連載 / コミュニケーション用サーパーのインストールと運用 - ② 図 3 記事の格納にかかわるファイル群 スプール h istory active Message-ID の記事本体の ニュースグル ープの一覧 格納場所 ところが、初期の SoIaris2. x では UNIX ドメインソ ケットにバグがあり、この機構が使えません。このよう な OS でも、 INN をコンパイルすると、 nntpin の代わ りに 119 番ポートを使う nnrpd を作ることができます。 この場合、 nnrpd から 119 番に接続しようとして再度 nnrpd か起動されるようでは困るので、 incoming ・ conf 、 localhost" に対する許可を書いておく必要がありま す。 incoming. conf には、デフォルトの状態でこの成疋 か当主されているので、そのままにしておけばよいでしょ NNTP 以前の配送方式による記事受入れ 次に、古くから利用されている UUCP による醋の場 合を考えます ( 図 2 ー④ ) 。 UUCP では、 uux コマンドを 用いて、ほかのホスト上でコマンドを実行させることかで きます。これは、 TCP/IP の世界の rsh コマンドのよう なものだと思えばいいでしよう。ネットニュースを酉当医 する際は、この uux コマンドを使って、酉当医先で rnews コマンドを実行させて記事の処理をおこないます。相 手から記事が送られてくると、受入れイ則では rnews コマ ンドか起動されます。 INN システム付属の rnews コマン innd は前節のようにして記事を受け取ったあと、その ドは、 nntpin 経由で記事を innd に渡します。 記事を↑内するための処理をおこないます。この際、たん ニュースリーダーによっては、 NNTP を使わずに同一 に記事をスプールに置くだけではなく、 history ファイ ホスト上に置かれた記事のスプールや、 active 、 history ルと active ファイルも生成されます ( 図 3 ) 。 といったファイルを直接読むものもあります。このような これらのファイルは、デフォルトの設定では / usr / local ニュースリーダーでは、 inews コマンドを用いて記事を投 /news/db ディレクトリに置かれており、 history は過去 稿します ( 図 2 ー⑤ ) 。 INNf'jfÆの inews コマンドは、あ に受け取った記事の Message-ID の一覧、 active はその たかもニュースリーダーであるかのように働き、 NNTP ニュースサーバーて取り扱っているニュースグルーフの一 接続で nnrpd を起動させ、 post コマンドを用いて記事を 覧尉寺しています。前回、とりあえずインストールした 才財高します。 ときには、これらのファイルを必要最低限の状態で衫期化 ところで、 innd はかならすしもすっと稼動していると しました。 はかぎりません。なんらかの事故で止まってしまった場 これらのファイルは、受け付けた記事が本当に必要なも 合はもちろん、 innwatch が過負荷を検知して innd を一 のかを判定する際に使われます。具ー勺には、以下のよう 時停止状態にしたときや、 news. daily スクリプトによる な過程を経て最後まで残れば、 innd は記事をスプールに 竹喋中などには、 innd は記事を受け付けない状態になり オ褓内し、 history と active の情報を更新します。 ます。 1. 受け取った記事の Message-ID が history ファイルに このようなときにⅲ ews コマンドや rnews コマンドが 含まれるものと一致する場合、その記事は捨てます。た 7 ただし、 - ーホスト上のニュースリーダーから localhost に接続する と、さきはどの、、 mode reader 間題 " が発生します。しかし、 8 Cnews などではすべての記事かいったんⅲ . coming ディレクトリに スリーダーからは localhost ではなく、自う ) ホスト名 (FQDN) など 置かれますが、 INN ではこのようなキ未な状況でしか incoming ディ を用いて孑Æするように言立すれは 1 呂題は生しません。 レクトリは用いられません。 0 、℃「 V 肥 W 記事の主要 なヘッダの内 容一覧 innd overchan 起動されると、記事はいったん /usr/local/news/spool/ incoming ディレクトリ ( デフォルトの場合 ) に置かれま す ( 図 2 ー⑥ ) 8 。これについては、 rnews コマンドを一 U オ プション付きて起動すると、 spool/incoming ディレクト リ以下をチェックして再度 innd への送信を試みます。そ こで、、、 rnews -U" を疋期的に起動するように cron で設 定する必要があります。起動の頻度は、 15 分に 1 回ぐら いにしておけは十分でしよう。 己事の格納 - 三ロ 43 UNIX MAGAZINE 1998.9

ー② 連載コミュニケーション用サーハーのインストールと運用 図 1 INN システム要 監視 記事本体の格納場所 ( スプール ) および関連 ファイル innwatch ー実行状態の制御 隣接ニュース 隣接ニュース innd 記事の送出に 関連するプログ ラム群 己事配送の情報 必要に応じて記事など をディスクから読み出す n n rpd 三 = ロ 配送先 の決定 隣接ニュース 隣接ニュース 記事の受入れ に関連するプロ グラム群 隣接ニュース 隣接ニュース 、起動 7- 起動 n n rpd ーダー ニュースリ ニュースリーダー 記事の流れ その他の情報の流れ プログラム起動 rc. news から起動 されるプログラム innd から起動され るプログラム その他のプログラム 内容が変化するファ イルやディレクトリ ステムは、 rc. news というスクリプトの実行によって起動 れたり、あるいは一殳ューサーによるコマンドとして実行 されますが、 innd も rc. news から起動されます 2 。その されます。これらのプログラムの大半は、起重圻麦に innd 後はデーモンとして動き続け、外部からの記事の受入れ、 と妾または間接に通信をおこないます。 己事のスプール・ディレクトリへの本翻、記事の次の酉当医 innd から起動されるプログラムには、記事の酉当医に関 先の決定などをおこないます。 するもの以外に、ニュースリーダーの相手をする nnrpd があります。 innd は、外部から誰かが NNTP 接続してき rc. news からは、 innwatch も起動されます。このフロ たときに相手のホストを石忍し、そのホストか下幇妾ニ グラムの役目は、 INN システムが安全に動き続けるよう ーとして登録されていない場合には nnrpd を起 スサーノヾ に監視することです。具イ勺には、記事のスプール用ディ 動して、以後の NNTP コマンドの処理をすべて nnrpd スクの残量やマシン本の負荷率 (load average) などを に任迂ます。 nnrpd は、基本的には NNTP で接続して 定期的にチェックして、それらの値か許容範囲を超えてい きた相手ごとに 1 っすっ起動され、それぞれか並行して動 たら innd を中断状態にし、許容範囲内に戻った点でふ 作します。 たたび innd を実行状態に戻す、といった仕事をおこない 以降の節では、 INN システムを下記のように分けて解 ます。 説していきます 3 。 ほかの多くのプログラムは、 innd や cron から起動さ 謝妾サーバーからの記事の受入れ ( およびニュースリー 2 実際には、 rc. news は inndstart というプログラムを起動し、 innd- ダー用インターフェイス ) start が innd を力します。 inndstart は、 NNTP のポートで侍 受けを開始するための bind 処理をおこないます。 NNTP のポートは 119 番と決まっていますが、 1023 番以下のポートは root 限がな いと bind できません。そこで、 inndstart が root 襯具て力されて 3 舅邸 ) 角得見では、記ⅳ絲りなにとして traditional もした場合を前 119 番を bind したあと、ユーザー news ク限で innd を実行する仕 提としていますが、ほかの方式を選んた場合も記事の流れ自体はさほど変 組みになっています。 わりません。 一三ロ 己事のオ内 1 = 一口 41 UNIX MAGAZINE 1998.9

連載 / コミュニケーション用サーハーのインストールと運用ー② 図 2 記事の受入れの充れ 隣接ニュース る記事のやりとりには、前号の「 NNTP の一実験」の 節で紹介した post コマンドではなく、 ihave 、 check 、 takethis などのコマンドが使われます。 incoming ・ conf ファイルに NNTP てオ妾続してきた相 手先と一 -- ・致する名前がなければ、 innd は nnrpd を起動 し、 NNTP 通信を nnrpd に任せます ( 図 2 ー② ) 。起動 された nnrpd は、ます成疋ファイル nnrp. access を 読み込み 5 、相手先のホストからの接続が許可されている かどうかを調べます。許可されていなけれは、 502 You have no permission to talk. Goodbye . とだけ返答して NNTP 接続を切断します。一方、なん らかのかたちで許可されていれは、 NNTP 通信を続けま す。この場合、接続相手はニュースリーダーということに なるので、前回紹介した group 、 article コマンドや、記 事を投稿するための post コマンドなどが使えるようにな ります。 このように、相手先の認証は基本的に、、ホスト単位 " で おこなわれます。ここで注意点が 1 つあります。、、謝妾 己事の受入れについては、いくつかの糸習各があります ニュースサーバーカ力いている " と同時に、、、ユーサーか ( 図 2 ) 。互いに記事を交換する約束をしたニュースサー ニュースリーダーを起動してこちら側に接続してくる " ホ ー ( 謝妾ニュースサーバー ) から記事を受け取ったり、 ストにはどう対処すればいいのでしようか。 ニュースリーダーからの投稿というかたちで受け取ったり この場合、 incoming. conf と nnrp. access の両方に記 します。 述することになりますが、 INN は上記の順序で処理をお こなうため、最初はⅲ nd が通信を開始してしまいます。 NNTP 経由での記事受入れ そこで、ニュースリーダーから接続する際は、前回紹介し 現在、隣接ニュースサーバーから記事を受け入れる際の た、、 mode reader" コマンドを用いて強制的に nnrpd に フロトコルとしては、おもに NNTP (Network News 切り替える必要があります。 mode reader 機能に対応し Transfer Protocol) か使われています。この場合、隣接 ていないニュースリーダーを使うと、記事の読み書きがで ーは受入れ側ホストの 119 番ポートに接 ュースサーノヾ きないという現象か起こります ( 旧い nntp. el を用いた 続してきます。 GNUS がこれに該当するようです ) 6 119 番ポートへの接続は、ます innd が受け付けます。 nnrpd は、 post コマンドで送られた記事を受け取ると、 innd は、接続してきた相手がニュースサーバーなのかニ それを innd に引き渡します。このときには、 nntpin と ュースリーダーなのかを判別するため、設定ファイル in- いう通信路が使われます ( 図 2 ー③ ) 。これは、デフォル c 。 ming ・ con 戸の内容と上交します。この疋ファイル トの設定ならば /usr/local/news/run/nntpin にある に相手先と一致する名前があれは、 innd 自身がそのまま UNIX ドメインソケットです。 通信を続けます ( 図 2 ー① ) 。この場合の NNTP におけ 5 nnrp ・ access は nnrpd の起剏時 = に読み込まれるので、成正ファイル 4 INN-I. x 系では hosts. nntp ファイルに相当します。 incom- を変更するだけで次簽財目手のときには自勺に央されます。 mg ・ conf は innd の起重加叔こ読み込まれるので、 innd か動いている 6 しかし、相手先でニュースサーバーカ起動しているのなら、相手先のニ 最中にこの成正ファイルを変史した場合は、彳あする ctlinnd コマンド ュースリーダーがわざわざこちらのホストに接続してくる必要はあまりな により再隻読み込ませる必要があります。 いはすなので、通常は間題になりません。 :W611 ① ス 隣サ innd nntpin n n rpd 6 lnews spool/incoming rnews 5 NNTP に対応し ていない旧いニ ュースリーダー 3 rn ews ー lJ 2 n n rpd NNTP 対応 ニュースリーダー 記事の流れ プログラム起動 4 隣接ニュース ・己事の医先の決定 各酉当先への記事の送出 uux rnews!SlTENAME 一三ロ 記事の受入れ 二ロ 42 UNIX MAGAZINE 1998.9

連載 / コミュニケーション用サーパーのインストールと運用ー② これを利用して、 moderated な ( モデレータ付きの ) ニュースグループだけ保存期間を長くするといった設定が できます。 第 3 フィールドから第 5 フィールドでは、記事の保存 期間を設定します。各フィールドでは、日数 ( 小数も使用 可育もしくは、、 never" ( 永久保存 ) を指定します。これ ら 3 つのフィールドは左から順に keep 、 default 、 purge と呼はそれぞれの次のような未をもっています。 ・ keep 記事の最短保存日数を指定します。 Expires: ヘッダを 含む記事の場合、基本的にはそのヘッダで指定された 期日に消去しますが、期限を過ぎていても keep で指定 した日数のあいだは消さずに残します。 ・ default Expires: ヘッダのない普通の記事の保存期間を指定し INN には、 expire をするとともにログファイルの整理 数カ釜過すれば消去します。 pires : の期限を過ぎていなくても、 記事の最長保存日数を指定します。 keep とは逆に、 Ex- ・ purge ます。 ここに指定された日 UNIX MAGAZINE 1998.9 メールが usenet ( 管理者 ) 宛に送られてきます。 INN の daily を実行した形跡がないが、大丈夫か ? 」という主旨の ていない段階で rc. news を起動けると、起重加叔こ「 news. 前回書き忘れましたが、 news. daily が 1 回も実行され lowmark オプションを指定するだけでいいでしよう。 が、とりあえすは INSTALL ファイルの例にならって 処理効率を上げるためのオプションもいくつかあります expxreover lowmark 30 2 * * * /usr/local/news/bin/news . daily - over オプションを付ける必要があります。 overview 情報を作っている場合は、次のように expire- news. daily には、いくつかのオプションがあります。 するように設疋するといいでしよう。 サーがあまりニュースサーバーを利用しない帯に起動 の実行には、場合によっては数日制かかるので、一イ殳ユー として 1 日 1 回ずつ cron で起動します。 news. daily クリプトが伺属しています。これは、その名のとおり原則 やレポートメールの生成などもおこなう news ・ daily ス インストール直後に起動したときは、かならすこのメール が送られてきますが、異常ではないのでじ、配する必要はあ りません。 innd への設疋ファイル更新通知 いくつかの成疋ファイルは、 innd の起重加こ読み込ま れます。これらのファイルを innd の実行中に変更した場 合には、再度読み込ませる必要があります。これには、次 のように ctlinnd コマンドを実行します。 % ctlinnd reload a11 'reason' ctlinnd reload" では、再言もムみの必要なファイルを個 別に指定することもできますが、上記のように、、 a Ⅱ " と指 定するはうが簡単です。、、 'reason"' の部分はログファイ ルに言求されるだけなので、このコマンドを実行した理由 を適当に言当します。たとえば、 incoming. conf に隣接 サ→ヾー X を新たに追加する設定をした場合は、 % ctlinnd reload a11 'add X t0 incoming ・ conf ' のようにします。 おわりに 今回は、 INN システムの全体像と、おもな設定ファイ ルの書き方について説明しました。 innd を制御するための ctlinnd コマンドの使い方、コ ントロール・メッセージについては角見できませんでした。 INN-2.0 の storageapi (CNFS などの新しい記事のイ呆 : 方式 ) に関する部分にも触れたかったのですが、これも今 回は見送ることにしました。 これらの点については、次回以降で解説する予定です。 53 にやま・よういち京都大学 )

連載 / コミュニケーション用サーパーのインストールと運用ー② 図 4 記事の送出の充れ 記事本体の格納場所 ( スプール ) および関連ファイル spooI/outgoing/S 工 TEI sp001/outgOing/SITE2 spooI/outgoing/SITE3 必要に応じて記事など をディスクから読み出す です 10 。また、ある範川だけで通用するローカルなニュー スグループも作れます。極端にいえば、、、自分のニュース サーバーからはいっさい外に出さない " ニュースグループ を作って運営してもいいわけです。 さらに、謝妾サーバーとのあいだの転送にもさまざまな 手段 (NNTP 、 UUCP 、等々 ) か利用できるので、どの 手法を使うかを決めなけ川まなりません。 このような設定はすべて、 newsfeeds というファイル に言当します。 酉当に関係なく、いくつかのニュースグルーフについて アーカイプをおこなったり、糸兤 1 情報を抽出したりする場 合もあります。こういう需要にも、 newsfeeds で、、イ瓦想 的な酉占医先 " を 1 つ準備して、酉占医用プログラムの代わり にアーカイプ・プログラムや糸 1 フ。ログラムなどを呼び出 すように言当すれは対応できます。 いすれの場合も、記事ごとに、、この記事はどことどこ の酉占先に送るのか " か決定されます。その結果は、 /usr/ local/news/log/news ファイル ( デフォルトの場合 ) に 書き込まれていきます。このファイルは、 newsfeeds の 設定に間題がないかどうかを石忍するときに役立ちます。 innxmit innxmit innxmit nntpsend innd - ー nntplink nntplink nntplink innfeed 医すべき記事のファイル名を追加していきます。 nntp- send は、 cron から定期的に起動されて処理をおこない、 nntpsend. ctl ファイノレの設疋に従って innxmit フ ログラムを起動します。 innxmit は、 /usr/local/news/ spool/outgoing にある酉当バッチファイルを読み込み、 酉占先に NNTP て接続して記事を送ります。 innxmit が innd は newsfeeds によって記事の配送先を決定しま 終了すると、送り終えたぶんの酉当医バッチファイルを消去 すが、その後の処理は innd 自身はおこないません。 innd します。 は、各酉占医先ごとに、どの記事を酉占医すべきという情報を 適切なかたちに加工してファイルに記録したり、別のフ しかしこの去では、ある記事力応してから送出され るまでの時間が長くなってしまいます。このため、ディス ログラムの標準入力に渡したりするところまでを担当しま す。その情報を読み取って実際に酉占医をおこなうのは、配 クのキャッシュなどの機溝がうまく活かせす、ディスク 送担当のプログラム (feeder) です ( 図 4 ) 。 からの言もムみが枸碍に増えるという点がありました。ノ 量の記事しかやりとりしないニュースサーバーならばいい INN-I. x では、標準の配送プログラムとして nntp- のですが、フルフィード 11 などにはとうてい追いつけす、 send が付属しており、 INN のみを用いてサーバーを運 酉占尠ヾッチファイルがどんどん肥大化してしまいます。 営するときはこれを利用していました ( 図 4 ー① ) 。この これに対し、大規模な配送をおこなうニュースサーバ 場合、 innd は /usr/local/news/spool/outgoing ディ レクトリ ( デフォルトの場合 ) 以下に、配送先ごとに 1 11 フルフィードとは、 "Newsgroups: による選別はせすに、記 4 ) すべ っすっファイル ( 配送バッチファイル ) を作り、そこに てをやりとりする " という程隻の未です。しかし、世界中て投稿された すべての記事力くわけではなく、謝妾ニュースサーバーまでのネット 、、どのニュースグルーフ。の記事をもらうか " は、受け入れる側 ワークの太さや、経由するニュースサーバーの能力や定によって、届 10 つまり、 の定ではなく、謝妾サーバー側の設定しだいなのてす。もちろん、よ く記事の量は大きく変わります。このため、一口にフルフィードといっ ぶんに送ってもらい、こちら側で incoming. conf や active の負爼 ても実はさまざまてす。現在は、多いところで 1 日に約 100 万の記 みを利用して捨ててもかまいませんが、申幻医自体はおこなわれるのでネッ 事力ヾ充れているようてすが、私の管理しているサーバーには、多い日でも トワークに無県なトラフィックが発生します。 せいせい 30 カ程隻の記事しか届きません。 ニュースサーノヾー 己事の送出 - 三ロ 45 UNIX MAGAZINE 1998.9

だし、 innd が NNTP の ihave コマンドで記事を受け の記事番号を利用して管理しています。ニュースリーダー 付ける場合には、ます Message-ID をチェックするの は、最初に NNTP の list コマンドで active ファイルを で、 history にすでに存在することが分かれは記事本体 得て既読の記事番号と上交し、未読記事の有無をチェック はそもそもここまで入ってきません。 するわけです。 2. 成疋によっては Path : ヘッダをみて、特定のニュースサ 最後の、 ニュースグルーフのモード " は、特殊なニュ ーを通過してきた記事を捨てます。これは、 news- ースグルーフ ( モデレータ付きニュースグループや高不 feeds ファイルの ME 行の設疋に依存します。 可能な ( 読出し専用の ) ニュースグループなど ) を作成す 3. 記事の Newsgroups: ヘッダをみます。 Newsgroups: る際に用いられます。 の文字列が incoming. conf による成疋パターンと一致 active にどのようなニュースグループを準備するかは、 する ( または一致しない ) 場合は記事を捨てます。ⅲー 最終的にはニュースサーバー管理者カ鴃めます。しかし、 coming ・ conf にとくに設定がなけれは次に進みます。 現実には巧 . * や japan. * といったまとまりがあり、これら 4. Newsgroups: ヘッダに書かれているニュースグルーフ のまとまりごとに、どのようなニュースグループを設ける 名が、 active ファイルにあるかどうかを調べます。該 かについて、ネットニュース自身を利用して話合いがおこ 当する記述がなければ ( クロスポスト記事の場合は、 なわれています。新たなニュースグルーフ。が作成された場 Newsgroups: ヘッダに書かれたニュースグルーフのい ニュースサーバー管理者がいちいち手作業で active すれも active になけれは ) 、この記事をスプールする を変更するのは大変です。そこで、コントロール・メッ 場所がないことになります。この場合、 inn. conf ファ セージ (control message) と呼ばれる特殊な記事を利用 イルの wanttrash 行の設疋が、、 yes" ならは、イ反想的な して active を自重加勺に変更する仕組みか備わっています ニュースグループ junk に才高されたものとして扱われ ( 今回は、コントロール・メッセージについては説明しま ます。 wanttrash が、、 n 。 " ならば、この記事は捨てら せん ) 。 れます。 overview というデータも生成されます。これはニ ースグループごとの記事へッダの一覧で、 ニュースリ 通常、 history ファイルは巨大 ( 数百 MB 程度 ) にな ダーが xover コマンドを利用して記事一覧の情報を要求 るので、記事が到着するたびに history ファイルを単純 してきたとき、高速に応答できるようにするためのもの に検索するのではとても間に合いません。そこで、検索に です。 overview は、 innd 自身ではなく overchan とい ハッシュ法を利用する DBZ という仕組みが用意されて うプログラムが生成します。 overchan を起動するには、 います。これにより、 history ファイルにイ寸随して his- newsfeeds に設正を言当する必要があります ( これについ tory. dir 、 history. index 、 history. hash というファイノレ ては、「設定ファイルの書き方」の newsfeeds の項で説明 が生成されます 9 。 します ) 。 active ファイルは単純なテキストファイル形式で、各 行には以下のような情報が含まれています。 ニュースグルーフ。名 ・そのニュースグルーフの最大記事番号 ・そのニュースグルーフ。の最小記事番号 ニュースグノレーフのモード 記事番号は各ニュースサーバーて独自に付けら新し い記事か届いたら順番に 1 っすっ増やしていきます。多く のニュースリーダーでは、、、すでに読んだかどうか " をこ 9 configure の実行時に --enable-tagged-hash を指定した場合は、 history. dir 、 history. pag カ当 E 成されます。 連載 / コミュニケーション用サーパーのインストールと運用 - ② 己事の配送先の決定 - 三ロ innd の一番大きな仕事は、受け取った記事を次にどこ に運ぶべきかを決定することです。たとえば、巧 . * はサー バー A とサーバー B に運ぶけれども、 japan. * はサー バー A にしか運ばない、といった設疋ができます。 ニュースサーバーの運営を始める場合は、購読したい ニュースグループだけを送ってもらうように、ド蝌妾サー ーの管理者に頼むことになります。そうすれは、謝妾サー バー管理者はそのように成疋ファイルを書いてくれるはず 44 UNIX MAGAZINE 1998.9

連載 / コミュニケーション用サーパーのインストールと運用ー② ーでは、 nntpsend を使わすに nntplink という別のフ ログラムを組み合わせて運用する形態がよくとられてきま した ( 図 4 ー② ) 。 nntplink は、 newsfeeds の成疋により innd から子プロセスとして起動され、標準入力などを通 して酉当当青報を受け取り、記事を即座にします。 この方法は、記事の到着から配送までの時間が矢噌さ れるため、 nntpsend にくらべて効率的です。しかし、 nntplink は酉占先ごとに 1 っすっ起動されるため、記事 の酉占却こは各 nntplink がバラバラに記事をディスクか ら読み出します。タイミングカ甘前っているうちはいいので すが、酉占先の 1 つがしばらく止まっていたなどの理由で 遅延が発生すると、ディスクのキャッシュが活かせなく なります。 そこで、 INN-2.0 では innfeed という新しい酉占医フ ログラムが登場しました (INN-I. x のころから別のプロ グラムとして配布されていましたが、 INN-2.0 から正式に INN の一部に取り込まれました ) 。 innfeed は nntplink と同様、 newsfeeds の設疋により innd から子プロセスと して起動さオ L 、標準入力などを通して醋青報を受け取り ます。ただし、 nntplink とは違って、複数の酉当先を 1 つの innfeed プロセスだけて処理します ( 図 4 ー③ ) 。これ によって、基本的には記事のスプールからの読出しは 1 回 ですみます。ある酉占先がしはらく止まっていた場合、そ の間の記事は酉当医バッチファイルとして蓄えておきます。 そして、か再開できるようになったら、 ( 嗤間があれ は ) その医バッチファイルを処理しようとし、時間がな けれは、、届いたはかりの新しい記事 " を優先して醋しよ うとします。 この仕組みによって、ディスクのキャッシュか最大限 に活用されるわけです。 INN-2.0 では、配送用プログラムとして innfeed を 使うのカ鰾準的な方法になったようですが、従来どおり nntpsend も伺属しています。 innfeed は重川徂こやや不安 定な部うゞあるようなので、酉当医先が 1 ~ 2 カ戸呈度で記 翡益も 1 日数千 ~ 数万程隻なら、 nntpsend を利用した はうが安全かもしれません。 nntpsend を使う場合は newsfeeds と nntpsend. ctl ファイルの設疋を、 innfeed を使う場合は newsfeeds と innfeed. conf ファイルの設定をする必要があります。 46 UNIX MAGAZINE 1998.9 ( 必要なだけ書く ) 設定行 設定行 peer 名前 { をします。 incoming ・ conf では、接続相手ごとに次のような言当 成疋ファイルの名前も改称されたのでしよう。 が大きく変わり、さらに柔軟な設定が可能になったため、 設疋していましたが、 INN-2.0 では設定ファイルの文法 従来のバージョンでは hosts. nntp ファイルて接続許可を 連する設定をおこなうファイルです ( リスト 1 ) 。 INN の ュースサーノヾ ド妾ニ ーに対する接続の許可と、それに関 incoming. conf ファイノレ です ( もちろん、こちらの pathhost も相手に教えます ) 。 DNS での名前のはかに、 pathhost も教えてもらうわけ ーバーになってくれるサイトをみつけたら、そのホストの の pathhost の清報が必要です。つまり、ド爾妾ニュースサ newsfeeds を設疋する際には、隣接ニュースサーバー 名とは違うかもしれません。 利用しているド耐妾ニュースサーバーでは、 DNS のホスト 同しにすればいいのですが、従来の pathhost をそのまま このように こちら側の pathhost ・の設定は DNS と ホスト名 (FQDN) をそのまま利用すれはいいでしよう。 の交換ができなくなってしまいます。通常は、 DNS での と同し名前にしてしまうと、その同名のサーバーとは記事 な名前も使えますが、世界各地の既存のニュースサーバー イルで使われます。 DNS の世界でのホスト名とは無関係 サーノヾーの名前として、 Path: ヘッダや newsfeeds ファ ュース pathhost は、ネットニュースの世界におけるニ します。 が、もっとも重要な pathhost 行についてもう一度解説 inn. conf ファイルの最低限の成疋は前回説明しました inn. conf ファイノレ 定ファイルの書き方を具イ勺に解説します。 以降では、 INN システムを運用するために不可欠な設 設定ファイルの書き方

連載 / コミュニケーション用サーハーのインストールと運用 ー② リスト 1 incoming. conf の言殳定イ列 streaming: max—connections : 8 peer ME { hostname : peer news . neighbor ・ ac ・ jp { hostname : . neighbor . ac alias . neighbor. ac ・ JP peer adj acent—news { hostname news . adj acent . ne ・ JP max—connections : 15 "localhost, 127.0.0.1 ” これに対して、、名 { から } までがひとかたまりで、 ます。このような場合、いくつかの謝妾サーバーの max- 前 " を付けます。名前は、この成疋ファイル以外では使わ connections を小さめに設定して、接続数の合計を抑える れないので、どんな文字列でもかまいません。相手のホス ようにします。 ト名など、分かりやすいものにすればいいでしよう。 stream mode" による NNTP streaming 彳予では、 { } の内側では、次のように言当します。 接続を受理するか否かを指定します。 stream mode は INN に伺属の innfeed などカ用している、記事の酉当医 hostname : news . neighbor ・ ac ・ JP max—connections : 5 を高速化する仕組みです。通常は、、 true" にしておけは間 題はありません。 patterns : 最後の patterns では、そのホストから届いた記事の ます、 hostname 行に相手のホスト名を書きます。相 Newsgroups: ヘッダの内容と上交して、受け取るか捨て 手ホストか複数の IP アドレスをもっている場合、接紐芋 るかを判定させることができます。この設定は、 のバケットのヘッダ部にどの IP アドレスカ咐くか分から 「原則として、 active ファイルにあるニュースグループか ないことがあります。そのようなときは、それらすべてに 否かにかかわらす、すべての記事を次のニュースサーバー 接続許可をなえるのが一 -- ・・番確実です。この場合は、 に酉当医したい。ただし、ニュースグループ ( DCD と >< x は除 hostname : "news . neighbor. ac ・」 p , : 疇 - 外したい」 alias . neighbor ・ ac ・ JP といった場合に有効です。すべての記事を受け取る言影置で のように ( カンマ ) で区切って列挙します ( 誌面の よいのなら、この行を書かなけ川まいいでしよう。 都合ー E 、て折り返しています。以下同様 ) 。空白を含む すべての酉当医先に共通の設定は、正ファイルの最初の 値を指定するときは、 ” ( ダフルクオート ) て悃みます。 ほうで { } の外側に言当主できます。また、 group という 次の max-connections 行では、その相手からの 構文を利用して、酉当先のうちいくっかに共通する設定も NNTP 接続を同時にいくっ許すかを指定します。配送 可能です。しかし、 group 構文を活用する機会はあまりな プログラム innfeed は、同一の配送先に対して複数の いので、説明は省略します。 NNTP 接続を確立し、並列に通信します。しかし、多く nnrp. access ファイノレ の隣接ニュースサーバーが innfeed を利用していると、 innd への NNTP 接続の数が多くなりすぎて、、、ファイル nnrpd の許可に関する設定ファイルです ( リスト 2 ) 。 当子 (file descriptor)" の制限 12 を超えるおそれがあり 次のように ( コロン ) で区切った 5 つのフィール ドからなる行を列挙します。 12 この数は 64 稍隻に制限されている場イ朸ゞ多いようです。前回、「イン ストール事例」の節で触れたとおり、 csh などのシェルの "unlimit descriptors" コマンドで OS 限界値ぎりぎリまで増やせます。 ホスト名 : 許可 : ユーサー名 : パスワード : パターン 1 三ロ 47 UNIX MAGAZINE 1998.9

コミュニケーション用 サーバーの インストールと運用 小山洋一 INN-2.O のインストール ( 2 ) ふだん Web プラウザを使っているときに、しばしば 、、新しい情報 " を手に入れるのか難しい、あるいは面倒だ と感します。そのページをアクセスしないかぎり、更新の 有無が分からないからです。 たしかに、この手間を軽減するための工夫が疑らされた ページもあるようです。しかし、それにしても各制作者が 個別に工夫しているので、、、自分が見たい複数の情報 " す べてについて更新の有無を知るためには、けっきよくは自 カて調べなけれはなりません。 これに対し、古くからある電子メールやネットニュース などのメディアでは、新規情報の有無を一元管理していま す。新しい情報を伝えるためなら、これらのメディアのは うカイ更利でしよう。 このうち、ネットニュースのほうはどうもマイナーに なってしまったようです。たしかに、ネットニュースは システム上の間題をいくつカ寸包えています。とくに、去も匠 の記事流の増加にともなって、、醪医されても誰にも読ま れない記事 " の占める率か高くなり、無駄が強く意識され るようになってきたので、ネットニュースはすでに過去の 技術と考える人も少なくありません。 しかし、多人数でのコミュニケーションには、やはりネ ニュースのようなメディアが最適なのではないでしょ うか。電子メールによるメーリングリストにくらべて、同 ーサーバーへの酉当医やデータ保存が 1 回ですみますし、保 存された記事の時限管理をユーザーではなくサーバーに任 せられる点か大きな長所だと思います。 もちろん、これらの点カ鉄可斤になってしまう状兄もある でしよう。つまり、メディアにはそれぞれの、、得意分野 " があり、、、適材師斤 " ということで、場合に応した使い分 けが必要だと思います。ネットニュースの一屬己のような特 40 徴は、日判肋ってから参照するような情報には不向きと いえます。 則回、ネットニュースの記事酉当医のイ」剽 . みについて、 ュースサーバーの彳齬リを本屋さんになぞらえて説明しまし た。この比喩は、啝庫「かある本屋さんのどこに行っても 同し雑誌が読める ( 複数のサーバーのいすれに接続しても 同じ記事か読める ) けれども、置き場戸励ゞ違っていたりし て、まったく同じように読めるわけではない」、あるい は「朋は有限なので、いつまでも同じ嚠志を並べておく わけにはいかない ( ハードディスクは有限なので、いっか は記事を捨てる必要がある ) 1 」などの点から迅想したもの です。 しかし、こオ LJ ユタ ) 部分はあまり似ていません。はかの 例も考えてはみたのですが、ネットニュースははかのメ ディアとは発想が異なっている部分が多く、比喩による 解説には限界があるようです。正確に理解するためには、 やはりネットニュース・システム自体を知る必要があり ます。今回は、 INN というソフトウェアか動く仕組みと、 成疋ファイルの書き方を中心に説明します。 INN - 2.0 システムの構成 INN のシステムはいろいろなプログラムから構成され ていて、さまざまな運用形態に柔軟に通芯できます。一度 にすべてを孑当屋するのは難しいので、ます全体の概要から 角見します ( 図 1 ) 。 INN の中心は、 innd というプログラムです。 INN シ 1 囓棚とノードディスクは、、いくらあっても足リない " という点でもよく 似ています。私も、少ない本砌に多くのものを圧鏥して詰め込んでいます が、圧縮すればそのぶん、アクセス速度 " か落ちるので、利用頻度との兼 合いを考えねはならないのカ噬みどころてす。 UNIX MAGAZINE 1998.9

連載コミュニケーション用サーパーのインストールと運用ー② リスト 3 nntpsend. ctl の言聢例 news . neighbor. ac ・ jp:news . neighbor ・ ac ・ jp: :—a ー T1800 ー t300 adj acent—news : news . adj acent ・ ne ・ JP : ループになってしまう言己主をしないように十分注意してく ださい。 nntpsend. ctl ファイノレ —a ー T1800 ー t300 nntpsend を用いて記事を送り出す場合、 nntpsend. ctl ファイルを設定する必喫があります。このファイルのおも な彳割は、ド幇妾ニュースサーバーの pathhost の名前 ( 配 送バッチファイルの名前 ) と DNS での名前との対応関係 を指定することです。このほかに、 innxmit 起重加のオ プションを指定することもできます。詳しくは、 INN-2.0 に付ヴ属の nntpsend. ctl と innxmit のマニュアノレを参照 してください。 設定例をリスト 3 に示します。 ューザー news の権限で定期的に nntpsend を起動す るために、 crontab に次のようなエントリを準備する必喫 があります (crontab ファイルの書き方は、 OS によって 異なる場合があります。 OS のマニュアルで市忍してくだ さい ) 。 0 , 15 , 30 , 45 * * * * /usr/local/news/bin/nntpsend innfeed. conf ファイル innfeed を用いて記事を送り出す場合は、 innfeed. conf ファイルを設定する必要があります。このファイルのお もな彳齬リは、ド妾ニュースサーノヾーの pathhost と DNS での名前との対応関係を指定することです。書き方は in- coming. conf に似ていて、 peer のあとに pathhost の名 前を書き、 ip-name 行に DNS での名前を書きます ( リ スト 4 ) 。 これ以外にもいろいろなパラメータか調整できます。 れらについては、伺属のサンプルファイルの言己をそのま ま使えばいいでしよう。 newsfeeds ファイノレ nntpsend や innfeed の設疋ができたら、 innd からの 情報がこれらに適切に渡せるように newsfeeds ファイル で設定します。 UNIX MAGAZINE 1998.9 このファイルは、行末に、、 \ " を付けて、複数の行を 1 つの論理的な行として扱うことができます。それぞれの論 理行はコロンで区切った 4 つのフィールドからなり、配 送先ごとに 1 行すっ言当します。 第 1 フィーノレド . sitename/exclusions 酉己先の pathhost (newsfeeds では sitename と呼び ます ) をします。 sitename は、酉己医バッチファイル の名前として使われたり、あるいは innfeed などに渡さ れる情報のなかなどで使われたりします。各記事の Path: ヘッダと照合し、すでに同名のニュースサ→ヾーを j 面茴し ている場合には、その記事を同じ醋医先に酉占医しない、と いう判定にも利用されます。 また、 sitename/exclude, ecclude, のように言己主し、はかの pathhost 名を列挙することもで きます。この場合、 Path: ヘッダによるチェックの際に sitename だけでなく、、 / ・以降に日当した pathhost も使 われ、どれか 1 つでも Path: にあれ ( 己送しません。 れは、冗長な経路をもつニュースサーバーで、一方からき た記事を他方に流したくない場合などに利用できます。 第 2 フィーノレド patterns/distributions 酉当医するニュースグループのパターンを指定します。パ ターンはカンマで区切られたリストの形式で、各要素には シェルふうのワイルドカードが使えます ( 言田は INN-2.0 に付属の wildmat のマニュアルを参照してください ) 。た とえば、、巧 . * " と書くと、 . " という文字列で始まるすべ てのニュースグループを指定したことになります。 リスト 4 innfeed. conf の言聢例 ( パラメータの設定部分は省略 ) peer news . neighbor. ac ・ jp { ip¯name : news . neighbor ・ ac ・ JP max—connections : 3 peer adj acent—news { ip—name : news . adj acent . ne ・ JP 49