September 27, 1996
The usenet machine usenet.rpi.edu is a Sparc/10 running Solaris 2.5 and ODS 3.0 with 64 meg of memory and FDDI.
The main process is inn which coordinates a number of other processes for forwarding, receiving and reading news. All NNTP processes run as user usenet .
To shutdown and restart the news service use the /etc/init.d/usenet script with the stop and start options. After doing a stop check that all usenet owned processes (except innwatch ) have stopped. This script will be called as part of the normal Solaris startup and shutdown procedure.
The operation of inn is monitored by the daemon script innwatch . This script does two things:
Occasionally you may get mail from innwatch when the expire process finishes, or as logs are rolled over. This is because inn is temporarily throttled during these times.
The inn daemon is controlled with the ctlinnd command (the usenet login has this aliased to ct ). Some common ct operations are:
usenet:[1003]:ct mode Server running Allowing remote connections Parameters c 14 i 0 (6) l 1000000 o 51 t 300 normal specified Not reserved Readers separate enabled
Both of these commands edit the /usenet/lib/active file. Under normal circumstances, these should be the only way that file gets edited. If the active file is corrupted, inn will throttle. (See active(5) for the format of the active file.)
inn records lots of information in various log files. These files are kept in /usenet/logs and are summarized once a day by the news.daily script (run out of cron). This script also: rotates log files, runs expire to delete old news, runs expireover to create a new overview database, rotates the tires and checks the oil (I haven't discovered all that it does, but it does a lot and has lots of options---see news.daily(8)).
The results of the log summaries are mailed to usenet. They include partition sizes, batch file sizes, summaries of connections and messages transferred and error messages. We run news.daily 3 times. Once to summarize the logs, and twice to do expires. Mail is sent after each run, but the expire runs give a simple snapshot of the state of usenet.
The outgoing feeds are handled by nntplinks. They are specified in the file /usenet/lib/newsfeeds. The outgoing batches are stored in /usenet/batch/out.going. The links program is used to report on, and fix the state of nntplinks processes.
Note: Stopping the nntplinks does not stop batch spooling. Articles are spooled to /usenet/batch/outgoing by inn as specified in the /usenet/lib/newsfeeds file. The articles listed in the batch file are forwarded by nntplinks. links start: Start outgoing links.
To add an outgoing feed do:
Note, if news.clarkson.edu should contact you, their entry is commented out of /usenet/src/inn/site/newsfeeds (search for ``KENT''). Un-comment and proceed. Also, their incoming links have not been shutdown (they work), so hosts.nntp does not have to be edited or reloaded.
Access to newsgroups is controlled by
nnrp.access. All subnet 24
hosts can read and post to the
its.* newsgroups. Authenticated Xyplex
can read and post. Nim and unauthenticated Xyplex cannot post. Occasionally
there is a machine not on subnet 24 that needs to read and post to the
its.* groups. To add a machine to this list:
/usenet/src/inn/site
Gail makes the groups. If the group is unmoderated nothing else is needed. For a moderated newsgroup, a new aliases entry is needed on the usenet machine to forward the mail to the moderator.
ct newgroup <group> y is all that is needed. Gail usually does this, but you may have to if she is out.
Gail usually does these first two.
These are posts that for one reason or another could not be posted to usenet via the mail2news program. This happens if inn is throttled when the post arrives, or if usenet is down. The are bounced mail from the usenet machine (which goes to the usenet administrator). Simply repost them to the correct group.
Most ``official'' new groups are created automatically, and you will see them in the daily log reports. Occasionally an RPI resident will ask for a new group, and frequently requests to create new groups will come to usenet. To create these groups follow the actions above, except that a new moderated group may require that /usenet/src/inn/site/moderators be edited according to instructions (included with the request).
If a request comes to remove an obsolete or ``joke'' group just cut and paste the ctlinnd command listed in the request message.
You usually find out about these from innwatch. First, run ct mode to see why is it throttled? If innwatch throttled it the message will say something like `` /usenet/spool over x space.'' Other reasons are a corrupt active file, in which case the error needs to be fixed. (Under no circumstance use makeactive. This would loose all of the moderator information, aliased entries, etc. It really is a last resort.)
To un-throttle inn use ct go ''. Note, if the reason is something like ``expire running'' and expire is running, give it time to finish before worrying about a throttled inn.
The news items are stored as files in /usenet/spool. We are currently running with the spool at about 30-35% full. This is lots of overhead. If, for some reason, this should start climbing it could mean there is trouble. Start by trying to determine why we are using so much space.
The /usenet/batch partition can fill if the outgoing feeds go down. All of the active feeds were up last I checked (I shutdown the inactive feeds). If /usenet/batch starts filling check the files in the out.going sub-directory. They should not bee too large (e.g., they currently take up 12% of the partition). If they are large, it means the feed is down.
Once the feed is shutdown, the spool file can be moved to a partition with more room (such as /private/spool ).
Running out of space on the /usenet partition is about the worst thing that can happen. If this partition fills, the history file could become corrupted, and expires.
The history file is stored in /usenet/lib . The expire process reads the history file (a history of every news message that comes through the system). This is an active and big database. The current history file is 9.6 meg, and it can be about 12 meg during the busy season.
As it reads through the history file expire creates a new ``expired'' copy of the history file in /usenet/lib/lib-inn . So, the /usenet partition must be big enough for both the current and new history file, and associated db files. Expire also makes a list of articles to expire in /usenet/lib and a list of what it did expire in /usenet/logs .
If space in /usenet is getting tight you can:
If for some reason the expire should fail without completing, the history file in /usenet/lib is the correct history file. Make a copy of it to a safe place (such as campus) and check out the news-recovery man page. The good news is, there is no usenet problem that cannot be fixed by restarting inn and waiting 3 days.