INN commit: trunk/doc (FAQ)
INN Commit
Russ_Allbery at isc.org
Sun Oct 5 23:44:50 UTC 2008
Date: Sunday, October 5, 2008 @ 16:44:50
Author: eagle
Revision: 8138
Merge FAQ into trunk.
Added:
trunk/doc/FAQ
(from rev 8137, branches/inn-faq/doc/FAQ)
-----+
FAQ | 1432 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 1432 insertions(+)
Copied: trunk/doc/FAQ (from rev 8137, branches/inn-faq/doc/FAQ)
===================================================================
--- FAQ (rev 0)
+++ FAQ 2008-10-05 23:44:50 UTC (rev 8138)
@@ -0,0 +1,1432 @@
+$Id: FAQ,v 1.68 2008-09-03 04:12:13 eagle Exp $
+
+From: Russ Allbery <rra at stanford.edu>
+Subject: INN 2.x FAQ
+Newsgroups: news.software.nntp
+Organization: The Eyrie
+Expires: 35d
+
+Archive-name: usenet/software/inn2-faq
+URL: http://www.eyrie.org/~eagle/faqs/inn.html
+Posting-frequency: monthly
+
+This FAQ is intended to answer frequently asked questions concerning the
+current versions of INN (INN 2.x and later) seen on news.software.nntp.
+It should be referred to in preference to the old INN FAQ, which only
+documents versions up to 1.7. It mostly covers INN 2.3 and later; earlier
+versions of INN may behave differently or use different configuration
+files.
+
+If you're reading this on Usenet, this FAQ is formatted as a minimal
+digest, so if your news or mail reader has digest handling capabilities
+you can use them to navigate between sections. In rn variants, you can
+use Ctrl-G to skip to the next section; in Gnus, press Ctrl-D to break
+each section into a separate article.
+
+Please send any comments, suggestions, or updates to rra at stanford.edu.
+Bear in mind when sending me e-mail that I receive upwards of 800 mail
+messages a day and have unanswered personal e-mail dating back six months
+or more, so please don't expect an immediate response. You may receive
+quicker responses by posting to news.software.nntp (even, due to the
+quirky way in which I read mail and news, from me).
+
+This FAQ is posted monthly to news.software.nntp, and is available on the
+web at <http://www.eyrie.org/~eagle/faqs/inn.html>.
+
+------------------------------
+
+Subject: Contents
+
+1. General Questions
+ 1.1. What is INN?
+ 1.2. What is the current version?
+ 1.3. Where can I get INN?
+ 1.4. Where can I find documentation?
+ 1.5. What newsgroups are there for INN?
+ 1.6. What mailing lists are there for INN?
+ 1.7. How can I support INN development?
+ 1.8. How can I contribute to INN?
+
+2. Terms
+ 2.1. What is tradspool (traditional spool)?
+ 2.2. What is CNFS?
+ 2.3. What are timehash and timecaf?
+ 2.4. What is overview?
+ 2.5. What are deferrals (NNTP code 431)?
+
+3. Specific Problems
+ 3.1. INN won't start after a new installation
+ 3.3. The news server isn't keeping up with incoming news
+ 3.4. news.notice is empty and the nightly report is missing things
+ 3.5. INN is running out of file descriptors
+ 3.6. Can't get debugging information out of INN
+ 3.7. Articles aren't being sent to remote peers
+ 3.8. sendmail isn't installed
+
+4. Error Messages
+ 4.1. innd: SERVER cant store article
+ 4.2. innd: SERVER internal no control and/or junk group
+ 4.3. Modification of read-only value attempted (Cleanfeed)
+ 4.4. tradspool: could not open ... File exists
+ 4.5. Binary posting to non-binary group (Cleanfeed)
+
+5. Problems on Specific Systems
+ 5.1. INN won't compile on SCO OpenServer / UnixWare / OpenUNIX
+ 5.2. Using raw devices on Solaris destroys the partition table
+ 5.3. Will INN run on Windows?
+ 5.4. Why aren't INN's files where the documentation says they are?
+
+6. How Do I...
+ 6.1. Set up a server with no external feeds, just local groups
+ 6.2. Process a single control message
+ 6.4. Feed all articles on a server to another server
+ 6.5. Rename a newsgroup
+ 6.6. Change the domain used for message IDs
+ 6.7. Use INN without a direct news feed
+ 6.8. Generate MRTG graphs for INN
+ 6.9. Hide the junk and control groups from users
+ 6.10. Modify the body of posts made through my server
+ 6.11. Hide the X-Trace header
+ 6.12. Run innd and nnrpd on separate ports
+ 6.13. Back up and restore an INN installation
+
+(Note that some numbers have been skipped. When questions are removed,
+the remaining questions are not renumbered to avoid breaking links in
+Usenet and mailing list archives.)
+
+------------------------------
+
+Subject: 1. General Questions
+
+Contained in this section are general questions about INN, where to find
+it, and things of that sort. It is aimed at the person who is not yet
+running INN, or who has general questions about how it works.
+
+------------------------------
+
+Subject: 1.1. What is INN?
+
+The README that comes with INN has this to say (in part):
+
+ INN (InterNetNews), originally written by Rich Salz, is an extremely
+ flexible and configurable Usenet / netnews news server. For a
+ complete description of the protocols behind Usenet and netnews, see
+ RFC 1036 and RFC 977 (or their replacements). In brief, netnews is a
+ set of protocols for exchanging messages between a decentralized
+ network of news servers. News articles are organized into newsgroups,
+ which are themselves organized into hierarchies. Each individual news
+ server stores locally all articles it has received for a given
+ newsgroup, making access to stored articles extremely fast. Netnews
+ does not require any central server; instead, each news server passes
+ along articles it receives to all of the news servers it peers with,
+ those servers pass the articles along to their peers, and so on,
+ resulting in "flood fill" propagation of news articles.
+
+ INN is free software, supported by Internet Systems Consortium and
+ volunteers around the world.
+
+For a more complete answer, see that file. A full description of what
+Usenet and netnews are is beyond the scope of this document; for a
+beginner's introduction, see the news.newusers.questions home page at
+<http://www.anta.net/misc/nnq/>.
+
+------------------------------
+
+Subject: 1.2. What is the current version?
+
+The most recently released version of INN is 2.4.5.
+
+INN development proceeds in two branches, as with many other free software
+projects. The STABLE branch is maintenance of the most recently released
+stable version, and only bug fixes are added to it. The CURRENT branch is
+the development version of the next release of INN.
+
+As mentioned in the next section, when installing a new INN server, you
+may wish to download the latest snapshot of the STABLE branch rather than
+the current full release.
+
+Note that the previous STABLE series for INN 2.3 terminated in the release
+of INN 2.3.5 and current STABLE snapshots are based on INN 2.4. You
+should therefore read the upgrade instructions in NEWS when upgrading from
+a STABLE snapshot before May 11th, 2003 to one dated after that.
+
+------------------------------
+
+Subject: 1.3. Where can I get INN?
+
+The download site for INN is <ftp://ftp.isc.org/isc/inn/>. In that
+directory are the various releases of INN, some additional documentation
+(particularly of security holes), the original INN Usenix paper.
+
+There is also a snapshots subdirectory, in which you will find daily
+snapshots of the INN CVS repository for the last seven days. The
+snapshots with STABLE in the name are the latest versions of the STABLE
+branch and may have some additional bug fixes over the current released
+version. The snapshots with CURRENT in the name are of the current
+development version.
+
+Please note: There is no guarantee that a snapshot will even compile, let
+alone function well as a news server. In particular, the CURRENT branch
+is under active development, and all sorts of things may be broken at any
+given point in time. Use snapshots with caution, and don't use snapshots
+from the CURRENT branch on any production system unless you're prepared to
+debug the inevitable problems in code that's actively changing and not yet
+thoroughly tested. (The STABLE snapshots should be fairly reliable,
+however.)
+
+------------------------------
+
+Subject: 1.4. Where can I find documentation?
+
+INN comes with extensive documentation. See the files INSTALL and README
+at the top level of the source tree, for starters. In addition, nearly
+every program and configuration file has its own Unix man page. The best
+place to start is by reading the entire INSTALL file and then from there
+discovering which configuration files and programs do what you want to do
+and reading their individual man pages.
+
+There are HTML conversions of the documentation that comes with recent
+versions of INN available at:
+
+ <http://www.eyrie.org/~eagle/software/inn/>
+
+For additional documentation beyond what is distributed with INN, start at
+<http://www.isc.org/inn.html> and follow the links.
+
+The documentation that comes with INN is fairly technical in nature and
+lacking in some more general details on configuring news servers. Some of
+the links off of the INN home page have additional overview documentation
+or documentation on how to set up servers for specific roles.
+
+Another good resource is the newsgroup news.software.nntp (and the Google
+archives thereof) and the archive of the inn-workers mailing list. A link
+to the latter is off the INN page referenced above.
+
+Finally, the following additional links may be useful:
+
+<http://web.inter.nl.net/users/Elena.Samsonova/unix/INN/v2.3/>
+ Excellent introductory and overview documentation for INN 2.3 and
+ later.
+
+<http://www.aplawrence.com/Unixart/newsserver.html>
+ A tutorial on setting up INN aimed at beginners using SCO Unix. While
+ it's mostly focused on SCO, it may be useful for any beginner to INN
+ and news servers.
+
+<http://www.kozubik.com/published/inn_tutorial.txt>
+ A tutorial on setting up INN on FreeBSD. Contains a lot of
+ information focused on FreeBSD and its preferred file layout, so may
+ be easier to follow than the generic instructions on that platform.
+
+------------------------------
+
+Subject: 1.5. What newsgroups are there for INN?
+
+news.software.nntp discusses all NNTP-based news servers, including INN.
+It's the best newsgroup for technical questions and discussion. The
+newsgroup news.software.b is also chartered for such discussion, but it's
+essentially dead now. General news administration questions are also
+on-topic in news.admin.technical (moderated) and news.admin.misc
+(unmoderated).
+
+news.admin.hierarchies covers questions of general hierarchy configuration
+and is where announcements of new news hierarchies are generally posted.
+news.admin.net-abuse.* covers the topic of network abuse and prevention
+(including spam), but is not for the faint of heart; it is extremely noisy
+to the point of being essentially unreadable without a lot of time and
+patience (and a good killfile).
+
+------------------------------
+
+Subject: 1.6. What mailing lists are there for INN?
+
+There are several INN-related mailing lists:
+
+inn-announce at isc.org
+ Where announcements about INN are set (no posting allowed).
+
+inn-workers at isc.org
+ Discussion of INN development (postings by members only).
+
+inn-patches at isc.org
+ Where to send patches for consideration for inclusion into INN (open
+ posting).
+
+inn-committers at isc.org
+ CVS commit messages for INN are sent to this list (no posting
+ allowed).
+
+inn-bugs at isc.org
+ Where to send bug reports (open posting). If you're an INN expert and
+ have the time to help out other users, we encourage you to join this
+ mailing list to answer questions. (You may also want to read the
+ newsgroup news.software.nntp, which gets a lot of INN-related
+ questions.)
+
+To join these lists, send a subscription request to the `-request'
+address. The addresses for the above lists are:
+
+ inn-workers-request at isc.org
+ inn-patches-request at isc.org
+ inn-committers-request at isc.org
+ inn-bugs-request at isc.org
+ inn-announce-request at isc.org
+
+inn-workers tends to be moderate volume (3-5 messages a day, but varying a
+lot depending on what's being discussed). inn-committers is occasionally
+higher volume but entirely automatically generated commit notifications.
+inn-announce is a low-volume moderated list containing only major
+announcements. The others see sporadic, mostly low, traffic.
+
+------------------------------
+
+Subject: 1.7. How can I support INN development?
+
+There are four major ways. First, like with any other free software
+project, a great way to support INN development is to join in yourself.
+If you know how to program and have an interest in working on a widely
+deployed and fairly intricate news server, we'd love to have your help.
+See the next question for more details.
+
+Second, even if you don't have the time or expertise to write much code,
+any contributions of documentation are *greatly* appreciated. There's
+always documentation work to be done, from maintenance of INN's technical
+documentation to tutorials and overviews for the new user or the user who
+wants to do something specific. Listen on news.software.nntp for what
+people are looking for, or ask on inn-workers. Similarly, beta testers
+are always welcome; if you have a test news server and some knowledge of
+how to diagnose server problems and want to try out the current
+development code and report any bugs you run into, that helps the
+developers immensely.
+
+Third, there are always more questions from new INN users to answer.
+news.software.nntp gets a regular stream of them, and it's a great way to
+help out intermittantly when you have a few moments to read news. If you
+can identify general solutions to frequent problems and pass them along to
+the INN maintainers in the form of documentation or suggestions, even
+better.
+
+Fourth, from the README:
+
+ Note that INN is supported by Internet Systems Consortium, and
+ although it is free for use and redistribution and incorporation into
+ vendor products and export and anything else you can think of, it
+ costs money to produce. That money comes from ISP's, hardware and
+ software vendors, companies who make extensive use of the software,
+ and generally kind hearted folk such as yourself.
+
+ Internet Systems Consortium has also commissioned a DHCP server
+ implementation and handles the official support/release of BIND. You
+ can learn more about the ISC's goals and accomplishments from the web
+ page at <http://www.isc.org/>.
+
+The ISC provides ftp and web space, CVS server access for developers, and
+mailing lists and archives. Donations to help support all of that are
+greatly appreciated.
+
+------------------------------
+
+Subject: 1.8. How can I contribute to INN?
+
+First, join inn-workers, since that's where all the development discussion
+takes place. The traffic isn't that high.
+
+Next, download a snapshot of the INN CURRENT branch as described above so
+that you have a relatively current source base to work from. You may also
+want to try configuring CVSup or some other update mechanism so that you
+can get the latest version directly out of CVS, or you can just use the
+nightly snapshots if you wish. Read the HACKING file at the top of the
+INN source tree for some general information and tips for working on INN.
+
+Then pick something that looks interesting to you, mention what you're
+doing on inn-workers if it's likely to affect other parts of the
+development, and have at it! The TODO file in the CURRENT tree has a
+pretty comprehensive list of things that could be done. Best to start
+with something small (getting INN to work correctly on a platform where it
+doesn't currently and which you have available is often a great start, or
+working on one of the supporting programs or scripts that's a bit easier
+to wrap one's mind around than the core INN daemons). Patches to INN
+should be sent to inn-patches at isc.org, or put on an ftp or web site
+somewhere and the URL sent to inn-workers if they're extremely large.
+
+------------------------------
+
+Subject: 2. Terms
+
+Here are definitions of some commonly used terms related to INN. (More
+definitions are welcome; this section is extremely incomplete at the
+moment and the FAQ maintainer tends not to recognize terms that need a
+definition for people unfamiliar with INN.)
+
+------------------------------
+
+Subject: 2.1. What is tradspool (traditional spool)?
+
+Traditional spool is called that because it's the way that all news
+servers used to store articles. A traditional news spool is a tree of
+directories matching the hierarchical structure of newsgroups. For
+example, the newsgroup news.software.nntp would be stored in a directory
+news/software/nntp under the root of the news spool, and next to the
+"nntp" directory in news/software would be a "readers" directory for the
+group news.software.readers.
+
+As of INN 2.3, traditional spool is completely integrated into the storage
+API as the tradspool storage method and use the same overview mechanisms
+as the rest of INN.
+
+Storing articles in the traditional spool format is slow relative to other
+storage mechanisms. It's probably nearly impossible to keep up with a
+full Usenet feed using pure traditional spool. It is, however, the
+recommended storage method for low-traffic local newsgroups and any
+newsgroups that you want to back up.
+
+For more details, see the INSTALL file.
+
+------------------------------
+
+Subject: 2.2. What is CNFS?
+
+CNFS is the Cyclic News File System, written by Scott Fritchie. It is a
+high-performance method of storing news articles, designed to avoid the
+high overhead involved in interacting with the file system when storing
+articles in individual files. CNFS stores articles sequentially in
+pre-configured buffer files. When the end of the buffer is reached, new
+articles are stored from the beginning of the buffer, overwriting older
+articles.
+
+It's the fastest article storage method in terms of write performance, and
+is recommended for storing binaries.
+
+For more details, see the INSTALL file.
+
+------------------------------
+
+Subject: 2.3. What are timehash and timecaf?
+
+These are two less-used storage mechanisms available under the INN storage
+API (similar in that respect to CNFS). Both can usefully be thought of as
+compromises between the write speed of CNFS and the fine-grained control
+over article expiration. INSTALL says for timehash:
+
+ Articles are stored as individual files as in tradspool, but are
+ divided into directories based on the arrival time to ensure that no
+ single directory contains so many files as to cause a bottleneck.
+
+and for timecaf:
+
+ Similar to timehash, articles are stored by arrival time, but instead
+ of writing a separate file for each article, multiple articles are put
+ in the same file.
+
+timecaf was new in INN 2.3.
+
+------------------------------
+
+Subject: 2.4. What is overview?
+
+Overview is summary information about articles in a newsgroup that is
+returned to news reading clients as a response to the XOVER command. It's
+a very common extension to the NNTP protocol that allows readers to review
+summary information about articles before taking the time (and bandwidth)
+to download the entire article.
+
+The canonical items of information included in an overview record are the
+Subject, From, Date, References, and Message-ID headers of the article,
+the byte count of the article, and the line count of the article. Nearly
+every server now also returns the Xref header (a list of the newsgroups
+carried by the server to which the article was posted and the article
+number in each of those newsgroups) as an additional field.
+
+Note that with the References and Message-ID headers, the overview record
+contains enough information to do article threading. It also contains all
+of the fields normally keyed on for client-side filtering (killfiles and
+the like).
+
+Generating overview information for a newsgroup on the fly would be
+prohibitively expensive, particularly for large groups, since the server
+daemon would have to find all of those articles and scan them to build the
+information. It would also be inefficient, since the overview information
+for a particular group will generally be requested many times by different
+clients.
+
+Any INN server that supports readers must therefore have an overview
+method configured. There are three different methods to choose from:
+tradindexed, which is the slowest but the best tested and most reliable
+and the method with the best recovery tools; buffindexed, which is fast at
+writing because it uses preconfigured large buffers like CNFS, but which
+is harder to recover; and the experimental ovdb overview method, which
+stores overview information in a BerkeleyDB database.
+
+------------------------------
+
+Subject: 2.5. What are deferrals (NNTP code 431)?
+
+Consider the following situation. You have two incoming peers, both of
+which are getting ready to offer you an article in streaming mode. The
+first sends you a CHECK <message-id> message, to which you respond
+affirmatively (i.e., you don't already have the article). Then, before
+that peer sends you the article with TAKETHIS, you receive a CHECK
+<message-id> from the second peer for the same message. What response
+does INN send to the second peer?
+
+If deferrals are enabled (noresendid == false in incoming.conf for that
+peer, the default), INN will send a 431 deferral telling that peer that
+you may or may not want the article; try again later. Chances are that
+when it retries, you will have received the article from the first peer
+and you'll just refuse it. But if the first peer dies before it ever
+sends you the article, this way you can still get it from the second peer.
+
+If deferrals are disabled, INN will refuse the article from the second
+peer, which means there's a possibility you'll lose news if the first peer
+dies before sending you the article.
+
+As a side note, some older versions of Diablo, upon receiving a deferral,
+turn around and immediately send the article via TAKETHIS, which is
+basically exactly what you don't want. (Chances are extremely high in
+practice that the first peer will come through with the article.)
+
+------------------------------
+
+Subject: 3. Specific Problems
+
+This section contains specific problems that are frequently reported when
+using INN, and includes fixes or suggestions for fixes. Candidates for
+inclusion in this section are any problems reported frequently on
+news.software.nntp or inn-bugs at isc.org. Contributions, including fixes,
+are very welcome.
+
+------------------------------
+
+Subject: 3.1. INN won't start after a new installation
+
+The most common cause of this problem is that inndstart isn't setuid root.
+inndstart must be installed owned by root and group news, mode 4550. The
+ls -l output for inndstart should look something like:
+
+-r-sr-x--- 1 root news 53768 Jan 8 00:47 inndstart*
+
+inndstart will automatically be installed with the right permissions if
+you run make install as root. If inndstart isn't setuid root, it will log
+errors to syslog when it tries to start and cannot. If you aren't seeing
+those error messages in syslog either, you probably haven't set up syslog
+properly (see 3.4).
+
+The other most frequent cause of this problem is not correctly following
+the instructions in INSTALL on how to set up the initial history database.
+After running makedbz, the initial history database files will have names
+starting with history.n. These files must be renamed to remove the ".n"
+before innd will start.
+
+------------------------------
+
+Subject: 3.3. The news server isn't keeping up with incoming news
+
+Start by looking for the profile information in your nightly report. That
+will tell you where the news server is spending most of its time and may
+identify the exact nature of the problem.
+
+This problem is quite frequently due to using the traditional spool
+storage format for news articles. This storage method is now too slow to
+be able to handle a full Usenet news feed (although with a more limited
+selection of groups it can still do just fine). If your server is
+spending a lot of time writing articles and you're using traditional
+spool, this is probably the problem.
+
+One possible solution would be to switch to CNFS as a storage mechanism.
+You can do this simply by configuring CNFS (see INSTALL for details),
+changing storage.conf to direct some or all of the incoming traffic to
+CNFS buffers, and then restarting INN. Older articles will continue to be
+stored in tradspool until they expire, but new articles will go into CNFS.
+
+------------------------------
+
+Subject: 3.4. news.notice is empty and the nightly report is missing things
+
+You have syslog set up incorrectly.
+
+INN logs nearly everything except article trace information via syslog.
+It expects syslog to write its log messages into particular files under
+~news/log, unless you gave it a different path at configure time. You'll
+need to set up logging of INN-related log messages in your system
+/etc/syslog.conf. See the "Configuring syslog" section in INSTALL.
+
+Note that you don't have to worry about rotating these log files;
+news.daily (which should be run nightly from cron) will take care of that
+and innreport generates a daily summary report from them.
+
+------------------------------
+
+Subject: 3.5. INN is running out of file descriptors
+
+You may need to increase your system file descriptor limits. See the
+"File Descriptor Limits" section of INSTALL for more details. This is
+particularly a concern on Solaris systems, since Solaris by default has an
+exceptionally low file descriptor limit.
+
+------------------------------
+
+Subject: 3.6. Can't get debugging information out of INN
+
+The INN startup process is quite complicated, involving the rc.news shell
+script and the setuid inndstart wrapper. This can make it rather
+difficult to get enough debugging information out of it to determine
+what's going wrong if it's crashing immediately after startup or otherwise
+having serious difficulties.
+
+One approach is to run innd by hand directly, giving it the -d option.
+This requires setting up a configuration where innd doesn't need to bind
+to privileged ports, however.
+
+Another, sometimes better option, is move the innd binary to another name,
+like innd-real, and put a shell script in its place. Here's an example,
+from Kai Henningsen:
+
+ #! /bin/bash
+ # allow core dumps
+ ulimit -c unlimited
+ # save any output
+ exec > /tmp/innd.log 2>&1
+ # who are we running as, anyway?
+ id
+ # show exported environment
+ export
+ # start innd (don't forget the arguments, or it will complain)
+ exec strace -o /tmp/innd.strace -f -F /path/to/innd-orig "$@"
+
+This starts innd under strace, suitable for debugging startup core dumps
+and the like. You can use this as a general model for a variety of
+debugging; for example, you could replace the strace invocation with an
+invocation of gdb and then start innd from inside gdb with the -d option.
+
+------------------------------
+
+Subject: 3.7. Articles aren't being sent to remote peers
+
+(This entry is based on a post by Jeffrey M. Vinocur.)
+
+Here's how to trace through INN's logs to figure out what's happened to a
+particular article. This should help you discover where the process of
+feeding an article to a peer broke down.
+
+1. First you look in the $pathlog/news file. There should be one line per
+ article (search for the Message-ID, or they're in order by time of
+ arrival if you know that).
+
+ If you don't see a line for the article in question, your innd has
+ never seen it. For articles being fed remotely, this means your peer
+ didn't feed it to you. For articles being posted to your server, this
+ generally indicates some sort of problem in nnrpd.
+
+ (The only other time you wouldn't see a line for the article in
+ question is if your innd has seen it in the past, and is considering
+ this attempt a "duplicate".)
+
+2. Next, look at the second field of the line you've found in
+ $pathlog/news.
+
+ If it's "-", then your innd rejected the article. The reason should be
+ at the end of that line.
+
+3. At this point, you should be looking at a line with "+" in the second
+ field. The article should be on your server at this point.
+
+ If it's not, either it's been canceled, or has already expired.
+
+4. You're now interested in whether the article was sent to your peers.
+ At the end of the same line in $pathlog/news, innd puts all of the
+ peers it thinks should receive this article.
+
+ If you don't see a peer you expect there, it indicates that
+ $pathetc/newsfeeds is not configured in the way you think it is.
+
+5. If a peer is listed at the end of the line, the article should have
+ been fed to that peer.
+
+ If a peer doesn't have that article, it's possible that the article is
+ spooled on your system somewhere. Check $pathspool/outgoing, or the
+ innfeed spool if the peer is configured to use innfeed. (It's probably
+ easier to look for error messages in $pathlog/news.notice than to
+ actually wade around in $pathspool/innfeed.)
+
+6. If you're sure the article isn't spooled, and it doesn't show up on the
+ peer, you have to consider the possibility that the peer has rejected
+ the article. Alternatively, it's possible that the peer has some
+ misconfiguration like the ones described above.
+
+ In either case, if you're sure that the article was offered to the peer
+ and not spooled, you will need the assistance of the peer's admin to
+ investigate further. INN does not generally log enough information
+ about outgoing articles to be able to tell more from your server alone.
+
+ It may be possible to get a slight bit of information from the remote
+ server by connecting with telnet (usually to port 119) and issuing
+ "IHAVE <message-id>". The peer may respond with something like "435
+ Duplicate" which means that the problem is not likely to be with your
+ server (it may be still a problem with the article itself). If the
+ peer responds with something like "335", your server probably did not
+ offer the article after all.
+
+ If you really are at a dead end and need to get more information about
+ what's going on with an outgoing feed, you can switch it from innfeed
+ to nntpsend (see INSTALL for instructions). You can then run it
+ manually with innxmit -dv, which will show the full conversation with
+ your remote peer.
+
+------------------------------
+
+Subject: 3.8. sendmail isn't installed
+
+Yes, INN really does require sendmail. It uses sendmail to send out the
+daily reports and to mail messages to moderators, and it assumes that you
+have a program installed as /usr/sbin/sendmail or /usr/lib/sendmail that
+it can use to do this. It does not speak SMTP, nor is it likely to ever
+speak SMTP; it's hard enough maintaining a package to speak NNTP.
+
+If you need a very simple local sendmail implementation that just sends
+mail to a smarthost, there are several available (nullmailer, for
+example).
+
+------------------------------
+
+Subject: 4. Error Messages
+
+Explanations of specific error messages, including solutions where
+applicable.
+
+INN logs nearly all messages to syslog, so in general these error messages
+will be found in syslog. If you aren't seeing anything from INN in syslog
+at all, make sure that you have it set up correctly (see 3.3).
+
+------------------------------
+
+Subject: 4.1. innd: SERVER cant store article
+
+You probably have a misconfigured storage.conf. In current versions of
+INN, "no matching entry in storage.conf" is added to the end of this
+message unless it really is a disk I/O problem, making the cause
+considerably clearer.
+
+storage.conf(5) has this to say:
+
+ If an article doesn't match any entry, either by being posted to a
+ newsgroup that doesn't match any of the <wildmat> patterns or by being
+ outside the size and expires ranges of all entries whose newsgroups
+ pattern it does match, the article is not stored and is rejected by
+ innd(8). When this happens, the error message
+
+ cant store article: no matching entry in storage.conf
+
+ is logged to syslog. If you want to silently drop articles matching
+ certain newsgroup patterns or size or expires ranges, assign them to the
+ "trash" storage method rather than having them not match any storage
+ method entry.
+
+One of the more frequent causes of this problem is misuse of the expires
+key in storage.conf entries. Read the man page for storage.conf very
+carefully if you're using the expires key, since it may not do what you
+think it does. In particular, if you have a storage class that specifies
+expires with a min-time greater than 0, it won't match any article without
+an Expires header (the vast majority of Usenet articles).
+
+------------------------------
+
+Subject: 4.2. innd: SERVER internal no control and/or junk group
+
+Your active file isn't complete. Either it's been mangled by something or
+it's missing some required entries. Even if you're running a small
+stand-alone server for internal use that only carries a handful of groups,
+there are some pseudogroups used internally by INN that you have to have.
+
+Since INN isn't running (it won't start when this error occurs), you can
+edit the active file by hand without worrying about stepping on INN's
+toes. Make sure the following lines are present in the active file (if
+the numbers are different, that's fine):
+
+ control 0000000000 0000000000 n
+ control.cancel 0000000000 0000000000 n
+ control.checkgroups 0000000000 0000000000 n
+ control.newgroup 0000000000 0000000000 n
+ control.rmgroup 0000000000 0000000000 n
+ junk 0000000000 0000000000 y
+
+and then start INN again. The control* groups are for control messages
+(messages with a named group will be filed into it, and all other control
+messages will go into the top-level catch-all group). The n flag is so
+that users won't post messages directly to the control* groups; control
+messages should be posted to the groups that they affect instead and INN
+will refile them automatically based on the Control header.
+
+------------------------------
+
+Subject: 4.3. Modification of read-only value attempted (Cleanfeed)
+
+INN 2.3 and later have an internal optimization to the interface to
+embedded filters that makes filtering about 15-20% faster, but which
+disallows a trick that many versions of Cleanfeed use to count the number
+of lines in the article. (This problem is fixed in current versions of
+Cleanfeed.)
+
+To correct this problem, find the line in Cleanfeed that looks like:
+
+ $lines = $hdr{'__BODY__'} =~ tr/\n/\n/;
+
+and change it to:
+
+ $lines = $hdr{'__LINES__'};
+
+The __LINES__ hash value is set internally by all recent versions of INN
+and is guaranteed to be correct.
+
+------------------------------
+
+Subject: 4.4. tradspool: could not open ... File exists
+
+This error generally happens after a crash or unclean shutdown of innd
+using the tradspool storage method, and is caused by overview information
+being out of sync with what articles are in the spool. When innd was
+restarted, it renumbered its active file (which determines the range of
+existing articles in each group and therefore what article number is
+assigned to new articles) based on the overview information. If there are
+newer articles already on disk that aren't mentioned in the overview
+(because the overview information for those articles hasn't been flushed
+to disk yet), new incoming articles will get assigned the same number as
+the existing article and then innd will fail to store the article and
+throttle with this error.
+
+In INN 2.4 and later when using the tradindexed overview method, you can
+solve this problem by rebuilding the overview for any affected group.
+Throttle the server (if it isn't already) and then run:
+
+ tdx-util -R <path-to-articles> -n <newsgroup>
+
+where <newsgroup> is the newsgroup that INN is complaining about and
+<path-to-particles> is the full path to the directory where the articles
+for that group are stored (it's generally in the error message).
+Immediately afterwards, run ctlinnd renumber for that newsgroup, and then
+unthrottle the server.
+
+The general solution to this problem, which works with any version of INN
+and any overview method, is to shut down the server, delete all of your
+overview database, and then rebuild it from your news spool with:
+
+ makehistory -O -x -F
+
+This takes a long time and is to some degree overkill.
+
+A third and better solution in some cases is to just remove all articles
+in the spool that have higher numbers than the numbers in the active file.
+Here's a Perl script that will do that. Just save this to a file, make it
+executable, and run it, giving it the path to the active file as the first
+argument and the path to the top of your tradspool news spool as the
+second argument:
+
+ #!/usr/bin/perl
+ die "Usage: <name> <active> <spool-path>\n" unless @ARGV == 2;
+ open (ACTIVE, $ARGV[0]) or die "Can't open $ARGV[0]: $!\n";
+ while (<ACTIVE>) {
+ my ($group, $hi, $lo, $flag) = split;
+ my $directory = $group;
+ next if ($hi == 0 and $lo <= 1);
+ $directory =~ tr%.%/%;
+ $directory = $ARGV[1] . '/' . $directory;
+ if (-d $directory) {
+ opendir (DIR, $directory) or die "Can't open $directory: $!\n";
+ while (defined ($_ = readdir DIR)) {
+ unlink "$directory/$_" if ($_ > $hi);
+ }
+ closedir DIR;
+ }
+ }
+
+If you're not already running INN 2.4, upgrade if you can. Not only can
+you recover directly from this problem if you're using tradindexed
+overview, but INN 2.4 does a better job of flushing data to disk and is
+less likely to have this problem in the first place.
+
+------------------------------
+
+Subject: 4.5. Binary posting to non-binary group
+
+This message does not actually come from INN. It's generated by
+Cleanfeed, and if you're seeing it, that means that you have Cleanfeed
+installed. At least at one point, the default Red Hat installation of INN
+included Cleanfeed without documenting this particularly well.
+
+In order to allow binaries in your local hierarchies, you should modify
+the Cleanfeed configuration file to set bin_allowed to a regular
+expression matching the groups that should allow binaries. Please don't
+allow binary postings to regular Usenet newsgroups that you don't know
+should have binaries, as they consume large amounts of bandwidth and
+possibly disk space for other sites.
+
+For more information on Cleanfeed configuration options, see the Cleanfeed
+documentation and the comments in the default configuration file.
+
+------------------------------
+
+Subject: 5. Problems on Specific Systems
+
+Problems specific to particular operating systems or platforms. Look here
+if INN doens't behave as expected on your particular system, or if you're
+having trouble compiling INN in the first place.
+
+------------------------------
+
+Subject: 5.1. INN won't compile on SCO OpenServer
+
+For information about getting INN to run on SCO UnixWare 7.1.* and
+OpenUNIX 8.0.0, see:
+
+ <http://www.zenez.com/tmp/ou8faqz/cache/269.html>
+
+On SCO OpenServer, the default cc requires -O be given when -Kalloca is
+given (which is added by default by configure since the parsers generated
+by bison need it). However, there appears to be a bug in the compiler
+that causes it to miscompile nnrpd/commands.c under -O, generating the
+error:
+
+ Assembler: commands.c
+ aline 1505 : Syntax error
+
+I had to get around this by cd'ing into nnrpd, running:
+
+ make COPT=-g commands.o
+
+and then cd'ing back to the top level and running make again. On
+OpenServer, to build with cc, you have to use:
+
+ env CC=cc CFLAGS=-O ./configure --with-sendmail=/usr/lib/sendmail
+
+Building under gcc is cleaner, but of course if you want to use
+--with-perl you want to build with the same compiler that you built Perl
+with.
+
+It's also worth noting that with a shared Perl library, Perl on this
+platform doesn't apparently generate the right link magic to include the
+path to the dynamic Perl libraries. You need to either set LD_RUN_PATH
+before building or LD_LIBRARY_PATH before running any binaries so that
+they can find the Perl libraries. (The former is preferred, since then
+the path is encoded into the binaries and you don't have to remember to
+set LD_LIBRARY_PATH later.)
+
+------------------------------
+
+Subject: 5.2. Using raw devices on Solaris destroys the partition table
+
+If you use slice 2, or some other disk slice that includes the entire
+disk, under Solaris as a raw partition for CNFS, you may run into this
+problem. The symptoms are that INN manages to initialize the cycbuffs
+just fine, but then gets invalid device errors when it tries to open them
+again, and the disks show up in format as needing to be repartitioned.
+
+The solution is to not use raw devices that include the first cylinder of
+the disk. Solaris doesn't protect the superblock from being overwritten
+by an application writing to raw devices and includes it in the first
+cylinder of the disk, so unless you use a slice that starts with cylinder
+1 instead of 0, INN will invalidate the partition table when it tries to
+initialize the cycbuff and all further accesses will fail until you
+repartition.
+
+Generally all that has to be done is to repartition the disk with slice 0
+starting from cylinder 1 and extending to the end of the disk and then
+point INN at slice 0 instead of slice 2. You lose some small amount of
+space, but generally not enough to care about.
+
+------------------------------
+
+Subject: 5.3. Will INN work on Windows?
+
+Amazingly enough, the answer is yes.
+
+Not out of the box, however; the standard INN distribution doesn't build
+on Windows. There is, however, a port to Cygwin (which is a Unix-like
+environment for Windows). For more information, see:
+
+ <http://homepage.mac.com/imeowbot/inn/>
+
+Don't forget to peruse INSTALL if you download and want to try this.
+
+------------------------------
+
+Subject: 5.4. Why aren't INN's files where the documentation says they are?
+
+INN's default installation locations are intended to be convenient for
+sysadmins adding INN to their system without disturbing other software.
+They don't match any of the standards used by various Linux distributions
+or other Unix packaging systems. Because of that, distributors who supply
+INN packages often rearrange the files and directories.
+
+Unfortunately, this is very confusing for system administrators, because
+the documentation is not updated to reflect the modified locations of
+files.
+
+You can always get the details of how your system is configured by looking
+in inn.conf at "pathnews" and similar parameters. But for convenience,
+here are comparisons of INN's default locations with some of the most
+common packages.
+
+(Data courtesy of John F. Morse.)
+
+ DEFAULT DEBIAN
+pathnews: /usr/local/news /usr/lib/news
+pathbin: /usr/local/news/bin /usr/lib/news/bin
+pathcontrol: /usr/local/news/bin/control /usr/lib/news/bin/control
+pathdb: /usr/local/news/db /var/lib/news
+pathetc: /usr/local/news/etc /etc/news
+pathfilter: /usr/local/news/bin/filter /etc/news/filter
+pathhttp: /usr/local/news/log /var/log/news
+pathlog: /usr/local/news/log /var/log/news
+pathrun: /usr/local/news/run /var/run/news
+pathtmp: /usr/local/news/tmp /var/spool/news/incoming/tmp
+pathspool: /usr/local/news/spool /var/spool/news
+patharchive: /usr/local/news/spool/archive /var/spool/news/archive
+patharticles: /usr/local/news/spool/articles /var/spool/news/articles
+pathincoming: /usr/local/news/spool/incoming /var/spool/news/incoming
+pathoutgoing: /usr/local/news/spool/outgoing /var/spool/news/outgoing
+pathoverview: /usr/local/news/spool/overview /var/spool/news/overview
+
+ DEFAULT FEDORA
+pathnews: /usr/local/news /usr/lib/news
+pathbin: /usr/local/news/bin /usr/lib/news/bin
+pathcontrol: /usr/local/news/bin/control /usr/lib/news/bin/control
+pathdb: /usr/local/news/db /var/lib/news
+pathetc: /usr/local/news/etc /etc/news
+pathfilter: /usr/local/news/bin/filter /usr/lib/news/bin/filter
+pathhttp: /usr/local/news/log /var/log/news
+pathlog: /usr/local/news/log /var/log/news
+pathrun: /usr/local/news/run /var/run/news
+pathtmp: /usr/local/news/tmp /var/lib/news/tmp
+pathspool: /usr/local/news/spool /var/spool/news
+patharchive: /usr/local/news/spool/archive /var/spool/news/archive
+patharticles: /usr/local/news/spool/articles /var/spool/news/articles
+pathincoming: /usr/local/news/spool/incoming /var/spool/news/incoming
+pathoutgoing: /usr/local/news/spool/outgoing /var/spool/news/outgoing
+pathoverview: /usr/local/news/spool/overview /var/spool/news/overview
+
+ DEFAULT MANDRAKE
+pathnews: /usr/local/news /usr
+pathbin: /usr/local/news/bin /usr/bin
+pathcontrol: /usr/local/news/bin/control /usr/lib/news/bin/control
+pathdb: /usr/local/news/db /var/lib/news
+pathetc: /usr/local/news/etc /etc/news
+pathfilter: /usr/local/news/bin/filter /usr/lib/news/bin/filter
+pathhttp: /usr/local/news/log /var/log/news
+pathlog: /usr/local/news/log /var/log/news
+pathrun: /usr/local/news/run /var/run/news
+pathtmp: /usr/local/news/tmp /usr/tmp
+pathspool: /usr/local/news/spool /var/spool/news
+patharchive: /usr/local/news/spool/archive /var/spool/news/archive
+patharticles: /usr/local/news/spool/articles /var/spool/news/articles
+pathincoming: /usr/local/news/spool/incoming /var/spool/news/incoming
+pathoutgoing: /usr/local/news/spool/outgoing /var/spool/news/outgoing
+pathoverview: /usr/local/news/spool/overview /var/spool/news/overview
+
+In addition, the FreeBSD port uses the standard INN paths except that it
+puts logs in /var/log/news and pathtmp in /usr/local/news/spool/tmp.
+
+Most packages install INN's man pages into a system man directory
+(/usr/share/man or /usr/local/man) rather than into a separate man
+directory under news's home directory.
+
+------------------------------
+
+Subject: 6. How Do I...
+
+This section documents various common or uncommon tasks or configurations
+that people want to do with INN. It is mostly taken from frequently asked
+questions in news.software.nntp.
+
+------------------------------
+
+Subject: 6.1. Set up a server with no external feeds, just local groups
+
+The basic steps are to set up a newsfeeds file empty except for internal
+feeds like controlchan or overchan (if you're using either), have only
+localhost in incoming.conf, and start INN with the default minimal active
+file. Then, create the groups you want to carry with ctlinnd newgroup.
+Set up reading permissions using readers.conf as appropriate for your
+organization.
+
+In other words, it's very much like setting up any other instance of INN,
+but you don't bother with innfeed, nntpsend, or any of their configuration
+files. INN may also complain that you have no feeds in newsfeeds; this is
+harmless and can be ignored.
+
+------------------------------
+
+Subject: 6.2. Process a single control message
+
+To process a single control message, you can use controlchan from the
+command line. Just type either:
+
+ echo /path/to/article-file | controlchan
+
+or:
+
+ echo @token@ | controlchan
+
+if you have the storage API token of the article. (This assumes
+controlchan is in a directory in your path.) This is useful mostly for
+testing; if you just want to create, remove, or change a group, it's
+easier to use ctlinnd (newgroup, rmgroup, or changegroup).
+
+------------------------------
+
+Subject: 6.4. Feed all articles on a server to another server
+
+To feed all articles on an existing server to another one, regardless of
+how they're stored on the server, first tell the new server to accept
+articles regardless of how old they are (otherwise, INN will reject
+articles older than artcutoff in inn.conf) and disable your filtering:
+
+ ctlinnd param c 0
+ ctlinnd perl n
+ ctlinnd python n
+
+You may also want to set xrefslave to true in inn.conf and then restart
+INN on the new server if you want to keep the same article numbers as you
+had on the old server.
+
+Next, make sure that the old server is listed in incoming.conf of the new
+server, and reload incoming.conf with ctlinnd to pick up that change.
+Also make sure that the new server carries exactly the same set of
+newsgroups as the old server.
+
+Then try these commands (a variation on commands posted by Katsuhiro
+Kondou to inn-workers) on the old server:
+
+ cd pathdb
+ perl -ne 'chomp; ($a,$b,$_) = split " "; print "$_\n" if $_' history \
+ | tr . / > pathoutgoing/list
+ innxmit server list
+
+where pathdb is the path to the directory containing the history file
+(usually ~news/db), pathoutgoing is the path to the outgoing spool
+directory (usually ~news/spool/outgoing), and server is the name of the
+new news server to which you're feeding the articles.
+
+When done, set xrefslave to false in inn.conf again if you changed it and
+then either restart INN on the new server (necessary if you changed
+xrefslave) or use another ctlinnd param command to set the cutoff value
+back to what's specified in inn.conf and use ctlinnd perl and ctlinnd
+python to reactivate your filters.
+
+Please note that when using xrefslave, this method requires that all of
+the articles in your spool have Xref headers. Current versions of INN
+will always add an Xref header, but very old versions (earlier 1.x
+versions) will only add an Xref header to crossposted articles. If you're
+trying to import such a spool, you'll need to modify all of those articles
+to add an Xref header.
+
+------------------------------
+
+Subject: 6.5. Rename a newsgroup
+
+INN has no native support for renaming a newsgroup, and doing so is
+difficult, so the best advice is to not do this. If there's a way that
+you can just create the new newsgroup, encourage people to start using it,
+and then remove the old newsgroup, I recommend that. It's much easier.
+
+However, if it really must be done, it's best if you're using the
+tradspool storage method. The newsgroup of an article is stored in the
+Newsgroups header and Xref header of the article as stored on disk (and
+possibly in Followup-To), as well as determining where the overview
+information is stored, and in the case of tradspool is also encoded in the
+article's storage token. To rename a newsgroup in tradspool, stop the
+server, move the directory containing all of the articles to its
+appropriate new location in the news spool, edit every article to change
+the old name to the new name in Newsgroups, Followup-To, and Xref, create
+the new newsgroup with ctlinnd newgroup, and then rebuild history and
+overview with makehistory.
+
+The following bit of Perl may help with the renaming (from Jeffrey
+Vinocur):
+
+ #!/usr/bin/perl -wi
+ my ($src, $dst) = (shift, shift);
+ die "Usage: $0 oldgroup newgroup [file1 [file2 ...]]\n"
+ unless(defined $dst);
+ while(<>) {
+ s/$src/$dst/g if 1 .. /^$/ and /^(Newsgroups|Followup-To|Xref):/i;
+ print;
+ } continue {
+ close ARGV if eof;
+ }
+
+Note that this may cause some problems if the newsgroup you're renaming is
+contained in the name of another newsgroup to which messages in that group
+are crossposted. If that's a problem, you may have to use a more
+sophisticated script.
+
+If any articles were crossposted to other newsgroups, you'll also have to
+find and recreate the links in those newsgroups to the new location of the
+articles (if the links were hard links and the process of changing the
+Xref, Followup-To, Newsgroups headers didn't break those links, you may be
+lucky and be able to skip this).
+
+If you're using another storage method, this is harder, although with
+timehash you may be able to just change the Newsgroups, Xref, Followup-To
+headers of the articles in that newsgroup and then rebuild history and
+overview as above.
+
+One other approach that can be used regardless of storage method is to
+refeed the articles to the server into a new newsgroup. This approach
+works best if you're also changing news servers at the same time;
+otherwise, the message IDs of the articles will already be in history, and
+you'll have to change the message IDs of all of the messages or remove
+them from the history database (such as by moving the articles away,
+changing /remember/ to 0 so that old history entries won't be retained,
+and then running expire to purge them out of history). To do this, get
+all of the messages into a directory (by pulling them down via NNTP or
+some other method), change the Newsgroups, Xref, and Followup-To headers
+to rename the newsgroup, and then create a file containing paths to all of
+the articles, one per line. You can then use that file as input to
+innxmit, pointing it at the server to which to feed the articles, and if
+the articles aren't listed in history on that server and it carries the
+new group, they will be accepted into the new newsgroup.
+
+Note that if you use this method and something goes wrong the first time,
+the message IDs will probably have all been added to history on the new
+server and the articles now will never be accepted until those entries are
+removed from history again (or all the message IDs changed).
+
+------------------------------
+
+Subject: 6.6. Change the domain used for message IDs
+
+By default, any message IDs generated by INN will use the domain of the
+local system for the right-hand-side of the message ID. In some cases,
+this isn't desirable for various reasons (the server may have an internal
+name that doesn't make sense on Usenet at large, or one may not want to
+expose the name of the server).
+
+In INN 2.3.3 and later, you can set virtualhost: to true in an access
+stanza of readers.conf and then set domain: in the same stanza, and all
+posts coming from connections to which that access stanza applies will use
+that domain to generate message IDs. So if you need to change the domain
+used to generate message IDs for every local post from your server, just
+add virtualhost: and domain: keys to every access stanza in readers.conf.
+
+This is really overkill for this option, and eventually the domain:
+parameter in inn.conf will probably be changed to allow this to be
+modified for the whole server. (Right now, domain: in inn.conf means
+something completely different.)
+
+------------------------------
+
+Subject: 6.7. Use INN without a direct news feed
+
+INN is designed to be used as a regular news server, receiving direct news
+feeds from other news servers and sending news directly to other news
+servers using the peer-to-peer portions of the NNTP protocol. However,
+with some additional software, it is also possible to use INN as, in
+essence, a local cache for a news server that you can use to read and post
+but which doesn't treat your server like a peer.
+
+This configuration is generally called a "suck" feed, because rather than
+having news fed directly to your server, you pull it down or "suck" it
+from another news server, and because possibly the first and one of the
+most widely used packages for doing this is named suck.
+
+The software to pull down articles from another server and to feed
+articles to another server using post rather than peer-to-peer commands
+does not come with INN (INN has a few utilities to do this on a small
+scale, but not really anything designed to handle a lot of groups or a lot
+of articles). You will need an external package to do this. The two most
+popular are suck and newsx; however, both sites appear to be unavailable
+as of thos writing. You may be able to find a package in your local
+distribution or package repository.
+
+Note that current versions of INN refer to articles internally using a
+storage API token, not a path name, which is not always what suck or newsx
+expects. Read the documentation carefully; you'll need to use a script or
+configuration that retrieves articles using the sm program that comes with
+INN rather than trying to open files directly.
+
+It's also worth noting that INN is a fairly complex package, and while
+many people are running it successfully using this sort of configuration
+and like having a full-fledged news server available to them, other people
+have found INN rather complicated and difficult to configure for a small,
+simple personal news cache. If your needs and goals are simple and the
+number of groups you're interested in is small, you may be better off with
+a smaller, lighter package such as LeafNode or NNTPcache.
+
+------------------------------
+
+Subject: 6.8. Generate MRTG graphs for INN
+
+INN's CNFS storage system has direct support for producing information
+suitable for MRTG graphs on the usage of the CNFS cycbuffs. Running
+cnfsstat -m <cycbuf> will generate output suitable for MRTG, and running
+cnfsstat -p will generate sample MRTG configuration fragments for each
+cycbuff.
+
+To generate MRTG graphs of the usage of the buffindexed overview system,
+try the following configuration fragment:
+
+ Target[overview-BUFF]: `/usr/local/etc/mrtg/overview.sh`
+ MaxBytes[overview-BUFF]: 100
+ Title[overview-BUFF]: BUFF1 Usage
+ Options[overview-BUFF]: growright gauge
+ YLegend[overview-BUFF]: Overview Buffers
+ ShortLegend[overview-BUFF]: %
+ PageTop[overview-BUFF]: <H1>Usage of Overview Buffers</H1>
+ <BR><TT>overview</TT>
+
+where the overview.sh script is:
+
+ #!/bin/sh
+ echo "100"
+ /usr/local/news/bin/inndf -o | awk '{print $1}'
+ echo "0"
+ echo "overview"
+
+This sample configuration is from Basil Kruglov. Note that you can
+instead use -n (for total count of articles); in that case, you'll want to
+remove the MaxBytes setting above or change it to be some sensible limit
+on the total number of articles you receive. You'll also want to change a
+few of the other labels in the MRTG configuration.
+
+I'm not aware of any packaged solutions for generating MRTG data from
+other things, such as incoming or outcoming news flows. If anyone has any
+pointers, let me know.
+
+------------------------------
+
+Subject: 6.9. Hide the junk and control groups from users
+
+The junk, control, and control.cancel groups must exist in the active file
+for the proper operation of INN, so you can't remove the groups entirely.
+You can, however, hide them completely from users.
+
+To do this, edit readers.conf, and for each user access group where you
+want to hide the junk and control groups, add "!junk,!control,!control.*"
+to the newsgroups pattern. In other words, if you have a line like:
+
+ newsgroups: *
+
+just change that to:
+
+ newsgroups: *,!junk,!control,!control.*
+
+If you use read and post patterns instead, do the same for each of them
+individually. The groups will then no longer show up on the server for
+users to which that access group applies; it will be as if they do not
+exist.
+
+------------------------------
+
+Subject: 6.10. Modify the body of posts made through my server
+
+You can't without either making code changes to INN or putting your own
+software in the path of incoming posts. This is intentional.
+
+Some sites like to try to append a standard signature to all posts through
+their service, generally as advertising. This creates the appearance of
+users saying things that they didn't, runs the risk of corrupting messages
+by appending text without regard to what's in the message, and can
+possibly modify messages that arrive via a suck/rpost connection. It also
+adds advertising in an obnoxious location, rather than in the Organization
+header which is more widely used for that purpose. Accordingly, INN does
+not support this, or any other modification of the body of a message from
+inside the news server.
+
+If you only want to do this for a private hierarchy, the easiest way to do
+this (as well as any other modifications and internal filtering that you
+want to perform) is to mark all of the groups as moderated and route all
+submissions through a script that makes whatever modifications you want
+and then posts the messages with an Approved header.
+
+If you want to do this in order to advertise your service, please
+reconsider. You can add your advertisements to the headers, like many
+other news service providers.
+
+------------------------------
+
+Subject: 6.11. Hide the X-Trace header
+
+There is no built-in support for suppressing generation of the X-Trace
+header. You can, however, remove it from inside a Perl posting filter.
+Try using a posting filter like this:
+
+ sub filter_post {
+ $modify_headers = 1;
+ delete $hdr{'X-Trace'};
+ return '';
+ }
+
+Note that you have to set $modify_headers to make changes to the article
+header effective in the actual posted article.
+
+------------------------------
+
+Subject: 6.12. Run innd and nnrpd on separate ports
+
+Originally, innd was designed to handle all incoming connections and hand
+them off to nnrpd as appropriate. It is, however, becoming increasingly
+common to run innd and nnrpd on separate ports for a variety of reasons,
+such as wanting to handle connections to nnrpd with a smart network
+connection handling daemon like xinetd that can do things like rate
+limiting of connections. INN does support this configuration, but be
+warned that since you need to run nnrpd on port 119 for most reader
+clients to be able to find it, you'll need to tell all of your news peers
+to use a different port to feed you news.
+
+The recommended alternate port for innd transit-only connections is port
+433, which has been reserved for that purpose. If you want to use some
+low-numbered port (less than 1024) other than 119 or 433 for innd, you
+will need to build INN with the --with-innd-port option specifying that
+port.
+
+Now, set port in inn.conf to the port you want to run innd on and add
+noreader: true (so that innd will never attempt to hand connections off to
+nnrpd). Then, restart INN. It will now be listening on the new port.
+You should now set up nnrpd to run via of xinetd, inetd, tcpserver, or
+some other similar network connection handling daemon on port 119. Make
+sure that nnrpd is run as the news user, not as root. You don't have to
+pass any arguments to nnrpd (unless you want to).
+
+------------------------------
+
+Subject: 6.13. Back up and restore an INN installation
+
+(This entry is based on a post by Jeffrey M. Vinocur.)
+
+For a full backup, you need, at a minimum, to save all of the articles in
+$patharticles, the configuration files in $pathetc, and the active and
+newsgroup files in $pathdb. If you have any custom filters you've
+installed, or a cleanfeed.local file, you'll want to keep that, as well as
+any custom authentication programs or files you're using (like a password
+file for news accounts). You may also want to save HTML versions of the
+news.daily reports, if you've been generating them, and you may want to
+look at the first few lines of config.status in your original source tree
+so that you can be sure to use the same options to configure.
+
+Note that most people only back up those portions of the news spool that
+they retain for a long time (like local hierarchies) and don't bother with
+all the regular Usenet articles.
+
+It's considerably easier to back up and restore articles from tradspool
+than any other storage mechanism, and it's quite hard to back up and
+restore timecaf or CNFS. Remember that you can use different storage
+methods for different articles. I highly recommend saving the hierarchies
+you want to back up in tradspool and use the higher-performance storage
+mechanisms for news you don't care as much about.
+
+To restore a single newsgroup using tradspool and the tradindexed overview
+method, you can just restore the articles into the news spool and then
+rebuild overview for just that group with tdx-util -R.
+
+Otherwise, for more general restorations, compile INN on the new system
+with the same ./configure command if you've lost the installation, run
+make install, then put all the pieces back where they belong. Now, you
+have to run:
+
+ makehistory -O
+
+to rebuild the history and overview databases. When that finishes, cd to
+the $pathdb directory and run:
+
+ makedbz -s `wc -l history` -o
+
+You should now be able to start the server and read and post news to it.
More information about the inn-committers
mailing list