install.ms.2

早期freebsd实现

.PP
Make sure that you configure \fInntpd\fP so that it is using DBZ, and have
it feed each individual article to \fIinews\fP; don't use the \&``batched
input'' option.
It should also be set up so that it acts as if it is running under
\fIinetd\fP.
You should also make sure that \fIinetd\fP does nothing with the NNTP
port, number 119.
.NH 1
NNTP-based newsreaders
.PP
If you already have your NNTP-using newsreaders installed and running,
you do not have to do anything.
This includes \fIxvnews\fP, \fIxrn\fP, \fIrrn\fP and so on.
INN implements the standard NNTP protocol, with some extensions.
INN does not provide the extensions used by \fItrn\fP, \fItin\fP or
other newsreaders.
(You can enable the \fItrn\fP ``XTHREADS'' by modifing \fInnrpd/nnrpd.h\fP;
change the ``DONT_DO_XTHREAD'' to ``DO_DO_XTHREAD'' and verify the other
macros in that section.
INN will not implement all the different indexing systems because the
right solution is to have a generic interface that all readers can use.)
.PP
For administrative convenience, however, you might wish to have all your
newsreaders use the INN library and configuration files to talk to the server.
The next section describes how to do that for \fIrn\fP.
It is provided as an example, to help you convert other programs you
might have.
INN does not provide, nor fully support, any newsreaders.
.NH 1
Remote rn
.PP
The ``remote'' version of \fIrn\fP (also called \fIrrn\fP) uses a set of
routines in the NNTP ``clientlib'' file.
INN can emulate these routines; see \fIdoc/clientlib.3\fP.
If you need to build \fIrn\fP for client machines that don't have the
entire INN distribution available, use the \fIMakeLib\fP script to
build a distribution directory of the necessary routines.
Use this script the same way you use the \fIMakeInews\fP script.
.PP
\fIRn\fP, \fIrrn\fP, and \fItrn\fP are moving targets so these instructions
may be out of date.
The maintainers have agreed to officially support INN, however, which is
a good thing.
.PP
There are two ways to build \fIrn\fP so that it uses the INN library.
If you don't have the NNTP distribution installed you will have to use
the first way.
.PP
The first way is to apply a patch to the latest \fIrn\fP \fIConfigure\fP
script and then execute it and rebuild the program.
To do this, type the following:
.DS
cd \fIrn_source\fP
patch <$inn/frontends/rn.pch
\&./Configure
make
.DE
At some point, \fIConfigure\fP will ask you if you want to use the
InterNetNews library; answer \fIyes\fP.
You can then use either the full sources, or a special library that
contains just the needed header and sources files.
Tell \fIConfigure\fP the appropriate pathnames, and then proceed
with the rest of the \fIrn\fP installation.
.PP
The second way is to edit a couple of files after you have run \fIConfigure\fP
and set it up to build the remote rn.
First, replace the \fIrn\fP file \fIserver.h\fP with the INN file
\fIinclude/myserver.h\fP.
The next step is to edit the \fIrn\fP Makefile to remove the ``clientlib''
file from the source and object file lists.
This can probably be done by commenting out the definitions of the
\fIc5\fP and \fIobj5\fP variables.
You must also edit the Makefile to add the INN library to the list of
libraries that are linked in.
This can probably be done by editing the line that defines the \fIlibs\fP
variable so that the full pathname to \fIlibinn.a\fP is the first item
after the equal sign.
.NH 1
Removing the Other Stuff
.PP
The names below assume a ``standard'' news setup; things might be different
on your machine.
Also, many programs have alternate names and links; make sure you chase down
and remove \fBall\fP of them.
.PP
You might find it easiest to rename your \fI/usr/lib/news\fP (and
\fI/usr/lib/newsbin\fP) directories to something else and start with a
clean slate, copying over the files as they are needed.
Make \fBsure\fP that your news processing is completely stopped before
you begin this process.
That includes any \fIcron\fP jobs that may be running.
.PP
The \fI/usr/lib/news\fP directory can become cluttered \(em that's why
C News split everything up into separate directories.
The following files are compatible with C News and B2.11 News, and should be
\fIkept\fP:
.DS
.ta 1.5i
active	active.times
.DE
If you are running C News keep these files, otherwise delete them and use
\fImakehistory\fP to rebuild them:
.DS
history
history.dir
history.pag
.DE
.PP
\fIRn\fP does not have to be modified so leave this directory alone (or
copy it back if you moved your original):
.DS
/usr/local/lib/rn
.DE
If you set up \fIrn\fP to use the INN library, remove this file:
.DS
/usr/local/lib/rn/server
.DE
.PP
The input system is completely replaced.
Remove the following programs and their manpages:
.DS
/bin/cunbatch
/bin/inews, /usr/lib/news/inews, etc...
/bin/rnews, /usr/bin/rnews, etc...
/usr/lib/news/rnews.stall
/etc/nntpd, /usr/etc/nntpd, etc...
.DE
Also remove the following directories and everything within them:
.DS
/usr/lib/news/bin/input
/usr/lib/news/bin/relay
/usr/lib/news/bin/ctl
/usr/lib/news/bin/inject
/usr/lib/news/nntp (mkgrdates, nntp_access, shlock, etc)
.DE
.PP
The transmission facility is completely replaced.
You may keep your current feed subsystem if you want to, but it will require
some changes to make sure that batchfiles are properly flushed; see the
\fIsend-xxx\fP scripts for examples.
Remove these files and programs:
.DS
/usr/lib/news/batchparms
/usr/man/man8/newsbatch.8
.DE
Remove the following directory and everything within it:
.DS
/usr/lib/news/bin/batch
.DE
You can continue to use \fInntplink\fP, \fInewsxd\fP, and the like, subject
to the caveat just mentioned.
.PP
Article expiration and maintenance of the history and active files is
completely replaced.
Remove this file:
.DS
/usr/lib/news/explist
.DE
Remove the following directories and everything within them:
.DS
/usr/lib/news/bin/expire
/usr/lib/news/bin/maint
.DE
If you do not remove the \fIexpire\fP directory, you will probably have
problems installing INN's \fIexpire\fP, which is a program that often
has the same name as the C News directory.
.PP
The following programs in \fI/usr/lib/newsbin\fP are not needed and can be
deleted.
Keeping them around is harmless, and if you find them useful don't delete
them:
.DS
.ta 1.5i
canonhdr	newshostname
ctime	newslock
dbz	queuelen
getabsdate	sizeof
getdate	spacefor
gngp
.DE
Note that \fIctime\fP, \fIgetabsdate\fP, and \fIgetdate\fP are replaced by
\fIconvdate\fP.
More importantly, \fInewslock\fP does not lock \fIinnd\fP; it is best
to remove it.
.PP
The following files are replaced by INN configuration files.
You should delete them, just to avoid confusion:
.DS
.ta 1.5i
mailname	sys
mailpaths	whoami
organization
.DE
If you have other software that uses them (except \fIsys\fP),
you can keep them.
The following will be rebuilt (or overwritten) by \fIinnd\fP and
\fIscanlogs\fP so you should remove them:
.DS
.ta 1.5i
errlog	log
.DE
.PP
In addition to the manpages for the programs listed above, the following
manual pages should be removed:
.DS
.ta 1.5i
active.times.5	newsmail.8
expire.8	newsmaint.8
mkgrdates.8c	nntpd.8c
news.5	nntpxmit.1
newsaux.8
.DE
.PP
Any other files and directories can probably also be discarded.
.\"
.bp
.SH
Appendix III:  Setting up different feeds
.PP
This section gives some notes and advice on how to set up different
types of outgoing news feeds.
It duplicates and expands upon the information in the manual pages.
.NH 0
Ihave/sendme feed
.PP
For a standard UUCP newsfeed, a site batches up all the articles it
receives and sends them to the downstream site, which unpacks the batch
and processes each article.  If the downstream site has multiple feeds,
however, it might want to ``filter'' the articles that get sent.  This is
done by having the feeding site send a list of Message-ID's as an
``ihave'' control message.  The receiving site examines the list to see
which articles it does not currently have, and sends it back to the
upstream site as a ``sendme'' message.  The original site receives this
message and prepares a batch in the standard way.
.PP
Note that this has nothing to do with NNTP.  It is a specialized type of
batched feed that is not used very often.
To do ihave/sendme with a site named remote, the local site must either
have a ``to.remote'' newsgroup or be compiled with MERGE_TO_GROUPS set to
\&``DO''
.PP
Accepting an ihave/sendme feed is easy.  Suppose an ``ihave'' message is
received from a site named remote.  When \fIinnd\fP processes the message
it will invoke the appropriate control script,
\fI/usr/local/news/bin/control/ihave\fP.  The script will filter the body
using \fIgrephistory\fP, creating a list of Message-ID's not found in the
\fIhistory\fP database.  It uses this output to create a ``sendme''
control article which is posted to the ``to.remote'' newsgroup using
\fIinews\fP.  This article will then be queued and sent to remote in the
normal way.  The remote site will then send the desired articles back.
.PP
Providing an ihave/sendme feed is a bit more complicated.  First, you must
create two entries in your \fInewsfeeds\fP file.  The first should be
named remote.ihave.  Make this a ``Tf,Wm'' feed that contains the remote's
subscription list.  This entry results in a a file that accumulates the
Message-ID's of all articles that remote might want.  The other entry
should be named remote.  This should be a ``Tf,Wn'' feed that only
subscribes to the ``to.remote'' newsgroup.
(Actually, if you feed some groups as a standard feed, you can put them
on the remote entry, rather then the remote.ihave entry.)
.PP
The next step is to have the ``ihave'' control messages sent out.  To do
this, review the \fIsend-ihave\fP script and make sure it is invoked as
needed (usually out of \fIcron\fP).  It splits the batchfile from the
remote.ihave \fInewsfeeds\fP entry and posts ``ihave'' control messages
into the ``to.remote'' newsgroup.  These messages will get queued for the
remote entry.
.PP
The next step is to send out any articles queued for the remote entry.
Treat this as a standard UUCP feed, invoking \fIsend-uucp\fP or
\fIsendbatch\fP as appropriate, typically a few minutes after
\fIsend-ihave\fP runs.
.PP
When the remote site receives the ``ihave'' message it will filter it and
send back a ``sendme'' message whose body is the list of desired
Message-ID's.  When \fIinnd\fP processes this message it will invoke the
appropriate control script, \fI/usr/local/news/bin/control/sendme\fP.  This
script will call \fIgrephistory\fP to turn the list into a list of files
appended to the batchfile for remote.  Examine this script (the filename
should probably match the filename in the remote \fInewsfeeds\fP entry)
and send the batch to the remote site (using \fIbatcher\fP, often called by
\fIsend-uucp\fP or \fIsendbatch\fP).
.NH 1
Feeding a large number of sites
.PP
\fIInnd\fP tries to keep as many batchfiles open for as long as possible.
It will normally open as many as it can, using all the available
descriptors minus a fixed number for internal use (log files, etc.).
You can explicitly set the number of files to open by using the ``\-o'' flag.
.PP
If you have more outgoing feeds than available descriptors, \fIinnd\fP
will recycle the files on a a ``least recently used'' basis.
If most of your feeds get most articles (or you have vastly more feeds
then available descriptors), this will lead to ``file thrashing,'' closing
and opening all the excess feeds on each article.
To reduce this, you can have \fIinnd\fP use an internal buffer for a site
by using the ``I'' parameter in the \fInewsfeeds\fP file.
If a site does not have its batchfile open, the server will not try to open
it until there is more data to be written then will fit in the buffer.
For example, suppose \fIinnd\fP was started with ``\-o10'' and there
are 12 sites, all with ``I512'' in their \fInewsfeeds\fP entry.
If each article generates 50 bytes (a pathname and a Message-ID), then