既知問題

SunOS で NIS(以前は Yellow Pages と呼ばれていましたが)を使用する場合、 そのホスト名が FQDN でなければ、inn.conf に ``domainname'' を追加する必要があります。 これによる最もよく見られる現象は Message-ID を生成できないために、 inews が失敗するということがあります。 NIS におけるもう一つの問題は逆引きで FQDN を返さないということがあります。 ローカルのいずれのクライアント名にピリオドが含まれていないことがわかっている場合、 nnrp.access で ``*[^.]*'' のような名前を使用して対応することができます。

SunOS4.1.1 には write(2) が EINTR とともに終了するというバグがあります。 これによる最もよく見られる現象は innd からの次のようなエラーメッセージがあります。 Can't sync history, interrupted system call これは Sun のバグ 1052649 に相当します。 これは、100293-01 というパッチで修正されています。 リリースマニュアルによると、SunOS 4.1.2 以降のすべてのリリースでは修正されています。

NOFILE_LIMIT を指定した場合、SunOS4.x での標準 I/O ライブラリには、 127 を越えるディスクリプタ数の扱いには問題があるということを知っておくべきでしょう。 これによる最もよく見られる現象は innd からの次のようなエラーメッセージがあります。 can't fopen /usr/local/news/history, invalid argument これは、ctlinnd ``reload'' コマンド後に起きます。 このような場合は、苦労しないためにも、``reload'' しようとせず、サーバを再起動してください。 もう一つの現象は、サーバが pause あるいは throttle されている状態で、 ctlinnd ``flush'' すると、innd が終了してしまうことです。 これは Sun のバグ 1045141 に相当します。 Sun では 4.x での修正は計画していません。

一連の ``throttle'' と ``go'' コマンド後にこれと同じようなエラーメッセージが出力されるということが、 あるサイトから報告されています。 これは、現象は同じですが、上記で説明したバグには関係していないようです。 INN での xfopena ルーチンを次のように置き換えると、エラーにはなりません。 return fopen(p, "a+"); これは、lib/xfopena.c にあります。

Sun がバンドルしていないコンパイラ acc を使用している場合、 バンドルしていないアセンブラも使用するようにしなければいけません。 これは、``left operand must be modifiable lvalue'' というエラーが大量に出るかもしれないためです。 この場合、USE_CHAR_CONST を ``DONT'' とすればよいでしょう。

innd において VAX Ultrix 4.2 では malloc が正常に動かないことが報告されています。 この場合、スワップが徐々に消費されていきます。 innd でのすべてのメモリリークは修正されていていると信じていますが、 別の malloc を使用してみてみたいと思うかも知れません。 Kingsley/Perl の malloc が lib に添付されています。 これを使用する場合、``malloc.c'' と ``malloc.o'' を config.data の MISSING_SRC と MISSING_OBJ に追加して、innd を再生成してください。

SunSoft Interactive の UNIX System V Release 3.2 バージョン 3.0 での <errno.h> は複数行に渡って間違いがあるということが言われています。 この問題を解決するためのもっとも簡単な方法は、include/clibrary.h に ``#include <net/errno.h>'' を追加することです。

(BSDI ではなくて、Jolitz のポーティングによる)386BSD を使用している場合、 ACT_STYLE を ``READ'' にしなければいけないでしょう。 これを行っていなければ、active ファイルは更新されなくなります。 もう一つの解決法としては、MMAP_SYNC を ``DO'' とすることです。

デフォルトのカーネルの設定では、innd が動作するには十分なディスクリプタ数がないものがいくつかあります。 この場合、カーネルを ``MAXNOFILE=128'' と ``NOFILEEXT=64'' にして再生成する必要があるかもしれません。 また、innd のメインルーチンでの ``setdtablesize(nnn)'' と、 子プロセス生成ルーチンでの ``setdtablesize(0)'' を行わなければいけないかもしれません。

古いバージョンの SCO の opendir ルーチンにはファイルディスクリプタの処理洩れがあるといわれたことがあります。 もっとも明らかな現象としては、おそらく active ファイルのリナンバリングをしようとして innd が死んでしまうということでしょう。 この場合、FSF から配布されているような自由に再配布可能な ``dirent'' パッケージを使用することになるでしょう。 この場合、CLX_STYLE は ``FCNTL'' にしなければいけません。 最後に、``MaxOutgoing'' パラメータを計算している innd/innd.c を編集して、 fudge となっているところを 4 にすることになります。

いくつかの SVR4 システムでは、ソケットのバッファサイズの指定はサポートされていないか、 サポートしていてもよろしくないことに innd のデータサイズが増大することになるかもしれません。 もっとも明らかな現象としては、syslog の出力に ``cant setsockopt(SNDBUF)'' というメッセージが出力されるということでしょう。 これを修正するには、SET_SOCKOPT を ``DONT'' にしなければいけません。

SONY の SVR4 システムには多くの問題があるとのことです。 HAVE_UNIX_DOMAIN は ``DONT'' にしなければいけません。 このシステムでは、カーネルのクラッシュや innd のブロッキングを含めて、 一般的に socket に問題があるようです。

_PATH_SED パラメータで GNU の sed を使用するようにしてある場合、 バージョン 1.13 であることを確認しておいてください。 これより前のバージョンでは、parsecontrol スクリプトが正常に動かないというバグがあります。 もっとも明らかな現象としては、すべての ``newgroup'' のコントロールメッセージが、解析不能というような内容のメールとなるということがあります。

HP-UX のあるバージョンのシェルは、case 文でのパターンに使用されている、 引用記号で囲まれた ``['' を適切に解析しません。 もっとも明らかな現象としては、innwatch がサーバを throttle している時に news.daily で記事を適切に expire しないということがあります。 HP に連絡して、SR # 5003-009811 に対するバグフィックスを入手してください。

RS/6000 での AIX のいくつかのバージョンでは、メモリマップにより、 すべてのページ領域を消費するかシステムをクラッシュさせてしまいます。 これは、ACT_STYLE を ``MMAP'' にしたり、DBZCFLAGS に ``-DMMAP'' が付いている場合にわかるでしょう。 IBM の問い合わせ窓口に ``U413090'' PTF とそれにあらかじめ必要なものを要求し、適用してください。 これにより解決すると言われています。

システムによっては、innd から起動されたプロセスが終了しないことがあります。 この原因は、おそらくほとんどが CLX_STYLE が ``FCNTL'' になっていないためです。

付録 I: 他のニュースソフトウェアとの違い

システムを管理していくと、 INN は Bnews や Cnews との互換性が無いということに気付くでしょう。 このセクションでは、INN が他のニュースシステムと異なる最も重要な箇所について説明します。 Bnews や Cnews でメンテナンスを行ったことがなければ、 このセクションは読み飛ばしても構いません。

通常、ユーザが気付くことは、アクセスが INN の方が速いということだけでしょう。 ユーザレベルでは他のシステムと互換性が 100% なければいけません。 ここで説明されていない、特殊な問題に遭遇したことがあれば、教えてください。 しかし、このセクションでは INN の設定をどのように行うかとか、 古いソフトウェアからどのように変換を行うのかの手引ではないということに留意してください。 付録 II の``他のニュースソフトウェアからの変更''以外には、そのようなドキュメントはありません。 設定ファイル

以下は Bnews や Cnews および NNTP のリファレンス実装で使用したデータファイルのリストで、 それぞれ INN ではどの設定ファイルに相当するかの簡単な説明もしてあります。 シンタックスはすべて異なります。 INN でのファイルはほとんどが、コロンで区切られた一連のフィールドとなっていて、 ``#'' ではじまる行は無視されます。

explist
    これは、同じようなフォーマットの expire.ctl に置き換わります。 アーカイブは expire とは別のプログラムで行われます。

mailpaths
    これは、moderators に置き換わります。 mailpaths での ``default'' エントリは、moderators でのすべてに対するワイルドカード(``*'')のエントリか inn.conf での ``moderatormailer'' エントリとなります。

nntp.access
    これは、(NNTP の配送サイトについては) hosts.nntp と(ニュースリーダについては) nnrp.access に置き換わります。

nntp.sys
    これは NNTP が ``AUTH'' オプション付きでコンパイルされている場合に使用されるパスワードファイルです。 これは、passwd.nntp に置き換わります。 inews と rnews も passwd.nntp を読み込もうとすることに留意してください。 そのため、このようなニュースリーダのために一行だけのエントリのファイルを使用したくなる場合があるかもしれません。

organization
    これは、inn.conf の ``organization'' エントリに置き換わります。

rn/server
    これは、inn.conf の ``server'' エントリに置き換わります。

whoami
    これは、inn.conf の ``pathhost'' と ``fromhost'' エントリに置き換わります。 newsgroups、active、sys および newsfeeds

設定ファイルでのもっとも大きな違いは、newsfeeds と sys にあります。 ``all.all.ctl'' のようなニュースグループのパターンは完全になくなりました。 すべてのニュースグループのパターンは、active でのニュースグループに一致するシェルでのワイルドカード(``*'')となっています。

active は受け取りたいニュースグループの定義リストとなっています。 Bnews や Cnews では、sys で指定されるローカルのサーバの購読リストに一致しなければいけません。 一致すれば、各ニュースグループは active で参照されます。 一致するニュースグループがなければ、記事は ``junk'' という名前のニュースグループに保持されます。

INN での処理ははるかに簡単となっています。 ニュースグループが active になければそのニュースグループについては無視されます。 いずれのニュースグループも active になければ、記事は拒否されます。 デフォルトの設定では、ディスクには何も書かれません。 これは、十分に考慮された設計思想によるものです。 ディスクの空きを確保するために特定のニュースグループが必要なければ、 そのニュースグループを active から削除してください。 このようになっていると、相手のサーバが配送の設定を更新していなければ、 記事の配送によって、ネットワークの帯域を浪費することになってしまいますので注意してください。

また、他のサーバと同様な処理を行うように INN を変更することもできます。 このようにするには、WANT_TRASH を ``DO'' でコンパイルしてください。 ただし、これにより、すべての記事を受け取ることになることに留意してください。 active に実際にはニュースグループが無いにもかかわらず、``すべての foo の階層のニュースグループを送ってください(junk に保持されます)、でも alt の階層は送らないでください''としても意味はありません。 この場合は、active にニュースグループがなければいけません。

INN では、Distribution ヘッダを厳密に処理します。 newsfeeds の ME エントリで ``/distrib,...'' が指定されていれば、 受け取った記事は Distribution が無いかあるいは指定された distrib に一致しなければいけません。 Distribution ヘッダをすべて無視したい場合、ME エントリで ``/distrib,...'' を指定しないようにしてください。 ``/distrib,...'' は固有な文字列でなければいけません — パターンや ``all'' のように特別なワイルドカードは使用することはできません。

これらについての詳細は、newsfeeds(5) を参照してください。 コントロールメッセージ

Cnews と同様に INN では、 ''cancel'' 以外のコントロールメッセージの処理はすべてシェルスクリプトで実装されています。 しかし、パラメータの数とタイプは Cnews とは異なっています。 シェルスクリプトで処理されるすべてのコントロールメッセージは、 その処理を行う前に、control.ctl を参照します。 記事の送出者のアドレスが、(例えば、``group-admin@isc.org'' や ``*'' 等)指定されたものに一致すれば、そのコントロールメッセージは、処理されるか、 ニュース管理者にメールが送られるか、ログに記録されるか、あるいは無視されます。 例えば、``group-admin@isc.org'' からのメッセージはそのような対象となります。

``control''、``junk'' および ``to'' というニュースグループについては明示的に配送するかしないかを指定することができます。 詳細は、newsfeeds(5) および innd(8) を参照してください。

ctlinnd では実際にサーバにニュースグループを作成したり削除します。 これは innd にとっては次のように半再帰的な処理となります。 まず、コントロールメッセージを受け取り、 そのメッセージを処理するためにスクリプトを起動します。 そして、コントロールメッセージが受け入れられれば、そのスクリプトから ctlinnd を起動して、ニュースグループを作成あるいは削除するようにサーバにメッセージを送るようになるからです。 ロック

起動中のニュースシステムでは多くのファイルをオープンし続けています。 これらのファイルは二つのグループに分けられます。 一つは、history データベースと active ファイルから構成されます。 もう一つは、ログファイルと記事の配送のために使用されるバッチファイルから構成されます。

Bnews では前者のグループに対しては内部的なプロトコルを使用して、アクセスしています。 後者のグループには、inews が``一度に追加を行う''ため、ロックは必要ありません。 Cnews では、前者のグループに対しては、locknews と newslock スクリプトを使用しますが、後者のグループに対しては確実に行うような方法はありません。

INN では、サーバは常に動作していて、ctlinnd の指示によりすべてのロックを行うことができます。 前者のグループは通常、``throttle''、``pause'' および ``go'' コマンドを(また、必要であれば ``reload'' も)使用することによりロックの処理がされます。 後者のグループは ``flushlogs'' および ``flush'' コマンドによりロックの処理がされます。 詳細は、ctlinnd(8) を参照してください。 これらのコマンドの使用例は、samples ディレクトリのさまざまなスクリプト中にあります。

付録 II: 他のニュースソフトウェアからの変換

INN はニュース配送と expire をすべて提供するシステムとなっています。 古いニュースシステムから乗り換えようとして INN を最初からインストールする方もいるため、このセクションでは、 前のニュースシステムでの設定から何を``捨てる''ことができるかの判断をするための指針を示します。 しかし、すでに存在しているニュースソフトウェアと互換性も多くあるため、 必要であれば、また、十分に注意を払うことができるのであれば、 混在した環境を作成することもできます。 Cnews での expire

INN での expire はアーカイブを行いません。 現状の INN での history データベースと同じフォーマットとなっているため、必要ならば、 Cnews の expire を使用することも可能です。 (しかし、INN の history データベースは変更されるかもしれないので、 本当に必要な場合のみにしなければいけません — 変更された場合は INN の expire を使用しなければいけません。) これを行うには次の三つの方法があります。

一つ目の方法は、doexpire を変更して、expire を実行する前に、 ctlinnd により、innd を ``throttle'' させます。 そして、expire が終了後、ctlinnd ``go'' コマンドを行うようにします。 この方法の欠点は、expire が終了するまで記事を受け取らないということです。

二つ目の方法は、lib/lock.c をコンパイルして、Cnews のライブラリの libcnews.a に追加してロック関数を置き換えるようにします。 そして、expire を削除し、再リンクします。 この方法はあまりテストされていませんが、かなりシンプルなものとなっています。

三つ目の方法は、Cnews の expire が innd と通信を行って、 削除する記事をキャンセルするようにします。 これを行うためには、expire/expire.pch というパッチを Cnews の expire.c にあててください。 また、lib/inndcomm.o を libcnews.a に追加して、expire を再リンクしてください。 標準の NNTP デーモン

``標準の'' nntpd サーバを使用することもできます。 これを使用するのは、記事を配送してくるホストと同じホストのユーザが記事を読むような場合のみでなければいけません。

まず、nntpd が DBZ を使用するように設定し、受け取った各記事を inews に渡すようにしておいてください。 この場合、``batched input'' オプションは使用しないでください。 また、inetd からの起動による動作を行ったかのように設定しておかなければいけません。 また、inetd では NNTP のポート番号 119 を使用しないようにしなければいけません。 NNTP ベースのニュースリーダ

NNTP を使用したニュースリーダをすでにインストールして、使用してる場合、 変更する必要はありません。 これには、xvnews、xrn、rrn 等が含まれます。 INN では、NNTP をいくつか拡張したものと、標準の NNTP プロトコルを実装しています。 INN では、trn、tin や他のニュースリーダで使用しているような拡張は提供していません。 INN ではすべての方式のインデックスシステムは実装していません。 (これは、正しい解決策としては、すべてのニュースリーダで使用できる一般的なインタフェースを使用することだからです。)

しかし、管理の都合上、サーバと通信を行うために、 すべてのニュースリーダで INN のライブラリと設定ファイルを使用させたくなる場合があるかもしれません。 次のセクションでは、rn でこれを行うための方法を説明します。 この説明は、すでに存在しているプログラムを変更するための参考例として使用することができるでしょう。 なお、INN ではニュースリーダの提供もサポートもしていません。 remote rn

``remote'' 版の rn (rrn とも呼ばれます)では NNTP の ``clientlib'' の一連のルーチンを使用します。 INN ではこれらのルーチンをエミュレートできます。 詳細は、clientlib(3) を参照してください。 INN で配布されているものをそのまま利用できないクライアントマシン用の rn を作成しなければいけない場合は、MakeLib スクリプトを使用して、 必要なルーチンのディレクトリを作成してください。 このスクリプトは、MakeInews スクリプトを使用した方法と同じように使用してください。

rn、rrn および trn はターゲットが常に変更しているため、 上記の指針は使用できなくなっているかもしれません。 だだし、これらのニュースリーダをメンテナンスを行っている方は正式に INN をサポートすることに同意してくれていますのでそれほど心配することもないでしょう。

INN のライブラリを使用して rn を作成するには次の二つの方法があります。 配布されている NNTP がインストールされていなければ、 一つ目の方法を使用しなければいけません。

一つ目の方法は、最新の rn の Configure スクリプトにパッチをあてて、 それを実行し、プログラムを再作成することです。 これを行うには、次のように入力してください。 cd rn_source patch <$inn/frontends/rn.pch ./Configure make いくつかの設定について、Configure は InterNetNews ライブラリを使用するかどうかをきいてきます。 この場合は、yes と答えてください。 これにより、全ソースをあるいは、 必要なヘッダやソースファイルを含む特別なライブラリを使用することができます。 Configure からの問い合わせに対しては適切なパスを入力し、rn の残りのインストールを進めてください。

二つ目の方法は、Configure を実行し、remote rn を作成するための設定をした後、ファイルをいくつか編集することです。 まず、rn の server.h を INN の include/myserver.h に置き換えます。 次に、rn の Makefile を編集して ``clientlib'' からソースとオブジェクトファイルを削除します。 これは、おそらく、c5 と obj5 という変数の定義をコメントアウトすることにより可能となるはずです。 また、Makefile を編集して、INN のライブラリをリンクするライブラリのリストに追加しなければいけません。 これは、おそらく、libinn.a へのフルパス名が ``='' の後の最初のパラメータ となるように libs 変数の定義の行を編集することにより可能となるはずです。 その他のファイルの削除

次に示す名前は、ニュースソフトウェアでの``標準''の設定ファイルとして使用しています。 マシンによっては多少違っているかもしれません。 また、多くのプログラムがその別名やリンクとなっていたりします。 それらすべてを捜し出して削除するようにしてください。

実は、/usr/lib/news (や /usr/lib/newsbin) の名前を何か別のものにして、 必要に応じてファイルをコピーしておくことにして、 最初からインストールを始めるのが一番簡単であることに気付くかもしれません。 しかし、この方式を行う前に、サーバの処理は完全に停止させておくようにしておいてください。 これには、すでに起動しているかもしれない cron による処理も含まれます。

/usr/lib/news ディレクトリは、さまざまなファイルが入り混ざっているかもしれません— これが Cnews ではすべてを個々のディレクトリに分けている理由でもあります。 次のファイルは Cnews や Bnews 2.11 と互換があり、そのまま使用すべきです。
active    active.times
Cnews を使用している場合、次のファイルはそのまま使用してください。 使用しない場合は、削除し、makehistory を使用して再作成してください。 history history.dir history.pag

rn は変更する必要はなく、 次のディレクトリはそのままにしておいてください(あるいは、 すでに移動していればもとのところに戻しておいてください)。 /usr/local/lib/rn rn で INN のライブラリを使用するように設定している場合、次のファイルを削除してください。 /usr/local/lib/rn/server

記事を受け取るのためのシステムは INN では、まったく異なっています。 次のプログラムとその man ページは削除してください。 /bin/cunbatch /bin/inews、/usr/lib/news/inews 等 /bin/rnews、/usr/bin/rnews 等 /usr/lib/news/rnews.stall /etc/nntpd、/usr/etc/nntpd 等 また、次のディレクトリとその配下のすべてのファイルも削除してください。 /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 等)

配送システムも INN では、まったく異なっています。 必要ならば、現在の配送システムを使用しても構いませんが、バッチファイルを 適切に flush させるためにいくつかの変更が必要です。 例として send-xxx スクリプトを参照してください。 次のプログラムとファイルは削除してください。 /usr/lib/news/batchparms /usr/man/man8/newsbatch.8 次のディレクトリとそこにあるすべてのファイルも削除してください。 /usr/lib/news/bin/batch nntplink、newsxd 等はそのまま使用することができます。 この場合は、これまでに説明した注意にしたがってください。

記事の expire と history と active のメンテナンス方式も INN では、 まったく異なっています。 次のファイルは削除してください。 /usr/lib/news/explist 次のディレクトリとその配下のすべてのファイルは削除してください。 /usr/lib/news/bin/expire /usr/lib/news/bin/maint expire ディレクトリを削除しておかないと、 おそらく INN の expire のインストールで問題が生じるでしょう。 これは、Cnews でのディレクトリと同じ名前となっていることがよくあるためです。

/usr/lib/newsbin にある次のプログラムは必要ではなく、削除しても構いません。 これをそのままにしていても実害はなく、有用だと思っているならば、削除しなくても構いません。
canonhdr    newshostname
ctime    newslock
dbz    queuelen
getabsdate    sizeof
getdate    spacefor
gngp ctime、getabsdate および getdate は convdate に置き換わることに留意してください。 さらに重要なこととして、newslock は innd をロックできません。 したがって、このプログラムは削除するべきでしょう。

次のファイルは INN の設定ファイルに置き換わっています。 混乱を避けるために、これらは削除すべきです。
mailname    sys
mailpaths    whoami
organization (sys 以外の)上記のファイルを使用するその他のソフトウェアを使用している場合は、 そのままでも構いません。 次のファイルは innd および scanlogs により再作成(あるいは上書き)されるため、削除すべきです。
errlog    log

上記に示したプログラムの man ページに加えて、次の man ページも削除すべきです。
active.times(5)    newsmail(8)
expire(8)    newsmaint(8)
mkgrdates(8c)    nntpd(8c)
news(5)    nntpxmit(1)
newsaux(8)

その他のファイルやディレクトリはおそらく無視されるでしょう。

付録 III: 通常とは異なる配送の設定

このセクションでは、通常とは異なるタイプの配送の設定方法について、 いくつかの注意とアドバイスを行います。 man ページでの説明とは、重複する部分もありますが、補っている部分もあります。 ihave/sendme による配送

標準の UUCP での配送では、受け取るすべての記事をバッチにまとめ、 他のサイトに送り、そこではバッチを unpack し、それぞれの記事を処理します。 しかし、受け取ったサイトが複数の配送を行っている場合、 配送する記事をある意味で``フィルタ''したいことがあるかもしれません。 これは、Message-ID のリストを ``ihave'' のコントロールメッセージとして受け取るサイトに配送することにより行います。 このコントロールメッセージを受け取るサイトではそのリストからその時点で受け取っていない記事を調べて、 コントロールメッセージを送ってきたサイトに ``sendme'' のコントロールメッセージとしてそれを送り返します。 ``sendme'' を受け取ったもともとのサイトはこのコントロールメッセージを受け取り、 標準の方式でバッチを用意します。

この方式は NNTP とは関係ないことに留意してください。 しかし、これは非常によく使用されるバッチによる特別な配送方式です。 例えば、remote というサイト名と ihave/sendme による配送を行う場合、 ローカルなサーバには ``to.remote'' というニュースグループがあるか、あるいは MERGE_TO_GROUPS を ``DO'' にしてコンパイルしておかなければいけません。

ihave/sendme による配送を受けるのは簡単です。 remote というサイトから ``ihave'' のコントロールメッセージを受け取ったとします。 innd がこのコントロールメッセージを処理すると、 適切なコントロールメッセージ処理スクリプトの /usr/local/news/bin/control/ihave を起動します。 このスクリプトでは grephistory を使用して、history データベースに無い Message-ID のリストを作成しながら記事の本文を処理します。 その後、``sendme'' のコントロールメッセージを作成するためにこのリストの出力を使用し、 inews を使用して ``to.remote'' というニュースグループにポストします。 この記事はキューイングされ、通常の方式で remote に送られます。 そして remote というサイトからは、配送を要求された記事を送り返します。

ihave/sendme による配送を行うのは少し複雑です。 最初に、newsfeeds に二つのエントリを作成しなければいけません。 一つは remote.ihave という名前でなければいけません。 このエントリは ``Tf,Wm'' という flag で、remote の購読リストとなっていなければいけません。 このエントリは remote に送ることになるすべての記事の Message-ID を集めたものとなります。 もう一つのエントリは remote という名前でなければいけません。 これは、``Tf,Wn'' という flag で、``to.remote'' というニュースグループのみを購読するようになっていなければいけません。 (実際には、標準の配送でニュースグループも配送しているのであれば、 remote.ihave のエントリだけでは無く、remote のエントリに入れても構いません。)

次のステップは、``ihave'' のコントロールメッセージを送出することになります。 これを行うためには、send-ihave スクリプトの内容をチェックし、 また、必要に応じて起動(通常は cron からですが)されるようにしなければいけません。 このスクリプトは、newsfeeds の remote.ihave エントリに対するバッチファイルを取り出し、 ``to.remote'' というニュースグループへ ``ihave'' のコントロールメッセージをポストします。 このメッセージは remote のエントリへキューイングされます。

次のステップは remote へキューイングされた記事を送出することです。 これは send-uucp あるいは sendbatch を適切に起動して、 標準の UUCP での配送として行ってください。 通常は send-ihave の起動後数分後でよいしょう。

remote というサイトが ``ihave'' のコントロールメッセージを受け取ると、それを処理し、 本文が必要な記事の Message-ID のリストとなった ``sendme'' のコントロールメッセージを送り返します。 innd がこのコントロールメッセージを処理すると、適切なコントロール用のスクリプトの /usr/local/news/bin/control/sendme を起動します。 このスクリプトでは grephistory を使用して、remote に対するバッチファイルにファイル名のリストを追加します。 このバッチファイル(ファイル名は通常は newsfeeds のエントリでのファイル名に一致していなければいけません)を使用して remote のサイトへバッチを(send-uucp あるいは sendbatch から通常呼ばれる batcher を使用して)送ります。 多くのサイトへの配送

innd は可能な限り多くのバッチファイルをオープンし続けようとします。 (ログファイル等)内部で使用する固定数を差し引いた数の使用可能なディスクリプタを使用して、 通常は可能な限り多くオープンし続けます。 ``-o'' オプションを使用して明示的にバッチファイル数の上限を指定することもできます。

使用可能なディスクリプタ数を越えた配送数がある場合、innd は``もっとも最近使っていない''ということをベースにディスクリプタを使い回します。 配送先のほとんどに大量に記事を配送する(あるいは使用可能なディスクリプタ数をはるかに越えた配送先がある)場合、 記事が配送される毎に使用可能なディスクリプタ数を越えた配送はクローズとオープンを繰り返す``ファイルスラッシング''を招きます。 これを抑えるために、newsfeeds での ``I'' パラメータを使用することにより、 innd にそのサイトに対して内部バッファを使用させることができます。 サイトに対してのバッチファイルがオープンされていなければ、 これ以上データを出力できなくならないかぎり、 サーバはバッチファイルをオープンしようとはせず、バッファ中に保持します。 例えば、innd が ``-o10'' で起動され、12 サイトあって、それぞれ、 newsfeeds で ``I512'' となっている場合を考えます。 各記事によって 50 バイト(パス名と Message-ID)生成した場合、innd は 10 記事毎ぐらいに二つのディスクリプタをクローズして再割り当てします。

もう一つのよい方法としては funnel および exploder を使用することです。 funnel は newsfeeds で指定しますが、複数のサイトを一つにまとめて出力させることができます。 funnel の利点は、一つにまとめられたこの出力を channel とすることもできるということです。 この場合のおもな欠点は、funnel では、個々のサイトではなく、出力されるデータ先を指定するということです。 (ほとんどの配送では、``Wn'' あるいは ``Wnm'' のいずれかの flag を必要としているため、 これは通常はそれほど問題とはなりません。)

funnel の出力を使用するためには、通常、サイト毎の個々のファイルに分割しなければいけません。 このようなタイプの分割を行うプログラムは ``exploder'' と呼ばれています。 INN では filechan と buffchan の二つの exploder を提供しています。

filechan はもっとも簡単ですが、もっとも効率的でない exploder です。 このプログラムはファイルをオープンし続けることはなく、open、lseek および close のシステムコールを各記事毎に行うようになっています。 これは、Bnews 2.11 の inews と同様な処理(とパフォーマンス)を提供するために使用することもできます。 しかし、サイト数を制限しない funnel として使用することもできます。

buffchan は出力ファイルを常にオープンし続けます。 したがって、一つのプロセスでオープンできる数を越えたサイト数には使用すべきではありません。 buffchan には、指定した記事数毎にクローズと再オープンを行うオプションとファイルに自動的にフラッシュするオプションもあります。 (再オープンできることは、nntplink で ``batchfile'' モードのような場合には有用です。) buffchan を ``-l1 -c50'' オプションとともに使用すると、Cnews の relaynews と同様な処理となります。

buffchan は newsfeeds で完全な exploder(``Tx'') として動作させることができます。 これは、ctlinnd を使用して buffchan の入力にコマンドを送ることができるということにもなります。 (innd はニュースグループが変更されてもコマンドを送ります。) 唯一有用なコマンドは、``flush'' で、指定したサイトのファイルをクローズし、 再オープンします。 また、この処理はコマンドを送るのみであることに留意しなければいけません。 完全な exploder では応答を返すことはできないのです。 master/slave による複製

INN ではニュースのデータベースの複製を簡単な方法でサポートしています。 これはマスタホストがスレーブホストに更新するデータを送るというものです。 マスタは記事を受けるだけのホストです — これには記事の配送とローカルなユーザのポストの双方が含まれます。 スレーブホストはマスタホストから記事を受けるだけです。

マスタホストとしての設定には特別な作業は必要ありません。

スレーブホストは innd を ``-S'' オプションでマスタホストの名前か IP アドレスを指定して起動させることにより設定します。 これは、_PATH_NEWSBOOT スクリプトの変数 ``FLAG'' を変更することにより行わなければいけません。 innd が ``-S'' オプションとともに起動されると、このオプションは nnrpd にも渡されます。 これは、スレーブホストに接続して、``POST'' コマンドを送ると、nnrpd はマスタホストに接続して記事を送るということになります。

マスタホストの newsfeeds のスレーブホストへのエントリではすべての記事(例えば、 exclude をつけてはいけません)を送るようにしなければいけません。 スレーブホストでの nnrpd は通常、Path ヘッダにその名前を追加するため、 マスタホストのスレーブホストへのエントリでは、flag フィールドに ``Ap'' を追加しなければいけません。

スレーブホストが設定されれば、次はマスタホストに配送させるようにしなければいけません。 これは、NNTP プロトコルの拡張を使用して行われます。 この拡張は innd(8) で説明されてる ``XREPLIC'' コマンドです。 これを行うためには、newsfeeds のスレーブホストへのエントリを設定しなければいけません。 これは、バッチファイルにファイル名と複製情報の双方が出力されるようにしなければいけない以外は標準のエントリと同じでなければいけません。 これを行うためには、エントリでの flag を ``WnR'' としてください。

スレーブホストに実際に記事を送ろうとする場合は、innxmit コマンドで ``-S'' オプションを指定してください。 現在の nntplink のバージョンでは、``-x'' オプションを使用してください。

スレーブとして起動している場合は、innd はマスタでの記事に同期し続けることに専念してしまいます。 もっとも注意することとして、マスタとスレーブの双方ですべての newgroup と rmgroup をそれぞれが同じように処理しなければいけないということがあります。

最後に、(nnrpd 経由での)スレーブホストへのポストは実際には、マスタホストの innd に送られているということに留意してください。 したがって、スレーブホストはニュースの読み書きを行うホストではなくて、 記事を配送してくるものとしてマスタは扱わなければいけません。

付録 IV: USENET あるいは NNTP のはじめてのインストール

ニュースシステムの必要性や管理方式は大きく変わっていくため、このセクションでは、 いくつかの一般的なガイドラインとアドバイスを提供するのみにとどめておきます。 一般的な のシステム管理のように、多くの作業は、不幸なことではありますが、 ``実際にやってみて''学習するということにならざるを得ません。 しかし、INN を一度設定したことがあれば、それほど注意を払う必要はないでしょう。 一般的な問題については、``news.admin.misc'' にポストしてみてください。 インストールでの問題については、``news.software.nntp'' や ``news.software.b'' にポストしてみてください。

一旦 INN をコンパイルしてインストールしてしまえば、今度は記事を受けなければいけません。 これには、ひとつ(あるいはそれ以上)のサイトにそこで受け取ったすべての記事を配送してもらうようにすることも含まれます。 記事を受け取ることは受動的なものとなりますが、一般的にその方が効率的な配送となります。 (nntpget はもともとはデバッグ用のプログラムです。 記事の配送するために使用することは勧められなくて、 多くのサイトでそのようなことのために使用して欲しくないと思われているでしょう。)

USENET にアクセスできるのであれば、``news.admin.misc'' に、 配送をしてもらうようにポストしてもよいでしょう。 ただし、NNTP 接続を探しているということを明らかにしておかなければいけません。 NSFNet の地域ネットワークのメンバや、ISP に接続している場合は、ネットワークセンタにお願いしてください。 直接配送をしてくれない場合でも、別の配送元を紹介してくれるかもしれません。 また、<nntp-managers@colossus.apple.com> というメーリングリストに同様に送っても構いません。 このメーリングリストはインターネット上の多くの NNTP サイトのニュース管理者に届きます。 (このメーリングリストに参加したい場合は、nntp-managers ではなく、 nntp-managers-request に送るようにしてください。)

どこかのサイトが喜んで配送を引き受けてくれた場合は、 そのサイトが配送しようとするニュースグループのリストを入手しなければいけません。 そして、ローカルのサーバにこれらのニュースグループも作成しなければいけません。 これを行うためのもっとも簡単な方法は、通常そのサイトの active のコピーをもらうことで、それを使用して必要なニュースグループを追加することです。 active の場所はシステム依存ですが、man ページ、多くは最初の段落にですが、 にはどこにあるかを(他の管理者にもわかるように)示しているはずです。 配送してもらうサイトから active を送ってもらえなければ、 もっと適切な配送サイトを見つけることになるでしょう。 次のコマンドでは、active をあらたなサイトのために記事番号を設定し直します。 sed <active.old >active.new \
   -e 's/^\([^ ]*\) [0-9]* [0-9]* \([^ ]*\)$/\1 0000000000 000000001 \2/' もう一つの簡単な方法としては、配送を引き受けてくれたサイトに NNTP で接続可能であれば、そのサイトを引数に指定して actsync を使用することです。 actsync で使用する設定ファイルを適宜設定しておくことにより、 あらたな active を容易に作成することができます。 詳細は actsync(8) を参照してください。

ニュースグループを設定しておけば、配送サイトは周期的にローカルの NNTP サーバに接続し、最後に接続してから後に受け取った記事を送ってきます。 ローカルの innd はその接続を受け入れ、記事を受け取り、 他のサイトに配送するためにキューイングします。

次のステップは、記事を配送してくるサイトに記事を送るための設定を行うことです。 これを行うには、配送してくるサイトの Path ヘッダと同じ名前を使用して newsfeeds のエントリを作成します。 (違う名前を使用する場合は、``exclude'' のサブフィールドを使用して送ってきた記事をすべて送り返さないようにしてください。) 通常、ローカル向けではない記事はすべて file feed で配送しています。 例えばこのような設定により、``Foo 有限会社'' は、foo.* をどこにも配送しないということです。

ローカルサイトで誰かが記事をポストすると、innd は他のサイトへのバッチファイルにファイル名を出力します。 send-nntp あるいは nntpsend はバッチファイルのフラッシュとロックを行い、 innxmit を呼んで、他のサイトに接続し、キューイングされた記事を送ります。 この場合、配送しようとするサイトへ配送するための設定ファイルを必要に応じて編集し、 この設定ファイルを使用するスクリプトを起動する cron を適宜それに合わせなければいけません。 好きなタイミングで起動しても構いませんが、10 分というのが一般的な間隔です。

UUCP 経由で配送したい場合、newsfeeds でそのエントリのための file feed の設定をし、cron から send-uucp を必要に応じて起動するように変更しなければいけません。 (UUCP のバッチは通常、数時間毎にのみ行います。)

最後に、他のサイトと記事の配送を開始すると、expire を行うようにしなければいけません。 そうしないと、ディスクが溢れてしまいます。 news.daily スクリプトは cron で夜中に行うべきでしょう。 このスクリプトにより、その日のログファイルのサマリを行い、expire を呼んで古い記事を削除します。 また、cron から rnews を一時間毎に呼んで処理していない記事を処理する必要もあるかもしれません。 最後に、配送先のサイトが IP アドレスを変更するようなことを考慮して、 ``ctlinnd reload hosts.nntp "flush cache"'' を一日毎に行うようにしたくなるかもしれません。 これは、innd は現状では DNS の参照を接続時に行わないためです。

これらの処理は通常、root ではなく、ニュース管理者として起動するように cron を設定しておきたいでしょう。 これを容易に行うための良いバージョンの cron が gatekeeper.dec.com の pub/misc/vixie/cron.tar.Z にあります。 必要であればこれを使用することになります。

また、ニュースを読むためのプログラムがいくつか必要になるでしょう。 フリーに利用可能なプログラムがいくつかあります。 rn はポピュラーで、おそらく最初に使用するものとしてはもっともよいものでしょう。 正式な配布パッケージは tmc.edu の anonymous FTP の rn ディレクトリから利用することができます。

USENET へようこそ、USENET を楽しんでください。

付録 V: 記事の overview データベース

現在は、``スレッド''の表示が可能なニュースリーダが多く使用できます。 スレッドの表示の機能とは、 Subject ヘッダの内容にかかわらず、 References ヘッダ(あるいはそれ以外のデータ)を使用して、 ニュースグループでの話題の流れを追うためのものです。 これらのニュースリーダの例としては、nn、trn および gnus が含まれ、さらに広く利用されてきています。 最近までは、これらのニュースリーダの大きな問題は、すべてが、 スレッドのデータを含むような特別な外部データベースを必要としていたことです。

1992 年の終りごろに Geoff Collyer <geoff@world.std.com> が nov を、 あるいは、``記事の overview'' パッケージとも呼ばれますが、をリリースしました。 これは、データベースのツールと、クライアントのアクセスルーチンから構成されます。 このルーチンにより、スレッドが可能な現在のニュースリーダは、 共通に文字通りデータベースを使用しています。 overview データベースは通常、スプールでの使用量に加えてさらに 7〜9% のディスク使用量が必要となります。 デフォルトでは、overview のファイルはスプールのディレクトリに保持されます。 これは、_PATH_OVERVIEWDIR パラメータを変更することにより、 スプール構成と同じ別のツリーを使用させることもできます。

INN では、記事の overview データベースの作成と expire を完全にサポートしています。 これを行うためには、newsfeeds に次のようなエントリを追加してください。 overview:*:Tc,WO:/path/to/bin/overchan (/path/to/bin は _PATH_NEWSBIN パラメータの値で置き換えてください。) そして、newsfeeds を reload するかサーバを再起動させてください。 この設定を行うまでにすでに記事を受け取っている場合は最初にデータベースを作成するために、overchan を起動後、次のコマンドを実行してください。 expireover -a -s また、overview データベースを expire する必要もあります。 これを行うもっとも簡単な方法は、news.daily を起動する cron 処理に ``expireover'' というキーワードを追加することです。

nnrpd には、データベースをアクセスするために二つのコマンド拡張がされています。 これは、nnrpd(8) の``プロトコル差異''の部分で説明しています。 INN では overview データベースを使用するためのクライアント用のコードや、 ニュースリーダに対するパッチは用意していません。 ニュースリーダをメンテナンスしている方は、データベースへのアクセスについて INN での拡張も含めて、overview データベースの使用をサポートすることに正式に同意しています。 (Geoff によって行われた)多くのニュースリーダのプロトタイプ版は、world.std.com の src/news ディレクトリで見つけることができます。 reader.dist.tar.Z という名前のファイルを探してみてください。

付録 VI: 限定した MIME のサポート

このバージョンの INN では、限定した MIME のサポートを行っています。 MIME は、RFC 1341 で説明されている Multipurpose Internet Mail Extensions のことです。 これにより、任意の MIME メッセージを限定した MIME 変換して配送を行い、また nnrpd では MIME ヘッダを持たない、ローカルでポストされたすべての記事に MIME ヘッダを追加させることができます。

さらに、MIME をサポートした配送を行うための nntplink 用のパッチもあります。 このパッチは正式なリリースには(まだ)なっていません。 必要ならば、Christophe Wolfhugel <Christophe.Wolfhugel@hsc-sec.fr> に連絡してください。 彼は、INN についてもそのほとんどの作業を行っています。

nnrpd で MIME ヘッダをつけさせる場合は、十分注意しておかなければいけません。 これを行うためには、inn.conf(5) で示されているように inn.conf を編集してください。 これを行った場合、ポストされるすべての記事には MIME ヘッダが追加されます。 すでに存在している MIME ヘッダは変更されませんが、無いヘッダは追加されます。 inn.conf により追加されるデフォルトの値は次のようになっています。 mime-version: 1.0 mime-contenttype: text/plain; charset=us-ascii mime-encoding: 7bit さまざまな言語が使用されるサイトでは次のような値を使用したくなるかもしれません。 mime-version: 1.0 mime-contenttype: text/plain; charset=iso-8859-1 mime-encoding: 8bit INN では 8 ビットをそのまま通過させるため、これらの値を使用することは可能です。 しかし、配送先のサイトと特別に取り決めをしていなければ、7 ビットのデータを配送しなければいけません。 これを行うためには特別な配送エージェントが必要となります。 また、nnrpd は MIME 互換のリーダでは無いことに留意してください。 このような記事を読み取る場合、データを取り出し、適切に出力するようなソフトウェアが必要です。

7 ビットデータとなるようにサーバを設定した場合、 いずれのニュースクライアントからも 8 ビットの記事を作成しないようにしなければいけません。 nnrpd ではこれをチェックしません。 8 ビットデータを使用するようにサーバを設定した場合、ASCII コードの記事は問題は無いですが、 quoted printable な行は切断され、``='' は引用された形式となります。 これは、とりわけソースコードをポストする場合には実際にはまったく好ましくない結果となります。

character セットも問題を引き起こすかもしれません。 ``iso-8859-1'' を使用する場合、ニュースリーダではこの character セットを使用するようにしておかなければいけません(例えば、MS-DOS での CP-437 は使用できません)。 これは、nnrpd では character セットの変換をしないためです。

この部分については普段から、十分に注意してください。

MIME への変換を行いながらの記事の配送は、innxmit でのみ行うことができます。 ``-M'' オプションを使用しないと、MIME の変換は行いません。 このオプションを使用すると、次のようになります。 Content-Transfer-Encoding ヘッダが ``8bit'' あるいは ``binary'' となっている記事は、``quoted-printable'' 形式で配送されます(``base64'' 形式は未だサポートされていません)。 それ以外の記事は、— 特に MIME ヘッダを持たない記事や、``message'' あるいは ``multipart'' となった記事や、Content-Transfer-Encoding が ``7bit'' となった記事は — 変換されずに配送されます。