Path: network.ucsd.edu!ihnp4.ucsd.edu!swrinde!cs.utexas.edu!uunet!news.mentorg.com!sdl!not-for-mail
From: tal@Warren.MENTORG.COM (Tom Limoncelli)
Newsgroups: news.software.nntp,news.software.b,news.answers
Subject: INN FAQ Part 2/4: Debugging Guide & Tutorial
Supersedes: <inn-faq-2-764139607@Warren.MENTORG.COM>
Followup-To: news.software.nntp
Date: 5 Apr 1994 04:00:12 -0000
Organization: Mentor Graphics - IC Group, Warren, NJ, USA
Lines: 1392
Sender: tal@Warren.MENTORG.COM
Approved: news-answers-request@MIT.Edu
Distribution: world
Expires: 04/20/94
Message-ID: <inn-faq-2-765518407@Warren.MENTORG.COM>
References: <inn-faq-1-765518407@Warren.MENTORG.COM>
Reply-To: Tom_Limoncelli@Warren.MENTORG.COM (Tom Limoncelli)
NNTP-Posting-Host: sdl.warren.mentorg.com
X-Summary-1: Part 1: Common questions about INN itself, useful to people that do not currently run INN. Also, some advice specific to certain operating systems.
X-Summary-2: Part 2: Read this AFTER you've read and followed the directions in Install.ms. Help with getting innd to start. A tutorial on debugging posting/access problems. A list of error messages and what they mean.
X-Summary-3: Part 3: Day-to-day operational questions. General questions asked once INN is running for a while. Some big changes you can make. Bug warnings for 1.4, 1.3, 1.2.
X-Summary-4: Part 4: Norman's quick guide to getting started (assumes SunOS and other things), and misc. other things.
Xref: network.ucsd.edu news.software.nntp:6308 news.software.b:6164 news.answers:20328
Posted-By: auto-faq 2.4
Archive-name: inn-faq/part2
Last Changed: $Id: FAQ-inn.2,v 1.25 1994/03/31 21:21:56 tal Exp $
Part 2 of 4
INN FAQ Part 1/4: General Information
INN FAQ Part 2/4: Debugging Guide & Tutorial
Reasons why INN isn't starting
The debugging tutorial
Other error messages and what they mean
INN FAQ Part 3/4: Operational and Misc. Questions
INN FAQ Part 4/4: Appendix A: Norman's install guide
------------------------------
Subject: Table Of Contents for Part 2/4
=====================================================================
TABLE OF CONTENTS FOR PART 2/4: Debugging Guide & Tutorial
=====================================================================
REASONS WHY INN ISN'T STARTING:
Why does innd just exit right away with no message?
syslog message: ME internal no to group
syslog message: ME internal no control and/or junk group
syslog message: Can't setup communication (bind failure)
syslog message: ME bad_newsfeeds no feeding sites
syslog message: ME cant GetConfigValue
THE DEBUGGING TUTORIAL:
Should I read the Install.ms file in its entirety
before reading this document?
Terminology used in the rest of this document.
How does it all fit together?
What should I monitor as I debug INN problems?
My innd won't start!
Connecting to a TCP/IP server.
Make sure that "feeders" can connect.
Make sure that "readers" can connect.
Make sure that clients can post.
"client" doesn't have the software needed to post.
Introduction to the "newsfeeds" file
The ME line in the newsfeeds file.
How does the "ME" line interact with the other lines?
Cookbook example of an outgoing NNTP feed.
Cookbook example of an outgoing UUCP feed.
Cookbook example of an outgoing UUCP-over-TCP feed.
Testing an outgoing feed (your "newsfeeds" configuration).
Other cron jobs.
Cookbook example setting up NOV ("overchan").
How do I use nntplink with INN?
How do I use newsgate with INN?
OTHER ERROR MESSAGES AND WHAT THEY MEAN:
ld.so: Undefined symbol: _dbzwritethrough
Why does my innd often die with the message "Can't sync history..."
syslog message: ME cant sendto CCreader bytes 4 No such file
or directory.
inews says "bad message-id"
Why do all these "readclose" messages show up in my syslog?
"File exists writing symlinking article file -- throttling"
"cant fopen <newsgroup>/.thread No such file or directory"
news.daily reports: "Expire had problems removing articles"
syslog: ME cant nonblock 15 Operation not supported.
innd: ME cant update_active control
syslog message: innxmit[1234]: max connect failed Error 0
Can't open "/usr/local/news/shlock955", Permission denied
=====================================================================
REASONS WHY INN ISN'T STARTING
=====================================================================
------------------------------
Subject: Why does innd just exit right away with no message?
First, fix your syslog: innd always logs a message before it exits. (The
INN distribution includes a version of the current UCB syslog, along with
instructions on how to install it. Ultrix systems might want to look at
the syslog that is available on gatekeeper.dec.com) Second, the most
common cause of this is that you do not have a history file (or no history
database). You will see a message like this:
ME cant dbminit /usr/local/news/history No such file or directory
This means that you do not have a history database. You might want to run
the BUILD script in your INN source tree or read about makehistory in
doc/news-recovery.8; if you do the latter, make sure to rename the
database files.
******This FAQ covers general questions about INN and questions
about how to compile it. For information on configuration and debugging
one's configuration, see the "INN Configuration FAQ".
------------------------------
Subject: syslog message: ME internal no to group
Nelson Minar <nelson@reed.edu> discovered the hard way that:
If you set MERGE_TO_GROUPS to "DO",
You have to have a "to" group listed in your "active" file or you will
get the above syslog message and innd will not start.
------------------------------
Subject: syslog message: ME internal no control and/or junk group
You must have a newsgroup named "control" and a newsgroup named
"junk" for innd to start.
------------------------------
Subject: syslog message: Can't setup communication (bind failure)
The message "Can't setup communication (bind failure) Permission denied"
means that the permissions on your _PATH_NEWSCONTROL directory
are wrong. You might want to delete the directory and "make install"
to create it again.
------------------------------
Subject: syslog message: ME bad_newsfeeds no feeding sites
(Rich Salz replies:) The syslog message is telling you that you are not
feeding news to any sites. You have to have at least one feed. (You
may consider this to be a bug, it's just that I'm too lazy to make
everything work right if you don't have any newsfeeds.)
Until you go into production and start feeding sites, add a line like this:
dummy-feed:!*::
------------------------------
Subject: syslog message: ME cant GetConfigValue
Jan 12 17:38:06 galaxy innd: ME cant GetConfigValue pathhost Error 0
^^^^^^^^
This means you don't have "pathhost:" in your inn.conf.
GetConfigValue is the routine that gets data out of the inn.conf file.
If you get the above error, it means you don't have a particular value
in your inn.conf. Run "inncheck -v" usually will tell you what you
need to do.
=====================================================================
THE DEBUGGING TUTORIAL
(or, What do I do after Install.ms?)
=====================================================================
------------------------------
Subject: Should I read the Install.ms file in its entirety before reading this document?
YES! Install.ms tells you how to compile and install the software.
This document walks you through debugging the *configuration* of the
software once it is installed.
This document takes you from where install.ms leaves off, gives you a
quick overview of how all the pieces fit together, and then takes you
through specific debugging tasks.
Debugging INN problems is often difficult because one needs to be an
experienced netnews person to do it well. You can only get experience
by having a properly running system. This is a catch-22. This
tutorial attempts to take you through the basics. The rest you'll
figure out.
Newsgroups you should know exist:
news.software.nntp -- INN questions go here.
news.software.b -- Discussions about any of the many software
packages that support the "B news" format (i.e. INN, C news,
ANU-NEWS, etc.)
This document also takes you through the process of verifying that your
system is properly configured. When you are done, you should:
1. be sure that when feeders connect they are treated as feeders.
2. be sure that when clients connect they are treated as clients.
3. be sure that posting works.
4. be sure that your out-bound feeds are properly configured.
------------------------------
Subject: Terminology used in the rest of this document.
We will pretend that your machine is named "nntphost" or
"nntphost.do.main" and that there is a client named "client" or
"client.do.main".
Some machines connect to you to try to feed you new articles. We'll
call these machines "feeders". Some machines try to connect to you to
read and/or post articles. We'll call these machines "readers".
------------------------------
Subject: How does it all fit together?
Here is a fantastic overview of the workings of INN.
From: Ken Hornstein <kenh@leps5.phys.psu.edu>
I discovered that the biggest problem I had with INN was understanding how
everything fits together (since I had no experience with B or C news).
Here's a (hopefully) simple description of how everything fits
together:
After running rc.news (as "root"), you should have the "innd" daemon
running ("ps" will show the process to be owned by "news"). This is
the Master Daemon. It handles incoming connections, stores the
articles on your disk, but does _not_ send any articles out itself. It
directs other programs to do that. Exactly where articles are sent and
how they are sent is determined by the "newsfeeds" file. Setting up
your newsfeeds file will be the hardest part of configuring INN. Here
are some example entries from my newsfeeds file:
ra/ra.nrl.navy.mil\
:*,!psu.*/!psu\
:Tf,Wnm:
Looks complicated? It isn't. Here's what it means:
"ra" is the name of the feed. "/ra.nrl.navy.mil" is an alias for ra.
This is important because INN uses the "Path" header to insure the
articles are not sent to sites where they have already been. Thus, any
article that has "ra" or "ra.nrl.navy.mil" in the Path header will NOT
be sent to this site. We know that no other site inserts "ra.nrl.navy.mil"
because it is a FQDN (Fully Qualified Domain Name). We know that no
other site inserts "ra" because it is registered in the UUCP Maps.
(Ok, "ra" isn't registered so I'm just taking a small gamble.)
The second line tells what articles will be sent out to this site.
"*,!psu.*" means that articles for (all newsgroups minus those that
match "psu.*") will be sent to ra. The details of the pattern matching
is found in the wildmat(3) man page. The "/!psu" means that articles
with a "Distribution" header of psu will also not be sent to ra.
The last field specifies exactly what _kind_ of feeds. "Tf" means this
is a file feed. Unless you have unusual requirements, all of your
feeds will be file feeds. "Wnm" means that the relative path name and
the Message-ID of the article will be written to this file. By
default, this file is called the same name as your feed file, and is in
your out.going directory. So on my system, every article destined to
ra will have its filename and Message-ID written to the file
"/var/spool/news/out.going/ra".
So how do the articles actually GET to ra? You run a program that
reads the feeds file and transmits the article. Two such programs are
included with INN -- "send-nntp" and "nntpsend". My personal
preference is for nntpsend. If you are going to use nntpsend, you will
need to add a similar line to your nntpsend.ctl file:
ra:ra.nrl.navy.mil
This tells nntpsend that articles in the feed file "ra" should be sent
to the site "ra.nrl.navy.mil". I run nntpsend out of cron every 10
minutes with this line (in /usr/lib/crontab):
0,10,20,30,40,50 * * * * /bin/su news -c '/usr/local/news/bin/nntpsend'
This is under Ultrix. A sane cron would let you specify the userid to
run programs under.
UUCP feeds work similarly and are described in a different section.
As each article comes in (note that hosts feeding you _must_ be listed
in the hosts.nntp file), innd will examine it and distribute to your
listed feeds based on the above-described selection criteria.
Another important thing to do is to make sure your articles get
expired. This is done from the "news.daily" script. The "expire.ctl"
file describes how long you want each article to last. Here are some
sample lines from my expire.ctl:
/remember/:14
This line tells expire to keep history entries for articles 14 days
after they have been deleted.
*:A:1:7:21
This is the default line. This says that by default, an article is
kept a minimum of one day, the default expiration time is 7 days (this
applies if there is no "Expires" header), and the very maximum that the
article is kept is 21 days.
psu.*:A:1:14:28
This line applies to groups only in Penn State. By default, those
articles will last 14 days, 28 days at the most.
Note that lines in expire.ctl should have the most general entries
first, with the most specific entries last.
Lastly, where do newsreaders fit in? When a newsreader connects to the
innd process, it sees that this is not a feeder (the hosts.nntp file
lists only sitest that feed YOU) so it forks a nnrpd process and hands
the connection to it. This way innd can concentrate on newsfeeds.
Some newsreaders don't open a connection, but instead read the articles
out of "/usr/spool/news" (and gets meta data from "/usr/lib/news").
INN doesn't need to do anything about those readers except to make
sure the right data is where they expect it.
------------------------------
Subject: What should I monitor as I debug INN problems?
1. run "tail -f /var/adm/messages" to see if any syslog messages are
being generated.
2. run "tail -f /var/log/news/news.err" to see if any fatal errors
happen.
3. Check for incoming email constantly (especially when trying to post
from "nn").
------------------------------
Subject: My innd won't start!
Keep a "tail -f /var/adm/messages" running. INN reports most errors
via syslog. The syslog messages usually explain what is wrong.
Elsewhere in this document are details about some of the less obvious
syslog messages.
Chances are, INN is starting, finding a misconfigured "ME" line in the
newsfeeds file, and exiting. You might want to read the section on
configuring your "newsfeeds" file first.
Rich Salz says a common reason is that you ran makehistory but didn't
rename the DBZ files. "makehistory" generates history.n.dir
and history.n.pag. They must be renamed:
mv history.n.dir history.dir
mv history.n.pag history.pag
Izar Tarandach <izar@cs.huji.ac.il> suggests that another common
mistake is that innd wasn't being started by the correct uid. innd
(and therefore rc.news) must be started from "root" (not "news"). It
immediately turns itself in user "news" once certain tasks are
completed.
If you use a suid root inndstart, you can run it as any user.
------------------------------
Subject: Connecting to a TCP/IP server.
You know that "telnet"'ing to a machine lets you log into it. You are
actually connecting on the "telnet" port (port 23). Many TCP/IP
services allow you to "telnet" into their port and talk directly to
them. Try "telnet nntphost 21". This means log into port #21 (the
"ftp" port) instead of the usual remote login port.
Once you are in, you'll get no prompt. Type "help" and press RETURN.
You should get a list of commands. If you know what the commands are,
you can talk to this server. Type "quit" and press RETURN to get out.
After every command you should get some kind of status message. Each
line will begin with a number. Each message has a unique number.
Errors are defined as anything that starts with a number >= 400.
Positive (non-error) messages are <400.
SMTP (mail) and NNTP (netnews) work the same way. Telnet into their
port and issue commands and data. "quit" always gets you out.
We'll use this to debug INN configurations by "telnet"'ing into the
innd server and seeing the raw error messages it gives us.
Try "telnet"'ing into the NNTP port (#119) of a working NNTP server to
see what it's like.
------------------------------
Subject: Make sure that "feeders" can connect.
"feeders" are listed in hosts.nntp. "readers" are listed in
nnrp.access. This section deals with "feeders" and hosts.nntp.
When a machine connects to the NNTP port of nntphost, it connects to
the innd process. innd knows the internet address of the machine that
is making this connection, and sees if it matches the internet
addresses many of the machines listed in the hosts.nntp file.
If the machine is not listed in hosts.nntp, it is assumed that this
machine is not a "feeder" and forks off a nnrpd to handle this
connection as a "reader". If you didn't know that, you didn't read
enough of the INN installation documentation. Go back and read it
now.
Read the man page hosts.nntp to get a complete understanding of what's
going on. nnrpd uses its own authentication scheme, which is
described in the next section.
Since I know you didn't read that man page, I'll give you one more
chance to read it now.
Let's configure hosts.nntp. Just enter the names of all the machines
that feed you:
feeder1.do.main:
feeder2.do.main:
I don't use passwords yet. If you do, add them after the ":".
Now let's test to see if the feeder can connect properly.
Log into to the feeder and "telnet nntphost 119".
If you can't log into a feeder, configure your own machine as a feeder
(i.e. feeder to itself) for testing purposes. Once you can see that
INN is treating that machine as a feeder you can replace the machine's
name with the name of a real feed.
If you are given an error message and booted out, check the error
message to see what's wrong. Maybe the machine is running maintenance
at the time and you have to try again later. Maybe the machine doesn't
recognize you at all and you have to edit "hosts.nntp" (and don't
forget the "ctlinnd reload hosts.nntp" command!).
Run "inncheck" to tell you if you have made any obvious mistakes.
If your "history" file or other files have the wrong ownership or
protections INN will mention the offending file in the error message.
Another common mistake is that people try to use wildcards in
hosts.nntp (which is not supported). Remember, there are very few
machines that you consider to be "feeders", so you don't want to use a
wildcard.
To test a "feeder": If "feeder1" can send an "ihave" command and get a
"335" as a response, you know that "nntphost" is permitting "feeder1"
to transfer news as a "feeder". "ihave" requires an operand. I
usually type "ihave <1@test>" and press RETURN. "<1@test>" is a
Message-ID that I know doesn't exist. If I get "500 What?" I know that
innd assumed that I'm a "reader" (so I have to edit my "hosts.nntp"
file and add this client). If I get "335" and then a blank prompt,
then INN is expecting to be fed an article. I usually just "^]"
(control-]) and "quit" out; I know that it was willing to accept the
article. If I get some other error message, it usually gives me enough
information to debug the problem.
------------------------------
Subject: Make sure that "readers" can connect.
As I wrote before, if a connection comes from a machine that isn't
listed in the hosts.nntp file, it is assumed to be a "reader". A
"feeder" can also issue the "mode reader" command to become a
"reader". If you have "telnet"'ed in as a "feeder", try issuing this
command.
Note: If a site is going to feed *and* read, you'll have to link
readers with innd's client library. The reason for this is that the
clients must tell innd that they want to read using the "mode reader"
command. The library does that automagically. It is rare that you
have a machine that is a reader and a feeder (since people will want to
read on their local machine, not yours.) News readers are now
being packaged as "INN ready" so this will be less and less of a
problem.
Once the connection has been handed off to nnrpd, nnrpd checks to make
sure you are authorized. It does that by reading the nnrp.access
file.
There is a problem with what you enter in that file. Namely, I might
call the client machine "client", but that doesn't matter. What
matters is what "nntphost" thinks "client" is called. Maybe "nntphost"
thinks its name is "client.do.main" or even "137.202.177.3". It
doesn't matter what *you* call "client", permissions in the nnrp.access
file have to be specified based on what "nntphost" calls "client".
Technically, nntpd uses gethostbyaddr() to reverse-lookup the name.
gethostbyaddr() uses DNS or, if you are on a brain-dead Sun running
Sun's NIS/DNS hack, it uses NIS, or DNS, or whatever the hell Sun was
thinking when they created that cruft.
To find out what "nntphost" thinks your machine is called, do the
following: Telnet from "client" to "nntphost" and execute the "finger"
command (just "finger" alone on the command line). The last column is
what "nntphost" thinks your machine is called.
If you don't have an account on both machines things are more
difficult, consult your NIS or DNS expert to tell you what the answer
would be.
There is one exception to this technique. If you are using SunOS and
braindead NIS you get just the machine name (like "milk") instead of
the FQDN (like "milk.warren.mentorg.com") then you must tack on a
period then the domain of the machine.
So, with this knowledge (what your nntphost think's client's name is)
and a copy of the man page, edit nnrp.access and add "nntphost"'s name
for "client" to the file. Unlike hosts.nntp, nnrp.access can have
wildcards (for example, "*.sjc.mentorg.com"). You'll want to include
wildcards for all the domains that should be allowed to read/post.
Here are some decent examples from my nnrp.access file:
-------------------------------------- Tom's nnrp.access file START
## Default is no access, no way to authentication, and no groups.
*:: -no- : -no- :!*
*.mentorg.com:Read:::*
*.mentor.com:Read:::*
*.warren.mentorg.com:Read Post:::*
-------------------------------------- Tom's nnrp.access file END
The second field of "nnrp.access" is case sensitive. "read post" does
not mean the same as "Read Post". If you know this already it's
because you read the man page.
Note: nnrpd will append the domain to a name that is not a FQDN.
There is no need to try to find a wildcard that will match non-FQDN
names (i.e. machines in your local NIS cluster). Previously this FAQ
had reported that "*[^.]*" would match these short names but that was
wrong (the wildcard matches everything, oi!). nnrpd turns non-FQDN's
into FQDNs.
After you change "nnrp.access" you don't have do "ctlinnd reload" since
the file is read by each nnrpd as they start up.
Now "nntphost" should be letting "client" read. Let's test this out:
Log into to the reader and "telnet nntphost 119".
To test a "reader": Give the "mode reader" command and see how it
it goes. If it doesn't give an error, then nnrp.access is letting you
through. To read an article (or just get the header) type "head
<2@test>" and press RETURN. Again, "<2@test>" is a message-id that I
know doesn't exist. If you are allowed to read at all, it will tell
you that it can't find that article. You should try the command with an
message-id that you know exists and make sure you see the article's
header.
If reading works you can skip to the next section. The rest of this
section helps you debug reading problems.
If "mode reader" gives an error (and rudely disconnects you) then you
have a typo in nnrp.access OR you didn't issue the "ctlinnd reload"
command correctly (or at all) OR nntphost thinks that "client" is
called yet something else OR innd can't exec nnrpd for one reason or
another -- see the syslog output or the innd.err log file. Check all
of those things then go to the beginning of this section and start
over.
Note: Some telnet implementations are Real Stupid and disconnect you
before showing the error message.
You can also run nnrpd by hand if you have
stdin:Read Post:::*
in your nnrp.access file. Just run nnrpd and type interactively. This
is useful for making sure it's compiled right.
------------------------------
Subject: Make sure that clients can post.
The "inews" command (usually in /usr/local/bin) takes a post from a
user, adds any missing headers, appends the first 4 lines of
~/.signature (if it exists), and possibly replaces any headers that are
obviously forged. "inews" will also reject a message if the message is
seriously botched. "inews -h" expects a post on stdin beginning with
headers, then a blank line, then the body. "inews -h -D" doesn't post
the message, but outputs what it would have posted. The minimum
headers one can feed is "Newsgroups:" (which is plural) and "Subject:"
(which is singular).
By the way, a header looks like "Header-Name: data". I'm trying to
point out after the header name there is exactly one colon then exactly
one space. The space is a space, not a tab. Also, the list of
newsgroups on the "Newsgroups:" line is a comma separated list, with no
spaces. There are no spaces before the colon. If there is nothing
after the colon or if there is only whitespace after the colon then
that header will be removed by "inews". Sites that don't remove such
"empty" headers have broken software. Get it? Got it? Good.
Here's the test message I constantly use:
------------------------ cut here 8<
inews -h -D
Newsgroups: foo.test
Subject: test of inn posting
this is a test
------------------------ cut here 8<
Exciting huh?
You might also use the 'feedone' program in the frontends directory.
Do "cd $inn/frontends ; make feedone" to get it built. To run it, do
feedone -t -r /tmp/inews.input
This will (-t) trace all I/O with the server and (-r) use a random
message-id each time. If you want to test posting from a newsreading
host (i.e., one that connects to nnrpd and uses the POST command) use
the -p flag.
If inews was able to get to the /usr/lib/news/inn.conf file (for
defaults) you should get a nice post on your screen. If you don't,
here are my suggestions:
1 -- You have an old inews from C news or B news laying around
2 -- inews will give you an error message saying what's wrong.
You might want to look around the usual places to make sure that there
are no old versions of "relaynews" or "inews". People trying to use
the "inews" from C news will get a message about "can't open
redirection" or similar. Make sure they are running the programs
included with INN. There is something called "mini-inews" which should
just take a post and send it to the nntp server. Delete that and
replace it with INN's inews. INN's inews is mini-inews and regular
inews, it is the ying and then yang of inewses. It is the one true
inews. It is the one inews to end all inewses and all others are false
idols.
Note: False idol worshipper and heathen David Myers <dem@meaddata.com>
reports that mini-inews works fine. He stays with mini-inews...
"because INN inews needs to access not only inn.conf, but moderators,
too. Installing and maintaining these files in a ~1000 client,
multiple administrative domain setup like ours is too much of a pain.
Most (all?) of the work done by INN inews is done by in.nnrpd during
posting, anyway."
Kenji Rikitake <kenji@rcac.astem.or.jp> reports:
"Keep in mind that INN inews refers to many environment variables.
Beware of _inherited_ variables especially when you do su to maintain
your news server.
I got trapped and wasted a day with NNTPSERVER. I tried to post to a
local newsgroup, and inews kept refusing it and sending me 'no such
newsgroups...' error message. I finally found out that inews was
looking up a wrong server, _implicitly_ specified by
'setenv NNTPSERVER ...' in my .login script. It took a day to find
such a subtle misconfiguration, after a whole recompilation of entire
INN kit, active and history rebuilding, and all possible configuration
checking. *sigh*"
INN's inews sometimes prints the error: "Can't get list of newsgroups,
No such file or directory.". inews called CAlistactive() to get a
local copy of the active file. If it can't reach the active file you
get this error. Look at your PATH_TEMPACTIVE and see if it makes
sense; i.e., if it is a valid /tmp directory.
"inews -h" sometimes reports:
Can't send article to the server:
441 480 Transfer permission denied
This means that you set HAVE_UNIX_DOMAIN to DONT and you don't have
your news server in its own hosts.nntp file. (nnrpd gets a POST,
connects to innd over a TCP socket and sends an IHAVE.) (thanks to Chris
Jackson <cjj@sun.com> for pointing this out). Add your news server's
name to hosts.nntp and do "ctlinnd reload hosts.nntp".
(for the reason why, read "Warnings to people that must set
HAVE_UNIX_DOMAIN to DONT")
If it still doesn't work, look through your syslog to see the name
of the host that innd got, and why it handed off to nnrpd. Perhaps
there is a DNS/NIS/hosts-file mismatch. (suggested by Rich Salz)
Other problems are usually the result of not being able to find the
"inn.conf" file (copy it to the client or make it available via NFS) or
you are using Sun's brain-dead NIS/DNS stuff which doesn't do reverse
name lookups well. If inews tells you that it can't generate a
Message-ID, this is because it can't figure out your domain (which is
used in making the message-id string). Force it to know your domain by
adding a "domain:" line in "inn.conf". Solaris 2.x users will get a
"can't generate message-id" error if they didn't follow the advice
about getfqdn.c mentioned in another part of this FAQ.
Once you get "inews -h -D" working, do the same test without the "-D" option
and let it actually post the message. If it can't post, it will tell
you why. If the answer isn't clear enough, "telnet nntphost 119", give
the "mode reader" command, then the "post" command. Enter lines of
text like you would to "inews -h" and then type "." on a line by itself
(and press RETURN).
If posting via "telnet nntphost 119" DOES work and posting via "inews -h"
DOES NOT work, you know that (1) "inews" is compiled wrong, or more likely,
(2) you aren't using INN's inews. Either way, if this is happening
you know you have narrowed your problems down to the inews program.
By the way, posting to misc.test is pretty useless considering that the
entire world doesn't need to see your message. Post to a local
newsgroup or even a state-wide newsgroup like "nj.test" (assuming you
are in New Jersey). There are lots of people that reply to every test
message they see, so expect to get tons of stupid email. (though, if
you don't get any email consider yourself lucky). Also, there is no
newsgroup called "news.test" so don't post there. Many do, many fail.
By the way, if you are one of those people that reply to every test
message they see, get a real hobby.
Do *NOT* post your test message to a non-test newsgroup. You will get
many angry replies from all over the world.
Look at the posted message in the news spool (if you post a message to
nj.test, "cd /var/spool/news/nj/test" and cat the highest numbered file
you see). If your site name is listed multiple times in the "Path:"
header, put your server's name on the "pathhost:" line of "inn.conf"
and recompile INN with "INEWS_PATH" set to "DONT". (I don't know why
Rich likes that as the default!)
REMEMBER: inn.conf is read into innd only once. After it is changed,
the innd daemon must be shutdown and restarted. (use "ctlinnd shutdown x"
and then run rc.news as root).
If "inews -h" posts a message, smile because most of the battle is over.
------------------------------
Subject: "client" doesn't have the software needed to post.
If the client doesn't have "inews" at all, copy it from the server (if
they are compatible machines) or check the INN installation manual to
find out how to compile just the client programs for a machine. There
is a special gimick included with INN to compile inews for the various
other OS's and versions of Unix without having to compile the entire
INN package.
Since nnpost, Pnews, postnews, and all other news posting software
shouldn't do anything but ask for header information, let you add a
body, and then pipe the whole thing to "inews -h", you can be pretty
certain that if "inews -h" works, your news posting programs will
work. Think again! Post from each of them and make sure they all get
posted. You might find that they access a copy of "inews" that was
part of C news, mini-inews, or heavens knows what.
I highly recommend that people use "find" or "gnufind" to seek out and
replace all old versions of "inews" with symbolic links to the one
"official".
Something like:
gnufind / /usr /usr/local /usr/lib -xdev -follow -name inews\* -print
Then, for every file found, do the following:
mv inews inews.cnews
ln -s /usr/local/bin/inews inews
Now you only have to update /usr/local/bin/inews, rather than
chasing may copies.
"nn" and "nnpost" create a file called "~/.nn/params" right before you
post with tons of useful information. While posting you can shell out
of the editor and view the file. The file is deleted after the message
is posted. I had to view this file while shelled out of my editor to
find which "inews" was being used by "nnpost".
It's also a good idea to check your mail now and then while you are
doing this. Some newsreaders (like "nn" notify you of a posting
problem via mail.
On non-INN systems, "inews" returns pretty quickly. Actually they fork
a process to do the actual posting in the background. When those
"inews" return, you don't know if the post was successful or not.
These "inews"'s have a "-W" option which turns off this forking feature
(i.e. Wait for the post to complete).
INN's "inews" never forks because the wait is never that long. When
"inews" returns you know if the post was successful or not. INN's
"inews" accepts the "-W" option for compatibility.
This may seem obvious, but when posting a test message, consider
including the machine you are posting from and the program you are
using. Even though you may check to see if the message got posted
after every test, this will help you later when you go back to see what
you have done.
------------------------------
Subject: Introduction to the "newsfeeds" file
Outgoing news is controlled by the "newsfeeds" file. The INN 1.2 man
page for this file is a bit complex. The man page in 1.3 (and beyond)
gives better examples. Here's a "cookbook" of examples that should
cover most of your needs. Debugging tips are also included.
Always remember that newsfeeds uses "wildmat" matches, not the
semi-regular expressions that C news uses. This means that if you want
to get comp.foo and the subgroups under it (comp.foo.bar, comp.foo.baz,
etc.) you have to use a statement like:
comp.foo,comp.foo.*
OR
comp.foo*
BUT NOT
comp.foo.*
However, "comp.foo*" will match "comp.foobar", as well as
"comp.foo.bang".
------------------------------
Subject: The ME line in the newsfeeds file.
The "ME" entry is a bit confusing. Be careful when you
read the man page.
Here is the "ME" line that I use in my "newsfeeds" file. I find
it works quite well, but you might want to remove the distributions
that you don't need (i.e. New Jersey). Since my site has clients
reading from all over the world I try to have every distribution I
can find. However, I hear of a new distribution almost daily so this
list is always changing.
ME:!*/\
news,gnu,comp,biz,alt,rec,misc,sci,soc,talk,inet,world,worldwide,all,\
aus,su,uk,york,eunet,na,can,qc,tor,us,usa,mn,oh,chi,ca,ba,tx,pnw,il,ne,\
ny,nyc,phl,bl,nj,warren::
If you want to blindly accept all distributions, try this:
ME:!*::
------------------------------
Subject: How does the "ME" line interact with the other lines?
> I'm still a little confused about the ME line's second field.
The man page as of INN 1.3 is much more clear on this. Basically, the
second field of the "ME" line specifies the default for the rest of the
feeds. Otherwise, it isn't used. The "active" file declares which
newsgroups you accept and don't accept.
Here are some examples:
ME:!*:::
foo:!junk:... --send no newsgroups
ME:*:::
foo:!junk:... --send all newsgroups except junk
ME:!*:::
foo:*,!junk:... --send all newsgroups except junk
By the way, generally you do not want to send "junk" or "control*" to
your neighbors.
------------------------------
Subject: Cookbook example of an outgoing NNTP feed:
This example involves a machine named oddball.mentorg.com, that has an
alias of oddball.sjc.mentorg.com, which should receive all posts (but
control & junk should never be passed on) and not certain
distributions. Add the following line to newsfeeds:
oddball.mentorg.com/oddball.sjc.mentorg.com:*,!control*,!junk/!local,!warren:Tf,Wnm:
Have the user "news" run the following via cron:
3,23,43 * * * * /usr/lib/news/bin/nntpsend >/dev/null 2>&1
(this only needs to be added once. nntpsend refers to a file
called nntpsend.ctl to find out what to do).
Add the following to nntpsend.ctl:
oddball.mentorg.com:oddball.mentorg.com::
Done!
------------------------------
Subject: Cookbook example of an outgoing UUCP feed:
Example: A site named "plts" that can not get the "clari" newsgroups
or distribution "warren".
Add the following to the newsfeeds file:
plts:*,!clari.*,!junk*,!control*/!warren:Tf,Wnb:
Add the following to the cron tab (as user "news"):
0 0-5,16-23 * * 1-5 /usr/lib/news/bin/sendbatch -c plts >/dev/null 2>&1
NOTE: I know that "plts" is unique and won't conflict with
some other site named "plts" because it is registered
in the UUCP Maps.
------------------------------
Subject: Cookbook example of an outgoing UUCP-over-TCP feed:
jerry@strobe.ATC.Olivetti.Com (Jerry Aguirre) writes:
People ask about this like it was something exotic requiring special
setup. Kind of like: "I know how to use a wheel barrow and I know how
to shovel sand but how do I shovel sand in a wheel barrow?"
Step 1: Set up a UUCP/TCP connection between you and the destination
site. How? Read your UUCP documentation. If your, and the
desitination's, UUCP supports UUCP/TCP then it will be documented. If
not then get a better version of UUCP.
The point is to get the UUCP/TCP link working before even thinking
about sending news over it. This is true of any news feed over UUCP;
even dialup. Try using "uucp" to copy some scratch file to the other
end. When you have that working then you are ready for the next step.
The only "gotcha" here that I can think of is that the destination host
may not be accepting UUCP/TCP connections. Before wasting your time
trying to debug do a "telnet destination.host.name uucp" and see what
happens. If the connection is accepted and you see a "login" banner
then it is ready for you. If not then ask the admin of that site to
enable UUCP/TCP. This is typically done by uncommenting it in
/etc/inetd.conf and -HUPing inetd (on REAL versions of Unix).
Step 2. Set up a standard compressed news feed to the UUCP name of the
destination site. How? Read your news documentation. Setting up UUCP
feeds is a standard, documented, procedure. In this FAQ you'll find it
in "Cookbook example of an outgoing UUCP feed". Doing compression is
nothing special, it's part of the procedure you would be doing anyway.
It's either a flag or a slighly different command. The news system has
NO knowledge that this is UUCP/TCP. For all it knows this is a
standard dialup connection. In fact is is possible to have the UUCP
connection fall back to dialup if the TCP connection fails. The news
batching software just doesn't care.
The only variation here I can think of is to make the batch size bigger
than the default. The 50K default was picked back in the days when
modems were 1200 BPS (or even 300). It is no longer appropriate for
todays 9600 BPS or faster connections. Using a bigger batch size cuts
down on dead time in the connection and lets compress do a better job.
I would go to at least 200K batches.
Now maybe it would be nice to have a "cookbook", step by step, set of
instructions on how to do this. But UUCP seems to vary a bit between
different versions so what might work at one place would be useless at
another. And setting up the news feed is going to be different between
the different versions of news (B, C, and INN).
I suggest that if people are having trouble setting up a UUCP/TCP
connection that they post their configuration to the net and ask how it
is done on their versions of Unix and UUCP.
------------------------------
Subject: Testing an outgoing feed (your "newsfeeds" configuration).
Here is a decent game-plan for testing your newsfeeds configuration:
Suppose your site is in New Jersey and you have a distribution called
"mentorg" which should be used by people that want to make sure that
their post will not leave their company (Mentor Graphics). You should
do a test post to "nj.test" with no "Distribution:" header, and with
"Distribution: nj" and "Distribution: mentorg". After posting, do a
"ctlinnd flush ''" and make sure that the /var/spool/news/out.going
files for all your sites did/didn't queue up those three messages as
appropriate.
IMPORTANT: Remember to do a "ctlinnd reload newsfeeds x" command every
time you update your "newsfeeds" file!
Finally, for checking out changes to newsfeeds, I've found "ctlinnd
checkfile" handy. "inncheck" will verify that most of your
configuration is sane.
------------------------------
Subject: Other cron jobs.
Once a night you should run the "news.daily" script which will
expire old articles, run the daily reports, etc. It should run
as "news" and look something like this:
40 23 * * * /usr/lib/news/bin/news.daily delayrm
If you get news feeds via UUCP, you might want to add this cron
job (also as "news") which checks to see if any batches arrived
while innd was down and processes them.
20 * * * * /bin/rnews -U
------------------------------
Subject: Cookbook example setting up NOV ("overchan").
Now that you have your other feeds working, you might want to set up a
NOV feed so that your NOV database is built. Newsreaders use the NOV
database to speed up their queries.
Christophe.Wolfhugel@grasp.insa-lyon.fr (Christophe Wolfhugel) (with
many modifications from Tom Limoncelli) writes:
Step 1: Upgrade to INN 1.4 or higher: Most of the bugs in 1.3 were
related with overchan. In fact, the reason why many people used 1.3
without any problems was due to the fact that they were not using
overchan (and didn't hit on some of the bugs that appeared for SVR4
users, all of which were fixed in 1.4)
Step 2: Make sure INN is working. Get everything else working before
you try to get overchan to work. You'll only confuse yourself.
Step 3: Ponder if you have enough disk space. NOV uses up an
additional 10%-20% of your news spool. This is a good 100 Mb if you
have a full feed. The real space savings come when you delete your
separate databases for trn, nn, and tin and use one unified database.
All serious newsreaders will have NOV support soon.
Step 4: Edit overview.fmt (it's in the $INN/site directory, or you can
edit it where it was installed, in /usr/lib/news ) to include
"Xref:full" as the last line. (i.e. uncomment out the last line).
Step 5: Add this entry to your "newsfeeds" file. overchan gets it's data
from a special feed.
# This feeds header data to NOV:
OVERVIEW!:*:Tc,WO:/usr/local/news/bin/overchan
Read the "newsfeeds" man to make sure you understand what you've
just done.
Step 6: (optional) To create the original database:
(run this as "news")
% /usr/local/news/bin/expireover -a
% /usr/local/news/bin/expireover -s
If you skip this step, access will be slow for articles that came
in before you started "overchan". This is not a problem. You
will get a lot of warnings in your "news.daily" output until
you have received at least one new article in each newsgroup.
[ Note: "a lot of warnings" means one for every newsgroup. This can
make your news.daily report >6000 lines. The lines will all look
like:
overchan cant open clari/local/washington/.overview, No such file or directory
overchan cant open clari/local/sfbay/.overview, No such file or directory
overchan cant open uc/news/.overview, No such file or directory
]
Step 7: Change the invocation of news.daily:
In the crontab file for "news", edit the "news.daily" line to be
something like:
news.daily delayrm expireover
(the expireover is required if you use overchan)
Step 8: Inform your users that you now support "NOV, the News OverView
database" and suggest that people switch to newsreaders that use
newsreaders that are compliant with the Overview format.
Step 9: You are done.
Step 10: In a few weeks, drop support for mthreads, nnmaster, etc.
(assuming you've upgraded to replacements that use NOV)
------------------------------
Subject: How do I use nntplink with INN?
First of all, I don't personally recommend using this program. I feel
that it is a gimick. However, if you decide to join the INN Instant
Propagation Party (INN-IPP), I suggest that you first run the feed using
traditional methods for a month so that you make sure you are used to
INN and make sure that the feed is properly functioning. Once you're
ready, here's a cookbook example of an newsfeeds entry using nntplink.
PLEASE make sure traditional "nntpsend"-style feeds work reliably
before you switch to nntplink.
netcomsv.netcom.com\
:*,!junk/!ParcPlace\
:Tc,Wnm,S1024:/usr/local/news/bin/nntplink -i stdin netcomsv.netcom.com
INN 1.2 users should have an explicit S value (i.e. S1024 or S16384).
Without it innd 1.2 can choke and lose data if the receiver is jammed.
(fixed in INN 1.3).
The latest version of nntplink is available from
shape.mps.ohio-state.edu:/pub/nntplink/3.2pl1.tar.gz.
Ian Phillipps <ian@unipalm.co.uk> notes some criteria for using
nntplink rather than nnptsend:
> (1) If you have more than one backbone feed, you can save a lot of
> bandwidth, without risk, if you use nntplink (less duplication of
> articles over nearly-parallel paths).
> (2) More important, if you have a large number of feeds, nntplink
> permits them to be fed simultaneously with the same articles. No big
> deal, until you think of the what's going on in the pagedaemon and the
> disk cache.
> A "ps uaxr" rarely catches nntplink in the act ("D"), despite my having
> 17 of them last time I counted. Our biggest outgoing newsfeed delivered
> 16398 articles yesterday, using a total of 380 seconds CPU on a Sun
> IPC, and no disk time :-)
------------------------------
Subject: How do I use newsgate with INN?
This assumes you configured "mail2news" to put a distinctive
host-gateway name, like "news-mail-gateway" in your Path: headers.
In /usr/lib/news/newsfeeds:
====================================
##
## NEWS/MAIL GATEWAY
##
tech-gateway/news-mail-gateway\
:ne.nearnet.tech\
:Tp:/usr/lib/newsbin/news2mail \
nearnet-tech nearnet-ops nearnet-tech-request nic.near.net %s
====================================
On the mailing list side, one of the recipients is:
post-nearnet-tech: "|/usr/lib/newsbin/mail2news -n ne.nearnet.tech -o 'NEARnet News/Ma
il Gateway' -d ne"
=====================================================================
OTHER ERROR MESSAGES AND WHAT THEY MEAN
=====================================================================
------------------------------
Subject: ld.so: Undefined symbol: _dbzwritethrough
> Everything compiles correctly, but when I try to test rc.local I get:
>
> hermes# sh /usr/local/etc/rc.news
> ld.so: Undefined symbol: _dbzwritethrough
>
> What am I doing wrong?
This means that you are using a $INN/lib/dbz.c file that hasn't been
patched with the $INN/lib/dbz.pch patch. Apply that patch file to
dbz.c and rebuild libinn.a et al. and things should be copacetic. See
section "5.2 The DBZ package" of the Install.ms document. This might
have happened if you don't have the "patch" program (available from any
FSF/GNU archive).
------------------------------
Subject: Why does my innd often die with the message "Can't sync history,
interrupted system call"
Are you running SunOS? See "Known Problems" section of the
installation manual." To the best of my knowledge, nobody has seen
this problem on any other system.
------------------------------
Subject: syslog message: ME cant sendto CCreader bytes 4 No such file or directory
(Rich Salz replies:) It usually means that some ctlinnd command timed
out and gave up before innd could get around to replying. Always a
problem with datagrams. :-) Usually not a problem in real life
however. In INN1.3, the timeout stuff is handled better so most of
these should go away.
You can ignore the messages, but if it bothers you, edit news.daily and
find this line:
ctlinnd -s -t`wc -l <${ACTIVE}` renumber '' 2>&1
You can rewrite it to be something like this:
COUNT=`wc -l <${ACTIVE}`
ctlinnd -s -t`expr ${COUNT} \* 5` renumber '' 2>&1
------------------------------
Subject: inews says "bad message-id"
If this is a Solaris 2.x system, you didn't delete the lines mentioned
in "SVR4, Solaris 2.x, and SCO ODT 3.0" in part 1 of this FAQ.
------------------------------
Subject: Why do all these "readclose" messages show up in my syslog?
Chris Schmidt <cs@germany.eu.net> says:
The "readclose" message indicates that a remote connection to your
server was not correctly terminated with the server-command "quit".
This can have two reasons. First the line your feed uses to connect to
you might be instable so that the connection drops every now and then.
Solution: either ignore theses messages or find out why the line is
unstable. The second reason for these messages could be a
missconfigured client-program at your feed. This means the program
(e.g nntplink) does close the connection without sending the "quit"
first. If you configure a lower number for the exit-timeout (-e) than
the close-timeout (-C) in nntplink then exactly this will happen.
Solution: ask your feed to fix its nntplink-setup. Let me repeat
that: If you are using "nntplink" your -e value must be higher than
your -C value.
------------------------------
Subject: "File exists writing symlinking article file -- throttling"
QUESTION: I'm running INN 1.4, and the server throttles itself, saying
"File exists writing symlinking article file -- throttling". Why? I
have no clue, other than to note that the message is being emitted
while innd/art.c tries to link a crossposted group.
ANSWER: Innd wrote the article to comp/foo/123 and then tried to
symlink it to alt/bar/128 and found that the symlink failed with errno
== EEXIST. This generally only happens when your active file does not
match your file/directory use. The two most common cases of that are:
Trying to use MMAP on Ultrix
Trying to use MMAP on Linux
Some strange interaction with tind.
If you are using Ultrix or Linux, turn off MMAP. You don't have a choice in
this. The Ultrix mmap() function does something completely different
than the Sun/BSD mmap() function. The Linux function gives you some
of the functionality that Sun/BSD mmap() function has, but not enough.
(The Linux people expect to have it fully up to spec eventually.)
At least one person has reported problems with ICL DRS6000 SVR4 Unix
when using MMAP. Try turning off MMAP if you find problems.
It has been reported that tind writes to the active file and this
confuses innd (innd assumes it is the only process writing to the
active file). If you are using tin, upgrade to the newest version of
tin which can read the overview (NOV) database instead of the "tin"
database.
To fix the active file (which may be corrupted), make sure nobody
else is writing to the active file, then do
ctlinnd renumber ''
to get things synchronized again.
If your history file is corrupt, you should do:
ctlinnd renumber ''
makehistory -buv
ctlinnd renumber ''
(Note: the "makehistory" will take hours to run.)
------------------------------
Subject: "cant fopen <newsgroup>/.thread No such file or directory"
Q: nnrpd logs "cant fopen <newsgroup>/.thread No such file or
directory" hundreds of times a day although I installed trn-3 and
maintain an overview database. Why doesn't trn use overview files
instead of mthreads data?
A: trn-3 tries to open .thread files (or use XTHREAD) first because
$spooldir/db.init still exists. Delete it.
------------------------------
Subject: news.daily reports: "Expire had problems removing articles"
This message tells you that you need to look in the file
${MOST_LOGS}/expire.log to find out what really happened.
On the other hand...
Expire reports this if it goes through the entire expire process and
didn't find any articles to remove. It is normal to get this error the
first few days you are running INN. For example, if the smallest
integer that appears in your expire.conf is a "4", then you're sure to
see this error the first four days you get an news.daily report.
However, those first four days are when you are still learning the
system and it can be very shocking to see the error. "Eeek! Did I do
something wrong?" Nope, news.daily is just telling you that you have a
virginal system.
Rich writes a more technical explanation:
> When using the "delayrm" keyword, news.daily calls expirerm to
> actually remove the articles that expire listed in its "-z" file.
> As distributed, expirerm calls fastrm with the "-e" flag. This
> flag says "exit non-zero if nothing was removed." In the normal
> case, it is an error if expire doesn't find anything to remove.
...and a system being 4 days old isn't the normal case. So you
get the error. Ignore it.
------------------------------
Subject: syslog: ME cant nonblock 15 Operation not supported.
I get the following "syslog" message in /var/adm/messages:
Dec 2 20:40:04 venus innd: ME cant nonblock 15 Operation not supported
Answer: (from paulr@umbc4.umbc.edu (Paul Riddle))
It turns out that this is happening because /usr/spool/news on the
machine running innd is an NFS-mounted filesystem, and innd is trying
to do an FIONBIO on my feed file, which is under /usr/spool/news/out.going.
(tal@warren.mentorg.com adds:)
All news transports (INN, C news, B news) want the spool partition to
be local. Newsreader can read from an NFS mounted partition without
any problems but innd should only see local partitions. NFS has a
blatant disregard for many of the file semantics that are needed for a
good netnews implementation. If you don't agree, please feel free to
prove the authors of B news, C news, and INN wrong. Include source
code. :-)
Systems without unix-domain sockets sometimes see this error. Just
ignore it.
------------------------------
Subject: innd: ME cant update_active control
What does "innd: ME cant update_active control" mean?
Look at your active file. One of the fields is "99999" and has to be
incremented to "100000" but there is no space. Shut down innd
("ctlinnd shutdown x"). Edit your active file to add more leading
zero's to all the numbers. Restart innd.
------------------------------
Subject: syslog message: innxmit[1234]: max connect failed Error 0
John Line <jml4@cus.cam.ac.uk> writes:
If you get syslog messages like "innxmit[1234]: max connect failed
Error 0" when using nntpsend, it probably means you messed up a line in
nntpsend.ctl (specifically, missed out one of the first two fields).
While nntpsend.ctl is an obvious place to look for an nntpsend problem,
there is nothing obvious to link the error message directly to the
problem, because the text "max" is actually something invented by
nntpsend when processing the file, and doesn't exist in nntpsend.ctl.
It means the next-to-last field was null, but was the second field when
it should have been the third!
NB Remember to try inncheck when you have problems like this. I only
just thought of it, after finding the problem the hard way, and it
immediately reported "nntpsend.ctl:18: malformed line."
------------------------------
Subject: Can't open "/usr/local/news/shlock955", Permission denied
This usually means you don't have /usr/local/news owned by "news". The
first time you run "make install" it should set the proper ownership if
you run "make install" as "root".
--
Tom Limoncelli -- tal@warren.mentorg.com (work) -- tal@plts.org (play)
"Psst! Hey, Anthony! Y'know what I | Disclaimer: I do not
like about existing?" "Uh... uh... what?" | speak for Mentor Graphics.
"Possessing a physical extension." -TSA |