diff --git a/ja_JP.eucJP/books/faq/book.sgml b/ja_JP.eucJP/books/faq/book.sgml index 3659ec2927..1a5c44c2df 100644 --- a/ja_JP.eucJP/books/faq/book.sgml +++ b/ja_JP.eucJP/books/faq/book.sgml @@ -1,14475 +1,14475 @@ %man; %freebsd; %ja-authors; %authors; %teams; %bookinfo; %mailing-lists; %newsgroups; ]> FreeBSD 2.X, 3.X, 4.X についての FAQ (よくある質問とその答え) FreeBSD ドキュメンテーションプロジェクト $FreeBSD$ この文書は FreeBSD システム・バージョン 2.X, 3.X, 4.X についての FAQ です. 特に断わりがない限り, どの項目も FreeBSD 2.0.5 以降のものを想定しています. <XXX> のついている項目はまだ作業中のものです. この FreeBSD ドキュメンテーションプロジェクトに協力したいと思われる方は, &a.doc; まで(英語で)電子メールを送ってください. この文書の最新バージョンは, いつでも 日本国内版 FreeBSD World Wide Web サーバや FreeBSD World Wide Web サーバで 見ることができます. また, ひとつの巨大な HTML ファイルとして HTTP でダウンロードすることもできます. プレーンテキスト, PostScript, PDF, およびその他の形式のものは FreeBSD FTP サーバに置かれています. また, FAQ の検索も可能です. 2000 年 3 月現在, HTML 版以外の日本語 FAQ は用意されていません. 日本語版の作成は FreeBSD 日本語ドキュメンテーションプロジェクトが オリジナルの英語版をもとにして行なっています. FreeBSD FAQ 日本語訳および, FreeBSD FAQ 日本語版のみに関連することは, &a.jp.doc-jp; において日本語で議論されています. 必要に応じて日本語ドキュメンテーションプロジェクトから, FreeBSD Documentation Project に対してフィードバックを行ないますので, 英語が得意でない方は &a.jp.doc-jp; まで日本語でコメントをお寄せください. また, この FreeBSD FAQ とは別に, 日本の FreeBSD ユーザ有志によって メーリングリスト &a.jp.users-jp; やニュースグループ fj.os.bsd.freebsd などへの投稿をもとに作成された QandA が公開されています. 特に日本語環境など日本固有の話題が充実していますので, こちらも合わせてご覧ください. まえがき 訳: &a.kuriyama;, &a.hanai; &a.jp.nakai;, &a.motoyuki;, &a.jp.sugimura;, 1997 年 11 月 5 日. FreeBSD 2.X-4.X FAQ へようこそ! Usenet の FAQ がそうであるように, この文書も FreeBSD オペレーティングシステムに関して 頻繁に尋ねられる質問を網羅することを目的としています(もちろんそれに対する答えも!). FAQ は本来バンド幅を減らし, 同じ質問が何度も繰り返されるのを避けるために作られたものですが, 最近は有用な情報源と見なされるようになってきました. この FAQ をできる限り有用なものにしようと, あらゆる努力がはらわれています. もし何かしらの改善案が浮かんだら, ぜひ &a.faq; までメールを送ってください. FreeBSD って何? FreeBSD とは一言で言えば, カリフォルニア大学バークレイ校から リリースされた 4.4BSD-Lite と 4.4BSD-Lite2 による 強化の一部に由来する, i386 および Alpha/AXP 系のプラットフォーム向けの UN*X ライクなオペレーティングシステムです. 間接的には同じバークレイ校の Net/2 を William Jolitz が i386 系に移植した 386BSD も基にしていますが, 386BSD のコードはほとんど残っていません. FreeBSD についての詳細と, 何ができるかについては FreeBSD のホームページ を参照してください. FreeBSD は企業やインターネットサービスプロバイダ, 研究者, コンピュータ専門家, 学生, 家庭のユーザなどにより, 業務や教育, 娯楽に用いられています. これらに関しては FreeBSD ギャラリーをご覧ください. FreeBSD に関するより詳しい情報は FreeBSD ハンドブックを参照してください. FreeBSD が目指しているもの FreeBSD プロジェクトの目的は, いかなる用途にも使用でき, 何ら制限のないソフトウェアを供給することです. 私たちの多くは, コード(そしてプロジェクト)に対してかなりの投資をしてきており, これからも多少の代償はあっても投資を続けて行くつもりです. ただ, 他の人達にも同じような負担をするように主張しているわけではありません. FreeBSD に興味を持っている一人残らず全ての人々に, 目的を限定しないでコードを提供すること. これが, 私たちの最初のそして最大の「任務」であると信じています. そうすれば, コードは可能な限り広く使われ, 最大の恩恵をもたらすことができるでしょう. これが, 私たちが熱烈に支持しているフリーソフトウェアの最も基本的な目的であると, 私は信じています. 私たちのソースツリーに含まれるソースのうち, GNU 一般公有使用許諾(GPL) または GNU ライブラリ 一般公有使用許諾(GLPL) に従っているものについては, 多少制限が科されています. ただし, ソースコードへのアクセスの保証という, 一般の制限とはいわば逆の制限です. ただし GPL ソフトウェアを商用で利用する場合, さらに複雑になるのは避けられません. そのため, それらのソフトウェアを, より制限の少ない BSD 著作権に従ったソフトウェアで置き換える努力を, 可能な限り日々続けています. 訳注 GPL では, 「ソースコードを実際に受け取るか, あるいは希望しさえすればそれを入手することが可能であること」を求めています. どうして FreeBSD と呼ばれているのですか? 無料(free)で使うことができる(商利用も含む). オペレーティングシステムの完全なソースコードが自由(freely)に手に入り, 商利用・非商利用にかかわらず, 最低限の制限で他の仕事への利用, 配布, 導入が可能. 改良やバグフィックスがある場合, 誰でも(free)そのコードを提出でき, ソースツリーに加えることができます (いくつかの簡単な条件には従ってもらいます). 母国語が英語でない読者のために, ここでは free という単語が二つの意味で用いられていることを指摘しておくと分かりやすいかも知れません. ひとつは「無料である」ということ, もうひとつは「自分のやりたいようにできる」ということです. FreeBSD のコードでできないいくつかのこと (自分が書いたものだと偽るなど)を除けば, あなたは自分のやりたいことをやることが可能なのです. FreeBSD の最新バージョンは? 4.2 が最新の STABLE バージョンで, 2000 年 11 月にリリースされました. また, これは最新の RELEASE バージョンでもあります. 簡単に言ってしまうと, -STABLE は最新の -CURRENT のスナップショットのすばらしい新機能の数々よりも, 安定性と変更回数の少なさを好む ISP や, 他の企業のユーザをターゲットにしています. リリースはこの二種類のブランチで行なわれますが, (-STABLE と比較すると多少)不安定な動作があるということを許容できるなら, 必要となるのは -CURRENT の方だけでしょう. 各リリースは 数カ月毎にしか行なわれません. 多くの人々が FreeBSD のソースをそのリリースよりも 最新の状態に維持している(FreeBSD-current と FreeBSD-stable に関する質問も参照してください) のですが, ソースというのは常に改変され続けているため, そうすることは一種の慣例になっています. FreeBSD-CURRENTって何? FreeBSD-CURRENT はオペレーティングシステムのの開発バージョンで, やがて 5.0-RELEASE となります. よってこれは, そこに携わっている開発者や, どんな障害をも乗り越えていけるタフな愛好家たちにとってのみ興味の対象となるものです. -CURRENT の使用に際しての詳細は FreeBSD ハンドブック の 関連するセクション を参照してください. オペレーティングシステムに馴染みがない場合や, それが一時的に発生している問題なのか, それとも本質的な問題かを見極める能力がない場合は, FreeBSD-CURRENT を使うべきではありません. このブランチは時々急激に拡張されたり, システムが構築できない状態になることもちょっちゅうあります. FreeBSD-CURRENT を使う人は問題を分析し, 「小さな欠陥」ではなく, 明らかに間違いであると思われるものだけを報告できるものと想定されています. 「make world したら group 関係でエラーがでました」のような質問は, -CURRENT メーリングリストでは軽蔑の眼差しであしらわれることもあります. 毎日, その時点の -CURRENT と -STABLE のコードを元に snapshot が作成されています. 現在は, その snapshot の配布も利用可能です. それぞれの snapshot には以下のような目的があります. インストールプログラムの最新版のテスト. 試してみたいけれど, 基礎的な所から毎日変わるようなものを追いかける時間もバンド幅も無い, という人にも -CURRENT や -STABLE を使えるようにする. また, そのような人たちのシステム移行のための手っ取り早い方法を提供する. あとでとんでもないことをしてしまった時のために, 問題となるコードの特定の参照基準点を保存しておく. (通常は CVS がこういうハプニングのような恐ろしい事態を防止して いるんですけどね :) テストが必要な新しい機能を, できる限り多くの隠れテスターに試してもらう. どんな目的であれ, -CURRENT snapshot が製品レベルの品質であるとの考えに基づく要求は行わないでください. 安定性やテスト十分性にこだわる人は, 完全なリリース, あるいは -STABLE snapshot から離れてはいけません. スナップショットリリースは, 5.0-CURRENT が ftp://current.FreeBSD.org/pub/FreeBSD/ から, 4-STABLE が releng4.FreeBSD.org から直接入手可能です. また, 3-STABLE スナップショットは, この文章の執筆時点 (2000 年 5 月) で作成されていません. スナップショットリリースは, 現在, 開発や保守作業が行なわれているすべてのブランチにおいて, 平均して一日一回作成されます. FreeBSD-STABLE のコンセプトは何ですか? FreeBSD 2.0.5 がリリースされた後, 私たちは FreeBSD の開発を 2 系統に分割することにしました. 一つは -STABLE というブランチで, バグの修正はしっかりテストされ, 機能の強化は少しずつしか行われません(急な変更や実験的機能を望まない, インターネットサービスプロバイダや営利企業向け). もう一方のブランチは -CURRENT で, 2.0 がリリースされて以来 5.0-RELEASE(そしてその後も)へ向けて脈々と続いているものです. ASCII で描いた簡単な図がわかりやすいかは自信がありませんが, こんな感じになります. 2.0 | | | [2.1-STABLE] *BRANCH* 2.0.5 -> 2.1 -> 2.1.5 -> 2.1.6 -> 2.1.7.1 [2.1-STABLE 終了] | (1997/03) | | | [2.2-STABLE] *BRANCH* 2.2.1 -> 2.2.2-RELEASE -> 2.2.5 -> 2.2.6 -> 2.2.7 -> 2.2.8 [終了] | (1997/03) (1997/10) (1998/04) (1998/07) (1998/12) | | 3.0-SNAPs (1997 年第一四半期開始) | | 3.0-RELEASE (1998/10) | | [3.0-STABLE] *BRANCH* 3.1-RELEASE (1999/02) -> 3.2 -> 3.3 -> 3.4 -> 3.5 -> 3.5.1 | (1999/05) (1999/09) (1999/12) (2000/06) (2000/07) | [4.0-STABLE] *BRANCH* 4.0 (2000/03) ->4.1 -> 4.1.1 -> 4.2 -> ... 将来の 4.x リリース ... | | (2000/07) (2000/09) (2000/11) | \|/ + [5.0-CURRENT として継続中] -CURRENT ブランチは 5.0 とその先へ向けてゆっくりと進化を続けています. 従来あった 2.2-STABLE ブランチは 2.2.8 のリリースをもって終了しました. 3-STABLE がそれに代わり, 2000 年 7 月に 3.5.1-RELEASE (最後の 3.X リリース) がリリースされました. 2000 年 3 月 (3.5 の公開前になりますが) には, 3-STABLE ブランチはほぼ, 4-STABLE ブランチによって置き換えられました. 4.2-RELEASE は 2000 年 11 月にリリースされました. 4-STABLE は現在 -STABLE ブランチで活発に開発が続けられていますが, 3-STABLE へのバグの修正 (ほとんどがセキュリティ関連のもの) もまだ行なわれています. 3.X ブランチは 2000 年の夏には公式に開発が終了する予定です. 現在の current branch は 5.0-CURRENT であり, 最初の 5.0 系列のリリース予定はまだ決定していません. FreeBSD のリリースはいつ作られるのですか? FreeBSD コアチームは原則的に, 新しい機能やバグフィックスが充分集まり, リリースの安定性を損なうことが無いよう, さまざまな変更が十分に安定しているという条件を満たしている場合にのみ, 新しいバージョンの FreeBSD をリリースします. たとえこの用心深さが新しい機能が使えるようになることを 待ち望んでいるユーザを欲求不満にさせるとしても, 多くのユーザはこのことを FreeBSD の最も良い所の一つだと考えています. リリースの作成は, 平均的に言っておよそ 4 ヶ月ごとに行なわれます. もう少し刺激が欲しい(あるいは待ち遠しい)方々向けには, 毎日バイナリスナップショットが作成されています. 上記を参照してください. FreeBSD は PC 用だけしかないの? FreeBSD 3.x 以降は x86 アーキテクチャと同様, DEC Alpha でも動作します. また, SPARC, PowerPC, IA64 への移植という興味深い話もあります. 異なるアーキテクチャのマシンを 持っていて, ゆっくり待てないという場合には次の URL を 参照してください. NetBSD または OpenBSD. FreeBSD の責任者はいったい誰? プロジェクトの全体的な方向性や, 誰にソースツリーにコードの書き込み権限を与えるか, などといった FreeBSD プロジェクトに関する重要な意思決定は, 9 名からなるコアチーム(core team)によってなされます. ソースツリーを直接変更できる人はもっと多く, 200 名以上のソースツリー管理者(committer) がいます. しかし, メーリングリストで先行して議論される, 通常の変更ではないものの議論への参加には, 一切制限はありません. どこから FreeBSD を入手できますか? FreeBSD のすべての主要なリリースは anonymous FTP 経由で FreeBSD FTP サイト から入手できます. 現在の 3.X-STABLE リリース, 3.5.1-RELEASE は 3.5.1-RELEASE のディレクトリにあります. 現在の 4-STABLE リリース, 4.2-RELEASE は 4.2-RELEASE のディレクトリにあります. 4.X Snapshot は, ほぼ一日に一回作成されています. 5.0 Snapshot リリースは -CURRENT ブランチ用に一日に一回作成されており, これらは純粋に最先端の開発者およびテスターのために提供されています. また, FreeBSD は CD-ROM でも入手でき, 次のところで注文できます.
BSDi 4041 Pike Lane, Suite F Concord, CA 94520 USA Orders: +1 800 786-9907 Questions: +1 925 674-0783 FAX: +1 925 674-0821 email: BSDi Orders address WWW: BSDi Home pageOrders: +1 800 786-9907
オーストラリアでは, 次のところに問い合わせてください.
Advanced Multimedia Distributors Factory 1/1 Ovata Drive Tullamarine, Melbourne Victoria Australia Voice: +61 3 9338 6777 CDROM Support BBS 17 Irvine St Peppermint Grove, WA 6011 Voice: +61 9 385-3793 Fax: +61 9 385-2360
イギリスの場合は次のところです.
The Public Domain & Shareware Library Winscombe House, Beacon Rd Crowborough Sussex. TN6 1UL Voice: +44 1892 663-298 Fax: +44 1892 667-473
 FreeBSD のメーリングリストについて知りたいのですが? 完全な情報が FreeBSD ハンドブックのメーリングリストの節 にあります. FreeBSD の西暦 2000 年問題に関する情報はどこにありますか? 完全な情報が FreeBSD Y2K のページ にあります. FreeBSD のニュースグループは何がありますか? 完全な情報が FreeBSD ハンドブックのニュースグループの節にあります. FreeBSD の IRC(Internet Relay Chat)について何か情報はありますか? あります. 以下のように, ほとんどの有名な IRC ネットワークには FreeBSD のチャットチャンネルがあります. EFNet の Channel #FreeBSD は FreeBSD 関係のフォーラムですが, そこで技術的サポートを期待してはいけません. そこにいる人たちはあなたをマニュアルページを読むとか, 研究をするとかといった苦労から遠ざけようとします. まず第一に, これはチャットチャンネルであり, そこにあるトピックスは恋人募集, スポーツ, 核兵器といったようなものであり, FreeBSD も同列に扱われています. 一応注意しましたからね! これは irc.chat.org のサーバー上にあります. EFNet の Channel #FreeBSDhelp は FreeBSD ユーザのヘルプ専用チャネルです. 参加者は #FreeBSD チャネルよりも親切に質問に答えてくれます. DALNET の Channel #FreeBSD はアメリカでは irc.dal.net, ヨーロッパでは irc.eu.dal.net にあります. UNDERNET の Channel #FreeBSD はアメリカでは us.undernet.org, ヨーロッパでは eu.undernet.org にあります. ここはヘルプチャンネルです. ドキュメントを読める準備をしてから利用してください. HybNet の Channel #FreeBSD は irc.FreeBSD.org にあります. このチャンネルはへルプチャンネルです. それぞれのチャンネルは別個のもので, 互いに接続されていません. チャットのスタイルも違っていますので, 自分のチャットのスタイルにあったものを見つけるために一つ一つ試すのもいいでしょう. あらゆる種類の IRC トラフィックのため, 失礼なことをいう若者たち(年輩の方は少数です)のために機嫌を損ねたり, 手に負えなくなっても気にしてはいけません. FreeBSD の本 &a.doc; にコンタクトしてみてください(さらに参加すればもっとよいでしょう). このメーリングリストは FreeBSD 関連の文書に関する議論のためのものです. FreeBSD に関する質問に対しては, &a.questions; というメーリングリストがあります. FreeBSD ハンドブックもあります. これは現在作業中で, 不完全だったり最新情報でないものが含まれていることに注意してください. FreeBSD のガイド本の決定版は, Greg Lehey 氏による The Complete FreeBSD です. これは BSDi (以前の Walnut Creek CDROM) Books から出版されています. 現在は第二版になっていて, インストール, システム管理ガイド, プログラム設定のヘルプ, マニュアルページまでの内容が 1,750 ページにわたって書かれています. この本は(そして現在の FreeBSD リリースは) BSDi, CheapBytes, または最寄りの書店で注文することができます. ISBN コードは 1-57176-227-2 です. また, FreeBSD は Berkeley 4.4BSD-Lite ベースなので, 多くの 4.4BSD のマニュアルが FreeBSD にも応用できます. O'Reilly and Associates が以下のマニュアルを出版しています. 4.4BSD System Manager's Manual By Computer Systems Research Group, UC Berkeley 1st Edition June 1994, 804 pages ISBN: 1-56592-080-5 4.4BSD User's Reference Manual By Computer Systems Research Group, UC Berkeley 1st Edition June 1994, 905 pages ISBN: 1-56592-075-9 4.4BSD User's Supplementary Documents By Computer Systems Research Group, UC Berkeley 1st Edition July 1994, 712 pages ISBN: 1-56592-076-7 4.4BSD Programmer's Reference Manual By Computer Systems Research Group, UC Berkeley 1st Edition June 1994, 886 pages ISBN: 1-56592-078-3 4.4BSD Programmer's Supplementary Documents By Computer Systems Research Group, UC Berkeley 1st Edition July 1994, 596 pages ISBN: 1-56592-079-1 これらの詳細な説明が WWW 経由で 4.4BSD books description から読むことができます. 販売数が少ないためこれらのマニュアルは入手しにくいかもしれません. 4.4BSD のカーネル構成についてより徹底的に知りたいのなら, これなら間違いないでしょう. McKusick, Marshall Kirk, Keith Bostic, Michael J Karels, and John Quarterman. The Design and Implementation of the 4.4BSD Operating System. Reading, Mass. : Addison-Wesley, 1996. ISBN: 0-201-54979-4 システム管理について参考になる本は次のものです. Evi Nemeth, Garth Snyder, Scott Seebass & Trent R. Hein, ``Unix System Administration Handbook'', Prentice-Hall, 1995 ISBN: 0-13-151051-7 初版のものではなく, 赤いカバーの第二版であるか 確認してください. この本は TCP/IP だけでなく DNS, NFS, SLIP/PPP, sendmail, INN/NNTP, 印刷などの基礎を扱っています. 高価ですが(およそ US$45-$55), 買う価値はあります. また, 色々なツールのソースコードが入った CD-ROM が付属しています. しかし, それらのほとんどは FreeBSD 2.2.6R CD-ROM に収録されています(さらに FreeBSD CD-ROM の収録物の方がより新しい場合があります). 障害報告(PR; Problem Report) データベースにアクセスする方法は? ユーザからの変更要求がまとめられている Problem Report データベースは, 障害報告の web ベースのインタフェースを通して, 提出と問い合わせを行なうことができます. また, send-pr(1) コマンドを使用して, 電子メール経由で障害報告や変更要求を提出することもできます. プレインテキスト(ASCII)版 や PostScript 版の FreeBSD 文書はないのでしょうか? はい, もちろんあります. 数多くの異なるフォーマット, 圧縮形式の文書が FreeBSD FTP サイトの /pub/FreeBSD/doc/ というディレクトリから入手可能です. 文書は, 次のようなさまざまな観点から分類されています. faq や handbook といった文書名による分類. 文書の言語とエンコーディングによる分類. これは FreeBSD システムの /usr/share/locale にある locale 名に基づいています. 現在利用可能な言語, エンコーディングは以下のとおりです. 名前 意味 en_US.ISO8859-1 英語(米国) de_DE.ISO_8859-1 ドイツ語 es_ES.ISO8859-1 スペイン語 fr_FR.ISO8859-1 フランス語 ja_JP.eucJP 日本語(EUC エンコーディング) ru_RU.KOI8-R ロシア語(KOI8-R エンコーディング) zh_TW.Big5 中国語(Big5 エンコーディング) 言語によっては準備されていない文書も存在します. 文書の形式による分類. 文書は数多くの異なる出力形式を用意し, 可能な限り柔軟な対応ができるようにしています. 現在, 利用可能な文書形式は以下のとおりです. 文書形式 意味 html-split サイズの小さい, リンクされた複数の HTML ファイル html 文書全体を含んだ, 単一の大きなファイル pdb iSilo で利用可能な Palm Pilot データベース形式 pdf Adobe 社の PDF(Portable Document Format)形式 ps Postscript 形式 rtf Microsoft 社のリッチテキスト形式 この形式を Word で読み込んだ場合, ページ番号は自動的に更新されません. ページ番号を更新するには文書を読み込んでから CTRL+A, CTRL+END, F9 を押してください. txt プレインテキスト形式 圧縮と package 形式による分類. 現在利用されているのは次の 3 種類です. html-split 形式の場合, ファイルはまず, &man.tar.1; を使ってまとめられ, まとめられた .tar ファイルは次に解説する方式で圧縮されます. その他の形式の場合, ファイルは book.format (例えば book.pdb, book.html など) という単一のファイルです. 上にあげたファイルは 3 種類の方式のいずれかで圧縮されます. 方式 説明 zip Zip 形式. FreeBSD で圧縮を元に戻すには, まず archivers/unzip の port をインストールする必要があります. gz GNU Zip 形式. 圧縮を元に戻すには, FreeBSD に含まれる &man.gunzip.1; を使います. bz2 BZip2 形式. 他の形式に比べて普及していませんが, 一般的にファイルサイズが小さくなります. 圧縮を元に戻すには, archivers/bzip2 port をインストールしてください. Postscript 版のハンドブックが BZip2 形式で圧縮されている場合, ファイル名は handbook/ ディレクトリの中の book.sgml.bz2 になります. さまざまな形式に整形された文書は, 以下に述べるように FreeBSD の package としても提供されています. ダウンロードする文書と圧縮形式を選択したら, 文書を FreeBSD package としてダウンロードするかどうか決めなければなりません. package としてダウンロードしてインストールする場合には, 文書を &man.pkg.add.1; や &man.pkg.delete.1; といった, 普通の FreeBSD package 管理システムを用いた管理が可能であるという利点があります. 文書の package をダウンロードしてインストールすることに決めたら, まずはダウンロードするファイル名を知る必要があります. 文書の package は, packages というディレクトリに置かれています. そしてそれぞれの package ファイルは, 文書名.言語.エンコーディング.形式.tgz というような名前になっています. たとえば, FAQ の英語版で PDF 形式のものは, faq.en_US.ISO8859-1.pdf.tgz というファイル名です. ファイル名がわかったら, 次のようなコマンドで英語版の PDF 形式 FAQ の package をインストールすることができます. &prompt.root; pkg_add ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/packages/faq.en_US.ISO8859-1.pdf.tgz インストールの終了後は &man.pkg.info.1; を使い, ファイルがどこにインストールされたかを調べることができます. &prompt.root; pkg_info -f faq.en_US.ISO8859-1.pdf Information for faq.en_US.ISO8859-1.pdf: Packing list: Package name: faq.en_US.ISO8859-1.pdf CWD to /usr/share/doc/en_US.ISO8859-1/books/faq File: book.pdf CWD to . File: +COMMENT (ignored) File: +DESC (ignored) ご覧になるとわかるとおり, book.pdf は /usr/share/doc/en_US.ISO8859-1/books/faq にインストールされます. package を利用しない場合は, 自分で圧縮されたファイルをダウンロードして元に戻し, 適切な場所にそれをコピーする必要があります. たとえば, 分割された HTML 版の FAQ で, &man.gzip.1; で圧縮されているものは en_US.ISO8859-1/books/faq/book.html-split.tar.gz というファイルです. これをダウンロードして圧縮を元に戻すには, 次のようにする必要があるでしょう. &prompt.root; fetch ftp://ftp.freebsd.org/pub/FreeBSD/doc/en_US.ISO8859-1/books/faq/book.html-split.tar.gz &prompt.root; gzip -d book.html-split.tar.gz &prompt.root; tar xvf book.html-split.tar こうすると, 複数の .html ファイルが作成されます. 中心となっているのは index.html という名前のファイルで, 目次や前書き, 文書の他の部分へのリンクが含まれています. これらのファイルは, 必要に応じて他の場所にコピーしても構いません. FreeBSD のウェブサイトのミラーサイトになりたいです! 承知しました! ウェブページをミラーするにはいくつかの手段があります. CVSup を使います. CVSup を使って CVSup サーバに接続することで, 整形されたファイルを取ってくることができます. ウェブページを取得する場合は, /usr/share/examples/cvsup/www-supfile にある supfile の例を参考にしてください. FTP を使ってミラーリングします. あなたの好きな FTP ミラーリングツールを使って, FTP サーバに置いてある web サイトのコピーをダウンロードすることができます. タウンロードは単純に ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-CURRENT/www から始めてください. この文書を他の言語に翻訳したいのですが? 報酬は支払えませんが, 文書の翻訳を提出してくださる方には, フリーの CD, T シャツの手配や, ハンドブックにある貢献者一覧への登録を行ないたいと思います. 翻訳作業をはじめる前に, &a.doc; へ連絡するようにお願いします. 翻訳作業を手伝うという人が現われるかも知れませんし. 既に翻訳チームがあって, あなたの参加を歓迎してくれるかも知れません. その他の情報 以下のニュースグループには FreeBSD ユーザに直接関係のある議論が行われてます. comp.unix.bsd.freebsd.announce (moderated) comp.unix.bsd.freebsd.misc comp.unix.bsd.misc Web 上のリソース: FreeBSD のホームページ ラップトップ PC を持っている方は, 迷うことなく日本の細川 達己氏の Mobile Computing のページ を見ましょう. SMP (Symmetric MultiProcessing) に関する情報は, SMP サポートページをご覧ください. FreeBSD のマルチメディアアプリケーションに関する情報は, マルチメディアのページをご覧ください. 特に Bt848 ビデオキャプチャチップに興味のある方は, リンクをたどってみてください. FreeBSD ハンドブックには, 実に完成された参考図書の一覧があり, 買うべき本をさがしている方は読む価値があります. インストール 訳: &a.iwasaki;, &a.jp.mrt;, 1997 年 11 月 8 日. FreeBSD を入手するには, どのファイルをダウンロードすれば良いのでしょうか? FreeBSD 3.1-RELEASE 以前では, インストールの際に必要なのは floppies/boot.flp と名前のついた 一つのフロッピーディスクイメージだけでした. しかし FreeBSD 3.1-RELEASE 以降, 幅広い種類のハードウェアサポートが基本システムに追加され, そのサポートが必要とする容量を補うため, 3.X と 4.X の系列では新たに, floppies/kernel.flp および floppies/mfsroot.flp という, 二つのフロッピーディスクイメージを使うようになりました. これらのイメージをフロッピーディスクに書き込むには, fdimage や &man.dd.1; といったツールが必要となります. (DOS ファイルシステムからのインストールなどで) あなた自身が手動で配布ファイルをダウンロードする場合には, 以下の配布ファイルをダウンロードすることをおすすめします. bin/ manpages/ compat*/ doc/ src/ssys.* この手順の完全な説明と, 一般的なインストール時の問題については FreeBSD ハンドブックのインストールの節 を参照してください. ブートフロッピーイメージが一枚のフロッピーディスクに納まらないみたい! 3.5 インチ(1.44MB)のフロッピーディスクには, 1474560 バイトのデータを格納できます. ブートイメージはちょうど 1474560 バイトの大きさです. ブートフロッピーディスクを準備する際のよくある間違いには, 以下のものがあります. FTP によってフロッピーイメージをダウンロードする際に, バイナリ(binary)モードにしていなかった. FTP クライアントの中には, 転送モードのデフォルトをアスキー(ascii)モードにして, クライアント側システムの慣習にあうよう, すべての行末の文字を変更するものがあります. この場合は常に, ブートイメージが壊れたものになります. ダウンロードしたブートイメージのサイズをチェックしてください. サーバ上のものと正確に一致しなければ, ダウンロードの処理を疑いましょう. これを回避するには, サーバに接続してイメージのダウンロードを開始する前に FTP のコマンドプロンプトで binary とタイプします. ブートイメージを DOS の copy コマンド(または GUI の同等のツール)でフロッピーディスクへ転送した. copy のようなプログラムは, 直接起動するように作成されたブートイメージをうまく処理できません. イメージにはフロッピーディスクの完全な中身がトラック単位で格納されており, フロッピーディスク上に通常のファイルとして 格納されるように想定されているわけではありません. FreeBSD のインストールに記述されているように, 低レベルのツール(たとえば fdimage や rawrite) を使用してそのままの(raw)の状態でフロッピーディスクに 転送する必要があります. FreeBSD のインストールについての説明書はどこにありますか? インストールの説明書はFreeBSD ハンドブックのインストールの章にあります. FreeBSD を動作させるには何が必要ですか? 386 以上の PC, 5MB 以上の RAM, そして最低 60MB のハードディスク容量が必要となります. ローエンドの MDA カードでも動作しますが, X11R6 を使うには VGA かそれ以上のビデオカードが必要となります. もご覧ください. 4 MB しかメモリがないのですが, インストールできますか? 4MB のシステムにインストールできた最後の FreeBSD は FreeBSD 2.1.7 でした. 2.2 を含むより新しいバージョンの FreeBSD は新規のインストールに最低 5MB は必要になります. ただし, インストールプログラムが 4MB では動作しないだけで, 3.0 を含む FreeBSD のすべてのバージョンは 4MB の RAM で動作可能です. インストールする時だけさらに 4MB 追加しておき, システムがセットアップされて動作するようになった後, また 4MBを取り出して元に戻すこともできます. あるいは 4MB より多くメモリを搭載したシステムにディスクを持っていき, そのマシンでインストールした後にディスクを戻すこともできます. また, FreeBSD 2.1.7 であっても, 4MB ではインストールできない場合があります. 正確には, 640KB のベースメモリ + 3MB の拡張メモリでは, インストールはできません. もしマシンのマザーボードが 640KB から 1MB の領域で「失われた」メモリを再マップできる場合は, FreeBSD 2.1.7 をインストールできるかもしれません. BIOS のセットアップ画面で, remap のオプションを探して有効(enable)にしてみてください. また, ROM shadowing を無効(disable)にする必要もあります. 簡単なやり方としては, インストールする時だけあと 4MB 追加しておく方法があります. 必要なオプションだけを選択してカスタムカーネルを構築し, また 4MB を取り出してもとに戻せばいいのです. また, 2.0.5 をインストールして, それから 2.1.7 のインストーラの upgrade オプションでシステムを 2.1.7 へアップグレード するというやり方もあります. インストールしたあとでカスタムカーネルの構築をした場合には, 4MB でも動作します. 2MBで起動に成功した人もいます(でもそのシステムは, ほとんど使いものになりませんでした :-)). 自分用のインストールフロッピーを作るには? 現在はカスタムインストールフロッピーディスク「だけ」を作る方法はありません. カスタムインストールフロッピーディスクイメージを含む, release 環境全体を新たに作る必要があります. カスタムの release 環境をつくるには, ここの指示にしたがってください. 自分の PC に複数のオペレーティングシステムを入れるには? multi-OS のページをご覧ください. 同じマシンで Windows 95/98 と共存できますか? まず Windows 95/98 をインストールしてから, そのあとで FreeBSD をインストールしてください. FreeBSD のブートマネージャが Win95 と FreeBSD のブート管理をしてくれるようになります. Windows 95/98 を後にインストールした場合はひどいことに, 問い合わせることもなくブートマネージャを上書きしてしまいます. そうなってしまった場合は次の節をご覧ください. Windows 95/98 がブートマネージャを潰しちゃった! どうやって戻すの? ブートマネージャの再インストールの方法として, FreeBSD では以下に示す三通りの方法が用意されています. DOS を起動し, FreeBSD の配布物の中にある tools/ ディレクトリへ移動し, bootinst.exe を探してください. そして次のように実行します. ...\TOOLS> bootinst.exe boot.bin こうすることで, ブートマネージャが再インストールされます. FreeBSD のブートフロッピーディスクから起動し, 「カスタム」インストールメニューを選択し, 続いて「パーティション」を選択します. ブートマネージャがインストールされていたドライブ(多分最初のもの)を選択し, パーティションエディタにたどり着いたら, (何も変更せず)そのまま (W)rite を指定します. 確認のメッセージが出ますので「はい(Y)」と答え, ブートマネージャ選択の画面で確実に Boot Manager を選択します. これでブートマネージャがディスクに再び書き込まれます. インストールメニューから抜けて再起動すると, ハードディスクは元通りになります. FreeBSD 起動フロッピー (もしくは CD-ROM) から起動し, Fixit メニューを選択します. Fixit フロッピーか CD-ROM #2 (live ファイルシステムオプション) の好きな方をを選択して fixit シェルに入ります. そして, 次のコマンドを実行してください. Fixit# fdisk -B -b /boot/boot0 起動デバイス 起動デバイス の部分は, たとえば ad0 (一番目の IDE ディスク), ad4 (セカンダリ IDE コントローラの一番目の IDE ディスク), da0 (一番目の SCSI ディスク) などといった, 実際の起動デバイスを表しています. IBM Thinkpad の A, T, X シリーズのいずれかを持っています. FreeBSD をインストールしたら起動しなくなってしまいました. どうすればいいですか? これらのマシンに使われている初期のリビジョンの IBM BIOS にはバグがあり, FreeBSD のパーティションをディスクサスペンド用の FAT 領域だと誤認します. そのため, BIOS が FreeBSD のパーティションを 検出したところでシステムがハング (停止) してしまいます. IBM これは Keith Frechette kfrechet@us.ibm.com からのメールによります. によれば, 以下のモデル/BIOS リリース番号には修正が含まれています. モデル BIOS リビジョン番号 T20 IYET49WW 以降 T21 KZET22WW 以降 A20p IVET62WW 以降 A20m IWET54WW 以降 A21p KYET27WW 以降 A21m KXET24WW 以降 A21e KUET30WW もし問題のある BIOS を使っていてアップグレードが選べない場合, FreeBSD をインストールしてから FreeBSD が使っているパーティション ID を変更し, 変更されたパーティション ID を正しく扱うことのできる 新しい起動ブロックをインストールすることで解決することができます. それにはまず, セルフテスト画面を通過する状態にまでマシンを回復させる必要があります. そのためには, マシンがプライマリディスクから FreeBSD パーティションを見つけないようにして起動しなければなりません. たとえば, 一度ハードディスクを外してしまって, そのディスクを古い ThinkPad (ThinkPad 600 など) やデスクトップ PC に適切な変換ケーブルで接続します. その後 FreeBSD のパーティションを削除し, ハードディスクを元の ThinkPad に戻します. こうすることで ThinkPad は起動可能な状態に戻るはずです. マシンがちゃんと動くようになったら, 以下の復旧手順に従って FreeBSD をインストールすることができます. http://people.freebsd.org/~bmah/ThinkPad/ から boot1 と boot2 をダウンロードします. これらのファイルは, あとで必要になった時, 取り出せる場所に置いておきます. ThinkPad に普通に FreeBSD をインストールします. ただし, Dangerously Dedicated モードを使ってはいけません. また, インストールが終わっても再起動してはいけません. 緊急ホログラフィックシェル (Emergency Holographic Shell) (ALTF4) に切り替えるか, fixit シェルを起動します. &man.fdisk.8; を使って FreeBSD のパーティション ID を 165 から 166 に 変更します (これは OpenBSD で使われているものです). boot1 と boot2 のファイルをローカルファイルシステムに持って来ます. &man.disklabel.8; を使って boot1 と boot2 を FreeBSD のスライスに書き込みます. &prompt.root; disklabel -B -b boot1 -s boot2 ad0sn n は, あなたが FreeBSD をインストールしたスライスの番号です. 再起動します. 起動プロンプトは OpenBSD と示しますが, 実際には, それで FreeBSD が起動します. この方法で FreeBSD と OpenBSD をデュアルブートする方法は, 読者への練習問題としましょう. 不良ブロックのあるディスクにインストールできますか? FreeBSD 3.0 以前のシステムでは, 不良ブロックを自動的に再マッピングする bad144 というユーティリティが含まれていましたが, 現在の IDE ドライブはドライブ自身がこの機能を備えているため, bad144 は FreeBSD ソースツリーから削除されました. FreeBSD 3.0 かそれ以降をインストールしたいと思っているなら, 比較的新しいディスクドライブを購入することを強くおすすめします. 新しいドライブを購入する気がなければ, FreeBSD 2.x を利用するべきです. 現在の IDE ドライブで不良ブロックによるエラーが発生した場合, まもなくドライブが故障する可能性があります (それはそのドライブ内蔵の再マッピング機能では 不良ブロックが修正できなくなったということであり, ディスクがひどく壊れていることを意味します). 新しいハードディスクドライブに交換しましょう. 不良ブロックのある SCSI ドライブの場合は, この回答を参照してください. インストーラから起動したら変なことになりました! インストーラから起動しようとしたときに, マシンが固まってし まうとか自然と再起動してしまうといった現象であれば, 次の三つの項目を確認してください. 新品の, フォーマットしたての, エラーのないフロッピーディスクを使っていますか? (三年間もベッドの下に放置されていた雑誌の付録みたいなやつではなくて, 買ってきたばかりの新品を使ってください) フロッピーイメージをバイナリモードでダウンロードしましたか? (困った顔をしないでください. 私たちの中で一番優秀な人でさえ, 少なくとも一回はバイナリファイルを ASCII モードで思いがけずダウンロードしたことがあるのです!) Windows95 あるいは Windows98 を使用しているなら, ありのままの本物の DOS で fdimage か rawrite を実行しましたか? これらの OS はディスク作成プログラムのような, ハードウェアに直接書き込みを行なうプログラムに干渉する可能性があります. GUI の中の DOS シェル内部で動作している場合でも, この問題は発生します. また, Netscape でブートイメージをダウンロードする場合も問題があることが報告されていますので, できれば別の FTP クライアントを使うのがよいでしょう. APAPI CD-ROM から起動したのですが, インストールプログラムは CD-ROM が見つかりませんと言ってきます. CD-ROM はどこに行ってしまったのでしょうか? この問題は通常, CD-ROM ドライブの設定ミスによって発生します. 大部分の PC の CD-ROM ドライブは, セカンダリ側の IDE コントローラのスレーブデバイスとして接続され, マスタデバイスがない状態で出荷されています. この接続方法は ATAPI 規格違反なので, Windows は規格どおりに動いたり, 動かなかったりしますが, BIOS は起動時に規格違反を無視します. そのため BIOS は起動時に CD-ROM を見つけられますが, FreeBSD は CD-ROM を見つけられず, インストールを完了できないのです. CD-ROM が 接続されている IDE コントローラのマスタデバイスとなるように設定するか, もしくはマスタ, スレーブの両方にデバイスが接続されているようにシステムを再構成してください. あれれ? テープからインストールできません! FreeBSD 2.1.7R をテープからインストールする場合, tar ブロックサイズを 10(5120 バイト)にしたテープを作る必要があります. デフォルト の tar ブロックサイズは 20(10240 バイト)で, このデフォルトサイズで作られたテープでは FreeBSD 2.1.7R をインストールすることはできません. もしこうしたテープを使うと, レコードサイズが大きすぎるというエラーが起きることになります. PLIP 経由で二つ FreeBSD box を接続したいのですが Laplink パラレルケーブルを用意して, 両方の PC のカーネルに lpt ドライバが組み込まれていることを確認してください. &prompt.user; dmesg | grep lp lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface パラレルインタフェースに Laplink パラレルケーブルを接続します. root になって, 両方で lp0 のネットワークインタフェースパラメータを設定します. 例えば, ホスト max と moritz を接続したい場合, max <-----> moritz IP Address 10.0.0.1 10.0.0.2 max 側で次のようにして, &prompt.root; ifconfig lp0 10.0.0.1 10.0.0.2 moritz 側で同様に次のようにします. &prompt.root; ifconfig lp0 10.0.0.2 10.0.0.1 以上です! &man.lp.4; と &man.lpt.4; のマニュアルページも参照してください. また, /etc/hosts にホストの追加もしましょう. 127.0.0.1 localhost.my.domain localhost 10.0.0.1 max.my.domain max 10.0.0.2 moritz.my.domain moritz 動作確認は次のようにします. max 側: &prompt.user; ifconfig lp0 lp0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 10.0.0.1 --> 10.0.0.2 netmask 0xff000000 &prompt.user; netstat -r Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire moritz max UH 4 127592 lp0 &prompt.user; ping -c 4 moritz PING moritz (10.0.0.2): 56 data bytes 64 bytes from 10.0.0.2: icmp_seq=0 ttl=255 time=2.774 ms 64 bytes from 10.0.0.2: icmp_seq=1 ttl=255 time=2.530 ms 64 bytes from 10.0.0.2: icmp_seq=2 ttl=255 time=2.556 ms 64 bytes from 10.0.0.2: icmp_seq=3 ttl=255 time=2.714 ms --- moritz ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 2.530/2.643/2.774/0.103 ms ラップトップ PC に PLIP 経由でインストールできますか? 次のようにして, 二つのコンピュータを Laplink パラレルケーブルで接続してください. ネットワーク接続用のパラレルケーブルの結線 A-name A 側 B 側 説明 ポート / ビット DATA0 -ERROR 2 15 15 2 Data 0/0x01 1/0x08 DATA1 +SLCT 3 13 13 3 Data 0/0x02 1/0x10 DATA2 +PE 4 12 12 4 Data 0/0x04 1/0x20 DATA3 -ACK 5 10 10 5 Strobe 0/0x08 1/0x40 DATA4 BUSY 6 11 11 6 Data 0/0x10 1/0x80 GND 18-25 18-25 GND -
また, Mobile Computing についてのページもご覧ください. ハードディスクドライブには, どのジオメトリを使うべきでしょうか? ここでディスクの「ジオメトリ」とは, ディスクのシリンダ, ヘッダ, トラック当りのセクタの数を意味しています - 便宜上, C/H/S とすることにします. これはディスクのどの領域で読み書きを 行なうかを PC の BIOS が決定する手段となります. これについてはある理由のために, 誤解されている点が多いようです. まず最初に, FreeBSD はディスクブロックで動作しているため, SCSI ドライブの物理的なジオメトリという言い方は, まったく見当違いのものです. 事実, セクタの密度はディスクによってまちまちであるため, 物理的なジオメトリというものは存在しません. 製造者が「本当の」物理的なジオメトリと公表しているものは通常, 彼らが検査して得た最小の使用不可容量の結果のジオメトリのことです. IDE の場合, FreeBSD は C/H/S で動作しますが, 最近のドライブはすべて, これを内部で参照するブロックに変換しています. 問題はとなるのは論理的なジオメトリです. これは BIOS がそのディスクのジオメトリについて調べた際に取得されるものであり, その後のディスクへのアクセスに使用します. FreeBSD は起動時に BIOS を使用するため, これを正しく取得することは非常に重要なことなのです. 実際に, ディスク上に複数のオペレーティングシステムがある場合は, ジオメトリはどこからでも同じように解釈される必要があります. そうしないと, 起動時に深刻な問題が発生します. SCSI ディスクでは, 使用するジオメトリはコントローラの拡張 BIOS トランスレーション(>1GB の DOS ディスクドライブのサポート とも呼ばれます)が有効になっているかどうかによります. 無効になっている場合, N シリンダ, 64 ヘッド, 32 セクタ/トラックを使用しますが, ここで `N' は MB 単位のディスク容量です. 例えば, 2GB ディスクは見かけ上 2048 シリンダ, 64 ヘッド, 32 セクタ/トラックとなります. それが「有効」になっており(MS-DOS ではこの方法で, ある制限を回避する場合もあります), ディスク容量が 1GB を越える場合は, M シリンダ, 63 セクタ/トラック (64 「ではなく」), 255 ヘッドを使用します. `M' は MB 単位のディスク容量を 7.844238(!) で割った値となります. ということで, 2GB ディスクの例では, 261 シリンダ, 63 セクタ/トラック, 255 ヘッドとなります. (訳注: 以上は Adaptec 社と NCR 社製の SCSI アダプタの場合です. SCSI アダプタによって変換の数値が変わってくるのでマニュアルを 参照してください.) これについてよく分からない場合や FreeBSD がインストール中に正しくジオメトリを取得できない場合, これを回避するもっとも簡単な方法は, ディスクに小さな DOS パーティションを作ることです. そうすると正しいジオメトリが取得されるはずです(そして, 残しておきたくないとか, ネットワークカードのプログラミング用に使いたい場合などには, いつでもパーティションエディタで DOS パーティションを削除することができます). もう一つの方法として, FreeBSD と一緒にに配布されているフリーで使えるユーティリティに pfdisk.exe (FreeBSD CD-ROM の tools ディレクトリや, 他のさまざまな FTP サイトにあります)と呼ばれるものがあり, ディスク上の他のオペレーティングシステムが使用している ジオメトリを調べるのに役立ちます. このジオメトリ情報は, パーティションエディタに入力することができます. ディスクの分割の仕方で何か制限はありますか? はい. BIOS がカーネルを起動できるようにルートパーティションが 1024 シリンダ以内にあることを確認する必要があります(これは FreeBSD ではなく PC の BIOS の制限です). SCSI ドライブでは, 通常はルートパーティションが最初の 1024MB に収まっていることが前提となります(または拡張 BIOS トランスレーションが有効になっている場合は最初の 4096MB - 他の質問をご覧ください). IDE でそれに相当する値は 504MB となります(訳注: E-IDE 対応の BIOS 搭載マシンの場合は IDE の 504MB という制限はありません). 大容量ディスクを持っていますが, ディスクマネージャは使えますか? FreeBSD は Ontrack Disk Manager を認識し, これを考慮にいれます. 他のディスクマネージャはサポートしません. ディスク全体を FreeBSD で使いたい場合, ディスクマネージャは必要ありません. BIOS が扱える容量(通常 504MB)いっぱいでディスクの設定を行なうと, FreeBSD は実際の容量を算出するはずです. MFM コントローラ付きの古いディスクを使っている場合は, FreeBSD に使用するシリンダ数を詳細に指定する必要があります. FreeBSD と他のオペレーティングシステムが入っているディスクを使用したい場合は, ディスクマネージャなしでもできるでしょう. FreeBSD の起動パーティションと他のオペレーティングシステム用のスライスが, 最初の 1024 シリンダ内に収まっている事を確認するだけです. 気になる方は, 起動パーティションを 20 メガバイトぐらいにして大きめにするととよいでしょう. FreeBSD の起動時に Missing Operating System と表示されます これは FreeBSD や DOS, そのほかの OS がディスク領域ジオメトリ のとらえ方で衝突しあっていることから起こる典型的な例です. こうなったら FreeBSD をインストールし直す以外にはありませんが, 他のところで説明した手順にしたがってやれば, ほぼ間違いなくうまくいくはずです. ブートマネージャの F? プロンプトが表示されません. これはすでに前に質問されている問題のもう一つの症状です. BIOS のジオメトリと FreeBSD のジオメトリ設定が一致していないのです! コントローラや BIOS がシリンダの変換(>1GB ドライブの サポートとも呼ばれます)をサポートしていたら, その設定を無効化して FreeBSD をインストールし直してみてください. ソースを全部インストールする必要はありますか? 一般的には「いいえ」です. しかし最低でも, base ソースキット(これにはこの FAQ で述べられているファイルのいくつかが含まれています)と, sys (kernel) ソースキット(これにはカーネルのソースが含まれています) をインストールする事を強くおすすめします. 通常, 何かの実行にソースが必要になる事はありません. しかし, カーネルをコンフィグレーションするためのプログラム &man.config.8; を実行する時は例外です. カーネルのソースをインストールしなくてもよい例として, どこか別の場所からカーネルのソースを読み込み専用で NFS マウントすることができます. また, そこから新しいバイナリを作成できるようにもなっています. (カーネルソースの制限があるので, 直接 /usr/src をマウントする事はおすすめできません. それよりもどこか別のディレクトリにマウントして, ソースツリーの複製ができるように適切にシンボリックリンクを張ってください.) ソースをネットワーク上に持ち, そこからシステムをビルドするようにしておけば, FreeBSD の将来のリリースへのアップグレードがずっと簡単になります. 実際にソースのサブセットを選択するには, システムインストールツールの「配布ファイル」メニューにある, 「カスタム」メニューを使用します. カーネルは必ず作り直さなくちゃならないんですか? カーネルを新しく作り直すのは元々, FreeBSD のインストール時に必須の作業でした. でも最近のリリースでは, とてもユーザフレンドリなカーネル設定ツールの恩恵を受けています. FreeBSD の起動プロンプト (boot:) で とタイプすればビジュアルな設定画面になり, ほとんどの一般的な ISA カードについてのカーネルの設定をすることができるのです. 今でも, 必要なデバイスドライバだけを組み込んだカーネルを作ることはよい事とされています. ほんのちょっとだけメモリを節約できますからね. でもほとんどのシステムでは, もはやどうしてもやらなくちゃならないことではないのです. DES と MD5, どちらのパスワードを使うべきなのでしょうか? また, ユーザがどちらを使うことになるか指定する方法はありますか? FreeBSD の標準のパスワードフォーマットは MD5 を使ったものです. これは DES アルゴリズムに基づいた手法を用いる UNIX の伝統的なパスワードフォーマットより安全 (secure) だと 信じられているものです. DES パスワードは あなたが FreeBSD のパスワードファイルを, 安全性に劣るパスワードフォーマットを利用している古い OS と共有しなければならなくなったときのために 利用可能になっています (これは利用するためには, sysinstall から crypto 配布物のインストール 選ぶか, ソースから build しているなら, crypto のソースがインストールされている必要があります). 新しいパスワードにどちらのパスワードフォーマットを使うかは /etc/login.conf の中の passwd_format という login ケーパビリティで制御されます. このケーパビリティは des (利用できるなら) か md5 のどちらかの値を取ります. login ケーパビリティの詳細については login.conf(5) を 参照してください|あ!|. ブートフロッピーで起動すると, Probing Devices... の画面でハングアップします. IDE Zip か Jaz ドライブが接続されていたら, それを取り外してもう一度試してみましょう. ブートフロッピーはこの種のドライブを誤認してしまうのです. システムがインストールされた後は, そのドライブを再度接続することができます. うまくいけばこの問題は将来のリリースで解決されるでしょう. インストール終了後にシステムを再起動すると, panic: cant mount root のエラーとなります. このエラーはディスクデバイスについて, 起動ブロックとカーネルの認識が混乱しているために起こります. このエラーは通常, 2 台の IDE ディスクがそれぞれ別の IDE コントローラのマスターに一つずつ接続されているシステムにおいて, FreeBSD がセカンダリ IDE コントローラに接続されたディスクにインストールされている場合に発生します. 起動ブロックは FreeBSD が wd1(2 台目の BIOS ディスク)にインストール されていると認識するのに対し, カーネルはセカンダリ IDE の 1 台目のハードディスクである wd2 にインストールされていると認識するのです. デバイス検出後で, カーネルは起動ブロックが起動ディスクだと認識したディスクである wd1 をマウントしようとします. しかし, 実際には起動ディスクは wd2 なので失敗してしまうのです. この問題を解決するには, 以下のどれか一つを行ってください. FreeBSD 3.3 以降を利用している場合には, システムを再起動して, Booting kernel in 10 seconds; hit [Enter] to interrupt が表示されている間に Enter キーを押します. すると, ブートローダに移行します. そうしたら, set root_disk_unit="disk_number" と入力します. FreeBSD が最初の IDE コントローラのマスターに接続されたドライブにインストールされていれば, disk_number は 0 です. また, 最初の IDE コントローラのスレーブなら 1, 二番目のIDE コントローラのマスターなら 2, 二番目のIDE コントローラのスレーブなら 3 になります. その後, boot と入力します. システムはきちんと再起動するはずです. この変更を恒久的なものにする(つまり, 再起動や電源を入れる度にこの操作する必要がないようにする)には, /boot/loader.conf.local に root_disk_unit="disk_number" という行を追加してください. FreeBSD 3.2 以前を利用している場合は, Boot: プロンプトで 1:wd(2,a)kernel と入力してエンターキーを押します. システムが起動したら, echo "1:wd(2,a)kernel" > /boot.config というコマンドを実行してこれをデフォルトのブート文字列とします. FreeBSD のディスクをプライマリ IDE コントローラに接続して, ハードディスクが連続したドライブ番号で認識されるようにします. カーネルのコンフィグレーションファイルで wd の行を以下のように変更し, カーネルの再構築を行って, 新しいカーネルをインストールします. controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr disk wd0 at wdc0 drive 0 # disk wd1 at wdc0 drive 1 # この行をコメントアウト controller wdc1 at isa? port "IO_WD2" bio irq 15 vector wdintr disk wd1 at wdc1 drive 0 # wd2 から wd1 へ変更 disk wd2 at wdc1 drive 1 # wd3 から wd2 へ変更 ディスクの接続を変更して元の設定に戻したい場合は, ディスクを お望みの設定の通りの接続に戻してから再起動します. システムは正常に起動するはずです. メモリの大きさの制限は? 認識できるメモリの上限は, 4GB です. この構成は試験済みで, 詳細は wcarchive's configuration をご覧ください. このようにたくさんのメモリをマシンに導入しようという場合には, 注意が必要です. ECC 機能をサポートし, なおかつ 容量性負荷(訳注: 多くのメモリ素子は容量性負荷として働きますが, メモリバス上に容量性負荷が増えると信号の伝達が遅れ, 誤動作の原因となります)を 低減させるため, 18 チップ構成のメモリモジュールより 9 チップ構成のメモリモジュールを選択することが, おそらく望ましいでしょう. ffs ファイルシステムの大きさの制限は? ffs ファイルシステムの場合, 論理的な最大の上限は 8 TB(2G ブロック), デフォルトのブロックサイズを 8K とすると 16 TBとなります. 実際問題として, 1 TB のソフトウェアの限界がありますが, 修正すれば 4 TB のファイルシステムが可能です(実際に存在します). 一つの ffs のファイルの最大のサイズは, ブロックサイズが 4K の場合で 約 1G ブロック(4 TB)です. 最大ファイルサイズ fs ブロックサイズ 2.2.7-stable 3.0-current 動作確認済みのサイズ 動作するはずのサイズ 4K 4T-1 4T-1 4T-1 4+t 8K 32+G 8T-1 32+G 32T-1 16K 128+G 16T-1 128+G 32T-1 32K 512+G 32T-1 512+G 64T-1 64K 2048+G 64T-1 2048+G 128T-1
fs ブロックサイズが 4K の場合は三重間接ブロックが使用され, いずれの場合でも三重間接ブロックを使用して表現できる最大の fs ブロック番号 (およそ 1K^3 + 1K^2 + 1K) に制限されるはずなのですが, 実際は fs ブロック番号の (間違った) 上限 1G-1 で制限されます. fs ブロック番号の制限は 2G-1 となるはずです. 2G-1 付近に fs ブロック番号のバグが多少ありますが, fs ブロックサイズが 4K の場合は, ここまでのブロック番号には到達しません. ブロックサイズが 8K 以上の場合, いずれの場合も fs ブロック番号の上限 2G-1 で制限されるはずですが, 実際は fs ブロック番号の上限 1G-1 で制限されます. 例外的に -STABLE では三重間接ブロックまでは到達しないため, 制限は二重間接ブロックで表現できる最大の fs ブロック番号 (およそ (blocksize/4)^2 + (blocksize/4)) となります. -CURRENT ではこの制限を超えると問題を引き起こすかもしれません. 正しい制限値である 2G-1 ブロックを使用すると明らかに問題が出ます. フロッピーに 1 TB のファイルを格納するには? 寄稿: Bruce Evans, 1998 年 9 月 わたしのところでは, フロッピーにいくつかの実際のファイルを保存しています :-). 最大のファイルサイズは最大のディスクサイズとはあまり関係はありません. 最大のディスクサイズは 1 TB です. ファイルサイズがディスクサイズより大きくなりうるというのは仕様です. 以下の例は, 32K のディスク容量(3 つの間接ブロックと 1 つのデータブロック)を使って, 小さなルートパーティションに 8T-1 の大きさのファイルを作成します. ここでの dd コマンドは大きなファイルが扱えるものが必要です. &prompt.user; cat foo df . dd if=/dev/zero of=z bs=1 seek=`echo 2^43 - 2 | bc` count=1 ls -l z du z df . &prompt.user; sh foo Filesystem 1024-blocks Used Avail Capacity Mounted on /dev/da0a 64479 27702 31619 47% / 1+0 records in 1+0 records out 1 bytes transferred in 0.000187 secs (5346 bytes/sec) -rw-r--r-- 1 bde bin 8796093022207 Sep 7 16:04 z 32 z Filesystem 1024-blocks Used Avail Capacity Mounted on /dev/da0a 64479 27734 31587 47% / 新しいカーネルをコンパイルしたら, 起動時に archsw.readin.failed というエラーメッセージが表示されるようになってしまいました. ローダがスタートする前の | が表示されているときに何かキーを押すことで, 起動のセカンドステージから直接, 起動するカーネルを指定して起動することができます. 特に, カーネルのソースを更新し, make world しないで新しいカーネルだけインストールした場合にこの症状が現われます. こういう操作は動作が保証されません. きちんと make world してください. 3.X から 4.X にアップグレードするにはどうしたら良いのですか? アップグレードには, バイナリスナップショットを使うことを強くおすすめします. 4-STABLE スナップショットは releng4.FreeBSD.org から入手可能です. ソースを使ってアップグレードする場合は, 詳細について FreeBSD ハンドブックを参照するようにしてください. ソースを使ったアップグレードは, 慣れていないユーザにはまったくおすすめできません. 3.X -> 4.X の場合は特にそうです. ソースを使ったアップグレードを試す前に, 手順を注意深く読むように心がけてください. ハードウェアコンパチビリティ 訳: にしか nishika@cheerful.com, 1997 年 11 月 12 日. FreeBSD は, どんなハードディスクドライブをサポートしているのですか? FreeBSD は, EIDE と SCSI ハードディスクドライブをサポートしています(互換コントローラも含みます. 次の節参照). また独自の Western Digital インタフェースを使用しているすべてのドライブ(MFM, RLL, ESDI, もちろん IDE)もサポートしています. 独自仕様のインタフェースを使用する ESDI コントローラでは動作しないものがあり, WD1002/3/6/7 とその互換インタフェースと衝突します. どの SCSI コントローラをサポートしているのですか? FreeBSD ハンドブックに記されている完全なリストを参照してください. どんな CD-ROM ドライブをサポートしているのですか? サポートされている SCSI コントローラに接続できる SCSI ドライブは, すべてサポートされています. また, 以下の専用 CD-ROM インタフェースもサポートしています. ミツミ LU002(8bit), LU005(16bit) および FX001D(16bit 2倍速). ソニー CDU 31/33A Sound Blaster 非 SCSI タイプの CD-ROM 松下/Panasonic CD-ROM ATAPI 互換の IDE CD-ROM SCSI でないカードはすべて, SCSI ドライブよりも極めて動作速度が 遅いことが知られており, ATAPI CD-ROM には動作しないものもあるようです. BSDi の FreeBSD 2.2 CD-ROM からは CD からの直接起動が サポートされています. ZIP ドライブをサポートしていますか? もちろん, FreeBSD は SCSI ZIP ドライブ(外付け)をサポートしています. ZIP ドライブは SCSI ID を 5 か 6 に設定した状態でなら使用できますが, もし SCSI ホストアダプタの BIOS がサポートしてさえいれば ZIP ドライブから起動させることもできます. 私はどのホストアダプタが SCSI ID を 0 や 1 以外に設定したデバイスから起動できるのか知りませんが... ドキュメントを参照してください(うまくいった場合は教えてください). ATAPI(IDE) ZIP ドライブは, FreeBSD 2.2.6 以降のバージョンでサポートされています. バージョン 3.0 以降の FreeBSD では, パラレルポート接続の ZIP ドライブをサポートしています. 最近のバージョンの FreeBSD をお使いでしたら, カーネルコンフィグレーションファイルに scbus0, da0, ppbus0, vp0 の各ドライバが記述されていることを確認してください. (GENERIC カーネルには vp0 を除くすべてのドライバが含まれています). これらすべてのドライバがあれば, パラレルポートのドライブは /dev/da0s4 となります. ディスクは mount /dev/da0s4 /mnt とするか mount_msdos /dev/da0s4 /mnt (DOS ディスクの場合) とすることでマウントできます. それからリムーバブルドライブに関する注意および, 「フォーマット」に関する注意についても 確認しておいてください. では, JAZ や EZ, それからその他のリムーバブルドライブはサポートしていますか? FreeBSD では, IDE バージョンの EZ ドライブを除くすべての SCSI デバイスは, SCSI のディスクと同等に扱われます. また IDE EZ は IDE ドライブと同等となります. システム稼働中のメディア交換について FreeBSD がどれほどうまく動くか定かではありません. もちろんメディアを入れ替える前にそのドライブのマウントを解除しなければいけないでしょうし, FreeBSD がそれらを認識するには, 起動時に外部ユニットにも電源が投入されていることを確認しなければいけないでしょう. 「フォーマット」に関する注意も参照のこと. どのマルチポートシリアルカードをサポートしていますか? 一覧は その他のデバイスの節にあります. 無名のカードにもうまく動くものがあり, 特に AST 互換といわれているものに多く見られます. カード設定の詳細な情報は, &man.sio.4; のマニュアルページを参照してください. USB キーボードを持っているのですが, FreeBSD で使えますか? USB デバイスは FreeBSD 3.1 からサポートされましたが, 実装は FreeBSD 3.2 であってもまだ完全ではないため, 必ずしも安定して動作するとは限りません. もし, それでも USB キーボードを使ってみたいという人は, 以下の手順を試してみてください. FreeBSD 3.2 か, それ以降を使います. カーネルコンフィグレーションファイルに以下の行を追加し, カーネルを再構築します. device uhci device ohci device usb device ukbd options KBD_INSTALL_CDEV FreeBSD 4.0 より前のバージョンでは, 代わりに次のようにします. controller uhci0 controller ohci0 controller usb0 controller ukbd0 options KBD_INSTALL_CDEV /dev ディレクトリに移動し, 次のようにしてデバイスノードを作成します. &prompt.root; cd /dev &prompt.root; ./MAKEDEV kbd0 kbd1 /etc/rc.conf を編集し, 以下の行を追加します. usbd_enable="YES" usbd_flags="" システムを再起動させた後, AT, USB 両方のキーボードが接続されていれば, AT キーボードは /dev/kbd0 に, USB キーボードは /dev/kbd1になります. 一方, USB キーボードだけが接続されているなら, /dev/ukbd0 となります. USB キーボードをコンソールで利用するには, それをコンソールドライバに対して明示的に指定する必要があります. システムの初期化の際に, 次に示すようなコマンドを実行してください. &prompt.root; kbdcontrol -k /dev/kbd1 < /dev/ttyv0 > /dev/null ただし, USB キーボードしか接続されていない場合, それは /dev/kbd0 としてアクセスされますので, コマンドは次のようにしなければなりません. ご注意ください. &prompt.root; kbdcontrol -k /dev/kbd0 < /dev/ttyv0 > /dev/null 上のコマンドは, /etc/rc.i386 に追加すると良いでしょう. この設定を一度行なっていれば, X 環境でも特に他の設定なしに USB キーボードが利用できます. USB キーボードの活線挿抜(ホットプラグ機能)は, まだおそらくきちんと動作しないと思われます. トラブルを避けるためにも, キーボードはシステムを起動させる前に接続しておき, シャットダウンするまではずさないようにした方が良いでしょう. 詳細については, &man.ukbd.4; のマニュアルページを参照してください. 珍しいバスマウスを持っているのですが, どのように設定すればいいのですか? FreeBSD は Microsoft, Logitech, ATI 等のメーカーから出ているバスマウスと InPort バスマウスをサポートしています. FreeBSD 2.X の場合, バスマウスのデバイスドライバは GENERIC カーネルに標準で含まれますが, FreeBSD 3.X 以降では標準で含まれていません. もしバスマウスのデバイス ドライバを含むカーネルを自分で構築する場合には, カーネルコンフィグレーションファイルに以下の行が含まれていることを確認してください. それは FreeBSD 3.0 を含む, それ以前のリリースの場合は次のとおり, device mse0 at isa? port 0x23c tty irq5 vector mseintr FreeBSD 3.X では, 次のとおりです. device mse0 at isa? port 0x23c tty irq5 そして FreeBSD 4.X とそれ以降では, 次のようになります. device mse0 at isa? port 0x23c irq5 通常バスマウスには専用のインタフェースカードが附属しています. インタフェースカードによってはポートアドレスや割り込み番号を上記の 設定以外に変更できるかもしれません. 詳しくはバスマウスのマニュアルと &man.mse.4; のマニュアルページを参照してください. PS/2 マウス(「マウスポートマウス」, 「キーボードマウス」)を 使うにはどのように設定すればいいのですか? あなたが 2.2.5 以降のバージョン FreeBSD を使っているのなら, 必要なドライバ psm はカーネルに含まれていて有効になっています. カーネルは起動時に PS/2 マウスを検出するでしょう. あなたの使っている FreeBSD が比較的新しいけれど前のバージョン(2.1.x 以降)のものなら, インストールの時に, 単にカーネルのコンフィグレーションのメニュー上で PS/2 マウスを有効化するだけです, あるいは後で boot: プロンプト上で を指定することでもメニューは現れます. デフォルトでは無効に設定されていますので, 明示的に有効化してあげないといけません. あなたの使っている FreeBSD が比較的古いものなら, カーネルコンフィグレーションファイルに以下の行を加えて カーネルを再コンパイルする必要があります. それは FreeBSD 3.0 を含む, それ以前のリリースでは次のとおり, device psm0 at isa? port "IO_KBD" conflicts tty irq 12 vector psmintr FreeBSD 3.1 を含む, それ以降のリリースでは次のとおり, device psm0 at isa? tty irq 12 FreeBSD 4.0 とそれ以降のリリースでは次のとおりです. device psm0 at atkbdc? irq 12 カーネルの再構築についてよく知らないのであれば, カーネルのコンフィグレーションを参照してください. 起動時にカーネルが psm0 を検出したら, psm0 のエントリが /dev の中にあることを確認してください. それには, 以下のようにします. &prompt.root; cd /dev; sh MAKEDEV psm0 これは root でログインしているときに行なってください. X Window System 以外の環境でマウスを使うことは可能ですか? もしデフォルトのコンソールドライバである syscons を使っているのであれば, テキストコンソール上でマウスを使って, テキストのカットアンドペーストができます. マウスデーモンである moused を起動し, 仮想コンソールでマウスポインタを有効にしてください. &prompt.root; moused -p /dev/xxxx -t yyyy &prompt.root; vidcontrol -m on ここで xxxx はマウスのデバイス名, yyyy はマウスのプロトコルタイプです. サポートされているプロトコルタイプについては &man.moused.8; のマニュアルページを参照してください. システムを起動する時に自動的に moused を起動したい場合には, 次のようにします. FreeBSD 2.2.1 では以下の変数を /etc/sysconfig で設定してください. mousedtype="yyyy" mousedport="xxxx" mousedflags="" FreeBSD 2.2.2 以降のバージョンでは /etc/rc.conf で以下のように設定します. moused_type="yyyy" moused_port="xxxx" moused_flags="" FreeBSD 3.1 とそれ以降で PS/2 マウスを利用する場合は, moused_enable="YES" を /etc/rc.conf に書き加えるだけです. また, 起動時にすべての仮想端末で, 標準のコンソールに加えマウスデーモンも使えるようにしたい, という場合には, 以下の行を /etc/rc.conf に加えます. allscreens_flags="-m on" FreeBSD 2.2.6 以降の場合で 比較的新しいシリアルマウスを使っているならば, マウスデーモンはマウスのプロトコルタイプを自動判別できます. 自動判別を試みるには, プロトコルタイプとして auto を指定します. マウスデーモンを実行中は, マウスデーモンと他のプログラム(例えば X Window System)の間でマウスへのアクセスを調整しなければなりません. この問題については X とマウスをご覧ください. マウスを使って, テキストコンソールでカットアンドペーストするにはどうしたらよいのですか? マウスデーモンを起動 (前の質問に対する答えを参照してください) したあと, ボタン 1(左ボタン)を押しながらマウスを動かして範囲を指定します. ボタン 2(中ボタン)またはボタン 3(右ボタン)をクリックするとテキスト カーソルの位置に選択した範囲のテキストがペーストされます. FreeBSD 2.2.6 以降では, ボタン 2 をクリックするとペーストされ, ボタン 3 をクリックした場合に既存の選択範囲が現在のマウスポインタの位置まで 「延長または短縮」されます. もしマウスに中ボタンがないなら, moused のオプションを使って中ボタンのエミュレーションをするか, 他のボタンを中ボタンとして使う事ができます. 詳しくは &man.moused.8; のマニュアルページを参照してください. USB マウスを持っているのですが, FreeBSD で使えますか? USB デバイスは FreeBSD 3.1 からサポートされましたが, 実装は FreeBSD 3.2 であってもまだ完全ではないため, 必ずしも安定して動作するとは限りません. もし, それでも USB マウスを使ってみたいという人は, 以下の手順を試してみてください. FreeBSD 3.2 か, それ以降を使います. カーネルコンフィグレーションファイルに以下の行を追加し, カーネルを再構築します. device uhci device ohci device usb device ums FreeBSD 4.0 より前のバージョンでは, 代わりに次のようにします. controller uhci0 controller ohci0 controller usb0 device ums0 /dev ディレクトリに移動し, 次のようにしてデバイスノードを作成します. &prompt.root; cd /dev &prompt.root; ./MAKEDEV ums0 /etc/rc.conf を編集し, 以下の行を追加します. moused_enable="YES" moused_type="auto" moused_port="/dev/ums0" moused_flags="" usbd_enable="YES" usbd_flags="" moused の設定の詳細については, 前項も参照してください. X のセッションで USB マウスを使うには, XF86Config を編集する必要があります. XFree86 3.3.2, もしくはそれ以降を利用している場合は, Pointer セクションが次のようになっていることを確認してください. Device "/dev/sysmouse" Protocol "Auto" それより前のバージョンの XFree86 を利用している場合は, Pointer セクションが次のようになっていることを確認してください. Device "/dev/sysmouse" Protocol "SysMouse" X 環境でのマウスの利用については, 他の項も参照してください. USB マウスの活線挿抜(ホットプラグ機能)は, まだおそらくきちんと動作しないと思われます. トラブルを避けるためにも, マウスはシステムを起動させる前に接続しておき, シャットダウンするまではずさないようにした方が良いでしょう. わたしのマウスにはホイール機能や便利なボタンがついているのですが, これは FreeBSD でも使えるのですか? 答えは残念ながら「場合によります」です. こうしたマウスの付加的な機能は大抵の場合, 特殊なドライバを必要とします. マウスのデバイスドライバやユーザのプログラムが そのマウスに対する固有のサポートをしていない場合には, 標準的な 2 ボタン/3 ボタンマウスのように振舞います. X ウィンドウシステムの環境でのホイールの使い方については, X とホイールの項をご覧ください. わたしのマウスはきちんと動いてくれないようです. マウスカーソルが画面中をとびまわります. このマウスにはホイールがついていて, 接続は PS/2 ポートです. FreeBSD 3.2 およびそれ以前の PS/2 マウスドライバ psm には, Logitech モデル M-S48 とその OEM のホイールマウスで不具合が発生します. 以下のパッチを /sys/i386/isa/psm.c に適用して, カーネルを再構築してください. Index: psm.c =================================================================== RCS file: /src/CVS/src/sys/i386/isa/Attic/psm.c,v retrieving revision 1.60.2.1 retrieving revision 1.60.2.2 diff -u -r1.60.2.1 -r1.60.2.2 --- psm.c 1999/06/03 12:41:13 1.60.2.1 +++ psm.c 1999/07/12 13:40:52 1.60.2.2 @@ -959,14 +959,28 @@ sc->mode.packetsize = vendortype[i].packetsize; /* set mouse parameters */ +#if 0 + /* + * A version of Logitech FirstMouse+ won't report wheel movement, + * if SET_DEFAULTS is sent... Don't use this command. + * This fix was found by Takashi Nishida. + */ i = send_aux_command(sc->kbdc, PSMC_SET_DEFAULTS); if (verbose >= 2) printf("psm%d: SET_DEFAULTS return code:%04x\n", unit, i); +#endif if (sc->config & PSM_CONFIG_RESOLUTION) { sc->mode.resolution = set_mouse_resolution(sc->kbdc, - (sc->config & PSM_CONFIG_RESOLUTION) - 1); + (sc->config & PSM_CONFIG_RESOLUTION) - 1); + } else if (sc->mode.resolution >= 0) { + sc->mode.resolution + = set_mouse_resolution(sc->kbdc, sc->dflt_mode.resolution); + } + if (sc->mode.rate > 0) { + sc->mode.rate = set_mouse_sampling_rate(sc->kbdc, sc->dflt_mode.rate); } + set_mouse_scaling(sc->kbdc, 1); /* request a data packet and extract sync. bits */ if (get_mouse_status(sc->kbdc, stat, 1, 3) < 3) { FreeBSD 3.2 より新しいリリースではきちんと動作するはずです. ラップトップ PC のマウス/トラックボール/タッチパッドは使えますか? 前の質問に対する答えと, モバイルコンピューティングのページをご覧ください. どんなテープドライブをサポートしていますか? FreeBSD は SCSI と QIC-36 (QIC-02 インタフェース付き) をサポートしています. これらには 8-mm (Exabyte と呼ばれています) や DAT ドライブも含まれています. 初期の 8-mm ドライブの中には SCSI-2 とまったく互換性を持たないものがあります. これらは FreeBSD 上では動作しません. どんなテープチェンジャーをサポートしていますか? FreeBSD 2.2 は ch(4) デバイスと chio(1) コマンドを使用した SCSI チェンジャーをサポートしています. 実際のチェンジャーの制御方法の詳細は, chio(1) のマニュアルページを参照してください. 使用している製品が AMANDA のようにチェンジャーに対応済みのものでない場合は, 次のことについて留意してください. それらの製品は任意のポイント間のテープの移動を制御するだけなので, テープがどのスロットに入っているか, 現在ドライブにあるテープが どのスロットに戻るべきかを把握しておく必要があります. どんなサウンドカードをサポートしていますか? FreeBSD は SoundBlaster, SoundBlaster Pro, SoundBlaster 16, Pro Audio Spectrum 16, AdLib それから Gravis UltraSound サウンドカードを サポートしています. MPU-401 やその互換カードも機能に制限はあるものの サポートされています. マイクロソフトサウンドシステムのスペックに準拠 したカードも, pcm ドライバでサポートされています. これらはサウンドについてのみの話です! これらのドライバは CD-ROM, SCSI, カード上にあるジョイスティックをサポートしていません (SoundBlaster は例外です). SoundBlaster SCSI インタフェースと非 SCSI CD-ROM はサポートしていますが, そのデバイスからは起動できません. pcm ドライバで es1370 から音が出ないのはどうにかなりませんか? マシンを起動するごとに以下のコマンドを実行してください. &prompt.root; mixer pcm 100 vol 100 cd 100 どんなネットワークカードをサポートしていますか? より完全な一覧についてはイーサネットカードの節を参照してください. 数値演算コプロセッサを持っていませんが, 何かまずいでしょうか? これらは 386/486SX/486SLC を持っている場合に影響します - ほかのマシンでは CPU に内蔵されています. 一般にこれらは問題とはなりません. しかし, 数値演算エミュレーションコードのパフォーマンスか, 正確さのいずれかを選択する状況があります(詳しくは FP エミュレーション についての節をご覧ください). とくに, X 上で弧を描く際にとても遅くなることでしょう. 数値演算コプロセッサを購入されることを強くおすすめします. とても役立つことでしょう. 他の数値演算コプロセッサよりも優れたコプロセッサもあります. これは言いにくいことなのですが, Intel を買うために躍起になる人もいないでしょう. それが FreeBSD 上で動くという確信がないのなら, クローンにご用心を. FreeBSD がサポートするデバイスは他にもあるんでしょうか? FreeBSD ハンドブックに記されている, サポートされている他のデバイスの一覧を参照してください. パワーマネージメント機能付きのラップトップ PC を持っているのですが... FreeBSD は一部のマシンの APM をサポートしています. LINT カーネルコンフィグファイル の APM の部分をご覧ください. Micron システムが起動時に固まってしまいます. 特定の Micron 製のマザーボードの中には, PCI BIOS が規格通りに 実装されていないために FreeBSD の起動に失敗するものがあります. その BIOS は, PCI デバイスをあるアドレスで設定したと報告するにも 関わらず, 実際にはそうしていないのです. この問題を回避するには, BIOS の Plug and Play Operating System を無効に設定してください. また, より詳しい情報は http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html#micron を参照してください. 新しい Adaptec コントローラを持っているのですが, FreeBSD が検出できないようです. 新しい AIC789x シリーズの Adaptec チップは, 3.0 でデビューした CAM SCSI フレームワークでサポートされています. 2.2-STABLE のパッチは ftp://ftp.FreeBSD.org/pub/FreeBSD/development/cam/ にあります. CAM システムが入っている高機能ブートフロッピーは http://people.FreeBSD.org/~abial/cam-boot/ にあります. どちらの場合にしても, 作業を始める前に README をお読みください. 内蔵の Plug & Play モデムを持っているのですが, FreeBSD が検出できないようです. モデムの PnP ID を シリアルドライバの PnP ID リストに追加する必要があるでしょう. Plug & Play サポートを有効にするには, controller pnp0 をコンフィグレーション ファイルに付け加え, 新しいカーネルをコンパイルしてシステムを再起動してください. カーネルは, 検出した全てのデバイスの PnP ID を表示します. モデムの欄にある PnP ID を /sys/i386/isa/sio.c の 2777 行目くらいにあるテーブルに書き入れてください. テーブルを見つけるには, 構造体 siopnp_ids[] の文字列 SUP1310 を探します. カーネルを作り直したらインストールし, システムを再起動してください. そうすれば, モデムが検出されるはずです. 起動時のコンフィグレーションの際に, pnp コマンドを使用して PnP の設定をマニュアルで行なわなければならないかもしれません. その場合, モデムを検出させるためのコマンドは pnp 1 0 enable os irq0 3 drq0 0 port0 0x2f8 のようになります. シリアルコンソールで boot: プロンプトを表示するにはどうすればいい? options COMCONSOLE を指定してカーネルを構築してください. そして /boot.config を作成して とだけ書き入れてください. その後, キーボードをシステムから抜きます. /usr/src/sys/i386/boot/biosboot/README.serial に, これに関する情報が書かれています. なぜ Micron コンピュータで 3Com PCI ネットワークカードが動かないのでしょう? 特定の Micron 製のマザーボードの中には, PCI BIOS が規格通りに 実装されていないために FreeBSD の起動に失敗するものがあります. その BIOS は, PCI デバイスをあるアドレスで設定したと報告するにも 関わらず, 実際にはそうしていないのです. この問題を回避するには, BIOS の Plug and Play Operating System を無効に設定してください. また, より詳しい情報は http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html#micron を参照してください. 対称型マルチプロセシング(SMP)をサポートしていますか? SMP は, 3.0-STABLE とそれ以降のリリースでのみサポートされています. GENERIC カーネルでは SMP は有効化されていませんので, SMP を有効化するにはカーネルを再構築する必要があります. /sys/i386/conf/LINT を見て, カーネルコンフィグファイルにどのオプションを追加すれば良いのか確かめてください. ASUS K7V マザーボードのシステムでブートフロッピーを使うと, システムがハングアップします. 対応策はありませんか? BIOS セットアップで起動時のウィルス保護機能を無効化してください. トラブルシューティング 訳: &a.jp.yoshiaki;, 1997 年 11 月 10 日. ハードディスクに不良ブロックがあります! SCSI ディスクの場合は自動的に再マップする機能があるはずです. しかし, 理解し難い理由から多くのドライブがこの機能が無効化 されて出荷されています... これを有効化するには, 最初のデバイスのモードページを変更する必要があります. これは次のコマンドを実行することで, FreeBSD 上で行なうことができます(root 権限で行ないます). &prompt.root; scsi -f /dev/rsd0c -m 1 -e -P 3 そして, AWRE と ARRE の値を 0 から 1 へ変更します AWRE (Auto Write Reallocation Enbld): 1 ARRE (Auto Read Reallocation Enbld): 1 以下は, Ted Mittelstaedt 氏から寄せられたものです. IDE ドライブの場合は通常, 不良ブロックは潜在的な障害の兆候です. 最近の IDE ドライブは, 内部の不良ブロック再マッピング機能を有効にした状態で 出荷されています. また, 今日の IDE ハードディスクメーカは, 出荷以降に不良ブロックが発生することに関して保証を提供していて, 不良ブロックのあるディスクドライブを交換するサービスを行なっています. もし, 不良ブロックのある IDE ディスクドライブを復旧しようと思うなら, IDE ドライブメーカが提供する IDE 診断プログラムをダウンロードして, そのドライブに使ってみてください. この種のプログラムは大抵, ドライブの制御部分に対して不良ブロックを再走査し, 不良ブロックを使用不能にするようにセットすることができます. ESDI, RLL および MFM ドライブの場合, 不良ブロックはドライブの正常な部分であり, 一般的に言って障害を表すものではありません. PC では, ディスクドライブコントローラカードと BIOS が不良ブロックの使用不能化の作業を行ないます. DOS など, ディスクアクセスに BIOS を経由する OS にとっては有効に働きますが, FreeBSD のディスクドライバは BIOS を利用しません. そのため, 代替として bad144 という機構が存在します. bad144 は, wd ドライバでだけ (つまり FreeBSD 4.0 ではサポートされていない)動作し, SCSI ドライバに利用することは できません. bad144 は, 検出された不良セクタをスペシャルファイルに記録するという機能を持っています. bad144 を利用する上で, 注意しなければならない点が一つあります. それは, 不良ブロックスペシャルファイルは, ディスクの最終トラックに置かれるということです. このファイルには, ディスクの先頭の付近, /kernel ファイルが位置しているであろう部分で発生した不良セクタが記録されています. したがって, このファイルは BIOS コールを使ってカーネルファイルを読み込む起動プログラムが, アクセス可能でなければなりません. これはつまり, bad144 を利用するディスクは 1024 シリンダ, 16 ヘッド, 63 セクタを超えてはならないということを意味し, bad144 を利用したディスクが実質 500MB を超えられないことになります. bad144 を使うには, FreeBSD のインストール時に表示される fdisk 画面で Bad Block 走査を ON に設定するだけです. これは, FreeBSD 2.2.7 以降で機能します. ディスクは, 1024 シリンダ以内でなければなりません. ディスクドライブは事前に少なくとも 4 時間, ディスクが温度によって膨張し, トラックに曲がりが出るまで回転させることをお薦めします(訳注: 温度変化に対する膨張によって, ディスクが微小変形することにより発生する不良セクタを確実に検出するためです). 大容量の ESDI ドライブのように 1024 シリンダを超えるディスクの場合, DOS 上でそのディスクが利用できるよう, ESDI コントローラは特殊な変換モードを利用します. fdisk の set geometry コマンドを使って 変換された(translated) ジオメトリに切替えると, wd ドライバはこの変換モードを解釈できます. その際, FreeBSD パーティションを作成するのに dangerously dedicated モードを利用してはいけません. このモードは, そのようなジオメトリを無視するからです. たとえ fdisk がオーバーライドされたジオメトリ情報を使ったとしても, 依然としてディスクの真の大きさを保持しているため, 大きすぎる FreeBSD パーティションを作成しようとしてしまうでしょう. ディスクジオメトリ情報が変換されたジオメトリ情報にかわっている場合は, 手動でブロック数を入力し, パーティションを作成する必要があります. 大容量の ESDI ディスクを ESDI コントローラでセットアップするには, ちょっとしたトリックを使います. まず, DOS のディスクで起動して そのディスクを DOS パーティションとしてフォーマットします. そして FreeBSD を起動し, インストーラの fdisk 画面で DOS パーティションのブロックサイズとブロック数を読みとり, メモしておきます. ジオメトリ情報を DOS が利用しているものと同一に再設定し, DOS パーティションを削除して cooperative FreeBSD パーティションを 先程記録したブロックサイズを使って作成してください. そのパーティションを起動可能パーティションに設定し, 不良ブロック走査を 有効にします. 実際のインストールでは, ファイルシステムが作成される前に bad144 が最初に実行されます(Alt-F2 を押すことで状況を確認できます). 不良セクタファイルを作成中に何らかの障害が発生したなら, システムを再起動して, もう一度最初からやり直しになります. おそらくディスクジオメトリ情報の設定を大きくしすぎているのでしょう. (やり直しは, DOS によるフォーマットとパーティション確保を含みます) もし, 不良ブロックの再マッピングを有効にしていて不良ブロックが見付かったら, ドライブの交換を考えてください. 不良ブロックは, 時間とともに悪化するからです. Bustek 742a EISA SCSI が認識されません. この情報は 742a のためのものですが, 他の Buslogic カードについても 同様のことが言えます. (Bustek = Buslogic) 742a カードには大きくわけて 2 つの「バージョン」が存在します. ハードウェアリビジョンの A-G と H 以降です. リビジョンの 文字はカードの隅にあるアセンブリ番号の後ろにあります. 742a は二つの ROM チップを持っており, 一つは BIOS チップで もう一つはファームウェアチップです. FreeBSD はあなたの 持っているものがどの BIOS バージョンかは問題ありませんが, ファームウェアバージョンについては問題となります. Buslogic の技術サポート部門に連絡すれば, アップグレード版の ROM を送ってくれることでしょう. BIOS チップと ファームウェアチップはペアで出荷されます. アダプタカードのハードウェアリビジョンにあわせた 最も新しいファームウェア ROM を使用しなければなりません. リビジョン A-G のカードには, 2.41/2.21 までの BIOS/ファームウェアのセットを使用することができます. リビジョン H 以降のカードには, 最新のものである 4.70/3.37 の BIOS/ファームウェアのセットを 使用することができます. これらのファームウェアの違いは, ファームウェア 3.37 が 「ラウンドロビン方式」 をサポートしているところからきています. Buslogic のカードには, 製造番号も刻印されています. 古い ハードウェアリビジョンのカードを持っている場合は, Buslogic の RMA 部門に問い合わせて製造番号を伝えると, 新しいハードウェアリビジョンの カードに交換することもできます. もしカードが十分新しければ, 彼らは 交換に応じてくれるでしょう. FreeBSD 2.1 は ファームウェアリビジョン 2.21 以降のものをサポートしています. これよりも古いファームウェアリビジョンのものは, Buslogic カードとして正常に認識されません. しかし, Adaptec 1540 として認識されるかもしれません. 初期の Buslogic のファームウェアは AHA1540 「互換」モードを 持っています. しかし, EISA カードにとってこれは よいことではありません. 古いハードウェアリビジョンのカードを持っていてファームウェア 2.21 を入手するのであれば, ジャンパ W1 の位置をデフォルトの A-B から B-C に合わせる必要があるでしょう. HP Netserver 上のオンボード SCSI コントローラが認識されません. 基本的にこれは既知の問題です. HP Netserver マシンの EISA オンボード SCSI コントローラは EISA のスロット番号 11 を占有しますが, 「本当の」EISA スロットはすべてそれよりも前のアドレスに配置されているのです. 残念ながら, 10 番以上の EISA スロットは PCI に割り当てられたアドレス空間と衝突し, FreeBSD の自動コンフィグレーションは, 現状ではうまくこの状況を処理できていないのです. ですから現時点での最良の方法は, カーネルオプションの EISA_SLOTS を 12 に変え, アドレス空間の衝突がないかの ようなふりをさせることです :) カーネルの再構築に記述されているようにしてカーネルを再構築してください. もちろん, これはこのようなマシンにインストールする際に 「卵が先か, 鶏が先か」といった問題を生み出すことになります. この問題を回避するために, ユーザコンフィグ(UserConfig) の中には特別な仕組みが組み込まれています. このとき visual インタフェースは使用せず, コマンドラインインタフェースを使用してください. 単純に eisa 12 quit とプロンプト上から打ち込み, 後は普通にインストールを行なってください. とにかくカスタムカーネルのコンパイルとインストールを行なうことを おすすめします. うまくいけば, 将来のバージョンではこの問題が解決していることでしょう. HP Netserver では危険覚悟の専用ディスクは使用できません. 詳細については この注意事項をご覧ください. この CMD640 IDE コントローラはどこかおかしいようです. それは壊れているのです. 両方のチャンネルを同時に制御できないのです. 現在, このチップを使っているシステムを自動的に検出して, うまく動かすためのしくみが使えるようになっています. くわしくは wd(4) のマニュアルページを参照してください. CMD640 IDE コントローラを使っているシステムで FreeBSD 2.2.1 あるいは 2.2.2 を使い, かつセカンダリのチャネルを使いたいのであれば, options "CMD640" を有効にしてカーネルを作り直してください. FreeBSD 2.2.5 以降では, デフォルトでそうなっています. ed1: timeout のようなメッセージがいつも出ます. たぶん IRQ の衝突が原因でしょう (二つのボードが同じ IRQ を使用しているなど). FreeBSD 2.0.5R 以前はこれに関して寛大で, IRQ の衝突があってもネットワークドライバは機能していました. しかし 2.0.5R 以降はもはや, IRQ の衝突に寛大ではありません. オプションをつけて起動し, ed0/de0/... のエントリをボードの設定に合わせてください. ネットワークカードの BNC - コネクタ(訳注: 10BASE-2 タイプのインターフェース) + コネクタ(訳注: 10BASE-2 タイプのインタフェース) を使っている場合, デバイスのタイムアウトはターミネーションの不良によっても起きます. これをチェックするにはケーブルを外してターミネータを直接 NIC に接続します. そしてエラーメッセージが消えるかどうか 確認します. NE2000 コンパチブルカードのなかには, UTP ポートのリンクがなかったりケーブルが接続されていない場合に このエラーを出すものがあります. CDROM をマウントしようとすると Incorrect super block と言われます. mount にマウントしたいデバイスのタイプを指定する必要があります. デフォルトでは mount(8) はファイルシステムを ufs とみなします. CDROM のファイルシステムを マウントしたいのであれば と mount(8) にオプションをつけて明示する必要があります. これはもちろん CDROM が ISO 9660 ファイルシステムである場合です. ほとんどの CDROM はこの形式です. 1.1R の FreeBSD では (訳注: 2.1.5R, 2.2R でも同様です) 自動的に Rock Ridge 拡張(長いファイル名への対応)をうまく解釈します. CDROM のデバイス /dev/cd0c を /mnt にマウントしたい場合の例では, 次のようにします. &prompt.root; mount -t cd9660 /dev/cd0c /mnt デバイスの名前はインタフェースによっては別の名前になっている かもしれないので注意してください(/dev/cd0c はこの場合の例です). オプション によって mount_cd9660 コマンドが実行されることに注意してください. このため例は次のようにすることもできます. &prompt.root; mount_cd9660 /dev/cd0c /mnt CDROM をマウントしようとすると Device not configured と言われます. これは 一般的に CDROM ドライブの中に CDROM が入っていないか, ドライブがバス上に見えないことを意味します. ドライブに CDROM を入れるか, IDE (ATAPI) であれば master/slave の状態をチェックしてください. また, CDROM ドライブに CDROM を入れてから認識するまでには数秒かかりますので, 少し待ってみてください. SCSI CDROM ではバスリセットへの応答時間が遅いために, 失敗することがあるかもしれません. SCSI CDROM を持っている場合は, カーネルコンフィグレーションファイルに以下の行を加えて 再コンパイルして試してみてください. 訳注 現在の GENERIC カーネルでは上の設定はデフォルトになっています. 問題のある場合は SCSI_DELAY の数値を増やしてみてください. options "SCSI_DELAY=15" 私のプリンタはとてつもなく遅いのです. どうしたらよいのでしょう? パラレルインタフェースで, 問題はとんでもなく遅いだけであるなら, プリンタボートを polled モードに設定してみてください. &prompt.root; lptcontrol -p HP の新しいプリンタには, 割り込みモードで使えないものがあるようです(完全にわかったわけではありませんが). タイミングの問題のように思われます. わたしのプログラムは時々 Signal 11 のエラーで止まってしまいます. Signal 11 エラーはオペレーティングシステムが 許可を与えていないメモリにアクセスしようとしたときに発生します. このようなことがランダムな間隔で起っているようなら, 注意深く調査していった方が良いです. この手の問題はたいていの場合, 以下のどちらかです. その問題が特定の, あなたが自分で開発したアプリケーションでのみ起っているなら, あなたのコードにバグがあるのでしょう. それが FreeBSD のベースシステムの一部と関連する問題なら, コードにバグがあるということになります. しかしほとんどの場合, 普通の FAQ の読者がそのようなコードを使うようになるずっと前に, そういった問題は発見され, 修正されているはずです (それが -current の役目なのですから). それが FreeBSD のバグでは「ない」という決定的なケースとして, その問題の発生がプログラムをコンパイルしているときであり, コンパイル毎に毎回, コンパイラの挙動が変るというものがあります. たとえば, あなたが make buildworld を実行していて, コンパイラが ls.c から ls.o をコンパイルしようとしたときに コンパイルに失敗したとします. もう一度 make buildworld を実行したときに, まったく同じ場所でコンパイルが失敗したのなら, それは build が壊れている (訳注: つまりソースにバグがある) と言うことです -- ソースを更新してやりなおしてみてください. もしコンパイルが別の場所でしくじっていたら, それはハードウェアの問題です. あなたのやるべき事は: 前者の場合は, そのプログラムの間違ったアドレスへアクセスしようとしている部分を, gdb 等のデバッガで見つけて修正します. 後者の場合は, ハードウェアに問題がないことを確かめる必要があります. その一般的な原因として : ハードディスクが熱を持ちすぎているかも知れません: ケースのファンがちゃんと動いていてディスクを冷やしているか 確かめてください (たぶん, 他の部品も過熱しています). CPU がオーバーヒートしています: CPU をオーバークロックしていませんか? さもなければ CPU ファンが死んでいるのかもしれません. いずれにせよ, 少なくとも問題解決の間では ハードウェアが動くべく指定された条件で動かしてください. クロックはデフォルトの設定に戻してください. もしあなたがクロックアップをしているのなら, 遅いシステムでも, システムが焼き付いて 買い換えなければならなくなるよりずっとマシだということを 覚えておいた方が良いでしょう. 大きいコミュニティでは特に, あなたがそれが安全だと思っているかどうかは関係なく, オーバークロックしたシステムに発生した問題には同情的ではありません. 怪しいメモリ: もし複数の SIMM や DIMM を使っているならそれを全部抜いてから 各 SIMM や DIMM を別個に組み込んだシステムを立ち上げてることで どの DIMM/SIMM が怪しいのか, それとも組合わせが悪いのか と問題の幅が狭まります. 楽観的すぎるマザーボードの設定: ほとんどの場合に標準設定で十分なタイミングを, BIOS の設定やマザーボード上のジャンパピンを変えることで, さまざまに変更することができます. しかし時には RAM の アクセスウェイトを低くしすぎたり RAM Speed: Turbo や その手の BIOS の設定でおかしな挙動が起こることがあります. BIOS を標準の設定に戻すというのはいいアイディアですが, その前にあなたの設定を書き留めておいた方がいいでしょう. マザーボードへの電源が安定していない. もし使っていない I/O ボードやハードディスク, CDROM 等があるなら, 一旦それらから電源ケーブルを抜き, 電源が小さな負荷ならなんとか動作するか確認しましょう. あるいは別の電源を試してみましょう. その時はなるべく, 少し容量の大きいもので試しましょう (たとえば, 今の電源容量が 250W だったら 300W のものを試します). SIG11 FAQ (下に示します) にはこれらの問題のすべてが 詳しく説明されています. Linux の視点に基づくものですが, これも読んでおいた方がいいでしょう. そこではまた, メモリのテストを行うソフトウェアや, ハードウェアがなぜ問題のあるメモリを見逃してしまうかについても 議論されています. 最後に, これらがどれも助けにならなかったら, FreeBSD のバグを発見した可能性があります. 以下の説明を読んで障害報告を送ってください. 詳細な FAQ は, the SIG11 problem FAQ にあります. 起動の時に画面が真っ暗になって同期も取れません. これは ATI Mach 64 ビデオカードの既知の問題です. この問題はカードがアドレス 2e8 を使い, 4 番目のシリアルポートもここを使うということにあります. &man.sio.4; ドライバのバグ(仕様?)のため, 4 番目のシリアルポートがなくても, 通常このアドレスを使う sio3(4 番目のポートにあたります) を無効にしても, ドライバはこのアドレスをさわります. バグが修正されるまでは, 次のようにして対処してください. 起動プロンプトが出たら と入力します (これによりカーネルはコンフィグレーションモードに入ります). sio0, sio1, sio2, sio3(これらすべて)を無効にします. これによって &man.sio.4; ドライバは動作しなくなりますが, 問題はありません. exit とタイプして起動を続行します. もしシリアルポートを有効にしたいのであれば以下の変更を行なって 新しいカーネルを作る必要があります. /usr/src/sys/i386/isa/sio.c の中で 1 ヵ所ある 0x2e8 という文字列を探し, この文字列とその手前にあるコンマを削除します(後ろのコンマは残します). 後は通常の手続きにしたがって新しいカーネルを作ります. この対処を行なった後でもまだ X ウィンドウシステムはうまく動かないかもしれません. その場合は, 使用している XFree86 がすくなくとも XFree86 3.3.3 以降であることを確かめてください. それ以降のバージョンでは, Mach64 カードやそれらのカードのためにつくられた X サーバ の組込みをサポートします. 128MB の RAM があるのですが, 64MB しか認識しません. FreeBSD がメモリのサイズを BIOS から取得する方法の制限により, KB 単位で 16 ビット分までしか検出できません(すなわち最大 65535KB=64MB です. これより少ない場合もあります. ある BIOS の場合はメモリサイズが 16MB に制限されます). 64MB 以上のメモリを積んでいる場合, FreeBSD はそれを検出しようとします. しかしその試みは失敗するかもしれません. この問題を回避するには, 以下に示すカーネルオプションを使用する必要があります. 完全なメモリ情報を BIOS から取得する方法もありますが, 起動ブロックに空きが無いため実装できません. 起動ブロックの問題が解決されれば, いつか拡張 BIOS 機能を使用して完全なメモリ情報を取得できるようになるでしょう. とりあえず現在は, カーネルオプションを使ってください. options "MAXMEM=n" n には, キロバイト単位でメモリの量を指定します. 128MB の場合は, 131072 となります. FreeBSD 2.0 が kmem_map too small! と言ってパニックします. メッセージは, mb_map too small! の場合もあります. このパニックは, ネットワークバッファ(特に mbuf クラスタ)の仮想メモリが無くなったことを示します. 以下のオプションをカーネルコンフィグファイルに追加して mbuf クラスタに使用できる仮想メモリの量を増やしてください. options "NMBCLUSTERS=n" n には, 同時に使用したい TCP コネクションの数に応じて 512 から 4096 までの数値を指定できます. とりあえず 2048 を試してみるのをおすすめします. これでパニックは完全の予防できるはずです. mbuf クラスタの割り当て, 使用状況については, netstat -m で知ることができます. NMBCLUSTERS のデフォルト値は 512 + MAXUSERS * 16 です. 新しいカーネルで再起動すると CMAP busy panic となってパニックを起こしてしまいます. ファイル /var/db/kvm_*.db において範囲外のデータを検出するためのロジックは失敗することがあり, こうした矛盾のあるファイルを使用することでパニックを引き起こすことがあります. これが起こったなら, シングルユーザで再起動した後に, 以下のコマンドを実行してください. &prompt.root; rm /var/db/kvm_*.db ahc0: brkadrint, Illegal Host Access at seqaddr 0x0 というエラーが出ます これは Ultrastor SCSI Host Adapter と衝突しています. 起動時に kernel configuration メニューに入り, 問題を起こしている uha0 を disable にしましょう. sendmail が mail loops back to myself というメッセージを出すのですが. この事は, sendmail FAQ に次のように書いてあります. * "Local configuration error" というメッセージが出ます. 例えば: 553 relay.domain.net config error: mail loops back to myself 554 <user@domain.net>... Local configuration error のような物ですが, どのようにしたらこの問題を解決できますか? これは, たとえば domain.net のようなドメイン宛てのメールを MX record で 特定のホスト (ここでは relay.domain.net) に送ろうとしたのに, そのホストでは domain.net 宛てのメールを受け取れるような設定に なっていない場合です. 設定の際に FEATURE(use_cw_file) を 指定してある場合には /etc/sendmail.cw の中に domain.net を 追加してください. もしくは, /etc/sendmail.cf の中に "Cw domain.net" を追加してください. もはや現在の sendmail FAQ は sendmail release とは一緒には保守されていません. しかし次のネットニュースに定期的に投稿されてます. comp.mail.sendmail, comp.mail.misc, comp.mail.smail, comp.answers, news.answers. また, メール経由でコピーを入手する場合は mail-server@rtfm.mit.edu 宛まで本文に send usenet/news.answers/mail/sendmail-faq と書いて送ります. リモートマシン上のフルスクリーンアプリケーションがうまく動かない リモートマシンのターミナルタイプが FreeBSD のコンソールで必要とされている cons25 以外のものです. この問題を解決しうる方法はいろいろあります: リモートマシンにログインした後, そのリモートマシンが ansi か sco のターミナルタイプを知っているなら, shell 変数の TERM にそれらのいずれかを設定します. FreeBSD のコンソール側で screen のような VT100 エミュレータを使用します. screen は一つのターミナルの中で複数のセッションを並列動作させることができますし, 本来の機能も優れています. 各々の screen のウィンドウは VT100 ターミナルのように振る舞うので, リモート側で設定されるべき TERM 変数は vt100 となります. リモートマシンのターミナルデータベースに cons25 のエントリをインストールします. このインストール方法はリモートマシンのオペレーティングシステムに依存します. リモートのシステムのシステム管理マニュアルが役に立つことでしょう. FreeBSD 側で X サーバを起動して, リモートマシンに xterm や rxvt のような X ベースのターミナルエミュレータを使ってログインします. (訳注: 日本語が必要な場合は kterm 等を 利用します) リモートホストの TERM 変数は xterm もしくは vt100(訳注: もしくは kterm) に設定します. 私のマシンで calcru: negative time... と表示されるのですが これは, 割り込みに関連するさまざまな不具合によって発生します. あるいは, あるデバイスが元々持っているバグが表面化したのかも知れません. この症状を再現させる一つの方法として, パラレルポート上で, TCP/IP を 大きな MTU で走らせるというものがあります. グラフィックアクセラレータがこの症状を起こすことがありますが, その場合はまず, カードの割り込み設定を確認してください. この問題の副作用として, プロセスが SIGXCPU exceeded cpu time limit というメッセージとともに終了してしまう, というものがあります. 1998 年 11 月 29 日に公開された FreeBSD 3.0 以降で この問題が解決しないなら, 次の sysctl 変数をセットしてください. &prompt.root; sysctl -w kern.timecounter.method=1 これは, パフォーマンスへ強い影響を与えますが, 問題の発生に比べればおそらく気にならない程度でしょう. もし, これでもまだ問題が残るようなら, カーネルオプションの NTIMECOUNTER を大きな値に増やしてください. NTIMECOUNTER=20 にまで増やしても解決しない場合は, 計時処理の信頼性が保てない程の割り込みが, そのマシン上で起こっていることを意味します. pcm0 not found という表示を見たり カーネルコンフィグレーションファイルには device pcm0 と 書いてあるのにサウンドカードが pcm1 として 発見されたりします. これは FreeBSD 3.x で PCI のサウンドカードを使っているときに 発生します. pcm0 デバイスは ISA のカード専用に予約されているものです. このため, あなたが PCI カードを持っているときはこのエラーが表示され, カードは pcm1 として検出されます. この警告を, 単にカーネルコンフィグファイルの当該行を device pcm1 に変更することで 抑制することはできません. その時は pcm1 が ISA カードのために予約され, PCI のカードは pcm2 として (pcm1 not found の警告とともに) 検出されます. PCI のサウンドカードを持っているのならば, 以下のようにして snd0 デバイスのかわりに snd1 を作る必要があります. &prompt.root; cd /dev &prompt.root; ./MAKEDEV snd1 この状況は FreeBSD 4.x では生じません. 多くの努力の結果より PnP 中心に作り替えられ, 現在, pcm0 デバイスは ISA カード専用に予約されたものではなくなりました. プラグアンドプレイのカードが認識されなくなりました (または, unknown と認識されるようになりました). 現在の FreeBSD 4.x はより PnP 中心に なっています. その副作用の影響で, FreeBSD 3.x で動いていた PnP デバイス (たとえばサウンドカードや内蔵モデム) の中には, 動かなくなってしまったものもあります. この挙動の原因は Peter Wemm が freebsd-questions メーリングリストに書いた, 以下の 「FreeBSD 4.x にアップグレードしたところ内蔵モデムが 見つからなくなった」というメールで解説されています. (わかりやすくするために [] 内に コメントを加えました).
PnP BIOS はあらかじめ, [モデムを] ポート空間に存在しているかのように設定します. そのため [3.x では] 従来の手法に基づく ISA デバイスの検索により, モデムの存在を「発見」できます. 4.0 の ISA コードは, より PnP 中心になっています. [3.x では] ISA デバイスの検索が「はぐれた」デバイスを発見して, 次に PNP デバイス ID のマッチが行なわれることでリソースの競合が発生し, デバイスの検索に失敗する可能性があります. したがって, 4,0 の ISA コードでは 二重に検索しないよう, プログラマブルなカードを 最初に無効にしています. これは, 対応している PnP ハードウェアの PnP ID が, 予めわかっている必要がある, ということを意味します. ユーザがこの挙動にもっと手を入れられるようにすることが TODO リスト中にあげられています.
3.0 で動作していたデバイスを 4.0 でも動作するようにするには, それの PnP ID を調べ, ISA デバイスの検索が PnP デバイスの識別に使っているリストにそれを追加する必要があります. デバイスの検索に使われる &man.pnpinfo.8; を用いて, PnP ID を得ることができます. たとえば, 内蔵モデムに関する &man.pnpinfo.8; の出力は, 以下のようになります. &prompt.root; pnpinfo Checking for Plug-n-Play devices... Card assigned CSN #1 Vendor ID PMC2430 (0x3024a341), Serial Number 0xffffffff PnP Version 1.0, Vendor Version 0 Device Description: Pace 56 Voice Internal Plug & Play Modem Logical Device ID: PMC2430 0x3024a341 #0 Device supports I/O Range Check TAG Start DF I/O Range 0x3f8 .. 0x3f8, alignment 0x8, len 0x8 [16-bit addr] IRQ: 4 - only one type (true/edge) [more TAG lines elided] TAG End DF End Tag Successfully got 31 resources, 1 logical fdevs -- card select # 0x0001 CSN PMC2430 (0x3024a341), Serial Number 0xffffffff Logical device #0 IO: 0x03e8 0x03e8 0x03e8 0x03e8 0x03e8 0x03e8 0x03e8 0x03e8 IRQ 5 0 DMA 4 0 IO range check 0x00 activate 0x01 必要な情報は, 出力の冒頭にある Vendor ID 行にあります. かっこの中の 16 進数 (例の中では 0x3024a341) が PnP ID で, 直前の文字列 (PMC2430) はユニークな ASCII ID です. この情報はファイル /usr/src/sys/isa/sio.c に 追加する必要があります. まず失敗したときに備えて sio.c の バックアップを取るべきです. 障害報告を送るために修正パッチを 作る時にも必要になるでしょう (send-pr しようとしていますよね？). sio.c を編集して以下の行を探してください. static struct isa_pnp_id sio_ids[] = { そしてあなたのデバイスのエントリを追加する正しい場所を探します. エントリは以下のような形をしていて, &man.pnpinfo.8; の 出力にある デバイスの説明の全部 (もし収まれば) か一部とともに行の右の方のコメント領域に書かれている ASCII ベンダ ID でソートされています. {0x0f804f3f, NULL}, /* OZO800f - Zoom 2812 (56k Modem) */ {0x39804f3f, NULL}, /* OZO8039 - Zoom 56k flex */ {0x3024a341, NULL}, /* PMC2430 - Pace 56 Voice Internal Modem */ {0x1000eb49, NULL}, /* ROK0010 - Rockwell ? */ {0x5002734a, NULL}, /* RSS0250 - 5614Jx3(G) Internal Modem */ あなたのデバイスの16進数のベンダ ID を正しい場所に 追加し, ファイルをセーブしてカーネルを作り直して再起動します. あなたのデバイスは FreeBSD 3.x の時と同じように sio として見つかるようになっているはずです. top や systat の 実行中に nlist failed という エラーがでます. このエラーは, 実行しようとしたアプリケーションが あるカーネルシンボルを検索した結果, 何らかの理由でその検索に失敗した, ということを意味しています. これは, 以下に示すいずれかの理由によるものです. カーネルとユーザランドが同期していない (つまり カーネルは新しいものを構築したが, installworld は行なっていない. あるいはその逆) ので, シンボルテーブルがユーザアプリケーションの考えているものと異なっている. もしこのケースなら, 一連のアップグレード手順に従ってアップグレードを行なってください (正しいやり方は /usr/src/UPDATING に書いてあります). カーネルをロードするのに /boot/loader を使わず, 直接 boot2 (&man.boot.8; 参照) からロードしている. もちろん /boot/loader を使わなくとも問題はないのですが, /boot/loader は一般的に, ユーザアプリケーションからカーネルシンボルを アクセスできるようにするための機能を持っています. 商用アプリケーション 訳: 山下 淳 junkun@esys.tsukuba.ac.jp, 1997 年 11 月 10 日. この章はまだまだ情報が足りません. 情報を追加してくれるような企業を待ち望んでいます. FreeBSD グループはここに載っている企業からの金銭的な支援を期待してはいませんので, 奉仕作業の一つとして掲載しています(そして FreeBSD が係わる宣伝は, 長い目で見ると FreeBSD に対してよい方向へ働くと思っています). 私たちは商用ソフトウェアベンダに, ここで製品を宣伝してもらうことを望んでいます. 詳しくは, 商用ソフトウェアベンダ覧のページをご覧ください. FreeBSD 用の Motif はどうやったら手に入りますか FreeBSD 用の廉価版 ELF Motif 2.1.20 (i386 版, Alpha 版) に関する情報はApps2go から 手に入れることができます. この製品には, 「開発者版(development edition)」 と, より安価な「ランタイム版(runtime edition)」 の二つの版があります. これらの製品は以下の物が含まれています. OSF/Motif manager, xmbind, panner, wsm. uil, mrm, xm, xmcxx, インクルードファイルや Imake ファイルといった開発者向けキット FreeBSD 3.0 以降で利用できる ELF 版スタティックライブラリ, およびダイナミックライブラリ デモンストレーションプログラム 注文する際には FreeBSD 用の Motif であることをきちんと 確認してください(あなたの欲しいアーキテクチャを指定するのも 忘れないでください!). NetBSD や OpenBSD 用の Motif もまた, Apps2goから販売されています. 現在, FTP による ダウンロードのみ利用可能です. より詳しい情報は Apps2go WWW page 問い合わせは Sales または Support 電子メールアドレス. もしくは phone (817) 431 8775 or +1 817 431-8775 他の FreeBSD 用 Motif 2.1(ELF 版, a.out 版) に関する情報は Metro Link から手に入れることができます. この製品は以下の物が含まれています. OSF/Motif manager, xmbind, panner, wsm. uil, mrm, xm, xmcxx, インクルードファイルや Imake ファイルといった開発者向けキット スタティックライブラリ, およびダイナミックライブラリ. (FreeBSD 3.0 以降で利用できる ELF 版か, FreeBSD 2.2.8 以前で利用できる a.out 版を指定してください) デモンストレーションプログラム 整形済みのマニュアルページ 注文する際には FreeBSD 用の Motif であることをきちんと 確認してください. Linux 用の Motif も Metro Link から販売されています. 現在, CDROM および FTP によるダウンロードが利用可能です. FreeBSD 用の a.out 版 Motif 2.0 に関する情報は Xi Graphics から 手に入れることができます. この製品は以下の物が含まれています. OSF/Motif manager, xmbind, panner, wsm. uil, mrm, xm, xmcxx, インクルードファイルや Imake ファイルといった開発者向けキット FreeBSD 2.2.8 以前のバージョンで利用できるスタティックライブラリ, およびダイナミックライブラリ デモンストレーションプログラム 整形済みのマニュアルページ 注文する際には FreeBSD 用の Motif であることをきちんと 確認してください. BSDI や Linux 用の Motif もまた, Xi Graphics から販売されています. 現在フロッピーディスク 4枚組ですが, 将来的には CDE のように統合された CD に変わるでしょう. FreeBSD 用の CDE はどうやったら手に入りますか 以前 Xi Graphics より FreeBSD 用の CDE が 販売されていましたが, 現在は既に販売が終了しています. KDE 多くの点で CDE と類似しているオープンソースの X11 デスクトップ環境です. xfce の ルック & フィール(訳注: 外観や操作方法のこと)も気に入るかも知れません. KDE, xfce は, いずれも FreeBSD Ports Collection に含まれています. 高機能な商用 X サーバってあるんですか? はい, Xi Graphics と Metro Link から, FreeBSD ほか Intel ベースのシステムで動作する Accelerated-X という製品が販売されています. Metro Link は, FreeBSD のパッケージ操作ツールを利用することで 容易に設定が行なえるほか, 数多くのビデオボードをサポートした 高機能な X サーバを提供しています. 配布はバイナリ形式のみで, FTP が利用可能です. もちろん, とても安価($39)に手に入れることができます. また, Metro Link は ELF 版, a.out 版の FreeBSD 用 Motif も販売しています(前を参照). より詳しい情報は Metro Link WWW page 問い合わせは Sales または Support 電子メールアドレス もしくは phone (954) 938-0283 or +1 954 938-0283 Xi Graphics が提供している高性能な X サーバは楽に設定を行なえるほか, 数多くのビデオボード をサポートしています. サーバはバイナリのみが含まれます. FreeBSD 用と Linux 用の統合されたフロッピーディスクに入っています. Xi Graphics は Laptop サポートに特化した高性能 X サーバも提供しています. バージョン 5.0 の「互換デモ」が無料で入手できます. また Xi Graphics は FreeBSD 用の Motif と CDE も販売しています (前を参照). より詳しい情報は Xi Graphics WWW page 問い合せは Sales または Support もしくは phone (800) 946 7433 or +1 303 298-7478. FreeBSD 用のデータベースシステムはありますか? もちろんです. FreeBSD のウェブサイトにある 商用ベンダー というセクションをご覧ください. また, FreeBSD Ports Collection のデータベースのセクションも参考になるでしょう. Oracle を FreeBSD 上で動かすことはできますか? はい. Linux 版 Oracle を FreeBSD でセットアップするための方法は, 次に示すページに詳しく書かれています. http://www.scc.nl/~marcel/howto-oracle.html http://www.lf.net/lf/pi/oracle/install-linux-oracle-on-freebsd ユーザアプリケーション 訳: 山下 淳 junkun@esys.tsukuba.ac.jp, &a.jp.shou;, 1997 年 11 月 8 日. そういうユーザアプリケーションはどこにあるの? FreeBSDに移植されたソフトウェアパッケージについては, FreeBSD Ports Collection のページをご覧ください. このリストには現在 3400 を越える項目があり, しかも毎日更新されています. このページをこまめに訪れるか, freebsd-announce メーリングリストを購読すると, 新しく入った ports を定期的にチェックすることができます. 大部分の ports は 2.2 と 3.x および 4.x ブランチで利用できるはずです. 多くは 2.1.x 系のシステムでも同様に動作するでしょう. FreeBSD のリリースが出る度に, そのリリースの時点での ports ツリーの スナップショットが撮られ, ports/ ディレクトリに 納められることになっています. また, package という考えも採用されています. これは基本的には gzip で圧縮されたバイナリディストリビューションに, インストール時に環境に合わせた作業が必要になった場合, 行う機能を多少付け加えたものです. package を使えば, どのようなファイルが配布物として含まれているか, と言った細かい事柄にいちいち煩わされることなく, 簡単にインストールやアンインストールを繰り返すことができます. インストールしたい package があるなら, /stand/sysinstallの, 「インストール後の FreeBSD の設定を行う」の下にある package のインストールメニューを使うか, package のファイル名を指定して pkg_add(1) を使用してください. package のファイル名には, 通常末尾に .tgz がついています. CDROM をご使用の方は, CD の packages/All ディレクトリからそれらのファイルを利用することができます. また, 以下の場所から, FreeBSD の各種バージョンにあわせた package をダウンロードする こともできます. 2.2.8-RELEASE/2.2.8-STABLE 用 ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-2.2.8/ 3.X-RELEASE/3.X-STABLE 用 ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/ 4.X-RELEASE/4-STABLE 用 ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/ 5.X-CURRENT 用 ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current お近くのミラーサイトもご利用ください. 新しい ports が続々と追加されている状態なので, 全ての ports に 対応する package が存在するわけではないことを覚えておいてください. 定期的に ftp.FreeBSD.org マスターサイトを訪れて, どのような package が利用できるのかチェックするのも良いでしょう. なぜ /bin/sh はこんなに低機能なのですか? どうして bash や他のシェルを採用しないのでしょう? それは, POSIX がそのようなシェルがあることを規定しているからです. もっと込み入った回答: 多くのユーザは, 多くのシステムで同じように動作できるシェルスクリプトを書く必要があります. これが, POSIX でシェルやユーティリティコマンドが細く規定されている理由です. ほとんどすべてのスクリプトは Bourne shell で書かれているのですが, それは, 数多くの重要なプログラミングインタフェイス(&man.make.1;, &man.system.3;, &man.popen.3;, や Perl や Tcl 等の類似の 高水準スクリプト言語)が, コマンドの解釈に Bourne shell を使うからです. このように Bourne shell が極めて頻繁にかつ広範囲で使われているため, 素早く起動できて確実に動作し, メモリを少ししか消費しないということが 重要になります. 既存の実装は, 私たちに可能な限りこれらの多くの要求を同時に満足することができる最良のものです. /bin/sh を小さいままに保つため, 私たちは他のシェルが持つ様々な便利な機能を提供していません. Ports コレクションが bash や scsh, tcsh, zsh などの 多機能なシェルを含んでいるからです. (これらのシェルすべての メモリ使用状況は, ps -u の VSZ や RSS の行で, あなた自身が確認することができます.) libc.so.3.0 はどこにありますか? FreeBSD 2.1.x のシステムで 2.2 以降用の package を動かそうとしていますね? 前のセクションを読んで, システムに合った正しい port/package を入手してください. Error: can't find libc.so.4.0 というメッセージが表示されるのですが. 何かの手違いで, 4.X と 5.X のシステム用 package をダウンロードし, FreeBSD 2.X, もしくは 3.X のシステムにインストールしてしまったのでしょう. 対応する正しいバージョンの package をダウンロードしてください. 386/486SX のマシンで ghostscript を動かすとエラーがでます. あなたのマシンには数値演算プロセッサが塔載されていませんね? カーネルにコプロセッサの代わりとなる数値演算エミュレータを追加する必要があります. 以下のオプションをカーネルのコンフィグレーションファイルに追加して, カーネルを再構築してください. options GPL_MATH_EMULATE このオプションを追加する場合, MATH_EMULATE の行を削除してください. SCO/iBCS2 のアプリケーションを実行すると, socksys で落ちてしまいます. (FreeBSD 3.0 とそれ以前のみ) まず最初に /etc/sysconfig(または /etc/rc.conf)の中の 最後のセクションを編集し, 以下の変数を YES に直します. # Set to YES if you want ibcs2 (SCO) emulation loaded at startup ibcs2=NO これでシステムの起動時に ibcs2 カーネルモジュールが読み込まるようになります. 次に /compat/ibcs2/dev/ を以下のように編集します. lrwxr-xr-x 1 root wheel 9 Oct 15 22:20 X0R@ -> /dev/null lrwxr-xr-x 1 root wheel 7 Oct 15 22:20 nfsd@ -> socksys -rw-rw-r-- 1 root wheel 0 Oct 28 12:02 null lrwxr-xr-x 1 root wheel 9 Oct 15 22:20 socksys@ -> /dev/null crw-rw-rw- 1 root wheel 41, 1 Oct 15 22:14 spx open や close の処理は, socksys から /dev/null へシンボリックリンクを張ることで代用します. 残りの処理は, -CURRENT に入っているコードが担当しています. これは以前のものより ずっとスッキリした方法です. INN(インターネットニュース)の設定方法は? inn の package や port をインストールしたあとに Dave Barr's INN Page を見てみましょう. 初心者向けの INN FAQ があります. どのバージョンの Microsoft FrontPage を手に入れる必要がありますか? ルーク, ports を使うのだ! パッチ処理済みの Apache が ports ツリーから入手できます. FreeBSD は Java をサポートしていますか? はい. http://www.FreeBSD.org/java/ をご覧ください. 日本語訳 もあります. 3.x-STABLE を載せているマシンで port がコンパイルできないことがあります. それはどうしてですか? もし, その時点の -CURRENT か -STABLE に比べてずっと古いバージョンの FreeBSD を利用しているなら, http://www.FreeBSD.org/ports/ にある ports アップグレードキットが必要です. 最新の FreeBSD を利用しているのに発生する場合はおそらく, -CURRENT では正常なのに -STABLE ではうまく動かなくなるような変更がその port に対して行なわれ, 受理されてしまっているのでしょう. ports コレクションは -CURRENT と -STABLE, 両方のブランチで動かなければならないものですので, もしそれを発見したら send-pr(1) コマンドを使ってバグレポートの提出をお願いします. ld.so はどこにありますか? 3.1-R 以降などの Elf 化されたマシンで Netscape Navigator などの aout 形式のアプリケーションを動かすときには, /usr/libexec/ld.so と aout ライブラリのファイルが必要です. それらは配布物の compat22 に納められています. /stand/sysinstall や compat22 サブディレクトリ内の install.sh を使って compat22 をインストールしてください. 合わせて 3.1-R と 3.2-R の ERRATA もお読みください. カーネルコンフィグレーション 訳: &a.jp.kiroh;, 1997 年 11 月 10 日. カーネルをカスタマイズしたいんですが, 難しいですか? 全然難しくありません. カーネルの再構築を調べてください. うまく動作するカーネルができたら, 日付入りのカーネルのスナップショットを kernel.YYMMDD のように作成することをおすすめします. こうしておけば, 次にカーネルの構築をやってうまくいかなくなってしまっても, kernel.GENERIC にわざわざ戻る必要がなくなります. これは, GENERIC カーネルでサポートされないデバイスから起動している場合は, 特に重要です(経験者は語るってやつです). _hw_float が無いので, カーネルのコンパイルがうまくいきません. 推測ですけど, 数値演算コプロセッサを持ってないからと思って, npx0 をカーネルコンフィグファイルから削除しちゃったんじゃないですか? npx0 は必須です. コプロセッサがなくても, npx0 デバイスは削除してはいけません. わたしのカーネルはどうしてこんなに大きい (10MB 以上) のでしょうか? これはデバッグモードでカーネルを構築していることが原因です. デバッグモードで構築されたカーネルは, デバッグに用いられる膨大なシンボル情報を含んでいるため, カーネルのサイズが非常に大きくなります. ただし FreeBSD 3.0 とそれ以降のシステムの場合は カーネルのサイズは小さくなりますし, デバッグカーネルを実行する時のパフォーマンスの低下もありません. また, そのカーネルはシステムがパニックした場合に有用です. しかし, 容量の小さなディスクでシステムを運用していたり, 単にデバッグカーネルを実行したくない場合は, 以下の両方が当てはまっているかどうか確認してください. カーネルコンフィグファイルに以下の行が書かれていないこと. makeoptions DEBUG=-g config を実行する際, オプションを付けていないこと. 上に書かれた指定は両方ともカーネルをデバッグモードで構築するためのものです. 上の手順を従っている限り, カーネルを普通に構築してサイズの小さなカーネルを得ることができます. その場合のカーネルサイズは, およそ 1.5MB から 2MB 程度になります. マルチポートシリアルのコードで割り込みが衝突しています. Q. マルチポートシリアルを サポートするコードを含んだカーネルをコンパイルしようとすると, 最初のポートだけ検出され, 残りのポートは割り込みの競合のためスキップされたと言われます. どうやったらいいでしょうか? A. ここでの問題は, FreeBSD にはハードウェアまたはソフトウェアの競合により, カーネルがクラッシュするのを防ぐコードが含まれているという点です. 解決するには, 最初のポートにだけ IRQ の設定を書き, 残りは IRQ の設定を削除します. 以下に例を示します. # Multiport high-speed serial line - 16550 UARTS # device sio2 at isa? port 0x2a0 tty irq 5 flags 0x501 vector siointr device sio3 at isa? port 0x2a8 tty flags 0x501 vector siointr device sio4 at isa? port 0x2b0 tty flags 0x501 vector siointr device sio5 at isa? port 0x2b8 tty flags 0x501 vector siointr カーネルを構築にいつも失敗します. GENERIC カーネルも構築できません. さまざまな理由が考えられます. 以下, 順に列記します. あなたは新しい make buildkernel や make installkernel ターゲットを使わず, 現在走っているシステムを構築した時と異なるソースツリーを 構築しようとしている (たとえば, 4.0-RELEASE のシステム上で 4.2-RELEASE を構築しようとしている) のではないでしょうか? もしシステムをアップグレードしようとしているのなら, /usr/src/UPDATING ファイルを 共通項目 (COMMON ITEMS) 節に注意しながら最後までお読みください. あなたは新しい make buildkernel や make installkernel ターゲットを 使っているのにも関わらず, make buildworld を行なっていないのではないでしょうか? make buildkernel ターゲットは, make buildworld ターゲットによって作られるファイルに依存しています そのため, make buildkernel が正常に終了するためには make buildworld ターゲットが正常に完了している必要があります. 構築しようとしているのが FreeBSD-STABLE だったとしても, あなたが入手したソースツリーが何らかの理由で 書き換わったり, 壊れてしまっているのかも知れません. FreeBSD-STABLE はほとんどの場合, きちんと構築できるようになっていますが, 確実に構築可能であることが保証されているのは リリース版だけです. 一度ソースツリーを再取得して, 問題が解決しないかどうか試してみてください. また, あるサーバから取得した時に問題が発生したら, 別のサーバを試すのも効果があるかも知れません. システム管理 訳: にしか nishika@cheerful.com, 1997 年 11 月 12 日. システムスタートアップファイルはどこにあるのですか? FreeBSD 2.0.5R から 2.2.1R までは, プライマリコンフィグレーションファイルは /etc/sysconfig にあります. オプションはすべて, このファイルと /etc/rc および /etc/netstartといった, 別のファイルに指定されています. ファイル /etc/sysconfig を見て, システムに適合するように変更してください. このファイルには, それぞれの場所に何を書けばいいのかを表すコメントがたくさん書かれています. FreeBSD 2.2.2 から 3.0 までのシステムでは, /etc/sysconfig は, より分りやすい名前の rc.conf に改名され, それに従って書式もいくぶん改められています. /etc/netstart も /etc/rc.network に改名され, 全部のファイルを cp /usr/src/etc/rc* /etc で一度にコピーすることが出来るようになります. FreeBSD 3.1 とそれ以降では, /etc/rc.conf が /etc/defaults/rc.conf に移動しました. このファイルを編集してはいけません! 代わりに, /etc/defaults/rc.conf の中で変えたいエントリの行を /etc/rc.conf にコピーし, そこで変更するようにしてください. たとえば named を起動したいとしましょう. FreeBSD 3.1 かそれ以降のシステムで FreeBSD 付属の DNS サーバを起動するには, 次のようにするだけです. &prompt.root; echo named_enable="YES" >> /etc/rc.conf FreeBSD 3.1 かそれ以降でローカルサービスを起動するためには, /usr/local/etc/rc.d ディレクトリにシェルスクリプトを置きます. シェルスクリプトは起動可能に設定し, ファイル名が .sh で終わっていなければなりません. FreeBSD 3.0 とそれ以前のリリースでは, /etc/rc.local を編集する必要があります. ファイル /etc/rc.serial はシリアルポートの初期化(たとえばポートの設定を固定したり等々)のためにあります. ファイル /etc/rc.i386 は iBCS2 エミュレーションのような Intel アーキテクチャ固有の設定や, PC システムコンソール設定のためにあります. 簡単にユーザを追加するにはどうすればいいのですか? adduser コマンドを使用してください. また, pw コマンドを用いることで, さらに細かい操作が可能です. ユーザを削除するには rmuser コマンドを使用してください. 繰り返しになりますが, pw でも構いません. FreeBSD システムに新しいハードディスクを追加するには? www.FreeBSD.org に書かれているディスクフォーマットチュートリアルを参照してください. 新しいリムーバブルドライブを持っていますが, どうやって使うの? そのリムーバブルドライブが ZIP であれ EZ drive であれ (あるいはもしそういう風に使いたいのなら, フロッピーであれ), またハードディスクであれ, 一旦システムにインストールされて認識され, カートリッジ, フロッピー等々が挿入されていれば, ことはどのデバイスでも全く同じように進みます. (このセクションはMark Mayo's ZIP FAQ に基づいています.) ZIP ドライブやフロッピーで, すでに DOS のファイルシステムで フォーマットしてある場合, 次のコマンドを使うことができます. これはフロッピーの場合です. &prompt.root; mount -t msdos /dev/fd0c /floppy 出荷時の設定の ZIP ディスクではこうです. &prompt.root; mount -t msdos /dev/da2s4 /zip その他のディスクに関しては, fdisk や /stand/sysinstall を使って, どのようにレイアウトされているか確かめてください. 以降は ZIP ドライブが 3 番目の SCSI ディスクで, da2 と認識されている場合の例です. 他人と共有しなければならないフロッピーやリムーバブルディスク でなければ, BSD ファイルシステムを載せてしまうのが良い考えでしょう. ロングファイル名もサポートされ, パフォーマンスは少なくとも 2 倍は向上しますし, おまけにずっと安定しています. まず最初に, DOS レベルでのパーティション / ファイルシステムを無効にしておく必要があります. 使用するのは fdisk でも /stand/sysinstall でも結構です. 複数のオペレーティングシステムを入れることを考慮する 必要がないような容量の小さなドライブの場合は, 次のように FAT パーティションテーブル (スライス) 全体を飛ばして, BSD のパーティション設定を行うだけで良いでしょう. &prompt.root; dd if=/dev/zero of=/dev/rda2 count=2 &prompt.root; disklabel -Brw da2 auto 複数の BSD パーティションをつくる場合, disklabel か /stand/sysinstall を使います. 固定ディスク上にスワップ領域を加える場合, そういうことをしたいと思うのはもっともですが, ZIP のようなリムーバブルドライブの上ではそういう考えは不適切 でしょう. 最後に, 新しいファイルシステムをつくります. ディスク全体を使用する ZIP ドライブの場合は, 以下のようにします. &prompt.root; newfs /dev/rda2c 次にマウントします. &prompt.root; mount /dev/da2c /zip また, 次のような行を /etc/fstab に入れておくのも良い考えでしょう. mount /zip と入力するだけでマウントできるようになります. /dev/da2c /zip ffs rw,noauto 0 0 自分の crontab ファイルを編集した後 root: not found のようなメッセージが延々と表示されるのですが, これはなぜですか? これは通常, システム crontab (/etc/crontab) を編集し, &man.crontab.1; を使ってインストールした場合に起こります. &prompt.root; crontab /etc/crontab この方法は正しくありません. システム crontab のフォーマットは &man.crontab.1; が更新する各ユーザの crontab とは異なります (フォーマットの相違点の詳細は &man.crontab.5; で説明されています). もしこのような操作をしてしまったなら, あらたな crontab は誤ったフォーマットの /etc/crontab のコピーになってしまっているからです. 以下のコマンドで削除してください. &prompt.root; crontab -r 今度 /etc/crontab を編集する時は, その変更を &man.cron.8; に伝えるような操作をしてはいけません. &man.cron.8; は, 自動的にその変更を認識するからです. もしあなたが何かを一日一回, あるいは一週間や一ヶ月に一回だけ 実行させたいなら, シェルスクリプトを /usr/local/etc/periodic に追加し, &man.periodic.8; コマンドにシステムの cron スケジュールから 他の定期的なシステムのタスクとともに 実行させたほうが良いかもしれません. このエラーの実際の原因は, システム crontab には どのユーザ権限でコマンドを実行するかを指定する余分なフィールドがあることによるものです. FreeBSD に添付されている標準のシステム crontab には, すべてのエントリに root が書かれています. この crontab が root ユーザの crontab (システム crontab とは 異なります) として使われた場合, &man.cron.8; は root を実行するコマンドの最初の単語だと認識しますが, そのようなコマンドは存在しないのです. rc.conf やその他の スタートアップファイルを書き間違えてしまいました. しかもそのためファイルシステムがリードオンリーになってしまっていて 編集ができません. どうすればいいですか? シェルのパス名を入力するプロンプトが表示されたときに, 単に ENTER を押し, mount / を 実行してそルートファイルシステムを再マウントさせるます. また, お気に入りのエディタがあるファイルシステムを マウントするために mount -a -t ufs を する必要があるかも知れません. あなたのお気に入りのエディタが ネットワークファイルシステム上にある場合は, ネットワークファイルシステムをマウントする前にネットワークを 手動で設定するか, &man.ed.1; のようなローカルファイルシステムにある エディタを使うかしなければなりません. &man.vi.1; や &man.emacs.1; の様なフルスクリーンエディタを 使うつもりなら export TERM=cons25 と やってエディタが &man.termcap.5; データベースから正しい データを読み取れるようにしなければなりません. これを行ったあとはいつもと同様, /etc/rc.conf を編集して間違いを訂正することができるようになります. カーネル起動メッセージの直後に表示されたエラーメッセージには, 問題の起こったファイル内での行番号を表示されているはずです. どのようにしたら DOS の拡張パーティションをマウントできますか? DOS 拡張パーティションは, すべての基本パーティションの後に認識されます. たとえば, 2台目の SCSIドライブの拡張パーティションに E パーティションがあるとしますと, これは /dev に「スライス 5 」のスペシャルファイルを作る必要があり, /dev/da1s5 としてマウントされます. &prompt.root; cd /dev &prompt.root; ./MAKEDEV da1s5 &prompt.root; mount -t msdos /dev/da1s5 /dos/e 他のシステムのファイルシステムを FreeBSD でマウントすることはできますか? Digital UNIX: UFS CDROM は直接 FreeBSD でマウントすることができます. Digital UNIX やそれ以外のシステムのサポートする UFS のディスクパーティションをマウントすることはもっと複雑なことで, オペレーティングシステムのディスクパーティションの詳細に依存します. Linux: 2.2 以降は ext2fs パーティションをサポートします. マニュアルの mount_ext2fs を見てください. より多くの情報があります. NT: FreeBSD 用の読みだしのみ可能な NTFS ドライバがあります. 詳しくは, Mark Ovens 氏によって書かれたチュートリアル http://ukug.uk.freebsd.org/~mark/ntfs_install.html をご覧ください. この問題について他の情報があれば, 他の人から感謝されるでしょう. どのようにしたら FreeBSD を NT ローダーから起動させることができますか? この手順は 2.2.x と(起動が 3 つのステージに分かれている)3.x のシステムとで多少異なります. FreeBSD のネイティブルートパーティションの最初のセクタをファイルにして DOS/NT パーティション上に置くという画期的なアイディアがあります. ファイル名を c:\bootsect.bsd(c:\bootsect.dos からの発想です)としたとします. c:\boot.iniファイルを次のように編集します. [boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS [operating systems] multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows NT" C:\BOOTSECT.BSD="FreeBSD" C:\="DOS" この手順は, 利用しているシステムが 2.2.x であり, DOS, NT, FreeBSD あるいはその他のオペレーティングシステムがすべて, 同じディスクのそれぞれの fdisk パーティションにインストールされていることを想定しています. 私の場合は, DOS と NT は最初のパーティション, FreeBSDは 2番目にあります. また, FreeBSD は MBR を使わずに, ネイティブパーティションから起動するようにインストールしてあります. (訳注: FreeBSD のインストールではブートマネジャを使わずに標準 MBR を使う場合に相当します) (もし NTFS に変換してしまっているなら)DOS フォーマットのフロッピーディスクか FAT パーティションを /mnt に DOS マウントします. &prompt.root; dd if=/dev/rda0a of=/mnt/bootsect.bsd bs=512 count=1 再起動してして DOS か NT に切替えます. NTFS ユーザは bootsect.bsd や bootsect.lnx をフロッピーディスクから C:\ へコピーします. boot.ini のファイル属性(パーミッション)の変更を以下のように行ないます. > attrib -s -r c:\boot.ini 上の例の boot.ini で示したような正しいエントリを加え, ファイル属性を元に戻します. > attrib +s +r c:\boot.ini FreeBSD が MBR から起動するようになっている場合, それぞれのネイティブパーティションから起動するように設定した後で, DOS から fdisk コマンドを実行して元に戻してください. FreeBSD 3.X における手順は, これよりいくぶん簡単です. FreeBSD が NT 起動パーティションとして同じディスクにインストールされている場合には, /boot/boot1 を単純に C:\BOOTSECT.BSD へコピーします. もし FreeBSD が異なったディスクにインストールされている場合には, /boot/boot1 では動作しませんので, /boot/boot0 が必要です. ここで /boot/boot1 の代わりに /boot/boot0 をコピーするようなことをしてはいけません! そうすると, パーティションテーブルを上書きしてしまい, コンピュータが起動できなくなってしまいます. /boot/boot0 をインストールするには, sysinstall のブートマネージャを利用するかどうか尋ねられる画面で FreeBSD ブートマネージャを選択する必要があります. /boot/boot0 のパーティションテーブル部分は NULL 文字で埋められているのですが, sysinstall は /boot/boot0 を MBR にコピーする前にパーティションテーブルをきちんとコピーしてくれるからです. FreeBSD ブートマネージャは最後に起動した OS を記録するために パーティションテーブルの最後に起動した OS のエントリにあるアクティブフラグをセットし, 512 バイト全体を MBR に書き戻します. これは /boot/boot0 を C:\BOOTSECT.BSD にコピーし, エントリの一つにアクティブフラグをセットして空のパーティションテーブルを MBR に書き込むことと同じです. FreeBSD と Linux を LILO から起動するには? FreeBSD と Linux が同じディスクにインストールされている場合, 単に Linux 以外の OS を起動するための LILO のインストール手順に 従えばいいだけです. 非常に簡単にではありますが, 記してみましょう. Linux を起動し, /etc/lilo.conf に以下の行を加えて ください. other=/dev/hda2 table=/dev/hda label=FreeBSD (上記の手順は FreeBSD のスライスが Linux から /dev/hda2 という名前で見えていると仮定しています. あなたの設定にあわせてください) その後, lilo を root で実行すれば完了です. FreeBSD が別のディスクにインストールされているのなら, LILO のエントリに loader=/boot/chain.b を追加してください. 例えば, このようになります. other=/dev/dab4 table=/dev/dab loader=/boot/chain.b label=FreeBSD 場合によっては, 二つ目のディスクを正しく起動するために FreeBSD ブートローダに BIOS ドライブ番号を指定する必要があるかもしれません. 例えば, FreeBSD SCSI ディスクが BIOS によって BIOS ディスク 1 として認識されるのなら, FreeBSD のブートローダのプロンプトで, 次のように指定する必要があります. Boot: 1:da(0,a)/kernel FreeBSD 2.2.5 やそれ以降の版では, 起動時に上記のことを行なう だけで自動的に boot(8) が設定されます. Linux+FreeBSD mini-HOWTO が FreeBSD と Linux とを相互に使えるようにするためのよい参考資料になるでしょう. FreeBSD と Linux を BootEasy から起動するには? LILO をマスターブートレコード(MBR)ではなく Linux の起動パーティションにインストールしてください. これで BootEasy から LILO を起動できるようになります. Windows95 と Linux を使用している場合は, いずれにせよ後者の方がおすすめです. Windows95 を再インストールする必要にかられたとき, Linux を起動可能に戻す手続きが簡単ですむからです (Windows95 は偏屈なオペレーティングシステムで, マスターブートレコード(MBR)から他のオペレーティングシステムを追い払ってしまうのです). 「危険覚悟の専用(dangerously dedicated)ディスク」は健康に悪いの? インストール作業中, ハードディスクのパーティションを切る際に 2 つの方法を選ぶことができます. デフォルトの方法では, fdisk のテーブルエントリ(FreeBSD ではスライスと呼ばれる) を使って, 自身のパーティションを使用する FreeBSD のスライスを, 同じマシンの他のオペレーティングシステムと互換性のある形にします. それに付随して, ブートセレクタをインストールすれば, ディスク上の使用可能なオペレーティングシステムを切り替えることができます. もう一つの方法はディスク全てを FreeBSD で使うというもので, この場合ほかのオペレーティングシステムとの互換性を考慮しないことになります. では, なぜこれが 「危険覚悟の」と言われるのでしょう? このモードのディスクが, 通常の PC のユーティリティが有効な fdisk テーブルと見なす情報を持っていないからです. ユーティリティの出来如何によりますが, そのようなディスクを発見したとき, 警告を出すものもあります. また, もっと悪い場合, 確認も通告もなしに BSD のブートストラップにダメージを与えるものもあるでしょう. さらには, 「危険覚悟の」ディスクレイアウトは多数の BIOS, AWARD(例えば HP Netserver や Micronics システム, 他多数で使用されていた)や Symbios/NCR(人気のあるSCSI コントローラ 53C8xx 用)などを混乱させることが分かっています. これは完全なリストではありません. 他にもまだまだあります. この混乱の兆候は, 起動時にシステムがロックするというだけでなく, FreeBSD のブートストラップが自分自身を見つけられないために表示する read error というメッセージなどにも現れることでしょう. そもそもいったいなぜこのモードがあるのでしょうか? これはわずかに数キロバイトのディスク容量を節約するのみであり, 新規インストールで実際に問題を生ずるのです. 「危険覚悟の」モードの起源は新しい FreeBSD インストーラでの, BIOS から見えるディスクの 「ジオメトリ」の値とディスク自身との整合性という, もっとも一般的な問題のひとつを回避したいという要求が背景にあります. 「ジオメトリ」は時代遅れの概念ですが, 未だに PC BIOS とディスクへの相互作用の中核をなしています. FreeBSD のインストーラがスライスを作る時, ディスク上のスライスを BIOS が見つけられるように, スライス位置をディスク上に記録します. それが誤っていれば, 起動できなくなってしまうでしょう. 「危険覚悟の」モードはこれを, 問題を単純にすることで回避しようとします. 状況によってはこれでうまくいきます. しかし次善の策として使われているに過ぎません. この問題を解決するもっと良い方法はいくらでもあるのです. では, インストール時に「危険覚悟の専用」モードが必要になる 状況を回避するにはどうすればよいのでしょうか? まず BIOS が報告するディスクのジオメトリの値を覚えておくことからはじめましょう. boot: プロンプトで を指定するか, ローダで boot -v と指定して, 起動時にカーネルにこの値を表示させることができます. インストーラが起動する直前に, カーネルがジオメトリ値のリストを表示するでしょう. パニックを起こさないでください. インストーラが起動するのを待ち, 逆スクロールでさかのぼって値を確認してください. 普通は BIOS ディスクユニット番号は, FreeBSD がディスクを検出する順序と同様であり, 最初に IDE, 次に SCSI となります. ディスクをスライシングする際に, FDISK の画面で表示されるディスクのジオメトリが正しいこと(BIOS の返す値と一致しているか)を確認してください. 万一異なっていたら g を押して修正してください. ディスクにまったくなにもない場合や, 他のシステムから持ってきたディスクの場合は これを行なう必要があるかもしれません. これはそのディスクから起動させようとしている場合にのみ, 問題になることに注意してください. FreeBSD はそのディスクをうまい具合いに他のディスクと区別してくれます. ディスクのジオメトリについて BIOS と FreeBSD 間で一致させることができたら, この問題はほぼ解決したと思ってよいでしょう. そしてもはや「危険覚悟の専用」モードは必要ありません. しかし, まだ起動時に恐怖の read error メッセージが出るようであれば, お祈りを捧げて新しいディスクを買いましょう. もう失うものは何もありません. 「危険覚悟の専用ディスク」を通常の PC での使用法に戻すには, 原則として 2 つ方法があります. 1 つは十分な NULL バイトを MBR に書き込んで, きたるべきインストーラにディスクはまっさらだと思い込ませる方法です. 例えば, こんな感じです. &prompt.root; dd if=/dev/zero of=/dev/rda0 count=15 また, マニュアルには書かれていない DOS の「機能」 > fdisk /mbr は, BSD ブートストラップを追い払ってくれる上に, 新しいマスターブートレコードをインストールしてくれます. どのようにしたらスワップ領域を増やせますか? スワップパーティションのサイズを増やすのが最良の方法ですが, 別のディスクを追加しなくて済むという利点のある方法があります. 経験から得た一般的な方法はメインメモリの 2倍程度のスワップ領域を とるというものです. しかしごく小さなメインメモリしかない場合は, それ以上のスワップを構成したいと思うでしょう. また, 将来のメモリの アップグレードに備え, 後でスワップの構成を変更する必要がないように 十分なスワップを構成しておくことは良い考えです. スワップを別のディスク上に追加することは, 単純に同じディスク上 にスワップを追加する場合よりも高速に動作するようになります. 例に挙げれば, あるディスク上のソースをコンパイルしているとして, スワップが別のディスク上に作られていれば, これらが同じディスク上 にある場合よりも断然速いです. SCSI ディスクの場合は特にそうだと言えます. ディスクが複数ある場合, スワップパーティションを各ディスクに 作るように構成すると, 使用中のディスク上にスワップを置いたとしても, 通常の場合は有益です. 一般的に, システムにある高速なディスクには スワップを作るようにすべきでしょう. FreeBSD はデフォルトでインターリーブなスワップデバイスを 4つまで サポートします. 複数のスワップパーティションを構成する際に, 普通はそれらを大体同じくらいの大きさにして作りたいところですが, カーネルのコアダンプを取るのに都合が良いようにメインの スワップパーティションを大きめにとる人もいます. メインのスワップパーティションはカーネルのコアがとれるように 最低でも実メモリと同じ大きさにすべきでしょう. IDE ドライブは同時に同じチャネル上の複数のドライブには アクセスできません (FreeBSD は mode 4 をサポートしていないので, すべての IDE ディスク I/O は programmed です). IDE の場合であってもやはり, スワップを別のハードディスク上に 作成することをおすすめします. ドライブは実に安いものです, 心配するだけ無駄です. NFS 越しにスワッピングさせる方法は, スワップ用のローカルディスクが無い場合にのみ推奨されます. NFS 越しのスワッピングは遅く, FreeBSD 4.x より前のリリースでは 効率が悪いのですが, 4.0 以降ではそれなりに高速になります. そうはいっても, 利用できるネットワークの太さに制限されますし, NFS サーバに余計な負荷がかかります. これは 64MBの vn-swap を作る例です(ここでは /usr/swap0 としますが, もちろん好きな名前を使うことができます). カーネルが次の行を含むコンフィグファイルから構成されているかを 確認します. GENERIC カーネルには, この行が含まれています. pseudo-device vn 1 #Vnode driver (turns a file into a device) vn デバイスを作ります &prompt.root; cd /dev &prompt.root; sh ./MAKEDEV vn0 スワップファイルを作ります(/usr/swap0) &prompt.root; dd if=/dev/zero of=/usr/swap0 bs=1024k count=64 /etc/rc.conf でスワップファイルを有効化させます swapfile="/usr/swap0" # Set to name of swapfile if aux swapfile desired. マシンを再起動します スワップファイルをすぐに有効化させたいのなら以下のようにタイプします. &prompt.root; vnconfig -ce /dev/vn0c /usr/swap0 swap プリンタのセットアップで問題があります ハンドブックのプリンタの部分を参照してください. 探している問題のほとんどが書かれているはずです. FreeBSD ハンドブックの「プリンタの利用」をご覧ください. 私のシステムのキーボードマッピングは間違っています. kbdcontrol プログラムは, キーボードマップファイルを読み込むためのオプションを備えています. /usr/share/syscons/keymaps の下にたくさんのマップファイルがあります. システムに関連のあるものを一つ選んで, ロードしてください. &prompt.root; kbdcontrol -l uk.iso /usr/share/syscons/keymaps と拡張子 .kbd は, どちらも kbdcontrol によって使用されます. これは /etc/sysconfig(または rc.conf) 中で設定することができます. このファイル中にあるそれぞれのコメントを参照してください. FreeBSD 2.0.5R やそれ以降の版では, テキストフォントやキーボードマッピングに関係のあるものはすべて, /usr/share/examples/syscons の中におさめられています. 現在以下のマッピングがサポートされています. Belgian ISO-8859-1 Brazilian 275 keyboard Codepage 850 Brazilian 275 keyboard ISO-8859-1 Danish Codepage 865 Danish ISO-8859-1 French ISO-8859-1 German Codepage 850 German ISO-8859-1 Italian ISO-8859-1 Japanese 106 Japanese 106x Latin American Norwegian ISO-8859-1 Polish ISO-8859-2 (programmer's) Russian Codepage 866 (alternative) Russian koi8-r (shift) Russian koi8-r Spanish ISO-8859-1 Swedish Codepage 850 Swedish ISO-8859-1 Swiss-German ISO-8859-1 United Kingdom Codepage 850 United Kingdom ISO-8859-1 United States of America ISO-8859-1 United States of America dvorak United States of America dvorakx 起動時に, unknown: <PNP0303> can't assign resources というメッセージが表示されるのですが? このメッセージは, プラグアンドプレイ (Plug-and-Play) デバイスが検出されたが, 現在利用しているカーネルには対応するドライバがない, ということを示しています. 特に害はありません. このメッセージを表示させたくないと思われる方は, ぜひデバイスドライバを FreeBSD Project まで send-pr してください. ユーザディスククォータが正常に動作していないようです. / にはディスククォータを設定しないでください. クォータファイルが置かれるファイルシステム上に クォータファイルを置くようにしてください. Filesystem Quota file /usr /usr/admin/quotas /home /home/admin/quotas … … わたしの ccd は, 何が適合していない(Inappropriate)のでしょう? 次のような症状が現れます. &prompt.root; ccdconfig -C ccdconfig: ioctl (CCDIOCSET): /dev/ccd0c: Inappropriate file type or format 通常この現象はタイプを「未使用 (unused)」のまま放っておかれた c パーティションをつなげようとした場合に現れます. ccd ドライバは FS_BSDFFS タイプをベースとするパーティションを要求します. つなげようとしているディスクのディスクラベルを編集して, パーティションのタイプを 4.2BSD に変更してください. どうしてわたしの ccd のディスクラベルを変更することができないのでしょう? 次のような症状が現れます. &prompt.root; disklabel ccd0 (it prints something sensible here, so let's try to edit it) &prompt.root; disklabel -e ccd0 (edit, save, quit) disklabel: ioctl DIOCWDINFO: No disk label on disk; use "disklabel -r" to install initial label これは ccd から返されるディスクラベルが, 実はディスク上にはないまったくの偽の情報だからです. これを明示的に書き直すことで問題を解消できます, それには, つぎのようにします. &prompt.root; disklabel ccd0 > /tmp/disklabel.tmp &prompt.root; disklabel -Rr ccd0 /tmp/disklabel.tmp &prompt.root; disklabel -e ccd0 (this will work now) FreeBSD は System V の IPC プリミティブをサポートしますか? はい. FreeBSD は System-V スタイルの IPC をサポートします. 共有メモリ, メッセージ, セマフォが含まれます. 以下の行をカーネルコンフィグファイルに加えると, サポートが有効になります. options SYSVSHM # enable shared memory options SYSVSEM # enable for semaphores options SYSVMSG # enable for messaging FreeBSD 3.2 とそれ以降では, これらのオプションがあらかじめ GENERIC カーネルに含まれていますので, あなたのシステムにはすでに組み込まれています. カーネルを再構築してインストールしてください. UUCP でメールを配送するには sendmail をどう使えばよいのですか? FreeBSD に付属している sendmail は, インターネットに直接つながっているサイトにあわせて設定してあります. UUCP 経由で mail を交換したい場合には sendmail の設定ファイルを改めてインストールしなければなりません. /etc/sendmail.cf を自分の手で改造するのは純粋主義者のやるような事です. sendmail の version 8 は m4 のようなプリプロセッサを通して設定ファイルを生成する新しいアプローチを取っており, より抽象化されたレベルの設定ファイルを編集します. /usr/src/usr.sbin/sendmail/cf ディレクトリの中にある設定ファイルを使用してください. もしすべてのソースをインストールしていない場合には sendmail の設定ツールは, 別の tar ファイルにまとめてあります. CD-ROM が mount されている場合には, 次のようにしてください. &prompt.root; cd /cdrom/src &prompt.root; cat scontrib.?? | tar xzf - -C /usr/src contrib/sendmail これはたった数 100Kbyte ですから心配ないでしょう. cf ディレクトリにある README に, m4 での設定の基本的な説明があります. UUCP での配送のためには, mailertable を使用すれば よいでしょう. これによって, sendmail が配送方式を決定するデータベースを 作成することができます. まずはじめに, .mc ファイルを作成しなければなりません. /usr/src/usr.sbin/sendmail/cf/cf というディレクトリが, これらのファイルを作成する場所です. 既にいくつか例があると思います. これから作成するファイルの名前を foo.mc とすると, sendmail.cf を求めているような形式に変換するには, 次のようにしてください. &prompt.root; cd /usr/src/usr.sbin/sendmail/cf/cf &prompt.root; make foo.cf &prompt.root; cp foo.cf /etc/sendmail.cf 標準的な .mc ファイルは次のようになります. include(`../m4/cf.m4') VERSIONID(`Your version number') OSTYPE(bsd4.4) FEATURE(nodns) FEATURE(nocanonify) FEATURE(mailertable) define(`UUCP_RELAY', your.uucp.relay) define(`UUCP_MAX_SIZE', 200000) MAILER(local) MAILER(smtp) MAILER(uucp) Cw your.alias.host.name Cw youruucpnodename.UUCP nodns と nocanonify という指定をすることで, mail の配送に DNS を使用しなくなります. UUCP_RELAY という 行に関しては, ある理由から必要ですがそれは聞かないでください. .UUCP で終わる仮想ドメインを処理することのできるインターネット上での ホスト名をここに書いてください. 通常は, ISP の mail リレーホストを 書くことになると思います. これが終了したら, 次に /etc/mailertable というファイルが必要です. 標準的な例は次のとおりです. # # makemap hash /etc/mailertable.db < /etc/mailertable # horus.interface-business.de uucp-dom:horus .interface-business.de uucp-dom:if-bus interface-business.de uucp-dom:if-bus .heep.sax.de smtp8:%1 horus.UUCP uucp-dom:horus if-bus.UUCP uucp-dom:if-bus . uucp-dom: 見れば分かるように, これは実在する設定のファイルです. はじめの 3 行はドメイン名で指定されたメールが default の経路で配送されずに, 「近道」するために UUCP で隣りのサイトに送るための特別な状況を 処理するものです. 次の行は Ethernet でつながっているローカルのドメインに対しては SMTP で送るための設定です. 最後に, UUCP での隣りのサイトが. UUCP で終わる仮想ドメインの書式で 指定されており, default の rule を uucp-neighbour! recipient で上書きするためのものです. 一番最後の行はいつもドットを一つ書きます. これは, ここまでの行でマッチしなかったすべてのホストにマッチし, このサイトから世界に向けて出ていくための mail gateway に UUCP で配送するためのものです. uucp-dom: に続けて書かれているノード名は, uuname コマンドで指定することによって UUCP で直接配送される正しいノード名でなければなりません. 最後に, このファイルは使用する前に DBM データベースのファイルに 変換する必要があります. これを行なうコマンドラインは mailertable の最初のコメントに書いてあります. mailertable を変更した時には, 必ずこのコマンドを実行してください. 最後のヒントです: もし特定のメール配送がうまく作動するかどうか 確かめたい場合には, sendmail の オプションを 使用してください. このオプションによって sendmail は アドレステストモードで起動します. 0 の後に配送したいアドレスを書いてください. 最後の行に, 実際に使用される mail agent, この mail agent で送られる送信先のホスト, そして (多分変換されている) アドレスが表示されます. このモードを抜けるには Control-D を押してください. &prompt.user; sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > 0 foo@interface-business.de rewrite: ruleset 0 input: foo @ interface-business . de ... rewrite: ruleset 0 returns: $# uucp-dom $@ if-bus $: foo \ < @ interface-business . de > > ^D ダイアルアップでインターネットに接続する環境でメールをセットアップするにはどうやるの? 静的に IP アドレスが割り当てられる場合は, デフォルトの状態を変更する必要はありません. 割り当てられた名前をホストネームと するだけで, sendmail が後のことを引き受けてくれます. ダイアルアップ ppp をインターネット接続に使用し, 動的に IP アドレスが割り当てられる場合は, インターネットサービスプロバイダ(ISP)のメールサーバにメールボックスがあるはずです. ISP のドメインが myISP.com で, あなたのユーザ名が user だと仮定します. また, あなたが自分のマシンを bsd.home と呼んでおり, ISP が relay.myISP.com をメールリレーとして使用できると言っているとしましょう. メールボックスからメールを取ってくるためには, 回収(retrieval)エージェントをインストールする必要があります. Fetchmail は多種多様なプロトコルをサポートしているのでお勧めです. ISP が使用しているのは, 大抵 POP3 プロトコルです. ユーザ ppp を使用している場合, /etc/ppp/ppp.linkup に以下のように記述すると, インターネットと接続が完了した時点で自動的にメールを取得するようになります. MYADDR: !bg su user -c fetchmail ローカルでないアカウントにメールを配送するのに sendmail を使用している場合(後述), 上に示したエントリの後に !bg su user -c "sendmail -q" を記述します. これはネットワーク接続が確立したらすぐに sendmail に溜っている mailqueue を強制的に処理させるようにします. この例では, user が bsd.home にアカウントを持ち, bsd.home 上の user のホームディレクトリに, 以下のような .fetchmailrc ファイルがつくられていることを想定しています. poll myISP.com protocol pop3 fetchall pass MySecret; 言うまでもなく, このファイルは user 以外のユーザが読むことが出来ないようにしなくてはなりません. 内容にパスワード MySecret が含まれているからです. 正しい from: ヘッダをつけてメールを送るためには, sendmail に user@bsd.home ではなく user@myISP.com を使用するよう教える必要があります. メールをより早く転送するために, 全てのメールを relay.myISP.com へ送るように sendmail に 指示しておくのも良いでしょう. 上の要件を満たすには, 以下のような .mc ファイルが適しています. VERSIONID(`bsd.home.mc version 1.0') OSTYPE(bsd4.4)dnl FEATURE(nouucp)dnl MAILER(local)dnl MAILER(smtp)dnl Cwlocalhost Cwbsd.home MASQUERADE_AS(`myISP.com')dnl FEATURE(allmasquerade)dnl FEATURE(masquerade_envelope)dnl FEATURE(nocanonify)dnl FEATURE(nodns)dnl define(`SMART_HOST', `relay.myISP.com') Dmbsd.home define(`confDOMAIN_NAME',`bsd.home')dnl define(`confDELIVERY_MODE', `deferred')dnl .mc ファイルから sendmail.cf への変換方法については, 前のセクションを参照してください. sendmail.cf を更新した後に sendmail をリスタートするのもお忘れなく. しまった! root のパスワードを忘れてしまった! 慌てないでください! 単にシステムを再起動し, シングルユーザモードに移るために Boot: と表示されるプロンプトで boot -s と入力してください. (FreeBSD の 3.2 より前のリリースでは -sとなります. ) どのシェルを使うのかという質問には, ENTER キーを押してください. &prompt.root; に移ることができるでしょう. mount -u / と入力して ルートファイルシステムの読み書きを再マウントし, mount -a と入力して, すべてのファイルシステムをマウントし直した後, passwd root と入力して root のパスワードを設定し直してください. その後, exit と入力すれば, 起動が続けられます. Control-Alt-Delete でシステムが再起動しないようにするにはどうすればいい? FreeBSD 2.2.7-RELEASE 以降で syscons(デフォルトのコンソールドライバ) を使用している場合には, 次の行をカーネルコンフィグレーションファイルに追加して カーネルを再構築し, インストールしてください. options SC_DISABLE_REBOOT FreeBSD 2.2.5-RELEASE 以降で PCVT コンソールドライバを使用している 場合には, 同様に次の行をカーネルコンフィグレーションファイルに追加して カーネルを再構築し, インストールしてください. options PCVT_CTRL_ALT_DEL 上にあげたものよりも古い FreeBSD の場合, 現在コンソールが使用しているキーマップを編集し, キーワード boot を nop に書き換えてください. /usr/share/syscons/keymaps/us.iso.kbd にあります. その変更を反映させようとして, このキーマップのロードを明示的に行なうために, /etc/rc.conf を実行すべきかもしれません. もちろん他の国のキーマップを使っているのであれば, 代わりにそのキーマップファイルを編集してください. DOS のテキストファイルを UNIX のテキストファイルに整形するにはどうすればいい? 単に次の perl コマンドを実行してください. &prompt.user; perl -i.bak -npe 's/\r\n/\n/g' file ... file の部分には処理するファイルを指定してください. 整形後のファイルは元のファイル名で作成され, 整形前のファイルはバックアップとして元の ファイル名の末尾に拡張子 .bak のつけられた名前で作成されます. あるいは tr(1) コマンドを使うこともできます. &prompt.user; tr -d '\r' < dos-text-file > unix-file dos-text-file は DOS 形式のテストファイル, unix-file には変換された出力が格納されます. perl を使うよりほんのちょっぴり速くなります. 名前で指定してプロセスにシグナルを送るにはどうすればいい? killall(1) を使ってください. su が not in root's ACL と言って私を悩ませるのはなぜ? Kerberos の認証システムからくるエラーです. この問題は致命的なものではなく, うっとおしいといったものです. su に オプションをつけて起動するか, 次の質問で説明されている方法で Kerberos をアンインストールしてください. Kerberos をアンインストールするにはどうすればいいの? システムから Kerberos を削除するには, あなたの動かしているリリースの bin ディストリビューションを再インストールしてください. もし CDROM を持っているのなら, その CDROM をマウント(マウントポイントは /cdrom と仮定)して, 次のように入力してください. &prompt.root; cd /cdrom/bin &prompt.root; ./install.sh 疑似ターミナルを追加するには? telnet, ssh, X, screen をたくさん利用されている場合, 疑似ターミナルが足りなくなっている可能性があります. これを増やすには次のようにします. 次の行をカーネルコンフィグレーションファイルに追加して pseudo-device pty 256 新たにカーネルを作りインストールします. 次のコマンドを実行して &prompt.root; cd /dev &prompt.root; ./MAKEDEV pty{1,2,3,4,5,6,7} 新たなターミナル用の 256 個のデバイスノードを作ります. /etc/ttys を編集し 256 個のターミナルごとの定義を追加します. 既存のエントリーの形式にあわせる必要があるでしょう. 例えばこんな感じです. ttyqc none network 正規表現を使った指定は tty[pqrsPQRS][0-9a-v] となります. 新しいカーネルでシステムを再起動すると完了です. snd0 デバイスを作成することができません! snd というデバイスは存在しません. この名前は, FreeBSD サウンドドライバによって作成されるさまざまなデバイス, mixer や sequencer, dsp などを総称したものです. これらのデバイスを作成するには, 次のようにする必要があります. &prompt.root; cd /dev &prompt.root; sh MAKEDEV snd0 再起動せずにもう一度 /etc/rc.conf を読み込んで /etc/rc を開始させるには? シングルユーザモードに移行して, マルチユーザモードに戻ってください. コンソールで次のように実行します. &prompt.root; shutdown now(注: や は付けません) &prompt.root; return &prompt.root; exit 砂場(sandbox)とは何ですか? 砂場(Sandbox) とはセキュリティ用語の一つで, 次の二つの意味があります. 一つ目は, 「仮想的な『防壁』で囲まれているプロセス」です. その『防壁』は, そのプロセスに侵入した第三者が, さらにシステムの広い範囲に影響を与えることを防ぐように設計されます. このプロセスの振舞いは, 『防壁』の中だけに制限される, と表現できます. つまり, このプロセスにおいて, 『防壁』を越えるようなコードの実行は できないという意味です. そのため, コードの実行におけるセキュリティは 確かなものであると保証でき, 実行の詳細な追跡を行なう必要はなくなります. その『防壁』とは, 例えばユーザ ID がそれにあたるでしょう. この定義は, security(7) や named(8) のマニュアルページで用いられています. ntalk サービス(/etc/inetd.conf 参照のこと)を例にとってみます. このサービスはかつて, 実行時の ユーザ ID として root を用いていましたが, 現在では tty というユーザ ID で動作します. ユーザ tty は, ntalk を経由してシステムの侵入に成功した第三者が そのユーザ ID 以上の権限を得ることを, より一層困難にするために設計された砂場(sandbox)なのです. 二つ目は「シミュレートされたマシンの内側で実行されるプロセス」のことで, こちらはより中核的です. 普通に考えれば, あるプロセスに侵入することができる第三者は, マシンのより広い範囲にも侵入できると信じるものなのですが, この種のプロセスの場合, それは実際にはシミュレートされたマシンに 侵入しただけなので, 現実のデータを変更することは何一つできません. これを実現するための最も広く用いられている方法は, シミュレートされた環境をサブディレクトリに構築し, そのディレクトリに chroot して, そのディレクトリで プロセスを実行すること(つまり, そのプロセスにとって / は システムの実際のルートディレクトリ / ではなく, chroot されたサブディレクトリを指す)です. 広く用いられているもう一つの方法があります. それは, 既に存在しているファイルシステムを 読み込み専用(read-only)でマウントし, その上に, あるプロセスに対して そのファイルシステムが書き込み可能であるように見せるような, もう一つのファイルシステムの層を用意するものです. すると, そのプロセスはファイルを書き込むことができると認識し, 実際に書き込むことができるのもその特定のプロセスだけ - システムにある他のプロセスは書き込めないのに対して - であるという状況を実現することができます. この種の砂場(sandbox)は, その非常に透過的な性質を使って, ユーザ(もしくは侵入者)が その事実に気付かないように実現されます. UNIX は, 内部的に二つの砂場(sandbox)を実装しています. 一つはプロセスレベルのもの, もう一つはユーザ ID レベルのものです. UNIX プロセスは全て, 他の UNIX プロセスから完全に隔離されています. どのプロセスも, 他のプロセスのアドレス空間を変更することはできません. これは, あるプロセスが他のプロセスのアドレス空間を上書きできるような, クラッシュにつながる行為が容易に実現できる Windows とは全く異なるものです. UNIX プロセスは, 特定のユーザ ID が所有します. もし, 実行者のユーザ ID が root ユーザのものでなければ, ユーザ ID は, 他のユーザが所有するプロセスから そのプロセスを守る機能を果たすわけです. また, そのユーザ ID は, ディスク上にあるデータを 保護するのにも使われています. セキュアレベル (securelevel) って何ですか? セキュアレベルとはカーネルに実装されているセキュリティ機構の一つです. 簡単に言うと, カーネルはセキュアレベルが正の値の時に, ある特定の操作を制限します. この制限は, たとえスーパユーザ (root のこと) であっても例外ではありません. この文を書いている時点では, セキュアレベル機構を使って以下のような操作を制限することができます. schg (system immutable flag) のようなファイルフラグの変更 /dev/mem および /dev/kmem 経由でのカーネルメモリへの書き込み カーネルモジュールのロード &man.ipfirewall.4; ルールの変更 稼働中のシステムでセキュアレベルの状態をチェックするには, 次のコマンドを実行します. &prompt.root; sysctl kern.securelevel 出力には, &man.sysctl.8; 変数 (今の場合は kern.securelevel) と数字が現れます. 数字が現在のセキュアレベルの値です. これがもし正の値なら, 何らかのセキュアレベルによる制限が有効になっています. システム稼働中にセキュアレベルを下げることはできません. これは, それを可能にするとセキュアレベルの意味がなくなってしまうからです. セキュアレベルが正の値でないことを要求する操作 (たとえば installworld や日付の変更など) を行なう必要がある場合は, /etc/rc.conf にあるセキュアレベルの設定 (kern_securelevel と kern_securelevel_enable という変数) を変更して再起動する必要があります. セキュアレベルに関する詳しい情報や, 各レベルで実現される機能に関しては &man.init.8; のマニュアルページを参照してください. セキュアレベルは万能というわけではなく, 弱点も数多く存在します. また, 場合によっては, セキュリティを低下させてしまうこともあります. 最も大きな問題の一つに, セキュアレベルの機能を有効にするには, 起動処理でセキュアレベルが設定されるまでに使われるすべてのファイルを 保護する必要があるということがあります. もし攻撃者が, システムがセキュアレベルを設定する前にコードを実行することができるとしたら, セキュアレベルによる保護は無意味になってしまいます (起動時には低いセキュアレベルでしか実行できない処理を行なう必要があるため, セキュアレベルの設定は, 起動処理の最後の方で行なわれます). 起動処理で使われるすべてのファイルを保護することは技術的に不可能です. もしそうできたとしても, システムの保守はまさに悪夢となるでしょう. 設定ファイル一つ書き換えるのにも, シングルユーザモードに切替えなければならなくなるのですから. 以上で説明した内容やその他の点については, メーリングリストでも良く話題にのぼります. 議論のようすをこのページから検索してみてください. セキュアレベルは, いずれより粒度の細かい機構にとって代わるだろうと考えている人々もいますが, その点についてはまだ不透明なままです. どうか注意するようにしてください. フロッピーや CDROM や他のリムーバブルメディアのマウントを一般ユーザーに許可するには? 一般ユーザーでもデバイスをマウントできるようにすることができます. 手順は次のとおりです. root になって, sysctl 変数である vfs.usermount を 1 に設定します. &prompt.root; sysctl -w vfs.usermount=1 root になって, リムーバブルメディアに関連するブロックデバイスに適切なパーミッションを設定します. 例として, 最初のフロッピーデバイスをユーザーがマウントできるようにするには, 次のようにします. &prompt.root; chmod 666 /dev/fd0 operator グループに所属するユーザが CDROM ドライブをマウントできるようにするには 以下のようにします. &prompt.root; chgrp operator /dev/cd0c &prompt.root; chmod 640 /dev/cd0c 最後に vfs.usermount=1 という行を /etc/sysctl.conf ファイルに追加し, ブート時にセットされるようにしておきます. これで, すべてのユーザは フロッピー /dev/fd0 を 自身の所有するディレクトリへマウントすることができます. &prompt.user; mkdir ~/my-mount-point &prompt.user; mount -t msdos /dev/fd0 ~/my-mount-point これで, operator グループに所属するユーザは CDROM /dev/cd0c を 自身の所有するディレクトリへマウントすることができます. &prompt.user; mkdir ~/my-mount-point &prompt.user; mount -t msdos /dev/cd0c ~/my-mount-point デバイスのアンマウントは簡単です. &prompt.user; umount ~/my-mount-point しかし, vfs.usermount を有効にすることは, セキュリティ上よいことではありません. MSDOS 形式のメディアにアクセスには, Ports コレクションにある パッケージ mtools を使用した方がよいでしょう. システムを新しい巨大ディスクへ移すにはどうするのですか ? 一番良いのは新しいディスクに OS を再インストールして, それからユーザデータを移すことです. 特にあなたが -stable を 複数のリリースを跨いで追い掛けている場合にはこの方法をおすすめします. あなたは &man.boot0cfg.8; を使うことで booteasy を両方の ディスクにインストールでき, 新しい配置で満足している間 デュアルブートができます. これを行ったあとデータを移す 方法を探すなら次の段落は読み飛ばしてください. 何もないディスクへインストールしないことに決めたならば /stand/sysinstall, なり &man.fdisk.8; と &man.disklabel.8; なりを使って新しいディスクに パーティションとディスクラベルを作らなければなりません. また &man.boot0cfg.8; で booteasy を両方のディスクに インストールして, コピーの作業が終わったあとに 古いシステムからでも新しいディスクからでも起動できるように しておく必要があります. この作業の詳細は formatting-media tutorial を見てください. 新しいディスクの立ち上げが終わってデータの移動を 待つばかりになりました. しかし悲しいかな, 無闇やたらと コピーすればいいというものではありません. デバイスファイル (/dev) やシンボリックリンクなどは 失敗の元になります. これらを理解するツール, すなわち &man.dump.8; や &man.tar.1; 等を使う必要があります. わたしはデータの移転をシングルユーザで行うことを勧めますが 絶対と言うわけではありません. あなたは &man.dump.8; と &man.restore.8; 以外のもので root ファイルシステムを移行してはなりません. &man.tar.1; コマンドでもたぶんうまく行くでしょうが, やらないほうがいいでしょう. パーティション一つを もう一つのからのパーティションに移すときは &man.dump.8; と &man.restore.8; 使うべきです. パーティションのデータを新しいパーティションに移すのに dump を使うやり方は以下の通りです. 新しいパーティションに newfs をかける. それを暫定的なマウントポイントにマウントする. そのディレクトリに cd. 古いパーティションを dump し, その出力をパイプで新しい方へ. たとえば root を /dev/ad1s1a へ, 暫定的なマウントポイントを /mnt として移そうとすると以下のようになります. &prompt.root; newfs /dev/ad1s1a &prompt.root; mount /dev/ad1s1a &prompt.root; cd /mnt &prompt.root; dump 0uaf - / | restore xf - もしパーティションの構成を変えようと思っているなら - つまり一つだったものを二つにしたり二つだったものをくっつけたり しようとしているなら, 自前であるディレクトリ以下のすべてを 新しい場所へ移す必要が出てくるかも知れません. &man.dump.8; は ファイルシステムに働くのでこの目的には使えません. この場合は &man.tar.1; を使います. 一般に /old から /new への移動は &man.tar.1; で 以下のようにします. &prompt.root; (cd /old; tar cf - .) | (cd /new; tar xpf -) /old に他のファイルシステムが マウントされていて, そのデータの移動までは考えてないならば 最初の &man.tar.1; に 'l' フラグを追加します. &prompt.root; (cd /old; tar clf - .) | (cd /new; tar xpf -). tar のかわりに cpio(1) や pax(1), cpdup (ports/sysutils/cpdup) 等を 使っても構いません. システムを最新の -STABLE にアップデートしようとしたのですが -RC や -BETA になってしまいました! 何が起こったのですか? 短い答え: ただの名前です. RC は リリース候補 (Release Candidate) に 由来するもので, リリースが間近であることを意味します. また, FreeBSD における -BETA は通常, リリース前のコードフリーズ期間に入っているという意味になります. 長い答え: FreeBSD はそのリリースを 2 ヶ所あるうちの 一方から派生させます. 3.0-RELEASE や 4.0-RELEASE の様な (0 のマイナー番号を持つ) メジャーリリースは, 一般に -CURRENT と呼ばれる 開発版の流れから分岐させられてできます. 3.1-RELEASE や 4.2-RELEASE などのマイナーリリースはアクティブな -STABLE ブランチ (枝) の スナップショットです. リリースを作る時になるとそれを分岐させるブランチは 特定のプロセスへ突入します. そのプロセスの一つは コードフリーズ (コードの凍結) です. コードフリーズが 始まると, そのブランチの名前がリリースになろうとしていることを 反映するものに変えられます. たとえば, 4.0-STABLE と 呼ばれていたブランチは名前が 4.1-BETA へと 変えられ, コードフリーズとリリース前のテストが 始まったことを示します. バグの修正はリリースの一部としてコミットされます. ソースコードがリリースの形を取ったなら名前が 4.1-RC へと 変えられ, それからリリースが作られることを示します. ひとたび RC のステージになってしまうと, 発見された もっとも致命的なバグの修正しかできなくなります. ひとたびリリースが (この例では 4.1-RELEASE) 作られれば, そのブランチは 4.1-STABLE と改名されます. 新しいカーネルを入れようとしたのですが, chflags に失敗します. どうすれば良いのでしょう? 簡単な回答: 多分, セキュアレベルが 0 より大きくなっているのでしょう. 直接シングルユーザモードで再起動して, カーネルをインストールしてください. 詳しい回答: FreeBSD では, セキュアレベルが 0 より大きい場合, システムフラグの変更が禁止されます. 現在のセキュアレベルは, 次のコマンドを使って調べることができます. &prompt.root; sysctl kern.securelevel セキュアレベルを下げる操作は, できないようになっています. そのため, カーネルをインストールするには, シングルユーザモードで起動するか, /etc/rc.conf のセキュリティ設定を変更して再起動する必要ばあります. セキュアレベルの詳細は &man.init.8; を, rc.conf の詳細は /etc/defaults/rc.conf および, &man.rc.conf.5; のマニュアルページをご覧ください. システムの時刻を 1 秒以上変更することができないのです! どうすれば良いのでしょう? 簡単な回答: 多分, セキュアレベルが 1 より大きくなっているのでしょう. 直接シングルユーザモードで再起動して, 時刻の変更をしてください. 詳しい回答: FreeBSD では, セキュアレベルが 1 より大きい場合, 1 秒以上の時刻変更が禁止されます. 現在のセキュアレベルは, 次のコマンドを使って調べることができます. &prompt.root; sysctl kern.securelevel セキュアレベルを下げる操作は, できないようになっています. そのため, システムの時刻を変更するには, シングルユーザモードで起動するか, /etc/rc.conf のセキュリティ設定を変更して再起動する必要ばあります. セキュアレベルの詳細は &man.init.8; を, rc.conf の詳細は /etc/defaults/rc.conf および, &man.rc.conf.5; のマニュアルページをご覧ください. &man.rpc.statd.8; にメモリリークを見つけました! メモリを 256 メガバイトも使っています. いいえ. それはメモリリークではありませんし, 256 メガバイトのメモリを使っている, ということでもありません. おそらく (ほとんどの場合), 処理に都合が良いように非常にたくさんの量のメモリを そのプロセスのアドレス空間にマッピングしているのでしょう. 技術的な見地から考えても, これは大きな害があることではなく, 単に &man.top.1; や &man.ps.1; といったツールの表示に影響がある程度です. &man.rpc.statd.8; は, (/var にある) ステータスファイルを自分のアドレス空間にマッピングします. マッピングは, 後で大きな空間が必要になった時に再マッピングしないで済むよう, 非常に大きなサイズを指定して行なわれます. これは, ソースコードに含まれる &man.mmap.2; 関数のマッピング長を示す引数に 0x10000000 が指定されていることからも分かります. この数字が IA32 アーキテクチャの持つアドレススペース全体の 16 分の 1, すなわち, ちょうど 256 メガバイトに相当するのです. X Window System と仮想コンソール 訳: &a.motoyuki; 1997 年 11 月 13 日. X を動かしたいのですが, どうすればいいのですか? もっとも簡単な方法は FreeBSD のインストールの際に X を動かすことを指定するだけです. それから xf86config ツールのドキュメントを読んでこれに従ってください. このツールはあなたのグラフィックカードやマウスなどに合わせて XFree86(tm) の設定を行うのを助けてくれます. Xaccel サーバーについて調べてみるのもいいでしょう. 詳しくは Xi Graphics について か Metro Link をご覧ください. X を実行しようとして startx と入力したのですが, KDENABIO failed (Operation not permitted) というエラーが表示されます. 何かおかしなことをやってしまったんでしょうか? あなたのシステムは高いセキュアレベルで運用されていますね? 実は, 高いセキュアレベルで X を起動することはできないのです. どうしてなのかについては, &man.init.8; のマニュアルページに書かれています. では, 代わりにどうすれば良いのかお答えしましょう. 基本的に 2 つの方法があります. 一つはセキュアレベルを 0 にする (通常, これは /etc/rc.conf で指定します) こと, もう一つは起動時 (セキュアレベルを上げる前) に &man.xdm.1; を実行するかです. 起動時に &man.xdm.1; を実行する方法の詳細については, を参照してください. 私のマウスはなぜ X で動かないのでしょうか? syscons (デフォルトのコンソールドライバ) を使っているのであれば, それぞれの仮想スクリーンでマウスポインターをサポートするように FreeBSD を設定できます. X でのマウスの衝突を避けるために, syscons は /dev/sysmouse という仮想デバイスをサポートしています. 本物のマウスデバイスから入力された全てのマウスのイベントは, moused を経由して sysmouse デバイスへ出力されます. 一つ以上の仮想コンソールと X の 両方で マウスを使いたい場合, を参照して moused を設定してください. そして, /etc/XF86Config を編集し, 次のように書かれていることを確認してください. Section Pointer Protocol "SysMouse" Device "/dev/sysmouse" ..... 上の例は, XFree86 3.3.2 以降の場合の例です. それより前のバージョンでは, Protocol という部分を MouseSystems と置き換える必要があります. X で /dev/mouse を使うのを好む人もいます. この場合は, /dev/mouse を /dev/sysmouse にリンクしてください. &prompt.root; cd /dev &prompt.root; rm -f mouse &prompt.root; ln -s sysmouse mouse わたしのマウスにはホイール機能が付いているのですが, X で使うことはできますか? はい, もちろん使えますが, そのためには X クライアントプログラムを適切に設定する必要があります. これについては, Colas Nahaboo 氏のウェブページ(http://www.inria.fr/koala/colas/mouse-wheel-scroll/) を参照してください. imwheel というプログラムを使う場合は, 次のような簡単な手順にしたがってください. ホイールイベントの変換 imwheel は, マウスのボタン 4, ボタン 5 をキー押下イベントに変換するプログラムです. そのためホイールマウスで利用するには, マウスホイールのイベントをボタン 4, ボタン 5 のイベントに変換するマウスドライバを利用する必要があります. この変換を行なうには二つの方法があります. 一つは &man.moused.8; で行なう方法, 二つめは X サーバ自身に変換を行なわせる方法です. ホイールイベントの変換に &man.moused.8; を使う &man.moused.8; にイベントを変換させるには, &man.moused.8; 起動時にオプション を追加します. たとえば, 普段 &man.moused.8; を moused -p /dev/psm0 として起動しているなら, その代わりに moused -p /dev/psm0 -z 4 とします. もし, /etc/rc.conf を使って自動的に起動するように設定しているなら, /etc/rc.conf の中の moused_flags という変数に を追加するだけです. そして, 5 ボタンマウスを使うことを X サーバに伝える必要があります. これを行なうには /etc/XF86Config の Pointer セクションに Buttons 5 という行を追加するだけです. そうすると /etc/XF86Config の Pointer は, たとえば次のようになるでしょう. moused による変換を利用してホイールマウスを使用するための XF86Config の <quote>Pointer</quote> セクションの設定例 Section "Pointer" Protocol "SysMouse" Device "/dev/sysmouse" Buttons 5 EndSection X サーバを使ったホイールイベントの変換 &man.moused.8; を起動していなかったり, ホイールイベントの変換に &man.moused.8; を起動したくない場合には, その代わりに X サーバを使うことができます. これには, /etc/XF86Config ファイルを書き換える必要があります. まず最初に必要なのは, マウスがどのプロトコルを使っているのかを確認することです. ほとんどのホイールマウスは IntelliMouse プロトコルを使用していますが, XFree86 サーバはその他のプロトコル, たとえば Logitech MouseMan+ マウスが利用している MouseManPlusPS/2 プロトコルなどもサポートしています. 使用されているプロトコルが確認できたら Pointer セクションに Protocol の行を追加してください. つぎに, ホイールのスクロールイベントをマウスボタン 4, マウスボタン 5 に割り当てることを X サーバに伝えます. これを行なうには ZAxisMapping オプションを使用します. たとえば, &man.moused.8; が起動していない状態で, PS/2 マウスポートに IntelliMouse が接続されているとしたら /etc/XF86Config はおそらく次のようになります. X サーバによる変換を利用してホイールマウスを使用するための XF86Config の <quote>Pointer</quote> セクションの設定例 Section "Pointer" Protocol "IntelliMouse" Device "/dev/psm0" ZAxisMapping 4 5 EndSection imwheel のインストール さて, つぎに Ports Collection から imwheel をインストールします. これがあるのは x11 カテゴリです. このプログラムは, マウスイベントをキーボードイベントに変換します. たとえば, マウスホイールを前に回した時, imwheel は PageUp をアプリケーションプログラムに送るような動作をするわけです. Imwheel はホイールイベントとキーボード押下の対応を設定ファイルを使って設定するため, アプリケーション毎に異なる対応を持たせることも可能です. imwheel のデフォルトの設定ファイルは /usr/X11R6/etc/imwheelrc にインストールされます. これを ~/.imwheelrc にコピーして編集し, お好きなように imwheel で利用したいアプリケーションの設定をカスタマイズしてください. 設定ファイルの書式は &man.imwheel.1; に説明されています. Emacs で Imwheel を使うように設定する (必須ではありません) emacs や Xemacs で利用するには, ~/.emacs にいくらか書き加える必要があります. emacs の場合は次の部分を追加してください. <application>Imwheel</application> を利用するための <application>Emacs</application> の設定例 ;;; For imwheel (setq imwheel-scroll-interval 3) (defun imwheel-scroll-down-some-lines () (interactive) (scroll-down imwheel-scroll-interval)) (defun imwheel-scroll-up-some-lines () (interactive) (scroll-up imwheel-scroll-interval)) (global-set-key [?\M-\C-\)] 'imwheel-scroll-up-some-lines) (global-set-key [?\M-\C-\(] 'imwheel-scroll-down-some-lines) ;;; end imwheel section Xemacs の場合は ~/.emacs に次の部分を追加してください. <application>Imwheel</application> を利用するための <application>XEmacs</application> の設定例 ;;; For imwheel (setq imwheel-scroll-interval 3) (defun imwheel-scroll-down-some-lines () (interactive) (scroll-down imwheel-scroll-interval)) (defun imwheel-scroll-up-some-lines () (interactive) (scroll-up imwheel-scroll-interval)) (define-key global-map [(control meta \))] 'imwheel-scroll-up-some-lines) (define-key global-map [(control meta \()] 'imwheel-scroll-down-some-lines) ;;; end imwheel section Imwheel の実行 インストールが完了していれば, 単に xterm(訳注: 日本語環境で広く使われている kterm でも構いません)から imwheel を入力するだけで起動できます. 起動するとバックグラウンドで動作し, すぐに利用できます. imwheel をいつも使うように設定するには, .xinitrc か .xsession のファイルにそのままコマンドを追加してください. imwheel が PID ファイルに関する警告を表示するかも知れませんが, 無視しても危険はありません. この警告が意味を持つのは, Linux 版の imwheel だけです. X のメニューやダイアログボックスがうまく動きません. Num Lock キーをオフにしてください. Num Lock キーがデフォルトで起動時にオンになる場合は, XF86Config ファイルの Keyboard セクションに以下の行を加えてもいいでしょう. # Let the server do the NumLock processing. This should only be # required when using pre-R6 clients ServerNumLock 訳注 この問題は XFree86 3.2 以降では解決しています. 仮想コンソールとは何ですか? どうやったら使えますか? 仮想コンソールは, 簡単にいうと, ネットワークや X を動かすなどの複雑なことを行なわずに, いくつかのセッションを同時に行なうことを可能にします. システムのスタート時には, 起動メッセージが出た後に login プロンプトが表示されます. そこで ログイン名とパスワードを入力すると 1 番目の仮想コンソール上で仕事(あるいは遊び)を始めることができます. 他のセッションを始めたい場合もあるでしょう. それは動かしているプログラムのドキュメントを見たり, FTP の転送が終わるまで待つ間, メールを読もうとしたりすることかもしれません. Alt-F2 を押す(Alt キーを押しながら F2 キーを押す) と, 2 番目の「仮想コンソール」で ログインプロンプトが待機していることがわかります. 最初のセッションに戻りたいときは Alt-F1 を押します. 標準の FreeBSDインストールでは, 3 枚(3.3-RELEASE では 8 枚)の仮想コンソールが有効になっていて, Alt-F1, Alt-F2, Alt-F3 で仮想コンソール間の切替えを行ないます. より多くの仮想コンソールを有効にするには, /etc/ttys を編集して Virtual terminals のコメント行の後に ttyv4 から ttyvc の手前までのエントリを加えます(以下の例は先頭には空白は入りません). # /etc/ttys には ttyv3 がありますので # "off" を "on" に変更します. ttyv3 "/usr/libexec/getty Pc" cons25 on secure ttyv4 "/usr/libexec/getty Pc" cons25 on secure ttyv5 "/usr/libexec/getty Pc" cons25 on secure ttyv6 "/usr/libexec/getty Pc" cons25 on secure ttyv7 "/usr/libexec/getty Pc" cons25 on secure ttyv8 "/usr/libexec/getty Pc" cons25 on secure ttyv9 "/usr/libexec/getty Pc" cons25 on secure ttyva "/usr/libexec/getty Pc" cons25 on secure ttyvb "/usr/libexec/getty Pc" cons25 on secure 多くするか少なくするかはあなたの自由です. より多くの仮想ターミナルを使うとより多くのリソースを使うことになります. 8MB 以下のメモリしかない場合はこれは重要な問題です. もし必要があれば secure を insecure に変更してください. X を使いたいのであれば, 最低一つの仮想ターミナル(のエントリ)を使わずに残しておくか, off にしておく必要があります. つまり, 12 個の Alt-ファンクションキー全てでログインプロンプトを 出したいのならば, 残念ながら X は利用できないということです. 同じマシンで X サーバーも動かしたいのならば 11 個しか使えません. 仮想コンソールを無効にするもっとも簡単な方法は, コンソールを off にすることです. 例えば 12 個全てのターミナルを割り当てている状態で X を動かしたいときは, 仮想ターミナル 12 を変更します. ttyvb "/usr/libexec/getty Pc" cons25 on secure これを次のように変更します. ttyvb "/usr/libexec/getty Pc" cons25 off secure キーボードにファンクションキーが 10 個しかないのであれば, 次のように設定します. ttyv9 "/usr/libexec/getty Pc" cons25 off secure ttyva "/usr/libexec/getty Pc" cons25 off secure ttyvb "/usr/libexec/getty Pc" cons25 off secure (これらの行を消すだけでもいいです.) /etc/ttys を編集したら, 次は十分な数の仮想ターミナルデバイスを作らなくてはなりません. もっとも簡単な方法を示します. &prompt.root; cd /dev &prompt.root; ./MAKEDEV vty12(12 個のデバイスをつくる場合) さて, 仮想コンソールを有効にするもっとも簡単(そして確実)な方法は, 再起動することです. しかし, 再起動したくない場合は, X ウィンドウシステムを終了させて次の内容を(root 権限で)実行します. &prompt.root; kill -HUP 1 重要な点は, このコマンドを実行する前に X ウィンドウシステムを完全に終了させておくことです. もしそうしないと kill コマンドを実行した後, システムはおそらくハングアップするでしょう. X から仮想コンソールに切替えるにはどうすればよいのですか? 仮想コンソールへ戻るには Ctrl Alt Fn を使ってください. 最初の仮想コンソールへは Ctrl Alt F1 で戻れます. テキストコンソールへ移った後は, その中で移動するのに 今度はいつもどおり Alt Fn を使ってください. X のセッションへ戻るには X の走っている仮想コンソールへ 切り替える必要があります. もしあなたが X をコマンドラインから 実行していたのであれば (たとえば startx を使う) X のセッションはそれを実行したテキストコンソールではなく 最初の使われていない仮想コンソールに割り当てられているはずです. あなたが仮想端末を 8 個用意している場合は X を 9 番目の コンソールにいるはずで, Alt F9 を使うことになります. 訳注 X に戻るには, 3 枚の仮想コンソールが有効になっている場合は Alt-F4 です. 有効な仮想コンソールの数 +1 のファンクションキーの 位置に X が割り当てられます. XDM を起動時に起動させるにはどうしますか? xdm の起動方法について, その考え方には二つの流派があります. ある流派では提供された例を使用して xdm を /etc/ttys から起動し, 他の流派では xdm を単に rc.local または /usr/local/etc/rc.d にある X.sh スクリプトから起動します. どちらも正しく, 片方が動作しない場合は, もう片方が動作するでしょう. どちらも場合でも結果は同じであり, X はグラフィカルな login: プロンプトを表示します. ttys を利用する方法の利点は, どの vty で X が起動したかの記録が残せることと, ログアウト時に X サーバを再起動する責任を init に押しつけることができることでしょう. rc.local からロードされる場合, xdm は引数を持たずに(すなわち, デーモンとして)起動します. xdm は getty が起動した後にロードされなければなりません. そうでないと, xdm は getty と衝突し, コンソールをロックアウトしてしまいます. この問題に対処する最善の方法は, 起動スクリプト(訳注: rc.local のこと)で 10 秒ほどの sleep を実行させ, その後に xdm をロードすることです. /etc/ttys から xdm を起動させている場合には, xdm と getty が衝突する可能性があります. この問題を回避するには, /usr/X11R6/lib/X11/xdm/Xservers に vt 番号を追加してください. :0 local /usr/X11R6/bin/X vt4 上の例は, /dev/ttyv3 を X サーバに対応させます. 番号は 1 から始まりますので注意してください. X サーバは vty を 1 から数えますが, FreeBSD カーネルは vty を 0 から数えます. xconsole を動かそうとすると Couldn't open console とエラーが出ます. X を startx で起動しますと, /dev/console のパーミッションは 変更ができないようになっていますので, xterm -C や xconsole は動きません. これはコンソールのパーミッションが, 標準ではそのように設定されているからです. マルチユーザシステムでは, ユーザの誰もがシステムコンソールに書き込むことが可能である必要は必ずしもありません. VTY を使い直接マシンにログインするユーザのために, このような問題を解決するために fbtab というファイルがあります. 要点を述べると, 次のような形式の行を fbtab に加えます. /dev/ttyv0 0600 /dev/console そうすると, /dev/ttyv0 からログインしたユーザが コンソールを所有することになるでしょう. わたしはいつも XFree86 を一般ユーザから起動していたのですが, 最近になって root ユーザでなければならないと言われるようになりました. すべての X サーバは, ビデオハードウェアに直接アクセスするために root ユーザで実行される必要があります. 古いバージョンの XFree86 (<= 3.3.6) に含まれるすべてのサーバは, 自動的に root 権限で実行されるように (root ユーザに setuid されて) インストールされます. X サーバは大きく複雑なプログラムであり, これは明らかにセキュリティを危険に晒す要因となります. そのため新しいバージョンの XFree86 では, サーバを root ユーザに seruid しないでインストールするようになりました. X サーバを root ユーザで動かすというのは, 明らかにセキュリティ的に不適当で受け入れられないことです. X を一般ユーザで実行するには, 二つの方法があります. 一つは xdm や, その他のディスプレイマネージャ (たとえば kdm など) を使うこと, もう一つは Xwrapper を使うことです. xdm は, グラフィカルなログイン画面を扱うデーモンです. 通常, 起動時に実行され, 各ユーザの認証とユーザセションを開始させる機能を実現します. 基本的に, getty と login のグラフィック版, と考えて良いでしょう. xdm の詳細については, XFree86 関連文書 および FAQ 項目をご覧ください. Xwrapper とは, X サーバ用のラッパ (wrapper) のことです. これは必要なセキュリティを確保しつつ, 一般ユーザが X サーバを実行できるようにした小さなユーティリティで, コマンドライン引数の正当性チェックを行ない, それを通過すれば適切な X サーバを起動します. 何らかの理由でディスプレイマネージャを使いたくない場合に これを使うと良いでしょう. Ports Collection 全体をインストールしていれば, /usr/ports/x11/wrapper にあります. 私の PS/2 マウスは X ウィンドウシステム上でうまく動きません. あなたのマウスとマウスドライバがうまく同期していないからかもしれません. FreeBSD 2.2.5 までのバージョンでは, X から仮想ターミナルへ切替えて, また X へ戻ると再同期するかもしれません. この問題がよく起きるようであれば, カーネルコンフィグレーション ファイルに次のオプションを書いてカーネルを再構成してみてください. options PSM_CHECKSYNC もし, カーネルの再構築を行なったことがないのであれば, カーネルを構築するの項を参照してください. このオプションにより, マウスとドライバの同期で問題が起きる可能性は少なくなるでしょう. もしそれでもこの問題が起きるようならば, 再同期させるにはマウスを動かさないようにしておいて マウスボタンのどれかを押してください. このオプションは残念ながらすべてのシステムで働くわけではなく, また, PS/2 マウスポートにつながれているのが タップ(tap)機能を持つ アルプス社製 GlidePoint デバイスの場合, タップ機能が無効となってしまいます. FreeBSD 2.2.6 以降のバージョンでは, 同期のチェック方法が少し改善されたので標準で有効になっています. GlidePoint でもうまく働きます(同期チェックが標準の機能になったので PSM_CHECKSYNC オプションはこれらのバージョンからは削除されました). しかしながら, まれにドライバが間違って(訳注: 問題がないのに)同期に関して問題があると報告し, カーネルから psmintr: out of sync (xxxx != yyyy) というメッセージが出力されて, マウスが正しく動作していないように見える ことがあるかもしれません. もしこのようなことが起こる場合には, PS/2 マウスドライバのフラグに 0x100 を指定して同期チェックを無効にしてください. システムの起動時に 起動オプションを与えて UserConfig に入ります. boot: -c boot: UserConfig のコマンドラインで以下のように入力してください. UserConfig> flags psm0 0x100 UserConfig> quit MouseSystems の PS/2 マウスがうまく動きません. MouseSystems の PS/2 マウスのあるモデルは, 高解像度モードの場合にのみ正しく動作するということが報告されています. それ以外のモードでは, マウスカーソルがしょっちゅうスクリーン左上に行ってしまうかもしれません. 残念ながら FreeBSD 2.0.X や 2.1.X のバージョンでは, この問題の解決する方法はありません. 2.2 から 2.2.5 のバージョンでは, 以下のパッチを /sys/i386/isa/psm.c に適用しカーネルの再構築を行なってください. もし, カーネルの再構築を行なったことがないのであれば, カーネルの構築の項を参照してください. @@ -766,6 +766,8 @@ if (verbose >= 2) log(LOG_DEBUG, "psm%d: SET_DEFAULTS return code:%04x\n", unit, i); + set_mouse_resolution(sc->kbdc, PSMD_RES_HIGH); + #if 0 set_mouse_scaling(sc->kbdc); /* 1:1 scaling */ set_mouse_mode(sc->kbdc); /* stream mode */ FreeBSD 2.2.6 以降のバージョンでは, PS/2 マウスドライバのフラグに 0x04 を指定してマウスを高解像度モードにします. システムの起動時に 起動オプションを与えて UserConfig に入ります. boot: -c UserConfig のコマンドラインで以下のように入力してください. UserConfig> flags psm0 0x04 UserConfig> quit マウスに関する不具合の他の原因の可能性については, 直前のセクションも見てみてください. X のアプリケーションを構築する時に, imake can't find Imake.tmpl となります. どこにあるのでしょうか? Imake.tmpl は X の標準アプリケーション構築ツールである Imake パッケージの一部です. Imake.tmpl は, X アプリケーションの構築に必要な多くのヘッダファイルと同様に, X のプログラムディストリビューションに含まれています. sysinstall を使うか, 手動で X のディストリビューションファイルからインストールすることができます. マウスのボタンを入れ替える方法はありますか? .xinitrc か .xsession で xmodmap というコマンドを実行してください. スプラッシュスクリーンのインストールはどうするのですか. どこで見つけることができますか? FreeBSD 3.1 のリリース直前に, 起動メッセージの表示期間に いわゆる "スプラッシュ" スクリーンを表示させることができる新しい機能が追加されました. いまのところスプラッシュスクリーンは 256 色のビットマップ(*.BMP)か ZSoft PCX(*.PCX)ファイルです. それに加えて, 標準の VGA アダプタでの動作させるには 320x200 以下の解像度である必要があります. カーネルに VESA サポートを追加すれば 1024x768 までのより大きいビットマップを使用できます. VESA サポートを有効化するにはまず, カーネルが VM86 カーネルオプションとともにコンパイルされている必要があることに注意してください. VESA サポートそのものは VESA カーネルコンフィグオプション によって直接カーネル中にコンパイルするか, 起動時に VESA kld モジュールを読み込ませることができます. スプラッシュスクリーンを使うには, FreeBSD の起動プロセスをコントロールするスタートアップファイルを書き換える必要があります. これらのファイルは FreeBSD 3.2 のリリース以前に変更されましたので, 現在は, スプラッシュスクリーンを読み込む方法が二つあります. FreeBSD 3.1 の場合 まず最初のステップは, スプラッシュスクリーンのビットマップ版を探してくることです. 3.1-RELEASE では Windows のビットマップ形式のスプラッシュスクリーンだけをサポートしています. お望みのスプラッシュスクリーンを見つけたなら, それを /boot/splash.bmp にコピーします. 次に, これらの行が書かれた /boot/loader.rc ファイルが必要です. load kernel load -t splash_image_data /boot/splash.bmp load splash_bmp autoboot FreeBSD 3.2 以降の場合 PCX 形式のスプラッシュスクリーンのサポートが追加されると同時に, FreeBSD 3.2 には起動プロセスを設定する, より洗練された方法が含まれています. もしお望みなら, 上に示した FreeBSD 3.1 用の方法を使うこともできます. もしそうしたくて, かつ PCX 形式を使いたいなら, splash_bmp を splash_pcx と読み換えてください. そうではなくて, 新しい起動設定方法を使うのなら, 次の数行が書かれた /boot/loader.rc ファイルと, include /boot/loader.4th start 次の数行が含まれた /boot/loader.conf ファイルを作ることが必要です. splash_bmp_load="YES" bitmap_load="YES" この例では, スプラッシュスクリーンとして /boot/splash.bmp を使うことを想定しています. PCX 形式のファイルを使う場合には, そのファイルを /boot/splash.pcx にコピーして, 上で示したように /boot/loader.rc を作ります. そして, 次の内容の /boot/loader.conf というファイルを作ってください. splash_pcx_load="YES" bitmap_load="YES" bitmap_name="/boot/splash.pcx" さて, あとはスプラッシュスクリーンを用意するだけです. それには http://www.baldwin.cx/splash/ のギャラリーをサーフしてみてください. X で Windows(tm) キーを使うことはできるのでしょうか? はい, もちろん. どういう動作をするかについて定義するには &man.xmodmap.1; を使います. 標準的な "Windows(tm)" キーボードの場合, 対応するキーコードは 3 種類あります. 115 - 左の Ctrl と Alt の間にある Windows(tm) キー 116 - 右の Alt と Gr の間にある Windows(tm) キー 117 - 右の Ctrl の左隣にあるメニューキー 左にある Windows(tm) キーを押すとカンマ記号が入力されるようにするには, こんな風にします. &prompt.root; xmodmap -e "keycode 115 = comma" 設定を反映させるには, おそらくウィンドウマネージャを再起動する必要があります. Windows(tm) キーのキーマップを X 起動時に毎回, 自動的に有効化するには xmodmap コマンドを ~/.xinitrc に追加するか, もしくはおすすめできる方法として ~/.xmodmaprc というファイルを作成して, そのファイルの一行一行に xmodmap のオプションを記述し, 次の一行 xmodmap $HOME/.xmodmaprc を ~/.xinitrc に追加するという方法があります. たとえば, 先ほどあげた三つのキーを F13, F14, F15 に割り当てるとします. こうしておけば, アプリケーションやウィンドウマネージャの便利な機能を その三つのキーに簡単に割り当てることができます. こうするには, 次の内容を ~/.xmodmaprc に追加します. keycode 115 = F13 keycode 116 = F14 keycode 117 = F15 わたしは fvwm2 を使っていて, F13 をカーソル下のウィンドウのアイコン化, F14 をウィンドウの前面/背面化, F15 を, あたかもデスクトップにカーソルが存在しないかのように, メインワークスペース(アプリケーション)のメニューを呼び出せる機能に割り当てています. 最後の機能は, そのデスクトップがまったく見えないときに便利です. (また, キートップのロゴにもぴったりです) 次の例は, わたしがそのように割り当てを行なうために使っている ~/.fvwmrc のエントリです. Key F13 FTIWS A Iconify Key F14 FTIWS A RaiseLower Key F15 A A Menu Workplace Nop ネットワーキング 訳: &a.jp.arimura;, &a.jp.shou;, にしか nishika@cheerful.com, &a.jp.kiroh;, 1998 年 10 月 4 日. ディスクレスブート(diskless boot) に関する情報はどこで得られますか? ディスクレスブート(diskless boot) というのは, FreeBSD がネットワーク上で起動し, 必要なファイルを自分のハードディスクではなくてサーバから読み込むものです. 詳細については FreeBSD ハンドブックの「ディスクレスブート」を読んでください. FreeBSD をネットワークのルータ(router)として使用することはできますか? インターネット標準やこれまでのよい経験によって指摘されている通り, FreeBSD は標準ではパケットを転送(forward)するように設定されていません. しかし, rc.conf の中で次の変数の値を YES とする事によってこの機能を有効にすることができます. gateway_enable=YES # Set to YES if this host will be a gateway このオプションによって sysctl の変数 net.inet.ip.forwarding が 1 になります. ほとんどの場合, ルータについての情報を同じネットワークの他の計算機等に知らせるために, 経路制御のためのプロセスを走らせる必要があるでしょう. FreeBSD には BSD の標準経路制御デーモンである routed が付属していますが, より複雑な状況に対処するためには GaTeD(http://www.gated.org/ から入手可能)を使用することもできます. 3_5Alpha7 において FreeBSD がサポートされています. 注意してほしいのは, FreeBSD をこのようにして使用している場合でも, ルータに関するインターネット標準の必要条件を完全には満たしていない ということです. しかし, 普通に使用する場合にはほとんど問題ありません. Win95 の走っているマシンを, FreeBSD 経由でインターネットに接続できますか? 通常, この質問が出てくる状況は自宅に二台の PC があり, 一台では FreeBSD が, もう一台では Win95 が走っているような場合です. ここでやろうとしていう事は FreeBSD の走っている計算機をインターネット に接続し, Win95 の走っているマシンからは FreeBSD の走っているマシンを経由して接続を行なう事です. これは二つ前の質問の特別な場合に相当します. ... で, 答えは「はい」です. FreeBSD 3.x のユーザモード ppp には オプションがあります. ppp を オプション付きで起動し, /etc/rc.conf にある gateway_enable を YES に設定します. そして Windows マシンを正しく設定すれば, きちんと動作するでしょう. 設定に関するさらに詳しい情報は, Steve Sims 氏による Pedantic PPP Primer にあります. カーネルモード ppp を利用する場合や, インターネットとのイーサネット接続が利用できる場合は, natd を利用する必要があります. この FAQ の natd のセクションを参照してください. ISC からリリースされている BIND の最新版はコンパイルできないんでしょうか? BIND の配布物と FreeBSD とでは cdefs.h というファイルの中でデータ型の矛盾があります. compat/include/sys/cdefs.h を削除してください. FreeBSD で SLIP と PPP は使えますか? 使えます. FreeBSD を用いて他のサイトに接続する場合には, slattach, sliplogin, pppd そして ppp のマニュアルページを見てください. pppd と ppp は, PPP のサーバ, クライアント両方の機能を持っています. sliplogin は SLIP のサーバ専用で, slattach は SLIP のクライアント専用です. これらのプログラムの解説が, FreeBSD ハンドブックの以下のセクションにあります. SLIP サーバ SLIP クライアント カーネル PPP ユーザモード PPP 「シェルアカウント」を通じてのみインターネットへアクセス可能な場合, slirp package みたいなものが欲しくなるかもしれませんね. これを使えば, ローカルマシンから直接 ftp や http のようなサービスに(限定的ではありますが)アクセスすることができます. FreeBSD は NAT か IP マスカレードをサポートしていますか? ローカルなサブネット (一台以上のローカルマシン) を持っているが, インターネットプロバイダから 1 つしか IP アドレスの割り当てを受けていない場合(または IP アドレスを動的に割り当てられている場合でも), natd プログラムを使いたくなるかもしれませんね. natd を使えば, 1 つしか IP アドレスを持っていない場合でも, サブネット全体をインターネットに接続させることができます. ppp も同様の機能を持っており, スイッチで有効にすることができます. どちらの場合も alias ライブラリが使われます. /dev/ed0 デバイスを作成することができません. Berkeley UNIX におけるネットワークの構成において, ネットワークのインタフェースはカーネルコードからのみ, 直接あつかうことができます. より詳しく知りたい場合は, /etc/rc.network というファイルや, このファイルの中に書いてある, さまざまなプログラムについてのマニュアルページを見てください. それでもまだ分からない場合には, 他の BSD 系の OS のネットワーク管理についての本を読むべきでしょう. ごく少しの例外をのぞいては, FreeBSD のネットワーク管理は SunOS 4.0 や Ultrix と基本的に同じです. Ethernet アドレスのエイリアス(alias)はどのようにして設定できますか? ifconfig のコマンドラインに netmask 0xffffffff を追加して, 次のように書いてください. &prompt.root; ifconfig ed0 alias 204.141.95.2 netmask 0xffffffff 3C503 で他のネットワークポートを使用するにはどのようにすればよいですか? 他のポートを使用したい場合には, ifconfig のコマンドラインにパラメータを追加しなければなりません. デフォルトでは link0 が用いられるようになっています. BNC のかわりに AUI ポートを使用したい場合には, link2 というパラメータを追加してください. これらのフラグは, /etc/rc.conf にある ifconfig_* の変数を使って指定されるはずです. FreeBSD との間で NFS がうまくできません. PC 用のネットワークカードによっては, NFS のような, ネットワークを酷使するアプリケーションにおいて問題を起こすものがあります. この点に関しては FreeBSD ハンドブックの「NFS」を参照してください. 何故 Linux のディスクを NFS マウントできないのでしょうか? Linux の NFS のコードには, 許可されたポートからのリクエストしか受けつけないものがあります. 以下を試してみてください. &prompt.root; mount -o -P linuxbox:/blah /mnt 何故 Sun のディスクを NFS マウントできないのでしょうか? SunOS 4.X が走っている Sun Workstation は, 許可されたポートからのマウント要求しか受けつけません. 以下を試してみてください. &prompt.root; mount -o -P sunbox:/blah /mnt mountd から can't change attributes というメッセージがずっと出続けていて, FreeBSD の NFS サーバでは bad exports list と表示されます. これは何が原因なのでしょう? 最も良くある問題は, &man.exports.5; のマニュアルページの以下の部分を正しく理解していないことです.
このファイルの各行 (# ではじまるコメント行を除く) は, NFS サーバのローカルファイルシステムに存在する, 他のホストにエクスポートされるマウントポイント (複数可) と, それに対するエクスポートフラグを指定します. 特定のエクスポート先ホストおよび, すべてのホストに適用されるデフォルトエントリは両方とも, サーバの各ローカルファイルシステムに対して一回だけしか指定できません.
さて, ありがちな間違いをご覧になればはっきりするでしょう. もし /usr 以下が単一のファイルシステムである (つまり /usr に何もマウントされない) 場合, 次の exports リストは正しくありません. /usr/src client /usr/ports client 一つのファイルシステムに対して属性の指定が二行になっています. /usr は同じホスト client にエクスポートされますから, 正しい書き方は次のようになります. /usr/src /usr/ports client もう一度マニュアルページの文章を確認すると, あるホストにエクスポートされる各ファイルシステムの属性は すべて一行に書かれていなければならない, となっています (ここでは,「アクセス可能なすべてのホスト」 も一つの独立したホストとして扱われることに注意してください). このことは, ファイルシステムをエクスポートするために 奇妙な書式を使わなければならない原因にもなっているのですが, ほとんどの人にとって, これは問題にはならないでしょう. 次に示すのは, 有効な exports リストの例です. ここでは, /usr と /exports がローカルファイルシステムです. # Export src and ports to client01 and client02, but only # client01 has root privileges on it /usr/src /usr/ports -maproot=0 client01 /usr/src /usr/ports client02 # The "client" machines have root and can mount anywhere # up /exports. The world can mount /exports/obj read-only /exports -alldirs -maproot=0 client01 client02 /exports/obj -ro PPP で NeXTStep に接続する際に問題があるのですが. /etc/rc.conf の中で次の変数を NO にして, TCP extension を無効にしてみてください. tcp_extensions=NO Xylogic の Annex も同様の問題がありますので, Annex 経由で PPP を行なう場合にもこの変更を行ってください. IP マルチキャスト(multicast)を有効にするには? FreeBSD 2.0 かそれ以降では, 標準の状態で完全にマルチキャストに対応しています. 現在使用している計算機をマルチキャストのルータ(router)として使用するには, MROUTING というオプションを定義したカーネルを作ったうえで, mrouted を走らせる必要があります. 2.2 かそれ以降の FreeBSD ならば, /etc/rc.conf でフラグ mrouted_enable を YES にセットしておくことで, 起動時に mrouted を起動できます. MBONE 用のツールは ports 内の専用のカテゴリー mbone にあります. vic や vat といった会議用のツールを探している場合は, この場所を見てください. 詳しい情報は Mbone Information Web にあります. DEC の PCI チップセットを用いているネットワークカードには, どのような物がありますか? Glen Foster 氏による一覧に, 最近の製品を追加したものを以下に示します. Vendor Model ---------------------------------------------- ASUS PCI-L101-TB Accton ENI1203 Cogent EM960PCI Compex ENET32-PCI D-Link DE-530 Dayna DP1203, DP2100 DEC DE435, DE450 Danpex EN-9400P3 JCIS Condor JC1260 Linksys EtherPCI Mylex LNP101 SMC EtherPower 10/100 (Model 9332) SMC EtherPower (Model 8432) TopWare TE-3500P Znyx (2.2.X) ZX312, ZX314, ZX342, ZX345, ZX346, ZX348 (3.X) ZX345Q, ZX346Q, ZX348Q, ZX412Q, ZX414, ZX442, ZX444, ZX474, ZX478, ZX212, ZX214 (10mbps/hd) 何故自分のサイトのホストに対して FQDN を使用する必要があるのですか? 実際にはそのホストは別のドメインにあるのではないですか. たとえば, foo.bar.edu というドメインの中から, bar.edu ドメインにある mumble というホストを指定したい場合には, mumble だけではダメで, mumble.bar.edu という FQDN(fully-qualified domain name) で指定しなければなりません. 伝統的に, BSD の BIND のリゾルバ(resolver)ではこのような事は可能でしたが, FreeBSD に入っている bind の現在のバージョンでは, 自分以外のドメインに対して FQDN でない別名を自動的につけてくれるような事はありません. したがって mumble というホスト名は, mumble.foo.bar.edu という名前か, もしくは root ドメイン内にある場合にしか適用されません. これは, mumble.bar.edu と mumble.edu ということなったドメイン名に対してホスト名のサーチが行なわれていた 以前の振る舞いとは異なったものです. このような事が悪い例もしくは セキュリティホールとみなされる理由については RFC 1535 を見てください. /etc/resolv.conf の中で domain foo.bar.edu と書いてある行を, search foo.bar.edu bar.edu のように書きかえることで, 上のような事ができます. しかし, RFC 1535 にあるように, 検索順序が「内部(local)と外部(public)の管理の境界」をまたがないようにしてください. すべてのネットワークの操作に対して Permission denied というメッセージが表示されるのですが. IPFIREWALL オプションを付けてカーネルをコンパイルした場合には, 2.1-STABLE の開発の途中から変更になった 2.1.7R の標準的な方針として, 明示的に許可されていないすべてのパケットは落とされる設定 になっている事を覚えておいてください. もしファイアウォールの設定を間違えた場合にネットワークの操作が再びできる ようにするには, root でログインして次のコマンドを実行してください. &prompt.root; ipfw add 65534 allow all from any to any /etc/rc.conf に firewall_type='open' を追加してもよいでしょう. FreeBSD のファイアウォールの設定についての情報は FreeBSD ハンドブックの「ファイアウォール」にあります. IPFW のオーバヘッドはどのくらいでしょうか? この答えは, 使っているルールセットとプロセッサのスピードによってほとんど決まります. イーサネットに対して少しのルールセットだけを使っている場合には, ほとんどその影響は無視できる程度です. 実際の測定値を見ないと満足できない方々のために, 実際の測定結果をお見せしましょう. 次の測定は 486-66(訳注: Intel 社製 CPU i486, 66MHz のこと)上で 2.2.5-STABLE を使用して行なわれました. IPFW は変更が加えられて, ip_fw_chk ルーチン内でかかる時間を 測定して 1000 パケット毎に結果をコンソールに表示するようになっています. それぞれ 1000 ずつのルールが入っている 2 つのルールセットでテストが行なわれました. ひとつ目のルールセットは最悪のケースを見るために ipfw add deny tcp from any to any 55555 というルールを繰り返したものです. IPFW のパケットチェックルーチンは, パケットが(ポート番号のせいで)このルールにマッチしないことがわかるまでに, 何度も実行されます. そのため, これは最悪のケースを示します. このルールを 999 個繰り返し並べた後に allow ip from any to any が書かれています. 2つ目のルールセットは, なるべく早くチェックが終了するように書かれたものです. ipfw add deny ip from 1.2.3.4 to 1.2.3.4 このルールでは, 発信元の IP アドレスがマッチしないので, チェックはすぐに終了します. 上のルールセットとおなじように, 1000 個目のルールは allow ip from any to any です. 1 つ目のルールセットの場合, パケットあたりのオーバヘッドはおよそ 2.703ms/packet, これはだいたい 1 つのルールあたり 2.7 マイクロ秒かかっていることになります. したがって, このルールにおけるパケット処理時間の理論的な限界は, 毎秒約 370 パケットです. 10Mbps のイーサネットで 1500 バイト以下のパケットサイズを仮定すると, バンド幅の利用効率は 55.5% が限界となることになります. 2 つ目のルールセットでは, それぞれのパケットがおよそ 1.172msで処理されていますので, だいたい 1 つのルールあたり 1.2 マイクロ秒かかっていることになります. パケット処理時間の理論的な限界は, 毎秒約 853 パケットとなりますので, 10Mbps Ethernet のバンド幅を使い切ることができます. このテストでのルール数は多過ぎるため, 実際に使用する際の結果を反映している訳ではありません. これらは上に示した数値を出すためだけに用いられたものです. 効率の良いルールセットを作るためには, 次のような事を考えておけばよいでしょう. 「確定している」ルールは先頭の方に持ってきてください. これは, 多数の TCP のトラフィックがこのルールで処理されるためです. そしてこのルールの前には allow tcp という記述を置かないでください. 良く使われるルールを, あまり良く使われないルールよりも 前の方に(もちろんファイアウォールの許可設定を変えない範囲で) 持ってきてください. ipfw -a l のようしてパケット数の統計を取ることで, どのルールが最もよく使われているかを調べることができます. &man.ipfw.8; fwd ルールを使って他のマシンにサービスをリダイレクトしたのですが, うまく動いてくれないようです. どうしてなんでしょう? おそらく, あなたが期待している動作とは, 単なるパケット転送ではなくネットワークアドレス変換 (NAT) と呼ばれるものだからでしょう. fwd ルールは文字どおり, 本当に転送しか行ないません. パケットの中身については一切手を加えないのです. そのため, 次のようなルールを設定したとすると, 01000 fwd 10.0.0.1 from any to foo 21 宛先アドレスに foo と書かれたパケットが このルールを設定したマシンに到着した場合, そのパケットは 10.0.0.1 に転送されますが, 宛先アドレスは foo のままになります. つまり, パケットに宛先アドレスが 10.0.0.1 に書き換えられるということはありません. 自分宛でないパケットを受けとったマシンは, おそらくほとんどの場合, そのパケットを破棄すると思います. そのため fwd ルールは, そのルールを書いたユーザが意図したようには動かないことが良くあります. この動作はバグではなく, 仕様なのです. サービスの転送をきちんと動作させる方法については, サービスのリダイレクトに関する FAQ や &man.natd.8; のマニュアルページ, Ports Collection にいくつか含まれているポート転送ユーティリティなどをご覧になると良いでしょう. サービス要求を他のマシンにリダイレクトするには? FTP などのサービスのリクエストは, socket パッケージを利用してリダイレクトできます. socket パッケージは ports の sysutils カテゴリに含まれています. (/etc/inet.confに書かれている) コマンド行を, 次のように socket を呼ぶように変更してください. ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.foo.com ftp ここで ftp.foo.com はリダイレクト先のホスト名, 行の最後の ftp はポート名です. バンド幅の管理を行なえるツールはどこで手に入れられますか? FreeBSD 用のバンド幅管理ツールには, 無料で手に入れられる ALTQ と, Emerging Technologies から入手できる Bandwidth Manager という市販のものの 2 種類があります. なぜ /dev/bpf0: device not configured が出るのでしょうか? バークレーパケットフィルタ(bpf) ドライバは, それを利用するプログラムを実行する前に有効にしておく必要があります. カーネルコンフィグファイルに, 次のように追加してカーネルの再構築をしてください. pseudo-device bpfilter # Berkeley Packet Filter そして再起動してから, 次にデバイスノードを作成する必要があります. これは, 次のように入力し, /dev を変更することで行ないます. &prompt.root; sh MAKEDEV bpf0 デバイスノードの作成の詳細は, FreeBSD ハンドブックの「デバイスノード」を参照してください. Linux の smbmount のように, ネットワーク上の Windows マシンのディスクをマウントするにはどうしたら良いのでしょう? Ports Collection に含まれる sharity light パッケージを使ってください, icmp-response bandwidth limit 300/200 pps というメッセージがログファイルに現れるのですが, どういうことでしょう? これは, カーネル自身から「ICMP や TCP のリセット (RST) 応答を, 妥当な数よりも多く送っている」ということを, あなたに伝えるメッセージです. ICMP 応答は良く, 使われていない UDP ポートに接続しようとした結果として生成されます. また, TCP リセットはオープンされていない TCP ポートに接続しようとした結果として生成されます. その他, これらのメッセージが表示される原因となる状況として, 以下のようなものがあります. (特定のセキュリティ上の弱点を悪用しようとする攻撃ではなく) 膨大な数のパケットを使った強引なサービス妨害 (DoS) 攻撃. (一部のウェルノウンポートを狙ったものではなく) 非常に広い範囲のポートに接続を試みるポートスキャン. メッセージ中の最初の数字は, 上限を設定しなかった場合にカーネルが送っていたであろうパケットの数を示し, 二番目の数字は, パケット数の上限値を示します. この上限値は net.inet.icmp.icmplim という sysctl 変数を使うことで, 以下のように変更可能です. ここでは上限を 1 秒あたりのパケット数で 300 にしています. &prompt.root; sysctl -w net.inet.icmp.icmplim=300 カーネルの応答制限を無効にせず, ログファイル中のメッセージだけを抑制したい場合, net.inet.icmp.icmplim_output sysctl 変数を次のようにすることで出力を止めることができます. &prompt.root; sysctl -w net.inet.icmp.icmplim_output=0 最後に, もし応答制限を無効にしたい場合は, net.inet.icmp.icmplim sysctl 変数に (上の例のようにして) 0 を設定することで実現できます. ただし応答制限を無効化するのは, 上記の理由からおすすめしません. PPP ppp が動きません. どこを間違えているのでしょう? まず ppp のマニュアルと, FreeBSD ハンドブックの「PPP」を読んでみましょう. 次に, set log Phase Chat Connect Carrier lcp ipcp ccp command という命令を ppp のコマンドプロンプトに対して打ち込むか, 設定ファイル /etc/ppp/ppp.conf に加えて(default セクションの先頭に加えるのが一番良いでしょう)ログを有効にしてみてください. その際, /etc/syslog.conf に !ppp *.* /var/log/ppp.log と書かれた行が含まれているか, また, /var/log/ppp.log が存在しているかどうか確かめておいてください. さて, これで何が起きているのか突き止めるために, ログファイルからたくさんの情報を得られるようになりました. ログに訳の分らない部分があっても心配ご無用. あなたが助けを求めた誰かにとっては, その部分が意味をなす場合があるのです. 訳注 ログの取得に syslog を使用するようになったのは 2.2.5 以降からです. 使用中の ppp のバージョンで set log 命令を解釈しない場合は, 最新版をダウンロードすべきです. FreeBSD の 2.1.5 以降でビルドできます. ppp を実行するとハングします ホスト名の解決がうまくいっていないのでしょう. まず, リゾルバ(resolver)が /etc/hostsを参照するように, /etc/host.conf の最初の行に host と書き込んでください. つぎに, /etc/hosts に使用しているマシンのエントリを書き加えます. ローカルでネットワークを使用していない場合は, localhost の行を以下のように変更してください. 127.0.0.1 foo.bar.com foo localhost 使用しているホストのエントリを追加してもかまいません. 詳細は関連するマンページを参照してください. ppp が モードでダイアルしてくれない まず最初に, デフォルトルートが確立しているかどうかチェックしてください. netstat -rn を実行すると, 以下のような情報が表示されるはずです. Destination Gateway Flags Refs Use Netif Expire default 10.0.0.2 UGSc 0 0 tun0 10.0.0.2 10.0.0.1 UH 0 0 tun0 これはあなたがハンドブックやマニュアル, ppp.conf.sample の中で出てくるアドレスを使用していると仮定した場合の例です. デフォルトルートが確立していない場合, ppp.conf の中の HISADDR が理解できない, 古いバージョンの ppp が走っている可能性があります. FreeBSD 2.2.5 より前のバージョンに付属していた ppp を使用している場合, add 0 0 HISADDR と書かれた行を以下のように修正してください. add 0 0 10.0.0.2 netstat -rn でデフォルトルートの情報が表示されない場合, もう一つ, /etc/rc.conf(2.2.2 より前のリリースでは /etc/sysconfig と呼ばれていました)の中でデフォルトのルータを誤って設定し, ppp.conf から delete ALL の行をうっかり消してしまった可能性があります. この場合は, FreeBSD ハンドブックの「システムの最終設定」の項を読み直してください. No route to host とはどういう意味ですか? このエラーは通常, /etc/ppp/ppp.linkup に以下のようなセクションが無い場合に起こります. MYADDR: delete ALL add 0 0 HISADDR これは動的 IP アドレスを使用している場合, またはゲートウェイのアドレスを知らない場合にのみ必要な設定です. インタラクティブモードを使用している場合, パケットモードに入った後で(プロンプトが PPP と大文字に変わったらパケットモードに入ったしるしです), 以下の命令を入力してください. delete ALL add 0 0 HISADDR 詳しい情報については, FreeBSD ハンドブックの「PPP と動的 IP 設定」の項を参照してください. 3 分ほど経つと接続が切れてしまう ppp のタイムアウトは デフォルトでは 3 分です. これは set timeout NNN という命令によって調整することができます. NNN には, 接続が切れるまでのアイドル時間が秒数で入ります. NNN が 0 の場合, タイムアウトによる切断は起こりません. このコマンドは ppp.conf に入れることも, インタラクティブモードでプロンプトから入力することも できます. ソケットを用いる telnet か pppctl を使用し, ppp サーバに接続することによって, 回線がアクティブな間に限定してタイムアウトの時間を調整することも可能です. 訳注 pppctl は 2.2.5R からです. 詳しい情報は ppp のマニュアルページを参照してください. 負荷が高いと接続が切れてしまう Link Quality Reporting(LQR)の設定を行っている場合, マシンと接続先の間で非常にたくさんの LQR パケットが失われている可能性があります. 結果として ppp は回線の具合いが悪いと考え, 回線を切断するのです. 2.2.5 より前のバージョンの FreeBSD では LQR はデフォルトで有効になっています. 現在ではデフォルトの状態で無効です. LQR は以下の命令で無効にすることができます. disable lqr 接続がランダムに切れてしまう ノイズの多い回線, あるいは待ち機能付きの回線では, 時々モデムが(誤って)キャリアを失ったと思い込み, 回線が切断されてしまうことがあります. 大多数のモデムでは, 一時的なキャリアの喪失をどれくらいの時間で検出するかを, 設定で決めることができます. 例えば USR Sportster では, S10 レジスタ の値を 10 倍した秒数がその値になります. この場合, モデムをもっとのんびり屋さんにするには, dial 行に次のような文字列を加えると良いでしょう. set dial "...... ATS10=10 OK ......" 詳しくはお使いのモデムのマニュアルをご覧ください. 接続が不規則にハングアップしてしまう たくさんの人が, 原因不明のハングアップを経験しています. 検証のために必要なのは, まずどちら側のリンクでそれが起こっているか, ということです. 外部接続型モデムを利用しているなら, 単に ping を使うことで, データを送信するときに TD ランプが点灯するかどうかを確認することができます. もし, TD ランプが点灯して, RD ランプが点灯しなければ, 問題は回線の向こう側にあります. TD が点灯しなければ, 問題は回線のこちら側です. 内蔵型モデムの場合, ppp.conf ファイルに set server コマンドを入れる必要があるでしょう. 回線が切断されたとき, pppctl を使って ppp に接続してください. そのとき, ネットワーク接続が急に復旧(診断ソケットへのアクセスで, ppp が復活します)するか, もしくは接続自体が全くできない(ただし, ppp 起動時に set socket コマンドがちゃんと実行されているとします)としたら, 問題は回線のこちら側です. もし, 接続可能で, かつ状況が変化しなければ, set log local async を使ってローカル非同期ログ(async logging)を有効にし, ping を他のウィンドウかターミナルから使ってください. 非同期ログには, こちら側のリンクの送受信データが記録されます. もし, データが送信されたにもかかわらず返って来ていなければ, 問題は回線の向こう側にあることになります. 問題が回線のどちら側かにあることが分かったら, つぎの二つの可能性が考えられるでしょう. 回線の向こう側での反応がない これに対処できることはほとんどありません. 大部分の ISP は, Microsoft 社製 OS 以外の利用者に対してのサポートを拒否するでしょう. ppp.conf ファイルの中に enable lqr を記述することで ppp が回線の向こう側で発生する切断を検出することができますが, この検出は比較的遅いため, あまり役に立ちません. また, あなたは user-ppp を利用していることを ISP に知られたくないと思うかも知れませんね. まず最初に, こちら側の圧縮機能を全て無効にしてみてください. それには, 設定ファイルをつぎのようにします. disable pred1 deflate deflate24 protocomp acfcomp shortseq vj deny pred1 deflate deflate24 protocomp acfcomp shortseq vj そして再接続し, 変更前と同じように通信できることを確認します. もしこれによって状況が改善されるか, 完全に解決したら, (上の設定のうち)どの設定で状況が変化したのかを, 色々な組合せで試してみてください. これは, ISP に問い合わせを行なうときの有効な情報となります(ただし, あなたが Microsoft 社製品以外のものを利用していることも明らかにしてしまいますが). ISP に問い合わせを行なう前に, こちら側の非同期ログを有効にして, 接続がハングアップするまで待ってください. この作業は, 非常に多くのディスク空間を消費するかも知れません. 興味の対象となっているのは, 通信ポートから最後に読み込まれたデータです. それは通常 ASCII データで, 問題点の詳細(Memory fault, core dumpなど)が 記載されている可能性があります. 回線の向こう側で通信ログを監視することは可能なはずですので, 切断が発生した時, ISP の対応が好意的ならば どうして ISP 側で問題が発生したのかこちらに伝えてくれるかも知れません. brian@Awfulhak.org まで詳細を送って頂くか, ISP に直接私に連絡するように伝えて下さっても構いません. ppp がハングアップする ベストな方法は, CFLAGS+=-g と STRIP= を ppp の Makefile に追加して, ppp を再構築し, そして make clean && make && make install を行なうことです. ppp がハングアップした時, ps ajxww | fgrep ppp を使って ppp のプロセス ID を調べ, gdb ppp PID を実行してください. gdb のプロンプトから, bt を使ってスタックをトレースすることができます. スタックトレースの結果は, brian@Awfulhak.org まで送ってください. Login OK! のメッセージが出た後, 何も起こらない 2.2.5 より前のリリースの FreeBSD では, ppp はリンクが確立した後, 接続先が Line Control Protocol(LCP) を発信するのを待ちます. しかし, 多くの ISP ではネゴシエーションを自分からは起こさず, クライアントが起こすのを待っています. ppp に強制的に LCP を発信させるには, 次の命令を使います. set openmode active 両方の側がネゴジェーションを起こしても, 大抵の場合は何の問題もありません. ですから, 現在では openmode はデフォルトで active になっています. 次のセクションでこれが問題になる場合を説明します. でもまだ magic is the same というエラーが出る 時折, 接続直後のログに magic is the same というメッセージがあらわれることがあります. このメッセージがあらわれても何も起きない場合もありますし, どちらかの側が接続を切ってしまう場合もあります. ppp の実装の多くはこの問題に対応できておらず, その場合にはちゃんと link が上がっている状態であっても, ppp が最終的にあきらめてしまい, 接続を切るまで設定のリクエストが繰り返し送られ, 設定が行われたという通知がログファイルに残ると思います. これは通常, ディスクアクセスの遅いサーバマシンのシリアルポートで getty が生きていて, ppp がログインスクリプトか, ログイン直後に起動されたプログラムから実行されている場合に起こります. slirp を使用している場合に同様の症状が見られたという報告もあります. 原因は getty の終了されるまでと, ppp が実行され, クライアント側の ppp が Line Control Protocol(LCP) を送り始めるまでのタイミングにあります. サーバ側のシリアルポートで ECHO が有効なままになっているので, クライアント側の ppp にパケットが「反射」してしまうのです. LCP ネゴシエーションの一部として, リンクの両サイドで magic number を定めて, 「反射」が起きていないかどうか確かめる作業があります. 規約では, 接続相手がこちらと同じ magic number を提示してきたら, NAK を送って新しい magic number を選択しなければならないと定めています. この作業の間, サーバのシリアルポートの ECHO がずっと有効になったままなので, クライアント側の ppp は LCP パケットを送り, パケットが反射して全く同じ magic number が送られてくるのを見つけ, それに対して NAK を送るのです. 一方 NAK 自体も(これは ppp が magic number を変更しなければいけないことを意味しています)反射してくるので, 結果として magic number が数えきれないほど変更され, その全てがサーバの tty バッファの中に積み重なることになるのです. サーバでスタートした ppp は, すぐに magic number であふれかえってしまい, LCP のネゴシエーションを十分に行ったものと判断して, さっさと接続を切ってしまいます. 一方, クライアント側は反射が帰ってこなくなったので満足しますが, それもサーバが接続を切ったことを知るまでです. この事態は, 以下の行を ppp.conf の中に書いて, 相手がネゴシエーションを開始できるようにする事によって回避できます. set openmode passive これで ppp はサーバが LCP ネゴシエーションを起こすのを待つようになります. しかし, 自分からは決してネゴジェーションを起こさないサーバもあるかもしれません. もしこの状況に遭遇した場合には, 次のようにしてください. set openmode active 3 これによって ppp は 3 秒間 passive モードを続けた後で, LCP リクエストを送り始めます. この間に相手がリクエストを送り始めた場合には 3 秒間待たずにこのリクエストに即座に応答します. 接続が切れるまで LCP のネゴシエーションが続くのですが. 現在の ppp は, まだ LCP や CCP, IPCP の返事が, 元のリクエストと連携してくれる機能がきちんと実装されていません. その結果, ある ppp が相手よりも 6 秒以上遅い場合には, LCP 設定ののリクエストをさらに 2 回送ります. これは致命的な物です. A と Bという 2 つの実装を考えてみましょう. A が接続の直後に LCP リクエストを送り, 一方 B の方はスタートするのに 7 秒かかったとします. B がスタートする時には A は LCP リクエストを 3 回送ってしまっています. 前の節で述べた magic number の問題が起きないよう, ECHO は off になっていると考えています. B は REQ を送ります. するとこれは A の REQ のうち, 最初の物に対する ACK となります. 結果として, A は OPENED の状態に入り, B に対して(最初の) ACK を送ります. そのうちに B は, B がスタートする前に A から送られたもう 2 つの REQ に対する ACK を送り返します. B は A からの最初の ACK を受け取り OPENED の状態に入ります. A は B からの 2 つ目の ACK を受け取りますので, REQ-SENTの状態に戻り, さらに, RFC のとおりに(4 つ目の)REQ を送ります. そして 3 つ目の ACK を受け取って OPENED の状態に入ります. 一方, B は A からの 4 つ目の REQ を受け取りますので, ACK-SENT の状態に入り, 2 つ目の REQ と 4 つ目の ACK を RFC のとおりに送ります. Aは, REQ を受けとると REQ-SENT の状態になり, さらに REQ を送ります. そしてすぐに ACK を受け取って OPENED の状態に入ります. これが, 片方の ppp があきらめてしまうまで続きます. これを回避する最も良い方法は, 片方を passive モードに設定する, すなわち反対側がネゴシエーションを開始するまで待つようにする事です. これは, set openmode passive というコマンドでできます. このオプションは気を付けて使わないといけません. さらに set stopped N というコマンドを追加して, pppがnegotiationが開始するまで待つ 最大の時間を設定してください. もしくは, set openmode active N というコマンド(ここで, N はネゴシエーションが始まるまで待つ時間)を使うこともできます. 詳しくはマニュアルページを参照してください. ppp が接続直後に固まってしまう 2.2.5 より前のバージョンの FreeBSD では, ppp が Predictor1 圧縮のネゴシエーションを誤って解釈して, 接続直後にリンクを無効にしている可能性があります. これは両サイドが異なる Compression Control Protocols (CCP) を使ってネゴジェーションを行った場合にのみ発生します. この問題は現在は解決していますが, あなたの走らせている ppp のバージョンが古い場合でも, 次の命令で解決することができます. disable pred1 ppp の内部でシェルを起動しようとすると固まってしまう shell あるいは ! コマンドを使用すると, ppp はシェルを起動し(何か引数を渡した場合は, ppp は引数も実行します), コマンドが終了するまで処理を中断します. コマンドを実行中に ppp のリンクを使おうとすると, リンクが固まっているように見えますが, これは ppp がコマンドの終了を待っているからです. このような場合は, 代わりに !bg コマンドを使用してください. 与えられたコマンドがバックグラウンドで実行されるので, ppp はリンクに関するサービスを継続することができます. ヌルモデムケーブルを使用しているとき, ppp が終了しない ヌルモデムケーブルを使用して直接接続している場合, ppp は自動的には接続の終了を知ることができません. これはヌルモデムシリアルケーブルの配線に起因しています. この種の接続形態を用いる場合は, 以下の命令を用いて LQR を常に有効にする必要があります. enable lqr こうすると, 接続先がネゴシエーションを行う場合, デフォルトで LQR の使用を受け入れるようになります. ppp を モードで動かすと, 勝手にダイアルすることがある ppp が思いもしないときにダイアルを始める場合, その原因を突き止め, 防止のためにダイヤルフィルタ(dfilters)をかけてやる 必要があります. 原因を突き止めるためには, 以下の命令を使用してください. set log +tcp/ip これで接続を通過する全てのトラフィックをログに残すことができるようになりました. 次に突然回線がつながったときのログのタイムスタンプをたどれば, 原因を突き止めることができるはずです. 原因がわかったら, 次に, このような状況ではダイヤルが起こらないようにしましょう. 通常, この手の問題は, DNS で名前の解決をしようとしたために起こります. DNS による名前の解決によって, 接続が行われるのを防止するには, 次のような手段を用います(これは ppp の既に確立した接続に関してパケットのフィルタリングをするものではありません). set dfilter 1 deny udp src eq 53 set dfilter 2 deny udp dst eq 53 set dfilter 3 permit 0/0 0/0 これはデマンドダイヤル機能に問題を生じさせるため, 常に適切であるとはかぎりません. ほとんどのプログラムは他のネットワーク関連の処理を行なう前に DNS への問い合わせが必要になります. DNS の場合は, 何が実際にホスト名を検索しようとしているのかを突き止めるべきでしょう. 大抵の場合は, sendmail が犯人です. 設定ファイルで sendmail が DNS に問い合わせないようになっているか確認すべきです. 自分用の設定ファイルを作成するための詳しい方法は, メールの設定 の項をご覧ください. または, .mc ファイルに次のような行を追加してもよいでしょう. define(`confDELIVERY_MODE', `d')dnl この行を追加すると, sendmail はメールキューを処理する(通常 sendmail は 30 分ごとにキューを処理するよう, というオプションを付けて起動されます)までか, または(多分 ppp.linkup というファイルの中で) sendmail -q というコマンドが実行されるまで, 全てのメールをキューに溜めるようになります. 訳注 sendmail -q はその時点のメールキューの内容を処理して終了します. CCP エラーとはどういう意味ですか ログファイル中の以下のエラーは, CCP: CcpSendConfigReq CCP: Received Terminate Ack (1) state = Req-Sent (6) のネゴシエーションにおいて ppp は Predictor1 圧縮を用いるべく主張したのに対して, 接続先は圧縮を使用しないことを主張した場合に起こります. このメッセージには何の害もありませんが, 出るのが嫌なら, 以下の命令を用いてこちら側でも Predictor1 圧縮を無効にすることで対応できます. disable pred1 ファイル転送の途中で, ppp が IO エラーを出して固まってしまう FreeBSD 2.2.2 以前のバージョンの tun ドライバには, tun インタフェースの MTU のサイズより大きなパケットを受け取ることができないというバグがありました. MTU のサイズより大きなパケットを受け付けると IO エラーが起こり, syslogd 経由で記録されるのです. ppp の仕様では, LCP のネゴシエーションを行う場合を含むどのような場合でも最低 1500 オクテットの Maximum Receive Unit (MRU) を受け入れる必要があります. ですから, MTU を 1500 以下に設定した場合でも, ISP はそれに関係なく 1500 の大きさのパケットを送ってくるでしょう. そしてこのイケてない機能にぶちあたって, リンクが固まるのを目にすることになるのです. FreeBSD 2.2.2 以前のバージョンでは, MTU を決して 1500 より小さくしないことで, この問題を回避することができます. どうして ppp は接続速度をログに残さないんでしょう? モデムとの「やり取り」全ての行をログに残すには, 以下のようにして接続速度のログの有効化を行ってください. set log +connect これは ppp に最後にくることが要求されている expect という文字列がくるまでのすべてのものをログに記録させます. 接続速度はログにとりたいけれど, PAP や CHAP を使っている(その結果, ダイヤルスクリプト中の CONNECT 以降に全く「やりとり」を行わない - set login スクリプトには何も書かない)のであれば, ppp に expect を含んだ CONNECT 行全てがくるまで待たせるようにしないといけません, 以下のようになります. set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 4 \"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n" ここで, CONNECT を受信してから, 何も送らず, 復帰改行(linefeed)を待っています, ppp に CONNECT の応答全てを読み込ませているわけです. 私の chat スクリプトでは \ という文字を PPP が解釈してくれません. PPP は設定ファイルを読み込むときに, set phone "123 456 789" のような文字列を正しく解釈し, 番号が実際に1 つの引数であると理解します. " という文字を指定するには, バックスラッシュ(backslash; \)でエスケープしなければなりません. chat の各引数が解釈されるときには, \P や \T のような特別なエスケープシーケンス(マニュアルページ参照のこと)を見付けるために, もう 1 回, 字句解析を行います. このように字句解析は 2 回繰り返されますので, 正しい回数だけエスケープ処理を行わないといけません. モデムにたとえば \ のような文字を送りたい場合には, 次のようにする必要があります. set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK" 実際にモデムに送られる文字列は次のようになります. ATZ OK AT\X OK 他の例ですと set phone 1234567 set dial "\"\" ATZ OK ATDT\\T" は次のようになります. ATZ OK ATDT1234567 ppp が segmentation fault になるのですが, ppp.core ファイルがありません ppp(や他のプログラム)は決して core を吐いてはいけません. ppp は実効 uid が 0 で動いていますので, オペレーティングシステムは ppp を終了させる前にディスクに core イメージを書き込みません. しかし ppp は実際にはセグメンテーション違反や, 他の core を吐く原因となるようなシグナルによって終了して おり, さらに最新のバージョン(このセクションの始めを見てください)を使用しているならば, 次のようにしてください. &prompt.user; tar xfz ppp-*.src.tar.gz &prompt.user; cd ppp*/ppp &prompt.user; echo STRIP= >>Makefile &prompt.user; echo CFLAGS+=-g >>Makefile &prompt.user; make clean all &prompt.user; su &prompt.root; make install &prompt.root; chmod 555 /usr/sbin/ppp これでデバッグ可能なバージョンの ppp がインストールされます. root で ppp を実行し, 全ての特権が無効になっているようにする必要があるでしょう. ppp を実行する時には, カレントディレクトリが make したディレクトリであるようにしてください. これで, ppp がセグメンテーション例外を受け取ったときには ppp.core という名前の core ファイルを吐くようになります. core が 吐かれたら次のようにしてください. &prompt.user; su &prompt.root; gdb /usr/sbin/ppp ppp.core (gdb) bt ..... (gdb) f 0 .... (gdb) i args .... (gdb) l ..... 質問する際には, これら全ての情報を提供して, 問題点の分析ができるようにしてください. gdb の使い方に慣れている場合には, 実際に dump の原因となった理由やそのアドレス, 関連した変数の値なども調べる事ができるでしょう. auto モードでダイアルをするようなプロセスが接続されない. これは ppp がローカル側の IP アドレスを, 動的に通信相手と交渉するように設定されている時に発生する良く知られた障害でした. 最新のバージョンでは, この問題は修正されています. iface をマニュアルページから検索してみてください. これは, 最初のプログラムが connect(2) を呼び出した時, tun インターフェイスの IP アドレスが, ソケットの終端に割り当てられてしまうという問題です. カーネルは, 外へ出ていく最初のパケットを作り, それを tun デバイスへ書き込みます. そして ppp は, そのパケットを読み込んで接続を確立します. ppp は動的に IP アドレスを割り当てるため, もしインターフェイスのアドレスが変化してしまうと, 最初に割り当てられたソケット終端の IP アドレスは無効になってしまいます. そのため, それ以降相手に送られる全てのパケットは通常, 相手に届くことはないでしょう. もし仮に届いたとしても, 既にこちらの IP アドレスは変更されているので, どんな反応も最初のマシンには戻ってきません. この問題に対処する理論的な方法がいくつかあります. もし可能なら, 相手が再度, 同じ IP アドレスを割り当ててくれることが一番です :-) ppp の現在のバージョンはこれを行ないますが, 他のほとんどの実装はそういった動作をしません. 我々の側から対処できる最も簡単な方法は, tun インターフェイスの IP アドレスを固定する事です. またそのかわりに, 外に出ていくパケットを変更して, 発信元 IP アドレスをインターフェイスの IP アドレスから, 交渉によって得られた IP アドレスに, 適宜書きかえる事によっても対処できます. これは, 基本的に ppp の最新バージョンにある iface-alias オプションが行なっていることと同じです(libalias(3) および, ppp の スイッチにも関係します). それは, 以前の IP アドレスを全て管理し, それらを最後の交渉によって得られた IP アドレスに対して NAT 機能を有効化します. もう 1 つの(おそらく最も信頼できる)方法は, bind された 全てのソケットの IP アドレスを, 異なるものに変更できるシステムコールを実装することです. pppは, 交渉によって新しい IP アドレスを得た時, このシステムコールを用いて実行されているプログラムにある, 全てのソケットを書きかえてやるわけです. 同じシステムコールが, DHCP クライアントが利用するソケットを 強制的に再 bind するのにも使うことができるでしょう. 3 つ目の方法は, IP アドレスを指定しないでインターフェイスを利用できるようにすることです. 外に出ていくパケットは, 最初の SIOCAIFADDR ioctl の完了まで, 255.255.255.255 という IP アドレス が与えられます. これによって. ソケットは常に bind することができます. ppp に対して発信元 IP アドレスを変更させる事になりますが, もしそれが 255.255.255.255 になっていたら, IP アドレスと IP チェックサムだけ変更すれば良ければの話になります. この方法はちょっとした変更ですが, 他の機構が今までのように, IP アドレスを固定して利用する場合に, カーネルが不適切に設定されたインターフェイスに向けて, 正常でないパケットを送り出してしまう可能性があります. 何故ほとんどのゲームが スイッチ付きだと動かないんですか? libalias を使っている時にゲームなどの類のものが動作しない理由は, 外側にあるマシンが接続しようとしているか, 内側にあるマシンに (余計な)UDP パケットを送信しようとしているからです. 内側のマシンにこれらのパケットを送るべきかについて, NAT ソフトウェアは関知しません. うまく動かすためには, 実行中のものが問題の発生しているソフトウェアだけであるかを確認し, ゲートウェイの tun インタフェースに対して tcpdump を実行するか, ゲートウェイ上で ppp の TCP/IP ログ記録を有効化(set log +tcp/ip)してください. 行儀の悪いソフトウェアを起動する際に, ゲートウェイマシンを通過するパケットを監視すべきです. 外側から何かパケットが戻ってきた時に, そのパケットは破棄されるでしょう(それが問題なのです). これらのパケットのポート番号に注意して, その行儀の悪いソフトウェアを停止してください. これを数回繰り返してポート番号が常に同じであるかを確認してみてください. 同じであった場合は, /etc/ppp/ppp.conf の適切なセクションに次の行を入れると, そのソフトウェアは動作するようになるでしょう. nat port proto internalmachine:port port ここで proto は tcp か udp であり, internalmachine はパケットを送りたいマシン, そして port はパケットの送信先のポート番号です. 上記のコマンドを変更せずに, 他のマシン上でそのソフトウェアを使用できるようにはしたくないかもしれません. そして同時に二つの内部のマシン上でそのソフトウェアを実行することは, この質問の範囲を超えています. 結局, 外側の世界からは, 内部ネットワーク全体がただ一つのマシンとして見えるのです. ポート番号が常に同じとは限らない場合, さらに三つのオプションがあります. libalias でサポートするようにし, 結果を送り付ける. 特定の場合の例は /usr/src/lib/libalias/alias_*.c にあります(alias_ftp.c は良いプロトタイプです). これには通常, 外向きの特定のパケットを読み, 内部の計算機のある特定のポートへの接続を開始するような命令が, 外部の計算機対して送られていることを見分け, 後続のパケットがどこに行けばいいのかが分かるように, エイリアステーブル中の route の部分を設定する, という作業が含まれます. これは最も難しい方法ですが, 最も良い方法でもありますし, ソフトウェアが 複数の計算機で動くようにできます. プロキシ(proxy)を使う. アプリケーションが, 例えば socks5 をサポートしているか, (cvsup のように) passive オプションを持っているとこの方法が使えます. passive とは相手側のほうから接続を求めてくることを避けるためにあるオプションです. nat addr を使ってなんでもかんでも内部の計算機に向けて流してしまう. これはちょっと無理矢理な解決法です. 有用なポート番号のリストはありませんか? まだ出来ていません. しかし, これは(関心を持って頂けるならば)そういったリストにしていく予定です. それぞれの例にある internal は, ゲームで遊ぶマシンの IP アドレスに置き換えてください. Asheron's Call nat port udp internal:65000 65000 手動でゲームのポート番号を 65000 に変更してください. マシンが複数ある場合は, それぞれのマシンに重複しないポート番号(つまり 65001, 65002 など)を設定し, その設定ごとに nat port の行を追加します. Half Life nat port udp internal:27005 27015 PCAnywhere 8.0 nat port udp internal:5632 5632 nat port tcp internal:5631 5631 Quake nat port udp internal:6112 6112 このように設定する代わりに, www.battle.net で Quake のプロキシ(proxy)がサポートされているか調べてもいいでしょう. Quake2 alias port udp internal:27901 27910 Red Alert nat port udp internal:8675 8675 nat port udp internal:5009 5009 FCS エラーって何? FCS とは Frame Check Sequence(フレームチェックシーケンス)の略です. 個々の ppp パケットには, 送受信するデータが正しいかを調べるためのチェックサムが含まれています. 受信したパケットの FCS が正しくない場合は, そのパケットは廃棄され, HDLC FCS カウントが増やされます. HDLC エラーの数 は, show hdlc コマンドを使って表示できます. リンクの品質が悪かったり, シリアルドライバがパケットを取りこぼしていたりすると, FCS エラーがたびたび発生します. FCS エラーは, 圧縮プロトコルの速度低下の原因にはなりますが, 特に心配する必要はありません. 外付けモデムを使っている場合は, ケーブルがちゃんとシールドされているかを確認してください. そうでない場合, FCS エラーの原因となる場合があります. 接続直後からリンクがフリーズし, 大量の FCS エラーが発生する場合は, リンクが 8 ビットクリーンでない可能性があります. ソフトウェアフロー制御(XON/XOFF) が使われていないことを確認してください. どうしてもソフトウェアフロー制御を使わなければならない場合は, set accmap 0x000a0000 コマンドを使用して, ppp に ^Q と ^S をエスケープさせてください. リモートホストが PPP プロトコルを使用してない場合も, 大量の FCS エラーが発生します. この場合はログをとりながら非同期で接続し, ログインプロンプトやシェルプロンプトが送られて来ていないか確認してください. ログファイルにリンクを終了した原因となるような記録がない場合は, リモートホスト(プロバイダ?)の管理者に, セッションを終了された理由を尋ねてください. ゲートウェイで PPPoE を実行すると MacOS や Windows 98 との接続がフリーズしてしまうのですが, これはなぜなのでしょうか? Michael Wozniak mwozniak@netcom.ca 氏が, この現象に関して説明してくれました. また, Dan Flemming danflemming@mac.com 氏は MacOS での解決策を提供してくれました. 情報の提供に感謝します. これは, いわゆる「ブラックホールルータ (Black Hole router)」に原因があります. Windows 98 と MacOS (および, おそらく他の Microsoft 社製 OS) の TCP パケット送出は, PPPoE のフレーム (Ethernet の MTU は標準で 1500) に入らないような大きなセグメントサイズを要求します. そしてさらに分割禁止 ("don't fragment") フラグビットを (TCP パケットにデフォルトで) セットするのですが, Telco のルータは, 分割が必須 ("must fragment") であることを示す ICMP メッセージを, 接続しようとするウェブサイトに対して送出しません (つまり, ルータは正しく ICMP パケットを送出しているのですが, ウェブサイトのファイアウォールがそれを落としているのです). そのためウェブサーバが PPPoE 接続に対して大きすぎるフレームを送出すると Telco のルータはそのフレームを捨ててしまい, 見ようとしたページが表示されないという症状が現われます (MSS より小さいページや画像は表示されます). ほとんどの Telco PPPoE 設定は, 標準でこのように設定されているようです. (ああ, 彼らがルーティングプログラムの作り方を理解してさえいれば...). 一つの解決法は, Windows 95/98 マシンで regedit を使い, 次のレジストリエントリを追加することです. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\NetTrans\0000\MaxMTU レジストリエントリは, 1450 の値 (もっと正確に言うと, TCP パケットを PPPoE フレームに完全に適合させるには 1464 であるべきでですが, 1450 とすると, 現われる可能性がある他の IP プロトコルに対してエラーマージンを確保することができます) にする必要があります. このレジストリキーは, Windows2000 で Tcpip\Parameters\Interfaces\ID for adapter\MTU に移されたという報告がありました. FreeBSD/NAT/PPPoE ルータと共存させるために Windoze の MTU を変更する方法に関する詳細は, Microsoft Knowledge Base にある, 番号 Q158474 - Windows TCPIP Registry Entries, および番号 Q120642 - TCPIP & NBT Configuration Parameters for Windows NT を参照してください. 残念なことに, MacOS には TCP/IP 設定を変更する方法がありません. しかし, Sustainable Softworks 社 が販売している OTAdvancedTuner (OT は OpenTransport という MacOS の TCP/IP スタックの名前のこと) のような商用ソフトウェアが存在します. このソフトウェアは, ユーザから TCP/IP 設定の変更を行なうことを可能にします. MacOS NAT ユーザはドロップダウンメニューから ip_interface_MTU を選択し, ボックスにある 1500 の代わりに 1450 を入力し, Save as Auto Configure の隣のボックスをクリックして Make Active をクリックする必要があります. ppp の最新版 (2.3 かそれ以降) には, 自動的に MSS を適切な値に調節する enable tcpmssfixup コマンドがあります. この機能は標準で有効になっています. もし旧バージョンの ppp を使わなければならない状況にあるなら, tcpmssd の port をご覧になると良いでしょう. どれにも当てはまらない! どうしたらいいの? これまでのすべての質問に当てはまらない場合, 設定ファイル, ppp の実行方法, ログファイルの該当部分と netstat -rn コマンドの出力 (接続前と接続後) を含む, あなたの持っている全ての情報を &a.questions; や comp.unix.bsd.freebsd.misc ニュースグループへ送ってください. 誰かがあなたを正しい方向へ導いてくれるでしょう. シリアル接続 訳: 一宮 亮 ryo@azusa.shinshu-u.ac.jp, 1997 年 11 月 16 日. このセクションでは, FreeBSD でシリアル接続をする時の一般的な質問に答えます. PPP および SLIP については, のセクションを参照してください. どうやったら FreeBSD がシリアルポートを認識したことを知る事ができますか? FreeBSD のカーネルが起動する時, カーネルはその設定にしたがって, システムのシリアルポートを検出します. 起動時に表示されるメッセージをよく観察するか, 起動後に次のコマンドを実行する事によって確認できます. dmesg | grep sio ここに上に挙げたコマンドの出力例を示します. sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A これは, 二つのシリアルポートを示しています. 1 番めは, irq が 4 で 0x3f8 のポートアドレスを使用しています. そして, 16550A-type UART チップが存在します. 2 番目は, 同じチップを使っていますが, irq は 3 で, 0x2f8 のポートアドレスを使用しています. 内蔵のモデムカードは, 通常のシリアルポートと同じように扱われますが, 常時シリアルポートにモデムが接続されているという点で異なります. GENERIC カーネルは, 上の例と同じ irq とポートアドレスの設定の二つのシリアルポートをサポートしています. これらの設定があなたのシステムに合わない場合, またはモデムカードを追加した場合やカーネルの設定以上にシリアルポートを持っている場合は, カーネルを再構築してください. 詳しくは, カーネルの構築の項を参照してください. どうやったら FreeBSD がモデムカードを認識したことを知ることができますか? 前の質問を参照してください. FreeBSD 2.0.5 にアップグレードしたら tty0X が見つからなくなってしまったのですが 心配ありません. ttydX に統合されました. ただ, 古い設定ファイルのすべてを更新する必要があります. どうやったら FreeBSD でシリアルポートにアクセスできますか? 3 番目のポート sio2(DOS では, COM3 と呼ばれます.) には, ダイヤルアウトデバイスとしては /dev/cuaa2, ダイヤルインデバイスとして /dev/ttyd2 があります. それではこの両者にはどのような違いがあるのでしょうか? まず, ダイヤルインの時には ttydX を使います. /dev/ttydX をブロッキングモードでオープンすると, プロセスは対応する cuaaX デバイスがインアクティブになるのを待ちます. 次に CD 信号がアクティブになるのを待ちます. cuaaX デバイスをオープンすると, シリアルポートが ttydX デバイスによってすでに使われていないかどうかを確認します. もしこのポートが使用可能であれば, ポートの使用権を ttydX から「奪い取る」のです. また, cuaXX デバイスは CD 信号を監視しません. この仕組みと自動応答モデムによって, リモートユーザーをログインさせたり, 同じモデムでダイヤルアウトしたりすることができ, システムのあらゆるトラブルの面倒を見ることができるでしょう. マルチポートシリアルカードをサポートさせるにはどうしたらよいのでしょうか? 繰り返しになりますが, カーネルコンフィグレーションのセクションでは, あなたのカーネルの設定についての情報が得られるでしょう. マルチポートシリアルカードを使用するためには, カーネルの設定ファイルに, カードの持つそれぞれのシリアルポートに対応する sio の行を記述する必要があります. しかし, irq とベクタアドレスは一つのエントリにのみ記述してください. カード上のすべてのポートは一つの irq を共有しなければなりません. 一貫性を持たせるためにも, 最後のシリアルポートの所で irq を指定してください. また, COM_MULTIPORT オプションも付けてください. 次に示す例は, AST の 4 ポートシリアルカードを irq 7 で設定したものです. options "COM_MULTIPORT" device sio4 at isa? port 0x2a0 tty flags 0x781 device sio5 at isa? port 0x2a8 tty flags 0x781 device sio6 at isa? port 0x2b0 tty flags 0x781 device sio7 at isa? port 0x2b8 tty flags 0x781 irq 7 vector siointr このフラグはマスタポートがマイナー番号 7(0x700) を持っていて, 検出時の診断機能を有効にし(0x080), そしてすべてのポートで irq を共有する(0x001)ということを意味しています. FreeBSD で複数のマルチポートシリアルカード間で irq を共有することはできますか? 現在のところはできません. それぞれのカード毎に異なった irq を使ってください. ポートにデフォルトのパラメータを設定する事は出来ますか? ttydX デバイス(または cuaaX デバイス)は, アプリケーションのためにオープンする標準的なデバイスです. プロセスがそのポートをオープンする時, プロセスはデフォルトの端末 I/O 設定を取得します. これらの設定は次のコマンドで確認することができます. stty -a -f /dev/ttyd1 このデバイスに対する設定を変更した場合, その設定はデバイスをクローズするまで有効です. デバイスを再オープンした場合, それらの設定はデフォルトに戻ってしまいます. デフォルトの設定に変更を加えるために, 「初期設定」デバイスをオープンし, 設定を修正することができます. 例えば, CLOCAL モード, 8 ビット, XON/XOFF フロー制御という設定を ttyd5 のデフォルトにしたい場合, 次のように行なってください. stty -f /dev/ttyid5 clocal cs8 ixon ixoff この設定を行なうためのコマンドを記述するのに適切なファイルは, /etc/rc.serial です. これでアプリケーションが ttyd5 をオープンした時に, これらの設定をデフォルトで取得します. しかし, こういったリンクによる設定は変更可能です. 「設定固定」デバイスを調整してやることによって, アプリケーションによる設定の変更を禁止することができます. 例えば, ttyd5 の通信速度を 57600bps に固定するには, 次のように行ってください. stty -f /dev/ttyld5 57600 これにより, アプリケーションは ttyd5 をオープンし, ポートの通信速度を変更しようとしますが, 通信速度は 57600bps のままになります. 当然のことながら, 初期設定デバイスおよび, 設定固定デバイスは root のみが書き込みできるようになっていなければなりません. しかし, MAKEDEV スクリプトはデバイスエントリを作成する時に, このような設定は行いません. どのようにしたらモデム経由でダイヤルアップログインができるのでしょうか? つまり, インターネットサービスプロバイダーになりたいのですね. それにはまず, 1 台ないし複数の自動応答モデムが必要です. モデムには, キャリアーを検出した時には CD 信号を出力し, そうでない場合には出力しないことが必要とされます. また DTR 信号が on から off になった時には, 電話回線を切断し, モデム自身をリセットしなければなりません. おそらく, RTS/CTS フロー制御を使うか, ローカルフロー制御をまったく使わないかのどちらかでしょう. 最後に, コンピュータとモデムの間は固定速度でなければなりません. ただ, (ダイヤルアップの発呼者に対して親切であるためには, )こちらのモデムと相手側のモデムの間の速度を, モデム間で自動調整できるようにすべきでしょう. 多くあるヘイズコマンド互換モデムに対して, 次のコマンドはこれらの設定を行ない, その設定を不揮発性メモリーに保存します. AT&C1&D3&K3&Q6S0=1&W MS-DOS のターミナルプログラムに頼らずに AT コマンドを送出するには, 「AT コマンドを入力するには」のセクションを参照してください. 次に, モデム用のエントリを /etc/ttys に作成しましょう. このファイルには, オペレーティングシステムがログインを待っているすべてのポートが記述されています. 以下のような行を追加してください. ttyd1 "/usr/libexec/getty std.57600" dialup on insecure この行は, 2 番目のシリアルポート(/dev/ttyd1)には, 57600bps の通信速度でノンパリティ(std.57600: これは /etc/gettytab に記述されています)のモデムが接続されていることを示しています. このポートの端末タイプは dialup です. またこのポートは, on すなわちログイン可能であり, insecure これは root がこのポートから直接ログインするのは, 許可されていないということを意味します. このようなダイヤルインポートに対しては, ttydX のエントリを使用してください. これが一般的な, ターミナルタイプとして dialup を使う方法です. 多くのユーザーは, .profile や .login で, ログイン時の端末タイプが dialup であった場合には, 実際の端末タイプをユーザーに問い合わせるように設定しています. この例は, ポートが insecure でした. このポートで root になるには, 一般ユーザーとしてログインし, それから su を使って root になってください. もし, secure を指定したならば, 直接 root がそのポートからログインできます. /etc/ttys に変更を加えた後は, HUP シグナル(SIGHUP)を init プロセスに送る必要があります. &prompt.root; kill -HUP 1 この操作は init プロセスに /etc/ttys を再読み込みさせます. これにより, init プロセスは getty プロセスをすべての on となっているポートに起動させます. 次のようにして, ポートがログイン可能かを知ることができます. &prompt.user; ps -ax | grep '[t]tyd1' ログイン可能であれば, 次のような出力が得られるはずです. 747 ?? I 0:00.04 /usr/libexec/getty std.57600 ttyd1 ダムターミナルを FreeBSD マシンに接続するにはどうしたらよいのでしょうか? もし, 他のコンピューターを FreeBSD の端末として接続したいのならば, お互いのシリアルポート間をつなぐヌルモデムケーブル(訳注: リバースケーブルもしくはクロスケーブルとも呼ばれます)を用意してください. もし, 既製の端末を使う場合は, 付属するマニュアルを参照してください. そして, /etc/ttys を上と同じように変更してください. 例えば, WYSE-50 という端末を 5 番目のポートに接続するならば, 次のようなエントリを使用してください. ttyd4 "/usr/libexec/getty std.38400" wyse50 on secure この例は, /dev/ttyd4 ポートにノンパリティ, 端末タイプが wyse50, 通信速度が 38400bps(std.38400: この設定は, /etc/gettytab に記述されています)の端末が存在しており, root のログインが許可されている(secure)であることを示しています. どうして tip や cu が動かないのですか? おそらくあなたのシステムでは tip や cu は uucp ユーザーか, dialer グループによってのみ実行可能なのでしょう. dialer グループは, モデムやリモートシステムにアクセスするユーザーを管理するために, 使用することができます. それには, /etc/group ファイルの dialer グループにあなた自身を追加してください. そうする代わりに, 次のようにタイプすることにより, あなたのシステムの全ユーザーが tip や cu を実行できるようになります. &prompt.root; chmod 4511 /usr/bin/cu &prompt.root; chmod 4511 /usr/bin/tip 私の Hayes モデムはサポートされていないのですが, どうしたらいいのでしょうか. 実際, tip のオンラインマニュアルは古くなっています. すでに, Hayes ダイアラが実装されています. /etc/remote ファイルで, at=hayes と指定してください. Hayes ドライバは, 最近のモデムの新しい機能である, BUSY, NO DIALTONE, CONNECT 115200 などのメッセージを認識できるほど賢くはなく, 単に混乱を起こすだけです. tip を使う場合には(ATX0&Wとするなどして), これらのメッセージを表示させないようにしなくてはいけません. また, tip のダイヤルのタイムアウトは 60 秒です. モデムのタイムアウト設定はそれより短くすべきであり, そうしないと tip は通信に問題があると判断するでしょう. ATS7=45&W を実行してください. 実際, デフォルトの tip は Hayes の完全なサポートをしているわけではありません. 解決方法は /usr/src/usr.bin/tip/tip の下の tipconf.h を変更することです. もちろん, これにはソース配布ファイルが必要です. #define HAYES 0 と記述されている行を #define HAYES1 と変更し, そして make と make install を実行します. これでうまく動作するでしょう. これらの AT コマンドを入力するには? /etc/remote ファイルの中で direct エントリを作ります. たとえばモデムが 1 番目のシリアルポートである /dev/cuaa0に接続されている場合, 次のようにします. cuaa0:dv=/dev/cuaa0:br#19200:pa=none モデムがサポートする最大の bps レートを br フィールドに使います. そして tip cuaa0 を実行すると, モデムが利用できるようになります. /dev/cuaa0がシステムに存在しない場合は, 次のようにします. &prompt.root; cd /dev &prompt.root; ./MAKEDEV cuaa0 または root になって以下のように cu コマンドを実行します. &prompt.root; cu -lline -sspeed line にはシリアルポート(例えば /dev/cuaa0)を指定します. そして speed には接続する速度(例えば 57600)を指定します. その後 AT コマンドを実行したら, ~. と入力すれば終了します. pn 機能の <@> 記号が使えません! 電話番号 (pn) 機能の中での <@> 記号は, tip に /etc/phones にある電話番号を参照するように伝えます. しかし <@> の文字は /etc/remote のような設定ファイルの中では特殊文字となります. そこで, バックスラッシュを使ってエスケープを行います. pn=\@ コマンドラインから電話番号を指定するには? generic エントリと呼ばれるものを /etc/remote に追加します. 例えば, 次のようにします. tip115200|Dial any phone number at 115200 bps:\ :dv=/dev/cuaa0:br#115200:at=hayes:pa=none:du: tip57600|Dial any phone number at 57600 bps:\ :dv=/dev/cuaa0:br#57600:at=hayes:pa=none:du: そして tip -115200 5551234 のように利用できます. tip より cu を使いたい場合, cu の generic エントリを使います. cu115200|Use cu to dial any number at 115200bps:\ :dv=/dev/cuaa1:br#57600:at=hayes:pa=none:du: そして cu 5551234 -s 115200 と実行します. 毎回 bps レートを入力しなければいけませんか? tip1200 や cu1200 用のエントリを記述し, 適切な通信速度を br フィールドに設定します. tip は 1200bps が正しいデフォルト値であるとみなすので, tip1200 エントリを参照します. もちろん 1200bps を使わなければならないわけではありません. ターミナルサーバを経由して複数のホストへアクセスしたいのですが. 毎回接続されるのを待って CONNECT <host> と入力するかわりに, tip の cm 機能を使います. 例えば, /etc/remote に次のようなエントリを追加します. pain|pain.deep13.com|Forrester's machine:\ :cm=CONNECT pain\n:tc=deep13: muffin|muffin.deep13.com|Frank's machine:\ :cm=CONNECT muffin\n:tc=deep13: deep13:Gizmonics Institute terminal server:\ :dv=/dev/cuaa2:br#38400:at=hayes:du:pa=none:pn=5551234: これで, tip pain や tip muffin と実行すると pain や muffin のホストに接続することができ, tip deep13 を実行するとターミナルサーバに接続します. tip を使ってそれぞれのサイトの複数の回線に接続できますか? これは大学に電話回線がいくつかあって, 数千人の学生が接続しようとする場合によくある問題です. あなたの大学のエントリを /etc/remote ファイルに作成して, pn のフィールドには <\@> を使います. big-university:\ :pn=\@:tc=dialout dialout:\ :dv=/dev/cuaa3:br#9600:at=courier:du:pa=none: そして /etc/phones ファイルに大学の電話番号の一覧を書きます. big-university 5551111 big-university 5551112 big-university 5551113 big-university 5551114 tip は一連の電話番号を上から順に試みて, 最終的に接続できなければあきらめます. リトライを続けさせたい場合は, tip を while ループに入れて実行します. CTRL+P を 1 回送るために 2 度押す必要があるのはなぜ? CTRL+P は通常「強制(force)」文字であり, tip に次の文字がリテラルデータであることを伝えます. 強制文字は「変数の設定」を意味する ~s エスケープによって, 他の文字にすることができます. ~sforce=<single-char> と入力して改行します. <single-char> は, 任意の 1 バイト文字です. <single-char> を省略すると NUL 文字になり, これは CTRL+2 や CTRL+SPACE を押しても入力できます. いくつかのターミナルサーバで使われているのを見ただけですが, <single-char> に SHIFT+CTRL+6 に割り当てるのもよいでしょう. $HOME/.tiprc に次のように定義することで, 任意の文字を強制文字として利用できます. force=<single-char> 打ち込んだ文字が突然すべて大文字になりました?? CTRL+A を押してしまい, caps-lock キーが壊れている場合のために設計された tip の raise character モードに入ったのでしょう. 既に述べた ~s を使って, raisechar をより適切な値に変更してください. もしこれら両方の機能を使用しないのであれば, 強制文字と同じ設定にすることもできます. 以下は CTRL+2 や CTRL+A などを頻繁に使う必要のある Emacs ユーザにうってつけの .tiprc ファイルのサンプルです. force=^^ raisechar=^^ ^ は SHIFT+CTRL+6 です. tip でファイルを転送するには? もし他の UNIX のシステムと接続しているなら, ~p(送信)や ~t(受信)でファイルの送受信ができます. これらのコマンドは, 相手のシステムの上で cat や echo を実行することで送受信をします. 書式は以下のようになります. ~p <ローカルのファイル名> [<リモートのファイル名>] ~t <リモートのファイル名> [<ローカルのファイル名>] この方法ではエラーチェックを行いませんので, zmodem などの他のプロトコルを使った方がよいでしょう. tip から zmodem を実行するには? まず始めに, FreeBSD Ports Collection(lrzszと rzsz との, 2 つの通信カテゴリーのプログラムのどちらか)をインストールします. ファイルを受信するには, リモート側で送信プログラムを起動します. そして, Enter キーを押してから ~C rz (lrzsz をインストールした場合は ~C lrz)と入力すると, ローカル側へのファイルの受信が始まります. ファイルを送信するには, リモート側で受信プログラムを起動します. そして, Enter キーを押してから ~C sz <files> (lrzsz をインストールした場合は ~C lsz <files>)と入力すると, リモート側へのファイルの送信が始まります. 設定が正しいのにもかかわらず, FreeBSD がシリアルポートを見付けられません. マザーボードやシリアルカードが Acer の UART チップを使った物の場合, FreeBSD の sio ドライバでは正しく検出する事が出来ません. この問題を解決するためには, www.lemis.com からパッチを入手してください. その他の質問 訳: &a.jp.yoshiaki;, &a.jp.sugimura;, 福間 康弘 yasuf@big.or.jp, 1997 年 11 月 10 日 - 1999 年 5 月 8 日. FreeBSD は Linux より多くのスワップ領域を消費するのはなぜですか? 実際にはそうではありません. FreeBSD は Linux よりもスワップを多く使っているように見えるだけです. この点における FreeBSD と Linux の主な違いは, FreeBSD はより多くのメインメモリを有効利用できるようにするため, 完全にアイドルになったものやメインメモリ上の使われなくなったページを, スワップにあらかじめ積極的に移動しているということです. Linux では, 最後の手段としてページをスワップに移動させるだけという傾向があります. このスワップの使い方は, メインメモリをより効果的に使用することによってバランスが保たれています. FreeBSD はこのような状況では先手策を取りますが, システムが本当に空き状態の時に, 理由も無くページをスワップしようと決めることはないということに注意してください. したがって, 夜中に使わずにおいたシステムが朝起きたとき, すべてページアウトされているということはないのです. ほとんどプログラムは実行されていないのに, どうして &man.top.1; は非常に少ない free memory を報告するのでしょうか? 簡単に言えば, free memory とは無駄になっているメモリのことだからです. プログラムが確保しているメモリ以外のすべてのメモリは, FreeBSD カーネル内でディスクキャッシュとして利用されます. この値は &man.top.1; において Inact, Cache Buf として表示され, それぞれは異なるエージングレベル (訳注: データがどれだけ古いかを示す評価値) でキャッシュされた全データを表します. データがキャッシュされると言うのは, 最近アクセスされたデータであれば, 再度そのデータをアクセスするためにシステムが遅いディスクにアクセスする必要がない, ということを意味します. そのため, 全体のパフォーマンスが向上します. 一般的に, &man.top.1; で表示される Free メモリが小さい値を示すことは良いことで, 自由に使えるメモリの残量が本当に少ない, ということを表しているわけではありません. FreeBSD の実行フォーマットの a.out, ELF とはどのようなものですか? また, a.out, ELF を使う理由は何でしょう? FreeBSD が何故 ELF フォーマットを利用しているのかを理解するためには, まず UNIXにおいて現在「優勢」な 3 種類の実行フォーマットについて いくらか知っておく必要があります. FreeBSD 3.x より前の FreeBSD では a.out フォーマットが使われていました. a.out 最も古く 「由緒正しい」 unix オブジェクトフォーマットです. マジックナンバを含む短くてコンパクトなヘッダが先頭にあり, これがフォーマットの特徴とされています(a.out(5) に詳細な内容があります). ロードされる 3種類のセグメント, .text, .data, .bss と加えてシンボルテーブルと文字列テーブルを含みます. COFF SVR3 のオブジェクトフォーマットです. ヘッダは単一のセクションテーブルから成り, .text, .data, .bss セクション以外の部分を持つことができます. ELF COFFの後継です. 複数のセクションをサポートし, 32-bit と 64-bitのいずれの値も可能です. 大きな欠点の一つは, ELF はそれぞれのシステムアーキテクチャ毎に単一の ABI のみが存在するという仮定で設計されていることです. この仮定はまったく正しくありません. 商用の SYSV の世界でさえそうです(少なくとも SVR4, Solaris, SCO の 3種類の ABI があります). FreeBSD はこの問題を解決するための試みとして, 既知の ELF 実行ファイルに ABI に応じた情報を 書き加えるユーティリティを提供しています. brandelf のマニュアルページを参照してください. より多くの情報があります. FreeBSD は伝統的な立場をとり, 数多くの世代の BSD のリリースで試され, 実証されてきた a.out フォーマットを伝統的に使用しています. いつかは FreeBSD システムでネイティブ ELF バイナリを作り, 実行することができるようになるかもしれませんが, 初期の頃 FreeBSD では ELF をデフォルトのフォーマットに変更するという動きは ありませんでした. なぜでしょうか? ところで Linux においては, ELF への苦痛をともなった変更は, その時に a.out 実行フォーマットから逃れたというよりは, ジャンプテーブルベースの共有ライブラリのメカニズムの柔軟性の低さからの脱却でした. これはベンダや開発者全体にとって, 共有ライブラリの作成が非常に難しかった原因でした. ELF のツールには共有ライブラリの問題を解決することができるものが提供されており, またいずれにせよ一般的に「進歩」していると考えられます. このため移行のコストは必要なものとして容認され, 移行は行なわれました. FreeBSD の場合は, 共有ライブラリのメカニズムは Sun の SunOS スタイルの共有ライブラリのメカニズムに極めて近いものになっていて, 非常に使いやすいものになっています. しかしながら, FreeBSD では 3.0 から ELF バイナリをデフォルトのフォーマットとして公式にサポートしています. a.out 実行フォーマットはよいものを私達に提供してくれているものの, 私たちの使っているコンパイラの作者である GNU の人々は a.out フォーマットのサポートをやめてしまったのでした. このことは, 私たちに別バージョンのコンパイラとリンカを保守することを余儀なくされることとなり, 最新の GNU 開発の努力による恩恵から遠ざかることになります. その上, ISO C++ の, とくにコンストラクタやデストラクタがらみの要求もあって, 今後の FreeBSD のリリースでネイティブの ELF のサポートされる方向へと話が進んでいます. それにしても, なぜそんなに多くのフォーマットがあるのですか? もうおぼろげになってしまった暗い過去に, 単純なハードウェアがありました. この単純なハードウェアは, 単純で小さなシステムをサポートしていました. a.out はこの単純なシステム(PDP-11) での作業を行なうバイナリとして完全に適したものだったのです. 人々はこの単純なシステムから UNIX を移植する際に, a.out フォーマットをそのまま使いました. というのは Motorola 68k, VAXen, といったアーキテクチャへの UNIX の初期の移植ではこれで十分だったからです. やがてある聡明なエンジニアが, ソフトウェアでちょっとしたトリックを使うことを決めました. 彼はいくつかのゲートを削り取って CPU のコアをより速く走らせることができたのです. これは新しい種類のハードウェア(今日では RISC として知られています)で動いたのです. a.out はこのハードウェアには適していなかったので, このハードウェア上で多くのフォーマットが, 限定された単純な a.out フォーマットでのものよりもより良いパフォーマンスを出すことを目指して開発されたのです. COFF, ECOFF, そしていくつかの有名でないフォーマットが ELF が標準になる前に開発され, それらの限界が探求されたのです. さらに, プログラムサイズは巨大になり, ディスク(および物理メモリ)は依然として相対的に小さかったため, 共用ライブラリのコンセプトが誕生しました. また, VM システムはより複雑なものになりました. これらの個々の進歩は a.out フォーマットを使用して遂げられましたが, その有用性は新しい機能とともにどんどん広がってきました. これらに加え, 実行時に必要なものを動的にロードする, または初期化コードの実行後にプログラムの一部を破棄し, コアメモリおよびスワップ空間を節約するという要望が高まりました. プログラミング言語はさらに複雑になり, main 関数の前に自動的にコールされるコードの要望が高まりました. 多くの機能拡張が行なわれ, a.out フォーマットがこれらすべてを実現できるようになり, それらはしばらくは基本的に動作していました. やがて, a.out はコードでのオーバヘッドと複雑さを増大させずに, これらの問題すべてを処理することに無理がでてきました. 一方, ELF はこれらの問題の多くを解決しますが, 現状稼働しているシステムからの切替えは厄介なものになるでしょう. そのため ELF は, a.out のままでいることが ELF への移行よりももっと厄介なものになるまで待つ必要がありました. しかし時が経つにつれ, FreeBSD のビルドツールの元となったツール群(特にアセンブラとローダ)と FreeBSD のビルドツール群は異なった進化の経路をたどりました. FreeBSD のツリーでは, 共有ライブラリが追加され, バグフィックスも行われました. もともとのツール群を作成した GNU の人たちは, プログラムを書き直し, クロスコンパイラのサポート, 異なるフォーマットを任意に取り込む機能などを追加していきました. 多くの人々が FreeBSD をターゲットとしたクロスコンパイラの構築を試みましたが, FreeBSD の使っている as と ld の古いプログラムコードはクロスコンパイルをサポートしておらず, うまくいきませんでした. 新しい GNU のツール群(binutils)は, クロスコンパイル, 共有ライブラリ, C++ 拡張などの機能をサポートしています. さらに数多くのベンダが ELF バイナリをリリースしています. FreeBSD にとって ELF バイナリが実行できることは, 非常にメリットがあります. ELF バイナリが FreeBSD で動くのなら, a.out を動かすのに手間をかける必要はありませんね. 長い間忠実によく働いた老いた馬は, そろそろ牧草地で休ませてあげましょう. ELF は a.out に比べてより表現力があり, ベースのシステムに対してより幅広い拡張性を提供できます. ELF 用のツールはよりよく保守されています. また多くの人にとって重要なクロスコンパイルもサポートしています. ELF の実行速度は, ほんの少し a.out より遅いかもしれませんが, 実際に速度の差をはかるのは困難でしょう. ELF と a.out の間には, ページマッピング, 初期化コードの処理など多くの違いがありますが, とりたてて重要なものはありません. しかし違いがあるのは確かです. ほどなく, GENERIC カーネルから a.out のサポートが外されます. a.out のプログラムを実行する必要性がなくなれば, 最終的に a.out のサポートはカーネルから削除されます. シンボリックリンクの許可属性を chmod で変えられないのはなぜですか? シンボリックリンクは許可属性を持ちません. また &man.chmod.1; のデフォルト動作は, シンボリックリンクをたどってリンク先のファイルの許可属性を変更するようになっていません. そのため, foo というファイルがあり, このファイルへのシンボリックリンク bar があったとすると, 以下のコマンドは常に成功します. &prompt.user; chmod g-w bar しかしこの場合, foo の許可属性は変更されません. この場合, か のどちらかのオプションを と同時に使う必要があります. chmod と symlink のマニュアルページにはもっと詳しい情報があります. オプションは再帰的に chmod を実行します. ディレクトリやディレクトリへのシンボリックリンクを chmod する場合は気をつけてください. シンボリックリンクで参照されている単一のディレクトリのパーミッションを変更したい場合は, chmod をオプションをつけずに, シンボリックリンクの名前の後ろにスラッシュ(/) をつけて使います. 例えば, foo がディレクトリ bar へのシンボリックリンクである場合, foo(実際には bar)のパーミッションを変更したい場合には, このようにします. &prompt.user; chmod 555 foo/ 後ろにスラッシュをつけると, chmod はシンボリックリンク foo を追いかけてディレクトリ bar のパーミッションを変更します. ログイン名がいまだに 8 文字に制限されているのはなぜですか? UT_NAMESIZE を変更してシステム全体を作り直せば十分で, それだけでうまくいくだろうとあなたは考えるかもしれません. 残念ながら多くのアプリケーションやユーティリティ(システムツールも含めて)は, 小さな数値を構造体やバッファなどに使っています(必ずしも 8 や 9 ではなく, 15 や 20 などの変った値を使うものもあります). (固定長のレコードを期待するところで可変長レコードになるため, )台無しになったログファイルを得ることになるということだけでなく, Sun の NIS のクライアントの場合は問題が起きますし, 他の UNIX システムとの関連においてこれら以外の問題も起きる可能性があります. しかし, FreeBSD 3.0 以降では 16 文字となり, 多くのユーティリティのハードコードされた名前の長さの問題も解決されます. 実際にはシステムのあまりに多くの部分を修正するために, 3.0 になるまでは変更が行われませんでした. それ以前のバージョンでは, これらの問題が起こった場合に, 問題を自分自身で発見し, 解決できることに絶対的な自信がある場合は /usr/include/utmp.h を編集し, UT_NAMESIZE の変更にしたがって, 長いユーザ名を使うことができます. また, UT_NAMESIZE の変更と一致するように /usr/include/sys/param.h の MAXLOGNAME 更新しなくてはなりません. 最後に, ソースからビルドする場合は /usr/include を毎回アップデートする必要があることを忘れないように! /usr/src/.. 上のファイルを変更しておいて置き換えましょう. FreeBSD 上で DOS のバイナリを動かすことはできますか? はい, FreeBSD 3.0 からは, 統合と改良が重ねられた BSDI の doscmd DOS エミュレーションサブシステムを使ってできるようになりました. 今なお続けられているこの努力に興味を持って参加していただけるなら, &a.emulation; へメールを送ってください. FreeBSD 3.0 以前のシステムでは, pcemu という巧妙なユーティリティが FreeBSD Ports Collection にあり, 8088 のエミュレーションと DOS のテキストモードアプリケーションを動かすに十分な BIOS サービスを行ないます. これは X ウィンドウシステムが必要です(XFree86 として提供されています). sup とは何で, どのようにして使うものなのでしょうか? SUP とは, ソフトウェアアップデートプロトコル(Software Update Protocol)で カーネギーメロン大学(CMU)で開発ツリーの同期のために開発されました. 私たちの中心開発ツリーをリモートサイトで同期させるために使っていました. SUP はバンド幅を浪費しますので, 今は使っていません. ソースコードのアップデートの現在のおすすめの方法は FreeBSD ハンドブックの「CVSup」にあります. FreeBSD をクールに使うには? FreeBSD を動かす時に温度測定を行なった人はいますか? Linux は dos よりも温度が下がるということは知っていますが, FreeBSD についてはこのようなことに触れたものを見たことはありません. 実際熱くなっているように見えます. いいえ. 私たちは 250 マイクログラムの LSD-25 をあらかじめ与えておいたボランティアに対する, 目隠し味覚テストを大量に行なっています. 35% のボランティアは FreeBSD はオレンジのような味がすると言っているのに対し, Linux は紫煙のような味わいがあると言っている人もいます. 私の知る限り両方のグループとも温度の不一致については触れていません. この調査で, 非常に多くのボランティアがテストを行なった部屋から不思議そうに出てきて, このようなおかしな結果を示したことに私たちは当惑させられました. 私は, ほとんどのボランティアは Apple にいて彼らの最新の「引っかいて匂いをかぐ」GUI を使っているのではないかと考えています. 私たちは奇妙な古い仕事をしているのでしょう! 真面目に言うと, FreeBSD や Linux は共に HLT (停止) 命令をシステムのアイドル(idle)時に使い, エネルギーの消費を押えていますので熱の発生も少なくなります. また, APM(advanced power management) を設定してあるなら FreeBSD は CPU をローパワーモードにすることができます. 誰かが私のメモリカードをひっかいているのですか?? FreeBSDでカーネルのコンパイルをしている時, メモリから引っかいているような奇妙な音が聞こえるようなことはあるのでしょうか? コンパイルをしている時(あるいは起動時にフロッピドライブを認識した後の短い間など), 奇妙な引っかくような音がメモリカードのあたりから聞こえてきます. その通り! BSD の文書には良く, デーモン(daemon)という言葉が出てきます. ほとんどの人は知らないのですが, デーモンとは, あなたのコンピュータを依り代とする, 純粋で非物質的な存在のことです. メモリから聞こえるひっかくような音は, さまざまあるシステム管理タスクの扱いをいかに最善なものにするか, といったことを決めるときにデーモンたちが交わす, かん高いささやき声なのです. この雑音が聞こえたとき, DOS から fdisk /mbr というプログラムを実行すれば, うまくデーモンを追い出すことができるでしょう. でも, デーモンはそれに歯向かって fdisk の実行をやめさせようとするかも知れません. もし, それを実行しているときにスピーカならビル ゲイツ(Bill Gates)の悪魔のささやきが聞こえてきたら, すぐに立ち上がって逃げてください. 決して振り返ってはいけません! BSD のデーモンたちが押え込んでいた双子のデーモン, DOS と Windows が解放され, あなたの魂を永遠の破滅へ導こうとマシンを再び支配してしまうことでしょう. ええ, 選べと言われたら, わたしはむしろ, ひっかき音に慣れる方を選ぶでしょうね. "MFC" とはどういう意味ですか MFC とは, 「CURRENT との合流(Merged From -CURRENT)」の頭文字をとったものです. CVS ログで -CURRENT から -STABLE ブランチへの合流を示します. "BSD" とはどういう意味ですか? この言葉は, 仲間うちだけに分かる隠語で何とかという意味です. 文字どおりに訳すことはできませんが, BSD の訳は「F1 のレーシングチーム」か「ペンギンはおいしいスナック」, あるいは「俺たちゃ Linux より洒落は利いてるぜ」とかそのへんだと言っておけばおっけーでしょう. :-) 冗談はさておき. BSD とは, Berkeley CSRG(コンピュータシステム評議会)が彼らの UNIX の配布形態の名前として当時選んだ "Berkeley Software Distribution" の略です. リポジトリ・コピー (repo-copy) とは一体何のことでしょう? repo-copy (repository copy の略) とは, CVS リポジトリの中で直接ファイルをコピーすることを示す用語です. repo-copy を行なわない場合を考えます. リポジトリの中の異なる場所にファイルをコピーしたり, 移動したりする必要性が生じると, コミッターは ファイルを新しい場所に置くために cvs add を, そして古いファイルが削除される場合は, 古いファイルに対して cvs rm を実行するでしょう. この方法の欠点は, ファイルの変更履歴 (たとえば CVS ログのエントリ) が新しい場所にコピーされないことです. FreeBSD プロジェクトではこの変更履歴をとても有用なものだと考えているため, 前述の方法の代わりにリポジトリコピーが良く用いられます. この操作は cvs プログラムを利用するのではなく, リポジトリの管理担当者がリポジトリの中でファイルを直接コピーすることによって行なわれます. なんでバイク小屋 (bikeshed) の色にまで気を使わなければいけないんですか? 一言で言ってしまえば, そうすべきではありません. もう少し詳しく説明しましょう. たとえば, あなたがバイク小屋を建てる技術を持っていたとします. しかしそれは, 塗ろうとしている色が気に入らないからと言って, 他人がバイク小屋を建てようとしているのを止めて良い理由にはなりませんよね. これは, 自分の行動について十分な理解を持っているなら, あなたは細かな機能すべてにわたって議論する必要はないことを示す比喩です. ある変更によって産み出されるノイズの総量は, その変更の複雑さに反比例するのだと言っている人達もいます. さらに詳しく, 完全な回答を紹介しましょう. Poul-Henning Kamp は, 「&man.sleep.1; は分数の秒数を引数として取るべきか」という 非常に長い議論の後で, A bike shed (any colour will do) on greener grass... というタイトルの長文を投稿しました. 関係のある部分だけを以下に掲載します.
1999 年 10 月 2 日 freebsd-hackers にて Poul-Henning Kamp このバイク小屋, どうだろう? 誰かがたずねました. 長い…というか, むしろ古い話になりますが, 中身はわりと簡単な話です. パーキンソン (C. Northcote Parkinson) は 1960 年代初頭に パーキンソンの法則 と呼ばれる本を書きました. この中にはさまざまな経営の力学に関する洞察が含まれています. [ この本に関する解説があったが省略 ] バイク小屋に関連する例として, もう一つの重要な構成要素となっているのは原子力発電所です. この本の年代がわかりますね. パーキンソンは, あなたが重役会に出席して 数百万から数10億ドル規模の原子力発電所の建設の承認を得る ことはできるでしょうが, あなたが建てたいのがバイク小屋ならば, 終わりなき議論に巻き込まれるだろうと言っています. パーキンソンはこのように説明しています. これは原発が余りに巨大で高価で複雑なので誰もこれを一手に握ることができず, それを試みるくらいならむしろ, 手が出せなくなる前に 他の誰かがすべてを詳細にチェックすることを 引き受けることに頼るのです. リチャード・ファインマン (Richard P. Feynmann) は, ロスアラモスでこの手の重要な経験を何度も見てきたと本に書いています. 一方でバイク小屋の場合は, 誰でも週末にこれを作り上げることができ, しかも TV の試合を見る時間があまるほどです. なので, どんなに準備が整えてあって, どんなに計画が順当であったとしても, わたしは仕事をやっているよ, わたしは注意を払っているよ, そして わたしはここにいるよ, ということを示そうとする人が必ず現れます. デンマークではこれを「指紋をつける」と呼んでいます. これは個人的なプライドや名声を求め, ある場所を指し示して「ここ! ここは俺が やったんだぜ〜」というようなものです. これは政治家に見られる強い特徴ですが, その他のほとんどの人もこういう風に振舞う可能性はあるのです. 生乾きのセメントにつけられた足跡のことを考えればお分かりでしょう.
ひとつの電球を取り替えるのに, 何人の FreeBSD ハッカーが必要? 1,172人です. 電球が消えていると -CURRENT で文句を言うのに 23 人. 設定上の問題で -questions で話をすべきことについて騒ぐのに 4 人. それを send-pr (訳注: 障害報告) するのに 3 人(そのうちのひとつは間違って doc カテゴリに送りつけられたうえに, 内容が「暗くなった」というだけのもの). buildworld を失敗させ, 5 分後には元に戻されるような電球を テストもせずにコミットするのに 1 人. send-pr した人に, パッチが含まれていないと「いちゃもん」を付けるのに 8 人. buildworld が失敗すると文句を言うのに 5 人. 自分のところではちゃんと動く, cvsup したタイミングが悪かったんだろうと答えるのに 31 人. 新しい電球のためのパッチを -hackers に投げるのに 1 人. 自分は 3年も前にパッチを作ったが, それを -CURRENT に投げたときには無視されただけだった, 自分は send-pr のシステムには嫌な経験があると(おまけに, 提案された新しい電球には柔軟性が無いとまで)文句を言うのに 1 人. 電球が基本システムに組み込まれていない, committer はコミュニティの意見を聞くこと無しにこんなことをする権利は無いと叫び, 「こんなときに -core は何をやってるんだ!?」とわめきちらすのに 37 人. 自転車置き場の色に文句を言うのに 200 人. パッチが style(9) 違反だと指摘するのに 3 人. 提案された新しい電球は GPL の下にあると文句を言うのに 70 人. GPL と BSD ライセンスと MIT ライセンスと NPL と, 某 FSF 創立者らの個人的な健康法の優位性についての論争を戦わすのに 586 人. スレッドのあちこちの枝を -chat や -advocacy に移動するのに 7 人. 提案された電球を, 古いのよりずっと薄暗いのにコミットしてしまうのに 1 人. FreeBSD に薄暗い電球を付けるくらいなら真っ暗のほうがましだという, コミットメッセージへの凄まじい非難の嵐によって, それを元に戻すのに 2 人. 薄暗い電球が帳消しにされたことに対してどなり声で口論し, -core の声明を要求するのに 46 人. もし FreeBSD をたまごっちに移植することになったときに都合がいいように, もっと小さな電球を要求するのに 11 人. -hackers と -chat の S/N比に文句を言い, 抗議のため講読を取りやめるのに 73 人. 「unsubscribe」「どうやったら講読をやめられるんですか?」 「このメーリングリストからわたしを外してください」といった メッセージを, 例のフッタをくっつけて投稿するのに 13 人. みんなが激論を戦わせるのに忙がしくて気付かない間に, 作業中の電球をコミットするのに 1 人. 新しい電球は TenDRA を使ってコンパイルされた場合に 0.364% も明るくなる(ただし電球を立方体にしなければならない), だから FreeBSD は EGCS から TenDRA に変えるべきだと指摘するのに 31 人. 新しい電球は美しさに欠けていると文句を言うのに 1 人. 「MFC って何ですか?」と聞くのに 9 人(send-pr した人も含む). 電球が取り替えられてから 2 週間も消えっぱなしだと文句を言うのに 57 人. &a.nik; による追記 これには爆笑しました. それからわたしは考えました. 「ちょっと待てよ? このリストのどこかに, 『これを文書にまとめるのに 1人』というのがあってもいいんじゃないか?」 それからわたしは悟りを開いたのです :-) この項目の著作権は Copyright (c) 1999 &a.des; にあります. 無断で使用しないでください. まじめな FreeBSD ハッカーだけの話題 訳: &a.iwasaki;, 1997 年 11 月 8 日. SNAP とか RELEASE とかは何? 現在, FreeBSD の CVS リポジトリ には, 三つのアクティブ/準アクティブなブランチがあります (アクティブな開発ブランチは三つしか存在しないため, おそらく RELENG_2 ブランチの変更は年に 2 回だけになるでしょう). RELENG_2_2 通称 2.2-STABLE RELENG_3 通称 3.X-STABLE RELENG_4 通称 4-STABLE HEAD 通称 あるいは 5.0-CURRENT HEAD は他の二つと違って, 実際のブランチタグではなく, 「current, 分岐していない開発本流」のための単なるシンボリックな定数です. 私たちはこれを -CURRENT と呼んでいます. 現在, -CURRENT は 5.0 の開発本流であり, 4.0-STABLE ブランチ, つまり RELENG_4 は 2000 年 3 月に -CURRENT から分岐しています. 2.2-STABLE ブランチ, RELENG_2_2 は 1996 年 11 月に -CURRENT から分岐しました. これは保守が完全に終了しています. 自分用のカスタムリリースを構築するには? リリースを構築するには三つのことが必要です. まず, vn ドライバが組み込まれたカーネルを実行させている必要があります. 以下をカーネルコンフィグレーションファイルに追加し, カーネルを作り直してください. pseudo-device vn #Vnode driver (turns a file into a device) 次に, CVS リポジトリ全体を手元においておく必要があります. これを入手するには CVSUP が使用できますが, supfile で release の名称を cvs にして 他のタグや date フィールドを削除する必要があります. *default prefix=/home/ncvs *default base=/a *default host=cvsup.FreeBSD.org *default release=cvs *default delete compress use-rel-suffix ## Main Source Tree src-all src-eBones src-secure # Other stuff ports-all www doc-all そして cvsup -g supfile を実行して自分のマシンに CVS リポジトリ全体をコピーします... 最後に, ビルド用にかなりの空き領域を用意する必要があります. そのディレクトリを /some/big/filesystem として, 上の例で CVS リポジトリを /home/ncvs に置いたものとすると, 以下のようにしてリリースを構築します. &prompt.root; setenv CVSROOT /home/ncvs # or export CVSROOT=/home/ncvs &prompt.root; cd /usr/src &prompt.root; make buildworld &prompt.root; cd /usr/src/release &prompt.root; make release BUILDNAME=3.0-MY-SNAP CHROOTDIR=/some/big/filesystem/release
ただし, すでに /usr/obj 以下に構築物が存在しているなら, buildworld の必要はありません.
処理が終了すると, リリース全体が /some/big/filesystem/release に構築され, 完全な FTP インストール用の配布物が /some/big/filesystem/release/R/ftp に作成されます. -current 以外の開発ブランチの SNAP を自分で構築したい場合は, RELEASETAG=SOMETAG を上の make release のコマンドラインに追加します. 例えば, RELEASETAG=RELENG_2_2 とすると最新の 2.2-STABLE snapshot が構築されます. カスタムのインストールディスクを作るにはどうすればいいのですか? /usr/src/release/Makefile のいろいろなターゲットとしてインストールディスク, ソース, バイナリアーカイブを作る完全な処理を自動的に行なうようになっています. Makefile に十分な情報があります. しかし, 実行には make world が必要で, 多くの時間とディスクの容量が必要です. make world を行なうと既存のバイナリを上書きしてしまうのですが. ええ, それが一般的な考え方です. 名前が示しているように make world はすべてのシステムのバイナリを最初から作り直しますので, 結果として, クリーンで一貫性のある環境を得ることができます(これがそれだけ長い時間がかかる理由です). 環境変数 DESTDIR を make world や make install を実行する時に定義しておくと, 新しく作られたバイナリは ${DESTDIR}を root とみなしたディレクトリツリーにインストールされます. あるでたらめな共有ライブラリの変更やプログラムの再構築によって make world は失敗することもあります. システム起動時に (bus speed defaulted) とメッセージが出ます. Adaptec の 1542 SCSI ホストアダプタは, ユーザがソフトウェア的にバスアクセス速度の設定を行なうことができます. 以前のバージョンの 1542 ドライバは, 使用可能な最大の速度を求めてアダプタをその設定にしようとしました. これは特定のユーザのシステムでは問題がある事がわかり, 現在ではカーネルコンフィグオプションに TUNE_1542 が加えられています. これを使用すると, これが働くシステムではディスクが速くなりますが, データの衝突が起きて速くはならないシステムもあるでしょう インターネットアクセスに制限があっても current を追いかけられますか? はい, CTM システムを使って, ソースツリー全体のダウンロードを行なわずに追いかけることができます. どのようにして配布ファイルを 240KB に分割しているのですか? 比較的新しい BSD ベースのシステムでは, split に任意のバイト境界で分割する オプションがあります. 以下は /usr/src/Makefile からの例です. bin-tarball: (cd ${DISTDIR}; \ tar cf - . \ gzip --no-name -9 -c | \ split -b 240640 - \ ${RELEASEDIR}/tarballs/bindist/bin_tgz.) 私はカーネルに拡張を行ないました. 誰に送ればいいですか? FreeBSD ハンドブックの「FreeBSD への貢献」を参照してください. あなたのアイディアに感謝します! PnP ISA カードの検出と初期化はどのように行なうのですか? Frank Durda IV 氏 より:
要点は, ホストが認識されていないボードを探す時に, すべての PnP ボードが応答することのできる少数の I/O ポートがあるということです. それにより, PnP プローブルーチンが開始したとき, PnP ボードが存在するなら, すべての PnP ボードは自分のモデル番号を返します. そのポートを I/O read するとプローブルーチンは問いに対するワイアード-OR された yes を得ます. この場合は 少なくとも 1ビットが ON になります. そして, プローブルーチンはモデル ID(Microsoft/Intel によって割り当てられています)が X より小さいボードを オフライン にすることができます. この操作を行ない, 問い合わせに応答しているボードがまだ 残っているかどうかを調べます. もし 0 が返ってくるなら X より大きな ID を持つボードはないことになります. 今度は X よりも小さな値を持つボードについて問い合わせます. もしあるのであれば, プローブルーチンはモデル番号が X より小さいことを知ります. 今度は, X-(limit/4) より大きな値を持つボードをオフラインにして問い合わせを繰り返します. この ID の範囲による準バイナリサーチを十分繰り返すことにより, プローブルーチンはマシンに存在するすべての PnP ボードの値を最終的に得ることができます. その繰り返しの回数は 2^64 よりはるかに少ない回数です. ID は二つの 32-bit (つまり 64bit) フィールド + 8 bit チェックサムからなります. 最初の 32 bits はベンダの識別子です. これは公表されてはいませんが, 同一のベンダから供給されている異なるタイプのボードでは異なる 32-bit ベンダ ID を持つことができるように考えられます. 製造元を特定するだけのために 32-bit はいくらか過剰です. 下位の 32-bit はシリアル番号, イーサネットアドレスなどのボードを特定するものです. ベンダは上位 32 bits が異なっていないのであれば, 下位 32-bit が同一である 2枚目のボードを製造することはありません. したがって, 同じタイプの複数のボードをマシンにいれることができ, この場合でも 64-bit 全体ではユニークです. 32-bit のフィールドはすべてを 0 にすることはできません. これは初期化のバイナリサーチの間ワイアード-OR によって 0 ではない ビットを参照するからです. システムがすべてのボードの与えられた ID を認識すると, それぞれのボードに対応した処理を一つずつ(同一の I/O ポートを通して)行ないます. そして, 利用できる割り込みの選択などのボードが必要とするリソースを検出します. すべてのボードについてこの情報を集めます. この情報はハードディスク上の ECU ファイルなどの情報とまとめられ, マザーボードの BIOS にも結合されます. マザーボード上のハードウェアへの ECU と BIOS PnP のサポートは通常は統合されていますが, 周辺機器については真の PnPであるとはいえません. しかし, BIOS の情報に ECU の情報を加えて調査することで, プローブルーチンは PnP デバイスが再配置できなくなることを避けることができます. それから, 再度 PnP デバイスにアクセスし, I/O, DMA, IRQ, メモリマップアドレスの設定をします. デバイスはこのアドレスに見えるようになり, 次に再起動するまでこの位置を占めます. しかし, あなたの望む時に移動させることが不可能である, といっているわけではありません. 以上の話では大きく単純化をしてありますが, 基本的な考え方は得られたでしょう. マイクロソフトは, ボードのロジックが対立する I/O サイクルではデコードしていない(訳注: おそらく read 時しかデコードされていず write 時はポートが空いているという意味でしょう), プライマリプリンタのステータスポートのいくつかを PnP のために占有しました. 私は初期の PnP の提案レビュー時に IBM 純正のプリンタボードでステータスポートの write のデコードがされているということに気がつきましたが, MS は tough (頑固, 不運, 無法な) と言っています. そしてプリンタのステータスポートへアドレスの設定のために write を行なっています. また, そのアドレス + 0x800 と read のための 3番目の I/O ポートが 0x200 から 0x3ff の間のどこかに置かれるでしょう.
FreeBSD は, 他のアーキテクチャをサポートしないんですか? いくつかのグループの人々が, FreeBSD の他のアーキテクチャへの移植に関心を示しており, FreeBSD/AXP (ALPHA) はこれらの成果としてはとても成功したものの一つです. FreeBSD/AXP は現在 ftp://ftp.FreeBSD.org/pub/FreeBSD/alpha から入手できます. ALPHA への移植版が現在動く機種は増えつつあり, その中には AlphaStation, AXPpci, PC164, Miata そして Multia といったモデルが含まれています. 現状についての情報を得るには freebsd-alpha@FreeBSD.orgメーリングリストに参加してください. その他に FreeBSD の SPARC アーキテクチャへの移植があります. プロジェクトへの参加に興味がある方は freebsd-sparc@FreeBSD.orgメーリングリスト に参加してください. 進行中のプラットホームのリストにもっとも最近追加されたのが IA-64 と PowerPCです. 詳細は freebsd-ia64@FreeBSD.org および/あるいは freebsd-ppc@FreeBSD.orgメーリングリストに参加してください. 新しいアーキテクチャに関する一般的な議論については 新しいアーキテクチャに関する一般的な議論については freebsd-platforms@FreeBSD.orgメーリングリスト へ参加してください. デバイスドライバを開発したので, メジャー番号が欲しいのですが. これは, 開発したドライバを公開するかどうかに依存します. 公開するのであれば, ドライバのソースコード, files.i386 の変更, コンフィグファイルのサンプル, デバイスが使うスペシャルファイルを作成する MAKEDEV のコードを私たちに送ってください. 公開するつもりがない場合, ライセンスの問題により公開できない場合は, キャラクタメジャー番号 32 および, ブロックメジャー番号 8 がこのような目的のために予約されています. これらの番号を使用してください. どちらの場合であれ, ドライバに関する情報を &a.hackers; に流して頂けると助かります. 代替のディレクトリ配置ポリシー 現在使われているディレクトリの配置ポリシーは, 私が 1983 年に書いたものから全く変更されていません. 私は当初の配置ポリシーを, オリジナルの fast filesystem のために書き, まったく改定していません. このポリシーはシリンダグループを使い尽くすのを防ぐにはうまくいきましたが, お気づきの方もいる通り find の動作には不適切です. ほとんどのファイルシステムの内容は, 深さ優先検索(ftw とも呼ばれます)によって作られたアーカイブから, 抽出(restore)して作成されます. この際, ディレクトリは,シリンダグループにまたがって配置され, 以降の深さ優先検索を行うには, 考え得る限り最悪の状態になります. もし作成するディレクトリの総数がわかっていれば, 解決方法はあります. (総数/シリンダグループ数)個のディレクトリを, シリンダグループごとにまとめて作成すれば良いのです. もちろん最適なディレクトリ配置になるように, 総数を予測する方法を考えなければなりません. しかし仮にシリンダグループあたりのディレクトリ数を 10 くらいの小さな数に固定してしまったとしても, 大幅な改善が望めるでしょう. このポリシーを用いるべきリストア作業を, 通常の作業(おそらく既存のポリシーを使用したほうが良いでしょう)を区別するには, 10 秒間の間に作成されたディレクトリを最大 10 個までまとめて単一のシリンダグループに書き込むという手順が使えるでしょう. とにかく私の結論は, そろそろ実験を始めて見る時期だろうということです. カーネルパニックを最大限に利用する この節は, freebsd-current メーリングリストに &a.wpaul; 氏が投稿したメールを, &a.des; 氏が校正し, [] 内のコメントを追加して引用したものです. From: Bill Paul <wpaul@skynet.ctr.columbia.edu> Subject: Re: the fs fun never stops To: ben@rosengart.com Date: Sun, 20 Sep 1998 15:22:50 -0400 (EDT) Cc: current@FreeBSD.ORG [<ben@rosengart.com> が以下のパニックメッセージを投稿しました.] > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x40 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xf014a7e5 ^^^^^^^^^^ > stack pointer = 0x10:0xf4ed6f24 > frame pointer = 0x10:0xf4ed6f28 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 80 (mount) > interrupt mask = > trap number = 12 > panic: page fault このようなメッセージが表示された場合, 問題が起きる状況を確認して, 情報を送るだけでは十分ではありません. 下線をつけた命令ポインタ値は重要な値ですが, 残念ながらこの値は構成に依存します. つまり, この値は使っているカーネルのイメージに依存するのです. もしスナップショットなどの GENERIC カーネルを使っているのであれば, 他の人間が問題のある関数について追試をすることができますが, カスタマイズされたカーネルの場合は, 使っている本人にしか問題の起こった場所は特定できないのです. 何をすれば良いのでしょう? 命令ポインタ値をメモします. 0x8: という部分は今回必要ありません. 必要なのは 0xf0xxxxxx という部分です. システムが再起動したら, 以下の操作を行います. &prompt.user; nm -n /kernel.that.caused.the.panic | grep f0xxxxxx ここで, f0xxxxxx は命令ポインタ値です. カーネルシンボルのテーブルは関数のエントリポイントを含み, 命令ポインタ値は, 関数内部のある点であり最初の点ではないため, この操作を行っても完全に一致するものが表示されない場合もあります. この場合は, 最後の桁を省いてもういちどやってみてください. このようになります. &prompt.user; nm -n /kernel.that.caused.the.panic | grep f0xxxxx これでも一致しない場合は, 桁を減らしながら何らかの出力があるまで繰り返してください. 何か出力されたら, それがカーネルパニックを引き起こした可能性のある関数のリストです. これは, 問題点を見付ける正確な方法ではありませんが, 何もないよりましです. このようなパニックメッセージを投稿している人はよく見掛けますが, このように, 命令ポインタ値を, カーネルシンボルテーブルの中の関数とつき合わせて調べている人はまれです. パニックの原因を突き止める最良の方法は, クラッシュダンプをとり, gdb(1) でスタックトレースを行うことです. もちろん -CURRENT で gdb(1) がちゃんと動いていればですが(私は動くことを保証 できません. ELF 化された gdb(1) はカーネルクラッシュダンプを正しく扱えないと言っている人がいました. FreeBSD 3.0 がベータテストを終える前に調べなければいけません. さもないと CD 出荷後に大顰蹙を買うことになります). どっちにしろ, 私は普通以下のようにします. カーネルコンフィグファイルを作ります. カーネルデバッガが必要そうであれば options 'DDB' を加えても良いです(私は永久ループが起こっていそうな場合に, ブレークポイントを設定するのに使って います). config -g KERNELCONFIG としてビルドディレクトリを設定します. cd /sys/compile/KERNELCONFIG; make を実行します. カーネルのコンパイルが終了するのを待ちます. make install を実行します. 再起動します. &man.make.1; プロセスは２つのカーネル, kernel と kernel.debug をビルドします. kernel は /kernel としてインストールされ, kernel.debug は gdb(1) のデバッグ用シンボル情報を取り出すために利用されます. 確実にクラッシュダンプをとるには, /etc/rc.conf を編集して dumpdev を使用しているスワップパーティションに指定する必要があります. こうすると rc(8) スクリプトから dumpon(8) コマンドが実行され, クラッシュダンプ機能が有効になります. 手動で dumpon(8) コマンドを実行してもかまいません. パニックの後, クラッシュダンプは savecore(8) コマンドを使用して取り出すこと ができます. dumpdev が /etc/rc.conf で設定されていれば, rc(8) スクリプトから savecore(8) が自動的に実行され, クラッシュダンプを /var/crash に保存します. FreeBSD のクラッシュダンプのサイズは, ふつう物理メモリサイズと同じです. つまり 64MB のメモリを積んでいれば, 64MB のクラッシュダンプが生成されることになります. /var/crash に十分な空き容量があることを確認してください. 手動で savecore(8) を実行すれば, もっと空き容量のあるディレクトリにクラッシュダンプを保存できます. options MAXMEM=(foo) という行をカーネルコンフィグファイルに追加することで, カーネルのメモリ使用量を制限できます. たとえば 128MB のメモリがある場合も, カーネルのメモリ使用量を 16MB に制限し, クラッシュダンプのサイズも 128MB ではなく 16MB にすることができます. クラッシュダンプを取り出せたら, 以下のように gdb(1) を使ってスタックトレースをとります. &prompt.user; gdb -k /sys/compile/KERNELCONFIG/kernel.debug /var/crash/vmcore.0 (gdb) where 必要な情報が 1 画面に収まらないことも多いので, できれば script(1) を使って出力を記録します. strip していないカーネルイメージを使うことで, 全てのデバッグシンボルが参照でき, パニックの発生したカーネルのソースコードの行が表示されているはずです. 通常, 正確なクラッシュへの過程を追跡するには, 出力を最後の行から逆方向に読まなければなりません. また gdb(1) を使って, 変数や構造体の内容を表示させ, クラッシュした時のシステムの状態を調べられます. もしあなたがデバッグ狂で, 同時に別のコンピュータを利用できる環境にあれば, gdb(1) をリモートデバッグに使うこともできます. リモートデバッグを使うと, あるコンピュータ上の gdb(1) を使って, 別のコンピュータのカーネルをデバッグできます. ブレークポイントの設定, カーネルコードのステップ実行など, ふつうのプログラムのデバッグと変わりません. コンピュータを 2 台並べてデバッグするチャンスにはなかなか恵まれないので, 私はまだリモートデバッグを試したことはありません. Bill による追記 DDB を有効にしていてカーネルがデバッガに 落ちたら, ddb のプロンプトで "panic" と入力すれば, 強制的にパニックを起こしクラッシュダンプさせることができます. パニックの途中で, 再びデバッガに落ちるかもしれませんが, "continue" と入力すれば, クラッシュダンプを最後まで実行させられます. dlsym() が ELF 実行形式では動作しなくなります! ELF のツール類は, デフォルトでは実行形式の中に定義されているシンボルを, ダイナミックリンカから見えるようにはしません. このため, dlopen(NULL, flags) を呼び出して得られたハンドルに対して, dlsym() で探索を行っても, こういったシンボルを見つけられません. もし, あなたがプロセスの中心にあたる実行形式の中にあるシンボルを探索したければ, ELF リンカ に オプションを付けて実行形式をリンクする必要があります. カーネルアドレス空間を大きくしたり, 小さくするにはどうしたら良いのですか? カーネルアドレス空間は, FreeBSD 3.X 上で 256MB, FreeBSD 4.X 上で 1GB がデフォルトになっています. 負荷の高いネットワークサーバ(例えば大きな FTP, HTTP サーバ)を運用する場合は, 256MB では足りないことに気付くかも知れません. では, アドレス空間を大きくするにはどうしたら良いのでしょうか? それには, 二つの段階を踏みます. まず, より大きいアドレス空間を割り当てることをカーネルに知らせる必要があります. 次に, カーネルはアドレス空間の先頭にロードされるため, アドレスの先頭が天井(訳注:カーネルアドレス空間の最下端アドレスのこと)と ぶつかることのないように, ロードアドレスを今までより低位に設定する必要があります. 最初の段階は, src/sys/i386/include/pmap.h にある NKPDE の値を増加させることで行ないます. ここに 1GB のアドレス空間にするために, どのようにすれば良いかを示します. #ifndef NKPDE #ifdef SMP #define NKPDE 254 /* addressable number of page tables/pde's */ #else #define NKPDE 255 /* addressable number of page tables/pde's */ #endif /* SMP */ #endif 正確な NKPDE の値を計算するには, 望みのアドレス空間の大きさ(メガバイト単位)を 4 で割って, それから単一プロセッサ(UP)なら 1, SMP なら 2 を引き算してください. 次の段階を行なうには, ロードアドレスを正確に計算することが必要です. 単純に, アドレス空間の大きさ(バイト単位)を 0x100100000 から引き算してください. 1GB アドレス空間の場合, その結果は 0xc0100000 になります. そして, src/sys/i386/conf/Makefile.i386 にある LOAD_ADDRESS に, 今計算した値を入れます. また, 次のように src/sys/i386/conf/kernel.script のセクションの始めの方にあるロケーションカウンタにも同じ値を入れてください. OUTPUT_FORMAT("elf32-i386", "elf32-i386", "elf32-i386") OUTPUT_ARCH(i386) ENTRY(btext) SEARCH_DIR(/usr/lib); SEARCH_DIR(/usr/obj/elf/home/src/tmp/usr/i386-unknown-freebsdelf/lib); SECTIONS { /* Read-only sections, merged into text segment: */ . = 0xc0100000 + SIZEOF_HEADERS; .interp : { *(.interp) } それが完了したら, config し直してカーネルを再構築してください. おそらく, ps(1), top(1) などに不具合が出るでしょう. それらを正常にするために, make world(もしくは, 変更した pmap.h を /usr/include/vm/ にコピーした後に, libkvm, ps および top を手動で再構築すること)を行なうべきです. カーネルアドレス空間の大きさは, 4MB の倍数である必要があります. &a.dg; 氏による補足 カーネルアドレス空間は 2 の乗数である必要があると思いますが, それが確かなことかどうかははっきりしていません. 昔の起動コードには, 良く高位アドレスビットのトリックが使われていたため, 少なくとも 256MB の粒度であることが想定されていたと思います. 謝辞 訳: &a.jp.y-koga;, 1997 年 11 月 10 日.
FreeBSD Core Team この FAQ について問題を見つけたり, 何か登録したい場合は, &a.faq; までメールを送ってください. フィードバックしてくれるみなさんには感謝感謝なのです. みなさんに手伝ってもらわないとこの FAQ はよくなりませんから!
&a.jkh; たまに起こす FAQ の並べ替えや更新の発作 &a.dwhite; freebsd-questions メーリングリストでの義務を超えたサービス &a.joerg; Usenet (NetNews) での義務を超えたサービス &a.wollman; ネットワーク節の執筆と文書整形 Jim Lowe マルチキャストについて &a.pds; FreeBSD FAQ タイピング機械奴隷 FreeBSD チーム 不平を言ったり, うめいたり, 情報提供してくれたり あと, 抜けてしまった他の方々に対して, 謝罪と心からの感謝を捧げます! FreeBSD FAQ 日本語化について FreeBSD 日本語ドキュメンテーションプロジェクトは, FreeBSD 関係の日本語文書が少ないことを嘆いた数人の FreeBSD ユーザの提唱によって 1996 年 2 月 26 日にスタートし, FreeBSD 日本語ハンドブックの作成をはじめとした活動を行なってきました. FreeBSD FAQ の日本語化についてはオリジナルの翻訳作業だけでなく, 日本国内に固有の話題についても広く情報を集め, 日本の FreeBSD ユーザにとって真に有益なドキュメントを提供しようと考えています. オリジナルの FAQ は日毎に更新されており, 私たちもまたこれに追い付くために作業を続けていきます. もちろん, 新しいメンバも大歓迎です. 日本語翻訳版について, 何かお気づきの点がありましたら, &a.jp.doc-jp; までご連絡ください. また, もし私たちの作業を手伝ってくれるなら, FreeBSD 日本語ドキュメンテーションプロジェクトのページをご覧の上, 是非参加してください. 翻訳者 (五十音順) &a.jp.arimura; 一宮 亮 ryo@azusa.shinshu-u.ac.jp &a.iwasaki; &a.jp.yoshiaki; &a.kuriyama; &a.jp.y-koga; &a.motoyuki; &a.jp.sugimura; &a.jp.nakai; にしか nishika@cheerful.com &a.hanai; &a.jp.kiroh; &a.jp.shou; 福間 康弘 yasuf@big.or.jp &a.jp.mrt; 山下 淳 junkun@esys.tsukuba.ac.jp 査読者 (五十音順) &a.asami; &a.iwasaki; &a.jp.yoshiaki; 大橋 健 ohashi@mickey.ai.kyutech.ac.jp &a.kuriyama; &a.motoyuki; &a.jp.saeki; &a.jp.sugimura; &a.hanai; &a.jp.nao; &a.jp.kiroh; &a.jp.hino; 檜山 卓 shiyama@intercity.or.jp &a.jp.shou; &a.jp.mrt; 若井 久史 earth@hokuto7.or.jp 作業環境整備 (五十音順) 一宮 亮 ryo@azusa.shinshu-u.ac.jp &a.jp.iwasaki; &a.jp.simokawa; 鈴木 秀幸 hideyuki@jp.FreeBSD.org diff --git a/ja_JP.eucJP/books/handbook/advanced-networking/chapter.sgml b/ja_JP.eucJP/books/handbook/advanced-networking/chapter.sgml index c7c5130388..e8d4c2861c 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 + そして, 二つのネットワークインタフェイスカードを持つ FreeBSD システムは, ブリッジとして動作することができます. - ブリッジは, 各ネットワークインターフェイスに繋がる + ブリッジは, 各ネットワークインタフェイスに繋がる デバイスの MAC 層のアドレス (例えば Ethernet アドレス) を記憶します. ブリッジはトラフィックの送信元と受信先が異なったネットワーク上に ある場合にのみ, トラフィックを転送します. すなわち, ブリッジはポート数の少ない Ethernet スイッチ だ, ということができます. ブリッジがふさわしい状況とは 今日ブリッジが活躍する場面は大きく分けて二つあります. トラフィックの激しいセグメント ひとつは, 物理ネットワークセグメントがトラフィック 過剰になっているが, なんらかの理由によりネットワークを サブネットに分け, ルータで接続することができない場合です. 編集部門と製作部門がおなじサブネットに同居している 新聞社を例に考えてみましょう. 編集部門のユーザはファイルサーバとして全員サーバ A を利用し, 製作部門のユーザはサーバ B を利用します. すべてのユーザを接続するのには Ethernet が使われており, 高負荷となったネットワークは遅くなってしまいます. もし編集部門のユーザを一つのネットワークセグメントに 分離することができ, 製作部門もユーザも同様にできるのなら, 二つのネットワークセグメントをブリッジで繋ぐことができます. ブリッジの "反対" 側へ向かうネットワークトラフィックだけが 転送され, 各ネットワークセグメントの混雑は緩和されます. パケットフィルタ/帯域制御用ファイアウォール もうひとつは, IP Masquerading (NAT) を使わずに ファイアウォール機能を利用したい場合です. ここでは DSL もしくは ISDN で ISP に接続している 小さな会社を例にとってみましょう. この会社は ISP から 13 個のグローバル IP アドレスの割り当て を受けており, ネットワーク内には 10 台の PC が存在します. このような状況では, サブネット化にまつわる問題から ルータを用いたファイアウォールを利用することは困難です. ブリッジを用いたファイアウォールなら, IP アドレスの問題を気にすること無く, DSL/ISDN ルータの 下流側に置くように設定できます. ブリッジを設定する - ネットワークインターフェイスカードの選択 + ネットワークインタフェイスカードの選択 ブリッジを利用するには少なくとも二つのネットワークカードが 必要です. - 残念なことに, FreeBSD 4.0 ではすべてのネットワークインターフェイス + 残念なことに, 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 ドメイン名はネットワーク内で一意なければならないので, ドメイン名がドメインに含まれるマシンを表すようなものであれば, 分かりやすくなります. たとえば 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 を試してみますか?」という質問 + り, 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/boot/chapter.sgml b/ja_JP.eucJP/books/handbook/boot/chapter.sgml index 9afd9bb403..5767ad6637 100644 --- a/ja_JP.eucJP/books/handbook/boot/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/boot/chapter.sgml @@ -1,608 +1,608 @@ FreeBSD の起動のプロセス この章では 起動 ブートストラップ(bootstrap) FreeBSD は通常, 起動(bootstrap)を三段階に分けて行ないます. これには基本的に, 互いに順番に呼び出される三つのプログラム(二つの 起動ブロック(boot block)と ローダ(loader))が使われています. これらのプログラムはそれぞれ, その前に呼び出されるプログラムの情報に基づいて動作し, より洗練された機能を提供します. カーネル(kernel) init その後カーネルが起動し, デバイスの検出と初期化を行ないます. そしてカーネルの起動が終わると, 制御はユーザープロセスの &man.init.8; へ移されます. &man.init.8; はまず ディスクが利用可能であることを確かめ, ファイルシステムのマウント, ネットワークで利用するネットワークカードのセットアップ, そして通常 FreeBSD システムで初期時に起動されるすべてのプロセスの起動, といったユーザーレベルでのリソース(資源)設定を行ないます. 起動ブロック: 起動ステージ 1 および 2 起動(bootstrap)とは, コンピュータが接続されたデバイスを検出, 初期化し, 必要となるプログラムを動作させることを指します. 起動には起動の際の動作が記録された, 特殊な読み出し専用メモリチップを利用します. その動作は通常, メモリテストやデバイスの設定を行なう他のチップに制御を渡し, そして設定された内容をプログラムに提供するというものです. BIOS CMOS 標準的な個人向けコンピュータでは, BIOS (起動を行なう部分) と CMOS (設定を記録する部分) によって起動を実現しています. これらはディスクが存在すること, そしてオペレーティングシステムをロードするためのプログラムが ディスク上のどこにあるのかを認識しています. この章では上に述べたような起動の初期の過程については扱いません. 焦点を合わせるのは, ディスク上のプログラムに制御が移された後の内容についてです. 起動ブロックは(通常), ローダを見つけて実行する役割を持っています. したがって, ファイルシステム上のプログラムを見つけること, 実行できること, そしてその動作に関して最低限の設定が可能である必要があります. <filename>boot0</filename> マスターブートレコード (MBR) まず実際に最初にあるのは boot0 と呼ばれる起動ブロックです. これは マスターブートレコード(MBR; Master Boot Record) という, システムが起動時にプログラムを検索するディスク上の特殊な部分に存在します. この部分は, 単に起動可能なスライスのリストが格納されています. boot0 は非常に単純なプログラムです. これは, MBR にあるプログラムは 512 バイトの大きさでなければならないという制限があるためです. boot0 は, 下のような出力をします. <filename>boot0</filename> のスクリーンショット F1 DOS F2 FreeBSD F3 Linux F4 ?? F5 Drive 1 Default: F2 <filename>boot1</filename> boot1 は起動スライス (slice) の起動セクタにあります. 起動セクタとは, MBR 上にある boot0 もしくは他のプログラムが, 起動のプロセスを続けるために 必要なプログラムがあると想定している場所です. boot1 も非常に単純なプログラムです. これは boot0 同様に, 512 バイトの大きさでなければならないという制限があるためです. boot1 は boot2 を検索し, 実行するため, そのスライスの情報を保持する FreeBSD のディスクラベル(disklabel) に関する最低限の情報を持っています. <filename>boot2</filename> boot2 はもう少し高機能です. これは FreeBSDのファイルシステム上でファイルを見つける能力を持ち, - 実行するカーネルやローダを指定するための簡単なインターフェイスを提供する事ができます. + 実行するカーネルやローダを指定するための簡単なインタフェイスを提供する事ができます. ローダ(loader)はさらに高機能なもので, 使いやすく簡単な起動設定が行なえる手段を提供します. boot2 は通常それを起動します. 以前の boot2 は, カーネルを直接起動する機能しかありませんでした. <filename>boot2</filename> のスクリーンショット >> FreeBSD/i386 BOOT Default: 0:wd(0,a)/kernel boot: ローダ(loader): 起動ステージ 3 ブートローダ(boot-loader) ローダは三段階の起動プロセスの最終段階です. ローダは通常, ファイルシステム上の /boot/loader として存在しています. /boot/boot0, /boot/boot1, /boot/boot2 というファイルがありますが, これらは MBR, 起動セクタ, ディスクラベルの実際のコピーではありません. ローダは, よりさまざまなコマンド群をサポートした 強力なインタープリタによって提供される簡易組み込みコマンド群を利用することで, ユーザが利用しやすい設定手段となるように設計されています. ローダプログラムの処理の流れ ローダは初期化の際にコンソールとディスクの検出を行ない, どのディスクから起動しているかを調べます. そして必要な変数を設定してからインタープリタを起動し, 簡易コマンドを解釈します. ローダ ローダの設定 ローダは次に /boot/loader.rc を読み込み, 通常, 変数の標準値を定義した /boot/defaults/loader.conf と, そのマシンにローカルな変数を定義した /boot/loader.conf を読み込みます. loader.rc はそれらの変数にもとづき, 選択されたモジュールとカーネルをロードします. ローダは最後に, 標準設定で 10 秒のキー入力待ち時間を用意し, 入力がなければカーネルを起動します. 入力があった場合, 簡易コマンド群が使えるプロンプトが表示され, ユーザは変数を調整したり, すべてのモジュールをアンロードしたり, モジュールをロードしたりすることができます. その後, 最終的な起動や再起動へ移行します. この処理に関するより技術的な説明は &man.loader.8; にあります. ローダの組み込みコマンド 簡易コマンド群は, 次のようなもので構成されています. autoboot seconds seconds で与えられた時間内に入力がなければ, カーネルの起動へと進みます. カウントダウンを表示し, 標準設定では 10 秒間です. boot -options kernelname すぐにカーネルの起動へ進みます. オプション, カーネル名が指定されている場合は, それらが使われます. boot-conf すべてのモジュールの設定を, 起動時と同じように変数にもとづいて自動的に行ないます. このコマンドは, まず unload を行なって, 変数—普通 kernel など—を変更した場合にのみ有効に働きます. help topic /boot/loader.help を読み込み, ヘルプメッセージを表示します. topic に index 指定された場合, 利用可能な topic を表示します. include filename … 指定されたファイル名のファイルを処理します. ローダはファイルを読み込み, 行単位で解釈します. エラーが発生した場合, include コマンドの実行はその時点で停止します. load type filename 指定されたファイル名のカーネル, カーネルモジュール, あるいは type に指定された種類のファイルをロードします. ファイル名以降に指定された引数はファイルへと渡されます. ls path 指定された path にあるファイルを表示します. path が指定されていなければ, ルートディレクトリを表示します. が指定されていればファイルサイズも表示されます. lsdev モジュールがロード可能なすべてのデバイスを表示します. もし が指定されていれば, より詳細な出力がされます. lsmod ロード済みのモジュールを表示します. が指定されていれば, より詳細な内容が出力されます. more filename LINES 単位でスクロールを停止しながら指定されたファイルを表示します. reboot すぐにシステムを再起動します. set variable set variable=value ローダの環境変数を設定します. unload すべてのロード済みモジュールを削除します. ローダの使用例 次にあげるのは, ローダの実践的な使用例です. シングルユーザモード 普段使っているカーネルをシングルユーザモードで起動します. boot -s 普段使っているカーネルとモジュールをアンロードし, 古い(もしくは別の)カーネルをロードします. kernel.old unload load kernel.old kernel.GENERIC とすると, インストールディスクに入っていた generic カーネルを指定することができます. また, 直前にインストールされていたカーネル(たとえば, カーネルを自分で設定したり, アップグレードしたりした場合)を指定するには kernel.old とします. 普段のカーネルで使っているモジュールを 指定したカーネルでロードする場合は, 下のようにします. unload set kernel="kernel.old" boot-conf カーネルの設定スクリプト(通常, カーネル起動時に設定される内容を自動化するスクリプト)をロードします. load -t userconfig_script /boot/kernel.conf カーネル起動時の応答 カーネル(kernel) 起動時の応答 カーネルがローダ(通常は) かboot2 (ローダを迂回して)によってロードされると, 起動フラグを調べます. もし起動フラグがあれば, それに応じて動作を調整します. カーネル起動フラグ カーネル(kernel) 起動フラグ 良く使われる起動フラグは次のとおりです. カーネル初期化中に, ルートファイルシステムとしてマウントするデバイスを尋ねます. CDROM から起動します. 起動時にカーネルコンフィグレーションを行なう UserConfig を実行します. シングルユーザモードで起動します. カーネル起動時により詳細な情報を表示します. 起動フラグはこの他にもあります. それらについては &man.boot.8; を参照してください. init: プロセス制御の初期化 init カーネルの起動が完了すると, init というユーザプロセスに制御が移されます. これは /sbin/init, もしくは loader の init_path 変数で指定される場所にあります. 自動再起動(automatic reboot)の動作 自動再起動では, システム上で利用できるファイルシステムの一慣性を確認します. もしそれに問題があって fsck がその不一致を修復できなければ, 管理者に直接に処置させるため init はシステムをシングルユーザモードへと移行させます. シングルユーザモード シングルユーザモード コンソール(console) このモードには, 自動再起動の処理中か, ユーザが起動時に を指定た場合, あるいは loader で boot_single 変数を設定することによって移行します. また, マルチユーザモードから 再起動オプション() や停止(halt)オプション()なしで shutdown を呼び出すとこのモードに移行します. /etc/ttys でシステムコンソール console が insecure に設定されている場合, システムはシングルユーザモードに移行する前に root のパスワードを入力するように求めます. /etc/ttys の insecure コンソール # name getty type status comments # # This entry needed for asking password when init goes to single-user mode # If you want to be asked for password, change "secure" to "insecure" here # # 訳) このエントリは init がシングルユーザモードへ移行する際にパスワードを要 # 求させるために必要です. もし, パスワードの要求を望む場合, ここの "secure" を # "insecure" へ変更してください. # console none unknown off insecure insecure コンソールとは, あなた自身, コンソールが物理的に安全でないと考えていて, root パスワードを知る人だけがシングルユーザモードを使えるようにしたいという意味であり, コンソールを安全でない状態で使いたいという意味ではありません. そのため, 安全性を求めるならば secure でなく insecure を選んでください. マルチユーザモード マルチユーザモード init がファイルシステムが正常であると判断するか, ユーザがシングルユーザモードを終了すると, システムはマルチユーザモードへ移行し, リソースの設定を始めます. リソース設定(rc) rc ファイル群 リソース設定システムはデフォルト設定を /etc/defaults/rc.conf から, そのシステム独自の細かな設定を /etc/rc.conf から読み込みます. そして /etc/fstab に記述されるシステムファイルシステムをマウントし, ネットワークサービスの開始, さまざまなシステムデーモンの開始, そして最後に, ローカルにインストールされた package の起動スクリプトの実行へと進みます. リソース設定システムのに関する参考資料は, &man.rc.8; にあります. これはスクリプトそのものを調べることと同じくらい優れたものです. シャットダウン動作 shutdown shutdown を用いてシステムを意図的にシャットダウンした場合, init は /etc/rc.shutdown というスクリプトの実行を試みます. そして, すべてのプロセスへ TERM シグナルを送り, 続いてうまく終了できなかったプロセスへ KILL シグナルを送ります. diff --git a/ja_JP.eucJP/books/handbook/config/chapter.sgml b/ja_JP.eucJP/books/handbook/config/chapter.sgml index 077f1f4f2b..fb74d98aed 100644 --- a/ja_JP.eucJP/books/handbook/config/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/config/chapter.sgml @@ -1,866 +1,866 @@ 設定とチューニング この章は &a.msmith; と &a.dillon; によって書かれたものをもとに, &a.chern; と &a.murray によって書かれました. この章では System configuration System optimization システムを正しく設定することは, 作業の量を減らしメンテナンスや将来の更新の際の困難を減らします. この章では FreeBSD システムの管理上の設定の側面について記述します. またこの章では FreeBSD システムのパフォーマンスを最適化する チューンについても記述します. 初期設定 パーティションのレイアウト パーティションレイアウト /etc /var /usr 基本パーティション ファイルシステムのレイアウトを &man.disklabel.8; や &man.sysinstall.8; で行う際, ハードディスクの外周部は 内周部よりもデータ転送が速いということを覚えておくことが大事です. これに従えば, ルートやスワップのような小さくて激しくアクセスされるファイルシステムを外周付近に, /usr のようなより大きなパーティションはその内側に配置すべきでしょう. そうするなら, パーティションを作成する際には, ルート, スワップ, /var, /usr のような順で作ってゆくのがよいでしょう. /var パーティションのサイズは あなたが計算機をどのように使おうとしているかを反映します. /var は主としてメールボックスやプリントスプール, ログファイルの保持に使われます. 特にメールボックスとログファイルは, あなたのシステムのユーザ数やログの保持期間に依存して予期し得ぬサイズにまで成長します. もしあなたがメールサーバを運用する予定なら /var パーティションはギガバイト以上のものがよいでしょう. さらに, /var/tmp は追加したくなるかもしれない パッケージを収められるだけの大きさが必要です. /usr パーティションはシステムを サポートするのに必要なファイル群と, &man.ports.7; 階層からインストールされたファイル群を収める /usr/local と呼ばれるサブディレクトリを その中に含みます. ports をまったく使わずシステムのソース (/usr/src) も不要だというのであれば, 1 ギガバイトの /usr パーティションだけで充分です. しかし, ports (特にウィンドウマネージャや Linux エミュレーションを使うバイナリ) を少なからずインストールするのであれば 少なくとも /usr に 2 ギガバイトを薦め, システムのソースも置こうというなら 3 ギガバイトの /usr を推奨します. このパーティションで必要になる量を過小評価してはいけません. それは驚く程に蔓延るものなのです! パーティションのサイズを考える時, 必要量にシステムの成長分を見込んでおいてください. 別のパーティションには潤沢にスペースが余っているのに, あるパーティションでスペースが足らないままというのは フラストレーションがたまるものです. &man.sysinstall.8; の Auto-defaults パーティションサイズを使ったことのある人なら, そのルートや /var パーティションが 小さすぎることを知っているでしょう. 賢明かつ気前よくパーティションを切ってください. スワップパーティション swap サイズ swap パーティション 経験からスワップサイズはメインメモリの 2 倍というのが一般的です. つまり, 計算機のメモリが 128 メガバイトならばスワップファイルは 256 メガバイトになります. メモリの少ないシステムでは, もっとスワップを増した方が性能がよくなります. 256 メガバイト未満のスワップでシステムを設計することはお薦めできません. またスワップサイズを決める時に, 将来のメモリ増設のことも考えておくべきです. カーネルの VM (訳註: virtual memory(仮想メモリ)) ページングアルゴリズムはスワップパーティションがメインメモリの 2 倍以上存在するときに最も性能を発揮するように設計されています. スワップが少なすぎる設定は, あなたが後にメモリを増設したときに問題を起すばかりではなく, - VM ページスキャニングのコードを能率を落します. + VM ページスキャニングのコードの能率を落します. 最後に, 複数の SCSI ディスク (や異なるコントローラで操作される複数の IDE ディスク) を持つ大規模なシステムでは, それぞれのドライブ (4 台まで) にスワップを設定することを強く推奨します. 各ドライブのスワップパーティションはほぼ同一サイズであるべきです. カーネルは任意のサイズを扱うことができますが, 内部のデータ構造は最大のスワップパーティションの 4 倍に調節されます. スワップパーティションをほぼ同一のサイズにしておくことで カーネルはスワップスペースを最適なかたちで ディスクをまたいでストライブさせることができます. こだわりすぎる必要はありません. スワップスペースは UNIX のつつましい美点です. あなたが通常スワップをたくさん使わないとしても, プログラムが暴走してもリブートさせられる前に回復する時間を多く得られます. 何故パーティション化するのか? 何故パーティション化してしまうのでしょう? 何故巨大な root パーティション一発では駄目なのでしょう? そうすれば容量が溢れるかもと心配しなくてもすむのに! いくつかの理由からそれはよいアイデアとは言えません. まず各パーティションはアクセスの特徴がそれぞれ異なっていて, 分離しておくことでそれぞれの特徴に応じたチューンができるようになるからです. root パーティションや /usr パーティションはほとんどが読み出しでわずかな書き込みがあるだけですが /var や /var/tmp パーティションでは大量の読み書きが発生します. システムを適切にパーティション化することで 小さいが書き込みの激しいパーティションによって引き起こされる フラグメント化を読み出し専門のパーティションにまで波及させずにすみます. また書き込みの激しいパーティションをディスクの周辺部に配置することで, たとえばパーティションテーブル内で大きなパーティションの後のかわりに前に配置することで, それが最も必要とされているパーティションの I/O パフォーマンスを増大させることができます. 大きなパーティション内の I/O パフォーマンスもまた必要とされているでしょうが, それらは大きすぎてディスク周辺部へ移動させてやったとしても /var を周辺部に移動させることによって大きな効果が得られたのとは対照的に 意味のあるパフォーマンスの増加は見込めないでしょう. 基本的にリードオンリーな root パーティションを小さくまとめておくことで 不幸なクラッシュを生き延びるチャンスが増大します. 中核となる設定 rc files rc.conf システムの設定情報が収められている主な場所は /etc/rc.conf です. このファイルにはシステムの起動時にシステムの設定を行なうものをはじめ 多岐に渡る設定情報が含まれています. そのファイル名はダイレクトに, それが rc* ファイル群の設定情報であることを示しています. 管理者は /etc/defaults/rc.conf のデフォルトの設定を rc.conf ファイルにエントリを作ることで上書きすべきです. デフォルトのファイルをそのまま /etc にコピーするのはやめるべきです. それはデフォルト値であってサンプルではないのです. システム固有のすべての変更は rc.conf ファイルの中でするべきです. 管理の手間を減らす為, クラスター化されたアプリケーションには サイト共通の設定とシステム固有の設定を分離する様々な戦略が適用できます. 推奨されるアプローチは, サイト共通の設定は /etc/rc.conf.site のような別のファイルに置き, それをシステム固有の設定情報しか含ませない /etc/rc.conf からインクルードすることです. rc.conf は &man.sh.1; によって読み込まれているので, これはじつに簡単に達成できます. たとえば, rc.conf: . rc.conf.site hostname="node15.webcompany.com" network_interfaces="fxp0 lo0" ifconfig_fxp0="inet 10.1.1.1" rc.conf.site: defaultrouter="10.1.1.254" saver="daemon" blanktime="100" rc.conf.site ファイルは rsync 等を使うことで全システムに配布でき, 一方 rc.conf ファイルはユニークなままを保つことができます. システムを &man.sysinstall.8; や 'make world' 等で 更新した場合 rc.conf ファイルは上書きされません. なのでシステムの設定情報が失われることもありません. アプリケーションの設定 基本的に, インストールされたアプリケーションは独自の文法を持つ 固有の設定ファイルを持ちます. これらのファイルがベースシステムから分離されているということは重要で, このためパッケージ管理ツールによる配置と管理が容易になっています. /usr/local/etc 基本的に, それらのファイルは /usr/local/etc にインストールされます. 設定ファイルの数が多数にのぼるアプリケーションに対しては, それら用にサブディレクトリが作られます. 通常, ports やパッケージがインストールされると 設定ファイルのサンプルが一緒にインストールされます. 大抵, 識別のためにサフィックスとして ".default" がついています. アプリケーションのための設定ファイルがまだ存在していなければ, .defaults ファイルをコピーすることで作成できます. 以下は /usr/local/etc/apache の例です. -rw-r--r-- 1 root wheel 2184 May 20 1998 access.conf -rw-r--r-- 1 root wheel 2184 May 20 1998 access.conf.default -rw-r--r-- 1 root wheel 9555 May 20 1998 httpd.conf -rw-r--r-- 1 root wheel 9555 May 20 1998 httpd.conf.default -rw-r--r-- 1 root wheel 12205 May 20 1998 magic -rw-r--r-- 1 root wheel 12205 May 20 1998 magic.default -rw-r--r-- 1 root wheel 2700 May 20 1998 mime.types -rw-r--r-- 1 root wheel 2700 May 20 1998 mime.types.default -rw-r--r-- 1 root wheel 7980 May 20 1998 srm.conf -rw-r--r-- 1 root wheel 7933 May 20 1998 srm.conf.default srm.conf ファイルだけが変更されていることが即座に見てとれるでしょう. 後に apache を更新した時にも, この変更されたファイルは上書きされることはありません. サービスの起動 サービス 一つのシステムでサービスをいくつも立ち上げているということは よくあることです. それらには独自の立ち上げかたがあることがあり, それぞれ有利な点があります. /usr/local/etc/rc.d Ports collection やパッケージからインストールしたソフトウェアは しばしば /usr/local/etc/rc.d にスクリプトを置き, システムが起動した時には 'start', システムをシャットダウンする時には 'stop' の引数をつけてこれを実行します. これは root によって実行されるべきであるようなシステムワイドな サービスを起動する場合に推奨される方法です. これらのスクリプトはパッケージの一部としてインストール時に記録され, パッケージとともに削除されます. /usr/local/etc/rc.d にある 一般的なスクリプトは次のようなものです. #!/bin/sh echo -n ' FooBar' case "$1" in start) /usr/local/bin/foobar ;; stop) kill -9 `cat /var/run/foobar.pid` ;; *) echo "Usage: `basename $0` {start|stop}" >&2 exit 64 ;; esac exit 0 このスクリプトはその目的を果すべく起動時に , シャットダウン時に をつけて呼ばれます. サービスの中には固有のポートに接続を受けたときに &man.inetd.8; から起動されるものもあります. これはメールリーダサーバ (POP や IMAP 等) の場合によくあります. これらのサービスは /etc/inetd.conf ファイルを編集することで有効化されます. このファイルの編集に関する詳細は &man.inetd.8; を見てください. これらの他に /etc/rc.conf による有効化/無効化がカバーされていないサービスもあります. それらは伝統的に /etc/rc.local にコマンドを書き込むことで実行されていました. FreeBSD 3.1 にはデフォルトの /etc/rc.local は存在していません. もし管理者によって作られていれば, その時は一般的なやりかたとして認められるべきでしょう. rc.local は最後の場所と考えられているということを 知っておいてください. サービスを起動させるのにもっといい場所があるなら そこから始めてください. /etc/rc.conf でその他のコマンドを実行しないでください. そのかわり, デーモンの起動やブート時のコマンド実行は /usr/local/etc/rc.d にスクリプトを配置してください. この他にサービスの起動に &man.cron.8; を利用することもできます. このアプローチには, cron がそのプロセスを crontab のオーナ権限で実行したり, サービスが非特権ユーザによって 立ち上げられ管理されるなどといった有利な点がいくつもあります. これで cron の文書化されていない機能の利点を得ることができます. 日時の指定を '@reboot' で置き換えることでジョブは システムがブートした直後, cron が起動した時に実行されます. バーチャルホスト バーチャルホスト ip aliases FreeBSD の非常にありふれた用途の一つにバーチャルサイトの ホスティングがあります. これは一つのサーバがネットワークには複数のサーバとして現れるものです. これは一つのネットワークインタフェイスに 複数のアドレスを割当てることで実現されます. ネットワークインタフェイスは "真の" アドレスを一つと "別名" のアドレスを複数持ちます. これらの別名は通常 /etc/rc.conf に別名のエントリを置くことで追加されます. 'fxp0' インタフェイスへの別名のエントリは以下の様なものです. ifconfig_fxp0_alias0="inet xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx" 別名のエントリは alias0 から始まり _alias1, _alias2 の様に増加してゆかなければなりません. 設定プロセスは 最初に欠けた番号のところで停まります. 別名のネットマスクの計算は重要ですが, 幸いなことに非常に簡単です. 個々のインタフェイスについてそのネットワークのネットマスクを正しく 表現しているアドレスが必ず一つ必要です. そのネットワークに所属しているそれ以外のアドレスのネットマスクは 全て 1 でなければなりません. 例として, fxp0 インタフェイスが二つのネットワークに接続されている ものを考えてみましょう. 一つはネットマスクが 255.255.255.0 である 10.1.1.0 ネットワークで, もう一つはネットマスクが 255.255.255.240 である 202.0.75.16 ネットワークです. システムは 10.1.1.0 には 10.1.1.1 として, 202.0.75.20 には 202.0.75.17 として現れるようにします. 以下のエントリはネットワークインタフェイスを上述の環境に正しく 設定するものです. ifconfig_fxp0="inet 10.1.1.1 netmask 255.255.255.0" ifconfig_fxp0_alias0="inet 10.1.1.2 netmask 255.255.255.255" ifconfig_fxp0_alias1="inet 10.1.1.3 netmask 255.255.255.255" ifconfig_fxp0_alias2="inet 10.1.1.4 netmask 255.255.255.255" ifconfig_fxp0_alias3="inet 10.1.1.5 netmask 255.255.255.255" ifconfig_fxp0_alias4="inet 202.0.75.17 netmask 255.255.255.240" ifconfig_fxp0_alias5="inet 202.0.75.18 netmask 255.255.255.255" ifconfig_fxp0_alias6="inet 202.0.75.19 netmask 255.255.255.255" ifconfig_fxp0_alias7="inet 202.0.75.20 netmask 255.255.255.255" 設定ファイル <filename>/etc</filename> のレイアウト 設定のための情報が含まれているディレクトリはたくさんあります. それぞれ以下のものを含んでいます. /etc システム全般の設定情報. ここにあるデータはシステム 固有のものです. /etc/defaults デフォルトのシステム設定ファイル. /etc/mail 追加的な sendmail の設定, 他の MTA の設定ファイル. /etc/ppp ユーザモード, およびカーネルモードの ppp プログラムの設定. /etc/namedb bind(8) のデータのデフォルトの置場. 通常 boot ファイルはここに置かれ, /var/db に置かれた他のデータを 参照するディレクティブを含みます. /usr/local/etc インストールされたアプリケーションの設定ファイル. アプリケーションごとのサブディレクトリを含んでいることがあります. /usr/local/etc/rc.d インストールされたアプリケーションの起動/停止スクリプト. /var/db 永続的なシステム固有のデータファイル. たとえば bind(8) のゾーンファイル, データベースファイル等. ホスト名 hostnames DNS /etc/resolv.conf resolv.conf /etc/resolv.conf は FreeBSD に インターネットドメインネームシステム (DNS) にどのようにアクセスするかを指定します. resolv.conf の最もよくあるエントリは nameserver リゾルバが問い合わせるべきネームサーバの IP アドレス. サーバはリストの順に 3 番目まで問い合わせられます. search ホスト名をルックアップする検索リスト. 通常, ローカルなホスト名のドメインから決定されます. domain ローカルドメイン名. 基本的な resolv.conf. search foobar.com nameserver 147.11.1.11 +nameserver 147.11.100.30 &man.dhclient.8; は通常 resolv.conf を DHCP サーバから受け取った情報で書き換えます. <filename>/etc/hosts</filename> hosts /etc/hosts は古きインターネットを 偲ばせるシンプルなテキストのデータベースです. これはホスト名と IP アドレスをマッピングする DNS や NIS と組み合わせて使われます. LAN でつながれているローカルな計算機は, 名前引きを簡単にするために &man.named.8; サーバを立ち上げるかわりにここに書くことができます. さらに /etc/hosts はインターネット名のローカルなレコードを提供し, よくアクセスされる名前を外部に問い合わせるのを減らすためにも使えます. # $FreeBSD$ # # Host Database # This file should contain the addresses and aliases # for local hosts that share this file. # In the presence of the domain name service or NIS, this file may # not be consulted at all; see /etc/nsswitch.conf for the resolution order. # # ::1 localhost localhost.my.domain myname.my.domain 127.0.0.1 localhost localhost.my.domain myname.my.domain # # Imaginary network. #10.0.0.2 myname.my.domain myname #10.0.0.3 myfriend.my.domain myfriend # # According to RFC 1918, you can use the following IP networks for # private nets which will never be connected to the Internet: # # 10.0.0.0 - 10.255.255.255 # 172.16.0.0 - 172.31.255.255 # 192.168.0.0 - 192.168.255.255 # # In case you want to be able to connect to the Internet, you need # real official assigned numbers. PLEASE PLEASE PLEASE do not try # to invent your own network numbers but instead get one from your # network provider (if any) or from the Internet Registry (ftp to # rs.internic.net, directory `/templates'). # /etc/hosts は, 次のようなごく簡単なフォーマットになっています. [インターネットアドレス] [正式なホスト名] [別名1] [別名2] ... 例: 10.0.0.1 myRealHostname.foobar.com myRealHostname foobar1 foobar2 これ以上の情報は &man.hosts.5; をあたってください. ログファイルに関係する設定 log files <filename>syslog.conf</filename> syslog.conf syslog.conf は &man.syslogd.8; プログラムのための設定ファイルです. これはどのタイプの syslog メッセージを対応する ログファイルに記録するかを指定します. # $FreeBSD$ # # Spaces ARE valid field separators in this file. However, # other *nix-like systems still insist on using tabs as field # separators. If you are sharing this file between systems, you # may want to use only tabs as field separators here. # Consult the syslog.conf(5) manpage. *.err;kern.debug;auth.notice;mail.crit /dev/console *.notice;kern.debug;lpr.info;mail.crit;news.err /var/log/messages security.* /var/log/security mail.info /var/log/maillog lpr.info /var/log/lpd-errs cron.* /var/log/cron *.err root *.notice;news.err root *.alert root *.emerg * # uncomment this to log all writes to /dev/console to /var/log/console.log #console.info /var/log/console.log # uncomment this to enable logging of all log messages to /var/log/all.log #*.* /var/log/all.log # uncomment this to enable logging to a remote loghost named loghost #*.* @loghost # uncomment these if you're running inn # news.crit /var/log/news/news.crit # news.err /var/log/news/news.err # news.notice /var/log/news/news.notice !startslip *.* /var/log/slip.log !ppp *.* /var/log/ppp.log これ以上の情報は &man.syslog.conf.5; のマニュアルページに あたってください. <filename>newsyslog.conf</filename> newsyslog.conf newsyslog.conf は &man.newsyslog.8; のための設定ファイルで, 通常 &man.cron.8; によって実行されるプログラム &man.newsyslog.8; がログファイルをいつ保存して再編するかを決定します. logfile は logfile.1 に移され, logfile.1 は logfile.2 に, そして以下同様に移されます. さらにログファイルを gzip 形式で保存することもできます. この場合ファイル名は logfile.0.gz, logfile.1.gz の様になります. newsyslog.conf はどのログファイルが管理され, どのくらいの期間保存され, そしていつ touch されるかを指定します. ログファイルはあるサイズに到達するか, ある決められた時刻・ 日時で再編されあるいは保存されます. # configuration file for newsyslog # $FreeBSD$ # # logfilename [owner:group] mode count size when [ZB] [/pid_file] [sig_num] /var/log/cron 600 3 100 * Z /var/log/amd.log 644 7 100 * Z /var/log/kerberos.log 644 7 100 * Z /var/log/lpd-errs 644 7 100 * Z /var/log/maillog 644 7 * @T00 Z /var/log/sendmail.st 644 10 * 168 B /var/log/messages 644 5 100 * Z /var/log/all.log 600 7 * @T00 Z /var/log/slip.log 600 3 100 * Z /var/log/ppp.log 600 3 100 * Z /var/log/security 600 10 100 * Z /var/log/wtmp 644 3 * @01T05 B /var/log/daily.log 640 7 * @T00 Z /var/log/weekly.log 640 5 1 $W6D0 Z /var/log/monthly.log 640 12 * $M1D0 Z /var/log/console.log 640 5 100 * Z これ以上の情報は &man.newsyslog.8; のマニュアルページに あたってください. <filename>sysctl.conf</filename> sysctl.conf sysctl sysctl.conf は rc.conf によく似ています. 値は変数=値のかたちでセットされます. 指定された値はシステムがマルチユーザモードに移行した後でセットされます. すべての変数がこのモードで設定可能というわけではありません. 以下は sysctl.conf のサンプルで 致命的なシグナルを記録しないように, また Linux プログラムに それらが実際は FreeBSD 上で動いていることを知らせる様に チューニングしています. kern.logsigexit=0 # Do not log fatal signal exits (e.g. sig 11) compat.linux.osname=FreeBSD compat.linux.osrelease=4.3-STABLE sysctl によるチューニング sysctl sysctl によるチューニング &man.sysctl.8; は稼働中の FreeBSD システムに変更を加えるためのインタフェイスです. これには経験を積んだ管理者用の TCP/IP スタックへや 仮想メモリシステムのパフォーマンスを劇的に改善する 先進的なオプションが含まれます. 500 を越えるシステム変数を &man.sysctl.8; で読んだり セットしたりできます 中心において &man.sysctl.8; の機能は以下の二つに尽きます. すなわちシステムの設定を読んで変更することです. 読むことができるすべての変数を表示するには以下のようにします. &prompt.user; sysctl -a 個々の変数, たとえば kern.maxproc を読むには以下のようにします. &prompt.user; sysctl kern.maxproc kern.maxproc: 1044 個々の変数をセットするには = オプションを使います. &prompt.root; sysctl kern.maxfiles=5000 kern.maxfiles: 2088 -> 5000 sysctl 変数の値は通常, 文字列, 数値, 真偽値のいずれかです. 真偽値は yes の場合には 1 で no の場合には 0 です. ディスクのチューニング sysctl 変数 vfs.vmiodirenable vfs.vmiodirenable vfs.vmiodirenable sysctl はデフォルトは 0 (オフ) であり (しかし近いうちにデフォルトが 1 になるでしょう), 0 (オフ) または 1 (オン) にセットすることができます. このパラメータはディレクトリがシステムによってどのように キャッシュされるかを制御します. ほとんどのディレクトリは小さく, ファイルシステムにおいては単一フラグメント (典型的には 1K) であり, バッファキャッシュではさらに小さくなっています (典型的には 512 バイト). しかしデフォルトモードで動作している時は, 大量のメモリを搭載していても バッファキャッシュは固定数のディレクトリしかキャッシュしません. この sysctl をオンにすると、バッファキャッシュが VM ページキャッシュを, ディレクトリをキャッシュするために使うことを可能にします. これによる利点は, 全てのメモリがディレクトリを キャッシュするのに使えるようになるということです. 欠点は, キャッシュに使われる最小のメモリの大きさが 512 バイトではなく 物理ページサイズ (大抵は 4K) になることです. 多数のファイルを操作するサービスを稼動しているなら, 常にこのオプションをオンにすることを推奨します. そのようなサービスには, web キャッシュや大規模なメールシステム, ニューズシステムなどが含まれます. このオプションは一般にメモリを消費しますが, 性能を削減することはありません. ただし実験して調べてみるべきでしょう. hw.ata.wc hw.ata.wc FreeBSD 4.3 では IDE のライトキャッシュがオフになりました. これは IDE ディスクへの書き込み帯域幅を減らしてしまうことになりますが, ハードドライブベンダに起因するデータの一貫性に関する 重大な問題のために必要なことだと考えられました. 基本的には, 書き込み完了時期について IDE ドライブが嘘をつくという問題です. IDE ライトキャッシュがオンであると IDE ハードドライブはデータを順番に書きこまないばかりか, ディスクの負荷が高い時にはいくつかのブロックの書き込みを 無期限に延期してしまいます. クラッシュや電源故障の場合, ファイルシステムの重大な破壊をもたらします. したがって私たちはデフォルトを安全側に変更しました. 残念ながらこれは大変な性能の低下をもたらし, 私たちはあきらめてこのリリース後にオンに戻しました. hw.ata.wc sysctl 変数を見てデフォルトをチェックしてみるべきです. もし IDE ライトキャッシュがオフになっていたら, hw.ata.wc カーネル変数を 1 に戻すことでオンに戻すことができます. これはブート時にブートローダから行わなければなりません. カーネルがブートした後に行っても効果はありません. &man.ata.4; を見てください. ソフトアップデート ソフトアップデート tunefs &man.tunefs.8; はファイルシステムを fine チューンするのに使えます. この目的においてはソフトアップデートをオンオフすることを 考えるだけですみます. 以下の様にしてトグルします. &prompt.root; tunefs -n enable /filesystem &prompt.root; tunefs -n disable /filesystem ファイルシステムはマウントされているあいだは &man.tunefs.8; で変更することができません. ソフトアップデートを有効にする いい機会はシングルユーザモードでどのパーティションもマウント されていない時です. softupdates はメタデータの性能, 主にファイルの作成と削除の性能を劇的に改善します. 全てのファイルシステムで softupdates を有効にすることを推奨します. softupdates に関して, 2 つの欠点を意識すべきです. 1 つめは, softupdates はクラッシュ時におけるファイルシステムの一貫性は保証しますが, 物理ディスクの更新が何秒か (1 分になることもあります!) 遅れる可能性が高いことです. クラッシュした場合, より多くの成果が消えてしまうかもしれません. 2 つめは, softupdates はファイルシステムブロックを解放するのを遅らせるということです. あるファイルシステム (例えばルートファイルシステム) が満杯近くの時に それに対する大規模な更新, たとえば make installworld をすると, 空き領域を使い果たして更新が失敗してしまうことがあります. kernel の制限をチューニングする kernel の制限をチューニングする File/process 制限 kern.maxfiles kern.maxfiles kern.maxfiles はあなたのシステムの要求に 応じて増減させることができます. この変数はあなたのシステムのファイル記述子の最大値を示します. ファイル記述子テーブルが溢れるような時には dmesg に頻繁に file: table is full と表示されます. ファイル, ソケット, パイプ(fifo) は それぞれオープンされるとファイル記述子を一つ消費します. 大規模なプロダクションサーバでは その時実行されているサービスの種類や数に応じては あっさり数千のファイル記述子が必要になります. kern.maxfile のデフォルト値は kernel config ファイルの maxusers オプションで決ります. kern.maxfiles は maxusers の値に応じて増加します. diff --git a/ja_JP.eucJP/books/handbook/eresources/chapter.sgml b/ja_JP.eucJP/books/handbook/eresources/chapter.sgml index 31e92700b6..3d47476511 100644 --- a/ja_JP.eucJP/books/handbook/eresources/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/eresources/chapter.sgml @@ -1,1667 +1,1667 @@ インターネット上のリソース 訳: &a.jp.yuki;, 1996 年 8 月 28 日 FreeBSD の進歩は急速であり, 印刷したメディアは最新の開発をフォローするのに実用的ではありません. それだけしかない, というわけではありませんが, 最新情報を入手する方法としては電子的なリソースがベストです. FreeBSD はボランティアの努力によって, ユーザコミュニティ自体が, 一種のテクニカルサポート部門としての役割も通常果たしており, 電子メールや Usenet のニュースがこれらのコミュニティにたどり着く最も効果的な方法になっています. 以下に, FreeBSD ユーザコミュニティに連絡を取る場合の最も重要な点についての 概略を示します. もしここに書かれていない他のリソースに気がついた場合は, それらを &a.doc; に送って頂ければ, それらをここに含めるかもしれません. メーリングリスト 多くのFreeBSDの開発メンバはUSENETを読むことができますが, もし, comp.unix.bsd.freebsd.* のグループの一つに質問を投稿したとしても タイムリにその質問を受け取るということは保証できません. 質問を適切なメーリングリストに投稿すれば, 私たちかFreeBSDの関係者から, よりよい (そして少なくともより早い) 反応がいつでも得られることでしょう. さまざまなメーリングリストの憲章を このドキュメントの最後に記載しま す. 私たちは, メーリングリストの質, 特に技術面に関する質を高く保つ ために努力しているので, メーリングリストに参加する前にその憲章を読んで ください. 私たちのメーリングリストの参加者のほとんどは, 現在非常 にたくさんの FreeBSD に関連したメッセージを毎日受け取っており, メーリン グリストに対するふさわしい 用いられ方をするための憲章やルールを決めるこ とによって, メーリングリストの S/N 比を高くする保つように励んでいます. そうしないと, 結果的に, メーリングリストがプロジェクトにとって 事実上のコミュニケーションの手段になってしまうでしょう. メーリングリストはいずれもアーカイブされており, それらは FreeBSD World Wide Web server で検索することができます. キーワード検索可能なアーカイブの提供は, 良くある質問に対する回答を見つけるすぐれた方法ですから, 質問を投稿する前に調べてみるべきでしょう. メーリングリストの概説 一般的なメーリングリスト: 以下のものは誰でも自由に参加できる (そしておすすめの) 一般的なものです: リスト 目的 cvs-all FreeBSD ソースツリーへ加えられた変更について freebsd-advocacy FreeBSD の福音伝道 freebsd-announce 重要なイベントやプロジェクトのマイルストン freebsd-arch アーキテクチャ, 設計に関する議論 freebsd-bugs バグレポート freebsd-chat FreeBSD コミュニティに関連する技術的ではない話題 freebsd-config FreeBSD のインストールと設定用のツールの開発に関する話題 freebsd-current FreeBSD-current の使用に関連する議論 freebsd-isp FreeBSD を用いている インターネットサービスプロバイダの話題 freebsd-jobs FreeBSD 関連の雇用機会に関する話題 freebsd-newbies FreeBSD 初心者ユーザの活動と議論 freebsd-policy FreeBSD Core team のポリシーに関する議論. 流量は少なく, 投稿することはできません freebsd-questions ユーザからの質問と技術サポート freebsd-stable FreeBSD-stable の使用に関連する議論 freebsd-test メッセージの送信試験を行なうために, 実際のメーリングリストの代わりに使うアドレス 技術的なメーリングリスト: 以下のメーリングリストは, 技術的な 議論のためのものです. それらの利用や内容のためにしっかりとしたガイドラ インがあるので, これらのメーリングリストに入ったり, どれか一つにメール を送ったりする前には, それらのメーリングリストの憲章を注意深く読むべきで す. リスト 目的 freebsd-afs FreeBSD へのAFSの移植 freebsd-alpha FreeBSD の Alpha への移植 freebsd-atm FreeBSD での ATM ネットワーク使用に関する話題 freebsd-audit ソースコード監査プロジェクト freebsd-database FreeBSD 上でのデータベースの利用や開発に関する議論 freebsd-doc FreeBSD 関連ドキュメントの作成 freebsd-emulation Linux/DOS/Windows のような他のシステムのエミュレーション freebsd-fs ファイルシステム freebsd-hackers 一般的な技術の議論 freebsd-hardware FreeBSD の走るハードウェアの一般的な議論 freebsd-i18n FreeBSD の国際化 freebsd-ia64 FreeBSD の Intel が開発中の IA64 システムへの移植 freebsd-ipfw IP firewall コードの再設計に関する技術的議論 freebsd-isdn ISDN 開発者 freebsd-java Java 開発者や, FreeBSD へ JDK を移植する人たち freebsd-libh 第 2 世代のインストール, パッケージシステム freebsd-mobile モーバイルコンピューティングについての議論 freebsd-mozilla mozilla の FreeBSD への移植に関する議論 freebsd-new-bus バスアーキテクチャに関する技術的な議論 freebsd-net ネットワークおよび TCP/IP ソースコードに関する議論 freebsd-platforms Intel 以外のアーキテクチャのプラットフォームへの移植 freebsd-ports Ports コレクションに関する議論 freebsd-ppc FreeBSD の PowerPC への移植 freebsd-realtime FreeBSD 用のリアルタイム拡張の開発に関する話題 freebsd-scsi SCSI サブシステム freebsd-security セキュリティに関する話題 freebsd-security-notifications セキュリティに関する通知 freebsd-small 組み込みアプリケーションにおける FreeBSD の利用 freebsd-smp 対称 / 非対称の マルチプロセッシングの設計に関する議論 freebsd-sparc FreeBSD の Sparc への移植 freebsd-tokenring FreeBSD でのトークンリングのサポート 制限されているメーリングリスト: 以下のメーリングリストはより特化された (そしてより厳しい) メンバーのためのものであり, 一般的な興味を惹くようなものでは ありません. このようなメーリングリストに参加する前に, 技術的なメーリングリストで 自らの存在感をアピールするのは良い考えです. そうすることにより, 議論の際のエチケットを学ぶことができるでしょう. メーリングリスト 目的 freebsd-core FreeBSDコアチーム freebsd-hubs ミラーサイトを運営している人達 (基盤のサポート) freebsd-install インストール関係の開発 freebsd-user-groups ユーザグループの調整 freebsd-www www.freebsd.org の管理者 メーリングリストのダイジェスト版: 上述のメーリングリストの多くでダイジェスト版が利用できます. ダイジェスト版ではメーリングリストに新たに投稿された記事が集められ, 100KB を超えた時点で一つのメールとしてまとめて配送されます. ダイジェスト版が利用できる メーリングリストは以下のとおりです. メーリングリスト freebsd-afs-digest freebsd-alpha-digest freebsd-chat-digest freebsd-current-digest freebsd-cvs-all-digest freebsd-database-digest freebsd-hackers-digest freebsd-ia64-digest freebsd-isdn-digest freebsd-java-digest freebsd-questions-digest freebsd-security-digest freebsd-sparc-digest freebsd-stable-digest freebsd-test-digest CVSメーリングリスト: 以下のメーリングリストはソースツリーの さまざまな場所の変更のログメッセージを見ることに 興味のある人向けです. これらは読み専用のリストで, これらにメールを送る事は出来ません. メーリングリスト ソースの範囲 (ソースの) 範囲の説明 cvs-all /usr/src ツリーのすべての変更 (スーパーセット) 参加方法 どのメーリングリストもFreeBSD.ORGにあるので, メーリングリストにメールを送るには, ただ <listname@FreeBSD.org> にメールを送るだけです. すると, メーリングリストに登録されている世界中のメンバに 再配布されます. メーリングリストに参加するには, subscribe <listname> [<optional address>] という内容をメッセージの本文に含むメールを &a.majordomo; に送ります. 例えば, freebsd-announce に参加したい場合は次のようにします: &prompt.user; mail majordomo@FreeBSD.org subscribe freebsd-announce ^D もし, あなたが, 自分自身を違う名前 (メールアドレス) で登録したい場合, あるいは, ローカルなメーリングリスト (もしあなたのサイトに, 興味を持った仲間がいるなら, これはより有効ですし, 私たちにとっても非常に嬉しいことです.) を登録する申し込みをおこないたいのであれば, 次のようにします: &prompt.user; mail majordomo@FreeBSD.org subscribe freebsd-announce local-announce@somesite.com ^D 最後に, majordomo に対して 他のタイプのコントロールメッセージを送ることで メーリングリストから脱退したり, メーリングリストの他のメンバのリストを 得たり, 再びメーリングリストのリストを見たりすることも可能です. 利用できるコマンドの完全なリストを入手するには, 次のようにします: &prompt.user; mail majordomo@FreeBSD.org help ^D 再度言いますが, 私たちは技術的なメーリングリストでは技術的な議論を保つよう 要求します. もし, 重要なアナウンスにのみ興味があるなら, freebsd-announce への参加をお勧めします. これには, あまりたくさんのメールは流れません. メーリングリストの憲章 全て FreeBSD メーリングリストは誰でもそれらを利用することに 固守しなければいけないという一定の簡単なルールがあります. これらのルー ルに従わないと, 結果として FreeBSD の Postmaster postmaster@FreeBSD.orgから 2 回までは警 告を受けます. 3回違反すると, 投稿者は全てのFreeBSDのメーリングリストか ら削除され, そのメーリングリストへのさらなる投稿から締め出されるでしょ う. これらのルールや対策が必要なのは残念です. しかし, 今日のインターネッ トはずいぶんいやらしい環境になっており, 一般の人々は, その(対策の) メカニズムがいかにもろいかという事すら 認識する事が出来ていないと思われます. 道標 いかなる投稿記事もそのメーリングリストの 基本的な憲章を守るべきで す. 例えば, そのメーリングリストが技術的な問題に関するものであ れば, 技術的な議論を含む投稿でなければなりません. 現在継続中の 不適切な憲章やフレイムは, 所属している全ての人に対してメーリングリスト の価値を下げてしまうだけですし, 許される行為ではないでしょう. とくに話題のない自由形式の議論に対してはfreebsd-chat freebsd-chat@FreeBSD.orgメーリ ングリストが自由に認可されているので, かわりに使うべきでしょう. 一度に 3 つ以上のメーリングリストには決して投稿すべきでは ありません. 2 つのメーリングリストには双方に明確な必要性がある場合にのみ 投稿すべきです. どのリ ストに対しても, (メーリングリストの)参加者は(複数のメーリングリ ストに)重複して参加しており, 関連する部分が少ない(例えば, "-stable と -scsi")メーリングリストを除いては, 一度に複数のメー リングリストに投稿する理由は全くありません. もし, Cc に複数の メーリングリストがそのような形で現れて, あなたに届いたのであれば, 再びそのメールに返事を出す前に, Cc の部分もまた編集するべきです. 元記事を書いたのが誰であっても, あなた自身のクロスポストに まだ責任があります. ユーザであれ開発者であれ, (議論の中で) 個人を攻撃したり冒涜した りすることは許されません. 個人的なメールを引用したり再投稿したり する許可をもらえなかったり, もらえそうにない時に, それをおこなう ようなネチケット (訳注: ネットワークにおけるエチケット) に対する ひどい違反は好まれませんが, してはならないと特別に定められている わけではありません. しかしながら, そのような内容がメー リングリストの憲章に沿う場合はほとんどありません. このため, メー リングリストの憲章に違反しているということだけで警告 (または禁止) に値するものと考えていいでしょう. FreeBSD 以外の関連する製品やサービスの広告は, 絶対に禁止し, spam による違反者が宣伝していることが明確であったら, すぐに禁止しま す. 個々のメーリングリストの憲章: FREEBSD-AFS Andrew ファイルシステム このリストは, CMU/Transarc の AFS の移植や使用に関する議論のためです． FREEBSD-ANNOUNCE 重要なイベント/マイルストン これは, 単にたまに発表される重要な freebsd のイベントに関心がある人のた めのメーリングリストです. これは, スナップショットやその他のリリースに ついてのアナウンスを含みます. そのアナウンスは新しいFreeBSDの機能のア ナウンスを含んでいます. ボランティア等の呼びかけがあるかもしれませ ん. これは流通量の少ないメーリングリストで, 完全なモデレートメーリン グリストです. FREEBSD-ARCH アーキテクチャと設計の議論 これは, FreeBSD のアーキテクチャに関する議論を行なうためのメーリングリストです. 当然, その内容は原則的に技術的なものに限定されます. このメーリングリストにふさわしい話題は以下のようなものです. 複数のカスタマイズされたビルドを同時に行うには, ビルドシステムをどういじり直せばよいか VFS で Heidemann レイヤを動作させるには, 何を修正する必要があるか 同一のデバイスドライバを多数のバス, アーキテクチャに共通で使えるようにするには, - デバイスドライバインターフェースをどう改変すれば良いか + デバイスドライバインタフェースをどう改変すれば良いか ネットワークドライバの書き方 FREEBSD-AUDIT ソースコード監査プロジェクト これは, FreeBSD ソースコード監査プロジェクトのメーリングリストです. 本来はセキュリティ関連の変更を行なうためのものだったのですが, 現在の憲章では, ソースコードに対する監査全般のレビューを行なうためのもの, というように拡張されました. このメーリングリストは修正パッチを含んだ, 非常に大きなメッセージが流れます. おそらく, 普通の FreeBSD ユーザが興味を持つものではないでしょう. セキュリティに関する議論のうち, ソースコードの変更とは関係のないものについては freebsd-security で扱われています. 逆に FreeBSD 開発者は修正パッチをこのメーリングリストに送り, レビューを受けてください. これは, その修正パッチにあるバグがシステムの完全性に悪い影響を与える 可能性があるような箇所を扱う場合は特に必要になります. FREEBSD-BUGS バグレポート これは, FreeBSD のバグレポートのためのメーリングリストです. 可能である 場合はいつでも, バグは &man.send-pr.1; を使うか, WEB interfaceを用い て送られる必要があります. FREEBSD-CHAT FreeBSDのコミュニティに関する 技術的ではない話題 このメーリングリストは技術的ではなく, 社会的な情報について, 他のメーリングリストでは取り扱わない話題を含みます. これは, Jordanがシロイタチに似ているかどうか, 大文字で打つかどうか, 誰がたくさんコーヒーを飲むか, どこのビールが一番うまいか, 誰が地下室でビールを作っているか, などについての議論を含みます. 時々重要なイベント (将来開催されるパーティーや, 結婚式, 誕生日, 新しい仕事など) のお知らせが, 技術的なメーリングリストから でてきます. しかし, フォローは直接 -chatメーリングリストにするべきです. FREEBSD-CORE FreeBSDコアチーム これは, コアメンバが使う内部メーリングリストです. FreeBSDに関連する深 刻なやっかい事の裁定や ハイレベルな綿密な調査を要求するときに, このメー リングリストにメッセージを送る事が出来ます. FREEBSD-CURRENT FreeBSD-currentの使用に関する議論 これは freebsd-current のユーザのためのメーリングリストです. メーリングリストでの話題は, -current で登場した新しい機能について, その新機能によってユーザに影響することについての注意, および -current のままでいるために必要な手順についての説明を含みます. current を走らせている人はこのメーリングリストに 登録しなくてはなりません. これは技術的なメーリングリストなので, 完全に技術的な内容を要求します. FREEBSD-CURRENT-DIGEST FreeBSD-currentの使用に関する議論 freebsd-current メーリングリストのダイジェスト版です. このダイジェストは freebsd-current に送られたすべてのメッセージをまとめたものを, 1つのメールにして送り出します. このメーリングリストは 読み専用です. メールを送るような事はしないでください. FREEBSD-DOC ドキュメンテーションプロジェクト このメーリングリストは FreeBSD 向けの文書の作成に関連する事柄やプロジェクトについて議論を行なうためのものです. このメーリングリストに参加しているメンバは, FreeBSD ドキュメンテーションプロジェクトに参加していることになります. このメーリングリストは公開されているので, 参加や投稿は自由に行なうことができます. FREEBSD-FS ファイルシステム FreeBSDのファイルシステムに関する議論 これは技術的なメーリングリストなので, 完全に技術的な内容を要求します. FREEBSD-IPFW IP Firewall これは FreeBSD の IP firewall コードの再設計に関する 技術的な議論のためのフォーラムです. これは技術的なメーリングリストなので, 完全に技術的な内容を要求します. FREEBSD-IA64 FreeBSD の IA64 への移植 これは FreeBSD の Intel の IA-64 プラットフォームへの 移植に参加している人達のための技術的なメーリングリストで, 問題を提起し解決策を議論するためのものです. このような技術的な議論に興味を持つ個人は歓迎します. FREEBSD-ISDN ISDNコミュニケーション このメーリングリストは, FreeBSDに対するISDNサポートの開発の議論を おこなう人のためのものです． FREEBSD-JAVA Javaの開発 このメーリングリストは, FreeBSD 向けのの重要なJavaアプリケーションの開発や, JDK の移植やメンテナンスの 議論をする人のためのものです． FREEBSD-HACKERS 技術的な議論 これはFreeBSDに関する技術的な議論のための フォーラムです. これは最もテクニカルなメーリングリストです. このメーリングリストは, FreeBSD 上でアクティブに活動をしている人のためのもので, 問題を持ち出したり, 代わりの解決法を議論します. 技術的な議論をフォローするのに興味がある人も歓迎します. これは技術的なメーリングリストなので, 完全に技術的な内容を要求します. FREEBSD-HACKERS-DIGEST 技術的な議論 freebsd-hackersメーリングリストのダイジェスト版です. このダイジェスト はfreebsd-hackers に送られたすべてのメッセージをまとめたものを, 1つのメー ルにして送り出します. このメーリングリストは読み専用です. メールを送るような事はしないでください. FREEBSD-HARDWARE FreeBSDのハードウェアの一般的な議論 FreeBSDが走っているハードウェアのタイプや, 何を買ったり避けたりするかに関する様々な問題や, 提案に関する議論. FREEBSD-HUBS ミラーサイト FreeBSD ミラーサイトを運用している人達向けの, アナウンスと議論を行なうメーリングリストです. FREEBSD-INSTALL インストールに関する議論 このメーリングリストは将来のリリースの インストールに関する開発の議論のためのものです. FREEBSD-ISP インターネットサービスプロバイダのについての話題 このメーリングリストは, FreeBSDを用いたインターネット サービスプロバイダ (ISP) に関する話題の議論のためのものです. これは技術的なメーリングリストなので, 完全に技術的な内容を要求します. FREEBSD-NEWBIES 初心者の活動の議論 どのメーリングリストでも扱われていなかった 初心者の活動すべてをカバーします. 独学や問題解決, リソースの見つけ方や使い方, 質問のしかた, メーリングリストの使い方, どのメーリングリストを読めばいいのか, 普通の世間話, 間違いの犯し方, 自慢話, アイディアの共有, 物語, 道徳的な (技術的でない) お手伝い, FreeBSD コミュニティでの貢献のしかたなどの話題をが含まれます. これらの問題を取り扱い, freebsd-questions へ質問できるようサポートします. また, 初心者の頃にはまった同じ事柄に悩んでいる 他の初心者との出会いの場としてfreebsd-newbies を活用してください. FREEBSD-PLATFORMS Intel以外のプラットフォームへの移植 クロスプラットフォームのFreeBSDの問題. Intel 以外のプラットフォームへの FreeBSD の移植についての一般的な議論や提案. これは技術的なメーリングリストなので, 完全に技術的な内容を要求します. FREEBSD-POLICY コアチームのポリシーに関する議論 このメーリングリストは, FreeBSD コアチームのポリシーに 関する議論のためのものです. 流量は少なく, 投稿することはできません. FREEBSD-PORTS ports の議論 FreeBSD Ports コレクション (/usr/ports) に関連する話題や, 新たな ports の提案, Ports コレクションの基盤の変更および一般的な構成の整備活動に関する議論. これは技術的なメーリングリストなので, 厳密に技術的な内容のみが扱われます. FREEBSD-QUESTIONS ユーザからの質問 FreeBSDに関する質問のためののメーリングリストです. その質問がかなり技術的だと思わないのであれば, どのようにして という質問を技術的なメーリングリストに 送るべきではありません. FREEBSD-QUESTIONS-DIGEST ユーザからの質問 freebsd-questions メーリングリストのダイジェスト版です. このダイジェストは freebsd-questions に送られたすべてのメッセージをまとめたものを, 1つのメールにして送り出します. FREEBSD-SCSI SCSIサブシステム これは FreeBSD のための scsi サブシステムについて作業している人向けです. これは技術的なメーリングリストなので, 完全に技術的な内容を要求します. FREEBSD-SECURITY セキュリティの関連の話題 FreeBSDコンピュータのセキュリティの話題 (DES, Kerberos, よく知られている セキュリティホールや, それらのふさぎ方など) これは技術的なメーリングリストなので, 完全に技術的な内容を要求します. FREEBSD-SECURITY-NOTIFICATIONS セキュリティ関連の通知 FreeBSD のセキュリティ問題や, 修正に関する通知を行ないます. このメーリングリストは議論を行なうための メーリングリストではありません. 議論は FreeBSD-security で行ないます. FREEBSD-SMALL 組み込み用に FreeBSD を使う 特殊な FreeBSD 小型システムおよび FreeBSD の組み込み技術に関する議論. これは技術的なメーリングリストなので, 完全に技術的な内容を要求します. FREEBSD-STABLE FreeBSD-stable の使用に関する議論 これは freebsd-stable のユーザ用のメーリングリスト です. メーリングリストでの話題は, -stable で登場した新しい 機能について, その新機能によってユーザに影響すること についての注意, および -stable のままでいるために必要な手順についての説明を含みます. stable を走らせている人はこの メーリングリストに登録すべきです. これは技術的なメーリングリストなので, 完全に技術的な 内容を要求します. FREEBSD-USER-GROUPS ユーザグループの調整のメーリングリスト これは, ローカルなユーザグループがお互いに, または, コアチームが指定した個人と問題を議論する, それぞれのローカルエリアのユーザグループからの 調整人向けの メーリングリストです. このメーリングリストはユーザグループ間の ミーティングの概要やプロジェクトの調整に 制限されるべきです. Usenet ニュースグループ 2つのFreeBSD用のニュースグループがあります. ここでは FreeBSDの議論をするたくさんの様々な人がおり, 他にもFreeBSD関連するユーザがいます. これらのいくつかのニュースグループは Warren Toomey wkt@cs.adfa.edu.au によって Keyword searchable archives で, 検索できるようになっています. BSD用のニュースグループ comp.unix.bsd.freebsd.announce comp.unix.bsd.freebsd.misc 関連する他のUnixのニュースグループ comp.unix comp.unix.questions comp.unix.admin comp.unix.programmer comp.unix.shell comp.unix.user-friendly comp.security.unix comp.sources.unix comp.unix.advocacy comp.unix.misc comp.bugs.4bsd comp.bugs.4bsd.ucb-fixes comp.unix.bsd X Window システム comp.windows.x.i386unix comp.windows.x comp.windows.x.apps comp.windows.x.announce comp.windows.x.intrinsics comp.windows.x.motif comp.windows.x.pex comp.emulators.ms-windows.wine World Wide Web サイト http://www.FreeBSD.ORG/ — 本家のサーバ. http://www.au.FreeBSD.org/ — オーストラリア/1. http://www.au.FreeBSD.org/ — オーストラリア/2. http://www.au.FreeBSD.org/ — オーストラリア/3. http://freebsd.itworks.com.au/ — オーストラリア/4. http://www.au.FreeBSD.org/www.freebsd.org/ — ブラジル/1. http://www2.br.FreeBSD.org/www.freebsd.org/ — ブラジル/2. http://www3.br.FreeBSD.org/ — ブラジル/3. http://www.bg.FreeBSD.org/ — ブルガリア. http://www.bg.FreeBSD.org/ — カナダ/1. http://www2.ca.FreeBSD.org/ — カナダ/2. http://www3.ca.FreeBSD.org/ — カナダ/3. http://www.cn.FreeBSD.org/ — 中国. http://www.cz.FreeBSD.org/ — チェコ共和国. http://www.dk.FreeBSD.org/ — デンマーク. http://www.ee.FreeBSD.org/ — エストニア. http://www.fi.FreeBSD.org/ — フィンランド. http://www.fr.FreeBSD.org/ — フランス. http://www.de.FreeBSD.org/ — ドイツ/1. http://www1.de.FreeBSD.org/ — ドイツ/2. http://www2.de.FreeBSD.org/ — ドイツ/3. http://www.gr.FreeBSD.org/ — ギリシャ. http://www.hu.FreeBSD.org/ — ハンガリー. http://www.is.FreeBSD.org/ — アイスランド. http://www.ie.FreeBSD.org/ — アイルランド. http://www.jp.FreeBSD.org/www.FreeBSD.org/ — 日本. http://www.kr.FreeBSD.org/ — 韓国/1. http://www2.kr.FreeBSD.org/ — 韓国/2. http://www.lv.FreeBSD.org/ — ラトヴィア. http://rama.asiapac.net/freebsd/ — マレーシア. http://www.nl.FreeBSD.org/ — オランダ/1. http://www2.nl.FreeBSD.org/ — オランダ/2. http://www.no.FreeBSD.org/ — ノルウェー. http://www.nz.FreeBSD.org/ — ニュージーランド. http://www.pl.FreeBSD.org/ — ポーランド/1. http://www2.pl.FreeBSD.org/ — ポーランド/2. http://www.pt.FreeBSD.org/ — ポルトガル/1. http://www2.pt.FreeBSD.org/ — ポルトガル/2. http://www3.pt.FreeBSD.org/ — ポルトガル/3. http://www.ro.FreeBSD.org/ — ルーマニア. http://www.ru.FreeBSD.org/ — ロシア/1. http://www2.ru.FreeBSD.org/ — ロシア/2. http://www3.ru.FreeBSD.org/ — ロシア/3. http://www4.ru.FreeBSD.org/ — ロシア/4. http://freebsd.s1web.com/ — シンガポール. http://www.sk.FreeBSD.org/ — スロバキア. http://www.si.FreeBSD.org/ — スロベニア. http://www.es.FreeBSD.org/ — スペイン. http://www.za.FreeBSD.org/ — 南アフリカ/1. http://www2.za.FreeBSD.org/ — 南アフリカ/2. http://www.se.FreeBSD.org/ — スウェーデン. http://www.ch.FreeBSD.org/ — スイス. http://www.tw.FreeBSD.org/www.freebsd.org/data/ — 台湾. http://www.tr.FreeBSD.org/ — トルコ. http://www.ua.FreeBSD.org/www.freebsd.org/ — ウクライナ/1. http://www2.ua.FreeBSD.org/ — ウクライナ/2. http://www4.ua.FreeBSD.org/ — ウクライナ/クリミア. http://www.uk.FreeBSD.org/ — イギリス/1. http://www2.uk.FreeBSD.org/ — イギリス/2. http://www3.uk.FreeBSD.org/ — イギリス/3. http://www6.FreeBSD.org/ — アメリカ/オレゴン. http://www2.FreeBSD.org/ — アメリカ/テキサス. Email アドレス 以下のユーザーグループは, メンバーに FreeBSD に関係する メールアドレスを提供しています. 管理者はアドレスがどのような形であれ 悪用された場合に, アドレスを無効にする権利を留保しています. ドメイン 内容 ユーザーグループ 管理者 ukug.uk.FreeBSD.org forward のみ freebsd-users@uk.FreeBSD.org Lee Johnston lee@uk.FreeBSD.org シェルアカウント 以下のユーザーグループは, FreeBSD Project を活発にサポートしてくれる 人たちにシェルアカウントを提供しています. 管理者はアカウントがどのような形であれ悪用された場合に, アカウントを取り消す権利を留保しています. ホスト アクセス方法 提供内容 管理者 storm.uk.FreeBSD.org SSH のみ Read-only cvs, personal web space, email &a.brian dogma.freebsd-uk.eu.org Telnet/FTP/SSH E-Mail, Web space, Anonymous FTP Lee Johnston lee@uk.FreeBSD.org diff --git a/ja_JP.eucJP/books/handbook/hw/chapter.sgml b/ja_JP.eucJP/books/handbook/hw/chapter.sgml index 764c5a151a..af08e5436b 100644 --- a/ja_JP.eucJP/books/handbook/hw/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/hw/chapter.sgml @@ -1,6648 +1,6648 @@ PC ハードウェアコンパチビリティ 訳: &a.jp.yoshiaki;, 1998 年 3 月 23 日. ハードウェアコンパチビリティの問題は現在の コンピュータ業界でもっとも多く起きる種類の問題であり, FreeBSDもこれに無縁ではありません. 安価に普及している PC ハードウェアで動かすことができるという FreeBSDの利点は, 市場にある驚くほど多様な種類の製品の サポートの義務というマイナス点でもあります. FreeBSDのサポートするハードウェアを徹底的に調べて提供することは不 可能ですが, このセクションでは FreeBSDに含まれるデバイスドライバとそ のドライバがサポートするハードウェアのカタログを示します. 可能で適切 なものについては特定の製品についての注釈を含めました. また, このハンドブックの コンフィグレーション ファイル のセクションにも サポートされているデバイスのリストがありますので そちらもご覧ください. FreeBSD はボランティアプロジェクトでテスト部門には資金がありません から, より多くの情報をこのカタログに載せるにはあなたがたユーザに 頼らなければなりません. あなた自身の経験により, あるハードウェアが FreeBSDで動くか動かないかがわかったとしたら&a.doc; へ e-mailして知らせてください. サポートされているハードウェアについて の質問は, &a.questions;(詳しいことは メーリングリスト を参照してください) へ 宛ててください. 情報を提供したり質問をする時は FreeBSDのバージョンと使っ ているハードウェアのできるだけ詳しい情報を含めることを 忘れないでください. インターネット上のリソース 以下のリンクはハードウェアを選ぶのに役に立ちます. FreeBSDに対して は必要のない (あるいは適用できない) ように見えるかもしれませんが, ここ からのハードウェアの情報のほとんどは OSに依存しないものです. 購入をする前にはあなたの選んだものがサポートされているか FreeBSDハード ウェアガイドを注意して読んでください. Toms's Hardware & Performance Guide 訳注: 日本国内でFreeBSDの動くハードウェアの情報を提供してい るWWWサーバがあります. FreeBSD POWERED hardwares これ以外にも情報を提供しているサーバはあります. いくつかの URLについて はFreeBSD Japan. からたどることができます. 組合せの見本 以下のハードウェアの組合せのサンプルリストは ハードウェアベンダや FreeBSD プロジェクトが保証するものではありません. この情 報は公共の利益のために公開しているものであり, 極めて数多くあるであろう 異なったハードウェアの組合せの中からのある経験の カタログに過ぎません. やり方はいろいろあります. 場合によってはうまく行かないこともあります. 十分気をつけてください. Jordan氏の選んだ組合せ 私の作ったワークステーションとサーバの構成は まずまずうまく行っ ています. 私はこれを保証できるわけでもありませんし, ここにあげた組 合せがずっと best buysであるわけではありません. 私はできればリス トを更新して行きますがそれがいつになるかはわかりません. 訳注: &a.jkh; 氏は FreeBSDプロジェクト FreeBSD コアチームのメンバです. マザーボード Pentium Pro (P6)システム用で気に入っているのは Tyan S1668 デュアルプロセッサマザーボードです. これは Intel PR440FX 同様 オンボードの WIDE SCSI と 100/10MB Intel Etherexpress NIC が ついています. これを使えば最高の小型のシングルあるいは デュアルプロセッサシステム (FreeBSD 3.0ではサポートされています)を作ることができます. Pentium Pro 180/256K チップの価格は非常に安くなっていますが, いつまで手にはいるかはわかりません.. Pentium II には, どちらかと言えばひいき目ですが, Adaptec SCSI WIDE コントローラのついた ASUS P2l97-S マザーボードです. For Pentium machines, the ASUS http://www.asus.com.tw/Products/Motherboard/Pentium/P55tp4/index.html はミッドレンジからハイエンドの Pentium サーバあるいはワークステーションシステムには よい選択です. フォルトトレラントシステムを構築したいのであれば パリティメモリを 使い, 真に24時間/週7日間動作させ続けるアプリケーションであれば ECCメモリを使うべきでしょう. ECCメモリはいくらか性能のトレードオ フがあります (それが重要なものであるかそうでないかはあなたのアプ リケーションによりますが). しかし, メモリエラーに対しては明らかに フォルトトレランス性が強化されます. ディスクコントローラ これはいくらかトリッキーです. 私は ISAから PCIまですべてコンパチブルな Buslogic コント ローラを使うようにすすめていましたが, 現在では ISAでは Adaptec 1542CF, EISA では Bt747c, PCIでは Adaptec 2940UW をすすめるよう変わってきています. NCR/Symbios の PCIカードも私のところではうまく動いています, ただ し BIOS-less モデルのボード(SCSI ボード上に ROMらしいものがない 場合は, マザーボード上に SCSIアダプタのための BIOSが必要な ボードである可能性があります 訳注: SC-200など) を使うのであれば マザーボードがそれをサポートしているかどうか 注意しなくてはなりません. PCIマシンで2つ以上の SCSIコントローラが必要となるのであれば, PCIバスの不足を防ぐために Adaptec 3940 カードを考えてもいいでしょう. これは1つのスロットで2台の SCSIコントローラ(と内部バス)を持ちます. ます. 市場には2つのタイプの 3940 がありますので 注意しましょう. — 古いモデルでは AIC 7880 チップを使っていますが, 新しいモデルでは AIC 7895 を使っています. 新しいモデルでは CAM ドライバのサポートが必要です. これはまだ FreeBSD の一部では ありません. 自分で付け加えるか, CAM binary snapshot リリースから インストールする必要があります(URLを参照してください). ディスクドライブ 私は, 極々特殊な状況を除いて それだけのお金をかけることができる なら SCSIは IDEよりもよい と言っています. 小規模なデスクトップ構成 のシステムでも, SCSIであればディスクが安くなっていった時にサーバの (古い入れ換えた) ディスクを比較的簡単に移し替えることができます. あ なたが複数のマシンの管理をしているのであれば単純に 容量について考えるのではなく, 食物連鎖のように考えましょう. 重要なサーバの場合は議論の余地はありません. SCSI機器と品質の良いケーブルを使いましょう. CDROM ドライブ 私は SCSIの方が好みますのでもちろん SCSI CDROMを選びました. 東芝 のドライブは 常に(スピードがどうであっても)お気に入りでしたが, 古い Plextor PX-12CS ドライブも好きです. 高々12倍速のドライブですが, 高い性能と信頼性を提供してくれています. 一般的には, 大部分の SCSI CDROM ドライブは私の見た限りではほとんどしっかりした構造ですので 多分 HPや NECの SCSI CDROMでも問題が起き ることはないでしょう. SCSI CDROM の価格はここ数ヶ月でかなり下落したようで, 技術的に 優れた方法でありながら 現在では IDE CDROMと同じ程度の価 格になっています. もし IDE と SCSI の CDROM ドライブの間で選択することができるのなら, 特に IDE を選ぶ理由はないでしょう. CD-R (CD Recordable: WORM) ドライブ この原稿を書いている時点で, FreeBSDは 3種類の CDRドライブ (私は これらすべては結局は Phillips社のドライブであるのではないかと考えているのですが) をサポートしています : Phillips CDD 522 (Plasmon のドライブと同様の動作をします), PLASMON RF4100, HP 6020i です. 私は HP 6020i を CDROMを焼くのに使っています(2.2 以降の システムで動きます. — それ以前のリリースの SCSIコードでは動きません). 非常に調子よく動いています. システムの /usr/share/examples/worm を見てください. ISO9660ファイルシステムイメージ (RockRidge拡張) を作るスクリプトと それを HP6020i CDR で焼くためのスクリプトの例があります. テープドライブ 私はたまたま Exabyte の 8mm drives と HP の 4mm (DAT) を持っています. バックアップのためであれば, より本質的に丈夫な (また, より容量が大きい) Exabyteの 8mmテープの方がおすすめできます. ビデオカード もし (米国では) 99USドルをかけて商品の XサーバをXi Graphics, Inc. (以前の X Inside, Inc.)から買うことができる なら間違いなく Matrox Millenium IIカードをおすすめします. このカードは無償提供されている XFree86 (現在のバージョンは 3.3.2です) のサーバでも非常によく動きます. Number 9の S3 Vision 868と 968 ベースのカード (the 9FX series) はわりあいと速く, XFree86の S3サーバで うまくサポートされています, 加えて現在では非常に低価格です. まず問題も起きないでしょう. モニタ 私の持っている Sony Multiscan 17seII monitors は非常に調子がいいので, 同じ (トリニトロン) ブラウン管を使っている Viewsonic をおすすめします. 17"よりも 大きなモニタ, 例えば 21" のモニタが実際に必要だとしたらこの文章の執筆時点では 2,000USドル以下のもの (20"のモニタでは 1,700USドル以下のもの) はまったくすすめられません. 20" 以上のクラスでよいモニタは(いくつも) ありますし, 20" クラスで安いモニタもあり ます. うまくいかないことに安くてよいモニタはほとんどありません! ネットワーキング まず最初に, Intel EtherExpress Pro/100B カードをすすめます. ISA カードでは SMC Ultra 16 コントローラ, いくらか安めのPCIベースのカード では SMC 9392DST, SMC EtherPower と Compex ENET32カードがおすすめ できます. 一般的に DECの DC2104x イーサネットコントローラチップを 使っている Znyx ZX342 や DEC DE435/450 などのカードはうまく動くでしょうし, (firewall や roouter に便利な) 2-port 品や 4-port 品を よく見つけることができますが, Pro/100B カードは最も少ない オーバーヘッドで最高の性能を出すでしょう. もう一方, できるだけ低コストでそこその性能で動くものを探しているなら, ほとんどの NE2000のクローンは極めて低価格で うまく動いてくれます. (特殊な) シリアル 高速のシリアル ネットワーク インタフェース (同期シリアルカード) を探しているのであれば Digi International製の SYNC/570 シリーズのド ライバが今の FreeBSD-CURRENT にあります. Emerging Technologies も 提供 するソフトウェアにより T1/E1 の性能が得られるボードを製造しています. もっとも私が直接これらの製品を動かした 経験があるわけではありません. 訳注:Emerging TechnologiesのWeb ページを見るとカードのスペックに Operating Systems: MS-DOS, MS-WINDOWS, System V UNIX, BSD/OS, FreeBSD, NetBSD and Linux と書いてあります. また "BSD/OS, FreeBSD and LINUX Router Card Solutions" というページ もあってサポートは良さそうです. マルチポートカードの選択の幅はかなり広いですが, FreeBSDがサポー トするいう点では Cyclades の製品が最も信頼できるでしょう. この最大の理由はこ の会社が私たちに十分な評価用ボードとスペックを 供給することを約束してくれているからです. 私は Cyclom-16Y が最高の性能価格比であると聞 いていましたが最近は価格のチェックはしていません. 訳注: cycladesの WWWサーバでも Supported Operating Systemsに Linuxや BSDi, FreeBSD が明記されています. 他のマルチポートカードで評判がよいのは BOCAおよび ASTのカードと Stallion Technologiesで, このカードには ここ で非公式なドライバが提供されているようです. オーディオ 私は現在 Creative Labs AWE32 を 使っています. もっともクリエイティブラボ製品が現在一般的にうまく 動いているから, ということにすぎませんが. 他のタイプのサウンド カードは同様にうまくは動かないと聞いています. 単に私の経験が 乏しいということにすぎないと言うことなのかも知れませんが. (私は以前は GUS のファンでしたが, Gravis はサウンドカード から撤退してしまいました). ビデオキャプチャー ビデオキャプチャーについては2つのいい選択肢があります — Hauppauge や WinTV などの Brooktree BT848 チップベースのボードは FreeBSD で非常にうまく動きます. もう一つの動作するボードは Matrox Meteor カードです. FreeBSD はクリエィティブラボの古い video spigotカードの サポートはしていますがこれは見つけるのは非常に むずかしいでしょう. Meteor は 440FX チップセットベースのマザーボードでは 動きませんので注意してください. 詳細はマザーボードの節を参照してください. このような場合には BT848 ベースの ボードを使った方がよいでしょう. 中心部/プロセッサ マザーボード, バス, チップセット * ISA * EISA * VLB PCI 原作: &a.obrien; 投稿者: &a.rgrimes;. 25 April 1995. 更新: &a.jkh;.最終更新 26 August 1996. 訳: &a.jp.yoshiaki;. 12 October 1996. Intelの PCIチップセットについて, 以下にさまざまな種類 の既知の不具合と問題の程度のリストを示します. Mercury: ISAバスマスタがISAとPCIブリッジの向 こう側にある場合は,キャッシュコヒーレンシ(一貫性)の 問題があります. このハードウェア欠陥に対処してうま く動かす方法はキャッシュを offにする以外にはありません. Saturn-I (82424ZX の rev 0, 1 ,2): ライトバックキャッシュのコヒーレンシに 問題があります. このハードウェア欠陥に対処してうまく動かす方法は 外部キャッ シュをライトスルーにすること以外にはありませ ん. Saturn-IIにアップデートしましょう. Saturn-II (82424ZX の rev 3 or 4): 問題なく動きます. ただし多くのマザーボードではライトバック動作に必要な 外部ダーティビット SRAMが実装されていません. 対策としてはライトスルーモードで動かすか, ダーティ ビット SRAMをインストールするかがあります. (これは ASUS PCI/I-486SP3G の rev 1.6 以降で使われています) Neptune: 2つより多くの(3台以上の)バスマスタデ バイスを動かすことができません. Intelは設計の欠陥を 認めています. 2つを越えるバスマスタを許さない, 特別な 設計のハードウェアで PCIバスアービタを置き換えることに より解決されています. (Intelの Altair boardや他にはい くつかの Intelサーバグループマザーボードに見られます). そして, もちろん Intelの公式の回答は Triton チップセットへの 移行で, こちらでは修整したということです. Triton (430FX): 知られているキャッシュコヒーレンシ やバスマスタの問題はありませんがパリティチェック機能が ありません. パリティを使いたいような場合は, 可能であ れば Triton-II ベースのマザーボードを選びましょう. Triton-II (430HX): このチップセット を使っているマザーボードに関するすべての 報告によれば今の ところ好評です. 既知の問題はありません. Orion: このチップセットの初期のバージョンでは PCI write-posting にバグがあり, 大量の PCIバストラフィッ クのあるアプリケーションでは性能の著しい低下があるとい う障害がありました. B0以降のリビジョンのチップセットで は問題は解決されています. 440FX: これは Pentium Pro に対応したチップセットで, 初期の Orion チップセットにあったような問題は見られず, 問題なく動 いているようです. また, これは ECCやパリティを含んだ広い 種類のメモリに対応しています. 既知の問題は Matrox Meteor ビデオキャプチャカードに関するものだけです. CPU/FPU 原作 &a.asami;. 27 December 1997. P6 クラス (Pentium Pro/Pentium II) Pentim Pro, Pentim IIとも FreeBSDで使うのにまったく問題はありません. 実際, わたしたちのメイン FTP サイトである ftp.FreeBSD.org (世界一大きな FTP サイト "ftp.cdrom.com" としても知られています) では Pentium Pro で FreeBSD を使っています. 興味のある方向けに 設定の詳細が公開されています. Pentium クラス Intel Pentium (P54C), Pentium MMX (P55C), AMD K6と Cyrix/IBM 6x86MXプロセッサは全て FreeBSDで動作確認がされています. どの CPUが速いかということはここでは述べません. インターネットを探せばあれが 速いとかこっちの方がいいとか教えてくれるサイトは いっぱいありますので, そちらをご覧ください. :) 一つ注意しないといけないのは, CPU によって必要な電源電圧や冷却の仕様が 異なるということです. マザーボードが指定された電圧を供給できることを 必ず確認しましょう. 例えば, 最近の MMX チップにはコアと入出力で違う電圧を使うもの (コア 2.9V, 入出力 3.3V など) がたくさんあります. また, AMDと Cyrix/IBMのチップには Intelの製品より熱くなるものがいくつかあります. その場合には強力なヒートシンク／ファンを使いましょう. (各社のホームページにお勧めの部品のリストがあります.) クロックスピード 原作 &a.rgrimes;. 1 October 1996. 更新 &a.asami;. 最終更新 27 December 1997. Pentium クラスのマシンはシステムの いくつかの部分で異なったクロックスピードを使っています. これは CPU, 外部メモリバス, PCIバスです. 別々のクロックスピードが使われるために高速な CPUを使ったシステムが 低速な システムよりも必ずしも速いとは限りません. それぞれの場合の違いを以下の表に示します. CPUクロック MHz 外部クロックとメモリバス MHz 外部クロックと内部クロックの比 PCIバスクロック MHz 6060 1.030 6666 1.033 7550 1.525 9060 1.530 10050 225 10066 1.533 12060 230 13366 233 15060 2.530 (Intel, AMD) 15075 237.5 (Cyrix/IBM 6x86MX) 16666 2.533 16666 2.533 18060 330 20066 333 23366 3.533 66 MHz は実際には 66.667 MHzかもしれませんが, そうだと決まっているわけでもありません. Pentium 100 は 50MHzの外部クロックの 2 倍または 66MHz の 1.5 倍の両方で 動かすことができます. 3 倍クロック以上の CPU ではメモリアクセス速度が 不足気味であるという点には注意していただきたいですが, 上の表を見るかぎりでは 100, 133, 166, 200, 233 MHzを使うのが最良だというのがわかります. AMD K6のバグ AMDの K6プロセッサで大きなコンパイルをすると, セグメンテーションフォルトで プロセスが落ちることがあるという事例が 1997年に多数報告されました. これは '97年の第3四半期に直ったようです. 情報を総合すると, チップ上の製造年週が 9733 (97年の 第33週に製造) 以降のものは大丈夫ということのようです. * 486 クラス * 386 クラス 286 クラス FreeBSDは 80286マシンでは動きません. 現在の巨大なフ ルスペックの UNIXをこのようなハードウェアで動かすことはほとんど 不可能でしょう. メモリ FreeBSDをインストールするのに最低限必要なメモリ量は 5 MBです. いったんシステムが起動してカスタムカーネルを 作ることができるならば, もっと少ないメモリ で動かすこともできます. boot4.flp を使えば 4 MB しかメモリがなく てもインストールできます. * BIOS 入力/出力デバイス * ビデオカード * サウンドカード シリアルポートとマルチポートカード UART とは何か, そしてどのように動作するか Copyright © 1996 &a.uhclem;, All Rights Reserved. 13 January 1996. 訳: &a.jp.saeki;, &a.jp.iwasaki;. 11 November 1996. ( ここからは &a.jp.saeki; が翻訳を担当) 汎用非同期送受信コントローラ (UART) はコンピュータのシリアル通信 サブシステムの鍵となる部品です. UART は何バイトかのデータを受けとり, これを 1 ビットずつ順番に送信します. 受信側では, もう一つの UART が このビット列を完全なバイト列に組み立て直します. シリアル転送は, モデムやコンピュータ間の非ネットワーク型の通信, ターミナルその他のデバイスで広く使われています. シリアル転送には主に同期と非同期という 二つの形式があります: 通信サブシステムの名前は, そのハードウェアでサポートされている 通信モードによって変化します. 通常, 非同期通信をサポートしているものは文字 A を含み, 同期通信をサポートしているものは文字 S を含みます. 以下で両方の形式について詳しく説明します. 通常使われている略号は以下の通りです:
UART 汎用非同期送受信装置 (Universal Asynchronous Receiver/Transmitter)
USART 汎用同期-非同期送受信装置 (Universal Synchronous-Asynchronous Receiver/Transmitter)
同期シリアル転送 同期シリアル転送では, 送信側と受信側がクロックを共有している 必要があります. さもなければ, 送信側がストローブまたは その他のタイミング信号を供給して, 受信側にデータの次のビットを いつ読み込 めばよいのかを知らせる必要があります. ほとんどの同期シリアル通信では, 常に何らかのデータが転送され続けます. そのため, 転送のタイミングまでに送信データが用意できていなければ, 通常のデータのかわりに「埋め草」 (fill character) が送られます. 同期通信では, 送信側と受信側との間でデータビットのみが転送されるため, 同じビット速度の非同期シリアル通信に比べて効率的です. しかし, 送信側と受信側でクロック信号を共有するために余分な電線と 回路が必要となる場合には, よりコスト高となる可能性があります. プリンタやハードディスクでも同期転送の 一種が使用されています. このときデータが 1 組みの電線で送られる一方, クロック信号または ストローブ信号が別の電線で送られます. プリンタやハードディスクは通常, シリアルデバイスではありません. - ほとんどのハードディスクのインターフェース規格では, + ほとんどのハードディスクのインタフェース規格では, データを送るための 線とは別にクロックまたはストローブ信号を 送るための線を持っていて, ストローブ 1 回毎に一つのデータ全体を送ります. PC 産業界では, これらはパラレルデバイスとして知られています. PC の標準的なシリアル通信ハードウェアは, 同期モードをサポートして いません. ここで同期モードについて述べたのは, 非同期モードとの 比較のために過ぎません. 非同期シリアル転送 非同期転送は, 送信側がクロック信号を受信側に送らなくても データを転送することができます. そのかわり, 送信側と受信側は あらかじめタイミングパラメータや同期のために追加される 特別なビットについて 取り決めをおこなっておかなければなりません. 非同期転送をおこなうために UART にデータが与えられると, 「スタートビット」 と呼ばれるビットが転送データの先頭に追加されます. スタートビットはデータの転送開始を受信側に 知らせるために使われ, これにより受信側のクロックを送信側のクロックに 同期させます. この二つのクロックは, 転送データの残りのビットを転送する間に 10% 以上ふらつかないように正確なものでなければなりません. (この条件は機械式テレタイプの時代に定められたものなので, 現代の電子装置であれば容易に満足させることができます). スタートビットが送られた後, データの各ビットが最下位 (LSB) から 順番に送られます. 転送されるビットの長さはすべて同じになっていて, 受信側はそれぞれのビットの中央部でそれが 1 か 0 かを判断します. 例えば, 仮に 1 ビットを送るのに 2 秒かかるとすると, 受信側は スタートビットの始まりを認識した 1 秒後に信号が 1 か 0 かを調べ, その後 2 秒ごとに次のビットの値を調べるという動作を繰り返します. 送信側は, いつ受信側がビットの値を 見た のかはわかりません. 送信側はクロックにしたがって 次々にビットを転送するだけです. 設定によっては, 1 ワードのデータ全体が送られたあとに 送信側が内部で生成したパリティビットを 付加する場合があります. パリティビットは受信側で簡単なエラーチェックを するために使われます. その後に, 最低でも 1 ビットのストップビットが送られます. 1 ワードのすべてのビットを受信すると, 受信側がパリティビットの チェックをおこなうように設定することができます. (パリティビットを 使用するかどうか, 送信側と受信側であらかじめ取り決めておかなければ なりません). それから受信側はストップビットをチェックします. もしもストップビットが期待通りの位置に存在しなければ, UART は 転送エラーが発生したと判断して, ホストがデータを読もうとした時に フレーミングエラーが起きたと報告します. 通常, フレーミングエラーは 送信側と受信側のクロックが一致していなかったり, 信号に割り込みが 入った時に起こります. データが正しく受信されたかどうかにかかわらず, UART はスタート, パリティ, ストップビットを自動的に捨てます. 送信側と受信側で設定が正しく一致していれば, これらのビットが 誤ってホストに転送されることはありません. 1 回の転送が終了する前に次のデータの転送準備ができていれば, 前のデータのストップビットを送った後, 間を空けずに 次のデータのスタートビットを送ることができます. 非同期転送データは自己同期なので, 転送するべきデータがない場合は 転送路は空き状態になります. UART のその他の機能 転送のためにデータをパラレルからシリアルに変換し, 受信時に シリアルからパラレルに戻すという基本的な機能の他に, UART は通常, 転送路の状態を示したり, リモートデバイスで次のデータを受けとる準備が できていない場合にデータの流れを抑制するのに 使われる信号のための 付加回路も持っています. 例えば UART に接続されているデバイスがモデムの場合, モデムは 回線上に搬送波 (carrier) が存在していることを報告するかもしれません. 一方, コンピュータはこれらの付加信号を操作することにより モデムのリセットをおこなったり, かかってきた電話を取らないように モデムに指示するかもしれません. これらの付加信号の機能はそれぞれ EIA RE232-C 規格で定義されています. RS-232C と V.24 規格 ほとんどのコンピュータシステムでは, UART は EIA RS-232C 規格に 準拠した信号を生成するための回路に接続されています. また, RS-232C の仕様を反映した, V.24 という CCITT 規格に 準拠したシステムも存在しています. RS-232C のビット割り当て (マークとスペース) RS-232C では, 1 の値をマーク, 0 の値をスペースと 呼びます. 通信路にデータが流れていない時, 回線はマーキング であるとか, 1 の値を連続して転送し続けているとか言われます. スタートビットは常に 0 (スペース) で, ストップビットは常に 1 (マーク) です. このことは, たとえ複数のデータが連続して転送されている場合でも, それぞれのデータの転送開始時には必ず, マーク (1) から スペース (0) への遷移が回線上で起こるということを意味しています. これによって, 転送されるデータビットの内容にかかわらず, 送信側と受信側の クロックを同期させることができるのです. ストップビットとスタートビットの間の空き時間は, その通信路で 1 ビットを転送するのに必要な時間の正確な倍数である 必要はありません. (倍数にはゼロを含みます). しかし, ほとんどの UART では 設計の単純化のために, 倍数になるように設計されています. RS-232C では, 「マーク」信号 (1) は -2V から -12V の間の電圧で, 「スペース」信号 (0) は 0V から +12V の間の電圧で示されます. 送信部は +12V または -12V を送ることになっていて, 受信部では 長いケーブルによるいくらかの電圧ロスを 許容するように定められています. (ポータブルコンピュータなどで使用されている) 低消費電力デバイスの 送信部では しばしば +5V と -5V のみを使用していますが, 短いケーブルを使用するならば, これらの電圧も RS-232C 受信部の 許容範囲に入っています. RS-232C のブレーク信号 RS-232C は ブレーク と呼ばれる信号についても定めています. これは (スタートビットもストップビットも無しで) 連続して スペースの値を送ることで発生されます. データ回路に電流が流れていない場合は, 回線は ブレーク を送り続けているものと解釈されます. ブレーク 信号は完全な 1 バイトとスタート, ストップ, パリティ ビットを送るために必要な時間よりも 長い間続かなければなりません. ほとんどの UART はフレーミングエラーとブレークを区別することが できますが, もしも これを区別できない UART があった場合, フレーミングエラーの検出をブレークの識別のために 使用することができます. テレタイプの時代には, 国中でおびただしい数のテレタイプが (ニュースサービスなどで) 電線で直列に接続されていました. 任意のテレタイプユニットは, 電流が流れないように一時的に回路を オープンにすることで ブレーク 信号を発生させることができました. これは, 他のテレタイプが情報を送信している間に, 緊急ニュースを 送る必要のあるテレタイプが 割り込みをかけるために使われました. 現在のシステムでは, ブレーク信号には二つのタイプがあります. もしブレーク信号が 1.6 秒よりも長ければ, それは 「モデムブレーク」であると解釈されます. モデムがこの信号を検出すると, 通信を終了して電話を切ったり, コマンドモードに入るように プログラムされていることがあります. もしブレーク信号が 1.6 秒よりも短ければ, それはデータブレークを 示します. この信号に応答するのはリモートコンピュータの仕事です. この形のブレークは, しばしば注意喚起または割り込みのための信号として 使われ, ASCII の CONTROL-C 文字の代用とされることもあります. マークとスペースは紙テープシステムでの 穴空き と 穴無し に 相当しています. ブレーク信号は, 紙テープまたはその他のバイト列から生成できない ことに注意してください. なぜならバイト列は常にスタートビットや ストップビットとともに送られるからです. UART には通常, ホストプロセッサからの特別なコマンドにより 連続したスペース信号を生成する能力があります. RS-232C の DTE デバイスおよび DCE デバイス RS-232C 規格は二つのタイプの装置を定めています: それはデータターミナル装置 (DTE) とデータキャリア装置 (DCE) です. 通常, DTE デバイスはターミナル (またはコンピュータ) で, DCE は モデムです. 電話回線を介した通信のもう一方の端である受信側のモデムも また DCE デバイスで, そのモデムに接続されているコンピュータは DTE デバイスです. DCE デバイスが信号を受け取るピンは DTE デバイスが 信号を送るピンであり, また逆も同様です. 二つのデバイスがともに DTE であったり, ともに DCE であって, モデムやそれに類似したメディア変換装置を介さずに 接続する必要が ある場合, ヌルモデム (NULL modem) を使わなければなりません. ヌルモデムはケーブルを電気的に再配列し, 一方のデバイスの送信出力が もう一方のデバイスの受信入力に接続され, その逆もまた同様に 接続されるようにしてくれます. 同様の変換はすべての制御信号についておこなわれ, それぞれのデバイスが 他方のデバイスからの DCE (または DTE) 信号を受けとれるようになります. DTE デバイスと DCE デバイスで生成される信号の数は等しくありません. DTE デバイスが DCE デバイスのために生成する信号の数は, DTE デバイスが DCE デバイスから受けとる信号の数よりも 少なくなっています. RS-232C のピン割当て EIA の RS-232C 規格 (およびこれに相当する ITU の V.24 規格) は 25 ピンのコネクタ (通常 DB25 が使われます) を要求し, そのコネクタのほとんどのピンの 使用目的を定義しています. IBM PC および類似のシステムでは, RS-232C 信号のサブセットが 9 ピンのコネクタ (DB9) で提供されています. 主に同期モードで使用される信号は PC のコネクタには含まれていませんが, もともと この転送モードは IBM が IBM PC で使用することにした UART ではサポートされていません. メーカーによっては RS-232C 用のコネクタに DB25 か DB9, またはその両タイプのコネクタを使っている場合があります. - (IBM PC はパラレルプリンタインターフェースにも DB25 + (IBM PC はパラレルプリンタインタフェースにも DB25 コネクタを 使っているので, このことは しばしば混乱を引き起こします.) 以下は DB25 および DB9 コネクタにおける RS-232C 信号の割り当て表です. DB25 RS232-C 端子 DB9 IBM PC 端子 EIA 回路符号 CCITT 回路符号 一般名称 信号源 説明 1 - AA 101 PG/FG - 保安用接地 2 3 BA 103 TD DTE 送信データ 3 2 BB 104 RD DCE 受信データ 4 7 CA 105 RTS DTE 送信要求 5 8 CB 106 CTS DCE 送信可 6 6 CC 107 DSR DCE データセットレディ 7 5 AV 102 SG/GND - 信号用接地 8 1 CF 109 DCD/CD DCE 受信キャリア検出 9 - - - - - 予約 (テスト用) 10 - - - - - 予約 (テスト用) 11 - - - - - 未割当て 12 - CI 122 SRLSD DCE 従局受信キャリア検出 13 - SCB 121 SCTS DCE 従局送信可 14 - SBA 118 STD DTE 従局送信データ 15 - DB 114 TSET DCE 送信信号エレメントタイミング 16 - SBB 119 SRD DCE 従局受信データ 17 - DD 115 RSET DCE 受信信号エレメントタイミング 18 - - 141 LOOP DTE ローカルループバック 19 - SCA 120 SRS DTE 従局送信要求 20 4 CD 108.2 DTR DTE データ端末レディ 21 - - - RDL DTE リモートデジタルループバック 22 9 CE 125 RI DCE 被呼表示 23 - CH 111 DSRS DTE データ信号速度選択 24 - DA 113 TSET DTE 送信信号エレメントタイミング 25 - - 142 - DCE テストモード ビット, ボー, そしてシンボル ボーとは非同期通信における転送速度の単位です. モデム通信技術の進歩により, 新しいデバイスのデータ速度を 表記するにあたって, この用語が しばしば誤って使われるようになりました. ボーレートは伝統的に, 通信路を通して実際に送られるビットの数を 表します. ある DTE デバイスからもう一方へと実際に移動した データの量を表すものではありません. ボーレートは, 送信側 UART で生成されて受信側 UART で取り除かれる スタート, ストップ, パリティといったオーバーヘッドビットをも 含んでいます. これは 1 ワード 7 ビットのデータを送るためには, 実際には 10 ビットの データが完全に転送される必要があるということを意味します. そのため, もしパリティを使い, スタートビットとストップビットが それぞれ 1 ビットずつ存在する場合には, 1 秒あたり 300 ビットの 転送能力を持つモデムでは, 7 ビットのワードを通常 30 個しか 転送することができません. もし 1 ワード 8 ビットのデータとパリティビットを使用する場合には, データ転送速度は 1 秒あたり 27.27 ワードまで低下します. なぜなら 8 ビットのワードを送るのに 11 ビットが必要で, このモデムは 1 秒間に 300 ビットしか送ることができないからです. 1 秒あたりの転送バイト数をボーレートに変換したり, その逆をおこなう 計算式は, エラー訂正をおこなうモデムが現れるまでは単純でした. エラー訂正をおこなうモデムは, ホストコンピュータの UART から シリアルのビット列を受けとり, それをバイト列に戻します. (内蔵モデムを使用している場合でさえ, データは今まで通り 頻繁にシリアル化されます) その後これらのバイトはパケットに変換され, 同期転送方式を用いて 電話回線を通じて送信されます. これは DTE (コンピュータ) 中の UART で追加されたストップ, スタート およびパリティビットは, モデムから送り出される前に, モデムによって 取り除かれるということを意味します. これらのバイト列がリモートモデムに受信されると, リモートモデムは スタート, ストップおよびパリティビットを追加して, それらを シリアル形式に変換し, リモートコンピュータの受信側 UART に送ります. そしてリモートコンピュータの UART はスタート, ストップおよび パリティビットを取り除きます. これらの特別な変換はすべて, 二つのモデムの間でエラー訂正が 実行できるようにするためおこなわれています. エラー訂正とは, 受信側のモデムが正しいチェックサムで 受信できなかったデータブロックの再送を, 送信側のモデムに要求することができるということです. この作業はモデムにより処理されて, DTE デバイスは このようなプロセスがおこなわれていることに, 通常気がつきません. スタート, ストップおよびパリティビットを取り除くことにより, エラー訂正のために二つのモデムの間で共有しなければならない 追加のビットを, 実効転送速度を低下させずに送ることができます. そのため, 送受信 DTE にはエラー訂正がおこなわれているかどうかが ほとんど見えなくなります. 例えば, もしモデムが 10 個の 7 ビットデータをもう一方のモデムに送る 際に, スタート, ストップ, およびパリティビットを送る必要がなければ, その分の 30 ビットの情報を, 真のデータの転送速度に影響を与えることなく エラー訂正のために追加することができるわけです. データ圧縮をおこなうモデムでは, ボーという言葉の使い方は さらに混乱することになります. 例えば電話回線を通じて送られた二つの 8 ビットデータは, 送信側モデムに送られた 12 バイトのデータを表すかもしれません. 受信側モデムはそのデータを本来の内容に展開し, 受信側の DTE に渡します. また, 最近のモデムはバッファを内蔵しており, (DCE から DCE へ) 電話線を 流れるデータの転送速度と, 両端の DTE と DCE の間で流れるデータの 転送速度とを別々に設定することができます. モデムによる圧縮を使用する場合, 通常は DTE と DCE の間の速度を DCE と DCE の間の速度より速くしておきます. 1 バイトを記述するのに必要なビットの数は, 二つのマシンの間でも DTE-DCE と DCE-DCE のリンクでそれぞれ変化する場合がありますし, そのうえ, それぞれのビット転送速度が異なる場合もあります. そのため, 全体としての通信速度を表現するために ボーという言葉を使うことは 問題でもありますし, 真の転送速度を正しく伝えない場合があります. 1 秒あたりの転送ビット数 (bps) は DCE と DCE - の間のインターフェースに + の間のインタフェースに おける転送速度を記述するために使うなら正しい用語ですし, ボーまたは 1 秒あたりのビット数は, 二つのシステムが電線で直接 接続されていたり, エラー訂正や圧縮をおこなわないモデムが 使われている場合には, 許容可能な用語です. 最近の高速モデム (2400, 9600, 14,400, 19,200bps などのもの) も, 実際には 2,400 ボー (正確には 2,400 シンボル/秒) か, それ以下の 速度で通信しています. 高速モデムでは, 複数のビットを一つのシンボルで 伝送する技術 (多値符合化など) を用いて, シンボル速度 (シンボル/秒) よりも 高い通信速度 (ビット/秒) を達成しています. これが電話の限られた音声帯域で 高い伝送速度を得られる理由です. 28,800bps やそれ以上のモデムでは, シンボル速度自体が 可変になっていますが, それ以外は同様の技術が用いられています. IBM PC の UART 元祖 IBM PC を設計した際に, IBM はナショナル・セミコンダクタ社の INS8250 UART を IBM PC パラレル/シリアルアダプタで使用することに 決めました. IBM 自身やその他のベンダが作っている後継世代の AT 互換機でも, INS8250 そのものやナショナル・セミコンダクタの UART ファミリの 改良版を使い続けられています. ナショナル・セミコンダクタの UART ファミリ系統図 INS8250 UART にはいくつかのバージョンと後継の部品があります. 主要なバージョンを以下に示します. INS8250 -> INS8250B \ \ \-> INS8250A -> INS82C50A \ \ \-> NS16450 -> NS16C450 \ \ \-> NS16550 -> NS16550A -> PC16550D INS8250 この部品は元祖 IBM PC と IBM PC/XT で 使われていました. この部品は本来 INS8250 ACE (Asynchronous Communications Element) と いう名前で, NMOS 技術で作られていました. 8250 は八つの I/O ポートを占有し, 送信バッファ 1 バイトと 受信バッファ 1 バイトを持っています. この元祖の UART はいくつかの 競合状態などに関する欠陥を持っています. 元祖の IBM BIOS はこれらの欠陥を回避してうまく動くようなコードを 含んでいましたが, そのために BIOS が欠陥の存在に依存するように なってしまいました. このため, 元祖 IBM PC や IBM PC/XT では 8250A, 16450, または 16550 のような後継部品を使うことは できませんでした. INS8250-B これは NMOS 技術で作られた INS8250 の低速版です. これもオリジナルの INS8250 と同じ問題を含んでいます. INS8250A XMOS 技術を使い, さまざまな機能的欠陥を修正した INS8250 の改良版です. INS8250A は当初, クリーンな BIOS を 使用したベンダの PC クローンで使用されていました. なぜなら欠陥が修正されたことにより, この部品は INS8250 や INS8250B の ために書かれた BIOS で使うことはできなかったからです. INS82C50A これは INS8250A の CMOS 版 (低消費電力版) で, INS8250A と同じ機能特性を持っています. NS16450 より高速な CPU バスにも対応できるように 改良されたこと以外は NS8250A と同じです. IBM はこの部品を IBM AT で使うことに決め, もはや IBM BIOS が INS8250 のバグに依存しなくなるように 変更をおこないました. NS16C450 これは NS16450 の CMOS 版 (低消費電力版) です. NS16550 送信バッファと受信バッファをそれぞれ 16 バイトに 変更したこと以外は NS16450 と同じですが, バッファの設計に 欠陥があるため, 信頼して使用することはできません. NS16550A バッファの欠陥が修正されたこと以外は NS16550 と 同じです. 割り込みへの反応が遅い OS でも高い信頼性で高速なデータを 扱うことができることから, 16550A とその後継部品は PC 産業界で 最も一般的に使われる UART となりました. NS16C552 これは 2 個の NS16C550A CMOS UARTを 一つのパッケージに入れた部品です. PC16550D ささいな欠陥が修正されたこと以外は NS16550A と 同じです. これは 16550 ファミリの D リビジョンで, ナショナル・セミコンダクタ社から 提供されている最新の部品です. NS16550AFとPC16550Dは同じもの ( ここからは &a.jp.iwasaki; が翻訳を担当) ナショナル・セミコンダクタは 数年前に部品番号体系を再編成して おり, NS16550AFN という名称はもはや存在しません. (もしあなたが NS16550AFN を持っていたら, 部品の日付コードを見てください. それは 通常 9 から始まる4桁の数字です. 最初の2桁の数字は年度, 次の2桁 は部品がパッケージされた年度の週です. あなたの持っている NS16550AFN は, おそらく数年前のものでしょう.) 新しい番号は PC16550DV の様に, パッケージ材料と形状により接尾辞 に小さな違いがあります (番号体系についての記述は後述します). ここで注意しなければいけないことがあります. 例えば, ある店に行って 1990年製の NS16550AFN を15米ドルで売っているとします. ところが, そのすぐ隣には ナショナル・セミコンダクタが AFN を生産開始してから それにマイナーな変更を加えて作った PC16550DN があり, そちらは 最近 6ヶ月に作られたものなのに, 簡単に入手できるため NS16550AFN の 半額 (たくさん一度に買うと 5米ドルまで下がることもあります) 位で 買えたりすることがあるのです. NS16550AFN のチップ供給は減少し続けているため, PC16550DN が古い 部品番号のものとまったく同じ機能を持っていることに, より多くの人が 気付いて受け入れるまでは, 価格はおそらく上昇し続けるでしょう. ナショナル・セミコンダクタの部品番号体系 古い NSnnnnnrqp の部品番号は, 現在 PCnnnnnrgp というフォーマットになっています. r はリビジョンのフィールドです. 現在のナショナルセ ミコンダクタの 16550 のリビジョンはDです. p はパッケージタイプのフィールドです. タイプは以下 の通りです: "F" QFP (quad flat pack) L lead type "N" DIP (dual inline package) through hole straight lead type "V" LPCC (lead plastic chip carrier) J lead type 訳注: 具体的なパッケージ形状についての情報は http://www.national.com/packaging/plastic.html を参照 してください. g は製品グレードのフィールドです. もしパッケージタイ プの文字の前にIがあれば, 工業用グレード部品を表し, 標準 部品より高いスペックを持ちますが, Miltary 仕様 (Milspec) ほど高 くはありません. これは付加的なフィールドです. 私たちがかつて NS16550AFN (DIP パッケージ) と呼んでいたものは, 現在 は PC16550DN または PC16550DIN と呼ばれています. 他のベンダと類似の UART 長年に渡り, 8250, 8250A, 16450 そして 16550 はライセンスされ, または他のチップベンダにコピーされてきました. 8250, 8250A そして 16450 の場合は, そのものの回路 (megacell: LSIの中に組み込む ことのできるライブラリ化された回路の大規模な物) が Western Digital と Intel を含むたくさんのベンダにライセンスされまし た. 他のベンダは部品を リバースエンジニアリングした物か同じように 動作する互換品を製造しました. 内蔵モデムにおいては, モデム設計者はモデムのマイクロプロセッサで 8250A/16450 をエミュレートすることはよくおこなわれます. このエミュレート による (互換の) UART は数百バイトの隠れたバッファを持つでしょう. バッファのサイズのため, このような互換品は高速データ処理の能力では 16550A と変わらない信頼性を持つことができます. しかし, それでも ほとんどのオペレーティングシステムは UART は 8250A か 16450 である と報告し, 特殊なドライバが使用されなければ エミュレートによる UART の余分に存在する バッファリングの効果的な使用はおこないません. 幾つかのモデムメーカーは, 市場における競争を有利にするために数百バ イトのバッファを持ち 16550A の置き換えができるはずの設計を, たとえ 性能が低下する事になったとしても 棄てざるを得なくなるような市場の圧 力を受けています. 一般的にある誤解は, 16550A と書かれたすべての部品が同じ性能であると いうことです. それらは異なるものであり, 状況によってはまちがいなく 欠陥と呼べるものがこれらの 16550A クローンのほとんどにあります. NS16550 が開発された時に, ナショナル・セミコンダクタは設計に関する 幾つかの特許を取得し, 彼らはライセンスを制限して他のベンダが類似 の特徴を持つチップを供給することを困難にしました. 特許のため, リバー スエンジニアリングによる設計とエミュレーションは, 特許がカバーする 請求権を侵害を回避しなくてはなりませんでした. 結果として, これらの コピーのほとんどは, 多くのコンピュータとモデムのメーカーは支払いた くはない程の価格であった本物の部品の NS16550A または PC16550D とまった く同じような動作をさせることはできませんでした. 16550A のクローンに存在する相違点のうち いくつかは些細なものですが, そのほかに 特定のオペレーティングシステムやドライバでは 全然使いものにならないような相違が存在する場合もあります. あるドライバでは問題なく動作しても, 別のドライバを使用した場合には 問題が発生することもありますし, Windows のドライバにおいても 充分にテストや考慮がおこなわれなかったイベントの組合わせが 起こった場合には, これらの相違点が明らかになるかもしれません. これはほとんどのモデムベンダと 16550 クローンメーカーが, NS16550A との互換性のプライマリテストとして Windows for Workgroups 3.11 と Microsoft MS-DOS ユーティリティの Microsoft ドライバを使用しているか らです. この安易過ぎる規準は, もし異なるオペレーティングシステムが 使用されたらクローンと 本物の部品の微妙な違いのために問題が発生し得 る, ということを意味しています. ナショナル・セミコンダクタは, どんな OS のドライバからも独立した互 換性テストを実行する COMTEST という名前の入手可能なプログラムを作 成しました. このタイプのプログラムの目的は, 競合製品にある欠陥のデ モンストレーションであることをおぼえておくべきです. ですからそのプ ログラムは, テスト中の部品の動作の重要な問題と極めてささいな相違を 同じように報告するでしょう. この文書の著者が 1994 年に実行した一連のテストでは, ナショナルセミ コンダクタ, TI, StarTech そして CMD が製造した部品は megacell 及び COMTEST でテストされた内蔵モデムに埋め込まれたエミュレーションと同 等です. これらの部品のの幾つかで注目される相違点を以下に示します. これらのテストは1994年に実行されたので, これらはベンダから供給さ れた製品の現在の性能には反映されないでしょう. 極端に多くの問題やあるタイプの問題が検出された場合に, COMTEST は通 常は実行を中止することに注意してください. このテストの一部では, たと え何回相違点に遭遇しても中止しないように COMTEST を修正しました. ベンダ 部品番号 報告された「相違点」として知られるエラー National (PC16550DV) 0 National (NS16550AFN) 0 National (NS16C552V) 0 TI (TL16550AFN) 3 CMD (16C550PE) 19 StarTech (ST16C550J) 23 Rockwell Reference modem with internal 16550 or an emulation (RC144DPi/C3000-25) 117 Sierra Modem with an internal 16550 (SC11951/SC11351) 91 この文書の著者は今まで, COMTEST プログラムを 使用して相違点がゼロと報告されるナショナル・ セミコンダクタ以外の部品を一つも発見しませんでした. ナショナル・セミコンダクタは長年に渡り 16550 の五つのバージョンを持っており, 最新の部品は 機能性のために, ベンチマークを考慮した古い NS16550AFN と少し異なる振る舞いをすることに 注意するべきです. COMTEST はナショナル・セミコンダクタの製品ラインの 相違点については見て見ぬふりをするようになり, 部品のリビジョン A, B そして C にあるバグが 記述されている公式な正誤表がある時でも, (オリジナルの 16550 を除いては) ナショナル・ セミコンダクタの部品についてエラーを 報告しなくなったので, この COMTEST のひいきを 考慮にいれるべきです. COMTEST からの相違点の単純なカウントが, 何の相違点が重要であり どれがそうでないのかについて 多くを明らかにしないことを 理解すること が大切です. 例えば, 内蔵の UART を持つ上記の二つのモデムで報告され た相違点の約半分が, 5及び6ビットキャラクタモードをサポートしないク ローンの UART によって引き起こされました. 本物の 16550, 16450 そし て 8250 UART すべてはこれらのモードをサポートし, COMTEST はこれらの モードの機能性をチェックするので, 50を越える相違点が報告されました. しかし, 5及び6ビットキャラクタモードを サポートするモデムは殆どなく, 特ににこれらはエラー修正と圧縮機能付のものです. これは5及び6ビット キャラクタモードに関連した相違点は 差し引いて考えることができること を意味しています. COMTEST が報告した相違点の多くは, タイミングに関する点でしょう. 多くのクローンの設計では, ホストが一つのポートから読み込んだ時に他 のあるポートのステータスビットは, 本当の NS16550AFN と同じ 長さの時間内で更新されない (あるものは速く, あるものは遅く) かもしれ ませんが, COMTEST はこれらの相違点を探します. これは相違点の数は誤 解を招き易いものです. あるデバイスには一つか二つの相違点しかありま せんがそれらは非常に重大かもしれません. また別のデバイスは基準部品 と比べて速くまたは遅く status レジスタを更新するために (適切に書か れたドライバの操作にはまったく影響しないかもしれません) 多くの相違点を 報告されるかもしれません. COMTEST は問題を引き起こすかも知れない, または特殊なケースとして処 理しなければならない潜在的に矛盾した部品の存在に対して, 管理者に警 告を出すスクリーニングツールとして使用できます. もしモデムの中にある 16550 やシリアルポート接続されているモデムに 対して COMTEST を実行する場合, モデムがテストキャラクタをエコーし ないように最初に ATE0&W コマンドをモデムに発行する必要がありま す. これをおこなうことを忘れた場合, COMTEST は少なくともこの相違点を 報告するでしょう: Error (6)...Timeout interrupt failed: IIR = c1 LSR = 61 8250/16450/16550 のレジスタ 8250/16450/16550 UART は八つの連続する I/O ポートアドレスを予約 しています. IBM PC ではこれらの八つのポートに対して二つの定義された 位置があり, それらは集合的に COM1 と COM2 として知られています. PC クローンとアドオンカードのメーカーは COM3 と COM4 として知られる二つ の付加的な領域を作成しましたが, 幾つかのシステムではこれらの余分な COM ポートは他のハードウェアと衝突します. 最もよく起きるものは IBM 8514 エミュレーションを提供するビデオアダプタとの衝突です. COM1 には 0x3f8 から 0x3ff が割り当てられ, 通常 IRQ 4 が使用されます. COM2 には 0x2f8 から 0x2ff が割り当てられ, 通常 IRQ 3 が使用されます. COM3 には 0x3e8 から 0x3ef が割り当てられ, IRQ は標準化されていません. COM4 には 0x2e8 から 0x2ef が割り当てられ, IRQ は標準化されていません. 8250/16450/16550 UART のI/Oポートの詳細は以下に提供されています. I/O ポート 許可されたアクセス 説明 +0x00 write (DLAB==0) Transmit Holding Register (THR). このポートに書き込まれた情報は データ命令として 処理され, UART により送信されます. +0x00 read (DLAB==0) Receive Buffer Register (RBR). シリアル接続から UART によって受信されたすべての データ命令は, このポートを読むことによってホス トによりアクセスされます. +0x00 write/read (DLAB==1) Divisor Latch LSB (DLL) マスタ入力クロックの周波数を このレジスタに入っ ている値で割ることにより, UART の周波数が決定 されます (IBM PCでは, マスタクロックの周波数は 1.8432MHzです). このレジスタには上記の除数の下 位8ビットが入っています. +0x01 write/read (DLAB==1) Divisor Latch MSB (DLH) マスタ入力クロックの周波数をこの レジスタに入っ ている値で割ることにより, UART の周波数が決定 されます (IBM PCでは, マスタクロックの周波数は 1.8432MHzです). このレジスタには上記の除数の上 位8ビットが入っています. +0x01 write/read (DLAB==0) Interrupt Enable Register (IER) 8250/16450/16550 の UART はイベントを四つのカテ ゴリの一つに分類します. それぞれのカテゴリは設 定可能です. それぞれのカテゴリは, どんな類のイ ベントの発生時に割り込みを 生成するように設定可 能です. 8250/16450/16550 の UART は, 有効になっ ているカテゴリ内でいくつの イベントが発生してい るかに関わらず, 単一の外部割り込みシグナルを生 成します. 割り込みに応答し有効になっている割り 込みカテゴリ (通常すべてのカテゴリが有効になって いる割り込みを持ちます) を割り込みの本当の原因 を決定するためにポーリングするかは, ホストのプ ロセッサ次第です. Bit 7 予約済み, 常に 0. Bit 6 予約済み, 常に 0. Bit 5 予約済み, 常に 0. Bit 4 予約済み, 常に 0. Bit 3 Enable Modem Status Interrupt (EDSSI). このビットを「1」に設定することで, 一つ以上の状態ラインで変更が発生した時 に, UART が割り込みを生成可能となりま す. Bit 2 Enable Receiver Line Status Interrupt (ELSI) このビットを「1」に設定することで, 入っ てくるデータにエラー (または BREAK シ グナル) が検知された時に, UART が割り 込みを生成するようになります. Bit 1 Enable Transmitter Holding Register Empty Interrupt (ETBEI) このビットを「1」に設定することで, UART に送信される一つ以上の付加的な文 字に対する空きが生じた時に, UART が割 り込みを生成するようになります. Bit 0 Enable Received Data Available Interrupt (ERBFI) このビットを「1」に設定することで, UART が FIFO のトリガーレベルを越え る十分な文字を受け取るか, FIFO のタイ マが期限切れとなるか (古くなったデータ), FIFO が無効の場合にシグナル文字が受信 された時に, UART が割り込みを生成する ようになります. +0x02 write FIFO Control Register (FCR) (このポートは 8250 と 16450 の UART では 存在しません.) Bit 7 Receiver Trigger Bit #1 Bit 6 Receiver Trigger Bit #0この二つのビットは FIFO が機能している 場合にレシーバがどの時点で割り込みを生 成するかを制御します. 7 6 割り込み生成前にいくつの命令 が 受信されたか. 0 0 1 0 1 4 1 0 8 1 1 14 Bit 5 予約済み, 常に 0. Bit 4 予約済み, 常に 0. Bit 3 DMA Mode Select. Bit 0 が「1」 (FIFO 有効) に設定されて いる場合, このビットの設定は -RXRDY と -TXRDY の処理を Mode 0 から Mode 1 へ 変更します. Bit 2 Transmit FIFO Reset. このビットに「1」が書き込まれている場 合, FIFO の内容は破棄されます. 現在送 信されているすべての命令は損なわれずに送 られるでしょう. この機能は送信中止の場 合に役に立ちます. Bit 1 Receiver FIFO Reset. このビットに「1」が書き込まれている場 合, FIFO の内容は破棄されます. 現在 shift レジスタ内で組み立てられているすべ ての命令は損なわれずに受信されるでしょ う. Bit 0 16550 FIFO Enable. 設定されている場合, 送信 / 受信両方の FIFO が有効になります. holding レジス タ, shift レジスタまたは FIFO 内のすべて の内容は, FIFO が有効または無効になっ た時点で失われます. +0x02 read Interrupt Identification Register Bit 7 FIFO有効. 8250/16450 UART では, このビットはゼロ. Bit 6 FIFO有効. 8250/16450 UART では, このビットはゼロ. Bit 5 予約済み, 常に0. Bit 4 予約済み, 常に0. Bit 3 Interrupt ID Bit #2. 8250/16450 UART では, このビットはゼロ. Bit 2 Interrupt ID Bit #1 Bit 1 Interrupt ID Bit #0. これらの3つのビットは進行中の割り込み を引き起こしたイベントのカテゴリを併せ て報告します. これらのカテゴリは優先度 を持つため, イベントの複数のカテゴリが 同時に発生した場合, UART は最初に最も 重要なイベントを報告し, ホストは報告さ れた順に解決するでしょう. 現在の割り込 みを引き起こしたすべてのイベントは, 新し い割り込みが生成される前に解決されなけ ればなりません (これは PC のアーキテク チャの制限です). 2 1 0 優先度 説明 0 1 1 First レシーバエラー (OE, PE, BI, また FE) 0 1 0 Second 有効な受信データ 1 1 0 Second トリガーレベル識別子 (受信バッファ中の古いデータ) 0 0 1 Third トランスミッタに 命令用の空きがある (THRE) 0 0 0 Fourth モデムの状態が 変わった (-CTS, -DSR, -RI, または -DCD) Bit 0 Interrupt Pending Bit. このビットが「0」に設定されている場合, 少なくとも一つの割り込みがペンディング されています. +0x03 write/read Line Control Register (LCR) Bit 7 Divisor Latch Access Bit (DLAB). 設定されている場合, transmit/receive register (THR/RBR) と Interrupt Enable Register (IER) へのアクセスが無効にな ります. 現在これらのポートへのすべてのア クセスは Divisor Latch Register へリダ イレクトされます. このビットの設定, Divisor Register のローディング, そし て DLAB のクリアは割り込みが無効になっ ている状態でおこなわれるべきです. Bit 6 Set Break. 「1」に設定されている場合, トランスミッ タはこのビットが「0」に設定されるまで スペースを切り目なく送信します. これは 送信されている文字のすべてのビットに優先 します. Bit 5 Stick Parity. parity が有効になっている場合, このビッ トの設定はビット4の値に基づき parity を常に「1」か「0」にします. Bit 4 Even Parity Select (EPS). parity が有効でビット5が「0」の場合, このビットの設定は偶数 parity が送信そ して要求されるようにします. そうでなけ れば奇数 parity が使用されます. Bit 3 Parity Enable (PEN). 「1」に設定されている場合, データの最 後のビットとストップビットの間に parity ビットが挿入されます. また UART は受信データに存在する parity を要求す るでしょう. Bit 2 Number of Stop Bits (STB). 「1」に設定されている場合, 5-bit デー タ命令を使用して, 1.5の Stop ビットが 送信され各データ命令内に要求されま す. 6, 7 そして 8-bit データ命令に対し ては, 2つの Stop ビットが送信され要求 されます. このビットが「0」に設定され ている場合, 1つの Stop ビットが各デー タ命令で使用されます. Bit 1 Word Length Select Bit #1 (WLSB1) Bit 0 Word Length Select Bit #0 (WLSB0) これらのビットは共に 各データ命令内のビッ トの数を指定します. 1 0 命令長 0 0 5 Data Bits 0 1 6 Data Bits 1 0 7 Data Bits 1 1 8 Data Bits +0x04 write/read Modem Control Register (MCR) Bit 7 予約済み, 常に 0. Bit 6 予約済み, 常に 0. Bit 5 予約済み, 常に 0. Bit 4 Loop-Back Enable. 「1」に設定されている場合, UART のトラ ンスミッタとレシーバは診断処理のために 内部的に相互に接続されます. 付け加えて UART のモデム制御出力はモデム制御入力 に接続されます. CTS は RTS へ, DTR は DSRへ, OUT 1 は R1 へ, OUT 2 は DCD へ 各々接続されます. Bit 3 OUT 2. ホストのプロセッサが high または low に設定するであろう補助的な出力. IBM PC のシリアルアダプタ (とクローンの殆ど) では, OUT 2 は 8250/16450/16550 UART からの割り込み信号をハイインピーダンス (無効) にするのに使用されます. Bit 2 OUT 1. ホストのプロセッサが high または low に設定するであろう補助的な出力. IBM PC のシリアルアダプタではこの出力は使用 されません. Bit 1 Request to Send (RTS). 「1」に設定されている場合, UART の -RTS ラインの出力は Low (有効) となり ます. Bit 0 Data Terminal Ready (DTR). 「1」に設定されている場合, UART の -DTR ラインの出力は Low (有効) となり ます. +0x05 write/read Line Status Register (LSR) Bit 7 Error in Receiver FIFO. 8250/16450 UART では, このビットはゼロ です. FIFOの中に次のエラー条件が一つ以 上含まれている場合, このビットは「1」 に設定されます: PE, FE, または BI. Bit 6 Transmitter Empty (TEMT). 「1」に設定されている場合, 送信 FIFO または送信 shift レジスタ中に残ってい る命令はありません. トランスミッタは完 全に働いていません. Bit 5 Transmitter Holding Register Empty (THRE). 「1」に設定されている場合, 現在 FIFO (または holding レジスタ) には少なくと も一つの送信される付加的な命令に対する 空きあります. このビットが「1」に設定 されている時は, 多分トランスミッタはま だ送信しています. Bit 4 Break Interrupt (BI). レシーバは Break シグナルを検知しました. Bit 3 Framing Error (FE). Start ビットが検知されましたが, Stop ビットは要求された時間内には現れません でした. 受信された命令はおそらく勝手に 解釈されます. Bit 2 Parity Error (PE). parity ビットが受信された命令に対して 不正です. Bit 1 Overrun Error (OE). 新しい命令が受信され, 受信バッファに空 きがありませんでした. shift レジスタに 新たに到着した命令は破棄されます. 8250/16450 UART では, holding レジスタ 内の命令は破棄され新たに到着した命令は holding レジスタに置かれます. Bit 0 Data Ready (DR) 一つ以上の命令がホストが読むであろう受 信 FIFO にあります. このビットが設定さ れる前に, 命令は完全に受信され shift レジスタから FIFO (または 8250/16450 の設計では holding レジスタ) へ移動さ れなければなりません. +0x06 write/read Modem Status Register (MSR) Bit 7 Data Carrier Detect (DCD). UART の DCD ラインの状態を反映します. Bit 6 Ring Indicator (RI). UART の RI ラインの状態を反映します. Bit 5 Data Set Ready (DSR). UART の DSR ラインの状態を反映します. Bit 4 Clear To Send (CTS). UART の CTS ラインの状態を反映します. Bit 3 Delta Data Carrier Detect (DDCD). ホストによって MSR が最後に読み込まれ た時点から, -DCD ラインが状態を一回以 上変えた場合に「1」に設定されます. Bit 2 Trailing Edge Ring Indicator (TERI). ホストによって MSR が最後に読み込まれ た時点から, -RI ラインが low から high へ移り変わった場合に「1」に設定されま す. Bit 1 Delta Data Set Ready (DDSR). ホストによって MSR が最後に読み込まれ た時点から, -DSR ラインが状態を一回以 上変えた場合に「1」に設定されます. Bit 0 Delta Clear To Send (DCTS). ホストによって MSR が最後に読み込まれ た時点から, -CTS ラインが状態を一回以 上変えた場合に「1」に設定されます. +0x07 write/read Scratch Register (SCR). このレジスタは UART では機能しません. この場所 には どんな値でもホストによって書き込まれるこ とができ, その後ホストによって読み込むことが可 能です. 16550A UART を越えて ナショナル・セミコンダクタは付加的な機能を持つ 16550 と互換 性のある部品を提供していませんが, 色々な他のベンダがそれを持っ ています. これらの部品の幾つかは以下に記述されています. 効果的 にこれらの改良を使用するためには, 殆どのポピュラーなオペレーティ ングシステムが 16550 が提供する機能以上のものをサポートしない ため, ドライバはチップベンダから提供されなければならないことを 理解しておく必要があります. ST16650 デフォルトではこの部品は NS16550A と似ていますが, 拡 張された32バイトの送受信バッファを オプションで有効にで きます. StarTech により製造されました. TIL16660 デフォルトではこの部品は NS16550A と類似した振舞いを しますが, 拡張された64バイトの送受信バッファをオプショ ンで有効にできます. Texas Instruments により製造されま した. Hayes ESP この専売特許のプラグインカードは, 2048バイトの送受 信バッファを含み, 230.4Kbit/sec のデータレートをサポー トします. Hayes により製造されました. これらのダムUART に加え, たくさんのベンダがインテリジェ ントシリアルコミニュケーションボードを製造しています. こ のタイプの設計は通常マイクロプロセッサを提供しており, このマイ クロプロセッサは幾つかの UART へのインタフェースとなってデータ を処理 / バッファリングし, そして必要な時にメインの PC のプロセッ サへ警告を出します. UART はこのタイプのコミニュケーションシ ステムにおいて PC のプロセッサによって直接アクセスされないため, ベンダにとっては 8250, 16450, または 16550 UART と互換性のある UART を使用する必要はありません. これにより設計者は, より良い 性能特性を持つ部品が自由に利用できます. <devicename>sio</devicename>ドライバの設定 sio ドライバは, NS8250-, NS16450-, NS16550とNS16550A ベースの EIA RS-232C(CCITT V.24) 通信用インタフェースをサポートします. ま た, いくつかのマルチポートシリアルカードもサポートされています. 技術的 な詳細についてはマニュアル &man.sio.4; を見てください. Digi International (DigiBoard) PC/8 原作: &a.awebster;. 1995年8月26日. 訳: &a.jp.masaki;.6 September 1996. 以下にDigi International PC/8Dと16550チップを動作させるための, カーネ ルconfigの部分を示します. このボードは, 8本の回線にすべてモデムを接続 した場合でも良好に動作します. options COM_MULTIPORT を加えるのを忘れないでください. 忘れる とうまく動作しません! device sio4 at isa? port 0x100 tty flags 0xb05 device sio5 at isa? port 0x108 tty flags 0xb05 device sio6 at isa? port 0x110 tty flags 0xb05 device sio7 at isa? port 0x118 tty flags 0xb05 device sio8 at isa? port 0x120 tty flags 0xb05 device sio9 at isa? port 0x128 tty flags 0xb05 device sio10 at isa? port 0x130 tty flags 0xb05 device sio11 at isa? port 0x138 tty flags 0xb05 irq 9 vector siointr ここで各 SIO ポートが割り込みを共有する一つのグループであることを表現 するために, トリッキーな設定をしなければなりません. フラグ (flags の後 ろの 16 進数) の下から 2 バイト目にこのグループの最後の SIO ポートの番 号を設定します. この例では 11 (16進数では 0x0b) ですから, 各デバイスの フラグは 0xb05 となります. Boca 16 寄稿: &a.whiteside;. 1995年8月26日 FreeBSD で Boca 16pord のボードを動かすことは簡単ですが, そのた めにはいくつかの作業が必要です. : 2.0.5 のデフォルトのカーネルは, マルチポートのサポートをして いない ので, あなたは各ポート毎にデバイスエントリを追加する必要が あります. つまり必要なオプションを付けて, カーネルの再構築をしなければ なりません. そのためには, あなたのマシンにカーネルのソースコードが既に インストールされているか, あなたの替わりの誰かにカーネル再構築をやって もらう必要があります. 2番目に, あなたはカーネルオプションを正しく設定するために, あな たのBoca Boardの IO と割り込みの値を知っている必要があります. ひとつ重要なことがあります. Boca 16 に使われている実際の UART チップ は, Boca 16 のボードではなく, 外付けのコネクタボックスの中に存在します. コネクタボックスを接続しないと, ポートの検出に失敗するでしょう. 私は, 接続しないまま起動したり, 後から接続しなおしたりした時にどうなるかをテ ストしていません. どちらも実行しないようお奨めします. もしあなたがカスタマイズ済みのカーネル コンフィグレーションファイルを持っ ていなければ, 一般的な事柄については, FreeBSD カーネルのコンフィグレーション を参考にしてください. 以下にBoca 16のボード に関係する部分だけを記述します. この例では, あなたがMYKERNELという名前 のカーネルを使っていて, エディタには viを使っていることを仮定していま す. 次の1行をconfigファイルに追加してください. options COM_MULTIPORT この device sionという行を, 必要に応じて 16 個のデバイス分を追加してください. 最後のデバイスにだけ, このボード の割り込みベクタを記述します. (詳細は &man.sio.4; のマニュア ルページを参照してください.) 以下の例は, 割り込み 3, ベース IO アドレス 100h の値を持つ Boca Board の場合です. 各ポートのための IO アドレスは, 100h, 108h, 110h, ... のよ うに 16 進法で 8 づつ加えていきます. device sio1 at isa? port 0x100 tty flags 0x1005 device sio2 at isa? port 0x108 tty flags 0x1005 device sio3 at isa? port 0x110 tty flags 0x1005 device sio4 at isa? port 0x118 tty flags 0x1005 … device sio15 at isa? port 0x170 tty flags 0x1005 device sio16 at isa? port 0x178 tty flags 0x1005 irq 3 vector siointr フラグエントリは, あなたが全く同じsioの割り当てを使っていない限り 必ず 上記の例から変更してください. フラグは, 次のように設定します. 0x M YY のMは, マスタポート (Boca 16に搭載された最後 のポート)のマイナー番号を指定します. さらに YY の部分はFIFOが 有効または無効であること (この場合は有効), 割り込みを (ボード内で) 共 有しているか (この場合はYES), そして, AST/4 と互換性のある持つ割り込み 制御レジスタを持っているか (この場合はNO) を指定します. この例では, flags 0x1005 というフラグによって, マスタポートが sio16 であることを示します. も し同じボードをもう一枚追加し, sio17 から sio28 を割り当てるなら, 新しい方の ボードに対応する 16 個のポートのフラグはすべて 0x1C05 に なります. 28 (== 0x1C) は新しいボードのマスタポートのマイナー番号で す. フラグの 05 の部分は変更しないでください. カーネルコンフィグレーションファイルを 保存してカーネルの設定を完了しま す. カーネルをコンパイル後, インストールし, 新しいカーネルでリブートし てください. 再コンパイルされたカーネルがうまくインストールされて, そのカーネルに正 しいアドレスと割り込みが設定されていたならば, ブートメッセージは次の ように Boca ポートの検出に成功するはずです: (sioの番号, IOとIRQの値は, この例とは異なっているでしょう) sio1 at 0x100-0x107 flags 0x1005 on isa sio1: type 16550A (multiport) sio2 at 0x108-0x10f flags 0x1005 on isa sio2: type 16550A (multiport) sio3 at 0x110-0x117 flags 0x1005 on isa sio3: type 16550A (multiport) sio4 at 0x118-0x11f flags 0x1005 on isa sio4: type 16550A (multiport) sio5 at 0x120-0x127 flags 0x1005 on isa sio5: type 16550A (multiport) sio6 at 0x128-0x12f flags 0x1005 on isa sio6: type 16550A (multiport) sio7 at 0x130-0x137 flags 0x1005 on isa sio7: type 16550A (multiport) sio8 at 0x138-0x13f flags 0x1005 on isa sio8: type 16550A (multiport) sio9 at 0x140-0x147 flags 0x1005 on isa sio9: type 16550A (multiport) sio10 at 0x148-0x14f flags 0x1005 on isa sio10: type 16550A (multiport) sio11 at 0x150-0x157 flags 0x1005 on isa sio11: type 16550A (multiport) sio12 at 0x158-0x15f flags 0x1005 on isa sio12: type 16550A (multiport) sio13 at 0x160-0x167 flags 0x1005 on isa sio13: type 16550A (multiport) sio14 at 0x168-0x16f flags 0x1005 on isa sio14: type 16550A (multiport) sio15 at 0x170-0x177 flags 0x1005 on isa sio15: type 16550A (multiport) sio16 at 0x178-0x17f irq 3 flags 0x1005 on isa sio16: type 16550A (multiport master) もしメッセージの表示が速くて読み取れないときは, &prompt.root; dmesg | more とするとブート時のメッセージを ゆっくり見ることができます. 次に, root になってから, デバイスにあわせたエントリを /dev/MAKEDEV スクリプトを使って/dev に追加します. &prompt.root; cd /dev &prompt.root; ./MAKEDEV tty1 &prompt.root; ./MAKEDEV cua1 (中略) &prompt.root; ./MAKEDEV ttyg &prompt.root; ./MAKEDEV cuag もし, 何らかの理由で発信するデバイスが不要な場合, cua* デバ イスを作らないで済ますこともできます. デバイスが確実に動作しているかどうか 確認する手っ取り早い方法は, あなたが (rootになって) 各ポートにモデムを接続してみて, あなたが作成し た各デバイス毎に &prompt.root; echo at> ttyd* とやってみてください. 各ポー トが動作していれば RXの表示が光るのが見えるはず です. 安価な Multi-UART カードのサポート 寄稿: Helge Oldach hmo@sep.hamburg.com, September 1999 二つ(またはもっと多くの) COM ポートを備えた 20$ のマルチ I/O カードでの IRQ 共有が, FreeBSD でサポートされているか心配ですって? 次のようにすれば使うことができます. 通常, この種のボードをサポートする場合には, 各ポートに対して個別に IRQ を割り当てて利用します. 例えば, マザーボード上に COM1 ポート (sio0–I/O アドレス 0x3F8, IRQ 4) があり, 二つの UART ポートがついている拡張カードがあるとしましょう. その場合, この二つのポートには, 二番目のポートを COM2(sio1–I/O アドレス 0x2F8, IRQ 3) に, 三番目のポート(sio2)を I/O アドレス 0x3E8, IRQ 5 に設定する必要があります. しかしすぐわかるとおり, この方法では IRQ 資源を無駄に浪費します. 基本的に前セクションに記されている COM_MULTIPORT の設定に従えば, 拡張カード上の二つのポートで一つの IRQ を使用するように セットアップすることができます. そのような安価な I/O ボードには大抵, 次に示すような, COM ポートを選択する 4x3 のジャンパマトリクスがついています. o o o * Port A | o * o * Port B | o * o o IRQ 2 3 4 5 これは, Port A が IRQ 5 に, Port B が IRQ 3 に結線されていることを示しています. IRQ の並びはボードにより異なるでしょう—例えば, 他のボードは IRQ として 3,4,5,7 が選択できるようになっているかも知れません. 「ああ, IRQ を共有するには IRQ 3 の列にある 3 つの接続点をつなぐようなジャンパ線を手作りして, 両方のポートが IRQ 3 になるように結線すれば良いのか」と 考えるかも知れませんが, それは正しくありません. UART の出力段は トーテムポール 接続(*)されているので, IRQ 3 に複数接続することはできないのです. そのため, もし UART のどれか一つが IRQ 3 を発行したとしても, それが期待するような動作になりません. 拡張ボードやマザーボードの実装に依存することですが, IRQ 3 信号線は常時 H レベルか, L レベルを保っています. 訳注: トーテムポール とは, ディジタル論理回路を構成する TTL ロジック IC の内部構造の一種です. トーテムポール型出力の場合には 出力同士を接続すると短絡電流が流れてしまうため, CPU やメモリで使われている, いわゆるバス接続が使えないという特徴を持っています. IRQ 信号線が常時 H か L レベルに保たれる, というのは, 割り込み信号線が正論理/負論理のどちらになっているかが実装に依存することによります. 以降の解説は, 正論理を仮定して書かれていますのご注意下さい. したがって, 二つの UART の IRQ 出力を分離する必要があります. そのためには, どちらかの UART が IRQ を発行した時にだけ, ボード上の IRQ 信号線が H レベルになり, そうでない時には L レベルになるようにします. 以下の解決法は, Joerg Wunsch j@ida.interface-business.de から提案されたものです: 二つのダイオード(ゲルマニウム, あるいはショットキー型を強く推奨)と 1 キロオームの抵抗器一本で, ワイヤード OR を構成します. 以下に示すのは, 上に示した 4x3 ジャンパの回路図です. Diode +---------->|-------+ / | o * o o | 1 kOhm Port A +----|######|-------+ o * o o | | Port B `-------------------+ ==+== o * o o | Ground \ | +--------->|-------+ IRQ 2 3 4 5 Diode 各ダイオードのカソード側は接地点に, 1 キロオームのプルダウン抵抗器と直列にして接続します. プルダウン抵抗を接続することはとても重要です. これはバス上の IRQ 信号線がフロート状態になるのを防ぎます. さあ, これでカーネルの設定を変更する準備ができました. 上に示すような例の場合, 次のような設定になります. # standard on-board COM1 port device sio0 at isa? port "IO_COM1" tty flags 0x10 # patched-up multi-I/O extension board options COM_MULTIPORT device sio1 at isa? port "IO_COM2" tty flags 0x205 device sio2 at isa? port "IO_COM3" tty flags 0x205 irq 3 sio1 と sio2 の flags 設定は非常に重要です. 詳細は &man.sio.4; をご覧ください. (一般的には, "flags" 属性の 2 は, sio2 の IRQ を使用するということを示します. 下位ニブル(訳注: 16 進数一桁のこと) は間違いなく 5 とするでしょう.) カーネルの verbose モードが ON になっていると, こんな風な出力が得られます. sio0: irq maps: 0x1 0x11 0x1 0x1 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1: irq maps: 0x1 0x9 0x1 0x1 sio1 at 0x2f8-0x2ff flags 0x205 on isa sio1: type 16550A (multiport) sio2: irq maps: 0x1 0x9 0x1 0x1 sio2 at 0x3e8-0x3ef irq 3 flags 0x205 on isa sio2: type 16550A (multiport master) /sys/i386/isa/sio.c は irq maps 配列を使っているために 表示が少々難解なのですが, 基本的なアイデアは 1,3,4 番目の場所に 0x1 があるかどうか調べる, というものです. これはつまり, 対応する IRQ が出力された時にセットされ, その後クリアされるという, ちょうど期待する動作が 行なわれることを意味します. もし, カーネルがこのような表示を出力しない場合, 大部分は結線の誤りによるものでしょう. <devicename>cy</devicename> ドライバのコンフィグ 原作: Alex Nash. 6 June 1996. 訳: &a.jp.yuki;. 6 September 1996. Cyclades 社のマルチポートカードは, 他のマルチポートカードが 使う sio の代わりに cyドライバを使います. コンフィグレーションは非常に簡単で, cy デバイスをあなたの カーネルの コンフィグレーションに足します. (注意. あなたのirqやiomemの設定が違っているかもしれません) device cy0 at isa? tty irq 10 iomem 0xd4000 iosiz 0x2000 vector cyintr 新しいカーネルの 再構成と インストール をします. デバイスノード を次(8ポートと仮定しています.) のように打って作ります: &prompt.root; cd /dev &prompt.root; for i in 0 1 2 3 4 5 6 7;do ./MAKEDEV cuac$i ttyc$i;done もし, 必要なら シリアルデバイス (ttyd) とそっくりにコピーして dialupエントリを作り, ttydの代わりに ttycを使います. 例: ttyc0 "/usr/libexec/getty std.38400" unknown on insecure ttyc1 "/usr/libexec/getty std.38400" unknown on insecure ttyc2 "/usr/libexec/getty std.38400" unknown on insecure … ttyc7 "/usr/libexec/getty std.38400" unknown on insecure 新しいカーネルで立ち上げます. <devicename>si</devicename> ドライバのコンフィグ 原作 &a.nsayer;. 25 March 1998. 訳: &a.jp.yoshiaki;. 29 Apr 1999. マルチポートカードのSpecialix SI/XIO と SX は si ドライバを使います. 1台のマシンで4枚までのホストカードを使うことが できます. 以下のホストカードがサポートされています: ISA SI/XIO host card (2 versions) EISA SI/XIO host card PCI SI/XIO host card ISA SX host card PCI SX host card SX と SI/XIO ホストカードは明らかに違いがあるように見えますが これらの機能は基本的には同じものです. ホストカードはI/O空間を 利用しませんが, 代りに32Kブロックのメモリ空間を使います. ISAカードの工場出荷時の設定は0xd0000-0xd7fff です. これらはIRQを必要とします. PCIカードではもちろん自動設定されます. ホストカードには最大4個の外部モジュールが接続できます. 外部モジュールにはそれぞれ4/8本のシリアルポートが内蔵されています. モジュールは以下の品種があります. SI 4 ポート/ポート モジュール. ポートそれぞれ 最大 57600 bps がサポートされます. XIO 8 ボートモジュール. ポートそれぞれ最大 115200 bps がサポートされます. XIOモジュールには 7 シリアルポートと1 パラレルポート のタイプもあります. SXDC, 8ポートモジュール. ポートそれぞれ最大921600 bps がサポートされます. XIOと同様, 1つのパラレルポートを持つモデルがあります. ISA ホストカードを設定するには以下の行を カーネルコンフィグレーション ファイルに追加します. 数値は適当なものに変更してください. device si0 at isa? tty iomem 0xd0000 irq 11 有効なIRQ番号は SX ISA ホストカードでは 9, 10, 11, 12, 15 で SI/XIO ISAホストカードでは 11, 12, 15 です. EISAやPCIカードの設定は, 以下の行を使います: device si0 コンフィグレーションエントリを追加した後で, 新しいカーネルの 再構築とインストール を行ないます. 新しいカーネルで再起動した後に, デバイスノード を /dev 以下に 作成する必要があります. MAKEDEVスクリプト で注意深く行なってください. 利用するポートの数をタイプします: &prompt.root; cd /dev &prompt.root; ./MAKEDEV ttyAnn cuaAnn (nn はポートの数に置き換えます. login プロンプトにこれらのポート番号を表示させたい場合 は/etc/ttys に以下の行を追加する必要があります: ttyA01 "/usr/libexec/getty std.9600" vt100 on insecure ターミナルタイプは適当なものに変更してください. 例えばモデムの場合はdialup あるいは unknownが適当でしょう. * パラレルカード * モデム * ネットワークカード * キーボード マウス 寄稿: Joel Sutton jsutton@bbcon.com.au, 2000 年 1 月. FreeBSD は PS/2 ポート, シリアルポート, USB ポートを経由して様々な種類のマウスをサポートしています. mouse デーモンを使うとマウスを X とシステムコンソールの両方で利用することができるため, 多くの人は mouse デーモンを使うことを選んでいます. mouse デーモンに関する詳細は, &man.moused.8; を参照してください. この章の例では, mouse デーモンが使われていることを前提にしています. この節に書かれている各種製品の名前は, 著者が FreeBSD 上で 動作することを確認したものであり, ここに書かれていない他の同様のデバイスも動作する可能性があります. PS/2 マウス システム設定 PS/2 マウスが mouse デーモンで正しく機能するように設定するには, 以下の行を /etc/rc.conf に加える必要があります. moused_enable="YES" moused_type="ps/2" moused_port="/dev/psm0" 利用できることが分かっている機器 Logitech First Mouse - 3 ボタン マイクロソフト社製シリアル-PS/2 互換マウス シリアルマウス システム設定 シリアルマウスが mouse デーモンで正しく機能するよう設定するには, 以下の行を /etc/rc.conf に加える必要があります. この例では, マウスが COM1: に接続されていて, そのマウスが mouse デーモンによって自動的に認識されることを前提としています. moused_enable="YES" moused_type="auto" moused_port="/dev/cuaa0" 特定の種類のシリアルマウスで mouse デーモンを使用する設定に関しては, &man.moused.8; にある詳細な説明をご覧ください. 利用できることが分かっている機器 一般的なマイクロソフトマウス互換品 Logitech First Mouse - 3 ボタン マイクロソフト社製シリアル-PS/2 互換マウス USB システム設定 USB デバイスドライバは比較的最近 FreeBSD に追加されたもので, まだ GENERIC カーネルには含まれていません. 以下の手順は, 典型的なシステムで関連するドライバをいかに組み込むかという一例です. ums デバイスをあなたの カーネルコンフィグレーション の usb セクションに追加します. たとえば, 次のようにします. controller usb0 controller uhci0 device ums0 新しいカーネルを 再構築してインストールします. デバイスノード(device node) を作ります. それには, 以下のように入力します: &prompt.root; cd /dev &prompt.root; sh MAKEDEV ums0 以下の内容を /etc/rc.conf に追加し, mouse デーモンが正しく動作するように設定します. moused_enable="YES" moused_type="auto" moused_port="/dev/ums0" システムを再起動します. &prompt.root; shutdown -r now 利用できることが分かっている機器 Logitech TrackMan - Marble Wheel * その他 ]]> 記憶装置 ESDIハードディスクの使い方 原作および Copyright © 1995, &a.wilko;. 24 September 1995. 訳: &a.jp.ts; 2 September 1996. ESDIとは Enhanced Small Device Interfaceの略語です. この技術は, 馴染み 深い ST506や ST412といったインタフェースに基づくものであり, 世界初の普 及型 5.25インチのウィンチェスタディスクを造ったSeagate Technology社に よって最初に作られました. ESDIの Eは拡張 (Enhanced) を表しており, 実際そのとおりです. まず, イン タフェースの速度は速く, 10 ないし 15Mビット/秒であり, ST412インタフェー スに接続したドライブの 5Mビット/秒よりも高速です. また, 上位レベルのコ マンドがいくつか追加されて, オペレーティングシステムレベルのドライバ作 成者にとって, ESDIインタフェースはある程度インテリジェントなものとなり ました. ただし SCSIほどにインテリジェントではありません. ESDIは ANSIが 標準化をおこなっています. トラックごとのセクタ数を増やすことで, ESDIドライブの記憶容量は引き上げ られました. 通常, トラックあたり 35セクタですが, 今までに筆者がみたド ライブの中で大容量のものは, トラックあたり 54セクタもありました. ESDIは IDEや SCSIといったインタフェースの普及によって消えつつあります が, 無料あるいは在庫処分の 格安なドライブが入手可能であることを 考えると, 少ない (もしくは現状の) 予算で縛られたシステムにとって, ESDIドライブは 理想的です. ESDIのコンセプト 物理的な接続 ESDIインタフェースでは, ドライブごとに2つのケーブルを接続します. 第 1 のケーブルは34ピンのフラットケーブルエッジコネクタで, コントローラとド ライブ間のコマンドおよびステータスの 両信号のやりとりのためのものです. コマンド用ケーブルは, すべての ESDIドライブをデイジーチェーンで結び ますから, すべてのドライブを接続したバスを構成することに なります. 第 2 のケーブルは 20 ピンのフラットケーブル エッジコネクタで, ドライブへの データ入出力に使います. このケーブルは放射状に接続しますから, ドライブ ごとにコントローラへの専用接続を持つことに なるわけです. 筆者の経験によれば, PC向け ESDI コントローラには, コントローラあたり最 大 2 台までのデバイス接続が可能という制限がありました. これは, ドライ ブのアドレス割り当てのために, 単一ビットだけを用意したという WD1003 か ら持ち越された互換 (?) 機能なのだと思われます. デバイスのアドレス指定 1本のコマンドケーブルには最大で 7つのデバイスと 1つのコントローラを接 続することができます. どのドライブをコントローラがアドレスしているのか を個別に認識できるようにするために, ESDIデバイスは, デバイスアドレスを 設定するためのジャンパかスイッチを備えています. PC向けコントローラでは, 最初のドライブにはアドレス0を設定し, 第2番目の ディスクへはアドレス1を設定します. いつも留意すべきことは, ディスクごとに固有のアドレスを必ず設定するということです! つまり, コン トローラあたり最大2台のドライブというような PC向けのものでは, 第1 ドラ イブは第0番ドライブで, 第2ドライブは第1番ドライブだということです. ターミネート処理 (termination) デイジーチェーン接続用コマンドケーブル (34ピンのケーブルであることを覚 えていますか? ) では, 最後のチェーン接続ドライブでターミネートしなけれ ばなりません. このために, ESDIドライブにはターミネート用抵抗ネットワー クが付属しており, ターミネートする必要がないときにはその抵抗をドライブ から外したり, またはジャンパで無効 (disable) にすることができるようになっ ています. したがって, ひとつのドライブ, すなわちコマンドケーブルの最終端に位置す るドライブだけが, そのターミネート用抵抗を有効 (installまたは enable) にすることができます. コントローラは自動的にコマンドケーブルのもう一方 の端のターミネート用抵抗を有効にします. ご注意いただきたいのは, コント ローラは必ずコマンドケーブルのいずれかの 端に位置しなければならず, けっ して途中に位置するようにしては いけない ということです. ESDIディスクの FreeBSDでの使い方 ESDI を初めて動かすようにすることが, どうしてこうも大変なことなのでしょ うか ? ESDIディスクを FreeBSD で動かそうと試みた人たちが激烈なイライラを募らせ たことは知られています. 今までまったく ESDIを知らない場合には, 複数の 要因の組み合わせが悪く働いて, ESDIへの理解を妨げることになるかもしれま せん. このことは, ESDIと FreeBSDの組み合わせは選んではいけないという俗説も生 み出しました. 以下の節において, 落し穴のすべてとその解決策を 述べてみようと思います. ESDI速度の違い すでに簡単に紹介したように, ESDIは2種類の速度を持っています. 旧式のド ライブとコントローラは 10Mビット/秒のデータ転送速度ですが, 新しいもの では 15Mビット/秒が利用できます. 仮に 10Mビット/秒のコントローラへ 15Mビット/秒のドライブを接続したよ うな場合に問題が生じることを予想することは簡単です. したがって必ず, コ ントローラ および ドライブのマニュアルを参照して, それぞれの 転送速度が 一致しているかどうかを調べるようにしてください. トラックについて 主流の ESDIドライブは, トラックあたり34ないし36個のセクタを持ちます. しかし大部分の (古い) コントローラは36個以上のセクタを扱うことができま せん. 新しい大容量のドライブでは, トラックごとにさらに多くの数のセクタを持つ ことができます. たとえば筆者の 670MBのドライブは, トラックあたり 54セ クタも持たせることができます. 筆者のコントローラは 54 セクタ数をサポートしていませんでしたが, トラック あたり 35 セクタという設定で, 問題なく動作しました. しかし, これが意味す るのは大量のディスク容量を失うということです. もう一度, 詳しい情報についてハードウェアのドキュメントを 調べてください. この例のような仕様からはずれた設定をしたときには, うまく動くかもしれま せんが, 動かないこともあります. そのようなときには, 別のより多くの機能 をもつコントローラで試してみるようにしてください. ハードセクタとソフトセクタ 多くの ESDIドライブでは, ハードセクタまたはソフトセクタによる処理を, ジャンパ設定で指定することができます. ハードセクタとは, 新しいセクタの 開始位置において, ESDIドライブにセクタパルス (sector pulse) を発生させ ることです. コントローラはこのパルスを利用して, 書き込みや読み取りのタ イミングを指示します. ハードセクタではセクタのサイズを選ぶことができます (通常はフォーマット 後セクタあたり256, 512, および1024バイト). FreeBSDは512バイトのセクタ サイズを使います. トラックあたりのセクタ数は, 同じように選択に幅があり ますが, フォーマット後のセクタのバイト数はすべて同じです. セクタごとの 未フォーマット のバイト数は, コントローラがどの程度の調整用の バイト数を必要とするかによって異なります. トラックあたりのセクタ数を多 くすれば記憶容量は増えますが, もしドライブから与えられるバイト数よりも 多くのものをコントローラが必要とするのであれば, 問題を生じることがあり ます. ソフトセクタでは, コントローラ自身が読み書きの始まりと終りの位置を決め ます. なお, ESDI (筆者が知り得たものすべて) では, ハードセクタがデフォ ルトのようです. ソフトセクタを試みる必要性は感じたことがありません. 通常, FreeBSDをインストールする以前に, まずセクタ処理の設定を試される ことをおすすめします. というのも, セクタ処理の設定を変えるたびに, 物理 フォーマット (low-level format) をしなければならないからです. 物理フォーマット処理 ESDIドライブは, 使い始める前に, 物理フォーマットをおこなう必要があります. もしトラックあたりのセクタ数を変えたり, ドライブの物理的な設置方法 (水 平や垂直方向) を変えたときには, ふたたびフォーマットする必要があります から, よく検討した後でフォーマットしてください. フォーマット処理の所要 時間を短く予想してはいけません. 大容量のディスクでは数時間を要します. 物理フォーマットが終わったならば, サーフィススキャン (surface scan) を おこない, バッドセクタの検出とフラグの処理をします. ほとんどのディスクには, メーカが作成したバッドブロックリストを 記録した用紙またはステッカーが付 いています. さらに, ほとんどのディスク内にもバッドブロックリストが記録 されています. メーカが作成したリストを利用するようにしてください. この 時点で不良部分をマップし直す方が, FreeBSDのインストール後におこなうよりも, はるかに簡単です. 物理フォーマットプログラムのなかでも, トラックの中にひとつでもバッドセ クタがあれば, 同じトラック内の残りのすべてのセクタを不良とするようなプ ログラムがありますから, そのようなものは利用しないようにしてください. ディスクスペースの浪費だけでなく, より重大な bad144と関連した悲劇の原 因にもなるからです (bad144の節を参照のこと). トランスレーション トランスレーションが, ESDIだけに限定された問題ではないにもかかわらず, 重大な困難になることがあります. トランスレーションにはいくつかの側面が あります. 多くに共通なものは, IBM PC/ATのオリジナルの設計に起因するディ スクジオメトリに関する制限を, うまく回避するような調整を試みるものです (IBM に感謝 ! ). まずはじめに, 1024シリンダに関する (悪) 名高い制限があります. すなわ ち, ブート可能なシステムについて, システム関連ファイルは (オペレーティ ングシステムがどのようなものであっても) , ディスクの先頭部分の 1024シ リンダ内になければいけない, という制限です. シリンダ番号を表すためには 10ビットしか与えられていません. セクタの総数については, 上限は 64 (0か ら 63) です. この1024シリンダの制限を, 16ヘッドの制限 (これも ATの仕様 による) と組み合わせると, かなり限定されたディスク容量しか利用できませ ん. この難点を解消するために, PC 向け ESDIコントローラのメーカは, 自社のコ ントローラボードへ BIOS PROM拡張を施しました. この BIOS拡張の内容は, ブート時のディスクI/Oを (OSによっては すべて のディスクI/Oも) , トランスレーションを用いておこなうというものです. すなわち, 大容量のディ スクを, あたかも 32 ヘッドかつトラックあたり 64 セクタであるようなデバイス として OSへ知らせるのです. この結果, 総シリンダー数は 1024よりも少なく なりますから, 上記の難点などなかったものとして大容量ディスクを使うこと ができるようになります. なお, 注目いただきたいことは, FreeBSDカーネル の起動以降, FreeBSDはこの BIOS拡張機能を使わないということです. 詳しく は後ほどご説明いたします. トランスレーションの第 2 の存在理由は, 多くの旧いシステムBIOSが, トラッ クあたり 17 セクタのドライブだけしか扱えない (ST412 という古い仕様) から, というものです. 比較的新しい BIOSは通常, 自由な値を設定できるドライブ タイプ (多くの場合ドライブタイプ47) を持っています. この文書を読み終えられた後で, どのようにトランスレーションを利用す るにせよ, ぜひご留意いただきたいことがあります. もし複数の OSをひとつ のディスクにインストールするときには, 必ず同じトランスレーションを使わ なければなりません. トランスレーションに関して, 筆者が使用したコントローラは, ひとつのドラ イブを複数のパーティションに論理的に 分けることができる機能を BIOS のオ プションとして持っていました (このような製品はいくつかあると思われる). しかし, ひとつのドライブにはひとつのパーティションに限定しました. なぜ なら, このコントローラはパーティション情報を ディスクへ書き出すからです. つまり, 電源を入れると, コントローラはこの情報を読み取り, OSに対してディ スクから読みとった情報に基づくデバイスとして 知らせるからです. 代替セクタ処理 多くの ESDI コントローラはバッドセクタを 取り替える機能を備えています. ディスクの物理フォーマット処理の途中もしくは終了時に, バッドセクタであ ることを記録して, 代わりのセクタを壊れたセクタの位置へ (論理的に) 置き ます. 通常この置き換え処理は, トラック内の N-1 個のセクタを実際のデータ記録に 使い, 第N番目のセクタだけを代替セクタとすることで実現します. ここでNと いう値はトラック内の物理的セクタの総数です. このアイデアが生まれた背景 は, オペレーティングシステムが壊れたセクタを持たない 「完全」 なディスク を想定している, というものです. しかし FreeBSDではこのアイデアを使うこ とはできません. 理由は, 使用不可 (bad) から 使用可能 への変換をおこなう のが ESDIコントローラ上の BIOSだからなのです. FreeBSDは, 真の 32ビット のオペレーティングシステムであるために, ブート後には BIOSを使いません. 代わりに FreeBSDが使うのは, ハードウェアと直接「対話」するデバイスドラ イバというものです. 結論: 代替セクタ処理やバッドブロックマッピングなど, コントローラ・ メーカがなんと呼ぶかは判りませんが, それらに似た機能を FreeBSDのディス クへは使わないでください. バッドブロックの取り扱い 前節から残された問題があります. すなわち, コントローラによるバッドブロッ ク処理は利用できない状況であるにもかかわらず, FreeBSDのファイルシステ ムが想定しているのはあくまで完全無欠なディスクである, という問題で す. これを解消するために, FreeBSDは bad144 というツールを採用 しています. この bad144 (この名前は DEC社の標準となったバッドブロック 処理に由来している) は, FreeBSDのスライスごとにバッドブロックを調べま す. バッドブロックを見つけ出すと, bad144 は傷ついたブロック番号によるテー ブルを FreeBSDスライスの末尾へ書き込みます. ディスクが動作し始めると, ディスクから読みとられたテーブルを基に, ディ スクアクセスを調べます. この bad144 リストに記録されたブロック番号への 要求が起こると, 代わりのブロック (同じく FreeBSDスライスの末尾に位置す る) を使います. このように, bad144 による置換手続きによって 「完全」 なディ スクを FreeBSD ファイルシステムへ提供しているのです. bad144 の使用により陥るかもしれない落し穴があります. まず, ひとつのス ライスには 126 個以上のバッドセクタを持てません. もしドライブに 126 個以上 のバッドセクタがあったときには, 複数の FreeBSD のスライスに分けて, 各ス ライスのバッドセクタが 126 個以下となるようにする必要があります. くれぐ れも, ひとつのトラック内にたったひとつの欠陥セクタが 見つかっただけで, そのトラック内セクタ すべて を傷ついたものとして記録するよう な物理フォーマットプログラムを使わないようにしてください. 簡単にお解り いただけると思いますが, このような物理フォーマットをおこなえば, 126個の制 限は短時間で達成してしまいます. 次に, もしスライスが root ファイルシステムを含んでいるときには, 1024シ リンダ以内という BIOSの制限を守っていなければなりません. ブート処理の ときですから, bad144 リストは BIOS を使って読み取りますので, このリスト が 1024 シリンダ限界以内に位置していなければ読みとれません. この制限は root ファイルシステム だけ が1024シリンダ限界以内にあれば十分ということではなく, rootシステムを含 んだ スライス 全体が1024シリンダ限界以内におさまっている必要 があります. カーネルのコンフィグレーション ESDIディスクを扱うドライバは, IDEや ST412 MFMディスクなどと同じ wd ドライバです. この wd ドライバは, すべての WD1003 互換インタフェースにも利用できるはずです. 大部分のハードウェアは, ジャンパの設定によって, ふたつの I/Oアドレス範 囲と IRQ 値のうちから, それぞれひとつを選ぶことができます. したがって, wd タイプのふたつのコントローラを ひとつのシステムで使うことができます. もし設定しようとしているハードウェアが 標準以外の割り当てをサポートして いれば, 適切な設定情報をカーネルのコンフィグレーションファイルに 記述す ることで, この非標準割り当てを利用できます. 次にカーネルのコンフィグレー ションファイルの例を示します (このファイルがあるディレクトリは /sys/i386/conf である). # First WD compatible controller controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr disk wd0 at wdc0 drive 0 disk wd1 at wdc0 drive 1 # Second WD compatible controller controller wdc1 at isa? port "IO_WD2" bio irq 15 vector wdintr disk wd2 at wdc1 drive 0 disk wd3 at wdc1 drive 1 ESDIハードウェアの例 Adaptec 2320コントローラ 筆者は, ACB-2320でコントロールされた ESDIディスクへ, FreeBSDをインストー ルすることができました. なお, このディスクには他のオペレーティングシス テムをインストールしていません. インストールするために, まず, NEFMT.EXE (www.adaptec.com から ftp可能) でディスクを物理フォーマットし, かつトラックを代替セ クタとともにフォーマットするかどうかの設問に NOと答えました. また ACB-2320の BIOSは使わないように設定しました. そしてシステム BIOSがブー トできるように, システム BIOSの自由に設定可能 オプションを使いまし た. 実は, NEFMT.EXEを使う以前に, まず ACB-2320 の BIOSに組み込まれているフォー マットプログラムでディスクをフォーマットしてみましたが, 使えないことが 判りました. なぜなら, 代替セクタの処理をおこなわないようにするオプションが 用意されていないからです. 代替セクタ処理をおこなうようにすると, FreeBSDの インストール作業は bad144の実行の段階で失敗しました. もし ACB-232xy をお持ちであれば, そのバージョン番号に注意してください. 文字 x には 0 か 2 が入りまして, ボード上にフロッピーコントローラがあるかど うかを見分けることができます. 文字 yはさらに興味深いもので, ブランクか, A-8か, または Dのいずれかで す. ブランクは, 単純な10Mビット/秒のコントローラであることを表します. A-8は, 15Mビット/秒のコントローラで, かつ 52セクタ/トラックをサポート しているものであることを表します. Dは, 15Mビット/秒のコントローラで, かつ 36セクタ/トラック以上 (52セクタも可能か?) のドライブをサポートし ているものであることを表します. このコントローラのすべてのバージョンはインターリーブ比 1:1に対応してい るはずです. FreeBSDは充分高速なので, ぜひ 1:1と指定してください. Western Digital WD1007コントローラ 筆者は, WD1007でコントロールされた ESDIディスクへ, FreeBSDをインストー ルすることができました. 正確には WD1007-WA2というコントローラでした. これ以外の複数のバージョンも WD1007にあります. 利用できるようにするために, セクタトランスレーションとWD1007の BIOSと を使わないように設定しました. この設定の意味は, BIOSに組み込まれた物理 フォーマットプログラムを使えないようにしたということです. 代わりに, www.wdc.comから WDFMT.EXEを入手して, ディスクをフォーマットし ました. 以後, 順調に動いています. Ultrastor U14Fコントローラ ネットに流れたいくつかの報告によれば, Ultrastorの ESDIボードも FreeBSD で動作するようです. 実際の設定についての詳しい情報はありません. 追加資料 本格的に ESDIのプログラミングを計画している方は, 次の公式規格仕様書を 入手なさることをおすすめします. 最新の ANSI X3T10 委員会の文書は次のものです： Enhanced Small Device Interface (ESDI) [X3.170-1990/X3.170a-1991] [X3T10/792D Rev 11] USENETのニュースグループ comp.periphs は, 詳しい情報を得ることができる注目すべきもので す. World Wide Web (WWW) もまた便利な情報源です. Adaptec社の ESDIコントロー ラについては http://www.adaptec.com/ を参照ください. Western Digital 社のコントローラについては http://www.wdc.com/ を参照ください. 感謝 Andrew Gordon氏より, テスト用の Adaptec 2320コントローラと ESDIディス クを送っていただきました. SCSIとは? 原作:&a.wilko;. July 6, 1996. 訳: &a.jp.yoshiaki;. 4 November 1996. SCSI は Small Computer Systems Interface (小規模コンピュータシステムインタフェース) の頭文字をとったものです. これは ANSI 規格の一つであり, コンピュータ業界において最もよく使われる I/O バスの一つになっています. SCSI はシュガート社 (ミニフロッピーディ スクを世界で最初に販売しました) の開発した SASI (Shugart Associates Standard Interface) バスを元に規格化されました. その後の業界の努力により, 異なるベンダのデバイスが混在して使えるよう, より厳密な規格へと規格化されました. その結果, 認可されたのが ANSI の SCSI-1 規格です. SCSI-1 仕様の規格化が行なわれたのは 1985 年前後です. (訳注: SCSI-1 の最終案決定は 1985 年, ANSI の標準規格としての認可は 1986 年です) この規格は, すでに現在では時代遅れのものになっており, 現在の標準は SCSI-2 (さらに詳しい情報 を参照してください) で, これもまもなく SCSI-3 へ移行していくでしょう. 物理的な相互接続の規格に加えて, SCSIではディスクドライブに不可欠な論理的な規格 (コマンドセット) も定義しています. この規格は標準コマンドセット (CCS; Common Command Set) と呼ばれ, ANSI の SCSI-1 とほぼ同時期に制定されました. SCSI-2 には (改定された) CCS が規格の一部として組み込まれました. コマンドは, デバイスの種類によって変わります. たとえばスキャナにおいて, Write コマンドは意味がありません. SCSI バスは多くの種類があるパラレルバスです. 最も古く, 最も利用されているのが 8 bit 幅, シングルエンド (不平衡) 信号, 50線の信号線のバスです (もしシングルエンドの意味が分からなくても気にすることはありません. この文書は, まさにそのような人たちのために書かれているからです). より新しい設計では 16bit 幅で平衡信号のバスを使います. この場合, 転送速度は 20Mbytes/second まで, ケーブルの長さは 25m まで可能です. SCSI-2では追加のケーブルを使った最大 32bit のバス幅までが定義されています. 最近急速に増えているものに Ultra SCSI (Fast-20 とも呼ばれます) があります. また, SCSI-2には Ultra2 (Fast-40 とも呼ばれます) というものも定義されています. Fast-20 は 1 秒間に 2000 万回の転送 (8bit バスで 20Mbytes/sec), Fast-40 は 1 秒間に 4000 万回の転送 (8bit バスで 40Mbytes/sec) を行ないます. 最近売られているハードディスクのほとんどは, 不平衡信号の Ultra SCSI (8bit または 16bit) です. 訳注: ここでは電気的な用語としては平衡, 不平衡を用いて, バスの名称としては基本的にはシングルエンド, ディファレンシャルとしました. もちろん SCSI バスにはデータ信号だけではなく, 多くのコントロール信号線があります. 複数のデバイスがバスを効率よく共有するための 複雑なプロトコルも規格の一部です. SCSI-2 ではデータは常に独立したパリティ信号を使ってチェックされます. SCSI-2 以前では, パリティチェックはオプションでした. SCSI-3 ではさらに高速なバスタイプが導入され, それと共にケーブルの線数を減らし, より最大バス長を伸ばしたシリアル SCSI が導入されます. SSA や Fiberchannelといった名前を聞いたことはありませんか? シリアルバスは現在では, まだいずれの方式も普及していません (特に一般的な FreeBSD 環境では). このためシリアルバスタイプについては, ここではこれ以上は触れません. 今までの記述から想像されるように, SCSI デバイスはインテリジェントです. これは SCSIの規格 (この文書は 2 インチ以上の厚さがあります) と切り離すことはできません. このため, たとえばハードディスクでは特定のブロックを指す場合は, ヘッド / シリンダ / セクタによって決めるのではなく, 単に必要なブロック番号を指定します. 巧妙なキャッシュ動作や, 不正ブロックの自動置き換えなどの機能は, この「インテリジェントデバイス」のアプローチによって可能になっています. SCSI バスでは任意のデバイスの組で通信することが可能です (訳注: 任意のデバイスがイニシエータになれるという意味です). デバイスの機能がそれを許すかどうかはまた別の問題ですが, 規格では禁止されていません. その場合は信号の衝突を防ぐために, 2 つのデバイスがバスを使う前に調停 (arbitrate) を行なう必要があります. SCSI では, 古い規格のデバイスと新しい規格のデバイスが 同じバスの上で動くように規格を作っています. したがって, 古い SCSI-1の デバイスは SCSI-2 バス上でも普通は動きます. 普通は, と断った理由は, ある古いデバイスが (古い) 規格に対して, 新しいバスでも問題ない程に十分規格に準拠した実装になっているかどうかを 絶対的に保証することはできない, ということです. 一般に, 最近のデバイスはよりうまく動作します. その理由は規格化がより厳密になり, またメーカーがデバイスの製造において, よりきちんと規格に従うようになってきているからです. 一般的に言って, 単一のバス上で動かすデバイスは SCSI-2 あるいはより新しいデバイスであれば うまく動く可能性は高いと言えます. これは新しい 2GBのディスクを手に入れたとしたら 古いデバイスを捨ててしまわなければならないという 意味ではありません. 私のシステムでは SCSI-1以前のディスク, SCSI-2の QICテープユニット, SCSI-1のヘリカルスキャンテープユニット (訳注: VTRのような回転ヘッドを 持ったテープ装置のことです. DATテープドライブもその一つです), 2台の SCSI-1 ディスクが一緒に問題なく動いています. ただし効率の点から古いデバイスと新しい (= 速い) デバイスを分けたいかもしれません. (訳注: 古いデバイスの中には disconnectをサポートしないために一連のコマンド実行中に SCSIバスを占有してしまうデバイスもあります.) SCSI の構成要素 先に述べたように, SCSI デバイスはインテリジェントです. つまりハードウェア細部にからむ知識は SCSI デバイス自身が 持っています. そのためホストシステムは, あるハードディスクがいくつのヘッドを持っているのかとか, 指定したテープデバイスがいくつのトラックを持つか, というようなことを知る必要はありません. もしあなたが知りたいのであれば, 規格で定義されているコマンドを使って, デバイスにハードウェアの詳細について問い合わせることができます. インテリジェントデバイスの利点は明らかです. ホストのデバイスドライバはより一般的に書くことができ, 新しいデバイスを導入する場合でも変更の必要がありません. 接続でおこなうべきこと, してはならないこと ケーブルの接続には鉄則があります. よい部品を使うことです. バスの速度を上げることができ, 多くの災難を防ぐことができます. ですから, 金メッキのコネクタ, シールドケーブル, 固定器具付きの頑丈なコネクタカバーなどを 選ぶのは正しいことです. 2つ目の鉄則は, ケーブルを必要以上に長くしないことです. 私は以前にあるマシンでトラブルの 原因を探すのに 3日間悩んでいましたが, SCSIバスを 1m 短く することで問題を解決したことがあります. もちろん, 元のバスの長さでもSCSIの仕様はきちんと 満たしていたのですが. SCSI バスのタイプ 電気的に互換性のない 2種類のバスのタイプがあります. シングルエンドとディファレンシャルのバスです. これは SCSI デバイスとコントローラは同一のバス上に混在することのできない 2つのグループにに大きく分けられるということを意味しています. しかし, 特別なハードウェアを使えばシングルエンドバスを ディファレンシャルバスに (その逆も) 変換することはできます. これらのバスのタイプの違いは次のセクションで説明します. SCSI関連のドキュメントでは 異なるタイプのバスを一種の用語とし て略語で表します. これを次の表に示します. FWD: Fast Wide Differential (高速 ワイド 平衡) FND: Fast Narrow Differential (高速 ナロー 平衡) SE: Single Ended (不平衡) FN: Fast Narrow (高速 ナロー) etc. 少し想像力を働かせればどのような 意味であるかはわかるでしょう. ワイド (Wide) はいくらか曖昧で, 16 または 32 bitのバスを示します. 私の知る限りでは, 32 bit のインタフェースは (まだ) 使われていませんので Wide は通常 16 bitを意味します. 高速 (Fast) はバスのタイミングがいくつかの点で異なり, ナロー (8 bit) バスでは 低速 (slow) SCSIバスの 5 Mbytes/sec に対して 10 Mbytes/sec の能力があります. 前にも述べたように, 20Mbytes/sec や 40Mbytes/sec のバス速度を持つものも現れてきています (Fast-20 == Ultra SCSI で Fast-40 == Ultra2 SCSI です). データ線の上位 (> 8) はデータの転送とデバイスの指定だけに利用されています. コマンドの送出とステータスメッセージ等は下位側の 8 bitのデータ線のみを使います. この規格により ナローデバイスはワイドバス上でも 動作する事ができます. 利用できるバスの幅はデバイス間で調停 (ネゴシエーション) されます. デバイスの IDについてはワイドとナローが混在する時には 気をつけなければなりません. シングルエンドバス (不平衡バス) シングルエンド SCSIバスは 5Vと 0Vの電圧 (つまりTTLレベルです) を信号として使い, それらは共通のグラウンド (GND) レベルを基準 にします. シングルエンド SCSI 8 bitバスは約25本のグラウンド線 を持ち, すべてのデバイスを「直線状」に接続します. 基準ではシングルエンドバスは最大の長さは 6mです. Fast-SCSI デバイスを使う場合には, この最大長さは 3mに短くなります. Fast-SCSIでは 5Mbytes/sec ではなく 10Mbytes/sec の転送速度 が可能になります. Fast-20 (Ultra SCSI) と Fast-40ではそれぞれ1秒間に2000万 (20M) ないしは 4000万 (40M) 回の転送ができます. したがって, Fast-20では 8bitバスで 20Mbytes/sec, 16bitバスで 40Mbytes/secとなりま す. Fast-20ではバスの最大の長さは 1.5m, Fast-40では 0.75mに なります. Fast-20は限界を相当に広げるものなので SCSIバス に雑音が多い場合はその影響を即座に受けます. バス上のいずれかのデバイスが 「高速の」 転送を利用する場合は Fastバスの長さの制限を受けます. 最近の Fast-SCSI デバイスではバスの長さが実際の問題に なりつつあるのが明らかになっています. これがディファレンシャル SCSIバスがSCSI-2の規格に導入された理由です. コネクタのピン配置やコネクタの種類については SCSI-2の規格 (さらに詳しい情報) を参照してください.コネクタ等について 詳細なリストがあります. 非標準のケーブルを使うデバイスに気をつけてください. 例えば Apple (の Macintosh は) 25pin の D-type のコネクタ (シリアルポートやパラレルプリンタに使われているコネクタ -- 訳注: 日本では一般的に D-sub 25pinと言っています) を使っています. 公式なSCSIバスでは50 pin が必要である事からこのコネクタでは 「独創的なピン配置」が必要な事が想像できるでしょう. ここ でおこなわれているようにグラウンド線の数を 減らすことはよい考え ではありません. SCSIの規格通りの 50 pinの接続の方が望まし いです. Fast-20 や 40 でこのようなケーブルを使おうなんて 考えてはいけません. ディファレンシャル (平衡) バス ディファレンシャル SCSIバスは最大長が 25m です. シングルエンド Fast-SCSIバスの 3mとはまったく違います. 平衡信号の背景と なっている考え方は, それぞれのバスの信号はそれぞれ 独立したリターン信号線を持つというものです. つまり, それぞれの信号は (できればより線の) ペアの信号線で 伝えられます. これら2つの信号線の差分の電圧で信号が「真」(assert) で あるか「偽」(de-assert) であるか判定されます. かなりの電圧 がグラウンド電位と信号線ペアの間にかかったとしても影響があ りません (だからといって 10kVの電圧をかけてみたりしないで ください.. ). なぜ平衡信号が よいのかについての説明は このドキュメントの 範囲を越えています. 電気的に平衡信号はノイズマージンの点で 非常に優れたものとして利用されているということを 受け入れて ください. ディファレンシャルバスは普通は外部接続に 利用されています. これは低コストのシングルエンドバスが筐体内の短 い距離のバスでは非常に多く利用されているからです. FreeBSDを使うにおいて, FreeBSD でサポートされている デバイスドライバがあるのであれば ディファレンシャルバスの利用で 問題になることは 何もありません. 例をあげれば, アダプテックの AHA1740はシングルエンドで, AHA1744はディファレンシャルです. 双方のソフトウェアインタフェースはまったく同一です. ターミネータ SCSIにおける用語でのターミネータとはインピーダンスの マッチングを正確におこなうための抵抗ネットワークです. インピーダンス マッチングは反射やリンギングを抑え, バスの信号をきれいにす る重要なものです. たとえば, あまり状態のよくない回線で長距 離の電話をかけた時にあなたは反射をどんなものか 感じるかもしれません. 20Mbytes/sec で信号の伝わる SCSIバスでは信号のエコーはありがたくありません. 訳注: 電気信号のパルスは進行波としての性格を持っています. このため, 一般的には信号線の両端で反射が起きます. 3mのバスの端からパルスを入れた場合, 反対の端からの反射波は 20ns後 - 本当は電線中の信号の伝達は 光速よりも少し遅くなるのでもう少し時間がかかりますが - に返ってきます. 低速のバスの場合タイミング的な余裕があり, 反射を繰り返しているうちに反射波は減衰してしまうのですが 高速のバスの場合は, 反射波の影響が落ち着く前に信号の 読み込みなどを行うために波形の乱れが誤動作の原因に なる場合があります. このためターミネータを使用して反射波の発生をできるだけ おさえます. ターミネータはいろいろな - 洗練されたものもそうでないものも - 実現方法があります. もちろん, 内蔵のものと外部という区別もあります. 多くの SCSIデバイスにはいくつかのソケットがあり, その中には抵抗ネットワーク (集合抵抗) が 入っているものもあるかもしれません (いや, おそらく 間違いなくあるでしょう). ターミネータを デバイスから外す時は大事にしまっておいてください. SCSIの接 続の変更をしようと思った時に必要になるかもしれません. ま た, それらしい抵抗ネットワークが見つからないこともあります. この場合, SCSIデバイスは内蔵ターミネータの有効と無効を切替 えるジャンパがあります. フラットケーブルに取り付ける特別 なターミネータもあります. 他には外部コネクタのような形をし たものやケーブルのないコネクタヘッドだけのものもあります. いろいろと見られるように多くの選択があります. どのような場合に単純な抵抗 (パッシブ) ターミネータから アクティブターミネータへ切替えるかという問題があります. アクティブターミネータはいくらか精巧な回路が信号をより きれいにするために入っています. 一般的に受け入れられている意見としては, 長いバスを使ったり 高速なデバイスを使う場合はアクティブターミネータの 有効性は増加すると言えます. SCSI バスですでに問題が起きて いるならアクティブターミネータを試すことを考えていいで しょう. まず借りることができないか探してみてください. アクティブターミネータは非常に高価だそうですから. ディファレンシャルと シングルエンドバスのターミネータは互換 性がないということを覚えておいてください. これらの2つの種 類を 混在させることはできません. OK, ではあなたは ターミネータをどこに入れればいいでしょうか? これは SCSIで最も多く誤解されているところです. しかし, これ は極めて単純なことです.. ここでのルールは SCSIバスの線 一本一本は必ず両端に 2個のターミネータを入れる ということです. つまり 2個であって1個でも3個でもありません. このルールを受け入れてしたがってください. そうすれば終りの ない苦しみから救われるでしょう. なぜなら間違ったターミネーションは不可解なバグを引き起こす 可能性が非常に高いからです. (ここの 可能性 に注意; 一見動いているように見える ことがあるのがやっかいです.) よく陥りやすい落し穴はマシンの内部 (フラット) ケーブルと外部 ケーブルがコントローラにつながっている場合です. よく見られ るのはコントローラのターミネータを外すのを忘れることです. ターミネータは最後の外部デバイスで必要で, コントローラ には必要ありません! 一般的に, SCSIバスの接続の変更をする場 合はこのようなことに注意をしなければなりません. ターミネータの位置は 信号線ごとに決まることに注意して下さい. ナローとワイドのケーブルを 両方コントローラにつないでいる場 合には, ケーブルの両端とともにコントローラ上ではバスの上位 8ビットをターミネートしないといけません. 私自身は, すべてのデバイスとコントローラのターミネータを外し ています. 2個の外部ターミネータをセントロニクスタイプ (訳注: 日本ではケーブルに対してこういう言い方は あまりしないのでは ないでしょうか) 外部ケーブルと内部フラットケーブルの コネクタの両端に接続しています. こうすることにより接続の変更はかなり簡単になります. 最近のデバイスは, ICターミネータが使われることもあります. コントロールピンにより無効 / 有効を設定できる 特別の IC があります. これは物理的にデバイスから外す必要がありません. 新しいホストアダプタではセットアップツール等を使って ソフトウェア的に設定をおこなう場合があります. また, 中には端子に接続されたケーブルを検出して ターミネータ を必要に応じて自動的に 有効にするものもあります. いずれにしろ, マニュアルを見てく ださい. ターミネータの電源 ここまでの章で議論したターミネータは 正常に動作するためには 電源が必要です. SCSIバス上にはこの目的のために利用される線があります. だから特に気にする必要はないと思いますか? ところがそうではないのです. それぞれのデバイスはデバイス上 にあるターミネータソケットに電源を供給することはできます. けれども外部ターミネータがある場合やSCSIバスにターミネータ の電源を供給するデバイスのスイッチがオフになっているような 場合にはトラブルが起きるかもしれません. イニシエータ (ここではバスの動作を開始-initiate-させる デバイスを指します -- 訳注: 簡単に言えばホスト側のアダプタですがSCSIの 規格によれば, 例えばディスク側がコマンドを発行するような システムがあってもかまわないことになっているので こういう言い方をしています) は ターミネータ電源を供給しなければなりません. すべてのSCSIデバイスはターミネータの電源を供給することが できます (必ずしも供給しなければならないというわけ ではありません). スイッチがオフになっているデバイスが バス上に存在することを 許すために, ターミネータの電源はダイオードを通して供給され なければなりません. これはスイッチを切ったデバイスに電流 が逆流することを防ぐためです. 最悪の事態を避けるために, ターミネータの電源は普通はヒューズが入っています. 当然ヒューズは飛ぶかもしれません. この 場合でもバスが機能停止するとは限りません. 複数のデバイスが ターミネータの電源を供給しているのであれば, ヒューズが一つ 飛んでも全体の機能には影響しません. ただ一つの供給線の ヒューズが飛んだのであれば確かに問題になるでしょう. 外部ターミネータによっては LED でターミネータ電源 が与えられていることを示すものもあります. 最新の設計ではある程度の時間がたつと 「リセット」され 自動復帰するヒューズが使われることもあります. デバイス アドレッシング SCSIバスでは接続された異なるデバイスを区別して指定 できなければなりません. これには SCSIではターゲットIDが使われます. それぞれのデバイ スは特定のターゲットIDを持ちます. デバイスの IDはジャンパや DIPスイッチなどで設定できます. ブート時のメニューからIDを 変更できるようになっているコントローラもあります. (また, IDを 7から変えることができないコントローラもあります.) より詳しい情報はデバイスのマニュアルを見てください. 複数のデバイスを使う場合は IDの重複に気をつけてください. 重複すると普通は混乱状態になります. 同じ IDを共有している デバイスのうちの一つがI/Oリクエストに答えられたりすると 非常にやっかいなことになります. 8 bitバスでは, 最大8台のターゲットまで可能です. 最大8台で ある理由は, バスの8本のデータ線がデバイスの選択に使われる からです. ワイドなバスでは使えるデバイスの数は増えます (通常は16になるわけです). ナロー SCSI デバイスは 8 以上のターゲット ID を持つデバイスとは 通信できないことに注意してください. ですから, コントローラ のターゲットIDを8以上にするのはあまりいい考えとは いえません (CDROMが使えなくなったりします). 同時にバス使用の要求が発生した場合, 最も IDの大きいデバイス が優先されるという調停がおこなわれます. このことは SCSIホストアダプタの IDは通常7番が使われる理由でもあり ます. ただし, ワイドバスでは下位8ビットが上位8ビットより優 先度が高いことに注意してください. つまり, ワイドSCSIのシス テムではターゲットIDの優先度は高い順に [7 6 .. 1 0 15 14 .. 9 8] となります. (どうして下位8ビットの方が優先度が高いかは, 一つ前の段落を読んで考えてみて下さい.) さらにサブユニットとして, 規格では ロジカルユニット, 短縮形で LUNを持つことができます. 一つのターゲットIDが複数の LUNを 持つことができます. 例えば, テープチェンジャを持つテープ ドライブは LUN 0をテープドライブ自身, LUN 1を テープチェンジャ に与えることができます. このようにして, ホストシステムはテープチェンジャの目的の テープユニットの部分を指定することができます. バスの形状 SCSIバスは直線状です. つまり, Y接続, スター接続, 円形, クモの巣状の接続などの直線以外の接続ではありません. 初心者が よくやる間違いとしてはワイドSCSIのコントローラの端子3つと もにケーブルをつないでしまうというものがあります. (外部, 内部ナロー, 内部ワイド.) よほど運がよければこんなトポロジー でもちゃんと動くように見えるかもしれませんが, えてしてこう いうシステムは一番大切な時に使えなくなったりするものです (これをマーフィーの法則といいます). 先に議論したターミネータの問題は直線状以外の場合では より困難になるだろうということに注意してください. また, 内部バス用の ケーブルの端子の数よりデバイスの 数の方が少ない場合には, 必ず両端の端子にはデバイスをつなぐようにしてください. 内側の端子を使ってケーブルの端を余らせておくと, ターミネータの効果が半減します. 電気的特性はそのノイズマージンや全体の信頼性において, 直線状のバスのルールに強く依存しています. 直線状バスであるというルールに したがってください! FreeBSD で SCSIを使う トランスレーション, BIOS, そしてマジック... まず始める前に, 電気的に問題のないバスであるか調べておいてく ださい. SCSIディスクをPCでブートディスクとして使う場合に, PC BIOSに 関する気まぐれについて知っておく必要があります. PC BIOSは ハードディスクへの低レベル物理インタフェースを 利用するように 実現されています. したがって, BIOSに (セットアップツールやBIOSビルトイン セットアップを使って) ディスクの物理パラメタを教えてやる 必要があります. これはヘッドの数, シリンダの数, トラックあたりのセクタなどがあり, プリコンペンセーションや書き込み電流を 減少させるトラック, などのあまりよく知られていないものもあります. SCSIディスクはこれらのことをユーザは 気にする必要がないはず だと考えるかもしれません. しかし, 不思議なことに (これらの項 目の) セットアップはいまだにあるのです. システム BIOSはブート 時にFreeBSDのカーネルを読み込むためにSCSIディスクに /ヘッド/シリンダ/セクタ を指定する方法でアクセスするため, パラメタを知る必要があるのです. AT/EISA/PCIバスなどにあり, ディスクに接続される SCSIホストアダプタや SCSIコントローラは それ自身のオンボードBIOSを持っています. システムの起動時に, SCSI BIOSは システムBIOSのハードディスクの インタフェースルーチンを乗っ取ります. システムBIOSをごまかすために システムセットアップでは普通は `No hard disk' とします. 簡単ですね? 訳注: BIOS で `No hard disk' という設定をおこなうのは SCSI ドライブから直接起動させるためのテクニックです. 現在のマザーボードでは SCSI ドライブから起動させるための オプションを持つ BIOS を使用しているものもあります. また, ブートセレクタを使って IDEドライブのブートブロックから SCSIドライブ上の FreeBSDをブートすることもできます. SCSI BIOS はドライブの トランスレーション と呼ばれる 機能を持ちます. これはPCがブートするために作られたドライブテー ブルをごまかすものです. このトランスレーションは多くは (すべての場合ではありません) トラックあたり64あるいは32個のヘッドを 持つ仮想的なドライブを使います. シリンダの数を変更することで SCSI BIOS は実際のドライブのサイズに適合させます. 総セクタ数 を 32 * 64 / 2 で割った結果がメガバイト単位のドライブのサイズ になります. 2で割っているのは, 通常 512バイトのサイズの セクタを kByte 単位に変換するためです. ではこれですべてうまくいくのでしょうか. いいえ, そういう訳で はありません. ブート可能なハードディスクのシリンダ数は 1024よ り多くすることはできないのです. トランスレーションを使った 場合でもディスクの 1GB以上の領域は見えません. ディスクの容量 がどんどん増加していくにつれこれは問題になってきました. 幸いにして, 単純な解決方法があります. 単に別のトランスレーショ ンを使えばよいのです. 例えば, 32個に代わり, 128個のヘッドを使います. ほとんどの場合, 古いSCSIホストアダプタをアップグレードす るための新しいバージョンの SCSI BIOS が用意されています. 新しいアダプタではジャンパ やセットアップソフトによって SCSI BIOSの使う トランスレーションを選択できる物もあります. ここで非常に重要なことは, ディスク上のすべての オペレーティングシステムが 同一のトランスレーションを使って 正しいパーティションを得ることです. つまり FreeBSDをインストールする時に, ヘッド/シリンダなどについての 質問にあなたのホストアダプタが 使用しているトランスレートされた 値を使わなくてはなりません. トランスレーションに関する失敗でよく見られるものは, ブートしないシステムができたり, 他のパーティションを 上書きしてしまうことです. すべてのシステムが見えるように fdiskを使うべきです. あなたはデバイスについて これとは食い違った話を聞いたことが あるかもしれません. 古い FreeBSDのカーネルはブートする時に SCSI ディスクのジオメトリ情報を報告していました. 私のシステムの一つの例を示しましょう. aha0 targ 0 lun 0: <MICROP 1588-15MB1057404HSP4> sd0: 636MB (1303250 total sec), 1632 cyl, 15 head, 53 sec, bytes/sec 512 最近のカーネルは, 普通はこのような情報を報告しません. たとえば, このようになっています. (bt0:0:0): "SEAGATE ST41651 7574" type 0 fixed SCSI 2 sd0(bt0:0:0): Direct-Access 1350MB (2766300 512 byte sectors) なぜこのように変わったのでしょう? この情報は SCSIディスク自身から得られます. 最近のディスクで はよくゾーンビット記録方式 (zone bit recording) という 技術が使われています. これはドライブの外側のシリンダは 内側よりもスペースが広いのでトラックあたりのセクタ数を 増やすことができるというアイディアです. この結果, 外側のシリンダ上のトラックの容量は内側の シリンダよりも大きくなり, 全体ではより大きな容量となります. この場合, ドライブのジオメトリについての報告は, 最善のものかどうか疑わしく, ほとんどの場合誤解を招くものであ ることがわかるでしょう. ジオメトリを調べる場合, ほとんどの場合は BIOSの用い ている値を与える方がよい結果となり, BIOSがそのディスクに ついてまったく関知しないのであれば (例えばブートディスクで はないなら) 都合のよい仮想のジオメトリを与えればいいでしょう. SCSI サブシステムの設計 FreeBSDでは階層的な SCSIサブシステムを用いています. それぞれ 異なるコントローラカードの デバイスドライバが書かれています. このドライバはコントローラのハードウェアの 詳細を知っています. ドライバは SCSIサブシステムのより上位の階層のコマンドを受け取り, ステータスを報告するインタフェースを持ちます. カードのドライバの最上位には, デバイスのクラスのための いくつかの一般的なドライバがあります. 具体的にいうと, テープドライブのためのドライバ (略号は: st), 磁気ディスク (sd), CDROM (cd) などです. これらのソースコードは /sys/scsiにあります. マニュアルページ (man) のセクション 4 にはより詳しい内容が あるので見てください. 多階層の設計は低レベルとより高位の レベルを分離させることが できます. 新たに他の種類のハードウェアのサポートを加えることを より処理しやすい問題にします. カーネルコンフィグレーション あなたのハードウェア構成にしたがって, カーネルの コンフィグファイルに ホストアダプタについて 1行あるいは数行程度の記述をする 必要があります. これには I/O アドレスや割り込みなどについての内容も 含みます. あなたのアダプタのドライバについてのマニュアルページ にはより多くの情報があるのでよく読んでください. これとは別に /sys/i386/conf/LINT にはカーネルコンフィグファイルについての 概要があります. LINT には一般的なものについては可能なすべての オプションが含まれています. ただし, LINT では実際に動作するカーネルを作ることは できません. 当然のことを言うようで恐縮ですが, カーネルコンフィグファイルは実際のハードウェア構成を 反映すべきです. そのように割り込みやI/Oアドレス等に 合わせてカーネルコンフィグファイルを書か なければなりません. システムのブート時のメッセージは実際に 見つけたハードウェアの設定を表示します. ほとんどの EISA/PCI 用のドライバ (具体的には ahb, ahc, ncr と amdです) はブート時にコントローラから直接パラメータ を読みこみます. これらについては, 何も引数をつ けずにただ controller ahc0 のように書けば大丈夫で す. 例として FreeBSD 2.2.5-Releaseのいくつかのコメント ([]の中) をつけた LINT カーネルコンフィグファイルを示 します. # SCSI host adapters: `aha', `ahb', `aic', `bt', `nca' # # aha: Adaptec 154x # ahb: Adaptec 174x # ahc: Adaptec 274x/284x/294x # aic: Adaptec 152x and sound cards using the Adaptec AIC-6360 (slow!) # amd: AMD 53c974 based SCSI cards (e.g., Tekram DC-390 and 390T) # bt: Most Buslogic controllers # nca: ProAudioSpectrum cards using the NCR 5380 or Trantor T130 # ncr: NCR/Symbios 53c810/815/825/875 etc based SCSI cards # uha: UltraStore 14F and 34F # sea: Seagate ST01/02 8 bit controller (slow!) # wds: Western Digital WD7000 controller (no scatter/gather!). # [ Adaptec AHA274x/284x/294x/394x などのコントローラ] controller ahc0 [ NCR/Symbios 53c875 コントローラ] controller ncr0 [Ultrastor アダプタ] controller uha0 at isa? port "IO_UHA0" bio irq ? drq 5 vector uhaintr # Map SCSI buses to specific SCSI adapters controller scbus0 at ahc0 controller scbus2 at ncr0 controller scbus1 at uha0 # The actual SCSI devices disk sd0 at scbus0 target 0 unit 0 [SCSI ディスク 0 は scbus 0, LUN 0] disk sd1 at scbus0 target 1 [unit を省略すると暗黙で LUN 0] disk sd2 at scbus1 target 3 [uha0 上の SCSIディスク] disk sd3 at scbus2 target 4 [ncr0 上の SCSIディスク] tape st1 at scbus0 target 6 [SCSI テープ は ターゲット (ID)6] device cd0 at scbus? [最初に見つけた CDROM, 固定にしない] 上の例では カーネルは ahc (Adaptec 274x) コントローラをまず探し, その次に NCR/Symbios のボードというように順番に探して 行きます. その下の行の controller の記述ではデバイスの詳細 を記述して, 対応するバスでターゲット ID と LUN が指定された ものと一致する場合だけ 認識するようにカーネルに 伝えています. 固定された (Wired down) デバイスは 最初にユニット番号が 与えられるので, 固定されていないデバイスは同じ種類の 固定されたユニット 番号の最も大きい番号の1つ上の番号から割り当てられます. したがって, ターゲットID 2の SCSIテープを加えると, ターゲットID 6 のテープがユニット番号1に固定されているので, それはst2に設定 されるでしょう. ブート時に見つからなくても固定されたデバ イスにはユニット番号が常に割り当てられます. 固定のデバイスに 割り当てられたユニット番号は, もしそのデバイスのスイッチが ブート時に切られていてもそのデバイスに リザーブされています. これは, 電源を入れて接続した時のユニット番号が与えられます. デバイスのユニット番号は SCSIバスのターゲットID とは 何の関係もない ことに注意してください. 下の例は FreeBSD のバージョン 2.0.5 以前の カーネルコンフィ グファイルです. 最初の例との違いはデバイスの固定 (wired down) がないことです. 固定 によりどのSCSIターゲットをどの デバイスに割り当てるかを記述できるようになりました. 下のコンフィグファイルにより 構築されたカーネルでは最初に見つ けた SCSIディスクが sd0になり, 次に見つけたディスクが sd1に, という具合に割り当てられます. もしディスクの削除や追加をおこなう と, 他の同じタイプのデバイス (この場合はディスク) のすべてが 「移動して」しまうかもしれません. これによりそのたびに /etc/fstab を変更する必要があります. 古いスタイルでも動きますが, 新しいスタイルを使うことが強 く 推奨されています. これにより SCSIバスのハードウェアを どのように変更した場合でもトラブルを避けることができます. ですから, 2.0.5.R以前の FreeBSDからアップグレードした後に古い 信頼できるコンフィグファイルを再利用する時はこの部分を チェックして直してください. [Adaptec 174x用のドライバ] controller ahb0 at isa? bio irq 11 vector ahbintr [Adaptec 154x用のドライバ ] controller aha0 at isa? port "IO_AHA0" bio irq 11 drq 5 vector ahaintr [Seagate ST01/02インタフェースのドライバ] controller sea0 at isa? bio irq 5 iomem 0xc8000 iosiz 0x2000 vector seaintr controller scbus0 device sd0 [4台のSCSI ディスクのサポート, sd0 から sd3] device st0 [2台の SCSI テープのサポート] [CDROMのドライバ] device cd0 #Only need one of these, the code dynamically grows 両方の例で SCSIディスクがサポートされています. ブート中に 「固定」の記述がされているタイプ(例えば sd ディスク) のデバ イスで記述より多くのデバイスが見つかると, システムは単純に最後の 固定 のデバイスの番号より 1つずつ増加させた番号をデバイスに割り当てて行きます. もし 固定 のデバイスがなければユニット番号は 0 から始まります. man 4 scsi によって SCSIサブシステムの最新の情報を チェックしてください. より詳細なホストアダプタドライバの使い 方は, たとえば Adaptec 294xドライバの場合はman 4 ahc にあります. カーネルセットアップでの SCSI チューニング 経験的に SCSIバスリセット (ブート時におきます) 後のINQUIRYコマ ンドに対して応答が遅くなるデバイスがあります. INQUIRYコマンドは ブート時にカーネルがどの種類のデバイス (ディスク, テープ, CDROMなど) がどのターゲットIDに接続されているかを調べるために 発行します. ちなみにこのプロセスをデバイスプロービング (デバイス検出) と言います. 「応答の遅いデバイス」の問題を解決するために, FreeBSDは SCSIバスをリセットした後に SCSIデバイスの検出を おこなうまでのディレイタイムを調整することができます. カーネルコンフィグレーションファイルの下に示すような 行にディレイタイムを設定してください. options SCSI_DELAY=15 #Be pessimistic about Joe SCSI device この行ではディレイタイムは 15秒です. 私のシステムでは, 信頼できる古い CDROMが認識できるように3秒の値を使っています. もし デバイスの認識で問題が起きる時は大きな値 (30秒であるとか) から 始めてください. うまく動いたら, 値を減らしてちょうどよい値 にチューニングしてください. Rogue な SCSI デバイス (訳注: rogue は有名なゲーム, ではなくて 悪党, 群から離れた, 凶暴な, という意味) SCSI の規定は完全で簡潔なものにしようという 努力はされましたが, 複雑な規定となり, 正確に実現するのは簡単なことではありません. いくつかのベンダは他よりもよい仕事をしています. ここで イカレた デバイスが現れることになります. このような デバイスは FreeBSD のカーネルにいくらか標準的 ではない振舞をするものと認識されます. イカレたデバイスは ブート時にカーネルによって報告されます. 次の例は私の2つの カートリッジテープユニットです. Feb 25 21:03:34 yedi /kernel: ahb0 targ 5 lun 0: <TANDBERG TDC 3600 -06:> Feb 25 21:03:34 yedi /kernel: st0: Tandberg tdc3600 is a known rogue Mar 29 21:16:37 yedi /kernel: aha0 targ 5 lun 0: <ARCHIVE VIPER 150 21247-005> Mar 29 21:16:37 yedi /kernel: st1: Archive Viper 150 is a known rogue 例えば, あるターゲットIDから実際には1つのデバイスしかないの にすべての LUNからの応答があるようなデバイスがあるとします. カー ネルはその特定のターゲットIDに8個の LUNがあると誤解してしまう かもしれません. このような混乱の起きる原因については読者へ の課題にしておきます. FreeBSDの SCSIサブシステムは 検出時の INQUIRYの応答を見て 悪い習慣を持つデバイスの認識をしています. INQUIRYの応答には デバイスのファームウェアのバージョン番号が含まれるため, 異なる 動作をするファームウェアのバージョンを 区別することも可能です. 例えば, /sys/scsi/st.c や /sys/scsi/scsiconf.c を 見てください. どのように行っているか, より多くの情報があります. この方法はうまく行きますが, もちろん既知のデバイスがつながっ ている場合だけうまくいくということに 気をつける必要があります. もしあなた以前に Mumbletech SCSI CDROM (訳注: 架空のメーカ のデバイスです) を接続した人がいないとしたら, どんな 「ワザ」 を使ってそれを使うか自分で見つけないと いけないかもしれません. あなたの Mubletech を動かすことができたらその成果を FreeBSDの 次のリリースへ含めるために FreeBSD開発チームへ送ってくださ い. 他の Mumbletechの利用者たちはあなたに感謝するでしょう. 複数の LUNを持つデバイス 単一の SCSI ID上に複数の論理ユニット (LUN) を持つデバイスを使う ような場合もあるかもしれません. 多くの場合では FreeBSDは LUN 0 のみを検出します. このような例としては2台の SCSIではないハード ディスクを SCSIバスにつなぐブリッジボード (例えば古い Sunシステ ムに見られる Emulex MD21) があります. LUN が0ではないデバイスは普通はシステムブート時の検出では 見つかりません. この問題にうまく対処するには /sys/scsi/scsiconf.c に適切なエントリを加えてカーネルを再構築 しなければなりません. 以下のように初期化されている構造体を探します. { T_DIRECT, T_FIXED, "MAXTOR", "XT-4170S", "B5A", "mx1", SC_ONE_LU } LUNが複数あるあなたの Mumbletech BRIDGE2000 はハードディスク として働きます. またファームウェアのリビジョン123などを次のよ うに書き加えます. { T_DIRECT, T_FIXED, "MUMBLETECH", "BRIDGE2000", "123", "sd", SC_MORE_LUS } 訳注: 複数 LUNに対応するためには構造体の最後の要素を SC_MORE_LUSにします. エントリを作る必要がある場合は scsiconf.c にある MBR-7等のエントリを参考にするといいでしょう. カーネルは INQUIRYに一致するデータをブート時にテーブルから 探してこれにしたがってふるまいます. より多くの情報は ソースコードを見てください. タグ コマンド キューイング 最近の SCSI デバイス, 特に磁気ディスクではタグ コマンド キューイング (tagged command queuing: TCQ) がサポートされています. 要約すれば, TCQ は複数の I/O リクエストを同時に受けることを可能 にすることです. デバイスはインテリジェントですから,リクエスト キューにある処理 (ヘッドのポジショニングなど) の最適化を おこなうことができます. RAID (Redundant Array of Independent Disks) のようなSCSIデバイスではTCQ機能はデバイスの持つ並列性の 利点を生かすために不可欠です. 各々の I/O リクエストは単一の tag (タグ コマンド キューイン グの名前の由来) が与えられます. FreeBSDはこの tagによりデバ イスドライバのキューの中のどの I/Oリクエストが完了したかの 識 別をおこないます. TQC のリクエストはデバイスドライバが サポートしていたとしても あるデバイスのファームウェアではインプリメントが 正しくない かもしれません. このような問題に出会うと非常に不可解な問題に つながります. このような場合は TCQ を無効にしてみてください. バスマスタ ホストアダプタ すべてではありませんが多くの SCSIホストアダプタは バスマスタコントローラです. これはホストCPUにデータ転送の 負荷をかけず, ボード自身がI/Oをおこないます. これは FreeBSDのようなマルチタスクのオペレーティングシステム では大きな利点になります. しかし, 何らかの問題の起きることも あります. 例えば Adaptec 1542 コントローラは ホストバス (ここでは ISA または AT バス) を異なった転送速度に設定できます. コントローラが 異なるレートに設定できるのは すべてのマザーボードで 高速な転送が できるわけではないからです. マザーボードに合っていない高速の データ転送速度を用いた時には, ハングアップやデータの損傷等の 問題が起きるかもしれません. これを解決する方法は明らかです. より低いデータ転送速度に設定 してうまく動くか確かめることです. Adaptec 1542 の場合, 可能な限り高速な転送レートを動的に読み取って, 正しい決定をおこなうためのオプションを カーネルコンフィグファイルに 追加することができます. このオプションはデフォルトでは無効に なっています. options "TUNE_1542" #dynamic tune of bus DMA speed あなたの使うホストアダプタについてのマニュアルページを チェックしてください. また最終的な手段としては究極のドキュメントを 使ってください (つまりドライバのソースを読んでくださいというこ とです). 訳注: 2.1.5R の時点ではすべてのドライバに関してマニュアルページ があるわけではありません. また上の例の TUNE_1542のオプション も man aha にはないようです. ソースのコメントだけで も一度見ておいてもいいかもしれません. 問題を突き止める 以下は SCSI で一般的に問題が起きた場合に解決をするためのチェッ クリストの試みです. これは完全な物ではありません. コネクタとケーブルがゆるんでいないかチェックする. ターミネータの場所と数を念には念を入れて チェックする. 少なくとも 1 つのターミネータの電源の供給源があるかチェック する (特に外部ターミネータを使う場合). ターゲットIDが重複していないかチェックする. 使用するすべてのデバイスの電源が ON になっているかチェックする. 必要最小限のデバイスだけの構成を試してみる. 可能であれば, ホストアダプタのスピードを遅くする. 問題をより単純にするために, タグコマンドキューイングを可能 であれば無効にする. (NCRベースのホストアダプタについては man ncrcontrol を見てください) カーネルのコンパイルができるのであれば, SCSIDEBUGオプショ ンをつけて makeして, デバイスをデバッグモードにしてアクセ スしてみてください. もしそれでも起動時にデバイスが検出 されないのであれば, デバイスの設定アドレスが間違っている のかもしれません. また, /sys/scsi/scsidebug.h に あるデバッグレベルを変えてみてください. 検出はされるが 動かないのであれば, &man.scsi.8; コマンドで (SCSIDEBUG をつけてmakeした) カーネルが動いている状態で動的にデバッグ レベルを設定することができます. これは guru (UNIXの達人) で も混乱してしまうほどの非常に大量のデバッグ情報を 出すでしょ う. man 4 scsi にはより正確な情報があります. またman 8 scsi も見てください. さらに詳しい情報 もしあなたがいくらかは本気で SCSIハッキングをする気があるなら たぶん正規の規格を持っていたくなるでしょう. 承認ずみのアメリカ工業規格は ANSI から購入できます. 住所と電話番号は
13th Floor 11 West 42nd Street New York NY 10036 Sales Dept: (212) 642-4900
です. また, ANSIの規格および委員会の規格案 (ドラフト) のほとんどは Global Engineering Documents より買うことができます. 連絡先は
15 Inverness Way East Englewood CO, 80112-5704 Phone: (800) 854-7179 Outside USA and Canada: (303) 792-2181 Fax: (303) 792- 2192
です. X3T10 のドラフトの多くは電子的に利用できる形で SCSI BBS (719-574-0424) と ncrinfo.ncr.com の Anonymous FTP サイトから得ることができます. 最新の X3T10 委員会の文書は: AT Attachment (ATA or IDE) [X3.221-1994] (Approved) ATA Extensions (ATA-2) [X3T10/948D Rev 2i] Enhanced Small Device Interface (ESDI) [X3.170-1990/X3.170a-1991] (Approved) Small Computer System Interface — 2 (SCSI-2) [X3.131-1994] (Approved) SCSI-2 Common Access Method Transport and SCSI Interface Module (CAM) [X3T10/792D Rev 11] 追加情報を得ることのできる出版物は: SCSI: Understanding the Small Computer System Interface, NCR社 編. 出版: Prentice Hall, Englewood Cliffs, NJ, 07632 Phone: (201) 767-5937 ISBN 0-13-796855-8 Basics of SCSI, a SCSI tutorial, Ancot Corporation 編 Ancot の連絡先: Phone: (415) 322-5322 Fax: (415) 322-0455 SCSI Interconnection Guide Book, AMP社の出版物 (発行 4/93, カ タログ 65237) 色々な SCSI コネクタのリスト と ケーブル接続方法のガイド. AMP 社より入手可能. (800) 522-6752 または (717) 564-0100 Fast Track to SCSI, 富士通によるプロダクトガイド, 入手先: Prentice Hall, Englewood Cliffs, NJ, 07632 電話: (201) 767-5937 ISBN 0-13-307000-X The SCSI Bench Reference, The SCSI Encyclopedia, SCSI Tutor, ENDL Publications, 14426 Black Walnut Court, Saratoga CA, 95070 電話: (408) 867-6642 Zadian SCSI Navigator (クイックリファレンス) および Discover the Power of SCSI (最初の本は1時間のビデオとチュートリアルが付属), Zadian Software, Suite 214, 1210 S. Bascom Ave., San Jose, CA 92128, (408) 293-0800 Usenet のニュースグループ comp.periphs.scsi と comp.periphs は特により多くの情報を得るには注目すべき場所です. また定期的に ポストされる SCSI-FAQをここから得ることができます. 多くの主要な SCSIデバイスとホストアダプタの供給元は FTP サイト や BBSを開いています. これらはあなたの持っているデバイスに関す る貴重な情報源となるでしょう. * ディスク/テープ コントローラ * SCSI * IDE * フロッピー ハードディスクドライブ SCSI ハードディスク装置 寄稿: &a.asami; . 17 February 1998. 訳: &a.jp.miyasita;. 20 February 1998. SCSI の章で述べたように, 実際, 現在販売されている SCSI ハードディスク装置はすべて SCSI-2 互換であり, サポートされている SCSI ホストアダプタに 接続すればそれらは正常に動作するでしょう. 人々が直面する問題の多くは, ケーブル接続が間違っていたり (ケーブルが長過ぎる, スター型接続になっている, など), ケーブル終端の処理が不十分だったり, 部品が故障していたりのうちのどれかです. SCSI ハードディスク装置が動作しないときには, まず SCSI の章を参照して下さい. しかし SCSI ハードディスク装置を購入するときに 気を付けておきたいことがふたつあります. 回転速度 現在販売されている SCSI ドライブの回転速度の範囲は 4,500RPM から 10,000RPM であり, その大部分は 5,400RPM か 7,200RPM です. 一般的に 7,200RPM のドライブの方がデータ転送は速いのですが, 5,400RPM の同容量のものと比べてとても熱くなります. 現在のディスク装置の故障の大半は熱によるものです. もし PC のケースの中が非常によく冷却されていなければ, 5,400RPM かそれ以下のドライブにしておいた方がよいでしょう. より高密度で記録するようになっている新しいドライブは 以前のものに比べてより多くのビットを 各回転毎に転送することが できるということに気をつけて下さい. 現在, 5,400RPM の最高級機種では 1, 2 世代前の 7,200RPM の ドライブに匹敵する転送速度が出せます. 仕様一覧からバンド幅の数値を探すには 内部データ (または転送) 速度 という欄を見て下さい. 通常その数値は Mbits/s で書かれているので, それを 8 で割ればそのドライブで出せる速度が Mbytes/s で おおよそ見当をつけることができます. (もしあなたがスピード狂で, あなたの愛する小さなパソコンちゃんに 10,000RPM のドライブを載せたいのならそうしても構いませんが, そのようなドライブはものすごく熱くなります. ドライブへ 直接 風を当てられるようなファンや きちんと換気されているディスク区画を持っていないときには そういうことは考えない方がよいでしょう.) 最新の 10,000RPM のドライブや 7,200RPM のドライブは当然 最新の 5,400RPM のドライブよりも多くのデータを転送することが できますから, 絶対的なバンド幅がアプリケーションにとって 必要ならば, より速いドライブを選ぶしかありません. また, レイテンシを小さくする必要があるときも, より速いドライブが適当です. なぜなら, より速いドライブの方が平均シーク時間が 少ないだけでなく, 回転遅延という尺度において 低回転速度のドライブが高回転速度のものに 勝ることはないからです. (平均回転レイテンシはディスクが 1 回転するために要する時間を半分に したものです. すなわち, 10,000RPM のドライブでは 3 ms, 7,200RPM のドライブでは 4.2 ms, 5,400RPM のドライブでは 5.6 ms となります.) レイテンシはシーク時間と回転遅延との和になります. しかしここで, レイテンシの少ないドライブが欲しいのか, 1 秒あたりのアクセス数を増やす方がよいのかを はっきりさせておかなければいけません. 後者の場合 (例 : ニュースサーバ) では, 大きな速いドライブを 1 つ購入することは最適解とはならないでしょう. 遅いドライブを複数個使ってストライピングされた ディスクアレイを 作る ccd (連結ディスク) ドライバを用いることによって, 全体に必要な費用の点で同様かまたはより 良い結果を得ることができます. ドライブのまわりに適切な空気の 流れを作るようにする必要が あります. 高回転速度のドライブを使おうとしているときには特に 注意してください. 一般的に, ドライブの上下には少なくとも 1/2 インチ (1.25cm) の すき間が必要です. PC のケース内の空気がどんなふうに流れているか 理解しておいてください. 多くのケースには背面から空気を吸い込む電源が付いています. どこから空気が入ってくるかを確かめて, まわりに最大量の 冷たい空気が流れるようにドライブを設置してください. 効果的に冷却するためには, 不要な穴をいくつか塞いだり 新しいファンを追加する必要があるかも知れません. もうひとつ考慮するべき事柄は騒音です. 7,200RPM やそれより速い回転速度のドライブの多くは高い周波数の 音を発生し, この音は多くの人をとても不快にします. それに加えて, 冷却のために追加されたファンによっても, 7,200RPM やそれより速い回転速度のドライブはオフィスや家の環境に そぐわないものになるかもしれません. 形状 現在販売されている大部分の SCSI ドライブは 3.5 インチの 大きさです. それらは高さが 1.6 インチ (ハーフハイト) のものと 1 インチ (ロープロファイル) のものとの 2 種類に分類されます. ハーフハイトのドライブは CDROM ドライブと同じ高さです. しかし前節で述べたすき間についての ルールを忘れないでください. 3.5 インチドライブ用のベイが 3 段用意されているときに, ハーフハイトのドライブ 3 個を (焦がすことなく) そこに設置することはできないでしょう. インタフェース 現在売られている SCSI ハードドライブの多くは Ultra または Ultra-wide SCSI です. Ultra SCSI の最大バンド幅は 20MB/s, Ultra-wide SCSI の場合は 40MB/s です. Ultra と Ultra-wide の間にケーブル最大長の相違はありませんが, 同一バスに接続されるデバイスが増えれば増えるほど 早い時期にバスの整理に関する問題を 抱えることになるでしょう. うまく設計されたディスク区画を持っているのでなければ, 5 個か 6 個以上の Ultra SCSI ドライブを 1 本のバスに 接続することは容易なことではありません. 一方, 多数のドライブを接続する必要があるときに Fast-wide SCSI を利用することは悪くないアイデアでしょう. これは Ultra (narrow) SCSI と同じ最大バンド幅であると同時に 正しく 接続することが電気的にとても容易です. アドバイスとしてはこのようになるでしょうか : ディスクを多数接続したいときには wide SCSI のドライブを 選んで下さい. 通常 wide SCSI の方が少し高価ですが, 将来きっと役に立ちます. (なお, 価格差を補う余裕がないときにはディスクアレイを 作るべきではありません.) wide SCSI ドライブには 68 ピンのものと 80ピン SCA (単コネクタ型) のものとの 2 種類があります. SCA ドライブには 4 ピンの電源コネクタがなく, SCSI ID も 80 ピンコネクタを通じて設定されます. 真面目に大規模な記憶システムを作成するような場合には, SCA ドライブと SCA 筺体 (2 種類の電圧が供給できる電源と少なくとも 1 個のファンが付いたもの) を使ってください. その方が 68 ピンの同様のドライブよりも電気的に優れています. なぜなら, 68 ピンのドライブで作ったディスクアレイに 見られるような SCSI バスの スタブ がディスクキャニスタの内部に 存在しないからです. それらはより簡単に設置することができます (キャニスタの中にドライブをねじで固定すればよいだけで, (SCSI ID やディスクアクセス LED 用の線のような) 細かいケーブルを全部持ち上げるために狭いところへ指を入れて 握らなくてもよいのです). * IDE ハードディスクドライブ テープドライブ 原作: &a.jmb;. 2 July 1996. 訳: &a.jp.yoshiaki;. 13 October 1996. 一般的なテープアクセスコマンド &man.mt.1; はテープドライブへの一般的なアクセス方法を提 供します. rewind, erase, statusなど の共通コマンドがあります. マニュアルページの &man.mt.1; を見 てください. より詳しい解説があります. コントローラインタフェース テープドライブにはいくつかの異なったインタフェースがあり ます. SCSI, IDE, フロッピー, パラレルポートのインタフェース です. 非常に多くの種類のテープドライブがこれらのインタフェー スで使えます. コントローラについての議論はディスク/テープ のコントローラにあります(訳注:現在未完成です). SCSI ドライブ &man.st.4; ドライバは 8mm (Exabyte), 4mm (DAT: Digital Audio Tape), QIC (1/4インチカートリッジ), DLT (デジタルリニアテープ), QIC ミニカートリッジ, 9トラック (大きなリールがハリウッドの コンピュータルームで回っているのを見たことがあるでしょう) をサポートします. &man.st.4; マニュアルページにより詳しい解説があります. 以下のドライブリストは現在 FreeBSDコミュニティのメンバが 使っているものです. これらだけが FreeBSDで動くドライブという わけではありません. これらは単にたまたま私たちのうちの誰かが使っ ているというだけです. 4mm (DAT: Digital Audio Tape ) Archive Python 28454 Archive Python 04687 HP C1533A HP C1534A HP 35450A HP 35470A HP 35480A SDT-5000 Wangtek 6200 8mm (Exabyte) EXB-8200 EXB-8500 EXB-8505 QIC (1/4 インチカートリッジ) Archive Anaconda 2750 Archive Viper 60 Archive Viper 150 Archive Viper 2525 Tandberg TDC 3600 Tandberg TDC 3620 Tandberg TDC 3800 Tandberg TDC 4222 Wangtek 5525ES DLT (Digital Linear Tape) Digital TZ87 Mini-Cartridge Conner CTMS 3200 Exabyte 2501 Autoloaders/Changers Hewlett-Packard HP C1553A Autoloading DDS2 * IDE ドライブ フロッピードライブ Conner 420R * パラレルポートドライブ 詳細な情報 Archive Anaconda 2750 このドライブのブートメッセージの識別子は ARCHIVE ANCDA 2750 28077 -003 type 1 removable SCSI 2 です. これは QIC テープドライブです. QIC-1350テープを利用した場合の標準の容量は 1.35GBです. このドライブは QIC-150 (DC6150), QIC-250 (DC6250), QIC-525 (DC6525) の テープを問題なく読み書きすることができます. &man.dump.8; を使った時のデータ転送レートは 350kB/sです. Amanda における転送レートは 530kB/sと報告されています. このドライブは既に生産中止になっています. このテープドライブの SCSIバスコントローラは他のほとんどの SCSIドライブとピン配置が逆です. Anaconda テープドライブの前後でSCSIケー ブルを1/2ひねることができるくらい SCSI ケーブルが長いことを確認しておく か, 他の SCSIデバイスのピン配置を入れ換えておく必要 があります. そして, このドライブではカーネルコードの変更が 2箇所必要です. そ のままではうまく動かないでしょう. SCSI-2コントローラを持っているなら, ジャンパの 6番をショート してください. そうしないとこのドライブは SCSI-1として働きます. SCSI-1の デバイスとして動作する時, このドライブはテープのfsf (早送り), rewind (巻 戻し),rewoffl (巻戻してオフラインにする) 等を含む操作を行っている間, SCSIバスをロックします. NCR SCSIコントローラを使う場合, /usr/src/sys/pci/ncr.c (以 下を参照してください)にパッチを行って, カーネルを作り直し, 新しいカーネ ルをインストールしてください. *** 4831,4835 **** }; ! if (np->latetime>4) { /* ** Although we tried to wake it up, --- 4831,4836 ---- }; ! if (np->latetime>1200) { /* ** Although we tried to wake it up, 報告者: &a.jmb; Archive Python 28454 このドライブのブートメッセージの識別子は ARCHIVE Python 28454-XXX4ASB type 1 removable SCSI 2 density code 0x8c, 512-byte blocks です. これは DDS-1 テープドライブです. 90m テープを使った場合の標準容量は 2.5GBです. データ転送速度は不明です. このドライブは Sun マイクロシステムが再パッケージして model 595-3067として出しています. 報告者: Bob Bishop rb@gid.co.uk スループットは 1.5 MByte/sec クラスですが, ディスクとテープが同じ SCSI コントローラに接続されている 場合には遅くなってしまいます. 報告者: Robert E. Seastrom rs@seastrom.com Archive Python 04687 このドライブのブートメッセージの識別子はARCHIVE Python 04687-XXX 6580 Removable Sequential Access SCSI-2 deviceです. これは DAT-DDS-2 ドライブです. 120m テープを使った場合の標準容量は 2.5GBです. このドライブはハードウェアデータ圧縮をサポートしています. スイッチ4は MRS (Media Recognition System:メディア認識システム )をコントロールします. MRSテープの透明なテープリーダー部分には しま模様があります. スイッチ 4 をoff にすると MRS が有効に, on にすると MRS が無効になります. パリティはスイッチ 5 でコントロールされます. スイッチ 5 を on にするとパリティが有効になります. 圧縮は スイッチ 6 off で有効です. 圧縮については SCSI MODE SELECT コマンド (see &man.mt.1;) の指定が優先されます. データ転送レートは 800kB/s です. Archive Viper 60 このドライブのブートメッセージ識別子は ARCHIVE VIPER 60 21116 -007 type 1 removable SCSI 1 です. これは QICテープドライブです. 標準の容量は 60MB です. データ転送レートは不明です. このドライブは生産中止になっています. 報告者: Philippe Regnauld regnauld@hsc.fr Archive Viper 150 このドライブのブートメッセージの識別子は ARCHIVE VIPER 150 21531 -004 Archive Viper 150 is a known rogue type 1 removable SCSI 1です. このドライブのファームウェアには多くのリビジョ ンがあります. あなたのドライブではことなった数字が表示されるかもしれま せん(例えば 21247 -005). これは QICテープドライブです. 標準容量は 150/250MBです. 150MB (DC6150) テープと 250MB (DC6250)テープの記録フォーマットがあります. 250MBテープは およそ67% 150MBテープより長いです. このドライブは 120MBのテープを問題 なく読むことができます. 120MBテープに書き込むことはできません. データ転送レートは100kB/sです. このドライブは DC6150 (150MB) と DC6250 (250MB) テープの読み 書きができます. このドライブの奇妙な癖は SCSIテープデバイスドライバはあら かじめ (&man.st.4;) にあらかじめ組み込まれています. FreeBSD 2.2-CURRENTでは, ブロックサイズの設定を設定するためmt blocksize 512としてください. (ファームウェアリビジョンが 21247 -005 である場合の問題です. 他のリビジョンのファームウェアでは異 なる場合があります.) これ以前の FreeBSDバージョンにはこの問題はありません. このドライブは生産中止になっています. 報告者: Pedro A M Vazquez vazquez@IQM.Unicamp.BR &a.msmith; Archive Viper 2525 このドライブのブートメッセージの識別子は ARCHIVE VIPER 2525 25462 -011 type 1 removable SCSI 1です. これは QICテープドライブです. 標準容量は 525MBです. データ転送レートは 90inch/secの場合で 180kB/sです. QIC-525, QIC-150, QIC-120, QIC-24のテープを読むことができま す. QIC-525, QIC-150, QIC-120 に書き込むことができます. ファームウェアのリビジョンが 25462 -011 以前の物はバグが 多く, 正しく機能しません. このドライブは生産中止になっています. Conner 420R このドライブのブートメッセージの識別子は Conner tape です. これはフロッピーコントローラを 使うミニカートリッジテープド ライブです. 標準容量は不明です. データ転送レートは不明です. このドライブは QIC-80テープドライブを使います. 報告者: Mark Hannon mark@seeware.DIALix.oz.au Conner CTMS 3200 このドライブのブートメッセージの識別子は CONNER CTMS 3200 7.00 type 1 removable SCSI 2 です. これはミニカートリッジテープドライブです. 標準容量は不明です. データ転送レートは不明です. このドライブは QIC-3080テープカートリッジを使います. 報告者: Thomas S. Traylor tst@titan.cs.mci.com <ulink url="http://www.digital.com/info/Customer-Update/931206004.txt.html">DEC TZ87</ulink> このドライブのブートメッセージの識別子は DEC TZ87 (C) DEC 9206 type 1 removable SCSI 2 density code 0x19 です. これは DLTテープドライブです. 標準容量は 10GBです. このドライブはハードウェアデータ圧縮の機能があります. データ転送レートは 1.2MB/sです. このドライブは Quantum DLT2000と同一の物です. このドライブ のファームウェアは Exabyteの 8mmドライブ等のよく知られたいくつかのドラ イブのエミュレートをおこなうよう設定ができます. 報告者: &a.wilko; <ulink url="http://www.Exabyte.COM:80/Products/Minicartridge/2501/Rfeatures.html">Exabyte EXB-2501</ulink> このドライブのブートメッセージ識別子は EXABYTE EXB-2501です. これはミニカートリッジテープドライブです. MC3000XLミニカートリッジを使った時の標準容量は 1GBです. データ転送レートは不明です. このドライブは DC2300 (550MB), DC2750 (750MB), MC3000 (750MB), MC3000XL (1GB) ミニカートリッジの読み書きができます. 注意: このドライブは SCSI-2の仕様に適合していません. このドライブは, フォーマット済みのテープ以外を入れた場合, SCSI MODE_SELCTコマンドで完全にロックアップしてしまいます. このドライブを使 う前に, テープブロックサイズを次のように設定します. &prompt.root; mt -f /dev/st0ctl.0 blocksize 1024 ミニカートリッジは最初に使う前に フォーマットしなければなりません. FreeBSD 2.1.0-RELEASE およびそれ以前の場合は &prompt.root; /sbin/scsi -f /dev/rst0.ctl -s 600 -c "4 0 0 0 0 0" (あるいは, FreeBSD 2.1.5/2.2から scsiformatシェルスクリプトを コピーして持ってきた場合と) FreeBSD 2.1.5およびそれ以降の場合は &prompt.root; /sbin/scsiformat -q -w /dev/rst0.ctl とします. 今のところ, FreeBSDではこのドライブはあまりおすすめできません. 報告者: Bob Beaulieu ez@eztravel.com Exabyte EXB-8200 このドライブのブートメッセージの識別子は EXABYTE EXB-8200 252X type 1 removable SCSI 1です. これは8mmテープドライブです. 標準容量は 2.3GBです. データ転送レートは 270kB/sです. このドライブはブート時の SCSIバスへの応答はわりあい遅いです. カスタムカーネルが必要かもしれません (SCSI_DELAYを 10秒に設定しましょう). 訳注: GENERICカーネルの設定では 15秒になっています. このドライブには非常に多くのファームウェアの 構成があります. あるドライブでは特定のベンダのハードウェアに カスタマイズしてあります. ファームウェアは EPROMを置き換えることで変更できます. このドライブは生産中止になっています. 報告者: &a.msmith; Exabyte EXB-8500 このドライブのブートメッセージの識別子は EXABYTE EXB-8500-85Qanx0 0415 type 1 removable SCSI 2 です. これは 8mmテープドライブです. 標準容量は 5GBです. データ転送レートは 300kB/sです. 報告者: Greg Lehey grog@lemis.de <ulink url="http://www.Exabyte.COM:80/Products/8mm/8505XL/Rfeatures.html">Exabyte EXB-8505</ulink> このドライブのブートメッセージ識別子は EXABYTE EXB-85058SQANXR1 05B0 type 1 removable SCSI 2です. これは 圧縮機能を持った 8mmテープドライブで, EXB-5200 と EXB-8500に対する上位互換品です. 標準容量は 5GBです. このドライブは ハードウェアデータ圧縮機能があります. データ転送レートは 300kB/sです. 報告者: Glen Foster gfoster@gfoster.com Hewlett-Packard HP C1533A このドライブのブートメッセージの識別子は HP C1533A 9503 type 1 removable SCSI 2です. これはDDS-2テープドライブです. DDS-2 とはデータ容量を増や すためにハードウェア圧縮と 狭いトラックを採用したものです. 120mテープを使った場合の標準容量は4GBです. このドライブは ハードウェアデータ圧縮機能があります. データ転送レートは510kB/sです. このドライブはヒューレットパッカード社の 6000eU および 6000i テー プドライブ, C1533A DDS-2 DAT ドライブに使われています. このドライブは 8接点のディップスイッチがあります. FreeBSDで の適切な設定は 1 ON; 2 ON; 3 OFF; 4 ON; 5 ON; 6 ON; 7 ON; 8 ON です. スイッチ 1 スイッチ 2 結果 On On 電源投入時に圧縮 ON, ホストによるコントロール可能 On Off 電源投入時に圧縮 ON, ホストによるコントロール不可 Off On 電源投入時に圧縮 OFF, ホストによるコントロール可能 Off Off 電源投入時に圧縮 OFF, ホストによるコントロール不可 スイッチ 3 は MRS (Media Recognition System :メディア認識システ ム) をコントロールします. MRS テープは透明なテープリーダ部分にしま模 様があります. これはテープが DDS (Digital Data Storage) グレードである ことを示します. しま模様のないテープはライトプロテクトされたものとして 扱います. スイッチ3をOFFにすると MRSが有効になります. スイッチ3をONに すると MRSは無効になります. 訳注: 安価な音楽用のDATテープを使うには MRSをOFFにしておきます このドライブの設定についてのより詳しい情報は HP SureStore Tape Products および Hewlett-Packard Disk and Tape Technical Information をご覧ください. 注意: これらのドライブの品質管理は非常に幅がありま す. ある FreeBSDコアチームのメンバは このドライブを2つ返品しました. 報告者: &a.se; Hewlett-Packard HP 1534A このドライブのブートメッセージの識別子は HP HP35470A T503 type 1 removable SCSI 2 Sequential-Access density code 0x13, variable blocksです. これは DDS-1テープドライブです. DDS-1 は最初の DAT テープフォーマットです. 90m テープを使った場合の標準容量は 2GBです. データ転送レートは 183kB/sです. ヒューレットパッカード社の SureStore 2000i テープドライブ, C35470A DDS フォーマット DATドライブ, C1534A DDS フォーマット DATドライブ, HP C1536A DDS フォーマット DATドライブと 同じ機構を使用しています. HP C1534A DDSフォーマット DATドライブはグリーンと黄色(アンバー) の2つの表示ランプがあります. グリーンのランプは動作状 態を示し, ローディング中はゆっくり点滅, ローディングが終了すると点灯, read/write動作中は速く点滅します. 黄色のランプは警告灯で, クリーニング が必要であるかまたはテープが寿命に近くなるとゆっくり点滅, 致命的なエラー の場合は点灯します(工場での修理が必要かもしれません). 報告者:Gary Crutcher gcrutchr@nightflight.com Hewlett-Packard HP C1553A Autoloading DDS2 このドライブのブートメッセージの識別子は未確認です. これはテープチェンジャ付の DDS-2テープドライブです. DDS-2 とはデータ容量を増や すためにハードウェア圧縮と狭いトラックを 採用したものです. 120mテープを使用した場合の標準容量は 24GB です. このドライブはハードウェアデータ圧縮機能があります. データ転送レートは510kB/s (標準) です. このドライブはヒューレットパッカード社の SureStore 12000e テープドライブに使われています. このドライブはリアパネルに2つの選択スイッチがあります. ファンに近いスイッチは SCSI IDです. もうひとつは 7に設定しておきます. 内部に 4個のスイッチがあります. これらは 1 ON; 2 ON; 3 ON; 4 OFF に設定しておきましょう. 現在のカーネルドライバはボリュームの終りで 自動的にテープを 交換しません. ここに示す shellスクリプトでテープを交換できます. #!/bin/sh PATH="/sbin:/usr/sbin:/bin:/usr/bin"; export PATH usage() { echo "Usage: dds_changer [123456ne] raw-device-name echo "1..6 = Select cartridge" echo "next cartridge" echo "eject magazine" exit 2 } if [ $# -ne 2 ] ; then usage fi cdb3=0 cdb4=0 cdb5=0 case $1 in [123456]) cdb3=$1 cdb4=1 ;; n) ;; e) cdb5=0x80 ;; ?) usage ;; esac scsi -f $2 -s 100 -c "1b 0 0 $cdb3 $cdb4 $cdb5" Hewlett-Packard HP 35450A このドライブのブートメッセージの識別子は HP HP35450A -A C620 type 1 removable SCSI 2 Sequential-Access density code 0x13 です. これは DDS-1テープドライブです. DDS-1 は最初の DAT テープフォーマットです. 標準容量は 1.2GBです. データ転送レートは 160kB/sです. 報告者: Mark Thompson mark.a.thompson@pobox.com Hewlett-Packard HP 35470A このドライブのブートメッセージの識別子は HP HP35470A 9 09 type 1 removable SCSI 2です. これは DDS-1テープドライブです. DDS-1は最初の DAT テープフォーマットです. 90mテープを使用した時の標準容量は 2GBです. データ転送レートは 183kB/sです. これはヒューレットパッカード社の SureStore 2000i テープドライブ, C35470A DDSフォーマットDATドライブ, C1534A DDSフォーマットDATドライブ, HP C1536A DDS フォーマットDATドライブと同 じ機構が使われています. 注意: これらのドライブの品質管理には非常に大き な幅があります. ある FreeBSDコアチームのメンバは 5台のドライブを返品し ました. 9ヶ月以上もったものはありません. 報告者: David Dawes dawes@rf900.physics.usyd.edu.au (9 09) Hewlett-Packard HP 35480A このドライブのブートメッセージの識別子は HP HP35480A 1009 type 1 removable SCSI 2 Sequential-Access density code 0x13 です. これは DDS-DCテープドライブです. DDS-DCはハードウェアデータ 圧縮のついたDDS-1です. DDS-1は最初のDATテープフォーマットです. 90mテープを使った場合の標準容量は 2GBです. 120mテープは使用 できません. このドライブはハードウェア圧縮機能があります. 適切なスイッチ設定に関しては, HP C1533A の節を参照してください. データ転送レートは 183kB/sです. このドライブはヒューレットパッカード社の SureStore 5000eU , 5000i テープドラ イブ, C35480A DDS フォーマット DAT ドライブと同じ機構を使っています. このドライブは時々, テープの eject操作 (mt offline) を行っている時にハングアップすることがあります. テープをejectさせたり, ドライブを回復させるにはフロントパネルのボタンを 押してください. 注意: HP 35480-03110 では特有の問題がありました. 少なくとも2回, FreeBSD 2.1.0 で IBM Server 320に 2940W SCSIコントローラ をつけてこのドライブを使っている時にすべての SCSIディスクのパーティショ ンが失われたことがあります. この問題は解析も解決もできていません. <ulink url="http://www.sel.sony.com/SEL/ccpg/storage/tape/t5000.html">Sony SDT-5000</ulink> これらには少なくとも DDS-1のものと DDS-2のものの2つのモデルが あります. DDS-1のものは SDT-5000 3.02です. DDS-2のものは SONY SDT-5000 327M です. DDS-2バージョンには 1MBのキャッシュがあります. この キャッシュによりあらゆる状況で テープのデータの流れを途切れさせません. このドライブのブートメッセージの識別子は SONY SDT-5000 3.02 type 1 removable SCSI 2 Sequential-Access density code 0x13です. 120mテープを使用した場合の標準容量は 4GBです. このドライブ はハードウェアデータ圧縮機能があります. データ転送レートはドライブのモデルによります. SONY SDT-5000 327M でデータ圧縮を行った場合のレートは 630kB/s です. SONY SDT-5000 3.02では 225kB/sです. Kenneth Merry ken@ulc199.residence.gatech.edu の報告によれば このドライブからデータを読むためには, ブロックサイズを 512バイトにしま す (mt blocksize 512). SONY SDT-5000 327M の情報は Charles Henrich henrich@msu.edu による報告です. 報告者: &a.jmz; Tandberg TDC 3600 このドライブのブートメッセージの識別子は TANDBERG TDC 3600 =08: type 1 removable SCSI 2です. このドライブはQIC テープドライブです. 標準容量は150/250MBです. このドライブには奇妙な癖があることが知られていますが, SCSIテープドライバ (&man.st.4;) には問題なく動くコードが含まれてい ます. 問題の修整とSCSI 2へのコンパチビリティを得るためにファームウェ アをある (具体的には不明の) バージョンより上にしてください. データ転送レートは80kB/sです. IBMと Emerald製品のユニットは動かないでしょう. 問題を解決するためにファームウェア EPROMを交換してください. 報告者: &a.msmith; Tandberg TDC 3620 これは Tandberg TDC 3600ドライ ブに非常によく似ています. 報告者: &a.joerg; Tandberg TDC 3800 このドライブのブートメッセージの識別子は TANDBERG TDC 3800 =04Y Removable Sequential Access SCSI-2 device です. これは QIC テープドライブです. 標準容量は 525MB です. 報告者: &a.jhs; Tandberg TDC 4222 このドライブのブートメッセージの識別子は TANDBERG TDC 4222 =07 type 1 removable SCSI 2です. これは QICテープドライブです. 標準容量は2.5GBです. このドライブは 60M (DC600A) 以上のすべての カートリッジを読むことができ, 150MB (DC6150) 以上のすべてのカートリッジを 読み書きできます. ハードウェア圧縮は 2.5GB カートリッジを使用した時の オプションとしてサポートされています. このドライブには奇妙な癖がありますが, FreeBSD の 2.2-CURRENT以降の SCSIテープデバイスドライバ (&man.st.4;) には対応が組み込まれています. それ以前のバージョンの FreeBSDではmtを用いてテープから1ブロッ ク読み, テープを巻戻してからバックアッププログラムを 実行してください. (mt fsr 1; mt rewind; dump ...). データ転送レートは 600kB/s (データ圧縮時のベンダによる公称) で, start/stop モードでも 350kB/s にはなります. 容量の小さいカー トリッジを使った場合にはレートは下がります. 報告者: &a.joerg; Wangtek 5525ES このドライブのブートメッセージの識別子は WANGTEK 5525ES SCSI REV7 3R1 type 1 removable SCSI 1 density code 0x11, 1024-byte blocksです. これは QICテープドライブです. 標準容量は 525MBです. データ転送レートは 180kB/sです. 60, 120, 150, 525MB のテープを読むことができます. 60MB (DC600カートリッジ) には書き込むことはできません. 120および150テー プに確実に上書きするには, 先にテープを消去 (mt erase) します. 120および 150のテープは 525MBのテープより幅の広いトラックを使用してい ます(テープ当たりのトラック数は少なくなります). トラックの幅の外側には上書きされませんので, テープが消去されない限り 両側に古いデータが残ったまま 新しいデータが置かれることになります. このドライブの奇妙な癖は知られていて, SCSI テープドライバ (&man.st.4;) に組み込まれています. 他のファームウェアのリビジョンで動くことが 確認されているも のは M75Dです. 報告者: Marc van Kempen marc@bowtie.nl REV73R1 Andrew Gordon Andrew.Gordon@net-tel.co.uk M75D Wangtek 6200 このドライブのブートメッセージの識別子は WANGTEK 6200-HS 4B18 type 1 removable SCSI 2 Sequential-Access density code 0x13です. これは DDS-1テープドライブです. 90mテープを使用した場合の標準容量は 2GBです. データ転送レートは 150kB/sです. 報告者: Tony Kimball alk@Think.COM * 問題のあるドライブ CDROM ドライブ 原作: &a.obrien;. 23 November 1997. Jordan 氏の選んだ組合せ でふれられているように FreeBSD プロジェクトでは一般的には IDE CDROM よりも SCSI CDROM の方が好まれています. しかし全ての SCSI CDROM ドライブが同じであるというわけではありません. いくつかの SCSI CDROM ドライブの品質は IDE CDROM ドライブよりも 低いものであると感じている人もいます. 東芝は信頼性が高いという評判が ありましたが, 12倍速の XM-5701A は, SCSI メーリングリストでは ( オーディオ CDROM の再生で) 何種類かのオーディオ再生ソフトウェアで ボリュームのコントロールができない, という不満のメールを大量に 見ることがありました. SCSI CDROM のメーカー間の競争のもう一つの局面は, SCSI 規格に対する忠実度です. 多くの SCSI CDROM は ターゲットアドレス(ID)の マルチ LUN に応答します. 既知の規格違反デバイスにはティアックの6倍速ドライブ CD-56S 1.0D があります. * その他 * その他 * PCMCIA diff --git a/ja_JP.eucJP/books/handbook/install/chapter.sgml b/ja_JP.eucJP/books/handbook/install/chapter.sgml index 055a7b1d13..86e8403abb 100644 --- a/ja_JP.eucJP/books/handbook/install/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/install/chapter.sgml @@ -1,1923 +1,1923 @@ FreeBSDのインストール 改訂: &a.jim;, 2000 年 1 月. この章では この章では, あなたのシステムに FreeBSD をインストールする方法について説明しています. FreeBSD は, CD-ROM, フロッピーディスク, 磁気テープ, MS-DOS パーティション, (モデムや LAN を経由できるなら) anonymous FTP や NFS を通じてインストールすることができます. どのインストール方法を利用する場合も, まず 次のセクションで説明する インストールディスクの作成から始める必要があります. あなたが今すぐにインストールするつもりがなくとも, このディスクでコンピュータを起動すれば, あなたのハードウェアを FreeBSD で利用する上で重要な情報を得ることができます. また, その情報はどのインストール方法が利用できるのかについての判断材料にもなりますし, さらに, 後々起こるかも知れない問題を解決する手がかりにもなるでしょう. もし anonymous FTP を使用してインストールすることを考えているなら, 必要な作業はインストールフロッピーを用意することだけです. インストールプログラムは自動的に, 他に必要なものを用意してくれます. FreeBSD の入手に関する詳しい情報は, 付録の FreeBSD の入手方法 をご覧ください. さて, これまでの説明では, まだ具体的に何をすれば良いのかはっきりしないと思います. 続いて, 次のインストールガイドへ進んでください. インストールガイド この節では FreeBSD のインストールの準備から, 実際にインストールするところまでをひととおり解説しています. もし, 何か足りないな, と思われる部分に気付かれましたら, &a.doc; まで電子メールでお知らせください. 訳注 &a.doc; へのメールは英語でお願いします. 日本語訳に関するお問い合わせや, 英語でのやりとりが不安な方は &a.jp.doc-jp; まで日本語でお問い合わせください. インストールの準備 FreeBSD をインストールするには, その前にさまざまな準備作業が必要になります. これから, それぞれのインストール方法に対して どのような下準備が必要かを説明します. まず最初に, あなたの使っているハードウェアが FreeBSD でサポートされているかどうか確認しなければなりません. これには, サポートされている設定一覧 の節が便利です. ;-) SCSI コントローラやイーサネットアダプタ, サウンドカード等, あなたのマシンが装備している拡張カードのリストを作っておくと良いでしょう. このリストには割り込み番号 (IRQ) や IO ポートのアドレスといった, 拡張カードの設定に関する内容も書いておきます. インストールフロッピーの作成 何枚かのフロッピーディスクを用意します. これらのディスクは あなたのコンピュータを起動して, インストーラを起動するのに使用します. この手順は, あなたのシステムが CDROM からの起動をサポートしていて, CDROM からインストールを行う場合には必要ありません. もしそうでなければ, 起動用のフロッピーが必要です. あなたのシステムが CDROM からの起動をサポートしているかどうかわからない場合は, 試してみてください. 普通にドライブに CDROM を入れてシステムを再起動します. その際, システムがハードディスクよりも先に CDROM から起動を試みるように, BIOS の設定を変更する必要が あるかも知れません. もしあなたが CDROM を持っていても, ファイルをダウンロードすることには意味があります. それは, CD がリリースされた後に FreeBSD のインストーラのバグが見つかった場合, FTP サイトのイメージは速やかに修正されるからです. 当たり前のことですが, プレスされた後の CD が修正されることはありません. 起動フロッピーイメージの入手 イメージは .flp という拡張子のファイルです. FreeBSD の CD-ROM を持っている場合は, floppies サブディレクトリの中にあります. また, FreeBSD の FTP サイトの floppies ディレクトリおよび, そのミラーサイトからイメージをダウンロードすることも可能です. ファイルの名前は (時々) FreeBSD のリリースによって, またインストールを行うアーキテクチャによっても異なります. FTP サイトにあるインストール用起動ディスクのイメージに関する説明において, あなたが必要とするファイルに関する最新の情報が提供されています. フロッピーディスクの準備 ダウンロードしたイメージファイル一つに対して, 欠陥の無いフロッピーディスクを一枚用意する必要があります. 欠陥が無いことを確認する簡単な方法は, ディスクをフォーマットしてみることです. フォーマット済みで販売されているフロッピーディスクを信頼してはいけません. FreeBSD をインストールしようとした時に, インストーラがクラッシュもしくはフリーズしてしまったり, 不正な振る舞いをする場合にまず疑わなけばならないのは, 起動フロッピーです. 別のディスクにイメージファイルを書き込んで, もう一度試してみてください. イメージファイルのフロッピーディスクへの書き込み kern.flp というイメージファイルは, ディスクにコピーする通常ファイルではありません. これらはディスク全体の内容を含んだイメージファイルです. したがって, DOS の copy のような コマンドを使用してファイルを書き込むことはできません. これには, イメージを直接ディスクに書き込む特別なツールを使用する必要があります. もし DOS が動いているコンピュータ上でフロッピーを作成する場合は, わたしたちが提供する fdimage というツールを使用します. E: にある CD-ROM を利用して起動フロッピーを作成するには, 次のようにします. E:\> tools\fdimage floppies\kern.flp A: これをそれぞれの .flp ファイルに対して 毎回新しいフロッピーディスクに入れ換えながら繰り返します. コマンドは .flp の存在する場所に応じて調整してください. もし CD-ROM を持っていない場合には, FreeBSD の FTP サイトの tools ディレクトリから fdimage をダウンロードすることができます. (他の FreeBSD システムなどの) UNIX システム上で 起動フロッピーに書き込む場合は, &man.dd.1; コマンドが利用できます. FreeBSD 上でなら, コマンドの実行は次のようになるでしょう. &prompt.root; dd if=kern.flp of=/dev/rfd0 FreeBSD 上で /dev/rfd0 は 一台目のフロッピーディスク (A: ドライブ) を表し, /dev/rfd1 は同様に, 二台目のフロッピーディスク (B: ドライブ) を表します. 他の異なる UNIX システムでは, フロッピーディスクのデバイスに 違う名前が使われているかも知れません. 必要に応じて, それぞれのシステムに付属する文書を参照する必要があるでしょう. CDROM からインストールする前に あなたの CDROM ドライブが FreeBSD でサポートされない型である場合は, MS-DOS パーティションのセクションをご覧ください. BSDi の FreeBSD CD-ROM からインストールする場合は, 準備作業のすべてを行なう必要はありません (その他の CDROM でもそうだと思いますが, わたしたちはその CDROM の構成を知りませんので, 確実にそうかどうかはわかりません). Walnut Creek の CD-ROM に収録されている install.bat で直接 FreeBSD を起動することもできますし, makeflp.bat で起動フロッピーディスクをつくることも可能です. CD が El Torrito 規格の起動をサポートしていて, あなたのシステムが CDROM から直接起動する機能をサポートしているなら (多くの古いシステムは サポートしていません), 単に FreeBSD の CD の一枚目をドライブに CD を入れてシステムを再起動してください. すると CD から直接起動して, インストールメニューが表示されます. MS-DOS パーティションからインストールするつもりでいて, CD ドライブにアクセス可能なドライバが組み込まれているなら, CDROM に入っている install.bat スクリプトを起動してください. これは, DOS から直接 FreeBSD のインストールへと進みます. これは本当の DOS から行なわなければいけません (たとえば DOS モードで起動するなど). Windows の DOS プロンプトからでは駄目です. - (DOS から) 最も簡単なインターフェースを使うには, + (DOS から) 最も簡単なインタフェースを使うには, view と入力してください. すると DOS メニューユーティリティが起動し, 可能なすべてのインストール方法の選択ができるようになります. UNIX システム上で起動フロッピーを作成する場合は, このガイドのインストールフロッピーの作成のセクションを参照してください. DOS から, もしくはフロッピーディスクからの起動が完了したら, インストールプログラムでインストールメディアとして CDROM を選択することができるようになっているはずです. すべての配布ファイルは, CDROM から読み込まれますので, 他の種類のインストールメディアは不要です. システムのインストールがすべて終わって (ハードディスクから) 再起動したら, 次のように入力することで, いつでも CDROM をマウントすることができます: &prompt.root; mount /cdrom CD をドライブから取り出す前にはまず, 必ずアンマウントする必要があります. アンマウントは次のコマンドで行なうことができます. &prompt.root; umount /cdrom 単純にドライブから取り出さないように! インストールに入る前に CD-ROM をドライブに入れておいて, インストールフロッピーディスクが立ち上がるときに CD-ROM を見つけられるようにしておくようにしましょう. CD-ROM をデフォルトでシステムにつけ加えたい場合も CD-ROM を入れておきます (インストールメディアとして実際に CDROM を選択しない場合も同様). おわりに, あなたのマシンの CD-ROM を直接使って, FTP 経由で別のマシンに FreeBSD をインストールさせたいとします. やり方は簡単です. あなたのマシンのインストールが終了した後に, vipw コマンドを使って, passwd ファイルに以下の行を追加します. ftp:*:99:99::0:0:FTP:/cdrom:/nonexistent こうするとあなたのマシンにネットワーク接続できる人 (そして, login 許可を持っている人) は, メディアタイプとして FTP を選択できるように なります. 具体的には, FTP サイトの選択メニューから “Other” を選択して, ftp://あなたのマシンのアドレス を入力します. もしインストールの途中であなたのシステムの anonymous FTP を有効にしたなら, 上の設定はインストーラが自動的に 行います. フロッピーディスクからのインストールの前に あなたがフロッピーディスクからのインストールをしなくては ならない場合 (私たちはこの方法を とらない ことを強く提案します), その理由はハードウェアがサポートされてなかったためか, 単にいばらの道を通ることを楽しんでいるからでしょうが, インストール用の フロッピーディスクを用意する必要があります. 最低でも bin (基本配布ファイル) ディレクトリ内のすべてのファイル を入れられるだけの 1.44 メガバイトか 1.2 メガバイトのフロッピーディスク が必要です. これらのフロッピーディスクを DOS で作成している場合は, フロッピーディスクは「MS-DOS の FORMAT コマンドでフォーマット」 されなくてはなりません. Windows をお使いの場合は, Windowsのエクスプローラを使用してディスクを 初期化してください. (A: ドライブを 右クリックして, "フォーマット"を選択します). 工場での初期化済みディスクを「信用しないでください」. 念のためにあなた 自身でフォーマットし直してください. ユーザからのトラブル報告の多くは ちゃんと初期化されていないディスクを 使用していたことが原因となっています. 私が特にフォーマットし直してくださいと述べているのも, この理由からです. 他の FreeBSD マシンでフロッピーディスクを作成している場合, フォーマットすることは悪いことではありません. いちいち DOS ファイルシステムのフロッピーディスクを作成する必要は ありませんので, disklabel コマンドと newfs コマンドを使って, 次のような手順で (3.5 インチ 1.44 メガバイトディスク用の) UFS ファイルシステムを 作成することもできます. &prompt.root; fdformat -f 1440 fd0.1440 &prompt.root; disklabel -w -r fd0.1440 floppy3 &prompt.root; newfs -t 2 -u 18 -l 1 -i 65536 /dev/rfd0 5.25 インチの 1.2 メガバイトディスクの場合は "fd0.1200" と "floppy5" にしてください これで他のファイルシステムと同様に mount して書き込むことができます. フォーマットされたフロッピーディスクを用意したら, それらにファイル をコピーしなくてはなりません. 配布ファイルはいくつかのかたまり にわかれていて, これらのかたまり五つで一般的な 1.44 メガバイトの フロッピーディスクに収まるようになっています. フロッピーディスクに 入るだけファイルを入れていって, 配布ファイルをすべてコピーしてください. それぞれの配布ファイルはサブディレクトリに コピーする必要があります. たとえば, a:\bin\bin.aaや, a:\bin\bin.abのようになります. インストールメディアの選択場面になったら, Floppy を選択して, 残りの指定をやってください. ハードディスクの MS-DOS パーティションからインストールする前に ハードディスクの MS-DOS パーティションからインストールするときは, まずファイルを c:\freebsd にコピーします. CD-ROM にあるディレクトリ構造を反映してコピーしなくてはなりません. そこで, DOS の xcopy コマンドの使用をおすすめします. たとえば, FreeBSD の最低限のインストールをするには, このような手順で コピーします. C:\> md c:\FreeBSD C:\> xcopy e:\bin c:\FreeBSD\bin\ /s C:\> xcopy e:\manpages c:\FreeBSD\manpages\ /s ここで, C: ドライブには十分なディスクスペースが残っており, CD-ROM は E: ドライブに接続されているものとします. CDROM ドライブを持っていない場合, ftp.FreeBSD.org から配布ファイル (DISTS) をダウンロードすることができます. それぞれの配布ファイル (DISTS) は, それぞれ独自の ディレクトリに入っています; たとえば, bin 配布ファイルは &rel.current;/bin ディレクトリにあります. MS-DOS からたくさんの配布ファイル (DISTS) をインストールしたい (そしてディスクの余裕がある) 場合は, それぞれ c:\freebsd ディレクトリにコピーします — BIN 配布ファイルは, 最低限必要なものです. QIC/SCSI テープからのインストールの前に テープからのインストールは, おそらく FTP を利用したオンライン インストールか, CD-ROM を利用したインストールができない場合の, もっとも簡単な方法でしょう. インストールプログラムは, 以下のような コマンドを使用して, 単純に配布ファイルがテープ上に tar されていることを 期待しています. &prompt.root; cd /freebsd/distdir &prompt.root; tar cvf /dev/rwt0 dist1 ... dist2 インストールに入る前に, テンポラリ (一時使用) ディレクトリに 十分なディスクスペースを確保して, 作成したテープのすべての ファイルを格納できることを確認してください (テンポラリディレクトリは 自分で選ぶことができます). テープの特性上, ランダムにアクセスするこ とができませんので, 一時的に極めて大量の容量を必要とします. テープに準備しただけの量のディスクスペースを 一時的に使用することに 留意してください. インストールに入るときは, 起動フロッピーディスク から立ち上げる 前 にテープをドライブに入れておかなくてはなりません. さもないとインストール時のデバイス検出のときにテープを 見つけられません. ネットワーク経由のインストールの前に 三つの物理的な接続形態で, ネットワーク経由のインストールを おこなうことができます. シリアルポート (SLIP もしくは PPP), パラレルポート (PLIP (laplink ケーブル使用)), またはイーサネット (標準的なイーサネットコントローラ (いくつかの PCMCIA カードにも対応)) を使用することができます. SLIP のサポートはまだまだ原始的とも呼べる方法なので, ラップトップと 他のコンピュータをシリアルケーブルで接続するといった具合いに, 直接接続してなくてはいけません. SLIP インストールは, ダイヤル機能を 持っていませんので, インストールするためには直接接続しなくてはなりません. PPP インストールではダイヤルアップ接続が可能ですので, できれば PPP 接続の 方を選択しましょう. もしもあなたがモデムを使用しているなら, あなたに残された選択肢は ほぼ間違いなく PPP インストールでしょう. インストール時に必要になりますので, サービスプロバイダ (ISP) に関する情報を用意しておきましょう. PPP ダイヤルの際は, とてもシンプルな端末エミュレーターで 作業することになります. もし ISP に接続するのに PAP や CHAP を用いるなら (言い換えると, もしあなたが Windows で ISP に接続する時に スクリプトを使用していないのであれば), dial と ppp のプロンプトに対して入力 するだけでいいです. しかしそれ以外の場合は, お手持ちのモデムで ISP にダイヤルするための“ATコマンド”の使い方を 知っておく必要があります. これ以上の情報については, handbook や FAQ のユーザー PPP エントリーを参照してください. 問題が起きた場合には, set log local ... コマンドを用いてログを画面に吐くこともできます. FreeBSD (2.0R 以降) の動いている別のマシンと直接接続が可能でしたら, laplink パラレルポートケーブルで接続することを考えてみましょう. パラレルポート経由のデータ転送スピードは, シリアルラインでの 一般的なスピード (最高 50kbit/sec) よりもずっと高速ですので, 高速にインストールすることができます. 最後になりますが, ネットワークインストールのうちでもっとも高速なものとしては イーサネットアダプタを使用するのがあげられます. FreeBSD ではきわめて多くの PC イーサネットカードをサポートしています. サポートされている カードの表 (と, 必要な設定) は, サポートされているハードウェア に書いてあります. サポートされている PCMCIA カードを使っている場合には, ラップトップの電源を 入れる「前」に差し込んでおくことにも注意してください. 残念ながら今の FreeBSD は, インストール時の活線挿抜には対応していません. ネットワークでの IP アドレス, あなたのアドレスクラスに対応した ネットマスク, マシン名を知っておくことも必要です. PPP 接続を利用したインストールを行いたいけれども固定 IP アドレスを持っていないという場合は, ISP が自動的に IP アドレスを割り当てます. ネットワーク管理者の方に たずねればどんな値を使ったらよいかを教えてくれるでしょう. もしも他のホストを IP アドレスではなくて名前で引きたい場合, ネームサーバとゲートウェイ のアドレスも知らなくてはなりません (PPP をご使用の場合は, プロバイダの IP アドレスになります). HTTP proxy (下記参照) 経由で FTP インストールを行いたい場合は, proxy サーバのアドレスも必要になります. これらのうちのすべて, またはいくつかを 知らない場合は, イーサネット経由でのインストールを始める前に「まず」 ネットワーク管理者に相談してください. NFS インストールのための下準備 NFS インストールはまったく単純明解です. FreeBSD の配布ファイルを サーバの好きな場所にコピーしておいて, メディア選択で NFS を選択します. もしサーバが privileged (特権) ポート へのアクセスのみをサポート している場合, (Sun ワークステーションの標準ではこうなっています) インストールを進める前に Options メニューを選択して, ``privileged port'' オプションを選択してください. イーサネットカードの性能が悪くて, 転送速度が遅くて困っている場合も, 適当な Options を選択するとよいでしょう. NFS 経由でインストールするためには, サブディレクトリも 含めたマウントにサーバが対応している必要があります. たとえば, FreeBSD &rel.current; の配布ファイルが ziggy:/usr/archive/stuff/FreeBSD にあるとすると, マシン ziggy では /usr や /usr/archive/stuff だけではなく, /usr/archive/stuff/FreeBSD の直接マウントが可能に なっていなければなりません. FreeBSD の /etc/exports ファイルでは, このことは オプションによって制御されています. 他の NFS サーバの場合だとまた話が違ってくるかもしれません. もしもサーバから permission denied というメッセージが 返ってくるようでしたら, サブディレクトリマウントをちゃんと 有効にできていないことが考えられます. FTP インストールのための下準備 FTP 経由のインストールは, FreeBSD &rel.current; の最新バージョンを ミラーしているどのサイトからでも可能です. 世界中の妥当な FTP サイトの 選択肢をメニューに並べておきました. このメニューに出ていない他の FTP サイトからインストール する場合や, ネームサーバの設定に問題が生じた場合は, メニューでサイト “Other” を選ぶところで, お好みの URL でサイトを指定することができます. URL として直接 IP アドレスで指定してもよく, 直接指定した場合はネームサーバ がなくても FTP インストールが可能になります. たとえば, 以下のようにします. ftp://209.55.82.20/pub/FreeBSD/&rel.current;-RELEASE FTP 経由のインストールを行う場合, active, passive, HTTP proxy 経由の三種類のモードが利用できます. FTP Active すべての FTP 転送の際に Active モードを使用します. ファイアウォール内部のマシンではうまく動きませんが, passive モードをサポートしていない古い FTP サーバでも 動作します. passive モードでの FTP 転送 (こちらが デフォルトです) が失敗した場合は, active を使ってください. FTP Passive すべての FTP 転送の際に Passive モードを使用します. このモードを使用することで, ランダムポートアクセスインを 許さないファイアウォールを 越えることができるようになります. HTTP proxy 経由の FTP この方法では, (ウェブブラウザと同様に) HTTP プロトコルを使って proxy サーバに接続し, FTP の操作を実現します. proxy サーバは FTP 要求を (訳注: HTTP から FTP に) 変換して FTP サーバに送るため, ファイアウォールが FTP 接続を禁止していても, HTTP proxy サーバが提供されていれば ファイアウォールを超えた FTP 接続を行なうことが可能です. この方法を用いる場合は, FTP サーバの他に proxy サーバを指定する必要があります. FTP proxy には HTTP proxy タイプでないものもありますが, そういったタイプは非常にまれです. どちらであるかわからないような場合は大抵, 上で述べている HTTP proxy タイプであると考えて良いでしょう. 通常 proxy FTP サーバに対しては, ユーザ名の一部として @ 記号に続いて実際に接続したいサーバの名称を与える必要が あります. そうすると proxy サーバは本当のサーバの「ふり」 をするようになります. たとえば: ftp.FreeBSD.org から ポート番号 1234 で要求を待つ proxy FTP サーバ foo.bar.com を使って インストールしたいとします. この場合では, 「オプション」メニューで FTP username を ftp@ftp.FreeBSD.org, パスワードとして自分の電子メールアドレス を指定します. インストールメディアとして FTP (または proxy サーバがサポートしていれば passive FTP), URL を以下のようにします: ftp://foo.bar.com:1234/pub/FreeBSD ftp.FreeBSD.org の /pub/FreeBSD に対する FTP 要求については foo.bar.com が代理で処理をおこなうことになり, むこう のマシンからインストールすることができます (インストール時 の要求により ftp.FreeBSD.org からファイルをもってきます). BIOS によるドライブの番号付けの確認 BIOS の, ケーブルのつなぎ直しを必要としない番号の 付け替え機能を利用している場合は, 混乱しないように, まずはじめに を読んでください. FreeBSD のインストール ここまでのインストールの準備段階を状況に応じて完全に行うと, FreeBSDをインストールする準備が整います. 何かうまくいかなかった場合は, あなたが使おうとしている インストールメディアのことが書いてある箇所まで戻って もう一度読むとよいでしょう. おそらく最初読んだときに 見落していた, 有効なヒントがあるものと思います. ハードウェアの問題が出てきたとか, FreeBSD がまったく 立ち上がらない場合は, boot フロッピーディスクに提供されている Hardware Guide を読んで, 何か解決方法はないか探してください. FreeBSD の起動フロッピーディスクには, インストールをおこなうために 必要と思われるすべてのオンラインドキュメントを用意してあります. もしもそのドキュメントがお望みのものでないようでしたら, 私たちはあなたが何にもっとも困っているのかを知りたいと思います. コメントを &a.doc; にお送りください. FreeBSD のインストールプログラム (sysinstall) を, うっとうしい step-by-step ガイドなしに, プログラム自身で使用方法がわかるようにするのが最終目標です. 目標達成までには時間がかかりそうですが, ともかくそれが 目標なのであります :-) 閑話休題. ここに, 典型的なインストールの手順 を まとめてみましたので, お役にたてるものと思います. kern.flp を書き込んだフロッピーで 起動します. その後, 指示に従ってこれを取り出し, mfsroot.flp を書き込んだフロッピーを ドライブに入れ return キーを叩きます. ハードウェアの性能に よりますが, 起動には 30秒から 3分かかります. 起動したら 初期選択画面が出てくるでしょう. もしも kern.flp からまったく起動 しなかったり, どこかの段階で起動が止まってしまった 場合は, ハードウェアガイド の Q&A を読んで, 理由を探ってみます. F1 キーを叩きます. メニューシステムとインストールプログラム 全般に対しての使い方が表示されます. このメニューシステムを 使ったことがない場合は, 徹底的に読んでください. Options を選択し, 他に必要な特別な選択を おこないます. 典型的なインストールでおまかせしたいか, それぞれの段階をいちいちコントロールしたいか (可能であれば適切なデフォルトを使用して) 簡単にさっさと 済ませたいかによってそれぞれ, Standard, Custom, または Express を選択してください. FreeBSD を初めて使う方には, Standard を一番におすすめします. final configuration メニューからは, メニュー形式のさらに 進んだ設定をおこなうことができます. ネットワーク周りの 設定は, 特に CD-ROM / テープ / フロッピーディスクから インストールして, まだネットワーク設定をおこなっていない 人にとっては特に重要でしょう. インストールの時点できちんと 設定しておけば, ハードディスクからシステムを立ち上げ直した 時点でネットワーク接続ができるようになっていることでしょう. サポートされているハードウェア 現在 FreeBSD は, ISA, VLB, EISA, PCI バスを搭載した, 386SX から Pentium クラス までのさまざまな種類の PC で動作します (386SX はおすすめではありません). IDE, ESDIドライブや, さまざまな SCSI コントローラ, ネットワークカードや シリアルカードにも対応しています. FreeBSD は IBM のマイクロチャネル (MCA) バスもまたサポートしています. FreeBSD を走らせるには, 最低 8メガバイトの RAM が推奨されます. あなたのハードウェアによっては, それより少ないメモリでは 問題が発生する可能性があるため, 16メガバイトの RAM を推奨します. 以下のリストは, 現在 FreeBSD で動作が確認されているハードウェアの リストです. 他のハードウェアでも問題なく動いていると思いますが, 私たちのところには情報は入ってきていません. ディスクコントローラ WD1003 (あらゆる MFM/RLL) WD1007 (あらゆる IDE/ESDI) IDE ATA Adaptec 社製 1535 ISA SCSI コントローラ Adaptec 社製 154X シリーズ ISA SCSI コントローラ Adaptec 社製 174X シリーズ EISA SCSI コントローラ (スタンダード, エンハンスドモード) Adaptec 社製 274X/284X/2920C/294X/2950/3940/3950 (Narrow/Wide/Twin) シリーズ EISA/VLB/PCI SCSI コントローラ Adaptec 社製 AIC-7850, AIC-7860, AIC-7880, AIC-789X オンボード SCSI コントローラ Adaptec 社製 1510 シリーズ ISA SCSI コントローラ (起動デバイスとしては使用できません) Adaptec 社製 152X シリーズ ISA SCSI コントローラ AHA-152X および SoundBlaster SCSI カードなどの Adaptec 社製 AIC-6260 および AIC-6360 を使用したボード. AdvanSys 社製 SCSI コントローラ (全てのモデル). BT-948, BT-958, BT-9580 などの BusLogic 社製 MultiMaster W シリーズホストアダプタ. BT-946C, BT-956C, BT-956CD, BT-445C, BT-747C, BT-757C, BT-757CD, BT-545C, BT-540CF などの BusLogic 社製 MultiMaster C シリーズホストアダプタ. BT-445S, BT-747S, BT-747D, BT-757S, BT-757D, BT-545S, BT-542D, BT-742A, BT-542B などの BusLogic 社製 MultiMaster S シリーズホストアダプタ. BT-742A, BT-542B などの BusLogic 社製 MultiMaster A シリーズホストアダプタ. BusLogic 社製 MultiMaster の完全なクローンである AMI 社製 FastDisk コントローラもサポートされます. BusLogic/Mylex 社製 Flashpoint アダプタはまだサポートされていません. DPT 社製 SmartCACHE Plus, SmartCACHE III, SmartRAID III, SmartCACHE IV, および SmartRAID IV SCSI/RAID コントローラ. DPT 社製 SmartRAID/CACHE V はまだサポートされていません. DPT 社製 PM3754U2-16M SCSI RAID コントローラは サポートされています. Compaq 社製 Intelligent Disk Array コントローラ: IDA, IDA-2, IAES, SMART, SMART-2/E, Smart-2/P, SMART-2SL, Integrated Array, および Smart Arrays 3200, 3100ES, 221, 4200, 4200, 4250ES. ASUS 社製 SC-200, Data Technology 社製 DTC3130 (およびその変種すべて), Diamond 社製 FirePort (すべて), NCR 社製のカード (すべて), SymBios 社製のカード (すべて), Tekram 社製 DC390W, 390U, および 390F, それに Tyan 社製 S1365 などの SymBios 社(旧 NCR 社)製 53C810, 53C810a, 53C815, 53C820, 53C825a, 53C860, 53C875, 53C875j, 53C885, および 53C896 PCI SCSI コントローラ QLogic 社製 1020, 1040, 1040B, および 2100 など SCSI および Fibre Channel アダプタ DTC 社製 3290 EISA SCSI コントローラの 1542 エミュレーションモード サポートされている SCSI コントローラのすべてで, ハードディスク, 光ディスク, テープドライブ (DAT および 8mm Exabyte を含む), メディアチェンジャ, プロセッサターゲットデバイスおよび CD-ROM といった SCSI-I, SCSI-II 周辺機器が利用可能です. CDROM コマンドをサポートする WORM デバイスは, CDROM ドライバを使用することで読み込みアクセスのみサポートされます. WORM/CD-R/CD-RW への書き込みは Ports ツリーにある cdrecord によってサポートされます. 現在, 次にあげるタイプの CD-ROM ドライブがサポートされてます. cd - SCSI インタフェース (ProAudio Spectrum および SoundBlaster SCSI を含む) matcd - 松下 / Panasonic (Creative SoundBlaster) 独自のインタフェース (562/563 モデル) scd - ソニー 独自のインタフェース (全モデル) acd - ATAPI IDE インタフェース 以下のドライバは従来の SCSI サブシステムでサポートされていたものですが, 新しい CAM SCSI サブシステムではまだサポートされていません: NCR5380/NCR53400 (ProAudio Spectrum) SCSI コントローラ UltraStor 社製 14F, 24F, および 34F SCSI コントローラ Seagate 社製 ST01/02 SCSI コントローラ Future Domain 社製 8XX/950 シリーズ SCSI コントローラ WD7000 SCSI コントローラ UltraStor 社製ドライバについては, 現在新しい CAM フレームワークへ移植作業中のものがあります. しかし, いつ完成するか, そもそも完成するのかどうか, わかりません. 次のドライバは保守されていないので動作しないかもしれません: フロッピーテープ インタフェース (Colorado/Mountain/Insight) mcd - Mitsumi 独自の CD-ROM インタフェース (全モデル) ネットワークカード Adaptec 社製 AIC-6195 Fast Ethernet コントローラチップを使用した Fast Ethernet アダプタ: Adaptec 社製 Duralink PCI Fast Ethernet アダプタ ANA-62011 64-bit シングルポート 10/100baseTX アダプタ ANA-62022 64-bit デュアルポート 10/100baseTX アダプタ ANA-62044 64-bit 4 ポート 10/100baseTX アダプタ ANA-69011 32-bit シングルポート 10/100baseTX アダプタ ANA-62020 64-bit シングルポート 100baseFX アダプタ Allied-Telesys 社製 AT1700 および RE2000 カード Alteon Networks 社製 PCI ギガビット Ethernet NIC など Tigon 1 および Tigon 2 チップセットを使用した ギガビットイーサネットカード. 他に Alteon 社製 AceNIC (Tigon 1 および 2), 3Com 社製 3c985-SX (Tigon 1 および 2), Netgear 社製 GA620 (Tigon 2), Silicon Graphics 社製 ギガビット Ethernet, DEC/Compaq 社製 EtherWORKS 1000, NEC 社製 ギガビット Ethernet AMD 社製 PCnet/PCI (79c970 および 53c974 または 79c974) RealTek 社製 8129/8139 を使用した Fast Ethernet NIC Allied-Telesys 社製 AT2550 Allied-Telesys 社製 AT2500TX Genius 社製 GF100TXR (RTL8139) NDC Communications 社製 NE100TX-E OvisLink 社製 LEF-8129TX OvisLink 社製 LEF-8139TX Netronix Inc. 社製 EA-1210 NetEther 10/100 KTX-9130TX 10/100 Fast Ethernet Accton 社製 Cheetah EN1207D (MPX 5030/5038; RealTek 8139 クローン?) SMC 社製 EZ Card 10/100 PCI 1211-TX LinkSys 社製 EtherFast LNE100TX, NetGear 社製 FA310-TX Rev. D1, Matrox 社製 FastNIC 10/100, Kingston 社製 KNE110TX など Lite-On 社製 98713, 98713A, 98715 および 98725 を使用した Fast Ethernet NIC. NDC Communications 社製 SFA100A (98713A), CNet 社製 Pro120A (98713 または 98713A), CNet 社製 Pro120B (98715), SVEC 社製 PN102TX (98713) など Macronix 社製 98713, 98713A, 98715, 98715A および 98725 を使用した Fast Ethernet NIC. LinkSys 社製 EtherFast LNE100TX version 2 など Macronix/Lite-On 社製 PNIC II LC82C115 を使用した Fast Ethernet NIC Trendware 社製 TE100-PCIE など Winbond 社製 W89C840F を使用した Fast Ethernet NIC Hawking Technologies 社製 PN102TX および D-Link 社製 DFE-530TX など, VIA Technologies 社製 VT3043 Rhine I および VT86C100A Rhine II を使用した Fast Ethernet NIC Silicon Integrated Systems 社製 SiS 900 および SiS 7016 を使用した PCI fast Ethernet NIC D-Link 社製 DFE-550TX など Sundance Technologies 社製 ST201 を使用した PCI fast ethernet NIC SysKonnect 社製 SK-984x を使用した PCI ギガビット Ethernet カード. SK-9841 1000baseLX (シングルモード Fiber, シングルポート), SK-9842 1000baseSX (マルチモード Fiber, シングルポート), SK-9843 1000baseLX (シングルモード Fiber, デュアルポート) および SK-9844 1000baseSX (マルチモード Fiber, デュアルポート) など. Compaq 社製 Netelligent 10, 10/100, 10/100 Proliant, 10/100 デュアルポート, 10/100 TX Embedded UTP, 10 T PCI UTP/Coax および 10/100 TX UTP, Compaq 社製 NetFlex 3P, 3P Integrated および 3P w/BNC, Olicom 社製 OC-2135/2138, OC-2325, OC-2326 10/100 TX UTP および Racore 社製 8165 10/100baseTX and 8148 10baseT/100baseTX/100baseFX multi-personality カード など Texas Instruments 社製 ThunderLAN を使用した PCI NIC ADMtek 社製 AL981 および AN985 ベースの PCI Fast Ethernet NIC Alfa Inc. 社製 GFC2204 および CNet 社製 Pro110B など ASIX Electronics 社製 AX88140A を使用した PCI NIC DEC 社製 EtherWORKS III NIC (DE203, DE204 および DE205) DEC 社製 EtherWORKS II NICs (DE200, DE201, DE202 および DE422) DEC 社製 DC21040, DC21041 または DC21140 ベースの NIC (SMC 社製 Etherpower 8432T, DE245 およびその他のもの) DEC 社製 FDDI (DEFPA/DEFEA) NIC Efficient 社製 ENI-155p ATM PCI FORE 社製 PCA-200E ATM PCI 富士通 社製 MB86960A/MB86965A HP 社製 PC Lan+ カード (モデルナンバー: 27247B および 27252A) Intel 社製 EtherExpress ISA (ドライバが不安定なため推奨しません) Intel 社製 EtherExpress Pro/10 Intel 社製 EtherExpress Pro/100B PCI Fast Ethernet Isolan 社製 AT 4141-0 (16 ビット) Isolink 社製 4110 (8 ビット) Novell 社製 NE1000, NE2000 および NE2100 Ethernet インタフェース RealTek 社製 8029, NetVin 社製 5000, Winbond 社製 W89C940, Surecom 社製 NE-34, VIA 社製 VT86C926 など NE2000 をエミュレートする PCI ネットワークカード. 3Com 社製 3C501, 3C503 Etherlink II, 3C505 Etherlink/+, 3C507 Etherlink 16/TP, 3C509, 3C579, 3C589 (PCMCIA), 3C590/592/595/900/905/905B/905C PCI および EISA (Fast) Etherlink III / (Fast) Etherlink XL, 3C980/3C980B Fast Etherlink XL サーバ アダプタ, 3CSOHO100-TX OfficeConnect アダプタ 東芝 Ethernet カード IBM 社および National Semiconductor 社製 PCMCIA Ethernet カードもサポートされています. USB 接続の周辺機器 様々な USB 接続の周辺機器がサポートされています. このリストに機種名は書かれていません. しかしいくつかの例外はありますが, ここに書かれている種類のほとんどすべてのデバイスが サポートされます. USB キーボード USB マウス USB プリンタ および USB - パラレル プリンタ変換ケーブル USB ハブ マザーボードのチップセット: ALi 社製 Aladdin-V Intel 社製 82371SB (PIIX3) および 82371AB および EB (PIIX4) チップセット NEC 社製 uPD 9210 ホストコントローラ VIA 社製 83C572 USB ホストコントローラ およびその他の UHCI または OHCI に準拠した マザーボードのチップセット (現在使用できないものは知られていません). PCI プラグイン USB ホストコントローラ ADS Electronics 社製 PCI プラグインカード (2 ポート) Entrega PCI プラグインカード (4 ポート) 動作が報告されている個々の USB デバイス: Agiler マウス 29UO Andromeda ハブ Apple iMac マウスおよびキーボード ATen パラレルプリンタアダプタ Belkin F4U002 パラレルプリンタアダプタ および Belkin 社製 マウス マウスポートが付属した BTC 社製 BTC7935 キーボード Cherry G81-3504 Chic マウス Cypress マウス Entrega USB - パラレル プリンタアダプタ Genius 社製 Niche マウス Iomega 社製 USB Zip 100 MB Kensington 社製 Mouse-in-a-Box Logitech 社製 M2452 キーボード Logictech 社製 ホイールマウス (3 ボタン) Logitech 社製 PS/2 / USB マウス (3 ボタン) MacAlly 社製マウス (3 ボタン) MacAlly 社製 self-powered ハブ (4 ポート) Microsoft 社製 Intellimouse (3 ボタン) Microsoft 社製キーボード NEC 社製ハブ Trust Ami マウス (3 ボタン) ISDN (European DSS1 [Q.921/Q.931] プロトコル) Asuscom 社製 I-IN100-ST-DV (実験的なドライバ, おそらく動作します) Asuscom 社製 ISDNlink 128K AVM A1 AVM Fritz!Card classic AVM Fritz!Card PCI AVM Fritz!Card PCMCIA (現在は FreeBSD 3.x のみ) AVM Fritz!Card PnP (現在は FreeBSD 3.x のみ) Creatix ISDN-S0/8 Creatix ISDN-S0/16 Creatix ISDN-S0 PnP Dr.Neuhaus Niccy 1008 Dr.Neuhaus Niccy 1016 Dr.Neuhaus Niccy GO@ (ISA PnP) Dynalink 社製 IS64PH (保守されていません) ELSA 社製 1000pro ISA ELSA 社製 1000pro PCI ELSA 社製 PCC-16 ITK ix1 micro (現在は FreeBSD 3.x のみ) ITK ix1 micro V.3 (現在は FreeBSD 3.x のみ) Sagem Cybermod (ISA PnP, おそらく動作します) Sedlbauer Win Speed Siemens I-Surf 2.0 Stollman Tina-pp (開発途中) Teles 社製 S0/8 Teles 社製 S0/16 Teles 社製 S0/16.3 (16.3c などの c バージョンはサポートされません!) Teles 社製 S0 PnP (実験的なドライバ, おそらく動作します) 3Com/USRobotics 社製 Sportster ISDN TA 内蔵 (non-PnP バージョン) サウンドデバイス 次のサウンドカードおよびコーデックがサポートされます ('実験的なドライバ' と書かれているものをサポートしているのは, FreeBSD-CURRENT のみであり, 不安定かもしれません): 16550 UART (Midi) (実験的なドライバ, ヒントファイル中にトリックが必要です) Advance 社製 Asound 100, 110 および Logic ALS120 Aureal 社製 Vortex1/Vortex2 および Vortex Advantage ベースのサウンドコーデックは サードパーティのドライバ でサポートされます Creative Labs 社製 SB16, SB32, SB AWE64 (Gold を含む), Vibra16, SB PCI (実験的なドライバ), SB Live! (実験的なドライバ) およびほとんどの SoundBlaster 互換のカード Creative Labs 社製 SB MIDI ポート (実験的なドライバ), SB OPL3 シンセサイザ (実験的なドライバ) Crystal Semiconductor 社製 CS461x/462x オーディオアクセラレータ, CS461x MIDI ポートのサポートは実験的なものです Crystal Semiconductor 社製 CS428x オーディオコントローラ CS4237, CS4236, CS4232, CS4231 (ISA) ENSONIQ AudioPCI ES1370/1371 ESS 社製 ES1868, ES1869, ES1879, ES1888 Gravis 社製 UltraSound PnP, MAX NeoMagic 社製 256AV/ZX (PCI) OPTi931 (ISA) OSS-互換シーケンサ (Midi) (実験的なドライバ) Trident 社製 4DWave DX/NX (PCI) ヤマハ OPL-SAx (ISA) その他のデバイス AST 4 ポート シリアルカード (シェアード IRQ 使用) ARNET 8 ポート シリアルカード (シェアード IRQ 使用) ARNET (現在は Digiboard) 570/i high-speed 同期シリアルカード Boca BB1004 4 ポート シリアルカード (モデムはサポートしません) BOCA IOAT66 6 ポート シリアルカード (モデムをサポート) Boca BB1008 8 ポート シリアルカード (モデムはサポートしません) Boca BB2016 16 ポート シリアルカード (モデムをサポート) Cyclades Cyclom-y シリアルボード Moxa SmartIO CI-104J 4 ポート シリアルカード STB 4 ポート カード (シェアード IRQ 使用) SDL Communications RISCom/8 シリアルボード SDL Communications RISCom/N2 and N2pci high-speed 同期シリアルボード Specialix SI/XIO/SX マルチポート シリアルカード, SIHOST2.x より古いものおよび 拡張 (transputer ベース, aka JET) ホストカード どちらもサポートされます: ISA, EISA および PCI Stallion マルチポート シリアルボード: EasyIO, EasyConnection 8/32 & 8/64, オンボード 4/16 および Brumby Adlib, SoundBlaster, SoundBlaster Pro, ProAudioSpectrum, Gravis UltraSound および Roland MPU-401 サウンドカード Connectix QuickCam Matrox Meteor Video フレームグラバー Creative Labs Video Spigot フレームグラバー Cortex1 フレームグラバー Brooktree BT848 チップ および BT878 チップベースのフレームグラバー HP4020, HP6020, Philips CDD2000/CDD2660 および Plasmon CD-R ドライブ バスマウス PS/2 マウス 標準的な PC ジョイスティック X-10 power コントローラ GPIB および Transputer ドライブ Genius および Mustek ハンドスキャナ Floppy テープドライブ (いくつかのより古いモデルのみ, ドライバは不完全です) Lucent Technologies 社製 WaveLAN/IEEE 802.11 PCMCIA および ISA standard speed (2Mbps) および turbo speed (6Mbps) ワイヤレス ネットワークアダプタ および同様に動作するもの (NCR WaveLAN/IEEE 802.11, Cabletron RoamAbout 802.11 DS) これらのアダプタの ISA バージョンは, 実際には PCMCIA カードと ISA - PCMCIA ブリッジカードを組み合わせたものなので, どちらのデバイスも同じドライバで動作します. トラブルシューティング この節では基本的なインストールの際の, 報告された標準的な問題に対するトラブルシューティングのための情報が 書いてあります. また, FreeBSD と MS-DOS のデュアルブートを行う際の いくつかの質問と回答も書いてあります. なにかおかしいときには何をすればよいでしょうか PC アーキテクチャの様々な制限により, 100% 確実に原因を突き止めることは不可能ですが, いくつか失敗した時に できることがあります. サポートされているハードウェア を調べて, あなたのハードウェアがサポートされているかどうか 確認してください. もしあなたのハードウェアがサポートされているにもかかわらず, 動作しなかったり他の問題点がある時は, コンピュータをリセットして, ビジュアルカーネルコンフィギュレーション オプションを与えているときにはそれを選択してください. ここで設定することで, あなたのハードウェアを通過するようにしたり, システムに対して情報を与えたりすることができます. 起動ディスクのカーネルは, ほとんどのハードウェアデバイスの IRQ, IO アドレス, DMA チャンネルは出荷されたままの状態であるとして 設定されています. もしハードウェアの設定が変更されていると, コンフィギュレーションエディタを使用してこれらの値を設定しなければ なりません. 存在しないデバイスを認識してしまうことにより, その後実際に存在するデバイスの認識を失敗してしまうことがあります. このような場合は, 衝突しているドライバを無効にします. スクリーン (sc0) などのインストールに必要なドライバを無効にしないでください. もし, コンフィギュレーションエディタを終了したあと, インストーラが動かなくなったり, 不思議な失敗をする場合は, 削除したり変更したりしてはいけないものを, 削除あるいは変更してしまった可能性があります. 再起動してやり直してください. コンフィギュレーションモードでは, 次のことができます: カーネルにインストールされているドライバの一覧表示. システムに存在しないドライバの変更. デバイスドライバが使用する IRQ, DRQ および IO ポートアドレスの変更. カーネルをハードウェアの設定にあわせた後, Q と叩くことで, 新しい設定で起動します. インストールが終了すると, コンフィギュレーションモードで変更した 設定は保存されますので, 毎回起動するたびに設定する必要はありません. また, カスタムカーネル を作りたくなるかもしれません. X サーバーの設定 ここはダミー MS-DOS ユーザの質問と回答 多くのユーザは, FreeBSD を MS-DOS が入っている PC にインストールしようとするでしょう. このようなシステムへの FreeBSD のインストールに関して, よく聞かれる質問が以下にあります. 助けて! FreeBSD をインストールする容量がありません! まずはじめに, すべてを消去しなければいけないのですか? あなたのマシンではすでに MS-DOS が動いていて, FreeBSD をインストールする容量がないとしても, すべての望みがなくなったわけではありません. FreeBSD CDROM や 様々な FreeBSD の FTP サイトの tools ディレクトリにある FIPS ユーティリティを使うことができます. FIPS を使用することで, すでにある MS-DOS パーティションを, もともとの内容を保存したままのパーティションと, 何も入っていない FreeBSD をインストールすることのできる パーティションの二つに分割することができます. まず, Windows のデフラグ (DEFRAG) ユーティリティ (エクスプローラ上で ハードドライブを右クリックして, デフラグ (DEFRAG) を選択) か, ノートンディスクツールを使用して, 指示に従ってデフラグメントを行ってください. その後, 再起動して, 新しい空いているスライスに, FreeBSD をインストールすることができます. あなたが行うインストール方法では, どの程度の空き容量が必要なのかということについては, Distributioins メニューを見てください. また, PowerQuest 社の Partition Magic という, とても便利な製品があります. このアプリケーションは, FIPS よりも優れた機能をもっており, あなたが (わたしのように) 良くオペレーティングシステムを追加したり, 削除したりしようとしているのであれば, 強く推奨します. しかし, このアプリケーションは, お金がかかりますし, あなたが FreeBSD を一度インストールして, そのまま使用しようと考えているのであれば, FIPS が最も良いでしょう. FreeBSD から 圧縮された MS-DOS のファイルシステムを利用することができますか? できません. Stacker(tm) や DoubleSpace(tm) などのユーティリティを使用している場合は, FreeBSD からは圧縮していない部分しか扱うことができません. 残りのファイルシステムは, 一つの巨大なファイル (Stack された, または Double Space されたファイル) として見えるでしょう. このファイルを削除しないでください. さもないと強く後悔するでしょう! 別の圧縮されていない標準 MS-DOS パーティションを作成して, MS-DOS と FreeBSD との間のやりとりに使うのがよいでしょう. 拡張 MS-DOS パーティションをマウントすることができますか? できます. DOS 拡張パーティションは FreeBSD では, D: ドライブは /dev/da0s5, E: ドライブは /dev/da0s6 などといったように, その他のスライスの終わりに配置されます. これはもちろん, 拡張パーティションが SCSI のドライブ 0 にある場合の例です. IDE ドライブでは, da の代わりに, 4.0-RELEASE およびそれ以降の場合は ad を, それ以前のバージョンでは wd を使用してください. それ以外の点では, 拡張パーティションをマウントする際も, 他の DOS ドライブをマウントするときと同様に, 以下のようにします: &prompt.root; mount -t msdos /dev/ad0s5 /dos_d diff --git a/ja_JP.eucJP/books/handbook/internals/chapter.sgml b/ja_JP.eucJP/books/handbook/internals/chapter.sgml index ecfe93032c..b890f0d288 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/kernelconfig/chapter.sgml b/ja_JP.eucJP/books/handbook/kernelconfig/chapter.sgml index e844d639a1..aec51a795a 100644 --- a/ja_JP.eucJP/books/handbook/kernelconfig/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/kernelconfig/chapter.sgml @@ -1,1192 +1,1192 @@ FreeBSD カーネルのコンフィグレーション この章では 更新/再構成: &a.jim;, 2000 年 3 月. 寄稿: &a.jehamby;, 1995 年 10 月 6 日. 訳: &a.jp.tomo;, &a.jp.yoshiaki;. 1996 年 11 月 2 日. この章では, 自分のシステムに合わせた カーネルを構築する方法について扱います. カーネルの再構築によりどんなメリットがあるのか不思議に思っていたり, 自分用のカーネルを設定し, コンパイルし, インストールする方法を 知りたいと思っているのなら, この章が役に立つでしょう. なぜカスタムカーネルを作るか? システムに合わせたカーネルの構築はほとんどすべての UNIX ユーザが 避けて通ることのできない最も重要な通過儀礼の1つです. この作業は, 多くの時間を必要としますが, あなたの FreeBSD システムに多くの利益をもたらします. 広範囲のハードウェアをサポートしなければならない GENERICカーネルとは異なり, システムに合わせたカーネルは あなたの PC のハードウェアのみをサポートします. これは, 次にあげるような利益をもたらします. 素早く起動します. カーネルはあなたのシステム上にあるハードウェアしか 検出を行わないので, あなたのシステムの起動にかかる時間は劇的に短くなります. メモリの消費量が減少します. システムに合わせたカーネルは, 大抵 GENERIC カーネルより少ないメモリしか消費しません. カーネルは常にメモリ上に存在するプロセスなので, このことは重要になります. したがって, RAM が少ないシステムでは, カーネルの再構築は大変重要です. 追加のハードウェアをサポートします. システムに合わせたカーネルは, サウンドカードなど GENERIC カーネルに存在しない デバイスのサポートを追加することができます. カスタムカーネルの構築とインストール まず, カーネル再構築に必要なディレクトリをざっと見てみましょう. ここではディレクトリはすべて /usr/src/sys 以下の相対位置で示します. また, /sys からもアクセス可能です. ここには, カーネルの各部分を構成するサブディレクトリが いくつもあります. しかし, 私たちの目的で最も重要なのは arch/conf です. ここで, あなたの システムに合わせてカーネルコンフィグレーションを編集します. それから compileディレクトリ, ここはカーネルが作られる 場所です. arch は, i386, alpha, pc98(これは 日本で普及している PC のための開発ブランチです)のいずれかを表します. 各アーキテクチャのディレクトリ内部にあるファイルはすべて そのアーキテクチャでのみ使用され, 残りのコードは FreeBSD が他のプラットフォームに移植される際に共有されます. サポートされているデバイス, ファイルシステム, オプションが, それぞれ各々のサブディレクトリに分かれている, という論理的な構成に注意してください. もし, あなたのシステムに/usr/src/sys 以下のディレクトリがなければ, カーネルのソースが インストールされていません. もっとも簡単な方法は (rootで) /stand/sysinstall を用いて以下のようにします. 設定(Configure) を選んでから 配布ファイル(Distribution) を選択し, src の中の sys をインストールしてください. つぎに, arch/confに移動して, GENERIC コンフィグレーションファイルをカーネルに与えたい名前に コピーしてください. たとえば次のようにします. &prompt.root; cd /usr/src/sys/i386/conf &prompt.root; cp GENERIC MYKERNEL 慣習として, この名前はすべて大文字でつづられます. もし, いくつかの異なるハードウェアの FreeBSDマシンを扱うなら, この名前にホスト名を含めるとよいでしょう. ここでは, 例として MYKERNEL と呼ぶことにします. この作業は root権限でおこなう必要があります. そうでなければ, permission deniedというエラーが出ます. では, MYKERNEL をあなたの好きなエディタで編集してください. もし, システムをインストールしたばかりならば, 利用できるエディタは viだけかもしれません. ここでは使い方 の説明はしませんが, 参考図書 にあるような多くの本で詳しく説明 されていますので, そちらを参照してください. FreeBSD にはより簡単なエディタとして ee があります. 初心者の方であればこちらをエディタ に選ぶとよいでしょう. まずファイルの最初の方のコメント行を編集し, あなたのコンフィグ レーションに合せて変更した点などを記述して GENERIC と区別がつく ようにしておきましょう. もし SunOSや他の BSDオペレーティングシステムでカーネルの 再構築をしたことがあれば, このファイルはとても親しみ やすいでしょう. しかし, DOSのようなその他の オペレーティングシステムしか知らない人から見れば, GENERIC コンフィグレーションファイルはとても なじみにくいものかもしれません. そのような場合は, コンフィグレーションファイル の節をゆっくりと注意深く読んでください. FreeBSD Project の最新のソースファイルと, あなたの ソースツリーを同期させている場合, アップデートを行う際には, 必ず /usr/src/UPDATING ファイルをチェックするように してください. このファイルには, FreeBSD をアップデートする際のすべての重要な情報 が書かれています. /usr/src/UPDATING は常にあなたの FreeBSD ソースファイルのバージョンと同期していますので, ハンドブックの情報よりも正確なものとなっています. FreeBSD 4.0 より前の FreeBSD を使っていて, FreeBSD 4.0 以降へはアップグレードしない, もしくはリリース版の FreeBSD を使っていて /usr/src/ ディレクトリには sys/ しか無い場合, 編集し終ったら次のコマンドによってコンパイル, インストール を行ってください. 古いバージョンの FreeBSD からカーネルをアップグレードしようと している場合, 新しいカーネルのソースファイルを取ってきた場所と 同じところから, 新しいバージョンの &man.config.8; を取ってくる 必要があるでしょう. &man.config.8; は /usr/src/usr.sbin にあるので, これらのソースファイルもダウンロードする必要が あります. 次のコマンドを実行する前に, これを再構築してインストールして おいてください. &prompt.root; /usr/sbin/config MYKERNEL &prompt.root; cd ../../compile/MYKERNEL &prompt.root; make depend &prompt.root; make &prompt.root; make install 4.X 以降の新しいバージョンにアップグレードした場合 (例えば 3.X から 4-STABLE へ, もしくは 4-STABLE から 最新版の 4-STABLE へなど), 予め buildworld を行なって, 以下のコマンドを実行してください: &prompt.root; cd /usr/src &prompt.root; make buildkernel KERNCONF=MYKERNEL &prompt.root; make installkernel KERNCONF=MYKERNEL FreeBSD-4.2 とそれ以前の場合は, KERNCONF= ではなく KERNEL= としなければなりません. 2001 年 2 月 2 日以降の 4.2-STABLE は KERNCONF= を認識します. 何らかの方法であなたのソースツリーをアップグレードして いない 場合 (CVSup, CTM, anoncvs, などを実行していない場合), config, make depend, make, make install の手順を実行してください. 最後にカーネルを構築した後で, ソースをアップグレードした場合, カーネルを構築するには make buildkernel を使わなければ なりません. そうしないと, カーネルを構築するのに古いユーティリティが 使われてしまい, 失敗してしまうかもしれません. ソースを更新した場合には, カーネルを構築するのに config/make の手順は使わないでください! 新しいカーネルはルートディレクトリに /kernelという 名前でコピーされ, 今までのカーネルは /kernel.old という名前へ変更されます. では, システムをシャットダウン, リブー トして新しいカーネルを使ってください. うまく行かない場合は, この章の終りの 問題が起きた場合には を参照してください. この章の新しい カーネルが起動しない 場合のリカバリの方法を注意深く読んでおいてください. (サウンドカードのような)新しいデバイスを 追加した場合は, 使う前に /devディレクトリで デバイスノードを追加しなければならないかもしれません. 詳しくは, デバイスノード を読んでください. コンフィグレーション ファイル コンフィグレーション ファイルの一般的なフォーマット はとてもシンプルです. 各行は1つのキーワードと1つ以上の 引数を含んでいます. 見やすくするために, ほとんどのキーワードは 引数を1つしか書いてありません. #に続くものはすべてコメントとして扱われ, 無視されます. ここでは, それぞれのキーワードについて だいたい GENERIC に出てくる順番で説明します. しかし, お互いに関係のあるキーワードは, 実際には GENERIC ファイル上に バラバラに現れていても, (ネットワーキングのように)1つにまとめ てあります. おびただしい数の オプションの一覧が GENERICと同じディレクトリの LINT コンフィグ レーションファイルにあります. もし, ある行の目的や必要性に疑 問を持ったら最初に LINT をチェックしてください. 数字と二重引用符 FreeBSD 3.x と, それまでの全てのバージョンの FreeBSD における &man.config.8; は, コンフィグレーションファイル中の テキストとして使われる数字を含む文字列が 全て二重引用符で括られていなければならないという制限があります. この制限は (このハンドブックが対象としている) 4.X ブランチでは取り除かれました. 4.X 以前のシステムを使っている場合には, サンプルとしてシステム上の /usr/src/sys/i386/conf/LINT と /usr/src/sys/i386/conf/GENERIC を参照してください. 以下は必要に応じてコメントを追加した GENERIC カーネルの コンフィグレーションファイルです. この設定例は /usr/src/sys/i386/conf/GENERIC に極めて近いものになっているはずです. その他に指定可能なカーネルオプションについては, /usr/src/sys/i386/conf/LINT を参照してください. # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # このファイルについて更に情報が必要なら, ハンドブックのカーネル # コンフィグレーションファイルのセクションを参照して下さい. # # http://www.freebsd.org/handbook/kernelconfig-config.html # # doc ディストリビューションをインストールした場合, ハンドブックは # ローカルマシンの /usr/share/doc/handbook でも見ることができます. # 最新版は FreeBSD の WWW サーバ (http://www.FreeBSD.ORG/) を参照して # 下さい. # # ./LINT コンフィギュレーションファイルには, デバイス行に関する大量の # オプションと詳細な説明があります. もしある行の目的又は必要性について # 疑問がある場合はまず LINT をチェックして下さい. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.246 2000/03/09 16:32:55 jlemon Exp $ 以下は すべての カーネルの構築に 必須のキーワードです: machine i386 マシンのアーキテクチャです. これは i386, alpha, pc98 のいずれかでなければなりません. cpu I386_CPU cpu I486_CPU cpu I586_CPU cpu I686_CPU 上記はあなたのシステムの CPU タイプを指定します. 複数の行を書いても構いません. (例: I586_CPU とすべきか I686_CPU とすべきかはっきり分からない場合. しかしながら, カスタムカーネルを作る場合, あなたの持つ CPU だけを指定するのがベストです. もしあなたがどのタイプの CPU を使っているか分からない場合, dmesg を使って起動メッセージを 調べるとよいでしょう. Alpha アーキテクチャの場合は, cpu_type に異なった値を用います. cpu EV4 cpu EV5 もしあなたが Alpha マシンを使っている場合, 上記の内のどれかを指定して下さい. ident GENERIC ここはカーネルの識別名を書きます. あなたがカーネルに付けたい名前に書き換えて下さい (MYKERNELのように). ident に書いた名前はカーネルを起動する時に 表示されるので, 普段使っているカーネルと区別したいときは違う名前を付けると 良いでしょう(例: 実験的なカーネルを構築する場合). maxusers 32 maxusers オプションは重要なシステムテーブルの サイズを決定します. この数字はあなたのマシンを同時に使うと思われるユーザー数と おおよそ等しくするのが良いでしょう. しかしながら, 通常は X ウインドウシステムを使ったり, ソフトウエアをコンパイルするでしょうから, その場合は maxusers は最低 4 にして下さい. その理由は, maxusers によって計算される最も 重要なテーブルがプロセスの最大数で, それは 20 + 16 * maxusers となります. もし, maxusers を 1 にすると, 同時に 36 プロセスしか利用できなくなりますが, システムは起動時に 18 ほどのプロセスを立ち上げ, X ウインドウシステムは 15 ほどのプロセスを立ち上げるので, man コマンドのような単純な仕事でさえフィルタ, 展開, 表示に 9 個のプロセスを利用するために, プロセス数不足になります. maxusers を 64 に設定すると, 1044 個のプロセスを同時に利用することができるので, 殆どのユーザには充分でしょう. もしあなたが別のプログラムを立ち上げる時, 恐れられている proc table full エラーが 発生する場合や, ftp.FreeBSD.org のように多数のユーザにより 同時に利用されるサーバを動かしている場合には, この数字を増やしてカーネルを再構築することができます. maxusers はあなたのマシンにログインする ユーザ数を制限するものでは ありません. それは単に, あなたのシステムを使うであろうユーザの最大数や それぞれのユーザがどれくらいのプロセスを走らせるかに 合わせて各種テーブルの大きさを設定するだけです. 同時にリモートログインする最大ユーザ数を制限するキーワードは pseudo-device pty 16 です. 以下に続くすべては大体において追加設定項目です. 詳細は各項目の次に書かれている注意書きを参照して下さい. #makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols options MATH_EMULATE #Support for x87 emulation この行では, あなたのコンピュータが浮動小数点演算コプロセッサを 持たない場合(CPU が 386 又は 486SX), カーネルにシミュレートさせるよう設定します. あなたが 486DX, 又は (387 や 487 チップを別途搭載した) 386, 486SX 又は更に上位 (Pentium, Pentium II, 他) を持っている場合は コメントアウトして下さい. FreeBSD の浮動小数点エミュレーションルーチンはあまり正確では ありません. もしあなたが浮動小数点コプロセッサを持っておらず, かつベストな演算精度が必要であれば, GNU の浮動小数点サポートを 利用する GPL_MATH_EMULATION を使ってみて下さい. このオプションはライセンス上の理由によりデフォルトでは 含まれていません. options INET #InterNETworking ネットワークのサポート. ネットワークに接続する予定がなくてもこのオプションは残して下さい. 殆どのプログラムは少なくともループバックネットワーク (あなたの PC の中でのネットワーク接続) を必要としますので, 基本的にこの行は必須です. options INET6 #IPv6 communications protocols このオプションは IPv6 通信プロトコルを利用可能にします. options FFS #Berkeley Fast Filesystem options FFS_ROOT #FFS usable as root device [keep this!] これは標準のハードドライブファイルシステムです. ハードディスクから起動する場合は残して下さい. options MFS #Memory Filesystem options MD_ROOT #MD is a potential root device これはメモリ上にマップされたファイルシステムです. これは基本的に一時ファイルの高速格納用の RAM ディスクであり, あなたが有効に利用したい大量のスワップスペースを持っている 場合には有用でしょう. 多くのプログラムが一時データをここに保存することから, MFS パーティションをマウントする最適な場所は /tmp ディレクトリです. MFS RAM ディスクを /tmp にマウントするには 次の行を /etc/fstab に追加して下さい: /dev/ad1s2b /tmp mfs rw 0 0 次に再起動するか, コマンド mount /tmp を実行して下さい. options NFS #Network Filesystem options NFS_ROOT #NFS usable as root device, NFS required ネットワークファイルシステム. UNIX ファイルサーバから TCP/IP を介してパーティションを マウントするのでない限り, これらの行をコメントアウトして下さい. options MSDOSFS #MSDOS Filesystem MS-DOS ファイルシステム. 起動時に DOS でフォーマットされたハードドライブを マウントするのでない限り, この行は安全にコメントアウトできます. この機能は最初に DOS パーティションをマウントする時に自動的に ロードされます. 又, 優秀な mtools (Ports コレクションにあります) を使ってもマウント, アンマウントすることなしに DOS フロッピーにアクセスすることができます. (MSDOSFS は必要としません) options CD9660 #ISO 9660 Filesystem options CD9660_ROOT #CD-ROM usable as root, CD9660 required CD-ROM 用の ISO 9660 ファイルシステム. もしあなたが CD-ROM ドライブを持っていないか, 時々データ CD をマウントするだけならこの行をコメントアウトしても 大丈夫です (データ CD を最初にマウントする時, 自動的にロードされます). 音楽 CD はこのファイルシステムを必要としません. options PROCFS #Process filesystem プロセスファイルシステム. これは /proc にマウントされる, ファイルシステムの ふりをする もので, &man.ps.1; のようなプログラムに, どんなプロセスが走っているか に関するより多くの情報を提供させる事ができます. options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] 4.3BSD との互換機能です. 有効なままにして下さい. この行をコメントアウトするとおかしな動きをするプログラムがあります. options SCSI_DELAY=15000 #Delay (in ms) before probing SCSI この行は, カーネルがそれぞれの SCSI 機器を検出する前に 15 秒間待つようにします. あなたが IDE ドライブしか持たないなら無視して結構です. そうでないなら, 起動時間を短くするため, おそらく待つ時間を短く, 5 秒くらいにしたいでしょう. 勿論, そうした場合に FreeBSD が SCSI 機器を認識しなくなった場合は 時間を元に戻す必要があります. options UCONSOLE #Allow users to grab the console ユーザにコンソールを所有することを許可します. X のユーザには役に立ちます. たとえば xterm -C とコマンドを打つことにより, コンソール xterm を起動することができます. ここにはカーネルからのあらゆるコンソールメッセージとともに, write, talk による あらゆるメッセージを表示します. options USERCONFIG #boot -c editor このオプションは起動メニューからコンフィグレーションエディタ を起動することができるようにします. options VISUAL_USERCONFIG #visual boot -c editor このオプションは起動メニューからビジュアルコンフィグレーション エディタを起動できるようにします. options KTRACE #ktrace(1) support この行はデバッギングに役立つカーネルプロセスのトレースを 可能にします. options SYSVSHM #SYSV-style shared memory このオプションは System V 共有メモリを提供します. この機能の最も一般的な使用方法は X における XSHM 拡張です. 多くのグラフィックス重視のプログラムではこの機能を自動的に 描画のスピードアップに利用します. X を使っているなら, これを含めておいた方がいいでしょう. options SYSVSEM #SYSV-style semaphores System V セマフォのサポート. あまり使われませんが, カーネルサイズは数百バイト大きくなるだけです. options SYSVMSG #SYSV-style message queues System V のメッセージのサポート. これもカーネルサイズを数百バイト大きくするだけです. &man.ipcs.1; コマンドを実行するとこれらの System V 機能を使っているプロセスのリストを表示します. options P1003_1B #Posix P1003_1B real-time extentions options _KPOSIX_PRIORITY_SCHEDULING リアルタイム拡張が 1993 POSIX に追加されました. Ports コレクションの内のいくつかのアプリケーション (例えば Star Office) はこれを使っています. options ICMP_BANDLIM #Rate limit bad replies このオプションは ICMP エラー応答のバンド幅制限を可能にします. サービス不能パケットによる攻撃からマシンを保護するために必要です. # To make an SMP kernel, the next two are needed #options SMP # Symmetric MultiProcessor Kernel #options APIC_IO # Symmetric (APIC) I/O 上の行は両方とも SMP サポートのために必要です. device isa FreeBSD がサポートするすべての PC はこれらの内のひとつを 持っています. あなたが IBM PS/2 (マイクロチャネルアーキテクチャ) マシンを持っている場合, FreeBSD は現時点では動作しません (サポートには取組中です). device eisa あなたが EISA マザーボードを持っている場合, この行を含めて下さい. これは EISA バスに接続されているすべての デバイスの自動検出と設定を可能にします. device pci あなたが PCI マザーボードを持っている場合, この行を含めて下さい. これは PCI カードの自動検出と PCI から ISA バスへのゲートウエイを 可能にします. # Floppy drives device fdc0 at isa? port IO_FD1 irq 6 drq 2 device fd0 at fdc0 drive 0 device fd1 at fdc0 drive 1 これはフロッピーディスクコントローラです. fd0 は A: フロッピードライブ, fd1 は B: ドライブです. device ata このドライバはすべての ATA と ATAPI デバイスをサポートします. 最近のマシンでは device ata 行を 1 行書くだけで すべての PCI ATA/ATAPI デバイスを検出することができます. device atadisk # ATA disk drives ATAPI ディスクドライブには device ata と共にこの行が必要です. device atapicd # ATAPI CDROM drives ATAPI CDROM ドライブには device ata と共にこの行が必要です. device atapifd # ATAPI floppy drives ATAPI フロッピードライブには device ata と共にこの行が必要です. device atapist # ATAPI tape drives ATAPI テープドライブには device ata と共にこの行が必要です. options ATA_STATIC_ID #Static device numbering この行はコントローラ番号を (古いドライバのように) 静的に 割り当てます. そうでない場合, デバイス番号は動的に割り当てられます. # ATA and ATAPI devices device ata0 at isa? port IO_WD1 irq 14 device ata1 at isa? port IO_WD2 irq 15 上の行は古い, PCI ではないシステムの場合の形式です. # SCSI Controllers device ahb # EISA AHA1742 family device ahc # AHA2940 and onboard AIC7xxx devices device amd # AMD 53C974 (Teckram DC-390(T)) device dpt # DPT Smartcache - See LINT for options! device isp # Qlogic family device ncr # NCR/Symbios Logic device sym # NCR/Symbios Logic (newer chipsets) device adv0 at isa? device adw device bt0 at isa? device aha0 at isa? device aic0 at isa? SCSI コントローラです. あなたのシステムにないデバイスはコメントアウトして下さい. もし IDE しかないシステムならこれらすべてを削除できます. # SCSI peripherals device scbus # SCSI bus (required) device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) SCSI 周辺機器です. あなたが持っていないデバイスはコメントアウトして下さい. もし IDE しか持っていないならこれらを完全に削除できます. # RAID controllers device ida # Compaq Smart RAID device amr # AMI MegaRAID device mlx # Mylex DAC960 family サポートされる RAID コントローラです. これらのどれも持っていない場合, すべてをコメントアウト又は 削除することができます. # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc0 at isa? port IO_KBD キーボードコントローラ (atkbdc) は AT キーボード及び PS/2 スタイルポインティングデバイスの I/O サービスを提供します. キーボードドライバ (atkbd) と PS/2 ポインティングデバイスドライバ (psm) はこのコントローラを必要とします. device atkbd0 at atkbdc? irq 1 atkbd ドライバ. atkbdc コントローラと協調して動作し, AT キーボードコントローラに接続された AT 84 キーボードや AT 拡張キーボードへのアクセスを提供します. device psm0 at atkbdc? irq 12 あなたのマウスが PS/2 マウスポートに接続するタイプなら このデバイスを使って下さい. device vga0 at isa? ビデオカードドライバです. # splash screen/screen saver pseudo-device splash 起動時に画面がはじけます. スクリーンセーバもこのデバイスを必要とします. # syscons is the default console driver, resembling an SCO console device sc0 at isa? sc0 はSCOに類似したデフォルトの コンソールドライバです. 殆どのフルスクリーンのプログラムは termcap のようなターミナルデータベールライブラリにアクセスするので, sc0 を使うか VT220 互換のコンソールドライバである vt0 を使うかは重要ではありません. ログイン時, このコンソールでフルスクリーンプログラムが動かないときは TERM 変数を scoansi に設定して下さい. # Enable this and PCVT_FREEBSD for pcvt vt220 compatible console driver #device vt0 at isa? #options XSERVER # support for X server on a vt console #options FAT_CURSOR # start with block cursor # If you have a ThinkPAD, uncomment this along with the rest of the PCVT lines #options PCVT_SCANSET=2 # IBM keyboards are non-std これは VT220 互換のコンソールドライバで, VT100/102 と後方互換性があります. sc0 とハード的に互換性がないラップトップでも 問題なく動きます. ここでもログイン時に TERM 変数を vt100 又は vt220 と設定して下さい. このドライバは、sc0 デバイス用の termcap や terminfo のエントリが無い, ネットワーク上の多くの異なったマシンに 接続する際にも有用です — vt100 は仮想的にすべてのプラットフォームで有効であるべきです. # Floating point support - do not disable. device npx0 at nexus? port IO_NPX irq 13 npx0 は FreeBSD における - 浮動小数点演算ユニットへのインターフェースで, それは実際には + 浮動小数点演算ユニットへのインタフェースで, それは実際には コプロセッサ又はソフトウエアエミュレータです. これはオプションではありません. # Power management support (see LINT for more options) device apm0 at nexus? disable flags 0x20 # Advanced Power Management 先進的な電源管理機能 (APM) のサポート. ラップトップでは役に立つでしょう. # PCCARD (PCMCIA) support device card device pcic0 at isa? irq 10 port 0x3e0 iomem 0xd0000 device pcic1 at isa? irq 11 port 0x3e2 iomem 0xd4000 disable PCMCIA サポート. ラップトップにインストールする時は必要です. # Serial (COM) ports device sio0 at isa? port IO_COM1 flags 0x10 irq 4 device sio1 at isa? port IO_COM2 irq 3 device sio2 at isa? disable port IO_COM3 irq 5 device sio3 at isa? disable port IO_COM4 irq 9 これらは MS-DOS/Windows の世界では COM1からCOM4 と呼ばれている 4 つのシリアルポートです. もしあなたが内蔵モデムを COM4 に, シリアルポートを COM2 に設定している場合, FreeBSD からアクセスするには, (IRQ2=IRQ9 という, 不明瞭な技術的理由により) モデムの IRQ を 2 に変更する必要があります. もしマルチポートシリアルカードを持っていてこれらの設定の正しい 数値に関する情報がほしい場合はマニュアルページ &man.sio.4; を参照して下さい. ビデオカードのいくつかは (S3 チップベースのものは特に) IO アドレスを 0x*2e8 と言う形式で表現する一方, 多くの安価なシリアルカードは 16 ビットの IO アドレスを完全に デコードしないので, これらのカードを使った場合衝突が起こり, 事実上 COM4 ポートを使用不可能にします. 各々のシリアルポートは (共有割り込み番号をサポートする マルチポートカードを使っていない限り) 固有の IRQ を必要とします. 従って COM3 と COM4 用のデフォルト IRQ は利用できません. # Parallel port device ppc0 at isa? irq 7 - ISA バスパラレルポートインターフェースです. + ISA バスパラレルポートインタフェースです. device ppbus # Parallel port bus (required) パラレルポートバスのサポートを提供します. device lpt # Printer パラレルポートプリンタのサポートです. 上の 3 つはすべてパラレルプリンタを利用可能にするために 必要です. device plip # TCP/IP over parallel - パラレルネットワークインターフェース用のドライバです. + パラレルネットワークインタフェース用のドライバです. device ppi # Parallel port interface device 汎用I/O (geek port) + IEEE1284 I/O です. #device vpo # Requires scbus and da Iomega の Zip ドライブ用です. scbus と da サポートが必要です. EPP 1.9モードを使うと最高の性能が得られます. # PCI Ethernet NICs. device de # DEC/Intel DC21x4x (Tulip) device fxp # Intel EtherExpress PRO/100B (82557, 82558) device tx # SMC 9432TX (83c170 EPIC) device vx # 3Com 3c590, 3c595 (Vortex) device wx # Intel Gigabit Ethernet Card (Wiseman) PCI ネットワークカードのドライバです. あなたのシステムに ないものはコメントアウトするか削除して下さい. # PCI Ethernet NICs that use the common MII bus controller code. device miibus # MII bus support MII バスサポートはいくつかの PCI 10/100 イーサネット NIC, すなわち MII に従うトランシーバや MII のようなトランシーバ制御 - インターフェースを実装するもの, に必要となります. + インタフェースを実装するもの, に必要となります. カーネルコンフィギュレーションに device miibus を追加することで, 汎用 miibus API のサポートと, 特定のドライバを必要としない場合に利用される汎用のものを含む すべての PHY ドライバが導入されます. device dc # DEC/Intel 21143 and various workalikes device rl # RealTek 8129/8139 device sf # Adaptec AIC-6915 (Starfire) device sis # Silicon Integrated Systems SiS 900/SiS 7016 device ste # Sundance ST201 (D-Link DFE-550TX) device tl # Texas Instruments ThunderLAN device vr # VIA Rhine, Rhine II device wb # Winbond W89C840F device xl # 3Com 3c90x (Boomerang, Cyclone) MII バスコントローラコードを利用するドライバです. # ISA Ethernet NICs. device ed0 at isa? port 0x280 irq 10 iomem 0xd8000 device ex device ep # WaveLAN/IEEE 802.11 ワイヤレス NIC. # 注: WaveLAN/IEEE は PCMCIA デバイスとしてしか実在しません. # なので ISAア タッチメントは必要なく, リソースは常に PC カードコードに # より動的に割り当てられます. device wi # Aironet 4500/4800 802.11 ワイヤレス NIC. # 注: 下の宣言は ISA PnP モード (工場出荷時設定) のISAカード, PCMCIA # 及び PCI カードにのみ働きます. もし, ISA カードの I/O アドレスと IRQ # を手動で設定している場合は, ここでそれらのパラメータを指定しなく # てはいけません. device an # これらの検出順序は現在 i386/isa/isa_compat.c により決められます. device ie0 at isa? port 0x300 irq 10 iomem 0xd0000 device fe0 at isa? port 0x300 device le0 at isa? port 0x300 irq 5 iomem 0xd0000 device lnc0 at isa? port 0x280 irq 10 drq 0 device cs0 at isa? port 0x300 device sn0 at isa? port 0x300 irq 10 # requires PCCARD (PCMCIA) support to be activated #device xe0 at isa? ISA イーサネットドライバです. どのカードがどのドライバによりサポートされているかは /usr/src/sys/i386/conf/LINT を参照して下さい. # Pseudo devices - the number indicates how many units to allocated. pseudo-device loop # Network loopback TCP/IP の汎用ループバックデバイスです. localhost (すなわち 127.0.0.1) に対して telnet や FTP を使う場合, この疑似デバイスを通して戻ってきます. これは 必須 です. pseudo-device ether # Ethernet support ether はイーサネットカードを持っている場合に のみ必要です. 汎用イーサネットプロトコルコードを含みます. pseudo-device sl 1 # Kernel SLIP sl は SLIP サポートを行います. SLIP は設定のより簡単な, モデム-モデム間の接続にはより適していて より高機能な PPP に殆ど取って代わられています. sl に続く 数字 には同時に持てる SLIP セッション数を指定します. pseudo-device ppp 1 # Kernel PPP これはダイアルアップ接続用のカーネル PPP サポートです. 他にも tun を利用し, デマンドダイアリングのような 柔軟性と機能を提供するユーザーランドのアプリケーションとして 実装された PPP が存在します. ppp に続く 数字 には同時に持てる PPP セッション数を 指定します. pseudo-device tun # Packet tunnel. これはユーザーランド PPP ソフトウエアにより利用されます. tun に続く 数字 には同時に持てる PPP セッション数を指定します. 詳細はこの本の PPP セクションを 参照して下さい. pseudo-device pty # Pseudo-ttys (telnet etc) これは 疑似ターミナル 或いはシミュレートされた ログインポートです. これは入ってくる telnet と rlogin セッション, xterm やその他の emacs のような アプリケーションにより利用されます. 数字 は生成される pty の数を示します. もし同時にデフォルトの 16 より多くの xterm ウィンドウやリモートログインが 必要な場合, 必要に応じてこの数字を増やして下さい. 最大は 256 です. pseudo-device md # Memory disks メモリディスク疑似デバイス. pseudo-device gif 4 # IPv6 and IPv4 tunneling この行は IPv6 over IPv4 トンネル, IPv4 over IPv6 トンネル, IPv4 over IPv4 トンネル, IPv6 over IPv6 トンネルを提供します. pseudo-device faith 1 # IPv6-to-IPv4 relaying (translation) この疑似デバイスは自分宛に送られたパケットを受け取り, IPv4/IPv6 変換デーモンに渡します. # The `bpf' pseudo-device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! pseudo-device bpf # Berkeley packet filter これはバークレーパケットフィルタです. - この疑似デバイスはネットワークインターフェースを, イーサネットのような + この疑似デバイスはネットワークインタフェースを, イーサネットのような ブロードキャストネットワーク上ですべてのパケットを拾うことのできる promiscuous モードに設定できるようにします. これらのパケットはディスクに取り込むこともできますし, &man.tcpdump.1; を使ってチェックをすることもできます. # USB support #device uhci # UHCI PCI->USB interface #device ohci # OHCI PCI->USB interface #device usb # USB Bus (required) #device ugen # Generic #device uhid # Human Interface Devices #device ukbd # Keyboard #device ulpt # Printer #device umass # Disks/Mass storage - Requires scbus and da #device ums # Mouse # USB Ethernet, requires mii #device aue # ADMtek USB ethernet #device cue # CATC USB ethernet #device kue # Kawasaki LSI USB ethernet 様々なUSBデバイスのサポートです. より詳細な情報と, FreeBSD によりサポートされる他のデバイスに ついては /usr/src/sys/i386/conf/LINT を参照して下さい. デバイスノードを作る カーネル内のほとんどすべてのデバイスは対応する node エントリが /dev ディレクトリにあります. これらのノードは普 通のファイルのように見えますが, 実際にはプログラムがデバイスに アクセスするのに用いるカーネル内への特別なエントリです. シェルスクリプトである /dev/MAKEDEVはオペレーティング システムを最初にインストールする時に実行され, サポートされてい る大部分のデバイスのノードを作ります. しかし, すべての ノードが作られるわけではありませんので 新しいデバイスのサポートを加える時は対応するエントリがこのディ レクトリにあるかどうか確認してもしなければ, 作ってください. 以下に例を示します. IDE CD-ROMのサポートをカーネルに加えるとします. 次の行 を加えます. device acd0 これにしたがって, /devディレクトリに acd0 で始まるエントリをさがしてください. 1文字が後ろにつくかもしれません. 後ろについた文字が c であるか, 先頭に r のつくエントリは raw デバイスを示します. それらのファイルがないことが明らかになったとします. そこで /dev ディレクトリに移動して次のようにタイプします. &prompt.root; sh MAKEDEV acd0 スクリプトの実行が終ったら /devに acd0c と racd0c エントリがあることを確認してください. これによ り正しく実行されたことがわかります. サウンドカードの場合, 以下のコマンドで対応する エントリが作成されます: &prompt.root; sh MAKEDEV snd0 サウンドカードのようなデバイスのノードを作る場合で, もし他 の人がマシンにアクセスするようであれば, そのデバイスを /etc/fbtab ファイルに追加して外部からのアクセスから 保護するのが望ましいでしょう. このファイルの詳細については &man.fbtab.5; を参照してください. GENERIC に含まれていないデバイスはエントリがありませんから,以上 の簡単な手順をおこなうことになります. すべての SCSI コントローラは同じ /dev の エントリを使用しますのでノードを作る必要はありません. またネッ トワークカードと SLIP/PPP 疑似デバイスは /dev にはエント リがありませんのでこれらについても作る必要がありません. 問題が起きた場合には カスタムカーネルを作る場合に起きるトラブルは, 次の 4 種類に分けられます. config コマンドの失敗 カーネルコンフィグレーションファイルに設定を行なってから config コマンドが失敗したのであれば, おそらくファイルのどこかに単純な間違いがあります. さいわい, config はトラブルの起きた行番号を出力しますので vi で素早く見つけることができます. 例えば, 次のように出力された場合 config: line 17: syntax error vi のコマンドモードで 17G とタイプすれば, 問題のところへ飛ぶことができます. GENERIC カーネルのファイルや, 他のリファレンスと比較して注意深く修正してください. make コマンドの失敗 make コマンドが失敗した場合には, カーネル設定で config がとらえられなかったような間違いをしていることが多いようです. もう一度コンフィグレーションファイルを見直してください. それでも問題を解決することができなければ, &a.questions; へあなたのカーネルコンフィグレーションファイルをつけてメールしてください. 誰かが素早く間違いを見つけてくれるでしょう. カーネルが起動しない 新しいカーネルが起動しなかったり, デバイスの認識をしない場合でもあわてないでください! さいわい, BSDは 利用できないカーネルから復帰する 洗練されたメカニズムがあります. それは, FreeBSD のブートローダで起動したいカーネルを選択する (例えば boot kernel.old) だけです. カーネルの再設定をおこなう場合にはいつも, 確実に動くことが分かっているカーネルを用意しておくようにすると良いでしょう. 問題のないカーネルで起動した後に あなたのコンフィグレー ションファイルを調べ, 再び構築を試みてください. /var/log/messages ファイルにはすべての成功した 起動時のカーネルメッセージやその他の記録があり, これ は助けになる情報の一つでしょう. また, &man.dmesg.8; コマンドは現在の起動時のカーネルメッ セージを出力します. カーネルの構築中にトラブルが起きた時に使うために GENERICや他のカーネルを次の構築で消されない ように異る名前で保存するようにしてください. kernel.old は新しいカーネルをインストールする 時に, その一つ前にインストールしたうまく動かないかもしれ ないカーネルで上書きされてしまいますので当てにできませ ん. またできる限り早く動作しているカーネルを本来の kernelの位置に移動させてください. そうしないと &man.ps.1; のようなコマンドが正しく動きません. make でインストールされたカーネルのファイルを (別のカーネルに戻すために) アンロック するための特別 のコマンドは &prompt.root; chflags noschg /kernel です. また, 新しい置き換えたカーネルあるいは重要ファイ ルを動かしたり変更されないように ロック するには 次のようにします. &prompt.root; chflags schg /kernel カーネルは動くが ps は動かない! システムユーティリティと異る バージョンのカーネルをインストールした場合, 例えば 4.x のカーネルを 3.x システム上にインストールするような場合, &man.ps.1; や &man.vmstat.8; のような多くの システムステータスコマンドは動かなくなります. libkvm を再コンパイルして, これらのユーティリティを作りなおす必要があります. これは, カーネルとそれ以外で異なるバージョンを組み合わせて オペレーティングシステムを使用することが推奨されない理由の 一つとなっています. diff --git a/ja_JP.eucJP/books/handbook/kerneldebug/chapter.sgml b/ja_JP.eucJP/books/handbook/kerneldebug/chapter.sgml index e5a0f4b3f8..b388e0a83c 100644 --- a/ja_JP.eucJP/books/handbook/kerneldebug/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/kerneldebug/chapter.sgml @@ -1,729 +1,729 @@ カーネルデバッグ 原作 &a.paul; and &a.joerg; 訳: &a.jp.yoshiaki;. 1997 年 3 月 18 日. <command>gdb</command> によるカーネルのクラッシュダンプのデバッグ ここではクラッシュダンプ (crash dump : 訳注 この文脈では kernel 自身 の異常によって停止した場合に出力されるイメージを指します) によるカーネルデバッグの方法を示します。 ここではダンプするための十分なスワップ (swap) の容量があるものとします。 もし複数のスワップパーティションを持ち、 最初のパーティションがダンプ を保持するのに十分な大きさを持たない場合は 別のダンプデバイスを使うよ うに (config kernel 行で) カーネルのコンフィグをおこなうか、&man.dumpon.8; コマンドを使って別のデバイスを示すことができます。&man.dumpon.8; を使うもっともよい方法は変数 dumpdev を /etc/rc.conf で設定することです。一般的には /etc/fstab で設定されているスワップデバイスが 使われるでしょう。 スワップに使えないデバイスへのダンプ、 例えばテープへのダンプは現在サポートさ れていません。カーネルのコンフィグは config によって行ってください。 FreeBSD カーネルのコンフィグレーション には FreeBSD のカーネルの設定の詳細がありますので 参照してください。 &man.dumpon.8; コマンドを使ってどこへダンプするか カーネルに伝えてください (&man.swapon.8; によってそのパーティションが スワップとして設定された 後でなければならないことに注意してください)。これは普通は /etc/rc.conf や /etc/rc で設定されます。あるいは 別の方法としてカーネルコンフィグレーションファイルの config 行の dump 節で ダンプデバイスをハードコードすることができます。 この方法はあまりよくは ありません。カーネルがブート時に crash する場合のクラッシュダンプを取り たい時だけ使うべきです。 以下では gdbという用語は gdb をカーネルデバッグモードで動かしていることを意味します。 gdb を オプションをつけて起動することで、 このモードになります。 カーネルデバッグモードでは、プロンプトが (kgdb) に変わります。 FreeBSD 3 およびそれ以前のシステムを使っているなら、 巨大なデバッグカーネルをそのままインストールするのではなく strip されたデバッグ用カーネルをつくるべきでしょう。 &prompt.root; cp kernel kernel.debug &prompt.root; strip -g kernel この手順は必須ではありませんが、ぜひ行なうことをおすすめします (FreeBSD 4 およびそれ以降では、カーネルの make の段階で自動的にこれが行なわれます)。 自動的に、あるいは上のコマンドを手動で実行してカーネルが strip されたら、普通に make install と実行し、カーネルをインストールして構いません。 FreeBSD の古いリリース (3.1 を含まない以前のもの) は、 標準で a.out カーネルを使っていることに注意してください。 これはシンボルテーブルが常に物理メモリ上に存在することを要求するため、 strip されていないデバッグカーネルに含まれる大きなシンボルテーブルは非常に無駄になります。 ELF カーネルを使った FreeBSD の最近のリリースでは、 そのような問題がなくなりました。 カーネルを作った時にそのコピーを kernel.debug という名前で作りましょう。 また、オリジナルに対して strip -gを実行します。 オリジナルを普通にインストールします。また strip していないカーネルも同様にインストールすることができますが、 シンボルテーブルの参照時間 がいくつかのプログラムでは劇的に増加するでしょう。また、 カーネル全体はブート時に読み込まれ スワップアウトされないため数メガバイトの物理メ モリが無駄になります。 例えばブートプロンプトで 新しいカーネルの名前をタイプすることによって、 新しいカーネルをテストした場合で、 再びシステムを動かすのに別のカーネ ルで立ち上げることが必要な場合はブートプロンプトで フラグ を使いシングルユーザの状態にしてください。 そして以下のような操作をおこないます。 &prompt.root; fsck -p &prompt.root; mount -a -t ufs # /var/crash 用のファイルシステムを書き込み可能にする &prompt.root; savecore -N /kernel.panicked /var/crash &prompt.root; exit # ...マルチユーザモードへ移行 ここに示した &man.savecore.8; は (現在動いているものとは別の) カーネルのシンボル名の抽出をおこなうために使っています。 抽出はデフォルトで は現在動いているカーネルに対しておこなわれ、 クラッシュダンプとカーネルシンボ ルのくい違いのためにまったく何もしません (訳注: そのためにオプション で実際にダンプをおこしたカーネルを指定します)。 クラッシュダンプの起きた後に /sys/compile/WHATEVERへ行き gdbを動かします。gdb より次のようにします。 symbol-file kernel.debug exec-file /var/crash/kernel.0 core-file /var/crash/vmcore.0 こうすると、 クラッシュダンプを使ってカーネルソースを他のプログラムと同様に デバッグすることができます。 次に gdb での手順のセッションのログを示します。長い行は読 みやすくするために改行しました。また、 参照のために行番号を入れてあります。ただし、これは実際の pcvt コンソールドライバの開発中の実際のエ ラーのトレースです。 1:Script started on Fri Dec 30 23:15:22 1994 2:&prompt.root; cd /sys/compile/URIAH 3:&prompt.root; gdb -k kernel /var/crash/vmcore.1 4:Reading symbol data from /usr/src/sys/compile/URIAH/kernel ...done. 5:IdlePTD 1f3000 6:panic: because you said to! 7:current pcb at 1e3f70 8:Reading in symbols for ../../i386/i386/machdep.c...done. 9:(kgdb) where 10:#0 boot (arghowto=256) (../../i386/i386/machdep.c line 767) 11:#1 0xf0115159 in panic () 12:#2 0xf01955bd in diediedie () (../../i386/i386/machdep.c line 698) 13:#3 0xf010185e in db_fncall () 14:#4 0xf0101586 in db_command (-266509132, -266509516, -267381073) 15:#5 0xf0101711 in db_command_loop () 16:#6 0xf01040a0 in db_trap () 17:#7 0xf0192976 in kdb_trap (12, 0, -272630436, -266743723) 18:#8 0xf019d2eb in trap_fatal (...) 19:#9 0xf019ce60 in trap_pfault (...) 20:#10 0xf019cb2f in trap (...) 21:#11 0xf01932a1 in exception:calltrap () 22:#12 0xf0191503 in cnopen (...) 23:#13 0xf0132c34 in spec_open () 24:#14 0xf012d014 in vn_open () 25:#15 0xf012a183 in open () 26:#16 0xf019d4eb in syscall (...) 27:(kgdb) up 10 28:Reading in symbols for ../../i386/i386/trap.c...done. 29:#10 0xf019cb2f in trap (frame={tf_es = -260440048, tf_ds = 16, tf_\ 30:edi = 3072, tf_esi = -266445372, tf_ebp = -272630356, tf_isp = -27\ 31:2630396, tf_ebx = -266427884, tf_edx = 12, tf_ecx = -266427884, tf\ 32:_eax = 64772224, tf_trapno = 12, tf_err = -272695296, tf_eip = -26\ 33:6672343, tf_cs = -266469368, tf_eflags = 66066, tf_esp = 3072, tf_\ 34:ss = -266427884}) (../../i386/i386/trap.c line 283) 35:283 (void) trap_pfault(&frame, FALSE); 36:(kgdb) frame frame->tf_ebp frame->tf_eip 37:Reading in symbols for ../../i386/isa/pcvt/pcvt_drv.c...done. 38:#0 0xf01ae729 in pcopen (dev=3072, flag=3, mode=8192, p=(struct p\ 39:roc *) 0xf07c0c00) (../../i386/isa/pcvt/pcvt_drv.c line 403) 40:403 return ((*linesw[tp->t_line].l_open)(dev, tp)); 41:(kgdb) list 42:398 43:399 tp->t_state |= TS_CARR_ON; 44:400 tp->t_cflag |= CLOCAL; /* cannot be a modem (:-) */ 45:401 46:402 #if PCVT_NETBSD || (PCVT_FREEBSD >= 200) 47:403 return ((*linesw[tp->t_line].l_open)(dev, tp)); 48:404 #else 49:405 return ((*linesw[tp->t_line].l_open)(dev, tp, flag)); 50:406 #endif /* PCVT_NETBSD || (PCVT_FREEBSD >= 200) */ 51:407 } 52:(kgdb) print tp 53:Reading in symbols for ../../i386/i386/cons.c...done. 54:$1 = (struct tty *) 0x1bae 55:(kgdb) print tp->t_line 56:$2 = 1767990816 57:(kgdb) up 58:#1 0xf0191503 in cnopen (dev=0x00000000, flag=3, mode=8192, p=(st\ 59:ruct proc *) 0xf07c0c00) (../../i386/i386/cons.c line 126) 60: return ((*cdevsw[major(dev)].d_open)(dev, flag, mode, p)); 61:(kgdb) up 62:#2 0xf0132c34 in spec_open () 63:(kgdb) up 64:#3 0xf012d014 in vn_open () 65:(kgdb) up 66:#4 0xf012a183 in open () 67:(kgdb) up 68:#5 0xf019d4eb in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi =\ 69: 2158592, tf_esi = 0, tf_ebp = -272638436, tf_isp = -272629788, tf\ 70:_ebx = 7086, tf_edx = 1, tf_ecx = 0, tf_eax = 5, tf_trapno = 582, \ 71:tf_err = 582, tf_eip = 75749, tf_cs = 31, tf_eflags = 582, tf_esp \ 72:= -272638456, tf_ss = 39}) (../../i386/i386/trap.c line 673) 73:673 error = (*callp->sy_call)(p, args, rval); 74:(kgdb) up 75:Initial frame selected; you cannot go up. 76:(kgdb) quit 77:&prompt.root; exit 78:exit 79: 80:Script done on Fri Dec 30 23:18:04 1994 上の出力についてのコメントをします。 line 6: これは DDB (後述) からのダンプです。このため because you said to! という panicコメントがつき、ページフォルトのトラップによって DDBに入ったことが原因の、やや長いスタックトレー スがあります。 line 20: スタックトレースでのこれは trap()関数の位置です。 line 36: 新しいスタックフレームを使用するように指定しています。 ただし、ここでこれを指定する必要ありません。 trap の場合、スタックフレームは正しい場所を指していると考えられるからです。 ソースコードの 403 行を見ると、tp ポインタのアクセスが失敗しているか、 配列のアクセスが範囲外である可能性が高いことがわかります。 line 52: 怪しいポインタですが、 アクセスは正常におこなえました。 line 56: ところが、明らかにポインタはゴミを指しています。これで エラーを見つけました! (ここのコードの部分からはよくわかり ませんが、 tp->t_lineはコンソールデバイスの規定 する行を参照しているので、 もっと小さな整数でなければなりません。) DDD によるクラッシュダンプのデバッグ カーネルのクラッシュダンプは ddd のようなグラフィカルなデバッガで調べることもできます。 通常はコマンドラインで オプションをつけて ddd を起動します。たとえば: &prompt.root; ddd -k /var/crash/kernel.0 /var/crash/vmcore.0 クラッシュダンプを ddd - のグラフィカルなインターフェースを使って + のグラフィカルなインタフェースを使って 見ることができます。 突然ダンプした場合の解析 カーネルが予想もしない時にコアダンプして config -g を行ってコンパイルされていなかった場合にはどうしたら よいでしょう。すべてが失われるわけではありません。 パニックを起こさないでください。 もちろん、クラッシュダンプを使えるようにする必要があります。 使い方は前述の部分を見てください。 カーネルのコンパイルディレクトリ (/usr/src/sys/arch/conf) で、設定ファイルを編集します。以下の行のコメントを外します (行が存在しなければ追加します): makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols カーネルを再構築しましょう。 Makefileのタイムスタンプの変更により、例えば trap.o などのいくつかの他のオブジェクトファイルも作り直さ れます。少しの幸運があれば、 オプションが追加されても作ら れるコードは変更されず、いくらかのデバッグシンボル以外には 問題を 起こしたコードとそっくりな新しいカーネルを手に入れることが できます。少なくとも &man.size.1; コマンドで古い方と新しい方のサイズを比較すべきです。 これが食い違っていれば、 多分あきらめなければならないでしょう。 ダンプを使って前述のように動かして調べます。 デバッグシンボルは 必ずしも十分ではありません。 上の例ではスタックトレースでいくつかの関 数の行番号や引数リストが表示されないかもしれません。 もしより多くのデバッグシンボルが必要であれば、十分になるまで 適切なオブジェクトファイ ルを消して (makeして) gdb セッションを繰り返してください。 これは必ずしもうまく動くと保証はできません。 しかしほとんどの場合でうまくいくでしょう。 DDBを使ったオンラインカーネルデバッグ gdb は非常に高レベルのユーザインタフェースを提 供するオフラインデバッガですが、いくつかのことはできません。 (できないことの中で) 極めて重要なことはカーネルコードへのブレークポイ ントの設定とシングルステップ実行です。 カーネルの低レベルデバッグが必要であれば、DDBと呼ばれる on-lineデバッガが使えます。ブレークポイントの設定、 シングルステップのカーネルの実行、 変数の検査と変更などができます。 ただし、これはカーネルのソースファ イルにアクセスすることはできません。 gdbのようにすべてのデ バッグ情報にはアクセスできず、global と static のシンボルにアクセスすることができるだけです。 カーネルに DDB を含めるためにはコンフィグファイルに次のようなオプショ ンを加えて、 options DDB 再構築をおこないます。( FreeBSD のカーネルの設定の詳細については FreeBSD カーネルのコンフィグレーションを参照してくださ い。 古いバージョンの起動ブロックを使っている場合、ですと、 デバッガのシンボルが完全にはロードされないかもしれません。 その時は起動ブロックを最新のものに更新してください。 新しい起動ブロックは、DDB シンボルを自動的にロードします。 DDB カーネルの実行において、 DDB に入るいくつかの方法があります。最初の、 最も早い方法はブートプロンプトが出ている時に のブートフラグをタイプすることです。 カーネルはデバッグモードで起動し、デバイスのプローブ以前に DDB に入ります。したがって、デバイスのプローブ/初期 設定ファンクションのデバッグができます。 2 つ目のシナリオはキーボードのホットキーで、通常は Ctrl-Alt-ESC です。syscons ではホットキーは再設定することができ、 配付されているいくつかのキーマッピングでは別のキーに 再設定されていますので確認しておいてください。シリアルラインの BREAK を使ってシリアルコンソールから DDB へ入ることを可 能にするオプションもあります (カーネルコンフィグレーションファイルの options BREAK_TO_DEBUGGER)。これは多くのつまらないシリ アルアダプタが、例えばケーブルを引き抜いた時に BREAK 状態を意味もなく 作り出してしまうのでデフォルトでは無効になっています。 3つ目は、DDB を使うようになっているカーネルがパニック状態になると DDB へ入るというものです。このため、 無人運転するマシンのカーネルに DDB を 入れるのは賢明ではありません。 DDB のコマンドはおおまかには gdb のいくつかのコマンドと似て います。おそらく最初にブレークポイントを 設定する必要があるでしょう。 b function-name b address 数値はデフォルトでは 16 進数で、 シンボル名とはまったく異なります。16 進数で a-f の文字で始まる場合は、先頭に 0x をつける必要があります(それ以外の数字の場合はどちらでもか まいません)。function-name + 0x103のような単純な式を使うことができます。 割り込みされたカーネルから処理を続行するためには、 c とタイプするだけです。 スタックのトレースには trace とします。 DDB にホットキーで入った場合は、カーネルはその (ホットキーの) 割り込み の処理を行っていますのでスタックトレースは あまり役にたたないことに注意してください。 ブレークポイントを削除したい場合は、 del del address-expression とします。 最初の形式はブレークポイントにヒットしたすぐ後で使うことができ、 現在のブレークポイントを削除します。2 番目の形式では任意のブレー クポイントを削除することができますが、 次の形式で得られるような正確な アドレスを与えることが必要です。 show b カーネルをシングルステップ実行させるには s としてみてください。これは関数呼出し先までステップ実行 (step into function) するでしょう。 次のステートメントが終了するまでの DDBトレースは n によっておこなうことができます。 これは gdb の next 命令とは異ります。gdbの finish 命令と似ています。 メモリ上のデータを調べるには (例として) 次のようにします。 x/wx 0xf0133fe0,40 x/hd db_symtab_space x/bc termbuf,10 x/s stringbuf word/halfword/byte 単位でアクセスをおこない、hex (16進) /dec (10進) / char (文字) /string (文字列) で表示します。 カンマの後ろの数字はオブジェク トカウントです。次の 0x10 個の要素を表示するには、単純に x ,10 とします。同様に次のように使うことができます。 x/ia foofunc,10 foofunc の最初の 0x10 個の命令語をディスアセンブルし、 foofunc の先頭からのオフセットとともに表示します。 メモリの内容を変更するには write コマンドを使います。 w/b termbuf 0xa 0xb 0 w/w 0xf0010030 0 0 コマンドモディファイアの (b/h/w) はデータを 書くサイズを定義し、 これに続く最初の式は書き込むアドレス、残りがこれ に続く連続するメモリアドレスに書き込まれるデータになります。 現在のレジスタ群の内容を知りたい場合は show reg とします。また、単一のレジスタの値を表示するには、例えば p $eax とします。また値の変更は set $eax new-value とします。 DDBからカーネルの関数を呼び出す必要がある場合は、単に call func(arg1, arg2, ...) とします。return 値が出力されます。 動いているプロセスの &man.ps.1; スタイルの概要は ps です。 カーネルの失敗の原因の調査が終わったら、ここで再起動すべきです。 それまでの不具合により、カーネルのすべての部分が期待するような 動作をしているわけではないということを忘れないでください。 以下のうちいずれかの方法でシステムのシャットダウンおよび再起動を行ってください。 panic カーネルをコアダンプしてリブートしますので、後で gdbによってコアの高レベル解析をすることができます。 このコマンドは通常、一度 continue命令を使った後に 使うことになるでしょう。 call boot(0) は動いているシステムを `clean' に shut down するよい方法です。すべてのディスクを sync() して最後にリブートします。 ディスクとカー ネルのファイルシステムインタフェースが破損していない限り、 ほぼ完全に `clean' にシャットダウンするよい方法でしょう。 call cpu_reset() は大惨事を防ぐための最後の手段で 「赤い大きなボタン」 を押すのとほとんど同じです (訳注: リセットボタンを押すのとほぼ同じであるという意味です)。 短いコマンドの要約は help をタイプします。ただし、デバッグセッションのために &man.ddb.4; の マニュアルページのプリントアウトを用意しておくことを 強くお奨めします。 カーネルのシングルステップ中にオンラインマニュアルを 読むことは難しいということを覚えておいてください。 リモート GDB を使ったオンラインカーネルデバッグ この機能は FreeBSD 2.2 からサポートされました。 これは本当にすばらし い機能です。 GDB はすでにかなり以前より リモートデバッグ をサポートしてい ます。 これはシリアル回線を使い非常に単純なプロトコルで行ないます。 もちろん、この方法では今までに示した方法とは違い、 2 台のマシンが必要になります。1 台はデバッグ環境のためのホストで、 すべてのソースとす べてのシンボルを含んだバイナリのコピーを持っています。もう 1 台は ターゲットマシンで、同一のカーネルのコピー (ただしデバッグ情報は 取り除いてあるもの) を単に実行するためのものです。 この場合、カーネルのコンフィグレーションは config -g で行な い、 を含めなくてはなりません。そうして通常通りコンパイルし ます。 こうして作ったバイナリファイルはデバッグ情報のために非常に大き くなります。このカーネルをターゲットマシンにコピーして strip -x でデバッグシンボルを取り除きます。 そして ブートオプションを使いブートします。 sio デバイスにフラグ 0x80 が設定されているターゲットマシンの シリアル回線を、デバッグホストのいずれかのシリアル回線に つないでください。 それからデバッグ (訳注:ホスト) マシン上で、ターゲットとなって いるカーネルのコンパイルディレクトリで gdb を起動します: &prompt.user; gdb -k kernel GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.16 (i386-unknown-freebsd), Copyright 1996 Free Software Foundation, Inc... (kgdb) リモートデバッグセッションの初期化 (1 番目のシリアルポートを使用することの設定) を以下のように行ないます。 (kgdb) target remote /dev/cuaa0 次にターゲットマシン (デバイスのプローブ直前で DDB に入っています) で次のように入力します: Debugger("Boot flags requested debugger") Stopped at Debugger+0x35: movb $0, edata+0x51bc db> gdb DDB は次のような出力を返すでしょう。 Next trap will enter GDB remote protocol mode gdbと入力するたびにリモート GDB とローカル DDB が交互に切り替わります。 トラップをすぐに起こすために単に ``s'' (step) と入力して下さい。 そうするとホストの GDB はターゲットのカーネルの制御を行なうよ うになります。 Remote debugging using /dev/cuaa0 Debugger (msg=0xf01b0383 "Boot flags requested debugger") at ../../i386/i386/db_interface.c:257 (kgdb) このセッションではソースコードへのフルアクセスや Emacs の window 上 の gud-mode (これは別の Emacs window に自動的にソースコードを表示します) で動かすなど、通常の GDB セッションでできることのほとんどのことができます。 GDB を使ったローダブルモジュールのデバッグ モジュール内部で発生する panic のデバッグや、 動的モジュールを使っているマシンを GDB でリモートデバッグしている場合、 モジュールのシンボル情報を得る方法を GDB に伝える必要があります。 まず、モジュールをデバッグ情報を含めて構築する必要があります。 &prompt.root; cd /sys/modules/linux &prompt.root; make clean; make COPTS=-g リモート GDB を使っている場合は、 ターゲットマシンで kldstat を実行することで モジュールがどこにロードされたか調べることが可能です。 &prompt.root; kldstat Id Refs Address Size Name 1 4 0xc0100000 1c1678 kernel 2 1 0xc0a9e000 6000 linprocfs.ko 3 1 0xc0ad7000 2000 warp_saver.ko 4 1 0xc0adc000 11000 linux.ko クラッシュダンプをデバッグしている場合、 linker_files->tqh_first から始まる linker_files リストを調べ、 探している filename が見つかるまで link.tqe_next ポインタをたどる必要があります。 エントリ中の address メンバが、 モジュールのロードアドレスです。 次に、モジュール内の text セクションのオフセットを調べます。 &prompt.root; objdump --section-headers /sys/modules/linux/linux.ko | grep text 3 .rel.text 000016e0 000038e0 000038e0 000038e0 2**2 10 .text 00007f34 000062d0 000062d0 000062d0 2**2 必要なのは .text セクションで、 上の例では 10 にあたります。その 4 番目の 16 進数フィールド (全部で 6 フィールドあります) が、ファイル中の text セクションのオフセットになります。 そして、このオフセットをモジュールのロードアドレスに加算すると モジュールのコードの再配置アドレスを求めることができます。 この例では 0xc0adc000 + 0x62d0 = 0xc0ae22d0 です。 GDB コマンド add-symbol-file を使い、 得られたモジュールの情報をデバッガに伝えるには、次のようにします。 (kgdb) add-symbol-file /sys/modules/linux/linux.ko 0xc0ae22d0 add symbol table from file "/sys/modules/linux/linux.ko" at text_addr = 0xc0ae22d0? (y or n) y Reading symbols from /sys/modules/linux/linux.ko...done. (kgdb) これで、モジュール内のすべてのシンボルにアクセスできるようになります。 コンソールドライバのデバッグ DDBを動かすためにはコンソールドライバが必要ですから、 コンソールドラ イバ自身に不具合のある場合は複雑になります。 シリアルコンソールを利 用する方法 (ブートブロックを変更するか Boot:プロンプトで と入力する) を思い出してください。 そして標準ター ミナルを最初のシリアルポートに設定します。DDBは、 もちろんシリアルコンソールを含むいずれの コンソールドライバの設定でも動作します。 diff --git a/ja_JP.eucJP/books/handbook/mirrors/chapter.sgml b/ja_JP.eucJP/books/handbook/mirrors/chapter.sgml index c7c27e2d43..cf322ccd33 100644 --- a/ja_JP.eucJP/books/handbook/mirrors/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/mirrors/chapter.sgml @@ -1,3972 +1,3972 @@ FreeBSD の入手方法 CDROM 出版社 リテールボックス製品 FreeBSD は (FreeBSD CD、追加ソフトウェア、 印刷されたドキュメントなどから構成される) 箱入りの製品として以下の取り扱い業者から入手できます。
CompUSA WWW: http://www.compusa.com/
Frys Electronics WWW: http://www.frys.com/
Staples WWW: http://www.staples.com/
CD セット FreeBSD の CD セットは以下のオンライン業者から入手できます。
Daemon News 2672 Bayshore Parkway, Suite 307 Mountain View, CA 94043 USA 電話: +1 800 407-5170 Email: sales@daemonnews.org WWW: http://www.bsdmall.com/
FreeBSD Mall, Inc. 3623 Sanford Street Concord, CA 94520-1405 USA 電話: +1 925 674-0783 Fax: +1 925 674-0821 Email: info@freebsdmall.com WWW: http://www.freebsdmall.com/
Hinner EDV St. Augustinus-Str. 10 D-81825 München Germany 電話: (089) 428 419 WWW: http://www.hinner.de/linux/freebsd.html
問屋 あなたが小売業を営んでいて FreeBSD の CDROM 製品を取り扱いたいと考えているなら次の場所に連絡してください。
Cylogistics 2672 Bayshore Parkway, Suite 307 Mountain View, CA 94043 USA 電話: +1 650 694-4949 Fax: +1 650 694-4953 Email: sales@cylogistics.com WWW: http://www.cylogistics.com/
Kudzu, LLC 7375 Washington Ave. S. Edina, MN 55439 USA 電話: +1 952 947-0822 Fax: +1 952 947-0876 Email: sales@kudzuenterprises.com
Navarre Corp 7400 49th Ave South New Hope, MN 55428 USA 電話: +1 763 535-8333 Fax: +1 763 535-0341 WWW: http://www.navarre.com/
DVD 出版社 FreeBSD の DVD は以下の業者から入手できます:
FreeBSD Services Ltd 11 Lapwing Close Bicester OX26 6XR United Kingdom WWW: http://www.freebsd-services.com/
FTP サイト FreeBSD の公式な情報は anonymous FTP によって以下の場所から 入手できます:
ftp://ftp.FreeBSD.org/pub/FreeBSD/.
FreeBSD ミラーサイトデーターベース FreeBSD ハンドブックの ミラーサイト一覧 よりも正確です。というのはその情報を DNS から取得するので、 静的に記述されたリストよりも信頼性が高いのです。 さらに、FreeBSD は以下のミラーサイトから anonymous FTP によって 入手できます。もし FreeBSD を anonymous FTP によって手にいれる場合は、 近くのサイトを利用するようにしてください。 Argentina、 Australia、 Brazil、 Canada、 China、 Czech Republic、 Denmark、 Estonia、 Finland、 France、 Germany、 Hong Kong、 Hungary、 Iceland、 Ireland、 Israel、 Japan、 Korea、 Lithuania、 Netherlands、 New Zealand、 Poland、 Portugal、 Romania、 Russia、 Saudi Arabia、 South Africa、 Spain、 Slovak Republic、 Slovenia、 Sweden、 Taiwan、 Thailand、 UK、 Ukraine、 USA アルゼンチン 何か問題がある場合は，このドメインの hostmaster hostmaster@ar.FreeBSD.org に連絡してください。 ftp.ar.FreeBSD.org/pub/FreeBSD/ オーストラリア 何か問題がある場合は、このドメインの hostmaster hostmaster@au.FreeBSD.org に連絡してください。 ftp://ftp.au.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.au.FreeBSD.org/pub/FreeBSD/ ftp://ftp3.au.FreeBSD.org/pub/FreeBSD/ ftp://ftp4.au.FreeBSD.org/pub/FreeBSD/ ブラジル 何か問題がある場合は、このドメインの hostmaster hostmaster@br.FreeBSD.org に連絡してください。 ftp://ftp.br.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.br.FreeBSD.org/pub/FreeBSD/ ftp://ftp3.br.FreeBSD.org/pub/FreeBSD/ ftp://ftp4.br.FreeBSD.org/pub/FreeBSD/ ftp://ftp5.br.FreeBSD.org/pub/FreeBSD/ ftp://ftp6.br.FreeBSD.org/pub/FreeBSD/ ftp://ftp7.br.FreeBSD.org/pub/FreeBSD/ カナダ 何か問題がある場合は、このドメインの hostmaster hostmaster@ca.FreeBSD.org に連絡してください。 ftp://ftp.ca.FreeBSD.org/pub/FreeBSD/ 中国 何か問題がある場合は、このドメインの hostmaster phj@cn.FreeBSD.org に連絡してください。 ftp://ftp.cn.FreeBSD.org/pub/FreeBSD/ チェコ 何か問題がある場合は、このドメインの hostmaster hostmaster@cz.FreeBSD.org に連絡してください。 ftp://ftp.cz.FreeBSD.org/pub/FreeBSD/ 連絡先: calda@dzungle.ms.mff.cuni.cz デンマーク 何か問題がある場合は，このドメインの hostmaster hostmaster@dk.FreeBSD.org に連絡してください。 ftp://ftp.dk.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.dk.FreeBSD.org/pub/FreeBSD/ ftp://ftp3.dk.FreeBSD.org/pub/FreeBSD/ エストニア 何か問題がある場合は、このドメインの hostmaster hostmaster@ee.FreeBSD.org に連絡してください。 ftp://ftp.ee.FreeBSD.org/pub/FreeBSD/ フィンランド 何か問題がある場合は、このドメインの hostmaster hostmaster@fi.FreeBSD.org に連絡してください。 ftp://ftp.fi.FreeBSD.org/pub/FreeBSD/ フランス 何か問題がある場合は、このドメインの hostmaster hostmaster@fr.FreeBSD.org に連絡してください。 ftp://ftp.fr.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.fr.FreeBSD.org/pub/FreeBSD/ ftp://ftp3.fr.FreeBSD.org/pub/FreeBSD/ ftp://ftp4.fr.FreeBSD.org/pub/FreeBSD/ ftp://ftp5.fr.FreeBSD.org/pub/FreeBSD/ ftp://ftp6.fr.FreeBSD.org/pub/FreeBSD/ ftp://ftp7.fr.FreeBSD.org/pub/FreeBSD/ ftp://ftp8.fr.FreeBSD.org/pub/FreeBSD/ ドイツ 何か問題がある場合は、このドメインのミラー管理者 de-bsd-hubsr@de.FreeBSD.org に連絡してください。 ftp://ftp.de.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.de.FreeBSD.org/pub/FreeBSD/ ftp://ftp3.de.FreeBSD.org/pub/FreeBSD/ ftp://ftp4.de.FreeBSD.org/pub/FreeBSD/ ftp://ftp5.de.FreeBSD.org/pub/FreeBSD/ ftp://ftp6.de.FreeBSD.org/pub/FreeBSD/ ftp://ftp7.de.FreeBSD.org/pub/FreeBSD/ 香港 ftp://ftp.hk.super.net/pub/FreeBSD/ 連絡先: ftp-admin@HK.Super.NET ハンガリー 何か問題がある場合は、このドメインの hostmaster mohacsi@ik.bme.hu に連絡してください。 ftp://ftp.hu.FreeBSD.org/pub/FreeBSD/ アイスランド 何か問題がある場合は、このドメインの hostmaster hostmaster@is.FreeBSD.org に連絡してください。 ftp://ftp.is.FreeBSD.org/pub/FreeBSD/ アイルランド 何か問題がある場合は、このドメインの hostmaster hostmaster@ie.FreeBSD.org に連絡してください。 ftp://ftp.ie.FreeBSD.org/pub/FreeBSD/ イスラエル 何か問題がある場合は、このドメインの hostmaster hostmaster@il.FreeBSD.org に連絡してください。 ftp://ftp.il.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.il.FreeBSD.org/pub/FreeBSD/ 日本 何か問題がある場合は、このドメインの hostmaster hostmaster@jp.FreeBSD.org に連絡してください。 ftp://ftp.jp.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.jp.FreeBSD.org/pub/FreeBSD/ ftp://ftp3.jp.FreeBSD.org/pub/FreeBSD/ ftp://ftp4.jp.FreeBSD.org/pub/FreeBSD/ ftp://ftp5.jp.FreeBSD.org/pub/FreeBSD/ ftp://ftp6.jp.FreeBSD.org/pub/FreeBSD/ 韓国 何か問題がある場合は、このドメインの hostmaster hostmaster@kr.FreeBSD.org に連絡してください。 ftp://ftp.kr.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.kr.FreeBSD.org/pub/FreeBSD/ ftp://ftp3.kr.FreeBSD.org/pub/FreeBSD/ ftp://ftp4.kr.FreeBSD.org/pub/FreeBSD/ ftp://ftp5.kr.FreeBSD.org/pub/FreeBSD/ ftp://ftp6.kr.FreeBSD.org/pub/FreeBSD/ リトアニア 何か問題がある場合は、このドメインの hostmaster hostmaster@lt.FreeBSD.org に連絡してください。 ftp://ftp.lt.FreeBSD.org/pub/FreeBSD/ オランダ 何か問題がある場合は、このドメインの hostmaster hostmaster@nl.FreeBSD.org に連絡してください。 ftp://ftp.nl.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.nl.freebsd.org/pub/FreeBSD/ ニュージーランド 何か問題がある場合は、このドメインの hostmaster hostmaster@nz.FreeBSD.org に連絡してください。 ftp://ftp.nz.FreeBSD.org/pub/FreeBSD/ ポーランド 何か問題がある場合は，このドメインの hostmaster hostmaster@pl.FreeBSD.org に連絡してください。 ftp://ftp.pl.FreeBSD.org/pub/FreeBSD/ ポルトガル 何か問題がある場合は、このドメインの hostmaster hostmaster@pt.FreeBSD.org に連絡してください。 ftp://ftp.pt.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.pt.FreeBSD.org/pub/FreeBSD/ ルーマニア 何か問題がある場合は、このドメインの hostmaster hostmaster@ro.FreeBSD.org に連絡してください。 ftp://ftp.ro.FreeBSD.org/pub/FreeBSD/ ロシア 何か問題がある場合は、このドメインの hostmaster hostmaster@ru.FreeBSD.org に連絡してください。 ftp://ftp.ru.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.ru.FreeBSD.org/pub/FreeBSD/ ftp://ftp3.ru.FreeBSD.org/pub/FreeBSD/ ftp://ftp4.ru.FreeBSD.org/pub/FreeBSD/ サウジアラビア 何か問題がある場合は、 ftpadmin@isu.net.sa に連絡してください。 ftp://ftp.isu.net.sa/pub/mirrors/ftp.freebsd.org/ 南アフリカ 何か問題がある場合は、このドメインの hostmaster hostmaster@za.FreeBSD.org に連絡してください。 ftp://ftp.za.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.za.FreeBSD.org/pub/FreeBSD/ ftp://ftp3.za.FreeBSD.org/pub/FreeBSD/ スロヴァキア共和国 何か問題がある場合には、このドメインの hostmaster hostmaster@sk.FreeBSD.org に連絡してください。 ftp://ftp.sk.FreeBSD.org/pub/FreeBSD/ スロベニア 何か問題がある場合には、このドメインの hostmaster hostmaster@si.FreeBSD.org に連絡してください。 ftp://ftp.si.FreeBSD.org/pub/FreeBSD スペイン 何か問題がある場合は、このドメインの hostmaster hostmaster@es.FreeBSD.org に連絡してください。 ftp://ftp.es.FreeBSD.org/pub/FreeBSD/ スウェーデン 何か問題がある場合は、このドメインの hostmaster hostmaster@se.FreeBSD.org に連絡してください。 ftp://ftp.se.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.se.FreeBSD.org/pub/FreeBSD/ ftp://ftp3.se.FreeBSD.org/pub/FreeBSD/ 台湾 何か問題がある場合は、このドメインの hostmaster hostmaster@tw.FreeBSD.org に連絡してください。 ftp://ftp.tw.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.tw.FreeBSD.org/pub/FreeBSD/ ftp://ftp3.tw.FreeBSD.org/pub/FreeBSD/ ftp://ftp4.tw.FreeBSD.org/pub/FreeBSD/ タイ ftp://ftp.nectec.or.th/pub/FreeBSD/ 連絡先: ftpadmin@ftp.nectec.or.th ウクライナ ftp://ftp.ua.FreeBSD.org/pub/FreeBSD/ 連絡先: freebsd-mnt@lucky.net イギリス 何か問題がある場合は、このドメインの hostmaster hostmaster@uk.FreeBSD.org に連絡してください。 ftp://ftp.uk.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.uk.FreeBSD.org/pub/FreeBSD/ ftp://ftp3.uk.FreeBSD.org/pub/FreeBSD/ ftp://ftp4.uk.FreeBSD.org/pub/FreeBSD/ ftp://ftp5.uk.FreeBSD.org/pub/FreeBSD/ アメリカ 何か問題がある場合は、このドメインの hostmaster hostmaster@FreeBSD.org に連絡してください。 ftp://ftp2.FreeBSD.org/pub/FreeBSD/ ftp://ftp3.FreeBSD.org/pub/FreeBSD/ ftp://ftp4.FreeBSD.org/pub/FreeBSD/ ftp://ftp5.FreeBSD.org/pub/FreeBSD/ ftp://ftp6.FreeBSD.org/pub/FreeBSD/ ftp://ftp7.FreeBSD.org/pub/FreeBSD/ ftp://ftp8.FreeBSD.org/pub/FreeBSD/ ftp://ftp9.FreeBSD.org/pub/os/FreeBSD/ ftp://ftp10.FreeBSD.org/pub/FreeBSD/ ftp://ftp11.FreeBSD.org/pub/FreeBSD/ ftp://ftp12.FreeBSD.org/pub/FreeBSD/ ftp://ftp13.FreeBSD.org/pub/FreeBSD/ Anonymous CVS 訳: &a.jp.sugimura;、1998 年 7 月 19 日 <anchor id="anoncvs-intro">導入 Anonymous CVS (もしくは、anoncvs として知られています) は離れたところにある CVS リポジトリと同期を取るために FreeBSD に付属している CVS ユーティリティに含まれている機能です。他にもありますが、 それは FreeBSD のユーザが、特別な権限なしに FreeBSD プロジェクトの公式な anoncvs サーバに読み取り専用で CVS の操作をすることができるようにするためのものです。 それを使うには、単に CVSROOT 環境変数を設定して適切な anoncvs サーバを指定し、 cvs login を使って パスワード anoncvs を入力してください。 そして次に &man.cvs.1; コマンドを使うことで、 手元にあるリポジトリと同じようにアクセスできるようになります。 cvs login コマンドは、CVS サーバの認証に使われるパスワードを HOME ディレクトリの .cvspass というファイルに保存します。 このファイルが存在しなければ、最初に cvs login を使おうとしたときにエラーが出るでしょう。空の .cvspass ファイルを作成して再度ログインに挑戦してください。 CVSup と anoncvs のサービスは本質的に同じ機能ではないかということも言われていますが、 ユーザが同期を取る方法を選ぶときに影響を与える、 さまざまなトレードオフが存在します。要約して言えば、 CVSup はネットワーク資源の使い方においては非常に効率が良く技術的にもはるかに洗練されたものですが、 相当な手間がかかります。CVSup を使うには特別なクライアントをまずインストールして設定しなくては 1 bit も取ってくることができませんし、さらにそのとき CVSup で取ってくることができるのは、 コレクション (collection) と呼ばれる、 かなり大きなかたまりだけです。 それに対して anoncvs では、 CVS モジュールの名前を指定することで特定のプログラムの (ls や grep のような) 個々のファイルから調べることができます。もちろん、 anoncvs は CVS リポジトリの読み取り専用の操作に対してのみ適しているので、 もしあなたが FreeBSD プロジェクトのものと共有されたなにか ローカルなリポジトリを作ってそこでの開発を 行おうというときには、CVSup だけが唯一の手段となってしまいます。 <anchor id="anoncvs-usage">Anonymous CVS を使う &man.cvs.1; を設定して Anonymous CVS リポジトリを使うには単に CVSROOT 環境変数を設定して FreeBSD プロジェクトの anoncvs サーバを指定するだけのことです。 この文書を書いているときには、 次のサーバが利用できるようになっています。 USA: :pserver:anoncvs@anoncvs.freebsd.org:/home/ncvs (cvs login コマンドを使い、 プロンプトが表示されたらパスワード anoncvs を入力してください) ドイツ: :pserver:anoncvs@anoncvs.de.FreeBSD.org:/home/ncvs (cvs login コマンドを使い、 プロンプトが表示されたらパスワード anoncvs を入力してください) ドイツ: :pserver:anoncvs@anoncvs2.de.FreeBSD.org:/home/ncvs (rsh、pserver、ssh、ssh/2022 が使えます) 日本: :pserver:anoncvs@anoncvs.jp.FreeBSD.org:/home/ncvs (cvs login コマンドを使い、 プロンプトが表示されたらパスワード anoncvs を入力してください) CVS はかつて存在した (もしくはこれから存在するものも) ほとんどどんなバージョンの FreeBSD のソースを check out することができますが、あなたは &man.cvs.1; の リビジョン () のオプションや FreeBSD プロジェクトのリポジトリの中で それをどのように指定したらいいものかということを よく知っておく必要があります。 タグには 2 種類あって、 リビジョンタグとブランチタグがあります。 リビジョンタグは特定の改訂版を指しており、 それはいつも同じものを意味しています。一方ブランチタグは、 指定されたときの指定された開発の流れにおける 最も新しい改訂版を示しています。 ブランチタグは特定の改訂版を指していないために、 その意味はきょうと明日では違うものになっているでしょう。 にはユーザが興味を持つであろうリビジョンタグの一覧が載せられています。 これらはいずれも Ports Collection に対して使うことはできません。 Ports Collection は複数のリビジョンを持っていないからです。 ブランチタグを指定したときには、 普通はその開発の流れにおける 最も新しいバージョンのファイルを受け取ることができます。 もし以前のバージョンのものが欲しいときには、日付を オプションを使って指定すればよいです。 これ以上のことは &man.cvs.1; man page を見てください。 例 本当はなにかする前には &man.cvs.1; のマニュアルページの全体をちゃんと読んでからのほうがいいのですが、 Anonymous CVS の使い方の本質的なところを簡単に例を挙げて説明します。 -CURRENT (&man.ls.1;) をちょっと確認してから消してみます。 &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.freebsd.org:/home/ncvs &prompt.user; cvs login プロンプトが表示されたら、パスワード anoncvs を入力します。 &prompt.user; cvs co ls &prompt.user; cvs release -d ls &prompt.user; cvs logout &man.ls.1; のバージョンを 3.X-STABLE ブランチから調べてみます。 &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.freebsd.org:/home/ncvs &prompt.user; cvs login プロンプトが表示されたら、パスワード anoncvs を入力します。 &prompt.user; cvs co -rRELENG_3 ls &prompt.user; cvs release -d ls &prompt.user; cvs logout &man.ls.1; の変更点のリストを (unified diff で) 作ってみます。 &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.freebsd.org:/home/ncvs &prompt.user; cvs login プロンプトが表示されたら、パスワード anoncvs を入力します。 &prompt.user; cvs rdiff -u -rRELENG_3_0_0_RELEASE -rRELENG_3_4_0_RELEASE ls &prompt.user; cvs logout 他のどんなモジュールの名前が 使われているか検索してみます。 &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.freebsd.org:/home/ncvs &prompt.user; cvs login プロンプトが表示されたら、パスワード anoncvs を入力します。 &prompt.user; more modules/modules &prompt.user; cvs release -d modules &prompt.user; cvs logout 他の資料 次の資料は CVS を学ぶのに役に立つでしょう。 CVS チュートリアル Cal Poly によるものです。 CVS Home、 CVS の開発とサポートをしているコミュニティです。 CVSWeb - は FreeBSD Project の CVS のための WWW インターフェースです。 + は FreeBSD Project の CVS のための WWW インタフェースです。 CTM を使う 訳: &a.hanai;、1997 年 9 月 13 日 CTM はリモートのディレクトリツリーを中央のツリーに同期させるための 手段です。 これはFreeBSDのソースツリーの配布を行なうために開発されまし たが、時が経つにつれて別の目的にも有用であることがわかるかも しれません。 デルタを作り出す処理に関するドキュメントは現在ほとんど ありません。従って、もしあなたがCTM を他のことに使いたいなら &a.phk; にさらなる情報を問い合わせてください。 なぜ <application>CTM</application> を使うの? CTM を使うことにより FreeBSD ソースツリーのローカルコピーを手にいれることができます。 ソースツリーが使えることの魅力は数多くあります。完全な cvs ツリーを追いかけるにしても、ひとつのブランチを追いかける にしても CTM は必要な情報を与えてくれます。 もしあなたが FreeBSD のアクティブな開発者であるにもかかわらず お粗末な TCP/IP 接続しか持っていなかったり、または TCP/IP 接続が 行なえないとしたら、あるいは単に変更が自動的に送られてきて ほしいというのであれば CTM はそんなあなたのために 作られたのです。 アクティブなブランチでは 1 日に最大三つまでのデルタを受け取る必要があります。 これが自動的に e-mail で送られてくるという方法を ぜひ検討してみてください。 デルタのサイズは常にできるだけ小さく保たれています。 大抵の場合 5KB よりも小さく、 たまに (10 回に 1 回程度) 10-50KB になり、 ときおり 100KB かもっと大きくなるでしょう。 開発ソースから直接に得られたものを使うことについては、 あらかじめパッケージにされたリリースとは違い、 いろいろと注意することが あります。これは特に current のソースを選んでいるときは重要です。 最新の FreeBSD を追いかけるを読むことをお勧めします。 <application>CTM</application>を使うには何が必要? 二つのものが必要でしょう: CTM プログラムとそれに与える (current レベルを得るための) 最初のデルタです。 CTM プログラムはバージョン 2.0 のリリース以来 FreeBSD の一部にな りました。もしソースのコピーを持っているなら /usr/src/usr.sbin/CTMにあります。 もしFreeBSDの 2.0 以前のバージョンなら、 最新の CTM のソースを直接 ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-current/src/usr.sbin/ctm/ から入手できます。CTM に与える デルタ は二つの方法、FTP または e-mail、 で得ること ができます。 もしインターネットに FTP アクセスできるなら、 次の FTP サイト: ftp://ftp.FreeBSD.org/pub/FreeBSD/CTM/ または、そのミラーサイトが CTM へのアクセスをサポートします。 適切なディレクトリに FTP して README ファイルを入手し、そこからスタートしてください。 e-mail によってデルタを得たいという場合は: CTM 配布メーリングリストのいずれかに参加するために &a.majordomo; へ subscribe のメールを送ってください。 ctm-cvs-cur は完全な CVS ツリー をサポートします。ctm-src-cur は開発先端ブランチをサポートします ctm-src-2_2 は 2.2 リリースのブランチのサポートです (もし majordomo を使って参加する方法を知らないのであれば、 最初に help という語を含むメッセージを送ってください。— 使い方の説明が送られてくるでしょう)。 メールで CTM による更新ファイルを受け取り始めると、中身を取り出して使用 するために ctm_rmail プログラムを使うかもしれません。それを完全 に自動で行ないたいなら、/etc/aliases から ctm_rmailプロ グラムを直接使うこともできます。 さらに詳しいことは ctm_rmail manページを御覧ください。 CTM デルタを得るためにどの方法を使うのであっても、 ctm-announce@FreeBSD.org メーリングリストに参加するべきです。 このメーリングリストは将来的には CTM システムの操作に関する アナウンスがポストされる唯一の場になるでしょう。 メーリングリストに加わるためには subscribe ctm-announce と書いた一行だけのメールを &a.majordomo; へ送ってください。 はじめて <application>CTM</application> を使い始める CTM デルタを使い始めるためには、これは以降作られる全ての デルタの出発点を手にいれる必要があります。 最初にあなたが何をすでに持っているかをはっきりさせましょう。 すべての人は 空 のディレクトリから始めなければなりません。 ツリーをサポートしてるあなたの CTM を稼働するためには 指定した 空 のデルタを使う必要があります。いくつかの分岐点 では、あなたの都合により CD 内に分配されている スタータ デルタを使用できるようになっています。しかしながら、これは 頻繁に行われることではありません。 適切な出発点が決まれば、その出発点を CTM が 維持するツリーへ変換するための スタータ 初期デルタを使う必要が あります。 移行デルタは番号の後ろに X をつけたものがそうです (たとえば src-cur.3210XEmpty.gz)。 X の後ろは最初の開始ポイントに対応します。 Empty は 空のディレクトリです。 ルールとして Empty からの移行デルタは 100 デルタごとに 作られます。ところで、 これらは非常に大きいです! XEmptyのデルタは 数十 MB の gzip で圧縮されたデータというのが普通です。 一度スタートするためのベースデルタを得ると、 それに続く多数のすべてのデルタも必要になるでしょう。 <application>CTM</application> を日常で使う デルタを適用するためには、単に &prompt.root; cd /where/ever/you/want/the/stuff &prompt.root; ctm -v -v /where/you/store/your/deltas/src-xxx.* とします。 CTM はどれが gzip されているか理解します。 従って最初に gunzip しておく必要はありません。 ディスクの節約にもなります。 全体の処理に関して確信するまでは CTM は (ソース) ツリーに対して 何もしません。また、デルタを確かめるためには フラグを使うことができます。 このフラグがあると CTM はツリーに対して実際には何も行ないません。 単にデルタの完全性を確認し、 現在のツリーに問題なく使用できるかを確認 するだけです。 CTM には他にもオプションがあります。詳細に関しては マニュアルページを参照するかソースを見てください。 以上でやることは本当に全部です。 新しいデルタを入手した時には、 ソースを最新のものにするためにそれを CTMに通すだけです。 もしデルタを再ダウンロードするのが 骨の折れる作業であれば、デルタを消さないでおいてください。 なにかおかしなことが起こった場合には置いておけば良かった と思うかもしれません。 もしフロッピーディスクしか持っていない状況 であってもコピーを取るのに fdwrite を使うことを考えてください。 ローカルの変更を保存する 開発者としてはソースツリー中のファイルを 使って実験したり変更したく なるものです。 CTM はローカルの変更を制限つきでサポートします: ファイル foo の存在をチェックする前に、 foo.ctm を参照しにいきます。 このファイルが存在する場合、CTM は foo の代りにこれを処理します。 この動作はローカルの変更を保持する簡単な手段を 提供します: 単に変更したいファイルを拡張子 .ctm 付きのファイル名で コピーするだけです。あとは自由にコードをハックでき、 .ctm ファイルの方は CTM が最新状態に保ってくれます。 <application>CTM</application> のその他の面白いオプション 更新で変更されるファイルを正確に知る CTM のソースリポジトリに対する変更のリストを オプションを使って決定することができます。 これは、変更のログを保存したい、 変更されたファイルをなんらかの方法で 前・後処理したい、 または単にこだわりたい場合には、 役に立つでしょう。 更新前にバックアップを取る CTM の更新によって変更されるファイルすべてのバックアップを 取りたくなることがあります。 オプションを指定すると CTM は デルタで変更されるファイルすべてを backup-file としてバックアップするようになります。 更新で変更されるファイルを制限する CTM の更新の範囲を制限したり一連のデルタのから ほんの数ファイルを抽出したくなることがあります。 と オプションを用い正規表現を指定することで、 CTM が処理するファイルのリストを制御することが できます。 例えば、lib/libc/Makefile の最新のコピーを保存してある CTM デルタのコレクションから抽出するには、 以下のコマンドを実行します。 &prompt.root; cd /where/ever/you/want/to/extract/it/ &prompt.root; ctm -e '^lib/libc/Makefile' ~ctm/src-xxx.* CTM デルタで指定されたファイルごとに、 そして オプションがコマンドラインで指定された順序で適用されます。 すべての そして オプションが適用された後に更新対象と選択された場合に限り、 CTM はそのファイルを処理します。 <application>CTM</application>の将来計画 重要なもの なんらかの CTM システムへの認証機構を用い、不正な CTM の更新の検出を可能とする。 CTM へのオプションを整理する。さもないと混乱し、 直観に反したものになります。 その他 ports コレクションに対するデルタもあるのですが、 これに興味を持っている人はまだ少ないようです。 もしこれに対するメーリングリストが欲しい時はセットアップを行ないますので、 わたしの方まで連絡ください。 CTM サイト CTM/FreeBSD は以下のミラーサイトから anonymous FTP によって入手できます。 もし CTM を anonymous FTP によって手にいれる場合は、 近くのサイトを利用するようにしてください。 何か問題がある場合は、&a.phk; に連絡してください。 カリフォルニア、サンフランシスコ近辺、 公式なソース ftp://ftp.FreeBSD.org/pub/FreeBSD/CTM/ ドイツ、トリエル ftp://ftp.uni-trier.de/pub/unix/systems/BSD/FreeBSD/CTM/ 南アフリカ、ctm、sup、 CVSupなどの古い差分ファイルのバックアップサーバ ftp://ftp.za.FreeBSD.org/pub/FreeBSD/CTM/ 台湾/中華民国、チャーイー (嘉義) ftp://ctm.tw.FreeBSD.org/pub/freebsd/CTM/ ftp://ctm2.tw.FreeBSD.org/pub/FreeBSD/CTM/ ftp://ctm3.tw.FreeBSD.org/pub/freebsd/CTM/ 近くにミラーサイトがない場合やミラーが不完全な場合は、 http://ftpsearch.ntnu.no/ftpsearch/ の FTP search を試してください。 FTP search はノルウェーの Trondheim にある、 フリーの素晴らしい アーカイブサーバです。 CVSup を使う 訳: &a.jp.iwasaki;、1997 年 2 月 27 日 紹介 CVSup は、 リモートのサーバホストにあるマスタ CVS リポジトリから ソースツリーを配布し更新するための ソフトウェアパッケージです。FreeBSD のソースは、 カリフォルニアにある中心的な開発マシンの CVS リポジトリの 中でメンテナンスしています。CVSup を使用することで、FreeBSD ユーザは 簡単に自分のソースツリーを最新の状態に しておくことができます。 CVSup は pull モデルとよばれる更新のモデルを採用しています。pull モデルでは、 各クライアントが更新したい場合に更新したい時点で、 サーバに更新の問い合わせをおこないます。 サーバはクライアントからの 更新の要求を受け身の状態で待ちます。したがって、 すべての更新はクライアント主導でおこなわれます。 サーバは頼まれもしない更新情報を送るようなことはしません。 ユーザは CVSup クライアントを手動で実行して更新をおこなうか、 cron ジョブを設定して定期的に自動実行する必要があります。 用語 CVSup のように大文字で表記しているものは、ソフトウェアパッケージ 全体を指します。主な構成物は、 各ユーザマシンで実行するクライアントである cvsup、FreeBSD の各ミラーサイトで実行するサーバ cvsupd です。 FreeBSD の文書やメーリングリストを読んだ際に、 sup についての言及を 見かけたかもしれません。sup は CVSup の前に存在していたもので、 同様の目的で使われていました。 CVSup は sup と同じように使用されており、実際、sup と互換性のあるコンフィグレーションファイルを使用します。 CVSup の方がより高速で柔軟性もあるので、もはや sup は FreeBSD プロジェクトでは使用されていません。 インストール CVSup をインストールする最も簡単な方法は、FreeBSD Ports コレクションのパッケージ からコンパイル済みの net/cvsup パッケージをインストールすることです。 もしくは、net/cvsup でも構いません。 ただし、net/cvsup は Modula-3 システムに依存していて、構築にかかる時間、 ディスクスペースは比較的大きくなります。 たとえばサーバのような XFree86 がインストールされていない計算機で CVSup を使おうとしているのであれば、必ず CVSup GUI が含まれていない net/cvsup-without-gui を使ってください。 もし、あなたに CVSup に関してまったく知識がなく、 自動で設定ファイルをセットアップして、 - クリックするだけで転送を行なえるインターフェイスを提供してくれるような、 + クリックするだけで転送を行なえるインタフェイスを提供してくれるような、 単一のパッケージをインストールしたいと考えているなら、 net/cvsupit パッケージを利用して下さい。 これは &man.pkg.add.1; するだけで良く、 設定は、その際にメニュー形式で行なうことができるようになっています。 CVSup のコンフィグレーション CVSup の動作は、supfile と呼ばれるコンフィグレーションファイルで制御します。 supfile のサンプルは、ディレクトリ /usr/share/examples/cvsup/ の下にあります。 supfile には以下の cvsup に関する質問への答えを記述します: どのファイルを受け取りたいのか? どのバージョンのものが欲しいのか? どこから入手したいのか? 自分のマシンのどこに置きたいのか? どこに status ファイルを置きたいのか? 次のセクションで、これらの質問に順番に答えながら典型的な supfile を組み立てていきます。最初に supfile の全体構造を説明します。 supfile はテキストファイルです。 コメントは # から行末までです。 空行とコメントだけの行は無視します。 残りの各行には、 ユーザが受け取りたいファイル群について記述します。 行の始めは、 サーバ側で定義した論理的なファイルのグループである コレクション の名称です。 コレクションの名称を指定して、欲しいファイル群を サーバに伝えます。コレクション名の後には、 ホワイトスペースで区切られた 0 個以上のフィールドが続きます。 これらのフィールドが上記の質問に対する答えになります。 フィールドには 2 種類あります: flag フィールドと value フィールドです。flag フィールドは delete や compress のような 単独のキーワードから成ります。また、value フィールドもキーワードで始まりますが、 キーワードの後にはホワイトスペースは入らず、 = と二つめの単語が続きます。例えば、 release=cvs は value フィールドです。 通常、supfile には受け取りたいコレクションを一つ以上指定します。 supfile を組み立てる一つの方法として、 コレクション毎にすべての関係の あるフィールドを明示的に指定する方法があります。しかし、 これでは supfile のすべてのコレクションに対して ほとんどのフィールドが同じになるため、 行が非常に長くなってしまい不便になります。 これらの問題を避けるため、CVSup ではデフォルトを指定することのできる メカニズムが提供されています。特殊な擬似コレクション名 *default で始まる行は、 supfile 中の後続の コレクションに対して使用する flag フィールドと value フィールドのデフォルトを設定するために利用できます。 個々のコレクションで固有の値を指定すると、 デフォルト値を無効にできます。また 行を追加すると、supfile の途中からデフォルト値の変更や追加が可能になります。 これまでの予備知識を基に、 FreeBSD-current のメインのソースツリーを受け取って更新するための supfile を組み立ててみましょう。 どのファイルを受け取りたいのか? CVSup を通して入手できるファイルは コレクション と呼ばれる名前の付けられたグループにまとめられています。 利用可能なコレクションについては 後の節の中で説明しています。 ここでは、FreeBSD システムのメインのソースツリー全体 を受け取るための設定例を紹介します。 すべてを含む src-all という単一の大きなコレクションがあります。 supfile を組み立てる最初のステップとして、 これらのコレクションを一行に一つずつ記述します (この場合は一行だけです)。 src-all どのバージョンのものが欲しいのか? CVSup を使用すると、 かつて存在していたことのある、事実上どのバージョンの ソースでも受け取ることができます。これは cvsupd サーバがすべてのバージョンを含む CVS リポジトリに基づいて動作することにより、 実現されています。 tag= および の value フィールドを使用して、 欲しいバージョンの 一つを指定します。 tag= のフィールドの指定は正確に行うように十分注意 してください。いくつかのタグは特定のコレクションに 対してのみ有効です。 タグの綴りが違っていたり不適切なタグを指定すると、 CVSup はユーザが消し たくないファイルまで削除してしまいます。特に ports-* のコレクション に対しては tag=. だけ を指定するようにしてください。 tag= フィールドはリポジトリ中のシンボリックタグを指定します。 tag には revision tag と branch tag の二種類があります。 revision tag は特定のリビジョンを指します。これは、 毎日同じ状態に保つことになります。一方 branch tag は、 ある時点での開発分流の最新のリビジョンを指します。 branch tag は特定のリビジョンを指定している訳ではないので、 今日と明日では 異なるリビジョンを参照することになるかもしれません。 にはユーザが興味を持つであろうリビジョンタグの一覧が載せられています。 CVSup の設定ファイル中でタグを指定する時は、 tag= に続けて書きます (RELENG_4 は tag=RELENG_4 になります)。 tag=. だけが ports コレクションには 適切であることに注意してください。 tag 名を示した通りにタイプされているか十分注意してく ださい。CVSup は tag 名が正しいかどうかを見分けることはできません。tag が間違っていた場合、 たまたまファイルがまったく存在しない正しい tag が 指定されたものとしてCVSup は動作します。その場合は、現在あるソースが削 除されるでしょう。 branch tag を指定した際には、 通常はその開発分流の最新バージョンの ファイルを受け取ります。 いくらか前のバージョンを受け取りたい場合は、 の value フィールドを使って日付を指定することで、 これを実現することが できます。&man.cvsup.1; のマニュアルページで、 その方法を説明しています。 例として、FreeBSD-current を受け取りたいとします。 次の行を supfile の始めに追加します: *default tag=. tag= フィールドも date= フィールドも指定しなかった場合に 動き出す重要な特殊なケースがあります。そのケースでは、 特定のバージョンの ファイルを受け取るのではなく、 サーバの CVS リポジトリから実際の RCS ファイルを直接受け取ります。 一般的に開発者はこの処理のモードが好きなようです。 彼らのシステム上にリポジトリそのものの コピーを維持することで、 リビジョン履歴を閲覧し過去のバージョンの ファイルを検査できるようになります。しかし、 これには大きなディスクスペースが必要になります。 どこから入手したいのか? 更新情報をどこから入手するかを cvsup に伝えるために host= フィールドを使用します。 CVSup ミラーサイト のどこからでも入手できますが、 ネット上での最寄りのサイトを選ぶべきでしょう。 この例では、仮想上の FreeBSD 配布サイト cvsup666.FreeBSD.org を使用します: *default host=cvsup666.FreeBSD.org CVSup を実行する前にホスト名を 実在のものに変更する必要があります。どのように cvsup を実行しても、この設定は を 使用してコマンドラインで変更することができます。 自分のマシンのどこに置きたいのか? prefix= フィールドは、 cvsup に受け取ったファイルをどこに置くかを伝えます。 この例では、ソースファイルを直接メインのソースツリー /usr/src に置きます。 src ディレクトリはすでにファイルを受け取るために 選択したコレクションで暗黙に指定しているので、 これは正しい仕様となります: *default prefix=/usr どこに status ファイルを置きたいのか? CVSup クライアントは base ディレクトリと呼ばれる場所に、ある status ファイルを維持しています。 すでに受け取った更新情報を追従し続けることで、 これらのファイルは CVSup がより効果的に動作することを支援します。標準の base ディレクトリ /usr/local/etc/cvsup を使用します: *default base=/usr/local/etc/cvsup supfile に指定がない場合は、 この設定をデフォルトで使用しますので、 実際には上の行は必要ありません。 base ディレクトリが存在しない場合は作成しておきましょう。base ディレクトリが存在しない場合、cvsup クライアントは実行を拒否します。 その他もろもろの supfile の設定: 通常 supfile に入れておくべき行がもう一つあります: *default release=cvs delete use-rel-suffix compress release=cvs は、サーバがメインの FreeBSD CVS リポジトリから その情報を取得するように指示します。 ほとんどの場合はこのようにしておきますが、 ここでの説明の範疇をこえるような 状況では他の指定をすることも可能です。 delete は CVSup にファイルを削除することを許可します。 CVSup が ソースツリーを完全に最新の状態に 保てるようにするためには、これは常に 指定しておくべきでしょう。 CVSup は、 これらの責任範囲のファイルだけを慎重に削除します。 たまたま存在する他の余分なファイルについては、 まったく手をつけずに残しておきます。 use-rel-suffix は、…神秘的なものです。これについて本当に知りたい人は、 &man.cvsup.1; のマニュアルページをご覧ください。 でなければ、何も考えずに指定してみてください。 compress は通信チャネルで gzip 形式の圧縮の使用を有効にします。 ご使用のネットワーク接続が T1 speed 以上である場合、 この圧縮を使用しない方がよいかもしれません。 そうでない場合は十分に役に立ちます。 supfile の例のまとめ: 以下は supfile の例の全体です: *default tag=. *default host=cvsup666.FreeBSD.org *default prefix=/usr *default base=/usr/local/etc/cvsup *default release=cvs delete use-rel-suffix compress src-all 拒否ファイル (refuse file) 既に述べたように、CVSup は取り寄せ法 (pull method)を用いるのですが、 これは基本的に次のようなことを意味します。 まずあなたが CVSup サーバに接続します。 するとサーバは あなたがダウンロードできるのはこれこれです と言います。 それに対し、あなたが使っているクライアントは わかりました。 では、これとこれとこれをもらいます と答えます。 デフォルトの設定の CVSup クライアントは、 設定ファイルで選んだコレクションとタグに適合する すべてのファイルを取得します。 しかし、これは常にあなたの望む動作と一致するとは限りません。 特に doc や ports や www のツリーを同期させる場合などはそうでしょう。 ほとんどの人は四か国語も五か国語も操れるわけではありませんから、 特定の言語のファイルのダウンロードは必要ないでしょう。 Ports コレクションを CVSup で取得する場合には、各コレクションを個別に指定することができます (たとえば、単に ports-all とするかわりに ports-astrology、 ports-biology などと書きます)。 一方、doc と www のツリーは言語別のコレクションになっていません。 そこであなたは CVSup のたくさんある洗練された機能の一つ、 拒否ファイル (refuse file) 機能を使う必要があります。 拒否ファイル (refuse file) は CVSup に対し、 コレクションに含まれる一部のファイルを取得することを伝えます。 言い換えれば、それはクライアントに対し、 サーバから来る一部のファイルを拒否するよう指定するということです。 拒否ファイルは base/sup/refuse にあります (もしファイルがない場合には作成してください)。 base は supfile 内で定義されています。 デフォルトでは /usr/local/etc/cvsup です。つまり、 拒否ファイルのデフォルトは /usr/local/etc/cvsup/sup/refuse ということになります。 拒否ファイルの書式は、単にダウンロードしたくないファイルや ディレクトリの名前が書いてあるだけの非常にシンプルなものです。 たとえば、英語以外にはドイツ語を少し話せるだけの人で、 ドイツ語のアプリケーション (やその他英語以外の言語のためのアプリケーション) を必要と感じなければ 以下のような拒否ファイルが考えられます。 ports/chinese ports/french ports/german ports/hebrew ports/japanese ports/korean ports/russian ports/ukrainian ports/vietnamese doc/de_DE.ISO8859-1 doc/el_GR.ISO8859-7 doc/es_ES.ISO8859-1 doc/fr_FR.ISO8859-1 doc/it_IT.ISO8859-15 doc/ja_JP.eucJP doc/nl_NL.ISO8859-1 doc/pt_BR.ISO8859-1 doc/ru_RU.KOI8-R doc/sr_YU.ISO8859-2 doc/zh_TW.Big5 他の言語についても同様です (全リストは FreeBSD FTP サーバ をご覧になってください)。 拒否ファイルの中ではリポジトリの名前が ディレクトリ の先頭部分に対応することに注意してください。 この実に便利な機能を使うと まったく必要としないファイルをダウンロードする必要がなくなり、 インターネット接続の回線が遅かったり従量制で課金されている人は 貴重な時間を節約できるようになります。 拒否ファイルの詳細や CVSup が持つその他の便利な機能に関しては マニュアルページを参照してください。 <application>CVSup</application> の実行 さて、更新の準備ができました。 これを実行するコマンドラインは実に簡単です: &prompt.root; cvsup supfile もちろん、ここでの supfile は作成したばかりの supfile のファイル名です。X11 環境で実行するものと仮定して、cvsup は 通常の操作に必要なボタンを持つ GUI ウィンドウを表示します。 go ボタンを押して、 実行を監視してください。 この例では実際の /usr/src ツリーを更新しているので、cvsup にファイルを更新するのに必要なパーミッションを与えるために、 ユーザ root で実行する必要があります。 コンフィグレーションファイルを作ったばかりで、 しかも以前にこのプログラムを実行したことがないので、 神経質になるのは無理もない話だと思います。 大切なファイルに触らずに試しに実行する簡単な方法があります。 どこか適当な場所に空のディレクトリを作成して、 コマンドラインの引数で指定するだけです: &prompt.root; mkdir /var/tmp/dest &prompt.root; cvsup supfile /var/tmp/dest 指定したディレクトリは、すべての更新されるファイルの 更新先ディレクトリとして使用します。 CVSup は /usr/src の下のファイルを検査しますが、 変更や削除はまったくおこないません。かわりに /var/tmp/dest/usr/src に更新されたすべてのファイルが置かれるようになります。 この方法で実行した場合は、CVSup は base ディレクトリの status ファイルを更新せずにそのままにします。 これらのファイルの新しいバージョンは指定されたディレクトリ に書き込まれます。/usr/src の読み取り許可がある限り、このような試し実行のためにユーザ root になる必要はありません。 X11 を利用していないとか単に GUI が気に入らない場合は、 cvsup 起動時にコマンドラインに 二つほどオプションを追加する必要があります: &prompt.root; cvsup -g -L 2 supfile オプションは CVSup に GUI を使用しないように伝えます。X11 を利用していない場合には自動的に指定されますが、 そうでない場合は明示的に指定します。 オプションは cvsup にファイル更新中の詳細情報をプリントアウト するように伝えます。冗長性には から までの三つのレベルがあります。 デフォルトは 0 であり、エラーメッセージ以外はまったく出力 しません。 たくさんの他のオプション変数があります。 それらの簡単な一覧は cvsup -H で表示されます。 より詳しい説明はマニュアルページをご覧ください。 動作している更新の方法に満足したら、&man.cron.8; を使って CVSup を定期的に 実行させる準備をすることができます。cron から起動する際には、 明示的に CVSup が GUI を使わないようにする必要があります。 <application>CVSup</application> ファイルコレクション CVSup 経由で入手できるファイルコレクションは 階層的に組織化されています。 いくつか大きなコレクションがあり、 それらは小さなサブコレクションに 分割されています。 大きなコレクションは、そのサブコレクション毎に 受信することと同じことになります。 下の一覧ではコレクション間の階層関係を 字下げして表現します。 最も一般的に使用するコレクションは src-all、 ports-all です。 他のコレクションは特別な目的を持つ人達だけが使用しており、 ミラーサイトはそれらのすべてを 持っていないかもしれません。 cvs-all release=cvs メインの FreeBSD CVS リポジトリであり、 暗号のコードを含んでいます。 distrib release=cvs FreeBSD の配布とミラーに関連するファイルです。 doc-all release=cvs FreeBSD ハンドブックおよびその他のドキュメントのソースです。 これには FreeBSD web サイトのファイルは含まれません。 ports-all release=cvs FreeBSD の Ports コレクションです。 ports-archivers release=cvs アーカイビングのツール。 ports-astro release=cvs 天文学関連の ports。 ports-audio release=cvs サウンドサポート。 ports-base release=cvs /usr/ports のトップにあるその他のファイル。 ports-benchmarks release=cvs ベンチマークプログラム。 ports-biology release=cvs 植物学関連のプログラム。 ports-cad release=cvs CAD ツール。 ports-chinese release=cvs 中国語サポート。 ports-comms release=cvs 通信ソフトウェア。 ports-converters release=cvs 文字コードコンバータ。 ports-databases release=cvs データベース。 ports-deskutils release=cvs コンピュータが発明される前に 卓上で使われていたものたち。 ports-devel release=cvs 開発ユーティリティ。 ports-editors release=cvs エディタ。 ports-emulators release=cvs 他の OS のエミュレータ。 ports-ftp release=cvs FTP クライアントとサーバ。 ports-games release=cvs ゲーム。 ports-german release=cvs ドイツ語サポート。 ports-graphics release=cvs グラフィックユーティリティ。 ports-irc release=cvs インターネットリレーチャット (IRC) 用のユーティリティ。 ports-japanese release=cvs 日本語サポート。 ports-java release=cvs Java ユーティリティ。 ports-korean release=cvs 韓国語サポート。 ports-lang release=cvs プログラミング言語。 ports-mail release=cvs メールソフトウェア。 ports-math release=cvs 数値計算ソフトウェア。 ports-mbone release=cvs MBone アプリケーション。 ports-misc release=cvs 色々なユーティリティ。 ports-net release=cvs ネットワーキングソフトウェア。 ports-news release=cvs USENET ニュースのソフトウェア。 ports-palm release=cvs 3Com Palm シリーズ用ソフトウェア。 ports-print release=cvs 印刷ソフトウェア。 ports-russian release=cvs ロシア語サポート。 ports-security release=cvs セキュリティユーティリティ。 ports-shells release=cvs コマンドラインシェル。 ports-sysutils release=cvs システムユーティリティ。 ports-textproc release=cvs 文書処理ユーティリティ (デスクトップパブリッシングは含まない)。 ports-vietnamese release=cvs ベトナム語サポート。 ports-www release=cvs World Wide Web 関連のソフトウェア。 ports-x11 release=cvs X window システムをサポートする ports。 ports-x11-clocks release=cvs X11 上で動作する時計の数々。 ports-x11-fm release=cvs X11 上で動作するファイラ。 ports-x11-fonts release=cvs X11 のフォントとフォントユーティリティ。 ports-x11-toolkits release=cvs X11 のツールキット。 ports-x11-servers 各種 X11 サーバ。 ports-x11-wm release=cvs X11 のウィンドウマネージャ。 src-all release=cvs メインの FreeBSD ソース群であり、 暗号のコードを含んでいます。 src-base release=cvs /usr/src のトップにあるその他のファイル。 src-bin release=cvs シングルユーザモードで必要な ユーザユーティリティ (/usr/src/bin)。 src-contrib release=cvs FreeBSD プロジェクト外部からの ユーティリティおよびライブラリ、 比較的無修正 (/usr/src/contrib)。 src-crypto release=cvs FreeBSD プロジェクトの外部で開発された暗号ユーティリティとライブラリで、 ほとんどそのままの形で使われます (/usr/src/crypto)。 src-eBones release=cvs Kerberos と DES (/usr/src/eBones) のこと。 現在の FreeBSD リリースでは使われていません。 src-etc release=cvs システムコンフィグレーションファイル (/usr/src/etc)。 src-games release=cvs ゲーム (/usr/src/games)。 src-gnu release=cvs GNU Public License 下にあるユーティリティ (/usr/src/gnu)。 src-include release=cvs ヘッダファイル (/usr/src/include)。 src-kerberos5 release=cvs Kerberos5 セキュリティパッケージ (/usr/src/kerberos5)。 src-kerberosIV release=cvs KerberosIV セキュリティパッケージ (/usr/src/kerberosIV)。 src-lib release=cvs ライブラリ (/usr/src/lib)。 src-libexec release=cvs システムプログラムであり、 通常は他のプログラムから実行される (/usr/src/libexec)。 src-release release=cvs FreeBSD の release を構築するために必要なファイル (/usr/src/release)。 src-sbin release=cvs シングルユーザモード用の システムユーティリティ (/usr/src/sbin)。 src-secure release=cvs 暗号化ライブラリとコマンド (/usr/src/secure)。 src-share release=cvs 多様なシステム間で共有可能なファイル (/usr/src/share)。 src-sys release=cvs カーネル (/usr/src/sys)。 src-sys-crypto release=cvs カーネル用の暗号コード (/usr/src/sys/crypto)。 src-tools release=cvs FreeBSD の保守用の色々なツール (/usr/src/tools)。 src-usrbin release=cvs ユーザユーティリティ (/usr/src/usr.bin)。 src-usrsbin release=cvs システムユーティリティ (/usr/src/usr.sbin)。 www release=cvs FreeBSD WWW サイトのソースです。 distrib release=self CVSup サーバ自身のコンフィグレーションファイルです。CVSup ミラーサイトが使用します。 gnats release=current GNATS バグトラッキングデータベースです。 mail-archive release=current FreeBSD 関連メーリングリストのアーカイブ。 www release=current 前処理された FreeBSD www サイトのファイルです (ソースではありません)。 WWW ミラーサイトが使用します。 詳細について CVSup の FAQ や CVSup に関するその他の情報については The CVSup Home Page をご覧ください。 CVSup のほとんどの FreeBSD 関連の議論は &a.hackers; でおこなわれています。 ソフトウェアの新しいバージョンは &a.announce; で アナウンスされます。 質問とバグ報告はプログラムの作者、 cvsup-bugs@polstra.com へ 送ってください。 CVSup サイト FreeBSD の CVSup サーバは以下のサイトで稼働しています: アルゼンチン cvsup.ar.FreeBSD.org (保守担当 msagre@cactus.fi.uba.ar) オーストラリア cvsup.au.FreeBSD.org (保守担当 dawes@xfree86.org) cvsup3.au.FreeBSD.org (保守担当 FreeBSD@admin.gil.com.au) オーストリア cvsup.at.FreeBSD.org (保守担当 postmaster@wu-wien.ac.at) ブラジル cvsup.br.FreeBSD.org (保守担当 cvsup@cvsup.br.FreeBSD.org) cvsup2.br.FreeBSD.org (保守担当 tps@ti.sk) cvsup3.br.FreeBSD.org (保守担当 camposr@matrix.com.br) cvsup4.br.FreeBSD.org (保守担当 cvsup@tcoip.com.br) カナダ cvsup.ca.FreeBSD.org (保守担当 dan@jaded.net) cvsup2.ca.FreeBSD.org (保守担当 hostmaster@ca.FreeBSD.org) 中国 cvsup.cn.FreeBSD.org (保守担当 phj@cn.FreeBSD.org) チェコ cvsup.cz.FreeBSD.org (保守担当 cejkar@dcse.fee.vutbr.cz) デンマーク cvsup.dk.FreeBSD.org (保守担当 jesper@skriver.dk) エストニア cvsup.ee.FreeBSD.org (保守担当 taavi@uninet.ee) フィンランド cvsup.fi.FreeBSD.org (保守担当 count@key.sms.fi) cvsup2.fi.FreeBSD.org (保守担当 count@key.sms.fi) フランス cvsup.fr.FreeBSD.org (保守担当 hostmaster@fr.FreeBSD.org) cvsup2.fr.FreeBSD.org (保守担当 ftpmaint@uvsq.fr) cvsup3.fr.FreeBSD.org (保守担当 ftpmaint@enst.fr) cvsup4.fr.FreeBSD.org (保守担当 ftpmaster@t-online.fr) cvsup5.fr.FreeBSD.org (保守担当 freebsdcvsup@teaser.net) cvsup8.fr.FreeBSD.org (保守担当 ftpmaint@crc.u-strasbg.fr) ドイツ cvsup.de.FreeBSD.org (保守担当 cvsup@cosmo-project.de) cvsup2.de.FreeBSD.org (保守担当 cvsup@nikoma.de) cvsup3.de.FreeBSD.org (保守担当 ag@leo.org) cvsup4.de.FreeBSD.org (保守担当 cvsup@cosmo-project.de) cvsup5.de.FreeBSD.org (保守担当 &a.rse;) cvsup6.de.FreeBSD.org (保守担当 adminmail@heitec.net) cvsup7.de.FreeBSD.org (保守担当 karsten@rohrbach.de) ギリシャ cvsup.gr.FreeBSD.org (保守担当 ftpadm@duth.gr) cvsup2.gr.FreeBSD.org (保守担当 paschos@cs.uoi.gr) アイスランド cvsup.is.FreeBSD.org (保守担当 hostmaster@is.FreeBSD.org) アイルランド cvsup.ie.FreeBSD.org (保守担当 dwmalone@maths.tcd.ie)、 トリニティ大学、ダブリン 日本 cvsup.jp.FreeBSD.org (保守担当 cvsupadm@jp.FreeBSD.org) cvsup2.jp.FreeBSD.org (保守担当 &a.max;) cvsup3.jp.FreeBSD.org (保守担当 shige@cin.nihon-u.ac.jp) cvsup4.jp.FreeBSD.org (保守担当 cvsup-admin@ftp.media.kyoto-u.ac.jp) cvsup5.jp.FreeBSD.org (保守担当 cvsup@imasy.or.jp) cvsup6.jp.FreeBSD.org (保守担当 cvsupadm@jp.FreeBSD.org) 韓国 cvsup.kr.FreeBSD.org (保守担当 cjh@kr.FreeBSD.org) cvsup2.kr.FreeBSD.org (保守担当 holywar@mail.holywar.net) ラトビア cvsup.lv.FreeBSD.org (保守担当 system@soft.lv) リトアニア cvsup.lt.FreeBSD.org (保守担当 domas.mituzas@delfi.lt) cvsup2.lt.FreeBSD.org (保守担当 vaidas.damosevicius@sampo.lt) ニュージーランド cvsup.nz.FreeBSD.org (保守担当 cvsup@langille.org) オランダ cvsup.nl.FreeBSD.org (保守担当 xaa@xaa.iae.nl) cvsup2.nl.FreeBSD.org (保守担当 cvsup@nl.uu.net) cvsup3.nl.FreeBSD.org (保守担当 cvsup@vuurwerk.nl) ノルウェー cvsup.no.FreeBSD.org (保守担当 Per.Hove@math.ntnu.no) ポーランド cvsup.pl.FreeBSD.org (保守担当 Mariusz@kam.pl) ポルトガル cvsup.pt.FreeBSD.org (保守担当 jpedras@webvolution.net) ルーマニア cvsup.ro.FreeBSD.org (保守担当 razor@ldc.ro) ロシア cvsup.ru.FreeBSD.org (保守担当 ache@nagual.pp.ru) cvsup2.ru.FreeBSD.org (保守担当 dv@dv.ru) cvsup3.ru.FreeBSD.org (保守担当 fjoe@iclub.nsu.ru) cvsup4.ru.FreeBSD.org (保守担当 zhecka@klondike.ru) cvsup5.ru.FreeBSD.org (保守担当 maxim@macomnet.ru) cvsup6.ru.FreeBSD.org (保守担当 pvr@corbina.net) サンマリノ cvsup.sm.FreeBSD.org (保守担当 sysadmin@alexdupre.com) スロヴァキア共和国 cvsup.sk.FreeBSD.org (保守担当 tps@tps.sk) cvsup2.sk.FreeBSD.org (保守担当 tps@tps.sk) スロベニア cvsup.si.FreeBSD.org (保守担当 blaz@si.FreeBSD.org) 南アフリカ cvsup.za.FreeBSD.org (保守担当 &a.markm;) cvsup2.za.FreeBSD.org (保守担当 &a.markm;) スペイン cvsup.es.FreeBSD.org (保守担当 &a.jesusr;) cvsup2.es.FreeBSD.org (保守担当 &a.jesusr;) cvsup3.es.FreeBSD.org (保守担当 jose@we.lc.ehu.es) スウェーデン cvsup.se.FreeBSD.org (保守担当 pantzer@ludd.luth.se) cvsup2.se.FreeBSD.org (保守担当 cvsup@dataphone.net) 台湾 cvsup.tw.FreeBSD.org (保守担当 jdli@FreeBSD.csie.nctu.edu.tw) cvsup2.tw.FreeBSD.org (保守担当 ycheng@sinica.edu.tw) cvsup3.tw.FreeBSD.org (保守担当 tjs@cdpa.nsysu.edu.tw) ウクライナ cvsup2.ua.FreeBSD.org (保守担当 freebsd-mnt@lucky.net) cvsup3.ua.FreeBSD.org (保守担当 ftpmaster@ukr.net)、キエフ cvsup4.ua.FreeBSD.org (保守担当 phantom@cris.net) cvsup5.ua.FreeBSD.org (保守担当 never@nevermind.kiev.ua) イギリス cvsup.uk.FreeBSD.org (保守担当 ftp-admin@plig.net) cvsup2.uk.FreeBSD.org (保守担当 &a.brian;) cvsup3.uk.FreeBSD.org (保守担当 ben.hughes@uk.easynet.net) cvsup4.uk.FreeBSD.org (保守担当 ejb@leguin.org.uk) cvsup5.uk.FreeBSD.org (保守担当 mirror@teleglobe.net) アメリカ cvsup1.FreeBSD.org (保守担当 cwt@networks.cwu.edu)、 ワシントン州 cvsup2.FreeBSD.org (保守担当 djs@secure.net と &a.nectar;)、 バージニア州 cvsup3.FreeBSD.org (保守担当 &a.wollman)、 マサチューセッツ州 cvsup5.FreeBSD.org (保守担当 mjr@blackened.com)、 アリゾナ州 cvsup6.FreeBSD.org (保守担当 cvsup@cvsup.adelphiacom.net)、 イリノイ州 cvsup7.FreeBSD.org (保守担当 &a.jdp;)、 ワシントン州 cvsup8.FreeBSD.org (保守担当 hostmaster@bigmirror.com)、 ワシントン州 cvsup9.FreeBSD.org (保守担当 &a.jdp;)、 ミネソタ州 cvsup10.FreeBSD.org (保守担当 &a.jdp;)、 カリフォルニア州 cvsup11.FreeBSD.org (保守担当 cvsup@research.uu.net)、 バージニア州 cvsup12.FreeBSD.org (保守担当 &a.will;)、 インディアナ州 cvsup13.FreeBSD.org (保守担当 dima@valueclick.com)、 カリフォルニア州 cvsup14.FreeBSD.org (保守担当 freebsd-cvsup@mfnx.net)、 カリフォルニア州 cvsup15.FreeBSD.org (保守担当 cvsup@math.uic.edu)、 イリノイ州 cvsup16.FreeBSD.org (保守担当 pth3k@virginia.edu)、 バージニア州 cvsup17.FreeBSD.org (保守担当 cvsup@mirrortree.com)、 ワシントン州 CVS タグ cvs や CVSup でソースを入手したり同期させたりするとき、リビジョンタグ (日時で参照されている) を指定しなければなりません。 指定可能なタグを以下に示しますが、それぞれのタグは FreeBSD の異なるブランチの異なる瞬間を指しています。 ports ツリーにはこの手のタグは一切ありません。 つねに CURRENT なのです。 もっとも一般的なタグは以下のとおりです。 HEAD 主要部をなす流れ、すなわち FreeBSD-CURRENT のための名前です。また、 どのリビジョンも指定されなかったときにはこれになります。 CVSup では、 このタグは . で表されます (句読点ではありません。. 文字そのものです)。 CVS ではこれがリビジョンタグが指定されなかった時のデフォルトです。 STABLE な計算機上に CURRENT のソースをチェクアウトしたりアップデートするのは、 思うところがあってやっているのというのでなければ、 よい考えとはいえません。 RELENG_4 FreeBSD-4.X の開発のための流れです。 FreeBSD-STABLE としても知られています。 RELENG_4_6 FreeBSD-4.6 用のリリースブランチです。 これはセキュリティ勧告や重要な修正が行なわれる場合にのみ使われます。 RELENG_4_5 FreeBSD-4.5 用のリリースブランチです。 これはセキュリティ勧告や重要な修正が行なわれる場合にのみ使われます。 RELENG_4_4 FreeBSD-4.4 用のリリースブランチです。 これはセキュリティ勧告や重要な修正が行なわれる場合にのみ使われます。 RELENG_4_3 FreeBSD-4.3 用のリリースブランチです。 これはセキュリティ勧告や重要な修正が行なわれる場合にのみ使われます。 RELENG_3 FreeBSD-3.X の開発のための流れです。 3.X-STABLE としても知られています。 RELENG_2_2 FreeBSD-2.2.X の開発のための流れです。2.2-STABLE としても知られています。このブランチは大部分が すたれています。 指定可能なこの他のリビジョンタグは以下のとおりです。 RELENG_4_6_0_RELEASE FreeBSD 4.6 です。 RELENG_4_5_0_RELEASE FreeBSD 4.5 です。 RELENG_4_4_0_RELEASE FreeBSD 4.4 です。 RELENG_4_3_0_RELEASE FreeBSD 4.3 です。 RELENG_4_2_0_RELEASE FreeBSD 4.2 です。 RELENG_4_1_1_RELEASE FreeBSD 4.1.1 です。 RELENG_4_1_0_RELEASE FreeBSD 4.1 です。 RELENG_4_0_0_RELEASE FreeBSD 4.0 です。 RELENG_3_5_0_RELEASE FreeBSD-3.5 です。 RELENG_3_4_0_RELEASE FreeBSD-3.4 です。 RELENG_3_3_0_RELEASE FreeBSD-3.3 です。 RELENG_3_2_0_RELEASE FreeBSD-3.2 です。 RELENG_3_1_0_RELEASE FreeBSD-3.1 です。 RELENG_3_0_0_RELEASE FreeBSD-3.0 です。 RELENG_2_2_8_RELEASE FreeBSD-2.2.8 です。 RELENG_2_2_7_RELEASE FreeBSD-2.2.7 です。 RELENG_2_2_6_RELEASE FreeBSD-2.2.6 です。 RELENG_2_2_5_RELEASE FreeBSD-2.2.5 です。 RELENG_2_2_2_RELEASE FreeBSD-2.2.2 です。 RELENG_2_2_1_RELEASE FreeBSD-2.2.1 です。 RELENG_2_2_0_RELEASE FreeBSD-2.2.0 です。 AFS サイト FreeBSD の AFS サーバは以下のサイトで稼働しています: スウェーデン ファイルは以下の場所にあります: /afs/stacken.kth.se/ftp/pub/FreeBSD/ stacken.kth.se # Stacken Computer Club, KTH, Sweden 130.237.234.43 #hot.stacken.kth.se 130.237.237.230 #fishburger.stacken.kth.se 130.237.234.3 #milko.stacken.kth.se (保守担当 ftp@stacken.kth.se) 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 507d34457e..15ae1782fb 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-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 のマニュアルページを参照してください. diff --git a/ja_JP.eucJP/books/handbook/security/chapter.sgml b/ja_JP.eucJP/books/handbook/security/chapter.sgml index 522cd7209d..54815a44cd 100644 --- a/ja_JP.eucJP/books/handbook/security/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/security/chapter.sgml @@ -1,3204 +1,3204 @@ セキュリティ この章の多くの部分は&a.dillon;によって書かれた &man.security.7; マニュアルページからの引用です. 訳: &a.jp.hino;, (jpman プロジェクトの成果を利用させ ていただきました). この章では この章では, 基本的なシステムセキュリティの考え方, 覚えておくべき一般的なルールを紹介し, そして S/Key, OpenSSL, Kerberos などの高度な話題について簡単に説明します. はじめに セキュリティとは, システム管理者をいつも悩ませる仕事の一つです. すべての BSD UNIX マルチユーザシステムは, 従来からいくつかのセキュリティ機構を備えていますが, ユーザを疑心暗鬼に陥らせないように追加のセキュリティ機構を構築し 保守する仕事はおそらく, システム管理者としてもっとも大きな責務の一つでしょう. マシンの安全性に反映されるのは, 管理者が作業したことだけです. またセキュリティ問題は, 快適な環境に必要なものと競合します. 一般に UNIX システムは膨大な数のプロセスを同時に動作させることができ, そのプロセスの大部分は, サーバ – 外部から接続し, 通信するものとして動作します. かつてのミニコンとメインフレームがデスクトップにとってかわり, さらにコンピュータが相互に接続されたネットワークを形成するようになった今日, セキュリティは非常に大きな関心事になってきています. セキュリティを実装するには, タマネギのように階層化する手法 (a layered onion approach) が最適です. どうすれば良いのか簡単に説明すると, 便利な機能と同じ数だけセキュリティの階層を作り, システムへの侵入を注意深く監視するのです. あなたはセキュリティを過度に厳重にしたり, 侵入の監視に時間をとられたいとは思わないでしょう. この侵入の発見という部分は, あらゆるセキュリティ機構において最も重要な部分の一つなのです. たとえば, システムの各バイナリに schg フラグ を設定するのは, 大して意味がありません. フラグを設定すると一時的にバイナリが保護され, 侵入してきたクラッカーによってシステムに加えられる変更のうち, 容易に検出可能な変更は行なえなくなります. しかしその結果として, セキュリティ機構がその侵入者を検出することも まったくできなくなってしまうでしょう. また, システムセキュリティには, さまざまな形での攻撃に対処することとも関係しています. この攻撃には root 権限を奪おうとするものだけでなく, クラッシュやシステムの不安定状態を引き起こそうとするものを含まれます. このセキュリティ問題は, いくつかに分類することが可能です. サービス妨害攻撃 (denial of service attack) ユーザアカウントの不正利用 (user account compromise) アクセス可能なサーバを使った root 権限の不正利用 ユーザアカウントを経由した root 権限の不正使用 バックドアの設置 サービス妨害攻撃 (DoS 攻撃) とは, マシンから必要な資源を奪う行為です. 通常, サービス妨害攻撃はそのマシンで実行されるサーバや ネットワークスタックを過負荷状態にしてマシンをクラッシュさせたり, マシンを使えなくしたりするような力任せの方法です. サービス妨害攻撃の中には, ネットワークスタックのバグを利用して, パケット一つでマシンをクラッシュさせようとするものもあります. 後者には, カーネルにバグ修正を施すことによってのみ対応することができます. サーバプロセスに対する攻撃は, オプションを適切に指定することによって, 攻撃されている状況でサーバプロセスの負荷上昇に限界を設定することで 対応できる場合が多いです. これらに比べると, ネットワークへの力任せの攻撃への対応はずっと難しくなります. たとえば, 偽造パケットによる攻撃 (spoof-packet attack) は, インターネットからシステムを切り離す以外の方法で 防ぐことはほとんど不可能です. この攻撃によって, マシンを落としてしまうことはできないかもしれませんが, 接続しているインターネット回線を混雑させていっぱいにしてしまうことはできます. ユーザアカウントの不正利用は, サービス妨害攻撃 よりもずっとよくある問題です. このご時勢でも, 自分たちのマシンで 標準の telnetd, rlogind, rshd, ftpd サーバを実行させているシステ ム管理者は多いのです. これらのサーバは, デフォルトでは, 暗号化さ れたコネクション上で動作していません. その結果, 抱えているユーザ 数が標準くらいであれば, リモートログイン (そのシステムにログイン するには最も普通で便利な方法です) しているユーザのうち一人以上は, パスワードを覗き見られてしまうでしょう. システム管理者が注意深い 人ならば, たとえログインが成功していたとしても, リモートアクセス ログを解析して, 疑わしい送信元アドレスを探すものです. ひとたび攻撃者がユーザアカウントへのアクセス権を入手すると, 攻撃者が root の権限を破る可能性があることを仮定するべきです. し かし, セキュリティを十分維持し, 手入れの行き届いたシステムにおい ては, あるユーザアカウントへのアクセスが可能となっても, 攻撃者に 必ずしも root へのアクセス権を与えるとは限りません. こ の違いは重要です. というのは, 一般的に root へのアクセス権がなければ, 攻撃者は自分の侵入の痕跡を隠蔽することができませんし, そ のユーザのファイルを引っかき回したり, マシンをクラッシュさせたり できるのがせいぜいです. ユーザアカウントの不正利用は めずらしいことではありません. それは一般ユーザに, システム管 理者ほど注意を払わない傾向があるからです. システム管理者は「あるマシン上で root の権限を破る方法は, 潜 在的に何通りもあるのだ」ということを心しておかねばなりません. 攻撃 者が root のパスワードを知ってしまうかもしれませんし, 攻撃者が root の権限で実行されるサーバのバグを見つけ, ネットワークからそ のサーバへ接続して root の権限を破ることができるかもしれません. ひとたびユーザアカウントを破ると, ユーザアカウントから root の権 限を破ることを可能にするような suid-root プログラムに存在するバグを 攻撃者は知っているかもしれません. あるマシン上で攻撃者 が root の権限を破る方法を知ったとすると, 攻撃者は, 裏口を作る必 要はありません. これまでに発見され, ふさがれた root の 穴の多くには, クラッカーが侵入した跡を消そうとしてたくさん仕事し た結果が含まれています. そのためにこそ, 多くのクラッカーは裏口を 作るのです. 攻撃者は裏口を使ってシステムへの root アクセスを再び 簡単に得ることができます. しかしこの裏口は, クラッカーの検出をす るのに便利なものでもあります. クラッカーに裏口を作らせないように するということは, セキュリティにとっては実際には良くないことかも しれません. なぜなら, そうすることで, クラッカーが最初に侵入して くるために発見したセキュリティホールがふさがるわけではないからで す. セキュリティを改善する方法は, 常に, タマネギの皮 のように階層化する手法 (a multi-layered onion peel approach) で実装されるべきです. これら は次のように分類できます. root とスタッフのアカウントの安全性を高める. root の安全性を高める – root 権限で動作するサーバ と suid/sgid バイナリ. ユーザアカウントの安全性を高める. パスワードファイルの安全性を高める. カーネルのコア, raw デバイス, ファイルシステムの安全性を 高める. システムに対して行なわれた, 不適切な変更をすばやく検出す る. 必要と思われる以上の対応をとる (paranoia). 本章の次の節では, 上記の各項目についてより深く掘り下げていき ます. FreeBSDの安全性を高める 以下の節では, 本章の前節 でとりあげた FreeBSD システムの安全性を高める方法について 述べます. root アカウントとスタッフアカウントの安全性を高める root のアカウントの安全性を確保しないうちからスタッフのア カウントの安全性をうんぬんしてもしかたがありません. ほとんどの システムでは, root アカウントに割り当てたパスワードが 1 つあり ます. まず最初にすべきことは, このパスワードはいつで も不正利用の危険に晒されていると仮定することです. これは root のパスワードを消すべきだと言っているのではありません. root のパスワードは, マシンにコンソールからアクセスするのには, ほとんどいつでも必要なものです. ここで言いたいのは, コンソール 以外からは, そして可能なら &man.su.1; コマンドを実行する場合も root のパスワードを使えないようにするべきである, ということで す. たとえば, あなたが使っている pty が, /etc/ttys ファイルで unsecure と指定 されているか確認してください. そうすると, telnet や rlogin 経由では root で直接ログインできないようになります. sshd のような, 別のログインサービス を使っている場合でも同様に, 直接 root へログインすることを許し ていないかどうか確認してください. すべてのアクセス手段 – たとえば ftp のようなサービスが, 良くクラックの対象となることを 考えましょう. root への直接ログインは, シス テムコンソール経由でのみ可能であるべきなのです. また当然, システム管理者として自分が root になれるようにしておく必要が ありますから, そのための穴をいくつか開けておきます. し かし, それらの穴を動作させるには, さらに追加のパスワード認証が 必要であるようにしておくことが重要です. root でアクセス可能と する方法の一つとして, 適切なスタッフアカウントを (/etc/group 中の) wheel グループに加えることがありま す. wheel グループに入っているスタッフメン バは su を使って root になることが許されま す. パスワードエントリにおいて, スタッフメンバを wheel グループに置くことによって直接 wheel 権限を与えてはいけません. スタッフメンバのアカウントは staff グループに所属させるべきで, そして /etc/group ファイルを通して wheel グループに加えるべきです. 実際に root アクセスの必要なスタッフメンバのみ wheel グ ループに置くようにすべきです. 他の認証方法の場合, たとえば kerberos を使用する場合には, root アカウントの .k5login ファイルを使って, 誰も wheel グループに置く必要なく &man.ksu.1; を 使って root になることを許すようにすることもできます. このやり 方はよりよい解決策なのかもしれません. なぜなら, wheel のメカニズムでは, 侵入者がパスワード ファイルを手に入れ, スタッフアカウントのいずれか 1 つを破るこ とができると, root を破ることがまだできてしまうからです. wheel のメカニズムを用いる方が, 何もしない よりは良いのですが, 必ずしも最も安全な選択肢とは限りません. root アカウントの安全性を高める間接的な方法として, 別のロ グインアクセスの方法を用いてスタッフのアカウントの安全性を高め, その上でそのスタッフのアカウントの暗号化パスワードを * にしておく方法があります. この方法だと, 侵入者がパスワードファイルを盗むことができた場合でも, スタッフ アカウントを破ることはできなくなります (また, たとえ root が暗 号化パスワードをパスワードファイルに付けていたとしても, 間接的 に root アカウントを破ることはできません). スタッフメン バがスタッフアカウントでログインする際には, &man.kerberos.1; や &man.ssh.1; のような, 公開鍵 / 秘密鍵の鍵の組を使う安全性の 高いログイン機構を使います. kerberos のようなログイン機構を使う 場合は一般に, kerberos サーバを実行するマシンと自分のデスクトッ プワークステーションとの安全性を確保しなければなりません. また ssh で公開鍵 / 秘密鍵の組を使う場合, 一般に, ログイン元マシン (通常は自分のワー クステーション) の安全性を確保しなければなりません. ここで, <&man.ssh-keygen.1; で公開鍵 / 秘密鍵の組を生成する際, 鍵の組 をパスワードで防御することにより, 鍵の組への防御層を追加するこ ともできます. スタッフアカウントのパスワードを * でつぶすことができると, 管理者自身が設定 した安全性の高い方法でしかスタッフメンバがログインできないこと も保証できます. こうして, 多くの侵入者が使う重大なセキュリティ の穴, すなわち, 安全性の低い無関係なマシンからネットワークを覗 き見る方法, を塞ぐようなセッションを提供する, 安全性の高い暗号 化されたコネクションを使うことを, スタッフメンバ全員に強制する ことができるのです. より間接的なセキュリティの仕組みでは, 制限の強いサーバから 制限の弱いサーバへログインすることを前提としています. たとえば, メインマシンで, 様々な種類のサーバを実行させている場合, ワーク ステーションではそれらのサーバを実行させてはなりません. ワーク ステーションを十分に安全にしておくためには, 実行するサーバの数 を, 一つもサーバが実行されていないというくらいにまでできる限り 減らすべきです. また, パスワードで保護されたスクリーンセーバを 走らせておくべきです. ワークステーションへの物理的アクセスが与 えられたとすると, もちろん言うまでもなく, 攻撃者は管理者が設定 したいかなる種類のセキュリティをもうち破ることができるのです. このことは, 管理者として必ず考えておかねばならない問題ですが, システム破りの大多数は, ネットワーク経由でリモートから, ワーク ステーションやサーバへの物理的アクセス手段を持たない人々によっ て行われるという事実もまた, 念頭に置いておく必要があります. kerberos のような方法を使うことで, スタッフアカウントのパ スワードの変更もしくは停止を一箇所で行なうことと, スタッフメン バがアカウントを持つすべてのマシンに即時にその効果を及ぼすこと が可能となります. スタッフメンバのアカウントが危険に晒されたと きに, すべてのマシンでスタッフメンバのパスワードを即座に変更す る能力を過小評価してはいけません. パスワードが分散されている状 況では, N 台のマシンでパスワードを変更すると, てんやわんやの事 態を招く可能性があります. kerberos を使用すると, パスワードの 再発行に制限 (re-passwording restriction) を課することもできま す. この機能を使うことにより, ある kerberos チケットをしばらく 経つとタイムアウトにすることができるだけでなく, 一定期間 ( 例 えば, 1 ヶ月に 1 回) 経つと, ユーザに新しいパスワードを選ぶよ うに要求することもできます. root 権限で実行されているサーバと SUID/SGID バイナリの安全性を高める 用心深いシステム管理者は, 自分に必要なサーバプロセスだけを 過不足なく実行させるものです. サードパーティ製のサーバは, よくバグを持っ ていがちだということに注意して下さい. たとえば, 古いバージョンの imapd や popper を実行させておくのは, 全世界に万能の root の切 符を与えているようなものです. 自分で注意深くチェックしていない サーバは, 決して実行してはいけません. root で実行させる必要の あるサーバはほとんどありません. たとえば, ntalk, comsat, finger デーモンを, 専用ユーザの 砂場 (sandbox) で実行させることができます. 管理者が膨大な数の問題に直面していないのなら, この「砂場」は完 璧ではありませんが, セキュリティに関するタマネギ的アプローチは ここでも成り立ちます. 砂場で実行されているサーバプロセスを経由 して侵入を果たすことができたとしても, 攻撃者はさらに砂場から外 に脱出しなければなりません. 攻撃者が通過せねばならない層の数が 増えれば増えるほど, それだけ攻撃者が侵入に成功する確率が減りま す. root の抜け穴は歴史的に, 基本システムサーバも含め, root 権 限で実行されるほとんどすべてのサーバプロセスで発見されています. ユーザが sshd 経由でのみログインし, telnetd, rshd, rlogind 経由でログインすることが決 してないマシンを稼働させているのであれば, それらのサービスを停 止させて下さい! FreeBSD では, 今では ntalkd, comsat, finger は砂場で実行させることがデフォ ルトになっています. 次に砂場で実行させるべきプログラムの候補と して, &man.named.8; があります. /etc/defaults/rc.conf ファイルには, named を砂場で実行するために必要な 引数がコメントアウトされた形式で含まれています. 新しいシステム をインストールしているか, それとも既存のシステムをアップグレー ドして使っているかに依存しますが, 砂場として使用する特別のユー ザアカウントがインストールされていないかもしれません. 用心深い システム管理者であれば, できるだけいつでも研究を怠らず, サーバ に砂場を仕込むものでしょう. 通常, 砂場で実行しないサーバが他にいくつかあります. sendmail, popper, imapd, ftpd などです. これらのうちいくつか のサーバには代わりとなるものがありますが, 代わりのものをインス トールするには, あなたが思うより多くの仕事が必要になるかもしれ ません (便利さという要素がまたも勝利を収めるわけです). これら のサーバは, root 権限で実行せねばならいかもしれません. また, これらのサーバ経由で生じる侵入を検出するためには, 他の仕組みに 頼らなくてはならないかもしれません. システムの root 権限の潜在的な穴で他に大きなものとして, シ ステムにインストールされた suid-root/sgid バイナリがあります. これらのバイナリは, rlogin のように, /bin, /sbin, /usr/bin, /usr/sbin に存在するものがほとんどです. 100% 安全なものは存在しないとは いえ, システムデフォルトの siud/sgid バイナリは比較的安全とい えます. それでもなお, root の穴がこれらのバイナリにときおり発 見されています. 1998 年に Xlib で見つかった root の穴は, xterm (普通, suid 設定 されています)を脆弱にしてしまいました. 安全である方がよいので, 用心深いシステム管理者は残念に思いながらも, スタッフのみが実行 する必要がある suid バイナリは, スタッフのみがアクセス可能な特 別なグループに含めるように制限を加え, 誰も使わない suid バイナ リは (chmod 000 を実行して) 片付けてしまう でしょう. ディスプレイを持たないサーバは, 一般的に xterm のバイナリを必要としません. sgid バイナリもほとんど同様の危険な存在になり得ます. 侵入者が kmem に sgid されたバイナリを破ることができた場合, その侵入者 は /dev/kmem を読み出すことができるように なるでしょう. つまり, 暗号化されたパスワードファイルを読み出す ことができるようになるので, パスワードを持つどのアカウントをも, 潜在的な危険に晒すことになります. 他にも, kmem グループを破った侵入者が pty を通して 送られたキーストロークを監視できるという危険があります. キース トロークには, 安全な方法でログインするユーザが使っている pty も含まれます. tty グループを破った侵入者は, ほぼ任意のユーザの tty へ書き込みができます. ユーザが端末プログラムやキーボードを シミュレーションする機能を持ったエミュレータを使っている場合, 侵入者は潜在的に, 結局そのユーザとして実行されるコマンドをユー ザの端末にエコーさせるデータストリームを生成できる可能性があり ます. ユーザアカウントの安全性を高める ユーザアカウントは, 普通, 安全性を高めることが最も困難です. スタッフに対しては, とても厳格なアクセス制限を強制しパスワード を * で外すことができるでしょうが, 管理者が 持ちうる一般ユーザすべてのアカウントに対して同じことはできない かもしれません. 管理者が十分に統率をとることができるなら, 管理 者は勝利し, ユーザのアカウントの安全を適切に確保できるかもしれ ません. それができないならば, よりいっそう気を配って一般ユーザ のアカウントを監視するよりほかありません. 一般ユーザアカウント に対し ssh や kerberos を利用するこ とには, システム管理がさらに増えたりテクニカルサポートが必要に なるなどの問題があります. それでも, 暗号化パスワードファイルと 比較するとはるかに良い解です. パスワードファイルの安全性を高める できるだけ多くのパスワードを * で外し, それらのアカウントのアクセスには ssh や kerberos を使うようにするこ とが, 唯一の確実な方法です. 暗号化パスワードファイル (/etc/spwd.db) は root でのみ読み出し可能 だといっても, 侵入者が root の書き込み権限は得られなくとも, 読 み出しアクセス権限を得ることは可能かもしれません. セキュリティスクリプトで常にパスワードファイルの変更をチェッ クし, 報告するようにすべきです (ファイルの完全性のチェック 参照). カーネルのコア, raw デバイス, ファイルシステムの安全性を 高める root の権限を破ると, 攻撃者は何でもできますが, 特に重宝さ れる特定の事柄もいくつかあります. たとえば, 最近のカーネルは, 組 み込みのパケット覗き見デバイス (packet sniffing device) ドライ バを備えているものがほとんどです. FreeBSD では bpf デバイスと呼ばれています. 侵入者 は普通, 侵入済みのマシンでパケット覗き見プログラムを実行させよ うと試みます. 侵入者にわざわざそういう機能を提供する必要はない ので, ほとんどのシステムで bpf デバイスを組み込むべきではあり ません. bpf デバイスを外しても, /dev/mem と /dev/kmem という悩みの種がまだ残っていま す. この問題に関しては, 侵入者は raw ディスクデバイスに書き込 むこともできます. また, モジュールローダ, &man.kldload.8; とい う, 別のカーネル機能があります. やる気まんまんの侵入者は, KLD モジュールを使って自分独自の bpf もしくはその他覗き見デバイス を動作中のカーネルにインストールすることができます. この問題を 避けるため, システム管理者はカーネルをより高い安全レベル ( securelevel) , 少なくとも安全レベル 1 で実行させる必要がありま す. sysctl を使って kern.securelevel 変数に安全レベルを設定する ことができます. ひとたび安全レベルに 1 を設定すると, raw デバ イスに対する書き込みアクセスは拒否され, たとえば schg のような特別な chflags フラグの機能が 強制されます. システム起動に関わる重要なバイナリやディレクトリ, スクリプトファイルなど, 安全レベルが設定されるまでの間に実行さ れるすべてのものに対しても schg フラグを on にしておくことも確実に実行してください. この設定をやり過ぎても 構いませんが, より高い安全レベルで動作している場合, システムの アップグレードがはるかに困難になります. システムをより高い安全 レベルで実行させるようにするが, すべてのシステムファイルとディ レクトリに schg フラグを設定しないという妥 協をする方法もあります. もう一つの可能性としては, 単純に / および /usr を読み 込み専用でマウントすることです. ここで特筆すべきことは, システ ムを守ろうとして厳しくしすぎると, 侵入を検出するという非常に重 要なことができなくなってしまうということです. ファイルの完全性のチェック: バイナリ, 設定ファイルなど ことこの問題に至ると, システム管理者にできることは, 便利さ という要素がその醜い頭を上げない程度に, コアシステムの設定と制 御ファイルを防御することだけです. たとえば, / および /usr にある 大部分のファイルに schg ビットを設定するた めに chflags を使用するのは, おそらく逆効果 でしょう. なぜなら, そうすることでファイルは保護できますが, 侵 入を検出する窓を閉ざしてしまうことにもなるからです. セキュリティ のタマネギの最後の層はおそらく最も重要なもの – 検出で す. セキュリティの残りのものは, 突然の侵入を検出できなければ, まったく有用ではありません (あるいは, もっと悪ければ, 安全性に 対する間違った感覚を植え付けてしまいます). タマネギの仕事の半 分は, もう半分の検出側が攻撃者を攻撃の最中に捕えるようにするた めに, 攻撃者を食い止めるのではなく侵入を遅らせることなのです. 侵入を検出する最も良い方法は, 変更されていたり, 消えていた り, 入れた覚えがないのに入っているファイルを探すことです. 変更 されたファイルを探すのに最も良い方法は, もう一つの (しばしば中 央に集められた), アクセスが制限されたシステムから行なうもので す. さらに安全でアクセス制限されたシステム上でセキュリティ用ス クリプトを書けば, スクリプトは潜在的なクラッカー達からはほぼ見 えなくなります. これは重要なことです. この有効性を最大限に活用 するためには, 一般的に, アクセスの制限されたマシンから実際に使っ ている他のマシンへのかなりのアクセスを許す必要があります. 普 通は, 他のマシンからアクセス制限されたマシンへ読み込み専用の NFS エクスポートをしたり, アクセス制限されたマシンから他のマシ ンへ ssh を行なうために, ssh 鍵のペアを作ったりすることで行 います. ネットワークのトラフィックを別にして, NFS は最も可視性 のない方法です – 各クライアント上のファイルシステムを, 事実上検出されずに監視できるようになります. アクセス制限された サーバがスイッチを通してクライアントに接続されている場合, たい てい NFS がより良い選択肢です. アクセス制限されたサーバがハブ を通したり, いくつかのルーティング層を通したりしてクライアント に接続する場合, NFS はあまりにも危険な方法かもしれず (ネットワー クの面で) , ssh の方が認証の道筋は 跡となって残りますが, それでもより良い方法かもしれません. アクセス制限されたマシンに, 監視しようとするクライアントシ ステムへの少なくとも読み込みのアクセス権を与えたら, 次に実際に 監視するためのスクリプトを書かなくてはいけません. NFS マウント をすれば, &man.find.1; や &man.md5.1; などの単純なシステムユー ティリティでスクリプトを書くことができます. 少なくとも 1 日 1 回, クライアントのファイルを直接 md5 にかけ, さらにもっと頻繁 に /etc および /usr/local/etc にあるようなコントロール用 ファイルを試験するのが一番です. アクセス制限されたマシンが正し いと知っている, 基となる md5 情報と比べて違いが見つかった場合, システム管理者に調べて欲しいと悲鳴を上げるようにすべきです. 優 れたセキュリティ用スクリプトは, / および /usr などのシステムパーティション上で不適 当に suid されたバイナリや, 新たに作成されたファイルや削除され たファイルもチェックするでしょう. NFS ではなく, ssh を使用する場 合は, セキュリティ用スクリプトを書くのはずっと難しいことで す. スクリプトを動かすためには, クライアントに対してスクリプト を scp しなくてはいけませんし, それは目に見 えてしまいます. そして, 安全のためには, スクリプトが使うバイナ リ (find など) を scp する必要もあります. クライアントの ssh デーモンはすでに 攻撃されてしまっているかもしれません. 結局のところ, 安全でない リンク上の場合は ssh は必要かもしれ ませんが, ssh を扱うのはとても大変 なことです. 優れたセキュリティ用スクリプトは, ユーザやスタッフメンバの アクセス設定ファイルの変更もチェックするものです. .rhosts, .shosts, .ssh/authorized_keys など … MD5 チェックの範囲外になってしまうであろう ファイル群です. ユーザ用のディスク容量が非常に大きい場合は, パーティション 上の各ファイルを見て回るのに大変な時間がかかるかもしれません. この場合は, マウントフラグを設定して, このパーティションに suid されたバイナリやデバイスを置けないようにするのが良い考え です.nodev および nosuid オプション (&man.mount.8; 参照) が知るべきものでしょう. とにかく少なくとも週に 1 度はファイルシステムをスキャンするべきです. なぜなら, この層の目的は, 侵入が成功したかどうかに関わらず, 侵 入があったことの検出をすることだからです. プロセスアカウンティング (&man.accton.8; 参照) は, マシンへの侵入を検出するためのメカニズムとして推奨できる, 比較的オーバヘッドの少ないオペレーティングシステムの機能です. 侵入を受けた後でも当該ファイルが無傷である場合に, 侵入者が 実際にどのようにしてシステムに侵入したかを追跡するのに特に役立ちます. 最後に, セキュリティスクリプトはログファイルを処理するよう にし, ログファイル自体もできるだけ安全性の高い方法で生成するよ うにすべきです – リモート syslog は極めて有益になり得ま す. 侵入者は自分の侵入の痕跡を覆い隠そうとしますし, また, ログ ファイルはシステム管理者が最初の侵入の時刻と方法を追跡してゆく ために極めて重要です. ログファイルを永久に残しておくための 1 つの方法は, システムコンソールをシリアルポートにつないで走らせ, コンソールを監視している安全なマシンを通して絶えず情報を集める ことです. 偏執狂的方法 多少偏執狂的になっても決して悪いことにはなりません. 原則的 に, システム管理者は, 便利さに影響を与えない範囲でいくつでもセ キュリティ機能を追加することができます. また, いくらか考慮した 結果, 便利さに影響を与えるセキュリティ機能を追加することもでき ます. もっと重要なことには, セキュリティ管理者とは少し喧嘩にな るはずなのですが – もしあなたが, 本文書に書かれている勧 告をそのまま使用した場合は, 予想されるクラッカーはやはり本文書 を読んでいるわけですから, あなたの防御策を教えてしまうことにな ります. サービス妨害攻撃 このセクションではサービス妨害攻撃 (DOS 攻撃) を扱います. サービス妨害攻撃は, 普通は, パケット攻撃です. ネットワークを飽 和させる最先端の偽造パケット (spoofed packet) 攻撃に対してシス テム管理者が打てる手はそれほど多くありませんが, 一般的に, その 種の攻撃によってサーバがダウンしないことを確実にすることで, 被 害をある限度に食い止めることはできます. サーバの fork の制限. 踏み台攻撃の制限 (ICMP 応答攻撃, ping broadcast など). カーネルの経路情報のキャッシュ. よくあるサービス妨害攻撃は, fork するサーバプロセスに対す るものです. これは, サーバにプロセス, ファイル記述子, メモリを マシンが死ぬまで食い尽くさせようとするものです. inetd (&man.inetd.8; 参照) には, この種の攻撃を制限するオプションが いくつかあります. マシンがダウンすることを防止することは可能で すが, この種の攻撃によりサービスが中断することを防止することは 一般的に言ってできないことに注意する必要があります. inetd のマ ニュアルページを注意深く読んで下さい. 特に, , , オプションに注意して下さい. IP 偽造攻撃 (spoofed-IP attack) は inetd の オプションの裏をかけるので, 一般 にオプションを組み合わせて使用するべきであることに注意して下さ い. スタンドアロンサーバの中には, 自分自身で fork を制限するパ ラメータを持っているものがあります. Sendmail には, オプションがあります. シ ステム負荷の値変化には遅れがあるので, sendmail の負荷限界指定 オプションを使うよりも, このオプションを使う方がまともに動作す る可能性ははるかに高いです. sendmail の実行を開始する際に, MaxDaemonChildren パラメータを設定するべき です. その値は, 通常見込まれる負荷を扱える程度に十分高いが, そ れだけの数の sendmail を操作しよう とするとマシンが卒倒してしまうほどには高くないような値に設定す るべきです. sendmail をキュー処理モード () で実行することや, sendmail デーモン (sendmail -bd) をキュー処 理用プロセス (sendmail -q15m) と別に実行す ることも, 用心深いことと言えます. それでもなおリアルタイムでの 配送を望むのであれば, のようにすることで, キュー処理をはるかに短い時間間隔で行うことができます. いずれに しても, MaxDaemonChildren オプションに合理 的な値を確実に指定して, sendmail がなだれをうって失敗すること がないようにして下さい. syslogd は直接攻撃される可能性 があるので, 可能ならばいつでも オプション を用いることを強く推奨します. これができないなら, オプションを使って下さい. tcpwrapper の逆 identd などの接 続返し (connect-back) を行うサービスについては十分注意を払うよ うにするべきです. これらは直接攻撃を受ける可能性があります. こ ういう事情があるので, tcpwrapper の 逆 ident 機能を使おうとは思わないのが一般的です. 境界ルータのところでファイアウォールを設けて, 外部からのア クセスに対して内部サービスを防御するという考えは実によいもので す. この考えは, LAN の外部からの飽和攻撃を防ぐことにあり, 内部 サービスをネットワークベースの root 権限への攻撃から防御するこ とにはあまり考慮を払っていません. ファイアウォールは常に排他的 に設定して下さい. つまり, ポート A, B, C, D と M から Z まで以外 のすべてに防火壁を設ける というふうにです. このようにすることで, named (ゾーンのプライマリである場合), ntalkd, sendmail などのインターネットからア クセスできるサービスとして特に指定するもの以外の, 小さい番号の ポートすべてをファイアウォールで防御することができます. ファイ アウォールをこの他のやり方 – つまり包含的もしくは受容的 なファイアウォールとして設定しようとする場合, close することを忘れてしまうサービスがいくつか 出てきたり, 新しい内部サービスを追加したのにファイアウォールの 更新を忘れたりする可能性がよく出てきます. ファイアウォール上の 大きい番号のポートを開けておくことにより, 小さい番号のポートを 危険に晒すことなく受容的な動作を許すことができます. FreeBSD で は, net.inet.ip.portrange への sysctl (sysctl -a | fgrep portrange) をいろいろ使用することで, 動的バインドに使用される ポート番号の範囲を制御できることを記憶にとどめておいてください. これによりファイアウォールの設定を簡略化することもできます. たとえば, 通常の first/last 範囲として 4000 から 5000 を, 高位ポートの範囲として, 49152 から 65535 を指定し, (いくつかのインターネットアクセス可能 なポートをブロックから除外するのはもちろんですが) 4000 より下 のすべてをブロックするという設定が考えられるでしょう. また別のよくあるサービス妨害攻撃として, 踏み台攻撃 (springboard attack) と呼ばれるものがあります – これは, あるサーバを攻撃し, そこ結果として生成される応答が自分自身, ロー カルネットワーク, そして他のマシンを過負荷に追い込むようにする 攻撃です. この種の攻撃の中で最もありふれたものに, ICMP ping broadcast 攻撃があります. 攻撃 者は, 実際に攻撃したいマシンのアドレスを送信元アドレスに設定し た ping パケットを偽造して, 対象の LAN のブロードキャストアド レスに向けてパケットを送信します. 境界にあるルータがブロードキャ ストアドレスに対する ping パケットを握り潰すように設定されてい ない場合, LAN は, 詐称された送信元アドレスに向けて応答パケット を生成するはめになり, 犠牲となるマシンが飽和するところまで行っ てしまいます. 攻撃者が同じトリックを異なるネットワーク上のいく つものブロードキャストアドレスに対して同時に使用した場合, とく にひどいことになります. これまでに, 120 メガビット以上のブロー ドキャスト攻撃が観測されています. 2 番目の踏み台攻撃は, ICMP エラー報告の仕掛けを狙うものです. 攻撃者は ICMP エラー応答を生 成するパケットを生成し, サーバの受信ネットワークを飽和させ, そ の結果としてサーバが送信ネットワークを ICMP 応答で飽和させてし まうようにすることができます. mbuf を消費し尽くさせることによ り, この種の攻撃でサーバをクラッシュさせることも可能です. サー バが生成した ICMP 応答を十分速く送信できない場合, とくにひどい ことになります. FreeBSD カーネルには, この種の攻撃の効果を抑制 する ICMP_BANDLIM と呼ばれる新しいカーネルコンパイルオプション があります. 踏み台攻撃の 3 つめの主要なクラスに属する攻撃は, udp echo サービスのような, 特定の inetd 内部サービスに関連する ものです. 攻撃者は, 単に送信元アドレスがサーバ A の echo ポー トであり, 送信先アドレスがサーバ B の echo ポートであるように UDP パケットを偽造します. ここでサーバ A, B はともにあなたの LAN に接続されています. この 2 つのサーバは, この一つのパケッ トを両者の間で互いに相手に対して打ち返しあいます. このようにし てパケットをほんのいくつか注入するだけで, 攻撃者は両方のサーバ と LAN を過負荷状態にすることができます. 同様の問題が内部 chargen ポートにも存在します. 有能なシステム管理者はこの手の inetd 内部テストサービスのすべてを無効にしておくものです. 偽造パケット攻撃は, カーネルの経路情報キャッシュに過負荷を 生じさせるために用いられることもあります. net.inet.ip.rtexpire, rtminexpire, rtmaxcache の sysctl パラメータを参照して下さい. でた らめな送信元 IP アドレスを用いた偽造パケット攻撃により, カーネ ルは, 一時的なキャッシュ経路を経路情報テーブルに生成します. こ れは netstat -rna | fgrep W3 で見ることがで きます. これらの経路は, 普通は 1600 秒程度でタイムアウトになり ます. カーネルがキャッシュ経路テーブルが大きくなり過ぎたことを 検知すると, カーネルは動的に rtexpire を減らしますが, rtminexpire より小さくなるようには決して減らしません. ここに問 題が 2 つあります: 負荷の軽いサーバが突然攻撃された場合, カーネルが十分素 早く反応できないこと. カーネルが持続的攻撃に耐えられるほど十分 rtminexpire が低く設定されていないこと. 自分のサーバが T3 もしくはそれより高速の回線でインターネッ トに接続されている場合, &man.sysctl.8; を用いて rtexpire と rtminexpire とを手動で上書きしておくことが思慮深いことといえます. どちらか 一方でも 0 には決してしないで下さい (自分のマシンをクラッシュ させたくないのであれば :-). 両パラメータを 2 秒 に設定すれば, 攻撃から経路情報テーブルを守るには十分でしょう. Kerberos および SSH を用いたアクセスの問題 もしあなたが, kerberos および ssh を使用したいのだとしたら, 両者 に関して言っておく必要のある問題がいくつかあります. kerberos V は大変優れた認証プロトコルですが, kerberos 化された telnet や rlogin は, バイナリストリームを扱う のに不向きになってしまうようなバグがあります. さらに, デフォル トでは, kerberos は オプションを使わない限 りセッションを暗号化してくれません. ssh では, デフォルトですべてを暗号 化してくれます. ssh はあらゆる場面でとても良く 働いてくれます. ただし, デフォルトで暗号鍵を転送してしまうこと を除けばです. これはつまり, 暗号鍵を持った安全なワークステーショ ンがあって, この暗号鍵で残りのシステムとアクセスできるようになっ ている場合に, 安全でないマシンへ ssh を行なう時に暗号鍵が見えてしま うということです. 実際の鍵そのものが見えてしまうわけではありま せんが, ssh は, あなたが login して いる間, 転送用ポートを作ります. クラッカーが安全でないマシンの root を破ると, クラッカーは, このポートを使って暗号鍵を取得し, この暗号鍵でロックの外れる他のマシンへのアクセスを得ます. スタッフのログインには, kerberos を組み合せた ssh を使用することを勧めます. ssh は, kerberos サポート機能と一緒 にコンパイルできます. こうすると, 見えてしまうかもしれない ssh 鍵をあまりあてにしないで良いよ うになります. また, それと同時に, kerberos 経由でパスワードを 保護することもできます. ssh 鍵は, 安全なマシンからの自動化されたタスク (kerberos はこの用途には 不向きです) のみに使用するべきです. また, ssh の設定で鍵転送をしないようにす るか, あるいは, ssh が authorized_keys ファイル中に書くことを許 している from=IP/DOMAIN オプションを使用し て, 特定のマシンからログインしてきたときのみ鍵が有効であるよう にすることも勧めます. DES, MD5, と Crypt 改訂: &a.unfurl;, 21 March　 2000. 訳: &a.hanai;, 12 September 1996. 訳改訂: &a.jp.hino;, 12 March 2001. UNIX システムにおけるすべてのユーザは, そのアカウントに対応し た一つのパスワードを持っています. それらのパスワードはユーザ本人 と本当のオペレーティングシステムのみが知っているべきであるという ことは明らかでしょう. それらのパスワードを秘密に保っておくために, パスワードは一方向ハッシュとして知られる方式で暗 号化されます. 一方向ハッシュとは, 簡単に暗号化はできるが解読は難 しいという方法です. 言葉を換えると, 先ほど明らかであると書いたの は実は正しくないのです: オペレーティングシステム自身は 本当はパスワードを知らないのです. その代わりに 暗号化された形でのみパスワードを知っていま す.素のテキストとしてパスワードを得る唯一の方法は, 可能な限りのパスワード空間を検索するという力任せの方法です. 不幸なことに, UNIX が生まれようとしているときにパスワードを 安全な形で暗号化できる方式は DES(Data Encryption Standard) に基 づいたものだけでした. このことは米国に住んでいるユーザにとって は大して問題ではありませんでしたが, DES のソースコードを米国外に 輸出することはできないという問題がありました. そのために, FreeBSD は, 米国の法律を守ることと, 未だに DES を使っている他の UNIX 一族との互換性を保つこととを両立する方法を探し出す必要があ りました. その解決方法は, 米国のユーザは DES のライブラリをインストー ルして DES を使用できるが, 米国外のユーザは国外に輸出可能な他の ひとつの暗号化方式を使用することができる, というように暗号化ライ ブラリを分割することでした. これが FreeBSD がデフォルトの暗号化 方式として MD5 を使うようになったいきさつです. MD5 は DES よりも より安全であると考えられているため, DES をインストールする一番の 理由は互換性を保つためといえます. 暗号化機構を理解する FreeBSD がどの暗号化方式を使うようにセットアップされている かを判断するのは簡単です. /etc/master.passwd ファイルの中の暗号化さ れたパスワードを調べてみるのが一つの方法です. MD5 ハッシュで暗 号化されたパスワードは, DES ハッシュで暗号化されたパスワードよ りも長いですし, その上 $1$ と いう文字で始まるという特徴も持っています. DES のパスワードはこ れといって識別可能な特徴は持っていませんが, MD5 のパスワードよ りは短く, そして $ という文字を含ま ない 64 文字のアルファベットを使って表現されているので, 比較的 短い文字列でドル記号で始まっていないものはおそらく DES のパス ワードでしょう. 同様の方法で, ライブラリはパスワードを識別します. 結果とし て, DES のライブラリは MD5 パスワードを識別でき, そして MD5 を 使って MD5 で暗号化されたパスワードをチェックし, その他のパス ワードには DES を使ってチェックします. DES のライブラリは MD5 も含んでいるのでこのようなことが可能なのです. 残念なことに, 反 対は真ではありません. MD5 のライブラリは DES で暗号化されたパ スワードを認証することができません. あなたのシステムでプログラムがどちらのライブラリを使ってい るかを調べるのは非常に簡単です. crypt を使うプログラムは libcrypt をリンクしています. そしてそれぞれのライブラリに対す る適切な実装へのシンボリックリンクとなってい ます. たとえば, DES 版を使っているようなシステムにおいては次のようになっています: &prompt.user; ls -l /usr/lib/libcrypt* lrwxr-xr-x 1 root wheel 13 Mar 19 06:56 libcrypt.a -> libdescrypt.a lrwxr-xr-x 1 root wheel 18 Mar 19 06:56 libcrypt.so.2.0 -> libdescrypt.so.2.0 lrwxr-xr-x 1 root wheel 15 Mar 19 06:56 libcrypt_p.a -> libdescrypt_p.a MD5 に基づいたライブラリを使っているシステムにおいては, 同 じようなリンクが 見られるでしょうが, そのターゲットは libdescrypt ではなく libscrypt になっているでしょう. もし DES 機能を持った crypt ライブラリ libdescrypt をインストールしたのなら (つ まり "crypt" ディストリビューションをインストールした場合), 新 規パスワードがどちらのパスワード形式になるかは, /etc/login.conf の中の passwd_format ログインケーパビリティによって制 御されます. その値としては, des または md5 を設定することができます. ログインケーパビ リティに関するより詳細な情報は, &man.login.conf.5; マニュアルページ をご覧ください. S/Key S/Key は一方向ハッシュ関数を基にしたワンタイムパスワード方式 です. FreeBSD では, 互換性のために MD4 ハッシュを用いていますが 他のシステムでは MD5 や DES-MAC を用いてます. S/Key は, バージョ ン1.1.5 以降のすべての FreeBSD に含まれていますし, FreeBSD 以外 の数多くのシステムの上でも利用されています. S/Key ば Bell Communications Research, Inc. の登録商標です. 以下の説明では, 三種類の異なる「パスワード」が使われます. まず一つ目は, あなたが普段使っている普通の UNIX スタイルの, もし くは Kerberos でのパスワードです. ここではこれを UNIX パ スワードと呼ぶことにし ます. 二つ目は, S/Key の key プログラムによって生成され, keyinit プログラムとログインプロンプトが受け 付けるパスワードです. ここではこれをワンタイムパスワード と呼ぶことにします. 三つ目のパスワードは, key (と場合により keyinit) プログラムに対してユーザが入力する秘密のパスワードで, ワンタイム パスワードを生成するのに使われます. ここではこれを秘密の パスフレーズもしくは単に “パスフレーズ” と呼 ぶことにします. (訳注: ユーザが頭の中だけにしまっておくべきもの が, この秘密のパスフレーズです. なお, 原文ではこれをパスワードと 表記していますが, 混乱を避けるために訳文ではすべて 秘密の パスフレーズに統一しています.) 秘密のパスフレーズは, UNIX パスワードと何の関連性もありませ ん: 両者を同一に設定することは可能ですが, お奨めしません. UNIX パスワードは長さが 8 文字に制限されています (訳注: FreeBSD で DES を導入していない場合はもっと長いパスワードも認識されます). これに対し, S/Key では秘密のパスフレーズを好きなだけ長くすること ができます (訳注: 実装上, key コマンドなどの バッファ長で制限されてしまう可能性があります. 200 文字程度に押 えておいた方がよいでしょう :-). 6 語から 7 語からなるパスフレー ズがふつうです. ほとんどの部分で, S/Key システムは UNIX のパスワー ドシステムと完全に独立して動作するようになっています. パスフレーズに加え, S/Key システムにとって重要な二種類のデー タがあります. 一つはシード (seed: 種)または キー (key: 鍵)と呼ばれるもので, 二つの文字と五つ の数字で構成されます. もう一つはシーケンス番号 (iteration count) で, 1 から 100 までの整数です. S/Key はここまで に述べたデータを利用してワンタイムパスワードを生成します. その方 法は, まずシードと秘密のパスフレーズを連結し, それに対してシーケ ンス番号の回数だけ MD4 ハッシュを繰り返し計算します. そしてその 結果を 六つの短い英単語に変換します. login プ ログラムと su プログラムは, 前回最後に受け付 けられたワンタイムパスワードを記録しています. そして, その前回 のワンタイムパスワードと, ユーザが入力したワンタイムパスワードを 一回ハッシュ関数にかけた結果とが一致した場合に, このユーザは認証 されます. 一方向ハッシュ関数を使っているので, もし正しく認証され たワンタイムパスワードが一回盗聴されたとしても, 次回以降に使われ る複数のワンタイムパスワードを生成することは不可能です. シーケ ンス番号はログインが成功するたびに一つずつ減らされて, ユーザとロ グインプログラムの間で同期が取られます. シーケンス番号が 1 まで 減ったら, S/Key を再度初期化する必要があります. 次に, S/Key 関連の四つのプログラムについて説明します. key プログラムは, シーケンス番号一つと, シー ド一つと, 秘密のパスフレーズ一つとを受け付けて, ワンタイムパスワー ドを一つ生成します. keyinit プログラムは, S/Key を初期化するのに使用され, また秘密のパスフレーズやシーケン ス番号やシードを変更するためにも使用されます. このプログラムを実 行するには, 秘密のパスフレーズか, または, シーケンス番号とシード とワンタイムパスワードの一組かの, どちらかが必要になります. keyinfo プログラムは, /etc/skeykeys というファイルを調べて, この プログラムを起動したユーザの現在のシーケンス番号とシードを表示し ます. 最後に, login と su プログラムについてですが, これらは S/Key のワンタイムパスワード を, (訳注:システムが) ユーザを認証するものとして受理するのに必要 な処理をおこないます. login プログラムは, 指 定された特定のアドレスからの接続に対して, UNIX パスワードの使用 を認めなくする機能, 逆に言えば S/Key の利用を強制する機能も持っ ています. この文書では, 四種類の異なる操作について説明します. 一つ目は, keyinit プログラムを信頼できる通信 路上で利用する場合で, 一番始めに S/Key を設定する操作や, 使い始 めたあとで秘密のパスフレーズやシードを変更する操作です. 二つ目は, keyinit プログラムを信頼できない通信路上で利 用する場合で, 操作の目的は一つ目と同じです. この場合には key プログラムを併用する必要があります. 三つ 目は, key プログラムを使い, 信頼できない通信 路を通じてログインする操作です. 四番目は, key プログラムを使って, 複数のワンタイムパスワードを一気に生成する操 作です. ここで生成した複数のワンタイムパスワードは, メモしたり 印刷したりして携帯し, 信頼できる通信路が一切ないところで利用する ことができます. (訳注: ワンタイムパスワードを記録した紙をなくさ ないこと! 電話番号やIPアドレス, ユーザ名を一緒にメモしていたら 最悪です!!) 信頼できる通信路での初期化 信頼できる通信路 (たとえばあるマシンのコンソール画面や, ssh を使っている時など) を利用しているときに, S/Key を初めて初期化 すること, S/Key の秘密のパスフレーズを変更すること, またはシー ドを変更すること, をおこなうことができます. そのためには, まず あなた自身がログインし, keyinit コマンドを 以下のようにパラメタなしで実行します: &prompt.user; keyinit Adding unfurl: Reminder - Only use this method if you are directly connected. If you are using telnet or rlogin exit with no password and use keyinit -s. ) `keyinit' コマンドが出力する注意です. 訳すと, ) 注意 - この動作モードはマシンに直接入力しているときのみ利用 ) すること. もし今 telnet や rlogin を使っているなら, 秘密のパ ) スフレーズを入力せずにこのままコマンドを終了し, かわりに ) keyinit -s を実行すること. Enter secret password: Again secret password: ID unfurl s/key is 99 to17757 DEFY CLUB PRO NASH LACE SOFT Enter secret password: というプロンプトに 対してあなたが考えた秘密のパスフレーズを入力します. このパスフ レーズはログインするときに使うものではなく, ログインするときに 使うワンタイムパスワードを生成するために使うものであることを覚 えておいてください. ID から始まる行は, S/Key に おける一回分のパラメタであり, あなたのログイン名とシーケンス番 号とシードです. (訳注: `keyinit' コマンドは 次回にログインするときに使えるパラメタを参考のためにここで表示 します.) S/Key を使ってログインするときには, システム側が自動 的にこれらのパラメタを表示してくれますから, これらのパラメタを 覚えておく必要はありません. 最後の行が, 今述べたパラメタと入力 された秘密のパスフレーズから計算されたワンタイムパスワードです. この例を実行した後, 次にログインするときに打ち込むべきワンタイ ムパスワードがこれです. 信頼できない通信路での初期化 信頼できない通信路を使って S/Key を初期化, または秘密のパ スフレーズを変更するためには, 信頼できる通信路として, その信頼 できない通信路とは別のものを用意する必要があります. その信頼で きる通信路は key プログラムを実行するために 必要となるもので, たとえばそれは, あなたが信頼できる Macintosh のデスクアクセサリや信頼できるマシンのシェルプロンプトだったり するでしょう. (訳注: ここでの通信路とはマシンそのものになりま す. 信頼できるマシンとは, 信頼できる人がしっかり管理しているマ シンということです.) 他に準備しておくものとして, シーケンス番 号 (100 は適切な値といえるでしょう) と, 場合によっては自分で考 えた, またはランダムに生成されたシードがあります. (あなたが S/Key を初期化しようとしているマシンへの) 信頼できない通信路を 使うときには, keyinit -s コマンドを以下のよ うに使用します: &prompt.user; keyinit -s Updating unfurl: Old key: to17758 Reminder you need the 6 English words from the key command. ) `keyinit' コマンドが出力する注意です. 訳すと, ) 注意 - skey コマンドの出力する 6 英単語が必要になります. Enter sequence count from 1 to 9999: 100 Enter new key [default to17759]: s/key 100 to 17759 s/key access password: デフォルトのシード (keyinit プログラム は困ったことにこれを key と読んでいるのです が, 混乱しないよう注意してください) で構わなければ, リターンキー を押してください. 次に, アクセスパスワードを入れる前に, あらか じめ用意しておいた信頼できる通信路(信頼できるマシンや信頼でき る S/Key デスクアクセサリなど) へ移って, 先ほどと同じパラメタ を入力します: &prompt.user; key 100 to17759 Reminder - Do not use this program while logged in via telnet or rlogin. Enter secret password: <秘密のパスフレーズ> CURE MIKE BANE HIM RACY GORE ここで信頼できない通信路の方に戻って, key コマンドが出力したワンタイムパスワード をコピーして keyinit プログラムに入力します. s/key access password:CURE MIKE BANE HIM RACY GORE ID unfurl s/key is 100 to17759 CURE MIKE BANE HIM RACY GORE 後は, 前章で説明したことと同様です. ワンタイムパスワードを一つ生成する S/Key の初期化ができたら, ログインするときには以下のような プロンプトが出てくるでしょう: &prompt.user; telnet example.com Trying 10.0.0.1... Connected to example.com Escape character is '^]'. FreeBSD/i386 (example.com) (ttypa) login: <ユーザ名> s/key 97 fw13894 Password: ここでは表示していませんが, 便利な機能がログインプログラム に備わっています: パスワードプロンプトに対して, 何も入力せずに リターンを押すとエコーモードに切り替わります. つまりタイプし た文字がそのまま見えるようになるのです. これはS/Key のワンタイ ムパスワードを紙に印刷していた場合など, ワンタイムパスワードを 手で入力しなければならない場合に特に役立つ機能です. また, この ログインしようとしてるマシンが, 接続元のマシンから UNIX パスワードを使ってログインすることができないように設定さ れている場合には, ログインプロンプトには S/Key のワンタイムパ スワードのみが受け付けられることを示す (s/key required) という注釈が表示されます. 次に, このログインプロンプトに対して入力するためのワンタイ ムパスワードを生成しましょう. そのために, key プログラムを使える信頼できるマシンを用 意します. (key プログラムには DOS や Windows の上で動くもの, MacOS の上で動くものなどもあります.) key プログラムを使うときには, シーケンス番 号とシードを指定します. ログインしようとしているマシンのログ インプロンプトの右側をカットアンドペーストすると楽でしょう. 信頼できるシステムで: &prompt.user; key 97 fw13894 Reminder - Do not use this program while logged in via telnet or rlogin. Enter secret password: WELD LIP ACTS ENDS ME HAAG ここでワンタイムパスワードが得られました. ログインを続けま しょう: login: <username> s/key 97 fw13894 Password: <return to enable echo> s/key 97 fw13894 Password [echo on]: WELD LIP ACTS ENDS ME HAAG Last login: Tue Mar 21 11:56:41 from 10.0.0.2 ... 以上の手順は, 信頼できるマシンが利用できる場合の みに使えるもっとも簡単な方法です. Java による S/Key の key applet もあり, The Java OTP Calculator からダウンロードして Java をサポートするブ ラウザ上でローカルに実行することができます. 複数のワンタイムパスワードを生成する 都合によっては, 信頼できるマシンや信頼できる通信路が一切確 保できないようなところで S/Key を使う必要があるでしょう. この ような場合には, key コマンドを使って複数の ワンタイムパスワードをあらかじめ一気に生成し, 紙に印刷して携帯 していくことができます. たとえば: &prompt.user; key -n 5 30 zz99999 Reminder - Do not use this program while logged in via telnet or rlogin. Enter secret password: <秘密のパスフレーズ> 26: SODA RUDE LEA LIND BUDD SILT 27: JILT SPY DUTY GLOW COWL ROT 28: THEM OW COLA RUNT BONG SCOT 29: COT MASH BARR BRIM NAN FLAG 30: CAN KNEE CAST NAME FOLK BILK という引数によって 5 個のワンタイム パスワードを順に生成します. ここで は, 最 後のシーケンス番号となるべき数字です. 出力は普通に使う順番とは 逆に出力されていることに注意してください (訳注: 一番最初に使うワンタイムパスワードは一番最後に出力され たものです). この結果をカットアンドペーストして lpr コマンドを使って印刷すると よいでしょう. もしあなたがセキュリティに偏執するなら, この結果を紙と鉛筆を使っ て手で書き移した方がよいかもしれません. ここで, 出力の各行はシー ケンス番号とそれに対応する一回分のワンタイムパスワードです. 消費済みの ワンタイムパスワードの行をペンで消していくと便利で しょう. UNIX パスワードの利用を制限する 設定ファイル /etc/skey.access を使っ て UNIX パスワードの利用を制限することができます. この場合の判 断基準として, ログインを受け付ける際のホスト名, ユーザ名, 端末 のポート, IP アドレスなどが利用できます. この設定ファイルの詳 細に関してはマニュアル &man.skey.access.5; をご覧ください. マ ニュアルにはこの機能に関わるセキュリティについて, いくつかの警 告が記述してあります. この機能を使ってセキュリティを高めようと するのならば絶対にこのマニュアルを読んでください. もし /etc/skey.access ファイルが存在 しないならば (FreeBSD のデフォルト状態ではそうです), すべての ユーザが UNIX パスワードを利用することができます. 逆に, もし ファイルが存在するならば, skey.access ファ イルに明示的に記述されていない限り, すべてのユーザは S/Key の 利用を要求されます. どちらの場合においても, そのマシンのコンソー ルからはいつでも UNIX パスワードを使ってログインすることが可能 です. 以下によく使われるであろう三種類の設定を含む設定ファイルの 例を示します: permit internet 192.168.0.0 255.255.0.0 permit user fnord permit port ttyd0 はじめの行 (permit internet) で, telnet などで接続するときの IP のソースアドレス (注意: これは偽造され るおそれがあります) が特定の値とマスクに一致している場合に, UNIX パスワードの利用を許可することを指定しています. この設定 自体はセキュリティを高めるための機能ではありません. そうでは なく, ログインの権利を持つ許可されたユーザに対して, 現在そのユー ザが使っているネットワークが信頼できないと考えられるので S/Key を使うべきである, ということを気づかせるための機能であると考え てください. 二行目 (permit user) によって, ある特定 のユーザ, この場合は fnord, に対して, いつ でも UNIX パスワードの利用を許可するように指定しています. 一般 的にはこの設定をおこなうべきではありません. key プログラムがどうしても使えない環境にい る人や, ダム端末しかない環境にいる人, または何度教えても聞く耳 を持たないような人をサポートする必要がある場合にのみ設定をおこ なってください. 三行目 (permit port) によって, ある特定 の端末ポートからログインしようとするすべてのユーザに対して UNIX パスワードの利用を許可するように指定しています. この設定 はダイヤルアップ回線に対する設定として利用できるでしょう. Kerberos 原作: &a.markm; (Mark Dapoz md@bsc.no からの寄稿に基づいています). 訳: &a.jp.arimura;. Kerberosは, サーバのサービスによってユーザが安全に認証を受けられる ようにするための, ネットワークの付加システム及びプロトコルです. リモートログイン, リモートコピー, システム間での安全なファイルのコピ ーやその他のリスクの高い仕事がかなり安全に, そしてこれまでより制御 できるようになります. 以下の文章は, FreeBSD用として配布されているKerberosをセットアップ する際のガイドとして読むことができます. しかし, 完全な説明が必要な場合には, マニュアルページを読んだ方がよい でしょう. FreeBSDのKerberosは, オリジナルの4.4BSD-Liteの配布に含まれているものではなく, FreeBSD 1.1.5.1のときに移植されたeBonesです. これはアメリカ/カナダの外で作成されており, そのため, アメリカか らの暗号技術の輸出制限があった時代でも, これら以外の国の人々が手に入れられるものでした. 初期データベースの作成 この作業はKerberosサーバだけでおこないます. まず, 古いKerberosの データベースが存在しないことを確認してください. ディレクトリ/etc/kerberosIVに移って, 次のファイルだけが 存在することをチェックします: &prompt.root; cd /etc/kerberosIV &prompt.root; ls README krb.conf krb.realms もし他のファイル (principal.* や master_key) が 存在する場合には, kdb_destroyというコマンドで古い Kerberosデータベースを消してください. Kerberosが走っていなければ, 単に余計なファイルを消せばよいです. まず, krb.conf と krb.realmsを編集してKerberosの 管理領域 (realm) を定義してください. ここでは管理領域がGRONDAR.ZA で, サーバ名がgrunt.grondar.zaであるとします. krb.conf というファイルを次のように編集してください: &prompt.root; cat krb.conf GRONDAR.ZA GRONDAR.ZA grunt.grondar.za admin server CS.BERKELEY.EDU okeeffe.berkeley.edu ATHENA.MIT.EDU kerberos.mit.edu ATHENA.MIT.EDU kerberos-1.mit.edu ATHENA.MIT.EDU kerberos-2.mit.edu ATHENA.MIT.EDU kerberos-3.mit.edu LCS.MIT.EDU kerberos.lcs.mit.edu TELECOM.MIT.EDU bitsy.mit.edu ARC.NASA.GOV trident.arc.nasa.gov この例にあるような他の管理領域は, 実際には必要ありません. この例は複数の管理領域を認識する方法を示したものですので, これらの行は含めなくても結構です. 1行目はこのシステムが動いている管理領域の名前です. 他の行は管理領域とホスト名のエントリです. 行の1つめの単語が管理領域で, 2つめがその管理領域の中で 鍵配布センター(Key Distribution Center) として働くホスト名です. ホスト名の次に admin server と書いてある場合には, そのホストが ``管理データベースサーバ''(Administrative Database Server) も提供 することを意味します. これらの単語について詳しく知りたい場合にはKerberosのマニュアル ページをご覧ください. ここで, GRONDAR.ZAという管理領域にgrunt.grondar.za およびその他の.grondar.za ドメインのすべてのホストを追加し なければなりません. krb.realmsは次のようになります: &prompt.root; cat krb.realms grunt.grondar.za GRONDAR.ZA .grondar.za GRONDAR.ZA .berkeley.edu CS.BERKELEY.EDU .MIT.EDU ATHENA.MIT.EDU .mit.edu ATHENA.MIT.EDU もう一度注意しますが, 他の管理領域を書く必要はありません. これらは複数の管理領域を認識できるようにマシンを設定する方法を 示した例ですので, これらの行は消して構いません. 1行目は名前をつけた管理領域に 特定の システムを含めるための ものです. 残りの行は名前をつけた管理領域にサブドメインのデフォルトの システムを含めるためのものです. これでデータベースを作成する準備ができました. この操作はKerberos サーバ (鍵配布センター) を起動するだけです. kdb_initコ マンドを次のように実行してください: &prompt.root; kdb_init Realm name [default ATHENA.MIT.EDU ]: GRONDAR.ZA You will be prompted for the database Master Password. It is important that you NOT FORGET this password. Enter Kerberos master key: ここで鍵を保存して, ローカルのマシンにあるサーバが取り出せるように します. それにはkstashコマンドを使用します. &prompt.root; kstash Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! これで暗号化されたマスタパスワードが /etc/kerberosIV/master_key に保存されました. すべてが動くようにするための設定 Kerberosを導入する それぞれの システムのデータベースに, 2つ のprincipal (主体名) を追加する必要があります. その名前は kpasswdとrcmdです. これら2つのprincipalは, 個々 のシステムにおいて, システム名と同じ名前のインスタンスと組にして作成 されます. これらの kpasswd と rcmd というデーモンによって, 他の システムからKerberosのパスワードを変更したり, rcpや rlogin, rshといったコマンドを実行したりできるよ うになります. それでは実際にこれらのエントリを追加しましょう: &prompt.root; kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: passwd Instance: grunt <Not found>, Create [y] ? y Principal: passwd, Instance: grunt, kdc_key_ver: 1 New Password: <---- ここは「RANDOM」と入力してください Verifying password New Password: <---- ここは「RANDOM」と入力してください Random password [y] ? y Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: rcmd Instance: grunt <Not found>, Create [y] ? Principal: rcmd, Instance: grunt, kdc_key_ver: 1 New Password: <---- ここは「RANDOM」と入力してください Verifying password New Password: <---- ここは「RANDOM」と入力してください Random password [y] ? Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: <---- 何も入力しないと終了します サーバファイルの作成 次に, 各マシンにおけるサービスを定義している, すべてのインスタンス を展開します. これにはext_srvtabというコマンドを使用しま す. このコマンドで作成されるファイルは, Kerberosの各クライアン トの/etc/kerberosIVディレクトリに 安全な方法でコピーまたは 移動する必要があります. このファイルはそれぞれのサーバとクラ イアントに存在しなければならず, またKerberosの運用において重要なも のです. &prompt.root; ext_srvtab grunt Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Generating 'grunt-new-srvtab'.... このコマンドは一時的なファイルを作成するだけです. ファイル名をすべ てのサーバが読めるような srvtab という名前に変更しな ければなりません. mvコマンドを用いてシステムの場所に移動 してください. &prompt.root; mv grunt-new-srvtab srvtab そのファイルがクライアントに配るためのもので, ネットワークが安全で はないと思われる場合には, client-new-srvtab を移動 可能なメディアにコピーして物理的に安全な方法で運んでください. クラ イアントの/etc/kerberosIVディレクトリで, 名前を srvtabに変更し, modeを600にするのを忘れないでください: &prompt.root; mv grumble-new-srvtab srvtab &prompt.root; chmod 600 srvtab データベースへのユーザの追加 ここで, ユーザのエントリをデータベースに追加する必要があります. 始めに, ユーザjaneのエントリを作成してみましょう. kdb_edit を用いて次のように作成してください: &prompt.root; kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: jane Instance: <Not found>, Create [y] ? y Principal: jane, Instance: , kdc_key_ver: 1 New Password: <---- 安全なパスワードを入れてください Verifying password New Password: <---- もう一度パスワードを入れてください Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: <---- 何も入力しないと終了します すべてのテスト まず始めにKerberosデーモンを起動する必要があります. /etc/rc.conf ファイルを正しく編集してあれば, マシンを再 起動することでに自動的にデーモンが起動します. これはKerberosサー バでのみ必要です. Kerberosクライアントは/etc/kerberosIVか ら必要なものを自動的に入手します. &prompt.root; kerberos & Kerberos server starting Sleep forever on error Log file is /var/log/kerberos.log Current Kerberos master key version is 1. Master key entered. BEWARE! Current Kerberos master key version is 1 Local realm: GRONDAR.ZA &prompt.root; kadmind -n & KADM Server KADM0.0A initializing Please do not use 'kill -9' to kill this job, use a regular kill instead Current Kerberos master key version is 1. Master key entered. BEWARE! さあ, これで上で作成した jane というIDのチケットを kinitコマンドで得ることができます: &prompt.user; kinit jane MIT Project Athena (grunt.grondar.za) Kerberos Initialization for "jane" Password: klist コマンドを用いてトークンを見て, きちんとチケットを持って いるかどうか確認してください: &prompt.user; klist Ticket file: /tmp/tkt245 Principal: jane@GRONDAR.ZA Issued Expires Principal Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.GRONDAR.ZA@GRONDAR.ZA passwd コマンドを用いてパスワードを変更して, kpasswdデーモ ンがKerberos データベースに対して認証されるかどうかチェックして ください: &prompt.user; passwd realm GRONDAR.ZA Old password for jane: New Password for jane: Verifying password New Password for jane: Password changed. <command>su</command>特権の追加 root権限が必要なユーザは誰でも, suコマンドのパス ワードをユーザ毎に別のもの として持つことができます. rootにsu できる権利を与えられたidを追加します. これは, principalに付いているroot というインスタンスに よって制御されています. kdb_editを用いて jane.rootというエントリを Kerberosデータベースに作成します: &prompt.root; kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: jane Instance: root <Not found>, Create [y] ? y Principal: jane, Instance: root, kdc_key_ver: 1 New Password: <---- 安全なパスワードを入れます Verifying password New Password: <---- もう一回パスワードを入れます Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? 12 <--- ここは短くしてください Attributes [ 0 ] ? Edit O.K. Principal name: <---- 何も入力しないと終了します 実際にトークンをもらって, ちゃんと働いているかどうか確認しましょう: &prompt.root; kinit jane.root MIT Project Athena (grunt.grondar.za) Kerberos Initialization for "jane.root" Password: ここでrootユーザの .klogin ファイルにユーザを追加する必要が あります. &prompt.root; cat /root/.klogin jane.root@GRONDAR.ZA suしてみましょう: &prompt.user; su Password: どのトークンを持っているか見てみましょう: &prompt.root; klist Ticket file: /tmp/tkt_root_245 Principal: jane.root@GRONDAR.ZA Issued Expires Principal May 2 20:43:12 May 3 04:43:12 krbtgt.GRONDAR.ZA@GRONDAR.ZA 他のコマンドの使用 ここまでの例では, jane という principal を root とい うインスタンス付きで作成しました. これはユーザと同じ名前をprincipalと しており, Kerberosのデフォルトの値です; <username>.root という形式の <principal>.<instance>で, 必要なエント リがrootのホームディレクトリの .kloginファイルに あれば, <username>がrootに suすることができま す. &prompt.root; cat /root/.klogin jane.root@GRONDAR.ZA 同様に, ユーザのホームディレクトリの .kloginファイルに次の ような行がある場合には: &prompt.user; cat ~/.klogin jane@GRONDAR.ZA jack@GRONDAR.ZA jane または jack という名前で (前述のkinit によって) 認証されている GRONDAR.ZA という管理領域のユーザ なら誰でもrlogin や rsh, rcp等によってこ のシステム (grunt) のjaneのアカウントまたはファ イルにアクセスできます. たとえば, Janeが他のシステムにKerberos を用いてloginします: &prompt.user; kinit MIT Project Athena (grunt.grondar.za) Password: &prompt.user; rlogin grunt Last login: Mon May 1 21:14:47 from grumble Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995 次の例では, Jackが同じマシンの Jane のアカウントにloginします. Janeは .klogin ファイルを前述のように設定しており, Kerberosではjackというprincipal をインスタンスなしで設定してあ ります. &prompt.user; kinit &prompt.user; rlogin grunt -l jane MIT Project Athena (grunt.grondar.za) Password: Last login: Mon May 1 21:16:55 from grumble Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995 ファイアウォール 原作: &a.gpalmer;, Alex Nash;. 訳: &a.jp.saeki;. 11 November 1996. ファイアウォールは, インターネットに参加している人はもちろんのこと, プライベートネットワークのセキュリティ向上のための アプリケーションを 探している人にとっても, ますます興味深くなりつつある分野です. このセクションではファイアウォールとは何か, ファイアウォールの使用法, そしてファイアウォールを構築するために FreeBSD のカーネルで 提供されているファシリティ (機能) の使用法について説明したいと思います. 社内のネットワークと 巨大かつ信頼のおけない インターネットとの間にファイアウォールを構築することで セキュリティ上のすべての問題が解決できると考える人がいます. ファイアウォールはセキュリティ上の問題を 解決する助けになる場合もありますが, 充分な設定がなされていないファイアウォールは, まったくファイアウォールを 持たない場合よりもセキュリティ上の危険を増大させてしまいます. ファイアウォールにできることは, あなたのシステムにもう一つのセキュリティ層を 追加することだけで, 本気でアタックをしかけてくるクラッカーが内部ネットワークに 侵入するのを妨げることはできません. ファイアウォールを侵入不可能と過信して 内部のセキュリティをおろそかにすることは, 単にクラッカーの仕事を少し簡単にするだけでしか ありません. ファイアウォールとは何か ? 現在インターネットで普通に使用されている ファイアウォールには 二つの異なるタイプがあります. 一つは, 厳密には パケットフィルタリングルータ と 呼ばれるタイプのものです. これはマルチホームのホストマシン (複数の ネットワークに接続されているマシン) のカーネルが, ある規則にしたがって パケットを転送したりブロックしたりするものです. もう一つは, proxy (代理) サーバ として知られているタイプのものです. これは, おそらくはマルチホームのホストマシン上で, カーネルによるパケット転送を 禁止して, デーモンにより認証の提供とパケットの転送とを おこなうものです. 二つのタイプのファイアウォールを組み合わせて使用して, 特定のマシン ( 要塞ホスト と呼ばれる) だけが パケットフィルタリングルータを通して内部ネットワークへ パケットを送ることができるよう設定している サイトがしばしば存在します. proxy (代理) サービスは通常の認証機構よりもセキュリティを 強化してある 要塞ホストで動作させます. FreeBSD は (IPFW として知られる) カーネルパケットフィルタ込みで 提供されています. このセクションの後の方では, このフィルタについての 説明を集中しておこないます. サードパーティから提供されるソフトウェアを使用することにより, Proxy サーバを FreeBSD 上に構築することができます. しかし, 現在入手可能な proxy サーバは たいへんバラエティに富んでいるので, このドキュメントでそれらすべてを カバーすることは不可能です. パケットフィルタリングルータ ルータとは, 二つまたはそれ以上のネットワークの間で パケットの転送をおこなう マシンのことです. パケットフィルタリングルータは, そのカーネルの内部に, 一つ一つのパケットをルールリストと比較して 転送するかしないかを決める 特別なコードを持っています. 最近の IP ルーティングソフトウェアのほとんどは, 内部に パケットのフィルタリングをおこなうためのコードを持っていて, デフォルトでは すべてのパケットを転送するようになっています. このフィルタを有効にするためには, パケットの通過を許すべきかどうかを決める ルールを自分で定義する必要があります. パケットを通すべきか通すべきでないかを決めるために, パケットヘッダの内容にマッチするものが ルールリストから探されます. マッチするルールが見つかると, ルールアクションが実行されます. ルールアクションには, パケットを捨てる, パケットを転送する, またはパケットの発信元に ICMP メッセージを送り返すというものがあります. ルールの検索は先頭から順番におこなわれ, 通常は最初にマッチしたものだけが 適用されます. そのため, このルールリストはルールチェーン と呼ばれることもあります. パケットマッチングの基準は使用するソフトウェアに よって異なりますが, 通常はパケットの発信元 IP アドレス, 宛先 IP アドレス, 発信元ポート番号, 宛先ポート番号 (ポート番号はポートをサポートするプロトコルの場合のみ), パケットタイプ (UDP, TCP, ICMP など) に基づくルールを指定することができます. Proxy サーバ Proxy サーバとは通常のシステムデーモン (telnetd, ftpd など) を 特別なサーバで置き換えたマシンのことです. これらのサーバは, 通常は中継をおこなって特定方向への接続だけを許すため, proxy サーバ と呼ばれます. (たとえば) proxy telnet サーバをファイアウォールホストで走らせておきます. 外部からユーザがファイアウォールに対して telnet を実行すると, proxy telnet サーバが応答して, 何らかの認証機構を実行します. これを通過した後で, 内部ネットワークへのアクセスがおこなえるように なるのです. (内部ネットワークからの信号は proxy サーバがかわりに受け取り, 外へ向けて送り出します.) Proxy サーバは通常, 普通のサーバより堅固に構築されていて, しばしば 使い捨てパスワードシステムなどを含む, 多様な認証機構を持っています. 使い捨てパスワードシステムとは, どういうものなのでしょうか. 仮に誰かが何らかの方法で, あなたが使用したパスワードを手に入れたとします. しかし, 一度使用したことで, そのパスワードは既に無効になっているのです. ですから, そのパスワードをもう一度使用したとしても, あなたのシステムへ アクセスすることはできないというわけです. これらのサーバは中継をおこなうだけで, 実際のところサーバホスト自身への アクセスをユーザに許してはいません. そのため, 何者かがセキュリティシステムに 侵入用の裏口を取り付けることは, より困難になっています. proxy サーバはアクセス制限の方法をいくつも持っていて, 特定のホスト だけがサーバへのアクセス権を得ることができるように なっていることがあり ます. そして目的のマシンと通信できるユーザを制限するように 設定することもできます. もう一度言いますが, どんなファシリティ (機能) が使えるかは, どんな proxy サービスをおこなうソフトウェアを選ぶかに大きく 依存します. IPFW で何ができるか FreeBSD とともに配布されている IPFW は, カーネル内部にあって パケットのフィルタリングとアカウンティングを おこなうシステムであり, ユーザ側のコントロールユーティリティである &man.ipfw.8; を 含んでいます. ルーティングの決定をおこなう際に, これらは互いに協力して, カーネルで使用されるルールを定義したり, 現在使用されているルールを 問い合わせたりすることができます. IPFW は互いに関連する二つの部分からなっています. ファイアウォールセクションは パケットフィルタリングをおこないます. また, IP アカウンティングセクションはファイアウォールセクションのものと 似たルールに基づいてルータの使用を追跡します. これにより, (たとえば) 特定のマシンからルータへのトラフィックがどのくらい 発生しているか調べたり, どれだけの WWW (World Wide Web) トラフィックが フォワードされているかを知ることができます. IPFW は, ルータではないマシンにおいても入出力コネクションの パケットフィルタリングのために 使用することができるように設計されています. これは一般的な IPFW の使用法とは異なる特別な使い方ですが, こういった状況でも同じコマンドと テクニックが使用されます. FreeBSD で IPFW を有効にする IPFW システムの中心となる部分はカーネル内部にあります. そのため, どのファシリティ (機能) を必要とするかによって, 一つまたは それ以上のオプションをカーネルコンフィグレーション ファイルに追加し, カーネルを再コンパイルする必要があるでしょう. カーネルの再コンパイル方法の詳細については, カーネルコンフィグレーション を参照してください. 現在, IPFW に関係するカーネルコンフィグレーションオプションは 三つあります: options IPFIREWALL パケットフィルタリングのためのコードを カーネルに組み込みます. options IPFIREWALL_VERBOSE &man.syslogd.8; を通じて パケットのログを取るためのコードを有効にします. フィルタルールでパケットのログを取るように指定しても, このオプションが指定されていなければ, ログを取ることはできません. options IPFIREWALL_VERBOSE_LIMIT=10 &man.syslogd.8; を通じて ログを取るパケットの数をエントリ毎に制限します. 敵対的な環境においてファイアウォールの 動作のログを取りたいけれど, syslog の洪水によるサービス拒絶攻撃に対し 無防備でありたくないという場合に, このオプションを使用したいと思うことが あるかもしれません. チェーンエントリのログが指定された制限数に達すると, そのエントリに関するログ取りは停止されます. ログ取りを再開するには, &man.ipfw.8; ユーティリティを使用して 関連するカウンタをリセットする必要があります: &prompt.root; ipfw zero 4500 4500 とは, ログ取りを続行したいチェーンエントリの番号です. 以前のバージョンの FreeBSD は IPFIREWALL_ACCT というオプションを 持っていました. しかし, ファイアウォールコードがアカウンティングファシリティ (機能) を 自動的に含むようになったため, 現在では使用されることはなくなっています. IPFW の設定 IPFW ソフトウェアの設定は &man.ipfw.8; ユーティリティを 通じておこないます. このコマンドの構文は非常に 複雑に見えますが, 一旦その構造を理解すれば比較的単純です. このユーティリティでは今のところ四つの異なる コマンドカテゴリが 使用されています: それは追加 / 削除, 表示, フラッシュ, およびクリアです. 追加 / 削除はパケットの受け入れ, 拒絶, ログ取りをどのようにおこなうか というルールを構築するのに使用します. 表示はルールリスト (またはチェーン) と (アカウンティング用) パケットカウンタの 内容を調べるのに使用します. フラッシュはチェーンからすべてのエントリを 取り除くのに使用します. クリアは一つまたはそれ以上のアカウンティングエントリを ゼロにするのに 使用します. IPFW ルールの変更 この形式での使用法は: ipfw -N コマンド index アクション log プロトコル アドレス オプション この形式で使用する際に有効なフラグは一つだけです: -N アドレスやサービス名を 文字列に変換して表示します. コマンド は一意である限り短縮可能です. 有効な コマンド は: add ファイアウォール / アカウンティングルールリストに エントリを追加します. delete ファイアウォール / アカウンティングルールリストから エントリを削除します. 以前のバージョンの IPFW では, ファイアウォールエントリと パケットアカウンティングエントリが別々に利用されていました. 現在のバージョンでは, それぞれのファイアウォールエントリ毎に パケットアカウンティングエントリが備えられています. index が指定されていると, エントリはチェーン中の index で示される位置に置かれます. index が指定されて いなければ, エントリは (65535 番のデフォルトルールである パケット拒絶を別にして) 最後のチェーンエントリの index に 100 を足した 位置 (チェーンの最後) に置かれます. カーネルが IPFIREWALL_VERBOSE つきでコンパイルされている場合, log オプションはマッチしたルールを システムコンソールに出力させます. 有効な アクション は: reject パケットを捨てます, ICMP ホスト / ポート到達不能パケットを (適切な方を) 発信元へ送ります. allow 通常通りパケットを通過させます. (別名: pass および accept) deny パケットを捨てます. 発信元は ICMP メッセージによる 通知を受けません (そのためパケットが 宛先に到達しなかったように見えます). count このルールはパケットカウンタを更新するだけで, パケットを 通過させたり拒絶したりしません. 検索は次のチェーンエントリから続けられます. それぞれの アクション は一意な先頭部分だけでも認識されます. 指定可能な プロトコル は以下の通り: all 任意の IP パケットにマッチします. icmp ICMP パケットにマッチします. tcp TCP パケットにマッチします. udp UDP パケットにマッチします. アドレス の指定は: from address/mask port to address/mask port via interface port はポートをサポートする プロトコル (UDP と TCP) の 場合にだけ指定可能です. は必須ではなく, - 特定のインターフェースを通ってきたパケット + 特定のインタフェースを通ってきたパケット だけにマッチするように, IP アドレスまたはローカル IP - インターフェースの ドメイン名, またはインターフェース名 + インタフェースの ドメイン名, またはインタフェース名 (たとえば ed0) を 指定することができます. - インターフェースユニット番号はオプションで, + インタフェースユニット番号はオプションで, ワイルドカードで指定することが できます. たとえば, ppp* はすべてのカーネル PPP - インターフェースに マッチします. + インタフェースに マッチします. address/mask の指定は: address または address/mask-bits または address:mask-pattern IP アドレスのかわりに有効なホスト名を指定することも可能です. はアドレスマスクで上位何ビットを１にするべきかを 示す十進数値です. たとえば次の指定, 192.216.222.1/24 はクラス C のサブネット (この場合 192.216.222) の任意のアドレスにマッチする マスクを作成します. は与えられたアドレスと 論理 AND される IP アドレスです. キーワード any は任意の IP アドレスを指定するために 使用することができます. ブロックするポート番号は以下のように指定します: port, port, port… のように単独のポートまたはポートのリストを指定します. または port- port のようにポートの範囲を指定します. 単独のポートとポートのリストを 組み合わせて指定することも可能ですが, その場合は常に範囲の方を 最初に指定しなければなりません. 使用可能な オプション は: frag データグラムの最初の フラグメントでなければマッチします. in 入力途中のパケットであればマッチします. out 出力途中のパケットであればマッチします. ipoptions spec IP ヘッダが spec に指定された カンマで区切られた オプションのリストを含んでいればマッチします. サポートされている IP オプションのリストは: ssrr (ストリクトソースルート), lsrr (ルーズソースルート), rr (レコードパケットルート), そして ts (タイムスタンプ) です. 特定のオプションを含まないことを指定するには ! を先頭につけます. established パケットが既に確立されている TCP コネクションの一部であれば (つまり RST または ACK ビットがセットされていれば) マッチします. established ルールをチェーンの最初の方に置くことで, ファイアウォールのパフォーマンスを向上させることが できます. setup パケットが TCP コネクションを確立しようとするものであれば (SYN ビットがセットされ ACK ビットはセットされていなければ) マッチします. tcpflags flags TCP ヘッダが flags に指定された カンマで区切られたフラグの リストを含んでいればマッチします. サポートされているフラグは, fin, syn, rst, psh, ack と urg です. 特定のフラグを含まないことを指定するには ! を先頭につけます. icmptypes types ICMP タイプが types リストに 存在していればマッチします. リストはタイプの範囲または個々のタイプを カンマで区切った任意の組合せで指定できます. 一般的に使用されている ICMP タイプは: 0 エコーリプライ (ping リプライ), 3 相手先到達不可能, 5 リダイレクト, 8 エコーリクエスト (ping リクエスト), そして 11 時間超過 (&man.traceroute.8; で使用されているように, TTL 満了を示すのに使用されます) です. IPFW ルールリストの表示 この形式での使用法は: ipfw -a -t -N l この形式で使用する際に有効なフラグは三つあります: -a リスト表示の際にカウンタの値も表示します. このオプションは アカウンティングカウンタの 内容を見る唯一の手段です. -t 各チェーンエントリが最後に マッチした時刻を表示します. この時刻表示は &man.ipfw.8; ユーティリティで使用される入力形式と 互換性がありません. -N (可能であれば) アドレスやサービス名を文字列に変換して表示します. IPFW ルールのフラッシュ チェーンをフラッシュするには: ipfw flush カーネルに固定されているデフォルトルール (インデックス 65535 番) 以外の, ファイアウォールチェーンの中のすべてのエントリを削除します. デフォルトではすべてのパケットが拒絶されるので, 一旦これを実行すると, パケットを許可するエントリがチェーンに追加されるまで, あなたのシステムがネットワークから切り放されてしまいます. そのため, ルールのフラッシュをおこなうときは注意が必要です. IPFW パケットカウンタのクリア 一つまたはそれ以上のパケットカウンタをクリアするためには: ipfw zero index index が指定されていなければ, すべてのパケットカウンタが クリアされます. index が指定されていれば, 特定のチェーンエントリだけが クリアされます. ipfw に対するコマンドの例 このコマンドは, ホスト evil.crackers.org から ホスト nice.people.org の telnet ポートへの すべてのパケットを拒絶します: &prompt.root; ipfw add deny tcp from evil.crackers.org to nice.people.org 23 次の例は, ネットワーク crackers.org (クラス C) 全体から マシン nice.people.org (の任意のポート) への 任意の TCP トラフィックを拒絶し, ログを取ります. &prompt.root; ipfw add deny log tcp from evil.crackers.org/24 to nice.people.org あなたの内部ネットワーク (クラス C のサブネット) に対する X セッションを 張れないようにする場合, 以下のコマンドで必要なフィルタリングがおこなえます: &prompt.root; ipfw add deny tcp from any to my.org/28 6000 setup アカウンティングレコードを見るには: &prompt.root; ipfw -a list または短縮形式で &prompt.root; ipfw -a l 最後にチェーンエントリがマッチした 時刻を見ることもできます. &prompt.root; ipfw -at l パケットフィルタリングファイアウォールの構築 以下の提案は, ただの提案にすぎません: 必要な処理はそれぞれのファイアウォールで異なるため, あなた独自の要求にあったファイアウォールを構築する方法を ここで述べることはできないのです. 最初にファイアウォールをセットアップするとき, コントロールされた環境でファイアウォールホストの 設定がおこなえるような テストベンチセットアップが用意できない場合には, カーネルのログ取りを 有効にしてログ取り版のコマンドを使用することを 強くおすすめします. そうすることで, 大した混乱や中断なしに問題となる範囲の特定と処置を 素早くおこなうことができます. 初期セットアップフェーズが完了してからであっても, アタックの可能性のあるアクセスをトレースしたり, 要求の変化に応じてファイアウォールルールを 変更したりできるので, `deny' に対するログ取りをおこなうことをおすすめします. accept コマンドのログ取りをおこなっていると, ファイアウォールをパケットが一つ通過する毎に 1 行のログが生成されるため 大量の ログデータが発生します. そのため, 大規模な ftp/http 転送などをおこなうと, システムが非常に 遅くなってしまいます. また, パケットが通過するまでにカーネルにより 多くの仕事を要求するため, パケットのレイテンシ (latency) を増加させてしまいます. syslogd もログをディスクに記録するなど, より多くの CPU タイムを 使用し始め, 実に容易に /var/log が置かれているパーティションを パンクさせてしまう可能性があります. ファイアウォールは, /etc/rc.conf.local か, もしくは /etc/rc.conf によって有効化されるべきです. 関連マニュアルページには, どのドアノブ(訳注: ポートや IP アドレスなど, ネットワークからの入口を示すもののこと)に手をつければ良いのかに ついての説明と, ファイアウォール設定の既定値のリストがあります. もし, 設定の既定値を使わない場合には, ipfw list とすることで, 現在のルールセットを rc.conf から読み込める形で ファイルに出力することができます. また, /etc/rc.conf.local や /etc/rc.conf によってファイアウォールを 有効化しない場合には, ファイアウォールの有効化がすべての - IP インターフェイス設定より先に行なわれるように確認することが重要です. + IP インタフェイス設定より先に行なわれるように確認することが重要です. 次の問題は, ファイアウォールが実際には何を する べきかです ! これは外部からそのネットワークへのどんなアクセスを許したいか, また内部から外界へのアクセスを どのくらい許したいかに大きく依存します. いくつか一般的なルールを挙げると: 1024 番以下のポートへのすべての TCP 入力アクセスをブロックします. ここは finger, SMTP (mail) そして telnet など, 最もセキュリティに敏感な サービスが存在する場所だからです. すべての 入力 UDP トラフィックをブロックします. これは UDP を使用しているサービスで有用なものは極めて少ないうえ, 有用なトラフィック (たとえば Sun の RPC と NFS プロトコル) は, 通常セキュリティに対する脅威となるためです. UDP はコネクションレスプロトコルであるため, 入力 UDP トラフィックを拒絶することは すなわち出力 UDP トラフィックに対する返答をも ブロックすることになるので, このことはそれなりの不利益をもたらします. たとえば外部の archie (prospero) サーバを使用している (内部の) ユーザに とって問題となる可能性があります. もし archie へのアクセスを許したければ, 191 番と 1525 番のポートから 任意の UDP ポートへ来るパケットがファイアウォールを通過することを 許可しなければなりません. 123 番のポートから来るパケットは ntp パケットで, これも通過の許可を考慮する必要がある もう一つのサービスです. 外部から 6000 番のポートへのトラフィックをブロックします. 6000 番のポートは X11 サーバへのアクセスに使用されるポートで, セキュリティに対する脅威となりえます. (特に自分のワークステーションで xhost + をおこなう癖を持っている人がいればなおさらです). X11 は実際に 6000 番以降のポートを使用する可能性があるため, 通過許可に 上限を定めると, そのマシンで走らせることのできる X ディスプレイの 個数が制限されます. RFC 1700 (Assigned Numbers) で定義されているように, 上限は 6063 です. 内部のサーバ (たとえば SQL サーバなど) がどのポートを使用するかを チェックします. それらのポートは通常, 上で指定した 1-1024 番の範囲から外れていますので, これらも同様にブロックしておくことは おそらく良い考えです. これとは別のファイアウォール設定に 関するチェックリストが CERT から 入手可能です. http://www.cert.org/tech_tips/packet_filtering.html 前にも述べたように, これはただの ガイドライン にすぎません. ファイアウォールでどのようなフィルタルールを使用するかは, あなた自身が 決めなければなりません. これまでのアドバイスにしたがったにも関わらず, 誰かがあなたのネットワークに 侵入してきたとしても, わたしたちは「いかなる」責任もとることはできません. OpenSSL FreeBSD 4.0 では, OpenSSL ツールキットが基本構成の一部に 含まれています. OpenSSL は, Secure Sockets Layer v2/v3 (SSLv2/SSLv3) や Transport Layer Security v1 (TLSv1) ネットワークセキュリティプロトコルと同様の 多目的な暗号化ライブラリを提供します. しかしながら, OpenSSL に含まれるアルゴリズムのひとつ (特に IDEA) は, 合衆国内, その他の地域において, 特許により保護されています. そのため, 無制約な利用は許されません. IDEA は FreeBSD の OpenSSL 配布に含まれていますが, デフォルトではコンパ イルされません. もし IDEA を使いたいなら, そしてあなたがそのライ センス条項に合致するなら, /etc/make.conf の中の MAKE_IDEA スイッ チを有効にして, 'make world' でソースをリビルドしてください. 現在は RSA アルゴリズムはアメリカとその他の国で自由に利用で きます. 以前は特許により保護されていました. ソースコードのインストール OpenSSL は src-crypto と src-secure cvsup コレクションの一部です. FreeBSD のソースコードの取得と更新の詳細は, FreeBSD の入手の項を参照して下さい. IPsec 原作: &a.shin;, 5 March 2000. 訳: &a.jp.hino;, 14 March 2001. IPsec 機構は, IP 層とソケット層の両方に対して安全な通 信を提供します. 実装の詳細に関しては The Developers' Handbook を参照してください. 現在の IPsec の実装は, トランスポートモードとトンネルモード の両方をサポートしています. しかし, トンネルモードにはいくつかの 制限事項があります. http://www.kame.net/newsletter/ にはより総合的な例が載っています. ここで述べる機能を利用するには, 以下のオプションをカーネルコ ンパイル時に指定する必要があることにご注意ください. options IPSEC #IP security options IPSEC_ESP #IP security (crypto; define w/IPSEC) IPv4 におけるトランスポートモードの例 ホスト A (10.2.3.4) とホスト B (10.6.7.8) との間に安全なチャ ネルを配置するために, セキュリティアソシエーションを設定しましょ う. ここでは, 少し込み入った例を示します. ホスト A からホストB へは old AH のみを使います. ホスト B からホスト A へは new AH と new ESP を組み合わせます. ここで "AH"/"new AH"/"ESP"/"new ESP" に対応するアルゴリズ ムを決めないといけません. アルゴリズムの名前を知るには, &man.setkey.8; マニュアルページをご覧ください. ここでは, AH に MD5 を, new AH には new-HMAC-SHA1 を, new ESP には 8 バイト IV の new-DES-expIV を選びました. 鍵長はそれぞれのアルゴリズムに大きく依存します. たとえば, MD5 では鍵長は 16 バイトでなければなりませんし, new-HMAC-SHA1 では 20 バイトでなければなりませんし, new-DES-expIV では 8 バ イトでなければなりません. ここではそれぞれ "MYSECRETMYSECRET", "KAMEKAMEKAMEKAMEKAME", "PASSWORD", とします. 次に, それぞれのプロトコルに対して SPI (セキュリティパラメー タインデックス: Security Parameter Index) を割り当てます. 三種 類のセキュリティヘッダ (ホスト A からホスト B に一つ, ホスト B から ホスト A に二つ) を生成するので, この安全なチャネルには三 つの SPI が必要になることに注意してください. さらに, SPI は 256 以上である必要があることにも注意してください. ここではそれ ぞれ 1000, 2000, 3000 を割り当てます. (1) ホスト A ------> ホスト B (1)PROTO=AH ALG=MD5(RFC1826) KEY=MYSECRETMYSECRET SPI=1000 (2.1) ホスト A <------ ホスト B <------ (2.2) (2.1) PROTO=AH ALG=new-HMAC-SHA1(new AH) KEY=KAMEKAMEKAMEKAMEKAME SPI=2000 (2.2) PROTO=ESP ALG=new-DES-expIV(new ESP) IV length = 8 KEY=PASSWORD SPI=3000 次に, セキュリティアソシエーションを設定しましょう. ホスト A とホスト B の両方で, &man.setkey.8; を実行します: &prompt.root; setkey -c add 10.2.3.4 10.6.7.8 ah-old 1000 -m transport -A keyed-md5 "MYSECRETMYSECRET" ; add 10.6.7.8 10.2.3.4 ah 2000 -m transport -A hmac-sha1 "KAMEKAMEKAMEKAMEKAME" ; add 10.6.7.8 10.2.3.4 esp 3000 -m transport -E des-cbc "PASSWORD" ; ^D 実際には, セキュリティポリシのエントリが定義されるまでは IPsec による通信は行われません. この例の場合, 両方のホストを設 定する必要があります. A で: &prompt.root; setkey -c spdadd 10.2.3.4 10.6.7.8 any -P out ipsec ah/transport/10.2.3.4-10.6.7.8/require ; ^D B で: &prompt.root; setkey -c spdadd 10.6.7.8 10.2.3.4 any -P out ipsec esp/transport/10.6.7.8-10.2.3.4/require ; spdadd 10.6.7.8 10.2.3.4 any -P out ipsec ah/transport/10.6.7.8-10.2.3.4/require ; ^D ホスト A -------------------------------------> ホスト B 10.2.3.4 10.6.7.8 | | ========== old AH keyed-md5 ==========> <========= new AH hmac-sha1 =========== <========= new ESP des-cbc ============ IPv6 におけるトランスポートモードの例 IPv6 を使ったもう一つの例. ホスト-A とホスト-B 間の TCP ポート番号 110 番の通信には, ESP トランスポートモードが推奨されます. ============ ESP ============ | | ホスト-A ホスト-B fec0::10 -------------------- fec0::11 暗号化アルゴリズムは blowfish-cbc で, その鍵は "kamekame", 認証アルゴリズムは hmac-sha1 で, その鍵は "this is the test key" とします. ホスト-A の設定: &prompt.root; setkey -c <<EOF spdadd fec0::10[any] fec0::11[110] tcp -P out ipsec esp/transport/fec0::10-fec0::11/use ; spdadd fec0::11[110] fec0::10[any] tcp -P in ipsec esp/transport/fec0::11-fec0::10/use ; add fec0::10 fec0::11 esp 0x10001 -m transport -E blowfish-cbc "kamekame" -A hmac-sha1 "this is the test key" ; add fec0::11 fec0::10 esp 0x10002 -m transport -E blowfish-cbc "kamekame" -A hmac-sha1 "this is the test key" ; EOF そしてホスト-B の設定: &prompt.root; setkey -c <<EOF spdadd fec0::11[110] fec0::10[any] tcp -P out ipsec esp/transport/fec0::11-fec0::10/use ; spdadd fec0::10[any] fec0::11[110] tcp -P in ipsec esp/transport/fec0::10-fec0::11/use ; add fec0::10 fec0::11 esp 0x10001 -m transport -E blowfish-cbc "kamekame" -A hmac-sha1 "this is the test key" ; add fec0::11 fec0::10 esp 0x10002 -m transport -E blowfish-cbc "kamekame" -A hmac-sha1 "this is the test key" ; EOF SP の方向に注意してください. IPv4 におけるトンネルモードの例 二台のセキュリティゲートウェイ間のトンネルモード セキュリティプロトコルは old AH トンネルモード, すなわち RFC1826 で指定されるものです. 認証アルゴリズムは "this is the test" を鍵とする keyed-md5 です. ======= AH ======= | | ネットワーク-A ゲートウェイ-A ゲートウェイ-B ネットワーク-B 10.0.1.0/24 ---- 172.16.0.1 ----- 172.16.0.2 ---- 10.0.2.0/24 ゲートウェイ-A における設定: &prompt.root; setkey -c <<EOF spdadd 10.0.1.0/24 10.0.2.0/24 any -P out ipsec ah/tunnel/172.16.0.1-172.16.0.2/require ; spdadd 10.0.2.0/24 10.0.1.0/24 any -P in ipsec ah/tunnel/172.16.0.2-172.16.0.1/require ; add 172.16.0.1 172.16.0.2 ah-old 0x10003 -m any -A keyed-md5 "this is the test" ; add 172.16.0.2 172.16.0.1 ah-old 0x10004 -m any -A keyed-md5 "this is the test" ; EOF 上記の例のように, もしポート番号フィールドを書かないと, "[any]" と同じ意味になります. `-m' は使用される SA のモードを 指定します. "-m any" はセキュリティプロトコルのモードのワイル ドカードを意味します. この SA をトンネルモードとトランスポート モードの両方で使用できます. そしてゲートウェイ-B では: &prompt.root; setkey -c <<EOF spdadd 10.0.2.0/24 10.0.1.0/24 any -P out ipsec ah/tunnel/172.16.0.2-172.16.0.1/require ; spdadd 10.0.1.0/24 10.0.2.0/24 any -P in ipsec ah/tunnel/172.16.0.1-172.16.0.2/require ; add 172.16.0.1 172.16.0.2 ah-old 0x10003 -m any -A keyed-md5 "this is the test" ; add 172.16.0.2 172.16.0.1 ah-old 0x10004 -m any -A keyed-md5 "this is the test" ; EOF 二台のセキュリティゲートウェイ間の SA の束を作ります ゲートウェイ-A とゲートウェイ-B の間では, AH トランスポー トモードと ESP トンネルモードが要求されます. この例では, ESP ト ンネルモードが先に適用され, 次に AH トランスポートモードが適用さ れます. ========== AH ========= | ======= ESP ===== | | | | | ネットワーク-A ゲートウェイ-A ゲートウェイ-B ネットワーク-B fec0:0:0:1::/64 --- fec0:0:0:1::1 ---- fec0:0:0:2::1 --- fec0:0:0:2::/64 IPv6 におけるトンネルモードの例 暗号化アルゴリズムは 3des-cbc, ESP の認証アルゴリズムは hmac-sha1 とします. AH の認証アルゴリズムは hmac-md5 とします. ゲートウェイ-A での設定は: &prompt.root; setkey -c <<EOF spdadd fec0:0:0:1::/64 fec0:0:0:2::/64 any -P out ipsec esp/tunnel/fec0:0:0:1::1-fec0:0:0:2::1/require ah/transport/fec0:0:0:1::1-fec0:0:0:2::1/require ; spdadd fec0:0:0:2::/64 fec0:0:0:1::/64 any -P in ipsec esp/tunnel/fec0:0:0:2::1-fec0:0:0:1::1/require ah/transport/fec0:0:0:2::1-fec0:0:0:1::1/require ; add fec0:0:0:1::1 fec0:0:0:2::1 esp 0x10001 -m tunnel -E 3des-cbc "kamekame12341234kame1234" -A hmac-sha1 "this is the test key" ; add fec0:0:0:1::1 fec0:0:0:2::1 ah 0x10001 -m transport -A hmac-md5 "this is the test" ; add fec0:0:0:2::1 fec0:0:0:1::1 esp 0x10001 -m tunnel -E 3des-cbc "kamekame12341234kame1234" -A hmac-sha1 "this is the test key" ; add fec0:0:0:2::1 fec0:0:0:1::1 ah 0x10001 -m transport -A hmac-md5 "this is the test" ; EOF 異なる通信端での SA を作る ホスト-A とゲートウェイ-A の間では ESP トンネルモードが要 求されています. 暗号化アルゴリズムは cast128-cbc で, ESP の認 証アルゴリズムは hmac-sha1 です. ホスト-A とホスト-B との間で は ESP トランスポートモードが推奨されています. 暗号化アルゴリ ズムは rc5-cbc で, ESP の認証アルゴリズムは hmac-md5 です. ================== ESP ================= | ======= ESP ======= | | | | | ホスト-A ゲートウェイ-A ホスト-B fec0:0:0:1::1 ---- fec0:0:0:2::1 ---- fec0:0:0:2::2 ホスト-A での設定: &prompt.root; setkey -c <<EOF spdadd fec0:0:0:1::1[any] fec0:0:0:2::2[80] tcp -P out ipsec esp/transport/fec0:0:0:1::1-fec0:0:0:2::2/use esp/tunnel/fec0:0:0:1::1-fec0:0:0:2::1/require ; spdadd fec0:0:0:2::1[80] fec0:0:0:1::1[any] tcp -P in ipsec esp/transport/fec0:0:0:2::2-fec0:0:0:l::1/use esp/tunnel/fec0:0:0:2::1-fec0:0:0:1::1/require ; add fec0:0:0:1::1 fec0:0:0:2::2 esp 0x10001 -m transport -E cast128-cbc "12341234" -A hmac-sha1 "this is the test key" ; add fec0:0:0:1::1 fec0:0:0:2::1 esp 0x10002 -E rc5-cbc "kamekame" -A hmac-md5 "this is the test" ; add fec0:0:0:2::2 fec0:0:0:1::1 esp 0x10003 -m transport -E cast128-cbc "12341234" -A hmac-sha1 "this is the test key" ; add fec0:0:0:2::1 fec0:0:0:1::1 esp 0x10004 -E rc5-cbc "kamekame" -A hmac-md5 "this is the test" ; EOF OpenSSH 原作: &a.chern;, 2001 年 4 月 21 日. セキュアシェル (secure shell) はリモートマシンへのセキュアなアクセスに使われる ネットワーク接続ツールのセットです. それは rlogin, rsh, rcp, telnet を直接置き換えて使うことができます. また, 他のあらゆる TCP/IP 接続を ssh 経由でセキュアにトンネル/フォワードすることもできます. ssh はすべてのトラフィックを暗号化し, 盗聴や接続の乗っ取り等のネットワークレベルの攻撃を事実上無効化します. OpenSSH は OpenBSD プロジェクトによって維持管理されており, SSH v1.2.12 に最新のすべてのバグ修正と更新を適用したものをベースにしています. OpenSSH クライアントは SSH プロトコル 1 と 2 の両方に互換性があります. OpenSSH は FreeBSD 4.0 以降ベースシステムに取り込まれています. OpenSSH を使うことの利点 &man.telnet.1; や &man.rlogin.1; を使う場合, 一般にデータはネットワークを平文で流れます. ネットワークをクライアントとサーバの間のどこかで盗聴することで あなたのユーザ/パスワード情報やセション中を流れるデータを盗むことが可能です. OpenSSH はこれらを予防する為にさまざまな認証と暗号化の方法を提供します. sshd を有効にする rc.conf ファイルに 以下の行を追加してください. sshd_enable="YES" 次に起動したときから ssh デーモンが起動します. もしくは単に sshd デーモンを実行しても構いません. SSH クライアント &man.ssh.1; ユーティリティは &man.rlogin.1; と同様に働きます. &prompt.root ssh user@foobardomain.com Host key not found from the list of known hosts. Are you sure you want to continue connecting (yes/no)? yes Host 'foobardomain.com' added to the list of known hosts. user@foobardomain.com's password: ******* ログインは rlogin や telnet でセションを張った時と同様に続きます. SSH はクライアントが接続した時, サーバの信頼性の検証のために鍵指紋システム (key fingerprint system) を利用します. 初めての接続の際にのみ, ユーザは 'yes' と入力することを要求されます. これ以降の login では保存されていた鍵指紋を照合することで検証されます. SSH クライアントは保存されていた鍵指紋が login しようとした際に送られてきたものと異なっていた場合には警告を表示します. 指紋は ~/.ssh/known_hosts に保存されます. Secure copy scp コマンドが rcp と異なるのは, セキュアになっているという点だけです. つまりローカルのファイルをリモートマシンへ, あるいはリモートマシンのファイルをローカルにコピーします. &prompt.root scp user@foobardomain.com:/COPYRIGHT COPYRIGHT user@foobardomain.com's password: COPYRIGHT 100% |*****************************| 4735 00:00 &prompt.root 前回の例でこのホストの指紋がすでに保存されていれば この scp を使う時に検証が行なわれます. 設定 システム全体の設定ファイルは, OpenSSH デーモン, クライアントの両方とも /etc/ssh ディレクトリにあります. ssh_config はクライアントの動作設定, sshd_config はデーモンの動作設定を行ないます. ssh-keygen パスワードの代わりに &man.ssh-keygen.1; を使って ユーザの認証用の RSA 暗号鍵を作ることができます. &prompt.user ssh-keygen Initializing random number generator... Generating p: .++ (distance 66) Generating q: ..............................++ (distance 498) Computing the keys... Key generation complete. Enter file in which to save the key (/home/user/.ssh/identity): Enter passphrase: Enter the same passphrase again: Your identification has been saved in /home/user/.ssh/identity. ... &man.ssh-keygen.1; は認証に使う為の公開鍵と秘密鍵のペアを作ります. 秘密鍵は ~/.ssh/identity に保存され, 公開鍵は ~/.ssh/identity.pub に保存されます. 公開鍵はリモートマシンの ~/.ssh/authorized_keys にも置かなければなりません. これでパスワードの代わり RSA 認証を使って リモートマシンに接続できるようになったはずです. &man.ssh-keygen.1; でパスフレーズを使っている場合は, ユーザは秘密鍵を使うために毎回パスフレーズの入力を行なう必要があります. &man.ssh-agent.1; と &man.ssh-add.1; は 多重にパスワード化された秘密鍵の管理に使われます. SSH トンネリング OpenSSH は暗号化されたセションの中に他のプロトコルを カプセル化することでトンネルを作ることができます. 以下のコマンドは &man.ssh.1; で telnet 用のトンネルを作成します. &prompt.user; ssh -2 -N -f -L 5023:localhost:23 user@foo.bar.com &prompt.user; -2 は &man.ssh.1; にプロトコル 2 を使うことを指示します. (古い ssh サーバを使っているときには指定しないでください) -N はトンネルだけでコマンドはないことを示します. 省略されると &man.ssh.1; は通常のセッションを開始します. -f は &man.ssh.1; にバックグラウンド実行を強制します. -L はローカルトンネルとして localport:localhost:remoteport 形式を指示します. foo.bar.com はリモート/ターゲットの SSH サーバです. SSH のトンネルは指定されたローカルホストとポートを listen する ソケットを作ることで実現されています. SSH はローカルのホスト/ポートへのすべての接続を SSH 接続経由でリモートマシンの指定されたリモートポートへ 転送 (フォワード) します. たとえば, ローカルホストのポート 5023 がリモートマシンの 23 に転送されるようになっているとします. 23 は telnet なのでこれは SSH トンネルを通るセキュアな telnet セッションを作ります. このようにして smtp や pop3, ftp 等のセキュアではない TCP プロトコルをカプセル化することができます. 典型的な SSH トンネル &prompt.user; ssh -2 -N -f -L 5025:localhost:25 user@mailserver.foobar.com user@mailserver.foobar.com's password: ***** &prompt.user; telnet localhost 5025 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 mailserver.foobar.com ESMTP &man.ssh-keygen.1; と別のユーザアカウントを組み合わせて使うことで より透過的で悩まずに済むような SSH のトンネル環境を作ることができます. パスワードを入力するところで暗号鍵を使い, トンネルは別のユーザ権限で実行することが可能です. さらに知りたい人へ OpenSSH &man.ssh.1; &man.scp.1; &man.ssh-keygen.1; &man.ssh-agent.1; &man.ssh-add.1; &man.sshd.8; &man.sftp-server.8;