How to set up an UNIX news server

© January 1999 Roberto Zini

Copyright 1999 Roberto Zini, Strhold Sistemi Edp - Italy

Roberto Zini is a frequent contributor to the SCO newsgroups. Here he explains how to configure News. Roberto apologizes for his English, and asked me to "correct" it, but I really saw nothing that needed correcting, so all I did was add HTML formatting-so blame me for anything screwed up in that area- Tony Lawrence
Also note: https://www.zenez.com/tmp/ou8faqz/cache/269.html which explains how to compile Inn on Unixware and Open Unix 8.

Publishing Here

This article is also available in Italian at https://www.strhold.it/html/casehistory.html

Howdy ! This is an hopefully quick guide written to lead an UNIX system administrator (or whoever with some UNIX skills) to install and configure an INN 2.0 news server under SCO OpenServer 5.0.x. Despite the fact that "newsgroup" is a today widely used term (and most of all regularly "participate" in one or more groups), the installation and the configuration of an UNIX news server is not that easy; this is mainly due to the lack of documentation available (even if we'll see that this is not 100% true) and that sometimes it's difficult to retrieve a detailed "step-by-step" guide able to succesfully drive the administrator "to the hoop". Let's see if we can fill this gap.

What is a News server ?

OK, perhaps I'm not the most knowledgeable person to respond but I'll tell you my "idea" of this beast. A news server is a typically UNIX machine devoted to the switching of messages posted in "newsgroups" by people with common interests; this is not an "Email" server, since these messages are not private but are shared among many, in the sense that a message posted in a newsgroup will be read by several people scattered across the world. You can discuss about pretty anything your mind could imagine; you can talk about computer science, religion, arts, literature, music, sex, history and more (when, on the 22th of January '98, I asked our news server for the available groups, it replied to me with a list of 24683 items (one item = one newsgroup) and I know of several groups being added every day). When either you're interested in something or you want to discuss about a specific issue, you "post" a message; this message is then received by your server which, in turn, transmits it to other servers which are known to be interested in receiving it. Once these servers have been fed, other users can reply to the message and, by following the reverse path, these messages get sent back to you and so on. Depending on the newsgroup being chosen, you messages could be sent locally (I mean, within a limited geographical range) or worldwide. Please keep in mind that not all ISPs can offer this service; you have to ask in advance before configuring the whole stuff, or you'll risk to waste your time by configuring a service you couldn't use (and this is silly, isn't it ?).

OK, I want it; where can I find it ?

This depends upon your "spirit of adventure"; you can browse the 'Net for the INN (Internet Network News) sources to compile, but you must have a 'C' compiler installed on your machine and a good knowledge of UNIX programming in order to succesfully build the binaries. The official repository site is "ftp.uu.net", under the "networking/news/nntp/inn" path but there are several mirror sites scattered across the Internet. Alternatively, you can use the binaries included in the Skunkware 98 CD-ROM which comes shipped with the SCO OS 5.0.5 distribution (and this is our case since we're a little lazy guys ;-). Please keep in mind that you can configure INN under SCO OpenServer 5.0.x (where x is a number ranging from 0 to 5 - excluding 1 and 3 which have never been released) and UW7 and that the whole Skunkware stuff is available on the SCO's site (if you don't have the CD-ROM under hand).

Good, I've inserted the CD-ROM in the drive; where's the 'setup' icon ?

This is not Windoze so you have to be a little "creative" to get this stuff installed. Before proceeding, please check that :

- you have plenty of disk space available on your system. Depending on the newsgroups you want to subscribe to, the received articles could take a lot of space of your disk (ranging from some MB to several GB a day). - you have a working TCP/IP configuration (this is IMPORTANT) since the whole INN stuff is based upon the TCP/IP protocol. - if you use a DNS (Domain Name System), double check it's correctly configured since DNS issues are a real "pain in the ***" to solve.

Our environment is set up as follows:

demo.strhold.it (192.106.230.35) This is our LOCAL news server (the machine on which we'll install and configure the INN software. This machine receives/sends news messages from/to the ISP) and it's powered by SCO OS 5.0.5 .

bbs.strhold.it (192.106.230.2) This is our "simulated" remote ISP news server (under SCO OS 5.0.2). Please keep in mind that in the "real life" this server is usually located outside of your local network and you have to connect to it by using PPP, SLIP or a dedicated/leased line. Instructions on how to connect to the Internet by using one of the above protocols are not given in this guide.

fred.strhold.it (192.106.230.3) This is a local client we'll use to post and read news (Explorer 4.0 under Windows 95).

The above IP address are the ones we've used in our internal configuration; change 'em accordingly to your own needs.

First of all, you have to login on "demo" as "root" (the system administrator) and run "custom" (or scoadmin -> software manager); make sure you have the Skunkware98 CD-ROM inserted in your drive. Next, select Software -> Install New -> From <your_machine_name_here>-> CD-ROM Drive 0 (this is the path to follow under SCO OS 5.0.5). After a few seconds, a list of the available packages to install will appear on your screen; make sure the item labeled "SCO Skunkware 98 (ver 98.2)" is not checked (marked by an asterisk *). If it is, then the whole Skunkware software will be installed and this is not what we want; again, double check that the asterisk DOES NOT appear near the "SCO Skunkware 98 (ver 98.2)" entry. From the list you have to mark (move the up/down arrow keys and hit the SPACE key) the following packages:

- Unzip 5.3 - Pkunzip compatible unzip (ver 98.2) 
- Zip 2.1 - Pkzip compatible zip (ver 98.2) 
- Gzip 1.2.4 - GNU Compression Tools (ver 98.2)
- Inn 2.0 - InterNetNews (ver 98.2) 
- Perl 5.004_04 - Practical Extraction and Report Language (ver 98.2)
 

The zip/unzip packages are used the extract precious information files form the source archives, which are in turn compressed by using the above files. The Perl interpreter is necessary since some INN scripts are written in this language and Inn 2.0 is the news package we'll configure.

Please notice that the above packages are installed under the /usr/local directory (usually under bin - for the binaries - man - for the manual pages and so on). This is pretty useful since this "approach" allows you to "separate" system software from additional one (so, as an example, you can backup the whole /usr/local directory along with other users created files instead of backing up the whole system). The main disadvantage is that you have to add the above dir in your $PATH environment variable, so that you can run binaries stored in there. During our tests, we modified the .profile file as follows:

PATH=/bin:/etc:/usr/bin:/tcb/bin:/usr/local/bin:/usr/local/news/bin
 

This is for the Bourne shell; please change the PATH settings accordingly to the shell you're using (you can also add the above in the /etc/default/login file).

In order to access the software installed manual pages (for the packages which provides 'em) you'll have to modify the man(C) configuration files in order to force it to "point" to the new location. We modified /etc/default/man as follows:

MANPATH=scohelp:/usr/man:/usr/local/man:/usr/local/news/man
 

Thus making, you can type "man gzip" and you can have the gzip manual pages depicted on the screen. Unfortunately, some news manual pages have been formatted with the nroff package (a text formatting packages no longer distributed by SCO) so if you try to man(C) 'em you get error messages. There are 2 workarounds; you can install from Skunkware98 the groff package which does the same as the original one or use the deroff utility in order to strip down the formatting codes from the manual files. In both cases you have to invoke the man command with the -t switch in order to force it to use the preferred package to display the manual pages. We decided to use the second workaround so we created the /usr/bin/man1 file containing the following commands:

#!/bin/sh man -t/usr/bin/deroff $*
 

chmod it with mode 755 and try with man1 newsfeeds. You'll see the newsfeeds man pages depicted on the screen, but thus making you've lost the original format of the file (in the sense that the words are not well placed on the screen).

I'm a little confused; shall I go on ?

Sure; read on. During the INN installation, a new user has been added to the system. This user (named news) will be the "person in charge" of the INN stuff, in the sense that most of the configuration procedures will be executed by acting as this user. So the first thing to check is that his/her .profile contains the PATH change outlined above. Please notice that the $HOME dir for news has been set to /usr/local/news but the original $HOME dir (/usr/news) is still there. Under this dir we'll place some important files we're going to extract from the source package included in the Skunkware98 CD-ROM, as follows (please change your CD-ROM device and your mount point accordingly to your system configuration):

# mount -r /dev/cd0 /mnt 
# cd /mnt/src/news 
# cp inn_1.5.1* /usr/news
# cd /usr/news 
# gunzip *.gz # tar xvf *.tar 
# cd inn-1.5.1sec2
 

Under the above dir there are some files which contain A LOT of useful information about the INN configuration (in case something is not working properly), such as error messages and relative corrections, suggestions and so on. These files are :

Install.ms.1

Install.ms.2

FAQ/*

The Install* ones are in nroff format; again, you can read (and print) 'em by using the groff package or you can strip down the formatting codes by using the deroff utility (eg, deroff Install.ms.1 > Install1.txt). Please keep the above files under your hands since they do contain a lot of useful "tricks & tips" to successfully configure the software.

I'm impatient; let's start !

Ok, let's begin with the basic software configuration. My first advice is the following; supposing you're working at the system console with SCO OS 5.0.x or UW7, switch to ALT-F12 (SCO OS5) or CTRL-ALT-F8 (UW7), log in as root and keep the syslog depicted on that screen (tail -f /usr/adm/syslog). INN is especially designed to report misconfiguration and error messages to the syslogd daemon which, in turn, writes 'em down to the /usr/adm/syslog file. In case something is not working as expected, check the syslog file carefully and hopefully you'll get an appropriate error message describing the fault.

Next, log in as news on the ALT-F11 (CTRL-ALT-F7) screen (or whichever you want) in order to keep the man1 command described above under your fingertips; we'll now proceed with the configuration of some files which are deeply documented under /usr/local/man/news. I'm not going to give a fully detailed description of every single item you could configure, but I'll try to configure the system as its minimum in order to work properly. If you're confused about the meaning of a particular option or if you want to know more about it, please check the related documentation.

*/usr/local/news/etc/inn.conf

The above directory will contain most of the INN configuration files; this one (inn.conf) is the heart of the whole package. On every line you'll see a keyword and its associated value, separated by the ":" character; keep in mind that most of 'em are preconfigured and this means that while some are adeguate for most systems, you'll have to change some other parameters to better customize your environment. Let's see some of the parameters you'll probably have to change.

organization: put the name of your organization here

This parameter contains the name of the organization/firm/association for which the news server is being configured; every single message posted locally will have a line in the header section describing the server under which the messages has been posted. Place the name of your organization or firm here.

server : the FQDN of the ISP provider (the server to which we'll send locally composed message). In our case, bbs.strhold.it

pathost: the FQDN of the local machine (eg, demo.strhold.it)

domain: the local domain name (eg, strhold.it)

mailcmd: the name of the mailer the system will use for the reporting of INN related events

My suggestion is to proceed with the examination of the parameters with the related man page nearby; again, most of the parameters will work on most systems, but please check 'em carefully before proceeding.

*/usr/local/news/etc/incoming.conf

You have to tell your INN server the name of the sites allowed to feed news messages; they can be local ones (such as the machine fred equipped with Explorer 4) or remoted ones (such as the ISP machine). Again, the file is structured in the format name:value and every option is discussed in the related man page. Our file has been configured as follows:

streaming: true # streaming allowed by default 
max-connections: 8 # per feed 
peer ME { 
hostname: "localhost, 127.0.0.1" 
} 
peer bbs { 
hostname: "bbs.strhold.it, 192.106.230.2" 
}
 

As you can see, we've configured 2 systems; the first one is ME which corresponds to the local one (demo) and the second one is our simulated ISP server (bbs). In case your local system has to serve other machines, you have to insert their names here; accordingly to the docs (but not used in our case) you can restrict access by using a password (option password which defaults to no) and that you can specify the newsgroups list the remote system is allowed to send (option pattern, default * which means all). You can also group more options for a specific site, as follows:

peer bbs { hostname: "bbs.strhold.it, 192.106.230.2" pattern: "comp.unix.sco.*"
max-connections: 5 }
 

*/usr/local/news/etc/nnrp.access

This file contains the list of machine allowed to connect to the local server and post/read messages. Our file has been configured as follows:

## Default is no access, no way to authentication, and no groups. 
*:: -no- : -no- :!* 
# The following hosts are allowed to connect 
stdin:Read Post:::* 
localhost:Read Post:::* 
127.0.0.1:Read Post:::* 
demo.strhold.it:Read Post:::* 
bbs.strhold.it:Read Post:::* 
fred.strhold.it:Read Post:::*
 

The normal behavior is to deny access to all hosts not explicitally inserted in the list (see the first rule); in fact, we do specify the list of the host allowed to connect after the first line. If you plan to have a local machine which is interested in reading/posting news, you have to insert its FQDN (fully qualified domain name) here; this is very important, since machines not listed here are not allowed to connect. By default, we decided to let the above systems to connect in order to Read and Post new messages for all the newsgroups we locally have (*); you can however change this behavior by altering the above lines. Also (even if they're not used in our case), you can ask remote systems to provide a username and a password which are checked before allowing the connection (we left this fields empty - see the ::: placeholders). The last field (the allowed newsgroups) is worth mentioning; you can specify that a specific host is allowed to "participate" only in specific newsgroup, such as follows:

fred.strhold.it:Read Post:::comp.unix.sco.misc
 

Thus making, you specify that machine name fred.strhold.it is only allowed to post and read news concerning the comp.unix.sco.misc group. Check out the following line:

fred.strhold.it:Read Post:::comp.*,!comp.sources.*,comp.sources.unix
 

Machine fred.strhold.it is allowed to "participate" in all groups starting with comp. (such as comp.unix.sco.misc) while it gets access denied for the ones starting with comp.sources. (please notice the ! character before the group name), except for the comp.sources.unix one. As stated before, make sure that the FQDN you insert here is actually recognized by the system by carefully checking your /etc/hosts file and your DNS configuration.

*/usr/local/news/etc/newsfeeds

Once we've specified the sites allowed to connect to the local news server we have to tell the system where new received messages should be directed to; we have to fill in the above file, as follows:

ME\ 
:\ 
:: 
bbs/bbs.strhold.it\ 
:*,\ 
:Tf,Wnm:
 

The above file is a little bit unclear; let's shed some lights. Consider the file as divided into 2 sections; the first one is related to the local server and should be as depicted (believe me ;-) while the second one is related to the ISP machine. The first line on both sections contains the name of the remote server (ME is the local one, bbs/bbs.strhold.it is the remote one); the second line shows the list of newsgroups which have to be remotely sent (in our case, the * character means "all the groups handled by the local server" but you can use the wildmat format indicated above to "filter" specific groups). On the third line you can insert specific options which define the way local messages have to be sent to the remote site; the Tf flag states that the list of these messages is included in a file named /usr/local/news/spool/outgoing/<SERVER>, where the Wnm flag indicates that the above file will contain the relative pathname of the message (each message sent/received is locally stored in a file under the spool dir) and its relative message ID (which has to be unique in the world). There are some other parameters you can have in this file; please read the newsfeeds manual page in order to gather additional info.

*/usr/local/news/etc/nntpsend.ctl

But how do local messages get actually sent to the remote server ? INN has a specific program called nntpsend specifically devoted to this task; it scans the spool directory in order to find new messages and it sends 'em to the remote server. nntpsend.ctl specifies how the above program should operate; we defined the following options:

bbs:bbs.strhold.it::-t60

The first two fields contains the "short" and the FQDN of the remote server (the machine where local messages should be sent); the third one (we leave it empty) indicates the size that, once reached, should force the "fragmentation" of a message being sent. The last one contains the list of "switches" passed to the innxmit program (the program which actually performs the transmission since nntpsend acts as a frontend); we specify that innxmit should try up to 60 seconds to establish a connection to the remote server (usually it blocks until the TCP/IP connection to the remote machine is established). If the timer expires before connecting, innxmit will give up and send new messages later.

*/usr/local/news/etc/expire.ctl

Usually, news messages have an "expiration time" which, once expired, will cause the deletion of "old" messages from the system in order to free disk space. We'll see that there is a specific process (called news.daily invoked by cron) especially devoted to this task; under our configuration, the expire.ctl file is as follows:

/remember/:14
*:A:1:14:14
 

The first line states that articles should be maintained for at least 14 days; the second one states that a message should be maintained for (at least) 1 day, that after 14 days that message gets marked as "deletable" and that the expiration time is 14 days after the receiving of the message. You can specify other options as indicated in the expire.ctl manual page, such as follows:

comp.unix.sco.*:A:1:14:21

Thus making, all articles pertaining to the comp.unix.sco.* group should be maintained for 21 days (maximum).

I'm tired; gimme a break !

Ok, have a coffee (or a cigar).

We've just completed the first step of our configuration; let's proceed to the second one. The /usr/local/news/bin/rc.news file fires up the news server (nntpd) so we have to make sure this file is executed during the system startup; so, it's a good idea to create a "link" between this file and a new one which will be placed under /etc/rc2.d. Under this configuration, this file will be named /etc/rc2.d/S86news and will be link(C)ed to the rc.news stored in the /usr/local/news/bin directory.

Next, we have to make some changes to the /usr/local/news/bin/inndstart, as follows:

cd /usr/local/news/bin
chown root:sys inndstart
chmod u+s inndstart
 

Switch to the /usr/local/news/db and issue the following commands:

touch history
touch active
chmod 666 history active
chown news:group history active
 

The active file will contain the list of newsgroups we want to receive but presently it's empty; with an editor of your choice, insert the following lines EXACTLY as depicted below:

control 0000000000 0000000001 y
junk 0000000000 0000000001 y
 

If you're unsure about the permissions given to a specific file, you can use the inncheck command to test the whole package for errors and/or wrong permissions; operating under user news, issue the following command:

inncheck -f -perm | /bin/sh
 

inncheck will output the commands to execute in order to fix permission problems; it's also able to show files which have been misconfigured so try to execute it without switches and operate accordingly to the instructions given.

The /usr/local/news/etc/innshellvars file tries to execute the df command under /usr/local/bin while (on SCO OpenServer) this file is located under /bin; you can simply copy the df file under the /usr/local/bin directory or change the innshellvars file by replacing every occurrence of /usr/local/bin/df to /bin/df.

The same goes for the /usr/local/news/etc/innwatch.ctl (copy df under /usr/local/bin or change the file); also, you have to change every occurrence of the

NR == 2

string to

NR == 1

except for the one on line number 37 (leave it as is). While you're on this line, change the { print $7 } string to the { print $4 } one since awk(C) incorrectly checks the wrong input field.

Make sure you're operating as user news, switch to the /usr/local/news/db directory and issue the following command :

makehistory -ri

This command will create the history database in order to keep track of all received articles; it's pretty likely that makehistory will create the following files under the above dir:

history.n.dir
history.n.hash
history.n.index
 

These files have to be renamed as follows (delete the .n extension):

history.dir
history.hash
history.index
 

Switch to ALT-F12 and double check the /usr/adm/syslog file; if you don't see any errors, proceed to the first activation of the news server.

I'm looking forward to testing it !

OK; switch to the /etc/rc2.d directory and execute the S86news file. Make sure that /usr/adm/syslog reports the following lines (or something similar):

Jan 4 11:46:31 demo innd: SERVER descriptors 110
Jan 4 11:46:31 demo innd: SERVER outgoing 97
Jan 4 11:46:31 demo innd: SERVER ccsetup control:13
Jan 4 11:46:31 demo innd: SERVER lcsetup localconn:15
Jan 4 11:46:31 demo innd: SERVER rcsetup remconn:6
Jan 4 11:46:32 demo innd: bbs opened bbs:17:file
Jan 4 11:46:32 demo innd: SERVER starting
 

(change the date and the names depicted above accordingly to your configuration)

The above script will activate the innd daemon and will launch another script named innwatch, designed to watch over the news daemon; you can easily find it by executing the 'ps -ef | grep inn' command:

root 365 1 0 11:46:31 ? 00:00:06 /usr/local/news/bin/innwatch
news 363 1 0 11:46:31 ? 00:00:00 /usr/local/news/bin/innd -p6
 

innwatch will activate every 60 seconds so it's a safe procedure to wait at least 1 minute before proceeding with the tests; if you don't see error messages on the syslog, you're on the right path.

On the syslog file you could read some lines similar to the following one:

Jan 5 10:51:09 demo ctlinnd[528]: Reading config from /usr/local/news/etc/inn.conf

This is expected and it's not an error.

If, while starting, the S86news script will complain about the /usr/local/news/bin/innmail not found, it's likely that you have a misconfigured perl installation. Please verify that the very first line of the innmail is as follows:

#!/usr/local/bin/perl

This will tell the shell that the above script should be executed by the /usr/local/bin/perl command; if perl is located under another directory (such as /usr/bin/perl5) you have to change the above line accordingly to your configuration.

Also, S86news could fail if the previously created active file has been zeroed so make sure you've inserted the 2 lines (control and junk) as described above.

There are a lot of reasons which prevent S86news from starting up correctly, most of which are discussed on the FAQ/* files we extracted from the sources before configuring the package; please check 'em out carefully since they're a good starting point to solve configuration problems.

Does it work ?

Let's try it; issue the command 'ctlinnd mode' and compare the output with the one depicted below:

Allowing remote connections
Parameters c 14 i 50 (0) l 1000000 o 97 t 300 H 2 T 60 X 0 normal specified
Not reserved
Readers separate enabled
 

From the local machine, let's try to connect to the local news server which is listening on port 119; you can activate a telnet session as follows:

$ telnet demo 119
Trying 192.106.230.35...
Connected to demo.
Escape character is '^]'.
200 demo.strhold.it InterNetNews NNRP server INN 2.0 8-Jun-1998 ready (posting ok).
 

After 10 seconds, you'll notice the following message:

503 Timeout after 10 seconds, closing connection. Connection closed by foreign host.

This is expected; if you switch to ALT-F12, syslog should report the following:

Jan 5 11:09:40 demo nnrpd[818]: demo.strhold.it connect Jan 5 11:09:51 demo nnrpd[818]: demo.strhold.it timeout short Jan 5 11:09:51 demo nnrpd[818]: demo.strhold.it times user 0.000 system 0.020 elapsed 10.220

As you can see, demo.strhold.it has been allowed to access the server and, after 10 seconds of inactivity, it has been logged out. Let's test if the nnrp.access file has been correctly configured; fire up the same telnet connection from a machine which is NOT listed in the above file.

Trying 192.106.230.35...
Connected to 192.106.230.35.
Escape character is '^]'.
502 You have no permission to talk. Goodbye.
Connection closed by foreign host.
 

And syslog should report the following:

Jan 5 11:14:20 demo nnrpd[953]: 192.106.230.6 connect
Jan 5 11:14:20 demo nnrpd[953]: 192.106.230.6 no_permission
Jan 5 11:14:20 demo nnrpd[953]: 192.106.230.6 times user 0.020 system 0.000 elapsed 
0.010
 

You can now try with a valid group; first of all, pick a group devoted to testing purposes (here in Italy we have a specific group called it.test mainly used to test INN configuration - ask your provider for a list of these groups); do not post test messages on different groups or you'll be flamed by the posters (and this is not good).

First, insert it in the active file by executing (under user news) the following command :

ctlinnd newgroup it.test
 

DO NOT INSERT IT MANUALLY !!! ALWAYS USE ctlinnd !!!

Check the syslog file for the following message:

Jan 5 11:41:10 demo innd: SERVER newgroup comp.unix.sco.misc as y

The active file should be as follows:

control 0000000000 0000000001 y
junk 0000000000 0000000001 y
it.test 0000000001 0000000001 y
 

Now get in touch with your ISP news administrator and ask him/her if your machine (demo.strhold.it) is allowed to connect with the remote news server (basically, the ISP has to insert your machine name in its nnrp.access file); also, ask if the remote server does allow the use of the newnews command. This is a particular NNTP extension which allows the news client to pick a specific group and to download articles which have been posted after a specific date; I know that most servers DO NOT have this extension enabled due to security reason so you have to ask before proceeding.

If the ISP administrator tells you that you can safely use the newnews command, then you can use the nntpget binary to retrieve the articles related to the it.test group (or whichever group you did choose); as previously stated, the newnews command allows you to retrieve articles which have been posted after a specific date. nntpget will use the modification time of a locally created file in order to drive the download so it's time to create that file. Bring the machine down to single sure mode (just in case) and use asktime to bring the date back in the past (suppose now it's 01/10/1999; you can direct asktime to set the system date to 01/01/1999); once returned to the shell promtp, create the file as follows:

touch /tmp/it.test

(change the file name accordingly to the group chosen)

Next, use asktime to set the correct date back and bring the system to multi user mode; once your connection to the ISP is activated (you should be able to ping it or telnet it to port 119) issue the following command:

nntpget -o -v -u /tmp/it.test -n it.test bbs.strhold.it

(change bbs.strhold.it with the name of your remote ISP news server)

You should see the list of retrieved articles depicted on the screen (-v flag).

It's likely that during the period chosen (eg, from 01/01/1999 to 01/10/1999) no messages have been posted (received by the ISP server) related to the test group; you can either expand this period by setting a "distant" date (such as 12/01/1998) or you can ask your ISP for a group which is known to have some messages in.

If your ISP does not support the newnews command, then it's up to the provider machine to feed you with new messages; get in touch with the ISP administrator and ask him/her how to proceed.

Can I post locally composed messages ?

Sure. If you have a Windows machine around you can use Explore and/or Netscape Navigator to post a message (you can also use the UNIX version of Navigator); configure it in order to access your LOCAL news server (demo.strhold.it) at port 119 (default). During our tests, we posted a message on the it.test group named "This is a test"; the syslog file reported the following (date and time have been omitted):

demo innd: localhost connected 18
demo innd: ME HISstats 0 hitpos 0 hitneg 0 missed 0 dne
demo nnrpd[1339]: fred.strhold.it post ok 
<01be3899$3a129280$03e66ac0@fred.strhold.i>t
demo innd: localhost:18 closed seconds 0 accepted 1 refused 0 rejected 0
 

This confirms that the message has been received by the local server. Just to make sure, switch to the /usr/local/news/spool/articles/it/test directory (again, change the last 2 dirs accordingly to the group chosen) and hopefully you'll see the article listed as a file with the name 1 (since this is the first received article for this group).

Path: demo.strhold.it!not-for-mail
From: "Roberto Zini" <freddy@strhold.it>
Newsgroups: it.test
Subject: This is a test
Date: 5 Jan 1999 10:51:21 GMT
Organization: A.C.M.E. by Wile E. Coyote
Lines: 1
Message-ID: <01be3899$3a129280$03e66ac0@fred.strhold.it>
NNTP-Posting-Host: fred.strhold.it
X-Trace: demo.strhold.it 915533481 1339 192.106.230.3 (5 Jan 1999 10:51:21 GMT)
X-Complaints-To: usenet@demo.strhold.it
NNTP-Posting-Date: 5 Jan 1999 10:51:21 GMT
X-Newsreader: Microsoft Internet News 4.70.1155
Xref: demo.strhold.it it.test:2
 
Hi ! This is a test
 

As you can see, the article has been correctly composed; double check the headers to see if your Organization line has been put in correctly and that the From line is as expected (if you want to receive Email make sure you inserted your valid Email address in the client configuration).

To further check, fire up another news client (you can even use the same one you selected for your first post) and select the it.test group; you should see the above article available for browsing and (if you want) you can try by replying to the poster.

So far so good; we've just posted an article which can be locally read. But what about sending locally composed articles to our ISP server ? We can use the nntpsend command, configured by the /usr/local/news/etc/nntpsend.ctl file. As you might recall, our file has been configured as follows:

bbs:bbs.strhold.it::-t60

We want to send locally composed article to our "simulated" ISP server, named bbs. First, issue the following command to flush pending news articles:

ctlinnd flush bbs

Syslog will report the following messages:

Jan 5 12:19:35 demo innd: f:bbs Jan 5 12:19:35 demo innd: bbs flush Jan 5 12:19:35 demo innd: bbs opened bbs:18:file Jan 5 12:19:35 demo innd: bbs closed

As you can see, innd has created a local file (named bbs: did you remember the Tf flag in newsfeeds ?) which contains the list of local articles which have to be sent to the remote server. Not sure ? Let's check it out; switch to the /usr/local/news/spool/outgoing directory and look for the bbs file, which will contain a line similar to the one depicted below:

it/test/1 <01be3899$3a129280$03e66ac0@fred.strhold.it>

The first item is the article relative pathname (since the system has to insert the /usr/local/news/spool/articles path in order to find it) and the second one is the article ID (remember that this ID should be unique in the world). Now that we have the list of articles being sent, let's try by manually sending 'em; issue the following command:

nntpsend -d

You'll probably notice the following depicted on your screen:

$ nntpsend -d
nntpsend: [1933] start
nntpsend: [1933:1960] begin bbs Tue Jan 5 12:25:35 CET 1999
nntpsend: [1933:1960] innxmit -a -d -t60 bbs.strhold.it ...
nntpsend: [1933] stop
$ < 200 drake.strhold.it InterNetNews server INN 1.5.1 17-Dec-1996 ready
>mode stream
< 203 StreamOK.
> check <01be3899$3a129280$03e66ac0@fred.strhold.it>
< 238 <01be3899$3a129280$03e66ac0@fred.strhold.it>
> takethis <01be3899$3a129280$03e66ac0@fred.strhold.it>
> [ article 544 ]
> .
< 239 <01be3899$3a129280$03e66ac0@fred.strhold.it>
nntpsend: [1933:1960] end bbs Tue Jan 5 12:25:36 CET 1999
 

You can see the NNTP commands involved in the transmission; the local client (demo.strhold.it) puts the server in stream mode (mode stream), the server issues a numeric OK output (203 StreamOK,), the client asks the server if it wants to receive our message (check <msgid>), the server informs the client that it does want to receive it (238 <msgid>), the client then transfers the article to the server (takethis, [article], .) and the server informs the client that it has successfully received the message (239 <msgid>). The message body has been omitted (it's the [ article 544 ] line) and, at the end of the story, nntpsend closes the connection.

To make sure the article has been correctly transmitted, let's check our local syslog file:

demo innxmit[1966]: bbs.strhold.it stats offered 1 accepted 1 refused 0 rejected 0 demo innxmit[1966]: bbs.strhold.it times user 0.020 system 0.020 elapsed 0.050

As you can see, we offered 1 article which has been accepted by the remote server bbs.strhold.it. Since we are able to access bbs's syslog, we're in the position to confirm that everything has worked as expected.

bbs innd: demo.strhold.it connected 14 streaming allowed bbs innd: demo.strhold.it:14 NCmode "mode stream" received bbs innd: demo.strhold.it:14 closed seconds 0 accepted 1 refused 0 rejected 0

OK, since we now know that the system is working correctly we want our local server to automatically send locally composed messages to the remote one; we decided to write down a simple shell script (which simply executes the above commands) and to have it executed on regular basis by cron. Here's the script:

#!/bin/sh
#
PATH=/bin:/etc:/usr/bin:/tcb/bin:/usr/local/bin:/usr/local/news/bin
 
ctlinnd flush bbs 1>/dev/null 2>&1
sleep 5
nntpsend 1>/dev/null 2>&1
 

We named it /usr/local/news/bin/send_news and we made it executable by using chmod +x send_news (just to make sure it works, please post another article locally and execute the above script to have it remotely transferred). Next (as user news) issue the following command:

crontab -e

and insert the following line:

0,30 * * * * /usr/local/news/bin/send_news

Thus making we ask the local server to connect to the remote one every 30 minutes in order to transfer locally composed messages; if there aren't any, the nntpsend command will immediately return.

Please keep in mind that the above solution implies that you have a permanent connection to the ISP server; if this is not your case, you have to fire up your Internet connection first, and then you can execute the upload script.

Boy, that was easy !

We have to tune up the system a little bit; News.daily is a program which, as the name implies, runs daily to check the system configuration and to perform daily maintenance works (such as the deleting old messages, the renumbering of the active file and so on). Once it completes, it sends an Email message to the NEWSMASTER user (usually root but you can change it by editing the above field in the innshellvars file). We can use cron in order to have it executed once a day:

40 23 * * * /usr/local/news/bin/news.daily delayrm
 

We decided to fire it up ad 23:40 every day and we issued the delayrm command in order to speed up the articles deletion. If everything is working fine, root will received the following Email:

Subject: demo.strhold.it Daily Usenet report for Tue Jan 5 14:19:39 CET 1999
 
Server status:
Server running
Allowing remote connections
Parameters c 14 i 50 (0) l 1000000 o 97 t 300 H 2 T 60 X 0 normal specified
Not reserved
Readers separate enabled
 
Disk usage:
/usr/local/news/db (/dev/root ): 158422 blocks* 44292 i-nodes
/usr/local/news/etc (/dev/root ): 158422 blocks* 44292 i-nodes
/usr/local/news/log (/dev/root ): 158422 blocks* 44292 i-nodes
/usr/local/news/spool/articles (/dev/root ): 158422 blocks 44292 i-nodes
/usr/local/news/spool/incoming (/dev/root ): 158422 blocks* 44292 i-nodes
/usr/local/news/spool/outgoing (/dev/root ): 158422 blocks* 44292 i-nodes
/usr/local/news/spool/overview (/dev/root ): 158422 blocks* 44292 i-nodes
 
Batch file sizes:
 
Log file sizes:
0 errlog 0 news 0 news.err 0 nntpsend.log
2 expire.log 0 news.crit 0 news.notice 0 unwanted.log
 
Lock files:
LOCK.innwatch
 
Server connections:
 
TOTAL: 0 0
 
 
usage: rm [-fiRr] file...
 
Renumbering active file.
Expire messages:
expire begin Tue Jan 5 14:20:14 CET 1999: (-v1 -z/usr/local/news/log/expire.rm)
Article lines processed 2
Articles retained 2
Entries expired 0
Files unlinked 0
Old entries dropped 0
Old entries retained 1
expire end Tue Jan 5 14:20:15 CET 1999
        all done Tue Jan 5 14:20:15 CET 1999
---------
 
Post expiration status:
 
Server status:
Server running
Allowing remote connections
Parameters c 14 i 50 (0) l 1000000 o 97 t 300 H 2 T 60 X 0 normal specified
Not reserved
Readers separate enabled
 
Disk usage:
/usr/local/news/db (/dev/root ): 158400 blocks* 44283 i-nodes
/usr/local/news/etc (/dev/root ): 158400 blocks* 44283 i-nodes
/usr/local/news/log (/dev/root ): 158400 blocks* 44283 i-nodes
/usr/local/news/spool/articles (/dev/root ): 158400 blocks 44283 i-nodes
/usr/local/news/spool/incoming (/dev/root ): 158400 blocks* 44283 i-nodes
/usr/local/news/spool/outgoing (/dev/root ): 158400 blocks* 44283 i-nodes
/usr/local/news/spool/overview (/dev/root ): 158400 blocks* 44283 i-nodes
 
Batch file sizes:
 
Log file sizes:
0 errlog 0 news 0 news.err 0 nntpsend.log
2 expire.log 0 news.crit 0 news.notice 0 unwanted.log
 
Lock files:
LOCK.innwatch
 
Server connections:
 
TOTAL: 0 0
 

Next, touch(C) the /usr/local/news/etc/.news.daily file; this file is being updated daily by news.daily in order to inform the administrator that the script executed correctly.

As you might recall, during the execution of the /etc/rc2.d/S86news script, two files get executed; the first one is innd (the INN daemon) while the second one is innwatch. The latter constantly watches over the former in order to ensure everything is working as expected. You can configure the operations carried out by the program by editing the /usr/local/news/etc/innwatch.ctl file; every line in this file is made up of 7 fields, as follows:

!label!state!condition!test!limit!command!reason

Depending on the state filed, the program executes the condition statements and it checks the return value test against the one indicated in the limit field; whenever there's a match, the command statement gets executed and the reason message gets logged to syslog. As an example, consider the following line:

!!! /bin/df . | awk 'NR == 1 { print $4 }' ! lt ! 8000 ! throttle ! No space (spool)

We have to ensure that there are at least 8000 hd blocks free on the system (as reported by df); the output of df . is "piped" 'thru the awk command which isolates the fourth field (number of free blocks) of the first output line. If this number is less than (lt) 8000, then the script will execute a ctlinnd throttle command to throttle the news server and the message No space (spool) gets logged on /usr/adm/syslog.

You (as the system administrator) may instruct the script to check for specific limits accordingly to your current configuration.

Where to check if something goes wrong ?

Have a look at the FAQ/* files we stored in the /usr/news directory; there are a lot of suggestions and workaround to solve INN specific problems written by knowledgeable people who knows INN way better than me. Also, the /usr/adm/syslog file is the FIRST file to check if something gets wrong.

As previously stated, there could be errors due to an incorrect network configuration; check /etc/hosts the see if local sites have been correctly inserted (IP_address short_name fqdn) and, if you use it, check the DNS configuration. For SCO OS 5.0.x, the /etc/resolv.conf should contain the entry

hostresorder local bin

in order to direct the resolver routines to search first in the /etc/hosts file and next to ask the remote DNS server.

You can safely use the inncheck program to check your local configuration; you can direct it to output changes to be made to the screen or you can pipe its output to /bin/sh in order to have the above changes executed for you.

That's all folks; I hope you enjoy your NEWS server !

© 1999 Roberto Zini, Strhold Sistemi Edp - Italy

Got something to add? Send me email.

---

Have you tried Searching this site?

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us