336 ・ C News 17.1 ニュースを配信する 記事を C News に供給するには、いくつかのやり方があります。ローカルューザ が記事を投稿したとき、通常ニュースリーダはそれを inews コマンドに渡し、ヘッ ダ情報を完全なものにします。リモートサイトからのニュースは、単一の記事でも、 ひとまとまりのバッチでも、 rnews コマンドに渡されます。 rnews は、それを /var /spool/news/in. coming ディレクトリの中に格納します。そして、あとで newsrun がそこからニュースを取り出します。しかし、これら 2 つの手法のどちらにおいても、 記事は最終的に relaynews コマンドに渡されます。 各記事に対して、 relaynews コマンドは、まず history ファイルの中のメッセー ジ ID を調べて、その記事がこのローカルサイトにすでにあるかどうかをチェックし こで、重複した記事は捨てられます。次に、 relaynews は Newsgroups : ます。 ヘッダ行を見て、このローカルサイトがそれらのグループから記事をリクエストして いるかどうかを検査します。リクエストしていて、そのニュースグループが active ファイルの中にリストされている場合、 relaynews はニューススプール領域の対応 するディレクトリの中にその記事を格納しようとします。もしそのディレクトリが存 在しなければ、作成されます。そして、その記事のメッセージ ID は、 history ファ イルに記録されます。そうでない場合、 relaynews はその記事を捨てます。 投稿されたグループが act ⅳ e ファイルにリストされていないため、 relaynews が 着信記事を格納しなかった場合、その記事は junk グループに移されます注 1 。また re- laynews は、古いか日付の間違った記事もチェックして、拒絶します。そのほかの 理由で失敗した着信バッチは、 /var/spool/news/in. coming/bad に移され、エラー メッセージが記録されます。 このあと記事は、これらのグループからニュースをリクエストしているすべてのサ 注 1 あなたのサイトに存在するグループとあなたのサイトが受け取りたいグループとが異なってい るかもしれません。たとえば、予約購読リストには、 comp 以下のすべてのニュースグループ を意味する comp. all が指定されているが、あなたのサイトで、多くの comp グループが active ファイルにリストされていないような場合があります。それらのグループに投稿された記事は、 junk グループに移されるでしよう。
330 ・ 16 章ネットニュース Usenet サイトの間で交換されます。 2 つのサイトがニュースを交換することで合意 したら、どれでも好きなニュースグループを交換できますし、自分のローカルなニュ ース階層を追加することもできます。たとえば、 groucho.edu は、主要なニュース フィード ( 供給源 ) である barnyard.edu へのニュースリンクを持っています。ま た groucho.edu は、自分がニュースを供給しているマイナーサイトへのいくつかの こで、 Barnyard 大学はすべての Usenet グループを受け リンクを持っています。 取っていますが、 GMU (Groucho Marx 大学 ) は sci 、 comp 、 rec など、主要な 階層だけを持ちたいとします。下流のサイトのいくつか、たとえば brewhq という 名前の UUCP サイトは、ネットワークやハードウェアリソースが乏しいため、もっ と少ないグループしか持てません。他方、 brewhq は GMU が持っていない fj 階層 からニュースグループを受け取りたいとしましよう。そのため、 brewhq はすべての fj グループを受け取っている gargleblaster.com とも別の配送経路も維持していま す。この場合のニュースの流れを示したのが、図 16 ー 1 です。 brewhq から出ている矢印の上のラベルについては、少し説明が要るかもしれませ れ 流 の ス ュ る を 大 0 0 図 garglebaster.com barnyard.edu 。 comp, SCI, rec graucho.edu zcomp. OS, comp. periphs
そもそも Usenet とは何カ・ 329 16.2 16.2 そもそも lJsenet とは何か Usenet のもっとも驚くべき事実の 1 つは、それがいかなる組織にも属 さず、いかなる中心的な管理機構も持っていないことです。実際、技術的 文献目録い 7 〕 な記述を除けば、それが何であるかを定義できないというのが Usenet の 実態です。ただ、それが何でないのかを言うことだけができるのです。 馬鹿かと言われてしまいそうですが、 Usenet は、 Usenet ニュースを交換する個々 のサイトの共同作業であると定義できるかもしれません。 Usenet サイトになるには、 別の Usenet サイトをみつけて、その所有者と保守担当者にニュースをやりとりして くれるよう頼むだけです。別のサイトにニュースを供給するのは「フィードする」と こから Usenet 哲学のもう 1 つの共通原理「フィードを受ければ、 Usenet いわれ、 仲間」が生まれます。 Usenet ニュースの基本単位は記事です。 これは、ユーザが書いて、そ のネットに投稿したメッセージです。ニュースシステムで扱えるようにす るため、先頭には管理情報 ( いわゆる、記事へッダ ) が付けられます。 れは、インターネットメール規格 RFC 822 に規定されたメールヘッダ形式と非常に よく似ています。記事へッダはいくつかのテキスト行からなっており、各行はコロン で終わるフィールド名で始まり、その後にフィールドの値が続きます注 1 。 己事は、 1 つ以上のニュースグループに発送されます。ニュースグループというの ニュースグル は、共通の話題に関連した記事を集めた集会所と考えてよいでしよう。 ープは階層構造をなしており、各グループの名前がその階層構造における位置を表し ています。それを見るだけで、あるグループの性格が簡単にわかることがあります。 たとえば、 comp. os. linux. announce というニュースグループ名を見れば、それが Linux という名前のコンピュータオペレーティングシステムに関する広報であること は誰にでもわかるでしよう。 これらの記事は、そのグループのニュースを配信したいと思っているすべての RFC 822 一三ロ 注 1 Usenet ニュースメッセージの形式は、 RFC 1036 「 USENET メッセージの交換に関する規格」 の中に規定されています。
17.2 インストール・ 339 すべてのニュースグループのリスト。それぞれのグループの目的について、一行の ・ newsgroups 説明がついています。ニュースリーダはあなたが購読しているニュ これらの記述をしばしば使用します。 ・ mailname ストを表示するとき、 ースグループのリ あなたのサイトのメール名、たとえば、 vbrew. como ・ whoami ニュース用のあなたのサイト名。 UUCP サイト名が使用されることが多いです。 たとえば、 vbrew など。 ・ explist ィレクトリとサプディレクトリを作成します。 最後に、着信ニュースおよび発信ニュースのために使用されるニューススプールデ OOOOOI で置換されます。 です。この呼び出しによって、数字の 2 つの文字列が文字列 000800000 と文字列 2 番目のコマンドは、私の大好きな UNIX コマンドの 1 つである sed の呼び出し # rm active. 01d # sed 's/ [ 0 ー 9 ] * [ 0 ー 9 ] * / 0000000000 00001 / ・ active. 01d > active # cp active active. 01d にあるすべての記事番号を書き換えます。 次に、以下のコマンドを使用して、 active ファイルの 2 番目と 3 番目のフィールド に使用されますが、 ihave/sendme を使わない場合にも作成しなければいけません。 trol を追加します。 to. * グループは通常 ihave/sendme メッセージを交換するため すべての to. * グループを削除し、 tO. my-site と t0. feed-site および junk と con- ールし、所有者を news 、ファイルモードを 644 に設定します。 active ファイルから イルと newsgroups ファイルを入手して、それらを /usr/lib/news の中にインスト ニュースグループの階層を新しく作成するには、フィードサイトから active ファ うがいいでしよう。その際には、ディスク容量が重要な決め手となります。 このファイルを編集して、特別なニュースグループに対する購読期限を指定したほ
16.3 U senet がニュースを処理する方法・ 333 なく、ヘッダ情報を完全に書かなくても記事を投稿することができます。 各サイトでは、ニュースはディレクトリ階層 / var / SP001 / news の中に保存されま す。各ニュースグループごとに別々のディレクトリが作られ、各記事は別々のファイ ルに格納されます。そのディレクトリ名は、ニュースグループ名から作られます。パ スの構成要素がそのままディレクトリの構成要素になります。たとえば、 comp. os. linux. misc という記事は /var/spool/news/comp/os/linux/misc に格納されます。 ニュースグループ中の記事には、それらが到着した順に番号が割り当てられます。 この番号がファイル名の代わりをします。現在オンラインになっている記事の番号 は、 active という名前のファイルの中に格納されます。これは同時に、現在あなた のサイトで知られているニュースグループのリストの役目を果たします。 ディスク容量は有限なので注 3 、しばらくしたら記事を捨て始めなければいけません。 これは、ェクスパイア (expireing) と呼ばれています。通常あるグループや階層か らの記事は、それらが到着してから一定の日数がたっと捨てられます。これは、投稿 者が記事へッダの Expires : フィールドに期限切れ日付を指定した場合は変更され Usenet はモデムとハードディスクメーカによる陰謀だと主張する人もいます。 注 3 ます。
371 ー - ダの ニュースリ 設定、 ニュースリーダは、ユーザがニュース記事を読んだり書いたり保存したりするため に使うプログラムです。数種類のニュースリーダが Linux に移植されています。以 下では、 tin 、 trn 、 nn というもっとも人気のある 3 つのニュースリーダについて、 基本的な設定法を解説します。 もっとも強烈なニュースリーダの例を示してみましよう。 $ find /var/spool/news -name ・ [ 0 ー 9 ] * ・ -exec cat { } \ : ー more 頑固な UNIX 信者の読み方です。 しかし、ほとんどのニュースリーダはこれよりもずっと洗練されています。それら は通常、ユーザが購読しているニュースグループー覧、各グループ内のすべての記事 の概要、個々の記事といった、いくつかの表示レベルを持ったフルスクリーンのイン タフェースが付いてます。 ニュースグループ内の概要表示レベルでは、ほとんどのニュースリーダがサプジェ クト ( 題名 ) と著者を示した記事の一覧を表示します。大きなニュースグループでは、 ューザが互いに関連した記事をたどるのは困難ですが、前の記事に対するフォローア ップ ( 続報・応報 ) をみつけることは可能です。
346 ・ C News トにはフォワードされます。 INN のいずれも同一の形式を使います。 このグループの着信記事はローカルには格納されませんが、それらを要求するサイ これは議長のいるグループを示します。ューザがこのグループに投稿しようとする 御メッセージによって作成されたかローカルに作成されたかの区別、および作成した れると、 C News は、作成されたグループの名前、作成された日付、 newgroup 制 active と密接に関連するファイルは、 active. times です。あるグループが作成さ 月投稿される記事を読んでください。 ださい。ニュースグループの作成方法については、 news. announce. newusers に毎 は 1 つのグループを削除します。そのようなメッセージを決して勝手に送らないでく は、 Usenet 全体に対して 1 つのグループを追加します。一方、 rmgroup メッセージ ( 「 17.10 管理用のツールと仕事」を参照してください ) 。 newgroup 制御メッセージ ープは、 addgroup と delgroup を使用して、ローカルに追加または削除できます C News では、一般にこのファイルを直接アクセスする必要はありません。グル リダイレクトされるでしよう。 カルエイリアスと見なされます。 newsgroup に投稿されたすべての記事は、それに これによって、 newsgroup は別のグループ、すなわち real-group に対するロー ・ =real-group す。 議長のアドレスは、 /usr/lib/news の中にある moderators ファイルからとられま とき、賢いニュースリーダなら、それをユーザに知らせ、記事を議長に送るでしよう。 GROUPS コマンドによっても使用されます。 ーダが新設グループをユーザに知らせるのに使用されます。また、 NNTP の NEW- 人を記述した、 1 つのメッセージをこのファイルに記録します。 これは、ニュースリ 各記事は次のような行のあとに置かれます。 ニュースパッチは、 B News 、 C News 、 17.5 記事のバッチ処理
17.6 grouplist perm times archive ニュースを期限切れにする・ 351 grouplist は、そのエントリーが適用されるニュースグループをコンマで区切った リストです。ある階層全体を指定するには、グループ名を指定します。オプションと して、 a11 を追加することもできます。たとえば、 comp. os の下のすべてのグループ に適用するエントリーには、 comp. os または comp. os. a11 と表します。 あるグループからニュースが期限切れになったとき、その名前は与えられた順序で explist 中のすべてのエントリーに対してチェックされます。最初に一致したエント リーが適用されます。たとえば、 1 週間は保存しておきたい comp. os. linux. announce を除いて、 comp の大多数を 4 日後に捨てるには、 7 日の有効期限を指定した前者に 対するエントリーのあとに、 4 日の有効期限を指定した comp に対するエントリーを 作成しておきます。 perm フィールドには、そのエントリーが議長のいる ( モデレーテッド ) グループ、 議長なしのグループ、もしくは任意のグループに適用されるかどうかを指定します。 これは値 m 、 u 、 x をとり、それぞれ、議長あり、議長なし、任意のタイプを意味し ます。 3 番目のフィールド times は、通常 1 つの数値だけを含みます。これは、記事へッ ダの Expires: フィールドの中に有効期限が指定されていなかった場合に、記事が 期限切れになる日数です。これは投稿の日からではなく、あなたのサイトに到着した 日から数えた日数であるという点に注意してください。 しかし、 times フィールドはもっと複雑な場合があります。それは、ダッシュ ( ー ) によって区切られた最高 3 個の数値の組合せでもかまいません。最初のフィールドは、 その記事が期限切れの候補とみなされる前に経過しなければならない日数を意味しま す。 0 以外の値を使用する意味はほとんどありません。 2 番目のフィールドは、上述 の期限切れになるデフォルトの日数です。 3 番目のフィールドは、 E xpires : フィー ルドの有無に関わらず、記事が無条件で期限切れになる日数です。真ん中の数値だけ が与えられたとき、ほかの 2 つはデフォルト値をとります。これらは、下で述べる特 別なエントリー / bounds / を使用して指定することもできます。 4 番目のフィールド archive には、そのニュースグループをアーカイプするかど うか、またどこにアーカイプするかを指定します。アーカイプ処理を行わないときは、
350 ・ C News ーカルのニュースシステムにフィードする必要があります。これらの転送方法の完全 なリストを見たければ、 newsbatch マニュアルページを参照してください。 最後の 3 つのフィールドにあげたコマンドは、すべて out. going/site または /usr /lib/news/bin/batch の中になければいけません。これらのほとんどはスクリプト なので、自分のニーズに合った新しいツールを簡単に作成することができます。それ らは 1 本のパイプとして起動されます。記事のリストはバッチ処理コマンド ( batcher ) の標準入力に供給され、標準出力にバッチが生成されます。そして、それが muncher # batchparms file for the brewery 下にサンプルファイルを示しておきます。 などにパイプで送られます。 # s i t e 17.6 /default/ swlm ー Size lmax 1 ー 22 1 ー 10 lbatcher batcher batcher lmuncher compcun nOCO Ⅱ ltransport V1a1111X VI aUU-X ニュースを期限切れにする B News では、 expire と呼ばれるプログラムによってニュースを期限切れにしま す。これを工クスパイアすると言います。 expire コマンドは、ニュースグループの リストおよび記事が期限切れになる時間指定を引数としてとります。従来、それぞれ の階層を異なる時間に期限切れにするには、それらのおのおのに対して expire を起 動するスクリプトを書かなければなりませんでした。 C News では、これをもっと 手際よく解決しています。 explist と呼ばれるファイルの中で、ニュースグループと 有効期限を指定することができます。 doexpire と呼ばれるコマンドが、 cron から 通常 1 日に一度実行され、このリストにしたがってすべてのグループを処理します。 時として、期限切れになったあとでも、特定のグループの記事を保持しておきたい ことがあるかもしれません。たとえば、 comp. sources. un ⅸに投稿されたプログラ ムは保存しておきたいでしよう。これは、アーカイプ処理と呼ばれています。 explist によって、アーカイプ処理の対象となるグループを選ぶことができます。 explist のエントリーは、次のようになっています。具体例は後ほど示します。
332 ・ 16 章ネットニュース 先を (Distribution: ヘッダフィールドに ) 指定することです。これは、特定のサ イト群に配布を限定したいときに使用されます。他方、どのニュースグループをやり とりするかについては、送信側と受信側のシステムの両方が制限をつけることができ ます。あるサイトへ転送されることになったニュースグループと配布先のセットは、 通常 sys ファイルに書かれます。 しかし、記事があまりに多いので、上の方式を改善する必要があります。 UUCP ネットワークで普通に行われているのは、ある一定の時間、記事を集め、それらを 1 つのファイルに結合し、それを圧縮してリモートサイトに送ることです。これは、バ ッチ方式と呼ばれています。 もう 1 つの手法は、 ihave/sendme プロトコルです。これは、重複した記事が転 送されるのを事前に防ぎ、それによって正味の帯域幅を節約しようとするものです。 バッチファイルにすべての記事を入れて送る代わりに、記事のメッセージ ID だけを 大きな ihave メッセージの中に詰めて、リモートサイトに送ります。リモートサイ トは、このメッセージを読んで、それをヒストリーファイルと比較し、送ってほしい 記事のリストを sendme メッセージに入れて返します。すると、これらの記事だけ が送られてくるというわけです。 もちろん、 ihave/sendme は、複数の異なる供給源からニュースを受け取ってい る 2 つの大きなサイトが、ニュースを効率的に流すために互いに何度もやり取りする ような場合にしか効果はありません。 インターネット上のサイトは、一般に NNTP(Network News Trans- fer protocol) を使用する TCP/IP べースのソフトウェアを利用します。 RFC 977 それはフィード間でニュースを転送したり、リモートホスト上のシングル ューザに Usenet アクセスを供給したりします。 NNTP は、 3 つの異なる方法でニュースを転送します。 1 番目は、 ihave/sendme のリアルタイムバージョンで、ブッシング (pushing) ニュースとも呼ばれているも のです。二番目の手法は、プリング (pulling) ニュースと呼ばれているものです。 クライアントは、指定した日付以降にサーバのサイトに到着した所定のニュースグル ヒストリーファイルの中に す。あなたやニュースリーダは、指定したニュースグループから記事を読めるだけで ないものを選択します。三番目のモードは、対話方式でニュースを読むためのもので ープまたは階層の中にある記事のリストをリクエストし、