Copyright ©1996, Que Corporation. All rights reserved. No part of this book may be used or reproduced in any form or by any means, or stored in a database or retrieval system without prior written permission of the publisher except in the case of brief quotations embodied in critical articles and reviews. Making copies of any part of this book for any purpose other than your own personal use is a violation of United States copyright laws. For information, address Que Corporation, 201 West 103rd Street, Indianapolis, IN 46290 or at support@mcp .com.
Reading news and participating in UseNet and other news hierarchies is almost as popular an activity on the Internet as reading and writing e-mail. News is a way for people to participate in worldwide discussion forums or simply follow how various issues are viewed in other places.
Now is the time to decide whether you need to run a news server to handle news on your own site. If you do, it's time to install it!
In this chapter, you learn the following:
Many sites don't need to run their own news servers. Instead, their news software is configured to access the news server of their own provider. While this process takes a bit longer on the user's end, it saves a lot of your system resources for other tasks.
The following are two different types of news service that your site can offer:
Disk space, bandwidth, and your users' privacy are important considerations for you when deciding if you want to run an organizational news server.
Depending on the number of groups your users want access to and how much traffic each of these groups has, news can take up a small or huge amount of disk space. If you know which groups people on your site want access to, you can get an idea of the amount of material that comes through them on a regular basis by reading the file USENET_Readership_report for whichever month you are curious about. You can find this file via FTP at rtfm.mit.edu in the directory /pub/usenet-by-hierarchy/news/lists. The following is an example of what you will see in this file:
+-- Estimated total number of people who read the group, worldwide.
| +-- Actual number of readers in sampled population
| | +-- Propagation: how many sites receive this group at all
| | | +-- Recent traffic (messages per month)
| | | | +-- Recent traffic (megabytes per month)
| | | | | +-- Crossposting percentage
| | | | | | +-- Cost ratio: $US/month/rdr
| | | | | | | +-- Share: % of newsrders
| | | | | | | | who read this group.
V V V V V V V V
1 510000 3373 91% 39 0.6 22% 0.00 5.7% news.announce.newusers
2 260000 2759 57% 11408 11.5 46% 0.02 4.6% alt.sex
3 240000 1796 80% 78 0.3 0% 0.00 3.0% rec.humor.funny
4 220000 2508 51% 8307 58.7 34% 0.12 4.2% alt.sex.stories
5 200000 1348 88% 2451 0.5 99% 0.00 2.3% news.answers
6 180000 1205 87% 1 0.0 0% 0.00 2.0% news.announce.important
7 170000 2218 47% 18619 829.6 25% 2.00 3.7% alt.binaries.pictures.erotica
8 170000 1244 80% 34342 51.9 24% 0.22 2.1% misc.jobs.offered
9 160000 1119 87% 8296 14.0 2% 0.07 1.9% news.newusers.questions
10 150000 1104 83% 5161 7.0 21% 0.03 1.8% comp.lang.c
In the July 95 version of the USENET Readership Report, 3095 groups are listed, so it's fairly easy to get a feel for most of the groups your users might want to read.
When you have the raw numbers in front of you, it just takes a bit of math to figure out how much disk space a group might occupy. Take a look at the group misc.jobs.offered. The data passing through this group in a month totaled 51.9M. If you look at a 30 day month, that is 1.73M per day. If you want to be able to keep news on your site for a week (7 days) before it expires, then this group will consume around 12.11M of hard drive space as a general rule.
This is just one group, albeit one that takes up much more disk space than many pure text groups (such as news.answers, which only requires .5M in a month of traffic). However, as you can see with a quick glance at the top 10 groups listed above, if you are going to carry binary groups, you are going to have to be even more concerned about space!
If you don't think you'll have the hard drive space to handle the group load, then consider using your uplink's news server if this is possible. Especially if you feel you aren't able to purchase the kind of hard drive space you really need to meet your site's needs. When everything is up and running, you can take a look at how much hard drive space you have available and determine if you want to install a news server at that point.
Traffic in newsgroups can fluctuate from month to month. If you're particularly concerned about disk space, you may want to average the traffic for the groups you're looking at over a few months' worth of samplings.
You can mount /var/spool/news from a hard drive dedicated to that directory just like you can do with /home. The process for mounting remote directories is discussed in chapter 5, "Setting Up Your Site for General Use."
If you run your own news server, your site must periodically download the new news for every group you carry (e.g., once an hour). If you have a "slow" connection, such as one at 28.8 kbps, and unless you carry a minimal number of groups (high traffic binary groups count for more than one in this case), your news transfer can take a painful bite out of the bandwidth you have available every time your site downloads new news postings. Even with an ISDN connection at 64 kbps, a large amount of news traffic can take a chunk out of your bandwidth for every download.
To get a feel for the effect your news traffic will have on your bandwidth, use the calculations you made in the previous section. If you calculate that your news traffic will be around 750M per month, that's 25M per day (for a 30 day month). If you download new news posts once per hour, that's approximately 1M per hour.
If your connection is at 64 kbps, it will take approximately 2 minutes for 1M of data to pass through your connection if only news traffic is traveling at the time (time taken from experience). So, once an hour for an average of two minutes, your connection would be rather slow until the news transfer finishes.
This in itself can be annoying if you are trying to do something bandwidth-intensive when the news transfer hits. The more groups your users want, the more news traffic you will have. So if you find that you need to carry 2M or 3M worth of news, suddenly your bandwidth is slow for 4 or 6 minutes. That doesn't count anything else you and your users are doing that also eats up bandwidth, which will slow the news transfer down.
Another solution to this problem is to download news from your feed site only at off times. The longer you wait between news downloads, the longer it will take. However, if you only update your newsgroups at 1 AM and 5 AM, for example, it won't matter too much to most folks if your bandwidth is slowed down for an hour or two. It simply depends on how often you want to have news updates available to yourself and your users.
However, if your provider has limited bandwidth, they may not appreciate the long drain on their resources.
Although it's easy to talk about asking your users for the newsgroups they want to read, or asking them to tell you if they want you to add anything, it can be an invasion of their privacy to do so. For example, a user may want to read or participate in a counseling newsgroup of some sort, and it's really none of the provider's business. After all, users can post anonymously, so there is no need for anyone to know who is reading and/or participating in a particular group.
Dealing with this issue is tricky. You may seriously want to consider using your provider's news server unless you have one of the following:
Privacy is an important issue for Internet users. No matter how many users you have, it is important to try to deal with them in a professional manner as a system administrator. Unless there is a serious reason to do so, you should not look into users' home directories.
If you offer paying accounts and require users to list the newsgroups they want to read, then people may decide against using your site.
An excellent place to start looking regarding legalities and privacy issues on the Internet is the Electronic Freedom Foundation's (EFF's) Web pages. This group, according to the first portion of their main Web page, is "A non-profit civil liberties organization working in the public interest to protect privacy, free expression, and access to online resources and information." The URL for the EFF is EFF.
If you have a large site with large bandwidth (e.g., T1), you may want to run your own full news server. By full news server, I mean a server just like your provider's: one that not only brings news in to your site, but passes news on to other sites, who may yet pass it on to other sites (see fig. 9.1).
Fig. 9.1 Full news servers take in news from a feed and pass it on to other sites, who may pass it along as well.
A full news server always has a connection open to its feed site and the site it feeds, using a program called NNTPlink. Your provider has certain requirements that must be met by those who want to connect to their news server. Sometimes they may require a T1 or better, but there is no standard. This is something you will have to ask your provider about.
Of course, your newsfeed will also require an immense amount of disk space if you're going to carry a full feed. You'll need several gigabytes of disk space to store all of the news you'll be carrying. So, basically, unless you are running a large provider or company site, you probably won't have the necessary resources for a full feed.
The news server you are going to use (if you choose to run one) is INN. Fortunately, Slackware handles the actual installation for you, so this is one server you won't have to compile! There is quite a bit of configuration to do, however, so take it one step at a time.
You need two mail aliases on your site for INN: news and usenet. (In this example, you point them to root.) To add these, do the following:
Now, to make sure your system has the new version of the aliases file in memory, type newaliases and press Enter.
With most of the servers you'll deal with in this book, you add them to the file inetd. In this case, INN goes in the file rc.local. The reason for this is that the servers listed in inetd are started when they're needed; for example, when someone tries to get into your system via Gopher, the Gopher server starts up and handles the request. INN, on the other hand, sits quietly in the background all of the time, so it needs to be listed in rc.local among the other startup processes. The file rc.local is the last system startup script that's run when you're booting your machine. It's used to start up daemons and servers.
To add INN to the startup items for your system, do the following:
To automate a few of INN's duties so you don't have to make sure it does them, add some things to your system's crontab. A sample containing some recommendations is included with INN in the file crontab-news, as follows:
SHELL=/bin/sh # MAILTO=root # #=============================================================================== # # INN-1.4 (Inter Net News) # # Sample crontab file by andreas@knobel.knirsch.de (Andreas Klemm) # # copy it to /usr/spool/cron/crontabs/news # # Reboot your system or # kill and restart the crond job, to activate this file # #=============================================================================== # #------------------------------------------------------------------------------- # send news batches to your news feed #------------------------------------------------------------------------------- # 0,15,30,45 * * * * /usr/lib/news/bin/sendbatch -c manlobbi > /dev/null # #------------------------------------------------------------------------------- # Daily housekeeping ... expires news and other things ... #------------------------------------------------------------------------------- # 0 22 * * * /usr/lib/news/bin/news.daily < /dev/null # #------------------------------------------------------------------------------- # offer spooled news - that was spooled into the incoming directory when the # INNd server wasn't available - again to the INNd server. #------------------------------------------------------------------------------- # 15 * * * * /usr/lib/news/rnews -U
Take the following quick walk through this file to see what it does (note that there's one change you'll definitely want to make):
If you don't like the intervals assigned to any of the processes above, feel free to change them to match your preferences and needs. (cron files are covered in more detail in Chapter 5, "Setting Your Site Up for General Use").
A lot of newsreaders are hardcoded to look for news configuration files in /usr/local/lib/news. However, your configuration files are in /usr/lib/news.
An easy way to ensure that people won't have problems when they use a particular newsreader is by using a symbolic (soft) link. A soft link creates a pointer to a file such that if someone tries to access the pointer, they are redirected to the file it references.
Create a soft link from the location some clients expect to find your news configuration files, to where yours actually are. The syntax is:
Therefore, type:
Be sure to enter the paths for symbolic links in the correct order! Otherwise, you will erase the original file you want to link to.
There are a number configuration files found in /usr/lib/news that need to be set up to meet your system's requirements. Let's go through them one by one and see what needs to be changed.
The expire.ctl file is used to tell INN how article expiration is to be handled (i.e., how long to keep an old article around before removing it from the hard drive). Take a look at the example file first, and then I'll discuss the modifications you may want to make:
## $Revision: 1.8 $ ## expire.ctl - expire control file ## Format: ## /remember/:<keep> ## <patterns>:<modflag>:<keep>:<default>:<purge> ## First line gives history retention; other lines specify expiration ## for newsgroups. Must have a "*:A:..." line which is the default. ## <patterns> wildmat-style patterns for the newsgroups ## <modflag> Pick one of M U A -- modifies pattern to be only ## moderated, unmoderated, or all groups ## <keep> Mininum number of days to keep article ## <default> Default number of days to keep the article ## <purge> Flush article after this many days ## <keep>, <default>, and <purge> can be floating-point numbers or the ## word "never." Times are based on when received unless -p is used; ## see expire.8 ## If article expires before 14 days, we still remember it for 14 days in ## case we get offered it again. Depending on what you use for the INNd ## -c flag and how paranoid you are about old news, you might want to ## make this 28, 30, etc. /remember/:14 ## Keep for 1-10 days, allow Expires headers to work. *:A:1:8:never ## Some particular groups stay forever. dc.dining*:A:never:never:never uunet*:A:never:never:never
Now it's time to configure your expiration times for news articles. Common choices are anywhere from three days to a week, depending mostly on how much hard drive space there is available to store the files. You can even set some hierarchies to expire differently than others, which is useful for large binaries groups that may threaten to overrun your drive space in only a matter of two days.
The following is an example of setting up an expire.ctl file and the decision process that goes into it:
I could continue with the list, assigning varying expiration rules to different hierarchies or specific groups. You can go as far as assigning different times to each group you carry.
The hosts.nntp file tells your server what sites it gets news from. An example of this file is:
## $Revision: 1.4 $ ## hosts.nntp - names and addresses that feed us news ## Format ## <host>: ## <host>:<password> ## <host> can be a name or IP address; no wildcards. Any hosts not ## listed here are handed off to nnrpd. # news.foo.com:
All you need to have in this file is the site that feeds you news. If it doesn't require a password, you just need the site name followed by a colon, as follows:
If it does require a password, you need to include it after the colon, as follows:
The INN.conf file tells your site the important data it needs to know about itself, such as its domain and host. The example file is as follows:
## $Revision: 1.5 $ ## INN.conf -- INN configuration data ## Format: ## <parameter>:<whitespace><value> ## Used by various programs and libINN. The following parameters are defined: ## domain Local domain, without leading period. ## fromhost What to put in the From line; default is FQDN ## of the local host. ## moderatormailer Where to mail moderated postings, if not found ## in the moderators file; see moderators(5). ## pathhost What to put in the Path and Xref headers; default ## is FQDN of the local host. ## organization If $ORGANIZATION doesn't exist. What to put in ## the Organization header if blank. ## server If $NNTPSERVER doesn't exist. Local NNTP server ## host to connect to. ## # organization: A poorly-installed InterNetNews site # server: news # organization: Andreas Klemm, 41469 Neuss, Germany server: knobel.knirsch.de domain: knirsch.de
For example, I would fill the values of this file in as follows:
You'll at least want to include definitions for the variables domain, server, and organization. The rest only if you want or need them.
The moderators file tells your system where to mail posts for moderated groups to their moderators instead of trying to post them directly to the group. The example moderators file is as follows:
## $Revision: 1.4 $ ## Mailing addresses for moderators. ## Format: ## <newsgroup>:<pathname> ## First match found is used. ## <newsgroup> Shell-style newsgroup pattern or specific newsgroup ## <pathname> Mail address, "%s" becomes newgroup name with dots ## changed to dashes. gnu.*:%s@tut.cis.ohio-state.edu *:%s@uunet.uu.net
The line assigning the reroute address, from left to right (using the first one listed as an example), is a follows:
If you look at the last line in the moderators file, you will see it covers all newsgroups because of the asterisk in the first field. Therefore, the only lines you need to add are those for any local moderated groups you have at your site.
The newsfeeds file defines how you distribute incoming news to the sites you feed. The basic structure for feed definition is:
The terms used above each have a particular function, as follows:
The default, if you don't include any distribs, is to send all articles in the groups to which they subscribe to all of your sites.
This item contains the miscellaneous other parameters available to you in a newsfeed definition. The flags (listed in table 9.1) you list can be in any order, and if you need to include a number with one, include it directly after the flag as part of the flag (no space between the flag and the number).
Table 9.1 Flags You Can Use in the Newsfeeds File
| Flag | Parameters | What it Does | Example |
|---|---|---|---|
| < | size | Defines the maximum size (in bytes) of an article you can forward to the site whose feed you are defining. If you don't list a value here, the default is forward articles of any size. | <size1000
Forward all articles smaller than 1000 bytes |
| Ad | Only forwards an article if it contains a distribution | Ad header | |
| Ap | Tells the server to not check the path header of articles before passing them on. | Ap header | |
| B | high/low | Sets the size of a buffer for use when large posts come through. Eliminates waiting for files to be written completely before they can be dealt with. Has two parameters, the first being the number of bytes the server should have waiting before it starts draining its buffer. The second is the number of bytes it should get down to before it stops writing and returns to buffering. The default value is no buffering. | B5000/2000 |
| F | name | Use this to assign Fspooled the name of the file your server will use if it needs to spool news for the site whose feed you're defining. The default path is /usr/spool/news. The default file is togo. | |
| G | count | Defines a maximum number of groups a post can be cross posted to and still be passed on to the site you're defining the feed for. | G10 |
| H | count | Defines a maximum number of sites a post can have in its path line and still be passed on to the site you're defining the feed for. The default for count is 1. | H20 |
| I | size | Defines the size (in bytes) of the internal file feed buffer. This buffer is used when there are more files trying to feed in than your system allows. Once the buffer reaches the size you set, the system starts writing the data out to files. | I1000 |
| Nm | Use this item if you only want moderated groups for the section you're defining. | Nm | |
| Nu | Use this item if you only want unmoderated groups for the section you're defining. | Nu | |
| S | size | Tells the server when to switch over to spooling data queued up to go to this particular feed site. If the data queued reaches the number of bytes specified, it's appended to the file used for the F flag if you set it. Otherwise, the spool is in /usr/spool/news/out.going/sitename | S1000 |
| T | type | Defines the type of feed (discussed in more detail later in this chapter) you're using for the site you're defining. The options are: | |
| c | Channel feed | Tc | |
| f | File feed (most common) | Tf | |
| l | Log entry only | Tl | |
| m | Funnel | Tm | |
| p | Program | Tp | |
| x | Exploder | Tx | |
| W | items | Used to control what information is written in the files used for file, channel, and exploder feeds. You can use more than one item, and each item is written to file in the order you refer to them after the W. The items you can write to file are: | |
| b | Size of the article in bytes | Wb | |
| f | The article's full path | Wf | |
| g | The newsgroup the article was posted to (or the first one if it's crossposted). | Wg | |
| m | Article's Message-ID | Wm | |
| n | The article's path relative to your spool directory | Wn | |
| s | The site that fed the article to your server, taken from the path header. | Ws | |
| t | Time the article arrived as seconds from the epoch | Wt | |
| * | Names of all of the sites that get this article (funnel entries) | W* | |
| D | The value of the article's distribution header, or ? if empty. | WD | |
| H | Tells the server to go ahead and write all of the article headers to the file. The Xref and Bytes header are included. If you use this item it, should be the only one you use. Otherwise, it will create a new line and then list all of the headers, probably duplicating information that was already written. | WH | |
| N | The value of the Newsgroups header. | WN | |
| O | The file's overview data. This data is used for the program overchan. If you use this item, it should be the only one in the list. | WO | |
| R | The information needed for article replication. | WR |
If the site is fed by a program feed, only the asterisk (*) item is of use.
This field is specific to which type of feed (see table 9.2) you're using to provide news to the site in question. Table 9.2 Types of News Feeds Available
| Feed Type | Distinctive Features |
|---|---|
| Log | Simplest of the feed types. The only data written when using this kind of feed is a mention in the news logfile. |
| File | Another simple feed, and also the default if you don't specify one. When a site is supposed to get a particular article, a line is written to the file that tracks what articles need to be sent. |
| Program | Each time an article comes in that goes to the site being defined, a process starts up to handle this article. |
| Channel | Each time an article comes in that goes to the site being defined, a line is sent to a process telling it about the article. If this process exits, it's restarted or the data is written to a file if it can't be restarted for the moment, and handled later when the process starts back up. This differs from the program feed in that there's only one process handling the articles. |
What you need for the param statement differs for each feed type, as follows:
You must have one and only one ME definition in this file. It also needs to be the very first server entry in the file. The ME item also serves as the base subscription for the sites you feed. It's added onto the beginning of each site's subscription list.
An example ME line is as follows:
This example breaks down as follows:
The control group carries control messages, which are used to make changes in your newsgroups on your site. If you run a large news server with a large group list, it's a good idea to use control because otherwise, you'll have to maintain it by hand. However, if you run a small site, you'll have problems with the month posting to control of the checkgroups file. This file resets the newsgroup listings of the server it goes to, so suddenly your partial listing would become a full listing! If you don't have the space to hold this, you definitely don't want the control group.
Also, the control group is used to carry control messages, such as article cancellations.
Here are some examples of setting up site definitions for various purposes.
You can set a site definition to handle archiving the posts for specific groups by sending the appropriate articles to an archiving program. Let's say you want to archive the posts to all of the comp.os.linux groups. The definition would look something like the following:
source-archive!\ :!*,comp.os.linux.*\ :Tp:/news/bin/archive %s
One method of feeding news to a site is by sending news batch files to the site downstream. Here I'll set the definition to send everything but local administration traffic to the site news.downstream.net.
downstream\ :!junk/!foo\ :Tf,Wnm:news.downstream.net
Another method of providing newsfeeds is through UUCP. Here's an example of sending all of the comp groups to the UUCP site buddy.
buddy\ :!*,comp.*\ :Tf,Wfb
The nnrp.access file defines what hosts clients can access your news server from, and what they're allowed to do (read and/or post). The example file is as follows:
## $Revision: 1.4 $ ## nnrp.access - access file for on-campus NNTP sites ## Format: ## <host>:<perm>:<user>:<pass>:<groups> ## Connecting host must be found in this file; the last match found is ## used, so put defaults first. ## <host> Wildcard name or IP address ## <perm> R to read; P to post ## <user> Username for authentication before posting ## <pass> Password, for same reason ## <groups> Newsgroup patterns that can be read or not read ## To disable posting put a space in the <user> and <pass> fields, since ## there is no way for client to enter one. ## ## Default is no access, no way to authentication, and no groups. # *:: -no- : -no- :!* ## Foo, Incorporated, hosts have no password, can read anything. # *.foo.com:Read Post:::* *:: -no- : -no- :!* *:Read Post:::*
An example access definition is as follows:
This definition breaks down as follows:
The nntpsend.ctl file defines the list of sites nntpsend transfers news to. The example file is as follows:
## $Revision: 1.2 $ ## Control file for nntpsend. ## Format: ## site:fqdn:max_size:[<args...>] ## <site> The name used in the newsfeeds file for this site; ## this determines the name of the batchfile, etc. ## <fqdn> The fully-qualified domain name of the site, ## passed as the parameter to INNxmit. ## <size> Size to truncate batchfile if it gets too big; ## see trunc(1). ## <args> Other args to pass to INNxmit ## Everything after the pound sign is ignored. # nsavax:erehwon.nsavax.gov::-S -t60 # walldrug:walldrug.com:1m:-T1800 -t300
This is the file where you assign the aliases you referred to in the other news configuration files. A breakdown of the second example above (walldrug:walldrug.com:1m:-T1800 -t300) is as follows:
Argument Use Example
-A Assign an alternate -A/usr/spool/news/outgoing
spool directory
to use if it can't find
an article.
-a Always rewrite batch file. -a
-d Print debugging -d
information.
-M Changes MIME articles -M
that are not in seven-
bit format to quoted-
printable.
-r Don't requeue an article -r
if the remote server
sends an unexpected reply
code.
-t How long to wait for the -t180
connection to be made.
-T Total amount of time an -T2000
article transfer should
be allowed to take.
-p Purge the batch file of -p
entries that no longer
exist
The passwd.nntp file contains the passwords you'll need to connect to the news server that provides your feed. You won't need to use this feature often; ask your provider.
The example file is as follows:
## $Revision: 1.4 $ ## passwd.nntp - passwords for connecting to remote NNTP servers ## Format: ## <host>:<name>:<pass>[:<style>] ## Clients need only one entry, for where INNd is running. The ## server will have more entries for connecting to peers to feed them ## articles. ## <host> Host this line is for. ## <name> Name to use to authenticate with ## <pass> Password to send, after sending name ## <style> Optional authentication style, defaults to "authinfo" ## <name> and <pass> can be empty string; a peer INNd doesn't need a ## <name>, for example. # news.foo.com:rsalz:martha
The example above breaks down as follows:
There's a fourth optional item that is not listed that defines the type of authentication to use. Ask your provider if this item is necessary to connect to the news server.
There are now a few empty files you need to create for your news server's use. Do the following:
Fortunately, this last part is taken care of for you! There is a script that will set up all of the remaining directories on its own. To run it, do the following:
Now that you have your news server installed, it's time to test the following:
The FAQs that come with INN are an excellent source for more information on all aspects of INN. Also, there are man pages available for almost all of the files you installed in this chapter, so be sure to check them out.
If you haven't started INNd yet (do a ps aux to see if it's in your process list), just type /usr/lib/news/etc/rc.news.
Before you can connect to your feed site, your provider has to properly have you in their files. You may need to get on the phone with them if you run into problems that don't make any sense to make sure you're properly entered. Especially make sure you're properly entered as a news server and have posting permissions.
Let's take a look at some of the problems you'll run into at this stage.
If you try to start up innd and it exits without doing anything, there are a few things that can cause this. Look in the /usr/local/news directory and make sure the file history exists. If the file doesn't exist, run the BUILD script that comes with the INN source.
If you can't send posts out from your site, make sure you have a newsfeeds entry listing the site the posts are supposed to go to! If you do, try to telnet into the machine that's your provider's news server to the nntp port (e.g., telnet news.server.com nntp). You'll get messages back from the news server telling you what permissions you have. Type help for help on what you can do at this stage, and quit to leave. If it doesn't tell you that you have posting permissions, contact your provider.
Make sure you have the sites that you feed news to set as feeders, which means that you include them in hosts.nntp. Also, if you require passwords and userids, make sure the news admin on the other end knows exactly what they need to use!
To figure out what's wrong with feeder connections, configure one of the machines on your site as a feeder, and try to log into your server. Take a look for the error messages you get from the server when you try.
If you have to edit your host.nntp file, don't forget to run ctlinnd reload afterwards. This command takes a fresh look at the hosts.nntp file.
When you set up shell accounts, include default configuration files for the newsreaders (in the skeleton file). This will cut down on a lot of problems from shell users!
Make sure the host having problems connecting to your news server via news clients is listed in your nnrp.access file.
To make sure people can post both on your site and locally, try from a few machines to post to a local group, and also to the group misc.test on the Internet, which is where all test posts should go. If you can't post locally and/or on the Internet, it's a problem with the server, not the client.
Check the following two things if your posts aren't getting out:
For technical support for our books and software contact support@mcp.com
Copyright ©1996, Que Corporation
