The latest version of INN is available at http://www.isc.org/, so you can always grab the source and build your own INN if you really want to. But Linux distributions come with a prebuilt INN that you can just install and use. For example, if you ask the Red Hat installer to include INN, Linux will boot up with a news server running and ready for use.
There are a lot more moving parts in INN than
you’ll need to run local discussions. It’s a complex
beast and has grown more so over time. In addition to the server
itself, innd
, there are:
inndstart
, which launches the server;
nnrpd
, which is started once per connection
to handle conversations between newsreaders and the main server;
innwatch, which monitors the server; and a handful
of other helpers. There are also news-related
crontab
entries for scheduled replication and
expiration tasks.
If you’re setting up a Usenet node, you’ll need to understand and work with many of INN ’s components. To find out how, see O’Reilly & Associates’ Managing Usenet by Henry Spencer and David Lawrence. For light-duty local conferencing, though, you don’t need to worry about most of that machinery. I’ll focus here on just the minimum setup.
Start by editing the configuration file called
inn.conf—on my Red Hat system, it’s
/etc/news/inn.conf—and name your company
or department in the organization: field. If you
don’t, all messages posted to your server will carry the
header:
Organization: A poorly installed InterNetNews site
In the same file, add your fully qualified domain name (e.g.
udell.roninhouse.com) to the
pathname: field.
Then edit expire.ctl, the expiration policy. The
default setup includes the line:
*:A:1:10:never
That says: “Keep all (A) articles from any site (*) for one (1) to ten (10) days, and never purge articles.” To shut off expiration, change the line to:
*:A:never:never:never
To verify that INN
is working, try connecting to it using your newsreader or just by
pointing telnet at port 119. If you don’t
get a response, look for clues in the system
message
log—/var/log/messages on my system. Then
check the INN
FAQ files. The section called
“Reasons why INN isn’t starting”
covers the most common cases. These FAQ files are on the Red Hat CD,
but if you don’t have them locally, check the Usenet group
news.nntp.software or search the Web. One of
the most common problems is that the server, running as user
news, can’t access a file that
you’ve edited and rewritten while logged in as
root. You can run inncheck to
find these kinds of permission glitches. If that was indeed the
problem, you can use:
$ chown news:news filename
to restablish news as the owner and group for
filename.
Once you’ve got INN up and running, use the ctlinnd command to create your own newsgroups, for example:
$ ctlinnd newgroup public Ok $ ctlinnd newgroup watercooler Ok $ ctlinnd newgroup thinktank Ok $ ctlinnd newgroup saleslounge Ok
The names of these groups imply their intended scopes: public for discussion involving Ronin Group staff and the outside world; watercooler for internal but companywide discussion; thinktank for exclusive use by analysts; saleslounge for the sales force.
You enforce
scoping in the configuration file called
nnrp.access, which might look like this:
*:RP:analyst:bigideas:thinktank.*,watercooler.*,public.* *:RP:sales:bigbucks:saleslounge.*,watercooler.*,public.* *:RP:::public.*
The five fields of an nnrp.access entry are:
permitted hosts, permissions (Read, Post), username, password, and
affected groups. The first line of this example says:
“Newsreaders connecting from any host (*) can read and post
(RP) to thinktank, watercooler and public, after authenticating as user
analyst and typing the password
bigideas.” The second line is like the
first, but the user is sales, the password is
bigbucks, and the exclusive group is saleslounge rather than thinktank. The third line says:
“Anybody (*) can read and post (RP), without authenticating, in
the public group.” The
rules have to be ordered from most restrictive to least restrictive;
that’s why the public rule
comes last.
nnrp.access can be tricky, so it’s a good
idea to verify what each class of user can do. The
telnet transcript shown in Example 13.1 shows that only the public group is open to nonuthenticated
users. After authenticating as user analyst,
both watercooler (the companywide
group) and thinktank (the
analysts-only group) are available.
Example 13-1. Testing INN Access Controls
telnet localhost 119 200 InterNetNews server INN 1.7.2 08-Dec-1997 ready mode reader 200 InterNetNews NNRP server INN 1.7.2 08-Dec-1997 ready (posting ok). list 215 Newsgroups in form "group high low flags". public 0000000001 0000000001 y . group thinktank 411 No such group authinfo user analyst 381 PASS required authinfo pass bigideas 281 Ok list 215 Newsgroups in form "group high low flags". public 0000000001 0000000001 y watercooler 0000000000 0000000001 y thinktank 0000000000 0000000001 y
That’s the basic setup for INN. If
you’re going to deploy INN-based discussions
on an Internet-visible server, you should look carefully at how your
version of INN works and consider disabling
unneeded—and potentially dangerous—behavior. For example,
the version of INN shown in these examples
automatically starts up a replication daemon called
innfeed
, governed by a configuration file
(innfeed.conf) that names some default
replication partners. To be on the safe side and ensure that nothing
will leak from your server to the outside world, it’s probably
a good idea to shut down that daemon and/or remove those replication
partners from the configuration file.
If your discussion service is isolated on a LAN or intranet, there’s less reason to worry about information leakage. In this environment, a Linux-based INN server can transform an aging PC from a boat anchor into a really useful collaborative resource.