diff --git a/ja_JP.eucJP/articles/contributing/article.sgml b/ja_JP.eucJP/articles/contributing/article.sgml index 5f3b5603fa..13a75790a5 100644 --- a/ja_JP.eucJP/articles/contributing/article.sgml +++ b/ja_JP.eucJP/articles/contributing/article.sgml @@ -1,600 +1,600 @@ %articles.ent; ]>
FreeBSD への貢献 $FreeBSD$ この文書は、個人や団体が FreeBSD プロジェクトに貢献するためのいくつかの方法について説明しています。 Jordan Hubbard 寄稿: &tm-attrib.freebsd; &tm-attrib.ieee; &tm-attrib.general; 貢献 あなたも FreeBSD のために貢献したくなりましたか? 素晴らしい! FreeBSD は生き残るためにユーザベースの貢献に頼っています。 あなたの貢献は感謝されるだけではなく、FreeBSD が成長し続けるために極めて重要なものなのです! 一部の人達が発言しているのとは反対に、 貢献を受け付けてもらうために腕利きのプログラマーになるとか FreeBSD コアチームの人と親友になる必要はありません。 多くのそして益々増加する世界中の貢献者達が FreeBSD を開発しており、 彼らの年齢、専門技術分野は多岐に渡っています。 手の空いている人よりも成すべき仕事の方が多く、 お手伝いはいつでも歓迎されています。 FreeBSD プロジェクトはカーネルや散在しているユーティリティよりも、 オペレーティングシステム環境に対して責任を持っています。 私たちの TODO リストには文書整備、 ベータテスト、インストーラや専門化されたタイプの カーネル開発の好例を紹介するなど非常に広い範囲の作業があります。 あなたの技能レベルや分野に関わらず、 プロジェクトを支援できることが必ず何かあります! FreeBSD 関連の事業に携わる商業団体が私たちにコンタクトすることも歓迎しています。 あなたの製品を (FreeBSD 上で) 動作させるには、 特別な拡張が必要ではありませんか? あまりにも風変わりな要求でなければ、 それを受け入れる用意が私たちにあるとわかるはずです。 付加価値のある製品ですか? 私たちに知らせてください! 多分私たちは、 ある面において共同して作業をすることができるでしょう。 フリーソフトウェア界は、 ソフトウェアがどのように開発され、 販売され、保守されていくかについて、既存の仮説に挑戦しています。 少なくとももう一度考慮してみることを私たちは強くお奨めします。 何が必要? 次の課題とサブプロジェクトの一覧は、色々な TODO リストとユーザからの要求を合わせたものです。 進行中の非プログラマ向けの課題 FreeBSD に関わっている中には、プログラマではない人が たくさんいます。プロジェクトには、文書を書く人、Web デザイナ、 サポートを行う人がいます。貢献するのに必要なのは、時間の投資と学ぶ 意欲です。 定期的に FAQ とハンドブックを通して読んでみてください。 もしまずい説明や古い事柄や完全に間違っていることなどがあれば 私達に教えてください。 さらに良いのは我々に修正案を送ることです (SGML は学ぶのにそれほど難しくありませんが、 プレインテキストでも問題はありません)。 FreeBSD の文書を自分の母国語に翻訳するのを手伝ってください。 文書がすでに存在すれば、もっと文書を翻訳したり、 その翻訳が最新の状態かどうか確認するのを手伝うことができます。 まず FreeBSD ドキュメンテーションプロジェクト入門の 翻訳に関する FAQ (よくある質問とその答え) を一読してください。 とはいっても、 そうすることによってあなたがすべての FreeBSD 文書の翻訳に携わるようになるわけではないですからね。 — ボランティアとして、 多少に関わらず、自分がやろうと思うだけやってください。 いったん誰かが翻訳を始めたら、 たくさんの人達がいつだって協力してくれますから。 もし翻訳に費す時間やエネルギーが限られているなら、 まずインストール方法の翻訳からお願いします (訳注: なぜなら、 もっとも必要とされている文書がそれだからです)。 たまに (もしくは定期的に) &a.questions; や &ng.misc; を読んでください。 これは、あなたの持っている専門知識を共有したり、 誰かが抱えている問題を解決するのに非常に有効なものになり得ることです。 時にはあなた自身で新しいことを学ぶことさえできるかもしれません。 これらのフォーラムはやるべきことのアイディアの源にもなり得るのです。 進行中のプログラマ向けの課題 このセクションで挙げる課題は膨大な時間の投資または FreeBSD のカーネルに関する深い知識、もしくは両方を必要とします。 しかしながら、週末ハッカー に適した立派な課題も 数多くあります。 FreeBSD-CURRENT を運用しており、 状態の良いインターネット接続があるならば、 current.FreeBSD.org という一日に一回フルリリースを行っているマシンがあります — 時おり最新のリリースをそこからインストールし、 その過程で何か問題があるなら報告してください。 &a.bugs; を読んでください。 そこではあなたが建設的なコメントを付けたりテストできるパッチが 提供されているような問題があるかもしれません。 もしくはそれらの問題の一つをあなた自身で 修正することさえできるかもしれません。 -CURRENT に正しく当てられるがしばらく経っても (通常は 2, 3 週間) -STABLE に取り込まれてないようなバグフィックスがあるならばコミッターに丁寧に思い出させてください。 寄贈ソフトウェアをソースツリーの src/contrib に移動させてください。 src/contrib 以下のコードが最新のものであるか確認してください。 警告を詳細に報告するようにしてソースツリー全体 (もしくはその一部) を構築してみてください。 そして警告が出ないようにしてください。 ports で、gets() を使っているとか malloc.h をインクルードしているなどといった警告が出ないようにしてください。 もしなんらかの ports に関わっているなら、 あなたのパッチを作者にフィードバックしてください (次のバージョンが出た時にあなたが楽になります)。 &posix; のような公式標準の写しを入手してください。 FreeBSD C99 & POSIX 標準適合プロジェクトのウェブサイトに、 そういった標準へのリンクがいくつかあります。FreeBSD の挙動を 標準が要求するものと比較してください。挙動が異なる場合、 特にそれが仕様の取るに足らなかったり分かりにくい細かい部分なら、 障害報告を提出してください。できればどう修正すべきか明らかにして、 障害報告にパッチをつけてください。標準が間違っていると感じたら、 標準化団体にその疑問を糺してください。 この一覧に追加する課題を提案してください! 障害報告 (PR; Problem Report) データベースにおける作業 障害報告 (PR) データベース FreeBSD 障害報告一覧では、現在問題となっている障害報告と、 FreeBSD の利用者によって提出された改良の要望すべての一覧を公開しています。 障害報告データベースには、プログラマ向けと非プログラマ向けの 課題が共に含まれています。 open 状態の障害報告を見て、興味を引くものがあるか確かめてください。 なかには、障害報告に対する修正が適切なものであるかどうか単に チェックするだけのとても簡単な作業もあるでしょうし、ずっと 複雑なものや、修正が含まれてすらいないものもあるでしょう。 まず、まだ誰にも割り当てられていない障害報告から作業を始めてください。 もし、誰か他の人に割り当てが決まっているけれども自分が作業可能だ、 という障害報告があれば、作業ができるかどうか — 既にテスト用パッチが用意されているのかどうか、あるいは その問題についてあなたが考えている、 より進んだ考えに関して議論ができるかどうか、 割り当てられている人に電子メールで問い合わせてください。 貢献の仕方 一般的に、システムへの貢献は次の 5 つのカテゴリの 1 つ以上に分類されます: バグ報告と一般的な論評 一般的な技術的関心事に関するアイデアや提案は &a.hackers; へメールしてください。同様に、このような事柄に興味のある (そして膨大なメール! に耐えられる) 人は、 &a.hackers; に参加すると良いでしょう。 このメーリングリストや他のメーリングリストに関する詳しい情報については FreeBSD ハンドブックを参照してください。 バグを発見したり変更を送付しようとしている場合は &man.send-pr.1; プログラムか ウェブベースの send-pr を使用して報告してください。 バグレポートの各項目を埋めるようにしてください。65KB を超えるのでなければ、 レポート中に直接パッチを入れてくださって結構です。 パッチがソースツリーにすぐ適用できるものならば、 報告の概要に [PATCH] と書いておいてください。 パッチを入れる場合、カット&ペーストはしないで ください。カット&ペーストではタブがスペースに展開されて パッチが使い物にならなくなってしまいます。 20KB を超える場合は、 それらを compress して &man.uuencode.1; することも検討してください。 レポートがファイリングされれば、 バグ報告の確認とトラッキング番号をメールで受け取るはずです。 このトラッキング番号を覚えておき、問題に関する詳細情報を FreeBSD-gnats-submit@FreeBSD.org に メールで送って更新できるようにしてください。たとえば "Re: kern/3377" のように、 この番号をサブジェクト行に使用してください。 すべてのバグレポートの追加情報は、 この方法で送付されなければいけません。 もしタイムリーに (あなたの電子メール接続形態にもよりますが、 3 日から 1 週間) 確認を受けとれないとか、何らかの理由で &man.send-pr.1; コマンドが使用できない場合には、&a.bugs; へメールを送り、 誰か代りにバグ報告を送付してもらうようたずねてください。 良い障害報告を書く方法についてはこの文書をご覧ください。 文書の変更 文書に関する提案 文書の変更は &a.doc; が監督しています。 完全な説明は、FreeBSD ドキュメンテーションプロジェクト入門をご覧ください。 バグ報告と一般的な論評 に記述されているように &man.send-pr.1; コマンドを使用して、提案や変更 (どんな些細なものでも歓迎します!) を送ってください。 現存のソースコードの変更 FreeBSD-CURRENT 現存のソースコードへの追加または変更は、 いくらかトリッキーな仕事であり、FreeBSD 開発の現状にあなたがどれだけ通じているかに大きく依存します。 FreeBSD-CURRENT として知られる FreeBSD の特別な継続的リリースがあります。FreeBSD-CURRENT は開発者の積極的な活動の便宜のために、 色々な方法で利用可能になっています。FreeBSD-CURRENT の入手と使用方法についての詳しい情報についてはFreeBSD ハンドブック を参照してください。 古いソースをもとに作業すると、残念ながらあなたの変更が 時として時代遅れもしくは大きく異なるものになってしまって、 FreeBSD に再統合するのは困難になる恐れがあります。 システムの現状に関する議論がおこなわれている &a.announce; と &a.current; へ参加すれば、この可能性を最小限にできます。 十分新しいソースを変更のベースにできることが確実になったと仮定して、 次のステップは FreeBSD の保守担当者へ送る差分ファイルの生成です。これは &man.diff.1; コマンドを使用しておこないます。 diff たとえば、 &prompt.user; diff -c oldfile newfile または &prompt.user; diff -c -r olddir newdir で、指定されたソースファイルまたはディレクトリ階層に対する コンテキスト形式の差分が生成されます。 同様に、 &prompt.user; diff -u oldfile newfile または、 &prompt.user; diff -u -r olddir newdir で、unified diff 形式である以外は同じ結果が得られます。 詳しい説明は &man.diff.1; のマニュアルページを参照してください。 差分ファイル (&man.patch.1; コマンドでテストできます) を作ったら、それらを FreeBSD に含めてもらうようメールで送ってください。バグ報告と一般的な論評 に記述されているように &man.send-pr.1; コマンドを使用してください。差分ファイルだけを &a.hackers; へ送ってはいけません。見過ごされてしまうでしょう。 あなたの提案は大歓迎です (これはボランティアのプロジェクトです!)。 私たちは多忙なのですぐに取りかかれないかもしれませんが、 それまで PR データベースに残っているでしょう。 報告の概要に [PATCH] と書いてあなたの提案を表明してください。 uuencode あなたがそうした方がいいと思う場合 (たとえば、 ファイルの追加、削除または名称変更など)、変更を tar ファイルにまとめ、&man.uuencode.1; プログラムにかけてください。&man.shar.1; アーカイブも歓迎します。 たとえば、再配布に適用される著作権の問題に自信がないとか、 より厳しいレビューを行わなければどうしてもリリースできない場合など、 あなたの変更が微妙な性質のものである可能性があれば、 &man.send-pr.1; で提出するよりむしろ直接 &a.core; へ送ってください。&a.core; 宛のメールは、 日々の仕事のかなりの割合を FreeBSD に割いている人たちの、 より小さなグループに届きます。 このグループもまたとても忙しいことに注意して、 本当に必要な場合だけコアチームにメールを送るようにしてください。 コーディングスタイルに関して &man.intro.9; および &man.style.9; を参照してください。コードを提出する前には、 少なくともこの情報を意識しておいてくださるようお願いします。 新たなコードやきわめて付加価値の高いパッケージ 大きな分量の作業成果の貢献や、重要な新しい機能を FreeBSD に追加する場合には、大抵、変更点を tar ファイルにまとめて uuencode して送るか、ウェブサイトや FTP サイトへアップロードして アクセスできるようにしなければなりません。 - web や FTP サイトへが利用できなければ、適切な FreeBSD の + web や FTP サイトが利用できなければ、適切な FreeBSD の メーリングリストで誰かその変更をおくサイトを提供してくれるよう 頼んでください。 大量のコードを扱っている時は、常に著作権に関する微妙な問題が 出てきます。FreeBSD に含めるコードの著作権として受け入れることが できるのは、以下の二つです。 BSD copyright BSD コピーライト。 このコピーライトは 権利に縛られない 性格と商用企業にとって一般的な魅力をもつために最も好まれます。 FreeBSD プロジェクトは商用利用を阻んだりせず、何かを FreeBSD へ投資する気になった商業関係者による参加を積極的に奨励します。 GPLGNU General Public License GNU General Public License GNU一般公有使用許諾、または GPL。 このライセンスはコードを商用目的に使用する場合に余分な努力が求められるため、 私たちにあまり評判が良いというわけではありません。しかし、 私たちは既に GPL 下の高品質なコード (コンパイラ、アセンブラ、テキストフォーマッタ等) の提供を受けており、私たちは現在それを必要としています。そのため、 このライセンスによる新たな貢献を拒絶するというのは愚かなことでしょう。GPL 下のコードはソースツリーの別の部分、現在のところ /sys/gnu か /usr/src/gnu に入っています。 そのため、GPL が問題となるような人は、 誰でも簡単にそれとわかるようになっています。 これ以外のタイプの著作権による寄贈は、FreeBSD へ含めることを考慮する前に注意深いレビューを受けなければなりません。 特に限定的な商用の著作権が適用される寄贈は一般に拒否されます。 しかし、作者が独自の経路でそのような変更を配布することは常に 奨励されています。 あなたの作品に BSD スタイル の著作権を付けるには、 保護したいソースコードファイルすべての一番最初に以下のテキストを入れて、 %% の間を適切な情報に置き換えてください。 Copyright (c) %%適切な年%% %%あなたの名前%%, %%あなたの州%% %%郵便番号%%. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer as the first lines of this file unmodified. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS SOFTWARE IS PROVIDED BY %%あなたの名前%% ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL %%あなたの名前%% BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. $Id$ 便宜をはかるため、 このテキストのコピーは次の場所に置いてあります。 /usr/share/examples/etc/bsd-style-copyright 訳注 以下は神田敏広氏より寄贈された bsd-style-copyright の日本語訳です。 ソースファイルに含めるものは原文の方であることに注意してご利用ください。 また、原文との間に趣旨の差異が生じた場合、 原文の内容が FreeBSD プロジェクトの意思であるものとします。 Copyright (C) [年] [あなたの名前] All rights reserved. ソースとバイナリ形式の再配布および使用は、変更の有無にかかわらず以下の 条件を満たす場合に限り許可される: 1. ソースコードの再配布は、上記の著作権表示・この条件のリスト・下記の 否認声明文を保持しなければならない。 2. バイナリ形式の再配布は上記の著作権表示・この条件のリスト・下記の 否認声明文を、配布物と共に提供される文書および/または他の資料の中に 含めなければならない。 (訳注:ここから「否認声明文」です) このソフトウェアは[あなたの名前]および貢献者によって ``あるがままの状態'' で提供され、商品性と特定の目的に対する適合性についての暗黙の保証に留ま らず、いかなる明示および暗黙の保証を認めない。[あなたの名前]および貢献 者は、あらゆる直接的・間接的・偶発的・特殊的・典型的・必然的な損害 (代 替製品または代替サービスの獲得費; 効用・データ・利益の喪失; または業務 中断を含み、またそれだけに留まらない損害) に対して、たとえどのようにし て生じたとしても、そしてこのソフトウェアの使用によってどのようにであれ 生じる、契約上であろうと、厳密な責任内であろうと、あるいは不正行為 (過 失やそうでない場合を含む) における場合であろうとも、いかなる責任論上も、 たとえそのような損害の可能性が予見されていたとしても、一切の責任を持た ない。 翻訳: 神田敏広 御協力 (五十音順・敬称略): 池田研二、内川 喜章、藤村 英治、むらたしゅういちろう 杢野 雅一、横田＠宇都宮 金銭、ハードウェアまたはインターネットアクセス 私たちは FreeBSD プロジェクトの目的を進めるための寄付を 常に喜んで受け入れています。私たちのようなボランティア活動では、 ちょっとしたことが大いに役立つのです! また一般的に、私たちは自前で周辺機器を買う資金が不足しているため、 周辺機器のサポートを充実させるのにハードウェアの寄付はとても重要です。 資金の寄付 FreeBSD 財団は、FreeBSD プロジェクトの目標を推進するために 設立された、非営利の、税金を免除された財団です。501(c)3 に 適合する団体として、財団はアメリカ合衆国連邦所得税ならびに コロラド州所得税を一般に免除されています。免税団体への寄付は、 多くの場合連邦政府の課税対象所得から控除できます。 寄付は小切手で以下に送ってください。
The FreeBSD Foundation 7321 Brockway Dr. Boulder, CO 80303 USA
また、寄付の受け付けを PayPal を通じて web 経由でできるようになりました。 寄付をするには、FreeBSD 財団の web サイトを ぜひご覧ください。 FreeBSD 財団に関するこれ以上の情報は The FreeBSD Foundation -- an Introduction を見てください。 財団への email での連絡は bod@FreeBSDFoundation.org へどうぞ。 ハードウェアの寄贈 寄贈 FreeBSD プロジェクトは適切な使い道のあるハードウェアの 寄付を喜んで受け入れています。ハードウェアを寄贈しようとしているなら、 寄贈品受付事務局に連絡してください。 インターネットアクセスの寄付 私たちは常に FTP、WWW や cvsup の新しいミラーサイトを募集しています。 ミラーサイトになりたい場合には Mirroring FreeBSD を見て、詳しい情報を手に入れてください。
diff --git a/ja_JP.eucJP/books/handbook/advanced-networking/chapter.sgml b/ja_JP.eucJP/books/handbook/advanced-networking/chapter.sgml index d549fc4739..d579c195fe 100644 --- a/ja_JP.eucJP/books/handbook/advanced-networking/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/advanced-networking/chapter.sgml @@ -1,2936 +1,2936 @@ 高度なネットワーク この章では 以下の章では、 UNIX システム上で良く利用されるネットワークサービスについて書かれています。 これはもちろん、 あなたの FreeBSD システムでの、 そのようなサービスの設定に関する内容です。 ゲートウェイとルート 原作: &a.gryphon;. 1995 年 10 月 6 日. 訳: &a.jp.yuki;. 1996 年 9 月 6 日. あるマシンが他のマシンをみつけることができるようにするには、 あるマシンから他のマシンへ、 どのようにたどり着くかを適切に記述するための仕組みが必要です。 この仕組みをルーティングと呼びます。 ルート(経路)は destination (目的地) と gateway (ゲートウェイ) の 2 つのアドレスの組で定義します。 あなたが destination へアクセスしようとした場合、 gateway を通って送られることをこのペアは示しています。 destination には個々のホスト、 サブネット、 デフォルト の 3つの タイプがあります。 デフォルトルート は他への経路が適用できない 場合に使われます。 のちほどデフォルトルートについて少し述べること するとして、 ここでは、 個々のホスト、 インタフェース (リンク とも呼ばれます)、 イーサネットハードウェアアドレスという 3つのタイ プのゲートウェイについて説明します。 例 以下に示す netstat -r の出力の例を使って、 ルーティン グがいろいろと異なっている様子を説明することにします。 Destination Gateway Flags Refs Use Netif Expire default outside-gw UGSc 37 418 ppp0 localhost localhost UH 0 181 lo0 test0 0:e0:b5:36:cf:4f UHLW 5 63288 ed0 77 10.20.30.255 link#1 UHLW 1 2421 foobar.com link#1 UC 0 0 host1 0:e0:a8:37:8:1e UHLW 3 4601 lo0 host2 0:e0:a8:37:8:1e UHLW 0 5 lo0 => host2.foobar.com link#1 UC 0 0 224 link#1 UC 0 0 最初の2行はデフォルトルート(次の節で詳しく説明します)と、 localhostへの経路を示しています。 localhostのためのインタフェース (Netifの欄) はlo0で、 これはループバックデバイスとして知られています。 結局のところ戻るだけなので、 この destinationへのすべてのトラフィックが 内部的に処理されるのであって、 LAN を経由して送られるのではありません。 次の行では 0:e0:... というアドレスに注目しましょう。 これはイーサネットハードウェアアドレスです。 FreeBSDは自動的に ローカルなイーサネット上の任意のホスト (この例ではtest0) を見つけ、 イーサネットインタフェース ed0 の所にそのホストへの経路を直接つけ加えます。 タイムアウト時間 (Expireの 欄) も経路のタイプと結びついており、 指定された時間が経過しても応 答がないときに使用します。 この場合、 経路情報は自動的に削除されま す。 これらのホストは、 RIP(Routing Information Protocol) という、 最短パスの判定に基づいてローカルホストへの経路を 決定する仕組みを利用することで認識されます。 更に、 FreeBSDではローカルサブネット (10.20.30.255 は 10.20.30 というサブネットに対するブロードキャストアドレスで、 foobar.com はこのサブネットに結びつけられているドメイン名) への経路情報も加えることができます。 link#1というのは、 このマシンの最初のイーサネットカードのことをさします。 これら については、 何も追加インタフェースが指定されていないことに気づく でしょう。 これらの2つのグループ(ローカルネットワークホストと ローカルサブネット) の両方とも、 routed と呼ばれるデーモンによって自動的に経路が設定されます。 routed を動かさなければ、 静的に定義した (つまり具体的に設定した) 経路のみ存在することになります。 host1 の行は私たちのホストのことで、 イーサネットアドレスで示されています。 送信側のホストの場合、 FreeBSDはイーサネットインタフェースへ送るのではなく、 ループバックインタフェース (lo0)を使います。 2つあるhost2の行は、 ifconfigのエイリアス (このようなことをする理由については ethernetの章を参照してください) を使ったとき にどのようになるかを示す例です。 lo0の後にある=> は、 インタフェースが (このアドレスがローカルなホストを参照しているので) ループバックを使っているというだけでなく、 エイリアスになっていることも示しています。 このような経路はエイリアスをサポートしている ホストにのみ現れます。 ローカルネットワーク上の他のすべてのホストでは 単にlink#1となります。 最後の行 (destinationが224のサブネット) はマルチキャストで扱うものですが、 これは他の章で説明します。 他の欄については Flags について説明する必要があります。 それぞれの経路は欄に示されているように違った属性を もっています。 以下にいくつかのフラグとこれらが何を意味しているかを示します。 U Up: この経路はアクティブです。 H Host: 経路の destinationが単一のホストです。 G Gateway: この destinationへ送られると、 どこへ送れ ばよいかを明らかにして、 そのリモートシステムへ送られます。 S Static: この経路はシステムによって自動的に生成 されたのではなく、 手動で作成されました。 C Clone: マシンに接続したときにこの経路に基づく 新しい経路が作られます。 このタイプの経路は通常は ローカルネットワークで使われます。 W WasCloned: ローカルエリアネットワーク(Clone) の経路に基づいて 自動的に生成された経路であることを示します。 L Link: イーサネットハードウェアへの参照を含む 経路です。 デフォルトルート ローカルシステムからリモートホストにコネクションを張る 必要がある場合、 既知のパスが存在するかどうかを確認するためにル ーティングテーブルをチェックします。 到達するためのパスを知っているサブネットの内部に リモートホストがある場合 (Cloned routes)、 システムはインタフェース から接続できるかどうかをチェックします。 知っているパスがすべて駄目だった場合でも、 システムには 最後の切り札の デフォルト ルートがあります。 このルートは ゲートウェイルート (普通はシステムに 1つしかありません) の特別なものです。 そして、 フラグフィールドは必ず c がマークされています。 このゲートウェイは、 LAN 内のホストにとっ て、 外部 (PPPのリンクを経由する場合や、 データラインに接続するハードウェアデバイスなど) へ直接接続するマシンすべてのためのものです。 外部に対するゲートウェイとして機能するマシンで デフォルトルートを設定する場合、 デフォルトルートはインターネットサービスプロバイダ (ISP) のサイトのゲートウェイマシンになるでしょう。 それではデフォルトルートの一例を見てみましょう。 一般的な構成を示します。 [Local2] <--ether--> [Local1] <--PPP--> [ISP-Serv] <--ether--> [T1-GW] ホスト Local1 とホスト Local2 を PPP で ISP のターミナルサーバと接続されているあなたの サイトだとします。 ISP はサイト内にロー カルなネットワークを持っていて、 そこにはまざまなものがあり、 あなたの接続するサーバや ISP のインターネットへの 接続点であるハードウェアデバイス (T1-GW) などがあります。 あなたのマシンのデフォルトルートは それぞれ次のようになります。 host default gateway interface Local2 Local1 ethernet Local1 T1-GW PPP なぜ (あるいは、 どうやって) Local1 の デフォルトゲートウェイをISPのサーバでなく T1-GWにセットするのか という質問がよくあります。 コネクションのローカルの側については、 PPPのインタフェースは ISPのローカルネットワーク上のアドレスを用いているため、 ISPのローカルネットワーク上のすべてのマシンへの経路は 自動的に生成されています。 つまり、 あなたのマシンは、 どのようにT1-GW まで届くかという経路を既に知っていることになりますから、 ISPサーバに媒介的なトラフィックをかける必要はありません。 最後になりましたが、 一般的にローカルネットワークでは ...1 というアドレスをゲートウェイアドレスとして使います。 ですから (同じ例を用います)、 あなたのclass-Cのアドレス空間が 10.20.30で ISPが 10.9.9を用いている場合、 デフォルトルートは次のようになります。 Local2 (10.20.30.2) --> Local1 (10.20.30.1) Local1 (10.20.30.1, 10.9.9.30) --> T1-GW (10.9.9.1) マルチホームホスト ここで扱うべき他のタイプの設定があります。 それは2つの異なるネットワークにまたがるホストです。 技術的にはゲートウェイとして機能するマシン (上 の例では PPPコネクションを用いています) はマルチホームホストで す。 しかし実際にはこの言葉は、 2つのローカルエリアネットワーク上のサ イトであるマシンを指す言葉としてのみ使われます。 2枚のイーサネットカードを持つマシンが、 別のサブネット 上にそれぞれアドレスを持っている場合があります。 あるいは、 イーサネットカードを1枚持っているマシンで、 ifconfigのエイリアスを使っているかもしれません。 物理的に分かれている2つのイーサネットのネットワークが使われて いるならば前者が用いられます。 後者は、 物理的には1つのネットワ ークセグメントで、 論理的には分かれている 2つのサブネットとする 場合に用いられます。 どちらにしても、 このマシンがお互いのサブネットへのゲートウェイ (inbound route) として定義されていることが分かるように、 おのお ののサブネットでルーティングテーブルを設定します。 このマシンが 2 つのサブネットの間のブリッジとして動作するという構成は、 パケ ットのフィルタリングを実装する必要がある場合や、 一方向または双 方向のファイアウォールを利用したセキュリティを構築する場合によ く用いられます。 ルーティングの伝播 すでに外部との経路をどのように定義したらよいかは 説明しました。 しかし外部から私たちのマシンをどのようにして 見つけるのかについては説明していません。 ある特定のアドレス空間 (この例では class-C のサブネット) におけるすべてのトラフィックが、 到着したパケットを内部で転送するネ ットワーク上の特定のホストに送られるようにルーティングテーブル を設定することができるのは分かっています。 あなたのサイトにアドレス空間を割り当てる場合、 あなたのサブネットへのすべてのトラフィックがすべて PPPリンクを通じてサイトに送 ってくるようにサービスプロバイダはルーティングテーブルを設定し ます。 しかし、 国境の向こう側のサイトはどのようにしてあなたの ISPへ送ることを知るのでしょうか? 割り当てられているすべてのアドレス空間の経路を維持する (分散している DNS 情報とよく似た) システムがあり、 そのインターネット バックボーンへの接続点を定義しています。 バックボーン とは国を越え、 世界中のインターネットのトラフィックを運ぶ主要 な信用できる幹線のことです。 どのバックボーンマシンも、 あるネットワークから特定のバックボーンのマシンへ 向かうトラフィックと、 そのバックボーンのマシンからあなたのネットワークに届くサービス プロバイダまでのチェーンのマスタテーブルのコピーを持っていま す。 あなたのサイトが接続(プロバイダからみて内側にある ことになります) したということを、 プロバイダからバックボー ンサイトへ通知することはプロバイダの仕事です。 これが経 路の伝搬です。 トラブルシューティング ルーティングの伝搬に問題が生じて、 いくつかのサイトが 接続をおこなうことができなくなることがあります。 ルーティングがどこでおかしくなっているかを明らかにするのに 最も有効なコマンドはおそらく &man.traceroute.8; コマンドでしょ う。 このコマンドは、 あなたがリモートマシンに対して接続をおこなう ことができない(例えば &man.ping.8; に失敗するような場合) 場合も、 同じように有効です。 &man.traceroute.8; コマンドは、 接続を試みているリモートホストを引数にして実行します。 試みているパスの経由するゲートウェイホストを表示し、 最終的には目的のホストにたどり着くか、 コネクションの欠如によって終ってしまうかのどちら かになります。 より詳しい情報は、 &man.traceroute.8; のマニュアルページをみてください。 Bridging Written by Steve Peterson steve@zpfe.com. はじめに IP サブネットを作成し、 それらのセグメントをルータを 使って接続したりせずに、 (Ethernet セグメントのような) 物理ネットワークを二つのネットワークセグメントに分割することは とても有効な場合があります。 このような二つのネットワークを繋ぐデバイスはブリッジと呼ばれます。 そして、 二つのネットワークインタフェイスカードを持つ FreeBSD システムは、 ブリッジとして動作することができます。 ブリッジは、 各ネットワークインタフェイスに繋がる デバイスの MAC 層のアドレス (例えば Ethernet アドレス) を記憶します。 ブリッジはトラフィックの送信元と受信先が異なったネットワーク上に ある場合にのみ、 トラフィックを転送します。 すなわち、 ブリッジはポート数の少ない Ethernet スイッチ だ、 ということができます。 ブリッジがふさわしい状況とは 今日ブリッジが活躍する場面は大きく分けて二つあります。 トラフィックの激しいセグメント ひとつは、 物理ネットワークセグメントがトラフィック 過剰になっているが、 なんらかの理由によりネットワークを サブネットに分け、 ルータで接続することができない場合です。 編集部門と製作部門がおなじサブネットに同居している 新聞社を例に考えてみましょう。 編集部門のユーザはファイルサーバとして全員サーバ A を利用し、 製作部門のユーザはサーバ B を利用します。 すべてのユーザを接続するのには Ethernet が使われており、 高負荷となったネットワークは遅くなってしまいます。 もし編集部門のユーザを一つのネットワークセグメントに 分離することができ、 製作部門もユーザも同様にできるのなら、 二つのネットワークセグメントをブリッジで繋ぐことができます。 ブリッジの "反対" 側へ向かうネットワークトラフィックだけが 転送され、 各ネットワークセグメントの混雑は緩和されます。 パケットフィルタ/帯域制御用ファイアウォール もうひとつは、 IP Masquerading (NAT) を使わずに ファイアウォール機能を利用したい場合です。 ここでは DSL もしくは ISDN で ISP に接続している 小さな会社を例にとってみましょう。 この会社は ISP から 13 個のグローバル IP アドレスの割り当て を受けており、 ネットワーク内には 10 台の PC が存在します。 このような状況では、 サブネット化にまつわる問題から ルータを用いたファイアウォールを利用することは困難です。 ブリッジを用いたファイアウォールなら、 IP アドレスの問題を気にすること無く、 DSL/ISDN ルータの 下流側に置くように設定できます。 ブリッジを設定する ネットワークインタフェイスカードの選択 ブリッジを利用するには少なくとも二つのネットワークカードが 必要です。 残念なことに、 FreeBSD 4.0 ではすべてのネットワークインタフェイス カードがブリッジ機能をサポートしているわけではありません。 カードがサポートされているかどうかについては &man.bridge.4; を参照してください。 以下に進む前に、 二つのネットワークカードをインストールして テストしてください。 カーネルコンフィグレーションの変更 カーネルでブリッジ機能を有効にするには options BRIDGE という行をカーネルコンフィグレーションファイルに追加して カーネルを再構築してください。 ファイアウォール機能 ブリッジと同時にファイアウォール機能も利用しようとしている 場合には、 IPFIREWALL オプションも指定する必要があります。 ブリッジをファイアウォールとして設定する際の一般的な 情報に関しては、 を参照してください。 IP 以外のパケット (ARP など) がブリッジを通過するように するためには、 ドキュメント化されていないファイアウォール用 オプションを設定する必要があります。 このオプションは IPFIREWALL_DEFAULT_TO_ACCEPT です。 この変更により、 デフォルトではファイアウォールがすべての パケットを accept するようになることに注意してください。 この設定を行う前に、 この変更が自分のルールセットにどのような 影響をおよぼすかを把握しておかなければなりません。 帯域制御機能 ブリッジで帯域制御機能を利用したい場合、 カーネルコンフィグレーションで DUMMYNET オプションを加える必要があります。 詳しい情報に関しては &man.dummynet.4; を参照 してください。 ブリッジを有効にする ブリッジを有効にするには、 /etc/sysctl.conf に以下の行を加えてください: net.link.ether.bridge=1 ブリッジを経由したパケットを ipfw でフィルタしたい場合には、 net.link.ether.bridge_ipfw=1 という行も付け加える必要があります。 パフォーマンス 私のブリッジ/ファイアウォールは Pentium 90 で、 3Com 3C900B と 3c905B を使っています。 防護される側のネットワークは 10Mbps の half duplex で、 ブリッジとルータ (Cisco 675) の間は 100Mbps full duplex で 動作しています。 パケットフィルタを利用しない場合、 防護されている 10Mbps ネットワークから Cisco 675 への ping では、 ブリッジにより 0.4 ミリ秒の遅延が発生しています。 その他の情報 ネットワークからブリッジに telnet したい場合、 ネットワークカードの一つに IP アドレスを割り当てれば OK です。 一般的に、 両方のカードに IP アドレスを割り当てるのは よいアイデアではないとされています。 ネットワーク内に複数のブリッジを設置する場合、 任意のワークステーション間で一つ以上の経路を持つことは できません。 技術的には、 これは spanning tree link management はサポートされていない、 ということを意味します。 NFS Written by &a.unfurl;, 4 March 2000. FreeBSD がサポートしている多くのファイルシステムの中でも、 NFS、 すなわち Network File System は極めてユニークな存在です。 NFS はあるマシンから他のマシンへと、 ネットワークを通じて ディレクトリとファイルを共有することを可能にします。 NFS を使うことで、 ユーザやプログラムはリモートシステムのファイルを、 それがローカルファイルであるかのようにアクセスすることができます。 NFS には以下の利点があります: 一般的に使われるデータを単一のマシンに納める ことができ、 ネットワーク上のユーザはデータにアクセスできる ため、 ローカルワークステーションは多くのディクスを 必要としません。 ネットワーク上のすべてのマシンに、 ユーザが独自のホームディレクトリを持つ必要がありません。 一旦 NFS 経由でアクセスできるディレクトリができれば、 どこからでもアクセス可能です。 フロッピーや CD-ROM ドライブなどのストレージデバイスを、 追加のハードウェアなしにネットワーク上の他のマシンに 使ってもらうことができます。 どのようにして動作するのか NFS はクライアント、 サーバの二つの部分から 構成されます。 これは 需要(want)/供給(have) の関係として考えることができます。 クライアントはサーバが 供給 している データに対する 需要 があります。 サーバはそのデータをクライアントと共有します。 このシステムが適切に機能するために、 いくつかのプロセスが 設定され正しく動作していなければなりません。 サーバは以下のデーモンを動作させなければなりません: nfsd - NFS クライアントからの リクエストを処理する NFS デーモン。 mountd - nfsd から渡された リクエストを実際に実行する NFS マウントデーモン。 portmap - NFS サーバの利用しているポートを NFS クライアントから取得できるようにするためのポートマッパデーモン。 クライアント側ではデーモンを一つ実行する必要があります: nfsiod - NFS サーバからのリクエストを 処理する NFS 非同期 I/O デーモン。 NFS を設定する 幸運なことに、 FreeBSD システムで設定を行うのは簡単です。 実行させなければならないプロセスは、 /etc/rc.conf ファイルをちょっと編集することでブート時から実行させる ことができます。 NFS サーバでは、 以下の設定が必要です: portmap_enable="YES" nfs_server_enable="YES" nfs_server_flags="-u -t -n 4" mountd_flags="-r" mountd は NFS サーバが有効になっている 場合、 自動的に実行されます。 nfsd への 、 フラグは クライアントに UDP と TCP のサービスを提供することを指示します。 フラグは nfsd が 4 つのコピーを立ち上げることを指示します。 クライアント側では、 以下のようにします: nfs_client_enable="YES" nfs_client_flags="-n 4" nfsd と同様に、 は nfsiod が 4 つのコピーを立ち上げることを指示します。 最後に /etc/exports という 設定ファイルを作成します。 exports ファイルはサーバのどのファイルシステムが 共有されるのか (exported といいます)、 またどのクライアントが共有できるのかを指定します。 ファイル中の各行は、 共有されるファイルシステムを 指定します。 ファイル中で指定できるオプションはたくさんありますが、 そのうちの少ししか使うことはないでしょう。 より細かいことに関しては &man.exports.5; マニュアルページをお読み下さい。 いくつか /etc/exports の設定例 を示します: 以下の設定は、 サーバと同じドメイン名(ドメイン名が無いので)か、 /etc/hosts に記述のある三つのマシン に対して、 /cdrom を export します。 オプションは共有されるファイルシステムを 読み込み専用にします。 このフラグにより、 リモートシステムは共有されたファイルシステム にたいして何の変更も行えなくなります。 /cdrom -ro moe larry curly 以下の設定は、 IP アドレスによる三つのホストに対して /home を export します。 この設定はプライベートネットワークで DNS が走っていない 場合に便利な設定でしょう。 フラグは指定されたファイルシステム 以下のディレクトリに対しても同様に export します。 /home -alldirs 10.0.0.2 10.0.0.3 10.0.0.4 以下の設定は、 サーバとは異なるドメイン名の二つの マシンに対して /a を export します。 フラグは、 リモートマシンの root ユーザが共有されたファイルシステムに root として書き込むことを 許可します。 -maproot=0 フラグが無ければ、 リモートマシンの root 権限を 持っていても共有されたファイルシステム上のファイルを変更する ことはできません。 /a -maproot=0 host.domain.com box.example.com クライアントが export されたファイルシステムを共有 する際には、 そのような権限が与えられていなければなりません。 /etc/exports ファイルに クライアントが含まれているかどうか確認してください。 必要な変更はすべて行ったので、 FreeBSD を再起動してブート時からすべてが起動するようにするか、 root で以下のコマンドを実行します: NFS サーバでは: &prompt.root; portmap &prompt.root; nfsd -u -t -n 4 &prompt.root; mountd -r NFS クライアントでは: &prompt.root; nfsiod -n 4 これでリモートのファイルシステムを実際にマウントする 準備ができました。 やり方は二通りあります。 この例では、 サーバの名前は server で、 クライアントの名前は client とします。 リモートファイルシステムを一時的にマウントするだけ、 もしくは設定をテストするだけなら、 クライアント上で root として以下のコマンドを実行してください: &prompt.root; mount server:/home /mnt これにより、 クライアントの /mnt ディレクトリにサーバの /home が マウントされます。 もしすべてが正しく設定されていれば、 クライアントの /mnt に、 サーバにあるファイルすべてが見えるようになっているはずです。 リモートファイルシステムを今後も (リブートする度に) マウントしたいなら、 /etc/fstab ファイルに設定を追加する必要があります。 例としてはこのようになります: server:/home /mnt nfs rw 0 0 ほかのオプションに関しては &man.fstab.5; マニュアル ページをお読み下さい。 典型的な使い方 NFS にはいくつかすてきな使い方があります。 私は自分が管理している LAN でそれらを利用しています。 そのうちにいくつかをここで紹介しましょう。 ネットワークには幾つかのマシンがありますが、 CD-ROM ドライブを持っているのは一台だけです。 なぜかって? それは一台の CD-ROM ドライブをほかのマシンと NFS 経由で共有しているからです。 フロッピードライブについても同じことがいえます。 ネットワーク内に多くのマシンがあると、 様々な場所に ちらばる個人的なファイルは日に日に古くなってしまいます。 私はすべてのユーザのホームディレクトリを格納する、 中心となる NFS サーバを用意し、 LAN 上の残りのマシンと 共有しています。 そうすることで、 どこにログインしても、 同じホームディレクトリを使うことができるのです。 マシンのひとつに FreeBSD を再インストールするなら、 NFS こそその方法です。 ディストリビューション CD をファイル サーバに入れ、 再インストールを実行するだけです。 共用の /usr/ports/distfiles ディレクトリを用意して、 すべてのマシンで共有しています。 この方法だと、 別のマシンで既にインストールしたことのある port をインストールする場合、 再びすべてのソースをダウンロードする 必要がなくなります。 Problems integrating with other systems 原作: John Lind john@starfire.MN.ORG. 訳: &a.jp.tomo;. 6 September 1996. ISA用のイーサネットアダプタの中には性能が悪いため、 ネットワーク、 特に NFS で深刻な問題がおきるものがあります。 これは FreeBSD に限ったことではありませんが、 FreeBSD でも起こり得ます。 この問題は、 (FreeBSDを使用した) PC がシリコン・グラフィックス社や サン・マイクロシステムズ社などの高性能な WS にネットワーク接続されている場合に頻繁に起こります。 NFS マウントはうまく行きます。 また、 いくつかの操作もうまく働きますが、 他のシステム (WS) に対する要求や応答は続いていても、 突然サーバが クライアントの要求に対して反応しなくなります。 これは、 クライアントが FreeBSD か上記の WS であるとき、 にクライアント側に起きる現象です。 多くのシステムでは、 いったんこの問題が現われると、 行儀良くクライアントを終了する手段はありません。 NFS がこの状態に陥ってしまうと、 正常に戻すことはできないため、 多くの場合、 クライアントを強制終了し、 再び実行することが唯一の解決法となります。 正しい解決法は、 より高性能のイーサネットアダプタをFreeBSDシステムに インストールすることですが、 満足な操作ができるような簡単な方法があります。 もし、 FreeBSDシステムがサーバになるのなら、 クライアントからのマウント時に オプションをつけて下さい。 もしFreeBSDシステムがクライアントになる のなら、 NFSファイルシステムを オプションつきでマウントして下さい。 これらのオプションは自動的にマウントをおこなう場合には クライアントの fstab エントリの4番目のフィールドに指定してもよいですし、 手動マウントの場合は mount コマンドの パラメータで指定してもよいでしょう。 NFSサーバとクライアントが別々のネットワーク上にあるような 場合、 これと間違えやすい他の問題が起きることに注意して下さい。 そのような場合は、 ルータが必要な UDP 情報をきちんと ルーティングしているかを確かめて下さい。 そうでなければ、 たとえあなたが何をしようと解決できないでしょう。 次の例では、 fastwsは高性能のWSのホスト (インタフェース)名で、 freeboxは低性能のイーサネットアダプタを備えた FreeBSDシステムのホスト(インタフェース)名です。 また、 /sharedfs はエクスポートされる NFS ファイルシステムであり (man exports を見て下さい)、 /project はエクスポートされたファイルシステムの クライアント上のマウントポイントとなります。 全ての場合において、 や 、 といった追加オプションが アプリケーションにより要求されるかもしれないことに 注意して下さい。 クライアント側 FreeBSD システム (freebox) の例は: freebox の /etc/fstab に次のように書いて下さい: fastws:/sharedfs /project nfs rw,-r=1024 0 0 freebox 上で手動で mount コマンドを実行する場合は次のようにして下さい: &prompt.root; mount -t nfs -o -r=1024 fastws:/sharedfs /project サーバ側FreeBSDシステムの例は: fastws の /etc/fstab に次のように書いて下さい: freebox:/sharedfs /project nfs rw,-w=1024 0 0 fastws 上で手動で mount コマンドで実行する場合は次のようにして下さい: &prompt.root; mount -t nfs -o -w=1024 freebox:/sharedfs /project 近いうちにどのような 16 ビットのイーサネットアダプタでも 上記の読み出し、 書き込みサイズの制限なしの操作ができるようになるでしょう。 失敗が発生したとき何が起きているか関心のある人に、 なぜ回復不可能なのかも含めて説明します。 NFSは通常 (より小さいサイズへ分割されるかもしれませんが) 8Kのブロック サイズで働きます。 イーサネットのパケットサイズは最大1500バイト程度なので、 上位階層のコードにとっては1つのユニットのままなのですが、 NFS ブロックは 複数のイーサネットパケットに分割されます。 そして受信され、 組み立て直されてから肯定応答 されなければなりません。 高性能のWSは次々に NFSユニットを構成するパケットを、 基準の範囲内で間隔を詰めて次々に送り出すことができます。 小さく、 容量の低いカードでは、 同じユニットの 前のパケットがホストに転送される前に、 後のパケットがそれを 踏みつぶしてしまいます。 このため全体としてのユニットは再構成もされないし、 肯定応答もされません。 その結果、 WSはタイムアウトして再送を試みますが、 8Kのユニット全体を再送しようとするので、 このプロセスは 際限無く繰り返されてしまいます。 ユニットサイズをイーサネットのパケットサイズの 制限以下に抑えることにより、 受信された完全な イーサネットパケットは個々に肯定応答を受けられることが 保証されるので、 デッドロック状態を避けることができるようになります。 高性能のカードを使っている場合でも、 高性能な WS が力任せに次々と PC システムにデータを送ったときには 踏みつぶし が起きるかもしれません。 そのような踏みつぶし は NFS ユニット では保証されていません。 踏みつぶしが起こったとき、 影響を受けたユニットは再送されます。 そして受信され、 組み立てられ、 肯定応答される公平な機会が与えられるでしょう。 Diskless operation 原作: &a.martin; 訳: &a.jp.yasu; netboot.com/netboot.rom によって、 ディスクのないクライアントでネットワーク経由で FreeBSD マシンのブートを行い FreeBSD を走らせることができます。 2.0 ではローカルなスワップを持つことができます。 NFS 経由のスワッピングもサポートされています。 サポートされているイーサネットカード: Western Digital/SMC 8003, 8013, 8216 とその互換ボード, NE1000/NE2000 とその互換カード (再コンパイルが必要) セットアップの手順 サーバにするマシンを見つけます。 このマシンには、 FreeBSD 2.0のバイナリとbootpを 記憶するだけの十分なディスクスペースが必要です。 tftp と NFS も使えます。 テストしたマシン: HP9000/8xx / HP-UX 9.04以降 (9.04以前では動きません) Sun/Solaris 2.3. (bootpが必要) クライアントにIP、gateway、netmaskを提供する bootpサーバをセットアップします。 diskless:\ :ht=ether:\ :ha=0000c01f848a:\ :sm=255.255.255.0:\ :hn:\ :ds=192.1.2.3:\ :ip=192.1.2.4:\ :gw=192.1.2.5:\ :vm=rfc1048: クライアントにブート情報を提供する TFTP サーバを (bootp サーバと同じマシンに) セットアップします。 このファイルの名前は、 cfg.X.X.X.X (もしくは /tftpboot/cfg.X.X.X.X )で、 ここで X.X.X.X はクライアントの IP アドレスです。 このファイルの内容は netboot コマンドで有効です。 2.0では、 netboot は以下のようなコマンドを持ちます: help helpリストの表示 ip クライアントのIPアドレスの表示/セット server bootp/tftp サーバのアドレスの表示/セット netmask netmaskの表示/セット hostname name hostnameの表示/セット kernel カーネル名の表示/セット rootfs root ファイルシステムの表示/セット swapfs swap ファイルシステムの表示/セット swapsize diskless swapsize を KBytes単位でセット diskboot ディスクからのブート autoboot ブートプロセスの続行 trans | トランシーバのオン|オフ flags ブートフラグの設定 完全にディスクレスな場合の一般的な cfg ファイルは以下のようになります: rootfs 192.1.2.3:/rootfs/myclient swapfs 192.1.2.3:/swapfs swapsize 20000 hostname myclient.mydomain ローカルに swap を持つマシンについては以下のようになります: rootfs 192.1.2.3:/rootfs/myclient hostname myclient.mydomain NFS サーバがクライアントにroot(必要ならswapも) ファイルシステムをexportしているか、 また、 クライアントがこれらのファイルシステムに ルートアクセスできるか確認します。 FreeBSDにおける一般的な /etc/exports ファイルは 以下のようになります: /rootfs/myclient -maproot=0:0 myclient.mydomain /swapfs -maproot=0:0 myclient.mydomain そして、 HP-UX側では以下のようになります: /rootfs/myclient -root=myclient.mydomain /swapfs -root=myclient.mydomain NFS経由でスワッピングを行う場合 (完全にディスクレスな場合の設定)、 クライアントが使用する swap ファイルを dd で作成します。 もし、 swapfs コマンドが上記の例のように 引数 /swapfsを持ちそのサイズが 20000 である場合、 myclientに対するスワップファイルは /swapfs/swap.X.X.X.X で呼び出されます。 ここで X.X.X.X はクライアントの IP アドレスです。 例: &prompt.root; dd if=/dev/zero of=/swapfs/swap.192.1.2.4 bs=1k count=20000 また、 スワッピングが開始されるとクライアントの スワップスペースはセンシティブな情報を含むようになるので、 不正なアクセスを防止するため、 このファイルへの 読み書きのアクセス制限がなされていることを確認して下さい: &prompt.root; chmod 0600 /swapfs/swap.192.1.2.4 クライアントがそれぞれのrootファイルシステムとして使う ディレクトリにrootファイルシステムを展開します (上記の例では/rootfs/myclient)。 HP-UX システム: サーバはHP9000/800 シリーズのマシンで、 HP-UX 9.04 以降が必要です。 これ以前のバージョンでは NFS を経由するデバイスファイルが作成ができません。 /rootfs/myclient に /dev を 展開する際に、 いくつかのシステム (HPUX) では FreeBSD に合った デバイスファイルが作成されないので 注意してください。 その際には最初の起動時にシングルユーザモードに 移行して (ブートの段階でCtrl-Cを押す)、 /dev に移って sh ./MAKEDEV all として、 クライアントからこれを 修正してください。 クライアントで netboot.com を実行するか、 netboot.rom ファイルから EPROMを作成します。 <filename>/</filename> および <filename>/usr</filename> ファイルシステムを共有して使用する 今のところ、 これを行う公式に認められた方法はありませんが、 私はそれぞれのクライアントで /usr ファイルシステムと個々の / ファイルシステムを共有して使っています。 どなたかこれをきちんと行うやり方の提案がありましたら、 私に、 もしくは &a.core; グループに知らせてください。 特定の設定についてnetbootをコンパイルする /sys/i386/boot/netboot/Makefile の中の設定を変更して コンパイルすることで、 netbootでNE1000/2000 カードをサポートします。 このファイルの先頭にあるコメントを見てください。 ISDN 最終更新: Bill Lloyd wlloyd@mpd.ca. 訳: &a.jp.kiroh;. 11 December 1996. ISDN 技術とハードウェアに関しては、 Dan Kegel's ISDN Page がよい参考になるでしょう。 ISDN の導入手順は、 簡単にいって以下のようになります。 ヨーロッパ在住の方は、 ISDN カードの節に進んでください。 ISDN を使って、 インターネットプロバイダに(専用線は使用せず)、 ダ イアルアップ接続しようとしている場合は、 ターミナルアダプタの使用を考えてみてください。 この方法はもっとも柔軟性があり、 プロバイダを変更した場 合の問題も少ないでしょう。 2つの LAN の間を接続しようする場合や、 ISDN 専用線を使用する場合 には、 スタンドアローンルータ/ブリッジの使用を勧めます。 どの方法を用いるかを決定するには、 費用が重要な要素になってきます。 以下に、 最も安価な方法から、 高価な方法まで順に説明していきます。 ISDN カード 著者:&a.hm;. このセクションの記述は、 DSS1/Q.931 ISDN 標準がサポートされている国のユーザにのみ有効です。 最近増えてきている PC ISDN カードのうちいくつかは、 FreeBSD 2.2.x 以降で isdn4bsd ドライバパッケージによりサポートされています。 依然として開発中ではありますが、 ヨーロッパ中でうまく動作しているという報告があります。 最新の isdn4bsd は、 ftp://isdn4bsd@ftp.consol.de/pub/ から入手できます。 この ftp サイトでは、 ユーザ名として isdn4bsd を使い、 パスワードにメールアドレスを使ってログインする 必要があります。 ログインできたら pub ディレクトリに移動してください。 ユーザー名 ftp や anonymous によるログインでは、 必要なファイルにたどりつけません。 isdn4bsd は、 IP over raw HDLC もしくは同期 PPP を利用して他の ISDN ルータと接続できます。 留守番電話アプリケーションも使えます。 Siemens ISDN チップセット (ISAC/HSCX) を使用したものを主に多くのカードがサポートされています。 他のチップセット (Motorola、 Cologn ChipDesigns) のサポートは現在開発中です。 サポートされるカードの最新のリストは、 README を参照してください。 他の ISDN プロトコルを追加したい場合や、 サポートされていない ISDN PC カード サポートしたい場合など isdn4bsd を拡張したい場合は、 hm@kts.org までご連絡ください。 majordomoによるメーリングリストが利用できます。 参加するには、 本文に subscribe freebsd-isdn と記入したメールを &a.majordomo; 宛てに送ってください。 ISDN ターミナルアダプタ ターミナルアダプタ (TA) はISDN に対して、 通常の電話線に対するモデムに相当するものです。 ほとんどの TA は、 標準のヘイズ AT コマンドセットを使用しているので、 単にモデムと置き換えて使うことができます。 TA は、 基本的にはモデムと同じように動作しますが、 接続方法は異なり、 通信速度も古いモデムよりはるかに速くなります。 PPP の設定を、 モデムの場合と同じように行ってください。 とくにシリアル速度を 使用できる最高速度に設定するのを忘れないでください。 プロバイダへの接続に TA を使用する最大のメリットは、 動的 PPP を行えることです。 最近 IP アドレスが不足してきているため、 ほとんどのプロバイダは、 専用の IP アドレスを割り当てないようになっています。 ほとんどのスタンドアローンルータは、 動的 IP アドレスに対応していません。 訳注: 最近の ISDN ルータでは、 IP アドレスの動的割り当てに対応しているものも多いようです。 ただし制限がある場合もありますので、 詳しくはメーカ に問い合わせてください。 TA を使用した場合の機能や接続の安定性は、 使用している PPP デーモンに完全に依存します。 そのため、 FreeBSD で PPP の設定が完了していれば、 使用している既存のモデムを ISDN の TA に簡単にアップグレードすることができます。 ただし、 それまでの PPP のプログラムに問題があった場合、 その問題は TA に置き換えてもそのまま残ります。 最高の安定性を求めるのであれば、 ユーザープロセス iijPPP ではなく、 カーネル PPPを使用してください。 以下の TA は、 FreeBSD で動作確認ずみです。 Motorola BitSurfer および Bitsurfer Pro Adtran 他の TA もほとんどの場合うまく動作するでしょう。 TA のメーカーでは、 TA がほとんどの標準モデム AT コマンドセットを受け付けるようにするよう、 努力しているようです。 外部 TA を使う際の最大の問題点は、 モデムの場合と同じく良いシリアルカー ドが必要であるということです。 シリアルデバイスの詳細、 そして非同期シリアルポートと同期シリアルポートの差については、 同期・非同期の違いやシリアルデバイスについて説明したチュートリアル FreeBSD Serial Hardware を参照してください。 標準の PC シリアルポート(非同期)に接続された TA は、 128Kbs の接続を行っていても、 最大通信速度が 115.2Kbs に制限されてしまいます。 128Kbs の ISDN の性能を最大限に生かすためには、 TA を同期シリアルカードに接続しなければなりません。 内蔵 TA を購入して、 同期／非同期問題を片付けてしまおうとは思わないでく ださい。 内蔵 TA には、 単に標準 PC シリアルポートのチップが内蔵されてい るだけです。 内蔵 TA の利点といえば、 シリアルケーブルを買わなくていいと いうことと、 電源コンセントが一つ少なくて済むということくらいでしょう。 同期カードと TA の組合せは 386 の FreeBSD マシンの場合でも、 スタンドア ローンのルータと同程度の速度は確保できます。 またこの組合せでは、 ルータより柔軟な設定が可能です。 同期カード/TA を選ぶか、 スタンドアローンルータを選ぶかは、 多分に宗教的な問題です。 メーリングリストでもいくつか議論がありました。 議論の内容に ついては、 archives を参照してください。 スタンドアローン ISDN ブリッジ/ルータ ISDN ブリッジやルータは、 OS 特有のものではありません。 もちろん FreeBSD 特有のものでもありません。 ルーティングやブリッジング技術に関する詳細は、 ネットワークの参考書をご覧ください。 このページでは、 ルータとブリッジにどちらでもあてはまるように記述します。 ISDN ルータ/ブリッジは、 ローエンドの製品のコストが下がってきていることもあり、 より一般的に使用されるようになるでしょう。 ISDN ルータは、 外見は小さな箱で、 ローカルのイーサネットネットワーク(もしくはカード)と直接、 接続します。 また、 自身で他のブリッジ/ルータとの接続を制御します。 PPP や他のプロトコルを使用するためのソフトウェアは、 すべて組み込まれています。 ルータは、 完全な同期 ISDN 接続を使用するため、 通常の TA と比較してスループットが大幅に向上します。 ISDN ルータ/ブリッジを使用する場合の最大の問題点は、 各メーカーの製品間に相性の問題がまだ存在することです。 インターネットプロバイダとの接続を考えている場合には、 プロバイダと相談することをお勧めします。 事務所の LAN と家庭の LAN の間など、 二つの LAN セグメントの間を接続しようとしている場合は、 ブリッジ/ルータの使用がもっともメンテナンスが 簡単で、 努力が少なくてすむ方法です。 両側の機材を購入するのであれば、 メーカー間の接続性の問題もないでしょう。 たとえば家庭の LAN や出張所の LAN を本社のネットワークに接続するためには、 以下のような設定が使用できます。 出張所 LAN または 家庭 LAN ネットワークは、 10 Base T イーサネットです。 ルータとネットワークの間は、 必要に応じて AUI/10BT トランシーバを使って接続します。 ---Sun ワークステーション | ---FreeBSD マシン | ---Windows 95 (別に勧めているわけじゃありません) | スタンドアローンルータ | ISDN BRI ライン 家庭/出張所 LAN で、 一台しかコンピュータを接続しないのであれば、 クロス のツイストペアケーブルを使用して、 スタンドアローンルータと直結も可能です。 本社 LAN や他の LAN ネットワークは、 ツイストペアイーサネットです。 -------Novell サーバ | | |ハ ---Sun | | | ---FreeBSD | | |ブ ---Windows 95 | | |___---スタンドアローンルータ | ISDN BRI ライン ほとんどのルータ/ブリッジでは、 別々の二つのサイトに対して、 同時にそれ ぞれ独立した二つの PPP 接続が可能です。 これは、 通常の TA ではサポートされない機能で、 ルータ/ブリッジ接続の大きな利点です (シリアルポートを 二つもつ特殊(そして高価な) TA では可能です)。 チャンネル割り当てや MPP などと混同しないでください。 これは、 大変便利な機能です。 たとえば事務所で専用線 ISDN 接続を使用していて、 別の ISDN ラインを購入したくないとします。 この場合、 事務所のルータは、 一つの専用線 B チャンネル接続(64Kbs)を維持しつつ、 別 の B チャンネルを他の用途に使用することができます。 たとえば、 他の場所 とのダイアルイン、 ダイアルアウトに使用したり、 バンド幅を増やすために、 インターネットとの接続への動的に割り当て(MPP など)に使用したりすることが可能です。 またイーサネットブリッジは、 IP パケットだけでなく IPX/SPX などすべての プロトコルのパケットを中継することが可能です。 NIS/YP 原作: &a.unfurl;, 2000 年 1 月 21 日, 監修: Eric Ogren eogren@earthlink.net, Udo Erdelhoff ue@nathan.ruhr.de, 2000 年 6 月. NIS/YP とは? NIS とは Network Information Services の略で Sun Microsystems によって Unix の (もともとは SunOS の) 集中管理のために開発されました。 現在では事実上の業界標準になっており、 主要な Unix は (Solaris、 HP-UX、 AIX、 Linux、 NetBSD、 OpenBSD、 FreeBSD、 等々) すべてこれをサポートしています。 NIS は元々、 イエローページ (または yp) として知られていましたが、 著作権を侵害しているとして Sun はその名を変えさせられました。 NIS は RPC を使ったクライアント/サーバシステムです。 これを使うと NISドメイン内のマシン間で、 共通の設定ファイルを共有することができます。 また、 NIS を使うことでシステム管理者は最小限の設定データで NIS クライアントを立ち上げることができ、 1 ヶ所から設定データの追加、 削除、 変更が可能です。 NIS は Windows NT のドメインシステムに似ています。 内部の実装は似ても似つかないものですが、 基本的な機能を 対比することはできます。 知っておくべき用語 / プロセス NIS サーバの立ち上げや NIS クライアントの設定など、 NIS を FreeBSD に導入するにあたって、 目にするであろう用語や重要なユーザプロセスがいくつかあります。 NIS ドメイン名. NIS マスターサーバ一つと そのクライアント (スレーブサーバを含む) は一つの NIS ドメイン名を 持ちます。 NT のドメイン名同様、 NIS ドメイン名は DNS とは何の関係もありません。 portmap. portmap は RPC (Remote Procedure Call、 NIS で使われるネットワークプロトコル) を利用するために実行しておかなければなりません。 portmap が動いていなければ、 NIS サーバの起動もクライアントとしての機能も得られません。 ypbind. ypbind は NIS クライアントを NIS サーバに結び付けます。 これは NIS ドメイン名をシステムから受け、 RPC を用いてサーバに接続します。 ypbind はクライアントとサーバのコミュニケーションの中枢であり、 もしクライアントマシンの ypbind が機能を停止した場合は NIS サーバへアクセスできなくなります。 ypserv. ypserv は NIS サーバでのみ実行されるもので、 NIS のサーバプロセスそのものです。 ypserv が機能を停止したときは、 サーバは NIS リクエストに答えられなくなります (運が良ければ、 スレーブサーバがいて代わりを努めるでしょう)。 今まで使っていたサーバが機能を停止したとき、 別のサーバに再接続しに行かない NIS の実装もいくつかあります (FreeBSD のものは違います)。 そのような場合に復帰するための唯一の方法は、 サーバプロセス (あるいはサーバ全体)、 もしくはクライアントの ypbind プロセスを再スタートすることです。 rpc.yppasswdd. rpc.yppasswdd は NIS マスターサーバで動かされるべきもう一つのプロセスで、 NIS クライアントから NIS パスワードを変更させるデーモンです。 このデーモンが動いていないときは、 ユーザは NIS マスターサーバに login し、 そこでパスワードを変更することになります。 動作のしくみ NIS 環境にあるホストは、 次の 3 種類に分類されます。 それは、 マスターサーバ、 スレーブサーバ、 クライアントです。 サーバは、 ホストの設定情報の中心的な情報格納庫の役割をします。 マスターサーバは元となる信頼できる情報を保持し、 スレーブサーバは、 冗長性を確保するため、 この情報をミラーします。 そしてクライアントは、 サーバから情報の提供を受けて動作します。 この方法を用いることで、 数多くのファイルにある情報が共有できます。 よく NIS で共有されるのは、 master.passwd や group、 hosts といったファイルです。 クライアント上のプロセスで、 通常ローカルのファイルにある情報が必要 となったとき、 クライアントは接続しているサーバに問い合わせを行い、 その情報を得ます。 マシンの分類 NIS マスターサーバ. このサーバは Windows NT で言うところのプライマリ ドメインコントローラにあたります。 すべての NIS クライアントで利用されるファイルを保守し、 passwd や group、 その他 NIS クライアントが参照するファイルは、 マスターサーバにあります。 一つのマシンが一つ以上の NIS ドメインのマスターサーバになることは可能です。 しかし、 ここでは比較的小規模の NIS 環境を対象としているため、 そのような場合については扱いません。 NIS スレーブサーバ。 NT で言うところのバックアップドメインコントローラに似たもので、 NIS スレーブサーバは NIS マスターサーバのデータファイルのコピーを保持します。 NIS スレーブサーバは重要な環境で必要とされる冗長性を提供し、 マスターサーバの負荷のバランスをとります。 NIS クライアントは常に最初にレスポンスを返したサーバを NIS サーバとして接続しますが、 これにはスレーブサーバも含まれます。 NIS クライアント。 NIS クライアントは大部分の NT ワークステーションのように、 logon に際して NIS サーバに対して (NT ワークステーションの場合では NT ドメインコントローラに) 認証します。 NIS/YP を使う この節では NIS 環境の立ち上げ例を取り上げます。 この節ではあなたが FreeBSD 3.3 以降を使っているものとします。 ここで与えられる指示はおそらく FreeBSD の 3.0 以降の、 どのバージョンでも機能するでしょうが、 それを保証するものではありません。 計画を立てる あなたが大学の小さな研究室の管理人であるとしましょう。 この研究室は 15 台の FreeBSD マシンからなっていて、 現在はまだ集中管理されていません。 すなわち、 各マシンは /etc/passwd と /etc/master.passwd を各々が持っています。 これらのファイルは手動でお互いに同期させています。 つまり現時点では、 新しいユーザをあなたが追加するとき、 adduser を 15 ヶ所すべてで実行しなければなりません。 これは明らかに変える必要があるため、 あなたはこのうち 2 台をサーバにして NIS を導入することを決めました。 その結果、 研究室の設定はこのようなものになります: マシンの名前 IP address 役割 ellington 10.0.0.2 NIS マスタ coltrane 10.0.0.3 NIS スレーブ basie 10.0.0.4 教員用のワークステーション bird 10.0.0.5 クライアントマシン cli[1-11] 10.0.0.[6-17] その他のクライアントマシン もし NIS によるシステム管理の設定を行なうのが初めてなら、 どのようにしたいのか、 ひととおり最後まで考えてみることをお勧めします。 ネットワークの規模によらず、 いくつか決めるべきことがあるからです。 NIS ドメイン名を決める ここでいうドメイン名は、 今まであなたが使っていた、 いわゆる ドメイン名 と呼んでいたものとは違います。 正確には NIS ドメイン名 と呼ばれます。 クライアントがサーバに情報を要求するとき、 その要求には自分が属する NIS ドメインの名前が含まれています。 これは、 1 つのネットワークに複数のサーバがある場合に、 どのサーバが要求を処理すれば良いかを決めるために使われます。 NIS ドメイン名とは、 関連のあるホストをグループ化するための名前である、 と考えると良いでしょう。 組織によってはインターネットのドメイン名を NIS ドメイン名に使っているところがありますが、 これはネットワークのトラブルをデバッグするときに混乱の原因となるため、 お勧めできません。 - NIS ドメイン名はネットワーク内で一意なければならないので、 + NIS ドメイン名はネットワーク内で一意でなければならないので、 ドメイン名がドメインに含まれるマシンを表すようなものであれば、 分かりやすくなります。 たとえば Acme 社のアート(Art)部門であれば、 NIS ドメイン名を"acme-art"とすれば良いでしょう。 しかしながら、 オペレーティングシステムによっては、 そのネットワークドメイン名を NIS のドメイン名として使うものもあります (特に SunOS)。 あなたのネットワークにそのような制限のあるマシンが 1 台でもあるときは、 NIS のドメイン名としてインターネットのネットワークドメイン名を使わなければいけません。 サーバマシンの物理的な条件とは NIS サーバとして使うマシンを選ぶ際には、 いくつかの注意点があります。 NIS における困ったことの一つに、 クライアントのサーバへの依存度があります。 クライアントが自分の NIS ドメインのサーバに接続できない場合、 マシンが使用不能になることがよくあります。 もし、 ユーザやグループに関する情報が得られなければ、 ほとんどのシステムは一時的にですが停止してしまいます。 こういったことを念頭に置いて、 しょっちゅうリブートされるマシンや、 開発に使われそうなマシンを選ばないようにしなければなりません。 理想的には、 NIS サーバはスタンドアロンで NIS サーバ専用となるマシンにするべきです。 ネットワークの負荷が重くなければ、 他のサービスを走らせているマシンを NIS サーバにしてもかまいません。 ただし NIS サーバが使えなくなると、 すべてのクライアントに影響をおよぼす、 という点には注意しなければなりません。 NIS サーバ 元となるすべての NIS 情報は、 NIS マスターサーバと呼ばれる 1 台のマシンに置かれます。 この情報が格納されるデータベースを NIS マップと呼びます。 FreeBSDでは、 このマップは /var/yp/[domainname] に置かれます。 [domainname] は、 サーバがサービスする NIS ドメインです。 1 台の NIS サーバが複数のドメインをサポートすることも可能です。 つまり、 このディレクトリを各々のドメインごとに作ることができ、 各ドメインごと、 独立したマップの集合を持つことになります。 NIS のマスターサーバとスレーブサーバ上では、 ypserv デーモンがすべての NIS 要求を処理します。 ypserv は NIS クライアントからの要求を受け付け、 ドメイン名とマップ名を対応するデータベースファイルへのパスに変換し、 データをクライアントに返送します。 NIS マスターサーバの設定 やりたいことにもよりますが、 NIS マスターサーバの設定は比較的単純です。 FreeBSD は初期状態で NIS に対応しています。 必要なことは以下の行を /etc/rc.conf に追加し、 FreeBSD をリスタートすることだけです。 nisdomainname="test-domain" この行はネットワークのセットアップ時に (すなわち再起動したときに) NIS のドメイン名を test-domain にセットします。 nis_server_enable="YES" これは FreeBSD に、 次にネットワークが立ち上がったとき NIS のサーバプロセスを起動させます。 nis_yppasswdd_enable="YES" これは rpc.yppasswdd デーモンを有効にします。 上述したようにこれはユーザが NIS のパスワードをクライアントのマシンから変更することを可能にします。 あと、 あなたがしなければいけないことはスーパユーザ権限でコマンド /etc/netstart を実行することです。 これにより /etc/rc.conf で定義された値を使ってすべての設定が行なわれます。 NIS マップの初期化 NIS マップ とは /var/yp ディレクトリにあるデータベースファイルです。 これらは NIS マスタの /etc ディレクトリの設定ファイルから作られます。 唯一の例外は /etc/master.passwd ファイルです。 これは、 root や他の管理用アカウントのパスワードまでその NIS ドメインのすべてのサーバに伝えたくないという、 もっともな理由によるものです。 このため NIS マップの初期化の前に以下を行う必要があります。 &prompt.root; cp /etc/master.passwd /var/yp/master.passwd &prompt.root; cd /var/yp &prompt.root; vi master.passwd あなたはシステムに関するアカウント (bin、 tty、 kmem、 games、 etc) をすべて削除しなければなりません。 またあなたが NIS クライアントに伝えたくないと思うアカウント (たとえば root や他の UID が 0 (スーパユーザ) のアカウント) についても削除する必要があります。 /var/yp/master.passwd が グループや全世界から読めるようになっていないようにしてください (モード 600)! 必要なら chmod コマンドを 使ってください。 すべてが終わったらマップを初期化します! FreeBSD には、 これを行うために ypinit という名のスクリプトが含まれています (詳細はそのマニュアルページをご覧ください)。 このスクリプトはほとんどの UNIX OS で存在しますが、 すべてとは限らないことを覚えておいてください。 Digital Unix/Compaq Tru64 Unix では ypsetup と呼ばれています。 NIS マスタのためのマップを作るためには オプションを ypinit に与えます。 上述のステップを完了しているなら、 以下を実行して NIS マップを生成します。 ellington&prompt.root; ypinit -m test-domain Server Type: MASTER Domain: test-domain Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If you don't, something might not work. At this point, we have to construct a list of this domains YP servers. rod.darktech.org is already known as master server. Please continue to add any slave servers, one per line. When you are done with the list, type a <control D>. master server : ellington next host to add: coltrane next host to add: ^D The current list of NIS servers looks like this: ellington coltrane Is this correct? [y/n: y] y [..output from map generation..] NIS Map update completed. ellington has been setup as an YP master server without any errors. ypinit は /var/yp/Makefile を /var/yp/Makefile.dist から作成します。 作成されていれば、 そのファイルはあなたが扱っているのが FreeBSD のみからなる、 サーバが一つだけの NIS 環境であるという前提に立っています。 test-domain はスレーブサーバを一つ持っていますので、 /var/yp/Makefile を編集する必要があります。 ellington&prompt.root; vi /var/yp/Makefile `NOPUSH = "True"' としている行を (もし既にコメントアウトされていないならば) コメントアウトしなければなりません。 NIS スレーブサーバの設定 NIS スレーブサーバの設定はマスターサーバの設定以上に簡単です。 スレーブサーバにログオンし /etc/rc.conf ファイルを前回と同様に編集します。 唯一の違うところは ypinit の実行に オプションを使わなければいけないことです。 オプションは NIS マスターサーバの名前を要求し、 コマンドラインは以下のようになります。 coltrane&prompt.root; ypinit -s ellington test-domain Server Type: SLAVE Domain: test-domain Master: ellington Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If you don't, something might not work. There will be no further questions. The remainder of the procedure should take a few minutes, to copy the databases from ellington. Transferring netgroup... ypxfr: Exiting: Map successfully transferred Transferring netgroup.byuser... ypxfr: Exiting: Map successfully transferred Transferring netgroup.byhost... ypxfr: Exiting: Map successfully transferred Transferring master.passwd.byuid... ypxfr: Exiting: Map successfully transferred Transferring passwd.byuid... ypxfr: Exiting: Map successfully transferred Transferring passwd.byname... ypxfr: Exiting: Map successfully transferred Transferring group.bygid... ypxfr: Exiting: Map successfully transferred Transferring group.byname... ypxfr: Exiting: Map successfully transferred Transferring services.byname... ypxfr: Exiting: Map successfully transferred Transferring rpc.bynumber... ypxfr: Exiting: Map successfully transferred Transferring rpc.byname... ypxfr: Exiting: Map successfully transferred Transferring protocols.byname... ypxfr: Exiting: Map successfully transferred Transferring master.passwd.byname... ypxfr: Exiting: Map successfully transferred Transferring networks.byname... ypxfr: Exiting: Map successfully transferred Transferring networks.byaddr... ypxfr: Exiting: Map successfully transferred Transferring netid.byname... ypxfr: Exiting: Map successfully transferred Transferring hosts.byaddr... ypxfr: Exiting: Map successfully transferred Transferring protocols.bynumber... ypxfr: Exiting: Map successfully transferred Transferring ypservers... ypxfr: Exiting: Map successfully transferred Transferring hosts.byname... ypxfr: Exiting: Map successfully transferred coltrane has been setup as an YP slave server without any errors. Don't forget to update map ypservers on ellington. この例の場合、 /var/yp/test-domain というディレクトリが必要になります。 NIS マスターサーバのマップファイルのコピーはこのディレクトリに置かれますが、 あなたは、 これらが確実に最新のものに維持されるようにする必要があります。 次のエントリをスレーブサーバの /etc/crontab に追加することで、 最新のものに保つことができます。 20 * * * * root /usr/libexec/ypxfr passwd.byname 21 * * * * root /usr/libexec/ypxfr passwd.byuid この二行は、 スレーブサーバにあるマップファイルをマスターサーバのマップファイルと同期させるものですが、 必須というわけではありません。 なぜなら、 マスターサーバは、 NIS マップに対する変更をスレーブサーバに伝えようとするからです。 しかし、 サーバが管理するシステムにとってパスワード情報はとても重要なものですので、 強制的に更新してしまう方が良いでしょう。 特に、 マップファイルの更新がきちんと行なわれるかどうかわからないくらい混雑するネットワークでは、 重要なポイントになります。 コマンド /etc/netstart をスレーブサーバでも実行してください。 NIS サーバを起動します。 NIS クライアント NIS クライアントは ypbind デーモンを使って、 特定の NIS サーバとの間に結合 (binding) と呼ばれる関係を成立させます。 ypbind はシステムのデフォルトのドメイン (domainname コマンドで設定されます) をチェックし、 RPC 要求をブロードキャストパケットとしてローカルネットワークに送信します。 この RPC 要求により、 ypbind が結合を成立させようとしているドメイン名が指定されます。 要求されているドメイン名に対してサービスするよう設定されたサーバが ブロードキャストパケットを受信すると、 サーバは ypbind に応答し、 ypbind は応答のあったサーバのアドレスを記録します。 複数のサーバがある(たとえば一つのマスターサーバと、 複数のスレーブサーバがある)場合、 ypbind は、 最初に応答したサーバのアドレスを使用します。 これ以降、 クライアントのシステムは、 すべての NIS の要求をそのサーバに向けて送信します。 ypbind は、 サーバが順調に動作していることを確認するため、 時々 ping をサーバに送ります。 反応が戻ってくるべき時間内に ping に対する応答が来なければ、 ypbind は、 そのドメインを結合不能(unbound)として記録し、 別のサーバを見つけるべく、 再びブロードキャストパケットの送信を行います。 NIS クライアントの設定 FreeBSD マシンにおける NIS クライアントの設定は非常に単純です。 /etc/rc.conf ファイルを編集して以下の行を追加し、 ネットワークのセットアップ時に NIS ドメイン名をセットして ypbind を起動させます。 nisdomainname="test-domain" nis_client_enable="YES" NIS サーバにあるすべてのパスワードエントリを取り込むため、 vipw コマンドで以下の行を /etc/master.passwd に追加します。 +::::::::: この行によって NIS サーバのパスワードマップにアカウントがある人全員にアカウントが与えられます。 この行を変更すると、 さまざまな NIS クライアントの設定を行なうことが可能です。 詳細は netgroups の部分を、 さらに詳しい情報については、 O'Reilly の Managing NFS and NIS をお読みください。 NIS サーバにあるすべてのグループエントリを取り込むため、 以下の行を /etc/group に追加します。 +:*:: 上記の手順がすべて完了すれば、 ypcat passwd によって NIS サーバの passwd マップが参照できるようになっているはずです。 NIS セキュリティ 一般にドメイン名さえ知っていれば、 どこにいるリモートユーザでも ypserv に RPC を発行して NIS マップの内容を引き出すことができます。 こういった不正なやりとりを防ぐため、 ypserv には securenets と呼ばれる機能があります。 これはアクセスを決められたホストだけに制限する機能です。 ypserv は起動時に /var/yp/securenets ファイルから securenets に関する情報を読み込みます。 上記のパス名は、 オプションで指定されたパス名によって変わります。 このファイルは、 空白で区切られたネットワーク指定とネットマスクのエントリからなっていて、 # で始まる行はコメントとみなされます。 簡単な securenets ファイルの例を以下に示します。 # allow connections from local host -- mandatory 127.0.0.1 255.255.255.255 # allow connections from any host # on the 192.168.128.0 network 192.168.128.0 255.255.255.0 # allow connections from any host # between 10.0.0.0 to 10.0.15.255 10.0.0.0 255.255.240.0 ypserv が上記のルールの一つと合致するアドレスからの要求を受け取った場合、 処理は通常に行なわれます。 もしアドレスがルールに合致しなければ、 その要求は無視されて警告メッセージがログに記録されます。 また、 /var/yp/securenets が存在しない場合、 ypserv はすべてのホストからの接続を受け入れます。 ypserv は Wietse Venema 氏による tcpwrapper パッケージもサポートしています。 そのため、 /var/yp/securenets の代わりに tcpwrapper の設定ファイルを使ってアクセス制御を行なうことも可能です。 これらのアクセス制御機能は一定のセキュリティを提供しますが、 どちらも特権ポートのテストのような IP spoofing 攻撃に対して脆弱です。 すべての NIS 関連のトラフィックはファイアウォールでブロックされるべきです。 /var/yp/securenets を使っているサーバは、 古風な TCP/IP 実装を持つ正しいクライアントへのサービスに失敗することがあります。 これらの実装の中にはブロードキャストのホストビットをすべて 0 でセットしてしまったり ブロードキャストアドレスの計算でサブネットマスクを見落としてしまったりするものがあります。 これらの問題はクライアントの設定を正しく行なうことで修正できますが、 他の問題は問題となっているクライアントシステムの撤去か /var/yp/securenets の放棄が必要です。 このような古風な TCP/IP の実装を持つサーバで /var/yp/securenets を使うことは非常に悪い考えであり、 あなたのネットワークの大部分において NIS の機能を失うことになるでしょう。 tcpwrapper パッケージの使用はあなたの NIS サーバのレイテンシ (遅延) を増加させます。 追加された遅延は、 特に混雑したネットワークや遅い NIS サーバでクライアントプログラムのタイムアウトを引き起こすに十分なだけ長いでしょう。 一つ以上のクライアントシステムがこれらの兆候を示したなら、 あなたは問題となっているクライアントシステムを NIS スレーブサーバにして自分自身に結び付くように強制すべきです。 何人かのユーザのログオンを遮断する わたしたちの研究室には basie という、 教員専用のマシンがあります。 わたしたちはこのマシンを NIS ドメインの外に出したくないのですが、 マスタ NIS サーバの passwd ファイルには教員と学生の両方が載っています。 どうしたらいいでしょう? 当該人物が NIS のデータベースに載っていても、 そのユーザがマシンにログオンできないようにする方法があります。 そうするには、 -username を クライアントマシンの /etc/master.passwd ファイルの末尾に付け足します。 username はあなたがログインさせたくないと思っているユーザのユーザ名です。 これは vipw で行うべきです。 vipw は /etc/master.passwd への変更をチェックし、 編集終了後パスワードデータベースを再構築します。 たとえば、 ユーザ bill が basie にログオンするのを防ぎたいなら、 以下のようにします。 basie&prompt.root; vipw [add -bill to the end, exit] vipw: rebuilding the database... vipw: done basie&prompt.root; cat /etc/master.passwd root:[password]:0:0::0:0:The super-user:/root:/bin/csh toor:[password]:0:0::0:0:The other super-user:/root:/bin/sh daemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin operator:*:2:5::0:0:System &:/:/sbin/nologin bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/sbin/nologin tty:*:4:65533::0:0:Tty Sandbox:/:/sbin/nologin kmem:*:5:65533::0:0:KMem Sandbox:/:/sbin/nologin games:*:7:13::0:0:Games pseudo-user:/usr/games:/sbin/nologin news:*:8:8::0:0:News Subsystem:/:/sbin/nologin man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/sbin/nologin bind:*:53:53::0:0:Bind Sandbox:/:/sbin/nologin uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/sbin/nologin pop:*:68:6::0:0:Post Office Owner:/nonexistent:/sbin/nologin nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin +::::::::: -bill basie&prompt.root; netgroups の利用 netgroups の部分の原作: Udo Erdelhoff ue@nathan.ruhr.de. 2000 年 7 月. 前節までに見てきた手法は, 極めて少ないユーザ/マシン向けに個別のルールを必要としている場合にはうまく機能します。 しかし大きなネットワークでは, ユーザに触られたくないマシンへログオンを防ぐのを忘れるでしょうし, そうでなくとも各マシンを個別に設定して回らなければならず、 集中管理という NIS の恩恵を失ってしまいます。 NIS の開発者はこの問題を netgroups と呼ばれる方法で解決しました。 彼らの目的とその意味合いは UNIX のファイルシステムで使われている一般的なグループと比較できます。 主たる相違は数字による id を欠いていることと、 ネットグループを定義するのにユーザアカウントと別のネットグループの、 両方を含められる機能です。 ネットグループは百人/台以上のユーザとマシンを含む、 大きく複雑なネットワークを扱うために開発されました。 もし、 あなたがこのような状況を扱わなければならないなら便利なものなのですが、 この複雑さは単純な例でネットグループの説明をすることをほとんど不可能にしています。 この部の残りで使われている例は、 この問題を実演しています。 あなたの行なった、 研究室への NIS の導入の成功が上司の目に止ったとしましょう。 あなたの次の仕事は、 あなたの NIS ドメインをキャンパスの他のいくつものマシンを覆うものへ拡張することです。 二つの表は新しいユーザと新しいマシンの名前とその説明を含んでいます。 ユーザの名前 説明 alpha, beta IT 学科の通常の職員 charlie, delta IT 学科の新しい見習い echo, foxtrott, golf, ... 一般の職員 able, baker, ... まだインターン マシンの名前 説明 war, death, famine, polution 最も重要なサーバ。 IT 職員だけがログオンを許されます。 pride, greed, envy, wraith, lust, sloth あまり重要でないサーバ。 IT 学科の全員がログオンを許されます。 one, two, three, four, ... 通常のワークステーション。 本当の 職員だけがログオンを許されます。 trashcan 重要なデータの入っていないひどく古いマシン。 インターンでもこのマシンの使用を許されます。 もしあなたがこの手の制限を各ユーザを個別にブロックする形で実装するなら、 あなたはそのシステムにログオンすることが許されていない各ユーザについて -user という 1 行を、 各システムのパスワードに追加しなければならなくなるでしょう。 もしあなたが 1 エントリでも忘れればトラブルに巻き込まれてしまいます。 最初のセットアップの時にこれを正しく行えるのはありえることかも知れませんが、 遂には連日の業務の間に例の行を追加し忘れてしまうでしょう。 結局マーフィーは楽観主義者だったのです。 この状況をネットグループで扱うといくつかの有利な点があります。 各ユーザを別個に扱う必要はなく、 ユーザを一つ以上のネットグループに割り当て、 ネットグループの全メンバのログインを許可したり禁止したりすることができます。 新しいマシンを追加するときはネットグループへログインの制限を定義するだけ、 新しいユーザを追加するときはそのユーザを一つ以上のネットグループへ追加するだけで、 それぞれ行なうことができます。 これらの変更は互いに独立なので、 ユーザとマシンの組合わせをどうするか は存在しなくなります。 あなたの NIS のセットアップが注意深く計画されていれば、 マシンへのアクセスを認めるにも拒否するにも中心の設定をたった一カ所変更するだけです。 最初のステップは NIS マップ netgroup の初期化です。 FreeBSD の ypinit はこのマップをデフォルトで作りませんが、 その NIS の実装はそれが作られさえすればそれをサポートするものです。 空のマップを作るには、 単に ellington&prompt.root; vi /var/yp/netgroup とタイプして内容を追加していきます。 わたしたちの例では、 すくなくとも IT 職員、 IT 見習い、 一般職員、 インターンの 4 つのネットグループが必要です。 IT_EMP (,alpha,test-domain) (,beta,test-domain) IT_APP (,charlie,test-domain) (,delta,test-domain) USERS (,echo,test-domain) (,foxtrott,test-domain) \ (,golf,test-domain) INTERNS (,able,test-domain) (,baker,test-domain) IT_EMP、 IT_APP 等はネットグループの名前です。 それぞれの括弧で囲まれたグループが一人以上のユーザアカウントをそれに登録しています。 グループの 3 つのフィールドは その記述が有効なホスト(群)の名称。 ホスト名を特記しなければそのエントリはすべてのホストで有効です。 もしあなたがホスト名を特記するなら、 あなたは闇と恐怖と全き混乱の領域となるでしょう。 このネットグループに所属するアカウントの名称。 そのアカウントの NIS ドメイン。 もしあなたが一つ以上の NIS ドメインの不幸な仲間なら、 あなたは他の NIS ドメインからあなたのネットグループにアカウントを導入できます。 各フィールドには、 ワイルドカードが使えます。 詳細は &man.netgroup.5; をご覧ください。 8 文字以上のネットグループ名は、 特にあなたの NIS ドメインで他のオペレーティングシステムを走らせているときは使うべきではありません。 名前には大文字小文字の区別があります。 そのためネットグループ名に大文字を使う事は、 ユーザやマシン名とネットグループ名を区別する簡単な方法です。 NIS クライアントの中には (FreeBSD 以外で) 多数のエントリを扱えないものもあります。 たとえば SunOS の古い版では 15 以上のエントリを含むネットグループはトラブルを起こします。 この制限は 15 ユーザ以下のサブ・ネットグループをいくつも作り、 本当のネットグループはこのサブ・ネットグループからなるようにすることで回避できます。 BIGGRP1 (,joe1,domain) (,joe2,domain) (,joe3,domain) [...] BIGGRP2 (,joe16,domain) (,joe17,domain) [...] BIGGRP3 (,joe32,domain) (,joe33,domain) BIGGROUP BIGGRP1 BIGGRP2 BIGGRP3 単一のネットグループに 225 人以上のユーザをいれたいときは、 このやり方を繰り返すことができます。 新しい NIS マップの有効化と配布は簡単です。 ellington&prompt.root; cd /var/yp ellington&prompt.root; make これで新しい 3 つの NIS マップ netgroup、 netgroup.byhost netgroup.byuser ができるはずです。 新しい NIS マップが利用できるか確かめるには &man.ypcat.1; を使います。 ellington&prompt.user; ypcat -k netgroup ellington&prompt.user; ypcat -k netgroup.byhost ellington&prompt.user; ypcat -k netgroup.byuser 最初のコマンドの出力は /var/yp/netgroup の内容に似ているはずです。 2 番目のコマンドはホスト別のネットグループを作っていなければ出力されません。 3 番目のコマンドはユーザに対するネットグループのリストを得るのに使えます。 クライアント側の設定は非常に簡単です。 サーバ war を設定するには、 &man.vipw.8; を実行して以下の行 +::::::::: を +@IT_EMP::::::::: に入れ替えるだけです。 今、 ネットグループ IT_EMP で定義されたユーザのデータだけが war のパスワードデータベースに読み込まれ、 そのユーザだけがログインを許されています。 残念ながらこの制限はシェルの ~ の機能や、 ユーザ名やユーザの数値 id の変換ルーチンにも影響します。 言い換えれば、 cd ~user はうまく動かず、 ls -l はユーザ名のかわりに数値の id を表示し find . -user joe -print は No such user で失敗します。 これを避けるためには、 すべてのユーザのエントリをサーバにログインすることを許さずに読み込むことが必要です。 これはもう一行を /etc/master.passwd に追加することで実現できます。 その行は +:::::::::/sbin/nologin を含んでおり、 すべてのエントリを読み込むが、 読み込まれたエントリのシェルは /sbin/nologin で置き換えられる ということを意味します。 passwd エントリの他のフィールドを /etc/master.passwd の既定値から置き換えることも可能です。 +:::::::::/sbin/nologin の行が +@IT_EMP::::::::: の行より後ろに位置することに注意してください。 さもないと NIS から読み込まれた全ユーザが /sbin/nologin をログインシェルとして持つことになります。 この変更の後では、 新しい職員が IT 学科に参加しても NIS マップを一つ書き換えるだけで済みます。 同様にして、 あまり重要でないサーバのローカルの /etc/master.passwd のかつての +::::::::: 行を以下のように置き換えます。 +@IT_EMP::::::::: +@IT_APP::::::::: +:::::::::/sbin/nologin この行は、 一般のワークステーションでは以下のようになります。 +@IT_EMP::::::::: +@USERS::::::::: +:::::::::/sbin/nologin これでしばらく順調に運用していましたが、 数週間後、 ポリシに変更がありました。 IT 学科はインターンを雇い始め、 IT インターンは一般のワークステーションと余り重要ではないサーバを使うことが許され、 IT 見習いはメインサーバへのログインが許されました。 あなたは新たなネットグループ IT_INTERN を追加して新しい IT インターンたちをそのグループに登録し、 すべてのマシンの設定を変えて回ることにしました。 古い諺にこうあります。 集中管理における過ちは、 大規模な混乱を導く。 いくつかのネットグループから新たなネットグループを作るという NIS の機能は、 このような状況に対処するために利用できます。 その方法の一つは、 役割別のネットグループを作ることです。 たとえば、 重要なサーバへのログイン制限を定義するために BIGSRV というネットグループを作り あまり重要ではないサーバへは SMALLSRV というネットグループを、 そして一般のワークステーション用に USERBOX という第 3 のネットグループを 作ることができます。 これらのネットグループの各々は、 各マシンにログインすることを許されたネットグループを含みます。 あなたの NIS マップネットグループの新しいエントリは、 以下のようになるはずです。 BIGSRV IT_EMP IT_APP SMALLSRV IT_EMP IT_APP ITINTERN USERBOX IT_EMP ITINTERN USERS このログイン制限の定義法は、 同一の制限を持つマシンのグループを定義できるときには便利なものです。 残念ながらこのようなケースは例外的なものです。 ほとんどの場合、 各マシンに基づくログイン制限の定義機能が必要となるでしょう。 マシンごとのネットグループの定義は、 上述したようなポリシの変更を扱うことができるもうひとつの方法です。 このシナリオでは、 各マシンの /etc/master.passwd は ``+'' で始まる２つの行を含みます。 最初のものはそのマシンへのログインを許されたアカウントを追加するもので、 2 番目はその他のアカウントを/sbin/nologin をシェルとして追加するものです。 マシン名をすべて大文字で記述したものをネットグループの名前として使うのは良いやり方です。 言い換えれば、 件の行は次のようになるはずです。 +@BOXNAME::::::::: +:::::::::/sbin/nologin 一度、 各マシンに対してこの作業を済ませてしまえば、 二度とローカルの /etc/master.passwd を編集する必要がなくなります。 以降のすべての変更は NIS マップの編集で扱うことができます。 以下はこのシナリオに対応するネットグループマップに、 いくつかの便利な定義を追加した例です。 # Define groups of users first IT_EMP (,alpha,test-domain) (,beta,test-domain) IT_APP (,charlie,test-domain) (,delta,test-domain) DEPT1 (,echo,test-domain) (,foxtrott,test-domain) DEPT2 (,golf,test-domain) (,hotel,test-domain) DEPT3 (,india,test-domain) (,juliet,test-domain) ITINTERN (,kilo,test-domain) (,lima,test-domain) D_INTERNS (,able,test-domain) (,baker,test-domain) # # Now, define some groups based on roles USERS DEPT1 DEPT2 DEPT3 BIGSRV IT_EMP IT_APP SMALLSRV IT_EMP IT_APP ITINTERN USERBOX IT_EMP ITINTERN USERS # # And a groups for a special tasks # Allow echo and golf to access our anti-virus-machine SECURITY IT_EMP (,echo,test-domain) (,golf,test-domain) # # machine-based netgroups # Our main servers WAR BIGSRV FAMINE BIGSRV # User india needs access to this server POLLUTION BIGSRV (,india,test-domain) # # This one is really important and needs more access restrictions DEATH IT_EMP # # The anti-virus-machine mentioned above ONE SECURITY # # Restrict a machine to a single user TWO (,hotel,test-domain) # [...more groups to follow] もしユーザアカウントを管理するデータベースの類を使っているなら、 あなたはデータベースのレポートツールからマップの最初の部分を作れるようにしてあるべきです。 この方法なら、 新しいユーザは自動的にマシンにアクセスできるでしょう。 最後に使用上の注意を: マシン別のネットグループを使うことが常に賢明というわけではありません。 あなたが数ダースから数百の同一の環境のマシンを学生の研究室に配置しているのならば、 NIS マップのサイズを手頃な範囲に押さえるために、 マシン別のネットグループのかわりに役割別のネットグループを使うべきです。 忘れてはいけないこと NIS 環境にある今、 今までとは違ったやり方が必要なことが 2、3 あります。 研究室にユーザを追加するときは、 それをマスター NIS サーバにだけ追加しなければならず、 さらにNIS マップを再構築することを忘れてはいけません。 これを忘れると新しいユーザは NIS マスタ以外のどこにもログインできなくなります。 たとえば、 新しくユーザ jsmith をラボに登録したいときは以下のようにします。 &prompt.root; pw useradd jsmith &prompt.root; cd /var/yp &prompt.root; make test-domain pw useradd jsmith のかわりに adduser jsmith を使うこともできます。 管理用アカウントを NIS マップから削除してください。 管理用アカウントやパスワードを、 それらのアカウントへアクセスされるべきでないユーザが居るかも知れないマシンにまで伝えて回りたいとは思わないでしょう。 NIS のマスタとスレーブをセキュアに、 そして機能停止時間を最短に保ってください。 もし誰かがこれらのマシンをクラックしたり、 あるいは単に電源を落としたりすると、 彼らは実質的に多くの人を研究室へログインできなくしてしまえます。 これはどの集中管理システムにとっても第一の弱点で、 そして最も重要な弱点でしょう。 あなたの NIS サーバを守らなければ怒れるユーザと対面することになるでしょう! NIS v1 との互換性 FreeBSD の ypserv は、 NIS v1 クライアントを部分的にサポートします。 FreeBSD の NIS 実装は NIS v2 プロトコルのみを使用していますが、 ほかの実装では、 古いシステムとの下位互換性を持たせるため v1 プロトコルをサポートしているものもあります。 そのようなシステムに付いている ypbind デーモンは、 必要がないにもかかわらず NIS v1 のサーバとの結合を成立させようとします(しかも v2 サーバからの応答を受信した後でも、 ブロードキャストをし続けるかも知れません)。 FreeBSD の ypserv は、 クライアントからの通常のリクエストはサポートしていますが、 v1 のマップ転送リクエストはサポートしていないことに注意してください。 つまり FreeBSD の ypserv を、 v1 だけをサポートするような古い NIS サーバと組み合わせて マスターやスレーブサーバとして使うことはできません。 幸いなことに、 現在、 そのようなサーバが使われていることは ほとんどないでしょう。 NIS クライアントとしても動作している NIS サーバ 複数のサーバが存在し、 サーバ自身が NIS クライアントでもあるようなドメインで ypserv が実行される場合には、 注意が必要です。 一般的に良いとされているのは、 他のサーバと結合をつくるようにブロードキャストパケットの送信をさせるのではなく、 サーバをそれ自身に結合させることです。 もし、 サーバ同士が依存関係を持っていて、 一つのサーバが停止すると、 奇妙なサービス不能状態に陥ることがあります。 その結果、 すべてのクライアントはタイムアウトを起こして 他のサーバに結合しようと試みますが、 これにかかる時間はかなり大きく、 サーバ同士がまた互いに結合してしまったりすると、 サービス不能状態はさらに継続することになります。 ypbind に オプションフラグを指定して実行することで、 ホストを特定のサーバに結合することが可能です。 libscrypt 対 libdescrypt NIS を実装しようする人の誰もがぶつかる問題の一つに、 暗号ライブラリの互換性があります。 NIS サーバが DES 暗号ライブラリを使っている場合には、 同様に DES を使用しているクライアントしかサポートできません。 サーバとクライアントがどのライブラリを使用しているかは、 /usr/lib のシンボリックリンクを見ればわかります。 あるマシンが DES ライブラリを使うように設定されている場合、 リンクは以下のようになっています。 &prompt.user; ls -l /usr/lib/*crypt* lrwxrwxrwx 1 root wheel 13 Jul 15 08:55 /usr/lib/libcrypt.a@ -> libdescrypt.a lrwxrwxrwx 1 root wheel 14 Jul 15 08:55 /usr/lib/libcrypt.so@ -> libdescrypt.so lrwxrwxrwx 1 root wheel 16 Jul 15 08:55 /usr/lib/libcrypt.so.2@ -> libdescrypt.so.2 lrwxrwxrwx 1 root wheel 15 Jul 15 08:55 /usr/lib/libcrypt_p.a@ -> libdescrypt_p.a -r--r--r-- 1 root wheel 13018 Nov 8 14:27 /usr/lib/libdescrypt.a lrwxr-xr-x 1 root wheel 16 Nov 8 14:27 /usr/lib/libdescrypt.so@ -> libdescrypt.so.2 -r--r--r-- 1 root wheel 12965 Nov 8 14:27 /usr/lib/libdescrypt.so.2 -r--r--r-- 1 root wheel 14750 Nov 8 14:27 /usr/lib/libdescrypt_p.a マシンが FreeBSD の標準の MD5 暗号ライブラリを使うように 設定されている場合には、 以下のようになります。 &prompt.user; ls -l /usr/lib/*crypt* lrwxrwxrwx 1 root wheel 13 Jul 15 08:55 /usr/lib/libcrypt.a@ -> libscrypt.a lrwxrwxrwx 1 root wheel 14 Jul 15 08:55 /usr/lib/libcrypt.so@ -> libscrypt.so lrwxrwxrwx 1 root wheel 16 Jul 15 08:55 /usr/lib/libcrypt.so.2@ -> libscrypt.so.2 lrwxrwxrwx 1 root wheel 15 Jul 15 08:55 /usr/lib/libcrypt_p.a@ -> libscrypt_p.a -r--r--r-- 1 root wheel 6194 Nov 8 14:27 /usr/lib/libscrypt.a lrwxr-xr-x 1 root wheel 14 Nov 8 14:27 /usr/lib/libscrypt.so@ -> libscrypt.so.2 -r--r--r-- 1 root wheel 7579 Nov 8 14:27 /usr/lib/libscrypt.so.2 -r--r--r-- 1 root wheel 6684 Nov 8 14:27 /usr/lib/libscrypt_p.a NIS クライアントの認証でトラブルが発生した場合には、 ここから問題となりそうな部分を探すと良いでしょう。 NIS サーバを異種混在ネットワークに配置したいときは DES が最大公約数となるでしょうから、 すべてのシステムで DES を使わなければいけなくなるでしょう。 DHCP 原作: &a.gsutter;, 2000 年 3 月. DHCPとは何でしょう? DHCP (Dynamic Host Configuration Protocol) は、 システムをネットワー クに接続するだけで、 ネットワークでの通信に必要な情報を入手するこ とができる仕組みです。 FreeBSD では、 ISC (Internet Software Consortium) による DHCP の実装を使用しています。 したがって、 ここで の説明のうち、 実装によって異なる部分は ISC のもの用になっています。 この節で説明していること ハンドブックのこの節では DHCP システムの、 FreeBSD に組み込まれてい る部分についてだけ説明しています。 ですから、 サーバについては説明 していません。 後の節で紹介するリファレンスに加えて、 DHCP のマニュアルページも有力な参考になることでしょう。 DHCP の動作 クライアントとなるマシン上で DHCP のクライアントである dhclient を実 行すると、 まず設定情報の要求をブロードキャストします。 デフォルト では、 このリクエストには UDP のポート 68 を使用します。 サーバは UDP の ポート 67 で応答し、 クライアントの IP アドレスと、 ネットマスクやルー タ、 DNS サーバなどの関連する情報を提供します。 これらの情報の すべては DHCP の「リース」の形で送られ、 DHCP サーバ管理者によって決 められたある一定の時間内でのみ有効になります。 これによって、 ネッ トワークに存在しなくなったホストの IP アドレスは自動的に回収される ことになります。 DHCP クライアントはサーバから非常に多くの情報を取得することができます。 &man.dhcp-options.5; に、 その非常に大きなリストが載っています。 FreeBSD への組み込み FreeBSD は ISC の DHCP クライアントである dhclient を完全に組み込んでいます。 DHCP クラ イアントはインストーラと基本システムの両方で提供されています。 ですから DHCP サーバを走らせているネットワーク上ではネットワー ク関係の設定についての詳細な知識は必要になりません。 dhclient は、 3.2 以降の FreeBSD のすべての配布 に含まれています。 DHCP は sysinstall でサポートされてお り、 sysinstall でのネットワークインタフェイス設定の際は、 「こ のインタフェイスの設定として DHCP を試してみますか?」という質問 が最初になされます。 これに同意することで dhclient が実行さ れ、 それが成功すればネットワークの設定情報は自動的に取得されま す。 システム起動時に、 DHCP を使ってネットワーク情報を取得するように するには、 次の 2 つのステップを行なう必要があります。 bpf デバイスがカーネルに組み込まれていることを確認します。 これを組み込むには、 カーネルコンフィグレーションファイルに pseudo-device bpf という行を追加し、 カーネルを再構築します。 カーネルの構築に関する詳細は、 を参照してください。 bpf デバイスは、 FreeBSD の出荷時に用意されている GENERIC カーネルに組み込まれていますので、 自分で設定を変えたカスタムカーネルを使っているのでなければ、 DHCP を動作させるためにカーネルを再構築する必要はありません。 セキュリティに関心のある方向けに注意しておきます。 bpf デバイスは、 パケットスニファ (盗聴プログラム) を動作させることができる (ただし root 権限が必要) デバイスです。 bpf は DHCP を動作させるために かならず必要ですが、 セキュリティが非常に重要な場面では DHCP を本当に使う時まで bpf デバイスをカーネルに追加すべきではないでしょう。 /etc/rc.conf を編集して、 次の行を追加してください。 ifconfig_fxp0="DHCP" fxp0 の部分を、 動的に設定したいインター フェースの名前で置き換えることを忘れないようにしてください。 もし、 使っているdhclient の場所を変更してい たり、 dhclient にフラグを渡したい場合は、 同 様に下のように書き加えてください。 dhcp_program="/sbin/dhclient" dhcp_flags="" DHCP サーバである dhcpd は、 ports collectionに isc-dhcp2 として収録されていま す。 この port はクライアント、 サーバ、 リレーエージェントから成 る ISC の DHCP 配布物をすべて含んでいます。 関連ファイル /etc/dhclient.conf dhclient は設定ファイル /etc/dhclient.conf を必要とします。 大抵の場合、 このファイルはコメントだけであり、 デフォルトが 通常使いやすい設定になっています。 この設定ファイルは マニュアルページ &man.dhclient.conf.5; で説明しています。 /sbin/dhclient dhclient は静的にリンクされており、 /sbin に置かれています。 マニュアルページ &man.dhclient.8; で dhclient コマンドについて より詳しく説明しています。 /sbin/dhclient-script dhclient-script は FreeBSD 特有の、 DHCP クラ イアント設定スクリプトです。 これについてはマニュアルページ &man.dhclient-script.8; で説明されていますが、 これを編集する 必要はほとんど発生しないでしょう。 /var/db/dhclient.leases DHCP クライアントはこのファイルに有効なリースのデータベースを ログとして記録します。 &man.dhclient.leases.5; にもうすこし詳 しい解説があります。 参考になる文献 DHCP のプロトコルは RFC 2131 に完全に記述されています。 また、 dhcp.org にも有用な 情報源が用意されています。 diff --git a/ja_JP.eucJP/books/handbook/internals/chapter.sgml b/ja_JP.eucJP/books/handbook/internals/chapter.sgml index b890f0d288..0b9cffbdeb 100644 --- a/ja_JP.eucJP/books/handbook/internals/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/internals/chapter.sgml @@ -1,3572 +1,3572 @@ FreeBSD の内部 DMAとはどういったものでどういう働きをするのか 原作: Copyright © 1995,1997 &a.uhclem;, All Rights Reserved. 1996 年 10 月 10 日. 最終更新日 1997 年 10 月 8 日. 訳: &a.jp.yasu; Direct Memory Access (DMA)は, 中央演算処理装置 (CPU)からの干渉なく データを計算機中である場所から別の場所に動かすための手法です. DMA 機能の実装の方法はそれぞれの 計算機アーキテクチャ間で異なるもので あるため, ここでの議論はIBMパーソナルコンピュータ(PC), PC/AT とその互換機における DMA サブシステムの実装と働きに限定します. PCの DMAサブシステムは, Intelの 8237 DMAコントローラをベースにして います. 8237はそれぞれ独立にプログラムできる4つのDMAチャネルを持ち, それぞれどのチャネルもいつでもアクティブにできます. これらのチャネルは順に 0, 1, 2, 3となっています. PC/ATからは, セカンド 8237 チップが追加され,それらは 4, 5, 6, 7と なっています. オリジナルの DMAコントローラ(0, 1, 2, 3)は, 1回の転送で1バイト 転送します. セカンドDMAコントローラ(4, 5, 6, 7)は1回で 隣接する2つのメモリ番地から 16ビット転送します. ここで, 最初のバイトは通常偶数のアドレスになります. 2つのコントローラは全く同じものであり, 転送量が異なるのは セカンドコントローラがシステムに直結しているためです. 8237 は個々のチャネルについて, DRQと-DACKという2つの電気信号を 持っています. その他に, HRQ (Hold Request), HLDA (Hold Acknowledge), -EOP (End of Process)があり, バス制御信号として -MEMR (Memory Read), -MEMW (Memory Write), -IOR (I/O Read), and -IOW (I/O Write)があります. 8237 DMACは, いわゆるfly-by DMAコントローラです. これは, データの移動を行う際に, データは DMACチップを通過せず, DMACチップに格納されないことを意味します. また, DMACはI/Oポートとメモリアドレス間でのみデータを 転送することができますが, 2つのI/Oポートもしくは2つのメモリアドレス 間ではできません. 8237 は, 非 fly-byモードでは, 互いに接続された 2つのチャネルでのメモリ-メモリ間でのDMA操作を許可します. しかし, PC メーカは, ただでさえ乏しいこのリソースをこんなふうに 使ったりしません. なぜなら, CPUを使用してメモリ間のデータを動かす方が早いからです. PC アーキテクチャでは, それぞれのDMAチャネルは, 通常 与えられた DMA チャネルを使用するハードウェアがそのチャネルについて DRQ線を使って転送を要求した時のみ動作します. DMA転送の例 DMA転送の発生と処理の手順の例をあげてみましょう. この例では, フロッピーディスクコントローラ (FDC)が ディスケットから1バイト読み込んで, DMAを使って,メモリの0x00123456番地に 格納したいとします. 処理は, FDCが, DRQ2信号(DMAチャンネル2に 対するDRQ線)を有効にして DMAコントローラに要求を伝えることで開始されます. DMAコントローラは DRQ2 シグナルが有効になったことを記録します. するとDMAコントローラはDMAチャネル2がプログラムされ, マスクが かかっていない(有効になっている)ことを確認します. 同様に, DMAコントローラは, 他のDMAチャネルがアクティブまたは アクティブになろうとしていないこと, そしてより高い優先度を持って いないことを確認します. 一旦これらのチェックが完了すると, DMACはDMACがバスを使うために バスを開放するようにCPUに要求します. DMACはCPUにHRQ信号を送ってバスを要求します. CPUはHRQ信号を検出し, 現在の指示の実行を完了します. 一旦プロセッサがバスを開放することができる状態になると, 解放を 行います. 通常は CPU により駆動される信号 (-MEMR, -MEMW, -IOR, -IOW, その他)を すべてハイインピーダンス (ハイともローとも指定しない)状態にした後, CPUは HLDA信号を有効にして DMAコントローラにバスを明け渡したことを 伝えます. プロセッサによっては, CPUはバスを使用しないいくつかの 命令を追加して実行することもできますが, しかし,プロセッサの内部キャッシュや パイプライン以外のメモリから 何か読み出すといった指示に到達したら結局 CPU は待たなくてはなりません. ここで,DMACが バスを託されると, DMACはその -MEMR, -MEMW, -IOR, -IOW 出力信号をアクティブにし, DMACから出力されるアドレスは 0x3456にセットされます.これは 転送しようとする特定のメモリ番地をバイトで 指示するのに使われます. すると DMAC は DMA 転送をリクエストしたデバイスに転送が始まることを 知らせます.これは -DACK 信号をアクティブにすることで行われます. フロッピーディスクコントローラの場合は, -DACK2を アクティブにすることで行われます. バスのデータ線に転送されるバイトにを出力することについては フロッピーディスクコントローラが責任をもつことになります. もし,フロッピーディスクコントローラがバス上にバイトデータを 出力するのに余計な時間を必要としなければ (もし周辺装置がもっと時間を必要とする場合には, READY信号を 経由してDMACに通知します), DMAは 1 DMAクロック待ち, メモリにバス上のバイトデータを格納するために -MEMW および -IOR 信号を解除します. そして FDCはバイトデータが転送されたことを認識します. DMAサイクルは1度に1バイトしか転送しないので, FDCはDRQ2信号を止めて, DMACに転送が終了したことを知らせます. DMACは-DACK2信号を解除して, FDCはバス上へのデータ出力を 停止しなくてはならないことを知らせます. 次にDMACは他のDMAチャネルのいずれかに要求がきていないか チェックを行います. もしどのチャネルのDRQも有効になっていなければ, DMAコントローラは処理を完了して, -MEMR, -MEMW, -IOR, -IOW および アドレス信号をハイインピーダンス状態にします. 最後に, DMAはHRQ信号を解除します. CPUはこれを見ると,HOLDA信号を 解除します. そしてCPUは自らの -MEMR, -MEMW, -IOR, -IOW 信号および アドレス線を有効にし, 命令の実行やメインメモリや周辺機器へのアクセスを 再開します. 典型的なフロッピーディスクの1セクタについては, 上記のプロセスが それぞれのバイトについて1回行われ, 全部で512回繰り返されます. 1 バイト転送される毎に, DMAC 内のアドレスレジスタはインクリメントされ, 同じくDMAC内にある, 何バイト転送すればよいかを示すカウンタが デクリメントされます. カウンタが0になると, DMAはEOP信号を送ります. この信号は カウンタが0であり, DMAコントローラがCPUによって再び プログラムされるまで, これ以上データは転送されないことを 示すものです. このイベントはターミナルカウント(TC)とも呼ばれます. EOP信号は1本しかありません. そして, 一度にアクティブにできる DMAチャネルは一本だけなので, 現在アクティブであるDMAチャネルこそが, たった今処理を終了したDMAチャネルだと言うことができます. もし, バッファの転送が完了した時に周辺機器から割り込みを発生させたい とき, 周辺機器は -DACKn信号およびEOP信号の両方が同時に発信されたか どうかをテストします. その場合, DMACはCPUの介在がなければ これ以上はその周辺機器についての情報を転送しません. その後で, 周辺機器はプロセッサに割り込みを生じさせるために, 何らかの割り込み信号を発生させることができます. PCアーキテクチャ においては, DMAチップ自身が割り込みを生じさせることはできません. 周辺機器とそれに関連するハードウェアが割り込みを生成する責任を 持ちます. また, DMAを使用する周辺機器が割り込みを使用しない 可能性もあります. DMAC が要求を出したときには CPU は常にバスを DMAC に開放しますが, この動作は, DMAC がアクティブになった時にプロセッサが命令を実行するのに かかる時間がわずかに変化することを除いては, アプリケーション, オペレーティングシステムの両方からはわからないということを 理解することが重要です. そのため, プロセッサが確かにDMA転送が完了したことを知るためには, 周辺装置や DMA チップ中のレジスタを調べたり,周辺装置からの割り込みを 受け取る必要があります. DMA ページレジスタ および 16メガ アドレス空間制限 これまで述べたのとは異なり, DMACはアドレス線を 0x0123456 にセットする 代わりに 0x3456 だけをセットすることにあなたは気づいたかも しれません. この理由について少し説明します. オリジナルのIBM PCがデザインされた時, IBMは, DMACと割込み制御チップの 両方を, 8085(8ビットプロセッサで, 16ビットのアドレス空間(64k)を持つ)と 組み合わせて使うように設計されたチップを使うことを選びました. IBM PCが64k以上のメモリをサポートしていたため, DMACが64kを越えるメモリ番地に読み込み又は書き込みを行うために 変更を行う必要が生じました. この問題を解決するためにIBMが行ったのは, それぞれのDMAチャネルに, 読み込み元または書き込み先のアドレスの 上位ビットを保持するための 外部的なラッチを追加することでした. DMAチャネルがアクティブな時はいつでも, このラッチの内容はアドレスバスに書かれて, そのチャネルのDMA操作が 終了するまでそこに保持されます. IBM はこれらのラッチを ページレジスタ と呼んでいます. そのため上記に示した例では, DMACはアドレスの0x3456の部分をバス上に 置き, DMAチャネル2に対するページレジスタは, 0x0012xxxxをバス上に 置きます. これらの2つの値が組み合わされてアクセスされるメモリ中の完全な アドレスを形成します. ページレジスタのラッチはDMAチップとは独立であるので, 読み込まれる又は書き込まれるメモリ領域は, 64kの物理的境界を またいではなりません. 例えば, もし DMACがメモリの0xffff番地をアクセスした場合, データの転送後, DMACはアドレスレジスタをインクリメントし, 0x0000番地にある次のバイトを アクセスします. 0x10000番地ではありません. これはおそらく意図されたものとは異なっているでしょう. 物理的な 64Kの境界を 8086モードの 64k セグメントと混同してはいけません. セグメントは, セグメント レジスタに数学的にオフセットレジスタを 加算して作られるものです. ページレジスタにはアドレスのオーバーラップも無く, 数学的に OR を取られることもありません. さらに複雑なことには, PC/ATでは外部のDMAアドレスのラッチは 8ビットしか保持しません. よって8+16で24ビットになり, これは DMAが0から16メガの間のメモリ番地しか指し示せないことを 意味します. 16メガ以上のメモリを持ったより新しいマシンにおいても, 標準的なPCコンパチブルなDMAでは16メガ以上のメモリ番地には アクセスできません. この制限を避けるために, オペレーティングシステムは 16 メガ以下にある物理的な 64k の境界をまたがない領域に RAM バッファを 予約します. そして, DMACはデータを周辺機器からそのバッファに 転送するようにプログラムされます. 一旦DMACがこのバッファに データを動かすと, オペレーティングシステムは本当にデータを 格納したいアドレスにバッファからデータをコピーします. 16メガを越えるアドレスからDMAベースの周辺機器にデータを 書き込む際には, データは16メガ以下に位置したバッファから最初に コピーされなくてはならず, その後, DMACはバッファからハードウェアに データをコピーすることができます. FreeBSDでは, これらの予約バッファは バウンスバッファと呼ばれます. MS-DOSの世界では, これらはスマートバッファなどと呼ばれます. 82374と呼ばれる8237の新しい実装においては, ページレジスタを16ビットで指定して, バウンスバッファを使用しなくても, 32 ビットのアドレス空間全体にアクセスすることが可能です. DMA操作モードとその設定 8237 DMA はいくつかのモードで動作します. 主なモードは, 以下のとおりです. シングル転送モード シングルバイト(もしくはワード)が転送されます. DMAは1バイト毎にバスを開放し, 再び要求しなくてはなくてはなりません. これは一般に, すぐにはデータのブロック全てを転送できないデバイスに よって使用されます. 周辺装置は次の転送の準備ができる毎にDMAを要求します. 標準的な PC コンパチブルなフロッピーディスクコントローラ(NEC 765)は 1バイトのバッファしか持たないので, このモードを使用します. ブロック/デマンド転送モード 一旦 DMAC がシステムバスを取得すると, 最大64kまでのデータブロック 全体が転送されます. もし周辺装置が余分に時間を必要とするときは, 転送を一時中断するためにREADY信号を有効にします. READY信号は過度に使われるべきではなく, 遅い周辺装置の転送の場合は シングル転送モードを代わりに使うべきです. ブロック転送モードとデマンド転送モードの違いは, 一旦ブロック転送が 始まると, 転送カウンタか 0 になるまでそれが行われるところです. DRQ は -DACK が有効になるまでの間は有効でなければなりません. デマンドモードは DRQ が有効な間転送が続けられます. DRQが有効でなくなった場合, DMA はその時点で転送を中断し, バスを解放して CPU に返します. その後, DRQが有効になると, 転送は中断したところから再開されます. データの転送, 特に転送に使われるメモリ番地が16Mを越える場合に, CPU を使った方が効率がよくなるまで CPU の速度が向上する以前の 古いハードディスクコントローラはデマンドモードを 使っていました. カスケード転送モード このメカニズムは DMA チャネルがバスを要求することを許可する ものですが, 接続されたデバイスはバス上のアドレス情報の配置に ついてDMACに代わって責任を持ちます. これはバスマスタ と呼ばれる技術の実装に利用されます. カスケードモードの DMA チャネルがバスのコントロールを受け取ると, DMA は通常行われるようなバス上のアドレスと I/O コントロール信号の 出力を行いません. 代わりに, DMAはアクティブなチャネルの -DACK信号を 有効にします. この時点で, アドレスとバスコントロール信号の供給は DMAチャネルに接続された周辺機器が担当します. 周辺機器はシステムバスの完全なコントロールを行い, 16 メガ以下の任意のアドレスの読み込みおよび書き込みを 行うことが できます. 周辺機器はバスの使用を終えると DRQ 線を無効にするので, DMA コントローラは CPU もしくは他のDMAチャネルに制御を返すことが できます. カスケードモードは複数の DMA コントローラを相互接続するのに 使われます. PC内ではDMAチャネル4がまさにこの用途に使われています. 周辺機器がDMAチャネル0, 1, 2, 3でバスを要求すると, スレーブDMAコントローラは HLDREQ を有効にしますが, この線はCPUではなく, 実際にはプライマリDMAコントローラのDRQ4に 接続されています. その後, チャンネル4になにか仕事があるものと見なしたプライマリの DMAコントローラは HLDREQ を使ってCPUにバスを 要求します. バスが与えられると, -DACK4が有効になりますが, この線は実際にはスレーブDMAコントローラの HLDA信号に 接続されています. スレーブDMAコントローラはその後要求したDMAチャネル (0, 1, 2, 3) に対してデータを転送するか, SCSIコントローラのような バスマスタリングを要求する周辺機器にバスを許可します. このような配線がおこなわれているため, PC/ATシステムの 周辺機器ではDMAチャネルは 0, 1, 2, 3, 5, 6, 7のみが使用できます. 初期のIBM PCコンピュータでは, DMAチャネル0は操作の リフレッシュのために予約されていますが, 最近のシステムでは通常, 周辺機器によって使用することができます. 周辺機器がバスマスタリングを行っている時は, システムバスを保持している間絶えずメモリに もしくはメモリから データを転送することが重要です.もし, 周辺機器がこのように できないときは, システムがメインメモリのリフレッシュを 行なえるようにしばしばバスを開放しなくては なりません. 全ての PC でメインメモリとして使われるダイナミック RAM は, 中身が 満たされている ビットを保持するため 頻繁にアクセスされなくてはなりません. ダイナミック RAM は, それぞれが 1 ビットのデータを記憶するコンデンサが たくさん集まって構成されています. これらのコンデンサは充電された 状態で 1, 充電されていない状態で 0 を表します. 全てのコンデンサは放電するため, 1 の値を保持するために, 一定の間隔で電力を加える必要があります. 実際に RAM チップは RAM の適切な場所に電力を送る作業を行ないますが, メモリのリフレッシュ作業が RAM を普通にアクセスする時と 衝突しないように, それをいつ行なうかを コンピュータが休止状態の時に知らせなくてはなりません. もしコンピュータがメモリのリフレッシュを 行なえない場合は, メモリの中身はわずか数ミリ秒で壊れてしまいます. メモリの読み込みと書き込みのサイクルは リフレッシュサイクルとして カウントされる (ダイナミック RAM のリフレッシュサイクルは 実際には不完全なメモリ読み込みサイクルになります)ので, 周辺機器のコントローラが連続するメモリ番地から データの読み込み または書き込みを行う間は, メモリの全てがリフレッシュされます. バスマスタリングはいくつかの SCSI ホストインタフェースやその他の ハイパフォーマンスな周辺機器コントローラに 見られます. 自動初期化転送モード このモードにおいてDMAはバイト, ブロック, デマンド転送を行いますが, DMA転送カウンタが0になると, カウンタとアドレスはDMAチャネルが もともとプログラムされた時のものに戻されます. これは, 周辺機器が転送を要求している間は転送が続けられることを 意味します. 転送領域としてDMACにプログラムされた固定バッファの中で, 出力操作でDMACがデータを読み出す前もって新しいデータを 書き込んだり入力操作でDMACが書き込んだあとに, そこから新しいデータを読み出す作業は CPU が受け持ちます. このテクニックは, サンプリング 用のバッファが小さいもしくは それを持たないオーディオデバイスによく使われます. この環状バッファの管理は更なる CPU オーバーヘッドになりますが, DMAカウンタが0になり, 再プログラムされるまでDMAが停止してしまう ことによって起きる遅延は, この方法でしかなくす事ができない 場合もあります. DMAのプログラミング プログラムされるDMAチャネルは, 通常, 設定を行う前に マスクするべきです. これはハードウェアが予期せずそのチャンネルに対してDRQを有効に した場合, たとえ全てのパラメータが 満たされてない場合や更新されていない場合でも, DMACは それに応答してしまう可能性があるからです. マスクを行ってから,ホストは転送の方向(メモリからI/O, もしくはI/Oからメモリ)と, 転送に使用するDMA操作のモード (シングル, ブロック, デマンド, カスケードなど)を設定し, 最後に アドレスや転送の長さを設定します. 設定される長さはDMACに転送させたい量よりも1少なくなります. アドレスや転送長のLSBとMSBは同じ8ビットI/O ポートに書き込まれます. そのためDMACが最初のバイトをLSBとして, 2番目のバイトをMSBとして 受け取ることを保証するために, 最初に別のポートに書き込みを行なって LSBとMSB の判別を行なうフリップフロップをクリアしておく必要があります. そして,DMAのページレジスタを更新します. これはDMACの外部にあり I/O ポートの別のセットを通してアクセスされます. すべての設定ができると, DMAチャネルはマスクを解除することができます. そのDMAチャネルは準備ができたとみなされ, そのチャンネルのDRQが 有効になると応答します. 8237のプログラミングの正確な詳細については, ハードウェアデータブックを参照してください. PCシステムにおける I/O マップについても参照する必要があるでしょう. このマップには DMA およびページレジスタのポートがどこに位置するのかを 書いてあります. 以下に完全なポートのマップテーブルを示します. DMAポートのマップ IBM-PCとPC/ATに基づくすべてのシステムでは, 同じI/Oポートに配置された DMAハードウェアを持っています. その完全なリストを以下に示します. DMAコントローラ2に割り当てられたポートは, AT以外のデザインでは 未定義になっています. 0x00 – 0x1f DMA コントローラ #1 (Channels 0, 1, 2 and 3) DMA アドレス および カウントレジスタ 0x00 write Channel 0 starting address 0x00 read Channel 0 current address 0x01 write Channel 0 starting word count 0x01 read Channel 0 remaining word count 0x02 write Channel 1 starting address 0x02 read Channel 1 current address 0x03 write Channel 1 starting word count 0x03 read Channel 1 remaining word count 0x04 write Channel 2 starting address 0x04 read Channel 2 current address 0x05 write Channel 2 starting word count 0x05 read Channel 2 remaining word count 0x06 write Channel 3 starting address 0x06 read Channel 3 current address 0x07 write Channel 3 starting word count 0x07 read Channel 3 remaining word count DMA コマンドレジスタ 0x08 write Command Register 0x08 read Status Register 0x09 write Request Register 0x09 read - 0x0a write Single Mask Register Bit 0x0a read - 0x0b write Mode Register 0x0b read - 0x0c write Clear LSB/MSB Flip-Flop 0x0c read - 0x0d write Master Clear/Reset 0x0d read Temporary Register (新しいバージョンでは利用不可) 0x0e write Clear Mask Register 0x0e read - 0x0f write Write All Mask Register Bits 0x0f read Read All Mask Register Bits (Intel 82374にのみ存在する) 0xc0 – 0xdf DMA コントローラ #2 (Channels 4, 5, 6 and 7) DMA アドレス および カウントレジスタ 0xc0 write Channel 4 starting address 0xc0 read Channel 4 current address 0xc2 write Channel 4 starting word count 0xc2 read Channel 4 remaining word count 0xc4 write Channel 5 starting address 0xc4 read Channel 5 current address 0xc6 write Channel 5 starting word count 0xc6 read Channel 5 remaining word count 0xc8 write Channel 6 starting address 0xc8 read Channel 6 current address 0xca write Channel 6 starting word count 0xca read Channel 6 remaining word count 0xcc write Channel 7 starting address 0xcc read Channel 7 current address 0xce write Channel 7 starting word count 0xce read Channel 7 remaining word count DMA コマンドレジスタ 0xd0 write Command Register 0xd0 read Status Register 0xd2 write Request Register 0xd2 read - 0xd4 write Single Mask Register Bit 0xd4 read - 0xd6 write Mode Register 0xd6 read - 0xd8 write Clear LSB/MSB Flip-Flop 0xd8 read - 0xda write Master Clear/Reset 0xda read Temporary Register (Intel 82374には存在しない) 0xdc write Clear Mask Register 0xdc read - 0xde write Write All Mask Register Bits 0xdf read Read All Mask Register Bits (Intel 82374にのみ存在する) 0x80 – 0x9f DMA ページレジスタ 0x87 r/w Channel 0 Low byte (23-16) page Register 0x83 r/w Channel 1 Low byte (23-16) page Register 0x81 r/w Channel 2 Low byte (23-16) page Register 0x82 r/w Channel 3 Low byte (23-16) page Register 0x8b r/w Channel 5 Low byte (23-16) page Register 0x89 r/w Channel 6 Low byte (23-16) page Register 0x8a r/w Channel 7 Low byte (23-16) page Register 0x8f r/w Low byte page Refresh 0x400 – 0x4ff 82374 Enhanced DMA Registers Intel 82374 EISA System Component (ESC)は1996年の初めに発表されました. この中 には機能的には8237のスーパーセットであり, 1つのパッケージの中にその他の PC 互換機のコアとなる周辺コンポーネントをも含んだ DMA コントローラも含まれています. このチップはEISAとPCI 両方のプラットホームをターゲットにしたものであり, scatter-gather I/O やリングバッファを始めとして, システムDMAをして32ビットの アドレス空間全体に直接アクセスする能力も提供しています. これらの機能を使用する場合でも, 過去16年間のPC互換機で利用されてきた 同等機能を提供するコードも含めておく必要があります. 互換性の問題から, 82374の レジスタの一部は, 従来の8237のレジスタをプログラムした 後 に, 転送の度にプログラムされる必要があります. 8237のレジスタに書き込みを行うとき, ソフトウェアの下位互換性のために, 82374で追加された一部のレジスタの内容が 強制的に0にクリアされるからです. 0x401 r/w Channel 0 High byte (bits 23-16) word count 0x403 r/w Channel 1 High byte (bits 23-16) word count 0x405 r/w Channel 2 High byte (bits 23-16) word count 0x407 r/w Channel 3 High byte (bits 23-16) word count 0x4c6 r/w Channel 5 High byte (bits 23-16) word count 0x4ca r/w Channel 6 High byte (bits 23-16) word count 0x4ce r/w Channel 7 High byte (bits 23-16) word count 0x487 r/w Channel 0 High byte (bits 31-24) page Register 0x483 r/w Channel 1 High byte (bits 31-24) page Register 0x481 r/w Channel 2 High byte (bits 31-24) page Register 0x482 r/w Channel 3 High byte (bits 31-24) page Register 0x48b r/w Channel 5 High byte (bits 31-24) page Register 0x489 r/w Channel 6 High byte (bits 31-24) page Register 0x48a r/w Channel 6 High byte (bits 31-24) page Register 0x48f r/w High byte page Refresh 0x4e0 r/w Channel 0 Stop Register (bits 7-2) 0x4e1 r/w Channel 0 Stop Register (bits 15-8) 0x4e2 r/w Channel 0 Stop Register (bits 23-16) 0x4e4 r/w Channel 1 Stop Register (bits 7-2) 0x4e5 r/w Channel 1 Stop Register (bits 15-8) 0x4e6 r/w Channel 1 Stop Register (bits 23-16) 0x4e8 r/w Channel 2 Stop Register (bits 7-2) 0x4e9 r/w Channel 2 Stop Register (bits 15-8) 0x4ea r/w Channel 2 Stop Register (bits 23-16) 0x4ec r/w Channel 3 Stop Register (bits 7-2) 0x4ed r/w Channel 3 Stop Register (bits 15-8) 0x4ee r/w Channel 3 Stop Register (bits 23-16) 0x4f4 r/w Channel 5 Stop Register (bits 7-2) 0x4f5 r/w Channel 5 Stop Register (bits 15-8) 0x4f6 r/w Channel 5 Stop Register (bits 23-16) 0x4f8 r/w Channel 6 Stop Register (bits 7-2) 0x4f9 r/w Channel 6 Stop Register (bits 15-8) 0x4fa r/w Channel 6 Stop Register (bits 23-16) 0x4fc r/w Channel 7 Stop Register (bits 7-2) 0x4fd r/w Channel 7 Stop Register (bits 15-8) 0x4fe r/w Channel 7 Stop Register (bits 23-16) 0x40a write Channels 0-3 Chaining Mode Register 0x40a read Channel Interrupt Status Register 0x4d4 write Channels 4-7 Chaining Mode Register 0x4d4 read Chaining Mode Status 0x40c read Chain Buffer Expiration Control Register 0x410 write Channel 0 Scatter-Gather Command Register 0x411 write Channel 1 Scatter-Gather Command Register 0x412 write Channel 2 Scatter-Gather Command Register 0x413 write Channel 3 Scatter-Gather Command Register 0x415 write Channel 5 Scatter-Gather Command Register 0x416 write Channel 6 Scatter-Gather Command Register 0x417 write Channel 7 Scatter-Gather Command Register 0x418 read Channel 0 Scatter-Gather Status Register 0x419 read Channel 1 Scatter-Gather Status Register 0x41a read Channel 2 Scatter-Gather Status Register 0x41b read Channel 3 Scatter-Gather Status Register 0x41d read Channel 5 Scatter-Gather Status Register 0x41e read Channel 5 Scatter-Gather Status Register 0x41f read Channel 7 Scatter-Gather Status Register 0x420-0x423 r/w Channel 0 Scatter-Gather Descriptor Table Pointer Register 0x424-0x427 r/w Channel 1 Scatter-Gather Descriptor Table Pointer Register 0x428-0x42b r/w Channel 2 Scatter-Gather Descriptor Table Pointer Register 0x42c-0x42f r/w Channel 3 Scatter-Gather Descriptor Table Pointer Register 0x434-0x437 r/w Channel 5 Scatter-Gather Descriptor Table Pointer Register 0x438-0x43b r/w Channel 6 Scatter-Gather Descriptor Table Pointer Register 0x43c-0x43f r/w Channel 7 Scatter-Gather Descriptor Table Pointer Register FreeBSD VM システム 原作: &a.dillon;. 6 Feb 1999 物理メモリ管理 — <literal>vm_page_t</literal> 物理メモリはページ単位に, vm_page_t構造体を用いて管理されます. 物理メモリのページは, ページキューの一つに存在する, それぞれの vm_page_t 構造体の配置によって分類されます. ページは, wired(ワイヤード), active(活性状態), inactive(非活性状態), cache(キャッシュ状態), free(使われていない状態)の 各状態をとります. wired 状態を除いて, ページは通常 その状態を示す二重連結リストのキューに置かれます. wired 状態のページがキューに置かれることはありません. FreeBSD は, ページカラーリング(page coloring)を実装するため, cache 状態, free 状態にあるページ用に, さらに複雑なページキューを実装しています. その各々の状態は, プロセッサの L1, L2 キャッシュサイズに応じて最適化された 多重キューを利用します. FreeBSD は, 新たなページを確保(allocate)することが 必要になった場合に確保される VM オブジェクトのために, L1, L2 キャッシュに対して合理的にアライン(align)されたページを 得ようと試みます. 加えて, ページは参照カウントとともに保持され, ビジーカウントとともにロックされます. VM システムは, ページフラグとして PG_BUSY を使う完全ロック状態 も実装しています. 一般的には, 各々のページキューは最長不使用 (LRU) 方式で動作します. ページは普通, 最初に wired, もしくは active 状態に置かれます. wired 状態の場合, そのページはどこかにあるページテーブルに 関連づけられています. VM システムはアクティブなキュー内のページをスキャンし, wired 状態のページにエイジング (訳注: ページ参照頻度を量る手法の一つ; aging) を施します. そして, そのページはあまりアクティブでないキューへ 移動することになります. cache キューに移動させられたページは, 再利用の候補になっている VM オブジェクトに割り付けられています. free キューにあるページは, 完全に自由の状態にあります. FreeBSD は, free キューにあるページ数を最小限にとどめようと 試みますが, 割り込み発生時のページ確保を融通するため, 完全に自由なページをいくつか持っていなければなりません. プロセスがページテーブルに存在しない, ページキューの一つ(例えば, inactive, cache キュー等)に 存在するページをアクセスしようとしたとき, 比較的負荷の小さなページ再活性化フォールトが起こります. システムメモリに全く存在していないページの場合は, ディスクからページを読み出す間, そのプロセスはブロック(block)されます. FreeBSD は, ページキューを動的に調節し, 同期済(clean)のページ, 同期していない(dirty)ページの分類を 合理的に保つのと同様に, それぞれのキューにあるページが合理的な 比率に保つように試みます. 再バランス化処理が起こる量は, システムのメモリ負荷に依存します. この再バランス化処理は ページアウトデーモンによって実装されていて, (補助記憶とページを同期して)同期していないページの クリーニングすることや, (LRU キュー内でのページ位置を再配置したり, ページをキューの間を移動することで)ページが頻繁に 参照状態にあることに注目すること, キューを均等にするための キュー間ページ移動等を伴います. ページが実際にどれだけ使われているかを決定するために, FreeBSD の VM システムは, ページの再活性化フォールトを 自発的に, 合理的な数だけ発生します. これは, ページをスワップアウトしたり, クリーニングする時期を より良く決めることに繋がります. 統合バッファキャッシュ — <literal>vm_object_t</literal> FreeBSD は, 一般化した VM オブジェクト という考え方を実装しています. VM オブジェクトは, 様々な種類の補助記憶(backing store) — 補助記憶なし, スワップ, 物理デバイス, ファイル, に割り付けられます. ファイルシステムは ファイルと関連するインコアデータを管理するのに, 同じ VM オブジェクトを利用するため, 統合バッファキャッシュと呼ばれます. VM オブジェクトは, シャドウ化 することができます. シャドウ化とは, オブジェクトがそれぞれ互いの上に スタック(stack)されるということです. 例えば, MAP_PRIVATE mmap() の 動作を実装するために, ファイルに割り付けられた VM オブジェクトの上にスタックされた, スワップに割り付けられた VM オブジェクトが存在しているでしょう. このスタッキングは, fork されたアドレス空間のための 様々な共有属性, コピーオンライト(訳注: ページ共有のための 手法の一つ; cow,copy-on-write) を実装するのにも利用されています. vm_page_t は, 同時に一つの VM オブジェクトしか割り付けられることが できないことに注意しなければなりません. VM オブジェクトのシャドウ化は, 複数のインスタンスが同じページに 共有できるように実装されています. ファイルシステム I/O — <literal>struct buf</literal> 補助記憶にファイルを使う VM オブジェクトのように, v ノードを使う VM オブジェクトは通常, 処理されているかどうかという情報を, VMシステムが管理する処理情報から独立して 管理される必要があります. 例えば, VM システムが物理ページと補助記憶を同期させようとしたとき, VM システムは, 実際に書き戻す前に, ページがクリーニング済であるという マークを付ける必要があるわけです. さらに, ファイルシステムは, KVM 内で操作できるように, ファイルや, ファイルメタデータの一部分を KVM にマッピングすることが できなくてはなりません. これを管理するために使われる実体は, ファイルシステムバッファ, struct buf, bp として知られています. ファイルシステムに VM オブジェクトの一部を操作することが 必要となるときは通常, オブジェクトの部分が struct buf に マッピングされ, KVM に struct buf 内のページがマッピングされます. 同じ方法で, ディスク I/O はオブジェクトの部分を バッファ構造体内にマッピングし, その時バッファ構造体上の I/O を 発行することで発行されます. 基礎となっている vm_page_t は, I/O 処理の間 ビジー(busy)状態になります. ファイルシステムにも 独立したビジー状態があり, それはハードウェア上の VM ページの代わりに ファイルシステムバッファで動作する ファイルシステムドライバのコードに とって有用です. FreeBSD は, マッピングを保持するためにある量に制限された KVM を 予約していますが, KVM がマッピングを保持するためだけに使われ, キャッシュデータの能力を制限しないということは 明確にされるべきでしょう. 物理データキャッシュを行うことは厳密に vm_page_t の機能になっており, ファイルシステムバッファの機能ではありません. しかし, ファイルシステムバッファは placehold I/O に使われるため, それは実質的に同時処理可能な I/O 処理量を制限します. 通常は二, 三千のファイルバッファが利用可能ですから, このことは問題にならないでしょう. マッピングページテーブル — <literal>vm_map_t</literal>, <literal>vm_entry_t</literal> FreeBSD は, 物理ページテーブルの形態を VM システムと分離しています. ハードウェア上にある全てのプロセス毎のページテーブルは, その場その場で再構成され, 通常, 使い捨てだとみなされています. KVM を管理するような特殊なページテーブルは, 最初に永続的な確保が 行われ, これらのページテーブルが破棄されることはありません. FreeBSD は, vm_objects の部分を, 仮想メモリのアドレス範囲に vm_map_t と vm_entry_t 構造体を通して割り付けます. ページテーブルは, vm_map_t /vm_entry_t/vm_object_t という階層から 直接つくられます. “物理ページは, 直接一つの vm_object に 割り付けられる” と私が述べたことを思い出して下さい. ええと, そうですね, しかしそれはいつでも完全に当てはまる, というわけでもないのです. vm_page_t のは, 実際に割り付けられた ページテーブルにもリンクされています. 一つの vm_page_t は ページテーブルが呼ばれた時, いくつかの pmaps と リンクされることがあります. しかし, そのような階層的な割り付けは, 同じ vm_page_t を参照するオブジェクト内の, 同じページへの参照全てを保持しているため, その結果, 常にバッファキャッシュの統合を得ることができるわけです. KVM メモリマッピング FreeBSD は, 様々なカーネル構造体を保持するため, KVM を利用します. ファイルシステムバッファキャッシュは, KVM 内で最も大きなものです. それはつまり, struct buf の実体に対するマッピングに他なりません. Linux と異なり, FreeBSD は全ての物理メモリを KVM にマッピングしません. これは, FreeBSD が 32 ビットプラットフォームで 4G バイトまでの メモリを扱える, ということを意味します. 実際, MMU がそれを可能にしているならば, 理論上, FreeBSD は 32 ビットプラットフォームで 8TB までのメモリを扱うことができることになります. しかし, 大部分の 32 ビットプラットフォームは 4G バイトの RAM しか マッピングできないようになっている, ということには議論の余地があるでしょう. KVM は, いくつかのメカニズムによって管理されています. 中心となっているのは, ゾーンアロケータ(zone allocator)です. ゾーンアロケータは, 特定の構造体型を確保するために KVM の部分(chunk)を得て, 一定の大きさのメモリブロックに分割します. vmstat -m コマンドで, ゾーンによって 分割された, 現在の KVM 利用状況一覧を得ることができます. FreeBSD VM システムのチューニング FreeBSD カーネルでは, 動的に自分自身をチューニングするために, 協調的な努力が行なわれています. 普通は, maxusers と NMBCLUSTERS という カーネルオプション, つまり, /usr/src/sys/i386/conf/CONFIG_FILE で 指定されるもの以外, 変更する必要はありません. 可能なカーネルオプションの一覧は, /usr/src/sys/i386/conf/LINT に 記載されています. 大きなシステムに対しては, maxusers を増やしたいと思うかも知れませんね. この値は普通, 10 から 128 の間の値にします. maxusers を増やしすぎるとシステムの利用可能な KVM がオーバフローしてしまい, 予測できない動作に陥ってしまうことに注意して下さい. maxusers はある適度な値にとどめておいて, 特定のリソースを制御する NMBCLUSTERS のような, 他のオプションを増加させる方が良いでしょう. もし, システムが負荷の高いネットワーク用途に使われるなら, NMBCLUSTERS を増やしたいと望むことでしょう. この値は普通, 1024 から 4096 の間です. NBUF パラメータも, 伝統的にシステムの規模を決めるのに使われます. これは, システムがファイルシステムバッファを I/O のために マッピングするのに使われる, KVA の大きさを決めるのに使われます. このパラメータは, 統合バッファキャッシュには何の影響も与えません. これは 3.0-RELEASE 以降のカーネルでは動的にチューニングされるため, 普通は手作業で調整されるべきものではありません. NBUF パラメータは, 指定しようとしないことを推奨します. システムに選択させれば良いのです. 小さすぎる値は極端に非効率的なファイルシステム動作を招き, 一方で, 大きすぎる値は wired 状態のページを数多くつくりだし, ページキューを枯渇させてしまうでしょう. デフォルトでは, FreeBSD カーネルは最適化されていません. カーネルコンフィグにある makeoption ディレクティブを使って 最適化とデバッグフラグをセットすることができます. ただし, それによって得られる大きな (7MB 超の)カーネルを相手にするのが嫌なら, オプションは使ってはいけません. makeoptions DEBUG="-g" makeoptions COPTFLAGS="-O -pipe" sysctl は, 実行時にカーネルパラメータをチューニングする 手段を提供しています. しかし, 普通は sysctl 変数, 特に VM に関連したものを変更する必要が 生じるようなことはありません. 実行時の VM とシステムのチューニングは, 比較的単純です. まず, 可能ならば UFS/FFS ファイルシステムで softupdates を使いましょう. /usr/src/contrib/sys/softupdates/README のファイルに, 設定方法に関する手順(と制限)について書かれています. 次に, 十分なスワップを設定します. 作業 ディスクを含む 各物理ディスク装置毎に一つずつ (最大四つまで)のスワップパーティションを 設定すべきです. 少なくとも, メインメモリの 2 倍の スワップ空間が望ましく, メモリがあまりない場合には, おそらくそれより多く必要になります. また, スワップパーティションのサイズは, 後でパーティションをつくり直しする必要がないように マシンに設定したいメモリ設定の最大値を基準に 決めるべきでしょう. もし, クラッシュダンプをとりたい場合, スワップパーティションは最低限メインメモリと同じの大きさで, /var/crash にはダンプを保持するのに十分な - 空きがなければなければなりません. + 空きがなければなりません. NFS 経由のスワップは, -4.x 以降のシステムで完全に動作しますが, NFS サーバ側では, ページングがその負荷の主な原因になることに 注意しなければなりません. IPv6/IPsec の実装 原作: &a.shin;, 2000 年 3 月 5 日. 訳: &a.jp.hino;, 2001 年 3 月 19 日. 訳注 訳語については IPv6 次世代インターネット・プロトコル, クリスチャン・ウイテマ著, 村井純監修, WIDE プロジェクト IPv6 分科会監訳, 松島栄樹訳, 1997, ISBN4-88735-010-4 を参考にさせていただきました. 本章では, IPv6 と IPsec に関連する実装の詳細について説明します. これらの機能は KAME プロジェクトの成果を取り込んだものです. IPv6 規格適合性 わたしたちの IPv6 関連の機能は, 最新の IPv6 仕様に準処してい るか, または準処しようと努力しています. 今後の参考のために以下 に参考文献を挙げておきます (注: これ は完全なリストではありません - それを維持するのは大変ですか ら...). 詳しくは, 本文書の各章や, RFC, マニュアル ページ, そしてソースコード中のコメントを参照してください. 規格適合テストは, TAHI プロジェクトにより KAME STABLE kit に対して行われました. その結果は, http://www.tahi.org/report/KAME/ で見ることができます. わたしたちはまた, ニューハンプシャー大学で行われた IOL テスト (http://www.iol.unh.edu/) に以前のバージョンで参加したこともあります. RFC1639: FTP Operation Over Big Address Records (FOOBAR) (大きなアドレスレコードを用いる FTP 操作) RFC2428 は RFC1639 よりも推奨されます. FTP クラ イアントは, まず RFC2428 を試し, もしそれが失敗したな ら RFC1639 を試します. RFC1886: DNS Extensions to support IPv6 (IPv6 をサポー トするための DNS 拡張) RFC1933: Transition Mechanisms for IPv6 Hosts and Routers (IPv6 ホストおよびルータのための移行機構) IPv4 互換アドレスはサポートされません. 自動トンネリング (RFC の 4.3 で述べられています) はサポートされません. &man.gif.4; インタフェースは IPv[46]-over-IPv[46] トンネルを包括的な方法で実装しており, それは仕様で述べ られている "configured tunnel (構成されたトンネル)" を カバーしています. 詳細は本文書の 23.5.1.5をご覧ください. RFC1981: Path MTU Discovery for IPv6 (IPv6 における 経路 MTU 探索) RFC2080: RIPng for IPv6 (IPv6 のための RIPng) usr.sbin/route6d がこれをサポートしています. RFC2292: Advanced Sockets API for IPv6 (IPv6 のため の拡張ソケット API) サポートされているライブラリ関数やカーネルの API については, sys/netinet6/ADVAPI をご覧ください. RFC2362: Protocol Independent Multicast-Sparse Mode (PIM-SM) (プロトコル独立マルチキャスト - 疎モード (sparse mode)) RFC2362 は PIM-SM のパケットフォーマットを定義し ています. draft-ietf-pim-ipv6-01.txt はこれ に準じて書かれています. RFC2373: IPv6 Addressing Architecture (IPv6 アドレス 体系) ノードに必須のアドレス群をサポートし, スコープ要 求に準処しています. RFC2374: An IPv6 Aggregatable Global Unicast Address Format (IPv6 集約可能グローバルユニキャストアドレス形式) 64 ビット長のインタフェース ID をサポートしていま す. RFC2375: IPv6 Multicast Address Assignments (IPv6 に おけるマルチキャストアドレス割り当て) ユーザランドのアプリケーション群は本 RFC で割り 当てられている well-known なアドレスを使用しています. RFC2428: FTP Extensions for IPv6 and NATs (IPv6 と NAT のための FTP 拡張) RFC2428 は RFC1639 よりも推奨されます. FTP クラ イアントは, まず RFC2428 を試し, もしそれが失敗したな ら RFC1639 を試します. RFC2460: IPv6 specification (IPv6 仕様) RFC2461: Neighbor discovery for IPv6 (IPv6 における 近隣探索) 詳しくは本文書の 23.5.1.2 をご覧く ださい. RFC2462: IPv6 Stateless Address Autoconfiguration (IPv6 におけるステートレスアドレス自動設定) 詳しくは本文書の 23.5.1.4 をご覧ください. RFC2463: ICMPv6 for IPv6 specification (IPv6 のため の ICMPv6 仕様) 詳しくは本文書の 23.5.1.9 をご覧ください. RFC2464: Transmission of IPv6 Packets over Ethernet Networks (イーサネット上での IPv6 パケットの転送方式) RFC2465: MIB for IPv6: Textual Conventions and General Group (IPv6 用 MIB: 文字列的変換法と一般グループ) 必要な統計情報はカーネルにより集計されています. 実際の IPv6 MIB サポートは ucd-snmp に対するパッチキッ トとして提供されています. RFC2466: MIB for IPv6: ICMPv6 group (IPv6 用 MIB: ICMPv6 グループ) 必要な統計情報はカーネルにより集計されています. 実際の IPv6 MIB サポートは ucd-snmp に対するパッチキッ トとして提供されています. RFC2467: Transmission of IPv6 Packets over FDDI Networks (FDDI ネットワーク上での IPv6 パケットの転送方式) RFC2497: Transmission of IPv6 packet over ARCnet Networks (ARCnet ネットワーク上での IPv6 パケットの転送方 式) RFC2553: Basic Socket Interface Extensions for IPv6 (IPv6 のための 基本的ソケットインタフェースの拡張) IPv4 射影アドレス (3.7) と IPv6 ワイルドカードバ インドソケットの特別な動作 (3.8) をサポートしています. 詳しくは本文書の 23.5.1.12 をご覧ください. RFC2675: IPv6 Jumbograms (IPv6 巨大パケット) 詳しくは本文書の 23.5.1.7 をご覧ください. RFC2710: Multicast Listener Discovery for IPv6 (IPv6 のためのマルチキャスト受信者探索) RFC2711: IPv6 router alert option (IPv6 ルータ警報オ プション) draft-ietf-ipngwg-router-renum-08: IPv6 におけるルータの再番号付け draft-ietf-ipngwg-icmp-namelookups-02: ICMP による IPv6 名前検索 draft-ietf-ipngwg-icmp-name-lookups-03: ICMP による IPv6 名前検索 draft-ietf-pim-ipv6-01.txt: IPv6 用 PIM &man.pim6dd.8; は密モード (dense mode) を実装しています. &man.pim6sd.8; は疎モード (sparse mode) を実装しています. draft-itojun-ipv6-tcp-to-anycast-00: IPv6 エニーキャストアドレス向けに TCP 接続を切断 draft-yamamoto-wideipv6-comm-model-00 詳細は本文書の 23.5.1.6 を参照してください. draft-ietf-ipngwg-scopedaddr-format-00.txt : IPv6 のスコープ化アドレス形式の拡張 近隣探索 近隣探索はきわめて安定しています. 現在, アドレス検索 (Address Resolution), 重複アドレス検出 (Duplicated Address Detection), 近隣到達不能性検出 (Neighbor Unreachability Detection) がサポートされています. もうすぐ, カーネルに代理近 隣通知 (Proxy Neighbor Advertisement) サポートを加え, 管理者ツー ルとして近隣探索取消要請 (Unsolicited Neighbor Advertisement) を送出するコマンドを加える予定です. DAD (重複アドレス検出) が重複を検出した場合, そのアドレ スは "重複している" という印が付けられ, syslog にメッセージが 記録されます (そして通常はコンソールに表示されます). "重複して いる" 印は &man.ifconfig.8; で調べることができます. 重複検出の チェックおよび重複状態を解消することは管理者の責任となります. この動作は近いうちに改良するべきです. いくつかのネットワークドライバは, そうしないようにと指示 された場合でもマルチキャストパケットを自分自身に送り返してしま います (特に無差別 (promiscuous) モードでは). このような状況で は DAD は重複を検出するでしょう. なぜなら DAD を実行するプログ ラムは NS パケットの到着を検出し (それが自ノードが出力したもの であるにもかかわらず) それが重複を表しているとみなすからです. この問題に対処する方法は, sys/netinet6/nd6_nbr.c:nd6_dad_timer() 中の "heuristics" とマー クされた #if 条件のあたりを見てください ("heuristics" 部分のプ ログラムコードは仕様に反していることに注意してください). 近隣探索の仕様 (RFC2461) では, 以下に述べる状況での近隣 情報キャッシュの取り扱いについて記述されていません: 近隣情報キャッシュが空の時に, 下位層 (リンク層) アド レスを持たない RS/NS/NA/redirect 削除要請パケットを受信 下位層アドレスを持たない通信メディアにおける近隣情報 キャッシュの取り扱い (IsRouter ビットのために一つの近隣情 報キャッシュエントリが必要です) 一つめの場合については, IETF ipngwg メーリングリストで行 われた議論に基づく対応策を実装しています. より詳しくは, ソース コード中のコメントと, 1999 年 2 月 6 日の (IPng 7155) というメー ルから始まったスレッドを参照してください. IPv6 における同一リンク上かどうかの判断ルール (RFC2461) は, BSD のネットワークコードが想定している条件と全く異なります. とりあえず, デフォルトルータのリストが空の時には同一リンク上か どうかの判断ルールはサポートしていません (RFC2461 の 5.2 章, 第二文節の最後の文 - この仕様のこの章では何カ所かで "host" と "node" という単語の間違った使い方をしていることに注意). サービス妨害攻撃と無限ループをさけるために, ND パケット 中のオプションは 10 個だけが受け付けられます. そのため, もし RA に 20 個のプレフィックスを載せたとしても先頭の 10 個のプレ フィックスしか理解されません. もしこのことが問題となるのなら, FREEBSD-CURRENT メーリングリストに質問するか, または sys/netinet6/nd6.c 中の nd6_maxndopt を変 更してください. もし多くの要求があるようなら, この変数を変更す る sysctl 変数を用意できるでしょう. スコープ番号 IPv6 はスコープ化されたアドレスを使います. そのため, IPv6 アドレスにスコープ番号 (リンクローカルアドレスではインタ フェース番号, サイトローカルアドレスではサイト番号) を指定する ことは非常に重要です. スコープ番号が無いと, カーネルにとってス コープ化された IPv6 アドレスは曖昧なものとなり, そしてカーネル はそのパケットを出力するインタフェースを選ぶことができないでしょ う. ユーザランドのアプリケーションは, スコープ番号またはイン タフェース番号を指定するために, 通常は拡張 API (RFC2292) を使 うべきです. 同様の目的のために, RFC2553 において sockaddr_in6 構造体にsin6_scope_id メンバが定義されています. しかしながら, sin6_scope_id の意味づけは少々曖昧です. もし, あなたが自分のア プリケーションの移植性について気をつけたいのなら, sin6_scope_id ではなく拡張 API を使うことをお勧めします. カーネル中では, リンクローカルスコープのアドレスに対応す るインタフェース番号は IPv6 アドレスの二番目の 16 ビット語 (三 番めと四番めのバイト) に埋め込まれます. たとえばルーティングテー ブルとインタフェースアドレス構造体 (struct in6_ifaddr) の中で, 以下のような例を見ることができるでしょう: fe80:1::200:f8ff:fe01:6317 上で述べたアドレスはリンクローカルなユニキャストアドレス で, それはインタフェース番号が 1 であるネットワークインタフェー スに属するものです. 埋め込まれた番号によって, 複数のインタフェー スに対する IPv6 リンクローカルアドレス群を, 効率的に, かつ少々 のプログラムの対応だけで, 識別することができます. &man.route6d.8; や &man.ifconfig.8; のような, ルーティン グデーモンと設定プログラムは "埋め込まれた" スコープ番号を取り 扱う必要があります. これらのプログラムはルーティング用のソケッ トと (SIOCGIFADDR_IN6 のような) ioctl 群を使います. そしてカー ネル API は二番目の 16 ビット語を書き込んでから IPv6 アドレス を返します. これらの API はカーネル内部構造体を操作するための ものです. これらの API を利用するプログラムは, どちらにしろカー ネル間の違いについて意識する必要があります. コマンドラインでスコープ化されたアドレスを指定するときに は, (ff02:1::1 や fe80:2::fedc のような) 埋め込まれた形式を ＊ 絶対に＊ 使わないでください. たぶんこれでは動きません. インタ フェースを指定するコマンドラインオプション (たとえば ping6 -I ne0 ff02::1) を使うときには, 必ず ff02::1 や fe80::fedc のような標準形式を使ってください. 一般的 にいって, コマンドが出力インタフェースを指定するコマンドライン オプションを持っていないのならば, そのコマンドはスコープ化され たアドレスを受け付けることはできないでしょう. このことは IPv6 の, "歯医者のオフィス" をサポートするという前提に反するように 思えるでしょう. この問題に関して, わたしたちは仕様に何らかの改良を 加える必要があると信じています. いくつかのユーザランドのツールは, draft-ietf-ipngwg-scopedaddr-format-00.txt で文書化されている, IPv6 拡張数値記法をサポートしています. "fe80::1%ne0" というように, 出力インタフェースの名前を使って, パケットを出力するリンクを指定することができます. この方法によっ て, 特に問題なくリンクローカルなスコープ化されたアドレスを指定 することができるでしょう. あなたのプログラムでこの拡張数値記法を使うためには, &man.getaddrinfo.3;, と &man.getnameinfo.3; を NI_WITHSCOPEID をつけて使用する必要があります. 現在の実装では, リンクとインタ フェースとが一対一に対応していることを想定しています. これは仕 様で述べられているよりも強い想定です. プラグ & プレイ ほとんどの IPv6 ステートレスアドレス自動設定はカーネル中 に実装されています. 近隣探索機能は全てカーネル内に実装されてい ます. ルータ通知 (RA: Router Advertisement) のホストへの入力は カーネル内で実装されています. ルータ要請 (RS: Router Solicitation) の終端ホストからの出力, RS のルータへの入力, そ してルータでの RA の出力はユーザランドで実装されています. リンクローカルアドレスと特別アドレスの割り当て IPv6 リンクローカルアドレスは IEEE802 アドレス (イーサ ネットの MAC アドレス) から生成されます. 各インタフェースに は, そのインタフェースが利用可能になったとき (IFF_UP) に自動 的にリンクローカルアドレスが一つ割り当てられます. 同時に, そ のリンクローカルアドレスに対する直接のルートがルーティングテー ブルに加えられます. 以下に netstat コマンドの出力を示します: Internet6: Destination Gateway Flags Netif Expire fe80:1::%ed0/64 link#1 UC ed0 fe80:2::%ep0/64 link#2 UC ep0 IEEE802 アドレスを持っていないインタフェース (トンネル インタフェースのような疑似インタフェースや, ppp インタフェー ス) は, できる限り, イーサネットインタフェースなどの他のイン タフェースから IEEE802 アドレスを借用します. もし IEEE802 ア ドレスを持ったハードウェアが一つもなければ, 最後の手段として (MD5(ホスト名)で計算される) 疑似乱数値がリンクローカルアドレ スの元として使われます. もしこれがあなたの用途に合わないなら, リンクローカルアドレスを手動で設定する必要があるでしょう. もしあるインタフェースで IPv6 を使えない (たとえばマルチ キャストをサポートしない, 等の理由で) ならば, そのインタフェー スにはリンクローカルアドレスは割り当てられません. 詳細は 2 章をご覧ください. 各インタフェースは要請されたマルチキャストアドレスとリ ンクローカルな「全ノード」マルチキャストアドレスに加わります (すなわち, そのインタフェースがつながれたリンク上で, それぞ れ fe80::1:ff01:6317 と ff02::1 です). リンクローカルアドレ スに加え, ループバックアドレス (::1) がループバックインタフェー スに割り当てられます. また, ::1/128 と ff01::/32 が自動的に ルーティングテーブルに追加され, そしてループバックインタフェー スはノードローカルマルチキャストグループである ff01::1 に加 わります. ホスト上でのステートレスアドレス自動設定 IPv6 仕様では, ノードは二種類に分類されます: ルータとホストです. ルータは他宛のアドレスがついたパケットを転送します. ホストは パケットの転送を行いません. net.inet6.ip6.forwarding によっ て, このノードがルータであるかホストであるかが決定されます (1 ならルータで, 0 ならホストです). ホストがルータ通知 (Router Advertisement) をルータから 受信すると, ホストはステートレスアドレス自動設定によって自ら を自動設定することができます. この動作は net.inet6.ip6.accept_rtadv によって制御できます (1 にセット されているとホストは自らを自動設定します). 自動設定によって, この受信したインタフェースにネットワークアドレスプリフィック ス (通常はグローバルアドレスプリフィックス) が追加されます. デフォルトルートも同時に設定されます. ルータは定期的にルータ 通知パケットを送出します. 隣接するルータに RA パケットを送出 するよう要求するために, ホストはルータ要請 (Router Solicitation) を送信することができます. 好きなときに RS パケッ トを送出するためには, rtsol コマンドを 使います. また, &man.rtsold.8; デーモンもあります. &man.rtsold.8; は必要なときにはいつでもルータ要請を送出しま す. これは移動体のような使い方 (ノート型やラップトップ型コン ピュータ) をするときにとても調子良く働きます. もしルータ通知 を無視したいのなら, sysctl で net.inet6.ip6.accept_rtadv を 0 にしてください. ルータでルータ通知を送出するには &man.rtadvd.8 デーモ ンを使います. IPv6 仕様では, 以下の事柄を想定しており, それらに合致 しないケースに関しては仕様化されていないことに注意してくださ い: ホストだけがルータ通知を待ち受けている ホストは (ループバック以外には) ネットワークインタ フェースを一つだけ持つ 以上のことより, ルータや複数のインタフェースを持つホス トで net.inet6.ip6.accept_rtadv を有効にすることは賢いことで はないことが分かります. 設定を失敗したノードは変な動作をする 可能性があります (経験をしてみたい人のために仕様にあわない設 定も許されています). sysctl 変数を整理すると: accept_rtadv forwarding ノードの役割 --- --- --- 0 0 ホスト (手動で設定された) 0 1 ルータ 1 0 自動設定されたホスト (仕様ではホストはインタフェー スを一つのみ持つことを想定して いるので, 複数のインタフェース を持つホストの自動設定は想定外) 1 1 不正, または実験的 (仕様の想定外) RFC2462 の 5.5.3 (e) には到着した RA プリフィックス情 報オプションの検証ルールが書いてあります. これは悪意のある (または設定を失敗した) ルータが非常に短いプリフィックス生存 期間を通知してくることに対してホストを防御するためのものです. ipngwg メーリングリストで Jim Bound による更新があり (メーリ ングリストアーカイブの "(ipng 6712)" をご覧ください), ここで の実装はこの Jim の更新を取り入れたものです. DAD と自動設定との関係については, 本文書の 23.5.1.2 をご覧ください. 包括的トンネルインタフェース (Generic tunnel interface) GIF (包括的インタフェース: Generic Interface) は構成された トンネルのための疑似インタフェースです. 詳細は &man.gif.4; に 述べられています. 現在, v6 in v6 v6 in v4 v4 in v6 v4 in v4 が利用できます. gif インタフェースに物理的な (外側の) 始 点と終点アドレスを割り当てるためには &man.gifconfig.8; を使い ます. 内側と外側の IP ヘッダで同じアドレスファミリを使う (v4 in v4, または v6 in v6) 設定は危険です. 無限段数のトンネルを作っ てしまうようにインタフェースとルーティングテーブルを設定するの はとても簡単だからです.注意してください! gif は ECN (Explicit Congestion Notification: 明示的輻輳 通知) とともに使えるように設定することができます. ECN との親和 性については 23.5.4.5 をご覧ください. また, 設定方法に関しては &man.gif.4; をご覧ください. もし IPv4-in-IPv6 トンネルを gif インタフェースを使って 設定しようと思っているなら, &man.gif.4; を注意深く読んでくださ い. gif インタフェースに自動的に割り当てられる IPv6 リンクロー カルアドレスを削除する必要があるでしょう. 始点アドレスの選択 現在の始点選択ルールはスコープ指向です (いくつかの例外も あります - 以下を参照してください). ある終点アドレスに対する始 点 IPv6 アドレスは以下の規則に従って選択されます: もし始点アドレスがユーザにより明示的に指定 (たとえば拡 張 API を通じて) されていたならば, その指定されたアドレス が使われる. 出力インタフェース (通常はルーティングテーブルを検索 することにより決定される) にアドレスが割り当てられており, そのアドレスが終点アドレスと同一のスコープを持っているなら ば, そのアドレスが使われる. これがもっとも一般的な場合です. もし上記の場合を満たすアドレスがなかったときには, 送 出するノードが持つインタフェースのうちのどれか一つに割り当 てられているグローバルアドレスを選択する. もし上記の場合を満たすアドレスがなかったときで, 終 点アドレスがサイトローカルスコープであった場合には, 送出す るノードが持つインタフェースのうちのどれか一つに割り当てら れているサイトローカルアドレスを選択する. もし上記の場合を満たすアドレスがなかったときは, 終 点に向かっているルーティングテーブルエントリに関連づけられ たアドレスを選択する. これは最後の手段であり, スコープ違反 を引き起こす可能性がある. たとえば, ff01::1 に対しては ::1 が選択され, fe80:1::2a0:24ff:feab:839b に対しては fe80:1::200:f8ff:fe01:6317 が選択されます (埋め込まれたインタ フェース番号に注意 - 23.5.1.3 で述べられている - この番号により正しい始点アドレスが選択できます. これらの埋め込 まれた番号は通信路 (wire) 上では存在しません). もし出力インタ フェースが該当するスコープに対して複数のアドレスを持っていた場 合は, 始点は最長一致法 (規則 3) で選択されます. たとえば, 出力イ ンタフェースに, 3ffe:501:808:1:200:f8ff:fe01:6317 と 3ffe:2001:9:124:200:f8ff:fe01:6317 が付けられていたとします. 終点アドレスが 3ffe:501:800::1 であるとすると, 始点アドレスと しては 3ffe:501:808:1:200:f8ff:fe01:6317 が選択されます. 上記の規則は IPv6 仕様では文書化されていないことに注意し てください. これは「実装に任された」項目と考えられているのです. 上記の規則に則らないケースがいくつかあります. 一つの例は, 接続 済みの TCP セッションで, この場合は tcb に保存されているアドレ スを始点とします. 他の例としては, 近隣通知 (Neighbor Advertisement: NA) の際の始点アドレスです. 仕様 (RFC2461 7.2.2) によれば, NA の始点アドレスは対応する NS (近隣要請) の ターゲットアドレスであるべきとされています. この場合は, 上記の 最長一致規則ではなく仕様に従います. 新規に接続を行うとき (規則 1 に当てはまらないとき) に, 他に選択肢がある限り, 推奨有効期間切れアドレス (preferred lifetime が 0 であるアドレス）を始点アドレスとして選択すること はありません. もし他の選択肢がなければ, 最後の手段として推奨有 効期限切れアドレスが使われます. もし複数の推奨有効期間切れアド レスがあるときには, 上記のスコープ規則に従ってそれらのアドレス からの選択が行われます. もし何らかの理由により推奨有効期間切れ アドレスの使用を禁止したいのならば, net.inet6.ip6.use_deprecated を 0 に設定してください. 推奨有効 期間切れアドレスに関連する問題は, RFC2462 5.5.4 に記述されてい ます (注意: IETF の ipngwg では推奨有効期間切れアドレスをどの ように使うべきかの議論がいくつか進行中です). 巨大ペイロード 巨大ペイロード中継点毎オプションは実装されており, 65,535 バイトよりも長いペイロードを持つ IPv6 パケットを送信するときに 利用できます. しかし, MTU が 65,535 よりも大きな物理インタフェー スは現在サポートされていませんから, そのようなペイロードはルー プバックインタフェース (たとえば lo0) 上でのみ利用できます. もし巨大ペイロードを試してみたいのならば, まず始めに, ルー プバックインタフェースの MTU が 65,535 バイトよりも大きくなる ようにカーネルの再構成を行わなければなりません; 以下の行をカー ネル構成ファイルに追加してください: options "LARGE_LOMTU" #To test jumbo payload そして新しいカーネルをコンパイルしてください. 次に, &man.ping6.8; コマンドを -b と -s オプション付きで 使うことで巨大ペイロードを試してみることができます. -b オプショ ンはソケットバッファの大きさを拡大するために指定しなければなリ ません. -s オプションによりパケット長を指定します. その値は 65,535 よりも大きくなるでしょう. たとえば以下のように入力してく ださい: &prompt.user; ping6 -b 70000 -s 68000 ::1 IPv6 仕様では, 巨大ペイロードオプションは分割された (fragtment) ヘッダを持つパケットでは使えないことになっています. この条件が破られると ICMPv6 Parameter Problem メッセージが送信 元に送られるはずです. この仕様には従っているのですが, 通常はこ の ICMPv6 エラーを見ることはできないでしょう. IPv6 パケットが受信されると, そのフレーム長が調べられ, そして IPv6 ヘッダ中のペイロード長フィールド, またはもしあれば 巨大ペイロードオプションの値, で指定された長さと比較されます. もし前者の方が後者よりも短ければ, パケットは廃棄され統計情報が 更新されます. この統計情報は, &man.netstat.8; コマンドを `-s -p ip6' オプション付きで実行すると見ることができます: &prompt.user; netstat -s -p ip6 ip6: (snip) 1 with data size < data length それ故, カーネルはエラーを起こしたパケットが本当に巨大ペ イロードである, すなわち, そのパケット長が 65,535 バイトよりも 長い場合にしか ICMPv6 エラーを送りません. 上で述べたように, 現 在そのような巨大な MTU をもつ物理インタフェースはサポートされ ていませんので, IPMPv6 エラーが返ることは滅多にないでしょう. 現状では, 巨大パケット上の TCP/UDP はサポートされていま せん. これはテストできる通信メディアが (ループバック以外) 存在 しないためです. もしこれを必要としているなら, わたしたちに連絡して ください. IPsec は巨大パケットの上では動作しません. これは, 巨大パ ケットと AH を同時にサポートする場合の仕様の「ねじれ」のせいで す (AH ヘッダサイズはペイロード長に影響を及ぼし, そしてこのこ とが, 巨大ペイロードオプションと AH が両方付いた到着パケッ トを認証することを本当に困難にしてしまうのです). *BSD において巨大パケットをサポートするには基本的な問題 がいくつかあります. それらをここで指摘したいのですが, このリス トを完成させるためにはもっと時間が必要です. その中のいくつかを 以下に挙げます: 4.4BSD では mbuf の pkthdr.len フィールドは "int" 型 ですから, 32 ビットアーキテクチャの CPU 上では 2 ギガバイ ト以上の巨大パケットを保持できません. 巨大パケットを正しく サポートするには, このフィールドは, 4 ギガバイト + IPv6 ヘッ ダ + 下位層ヘッダを保持できるように拡張されなければなりま せん. そのため, 少なくとも int64_t に拡張する必要がありま す (u_int32_t では十分では＊ありません＊). 多くの場所で, パケット長を格納するための場所を誤って "int" としてしまっています. それらをもっと大きな整数型に変 換する必要があります. この作業には細心の注意が必要です. な ぜならパケット長の計算をするときにオーバフローを起こしてし まうかもしれないからです. たくさんの場所で, パケットのペイロード長を調べるのに, 間違って IPv6 ヘッダの ip6_plen フィールドをチェックしてい ます. そうではなくて, mbuf の pkthdr.len を調べなければな りません. ip6_input() が入力時に巨大ペイロードオプションの 健全性をチェックするようにすれば, その後は mbuf の pkthdr.len を安全に使うことができるでしょう. TCP のコードには, もちろん, たくさんの場所の注意深い更 新が必要でしょう. ヘッダ処理中のループ防止 IPv6 仕様はパケットに任意の数の拡張ヘッダがつくことを許 しています. もし IPv6 パケット処理コードを BSD の IPv4 コード が実装されているのと同様の方法で実装すると, 何重もの関数呼び出 しのせいでカーネルスタックがオーバーフローしてしまうでしょう. sys/netinet6 のコードは, カーネルスタックオーバフローを回避す るように注意深く設計されています. そのために, sys/netinet6 の コードでは独自のプロトコルスイッチ構造体を "struct ip6protosw" (netinet6/ip6protosw.h を参照してください) として定義しています. 互換性のために, IPv4 の部分 (sys/netinet) にはこの変更を行っていませんが, しかし, 小さな変 更が pr_input() のプロトタイプについて行われています. そのため "struct ipprotosw" も定義されています. 以上の理由により, 非常 に多くの IPsec ヘッダを持つ IPsec-over-IPv4 パケットを受け取っ たときにカーネルスタックがオーバーフローする可能性があります. IPsec-over-IPv6 は大丈夫です. (もちろん, それら全ての IPsec ヘッ ダが全て処理されるには, 一つ一つの IPsec ヘッダがそれぞれ IPsec の試験をパスする必要があります. そのため, 外部の攻撃者が そのような攻撃をすることは不可能です.) ICMPv6 RFC2463 が公開された後, IETF の ipngwg は, ネットワーク メディア上の ICMPv6 ストームを引き起こさないように, ICMPv6 向 け直し (redirect) に対して ICMPv6 エラーパケットを出さないよう に決定しました. これはすでにカーネル内で実装されています. アプリケーション ユーザランドのプログラミングのために, RFC2553, RFC2292, そして発行準備中の internet draft で定義されている, IPv6 ソケッ ト API をサポートしています. IPv6 上の TCP/UDP は利用可能であり, きわめて安定していま す. &man.telnet.1;, &man.ftp.1;, &man.rlogin.1;, &man.rsh.1;, &man.ssh.1, 等を試してみてください. これらのアプリケーションは プロトコル非依存となっています. つまり, DNS に従って自動的に IPv4 と IPv6 を選択します. カーネルの内部 ip_forward() は ip_output() を呼びだしていますが, ip6_forward() は ip_output() を直接呼びだします. これは, ルー タは IPv6 のパケットを断片に分割してはいけないからです. ICMPv6 は最大 1280 まで, できる限り元のパケットをコピー して含んでおく必要があります. たとえば, UDP6/IP6 ポート不到達 ICMPv6 パケットは, 全ての拡張ヘッダと, ＊未変更の＊ UDP6 と IP6 ヘッダを含まなければなりません. そのため, TCP を除く全ての IP6 関数はオリジナルのパケットを保存しておくために, ネットワー クバイト順をホストバイト順に変換しません. tcp_input() と udp6_input(), icmp6_input() は, 拡張ヘッ ダがあるために, IP6 ヘッダのすぐ後ろにトランスポートヘッダがあ ることを仮定できません. そのため, in6_cksum() は IP6 ヘッダと トランスポートヘッダが連続しないようなパケットを処理できるよう に実装されています. チェックサム計算のための TCP/IP6 ヘッダ構 造体も, UDP6/IP6 ヘッダ構造体も存在しません. IP6 ヘッダと, 拡張ヘッダ, トランスポートヘッダを容易に処 理できるように, ネットワークドライバに対する新たな要求事項とし て, パケットを一つの内部 mbuf に納めるか, または, 一つ以上の外 部 mbuf に納める必要性を追加しました. 典型的な古いドライバは, 96 から 204 バイトのデータ用の二つの内部 mbuf を用意しますが, 今後はそのようなパケットデータは一つの外部 mbuf に記録されるこ とになります. netstat -s -p ip6 を実行すると, ドラ イバが上記の要求を満たしているかどうかが分かります. 以下の例で は "cce0" は要求を満たしていません (詳細は 2 章をご覧ください.) Mbuf statistics: 317 one mbuf two or more mbuf:: lo0 = 8 cce0 = 10 3282 one ext mbuf 0 two or more ext mbuf 各入力関数は始めの段階で, IP6 とそのヘッダが連続した領域 にあるかどうかを調べるために IP6_EXTHDR_CHECK を呼び出します. IP6_EXTHDR_CHECK は mbuf が M_LOOP フラグを持っているときのみ m_pullup() を呼び出します. M_LOOP フラグは, パケットがループバッ クインタフェースからきたことを示します. 物理的なネットワークイ ンタフェースからきたパケットに対しては m_pullup() が呼ばれるこ とはありません. IP と IP6 両方の再構成 (reassemble) 機能は m_pullup() を 呼び出すことはありません. IPv4 射影アドレスと IPv6 ワイルドカードソケット RFC2553 では, IPv4 射影 (mapped) アドレス (3.7) と IPv6 ワイルドカードバインドソケットの特別な振る舞い (3.8) が記述さ れています. 仕様では以下の動作が許されています: AF_INET6 ワイルドカードバインドソケットで IPv4 接続 を受け付ける. 特別な形式のアドレス, たとえば ::ffff:10.1.1.1 を使うこ とで AF_INET6 ソケットから IPv4 のパケットを送出する. しかし, 仕様自体が非常に込み入っており, またこの仕様では ソケット層がどう動作すべきかということについて何も規定していま せん. ここでは前者を "待ち受け側" と呼び, 後者を "開始側" と呼 ぶことにします. 同一のポート上で, 両アドレスファミリのワイルドカードバイ ンドを実行することができます. 以下の表に FreeBSD 4.x の動作を示します. 待ち受け側 開始側 (AF_INET6 ワイルド (::ffff:10.1.1.1 への接続) カードソケットが IPv4 接続を受ける.) --- --- FreeBSD 4.x 設定可能 サポートされている デフォルト: 有効 以下の章で, より詳細を述べると共に, どうやってこの動作を 設定するかを示します. 待ち受け側に対するコメント: RFC2553 は, ワイルドカードバインドの問題についてあまりに も少ししか議論していません. 特に, ポート空間の問題, 失敗モード, そして AF_INET/INET6 ワイルドカードバインド間の関連について. この RFC に関しては, これに準処しているにもかかわらず異なった 動作をするいくつかの別々の解釈が成り立ちます. そのため, 移植可 能なアプリケーションを実装する際には, カーネルの動作について一 切の仮定をおくべきではありません. &man.getaddrinfo.3; を使う のがもっとも安全な方法です. ポート番号空間とワイルドカードバイ ンドの問題は, 1999 年 3 月半ばに ipv6imp メーリングリストにお いてつっこんだ議論がなされましたが, 最終的な合意は得られなかっ たようです (つまり, 実装次第ということです). メーリングリスト のアーカイブを調べてみてはいかがでしょうか. サーバアプリケーションで, IPv4 と IPv6 の両方の接続を受 けたいのなら, 別の方法が二つあります. 一つは, AF_INET ソケットと AF_INET6 ソケットを使う方法で す (二つのソケットが必要です). &man.getaddrinfo.3; を ai_flags に AI_PASSIVE を設定して使い, そして, 返ってきた全て のアドレスに対して &man.socket.2; と&man.bind.2; を使います. 複数のソケットを開くことで, 適切なアドレスファミリを持つソケッ ト上で接続を受けることができます. IPv4 接続は AF_INET ソケット で受けられ, そして IPv6 接続は AF_INET6 ソケットで受けられるで しょう. もう一つの方法は, AF_INET6 のワイルドカードバインドソケッ トを使う方法です. ai_flags にAI_PASSIVE を, ai_family に AF_INET6 を設定し, そして一つ目の引数であるホスト名を NULL に して &man.getaddrinfo.3; を使ってください. そして返ってきたア ドレス (IPv6 の未指定アドレスであるはずです) に対して &man.socket.2; と &man.bind.2; を行います. この一つのソケット で, IPv4 と IPv6 のパケットを受けることができます. 移植可能な方法で, AF_INET6 ワイルドカードバインドソケッ トで IPv6 のみをサポートするには, 待ち受けしている AF_INET6 ソ ケットに対して接続要求をしてきた相手アドレスを毎回チェックする ようにしてください. もしそのアドレスが IPv4 射影アドレスであっ たなら, その接続を遮断する必要があるかもしれません. この条件を 判定するのに, IN6_IS_ADDR_V4MAPPED() マクロを使うことができま す. この問題をもっと簡単に解決するために, システム依存の &man.setsockopt.2; オプション, IPV6_BINDV6ONLY があります. そ の使い方を以下に示します. int on; setsockopt(s, IPPROTO_IPV6, IPV6_BINDV6ONLY, (char *)&on, sizeof (on)) < 0)); この呼び出しが成功すれば, このソケットは IPv6 パケットの みを受信します. 開始側についてのコメント: アプリケーション実装者へのアドバイス: 移植可能な (複数種 の IPv6 カーネル上で動作する) IPv6 アプリケーションを実装する には, 以下に述べる点が成功への鍵となると信じます: ＊絶対に＊ AF_INET も AF_INET6 もハードコードしない. システムを通じて &man.getaddrinfo.3; と &man.getnameinfo.3; を使う. gethostby*() や, getaddrby*(), inet_*(), getipnodeby*() を絶対に使わない (既存アプリケー ションを簡単に IPv6 対応とするために, getipnodeby*() が便 利なこともあるでしょう. しかし, 可能であれば, コードを書き 直して &man.getaddrinfo.3; と &man.getnameinfo.3; を使うよ うに努力してみてください.) ある終点 (destination) に対して接続したいときは, &man.telnet.1; のように, &man.getaddrinfo.3; を使って, 返っ てきた全ての終点について試すようにしてください. いくつかの IPv6 プロトコルスタックは, バグありの &man.getaddrinfo.3; 付きで出荷されています. 最低限きちんと 動作するバージョンをあなたのアプリケーションと一緒に出荷し, それを最後の手段として使いましょう. もし AF_INET6 ソケットから IPv4 と IPv6 の両方の接続を行 いたいのなら, &man.getipnodebyname.3; を使う必要があるでしょう. 既存のアプリケーションを工数最小で IPv6 対応に更新したいのなら ば, この方法がよいでしょう. しかし, これは一時的な解であること に注意してください. なぜなら, スコープ化された IPv6 アドレスを 全く扱うことができないという欠点があるので &man.getipnodebyname.3; 自身を推薦できないからです. IPv6 の名 前検索には, &man.getaddrinfo.3; が推奨される API です. ですか ら, 時間があるときには, アプリケーションを &man.getaddrinfo.3; を使うように書き換えるべきです. 外部に出ていく接続を行うアプリケーションを書くときに, も し AF_INET と AF_INET6 とを完全に別々のアドレスファミリとして 取り扱うのならば, 話は非常に単純になります. {set,get}sockopt の問題は単純になり, DNS の問題も単純になるでしょう. IPv4 射影 アドレスに依存する手法は推薦できません. tcp と inpcb の統合コード FreeBSD 4.x では, tcp に関しては IPv4 と IPv6 でコード を共有しています (sys/netinet/tcp* で). そして udp4/6 では別々 のコードです. 統合した inpcb 構造体を使っています. このプラットフォームは IPv4 射影アドレスをサポートする ように設定できます. カーネルの設定は以下のようにまとめられま す: デフォルトでは, AF_INET6 ソケットはある条件下では IPv4 接続をハンドリングできます. そして IPv4 射影の IPv6 アドレス中に入っている IPv4 の終点へ向けて接続を開始する ことができます. 以下のように sysctl を使ってシステム全体でそれを無 効にできます. sysctl -w net.inet6.ip6.mapped_addr=0 待ち受け側 各ソケットは特別な AF_INET6 ワイルドカードバインドを サポートするように設定できます (デフォルトで有効です). 以 下のように, ソケット毎に &man.setsockopt.2; を使ってこれを 無効にできます. int on; setsockopt(s, IPPROTO_IPV6, IPV6_BINDV6ONLY, (char *)&on, sizeof (on)) < 0)); ワイルドカード AF_INET6 ソケットは, 以下の条件が成り 立つときのみ, IPv4 接続をハンドリングできます: その IPv4 接続にマッチする AF_INET ソケットが存 在しない その AF_INET6 ソケットは IPv4 通信を受け付けるよ うに設定されている, すなわち getsockopt(IPV6_BINDV6ONLY) が 0 を返す. open/close の順番は問題となりません. 開始側 FreeBSD 4.x では, ノードが IPv4 射影アドレスをサポー トするように設定されているときには, IPv4 射影アドレス (::ffff:10.1.1.1) へ向けての接続がサポートされています. sockaddr_storage RFC2553 が最後の仕上げにかかっている頃, sockaddr_storage 構造体のメンバにどのように名前を付けるかという議論がありました. 一つの提案は, それがいじってはいけないものであるのだから, メン バ名の前に "__" を付ける ("__ss_len" のように), というものでし た. 他の提案は, それらのメンバを直接操作する必要があるのだから, なにも付けない ("ss_len" のように), というものでした. この件に 関する明確な合意は得られませんでした. その結果として, RFC2553 では sockaddr_storage 構造体は以 下のように定義されました: struct sockaddr_storage { u_char __ss_len; /* address length */ u_char __ss_family; /* address family */ /* and bunch of padding */ }; これに反して, XNET ドラフトでは以下のように定義されまし た: struct sockaddr_storage { u_char ss_len; /* address length */ u_char ss_family; /* address family */ /* and bunch of padding */ }; 1999 年 12 月に, RFC2553bis では後者 (XNET) の定義を採用 することで合意がなされました. 現在の実装は, RFC2553bis の議論の結果, XNET の定義に適合 するようになっています. 複数の IPv6 実装を調べたならば, 両方の定義を見ることにな るでしょう. ユーザランドのプログラマとして, この件に対応するもっ とも移植性が高い方法は: GNU autoconf を使って, ss_family と/または ss_len がこのプラットフォームで利用可能であることを確かめる, -Dss_family=__ss_family として (ヘッダファイルも含め て) 全てを __ss_family に統合してしまう, または __ss_family には絶対に手を出さない. sockaddr * へキャ ストして, 以下の例のように sa_family を使う: struct sockaddr_storage ss; family = ((struct sockaddr *)&ss)->sa_family ネットワークドライバ ここで, 以下の二項目を標準的なドライバでサポートすることが必須 となります: mbuf クラスタリングが要求されます. この安定版リリース においては, 全てのドライバが期待通りに動くように, 全てのオペ レーティングシステムにおいて MINCLSIZE を MHLEN+1 に変更しま した. マルチキャスト. もしあるインタフェースについて &man.ifmcstat.8; が一つもマルチキャストグループを示さないな ら, そのインタフェースは修正が必要です. もしあるドライバが上記要求をサポートしないなら, そのドラ イバでは IPv6 と/または IPsec 通信には使えません. もしあなた のカードで IPv6/IPsec の使用に関して何か問題を見つけたなら, 是 非それを freebsd-bugs@FreeBSD.org に報告してくだ さい. (注: かつて, 全ての PCMCIA ドライバに in6_ifattach() を呼 ぶことを要求したことがありました. 現在では, もはやこの要求は 取り下げています) トランスレータ ここでは IPv4/IPv6 トランスレータを四つに分類します: トランスレータ A --- 移行の初期 の段階で使われるもので, IPv6 島上の IPv6 ホストから IPv4 海上の IPv4 ホストへの接続を確立できるようにするものです. トランスレータ B --- 移行の初期 の段階で使われるもので, IPv4 海上の IPv4 ホストから IPv6 島上の IPv6 ホストへの接続を確立できるようにするものです. トランスレータ C --- 移行の後期 の段階で使われるもので, IPv4 島上の IPv4 ホストから IPv6 海上の IPv6 ホストへの接続を確立できるようにするものです. トランスレータ D --- 移行の後期 の段階で使われるもので, IPv6 海上の IPv6 ホストから IPv4 島上の IPv4 ホストへの接続を確立できるようにするものです. 分類 A のための TCP 中継トランスレータはサポートされてい ます. これは "FAITH" と呼ばれます. 分類 A のための IP ヘッダト ランスレータも提供しています. (後者は FreeBSD 4.x ではまだ取り 込まれていません.) FAITH TCP 中継トランスレータ FAITH システムはカーネルの助けを借りた &man.faithd.8; と 呼ばれる TCP 中継デーモンを利用します. FAITH は IPv6 アドレス プリフィックスを一つ予約し, そのプリフィックスに向かう TCP 接 続を IPv4 終点に向けて中継します. たとえば, 予約された IPv6 プリフィックスが 3ffe:0501:0200:ffff:: で, TCP 接続の IPv6 終点が 3ffe:0501:0200:ffff::163.221.202.12 であるならば, その接続は 163.221.202.12 という IPv4 終点に向けて中継されます. 終点 IPv4 ノード (163.221.202.12) ^ | 163.221.202.12 へ向けた IPv4 tcp FAITH-中継 二重スタックノード ^ | 3ffe:0501:0200:ffff::163.221.202.12 へ向けた IPv6 TCP 始点 IPv6 ノード FAITH-中継 二重スタックノードでは &man.faithd.8; を起動 しておく必要があります. より詳細な情報は, src/usr.sbin/faithd/README をご覧ください. IPsec IPsec は主に三つの構成要素からなります. ポリシ管理 鍵管理 AH と ESP のハンドリング ポリシ管理 現在のカーネルには実験的なポリシ管理コードが実装されてい ます. セキュリティポリシを管理するには二つの方法があります. 一 つは, &man.setsockopt.2; を使ってソケット一つずつにポリシを設 定する方法です. この場合のポリシ設定は &man.ipsec.set.policy.3; で説明されています. もう一つの方法は, &man.setkey.8; によって PF_KEY インタフェース経由でカーネル内 のパケットフィルタをもとにしたポリシを設定する方法です. ポリシエントリはその番号によって並び替えられることはない ので, エントリを追加するときの順番がとても重要になります. 鍵管理 このキットで実装されている鍵管理コード (sys/netkey) は, 自家製の PFKEY v2 実装です. これは RFC2367 に準処しています. 自家製の IKE デーモンである "racoon" がこのキットに含ま れています (kame/kame/racoon). 基本的に, racoon はデーモンとし て走らせる必要があり, それから鍵を要求するポリシをセットアップ します (たとえば, ping -P 'out ipsec esp/transport//use' というように). カーネルは鍵を交 換するために, 必要に応じて racoon デーモンにアクセスします. AH と ESP のハンドリング IPsec のモジュールは, 標準の IPv4/IPv6 処理中の "フック" として実装されています. パケットを送信するときに, ip{,6}_output() は 一致する SPD (Security Policy Database: セ キュリティポリシデータベース) があるかどうかをチェックして ESP/AH 処理が必要かどうかを判断します. もし ESP/AH が必要なら, {esp,ah}{4,6}_output() が呼ばれ, mbuf が適切に更新されます. パ ケットを受信したときは, プロトコル番号に従って, すなわち (*inetsw[proto])() という形で {esp,ah}4_input() が呼ばれます. {esp,ah}4_input() はそのパケットの認証情報を解読 / 試験し, そ して数珠繋ぎのヘッダと ESP/AH のためのパディングを取り除きます. パケット受信時に ESP/AH ヘッダを取り除いてしまっても安全です. なぜなら受信したパケットを "あるがまま" の形で使うことは絶対に ないからです. ESP/AH を使うことによって, TCP4/6 における実効データセグ メント長は ESP/AH によって挿入される数珠繋ぎのヘッダの増加分だ け影響を受けます. わたしたちのコードはこの場合を考慮に入れています. 基本的な暗号機能は "sys/crypto" ディレクトリの中にありま す. ESP/AH 変換は wrapper 関数と一緒に {esp,ah}_core.c に記述され ています. もしアルゴリズムを追加したかったら, wrapper 関数を {esp,ah}_core.c に追加し, そして追加する暗号アルゴリズムを実装 したコードを src/crypto に追加してください. このリリースでは, トンネルモードは以下の制限と共に部分的 にサポートされています: IPsec トンネルは GIF による包括的トンネリングインタ フェースと結合されていません. ip_output() と tunnelifp->if_output() の間で無限ループを構成してしまうか もしれないので, 非常に注意深く作業する必要があります. 統合 した方がよいか, よくないか, 意見はいろいろ出ています. MTU と 分割禁止ビット (IPv4) についての考慮はさらな るチェックを必要としています, が, 基本的にはうまく動いてい ます. AH トンネルのための認証モデルは再考する必要があるで しょう. 今後, ポリシ管理エンジンを改良する必要が出てくると 思われます. RFC と ID への準処 カーネル内の IPsec コードは以下の標準に準処しています (もしくは, 準処しようと努力しています): rfc182[5-9].txt で文書化されている "old IPsec" 仕様 rfc240[1-6].txt と, rfc241[01].txt, rfc2451.txt, draft-mcdonald-simple-ipsec-api-01.txt (このドラフトは期限切れですが, ftp://ftp.kame.net/pub/internet-drafts/ から入手できま す) で文書化されている "new IPsec" 仕様. (注: IKE 仕様, rfc241[7-9].txt はユーザラ ンドの "racoon" IKE デーモンとして実装されています) 現在サポートしているアルゴリズムは: old IPsec AH 空の暗号チェックサム (文書化されていません. デ バッグのためだけのものです) 128 ビットの暗号チェックサムと鍵付き MD5 (rfc1828.txt) 128 ビットの暗号チェックサムと鍵付き SHA1 (文書化されていません) 128 ビットの暗号チェックサムと HMAC MD5 (rfc2085.txt) 128 ビットの暗号チェックサムと HMAC SHA1 (文書化されていません) old IPsec ESP 空の暗号化 (文書化されていません, rfc2410.txt と似たものです) DES-CBC モード (rfc1829.txt) new IPsec AH 空の暗号チェックサム (文書化されていません. デ バッグのためだけのものです) 96 ビットの暗号チェックサムと鍵付き MD5 (文書化されていません) 96 ビットの暗号チェックサムと鍵付き SHA1 (文書化されていません) 96 ビットの暗号チェックサムと HMAC MD5 (rfc2403.txt) 96 ビットの暗号チェックサムと HMAC SHA1 (rfc2404.txt) new IPsec ESP 空の暗号化 (rfc2410.txt) DES-CBC with derived IV (draft-ietf-ipsec-ciph-des-derived-01.txt, draft expired) DES-CBC with explicit IV (rfc2405.txt) 3DES-CBC with explicit IV (rfc2451.txt) BLOWFISH CBC (rfc2451.txt) CAST128 CBC (rfc2451.txt) RC5 CBC (rfc2451.txt) 上記のそれぞれは, 以下と結合可能: HMAC-MD5(96 ビット) による ESP 認証 HMAC-SHA1(96 ビット) による ESP 認証 以下のアルゴリズムはサポートされて ＊いません＊: old IPsec AH 128 ビットの暗号チェックサムと HMAC MD5 + 64 ビット の再送攻撃防止 (rfc2085.txt) 160 ビット暗号チェックサムと鍵付き SHA1 + 32 ビッ トのパディング (rfc1852.txt) IPsec (カーネル内) と IKE (ユーザランドの "racoon") は, 何回もの相互接続性試験イベントで試験されていて, そこでの結果とし て, 多くの他の実装とうまく相互接続可能であることがわかっていま す. また, 現在の IPsec 実装は, RFC に記述された IPsec 暗号ア ルゴリズムを非常に広くカバーしています (知的所有権の問題がない アルゴリズムに限ってカバーしています). IPsec トンネルにおける ECN の考察 ECN と親和性のある IPsec トンネルは, draft-ipsec-ecn-00.txt で述べられている方 法を用いてサポートされています. 通常の IPsec トンネルは RFC2401 で記述されています. カプ セル化されるときに, 内側の IP ヘッダの IPv4 TOS フィールド (ま たは, IPv6 トラフィッククラスフィールド) が外側の IP ヘッダに コピーされます. カプセル解放の時には外側の IP ヘッダは単に削ら れるだけです. 外側の IP ヘッダの TOS / トラフィッククラスフィー ルド中の ECN ビットが失われてしまうため, このカプセル解放規則 は ECN と互換性がありません. IPsec トンネルを ECN と親和性があるようにするために, カ プセル化手順とカプセル解放手順を変更する必要がありました. これ については, http://www.aciri.org/floyd/papers/draft-ipsec-ecn-00.txt の 3 章で記述されています. net.inet.ipsec.ecn (または net.inet6.ipsec6.ecn) に設定 する値によって, IPsec トンネルの実装は三通りの動作を行います: RFC2401: ECN を考慮しない (sysctl の値が -1 の時) ECN 禁止 (sysctl の値が 0 の時) ECN 許可 (sysctl の値が 1 の時) この振る舞いはノード毎に設定可能であり SA 毎ではないこ とに注意してください (draft-ipsec-ecn-00 では SA 毎の設定を要 求していますが, それは大変すぎます). ここで述べた動作をまとめると以下のようになります (より詳 しくはソースコードをご覧ください): カプセル化 カプセル解放 --- --- RFC2401 内側から外側へ 外側の TOS ビットを落とす 全ての TOS ビットをコピー. (内側の TOS ビットをそのまま使う) ECN 禁止 内側から外側へ ECN ビット以外 外側の TOS ビットを落とす (0xfc でマスク) の TOS ビット (内側の TOS ビットをそのまま使う) をコピー. ECN ビットを 0 に. ECN 許可 内側から外側へ ECN CE 以外 内側の TOS ビットを変更して使う. (0xfe でマスク) の TOS ビット もし外側の ECN CE ビットが 1 な をコピー. ECN CE ビットを 0 に. ら, 内側の ECN CE ビットを有効に. 設定方法に関する一般的な戦略は以下のようになります: もし IPsec トンネルの両端が ECN に親和性がある動作を するのなら, その両方を "ECN 許可" と設定した方がよいでしょ う (sysctl の値を 1 に設定). もし反対側の端が TOS ビットに関して非常に厳密に動作 するなら, "RFC2401" を使ってください (sysctl の値を -1 に 設定). その他の場合, "ECN 禁止" (sysctl の値を 0 に設定). デフォルトの動作は, "ECN 禁止" (sysctl の値が 0) です. より詳しくは, 以下を参照してください: http://www.aciri.org/floyd/papers/draft-ipsec-ecn-00.txt, RFC2481 (Explicit Congestion Notification: 明示的輻輳通知), src/sys/netinet6/{ah,esp}_input.c (詳しい分析をしてくれた, 長 健二朗 氏 kjc@csl.sony.co.jp に感謝します) 相互接続性 以下に, これまでに KAME と IPsec/IKE の相互接続性試験を 行ったプラットフォーム (の一部) を挙げます. これらのプラット フォームも KAME も, 試験以降に何らかの実装の変更を行っているで しょうから, 以下のリストは参考にとどめてください. Altiga, Ashley-laurent (vpcom.com), Data Fellows (F-Secure), Ericsson ACC, FreeS/WAN, HITACHI, IBM AIX, IIJ, Intel, Microsoft WinNT, NIST (linux IPsec + plutoplus), Netscreen, OpenBSD, RedCreek, Routerware, SSH, Secure Computing, Soliton, Toshiba, VPNet, Yamaha RT100i diff --git a/ja_JP.eucJP/books/handbook/ppp-and-slip/chapter.sgml b/ja_JP.eucJP/books/handbook/ppp-and-slip/chapter.sgml index 476c8329e6..18a4c78c43 100644 --- a/ja_JP.eucJP/books/handbook/ppp-and-slip/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/ppp-and-slip/chapter.sgml @@ -1,2794 +1,2794 @@ PPP と SLIP 改訂: &a.jim;, 2000 年 3 月 1 日. この章では もしあなたがモデムを使ってインターネットに接続したり, 他の人々に FreeBSD によるインターネットへのダイヤルアップ接続を 提供しようとしているのでしたら, PPP または SLIP 接続を選択することができます. この節では 3 種類の PPP について説明しています. それは ユーザ, カーネル, そして PPPoE (PPP オーバイーサネット) です. また SLIP のクライアントとサーバの設定についても記述しています. 最初に説明するのは, ユーザ PPP です. ユーザ PPP は FreeBSD に 2.0.5-RELEASE の時に, 既に存在していたカーネル実装の PPP に加えて導入されました. ユーザ PPP とカーネル PPP の主な違いは何かと疑問に思われるかも 知れませんが, その答えは簡単です. ユーザ PPP はデーモンとしては実行されず 必要に応じて実行されるのです. PPP インタフェイスを組み込んだカーネルは 必要ではなく, ユーザプロセスとして実行されカーネルとのデータの やり取りにはトンネルデバイスドライバ (tun) を 使用します. この節ではこれ以降ユーザ PPP のことは, pppd のような他の PPP ソフトウエアと特に区別する必要がある場合を除いて, 単に ppp と記述します. またこの節に記述されているコマンドは すべて root で実行されなければなりません. ユーザ ppp の利用 原作: &a.brian;, 協力: &a.nik;, Dirk-Willem van Gulik Dirk.vanGulik@jrc.it, Peter Childs pjchilds@imforei.apana.org.au. ユーザ PPP 前提条件 以下の情報を手に入れておく必要があるでしょう: PPP で接続するインターネットサービスプロバイダ (ISP) のアカウント. さらに, 接続済みのモデム (またはその他のデバイス) があり, プロバイダとの接続が可能なように正しく設定されている. プロバイダの電話番号. ログイン名とパスワード. これは通常の unix 形式のログイン名と パスワードの組という場合もありますし, PPP PAP または CHAP の ログイン名とパスワードの組という場合もあります. 一つ以上のネームサーバの IP アドレス. 通常, プロバイダから IP アドレスを二つ指示されている はずです. 一つすら提供されていないならば, ppp.conf ファイル中で enable dns コマンドを使って ppp にネームサーバを設定するよう 指示できます. プロバイダからは以下の情報が提供されているはずですが, どうしても必要というわけではありません: プロバイダのゲートウェイの IP アドレス. ゲートウェイとは, あなたがそこに接続をおこなって, デフォルトルート として設定することになるマシンです. プロバイダがこのアドレスを明示していなくても, 最初は 適当に設定しておいて, 接続時にプロバイダの PPP サーバから 正しいアドレスを教えてもらうことができます. このアドレスは, ppp から HISADDRとして参照されます. プロバイダのネットマスク設定. プロバイダが明示していないとしても, ネットマスクとして 255.255.255.0 を使用しておけば問題ありません. もしプロバイダから固定の IP アドレスとホスト名の割り当てを 受けていれば, その情報を指定しておくこともできます. 割り当てを受けていなければ, 接続先から適切な IP アドレスを指定してもらいます. もし, 必要な情報が不足していれば, プロバイダに連絡を取って 確認しておいてください. ppp 対応カーネルの構築 説明でも述べているように, ppp はカーネルの tun デバイスを使います. 使っているカーネルがどれであっても, tun デバイスを設定しなければなりません. FreeBSDに付属しているデフォルトの GENERIC カーネルに合うように tun デバイスは前もって設定されています. しかしながら, 自分で修正したカーネルをインストールするのであれば, pppが正しく動くよう, カーネルが設定されているか確認しなくてはいけません. これを確認するには, カーネルコンパイルディレクトリ (/sys/i386/conf または /sys/pc98/conf) に移動して, カーネルコンフィグレーションファイルを調べます. 以下の行がどこかに含まれている必要があります. pseudo-device tun 1 この行がカーネルコンフィグレーションファイルに 含まれていない場合, この行を追加して カーネルの再コンパイルとインストールをおこなう必要があります. 元々の GENERIC カーネルは 標準でこれを含んでいますので, カスタムカーネルをインストールしているのではなかったり, /sys ディレクトリが存在しないのであれば, 何も変更する必要はありません. カーネルコンフィグレーションの詳細については, FreeBSD カーネルのコンフィグレーション を参照してください. 以下のコマンドを実行することで, 現在のカーネルにトンネルデバイスが いくつ組み込まれているかを調べることができます: &prompt.root; ifconfig -a tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500 inet 200.10.100.1 --> 203.10.100.24 netmask 0xffffffff tun1: flags=8050<POINTOPOINT,RUNNING,MULTICAST> mtu 576 tun2: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500 inet 203.10.100.1 --> 203.10.100.20 netmask 0xffffffff tun3: flags=8010<POINTOPOINT,MULTICAST> mtu 1500 FreeBSD 4.0やより最近のリリースでは, すでに使われている tun デバイスしか見つけることが できないでしょう. これは, 全く tun デバイスを見つけることが できないかもしれないということです. しかし, もしこうなって しまっても, 心配することはありません. そのデバイスは ppp が使おうとする時に動的に作られるはず だからです. この例ではトンネルデバイスが四つ存在し, そのうち二つに 設定がおこなわれ, 使用中であることがわかります. 上の例で RUNNING フラグがオンになっている ものがありますが, これは そのインタフェースが何かに使用されていることを示している だけであるということに注意してください. つまり, RUNNING になっていない インタフェースがあったとしても, それはエラーではありません. トンネルデバイスがカーネルに組み込まれておらず, 何らかの理由で カーネルの再構築ができない場合でも, 方法がないわけではありません. 動的にデバイスをロードすることができるはずです. 詳細については &man.modload.8; や &man.lkm.4; など, 適切なマニュアルを参照してください. tun デバイスの確認 ほとんどのユーザは tun デバイス (/dev/tun0) が一つあれば充分でしょう. より多くのデバイスを使う場合 (すなわち, カーネルコンフィグレーション ファイルで pseudo-device tun の行に 1 以外の数値を指定している場合), 以下で tun0 と書かれている部分をすべて, あなたが使うデバイスの番号に あわせて読みかえてください. tun0 デバイスが正しく作成されていることを確認する最も簡単な方法は, それを作り直すことです. そのためには, 以下のコマンドを実行します: &prompt.root; cd /dev &prompt.root; ./MAKEDEV tun0 カーネルに 16 個のトンネルデバイスを組み込んだのであれば, tun0 だけでなく他の tun デバイスも作成しておく必要があるでしょう: &prompt.root; cd /dev &prompt.root; ./MAKEDEV tun15 また, カーネルが正しく設定されているかどうかを調べるために 以下のコマンドを実行して, このような出力が得られることを確認します: &prompt.root; ifconfig tun0 tun0: flags=8050<POINTOPOINT,RUNNING,MULTICAST> mtu 1500 まだ RUNNING フラグがセットされていない場合もあります. その時は以下のような出力が得られるでしょう: &prompt.root; ifconfig tun0 tun0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500 前述したように, FreeBSD 4.0 以降のリリースでは tun デバイスは要求に応じて 作られるので, もしそのデバイスがまだ使われていなければ, 見つけられないかもしれないということを思い出してください. 名前の解決に関する設定 リゾルバ (resolver) はシステムの一部分で, IP アドレスとホスト名との 変換をおこないます. IP アドレスとホスト名を対応させるためのマップを, 二つの場所のうちの一つから探すように設定できます. 一つめは /etc/hosts (man 5 hosts) と呼ばれるファイルです. 二つめはインターネット ドメインネームサービス (DNS) と呼ばれる 分散データベースですが, これに関する議論は このドキュメントで扱う範囲を 越えていますので, これについての説明はおこないません. リゾルバは名前のマッピングを おこなうシステムコールの集合体です. ただし どこからマッピング情報を見つけるのかは, 最初に指示しておく必要があります. これは まず /etc/host.conf ファイルを編集することでおこないます. 混乱の元になりますので, このファイルを /etc/hosts.conf と 呼んだりしてはいけません (余分な s がついていますね). <filename>/etc/host.conf</filename> ファイルの編集 このファイルには 以下の 2 行が (この順番で) 書かれているはずです: hosts bind これは, 最初に /etc/hosts ファイルを調べ, そこで目的の名前が 見つけられなかった場合に DNS を引きにいくようリゾルバに指示します. /etc/hosts(5) ファイルの編集 このファイルはローカルネットワーク上に存在するマシンの IP アドレスと ホスト名を含んでいるはずです. 最低でも ppp を動作させるマシンのエントリが 含まれている必要があります. そのマシンのホスト名が foo.bar.com で, IP アドレスが 10.0.0.1 であると仮定すると, /etc/hosts は 以下の行を含んでいなければいけません: 127.0.0.1 localhost.bar.com localhost 127.0.0.1 localhost.bar.com. 10.0.0.1 foo.bar.com foo 10.0.0.1 foo.bar.com. 一つめの行は localhost を現在のマシンの別名として定義しています. マシン固有の IP アドレスが何であっても, この行の IP アドレスは 常に 127.0.0.1 でなければいけません. 二つめの行はホスト名 foo.bar.com (と, その省略形 foo) を IP アドレス 10.0.0.1 にマップします. もしプロバイダから固定の IP アドレスとホスト名を割り当てられて いるのであれば, それを 10.0.0.1 エントリのかわりに使ってください. <filename>/etc/resolv.conf</filename> ファイルの編集 /etc/resolv.conf はリゾルバの振舞いを指定します. もし自前の DNS サーバを走らせているのなら, このファイルは空のままに しておくこともできます. 通常は, 以下のように書いておく必要があるでしょう: domain bar.com nameserver x.x.x.x nameserver y.y.y.y x.x.x.x と y.y.y.y はプロバイダから指示されたアドレスで, 接続するプロバイダが提供しているネームサーバを すべて書いてください. domain に指定するのは このマシンのデフォルトのドメイン名で, おそらく 書かなくても問題は無いでしょう. このファイルの各エントリの詳細については, resolv.conf のマニュアルページを参照してください. バージョン 2 以降の ppp を使用している場合には, enable dns コマンドを使用してネームサーバのアドレスを プロバイダに問い合わせるように指示することができます. 上の指定とは異なるアドレスをプロバイダが指定してきた場合 (または /etc/resolv.conf でネームサーバが指定されていない場合), ppp はプロバイダが指定したアドレスで resolv.conf を書きかえます. <command>ppp</command> の設定 ユーザ ppp と pppd (カーネルレベルの PPP 実装) は どちらも /usr/share/examples/ppp ディレクトリに置かれた設定ファイルを使います. ここには設定ファイルのサンプルが用意されていて, ユーザ ppp の設定を おこなう際に大変参考になりますので, 削除したりしないでください. ppp の設定をするためには, 必要に応じていくつかのファイルを編集する必要が あります. 書き込む内容は, プロバイダが静的に IP アドレスを割り当てる (つまり, 固定の IP アドレスを一つ与えられて, 常にそれを使う) か, または動的に IP アドレスを割り当てる (つまり, PPP セッションごとに IP アドレスが変化する可能性がある) かということに ある程度依存します. 静的 IP アドレスによる PPP 接続 まず /etc/ppp/ppp.conf という設定ファイルを作成する必要があります. これは以下の例とほとんど同じようなものになるでしょう. : で終る行は 1 カラム目から始め, その他の行はスペースまたはタブで以下の例のように 段をつける (インデントする) 必要があります. 1 default: 2 set device /dev/cuaa0 3 set speed 115200 4 set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" ATE1Q0 OK-AT-OK \\dATDT\\TTIMEOUT 40 CONNECT" 5 provider: 6 set phone "(123) 456 7890" 7 set login "TIMEOUT 10 \"\" \"\" gin:--gin: foo word: bar col: ppp" 8 set timeout 300 9 set ifaddr x.x.x.x y.y.y.y 255.255.255.0 0.0.0.0 10 add default HISADDR 11 enable dns ファイルでは行番号を取り除いておいてください. これは解説の際に参照する行を示すためにつけたものです. Line 1: デフォルトエントリを指定します. このエントリ中のコマンドは ppp が起動された際に自動的に実行されます. Line 2: モデムが接続されているデバイスを指定します. COM1: は /dev/cuaa0 に, COM2: は /dev/cuaa1 になります. Line 3: 通信速度 (DTE 速度) を指定します. もし 115200 が使えない (最近のモデムなら大抵使えるはずですが) 場合には, かわりに 38400 を指定してみてください. Line 4: ダイアルスクリプトを指定します. ユーザ PPP は &man.chat.8; 言語に似た, 受信待ち文字列と 送信文字列の対からなるスクリプトを使用します. この言語の機能に関しては, マニュアルページを参照してください. Line 5: 接続するプロバイダの名前 provider を エントリ名として指定します. Line 6: このプロバイダの電話番号を指定します. 複数の電話番号を : や | で区切って指定することができます. これら区切り文字の違いについては, &man.ppp.8 に 詳しく書かれています. 要約すると, 毎回違う番号に かけたいのであれば : を使います. 常に まず先頭の番号にかけてみて, つながらない時にだけ 2 番目以降の番号に かけたいのであれば | を使います. 例に示されているように, 常に電話番号全体を引用符で くくって (クォートして) おきます. Line 7: ダイアルスクリプトと同様に, ログインスクリプトも chat 言語風の記述をおこないます. この例は, 以下のようなログインセッションを使用する プロバイダのためのものです: J. Random Provider login: foo password: bar protocol: ppp このスクリプトは必要に応じて 書きかえなければならないでしょう. 初めてスクリプトを書く時には, 予想した通りに 処理が進んだかどうかを確認するため, chat ログを とるようにしておいた方が良いでしょう. PAP や CHAP を使用する場合には, ここでログインすることは ありませんから, ログイン文字列は空白のままにしておくべきです. 詳細については PAP および CHAP による認証を参照してください. Line 8: デフォルトの接続タイムアウト時間を (秒数で) 指定します. この例では, 300 秒間 通信がおこなわれなければ 自動的に接続を切るように指定しています. タイムアウトさせたくない場合には, この値を 0 に設定します. Line 9: インタフェースのアドレスを指定します. 文字列 x.x.x.x は プロバイダに割り当てられた IP アドレスで置きかえてください. 文字列 y.y.y.y はプロバイダから指示されたゲートウェイ (接続先となるマシン) の IP アドレスで置きかえてください. プロバイダがゲートウェイのアドレスを 指示していない場合は, 10.0.0.2/0 を使用しておいてください. もし 仮の アドレスを使用する必要がある場合には, 動的 IP アドレスによる PPP 接続に関する指示に従って, /etc/ppp/ppp.linkup にエントリを作成していることを 確認してください. この行が省略されている場合, ppp を モードで動作させることはできません. Line 10: プロバイダのゲートウェイへの経路を デフォルトルートとして 追加します. 特殊文字列 HISADDR は, 9 行目で指定された ゲートウェイのアドレスで置きかえられます. HISADDR は 9 行目までは初期化されていませんので, その行よりも後でしか使えないことに 注意してください. Line 11: ネームサーバのアドレスが正しいか どうかを確認するため, プロバイダに問い合わせをおこなうよう ppp に指示します. プロバイダがこの機能をサポートしていれば, ppp は /etc/resolv.conf のネームサーバエントリを 正しいアドレスに更新することができます. 静的な IP アドレスを持っていて, 接続が完了する前にルーティングテーブルの エントリが正しく設定されているのであれば, ppp.linkup に エントリを追加する必要はありません. しかし, この場合でもエントリを追加して, 接続が完了した時点で プログラムを呼び出したいことがあるかもしれません. これについては後ほど sendmail を例として説明します. これらの設定ファイルのサンプルが /usr/share/examples/ppp ディレクトリに 置かれています. 動的 IP アドレスによる PPP 接続 プロバイダが静的な IP アドレスの割り当てをおこなっていない場合, ppp が相手側のホスト (ゲートウェイ) と交渉して, こちら側と相手側のアドレスを 決めるように設定することができます. これは, 起動時には仮のアドレスを使っておいて, 接続後に IP コンフィグレーション プロトコル (IPCP) を使用して ppp が IP アドレスを正しく設定できるようにすることで実現されます. 静的 IP アドレスによる PPP 接続に 以下の変更を加える以外は, ppp.conf の設定は同じです: 9 set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 繰り返しますが, 行番号は取り除いておいてください. これは解説の際に参照する行を示すためにつけたものです. なお, 少なくともスペース 1 個分の段づけ (インデント) が必要です. Line 9: / 文字の後ろの数字は, アドレス交渉の際に固定しておきたい ビットの数です. 場合によっては, もっと適切な IP アドレスを 指定しておきたいこともあるかもしれませんが, ほとんどの場合には 上の例の通りで問題ありません. 最後の引数 (0.0.0.0) は, アドレスの交渉の際に 10.0.0.1 ではなく 0.0.0.0 を使用するよう ppp に指示するためのものです. set ifaddr コマンドの最初の引数として 0.0.0.0 を指定してはいけません. さもないと, モードで動作させる際に 初期経路を設定することができなくなります. バージョン 1.X の ppp を使用する場合, /etc/ppp/ppp.linkup にもエントリを作成しておく必要があります. ppp.linkup は接続が確立された後に使用されます. この時点では, ppp は実際にどの IP アドレスを使うべきなのか わかっているはずです. 以下のエントリは存在する仮の経路を削除し, 正しい経路を作成します: 1 provider: 2 delete ALL 3 add default HISADDR Line 1: 接続を確立する際に, ppp は以下のルールに従って ppp.linkup のエントリを検索します: まず ppp.conf で使用されたのと同じラベルを探します. もし見つからなければ, ゲートウェイの IP アドレスのエントリを 探します. このエントリは 4 オクテットの IP アドレス形式の ラベルです. それでも まだエントリが見つからなければ, MYADDR エントリを探します. Line 2: この行は, 使用する tun インタフェースに関する既存の経路を (ダイレクトルートのエントリを除き) すべて削除するよう ppp に指示します. Line 3: この行は HISADDR への経路をデフォルトルートとして 追加するように ppp に指示します. HISADDR は IPCP で 決定されたゲートウェイの IP アドレスで置きかえられます. 詳細なサンプルについては, /usr/share/examples/ppp/ppp.conf.sample ファイル中のpmdemand エントリと /usr/share/examples/ppp/ppp.linkup.sample を参照してください. バージョン 2 の ppp から sticky routes が導入されました. MYADDR や HISADDR を含む add コマンドと delete コマンドを記憶して, MYADDR や HISADDR の アドレスが変化した際には経路の再設定をおこないます. したがって, これらのコマンドを ppp.linkup に 繰り返し記述する必要は無くなりました. かかってきた電話を <command>ppp</command> で受けるには かかってきた電話を ppp が受けるように設定する際に, そのマシンが LAN に接続されているのであれば, パケットを LAN に転送するかどうかを決定する必要があります. 転送をおこなう場合には, その LAN のサブネットから IP アドレスを ppp クライアントに割り当て, 以下のコマンドを指定するのが良いでしょう. gateway_enable=YES どの getty を使いますか? getty でダイアルアップサービスをおこなう場合の優れた解説が FreeBSD でダイアルアップサービスをおこなうための設定 にあります. getty に代わるものとしては, mgetty があります. これは getty をより柔軟にしたもので, ダイアルアップ回線での使用を意図して 設計されています. mgetty を使う場合の利点は, mgetty が積極的にモデムと通信する ということです. つまり, もし /etc/ttys でポートを閉じている場合, モデムは電話をとらなくなります. 最近のバージョンの mgetty (0.99beta 以降) では, PPP ストリームの 自動検出もサポートされています. これにより, クライアント側で スクリプトを準備しなくてもサーバに アクセスすることができます. mgetty に関する, より詳細な情報については Mgetty と AutoPPP を参照してください. ppp の実行許可 ppp は通常, ID 0 のユーザ (root) として動作しなければいけませんが, 以下で説明するように, ppp を通常のユーザとしてサーバモードで実行させたい 場合には, そのユーザを /etc/group の network グループに 追加して, ppp を実行する許可を与えておかなければいけません. また, そのユーザが設定ファイル内の目的のエントリに アクセスできるように, 以下のように allow コマンドで許可を与えておく必要があります: allow users fred mary このコマンドがデフォルトエントリに 書かれている場合には, 指定されたユーザは すべてのエントリをアクセスできるようになります. 動的 IP ユーザのための ppp シェルの設定 /etc/ppp/ppp-shell という名前で, 以下のような内容のファイルを 作成します: #!/bin/sh IDENT=`echo $0 | sed -e 's/^.*-\(.*\)$/\1/'` CALLEDAS="$IDENT" TTY=`tty` if [ x$IDENT = xdialup ]; then IDENT=`basename $TTY` fi echo "PPP for $CALLEDAS on $TTY" echo "Starting PPP for $IDENT" exec /usr/sbin/ppp -direct $IDENT このスクリプトには実行可能属性をつけておきます. 次に, 以下のコマンドを実行し, ppp-dialup という名前で このスクリプトへのリンクを作成します: &prompt.root; ln -s ppp-shell /etc/ppp/ppp-dialup すべてのダイアルアップ ppp ユーザのログインシェルとして このスクリプトを使用します. 以下は pchilds というユーザ名の ダイアルアップユーザを /etc/password へ登録した場合の例です. (パスワードファイルを直接エディタで編集したりせず, vipw を使ってください) pchilds:*:1011:300:Peter Childs PPP:/home/ppp:/etc/ppp/ppp-dialup 任意のユーザが読むことのできる, /home/ppp ディレクトリを 作成します. /etc/motd が表示されないようにするため, このディレクトリには以下のように大きさが 0 バイトのファイルを 作成しておきます. -r--r--r-- 1 root wheel 0 May 27 02:23 .hushlogin -r--r--r-- 1 root wheel 0 May 27 02:22 .rhosts 静的 IP ユーザのための PPP シェルの設定 上記と同じように ppp-shell ファイルを作成し, 静的な IP アドレスを割り当てるアカウントそれぞれについて ppp-shell へのシンボリックリンクを作成します. 例えば, クラス C ネットワークの経路制御を必要とする, 三人のダイアルアップユーザ fred, sam, mary がいるとすると, 以下のコマンドを実行することになります: &prompt.root; ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-fred &prompt.root; ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-sam &prompt.root; ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-mary これらのユーザのダイアルアップアカウントでは, 上で作成した それぞれのシンボリックリンクを ログインシェルとして設定しておきます. (つまり, ユーザ mary のログインシェルは /etc/ppp/ppp-mary に なります). 動的 IP ユーザのための ppp.conf の設定 /etc/ppp/ppp.conf ファイルは, 大体以下のような内容になるでしょう: default: set debug phase lcp chat set timeout 0 ttyd0: set ifaddr 203.14.100.1 203.14.100.20 255.255.255.255 enable proxy ttyd1: set ifaddr 203.14.100.1 203.14.100.21 255.255.255.255 enable proxy 上の例のように段をつける (インデントする) 必要があることに注意してください. default: エントリはセッションごとにロードされます. /etc/ttys で有効にしてある各ダイアルアップ回線ごとに一つ, 上記の ttyd0: のようなエントリを作成します. 各行の相手側アドレスとして, それぞれ別の IP アドレスを 動的 IP ユーザのための IP アドレスのプールから割り当てておく必要があります. 静的 IP ユーザのための <filename>ppp.conf</filename> の設定 上のサンプルの /usr/share/examples/ppp/ppp.conf の内容に加えて, 静的に IP を割り当てられたダイアルアップユーザ それぞれのためのエントリを追加する必要があります. ここでも fred, sam, mary の例を使うことにしましょう. fred: set ifaddr 203.14.100.1 203.14.101.1 255.255.255.255 sam: set ifaddr 203.14.100.1 203.14.102.1 255.255.255.255 mary: set ifaddr 203.14.100.1 203.14.103.1 255.255.255.255 必要であれば, それぞれの静的 IP ユーザに対する経路制御情報も /etc/ppp/ppp.linkup ファイルに書いておくべきでしょう. 以下の例ではクライアントの PPP リンクを経由する, クラス C の 203.14.101.0 ネットワークへの経路を追加しています. fred: add 203.14.101.0 netmask 255.255.255.0 HISADDR sam: add 203.14.102.0 netmask 255.255.255.0 HISADDR mary: add 203.14.103.0 netmask 255.255.255.0 HISADDR <command>mgetty</command>, AutoPPP, マイクロソフト拡張の詳細 <command>mgetty</command> と AutoPPP AUTO_PPP オプションつきでコンパイルした mgetty を使えば, mgetty が PPP 接続の LCP フェーズを検出して, 自動的に PPP シェルを起動するように 設定することができます. しかし この場合, デフォルトの login/password シーケンスは発生しないので, ユーザの認証は PAP または CHAP を使っておこなう必要があります. このセクションでは, ユーザ (あなた) が問題なく AUTO_PPP オプションつきの mgetty (v0.99beta またはそれ以降) の設定, コンパイル, インストールができているものと仮定しています. /usr/local/etc/mgetty+sendfax/login.config ファイルが 以下の行を含んでいることを確認してください: /AutoPPP/ - - /etc/ppp/ppp-pap-dialup これにより, PPP 接続を検出したら mgetty が ppp-pap-dialup スクリプトを実行するようになります. /etc/ppp/ppp-pap-dialup という名前で, 以下のような内容のファイルを 作成します (このファイルには実行可能属性を つけておく必要があります): #!/bin/sh exec /usr/sbin/ppp -direct pap さらに, かかってきた電話すべてを自分で扱うエントリを /etc/ppp/ppp.conf に作成します. pap: enable pap set ifaddr 203.14.100.1 203.14.100.20-203.14.100.40 enable proxy この方法でログインする それぞれのユーザは, PAP によるユーザ認証を おこなうために /etc/ppp/ppp.secret ファイルにユーザ名とパスワードを 書いておくか, または /etc/password ファイルを使うように, enable passwdauth ユーザに静的な IP アドレスを割り当てる場合には, そのアドレスを /etc/ppp/ppp.secret の第三引数として指定することができます. サンプルについては, /usr/share/examples/ppp/ppp.secret.sample を参照してください. マイクロソフト拡張 クライアントからの要求に応じて, ppp が DNS や NetBIOS ネームサーバの アドレスを通知するように 設定をおこなうこともできます. バージョン 1.X の ppp で これらの拡張機能を有効にするには, 以下の行を /etc/ppp/ppp.conf の適切なセクションに追加する必要があるでしょう. enable msext set ns 203.14.100.1 203.14.100.2 set nbns 203.14.100.5 バージョン 2 以降の ppp では, 以下のようになります: accept dns set dns 203.14.100.1 203.14.100.2 set nbns 203.14.100.5 これにより, クライアントはプライマリと セカンダリのネームサーバアドレス および NetBIOS ネームサーバホストを知ることができます. バージョン 2 以降の ppp では, set dns の行を省略した場合には /etc/resolv.conf に書かれているネームサーバのアドレスを使用します. PAP および CHAP による認証 いくつかのプロバイダでは, PAP または CHAP のいずれかの認証メカニズムを 使用して接続時の認証をおこなうように システムを設定しています. この場合, プロバイダは接続の際に login: プロンプトを送信せず, 最初から PPP で通信を始めようとするでしょう. PAP ではパスワードがそのまま送られてしまうため, CHAP に比べると安全性が 低くなりますが, このパスワードはシリアル回線のみを通して送られます. そのため, クラッカーが 盗み聞き する余地は多くないので, 通常ここの セキュリティは問題にはなりません. 静的 IP アドレスによる PPP 接続または 動的 IP アドレスによる PPP 接続の セクションに戻って, 以下の変更をおこないます: 7 set login … 12 set authname MyUserName 13 set authkey MyPassword これまでと同様に, 行番号は取り除いておいてください. これは解説の際に参照する行を示すためにつけたものです. なお, 少なくともスペース 1 個分の段づけ (インデント) が必要です. Line 7: PAP または CHAP を使用する場合, 通常 プロバイダはサーバへの ログインを必要としません. そのため, set login 文字列を 無効にしておかなければいけません. Line 12: この行は PAP/CHAP ユーザ名を指定します. MyUserName に 正しい値を入れておく必要があります. Line 13: この行は PAP/CHAP パスワードを指定します. MyPassword に 正しい値を入れておく必要があります. PAP と CHAP はデフォルトで両方とも 受け付けられるようになって いますが, PAP や CHAP を使用するという 意思を明示するために, 15 accept PAP または 15 accept CHAP という行を追加しておくのも良いでしょう. 動作中の ppp の設定変更 適切な診断ポートが設定されている場合には, バックグラウンドで動作中の ppp プログラムと通信することができます. この設定をおこなうためには, 以下の行を設定ファイルに追加しておきます: set server /var/run/ppp-tun%d DiagnosticPassword 0177 これにより, ppp は指定された unix ドメインの ソケットをモニタして, クライアントから正しいパスワードを受け取った後に アクセスを許可します. このソケット名に含まれる %d は, この ppp が使用している tun デバイスの デバイス番号で置きかえられます. 一旦ソケットの設定が終了したら, スクリプト中で &man.pppctl.8; を 使用して, 動作中の ppp を操作することができるでしょう. システムの最終設定 これで ppp の設定は終りました. しかし ppp を動かす前に, まだ少し必要なことがあります. それらの設定は, すべて /etc/rc.conf ファイルを 編集することでおこないます. (このファイルは以前には /etc/sysconfig と呼ばれていました) このファイルを上から順に設定していきます. まずは hostname= の行が設定されていることを確認します. 例えば以下のように: hostname="foo.bar.com" もしプロバイダが静的な IP アドレスとホスト名を割り当てているのなら, ホスト名としてそれを使うのが おそらくベストでしょう. 次に network_interfaces 変数を調べます. 必要に応じて (on demand) プロバイダにダイアルするようにシステムを設定したい場合には, tun0 デバイスがこのリストに追加されていることを確認しておきます. それ以外の場合には, tun0 デバイスをリストから削除しておきます. network_interfaces="lo0 tun0" ifconfig_tun0= ifconfig_tun0 変数が空で, /etc/start_if.tun0 という名前の ファイルが作成されていなければなりません. このファイルの内容は以下のようになります. ppp -auto mysystem このスクリプトはネットワークの設定時に実行され, ppp デーモンを自動モードで立ち上げます. このマシンがもし LAN のゲートウェイであれば, スイッチも使用したいと思うかもしれません. 詳細に関しては, マニュアルページを参照してください. 以下のようにルータプログラムを NO に設定します. router_enable="NO" routed は, ppp が作成したデフォルトのルーティングテーブル エントリを削除してしまう場合がありますので, (初期設定では起動されるようになっている) routed デーモンが 起動されないようにしておくことが重要です. sendmail_flags 行が オプションを含まないように 設定しておいた方がよいでしょう. さもないと, sendmail が アドレスを調べようとして発信をおこなってしまう場合があります. 以下のような設定で良いでしょう: sendmail_flags="-bd" この結果, PPP リンクを立ち上げた時には いつでも以下のコマンドを実行して, キューにたまっているメールを sendmail に送信させる作業が必要になるでしょう. &prompt.root; /usr/sbin/sendmail -q ppp.linkup 中で !bg コマンドを使用することで, これを自動的に おこなうこともできます: 1 provider: 2 delete ALL 3 add 0 0 HISADDR 4 !bg sendmail -bd -q30m こうするのが嫌であれば, SMTP トラフィックをブロックするように dfilter を設定しておくこともできます. 詳細についてはサンプルファイルを参照してください. 後はマシンをリブートするだけです. リブートが終ったら, &prompt.root; ppp コマンドを実行し, 続いて PPP セッションを開始させるために dial provider と入力することもできますし, (start_if.tun0 スクリプトを作成していない場合に), 外部へのトラフィックが発生した時に, ppp が自動的に セッションを確立してくれるようにしたいのであれば, 以下のコマンドを実行することもできます. &prompt.root; ppp -auto provider まとめ 要約すると, 初めて ppp を設定する際には, 以下のステップが不可欠です: クライアント側: カーネルに tun デバイスが組み込まれていることを確認. /dev ディレクトリに tunX デバイスファイルが 存在することを確認. /etc/ppp/ppp.conf にエントリを作成. ほとんどのプロバイダでは, pmdemand の例で充分でしょう. 動的 IP アドレスを使用するなら, /etc/ppp/ppp.linkup に エントリを作成. /etc/rc.conf (または sysconfig) ファイルを更新. 必要に応じてダイヤル (demand dialing) したいのであれば, start_if.tun0 スクリプトを作成. サーバ側: カーネルに tun デバイスが組み込まれていることを確認. /dev ディレクトリに tunX デバイスファイルが 存在することを確認. (&man.vipw.8; コマンドを使って) /etc/passwd にエントリを作成. このユーザのホームディレクトリに ppp -direct direct-server か何かを実行するプロファイルを作成. /etc/ppp/ppp.conf にエントリを作成. direct-server の例で充分でしょう. /etc/ppp/ppp.linkup にエントリを作成. /etc/rc.confファイルを更新. カーネル PPP の利用 原作: Gennady B. Sorokopud gena@NetVision.net.il, Robert Huff rhuff@cybercom.net. 訳: &a.jp.graphite;. 1996 年 9 月 6 日. カーネル PPP の設定 PPP の設定を始める前に, pppd が /usr/sbin にあり, また /etc/ppp という ディレクトリが存在することを確認してください. pppd はふたつのモードで動作します. クライアント モード. シリアル接続やモデムを利用して, そのマシンを 外部のネットワークに PPP 接続したい場合に用います. サーバ モード. そのマシンがネットワーク上にあるときに, PPP を使って ほかのコンピュータを接続する際に用います. どちらの場合でも, オプションファイルを設定する必要があります (/etc/ppp/options または, そのマシン上で PPP を使用する人が 複数いる場合には ~/.ppprc). また, ダイヤルとリモートホストへの接続をおこなうために, シリアル接続やモデムを 操作する, なんらかのソフトウェアが必要です (kermit が適しているでしょう). PPP クライアントとしての動作 わたしは, CISCO ターミナルサーバの PPP 回線に接続するために, 下記のような /etc/ppp/options を使用しています. crtscts # enable hardware flow control modem # modem control line noipdefault # remote PPP server must supply your IP address. # if the remote host doesn't send your IP during IPCP # negotiation , remove this option passive # wait for LCP packets domain ppp.foo.com # put your domain name here :<remote_ip> # put the IP of remote PPP host here # it will be used to route packets via PPP link # if you didn't specified the noipdefault option # change this line to <local_ip>:<remote_ip> defaultroute # put this if you want that PPP server will be your # default router 接続方法: kermit (またはその他のモデム操作プログラム) を使ってリモートホストに ダイヤルし, 接続してください. そして, あなたのユーザ名とパスワード (必要 であれば, その他にもリモートホストで PPP を有効にするための操作) を入力 します. kermit を抜けてください. (回線を切断せずに) 下記のように入力します: &prompt.root; /usr/src/usr.sbin/pppd.new/pppd /dev/tty01 19200 (通信速度とデバイス名には, あなたの環境に適したものを入れてください) これでこのコンピュータは PPP で接続されました. もし, なんらかの理由で 接続に失敗したならば, /etc/ppp/options ファイルに オプションを追加して, 問題点を突き止めるために, コンソールに表示される メッセージを調べてください. 下記の /etc/ppp/pppup スクリプトは, 上記の作業を すべて自動的におこないます: #!/bin/sh ps ax |grep pppd |grep -v grep pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing pppd, PID=' ${pid} kill ${pid} fi ps ax |grep kermit |grep -v grep pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing kermit, PID=' ${pid} kill -9 ${pid} fi ifconfig ppp0 down ifconfig ppp0 delete kermit -y /etc/ppp/kermit.dial pppd /dev/tty01 19200 /etc/ppp/kermit.dial は kermit 用のスクリプトで, ダイヤルして, リモートホストでの認証に必要なすべての処理をおこないます. (そのようなスクリプトの例は この文書の終わりに添付してあります) PPP 接続を切断するには, 下記のような /etc/ppp/pppdown スクリプトを 使用します: #!/bin/sh pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'` if [ X${pid} != "X" ] ; then echo 'killing pppd, PID=' ${pid} kill -TERM ${pid} fi ps ax |grep kermit |grep -v grep pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing kermit, PID=' ${pid} kill -9 ${pid} fi /sbin/ifconfig ppp0 down /sbin/ifconfig ppp0 delete kermit -y /etc/ppp/kermit.hup /etc/ppp/ppptest PPP が動作中かどうかを調べます (/usr/etc/ppp/ppptest): #!/bin/sh pid=`ps ax| grep pppd |grep -v grep|awk '{print $1;}'` if [ X${pid} != "X" ] ; then echo 'pppd running: PID=' ${pid-NONE} else echo 'No pppd running.' fi set -x netstat -n -I ppp0 ifconfig ppp0 モデム回線を切断します (/etc/ppp/kermit.hup): set line /dev/tty01 ; put your modem device here set speed 19200 set file type binary set file names literal set win 8 set rec pack 1024 set send pack 1024 set block 3 set term bytesize 8 set command bytesize 8 set flow none pau 1 out +++ inp 5 OK out ATH0\13 echo \13 exit 次は kermit の代わりに chat を使う方法です. 原作: Robert Huff rhuff@cybercom.net. pppd 接続を確立するためには, 次の二つのファイルの設定だけで十分です. /etc/ppp/options: /dev/cuaa1 115200 crtscts # enable hardware flow control modem # modem control line connect "/usr/bin/chat -f /etc/ppp/login.chat.script" noipdefault # remote PPP serve must supply your IP address. # if the remote host doesn't send your IP during # IPCP negotiation, remove this option passive # wait for LCP packets domain <your.domain> # put your domain name here : # put the IP of remote PPP host here # it will be used to route packets via PPP link # if you didn't specified the noipdefault option # change this line to <local_ip>:<remote_ip> defaultroute # put this if you want that PPP server will be # your default router /etc/ppp/login.chat.script: (実際には一行になります.) ABORT BUSY ABORT 'NO CARRIER' "" AT OK ATDT<phone.number> CONNECT "" TIMEOUT 10 ogin:-\\r-ogin: <login-id> TIMEOUT 5 sword: <password> 正しくインストールし編集した後は, 必要な事はこれだけです &prompt.root; pppd このサンプルは主に Trev Roydhouse <Trev.Roydhouse@f401.n711.z3.fidonet.org> から寄せられた情報に基づいており, 承諾を得て使用しています. PPP サーバとしての動作 /etc/ppp/options: crtscts # Hardware flow control netmask 255.255.255.0 # netmask ( not required ) 192.114.208.20:192.114.208.165 # ip's of local and remote hosts # local ip must be different from one # you assigned to the ethernet ( or other ) # interface on your machine. # remote IP is ip address that will be # assigned to the remote machine domain ppp.foo.com # your domain passive # wait for LCP modem # modem line 下記のような /etc/ppp/pppserv スクリプトで, そのマシンを PPP サーバにすることができます. #!/bin/sh ps ax |grep pppd |grep -v grep pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing pppd, PID=' ${pid} kill ${pid} fi ps ax |grep kermit |grep -v grep pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing kermit, PID=' ${pid} kill -9 ${pid} fi # reset ppp interface ifconfig ppp0 down ifconfig ppp0 delete # enable autoanswer mode kermit -y /etc/ppp/kermit.ans # run ppp pppd /dev/tty01 19200 PPP サーバを終了するには, この /etc/ppp/pppservdown スクリプト を使用します: #!/bin/sh ps ax |grep pppd |grep -v grep pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing pppd, PID=' ${pid} kill ${pid} fi ps ax |grep kermit |grep -v grep pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing kermit, PID=' ${pid} kill -9 ${pid} fi ifconfig ppp0 down ifconfig ppp0 delete kermit -y /etc/ppp/kermit.noans 下記の kermit スクリプトは, モデムの自動応答機能を有効, または無効にします (/etc/ppp/kermit.ans): set line /dev/tty01 set speed 19200 set file type binary set file names literal set win 8 set rec pack 1024 set send pack 1024 set block 3 set term bytesize 8 set command bytesize 8 set flow none pau 1 out +++ inp 5 OK out ATH0\13 inp 5 OK echo \13 out ATS0=1\13 ; change this to out ATS0=0\13 if you want to disable ; autoanswer mod inp 5 OK echo \13 exit この /etc/ppp/kermit.dial スクリプトは, リモートホストに ダイヤルし, 認証手続きをするのに使用します. あなたは必要に応じて, これを 変更しないといけないでしょう. あなたのユーザ名とパスワードをこの スクリプトに書かなければいけませんし, モデムやリモートホストからの 応答によっては, 入力待ちの文を変更する必要もあります. ; ; put the com line attached to the modem here: ; set line /dev/tty01 ; ; put the modem speed here: ; set speed 19200 set file type binary ; full 8 bit file xfer set file names literal set win 8 set rec pack 1024 set send pack 1024 set block 3 set term bytesize 8 set command bytesize 8 set flow none set modem hayes set dial hangup off set carrier auto ; Then SET CARRIER if necessary, set dial display on ; Then SET DIAL if necessary, set input echo on set input timeout proceed set input case ignore def \%x 0 ; login prompt counter goto slhup :slcmd ; put the modem in command mode echo Put the modem in command mode. clear ; Clear unread characters from input buffer pause 1 output +++ ; hayes escape sequence input 1 OK\13\10 ; wait for OK if success goto slhup output \13 pause 1 output at\13 input 1 OK\13\10 if fail goto slcmd ; if modem doesn't answer OK, try again :slhup ; hang up the phone clear ; Clear unread characters from input buffer pause 1 echo Hanging up the phone. output ath0\13 ; hayes command for on hook input 2 OK\13\10 if fail goto slcmd ; if no OK answer, put modem in command mode :sldial ; dial the number pause 1 echo Dialing. output atdt9,550311\13\10 ; put phone number here assign \%x 0 ; zero the time counter :look clear ; Clear unread characters from input buffer increment \%x ; Count the seconds input 1 {CONNECT } if success goto sllogin reinput 1 {NO CARRIER\13\10} if success goto sldial reinput 1 {NO DIALTONE\13\10} if success goto slnodial reinput 1 {\255} if success goto slhup reinput 1 {\127} if success goto slhup if < \%x 60 goto look else goto slhup :sllogin ; login assign \%x 0 ; zero the time counter pause 1 echo Looking for login prompt. :slloop increment \%x ; Count the seconds clear ; Clear unread characters from input buffer output \13 ; ; put your expected login prompt here: ; input 1 {Username: } if success goto sluid reinput 1 {\255} if success goto slhup reinput 1 {\127} if success goto slhup if < \%x 10 goto slloop ; try 10 times to get a login prompt else goto slhup ; hang up and start again if 10 failures :sluid ; ; put your userid here: ; output ppp-login\13 input 1 {Password: } ; ; put your password here: ; output ppp-password\13 input 1 {Entering SLIP mode.} echo quit :slnodial echo \7No dialtone. Check the telephone line!\7 exit 1 ; local variables: ; mode: csh ; comment-start: "; " ; comment-start-skip: "; " ; end: PPP オーバイーサネット (PPPoE) の利用 原作: &a.jim; ( node.to より) 10 Jan 2000. 以下の解説は, PPPoE として知られる, PPP オーバイーサネットの設定法です. 必要なもの あなたのシステムで PPPoE を適切に機能させるためには, 以下のものが必要です. FreeBSD 3.4やそれより新しいバージョンのカーネルソース FreeBSD 3.4やそれより新しいバージョンのppp カーネルコンフィギュレーション 以下に示すオプションをカーネルコンフィギュレーションファイルに 追加して, その後 新しいカーネルを コンパイルする必要があります. options NETGRAPH 以下は任意 options NETGRAPH_PPPOE options NETGRAPH_SOCKET この機能は実行時には有効ではありませんが, 要求に応じて ppp は関係のあるモジュールを 読み込みます. <filename>ppp.conf</filename> の設定 これは動作している ppp.conf の 例です: default: # or name_of_service_provider set device PPPoE:xl1 # replace xl1 with your ethernet device set mru 1492 set mtu 1492 set authname YOURLOGINNAME set authkey YOURPASSWORD set log Phase tun command # you can add more detailed logging if you wish set dial set login set ifaddr 10.0.0.1/0 10.0.0.2/0 add default HISADDR nat enable yes # if you want to enable nat for your local net papchap: set authname YOURLOGINNAME set authkey YOURPASSWORD オプションを付けてPPPoE を起動する際には注意するべきです. <application>PPP</application> の起動 以下を root 権限において実行することで, 起動させることができます: &prompt.root; ppp -ddial name_of_service_provider システム起動時に <application>PPP</application> を立ち上げる /etc/rc.conf ファイルに以下の行を追加 してください: ppp_enable="YES" ppp_mode="ddial" ppp_nat="YES" ppp_profile="default" # or your provider SLIP の利用 原作: &a.asami;,&a.ghelmer;, 協力: &a.wilko;, &a.piero;. 訳: &a.hanai; 1996 年 8 月 8 日. SLIPクライアントのセットアップ ここには FreeBSD マシンを静的アドレスのネットワークにつなげる場合の SLIPのセットアップの一つの方法を書いてあります. ホスト名を動的に割り当てる(つまり, ダイヤルアップするたびにアドレスが かわる)ためには, おそらくもっと凝ったことが必要です. まず, モデムがどのシリアルポートにつながっているか決めましょう. 私は /dev/cuaa1 から /dev/modemへというシンボリックリンクを張り, コンフィグレーションではその名前だけを使っています. /etc や.kermrc など, システム全体に散らばっているファイルを修正する 必要がでるとまったく煩わしいのです! ここで, /dev/cuaa0は COM1であり, cuaa1はCOM2です. カーネルのコンフィグレーションファイルに pseudo-device sl 1 という記述があるのを確認してください. これは GENERIC カーネルに含まれている ので削除していない限り大丈夫でしょう. 最初の設定 /etc/hosts ファイルにあなたのマシンのゲートウェイとネームサーバ を加えてください. 私のは以下のようになっています. 127.0.0.1 localhost loghost 136.152.64.181 silvia.HIP.Berkeley.EDU silvia.HIP silvia 136.152.64.1 inr-3.Berkeley.EDU inr-3 slip-gateway 128.32.136.9 ns1.Berkeley.edu ns1 128.32.136.12 ns2.Berkeley.edu ns2 /etc/host.conf ファイル中で が よりも前にあること を確認してください. さもないとヘンなことが起こるかもしれません. /etc/rc.conf ファイルを編集してください. なお, お使いの FreeBSD が 2.2.2 よりも前のバージョンのものの場合は, /etc/sysconfig を編集してください. 行 hostname=myname.my.domain を編集してホスト名をセットしてください. 完全なInternetホスト名を与えるべきです. 行 network_interfaces="lo0" を network_interfaces="lo0 sl0" へ変更することにより ネットワークインタフェースのリストに sl0 を加えてください. 行 ifconfig_sl0="inet ${hostname} slip-gateway netmask 0xffffff00 up" を加えて sl0 のスタートアップフラグをセットしてください. 行 defaultrouter=NO を defaultrouter=slip-gateway へ変更してデフォルトのルータを 指定してください. 次の domain HIP.Berkeley.EDU nameserver 128.32.136.9 nameserver 128.32.136.12 という内容を含むファイル /etc/resolv.conf を作ってください. 見ればわかるように, これらはネームサーバホストを設定しています. もちろん, 実際のドメイン名やアドレスは あなたの環境に依存します. root と toor (及びパスワードを持っていない他のアカウントすべて) のパスワード を設定してください. passwdコマンドを使いましょう. /etc/passwd や /etc/master.passwd といったファイルを編集してはいけません! マシンを再起動して正しいホスト名で 立ち上がることを確認してください. SLIP接続をおこなう モデムを起動, つながったらプロンプトで slipとタイプし, マシン名と パスワードを入力してください. 入力する必要があるものは環境に よって異なります. 私は次のようなスクリプトでkermitを使っています. # kermit setup set modem hayes set line /dev/modem set speed 115200 set parity none set flow rts/cts set terminal bytesize 8 set file type binary # The next macro will dial up and login define slip dial 643-9600, input 10 =>, if failure stop, - output slip\x0d, input 10 Username:, if failure stop, - output silvia\x0d, input 10 Password:, if failure stop, - output ***\x0d, echo \x0aCONNECTED\x0a (もちろん, ホスト名とパスワードは変える必要があります). 接続するためには kermit のプロンプトで slipとタイプするだけです. ファイルシステムのどんなところにもプレインテキスト にパスワードを書いておくのは一般的にはよくありません. 覚悟の上で やってください. 私は単に不精なだけです. ここでkermitから抜け出し (zでkermitをサスペンドできます), root で &prompt.root; slattach -h -c -s 115200 /dev/modem と入力しましょう. もしルータの向う側のホストへ ping できるなら接続成功です! もしうまく いかなければslattachへの引数として の代わりにとやってみてください. 接続の切り方 slattachを殺すためにrootで &prompt.root; kill -INT `cat /var/run/slattach.modem.pid` とタイプしてください. そして kermit に戻り (もしkermitをサスペンドしていたなら fg), kermitから抜けてください (q). slattachのマニュアルページにはインタフェースを落すために ifconfig sl0 downをしなければいけないと書いていますが, 私には差がないように見えます. (ifconfig sl0とやっても同じ結果が得られる.) 時にはモデムがキャリアを落すのを 拒絶するかもしれません(私のは よくそうなります). その時は単にkermitをスタートしてまた終了 してください. 普通は2回目で落ちます. トラブルシューティング もし動かなければ自由に私に質問してください. 今までいろんな人がつまずいた のは次のようなことです. slattach で や を使わなかった(私はなぜこれが致命的になり得るのか わかりませんが, このフラグを付けることで少なくとも一人の 問題は解決しました.) の代わりに を使った(いくつかのフォントでは見分けるのは難しい かもしれません). インタフェースの状態を見るために ifconfig sl0 をやってみてください. 私は, &prompt.root; ifconfig sl0 sl0: flags=10<POINTOPOINT> inet 136.152.64.181 --> 136.152.64.1 netmask ffffff00 となります. また, pingが no route to host というメッセージを返す時には netstat -rでルーティングテーブルを確認しましょう. 私のは, &prompt.root; netstat -r Routing tables Destination Gateway Flags Refs Use IfaceMTU Rtt Netmasks: (root node) (root node) Route Tree for Protocol Family inet: (root node) => default inr-3.Berkeley.EDU UG 8 224515 sl0 - - localhost.Berkel localhost.Berkeley UH 5 42127 lo0 - 0.438 inr-3.Berkeley.E silvia.HIP.Berkele UH 1 0 sl0 - - silvia.HIP.Berke localhost.Berkeley UGH 34 47641234 lo0 - 0.438 (root node) となります. (これはたくさんのファイルを転送した後でのもので, あなたの見る数字はもっと小さいかも しれません). SLIPサーバのセットアップ方法 訳: &a.jp.ts;. 1996 年 9 月 6 日. この文書の目的は, SLIPサーバ機能を FreeBSDシステムのもとで設定するため の助言を提供することです. SLIPサーバ機能を設定するということは, リモー トの SLIPクライアントがログインできるようにするために, 自動的に接続処 理をおこなうようにすることです. この文書は著者の経験に基づいておりますが, 実際のシステム構成や要望は異なりますから, すべての疑問にこの文書が答え ることはできません. なお, ここでの助言を試みた結果, あなたのシステムへ の悪影響やデータの損失が生じたとしても, 著者が責任を持つことはできませ んのでご了解をお願いします. 前提 この文書の内容はテクニカルなものなので, 前提知識が必要です. すなわち, TCP/IPネットワークプロトコルについての知識, 特に, ネットワークとノード のアドレス指定をはじめ, ネットワークアドレスマスク, サブネット化, ルー ティング, および RIPなどのルーティングプロトコルなどに関する知識を前提 としています. ダイヤルアップサーバで SLIP機能を設定するためには, これ らの概念についての知識が必要ですから, もし不案内であると思われる方は, O'Reilly & Associates, Inc.から出版されている Craig Hunt氏の TCP/IP Network Administration (ISBN 0-937175-82-X)か, または Douglas Comer氏の TCP/IPプロトコルに関する一連の書籍をお読みください. 前提知識に加え, さらに, モデムの設定が完了しており, そのモデムを経由し てログインできるように, システムファイル群が適切に記述できているものと 仮定しています. もしモデムの準備ができていないときには, あらかじめダイヤ ルアップ機能の設定についてのチュートリアルをお読みください. Webブラ ウザが使えるのであれば http://www.FreeBSD.org/ におけるチュー トリアルの一覧を調べてください. あるいは, この文書を見つけた場所を調べ て, dialup.txt やそれに類似した名前の文書をお読みください. 関連す るマニュアルページとしては, シリアルポート向けデバイスドライバについて の &man.sio.4; をはじめ, モデムからのログインを 受理できるようにシステ ムを設定するための &man.ttys.5;, &man.gettytab.5;, &man.getty.8;, &man.init.8; など, さらには, シリアルポート関連パラメータ ( たと えば直接接続シリアルインタフェースの clocal ) についての &man.stty.1; なども助けになるかもしれません. 概要 一般的な設定内容で FreeBSDを SLIPサーバとして利用すると, その動作は次 のようになります. まず, SLIPユーザが FreeBSD による SLIPサーバへ電話し て, SLIP専用IDでログインします. なお, このIDを持ったユーザはシェルとし て /usr/sbin/sliplogin を使います. この sliplogin は, ファイル /etc/sliphome/slip.hosts の中から, ログインIDと一致する 記述行を探します. もし一致する行があれば, ログインしたシリアル回線を, 利用可能な SLIPインタフェースへ接続し, その後にシェルスクリプト /etc/sliphome/slip.login で SLIPインタフェースを設定します. SLIPサーバへのログイン例 仮に SLIPユーザIDが Shelmerg とします. すると, /etc/master.passwd における Shelmerg のエントリは次のよ うなものになります (実際には一つの行に続いている) . Shelmerg:password:1964:89::0:0:Guy Helmer - SLIP:/usr/users/Shelmerg:/usr/sbin/sliplogin Shelmerg がログインすると, sliplogin は, ファイル /etc/sliphome/slip.hosts からユーザIDと一致する行を探しま す. いま仮に, /etc/sliphome/slip.hosts に次のような記述がなされていたとします. Shelmerg dc-slip sl-helmer 0xfffffc00 autocomp sliplogin が上記のエントリを見つけると, Shelmerg が使用して いるシリアル回線を, 利用可能な SLIPインタフェースのなかの最初のものへ 接続し, 次の内容の /etc/sliphome/slip.login を実行します. /etc/sliphome/slip.login 0 19200 Shelmerg dc-slip sl-helmer 0xfffffc00 autocomp もし上記の手順が正常に処理されると, /etc/sliphome/slip.login は, sliplogin が割り当てた SLIPインタフェース (この例では slip.login で与えられたパラメータのうちで最初の値である SLIP インタフェース0である) に対して ifconfig を実行し, ローカル IPアドレス (dc-slip)をはじめ, リモート IPアドレス (sl-helmer), SLIPインタフェースへのネットワークマスク (0xfffffc00), およびその他のフラグ (autocomp)を設定 します. 逆に, さきほどの手順が正常に終了しなかった場合, 通常は sliplogin は十分な情報を syslog の daemon 機能経由で /var/log/messages へ記録します ( &man.syslogd.8; や &man.syslog.conf.5; のマニュアルページを参照のうえ, さらに /etc/syslog.conf を調べて syslogd がどのファイルへ記 録するかを確認のこと) . 例はこのくらいにして, さっそくシステムのセットアップを始めてみましょう. カーネルのコンフィグレーション FreeBSD のデフォルトのカーネルには, 通常, 二つの SLIPインタフェースが 準備されています (sl0 と sl1) . これらのインタフェー スが使用中のカーネルに準備されているかどうかを調べるには, netstat -i を実行してください. netstat -i の出力例 Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll ed0 1500 <Link>0.0.c0.2c.5f.4a 291311 0 174209 0 133 ed0 1500 138.247.224 ivory 291311 0 174209 0 133 lo0 65535 <Link> 79 0 79 0 0 lo0 65535 loop localhost 79 0 79 0 0 sl0* 296 <Link> 0 0 0 0 0 sl1* 296 <Link> 0 0 0 0 0 netstat -i の出力に sl0 と sl1 のインタフェー スが含まれているということから, カーネルには二つの SLIPインタフェー スが組み込まれているということを示しています. (sl0 と sl1 に付いたアスタリスクは, netstat -i の実行時点で はインタフェースが ダウン していることを表しています. ) なお, パケットのフォワード機能は FreeBSD のデフォルトのカーネルでは設定 されていません (すなわちルータとしては動作しない) . もしインターネット 接続ホストについての RFC要件 ( RFC 1009 [Requirements for Internet Gateways] と 1122 [Requirements for Internet Hosts — Communication Layers], おそらく 1127 [A Perspective on the Host Requirements RFCs] も ) に準拠して, FreeBSDによる SLIPサー バをルータとして動作させたいときには, /etc/rc.conf (バージョ ン 2.2.2 より前の FreeBSD では /etc/sysconfig) ファイル の gateway_enable 変数を としてください. もし古いシステ ムで /etc/sysconfig ファイルすらないときには, 次のコマン ドを /etc/rc.local へ追加してください. sysctl -w net.inet.ip.forwarding = 1 この新しい設定を有効とするには, リブートする必要があります. デフォルトのカーネルコンフィグレーションファイル (/sys/i386/conf/GENERIC) の最後の部分に, 次のような行がありま す. pseudo-device sl 2 この行によって, 使用可能な SLIPデバイスの総数が決まります. すなわち, 行 末の数値が, 同時に動作可能な SLIP接続の最大数となります. カーネルの再構築については, FreeBSDカー ネルのコンフィグレーション を参照ください. Sliploginのコンフィグレーション すでにご説明したように, /usr/sbin/sliplogin のコンフィグレー ションのために, 3種類のファイルが/etc/sliphome ディレクトリに あります (sliplogin についての実際のマニュアルページとしては &man.sliplogin.8; を参照のこと) . ファイル slip.hosts は SLIPユーザおよびその IPアドレスを決めます. 通常, ファイル slip.login は, SLIPインタフェースを設定することだけに使 用します. slip.logout はオプションのファイルで, slip.login で設定した内容を, シリアル接続が終了した時点で解除 するときに使用します. <filename>slip.hosts</filename> のコンフィグレーション /etc/sliphome/slip.hosts には, 少なくとも 4 つの項目をホワイ トスペース (スペースやタブ) で区切って指定します. SLIPユーザのログインID SLIPリンクのローカル (SLIPサーバ側) アドレス SLIPリンクのリモートアドレス ネットワークマスク ホスト名をローカルおよびリモートのアドレスとして 記述できます (IPアドレ スの決定は, /etc/host.conf の指定内容に応じて, /etc/hosts か DNSのいずれかによって決定される) . また, ネット ワークマスクも /etc/networks ファイルに記述された名前を参照す ることで, 指定することもできると思います. これまでの例としてあげたシス テムでの /etc/sliphome/slip.hosts は次のようになります. # # login local-addr remote-addr mask opt1 opt2 # (normal,compress,noicmp) # Shelmerg dc-slip sl-helmerg 0xfffffc00 autocomp それぞれの行の最後には, 次に示すオプションを一つ以上指定できます. — ヘッダを圧縮しない — ヘッダを圧縮する — リモートの設定に応じて, ヘッダを圧縮する — ICMPパケットを禁止する ( ping パケットは送出されず, バンド幅を占有しない) なお, FreeBSDバージョン2の初期リリースの sliplogin は, 旧 FreeBSD 1.xでは有効であった上記のオプションを無視していましたので, , , , そして などのオプションは FreeBSD 2.2でサポートされるまでは効果がありませんでした (た だしこれらのフラグを使うためには slip.login スクリプトへ記述する 必要がある) . SLIPリンクでのローカルとリモート向けのアドレスの 選び方は, TCP/IPサブネッ トを専用に割り当てるか, または プロキシ ARP を SLIPサーバへ用いるかによって違います ( プロキシ ARP という用語のここでの使い方は本来のものではないが, 説明のためにこの用語を使う) . もし, どちらの方式を選ぶべきか判らなかったり, IPアドレスの割り当て方が不明のときには, 上述の 前提 の節で紹介した TCP/IP関連書籍を参考になさるか, またはあなたの IPネットワークを管理している方に相談なさると よいでしょう. 独立したサブネットを SLIPクライアントへ適用するときには, すでに割り当てられている IPネットワーク番号の範囲からサブネット番号を割り当て, 同 時にそのサブネットの範囲内で有効な IPアドレスを SLIPクライアントの IP 番号として割り当てる必要があります. さらに, この SLIPサブネットから SLIPサーバを経由して最も近い IPルータへの経路を静的に設定するか, または gated を FreeBSDによる SLIPサーバへインストールして, 適当 なルーティングプロトコルを使って, SLIPサーバ経由のサブネットへの経路情 報をルータ群へ通知できるように設定するか, のいずれかをおこなう必要があります. プロキシ ARP 方式を採用するときには, SLIPクライアント向けの IPアドレス として, SLIPサーバのサブネットの範囲から 選んで割り当てるとともに, &man.arp.8; コマンドを使うために /etc/sliphome/slip.login と/etc/sliphome/slip.logout のスクリプトを修正して, SLIPサー バにおける ARPテーブル内のプロキシ ARPエントリへ 反映させる必要がありま す. <filename>slip.login</filename> のコンフィグレーション ファイル /etc/sliphome/slip.login の一般的な内容は次にようになります. #!/bin/sh - # # @(#)slip.login 5.1 (Berkeley) 7/1/90 # # generic login file for a slip line. sliplogin invokes this with # the parameters: # 1 2 3 4 5 6 7-n # slipunit ttyspeed loginname local-addr remote-addr mask opt-args # /sbin/ifconfig sl$1 inet $4 $5 netmask $6 この slip.login ファイルの役目は単に, SLIPインタフェースにつ いてのローカルとリモートのアドレス, およびそのネットワークマスクを ifconfig コマンドで設定することです. もし プロキシ ARP 方式を採用する (SLIPクライアントへ独立したサブネットを使わない) ときには, ファイル /etc/sliphome/slip.login は次のような内容になります. #!/bin/sh - # # @(#)slip.login 5.1 (Berkeley) 7/1/90 # # generic login file for a slip line. sliplogin invokes this with # the parameters: # 1 2 3 4 5 6 7-n # slipunit ttyspeed loginname local-addr remote-addr mask opt-args # /sbin/ifconfig sl$1 inet $4 $5 netmask $6 # Answer ARP requests for the SLIP client with our Ethernet addr /usr/sbin/arp -s $5 00:11:22:33:44:55 pub この slip.login で追加された行 arp -s $5 00:11:22:33:44:55 pub は, SLIPサーバにおける ARPテーブルへ新たなエントリを作ります. SLIPサーバ は, この ARPエントリが作られると, SLIPクライアントの IPアドレスと話し たい他の IPノードが要求してきたときにはいつも, SLIPサーバ の Ethernet MACアドレスを返すようになります. 上記の例を実際に流用なさるときには, 例にある Ethernet MACアドレス (00:11:22:33:44:55) を, あなたのシステムの実際のEthernetカー ドの MACアドレスと置き換えなければ プロキシ ARP はうまく動作しません! SLIPサーバの Ethernet MACアドレスを調べるには netstat -i コマ ンドを利用してください. 実行結果の第2行は次のようなものになるはずです. ed0 1500 <Link>0.2.c1.28.5f.4a 191923 0 129457 0 116 この例での Ethernet MACアドレスは 00:02:c1:28:5f:4a であると 読みます. なお &man.arp.8; における MAC アドレスの指定に際しては, コマンド netstat -i が付けた Ethernet MACアドレスのピリオド記 号をコロン記号と置き換え, かつ単一桁の 16 進数にはゼロを先頭に加える必 要があります. この指定についての正確な情報は &man.arp.8; を参照く ださい. /etc/sliphome/slip.login と /etc/sliphome/slip.logout を作成したならば, ファイル属性の 実行 ビット (すなわち chmod 755 /etc/sliphome/slip.login /etc/sliphome/slip.logout) を 設定しなければなりません. さもなければ sliplogin が うまく実行されません. <filename>slip.logout</filename> のコンフィグレーション ファイル /etc/sliphome/slip.logout は必ずしも必要なものではあ りません (ただし プロキシ ARP を利用する場合を除く) . もしこのファイルを 作成するときには, 次に示す標準的な slip.logout スクリプト例を 参考にしてください. #!/bin/sh - # # slip.logout # # logout file for a slip line. sliplogin invokes this with # the parameters: # 1 2 3 4 5 6 7-n # slipunit ttyspeed loginname local-addr remote-addr mask opt-args # /sbin/ifconfig sl$1 down プロキシ ARP を利用する場合, この /etc/sliphome/slip.logout を 使って, 特定の SLIPクライアント向けの ARPエントリを削除したくなるようなときがあります. #!/bin/sh - # # @(#)slip.logout # # logout file for a slip line. sliplogin invokes this with # the parameters: # 1 2 3 4 5 6 7-n # slipunit ttyspeed loginname local-addr remote-addr mask opt-args # /sbin/ifconfig sl$1 down # Quit answering ARP requests for the SLIP client /usr/sbin/arp -d $5 コマンド arp -d $5 は, SLIPクライアントがログインした 際に, プロキシ ARP を使った slip.login によって追加され た ARPエントリを削除します. これによって, 繰り返して利用することができるわけです. 必ず, /etc/sliphome/slip.logout を作成した後に, 実行ビットを設定し てください ( chmod 755 /etc/sliphome/slip.logout ) . ルーティングについての考慮点 プロキシ ARP 方式を利用せずに SLIPクライアントとその他のネットワーク (Internetも含む) の構成要素との間でパケットをルーティングするときには, SLIPサーバ経由で SLIPクライアントが属するサブネットまでの経路を, 最も 近いデフォルトのルータ群へ静的な経路情報として 追加しなければならないか, または gated を FreeBSDによる SLIPサーバへインストールして, SLIP サブネットについての経路情報を, 適当なルーティングプロトコルでルー タ群へ通知できるように設定するか, のどちらかをおこなわなければなりません. 静的な経路 静的な経路を最も近いデフォルトの ルータ群へ追加することが困難なことがあ ります (経路情報を追加できる権限がなければそもそも不可能となる). もし あなたの組織に複数のルータで構成された ネットワークがあるならば, ある種 のルータ (たとえば Ciscoや Proteonなど) は, 静的な経路を SLIPサブネッ トへ使うようにルータを設定しなければならないだけでなく, その静的経路を 他のどのルータへ知らせるのかもあらかじめ 指定しておく必要がありますから, 静的経路に基づくルーティングを軌道に乗せるには それなりの専門的技術やト ラブルシューティングやコツが必要だと思います. <command>gated</command>の稼働 静的経路についての頭痛への代替手段は, gated を FreeBSDによる SLIPサー バへインストールして, 適切なルーティングプロトコル (RIP/OSPF/BGP/EGP) を使って SLIPサブネットについての経路情報を他のルータへ知らせるように 設定することです. ports コレクションから gated を用いることもできますし, - the GateD 匿名 FTP サイト + GateD 匿名 FTP サイト から探して自分自身で構築することもで きます. この文章を執筆時点の最新バージョンは gated-R3_5Alpha_8.tar.Z であり, このファイル だけで FreeBSDで 動作させることができます. gated についてのすべての情報と文書 は Merit GateD コンソーシアム からはじまる Web 上で入手でき ます. gated のコンパイルとインストールを行ったならば, 独自の 設定のために /etc/gated.conf ファイルを記述してください. 次の 例は, 筆者が FreeBSDによる SLIP サーバで使っている内容と類似のものです. # # gated configuration file for dc.dsu.edu; for gated version 3.5alpha5 # Only broadcast RIP information for xxx.xxx.yy out the ed Ethernet interface # # # tracing options # traceoptions "/var/tmp/gated.output" replace size 100k files 2 general ; rip yes { interface sl noripout noripin ; interface ed ripin ripout version 1 ; traceoptions route ; } ; # # Turn on a bunch of tracing info for the interface to the kernel: kernel { traceoptions remnants request routes info interface ; } ; # # Propagate the route to xxx.xxx.yy out the Ethernet interface via RIP # export proto rip interface ed { proto direct { xxx.xxx.yy mask 255.255.252.0 metric 1; # SLIP connections } ; } ; # # Accept routes from RIP via ed Ethernet interfaces import proto rip interface ed { all ; } ; この gated.conf ファイルの例では, SLIPのサブネット xxx.xxx.yy についての経路情報を RIPを使って Ethernetへブロー ドキャストしています. もし ed ドライバ以外の Ethernetドライバを使うのであれば, ed インタフェースの記述を適切なものに置き換えてくだ さい. またこの例では, gatedの動作をデバッグするために, /var/tmp/gated.output へトレース情報を出力するように指示して います. gated が希望通りに動作したならば, このトレースオプショ ンを止めることができます. なお, 例における xxx.xxx.yy を, あ なた自身の SLIPサブネットのネットワークアドレスに換えてください (また proto direct 部分のネットワークマスクも換えることを忘れないこ と) . gated のコンパイルとインストールが終了し, コンフィグレーショ ンファイルの作成も完了したら, FreeBSDシステムではデフォルトの routedに代わって gated を起動してください. そのため には, /etc/netstart の routed/gated 起動パラメータを 適切な値に設定してください. gated のコマンドラインパラメータにつ いての情報は, gated のマニュアルページを参照してください.