From: <¥Ñ Microsoft Internet Explorer 5 Àx¦s> Subject: INN 2.x FAQ Date: Wed, 2 Oct 2002 17:57:14 +0800 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_001A_01C26A3D.240A4F80"; type="text/html" X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 This is a multi-part message in MIME format. ------=_NextPart_000_001A_01C26A3D.240A4F80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Location: http://www.eyrie.org/~eagle/faqs/inn.html INN 2.x = FAQ

INN 2.x FAQ

Russ Allbery = <rra@stanford.edu>
Last=20 modified September 11, 2002 (revision 1.29)

This FAQ is intended to answer frequently asked questions concerning = the=20 current versions of INN (INN 2.x and later) seen on news.software.nntp. = It=20 should be referred to in preference to the old INN FAQ, which only = documents=20 versions up to 1.7. It is very much a work in progress, and is currently = still=20 woefully incomplete.

If you're reading this on Usenet, this FAQ is formatted as a minimal = digest,=20 so if your news or mail reader has digest handling capabilities you can = use them=20 to navigate between sections. In rn variants, you can use Ctrl-G to skip = to the=20 next section; in Gnus, press Ctrl-D to break each section into a = separate=20 article.

Please send any comments, suggestions, or updates to = rra@stanford.edu. Bear=20 in mind when sending me e-mail that I receive upwards of 800 mail = messages a day=20 and have unanswered personal e-mail dating back six months or more, so = please=20 don't expect an immediate response. You may receive quicker responses by = posting=20 to news.software.nntp (even, due to the quirky way in which I read mail = and=20 news, from me).

This FAQ is posted monthly to news.software.nntp, and is available on = the web=20 at <http://www.eyrie.org/~= eagle/faqs/inn.html>.=20

General=20 Questions
1.1. What is = INN?
1.2.=20 What is the = current=20 version?
1.3. Where can I = get=20 INN?
1.4. Where can I = find=20 documentation?
1.5. What = newsgroups are=20 there for INN?
1.6. What mailing = lists are=20 there for INN?
1.7. How can I = support INN=20 development?
1.8. How can I = contribute to=20 INN?
Terms
2.1. = What is = tradspool=20 (traditional spool)?
2.2. What is=20 CNFS?
2.3. What are = timehash and=20 timecaf?
2.4. What is=20 overview?
2.5. What are = deferrals (NNTP=20 code 431)?
Specific=20 Problems
3.1. INN won't = start after a=20 new installation
3.2. Reader = performance is=20 extremely slow using the storage API
3.3. The news = server isn't=20 keeping up with incoming news
3.4. news.notice is = empty and=20 the nightly report is missing things
3.5. INN is running = out of=20 file descriptors
Error=20 Messages
4.1. innd: SERVER = cant store=20 article
4.2. innd: SERVER = internal no=20 control and/or junk group
4.3. Modification = of=20 read-only value attempted (Cleanfeed)
4.4. tradspool: = could not=20 open ... File exists
Problems = on Specific=20 Systems
5.1. INN won't = compile on SCO=20 OpenServer
5.2. Using raw = devices on=20 Solaris destroys the partition table
5.3. Will INN run = on=20 Windows?
How Do=20 I...
6.1. Set=20 up a server with no external feeds, just local groups
6.2. Process a = single control=20 message
6.3. Split ovdb = overview=20 across multiple disks
6.4. Feed all = articles on a=20 server to another server
6.5. Rename a=20 newsgroup
6.6. Change the = domain used=20 for message IDs
6.7. Use INN = without a direct=20 news feed

1. General Questions

Contained in this section are general questions about INN, where to = find it,=20 and things of that sort. It is aimed at the person who is not yet = running INN,=20 or who has general questions about how it works.

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=20 flexible and configurable Usenet / netnews news server. For a complete = description of the protocols behind Usenet and netnews, see RFC 1036 = and RFC=20 977 (or their replacements). In brief, netnews is a set of protocols = for=20 exchanging messages between a decentralized network of news servers. = News=20 articles are organized into newsgroups, which are themselves organized = into=20 hierarchies. Each individual news server stores locally all articles = it has=20 received for a given newsgroup, making access to stored articles = extremely=20 fast. Netnews does not require any central server; instead, each news = server=20 passes along articles it receives to all of the news servers it peers = with,=20 those servers pass the articles along to their peers, and so on, = resulting in=20 "flood fill" propagation of news articles.

INN is free software, supported by the Internet Software Consortium = and=20 volunteers around the world.

For a more complete answer, see that file. A full description of what = Usenet=20 and netnews are is beyond the scope of this document; for a beginner's=20 introduction, see the news.newusers.questions home page at <http://www.g= eocities.com/ResearchTriangle/Lab/6882/>.=20

1.2. What is the current version?

The most recently released version of INN is 2.3.3.

INN development proceeds in two branches, as with many other free = software=20 projects. The STABLE branch is maintenance of the most recently released = stable=20 version, and only bug fixes are added to it. The CURRENT branch is the=20 development version of the next release of INN.

As mentioned in the next section, when installing a new INN server, = you may=20 wish to download the latest snapshot of the STABLE branch rather than = the=20 current full release.

Note that the previous STABLE series for INN 2.2 terminated in the = release of=20 INN 2.2.3 and current STABLE snapshots are based on INN 2.3.3. You = therefore=20 cannot update from a STABLE snapshot before August 20th, 2000, to one = dated=20 after that without following the upgrade instructions in NEWS.

1.3. Where can I get INN?

The download site for INN is <ftp://ftp.isc.org/isc/inn/>. = In that=20 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=20 snapshots of the INN CVS repository for the last seven days. The = snapshots with=20 STABLE in the name are the latest versions of the STABLE branch and may = have=20 some additional bug fixes over the current released version. The = snapshots with=20 CURRENT in the name are of the current development version.

Please note: There is no guarantee that a snapshot will even compile, = let=20 alone function well as a news server. In particular, the CURRENT branch = is under=20 active development, and all sorts of things may be broken at any given = point in=20 time. Use snapshots with caution, and don't use snapshots from the = CURRENT=20 branch on any production system unless you're prepared to debug the = inevitable=20 problems in code that's actively changing and not yet thoroughly tested. = (The=20 STABLE snapshots should be fairly reliable, however.)

1.4. Where can I find = documentation?

INN comes with extensive documentation. See the files INSTALL and = README at=20 the top level of the source tree, for starters. In addition, nearly = every=20 program and configuration file has its own Unix man page. The best place = to=20 start is by reading the entire INSTALL file and then from there = discovering=20 which configuration files and programs do what you want to do and = reading their=20 individual man pages.

For additional documentation beyond what is distributed with INN, = start at=20 <http://www.isc.org/inn.html> = and follow the links.

The documentation that comes with INN is fairly technical in nature = and=20 lacking in some more general details on configuring news servers. Some = of the=20 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 = Deja=20 archives thereof) and the archive of the inn-workers mailing list. A = link to the=20 latter is off the INN page referenced above.

Finally, the following additional links may be useful:

<htt= p://web.inter.nl.net/users/Elena.Samsonova/unix/INN/v2.3/>=20: Excellent introductory and overview documentation for INN 2.3 and = later.=20
<http://www.avalon.net/~hakeh= oe/inn/>=20: Information about the ovdb overview method and about running INN on = HP-UX.=20
<http://www.apl= awrence.com/Unixart/newsserver.html>=20: A tutorial on setting up INN aimed at beginners using SCO Unix. = While it's=20 mostly focused on SCO, it may be useful for any beginner to INN and = news=20 servers.
<http://www.koz= ubik.com/published/inn_tutorial.txt>=20: A tutorial on setting up INN on FreeBSD. Contains a lot of = information=20 focused on FreeBSD and its preferred file layout, so may be easier to = follow=20 than the generic instructions on that platform.

1.5. What newsgroups are there for = INN?

news.software.nntp discusses all NNTP-based news servers, including = INN. It's=20 the best newsgroup for technical questions and discussion. The newsgroup = news.software.b is also chartered for such discussion, but it's = essentially dead=20 now. General news administration questions are also on-topic in=20 news.admin.technical (moderated) and news.admin.misc (unmoderated).

news.admin.hierarchies covers questions of general hierarchy = configuration=20 and is where announcements of new news hierarchies are generally posted. = news.admin.net-abuse.* covers the topic of network abuse and prevention=20 (including spam), but is not for the faint of heart; it is extremely = noisy to=20 the point of being essentially unreadable without a lot of time and = patience=20 (and a good killfile).

1.6. What mailing lists are there for = INN?

There are several INN-related mailing lists:

inn-announce@isc.org=20: Where announcements about INN are set (no posting allowed).
inn-workers@isc.org=20: Discussion of INN development (postings by members only).
inn-patches@isc.org=20: Where to send patches for consideration for inclusion into INN = (open=20 posting).
inn-committers@isc.org=20: CVS commit messages for INN are sent to this list (no posting = allowed).=20
inn-bugs@isc.org=20: Where to send bug reports (open posting). If you're an INN expert = and have=20 the time to help out other users, we encourage you to join this = mailing list=20 to answer questions. (You may also want to read the newsgroup=20 news.software.nntp, which gets a lot of INN-related questions.) =

To join these lists, send a subscription request to the `-request' = address.=20 The addresses for the above lists are:

    =
inn-workers-request@isc.org
    inn-patches-request@isc.org
    inn-committers-request@isc.org
    inn-bugs-request@isc.org
    inn-announce-request@isc.org

inn-workers tends to be moderate volume (3-5 messages a day, but = varying a=20 lot depending on what's being discussed). inn-committers is higher = volume but=20 entirely automatically generated commit notifications. inn-announce is a = low-volume moderated list containing only major announcements. The = others see=20 sporadic, mostly low, traffic.

1.7. How can I support INN = development?

There are four major ways. First, from the README:

Note that INN is supported by the Internet Software Consortium, and = although it is free for use and redistribution and incorporation into = vendor=20 products and export and anything else you can think of, it costs money = to=20 produce. That money comes from ISP's, hardware and software vendors, = companies=20 who make extensive use of the software, and generally kind hearted = folk such=20 as yourself.

The Internet Software Consortium has also commissioned a DHCP = server=20 implementation, handles the official support/release of BIND, and = supports the=20 Kerberos Version 5 effort at MIT. You can learn more about the ISC's = goals and=20 accomplishments from the web page at <http://www.isc.org/isc/>.=20

The ISC provides ftp and web space, release coordination, CVS server = access=20 for developers, mailing lists and archives, and (as resources permit) = developers=20 to work on INN. Donations to help support all of that are greatly = appreciated.=20

Second, like with any other free software project, a great way to = support INN=20 development is to join in yourself. If you know how to program and have = an=20 interest in working on a widely deployed and fairly intricate news = server, we'd=20 love to have your help. See the next question for more details.

Third, even if you don't have the time or expertise to write much = code, any=20 contributions of documentation are greatly appreciated. = There's=20 always documentation work to be done, from maintenance of INN's = technical=20 documentation to tutorials and overviews for the new user or the user = who wants=20 to do something specific. Listen on news.software.nntp for what people = are=20 looking for, or ask on inn-workers. Similarly, beta testers are always = welcome;=20 if you have a test news server and some knowledge of how to diagnose = server=20 problems and want to try out the current development code and report any = bugs=20 you run into, that helps the developers immensely.

Fourth, 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=20 out intermittantly when you have a few moments to read news. If you can = identify=20 general solutions to frequent problems and pass them along to the INN=20 maintainers in the form of documentation or suggestions, even better. =

1.8. How can I contribute to INN?

First, join inn-workers, since that's where all the development = discussion=20 takes place. The traffic isn't that high.

Next, download a snapshot of the INN CURRENT branch as described = above so=20 that you have a relatively current source base to work from. You may = also want=20 to try configuring CVSup or some other update mechanism so that you can = get the=20 latest version directly out of CVS, or you can just use the nightly = snapshots if=20 you wish. Read the HACKING file at the top of the INN source tree for = some=20 general information and tips for working on INN.

Then pick something that looks interesting to you, mention what = you're doing=20 on inn-workers if it's likely to affect other parts of the development, = and have=20 at it! The TODO file in the CURRENT tree has a pretty comprehensive list = of=20 things that could be done. Best to start with something small (getting = INN to=20 work correctly on a platform where it doesn't currently and which you = have=20 available is often a great start, or working on one of the supporting = programs=20 or scripts that's a bit easier to wrap one's mind around than the core = INN=20 daemons). Patches to INN should be sent to inn-patches@isc.org, or put = on an ftp=20 or web site somewhere and the URL sent to inn-workers if they're = extremely=20 large.

2. Terms

Here are definitions of some commonly used terms related to INN. = (More=20 definitions are welcome; this section is extremely incomplete at the = moment and=20 the FAQ maintainer tends not to recognize terms that need a definition = for=20 people unfamiliar with INN.)

2.1. What is tradspool (traditional = spool)?

Traditional spool is called that because it's the way that all news = servers=20 used to store articles. A traditional news spool is a tree of = directories=20 matching the hierarchical structure of newsgroups. For example, the = newsgroup=20 news.software.nntp would be stored in a directory news/software/nntp = under the=20 root of the news spool, and next to the "nntp" directory in = news/software would=20 be a "readers" directory for the group news.software.readers.

INN's INSTALL file expands on this:

This is the storage method used by all versions of INN previous to = 2.0.=20 Articles are stored as individual text files whose names are the same = as the=20 article number. The articles are divided up into directories based on = the=20 newsgroup name. For example, article 12345 in news.software.nntp would = be=20 stored as news/software/nntp/12345 relative to the root of the article = spool.=20

Advantages: Widely used and well-understood storage mechanism, can = read=20 article spools written by older versions of INN, compatible with all=20 third-party INN add-ons, provides easy and direct access to the = articles=20 stored on your server and makes writing programs that fiddle with the = news=20 spool very easy, and gives you fine control over article retention = times.

Disadvantages: Takes a very fast file system and I/O system to keep = up with=20 current Usenet traffic volumes due to file system overhead. Groups = with heavy=20 traffic tend to create a bottleneck because of inefficiencies in = storing large=20 numbers of article files in a single directory. Requires a nightly = expire=20 program to delete old articles out of the news spool, a process that = can slow=20 down the server for several hours or more.

Under INN 2.2, the behavior of INN changes in various extremely = significant=20 respects based on whether it is using the storage API or using = traditional=20 spool. In that version, traditional spool is implemented with completely = different code than the storage API, and overview is handled completely=20 differently using the storage API. It's therefore a very common question = asked=20 of people reporting problems whether they're using traditional spool or = not.=20

As of INN 2.3, traditional spool is completely integrated into the = storage=20 API as the tradspool storage method and use the same overview mechanisms = as the=20 rest of INN.

Storing articles in the traditional spool format is extremely slow = relative=20 to other storage mechanisms; you would need an extremely fast I/O = subsystem to=20 keep up with a full Usenet feed using pure traditional spool.

2.2. What is CNFS?

CNFS is the Cyclic News File System, written by Scott Fritchie. It is = a=20 high-performance method of storing news articles, designed to avoid the = high=20 overhead involved in interacting with the file system when storing = articles in=20 individual files. From INN's INSTALL file:

CNFS stores articles sequentially in pre-configured buffer files. = When the=20 end of the buffer is reached, new articles are stored from the = beginning of=20 the buffer, overwriting older articles.

Advantages: Blazingly fast because no file creations or deletions = are=20 necessary to store an article. Unlike all other storage methods, does = not=20 require manual article expiration; old articles are deleted to make = room for=20 new ones when the buffers get too full. Also, with CNFS your server = will never=20 throttle itself due to a full spool disk, and groups are restricted to = just=20 the buffer files you give them so that they can never use more than = the amount=20 of disk space you allocate to them.

Disadvantages: Article retention times are more difficult to = control=20 because old articles are overwritten automatically. Attacks on Usenet, = such as=20 flooding or massive amounts of spam, can cause wanted articles to = expire much=20 faster than you intended with no warning.

It is one of the storage methods that can be selected when using the = storage=20 API (and is generally the fastest).

2.3. What are timehash and = timecaf?

These are two less-used storage mechanisms available under the INN = storage=20 API (similar in that respect to CNFS). Both can usefully be thought of = as=20 compromises between the write speed of CNFS and the fine-grained control = over=20 article expiration. INSTALL says for timehash:

Articles are stored as individual files as in tradspool, but are = divided=20 into directories based on the arrival time to ensure that no single = directory=20 contains so many files as to cause a bottleneck.

and for timecaf:

Similar to timehash, articles are stored by arrival time, but = instead of=20 writing a separate file for each article, multiple articles are put in = the=20 same file.

timecaf is new in INN 2.3.

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=20 common extension to the NNTP protocol that allows readers to review = summary=20 information about articles before taking the time (and bandwidth) to = download=20 the entire article.

The canonical items of information included in an overview record are = the=20 Subject, From, Date, References, and Message-ID headers of the article, = the byte=20 count of the article, and the line count of the article. Nearly every = server now=20 also returns the Xref header (a list of the newsgroups carried by the = server to=20 which the article was posted and the article number in each of those = newsgroups)=20 as an additional field.

Note that with the References and Message-ID headers, the overview = record=20 contains enough information to do article threading. It also contains = all of the=20 fields normally keyed on for client-side filtering (killfiles and the = like).=20

Generating overview information for a newsgroup on the fly is = prohibitively=20 expensive, particularly for large groups, since the server daemon would = have to=20 find all of those articles and scan them to build the information. It's = also=20 inefficient, since the overview information for a particular group will=20 generally be requested many times by different clients. INN therefore = normally=20 pregenerates overview information for all articles it stores; in = versions of INN=20 up to 2.2.1, this is done via a program called overchan and a special = "outgoing=20 feed" to that program specified in the newsfeeds configuration file. =

(Technically, under the storage API, the actual overview information = is=20 written out internally by INN and overchan only stores index information = into=20 that "unified overview" or uniover database. Under INN 2.3, a completely = different mechanism is used and overchan can be used or not as you = choose.)

2.5. What are deferrals (NNTP code = 431)?

Consider the following situation. You have two incoming peers, both = of which=20 are getting ready to offer you an article in streaming mode. The first = sends you=20 a CHECK <message-id> message, to which you respond affirmatively = (i.e.,=20 you don't already have the article). Then, before that peer sends you = the=20 article with TAKETHIS, you receive a CHECK <message-id> from the = second=20 peer for the same message. What response does INN send to the second = peer?

If deferrals are enabled (noresendid =3D=3D false in incoming.conf = for that peer,=20 the default), INN will send a 431 deferral telling that peer that you = may or may=20 not want the article; try again later. Chances are that when it retries, = you=20 will have received the article from the first peer and you'll just = refuse it.=20 But if the first peer dies before it ever sends you the article, this = way you=20 can still get it from the second peer.

If deferrals are disabled, INN will refuse the article from the = second peer,=20 which means there's a possibility you'll lose news if the first peer = dies before=20 sending you the article.

As a side note, some older versions of Diablo, upon receiving a = deferral,=20 turn around and immediately send the article via TAKETHIS, which is = basically=20 exactly what you don't want. (Chances are extremely high in practice = that the=20 first peer will come through with the article.)

3. Specific Problems

This section contains specific problems that are frequently reported = when=20 using INN, and includes fixes or suggestions for fixes. Candidates for = inclusion=20 in this section are any problems reported frequently on = news.software.nntp or=20 inn-bugs@isc.org. Contributions, including fixes, are very welcome.

3.1. INN won't start after a new = installation

The most common cause of this problem is that inndstart isn't setuid = root.=20 inndstart must be installed owned by root and group news, mode 4550. The = ls -l=20 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=20 run make install as root. If inndstart isn't setuid root, it will log = errors to=20 syslog when it tries to start and cannot. If you aren't seeing those = error=20 messages in syslog either, you probably haven't set up syslog properly = (see=20 3.4).

The other most frequent cause of this problem is not correctly = following the=20 instructions in INSTALL on how to set up the initial history database. = After=20 running makedbz, the initial history database files will have names = starting=20 with history.n. These files must be renamed to remove the ".n" before = innd will=20 start.

3.2. Reader performance is extremely slow = using the=20 storage API

Try upgrading to INN 2.3. Under INN 2.3, overview operations use a = standard=20 API that allows you to select the overview storage method that best = suits your=20 situation, and there are three new overview mechanisms provided. One,=20 buffindexed, supports fast writing but with considerably faster reader=20 performance than the old unified overview mechanism in INN 2.2.

The unified overview (uniover) database used in INN 2.2 when the = storage API=20 is selected has proven in practice to be fairly slow for typical = newsreader=20 usage. Getting the full overview for a particular newsgroup can take = quite a bit=20 of time, particularly if the newsgroup is busy, because overview entries = are not=20 stored on the server by group but rather by article arrival time.

3.3. The news server isn't keeping up with = incoming=20 news

Start by looking for the profile information in your nightly report. = That=20 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=20 format for news articles. This storage method is now too slow to be able = to=20 handle a full Usenet news feed (although with a more limited selection = of groups=20 it can still do just fine). If your server is spending a lot of time = writing=20 articles and you're using traditional spool, this is probably the = problem.

One possible solution would be to switch to the storage API and CNFS = or=20 timehash as a storage mechanism. This will require rebuilding the = history and=20 overview data for all the articles in your news spool, however, and bear = in mind=20 that you may just be exchanging one performance problem for another = since=20 traditional spool is fairly fast for news reading (see 3.2).

3.4. news.notice is empty and the nightly = report is=20 missing things

You have syslog set up incorrectly.

INN logs nearly everything except article trace information via = syslog. It=20 expects syslog to write its log messages into particular files under = ~news/log,=20 unless you gave it a different path at configure time. You'll need to = set up=20 logging of INN-related log messages in your system /etc/syslog.conf. = From=20 INSTALL:

If your system understands the `news' syslog facility, INN will use = it;=20 otherwise, it will log to `local1'. Nearly every modern system has a = `news'=20 syslog facility so you can safely assume that yours does, but if in = doubt take=20 a look at the output from running `configure'. You should see a line = that=20 looks like:
    checking log level for news... LOG_NEWS
If that says LOG_LOCAL1 instead, change the below instructions to = use=20 `local1' instead of `news'.

Edit /etc/syslog.conf on your system and add lines that look like = the=20 following:
    news.crit           =
/usr/local/news/log/news.crit
    news.err            /usr/local/news/log/news.err
    news.notice         /usr/local/news/log/news.notice
(Change the path names as necessary if you installed INN in a = different=20 location than /usr/local/news.) These lines must be=20 tab-delimited, so don't copy and paste from these instructions. Type = it in by=20 hand and make sure you use a tab, or you'll get mysterious failures. = You'll=20 also want to make sure that news log messages don't fill your other = log files=20 (INN generates a lot of log traffic); for every entry in = /etc/syslog.conf that=20 starts with `*', add `;news.none' to the end of the first column. For = example,=20 if you have a line like:
    *.err               =
/dev/console
change it to:
    *.err;news.none     /dev/console
(You can choose not to do this for the higher priority log = messages, if you=20 want to make sure they go to your normal high-priority log files as = well as=20 INN's. Don't bother with anything lower priority than `crit', though.=20 `news.err' isn't interesting enough to want to see all the time.) Now, = make=20 sure that the news log files exist; syslog generally won't create = files=20 automatically. Enter the following commands:
    touch =
/usr/local/news/log/news.crit
    touch /usr/local/news/log/news.err
    touch /usr/local/news/log/news.notice
    chown news /usr/local/news/log/news.*
    chgrp news /usr/local/news/log/news.*
(again adjusting the paths if necessary for your installation). = Finally,=20 send a HUP signal to syslogd to make it re-read its configuration = file.=20

You don't have to worry about rotating these log files; news.daily = (which=20 should be run nightly) will take care of that and innreport generates a = daily=20 summary report from them.

3.5. INN is running out of file = descriptors

Also from INSTALL:

INN likes to use a lot of file descriptors, particularly if you = have a lot=20 of peers. Depending on what your system defaults are, you may need to = make=20 sure the default limit is increased for INN (particularly innd and = innfeed).=20 This is vital on Solaris, which defaults (at least as of 2.6) to an = absurdly=20 low limit of 64 file descriptors per process.

One way to increase the number of file descriptors is to set = rlimitnofile=20 in inn.conf to a higher value. This will cause startinnfeed and = inndstart, the=20 setuid root wrapper scripts that start innfeed and innd respectively, = to=20 increase the file descriptor limits before they run the regular INN = programs.=20 Note, however, that INN won't be able to increase the limits above the = hard=20 limits set by your operating system; on some systems, that hard limit = is 256=20 file descriptors (Linux, for example). On others, like Solaris, it's = 1024.=20 Increasing the limit beyond that value may require serious system=20 configuration work. (On some operating systems, it requires patching = and=20 recompiling the kernel. On Solaris it can be changed in /etc/system, = but for=20 2.6 or earlier the limit cannot be increased beyond 1024 without = breaking=20 select() and thereby breaking all of INN. For current versions of = Linux, you=20 may be able to change the maximum by writing to = /proc/sys/fs/file-max.)

256 file descriptors will probably be enough for all but the = largest site.=20 There is no harm in setting the limits higher than you actually need = (provided=20 they're set to something lower than or equal to your system hard = limit). 256=20 is therefore a reasonable value to try.

If you're installing INN on a Solaris system, particularly if = you're=20 installing it on a dedicated news server machine, it may be easier to = just=20 increase the default file descriptor limit across the board for all = processes.=20 You can do that by putting the line:
    set rlim_fd_cur =3D =
256
in /etc/system and rebooting. You can increase it all the way to = 1024 (and=20 may need to if you have a particularly large site), but that can cause = RPC and=20 some stdio applications to break. It therefore probably isn't a good = idea on a=20 machine that isn't dedicated to INN.

4. Error Messages

Explanations of specific error messages, including solutions where=20 applicable.

INN logs nearly all messages to syslog, so in general these error = messages=20 will be found in syslog. If you aren't seeing anything from INN in = syslog at=20 all, make sure that you have it set up correctly (see 3.3).

4.1. innd: SERVER cant store = article

You probably have a misconfigured storage.conf. In current versions = of INN,=20 "no matching entry in storage.conf" is added to the end of this message = unless=20 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=20 newsgroup that doesn't match any of the <wildmat> patterns or by = being=20 outside the size and expires ranges of all entries whose newsgroups = pattern it=20 does match, the article is not stored and is rejected by innd(8). When = this=20 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=20 newsgroup patterns or size or expires ranges, assign them to the = "trash"=20 storage method rather than having them not match any storage method = entry.=20

One of the more frequent causes of this problem is misuse of the = expires key=20 in storage.conf entries. Read the man page for storage.conf very = carefully if=20 you're using the expires key, since it may not do what you think it = does. In=20 particular, if you have a storage class that specifies expires with a = min-time=20 greater than 0, it won't match any article without an Expires header = (the vast=20 majority of Usenet articles).

4.2. innd: SERVER internal no control = and/or junk=20 group

Your active file isn't complete. Either it's been mangled by = something or=20 it's missing some required entries. Even if you're running a small = stand-alone=20 server for internal use that only carries a handful of groups, there are = some=20 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=20 the active file by hand without worrying about stepping on INN's toes. = Add the=20 following lines:

    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=20 (messages with a named group will be filed into it, and all other = control=20 messages will go into the top-level catch-all group). The n flag is so = that=20 users won't post messages directly to the control* groups; control = messages=20 should be posted to the groups that they affect instead and INN will = refile them=20 automatically based on the Control header.

4.3. Modification of read-only value = attempted=20 (Cleanfeed)

INN 2.3 and later have an internal optimization to the interface to = embedded=20 filters that makes filtering about 15-20% faster, but which disallows a = trick=20 that many versions of Cleanfeed use to count the number of lines in the = article.=20 (This problem is fixed in current versions of Cleanfeed.)

To correct this problem, find the line in Cleanfeed that looks like: =

    $lines =3D $hdr{'__BODY__'} =3D~ tr/\n/\n/;

and change it to:

    $lines =3D $hdr{'__LINES__'};

The __LINES__ hash value is set internally by all recent versions of = INN and=20 is guaranteed to be correct.

4.4. tradspool: could not open ... File = exists

This error generally happens after a crash or unclean shutdown of = innd using=20 the tradspool storage method, and is caused by overview information = being out of=20 sync with what articles are in the spool. When innd was restarted, it = renumbered=20 its active file (which determines the range of existing articles in each = group=20 and therefore what article number is assigned to new articles) based on = the=20 overview information. If there are newer articles already on disk that = aren't=20 mentioned in the overview (because the overview information for those = articles=20 hasn't been flushed to disk yet), new incoming articles will get = assigned the=20 same number as the existing article and then innd will fail to store the = article=20 and throttle with this error.

One way to correct this error is to rebuild the entire overview = database=20 with:

    makehistory -O -x -F

but this takes a long time and is to some degree overkill. A better = solution=20 in some cases is to just remove all articles in the spool that have = higher=20 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=20 executable, and run it, giving it the path to the active file as the = first=20 argument and the path to the top of your tradspool news spool as the = second=20 argument:

    #!/usr/bin/perl
    die "Usage: <name> <active> <spool-path>\n" unless =
@ARGV =3D=3D 2;
    open (ACTIVE, $ARGV[0]) or die "Can't open $ARGV[0]: $!\n";
    while (<ACTIVE>) {
        my ($group, $hi, $lo, $flag) =3D split;
        my $directory =3D $group;
        next if ($hi =3D=3D 0 and $lo <=3D 1);
        $directory =3D~ tr%.%/%;
        $directory =3D $ARGV[1] . '/' . $directory;
        opendir (DIR, $directory) or die "Can't open $directory: $!\n";
        while (defined ($_ =3D readdir DIR)) {
            unlink "$directory/$_" if ($_ > $hi);
        }
        closedir DIR;
    }

INN 2.4 is expected to have better recovery tools to deal with = problems like=20 this, and to be less vulnerable to losing overview information in system = crashes.

5. Problems on Specific Systems

Problems specific to particular operating systems or platforms. Look = here if=20 INN doens't behave as expected on your particular system, or if you're = having=20 trouble compiling INN in the first place.

5.1. INN won't compile on SCO = OpenServer

On SCO OpenServer, the default cc requires -O be given when -Kalloca = is given=20 (which is added by default by configure since the parsers generated by = bison=20 need it). However, there appears to be a bug in the compiler that causes = it to=20 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=3D-g commands.o

and then cd'ing back to the top level and running make again. On = OpenServer,=20 to build with cc, you have to use:

    env CC=3Dcc CFLAGS=3D-O =
./configure --with-sendmail=3D/usr/lib/sendmail

Building under gcc is cleaner, but of course if you want to use = --with-perl=20 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=20 doesn't apparently generate the right link magic to include the path to = the=20 dynamic Perl libraries. You need to either set LD_RUN_PATH before = building or=20 LD_LIBRARY_PATH before running any binaries so that they can find the = Perl=20 libraries. (The former is preferred, since then the path is encoded into = the=20 binaries and you don't have to remember to set LD_LIBRARY_PATH later.) =

5.2. Using raw devices on Solaris destroys = the=20 partition table

If you use slice 2, or some other disk slice that includes the entire = disk,=20 under Solaris as a raw partition for CNFS, you may run into this = problem. The=20 symptoms are that INN manages to initialize the cycbuffs just fine, but = then=20 gets invalid device errors when it tries to open them again, and the = disks show=20 up in format as needing to be repartitioned.

The solution is to not use raw devices that include the first = cylinder of the=20 disk. Solaris doesn't protect the superblock from being overwritten by = an=20 application writing to raw devices and includes it in the first cylinder = of the=20 disk, so unless you use a slice that starts with cylinder 1 instead of = 0, INN=20 will invalidate the partition table when it tries to initialize the = cycbuff and=20 all further accesses will fail until you repartition.

Generally all that has to be done is to repartition the disk with = slice 0=20 starting from cylinder 1 and extending to the end of the disk and then = point INN=20 at slice 0 instead of slice 2. You lose some small amount of space, but=20 generally not enough to care about.

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=20 Windows. There is, however, a port to Cygwin (which is a Unix-like = environment=20 for Windows). For more information, see:

<http://members.verizon= .net/~vze35rzk/inn/>=20

Don't forget to peruse INSTALL if you download and want to try this. =

6. How Do I...

This section documents various common or uncommon tasks or = configurations=20 that people want to do with INN. It is mostly taken from frequently = asked=20 questions in news.software.nntp.

6.1. Set up a server with no external = feeds, just local=20 groups

The basic steps are to set up a newsfeeds file empty except for = "internal"=20 feeds like overchan and the like, not worry about either nntpsend or = innfeed,=20 have only localhost in incoming.conf (hosts.nntp in older versions), = create the=20 minimal active file (see 4.2) before starting the server, and then after = starting the server create the groups you want to carry with ctlinnd = newgroup.=20 Set up reading permissions using readers.conf (nnrp.access for INN prior = to 2.3)=20 as appropriate for your organization.

6.2. Process a single control = message

To process a single control message, you can use controlchan from the = command=20 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=20 is in a directory in your path.) This is useful mostly for testing; if = you just=20 want to create, remove, or change a group, it's easier to use ctlinnd = (newgroup,=20 rmgroup, or changegroup).

6.3. Split ovdb overview across multiple = disks

The following information is from a message by Heath Kehoe to = inn-workers:=20

There's a way to put the data files in different places, but it's = kind of a=20 hack, and I havn't actually tried it. You can place a file named = DB_CONFIG in=20 your overview directory. In that file, you can list directories that = libdb=20 will search when it goes to open a database. This functionality is = provided by=20 the db library, and not by ovdb itself.

For example, let's say you have pathoverview set to = "/mnt/overview"; and=20 you had four additional filesystems mounted on "/mnt/ov?". You would = create a=20 file "/mnt/overview/DB_CONFIG" containing the following lines: =
    DB_DATA_DIR /mnt/overview
    DB_DATA_DIR /mnt/ov1
    DB_DATA_DIR /mnt/ov2
    DB_DATA_DIR /mnt/ov3
    DB_DATA_DIR /mnt/ov4
(This is valid for 2.7.7. For 3.1.17, replace "DB_DATA_DIR" with=20 "set_data_dir").

Distribute your ovNNNNN files into the four filesystems. (say, 8 = each).=20 When called upon to open a database file, the db library will look for = it in=20 each of the specified directories (in order). If said file is not = found, one=20 will be created in the first of those directories.

Whenever you change DB_CONFIG or move database files around, make = sure all=20 news processes that use the database are shut down first (including = nnrpds).=20

6.4. Feed all articles on a server to = another=20 server

To feed all articles on an existing server to another one, regardless = of how=20 they're stored on the server, first tell the new server to accept = articles=20 regardless of how old they are (otherwise, INN will reject articles = older than=20 artcutoff in inn.conf):

    ctlinnd param c 0

You may also want to set xrefslave to true in inn.conf and then = restart INN=20 on the new server if you want to keep the same article numbers as you = had on the=20 old server.

Then try these commands (a variation on commands posted by Katsuhiro = Kondou=20 to inn-workers) on the old server:

    cd pathdb
    perl -ne 'chomp; ($a,$b,$_) =3D 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=20 (usually ~news/spool/outgoing), and server is the name of the new news = server to=20 which you're feeding the articles.

When done, set xrefslave to false in inn.conf again if you changed it = and=20 then either restart INN on the new server (necessary if you changed = xrefslave)=20 or use another ctlinnd param command to set the cutoff value back to = what's=20 specified in inn.conf.

Please note that this method requires that all of the articles in = your spool=20 have Xref headers. Current versions of INN will always add an Xref = header, but=20 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=20 modify all of those articles to add an Xref header.

6.5. Rename a newsgroup

INN has no native support for renaming a newsgroup, and doing so is=20 difficult, so the best advice is to not do this. If there's a way that = you can=20 just create the new newsgroup, encourage people to start using it, and = then=20 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=20 storage method. The newsgroup of an article is stored in the Newsgroups = header=20 and Xref header of the article as stored on disk (and possibly in = Followup-To),=20 as well as determining where the overview information is stored, and in = the case=20 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=20 the articles to its appropriate new location in the news spool, edit = every=20 article to change the old name to the new name in Newsgroups, = Followup-To, and=20 Xref, and then rebuild history and overview with makehistory.

The following bit of Perl may help with the renaming (from Jeffrey = Vinocur):=20

    #!/usr/bin/perl -wi
    my ($src, $dst) =3D (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=20 contained in the name of another newsgroup to which messages in that = group are=20 crossposted. If that's a problem, you may have to use a more = sophisticated=20 script.

If any articles were crossposted to other newsgroups, you'll also = have to=20 find and recreate the links in those newsgroups to the new location of = the=20 articles (if the links were hard links and the process of changing the = Xref,=20 Followup-To, Newsgroups headers didn't break those links, you may be = lucky and=20 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=20 headers of the articles in that newsgroup and then rebuild history and = overview=20 as above.

One other approach that can be used regardless of storage method is = to refeed=20 the articles to the server into a new newsgroup. This approach works = best if=20 you're also changing news servers at the same time; otherwise, the = message IDs=20 of the articles will already be in history, and you'll have to change = the=20 message IDs of all of the messages or remove them from the history = database=20 (such as by moving the articles away, changing /remember/ to 0 so that = old=20 history entries won't be retained, and then running expire to purge them = out of=20 history). To do this, get all of the messages into a directory (by = pulling them=20 down via NNTP or some other method), change the Newsgroups, Xref, and=20 Followup-To headers to rename the newsgroup, and then create a file = containing=20 paths to all of the articles, one per line. You can then use that file = as input=20 to innxmit, pointing it at the server to which to feed the articles, and = if the=20 articles aren't listed in history on that server and it carries the new = group,=20 they will be accepted into the new newsgroup.

Note that if you use this method and something goes wrong the first = time, the=20 message IDs will probably have all been added to history on the new = server and=20 the articles now will never be accepted until those entries are removed = from=20 history again (or all the message IDs changed).

6.6. Change the domain used for message = IDs

By default, any message IDs generated by INN will use the domain of = the local=20 system for the right-hand-side of the message ID. In some cases, this = isn't=20 desirable for various reasons (the server may have an internal name that = doesn't=20 make sense on Usenet at large, or one may not want to expose the name of = the=20 server).

In INN 2.3.3, you can set domain: in an access stanza of = readers.conf, and=20 all posts coming from connections to which that access stanza applies = will use=20 that domain to generate message IDs. So if you need to change the domain = used to=20 generate message IDs for every local post from your server, just add a = domain:=20 key to every access stanza in readers.conf.

6.7. Use INN without a direct news = feed

INN is designed to be used as a regular news server, receiving direct = news=20 feeds from other news servers and sending news directly to other news = servers=20 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=20 cache for a news server that you can use to read and post but which = doesn't=20 treat your server like a peer.

This configuration is generally called a "suck" feed, because rather = than=20 having news fed directly to your server, you pull it down or "suck" it = from=20 another news server, and because possibly the first and one of the most = widely=20 used packages for doing this is named suck.

The software to pull down articles from another server and to feed = articles=20 to another server using post rather than peer-to-peer commands does not = come=20 with INN (INN has a few utilities to do this on a small scale, but not = really=20 anything designed to handle a lot of groups or a lot of articles). You = will need=20 an external package to do this. The two most popular are suck and newsx, = which=20 you can get from:

    <http://www.sucknews.org/>
    <http://www.kvaleberg.com/new=
sx.html>

respectively.

Note that current versions of INN refer to articles internally using = a=20 storage API token, not a path name, which is not always what suck or = newsx=20 expects. Read the documentation carefully; you'll need to use a script = or=20 configuration that retrieves articles using the sm program that comes = with INN=20 rather than trying to open files directly.

It's also worth noting that INN is a fairly complex package, and = while many=20 people are running it successfully using this sort of configuration and = like=20 having a full-fledged news server available to them, other people have = found INN=20 rather complicated and difficult to configure for a small, simple = personal news=20 cache. If your needs and goals are simple and the number of groups = you're=20 interested in is small, you may be better off with a smaller, lighter = package=20 such as LeafNode or NNTPcache.

Return to FAQs=20 and Documentation

Russ Allbery <rra@stanford.edu>
Converted = to XHTML=20 by faq2html = version 1.16=20

------=_NextPart_000_001A_01C26A3D.240A4F80 Content-Type: image/png Content-Transfer-Encoding: base64 Content-Location: http://www.eyrie.org/~eagle/valid.png iVBORw0KGgoAAAANSUhEUgAAAFgAAAAfCAMAAAEjEcpEAAACiFBMVEUAAADe5+fOezmtra3ejEKl hELvvWO9WlrehELOe3vepaWclHvetVLGc3PerVKcCAj3vVqUjHOUe1JjlL0xOUpjjL2UAAC91ueM rc7vrVKlvdbW3u+EpcbO3ufO1ucYWpSMKQi9SiF7e3taWkoQEAiMczkQSoxaUkpzc3O1lEoICACE azEhGAgIAACEYzFra2utjELWcznGnEr/7+9jY2POazHOYzGta2NShLVrlL05OUqctdacCADGa2uc AADGpVqUtc61ORg5OTmlUikYGAiUezl7YzEYEAiUczkxMTG9nEqtIRDe3t4AMXu9lEoQCACMazEA KXspKSmljFrW1ta1jELOzs7n7/fGxsa9pVqEOSkpY5xznL29tZxahLXOpVr/99ZrY1L/79ZjUilj SikAOYTvxmMAMYScezmchFqUczGtlFp7c2utjFqUlJStxt73///39/9Ce61CSkq9xsZznMbW5+9C c62MjIxCQkrv9/fv7/fOzsbnlErWjIz/3mtCORhza1IpIRBzWjH/1mtCMRhzY1L/zmvnvVpSQiHO pVJrUinntVr3zmOEc1L3xmNaWlq1nFo5QkrGWim1lFoISpRSUlK1zt4hWpwASoz///////8xa6WU aykAQoxKe61KSkp7nMbWtWPe5+9jWlL39/f39/fWrWNCQkLera3nvWPv7+85MRjntWPetVp7c1Ix KRCUlHtKORh7a1IxIRCUjHtaSiHWrVIpIQhzWinvvVpaQiH/1mPWpVKMe1L/zmP/xmNrUiGErc4Y GBj/73PG1ucQWpT/53O9nFoQUpS1SiEQEBC9zt69vb05c6UISoxSUko5a6UICAhSSkohUpS1tbXe tWMAQoSUgD+kAAAA2HRSTlP/////////iP9sSf//dP////////////////////////////////// //////////////8M////////////ef////////////////////////////////////////////// //////////////////////////////////////9d//////////////////////////////////// AP//////////////CP//RP////////////////////////////////////////////////////// //////9xPp1gAAAFvUlEQVR42pVWi18URRwfy7vsYUbaiqBRBFmICUQGVKcZckQeaRJQUCLeycMS fKGH0uo5NELpIvGQGzokvTTA85VHKTpbRoeJnPno/p1+M7t3txj20e/Nzu7Ofve7v/k9Zg4Vc+wR QMW0eyLx1ZSANeBDxVmxZZSwEUYkGAewm1eIBOMRvhv1UA+q8KXIVuxGdCelFYwxAnxOrxgbY8Ti 1t4VA0QHYz4x3FnVC8OVLXv9fkKGSWDoW/4lG6VbdtBblesOs+MjmEmzJKNIJWFEfEQTCWNPFKvc KEymjLO1b8bwYQd1hCiiDCl5KsrDCIlhj4fSuvcpfSpgJmyv6dzeZv+nMPx3dhbt94II07/JZliE tm1N2RIYPkTYshwYm245a/zkWjJwcyFh6ZIcYxxmqiaDSYxhOhFUsqngi3Fzcj3ljdYDNE9uzA1Y D/5MhnzW1KRqF7mYG8jFYXLcfLpjOe2LA0fuGqQrQHl10sdK0sFcFSOSlzF0BgXQH9h3QZDBI0cc NEhftjXuippBDD2/eMRiETmwwNEYHyqhdDyo22w+3QHuNbdve5a7eOkHmDVJ0ixNmfbz1h0qo/Q6 GuSB2wQJQbpOjOQAl7woWSRJ0m2ewhvAOUiYYtZtaZL0CZZmtmVOQttLfr/dbveLZodrfrL7W75w G/JjqkQxoNTtNsTKELQpQL6/D5loaSmyTT8TUhsmi8iFA0hZiyltf7OiNKdarRm5w2So2lTNdPLu IzR+AiLj8VTRJaj0LmX4VhJ27f/VJV/yycilWPOrk8NkXi7Qqmj5bHqVZlJKZIRk1wFzKrt0WUbn XMPJ1fk4TJ5oWBA61p1V76DeIs0MX+s3GxRlA1vtw83KhgNphc1nyErLO5zcvbOsrq+scbZnpzc6 QVFPenLwGxmC+BOfYI+DN55QYddh4Q/NE/yGYYj4TOGNngQavAZnzzTovEA+kcMJ+247uYexNA+4 Fsvjmuv662jsWxPZx2xg890bYMYnTgya7bjmCiEY0qgJ0vMF3c+NoFdPyzxz6V3Uxs3AOWCDchRv OsQtBrbFsrT2fhHEc7ByGzu/dA4IO0A3HdfeP9yMqAwP6NPEb6cbwn0PWVU17/FDBQh/CPIrbfcg 027IZrsAT/Bf3FNWyn9RSR4cvvwn3e4HFmYPDl/thYcRVi8qPEoXVUWBl6FTBFTtnqmKKg5wnlF4 wZ1yeLv7TiwXKektE+iDBNicWEyLpnFhfDkpJc3q2khSPyQBbE0dMJnOoDzTwGsI7cdyMkL5gWqU jCF6Txst/twxCv1WzzHoy21ZDQ1xnuDzdPDWR4knr14v0tYn3IxaMFFdiMOlEOJHw1jOQ4sWt5rQ opRkXZhMEi7pmeDCVWBlfUKwhMZ7rsF6elKsvbwiKxgxIdewa3ErsaYomCVZFYJb0GUu3JqGUNop lBxYiYby8vLBFWef+Cri4/I1sbQ/1OtYTrNtdXS+rSe7kQ52eSObL99/iErCWUjCy5W4JLygmCou GfG9x9fmx17XhBuDCaOerbt538erta7TFktLvdHghZcCbcPQO33zIJG9kxF5hoVXnzTzRz0r5js8 oTj6uyPkGRf346HOLcasgFexueNUWFPtuFKzjoSFYYedhwVlhsRVYWWJpltv1XPQT1Rl0bjZIBlb 1XujVDzY/Kj4k6Ku3+Z0jo1owjVzDpFTXe1juvBSWNFmNWGZy8LvzUl5PN4JCwyNDzbQ0aAj4Zrj z0FatGJJYhvq4j7mGSpvytGFlZtHf2C4o/28Zu8z7wo7eYPfXysnF0i9NnPh1t1zR7VBb9GqaOXh tTmHQdgMFXE+Z608cnpODdZdjL+TuDY44Q38kJXHhccWLoOd9uv1AwwvO+48uu+faCSJPJ1bmy6T hyvpivBmYWgjxPDPAp7JTemY/yGKFEiRt/jG/2P79s8KCwoLCgoLC/khUBA5F0SfQZ+RYfpNE/4X osmq7jsZAJsAAAAASUVORK5CYII= ------=_NextPart_000_001A_01C26A3D.240A4F80 Content-Type: text/css; charset="big5" Content-Transfer-Encoding: quoted-printable Content-Location: http://www.eyrie.org/~eagle/styles/faq.css BODY { BACKGROUND: white; COLOR: black } H1 { FONT-SIZE: x-large; TEXT-ALIGN: center } P.navigation { TEXT-ALIGN: right } ADDRESS { BACKGROUND: silver; COLOR: black } IMG.signature { FLOAT: right } A:link IMG.signature { BORDER-LEFT-COLOR: transparent; BORDER-BOTTOM-COLOR: transparent; = BORDER-TOP-COLOR: transparent; BORDER-RIGHT-COLOR: transparent } A:visited IMG.signature { BORDER-LEFT-COLOR: transparent; BORDER-BOTTOM-COLOR: transparent; = BORDER-TOP-COLOR: transparent; BORDER-RIGHT-COLOR: transparent } HR { BORDER-RIGHT: silver 1px solid; BORDER-TOP: silver 1px solid; = BACKGROUND: silver; BORDER-LEFT: silver 1px solid; COLOR: silver; = BORDER-BOTTOM: silver 1px solid; HEIGHT: 2px } H2 { FONT-SIZE: large; BACKGROUND: silver; COLOR: black } P.subheading { FONT-WEIGHT: bold; TEXT-ALIGN: center } ------=_NextPart_000_001A_01C26A3D.240A4F80--

INN 2.x FAQ

Contents