InterNetNews のインストール Rich $alz 改編: James Brister インターネットソフトウェアコンソーシアム E-mail は <inn@isc.org> 宛に送ってください このドキュメントでは InterNetNews をどのようにインストールし、 セットアップするかを説明します。 そのためにまず、USENET とネットワークについての知識を身に付けておかなければいけません。 最初のセクションではこれらについて触れられたドキュメントを示します。 付録 IV の``USENET あるいは NNTP のはじめてのインストール''では初心者のために USENET のインストールの概要を説明します。

このドキュメントでは関連するプログラムが何を行い、 どのように使用すべきかについても説明します。 パブリックなソフトウェアを make したり、維持するようなエキスパートの方であっても、 INN をインストールする場合には、このドキュメントは読んでください。

すべての作業をする前に知っておかなければいけないこと

InterNetNews は INN と省略され、その 3 文字の アイエヌエヌ と呼ばれます。 このシステムでは、USENET のほとんどのトラフィックに NNTP を使用している大規模な システム上での USENET の配送と expire システムを提供します。

このドキュメントは USENET の解説書ではありません。 USENET についての経験があまりないのであれば、 Using UUCP and Usenet、ISBN 0-937175-10-2 を読むべきです。 また、Managing UUCP and Usenet、ISBN 0-937175-48-X (最新版を参照してください)を読むのもよいかもしれません。 いずれの書籍も O'Reilly & Associates から出版されています。 問い合わせは <nuts@ora.com> に対して行ってください。 Smoot Carl-Mitchell と John S. Quarterman による The Internet Connection: A Guide to Connectivity and Configuration、 ISBN 0-201-54237-4 には INN の章があります。 これは、Addison-Wesley から出版され、1994 年の初頭あるいは 1993 年の年末には入手可能となっています。

ネットワークの知識についてはまず、BSD での TCP/IP について知っておかなければいけません — 少なくともホスト名と ドット形式の IP アドレスについては慣れ親しんでいなければいけません。 設定についての問題に直面するような場合には、 でのストリーム形式あるいはデータグラム形式のソケット等について知っておかなければいけません。 システムベンダからのドキュメントに加えて、 Programmer's Manual: Supplementary Documents 1 での二つの IPC の解説を読むのもよいかもしれません。 これのコピーは USENIX Association から有料で入手することができます。 問い合わせは <office@usenix.org> に対して行ってください。

InterNetNews にとって二つの重要な RFC があります。 RFC 1036 では USENET での記事のフォーマットについて説明しています。 これは不完全で、いくつか間違いがありますが、 これが現時点での唯一の正式なドキュメントとなっています。 RFC 977 では NNTP(Network News Transfer Protocol)を定義しています。 RFC は nnsc.nsf.net での anonymous FTP 等いくつかのサイトで利用可能となっています。 このサイトでは、rfc というディレクトリ配下で見つけることができます。 RFC 977 は現在改版中です。 1036 で改版するとすればほとんど``定義の厳密化''をすることになるでしょう。 しかし、INN ではすでに 1036 の厳密な解釈を行っているため、この改版は InterNetNews におそらくそれほど影響を与えることにはならないでしょう。 977 の改版では現在実際に使用されている特徴や機能を正式に追加することになります。 INN ではそれらすべてを提供しているわけではないため、多少影響を受けることになります。

InterNetNews は他のニュースソフトウェアとは異なる方式の実装がされています。 で使用されている他の USENET システムは Bnews 2.11 と Cnews です。 ただし、いずれも個別の NNTP の実装が必要です。 そのうちの一つは ``NNTP'' と呼ばれています。 このように呼ぶことが混乱(sendmail を ``SMTP'' とは呼びません)の元となるため、 ここでは``リファレンス実装''としておきます。 通常はこのような他のシステムについて知っておく必要はありませんが、 興味があるのであれば、次に正式なサイトを示しておきますので参考にしてください。
パッケージ    ホスト    ディレクトリ
Cnews    ftp.cs.toronto.edu    pub/c-news
B2.11    ftp.uu.net    news/bnews-2.11
nntp    ftp.academ.com    public/nntp
Cnews で配布されている doc/biblio、doc/problems および doc/rfcerrata というファイルは読む価値があることに気付かれるかもしれません。 一つ目のファイルは用語集、二つ目のファイルは Cnews のポーティングについての 問題(特に DBZ の章を参照してください。 シェルのコメントについてはほとんど無視してよいでしょう)を説明し、 三つ目のファイルは RFC 1036 のいくつかの技術的な間違いや根本的な間違いについて列記しています。

ここから先でのコマンドでの $inn は InterNetNews のソース構造のトップディレクトリを省略したものとします。

INN は自由に再配布可能な B2.11、Cnews および NNTP のソース無しでは作り上げることはできませんでした。 特に、Rick Adams、Geoff Collyer、Henry Spencer、Stan Barber、Erik Fair、 Brian Kantor、Phil Lapsley には感謝しています。 UUNET Technologies の資金的な援助にも非常に感謝しています。 ベータテストサイトからもはかり知れないフィードバックをいただきました。 とにかく使ってみたい場合は

ここから先の指示にしたがわない場合は次のように行ってください。 cd $inn/config cp config.dist config.data chmod 644 config.data vi config.data (あるいは emacs か他のエディタ) cd .. make world mkdir -p /usr/news /var/news /var/news/spool make install そして付録を読んでください。 何か問題があれば、ここから先を引続き読み進めてください。 配布内容

INN のソースは次のようなディレクトリに分けられています。

frontends
    記事を核となるサーバに送り、サーバを制御するプログラム群です。

innd
    核となる NNTP サーバです。 このサーバはコネクションを受け、記事を受け、配送先に送るために必要な処理を行います。

backends
    他のサイトへ記事を送るためのプログラム群です。

expire
    記事ファイルを消去したり、history データベースをそれに合わせて整えたりするプログラム群です。

nnrpd
    (記事の一括転送とは異なり)記事の読み書きを行うクライアント用の NNTP サーバです。

lib 上記すべてで使用するライブラリルーチンです。

include
    上記すべてで使用するヘッダファイルです。

dbz DBZ データベースパッケージです。

syslog
    INN で必要な syslog 機能が提供されていないシステムで syslog を使用するためのルーチンです。

配布されているものには次のようなディレクトリもあります。

samples
    スクリプトや設定ファイルのプロトタイプで、site にインストールする前に編集することもできます。

site
    samples ディレクトリにあるファイルを編集したものを保持します。

doc 上記すべての man ページです。

config
    各サイトに適した設定を行うツールがあります。

sample-configs
    さまざまなシステム用の設定データ例です。

authprogs
    nnrpd で使用できる認証用のプログラム例です。

contrib
    contribute された INN で有用となるプログラム群です。

obsolete
    前のバージョンで使用していましたが、今は使用しなくなったスクリプトです。

FAQ news.software.{b,nntp} に定期的にポストされる INN についての FAQ です。

最後に、トップディレクトリには次のような多くのファイルがあります。

README
    INN の基本的な紹介を行っています。

COPYRIGHT
    配布内容のコピーライト表示です。 適切に提供元が明らかにされるならば、InterNetNews は自由に再配布できます。

MANIFEST
    配布している各ファイルを一行程で説明しています。

BUILD
    対話的に INN を設定、作成、インストールするスクリプトです。

makedirs.sh
    /usr/news、/var/news および /var/news/spool 等のトップレベルのものを除く INN で使用するディレクトリを作成するためのスクリプトです。 プログラムをインストールするための書き込み権を有する限り、 inndstart を root の setuid 付きでインストールする以外は、 これらのトップディレクトリの作成は root でインストールしなければいけない唯一の箇所です。 この場合、root としてインストールする方が楽となるでしょう。

Makefile
    他の Makefile を呼んだり、プログラムやスクリプトの make を行います。

Install.ms
    このドキュメント自身です。 ``-ms'' を使用できる nroff あるいは troff のマクロパッケージが必要です。

MakeLib
    rn で必要なリファレンス実装の ``clientlib'' ルーチンと置き換わるディレクトリを作成するスクリプトです。

MakeInews
    クライアント配布用の inews のディレクトリを作成するスクリプトです。

MakeRnews
    クライアント配布用の rnews のディレクトリを作成するスクリプトです。

sedf.xxx
    lint の出力結果のフィルタを行う sed スクリプト群です。

README.perl_hook
    PERL による記事のフィルタについての説明を行っています。

README.tcl_hook
    TCL による記事のフィルタについての説明を行っています。

README.pgp
    PGP によるコントロールメッセージの認証についての説明を行っています。

CONTRIBUTORS
    INN に contribute していただいた方達です。

HISTORY
    INN 1.4 までの履歴です。

iftrue.sh
    test(1) を行うためのスクリプトです。

installit.sh
    INN で使用するプログラムやスクリプトや設定ファイルをインストールするためのスクリプトです。

PGPKEYS
    PGP による認証を行うコントロールメッセージで使用する公開キーです。 システムの構築

INN を順を追って作成します。 最初に、subst プログラムを作成します。 次に、key と value の対から構成される設定ファイルを作成します。 subst はこのファイルを読み込み、これを使用して INN で配布されている特定のファイル群を編集します。 (変更されるファイルのほとんどは Makefile かヘッダファイルです。) そして、ライブラリを作成します。 通常、lint の結果を確認することはいくつかの基本的な設定パラメータが正しく設定されているかどうかを確認するための良い方法となります。 次に、すべてのプログラムをコンパイル(そして lint)を行います。 その後、プログラムをインストールし、INN でのデータファイルを設定します。

設定処理はあえて対話的とはなっていません。 例えば、rn での設定スクリプトを観察するのは面白いのですが、 このスクリプトでは、grep が終了ステータスを返すかどうかのようなあまり本質的でないことを処理し過ぎています。 また、パラメータを一つでも変更してのプログラムの再作成をすることも難しくなっています。 (Cnews にもこれと同じ問題があります。)

INN での方式にもそのような欠点を抱えています。 ほぼすべての設定データが一つのヘッダファイル内にあるため、 変更を行った場合のほとんどで、すべての再コンパイルが必要となります。 subst の作成

INN では Cnews での subst というプログラムを使用して、設定を自動化しています。 subst を使用すると、 設定ファイルによってファイルを安全に編集するという非常に賢明な方法となります。 詳細については、subst(1) を参照してください。 subst を使用し、再配布することを許可していただいた Henry Spencer と Geoff Collyer に感謝します。

作成した subst をテストするために config.dist を設定ファイルとして使用することにしてみます。 (設定ファイルを配布してあるファイルに常に置き換え、 オリジナルのものを保存しておくために個別に make を使用することもできます。)

Cnews での subst はシェルスクリプトで sed を使用して編集を行います。 ところが、INN の設定ファイルは、あるバージョンの sed にとっては大き過ぎて処理できないことがあります。 最初のステップとしては sed が問題無く動くかどうかを確認することです。 この確認を行うには、次のようにしてください。 cd $inn/config cp config.dist config.data make sedtest sed で ``too much command text'' のようなエラーメッセージが出力される(あるいはコアダンプする)場合、 二つの選択肢があります。 (ベンダに対してもクレームすべきです。) 一つ目の選択肢は、FSF から配布されているような別の sed を使用することです。 これを使用する場合、config/Makefile を編集し、変数 SED の定義の行を変更してください。 Cnews でのスクリプトを使用する場合、次のようにしてください。 cd $inn/config make sh

もう一つの選択肢は C で記述された subst を使用することです。 この subst はシェルスクリプトのものよりもはるかに処理が速いため、 この方式を使用したくなるでしょう。 これを使用する場合、次のようにしてください。 cd $inn/config cp config.dist config.data make c quiet コンパイルエラーが発生した場合、config/subst.c を編集する必要があるでしょう。 初期のバージョンの AFS を使用している場合、USE_RENAME というマクロを有効にするためにこのファイルを編集しなければいけません。 それ以外の変更が必要な場合には、連絡してください。

subst はソースファイルを変更するため、 変更されるすべてのファイルのバックアップをしておきたくなるかもしれません。 これは、config ディレクトリで ``make backup'' とすることにより可能です。 これにより、変更されることになるすべてのファイルから構成される、ローカルな tar ファイルを作成します。 ``make restore'' により tar ファイルを元に戻します。 (subst による変更は安全に行われるため、このステップはオプションとなっています。) config.data の編集

一度 subst を実行させていれば、 次のステップは設定パラメータを設定することになります。 これが INN のインストールで最も難しい部分となります。 でも、混乱はしないでください。 このファイルには多くの設定パラメータがありますが、 その多くが非常に容易に決定できるものとなっています。 この作業を行うためには、sample-configs ディレクトリから使用するシステムに合ったものを config/config.data にコピーしてください。 このディレクトリに使用するシステムに合ったものがなければ、 配布されているもののマスタ版である config/config.dist をローカルなものである config/config.data にコピーしなければいけません。 INN ではデフォルトで BSD/OS 2.1 でコンパイルし実行されるものとなるように配布されています。

設定ファイルは次のようなセクションに分かれています。 MAKE CONFIG PARAMETERS LOGGING LEVELS OWNERSHIPS AND FILE MODES C LIBRARY DIFFERENCES C LIBRARY OMISSIONS MISCELLANEOUS CONFIG DATA PATHS TO COMMON PROGRAMS PATHS RELATED TO THE SPOOL DIRECTORY EXECUTION PATHS FOR INND AND RNEWS SOCKETS CREATED BY INND OR CLIENTS LOG AND CONFIG FILES INNWATCH CONFIGURATION TCL Configuration PGP Configuration Local Configuration Actsync Configuration Perl Configuration ここから先のセクションを読み進めながら config.data を変更しておくべきでしょう。 また、このファイルを編集する前に変更点を紙に書いておいてもよいでしょう。

このファイルのフォーマットは非常に厳密なものとなっています。 ``#'' で始まる行はコメント行です。 その他の行は次のようなフォーマットとなっていなければいけません。 parameter <一つ以上のタブ> value ``value'' が無くても ``<一つ以上のタブ>'' は必要です。 value の前後には引用記号を使用してはいけません — 引用をしてしまうと、 大体はシステムのコンパイル時にシンタックスエラーとなります。 以下の説明では value の始まりと終りを示すためのみに引用を行います。 MAKE CONFIG PARAMETERS

このセクションでは基本的に C コンパイラへのパスや必要な特別なライブラリやコマンドラインでのオプションを指定するために使用します。 例えば、CC 行には gcc -Wall を付けることができます。 -I オプションが必要な場合、DEFS 行に付けてください。 INN では非常に多くの register 宣言を使用します。 使用するコンパイラが非常に優れていれば、DEFS 行に -Dregister= を追加し、INN での宣言を無視させることもできます。

DBZ パッケージについては、データベースが mmap されるようにコンパイルすることができます。 このような処理にしたい場合、システムに mmap システムコールがあれば、 DBZCFLAGS パラメータに ``-DMMAP'' を追加してください。

(例えば、-lnet のように)他にライブラリをリンクする必要がある場合、 LIBS 行にこれを付けてください。

Makefile では通常すべての lint の出力を sed スクリプトを通してフィルタを行います。 結果が非常に気になるのであれば、LINTFILTER は cat にしてください。 lint の出力結果が次のように複数行形式となっていれば、 value type declared inconsistently
    exit llib-lc(297) :: test.c(7) function returns value which is always ignored
    printf LINTFILTER を ``sedf.sysv'' にしてください。

lib ディレクトリでは lint ライブラリも作成し、 他のプログラムがこのライブラリルーチンを問題なく使用できるようにすることができます。 (lib/Makefile と lib/makellib.sh で使用される)LINTLIBSTYLE パラメータは lint ライブラリがどのように作成されるのかを制御します。 lint で ``-C'' オプションが使用できる場合、``BSD'' としてください。 ライブラリを作成するために ``-o'' オプションが必要な場合、``SYSV'' としてください。 これらのいずれも使用できない場合、``NONE'' としてください。 これにより、空ファイルを作成し、他の Makefile でエラーとならないようになっています。 四つ目の方法が見つかれば、教えてください。

不幸なことに lint が使えないシステムがあります。 この場合はベンダにクレームを付け、塩をまいてやってください。 lint の出力で ``struct _DDHANDLE'' が未定義だという warning となることがあるかもしれません。 これは無視してもよくて、ベンダに BSD での lint の ``-z'' オプションをサポートするように要求してください。 また、HAVE_UNISTD を ``DO'' にした場合、include/clibrary.h での関数のプロトタイプ宣言と合っていないという warning となるかもしれません。 これも無視してもよくて、INN のヘッダファイルから関連する行を削除しても構いません。

(doc/Makefile と doc/putman.sh で使用する) MANPAGESTYLE パラメータでは man ページをパブリックなディレクトリにどのようにインストールするかを制御し、 MANx パラメータではどこのディレクトリにインストールするかを指定します。 man ページをインストールしたくない場合、MANPAGESTYLE は NONE としてください。 LOGGING LEVELS

INN では通常の syslog を使用して、level と category にメッセージを分けます。 <syslog.h> ヘッダの ``LOG_NEWS'' を探し、syslog(3) を確認して、 openlog が三つの引数を取ることを確認してください。 このようになっていなければ、ライブラリルーチンを使用し、syslog ディレクトリにあるサーバを使用する必要があります。 これについては後で説明します。

syslog(3) で説明している level の違いは難しいため、INN では実際に使用している次のような四つのレベルの名前を用います。
L_FATAL	致命的なエラーで終了します
L_ERROR	注意が必要なエラーです
L_NOTICE	処理情報で、特別な処理は不要です
L_DEBUG	プロトコルのトレースやその他のデバッグメッセージです
syslog.conf(5) ファイルをどのように設定するかによって、 このセクションでの L_xxx パラメータを変更する必要があるかもしれません。

scanlogs スクリプトでは上記の最初の三つの category がそれぞれ別のファイルに出力されているものとしています。 詳細については、newslog(5)、newslog(8) および syslog/syslog.conf を参照してください。 LOGGING については ``LOG AND CONFIG FILES'' のセクションでより詳細に説明します。 OWNERSHIPS AND FILE MODES

NNTP サーバは NNTP ポートを使用しなければいけません。 これはポート番号 119 で、root の権限が必要です。 INN において、root 権限を必要とするのはこの部分だけです。 それ以外のすべてのプログラムは NEWSUSER と NEWSGROUP パラメータで指定する別のユーザ ID とグループ ID で動作することができます。 ニュースの管理処理のほとんどは NEWSUSER というユーザで行わなければいけません(後述の ``SOCKETS CREATED BY INND OR CLIENTS'' のセクションの説明を参照してください)。 さらに、inews では NEWSUSER ユーザあるいは NEWSGROUP グループのユーザのみ cancel 以外のコントロールメッセージをポストできます。

(おもにコントロールメッセージのスクリプトや毎日のメンテナンススクリプトのように) INN スクリプトにはニュース管理者に E-mail を送る必要のあるものがあります。 NEWSMASTER パラメータでは正しい E-mail アドレスを指定します。 これはほとんどの場合、ユーザ ID が NEWSUSER のアカウントのログイン名となっています。 正しいアドレスへフォワードする場合は、alias を使用してください。

Path ヘッダを E-mail のリプライ用のアドレスを作成するために使用しているサイトがいくつかあります。 これまで Path ヘッダを使用することは保証されていなくて、INN でも Path による有効なアドレスが作成されないようにしてこのような慣習を無くすようにしています。 PATHMASTER パラメータでは inews が Path ヘッダの最後に付ける内容を指定します。 このような慣習により、多くのメールを受け取っていて、NEWSMASTER のメールボックスが混乱していれば、メッセージを拒否したり、捨てるために alias で変更したくなっていたかもしれません。 デフォルトの値は ``not-for-mail'' で、通常はこのアドレスに対しての E-mail はエラーとなります。

xxx_MODE パラメータはスプールでの記事やディレクトリや active ファイルやユーザ ID が NEWSUSER の持ちもののすべてのファイルのパーミッションを指定します。 C LIBRARY DIFFERENCES

このセクションでのパラメータの変更には /usr/include ディレクトリにあるヘッダファイルでの確認が必要です。

SIZE_T パラメータは memchr や fread のような関数での引数 ``size'' のデータタイプです。 LOCK_STYLE パラメータはファイルロックをどのように行うのかを指定します。

DIR_STYLE パラメータは readdir(3) での戻り値のタイプを指定します。 これは、``struct direct'' あるいは ``struct dirent'' のいずれかとなり、 それぞれ ``DIRECT'' あるいは ``DIRENT'' と指定します。

のソケットが無い場合、HAVE_UNIX_DOMAIN を ``DONT'' としてください。 この場合、INN では innd と ctlinnd 間の通信で名前付きの pipe を使用することになります。 この場合、rnews で使用するローカルな ``private'' ポートが無くなることにもなります。 これによりどのユーザも rnews を使用して偽の記事をポストするのが容易にはなりますが、 これによる問題は発生しません。 (syslog ルーチンを変更する必要もあるかもしれません。 これについての詳細は syslog/README の最後を参照してください。)

INN ではファイルやソケットで使用可能なディスクリプタ数の上限を知っておく必要があります。 この数を得るにはいくつか方法があります。 FDCOUNT_STYLE パラメータではこの方法を指定します。 ほとんどのシステムでは、getdtablesize によりこれを行うため、 デフォルトでは ``GETDTAB'' としてあります。 その他のシステムでは getrlimit、sysconf あるいは ulimit を使用する必要があり、それぞれ ``GETRLIMIT''、``SYSCONF'' あるいは ``ULIMIT'' を指定します。 これらのいずれも使用できない場合、``CONSTANT'' を指定し、lib/getdtab.c を編集して正しい値が返るようにしておきます。 この数は、システムヘッダファイルの OPEN_MAX を使用するか、 エラーになるまで /dev/null を繰り返しオープンするプログラムを書いて調べることになります。

このセクションの最後のいくつかのパラメータの xxxVAL はおもに lint の結果でエラーとならないようにするために使用します。 これらの関数は include/clibrary.h で宣言されていて、戻り値は常に無視されます。 通常は、man ページや lint ライブラリを調べることによって、これらの値を決めることができます。 C LIBRARY OMISSIONS

INN は、一部の システムには存在しない可能性のあるライブラリルーチンを使用します。 (このようなルーチンは本来存在しているはずのものです。) lib ディレクトリでは自由に再配布可能な BSD での文字列処理ルーチンを含むこれらのルーチンのいくつかを提供しています。 MISSING_SRC、MISSING_OBJ および MISSING_MAN パラメータには使用するシステムの C ライブラリに不足しているこれらのルーチンを設定することができます。 strcasecmp や strncasecmp が無い場合、INN ライブラリに strcasecmp モジュールが必要となります。 MISSING_SRC や MISSING_OBJ での名前にはそれぞれ ``.c'' や ``.o'' を追加しておいてください。

次のルーチンはすべて同じ名前のファイル名で見つかります。 これらのルーチンがなければ、同様に追加してください。
memchr    strchr    getopt
memcmp    strrchr    mkfifo
memcpy    strspn    strerror
memset    strtok
memmove

Sparc 上の SunOS で GNU の C コンパイラのバージョン 1 を使用する場合、 inet_ntoa という関数が無いため、これを追加しなければいけません。 これは、gcc の最初のバージョンでは Sun の C コンパイラでコンパイルされたこのルーチンに正しく構造体を渡していないためです。

古いバージョンの syslog を使用している場合、MISSING_SRC や MISSING_OBJ にそれぞれ syslog.c と syslog.o を追加して添付している syslog を使用するようにしてください。

OSx の Pyramid では ATT ライブラリに高速アセンブラ言語版の文字列処理ルーチンがあります。 このルーチンを使用する場合、MISSING_OBJS パラメータに ``$(OSXATTOBJ)'' を追加してください。 これによって、lib/Makefile で ATT ライブラリからオブジェクトファイルを抜きだし、INN のライブラリに追加するようになります。 MISCELLANEOUS CONFIG DATA

このセクションでのパラメータは include/configdata.h でのマクロとなります。 少なくとも VERIFY_CANCELS パラメータのところまでは目を通すようにしてください。 (このパラメータは ``DO'' にすると、innd はオリジナルの投稿者と From あるいは Sender が一致しなければ cancel を無視します。) ただし、INN での経験があまりないのであれば、 通常はこのセクションはそのままにしておいても構いません。 しかしながら、以下では有用となるパラメータについての説明をしておきます。

ACT_STYLE を ``MMAP'' にすれば、innd は active をメモリマップすることができます。 しかし、マッピングされたファイルが更新されても mtime が更新されないシステムがいくつかあります。 いくつかのバージョンの System V Release 4 には明らかにこの問題があります。 これによって、nnmaster のようなプログラムでは問題となります。 これは、このようなプログラムでは、あらたな記事が来たかどうかを決めるために stat 構造体の st_mtime を参照しているためです。 (nnmaster は nn のニュースリーダプログラムの一部です)。 この場合の最良な対策としてはおそらく、active ファイルを一時間毎に touch する cron を設定しておくことでしょう。

rnews での処理を制御するパラメータは多数あります。 RNEWS_SAVE_BAD を ``DO'' とすると、不正なヘッダがあるとして innd に拒否された記事は _PATH_BADNEWS で指定したディレクトリにセーブされます。 この場合、このディレクトリを周期的にスキャンしてこのような記事を消去しておく必要があります。 また、rnews のログで syslog 経由かとか、ファイルへとか、 あるいはログを行わないかなど、 どのように重複した記事のログをさせるかを制御することができます (このような記事は RNEWS_SAVE_BAD の値にかかわらずセーブされることはありません)。 RNEWS_LOG_DUPS を ``FILE'' に設定すると、この先にあらわれる 設定パラメータのファイルを示す _PATH_RNEWS_DUP_LOG を変更する必要があるでしょう。 UUCP 経由で記事を受け取る場合、この配送での最適化をすることによって、 通話料金を抑えるために記事の重複のログを行いたい場合があるかもしれません。 RNEWSPROGS パラメータは、入力記事のバッチファイルの先頭行の ``#!'' でのコマンド名として _PATH_NEWSPROGS を使用するかどうかを指定します。 おそらくは、``DO'' と指定することになるでしょう。 なお、rnews のフルパス名である _PATH_RNEWS が unpack 用のプログラムのあるディレクトリである _PATH_NEWSPROGS と同じにならないように注意してください。

IPADDR_LOG を ``DO'' に指定すると、ニュースのログでは Path ヘッダでの値ではなくて、記事を送ってきたホストの IP アドレスで記録されます。 これは、innd を ``-a'' オプションで起動している場合に有用となるかもしれません。 (これを行った場合、ee.lbl.gov から anonymous FTP で ``hf.tar.Z'' を取ってきて使用したくなるかもしれません。 これは、IP アドレスからホスト名に変換するフィルタです。)

xxx_TIMEOUT パラメータは INN でのさまざまなタイマ値を制御します。 システムの負荷によって、このうちのいくつかを変更することもできます。 PATHS TO COMMON PROGRAMS

INN では /bin/sh や sendmail のような標準的なプログラムをいくつか使用します。 sendmail が無い場合、メッセージ — ヘッダも含めて — を標準入力から受けて、配送するプログラムが別に必要になります。 このプログラムは _PATH_SENDMAIL パラメータで指定し、通常は ``/usr/lib/sendmail -t'' となっています。 このパラメータは実際には sprintf 形式の文字列で、 その引数に宛先のアドレスが渡されます。 ある(例えば MMDF が動いているような)場合には、``-t'' は ``%s'' に置き換えられるかもしれません。

INN ではほとんどの実行ファイルを _PATH_NEWSBIN パラメータで指定するディレクトリ配下に置いてあります。 ただし、inews や rnews がある特定の場所に存在していることを期待しているプログラムもあり、 例えば、UUCP では通常 rnews は /bin にあることを期待しています。 しかし、デフォルトの設定ではこれらのプログラムはそれぞれ一つの場所に置かれます。 同じファイルに複数のリンクを持たせなければいけない場合、INN をインストール後手動でその作業を行ってください。 システムを維持管理するために使用するスクリプトやプログラムが別にある場合、 任意のディレクトリに置いても構いません。 なお、そのようなスクリプトの実行パスにはおそらく _PATH_NEWSBIN を付ける必要があるでしょう。

/etc/rc.local があるようなシステムの場合、_PATH_NEWSBOOT パラメータで指定するスクリプトをここから起動するようにしておかなければいけません。 (ほとんどは SystemV 系ですが)他のシステムでは、システムブート処理で自動的に、 /etc/init.2 のような特別なディレクトリにあるすべてのスクリプトを起動します。 このような場合、/etc/init.2/S99news という名前にしたり、 そこにインストールされたニュースサーバ起動スクリプトからこのスクリプトを起動しなければいけません。 そうでない場合は、デフォルトの /etc/rc.news にインストールし、 個別にリンクを張ってください。

毎日のメンテナンススクリプトである、news.daily は scanlogs を呼んで、ログファイルや古いログの処理をし、egrep や awk を使用してサマリを作成します。 システムによってはこのようなプログラムにとってログファイルが大きすぎて正常に動作しないことがあります。 この場合、ベンダにクレームを付け、FSF のものをインストールする必要があるかもしれません。 scanlogs では egrep が問題無く動作するかどうか簡単にテストをするようになっています。 PATHS RELATED TO THE SPOOL DIRECTORY

デフォルトではすべての記事は /usr/spool/news 以下のディレクトリに保持されます。 別のディレクトリを指定した場合には注意してください — 多くのニュースリーダがこのディレクトリ名を意識しているからです。

INN ではトリック(これは Cnews で初めて目にしましたが)が使用可能で、 これにより(innd が使用できない状態で rnews によりスプールされる)受け取った記事と配送用のバッチファイルを保持するディレクトリと同じものを使用させることができます。 これは、ニュースグループをあらわすディレクトリ名にドットが含まれることはあり得ないため、 out.going のようなディレクトリがニュースグループ名となることはなく、 ニュースのバッチファイルをこのようなディレクトリに置くことは安全であるからです。 このようなディレクトリは _PATH_SPOOLNEWS パラメータと _PATH_BATCHDIR パラメータで使用しています。

_PATH_LOCKS を _PATH_SPOOLNEWS と同じファイルシステムにしてはいけません。 このようにしてしまうと、スプールが溢れてしまうと INN でのロックファイルを作成できなくなってしまうおそれがあるためです。 これは、news.daily を起動し、ディスクの空きを持たせるための expire を動かせないというようなことを意味します。 可能ならば、_PATH_NEWSLIB とは別のパーティションとするべきですが、 このパーティションはそれほどよく溢れることはないでしょうから、 このように分けることはあまり重要ではありません。

このセクションでのパラメータを多く変更する場合、 必要ないくつかの中間のディレクトリが存在していないため、makedirs.sh スクリプトで失敗する可能性があります。 この場合、個別にディレクトリを作成してください — owner と mode も正しく設定しておいてください。 なお、スクリプトは再実行することができるため、 最初の作成時に存在していなくても問題とはなり得ないでしょう。 EXECUTION PATHS FOR INND AND RNEWS

すべての(``cancel'' 以外の)コントロールメッセージはスクリプトによって処理されます。 そのため、システムでシェルスクリプトを直接実行できなければいけません。 INN で配布されているすべてのスクリプトは ``#! /bin/sh'' で始まっています。

_PATH_CONTROLPROGS パラメータではこれらのスクリプトを置くディレクトリを指定します。 誰かが ``rm'' というコントロールメッセージを送出するかもしれないため、 /bin のようなパブリックなディレクトリとしてはいけません。

rnews がバッチファイルを unpack する必要がある場合に _PATH_RNEWSPROGS ディレクトリに unpack 用のプログラムが置かれます。 RNEWSPROGS パラメータはそのディレクトリを実際に使用するかどうかを指定します。 SOCKETS CREATED BY INND OR CLIENTS

innd サーバとクライアント(ほとんどは明らかに ctlinnd ですが)は、 ドメインのソケットあるいは名前付き pipe を作成します。 これらは``ファイアウォール''内のディレクトリに作成され、 一連の制限されたユーザにのみアクセス許可が与えられています。 例えば、ディレクトリを /usr/local/news/innd とし、news のグループと news ユーザの持ちもので、mode を 0770 とします。 この権限を使用すると、news グループのメンバのみあらたなニュースグループを作成するために ctlinnd を使用することができます。 これは、このメンバのみ innd のソケットにメッセージを送ることができるためです。

(_PATH_INNDDIR パラメータで指定される)ディレクトリは、 すべての記事やファイルの owner と同様に innd から起動されるすべてのサブプロセスのユーザとグループ ID を決めるために使用されます。 このディレクトリの owner はインストール時に設定され、前述の ``OWNERSHIPS AND FILE MODES'' セクションで指定されます。 LOG AND CONFIG FILES

INN ではデータベースや制御用のファイルを INN 固有のディレクトリで保持します。 これは通常は /usr/local/news という名前です。 ログファイルは /var/log/news に保持します。 このセクションにはこのディレクトリ内のファイルを示すパラメータが多くあります。 ``/usr/local/news'' を ``/var/news'' にしたり、``/usr/lib/newsbin'' を ``/var/newsbin'' にしたりと大きく変えることもできます。

アクセスのためのパスワードを含むファイルには、_PATH_NNTPPASS と _PATH_NNRPACCESS の二つのファイルがあります。 これらのファイルのデフォルトの場所は /var/news/etc となっているため、 /usr/news を export することは一般的に安全です(read-only がおそらく一番よいのですが)。

INN でのプログラムでは多岐に渡るログを行い、 毎日のメンテナンススクリプトでもこれらの多岐に渡るサマリリポートと解析を行います。 INN でのログシステムの方式について理解するには多少時間がかかるかもしれません。 まずは、doc ディレクトリの newslog の man ページから読み始めてください。 INNWATCH CONFIGURATION

INN のサーバである innd ではディスクに十分な空きがあるかとか、 システムのロードアベレージが記事を受けるのに十分な低さかどうかをチェックすることはありません。 これには二つの理由があります。 一つ目は、本質的な理由です。 この種のポリシ的な情報をプログラム内に埋め込むことは間違いです。 例えば、別のファイルシステムに移っただけでプログラムを再コンパイルしたくはないでしょう。 (確かにこれは外部の設定ファイルにその情報を移すことで部分的には解決できますが、 一般的にコンパイルされる規則としてはまだ不十分です。) 二つ目は、実質的な理由です。 これは、必要な情報を求める標準的な方式がポータブルでないということです。 例えば、IDA sendmail での``ロードアベレージ取得''用のソースファイルは 700 行を越えていますが、Cnews では三つのルーチンを使用して(条件付きのコンパイルにより)ファイルシステムの状態を得るようになっています。

INN では #ifdef を使用して複雑にするより、innwatch という外部プログラム(シェルスクリプト)を使用して、 必要に応じてサーバを停止したり再開させたりするために ctlinnd を起動させます。 innwatch プログラムは innwatch.ctl という制御ファイルを読み込みます。 innwatch は innwatch(8) で説明し、innwatch.ctl は innwatch.ctl(5) で説明してあります。

このセクションのパラメータでは、サーバがいつ記事を受け取るのを止め、 いつ受け取りを再開するかを制御します。 site/innwatch.ctl を確認してみればわかるように、 おそらく変更する必要があるでしょう。 通常は、ディスクの空き容量をチェックするために変更する必要があるでしょう。 例えば、次のような記述がある innwatch.ctl の場合、 !!! df . | awk 'NR == 2 { print $4 }' ! ... これは空き容量を得るためにコマンドの結果の二番目の行の第四フィールドをチェックしています。 ここでは、``2'' と ``4'' を変更する必要があるでしょうし(これについては、 INNWATCH_INODES と INNWATCH_BLOCKS によりどのフィールドをチェックさせるかを指定することができます。)、 別の行ではシステムに応じて変更する必要があるでしょう。

INNWATCH_SLEEPTIME パラメータは innwatch がどれぐらいの周期でシステムをチェックするかを指定します — その他のパラメータはこれを念頭において指定すべきで、例えば、次の INNWATCH_SLEEPTIME 秒までの間にファイルシステムに空き容量があるようにしておく必要があります。

INNWATCH_xxxLOAD パラメータは個々の処理で必要なロードアベレージを指定します。 これは整数で、ロードアベレージを 100 で割った値を表します。 例えば、ロードアベレージが 7.5 になった場合にサーバを throttle させたい場合、 INNWATCH_HILOAD を ``750'' に設定してください。

INNWATCH_xxxSPACE パラメータは INN で使用するおもなファイルシステムでそれぞれ必要なディスクの最小空き容量を指定します。 数字は(512 バイト単位や 1K ブロック等)df が使用しているのと同じ``ローカルな単位''で表されます。

INNWATCH_SPOOLNODES パラメータはスプールにどれだけ使用可能な inode がなければいけないかを指定します。 TCL Configuration

innd では記事を受け取ったり、ある処理が発生する時に起動する TCL スクリプトを取り込むように設定することができます。 詳細については、README.tcl_hook を参照してください。

TCL_SUPPORT パラメータは TCL 処理コードをコンパイルさせるかどうかを指定します。 DO あるいは DONT のいずれかを選択してください。

TCL_LIB パラメータは TCL をサポートするのにリンク時に必要な他のライブラリを指定します。 通常は、``-ltcl -lm'' が必要となります。 TCL_SUPPORT を DONT とした場合は、これは空となっていなければいけません。

_PATH_TCL_STARTUP パラメータは処理開始時にロードされることになる TCL スクリプトのパス名を指定します。 このためのサンプル版が samples/startup.tcl にあり、ここで指定した場所にインストールされます。

_PATH_TCL_FILTER パラメータは ctlinnd コマンドによりロードされる TCL スクリプトのパス名を指定します。 詳細は ctlinnd(8)(``filter'' と ``reload'' コマンド)を参照してください。 このためのサンプル版が samples/filter.tcl にあり、ここで指定した場所にインストールされます。 PGP Configuration

inn では現在、コントロールメッセージの PGP による認証を行うことができます。

WANT_PGPVERIFY パラメータはコントロールメッセージの PGP による認証を行うかどうかを指定します。 DO あるいは DONT のうちのいずれかを選択してください。 これについての詳細は、README.pgp を参照してください。 Local Configuration

NEWSUSER のホームディレクトリを指定する等のローカルな設定を行います。 これは inndstart で innd を起動する場合に環境変数として設定されます。 Actsync Configuration

Landon Curt Noll により作成された actsync(8) が INN に取り込まれています。 このセクションでは actsync のデフォルトの設定ファイルのための変数を定義しています。 詳細については actsync(8) を参照してください。

ACTSYNC_HOST では active を同期させるためにどのホストを使用するのかを指定します。 Perl Configuration

TCL と同様に、innd では記事を受け取ったり、ある処理が発生する時に起動する perl スクリプトを取り込むように設定することができます。 さらに、nnrpd にポストされた記事についても同様な処理を行うように設定できます。 この処理は TCL ではサポートされていません。 詳細については、README.perl_hook を参照してください。

PERL_SUPPORT パラメータは perl 処理コードをコンパイルさせるかどうかを指定します。 DO あるいは DONT のいずれかを選択してください。

PERL_LIB パラメータは perl をサポートするのにリンク時に必要な他のライブラリを指定します。 通常は、``-lperl -lm'' が必要となります。 PERL_SUPPORT を DONT とした場合は、これは空となっていなければいけません。

_PATH_PERL_STARTUP_INND パラメータは処理開始時にロードされることになる perl スクリプトのパス名を指定します。 このためのサンプル版が samples/startup_innd.pl にあり、ここで指定した場所にインストールされます。

_PATH_PERL_FILTER_INND パラメータは ctlinnd コマンドによりロードされる perl スクリプトのパス名を指定します。 詳細は ctlinnd(8)(``filter'' と ``reload'' コマンド)を参照してください。 このためのサンプル版が samples/filter_innd.pl にあり、ここで指定した場所にインストールされます。

_PATH_PERL_FILTER_NNRPD パラメータは nnrpd にポストされた記事を perl によりフィルタするスクリプトのパスを指定します。 このためのサンプル版が samples/filter_nnrpd.pl にあり、ここで指定した場所にインストールされます。

おもなシステムでの config.data の変更

このセクションでは、INN をコンパイルするために必要なおもなシステム毎の config.data への変更について説明します。 これらは、あくまでも例です。 ``システムによって変わることもあります。''

gcc2 の最初のリリース版を使用している場合は、 USE_CHAR_CONST を ``DONT'' にしてください。

MISSING_SRC    memmove.c
MISSONG_OBJ    memmove.o

DEFS    -I../include -D_NO_PROTO -U__STR__
FORK    fork
FREEVAL    void
FUNCTYPE    int
HAVE_ST_BLKSIZE    DONT
HAVE_TM_GMTOFF    DONT
LDFLAGS
LINTFILTER    | sed -n -f ../sedf.aix
LINTFLAGS    -wkD -b -h $(DEFS)
LINTLIBSTYLE    SYSV
LOCK_STYLE    FCNTL
MISSING_MAN MISSING_SRC
NEED_TIME    DO
POINTER    void
USE_UNION_WAIT    DONT
AIX 3.1 では INN に添付されている syslog も使用しなければいけません。 これは、3.2 では不要です。 USE_UNION_WAIT を ``DONT'' にしなければいけないバージョンもいくつかあります。 また、rc.news を /etc/rc からではなく、init から起動しなければいけません。 これは、inittab ファイルの最後の方の ``cons'' 行の直前に次のような行を追加することになります。 rcnews:wait:2:/usr/local/etc/rc.news >/dev/console 2>&1

LIBS    -lbsd
gcc のバージョン 1 は使用しないように注意してください。 このバージョンでは、innd/cc.c でのソケットの呼び出しを誤ってコンパイルしてしまいます。

ABORTVAL    void
ALARMVAL    u_int
EXITVAL    volatile void
_EXITVAL    volatile void
FREEVAL    void
GETPIDVAL    pid_t
GID_T    gid_t
HAVE_UNISTD    DO
HAVE_VFORK    DONT
HAVE_WAITPID    DO
LSEEKVAL    off_t
MISSING_OBJ MISSING_SRC
_PATH_COMPRESS    /usr/bin/compress
_PATH_EGREP    /usr/bin/egrep
_PATH_MAILCMD    /usr/bin/Mail
_PATH_SENDMAIL    /usr/sbin/sendmail -t
PID_T    pid_t
POINTER    void
QSORTVAL    void
SIZE_T    size_t
SLEEPVAL    u_int
UID_T    uid_t
USE_UNION_WAIT    DONT
VAR_STYLE    STDARGS
config/Makefile と site/Makefile での SHELL 変数を /usr/contrib/bin/bash を指すように変更してください。 また、lib/Makefile を編集して、install ターゲットが ../llib-linn.ln を make しないようにしてください。 また、GNU の sed を使用しなければいけません。 これは、BSDI 0.9.4.1 で配布されているものは newgroup の処理で無限ループに陥ってしまうためです。

ABORTVAL    void
ALARMVAL    unsigned int
CLX_STYLE    FCNTL
CTYPE    isXXXXX((c))
DEFS    -I../include -DHPUX
FDCOUNT_STYLE    SYSCONF
FREEVAL    void
GETPIDVAL    pid_t
GID_T    gid_t
HAVE_SETBUFFER    DONT
HAVE_ST_BLKSIZE    DONT
HAVE_TM_GMTOFF    DONT
HAVE_UNISTD    DO
HAVE_WAITPID    DO
LINTFILTER    | sed -n -f ../sedf.sysv
LINTFLAGS    -b -h $(DEFS)
LINTLIBSTYLE    SYSV
LOCK_STYLE    LOCKF
LOG_INN_PROG    LOG_LOCAL7
LOG_INN_SERVER    LOG_LOCAL7
LSEEKVAL    off_t
_PATH_MAILCMD    /usr/bin/mailx
NOFILE_LIMIT    200
PID_T    pid_t
POINTER    void
PROF
QSORTVAL    void
RANLIB    echo
RES_STYLE    TIMES
SIZE_T    size_t
SLEEPVAL    unsigned int
UID_T    uid_t
USE_UNION_WAIT    DONT
_EXITVAL    void
おそらく、df の代わりに bdf コマンドを使用する必要があるでしょう。

ABORTVAL    void
ALARMVAL    uint
ACT_STYLE    MMAP
CFLAGS    $(DEFS) -g -w
CLX_STYLE    FCNTL
_EXITVAL    void
FORK    fork
FREEVAL    void
GID_T    gid_t
HAVE_ST_BLKSIZE    DONT
HAVE_TM_GMTOFF    DONT
HAVE_UNISTD    DO
LDFLAGS
LIBS    -lmld
LINTFILTER    | sed -n -f ../sedf.sysv
LINTFLAGS     $(DEFS)
LINTLIBSTYLE    SYSV
LSEEKVAL    off_t
POINTER    void
QSORTVAL    void
RANLIB    echo
SIZE_T    size_t
SLEEPVAL    uint
UID_T    uid_t
_PATH_COMPRESS    /usr/bsd/compress
MISSING_xxx パラメータは空でなければいけません。

DEFS    -I../include -DSUNOS5 -DPOLL_BUG
USE_CHAR_CONST    DO
CFLAGS    -O -Xa $(DEFS)
LDFLAGS
LIBS    -lnsl -lsocket -lelf
LINTLIBSTYLE    SYSV
LINTFLAGS    -b -h $(DEFS)
LINTFILTER    | sed -n -f ../sedf.sysv
RANLIB    echo
VAR_STYLE    STDARGS
SIZE_T    size_t
UID_T    uid_t
GID_T    gid_t
PID_T    pid_t
POINTER    void
ALIGNPTR    long
LOCK_STYLE    LOCKF
HAVE_UNISTD    DO
HAVE_SETSID    DO
HAVE_TM_GMTOFF    DONT
HAVE_WAITPID    DO
USE_UNION_WAIT    DONT
HAVE_VFORK    DONT
HAVE_UNIX_DOMAIN    DO
CLX_STYLE    FCNTL
RES_STYLE    TIMES
FDCOUNT_STYLE    SYSCONF
ABORTVAL    void
ALARMVAL    unsigned
GETPIDVAL    pid_t
SLEEPVAL    unsigned
QSORTVAL    void
LSEEKVAL    off_t
FREEVAL    void
_EXITVAL    void
MISSING_SRC MISSING_OBJ
PATH_COMPRESS    /bin/compress
C 版の subst を使用するようにしてください。

FREEVAL    void
GETPIDVAL    long
HAVE_TM_GMTOFF    DONT
HAVE_WAITPID    DO
LDFLAGS
LIBS    -lnsl -lsocket
LINTFILTER    | sed -n -f ../sedf.sysv
LINTFLAGS    -b -h $(DEFS)
LINTLIBSTYLE    NONE
LOCK_STYLE    FCNTL
MANPAGESTYLE    NONE
MISSING_MAN    strcasecmp.3
MISSING_OBJ    strerror.o strcasecmp.o
MISSING_SRC    strerror.c strcasecmp.c
_PATH_MAILCMD    /usr/bin/mailx
POINTER    void
QSORTVAL    void
RANLIB
RES_STYLE    TIMES
SIZE_T    unsigned int
USE_CHAR_CONST    DONT
USE_UNION_WAIT    DONT
このシステムで、lint が有効となったことはありませんでした。 (例えば、Esix 4.0.3 のように)SystemV のいくつかバージョンでは、次のような LIBS の値が必要です。
LIBS    -lresolv -lsocket -lnsl -L/usr/ccs/lib -lelf
Dell の SystemV マシンでは、HAVE_UNIX_DOMAIN を ``DONT'' にする必要があります。

ALARMVAL    unsigned int
FREEVAL    void
LDFLAGS
LINTFILTER    | sed -n -f ../sedf.sysv
LINTFLAGS    -b -u -x $(DEFS)
LSEEKVAL    off_t
MISSING_MAN
MISSING_OBJ    syslog.o strerror.o
MISSING_SRC    syslog.c strerror.c
POINTER    void
PROF    -p
QSORTVAL    void
SIZE_T    unsigned int
SLEEPVAL    unsigned int
_EXITVAL    void
Ultrix でも INN に添付されている syslog が必要です。 また、mmap を使用することはできません。 これは、Ultrix でのこのシステムコールは、デバイスに対してであって、ファイルに対してではないためです。 また、INN に添付されている syslog を使用すると問題があるという報告がいくつかのサイトからされています(出力されないとか、 浮動小数点が間違っている等)。 gatekeeper.dec.com の /pub/DEC にある、jtkohl-syslog-complete.tar.Z には、新旧両方の syslog を扱う``Ultrix 用''のパッケージがありますのでこれを使用してください。 さらに、Ultrix にはシンボリックリンクはありますが、find コマンドには ``-follow'' オプションがありません。 これは、expire/makeactive.c で使用されます。 このため、GNU の find をインストールするかソースファイルを編集する必要があります。 その他のソースの準備

設定ファイルを設定すること以外にも他に設定をする必要がある場合があります。 古い syslog を使用しているシステム

INN に添付されている syslog をインストールする必要がある場合、 ソースツリーのトップディレクトリで ``make syslogfix'' としてください。 これによりロギングデーモンの syslogd がコンパイルされます。 次に、これをすでに存在しているデーモン、通常は /etc/syslog ですが、 と置き換えるためにインストールしなければいけません。 また、新しい形式の syslog.conf もインストールする必要があるでしょう。

システムの syslogd と置き換えることができない場合、syslog/README を参照して代わりのデーモンとして設定する方法を調べてください。

INN のソースが openlog を間違った引数の数で呼んでいることについての lint の出力は無視してください。 実際に、出力が得られなければ、そのシステムでの syslog、 <syslog.h> あるいは lint ライブラリの設定が間違っていることになります。 DBZ パッケージ

INN では DBZ データベースパッケージを使用します。 Henry Spencer によりオリジナルから変更されていますが、DBZ の使用と再配布の許可を与えてくれた Jon Zeeff に感謝します。 INN では DBZ に INN 固有の変更を行っています。 この変更は patch プログラムと lib/dbz.pch によって行います。 patch がインストールされていなければ、手動で変更することもできます。 (Larry Wall の patch が無ければ、comp.sources.unix のアーカイブや、 FSF のアーカイブやその他のサイトから入手してください — この作業を行うぐらいなら手動で行った方がいいでしょう。)

INND_DBZINCORE と NNRP_DBZINCORE_DELAY パラメータを指定することによりそれぞれ、 innd と nnrpd は DBZ のハッシュテーブルをメモリ中に保持します。 これにより、history の大きさによりそれに比例して多くの RAM を消費するかもしれませんが、大量のディスク I/O を避けることができます。 これについての(簡単な)いくつかの説明は dbz(3) を参照してください。

SystemV 386 のコンパイラは明らかに dbz.c の最適化を行うことができません(GNU C コンパイラにはこの問題はありません。) この場合、DBZCFLAGS パラメータに ``-O'' があれば、取り除いてください。 writev の使用

INN では、一回の呼び出しで複数の I/O バッファを出力するために、 writev システムコールを広範囲にわたって使用しています。 writev がない場合、include/uio.h を /usr/include/sys ディレクトリにコピーしておかなければいけません。 また、``writev.c'' と ``writev.o'' をそれぞれ MISSING_SRC と MISSING_OBJ パラメータに追加しておかなければいけません。

lib ディレクトリにある``偽の'' writev はそれほど有効なものではありません。 このため、一度に write するために、あらたなバッファを malloc で割り当てて、すべてのデータを一つにまとめようと変更したくなるかもしれません。 しかし、innd は非常に大量のバッファを使用し得るため、 これは十分注意してから行うようにしてください。 システムのコンパイル

INN のソースの設定が終れば、コンパイルする準備は整っています。 変更した内容にまったく自信があるのであれば、次のように入力してください。 cd $inn make all エラーが何も出なければ、``システムのインストール''のセクションまで読み飛ばしてください。

自信があるけれども、注意してコンパイルしたければ、次のように入力してください。 cd $inn make world cat */lint これですべてをコンパイルし、各ディレクトリの lint を実行することになります。

もう一つの選択肢として、ソースツリーのトップディレクトリにある BUILD を起動することもできます。 これにより、対話的に設定、コンパイル、そしてシステムのインストールを行います。 スクリプトを起動した場合は、``システムのインストール''のセクションまで読み飛ばしてください。

もっと慎重にコンパイルしたければ、次のように入力してください。 cd $inn/config make quiet cd .. これにより、新しい config.data ファイルですでにテスト済の subst プログラムを使用します。 この場合、次のセクションでの指示にしたがってください。 ライブラリの作成

以下の作業により、INN でのライブラリを作成します。 次のように入力してください。 cd $inn/lib make libinn.a lint

これにより、ライブラリを作成し、ソースファイルに対して lint というファイルにその結果を出力しながら lint を実行します。 コンパイルがエラーになっている場合、おそらくは設定エラーで、 ほとんどが ``C LIBRARY DIFFERENCES'' セクションでの設定でしょう。 特に、SIGHANDLER と xxx_STYLE パラメータの双方はチェックしてください。

dbz.c での ``possible pointer alignment problem'' のような warning 以外は、 lint の出力結果はほとんど空でなければいけません。 これ以外に何かあれば、おそらく POINTER あるいは SIZE_T が適切に設定できていないのでしょう。 include/macros.h での NEW と RENEW というマクロは動的なメモリ割り当てに関連して、 すべての境界(アライメント)の問題をひとつにまとめることができます。 ALIGNPTR パラメータと include/macros.h の CAST マクロの双方をチェックしてください。

lint がその他に問題点を出力していれば、それも調べなければいけないでしょう。 しかし、多くの lint ライブラリ自身にもエラーがあることに留意してください。 また、parsedate.y での yaccpar でいくつか問題を見つけるかもしれません。 これは、ほとんどが yacc から生成された C コードでの問題のようです。 このような問題を見つけた場合、ベンダにクレームを付けてください。

移植に関する問題を見つけた場合は、教えてください。

ライブラリを作成すると、INN のソースのトップディレクトリにインストールしておかなければいけません。 これを行うには、lib ディレクトリで ``make install'' と入力してください。 これにより、他のディレクトリにあるプログラムに対して lint を行う場合に使用する lint ライブラリもコンパイルします。

ライブラリに対して変更を行った場合は常に ``make install'' を行わなければいけないことに留意してください。 ``make libinn.a'' を入力するだけでは不十分です。 このことは、十分注意しておいてください — ライブラリをコンパイルすることは他のプログラムを使用可能な状態にするのとは異なりますし、 ライブラリをインストールすることにより、プログラムに対して lint を使用することができるようにもならなければいけません。 プログラムのコンパイル

INN でのプログラムは次で詳細に示すように六っつに分類されています。 INN をインストールして使用する前にはそれぞれを作成する必要があります。 frontend プログラム

frontend プログラムは、ニュースサーバと通信するプログラムで、 記事を渡したり、innd の動作を制御するためのものです。 これには次のようなプログラムがあります。

inews
    記事の正当性をチェックし、サーバに渡すための前処理を行い、innd に記事を渡します。 これは多くの場合、ユーザが(通常は間接的に Pnews のようなプログラム経由で)使用しますが、 news/mail のゲートウェイのような特殊な機能でも使用します。

rnews
    UUCP 経由でのバッチファイルを unpack し、innd に渡します。

ctlinnd
    innd の動作を制御するプログラムです。 ニュースグループの作成や newsfeeds の更新などのニュース管理者が行わなければいけない作業の大部分がこのプログラムから行うことができるようになっています。

sys2nf
    Bnews あるいは Cnews の sys ファイルを INN の newsfeeds ファイルに変換するプログラムです。 これは、変換を支援するためのもので、使用方法はソース中の説明を参照してください。

これらのプログラムを作成するには、次のように入力してください。 cd $inn/frontends make all innd

ここでのプログラムはメインとなるニュースサーバで、次のようなプログラムから構成されます。

innd
    innd はすべての NNTP 接続を(一旦)受け入れます。 innd はそのコネクションを使用して、記事の処理を行うか、 ``ニュースリーダ''のサーバ(nnrpd)にそのコネクションを渡すようになっています。 記事の処理では、記事を受け付け、ファイルに落とし、 他のサイトに配送されるようにキューイングを行います。 innd は正式な NNTP ポート(119)で接続を待ちます。 さまざまなシステムのうちの多くは、これ(1024 未満のポート番号を使用すること)ができるのは root だけです。 したがって、innd では起動するすべてのプロセスの権限だけでなく、 作成するすべてのファイルの mode の設定を慎重に行っています。

inndstart
    root の権限が必要なプログラムを起動する場合、inndstart をインストールすることになるでしょう。 このプログラムでは NNTP ポートを open して、ユーザとグループ ID が news 管理者のものとなるように変更して、innd を exec して、 innd に open したポートを引き渡します。 同時に安全に実行するための環境も設定します。 このプログラムは小さくて(約 100 行)、容易に理解できます。 inndstart を使用すると、innd では、 chown システムコールを行う必要が無くなって、innd での処理がより速くなるため、このプログラムを使用すべきでしょう。 inndstart で root の setuid ビットを立てておけば、 どのニュース管理にも root で行う必要はなくなります。

これらのプログラムを作成するには、次のように入力してください。 cd $inn/innd make all

innd ではコントロールメッセージを実際にどのニュースグループにファイルとして保持するかとか、 それをどこに配送するかについては他のニュースシステムとは決定方式が異なっていることに留意してください。 例えば、``control'' というニュースグループには異なるタイプのコントロールメッセージが入ります。 詳細については、innd(8)、newsfeeds(5) および active(5) を参照してください。 nnrpd

innd は NNTP のサブセットを実装しています — 記事の配送に必要なもののみとなっています。 ユーザが記事を読むことができるためには、nnrpd をインストールしなければいけません。 配送で指定されていないホストから接続があった場合、nnrpd が起動され、 その処理を行います。 (nnrpd を動作させながら対話的にデバッグすることもできます。 この場合、nnrp.access ファイルに ``stdin'' という名前のエントリを追加してください。)

ニュースリーダサーバを作成するには、次のように入力してください。 cd $inn/nnrpd make all (記事を配送している)マシンのユーザが記事を受けているサーバの記事を読みたい場合には、 二つの方法があることに留意してください。 その一つの方法は、リファレンスプラットフォームの nntpd を使用することです(付録 II の``他のニュースソフトウェアからの変換''を参照してください)。 この場合、nntp.access ファイルに記事を配送しているマシンが入らないようにしてください。 もう一つの方法としては記事を読もうとするニュースリーダのソフトウェアに INN のライブラリを再リンクし、NNTP 拡張の ``mode reader'' を使用するようにすることです。 backend プログラム

backend プログラムは innd がすでに受け取った、他のサーバに配送するための記事を扱います。 これには次のようなプログラムがあります。

archive
    記事をアーカイブするための簡単なプログラムです。

actsync
    他サイトの active と同期させるためのプログラムです。

batcher
    UUCP 経由で配送するために記事をバッチにします。

buffchan
    innd からの単一出力を複数のファイルに分割するプログラムです。 データをバッファリングすることができ、 コマンド起動時のオプションをもとにファイルのフラッシュを行います。

crosspost
    クロスポストされた記事のリンクを行うプログラムです。 channel feed として起動され、innd での I/O 処理をいくつか行います。

cvtbatch
    記事のリストのファイルを INN のバッチファイルにするプログラムです。 このプログラムは、変換を支援するためのものです。

filechan
    innd からの単一出力を複数のファイルに分割するもう一つのプログラムです。 これは記事毎に open、lseek、close のシステムコールを毎回使用するようになっているため、 ロックを行うためのプロトコルを必要としません。

innxbatch
    NNTP を拡張した ``XBATCH'' を使用して配送するプログラムです。

innxmit
    リファレンス実装の nntpxmit の置き換えです。 これは、記事のリストを含むファイルを読み込み、他のサーバへ送ります。

nntpget
    他のサーバの記事を取り込むプログラムです。

shlock
    シェルスクリプトで使用するロックの機能を提供するプログラムです。

shrinkfile
    ファイルの先頭からデータ行を除くことによりファイルを切り詰めるプログラムです。 バックログのバッチファイルを整える場合に有用です。

これらのプログラムを作成するには、次のように入力してください。 cd $inn/backends make all expire

このディレクトリには history データベースを変更するプログラムとともにこの処理で有用となり得るいくつかのプログラムがあります。 データベースは history ファイルと呼ばれ、 システムが保持する各記事について記事をいつ受け取り、 どのファイルに保持しているか等の情報を一行に保持しています。 このファイルは Message-ID をインデックスとしていて、DBZ パッケージにより高速なアクセスが可能です。

convdate
    人が見て判別できる日時のフォーマットと history ファイルで使用されるフォーマットを相互に変換します。

expire
    history データベースをサーチして古いエントリを整え、スプールから古い記事を削除します。 ニュースグループ毎に保持する期間を指定することもできます。

makeactive
    このプログラムはシステムクラッシュで無くなった active ファイルを再生成します。

makehistory
    このプログラムはスプールをサーチして history ファイルを再生成します。

newsrequeue
    このプログラムはシステムクラッシュ後に他のサーバに記事を再送するためのキューを再生成します。

prunehistory
    これは記事を expire する他のプログラムのためのものです。 このプログラムは、Message-ID とそのファイル名のリストを読み込み、 記事のファイルが削除されたことを示しながら history を更新します。

このディレクトリには expire.pch と reap.pch もあります。 前者は Cnews の expire プログラムに対するパッチで、 記事が削除されると control channel 経由で innd に対してメッセージを送るというように、 innd と対話しながら動作します。 後者は reap プログラムに対する一連のパッチで、prunehistory とともに動作させることができます。 それ以外にもいくつか有用な機能も追加されています。 いずれのパッチにもそれ自身に説明がありますので参照してください。 いずれのパッチもベータテストのメンバから提供されたもので、INN としてはサポートの対象外です。

これらのプログラムを作成するには、次のように入力してください。 cd $inn/expire make all

現在 Cnews を使用している場合には、INN での expire プログラムが expire という名前のディレクトリと同じになることがあるということに留意してください。 INN でのプログラムをインストール前にディレクトリを移動するか削除する必要があります。 スクリプトとデータファイル

プログラム以外にも INN ではいくつかスクリプトが必要となっています。 例えば、システムブート時にサーバを起動させるスクリプトもあれば、 毎晩ログの処理と expire を行うものもあります。 このようなスクリプトの多くはどのように INN が動作しているかを知らなくてもそのまま使用することができます。

INN ではいくつかのデータファイルも必要となっています。 これには、記事をどのサーバから受けるのかを指定したり、どのサーバへ配送するのか等があります。 INN ではサンプルのエントリがある以外はこのように実際に使用するようなものそのものは提供できません。 おそらく、これらのファイルを記述することが、 インストールでの最も難しい所であることに気付かれるでしょう。

これらのファイルのプロトタイプはすべて samples ディレクトリにあります。 変更したものは site ディレクトリに保存しておかなければいけません。 このように分離することによって、 正式なバージョンアップによって変更したものが上書きされることはありません。

一連の初期ファイルを作成するには、次のように入力してください。 cd $inn/site make all

各ファイルについては``システムのインストール''のセクションでの説明を参照してください。 man ページ

INN にはさらに一連の man ページがあります。 インストールする man ページの owner を正しく設定するために Makefile を編集しても構いません。 それ以外はインストールでまったく悩むことはないでしょう。

man ページを読む場合、innd.8 と ctlinnd.8 から読み始めるべきでしょう。 そこからはクロスリファレンスによって参照してください。 システムのインストール

innd あるいは inndstart のいずれかは root の権限で起動されなければいけませんが、 その作成とインストールのほとんどの箇所で root である必要はありません — root の owner で setuid ビット付きでインストールされるため、実際に使用される inndstart のインストールのみ root の権限が必要となります。 $inn/makedirs.sh スクリプトは INN で使用する必要なディレクトリを作成し、 正しい owner と mode を設定します。 ほとんどが、0775 の mode と NEWSGROUP グループと NEWSUSER の持ちものになります(ただし、``ファイアウォール''ディレクトリの _PATH_INDDDIR は 0770 です)。 あらかじめこのスクリプトをチェックし、それから起動すべきです。

インストールのその他については news あるいは root で行うべきです。 Makefile はインストールするファイルの mode の設定については非常に厳密に行います。 プログラムをインストールするには次のように入力してください。 cd $inn make update これは、すべてのプログラムのディレクトリでの ``make install'' となります。 これにより、プログラムと man ページはインストールしますが、 設定ファイルやスクリプトを更新したりインストールすることはありません。 これは重要なことです。 (トップレベルを含めて)いずれのディレクトリでも、``make install'' により、 そのディレクトリにあるすべてのものを正しい所にインストールします。 ``make update'' はトップディレクトリあるいは site ディレクトリでのみ実行でき、site ディレクトリの場合はスクリプトのみ置き換え、設定ファイルは置き換えません。 新しい INN のリリースに更新する場合、おそらく最初に ``update'' を行い、site ディレクトリで ``make diff'' を行うことにより変更されたファイルを調べ、 ローカルな変更を適宜行うことになるでしょう。 Makefile では有用となり得ることも行うようになっています。 これについては例えば、Makefile での ``most'' と ``installed-diff'' でのコメントを参考にしてください。

この次と最後の作業は INN での設定ファイルとスクリプトを作成することです。 まだこれを行っていなければ、次のように入力してください。 cd $inn/site make all これにより、samples ディレクトリからスクリプトと設定ファイルをコピーし、 それに対して subst を実行します。 パッチが発行されれば、このディレクトリで make を行うと、ローカルな変更を変えずに、 更新されたファイルがどれであるかを知ることができます。 getsafe.sh スクリプトがこれを行うようになっています。 SCCS あるいは RCS ディレクトリのいずれかがあれば、getsafe.sh はこのディレクトリでのファイルとして適切なソースを使用します。

最初にインストールした一連のファイルが、コントロールメッセージを処理するために使用されます。 これらの概要を知っておきたくなることもあるでしょう。 この場合、特に control.ctl での指定と doc での newslog の man ページを確認してください。 コントロールメッセージ用のファイルは次の通りです。
checkgroups    rmgroup
control.ctl    sendme
default    sendsys
docheckgroups    senduuname
ihave    version
newgroup    writelog
parsecontrol    pgpverify

次のスクリプトは通常、cron あるいはシステム起動時に起動されるもので、 変更すべき箇所もあまりありません。
innlog.pl    scanlogs
innstat    tally.control
news.daily    tally.unwanted
rc.news rc.news はサーバを起動します。 1.4 やそれ以前のバージョンでは、このスクリプトは root で起動されていました。 このバージョンでは、rc.news は config.data ファイルでの NEWSUSER で指定したユーザで起動しなければいけません。 news.daily は expire と scanlogs を起動します。 scanlogs ではログを処理するために他のスクリプトを起動します。 これらのスクリプトが単にどのように処理しているかを確認したくなるかもしれませんが、 詳細にわたってまで確認する必要も無いでしょう。 単にコメントを読んでいただければわかるでしょう。 これらは news.daily(8)、newslog(5) および newslog(8) で説明しています。

記事を配送するためのスクリプトもいくつかあります。
nntpsend    send-nntp
nntpsend.ctl    send-uucp
send-ihave    sendbatch
これらのスクリプトでは、指定したサイトのバッチファイルをロックし、innxmit を呼んだりして他のサーバに記事を配送します。 send-ihave は ``ihave/sendme'' による配送で使用します。 この配送については付録 III の``通常とは異なる配送の設定''で説明しています。 sendbatch と send-uucp はバッチファイルをフラッシュおよびロックし、 batcher を呼んで UUCP のキューに入れます。 uux に渡すオプションを変更するためにこれらのファイルを変更することがあるかもしれません。 デフォルトでは、``d'' のグレードでキューに入れるようになっています。 ほとんどの場合間違いなく、スプールが溢れてしまわないように df の出力を適切に解析するようにこれらのスクリプトを編集しなければいけないでしょう。 nntpsend と send-nntp は NNTP での配送について同様なことを行います。 これらを使用して、記事をどのように配送するかを決めておく必要があるでしょう — 各スクリプトには処理が終了したということを知らせる共通の方式が用意されています。

次のファイルはローカルな情報が入るため、編集が必要となります。 これらの説明をしている man ページが doc ディレクトリにすべてあります。
expire.ctl    newsfeeds
hosts.nntp    nnrp.access
inn.conf    passwd.nntp
moderators

最後のファイル群はシステムを維持管理する上で有用となり得るスクリプトです。
inncheck    innwatch
scanspool inncheck は perl スクリプトで、INN でインストールされたファイルのシンタックスやパーミッションをチェックします。 contrib/innreport はサーバのログファイルのサマリを行うもう一つの方法です。 これは perl スクリプトです。 innwatch はシェルスクリプトで、システムをモニタし、ディスクの空き容量や inode が少なくなって来るとサーバを停止します。 _PATH_NEWSBOOT から起動することができます — デフォルトでは起動されるようになっています。 scanspool は perl スクリプトで、active ファイルとスプールのツリー構造 の内容に問題が無いかどうかを調べます。

必要な変更(これらのうちのいくつか — 特に newsfeeds ファイル — の変更は難しくなるだろう思われます)を行った場合、次のように入力してください。 make install 先に ``PATHS TO COMMON PROGRAMS'' セクションで説明しているように rc.news が正しい所にインストールされていることを確認しておいてください。 INN の設定ファイルの設定に対する指針を決定するための参考として付録 IV の``USENET あるいは NNTP のはじめてのインストール''は有用となるかもしれません。

ここまで来れば、チェックすべきことはあともう少しです。 最初に、active ファイルと history データベースがあることを確認してください。 付録 II の``他のニュースソフトウェアからの変更''で他のニュースシステムのファイルを変換する方法を説明していますのでそのような場合は、 参考にしてください。 通常は BUILD スクリプトによりあらたなファイルを生成します。 perl がある場合、inncheck を起動して設定ファイルが正しく設定されているかどうかを確認してください。 次は、INN で必要なファイル名とログレベルが一致するように syslog.conf が正しく更新されているか確認してください。 どのようにすべきかの例については syslog/syslog.conf を参照してください。

これらをすべて行えば、InterNetNews はインストールしたことになり、 起動する準備ができたことになります — ニュースシステムを楽しんでください。 さまざまなクライアントへのインストール

inews プログラムはユーザが使用するニュースリーダが使用します。 rn (このニュースリーダでは Pnews と呼びますが)等のようなプログラムでは、 記事を用意し、それを inews に渡します。 inews では記事のヘッダをチェックし、必要なヘッダを追加し、 innd に記事を渡します。 INN での inews はリファレンス実装での ``mini-inews'' より有用なものとなっています。 標準の Bnews 2.11 での inews を使用することはできません。 Cnews の inews は使用することはできますが、 (例えば $NEWSCTL/server ファイルにあるような)クライアントのマシンでだけです。 INN での inews をすべての inews を使用するクライアントマシンにインストールすることをお勧めします。

INN での MakeInews スクリプトは inews を作成し、 さまざまなホストへのインストールが容易となります。 このスクリプトではディレクトリを作成し、すべての必要なファイル(ヘッダ、 ソースおよび設定ファイル)をコピーします。 このスクリプトではオプションで引数を取り、 これはクライアントマシンのアーキテクチャとなっていなければいけません。 例えば、次のようになります。 cd $inn ./MakeInews sun3 これにより、inews.sun3 ディレクトリを作成します。 そして、そのディレクトリでの Makefile を確認した後、Sun 3 でのクライアント用の inews を作成、インストールすることができます。 これは、クライアントにこのソースディレクトリを NFS マウントもらうのが最も簡単でしょう — このようにして、すべての inews のソースを一箇所で管理することもできます。

rnews は UUCP (とおそらく mail-news のゲートウェイ)を動作させるマシンでのみ利用可能としなければいけません。 これが、innd が動作しているのと同じマシンでない場合、MakeRnews スクリプトを MakeInews と同様に使用して作成することができます。