Notice: This material is excerpted from Running A Perfect Internet Site with Linux, ISBN: 0-7897-0514-1. The electronic version of this material has not been through the final proof reading stage that the book goes through before being published in printed form. Some errors may exist here that are corrected before the book is published. This material is provided "as is" without any warranty of any kind.

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.

Chapter 9 - Installing UseNet Server Software

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:

Do You Need a News Server on Your Site?

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:

Do You Want To Run an Organizational News Server?

Disk space, bandwidth, and your users' privacy are important considerations for you when deciding if you want to run an organizational news server.

Disk Space Considerations

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 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%
   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%
   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%
   8 170000  1244   80% 34342    51.9    24%  0.22   2.1%
   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 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."

Bandwidth Considerations

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.

User Privacy Considerations

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.

Do You Want To Run a Full News Server?

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.

Configuring Your News Server

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.

Assigning Mail Aliases

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:

  1. Log in as root.
  2. Change to the directory /usr/lib.
  3. Edit the file aliases.
  4. To add the news alias so that it points to root (to enable people to send e-mail to the user news and have that mail go to the system administrator), add the following line:
  5. news: root
  6. To add the usenet alias so that it points to root (because some programs and scripts want to send mail to usenet instead of news), add the following line:
  7. usenet: root
  8. Save and exit the file.

Now, to make sure your system has the new version of the aliases file in memory, type newaliases and press Enter.

Adding INN to System Startup

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:

  1. Log in as root.
  2. Change to the /etc/rc.d directory.
  3. Edit the file rc.local.
  4. To add INN to the list of items to run at startup, add the following line:
  1. The program is your INN startup script.
  2. Save and exit the file.

Adding INN to Your crontab

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:

# INN-1.4 (Inter Net News)
#     Sample crontab file by (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):

  1. SHELL=/bin/sh
  2. This line tells your system to start up an sh shell and use that shell to interpret the rest of the file.
  3. MAILTO=root
  4. This tells your system to send any mail regarding error messages to root.
  5. 0,15,30,45 * * * * /usr/lib/news/bin/sendbatch -c manlobbi > /dev/null
  6. This tells your system to send any outgoing news batches to your news feed every hour on the hour, and at 15, 30, and 45 minutes past the hour.
  7. Change manlobbi to an alias you'd like to use for your provider's news server. You'll soon add this alias to your newsfeeds file.
  8. 0 22 * * */usr/lib/news/bin/news.daily < /dev/null
  9. This tells your system to do its daily housekeeping chores (i.e., expiring news) every day at exactly 22:00 (10 PM). The exact tasks covered under "daily housekeeping" are listed in the file news.daily shown above.
  10. 15 * * * */usr/lib/news/rnews -U
  11. This tells your system to hand any spooled news to INNd that, for some reason, couldn't be dealt with in the previous attempt. This is done every hour at 15 minutes after.

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").

Making Sure Newsreaders Can Find the Necessary Configuration Files

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.

Modifying Your News Configuration Files

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

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.

##  Keep for 1-10 days, allow Expires headers to work.

##  Some particular groups stay forever.

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:

  1. /remember/:25
  2. News articles aren't sent to a sight just once. As they circulate, they'll often pass through your site a number of times. The remember function retains the history of the article (the official article number and other identifying features) after the article has expired.
  3. The line above tells your news server to remember a particular article for 25 days from the time it arrived at your site. This ensures that within those 25 days, you won't be storing another copy of the article.
  4. *:A:1:5:25
  5. This is a line defining what the server should do with articles for particular groups. You must have one line of this structure, starting with an asterisk (*:A), which refers to all groups, moderated and unmoderated. It's the only way the server will know how to handle groups to which you don't assign specific expiration procedures.
  6. The line reads as follows, from left to right:
  2. Here, I've set everything in the hierarchy (instead of all groups), both moderated and unmoderated groups, to have a minimum stay of one day, default stay of three days, and a maximum stay of five days. I made this choice because the posts that go through pictures groups are huge, and I can't afford to have too many days' worth filling up my hard drive.

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

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.

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

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

For example, I would fill the values of this file in as follows:

  1. domain:
  2. Don't include a host name here. It just wants the domain name you're registered with InterNIC.
  3. fromhost:
  4. The default here is the FQDN (Fully Qualified Domain Name) of the host. For example, if I didn't fill a fromhost in, and I posted from the machine catherine, then the From line of articles coming out from your site would show as Because I set it to just, the machine name will not be included in postings.
  5. moderatormailer: dee
  6. Generally, you'll use the moderators file instead of this feature. However, if you only have one moderator on your site, then all posts to moderated groups will go to that one person, so you can bypass the moderators file by setting it here.
  7. pathhost:
  8. As with fromhost, the default for pathhost is the FQDN (Fully Qualified Domain Name) of the host. Pathhost sets what machine shows in the path and Xref headers of articles that go out from your site.
  9. organization: Renaissoft Enterprises
  10. If the user doesn't set an organization in his own news configuration files, then the organization header contains what's set here. Often the default is the name of the provider, or if it's a business site, the name of the business.
  11. server:
  12. If the user doesn't set a local news server to connect to in his news configuration files, then his server is whatever is set here. The host name, news, is an alias I set to my server machine so the user doesn't have to know the exact machine or the port number that the news server is on.

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

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.

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

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:

  1. If the Distribution header matches anything you list here in the distrib section, the article is forwarded to the news server the distrib section relates to.
  2. If the Distribution header matches anything you list in the distrib section with an exclamation point in front of it, the article is not forwarded to the news server the distrib section relates to.
  3. If the Distribution header doesn't match anything you listed in the distrib section, and you don't have anything in the distrib section with an explanation point in front of it, the article is not forwarded to the news server the distrib section relates to.
  4. If the Distribution header doesn't match anything you listed in the distrib section, but there are items listed that start with an exclamation point, the article is forwarded to the news server the distrib section relates to.

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:

ME Definitions

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.

Other Site Definitions

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:

: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


Another method of providing newsfeeds is through UUCP. Here's an example of sending all of the comp groups to the UUCP site buddy.


The nnrp.ccess File

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.
# * Post:::*

*:: -no- : -no- :!*
*:Read Post:::*

An example access definition is as follows:

This definition breaks down as follows:

The nntpsend.ctl File

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.
# -t60
# -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 ( -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
-M      Changes MIME articles   -M
        that are not in seven-
        bit format to quoted-
-r      Don't requeue an article        -r
        if the remote server
        sends an unexpected reply
-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

The passwd.nntp File

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.

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.

History and Log File Creation

There are now a few empty files you need to create for your news server's use. Do the following:

  1. Log in as root.
  2. Change to the directory /usr/lib/news.
  3. Type touch history.
  4. Type touch history.dir.
  5. Type touch history.pag.
  6. Type touch errlog.
  7. Type touch log.
  8. Type chmod 664 history to change the permissions: the owner can read and write and everyone else to read only.
  9. Repeat the chmod for each of the files you just created.
  10. 10. Type chown history to set the file's owner and group to news.
  11. 11. Repeat the chown for each of the files you just created.

Making the Final Necessary Directories

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:

  1. Log in as root.
  2. Type sh to start an sh shell.
  3. Type to run the script.

Verifying Your News Server

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/

Connecting to Your Feed Site

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.

innd Won't Run

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.

Can't Send Out Posts

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 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.

Connecting to the Sites You Feed

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.

Clients Connecting to Your Server

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!

Individual Host Can't Connect

Make sure the host having problems connecting to your news server via news clients is listed in your nnrp.access file.

Posting Problems

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:

QUE Home Page

For technical support for our books and software contact

Copyright ©1996, Que Corporation