diff --git a/ja_JP.eucJP/books/handbook/bibliography/chapter.sgml b/ja_JP.eucJP/books/handbook/bibliography/chapter.sgml index c83a2cfe0d..192df27921 100644 --- a/ja_JP.eucJP/books/handbook/bibliography/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/bibliography/chapter.sgml @@ -1,754 +1,754 @@ 参考図書 訳: &a.jp.nakai;, 1996 年 10 月 12 日。 FreeBSD オペレーティングシステムの個々の部分については マニュアルページで定義のような説明がなされていますが, それらにはどうやってその部分どうしをつなぎあわせて オペレーティングシステム全体を円滑に動作させるかを 説明していないという欠点がよく指摘されます。 それを補うためには &unix; システム管理についてのよい本や, すぐれた利用者向けのマニュアルが欠かせません。 FreeBSD 専門の書籍および雑誌 非英語文化圏の 書籍 & 雑誌: FreeBSD 入門與應用 (中国語)。 FreeBSD入門キット 98版第二版。 宮嵜忠臣 著。 秀和システム。 ISBN 4-87966-535-5 C3055 2900 円。 FreeBSD入門キット AT互換機版 第二版。 宮嵜忠臣 著。 秀和システム。 ISBN 4-87966-535-5 C3055 2900 円。 ここまでできる FreeBSD パワーガイド。 霜山 滋, 仲道 嘉夫, 山中 右次 著。 秀和システム。 ISBN 4-87966-637-8 2600円。 FreeBSD徹底入門。 あさだ たくや / 天川 修平 / 衛藤 敏寿 / 浜田 直樹 / 細川 達己 / 三田 吉郎 著。 翔泳社。 ISBN 4-88135-473-6 3600 円。 パーソナル UNIX スターターキット FreeBSD。 民田 雅人 / 古場 正行 / 増田 佳泰 / 天池 健 / 宮川 晋 共著。 アスキー。 ISBN 4-7561-1733-3 3000 円。 FreeBSD ハンドブック (日本語版)。 アスキー。 ISBN 4-7561-1580-2 3800 円。 FreeBSD mit Methode (ドイツ語版)。 Computer und Literatur Verlag/Vertrieb Hanser 発行。 1998。 ISBN 3-932311-31-0 FreeBSD 4 - Installieren, Konfigurieren, Administrieren (ドイツ語版), Computer und Literatur Verlag, 2001 年 発行。ISBN 3-932311-88-4。 FreeBSD 5 - Installieren, Konfigurieren, Administrieren (ドイツ語), Computer und Literatur Verlag 発行, 2003 年. ISBN 3-936546-06-1. FreeBSD de Luxe (ドイツ語), Verlag Modere Industrie 発行, - 2003 年。ISBN 3-8266-1343-0 + 2003 年。ISBN 3-8266-1343-0. FreeBSD インストール & 活用マニュアル, 毎日コミュニケーションズ発行。 Onno W Purbo, Dodi Maryanto, Syahrial Hubbany, Widjil Widodo 著 FreeBSD を使ったインターネットサーバの構築 (Building Internet Server with FreeBSD) (インドネシア語), Elex Media Komputindo 発行。 英語の書籍 & 雑誌: Absolute BSD: The Ultimate Guide to FreeBSD, No Starch Press 刊、2002 年。 The Complete FreeBSD, O'Reilly、2003 年。 ISBN: 0596005164 The FreeBSD Corporate Networker's Guide, Addison-Wesley 刊、2000 年。 ISBN: 0201704811 FreeBSD: An Open-Source Operating System for Your Personal Computer、The Bit Tree Press 刊、2001 年。 ISBN: 0971204500 Teach Yourself FreeBSD in 24 Hours, Sams 刊、2002 年。 ISBN: 0672324245 FreeBSD unleashed, Sams 刊、2002 年。 ISBN: 0672324563 FreeBSD: The Complete Reference, McGrawHill 刊、2003 年。 ISBN: 0072224096 利用者向けのガイド Computer Systems Research Group, UC Berkeley. 4.4BSD User's Reference Manual. O'Reilly & Associates, Inc., 1994. ISBN 1-56592-075-9 Computer Systems Research Group, UC Berkeley. 4.4BSD User's Supplementary Documents. O'Reilly & Associates, Inc., 1994. ISBN 1-56592-076-7 UNIX in a Nutshell. O'Reilly & Associates, Inc., 1990. ISBN 093717520X Mui, Linda. What You Need To Know When You Can't Find Your UNIX System Administrator. O'Reilly & Associates, Inc., 1995. ISBN 1-56592-104-6 オハイオ州立大学による UNIX Introductory Course。 オンラインで HTML 版と PostScript 版が利用可能。 FreeBSD 友の会 jpman プロジェクト。 FreeBSD User's Reference Manual (日本語訳)。 毎日コミュニケーションズ , 1998。 ISBN4-8399-0088-4 P3800E。 Edinburgh University による UNIX 環境の初心者向け オンラインガイド。 管理者向けのガイド Albitz, Paul and Liu, Cricket. DNS and BIND, 4th Ed. O'Reilly & Associates, Inc., 2001. ISBN ISBN 1-59600-158-4 (訳注: 邦訳は以下のものが出版されています。 高田 広章 / 小島 育夫 監訳 , 小舘 光正 訳。 DNS & BIND 第 3 版。 オライリー・ジャパン, 1999。 ISBN 4-900900-91-5) Computer Systems Research Group, UC Berkeley. 4.4BSD System Manager's Manual. O'Reilly & Associates, Inc., 1994. ISBN 1-56592-080-5 Costales, Brian, et al. Sendmail, 2nd Ed. O'Reilly & Associates, Inc., 1997. ISBN 1-56592-222-0 (訳注: 邦訳は以下の 2 分冊のものが出版されています。 原著の 3 章までが「システム管理」, 4 章が「リファレンス」 に対応します。 中村 素典 監訳, 鈴木 克彦 訳。 sendmail システム管理 (Volume1)。 オライリー・ジャパン, 1997。 ISBN 4-900900-40-0 中村 素典 監訳, 鈴木 克彦 訳。 sendmail システム管理 (Volume2)。 オライリー・ジャパン, 1998。 ISBN 4-900900-41-9) Frisch, Æleen. Essential System Administration, 2nd Ed. O'Reilly & Associates, Inc., 1995. ISBN 1-56592-127-5 (訳注: 邦訳は以下のものが出版されています。 谷川 哲司 監訳, 黒岩 真吾 / 株式会社ユニテック 訳。 UNIX システム管理入門 改訂版。 オライリー・ジャパン, 1998。 ISBN 4-900900-14-1) Hunt, Craig. TCP/IP Network Administration, 2nd Ed. O'Reilly & Associates, Inc., 1997. ISBN 1-56592-322-7 (訳注: 邦訳は以下のものが出版されています。 村井 純 監訳。 TCP/IP ネットワーク管理 第 2 版。 オライリー・ジャパン, 1998。 ISBN 4-900900-68-0) Nemeth, Evi. UNIX System Administration Handbook. 3rd Ed. Prentice Hall, 2000. ISBN 0-13-020601-6 (訳注: 邦訳は以下のものが出版されています。 井上 尚司 監訳。 UNIX システム管理入門。 ソフトバンク, 1992。 ISBN 4-89052-362-6 原本は第 3 版だが, 訳出は第 1 版のみ) Stern, Hal Managing NFS and NIS O'Reilly & Associates, Inc., 1991. ISBN 0-937175-75-7 (訳注: 邦訳は以下のものが出版されています。 砂原 秀樹 監訳, 倉骨 彰 訳, NFS & NIS。 アスキー, 1992。 ISBN 4-7561-0273-5) FreeBSD 友の会 jpman プロジェクト。 FreeBSD System Administrator's Manual (日本語訳)。 毎日コミュニケーションズ, 1998. ISBN4-8399-0109-0 P3300E. Dreyfus, Emmanuel. Cahiers de l'Admin: BSD (in French), Eyrolles, 2003. ISBN 2-212-11244-0 プログラマ向けのガイド Asente, Paul, Converse, Diana, and Swick, Ralph. X Window System Toolkit. Digital Press, 1998. ISBN 1-55558-178-1 Computer Systems Research Group, UC Berkeley. 4.4BSD Programmer's Reference Manual. O'Reilly & Associates, Inc., 1994. ISBN 1-56592-078-3 Computer Systems Research Group, UC Berkeley. 4.4BSD Programmer's Supplementary Documents. O'Reilly & Associates, Inc., 1994. ISBN 1-56592-079-1 Harbison, Samuel P. and Steele, Guy L. Jr. C: A Reference Manual. 4rd ed. Prentice Hall, 1995. ISBN 0-13-326224-3 (訳注: 邦訳は以下のものが出版されています。 斎藤 信男監訳。 新・詳説C言語リファレンス [H&Sリファレンス]。 ソフトバンク, 1994。 ISBN 4-89052-506-8 原本は第4版だが, 訳出は第3版のみ。) Kernighan, Brian and Dennis M. Ritchie. The C Programming Language.. PTR Prentice Hall, 1988. ISBN 0-13-110362-9 (訳注: 邦訳は以下のものが出版されています。 石田 晴久 訳。 プログラミング言語 C 第2版(訳書訂正版) 共立出版, 1989。 ISBN 4-320-02692-6) Lehey, Greg. Porting UNIX Software. O'Reilly & Associates, Inc., 1995. ISBN 1-56592-126-7 Plauger, P. J. The Standard C Library. Prentice Hall, 1992. ISBN 0-13-131509-9 (訳注: 邦訳は以下のものが出版されています。 福富 寛 / 門倉 明彦 / 清水 恵介 訳。 標準 C ライブラリ ANSI/ISO/JIS C規格. トッパン, 1995。 ISBN 4-8101-8541-9) Spinellis, Diomidis. Code Reading: The Open Source Perspective. Addison-Wesley, 2003. ISBN 0-201-79940-5 Stevens, W. Richard. Advanced Programming in the UNIX Environment. Reading, Mass. : Addison-Wesley, 1992. ISBN 0-201-56317-7 (訳注: 邦訳は以下のものが出版されています。 大木 敦雄 訳。 詳解 UNIX プログラミング。トッパン, 1994。 ISBN 4-89052-524-6) Stevens, W. Richard. UNIX Network Programming. 2nd Ed. PTR Prentice Hall, 1998. ISBN 0-13-949876-1 (訳注: 第 1 版の邦訳は以下のものが出版されています. 篠田 陽一 訳. UNIX ネットワークプログラミング。 トッパン, 1992. ISBN 4-8101-8509-5) 第 2 版の邦訳は以下のものが出版されています。 篠田 陽一 訳. UNIX ネットワークプログラミング 第 2 版 Vol.1。 トッパン, 1999。 ISBN 4-8101-8612-1) Wells, Bill. Writing Serial Drivers for UNIX. Dr. Dobb's Journal. 19(15), December 1994. pp68-71, 97-99. オペレーティングシステム内部 Andleigh, Prabhat K. UNIX System Architecture. Prentice-Hall, Inc., 1990. ISBN 0-13-949843-5 Jolitz, William. Porting UNIX to the 386. Dr. Dobb's Journal. January 1991-July 1992. Leffler, Samuel J., Marshall Kirk McKusick, Michael J Karels and John Quarterman The Design and Implementation of the 4.3BSD UNIX Operating System. Reading, Mass. : Addison-Wesley, 1989. ISBN 0-201-06196-1 (訳注: 邦訳は以下のものが出版されています。 中村 明 / 相田 仁 / 計 宇生 / 小池 汎平 訳。 UNIX 4.3BSDの設計と実装。丸善, 1991。 ISBN 4-621-03607-6) Leffler, Samuel J., Marshall Kirk McKusick, The Design and Implementation of the 4.3BSD UNIX Operating System: Answer Book. Reading, Mass. : Addison-Wesley, 1991. ISBN 0-201-54629-9 (訳注: 邦訳は以下のものが出版されています。 相田 仁 / 計 宇生 / 小池 汎平 訳。 UNIX 4.3BSDの設計と実装。 アンサーブック, トッパン, 1991。 ISBN 4-8101-8039-5) 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 (この本の第二章が FreeBSD ドキュメンテーションプロジェクト の一部として オンライン で公開されています. また, 第九章は ここ にあります。) Stevens, W. Richard. TCP/IP Illustrated, Volume 1: The Protocols. Reading, Mass. : Addison-Wesley, 1996. ISBN 0-201-63346-9 Schimmel, Curt. Unix Systems for Modern Architectures. Reading, Mass. : Addison-Wesley, 1994. ISBN 0-201-63338-8 Stevens, W. Richard. TCP/IP Illustrated, Volume 3: TCP for Transactions, HTTP, NNTP and the UNIX Domain Protocols. Reading, Mass. : Addison-Wesley, 1996. ISBN 0-201-63495-3 (訳注: 邦訳は以下のものが出版されています。 中本 幸一 / 石川 裕次 / 田中 伸佳 訳。 詳解 TCP/IP Vol.3: トランザクション TCP, HTTP, NNTP, UNIX ドメインプロトコル, アジソンウェスレイパブリッシャーズジャパン, 1998。 ISBN 4-8101-8039-5) Vahalia, Uresh. UNIX Internals -- The New Frontiers. Prentice Hall, 1996. ISBN 0-13-101908-2 (訳注: 邦訳は以下のものが出版されています。 徳田 英幸 / 中村 明 / 戸辺 義人 / 津田 悦幸 訳。 最前線UNIXのカーネル, ピアソンエデュケーション, 2000。 ISBN 4-89471-189-3) Wright, Gary R. and W. Richard Stevens. TCP/IP Illustrated, Volume 2: The Implementation. Reading, Mass. : Addison-Wesley, 1995. ISBN 0-201-63354-X Messmer, Hans-Peter. The Indispensable PC Hardware Book, 4th Ed. Reading, Mass: Addison-Wesley Pub. Co., 2002. ISBN 0-201-59616-4 セキュリティの参考資料 Cheswick, William R. and Steven M. Bellovin. Firewalls and Internet Security: Repelling the Wily Hacker. Reading, Mass. : Addison-Wesley, 1995. ISBN 0-201-63357-4 (訳注: 邦訳は以下のものが出版されています。 川副 博 監訳。ファイアウォール。 ソフトバンク, 1995。 ISBN 4-89052-672-2) Garfinkel, Simson and Gene Spafford. Practical UNIX & Internet Security. 2nd Ed. O'Reilly & Associates, Inc., 1996. ISBN 1-56592-148-8 (訳注: 邦訳は以下のものが出版されています。 山口 英 監訳. UNIX セキュリティ。 アスキー, 1993。 ISBN 4-7561-0274-3 原本は第 2 版だが, 訳出は第 1 版のみ) Garfinkel, Simson. PGP Pretty Good Privacy O'Reilly & Associates, Inc., 1995. ISBN 1-56592-098-8 ハードウェアの参考資料 Anderson, Don and Tom Shanley. Pentium Processor System Architecture. 2nd Ed. Reading, Mass. : Addison-Wesley, 1995. ISBN 0-201-40992-5 Ferraro, Richard F. Programmer's Guide to the EGA, VGA, and Super VGA Cards. 3rd ed. Reading, Mass. : Addison-Wesley, 1995. ISBN 0-201-62490-7 Intel Corporation は、自社の CPU やチップセットに関する文書を自社の 開発者向け Web サイト で公開しています。文書のフォーマットは通常 PDF です。 Shanley, Tom. 80486 System Architecture. 3rd ed. Reading, Mass. : Addison-Wesley, 1995. ISBN 0-201-40994-1 Shanley, Tom. ISA System Architecture. 3rd ed. Reading, Mass. : Addison-Wesley, 1995. ISBN 0-201-40996-8 Shanley, Tom. PCI System Architecture. 4th ed. Reading, Mass. : Addison-Wesley, 1999. ISBN 0-201-30974-2 Van Gilluwe, Frank. The Undocumented PC, 2nd Ed. Reading, Mass: Addison-Wesley Pub. Co., 1996. ISBN 0-201-47950-8 &unix; の歴史 Lion, John Lion's Commentary on UNIX, 6th Ed. With Source Code. ITP Media Group, 1996. ISBN 1573980137 Raymond, Eric s. The New Hacker's Dictionary, 3rd edition. MIT Press, 1996. ISBN 0-262-68092-0 これは ジャーゴンファイル (Jargon File) として知られています。 Saulus, Peter H. A quarter century of UNIX. Addison-Wesley Publishing Company, Inc., 1994. ISBN 0-201-54777-5 Simon Garfinkel, Daniel Weise, Steven Strassmann. The UNIX-HATERS Handbook. IDG Books Worldwide, Inc., 1994. ISBN 1-56884-203-1 Don Libes, Sandy Ressler Life with UNIX — special edition. Prentice-Hall, Inc., 1989. ISBN 0-13-536657-7 (訳注: 邦訳は以下のものが出版されています。 坂本 文 監訳. Life with UNIX. アスキー, 1990。 ISBN 4-7561-0783-4 邦訳が Special 版の訳出か否かは不明) BSD 系 OS の系譜図。1997 年。 か、 もしくは、最近の FreeBSD マシンにある /usr/share/misc/bsd-family-tree。 BSD リリース告知コレクション。1997 年。 Networked Computer Science Technical Reports Library . Computer Systems Research group (CSRG) からの古い BSD リリース集 : この 4 枚 CD セットには、1BSD から 4.4BSD までと 4.4BSD-Lite2 が含まれます (残念ながら 2.11BSD は含まれていません)。 また 4 枚目の CD には、最終ソースおよび SCCS ファイルが含まれています。 雑誌とジャーナル The C/C++ Users Journal. R&D Publications Inc. ISSN 1075-2838 Sys Admin — The Journal for UNIX System Administrators Miller Freeman, Inc., ISSN 1061-2688 freeX — Das Magazin für Linux - BSD - UNIX (in German) Computer- und Literaturverlag GmbH, ISSN 1436-7033 diff --git a/ja_JP.eucJP/books/handbook/chapters.ent b/ja_JP.eucJP/books/handbook/chapters.ent index d0d5a1fa58..f01bf6b63c 100644 --- a/ja_JP.eucJP/books/handbook/chapters.ent +++ b/ja_JP.eucJP/books/handbook/chapters.ent @@ -1,57 +1,57 @@ diff --git a/ja_JP.eucJP/books/handbook/cutting-edge/chapter.sgml b/ja_JP.eucJP/books/handbook/cutting-edge/chapter.sgml index f877eb37b8..1e3555aae9 100644 --- a/ja_JP.eucJP/books/handbook/cutting-edge/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/cutting-edge/chapter.sgml @@ -1,2064 +1,2064 @@ Jim Mock 再構成、再編成および改訂 Jordan Hubbard 原作 Poul-Henning Kamp John Polstra Nik Clayton 開発の最前線 この章では あるリリースから次のリリースまでの期間にも、 &os; の開発は休みなく続けられています。 この開発の最前線に興味を持っている人のために、 手元のシステムを最新の開発ツリーに同期させておくための、 とても使いやすい仕掛けが何種類も用意されています。 注意: 開発の最前線は、 誰もが扱えるという性質のものではありません! もしもあなたが、開発途中のシステムを追いかけようか、 それともリリースバージョンのどれかを使い続けようかと迷っているのなら、 きっとこの章が参考になるでしょう。 この章を読んで分かるのは: 2つの開発ブランチ、&os.stable; と &os.current; の違い CVSup、 CVS、もしくは CTM を使ったシステム更新方法 make world を使ってベースシステム全体を再構築しインストールする方法 この章を読む前に、以下の準備をしましょう。 ネットワーク接続の適切な設定 () サードパーティ製のソフトウェアのインストール方法の習得 () &os.current; vs. &os.stable; -CURRENT -STABLE FreeBSD には二つの開発ブランチがあります。 それは &os.current; と &os.stable; です。 この章ではそれぞれについて簡単に説明し、 どのようにしてあなたのシステムを対応するツリーに対して、 どうやって常に最新の状態に保つかについて扱います。 まずは &os.current;、次に &os.stable; について説明します。 訳: &a.hanai;、1996 年 11 月 6 日 最新の &os; を追いかける これを読む前に、 心にとめておいて欲しいことがあります。 &os.current; とは &os; の開発の 最前線 だということです。 &os.current; のユーザは高い技術力を持つことが要求され、 自分のシステムが抱える困難な問題を自力で解決できなければなりません。 もし &os; を使い始めたばかりなら、 これを運用することについて十分検討を重ねた方が良いでしょう。 &os.current; ってなに? &os.current; は &os; の最新の、そして作業進行中のソースです。 中には現在開発途上のソフトウェア、 実験的な変更、あるいは過渡的な機能などが含まれています。 また、この中に入っている機能がすべて、 次の公式リリースに入るとは限りません。 &os.current; をソースからほぼ毎日コンパイルしている人は たくさんいますが、 時期によってはコンパイルさえできない状態になっていることもあります。 これらの問題は可能な限り迅速に解決されますが、 &os.current; が不幸をもたらすか、 それとも非常に素晴らしい機能をもたらすかは、 まさにソースコードを手に入れた瞬間によるのです! 誰が &os.current; を必要としてるの? &os.current; は、 次の三つの重要なグループを対象としています。 ソースツリーのある部分に関して活発に作業している &os; グループのメンバ。 彼らにとっては 最新のもの にしておくのが 絶対に必要なことなのです。 活発にテストしている &os; グループのメンバ。 彼らは、&os.current; が 健全である ことを可能な限り保証するために、 種々の問題を解決するのに時間を惜しまない人々です。 彼らはまた、様々な変更に関する提案や &os; の大まかな方向付けを行ないたいと思っている 人々でもあり、それを実装するためのパッチを提示します。 単に、様々な事に目を向け、参考のために (たとえば動かすためではなく読むために) 最新のソースを使いたいと思っている人々。 これらの人々はまた、 時々コメントやコードを寄稿してくれます。 &os.current; に期待しては<emphasis>いけない</emphasis>ことは? なにか新しくカッコイイモノがあると聞き、 自分の周囲では一番にそれを持ちたいがために、 リリース前のコードの断片を追いかけること。 新しい機能を得るために一番乗りになるということは、 新しいバグに最初にぶち当たるということです。 バグを修正するための素早い方法。 いかなるバージョンの &os.current; であれ、 元からあるバグを修正するのと同じく、 新しいバグを生み出すおそれがあります。 公式にサポートする こと。 わたしたちは 3 つの 公式な &os.current; のグループの一つに、 実際に属する人々を助けるのにベストを尽くしますが、 技術的なサポートを行なうには、単に「時間が足りない」のです。 これはわたしたちが外の人を助けるの好まない、 ケチで意地悪い人間だということではありません (もしそうなら &os; なんてやっていません)。 わたしたちは一日に何百通ものメッセージに答え、 かつ &os; の作業をすることなど出来ない! というだけのことなのです。 もし、&os; の改良作業を続けるか、 それとも実験的なコードに関するたくさんの質問に答えるか、 という二つの選択を迫られたら、開発者は前者を選ぶでしょう。 &os.current; を使う &a.current; と &a.cvsall; に加わってください。 これは単に良い考えであるというだけでなく、 必須のことなのです。 もし &a.current; メーリングリストに入っていなければ、 さまざまな人がシステムの現在の状態について 述べているコメントを見ることは決してありませんし、 従って他の人が既に見つけて解決している 多くの問題に戸惑ってあきらめてしまうでしょう。 さらに言うと、システムを正常に保つための 重要な情報を見逃してしまう可能性もあります。 &a.cvsall; メーリングリストでは、 それぞれの変更についての commit ログを見ることができます。 また、それに関して起こり得る副作用の情報を得ることができますので、 参加する価値のあるメーリングリストです。 これらのメーリングリストに入るには、 &a.majordomo; へ subscribe freebsd-current subscribe cvs-all majordomo と書いたメールを送ってください。 オプションとして本文に help と書けば、Majordomo からあなたへ、 わたしたちがサポートする様々なメーリングリストに参加 /脱退する方法に関する詳しいヘルプが送られます。 ftp.FreeBSD.org からのソースの入手。 以下の 3 つの方法で行なうことができます。 cvsup cron -CURRENT CVSup を使った同期 cvsup を この supfile を用いて使用する。 これがもっとも推奨される方法です。 なぜなら、cvsup によって一度全体を入手し、 後は変更されたところだけを入手することができるからです。 たくさんの人が自動的にソースを最新のものに保つために cvsup を cron から起動しています。 上に挙げたサンプル supfile はカスタマイズして、環境に合わせて cvsup を設定する必要があります。 その設定を行なうのにヘルプが必要であれば、単に &prompt.root; pkg_add -f ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/packages/All/cvsupit-3.1.tgz とタイプしてください。 -CURRENT ftp によるダウンロード ftp を使う。 &os.current; のソースツリーは常に ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-current/ で 公開 されています。 全体を compress/tar して入手できる FTP ミラーもあります。 たとえば、 usr.bin/lex があったとすると、 ftp> cd usr.bin ftp> get lex.tar とすることにより、ディレクトリ全体 (この場合、 usr.bin/lex以下全体) を tar ファイルとして入手することができます。 -CURRENT CTM を使った同期 CTMを用いる。 (接続料が高額だったり、email でのアクセスしかできないような) あまり良質でない TCP/IP 接続の場合には、CTM を利用すると良いでしょう。ただし、 これには多くの手間がかかりますし、 壊れたファイルを受けとってしまう可能性もあります。 そのため、最近ではあまり使われなくなっており、 長い間使用できなくなってしまう事態が発生する可能性があります (訳注: 保守する人が少ないためです)。 9600bps 以上の速度で接続しているなら、 CVSup を利用されることを推奨します。 もし、ソースを眺めるだけでなく、 走らせるために入手しているのであれば、 一部だけ選ぶのではなく、&os.current; の全体を手に入れてください。 なぜなら、ソースのさまざまな部分が他の部分の更新に依存しており、 一部のみをコンパイルしようとすると、 ほぼ間違いなくトラブルを起こすからです。 &os.current; をコンパイルする前に /usr/src にある Makefile を良く読んでください。 アップグレードの処理の一部として、 少なくとも一回は最初に make world を行なうべきでしょう。 &a.current; を読めば、 次のリリースへ向けて時々必要になる他のブートストラップの方法に関して、 常に最新情報を得ることが出来ます。 アクティブになってください! もし &os.current; を走らせているなら、わたしたちはそれに関するコメント、 特に拡張やバグ潰しに関する提案を欲しています。 コードを伴う提案はもっとも歓迎されるものです! 安定版の &os; を使う 訳: &a.jp.iwasaki; &os.stable; ってなに? -STABLE &os.stable; とは定期的に公開されるリリースを作成するための開発ブランチです。 このブランチに加えられる変更は原則として、 事前に &os.current; で試験ずみであるという特徴があります。 ただそうであっても、 これは開発用ブランチの一つであるということに注意してください。 つまり、ある時点における &os.stable; のソースが どんな場合にも使えるものであるとは限らないということです。 このブランチはもう一つの開発の流れというだけであって、 エンドユーザ向けのものではありません。 誰が &os.stable; を必要としているの? もしあなたが FreeBSD の開発過程に興味があるとか、 それに対する貢献を考えていて、特にそれが 次回の ポイント リリースに関係するもの であるなら &os.stable; を追うことを考えると良いでしょう。 セキュリティ上の修正は &os.stable; ブランチに対して行なわれますが、 そのために &os.stable; を追う必要はありません。 すべての FreeBSD セキュリティ勧告には 影響のあるリリースで問題点を修正する方法が説明されており これは正確ではありません。 実際わたしたちは何年もの間古いリリースの FreeBSD をサポートしてはいるのですが、 永遠にサポートし続けることはできません。 現時点での古いリリースの FreeBSD のセキュリティポリシーの全説明を知るには、 http://www.FreeBSD.org/security/ を参照してください 、 セキュリティ上の理由のみから開発用ブランチ全体を追いかけることは、 同時に望ましくない変更点まで取り込んでしまう可能性があるからです。 わたしたちは &os.stable; ブランチがいつも安定に動作するように 努めていますが、それが保証されているというわけではありません。 また、コードは &os.stable; に加えられる前に &os.current; で開発されるのですが、&os.stable; のユーザは &os.current; よりも多いため、&os.current; で発見されなかった バグが &os.stable; で発見され、時々それが問題となることがあるのは 避けることができません。 このような理由から、わたしたちは盲目的に &os.stable; を追いかけることを推奨しません。 特に、最初に開発環境でコードを十分に試験せずに プロダクション品質が要求されるサーバを &os.stable; にアップグレードしてはいけません。 もしそうするための資源的な余裕がない場合は、 リリース間のバイナリアップデート機能を利用して、 最新の FreeBSD リリースを使うことを推奨します。 &os.stable; を使う -STABLE 利用する &a.stable; へ加わってください。 このメーリングリストでは、 &os.stable; の構築に関連する事柄や、 その他の注意すべき点 に関する情報が流れています。 また開発者は議論の余地がある修正や変更を考えている場合に、 このメーリングリストで公表し、 提案された変更に関して問題が生じるかどうかを返答する機会をユーザに与えます。 また、&a.cvsall; メーリングリストでは、 それぞれの変更がなされると、 起こりうる副作用に関するすべての適切な情報と一緒に commit log を読むことができます。subscribe しておきたいもう一つのメーリングリストです。 メーリングリストに参加するには、 &a.majordomo; へメッセージの本文に次のように書いたメールを送ってください: subscribe freebsd-stable subscribe cvs-all majordomo オプションとして本文に `help' と書けば、 Majordomo はわたしたちがサポートするさまざまなメーリングリストに参加 / 脱退する方法に関する詳しいヘルプを送付します。 もし、あなたが新しいシステムをインストールしようとしていて それを可能な限り安定なものにしておきたいなら、 最新のブランチの snapshot を ftp://releng4.freebsd.org/pub/FreeBSD から取得し、 これを一般のリリースのものと同様にインストールしてください。 もし、既に &os; の以前のリリースが動いている場合で、 これをソースからアップグレードしようとするならば、 ftp.FreeBSD.org より簡単に これを行う事が出来ます。これには次の 3 つの方法があります。 -STABLE CVSup を使った同期 cvsup を この supfile を用いて使用する。 一度コレクション全体を入手してしまえば前回からの変更部分だけですむので、 もっとも推奨される方法です。 多くの人が cron から cvsup を実行し、 自動的にソースコードを最新の状態に保っています。 これを簡単に扱うには次のようにタイプしてください。
&prompt.root; pkg_add -f ftp://ftp.FreeBSD.org/pub/FreeBSD/development/CVSup/cvsupit.tgz
 -STABLE FTP を使ったダウンロード ftp を使用する。&os.stable; 用のソースツリーは 常に次のところで 公開 されています: ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-stable/ compress/tar でツリー全体を入手できる FTP ミラーもあります。 たとえば: usr.bin/lex に対して: ftp> cd usr.bin ftp> get lex.tar とすることにより、ディレクトリ全体を tar ファイルとして入手することができます。 -STABLE CTM を使って同期する CTM 機能を使います。 インターネットへの接続に高速で安価な回線を利用できないのであれば、 この方法を検討してみましょう。 基本的には、 ソースに迅速でオンデマンドなアクセスが必要で、 接続のバンド幅が問題でなければ、cvsup か ftp を使いましょう。そうで ない場合は CTM を使いましょう。 -STABLE 構築、コンパイル &os.stable; をコンパイルする前に、 /usr/src にある Makefile をよ く読んでください。 少なくとも一回はアップグレードの処理の一部として最初に make world を実行するべきでしょう。&a.stable; を読めば、 次のリリースに移行する に当たって時々必要となる既存システムからの 新システムの構築手順に ついての最新情報が得られるでしょう。 ソースの同期 訳: &a.jp.iwasaki;、1997 年 9 月 13 日 インターネット接続 (または電子メール) を使用して、 あなたの興味の対象によって &os; プロジェクトのソースのある一部分または全体の最新を 追いかける方法は色々あります。 私たちが提供している基本的なサービスは Anonymous CVS、CVSup と CTM です: ソースツリーの一部を最新のものに更新することは可能です。 ただし、サポートされているアップデート手順は、 ソースツリー全体を最新のものに更新して、 ユーザランド (/bin や /sbin にあるような、ユーザが実行するプログラム全体のこと) およびカーネルのソースから再構築することのみであることに注意してください。 カーネルだけ、あるいはユーザランドだけというように、 ソースツリーの一部を更新した場合は、問題が生じることがよくあります。 この時に発生する問題はコンパイル時のエラーからカーネルパニック、 データの破壊とさまざまです。 anonymous CVS Anonymous CVS と CVSup は pull 同期モデルを採用しています。 CVSup の場合、ユーザ (または cron スクリプト) が cvsup 起動し、どこかにある cvsupd サーバとやりとりしてファイルを 最新状態にします。 届けられる更新情報はその時点の最新のものであり、 また必要な時にだけ取り寄せられます。 興味のある特定のファイルやディレクトリに 限定して更新することも簡単にできます。 クライアント側のソースツリーの状態・ 設定ファイルの指定に従い、サーバによって更新情報が 素早く生成されます。 Anonymous CVS は、 このプログラムがリモートの CVS リポジトリから直接変更点を pull できるようにした &man.cvs.1; への拡張であるという点で、 CVSup よりもずっと単純です。 CVSup は効率の点ではるかにまさっていますが、 Anonymous CVS の方が簡単に利用できます。 CTM 一方、CTM はあなたが持っているソースとマスタアーカイブ上に あるそれとの対話的な比較をおこないませんし、 あるいは向こう側から変更点を pull したりもしません。 そのかわりに、前回の実行時からの変更を認識するスクリプトが マスタ CTM マシン上で一日に数回実行され、 すべての変更を compress して通し番号を振り、 さらに電子メールで転送できるようにエンコードします (印字可能な ASCII キャラクタのみです)。受信した後は、 これらの CTM のデルタ は自動 的にデコード、検査してユーザのソースのコピーに変更を適用する &man.ctm.rmail.1; によって処理可能となります。 この処理は CVSup や Anonymous CVS よりずっと効率 的であり、pull モデルというよりむしろ push モデルで あるため、私たちのサーバ資源の負荷は軽くなります。 もちろん他のトレードオフもあります。うっかりアーカイブ の一部を消してしまっても、CVSup は壊れた部分を検出して再構築してくれます。 CTM はこれをやってくれませんし、 Anonymous CVS はおそらく他の何よりも深く混乱してしまうことが多いでしょう。 もしソースツリーの一部を消してしまったら、(最新の CVS ベースデルタ から) 一からやり直し、CTM か anoncvs を使って悪い部分を消去し、再同期させることによって すべてを再構築しなければなりません。 <command>make world</command> の利用 make world FreeBSD のどれか特定のバージョン &os; (&os.stable;、&os.current; など) について、ローカルのソースツリーを同期させたら、 そのソースツリーを使ってシステムを 再構築しなければなりません。 バックアップを作成する システムを再構築する前にバックアップを 作成することの重要性は、いくら強調してもし過ぎると言うことはありません。 システム全体の再構築とは (以降に書かれた手順に従っている限り) 難しい作業ではありませんが、 どんなに注意していたとしても、 あなた自身、あるいはソースツリーで作業している他の人達に手違いがあった時には、 システムが起動しなくなってしまう状態になることがあるのです。 まず、バックアップがきちんと作成されていることを確認して、 fix-it フロッピーを用意してください。 多分、それを使うことはないと思いますが、 あとで後悔することのないよう、念のため用意しておきましょう。 メーリングリストに参加する メーリングリスト もともと、&os.stable; と &os.current; のコードブランチは、 開発中のものです。 &os; の作業に貢献してくださっている人達も人間ですから、 時にはミスをすることだってあるでしょう。 そのような間違いは、単に警告を示す見慣れない 診断メッセージをシステムが、表示するような、 全く害のないものであることもあれば、システムを起動できなくしたり、 ファイルシステムを破壊してしまうような、 恐ろしい結果を招くものかも知れません。 万が一、このような問題が生じた場合、 問題の詳細と、どのようなシステムが影響を受けるかについて書かれた 注意 (heads up) の記事が 適切なメーリングリストに投稿され、そして、その問題が解決されると、 問題解決 (all clear) のアナウンス記事が同様に 投稿されます。 &os.stable; や &os.current; ブランチに追随するために試そうとするのに、 &a.stable; や &a.current; を過去にさかのぼって読まないというのは、 自ら災難を招くことになるでしょう。 訳注: これらのメーリングリストは英語でやりとりされているため、 日本語での投稿は歓迎されません。英語でのやりとりができない人は、 FreeBSD 友の会 の運営しているメーリングリストをあたってみるのがいいでしょう。 <filename>/usr/src/UPDATING</filename> を読む 何を始めるにしろ、まず最初に /usr/src/UPDATING (もしくはあなたがソースコードを どこにコピーしたにせよそれに相当するファイル) を読みましょう。 このファイルにはあなたが遭遇するかも知れない問題に対する重要な情報を 含んでいたり、あなたが特定のコマンドを実行しなければならなくなった時 その順序を指示したりするはずです。 UPDATING があなたが読んだ事柄と矛盾している時は UPDATING が優先します。 UPDATING を読むということは、前述の 適切なメーリングリストを購読する代わりにはなりません。 二つの要求は相補的なもので排他的なものではないのです。 <filename>/etc/make.conf</filename> の確認 make.conf まず、/etc/defaults/make.conf と /etc/make.conf を調べてください。そこには 最初から標準的なものが (多くのものはコメントアウトされていますが) 含まれています。ソースからシステムを再構築するときに make が /etc/make.conf に付け加えられた設定を使用します。 /etc/make.conf に追加された設定は make を実行したときに常に使われることを覚えておいてください。 そのため、システムに必要な設定を書いておくと良いでしょう。 標準的なユーザならおそらく、 /etc/defaults/make.conf の CFLAGS と NOPROFILE のコメントをはずすことを考えると思います。 他の定義 (COPTFLAGS、 NOPORTDOCS など) の定義行についても、 コメントを外す必要があるかどうか調べておきましょう。 <filename>/etc</filename> にあるファイルの更新 /etc ディレクトリには、 システム起動時に実行されるスクリプトだけでなく、 あなたのシステムの設定に関連する情報の大部分が 含まれています。そのディレクトリに含まれる スクリプトは、FreeBSD のバージョンによって多少異なります。 また、設定ファイルのなかには、稼働中のシステムが日々利用している ものもあります。実際には、/etc/group などがそれに該当します。 make world のインストールの段階では、 特定のユーザ名、あるいはグループが存在していることを 要求する場面があります。システムのアップグレードを行なう際には、 それらのユーザ名やグループが削除、あるいは変更されて存在していない可能性が 考えられますが、そういった場合、システムのアップグレードを 行なっている間に、問題が発生する原因になります。 この例で記憶に新しいのは、 smmsp ユーザが追加された時です。 mtree が /var/spool/clientmqueue を作成しようとする時、 そのユーザ名 (およびグループ) が存在しないためにインストールに失敗してしまったのです。 解決方法は、/usr/src/etc/group を調べ、 自分のシステムのグループ名リストと比較することです。 最新のファイルに含まれていて、あなたのファイルに含まれていない グループ名があれば、あなたのファイルにそのグループ名をコピーしてください。 同様に、名前が異なるにも関わらず、 /etc/group と /usr/src/etc/group で同じ GID を持っているグループ名があれば、 /etc/group に含まれる、 該当するすべてのグループ名を変更しておかなければなりません。 4.6-RELEASE からは、buildworld の前に をつけて &man.mergemaster.8; を実行してもよいです。 これを実行すると、buildworld や installworld が成功するために必要なファイルだけを比較します。 古いバージョンの mergemaster を使っていて、 がサポートされていない場合、 最初に実行するときソースツリーにある新しいバージョンのものを使ってください。 &prompt.root; cd /usr/src/usr.sbin/mergemaster &prompt.root; ./mergemaster.sh -p もし、あなたがもっと神経質な人なら、あなたが名前を変更したり、 削除してしまったグループが所有しているファイルを、 次のようにして調べることもできます。 &prompt.root; find / -group GID -print これは GID (グループ名もしくは数字で示されたグループ ID) で 指定されたグループが所有するすべてのファイルを表示します。 シングルユーザモードへの移行 シングルユーザモード コンパイルは、シングルユーザモードで行なった方が良いでしょう。 そうすることで多少速度が向上する、というちょっとした利点が あるだけでなく、システムの再インストールは重要なシステムファイル、 標準コマンド、ライブラリ、インクルードファイルなどを操作します。 稼働中のシステムに (特に他のユーザがそのシステムにログインしている時に) そのような変更を加えることは、トラブルを引き起こす原因となります。 マルチユーザモード もう一つの方法として、マルチユーザモードでシステムを再構築して、 シングルユーザモードに移行してからそれをインストールする、 というのがあります。もしこのような方法で行ないたい場合は、 以下の手順を構築が完了するところまで飛ばしてください。 稼働中のシステムでシングルユーザモードに移行するには、 スーパユーザ (root) 権限で次のコマンドを実行します。 &prompt.root; あるいはシステムを再起動し、ブートプロンプトから フラグを設定することで、シングルユーザモードで システムを起動させることができます。起動後、シェルプロンプトから 次のように実行してください。 &prompt.root; fsck -p &prompt.root; mount -u / &prompt.root; mount -a -t ufs &prompt.root; swapon -a これはファイルシステムをチェックした後、 / を読み書き可能にして再マウント、 /etc/fstab に指定されている、 それ以外の UFS ファイルシステムをすべてマウントしてから スワップを有効にします。 CMOS クロックが地域時間に設定されていて GMT ではない場合、 次のコマンドを実行する必要があるかもしれません。 &prompt.root; adjkerntz -i こうすれば、 確実に地域時刻が正しく設定されます — これを怠ると、 あとあと問題になるかもしれません。 <filename>/usr/obj</filename> の削除 システムが再構築される時、構築されたものは (デフォルトで) /usr/obj 以下のディレクトリに格納され、 そのディレクトリの下は /usr/src と同じ構造となります。 このディレクトリをあらかじめ削除しておくことにより、 make world の行程にかかる時間を短縮させ、 依存問題に悩まされるようなトラブルを回避することができます。 /usr/obj 以下のファイルには、 変更不可 (immutable) フラグ (詳細は &man.chflags.1; 参照) がセットされているものがある可能性があります。 そのため、まず最初にそのフラグを変更しなければなりません。 &prompt.root; cd /usr/obj &prompt.root; chflags -R noschg * &prompt.root; rm -rf * ソースの再構築 出力メッセージの保存 実行される &man.make.1; からの出力は、ファイルに保存すると良いでしょう。 もし、何か障害が発生した場合、エラーメッセージのコピーを手元に残すことができます。 何が悪かったのか、あなた自身がそれから理解することはできないかも 知れませんが、&os; メーリングリストに投稿して、 誰か他の人からの助言を得るために利用することができます。 ファイルに保存する最も簡単な方法は、&man.script.1; コマンドを 使い、引数に出力を保存したいファイル名を指定することです。 これを make world の直前に行ない、再構築が終了してから exit と入力すると、出力を保存することができます。 &prompt.root; script /var/tmp/mw.out Script started, output file is /var/tmp/mw.out &prompt.root; make TARGET … compile, compile, compile … &prompt.root; exit Script done, … 出力を保存する場合、/tmp ディレクトリの中に 保存してはいけません。 このディレクトリは、次の再起動で削除されてしまう可能性があります。 出力の保存には、(上の例のように) /var/tmpや root のホームディレクトリが適しています。 ベースシステムの構築とインストール まず、カレントディレクトリを /usr/src に 変更しなければなりません。次のように実行してください。 &prompt.root; cd /usr/src (もちろん、ソースコードが他のディレクトリにある場合には、 /usr/src ではなく、 ソースコードのあるディレクトリに移動してください)。 make make world を行なうには、&man.make.1; コマンドを使用します。 このコマンドは、Makefile というファイルから、 FreeBSD を構成するプログラムの再構築方法や、 どういう順番でそれらを構築すべきかといったような 指示を読み込みます。 コマンドラインの一般的な書式は、次のとおりです。 &prompt.root; make この例では、 が &man.make.1; に渡されるオプションになります。 どのようなオプションが利用できるかについては、マニュアルページを 参照してください。 は、 Makefile に渡される変数であり、 この変数は Makefile の動作をコントロールします。 また、/etc/make.conf で設定される変数も 同様です。これは変数を設定するもう一つの方法として用意されています。 &prompt.root; make -DNOPROFILE=true target は、プロファイル版のライブラリを構築しないことを指定する もう一つの記法で、/etc/make.conf 中の NOPROFILE= true # Avoid compiling profiled libraries の行に対応します。 target は、&man.make.1; に どのように動作するのかを指示するためのものです。 各々の Makefile には、数多くの異なる ターゲット (target) が定義されていて、 指定されたターゲットによって動作が決まります。 Makefile に書かれているターゲットには、 あなたが指定しても意味を持たないものも含まれます。 これらは、システムの再構築に必要な段階を、多くの さらに細かい段階に分割するため、構築の過程で利用されるものです。 大抵の場合、&man.make.1; にパラメータを指定する必要はないでしょうから、 コマンドラインは次のようなものになるでしょう。 &prompt.root; make target &os; の 2.2.5 から (実際には、&os.current; ブランチで最初に作成され、 2.2.2 と 2.2.5 の間の時点で &os.stable; に導入されたのですが)、 world ターゲットは buildworld と installworld の二つに分割されました。 その名前が示すように、buildworld は /usr/obj 以下に新しい完全な ディレクトリツリーを構築し、 installworld は、そのツリーを 現在のマシンにインストールします。 これは、二つの理由から非常に有用です。 まず第一に、稼働中のシステムに全く影響を与えることなく、 安全にシステムの構築作業を行えることです。 構築作業は 何にも依存せず独立して行なわれる ため、 マルチユーザモードで稼働中のシステムでも、何一つ 悪影響を与えずに buildworld を 実行することができます。 ただし、installworld は シングルユーザモードで行なうことをおすすめします。 第二に、NFS マウントを利用することで、 ネットワーク上の複数のマシンをアップグレードすることが 可能な点があげられます。たとえば三台のマシン、マシン A、マシン B、 マシン C をアップグレードしたい場合には、まず マシン A で make buildworld と make installworld を実行します。 それから、マシン B とマシン C でマシン A の /usr/src と /usr/obj を NFS マウントし、make installworld とすることで 構築済みのシステムを各マシンにインストールすることができるのです。 world ターゲットも利用可能ですが、 このターゲットの利用は推奨されていません。 次のコマンド &prompt.root; make buildworld を実行してください。ここで make に オプションをつけると、 同時にいくつかのプロセスを生成させることができます。 この機能はマルチ CPU マシンで特に効果を発揮します。 構築過程の大部分では CPU 性能の限界より I/O 性能の限界の方が問題となるため、シングル CPU マシンにも効果があります。 普通のシングル CPU マシンで以下のコマンド &prompt.root; make -j4 buildworld を実行すると、&man.make.1; は最大 4 個までのプロセスを同時に実行します。 メーリングリストに投稿された経験的な報告によると、 4 個という指定が最も良いパフォーマンスを示すようです。 もし、複数の CPU を備えたマシンで SMP 設定が行なわれたカーネルを 利用しているなら、6 から 10 の間の値を設定し、速度がどれくらい 向上するか確認してみてください。 ただし、この機能はまだ実験段階であるということに注意してください。 そのため、ソースツリーへ変更が加えられたときに これが正常に機能しなくなる可能性があります。 もし、このオプションを用いてシステムの構築に失敗した場合には、 障害を報告する前に、もう一度オプションを付けずに試してみてください。 - システムの構築にかかる時間 make world 時間 構築時間を決める要素はさまざまありますが、 現時点では Pentium III の 500 MHz、128 MB の RAM という構成で トリックや近道を使わずに普通に構築した場合、 &os.stable; の構築に約 2 時間かかります。 &os.current; の構築は、もう少し時間がかかります。 新しいカーネルの構築とインストール カーネル (kernel) 構築、コンパイル 新しいシステムの全機能を完全に利用できるようにするには、 カーネルの再構築をする必要があります。 再構築は、ある種のメモリ構造体が変更された時には特に必須であり、 &man.ps.1; や &man.top.1; のようなプログラムは、 カーネルとソースコードのバージョンが一致しないと正常に動作しないでしょう。 最も簡単で安全にカーネルの再構築を行なう方法は、 GENERIC を使ったカーネルを構築・インストールすることです。 GENERIC にはあなたが必要とするデバイスがすべて含まれていない かも知れませんが、あなたのシステムをシングルユーザモードで 起動させるのに必要なものはすべて入っています。 これは新しいバージョンのシステムがきちんと動作するかどうか 調べる良い方法の一つです。 GENERIC で起動してから、 あなたがいつも使っているカーネルコンフィグレーションファイルを 使って新しいカーネルを構築することで、 システムが正常に動作しているかどうか確かめることができます。 もし &os; 4.0 以降のシステムにアップグレードする場合、 ( に記載されている) 古いカーネル構築手順はおすすめできません。 代わりに、 buildworld を使ってシステムを構築したあとに、 以下のコマンドを実行してください。 &prompt.root; cd /usr/src &prompt.root; make buildkernel &prompt.root; make installkernel &os; の 4.0 以前にアップグレードする場合は、 古いカーネル構築手順に従う必要があります。 ただし、以下のコマンドを使って新しいバージョンの &man.config.8; を利用することが推奨されています。 &prompt.root; /usr/obj/usr/src/usr.sbin/config/config KERNELNAME シングルユーザモードで再起動する single-user mode 新しいカーネルが動作するかどうかテストするために、 シングルユーザモードで再起動するべきです。 シングルユーザモードでの起動は、 に書かれている手順に従ってください。 新しいシステムバイナリのインストール 十分最近のバージョンの &os; を make buildworld で構築しているなら、 次にここで installworld を 使うことで新しいシステムバイナリのインストールを行ないます。 それには、以下のコマンドを実行してください。 &prompt.root; cd /usr/src &prompt.root; make installworld make buildworld でコマンドラインから 変数を指定した場合は、同じ指定を make installworld のコマンドラインにも 指定しなければなりません。 ただし、オプションについてはその限りではありません。 たとえば は installworld で絶対に使ってはいけません。 たとえば以下のように実行したなら、 &prompt.root; make -DNOPROFILE=true buildworld 以下のようにしてインストールしなければなりません。 &prompt.root; make -DNOPROFILE=true installworld もしそうしなかった場合、 make buildworld の段階で構築されていない プロファイル版ライブラリをインストールしようとしてしまうでしょう。 <command>make world</command> で更新されないファイルの更新 システムの再構築は、いくつかのディレクトリ ( 特に、/etc や /var や /usr) において、 新規に導入されたり、変更された設定ファイルによる ファイルの更新は行なわれません。 これらのファイルを更新するもっとも簡単な方法は、&man.mergemaster.8; を使うことです。これは自分でやることも可能なので、そうしても かまいません。 いずれの方法に従うにせよ、 必ず /etc のバックアップを取って不測の事態に備えてください。 <command>mergemaster</command> mergemaster &man.mergemaster.8; ユーティリティは Bourne シェルスクリプトで、 /etc にある設定ファイルとソースツリーの /usr/src/etc にある設定ファイルの違いを確認するのを手伝ってくれます。 これを使うのが、ソースツリーにある設定ファイルにシステムの設定ファイルを 更新するために推奨される方法です。 mergemaster は 3.3-RELEASE と 3.4-RELEASE の間に FreeBSD のベースシステムに統合されました。 つまり、3.3 以降の -STABLE と -CURRENT のシステムにはすべて これがあるということです。 始めるには、プロンプトから単に mergemaster と入力して、 ファイルの比較を開始するのを見てください。 mergemaster は / を起点とした一時的なルート環境を構築し、 さまざまなシステム設定ファイルを (訳注: デフォルトでは /var/tmp/temproot に) 置いていきます。 次にこれらのファイルは現在システムにインストールされているファイルと比較されます。 この時点で、異なるファイルは &man.diff.1; 形式で示され、 の記号は追加または変更された行を表し、 は完全に削除されたか新しく置き換えられた行を表します。 &man.diff.1; の書式とファイルの違いの表示方法についてのより詳しい情報は、 &man.diff.1; を参照してください。 &man.mergemaster.8; は食い違いが起きているファイルをそれぞれ示します。 ここでは新しいファイル (一時ファイルとして参照されています) を削除するか、 一時ファイルをそのままインストールするか、 一時ファイルと現在インストールされているファイルを統合するか、 もしくは &man.diff.1; の結果をもう一度見るか選択できます。 一時ファイルの削除を選ぶと、&man.mergemaster.8; に現在のファイルを変更しないで新しいバージョンを削除せよと伝えます。 この選択は、現在のファイルを変更する理由が分からないのであれば、 お勧めできません。 mergemaster のプロンプトで とタイプすれば、 いつでもヘルプが見られます。 ファイルのスキップを選ぶと、他のすべてのファイルを終えたあと、 もう一度そのファイルが提示されます。 一時ファイルをそのままインストールすることを選ぶと、 現在のファイルを新しいファイルで置き換えます。 ほとんどの手を加えていないファイルは、 これが一番よい選択です。 ファイルの統合を選んだ場合、 テキストエディタが起動され、両方のファイルの中身が提示されます。 画面上に並ぶ両方のファイルを見て新しいファイルを作成するために両方から必要な部分を選択し、 2 つのファイルを統合することができます。 並んでいるファイルを比較するとき、 キーで左側の中身を選択し、 キーで右側の中身を選択します。 最終出力は左右両方の部分でできたファイルになるでしょう。 このファイルをインストールすることができます。 たいてい、このオプシュンはユーザが設定を変更したファイルに使われます。 diff の結果をもう一度見る、を選択すると、 ちょうど先ほど &man.mergemaster.8; が選択肢を表示する前と同じように、 ファイルの相異点を見ることができます。 &man.mergemaster.8; がシステムファイルの比較を終えたあと、 他のオプションについてもプロンプトが表示されます。 &man.mergemaster.8; パスワードファイルを再構築したいかどうか、 MAKEDEV を実行するかどうかを訊かれることがあります。 最後に残った一時ファイルを削除するかどうかを尋ねて終了します。 手動での更新 手動で更新することを選んだ場合、 単にファイルを /usr/src/etc から /etc に コピーしただけでは正常に動作させることはできません。 これらのファイルには、インストールという 手順を踏まなければならないもの が含まれています。 /usr/src/etc ディレクトリは /etc ディレクトリにそのまま置き換えられるような コピーではないからです。 また、/etc にあるべきファイルのうちで /usr/src/etc にないものもあります。 &man.mergemaster.8; を使っているのであれば (お勧めです)、 次のセクションまで飛ばしてもかまいません。 手動で行う際の 一番簡単な方法は、ファイルを新しいディレクトリにインストールしてから、 以前のものと異なっている部分を調べて更新作業を行なうことです。 既存の <filename>/etc</filename> をバックアップする 理論的に考えて、このディレクトリが自動的に 処理されることはありませんが、念には念を入れておいて 損はありません。たとえば以下のようにして、 既存の /etc ディレクトリを どこか安全な場所にコピーしておきましょう。 &prompt.root; cp -Rp /etc /etc.old は再帰的なコピーを行ない、 はファイルの更新時間や所有者などを保存します。 また、新しい /etc やその他のファイルを インストールするための、仮のディレクトリを作っておく必要があります。 仮ディレクトリは /var/tmp/root に置くのが良いでしょう。 同様に、必要なサブディレクトリもこの下に置きます。 &prompt.root; mkdir /var/tmp/root &prompt.root; cd /usr/src/etc &prompt.root; make DESTDIR=/var/tmp/root distrib-dirs distribution 上の例は、必要なディレクトリ構造をつくり、ファイルをインストールします。 /var/tmp/root 以下に作られる、 たくさんの空のディレクトリは削除する必要があります。 一番簡単なやり方は、次のとおりです。 &prompt.root; cd /var/tmp/root &prompt.root; find -d . -type d | xargs rmdir 2>/dev/null これは空ディレクトリをすべて削除します。 (空でないディレクトリに関する警告を避けるために、 標準エラー出力は /dev/null に リダイレクトされます) この段階の /var/tmp/root には、 本来 / 以下にあるべきファイルが すべて含まれています。 各ファイルを順に見て、既存のファイルと異なる部分を 調べてください。 /var/tmp/root 以下に インストールされているファイルの中には、 . から始まっているものがあります。 これを書いている時点で、それに該当するファイルは /var/tmp/root/ と /var/tmp/root/root/ の中にある シェルスタートアップファイルだけですが、 他のものがあるかも知れません。 (これは、あなたがこれをどの時点で読んでいるかに依存するので、 もっとも簡単な方法は、二つのファイルを比較するコマンド &man.diff.1; を使うことです。 &prompt.root; diff /etc/shells /var/tmp/root/etc/shells これは、あなたの /etc/shells ファイルと 新しい /etc/shells ファイルの 異なる部分を表示します。 これらを、あなたが書き換えたものに変更点をマージするか、 それとも既存のファイルを新しいもので上書きするかを 判断する材料にしてください。 新しい root ディレクトリ (<filename>/var/tmp/root</filename>) の名前に タイムスタンプを付けておくと、 異なるバージョン間の比較を楽に行なうことができます。 頻繁にシステムの再構築を行なうということは、 /etc の更新もまた、頻繁に行う必要がある ということです。これはちょっと手間のかかる作業です。 この作業は、あなたが /etc にマージした、 新しく変更されたファイルの最新のセットのコピーを保存しておくことで 素早く行なうことができます。 下の手順は、それを実現するための一つの方法です。 普通に make world します。/etc や 他のディレクトリを更新したくなったときは、ターゲット ディレクトリに、そのときの日付に基づく名前をつけてください。 たとえば 1998 年 2 月 14 日 だとすれば、以下のようにします。 &prompt.root; mkdir /var/tmp/root-19980214 &prompt.root; cd /usr/src/etc &prompt.root; make DESTDIR=/var/tmp/root-19980214 \ distrib-dirs distribution 上に説明されているように、 このディレクトリから変更点をマージします。 その作業が終了しても、 /var/tmp/root-19980214 を 削除してはいけません。 最新版のソースをダウンロードして再構築したら、 ステップ 1 にしたがってください。今度は、 /var/tmp/root-19980221 (更新作業が一週間おきだった場合) のような名前の、新しいディレクトリをつくることになるでしょう。 この段階で &man.diff.1; を使用し、 二つのディレクトリを比較する再帰的 diff を作成することで、 一週間の間に行なわれたソースへの変更による相違点を調べます。 &prompt.root; cd /var/tmp &prompt.root; diff -r root-19980214 root-19980221 これによって報告される相違点は、大抵の場合、 /var/tmp/root-19980221/etc と /etc との場合に比べて 非常に少ないものになります。 相違点が少ないため、変更点を既存の /etc ディレクトリにマージすることは、比較的容易になります。 ここまで終了したら、/var/tmp/root-* の 二つのうち、古い方のディレクトリは削除して構いません。 &prompt.root; rm -rf /var/tmp/root-19980214 この工程を、/etc へ変更点をマージする 必要があるたび、毎回繰り返します。 ディレクトリ名の生成を自動化するには、&man.date.1; を利用することができます。 &prompt.root; mkdir /var/tmp/root-`date "+%Y%m%d"` <filename>/dev</filename> の更新 DEVFS DEVFS もし DEVFS を利用しているなら、この作業は必要ありません。 ほとんどの場合、&man.mergemaster.8; は デバイスの再構築が必要であることを検出して自動的にそれを実行するのですが、 ここではデバイスの再構築を手動で行なう方法について説明します。 安全のため、これはいくつかの段階に分けて行ないます。 /var/tmp/root/dev/MAKEDEV を /dev にコピーします。 &prompt.root; cp /var/tmp/root/dev/MAKEDEV /dev MAKEDEV /etc を更新するのに &man.mergemaster.8; を使った場合、 MAKEDEV スクリプトは既に更新 されているでしょうが、(&man.diff.1; を使って) チェックすることは無駄ではありませんし、 必要なら自分でコピーしてください。 ここで、/dev のファイル一覧を記録しておきます。 この一覧は、各ファイルの許可属性、所有者、メジャー番号、マイナー番号が 含まれている必要がありますが、タイムスタンプは含まれていてはいけません。 これを行なう簡単な方法は、&man.awk.1; を使って、 いくつかの情報を取り除くことです。 &prompt.root; cd /dev &prompt.root; ls -l | awk '{print $1, $2, $3, $4, $5, $6, $NF}' > /var/tmp/dev.out デバイスファイルをつくり直します。 &prompt.root; もう一度、ディレクトリのファイル一覧を記録します。 今回は /var/tmp/dev2.out です。 この段階で、この二つのファイル一覧を調べて 作成に失敗したデバイスを探してください。 違いは一つもないはずなのですが、安全のために一応チェックしてください。 &prompt.root; diff /var/tmp/dev.out /var/tmp/dev2.out 次のようなコマンドを使用し、ディスクスライスエントリを 再作成することで、ディスクスライスの矛盾を検出することができます。 &prompt.root; sh MAKEDEV sd0s1 適当な組み合わせは、環境によって異なります。 <filename>/stand</filename> の更新 この段階は、完全な更新を行なう場合にだけ必要な内容を含んでいます。 悪影響はありませんので、省略しても構いません。 完全な更新を行なうために、 /stand にあるファイルも同じように 更新したいと考えるかも知れません。 これらのファイルは、/stand/sysinstall という バイナリファイルへのハードリンクです。このバイナリファイルは、 他のファイルシステム (特に /usr) が マウントされていない場合にも動作できるよう、 静的にリンクされていなければなりません。 &prompt.root; cd /usr/src/release/sysinstall &prompt.root; make all install 再起動 これで、作業はおしまいです。 すべてがあるべき正しい場所に存在することをチェックしたら、 システムを再起動します。これは、単に &man.fastboot.8; を実行するだけです。 &prompt.root; fastboot 作業の完了 ここまで来れば、&os; システムのアップグレードは成功です。 おめでとうございます。 もしちょっとした問題があった場合でも、 システムの一部を再構築するのは簡単です。 たとえば、アップグレードの途中で誤って /etc/magic を削除して /etc にマージしてしまい、 その結果 file コマンドが動作しなくなってしまったような場合を考えてみてください。 これを修復するには、次のコマンドを実行すれば修復することができます。 &prompt.root; cd /usr/src/usr.bin/file &prompt.root; 質問ですか? 変更が行なわれたら、その度にシステムの再構築が必要になるのでしょうか? それは変更の性質によるので、なんとも言えません。 たとえば、CVSup を実行したとき、最後に実行したときから比べて 次にあげるようなファイルが更新されていたとします。 src/games/cribbage/instr.c src/games/sail/pl_main.c src/release/sysinstall/config.c src/release/sysinstall/media.c src/share/mk/bsd.port.mk このときには、改めてシステム全体を再構築する必要はないでしょう。 適切なサブディレクトリに移って make all install を行うだけで更新することができます。 しかし、もし何らかの大きな変更が行なわれているとき、たとえば src/lib/libc/stdlib が変更されている場合には、 システム全体を再構築するか、もしくはそのうち、 少なくとも静的にリンクされているもの (と、あなたが追加した 静的にリンクされたプログラム) を作り直す必要があります。 結局のところ、どの時点で現在のシステムをアップグレードするかは あなたが決めることです。 2 週間ごとにシステムを再構築し、その 2 週間の変更を取り込めば 幸せかもしれませんし、 変更のあった部分だけ再構築し、依存関係を確かめたいと考えるかも知れません。 もちろん、それらはどのくらいの頻度でアップグレードしたいか、 そして &os.stable; か &os.current; のどちらを追いかけているのかによります。 signal 11 (もしくは他のシグナル番号) のエラーがたくさん出て コンパイルが失敗します。何が起こっているんでしょうか? signal 11 これは通常、ハードウェアに問題があることを示しています。 システムの再構築は、ハードウェアに対する負荷耐久試験を行なうための 有効な手段の一つで、メモリに関係する問題がよく報告されます。 その大部分は、コンパイラが奇妙なシグナルを受け取り、 不可解な異常終了となることで発見されます。 本当にこの問題によるものかどうかは、再構築をもう一度実行し、 異なる段階で異常終了が発生するか、ということから確認できます。 この場合には、マシンの部品を交換して、どの部分が悪いのかを 調べてみることくらいしかできることはありません。 終了したら /usr/obj を削除しても かまいませんか? 一言で答えるなら「削除しても構わない」です。 /usr/obj には、 コンパイルの段階で生成された すべてのオブジェクトファイルが含まれています。 通常 make world の最初の段階では、 このディレクトリを削除して新しくつくり直すようになっています。 その場合には、構築終了後の /usr/obj を保存しておいても、あまり意味はありません。 削除すれば、大きなディスクスペースを (現在はだいたい 340MB あります) 解放することができます。 しかし、もしあなたが何を行なおうとしているのか理解しているなら、 この段階を省略して make world を行なうことができます。 こうすると、ほとんどのソースは再コンパイルされないため、 構築はかなり高速化されます。 これは裏をかえせば、デリケートな依存関係の問題によって、 システムの構築が奇妙な失敗に終わる可能性があるということです。 &os; メーリングリストではしばしば、構築の失敗が、 この段階の省略によるものだということを理解せずに 不満の声をあげる人がいます。 構築を中断した場合、その構築を途中から再開することはできますか? それは、あなたが問題に気付く前に、 どれだけの作業を終えているかによって変わります。 一般的に (そしてこれは確実でしっかりした 規則ではありませんが)、 make world の過程では、 基本的なツール ( &man.gcc.1; や &man.make.1; のようなもの) や、システムライブラリの新しいコピーが作成されます。 その後まず、これらのツールやライブラリはインストールされてから 自分自身の再構築に使われ、もう一度、インストールされます。 全体のシステム (ここでは &man.ls.1; や &man.grep.1; といった 標準的なユーザプログラムを含みます) は、 その新しいシステムファイルを用いて作り直されることになります。 もし、再構築が最終段階に入っていること が (記録しておいた出力を見たりすることで) わかっていたら、 (全く悪影響を与えることなく) 次のようにすることができます。 … fix the problem … &prompt.root; cd /usr/src &prompt.root; make -DNOCLEAN all これは、前回の make world の作業をやり直しません。 次のメッセージ -------------------------------------------------------------- Building everything.. -------------------------------------------------------------- が make world の出力にある場合には、 上のようにしてもほとんど悪影響が現れることはありません。 もしこのメッセージがないとか、よく分からないという場合には、 安全を確保し、後悔するようなことがないよう、 システムの再構築を最初からやり直しましょう。 どのようにすれば make world を高速化できますか? シングルユーザモードで動かしてください。 /usr/src と /usr/obj ディレクトリを、 異なるディスク上の別のファイルシステムに置いてください。 また可能ならば、異なるディスクコントローラに接続された ディスクを使ってください。 さらに高速化するには、これらのファイルシステムを &man.ccd.4; (連結ディスクドライバ) デバイスを 使って、複数のディスク上に置いてください。 プロファイル版の作成を無効化してください。 (/etc/make.conf で NOPROFILE=true をセットします) 普通、それが必要になることはありません。 また、/etc/make.conf の中の CFLAGS を、 のように指定しましょう。 の最適化はさらに多くの時間を必要とし、 しかも と の 最適化には、ほとんど差はありません。 を指定することで、 コンパイラはテンポラリファイルの代わりにパイプを利用します。 その結果、(メモリの利用は増えますが) ディスクアクセスが減ります。 &man.make.1; に オプションを指定して、 複数のプロセスを並列に実行させてください。 これはプロセッサが単一か複数かによらず、 どちらも同様に恩恵を得ることができます。 /usr/src のある ファイルシステムを、 オプションを付けてマウント (もしくは再マウント) してください。 これは、そのファイルシステムにおいて、 最後にアクセスされた時刻の書き込みを抑制します。 おそらく、この情報が必要になることはないでしょう。 &prompt.root; mount -u -o noatime /usr/src 上の例は、 /usr/src 自身が独立したファイルシステムで あることを想定しています。 もしそうでないときには (たとえば /usr の 一部である場合には)、 /usr/src ではなく 適切なマウントポイントを指定する必要があります。 /usr/obj のあるファイルシステムを、 async オプションをつけてマウント (もしくは 再マウント) してください。これによって、 ディスクへの書き込みが非同期になります。 つまり、書き込み命令はすぐに完了するのに対し、 実際にデータがディスクに書き込まれるのは、その数秒後になります。 これによって、書き込み処理の一括化が可能になるため、 劇的なパフォーマンスの向上が期待できます。 このオプションを指定すると、ファイルシステムは 壊れやすくなってしまうことに注意してください。 このオプションを付けていて、突然電源が落ちた場合には、 再起動後にファイルシステムが復旧不能になる可能性が 非常に高くなります。 もし、/usr/obj 自身が独立した ファイルシステムであるならば、これは問題になりません。 しかし、同じファイルシステムに、他の貴重なデータを置いているときには、 このオプションを有効にする前に、 バックアップをきちんと取っておきましょう。 &prompt.root; mount -u -o async /usr/obj もし /usr/obj 自身が ファイルシステムでない場合には、適切なマウントポイントを指すように、 上の例の名前を置き換えてください。 なにか悪いことがあったらどうすればいいですか? 自分の環境に前のビルドの余計なゴミが残っていないことをはっきりと確認してください。 とても簡単です。 &prompt.root; chflags -R noschg /usr/obj/usr &prompt.root; rm -rf /usr/obj/usr &prompt.root; cd /usr/src &prompt.root; make cleandir &prompt.root; make cleandir ええ、make cleandir は本当に 2 回実行するのです。 そして、make buildworld を行い、 全プロセスを最初からやり直してください。 まだ問題があれば、エラーと uname -a の出力を &a.questions; に送ってください。 自分の設定についてさらに質問されても答えられるよう用意してください! Mike Meyer 複数のマシンで追っかける NFS 複数のマシンにインストール 同じソースツリーを追いかけたいマシンを複数の持っているなら、 全部のマシンにソースをダウンロードして全部再構築するのは資源、 つまりディスクスペース、ネットワーク帯域、そして CPU サイクルの無駄使いに思えます。 実際これは無駄で、解決策は 1 つのマシンに仕事のほとんどをさせ、 残りのマシンは NFS 経由でそれをマウントする、というものです。 このセクションではそのやり方を概観します。 準備 まず初めに、同じバイナリで動かそうとするマシンたちを決めます。 このマシンたちのことをビルドセットと呼びましょう。 それぞれのマシンはカスタムカーネルを持っているかもしれませんが、 同じユーザランドバイナリを動かそうというのです。 このビルドセットから、 ビルドマシンとなるマシンを 1 台選びます。 ベースシステムとカーネルを構築するのはこのマシンになります。 理想的には、このマシンは make world を実行するのに十分な CPU を持った速いマシンであるべきです。 テストマシンとなるべきマシンも選びたいでしょう。 更新されたソフトウェアを使う前にそのマシンでテストするのです。 テストマシンはかなり長い時間落ちていても だいじょうぶなマシンであったほうがいいでしょう。 ビルドマシンでもかまいませんが、ビルドマシンである必要はありません。 このビルドセットのマシンはすべて /usr/obj と /usr/src を同じマシンの同じ場所からマウントする必要があります。 理想的にはビルドマシンの 2 つの違うドライブ上にあるとよいのですが、 ビルドマシンに NFS マウントされていてもかまいません。 ビルドセット自体が複数ある場合は、 /usr/src はひとつのビルドマシン上にあるべきです。 他のマシンからはそれを NFS マウントするようにしましょう。 最後にビルドセットの全てのマシン上の /etc/make.conf がビルドマシンと一致していることを確認してください。 つまり、ビルドマシンはビルドセットのどのマシンもインストールしようとしている ベースシステムを全部ビルドしなければならないということです。 また、各ビルドマシンは /etc/make.conf にそれぞれのビルドマシンのカーネル名を KERNCONF で指定し、 ビルドマシンは自分自身のカーネルから順に全部のカーネル名を KERNCONF にリストアップしてください。 各マシンのカーネルもビルドするのであれば、 ビルドマシンは各マシンのカーネル設定ファイルを /usr/src/sys/arch/conf に持っていなければなりません。 ベースシステム さて、準備は整ったので、ビルドしましょう。 に書いてあるようにカーネルとベースシステムを構築してください。 でも、まだインストールしないでください。 ビルドが終わったら、テストマシンに移り、 ビルドしたばかりのカーネルをインストールしてください。 テストマシンが NFS 経由で /usr/src と /usr/obj をマウントしているなら、 シングルユーザで再起動したときネットワークを使えるようにしてマウントする必要があります。 もっとも簡単な方法は、 マルチユーザモードで起動して、shutdown now を実行してシングルユーザモードに移行することです。 そうしたら、カーネルとベースシステムをインストールし、 いつもするように mergemaster を実行できます。 終わったら、 テストマシンを再起動して通常のマルチユーザ動作に戻します。 テストマシンにあるものすべてがちゃんと動いている確信が得られたら、 同じ手順でビルドセットの他のマシンにも新しいソフトウェアをインストールします。 Ports ports ツリーにも同じアイデアが使えます。 最初に重要な点は、 ビルドセットのすべてのマシンに同じマシンの /usr/ports をマウントすることです。 そして、distfiles を共有するために、 /etc/make.conf を適切に設定します。 NFS マウントによってマップされる root ユーザが何であれ、DISTDIR はそのユーザが書き込める共通の共有ディレクトリに設定する必要があります。 各マシンは WRKDIRPREFIX を自分のマシンのビルドディレクトリに設定しなければなりません。 最後に、パッケージをビルドして配布しようとしているなら、 DISTDIR と同じように PACKAGES ディレクトリも設定してください。 diff --git a/ja_JP.eucJP/books/handbook/linuxemu/chapter.sgml b/ja_JP.eucJP/books/handbook/linuxemu/chapter.sgml index 8b7df4c309..1752e93804 100644 --- a/ja_JP.eucJP/books/handbook/linuxemu/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/linuxemu/chapter.sgml @@ -1,793 +1,793 @@ Linux バイナリ互換機能 オリジナルは Brian N. Handy handy@sxt4.physics.montana.edu と &a.rich; によるものですが、 &a.jim; が 2000 年 3 月 22 日に再構成と一部の更新を行ないました。 訳: &a.jp.kiroh;、1996 年 9 月 24 日 この章では この章では FreeBSD における Linux バイナリとの互換機能について、 インストール方法やその仕組みを解説します。 現時点では、一体なぜ FreeBSD が Linux バイナリを実行できるようにならなければならないのか自問しているのではないでしょうか? 答えはきわめて簡単です。 Linux は現在コンピュータの世界では最もホットなモノなのでたくさんの会社や開発者たちが Linux のためだけに開発を行なっています。そのため、残された私たち FreeBSD ユーザは彼らに対して FreeBSD ネイティブなアプリケーションも出すように言うしかないのです。 問題は、FreeBSD バージョンも出した場合にどれくらいの数のユーザーが使うのかわからない、 ということであり、そのため Linux 版のみを開発しているということなのです。 そこで FreeBSD では Linux バイナリ互換機能が役に立つのです。 簡単に言ってしまえば、この機能により全ての Linux アプリケーションの 90% が修正なしに FreeBSD 上で起動できます。 この中には Star Office や Linux 版の Netscape、Adobe Acrobat、RealPlayer 5 と 7、 VMWare、Oracle、WordPerfect、Doom、Quake などがあります。 また、ある状況においては Linux バイナリを Linux で動かすよりも FreeBSD で動かすほうが良いパフォーマンスが出るという報告もあります。 しかしながら、いくつかの Linux に特有な OS の機能は FreeBSD ではサポートされていません。 例えば、Linux の /proc ファイルシステムを過度に使うような Linux バイナリは FreeBSD では動きません (FreeBSD の /proc ファイルシステムとは異なるのです) し、 仮想 8086 モードを有効にするような i386 特有の呼び出しも動きません。 Linux バイナリ互換モードのインストールに関しては次のセクションをご覧ください。 インストール 3.0-RELEASE以降であればカーネルのコンフィギュレーションファイルに options LINUX や options COMPAT_LINUX といった行を加える必要はありません。 Linux バイナリ互換機能は今は KLD オブジェクト (Kernel LoaDable object) として実現されており、リブートしなくても on-the-fly で組み込むことができるのですが、 /etc/rc.conf に次の行を加える必要があります。 linux_enable=YES この設定により、/etc/rc.i386 では次のような操作が行なわれます。 # Start the Linux binary compatibility if requested. # case ${linux_enable} in [Yy][Ee][Ss]) echo -n ' linux'; linux > /dev/null 2>&1 ;; esac 望みの KLD モジュールがロードされているか確認したい時には kldstat を利用します。 &prompt.user; kldstat Id Refs Address Size Name 1 2 0xc0100000 16bdb8 kernel 7 1 0xc24db000 d000 linux.ko 何らかの理由で Linux KLD をロードしたくない、 あるいはロードできないような場合には、 options LINUX をカーネルの設定ファイルに指定して、 Linux バイナリ互換機能をカーネルにスタティックリンクしてください。 そして、FreeBSD カーネルのコンフィギュレーション の記述にしたがって新しいカーネルをインストールしてください。 Linux ランタイムライブラリのインストール これは、linux_base の port を用いるか、もしくは手動でインストールします。 linux_base の port を用いたインストール ランタイムライブラリをインストールするには最も簡単な方法です。 ports コレクションから他の port をインストールするのと全く同じようにできます。 &prompt.root; cd /usr/ports/emulators/linux_base &prompt.root; make install distclean これで Linux バイナリ互換機能が使えるはずです。 いくつかのプログラムはシステムライブラリのマイナーバージョンが違うと文句を言うかもしれませんが一般的には大した問題ではありません。 手動でのライブラリのインストール ports コレクションをインストールしていない場合、 代わりに手動でライブラリをインストールすることができます。 プログラムが必要とする Linux のシェアードライブラリとランタイムリンカが必要です。 また Linux ライブラリ用の shadow root ディレクトリ、 /compat/linux を作成する必要があります。 FreeBSD で動作する Linux プログラムが使用するシェアードライブラリは、 まずこのファイルツリーから検索されます。例えば、 Linux のプログラムが /lib/libc.so をロードしようとした場合には、FreeBSD はまず /compat/linux/lib/libc.so を開こうとします。これが存在しなかった場合には、次に /lib/libc.so を試します。 シェアードライブラリは、Linux の ld.so が報告するパスではなく、 /compat/linux/lib 以下にインストールする必要があります。 Linux のプログラムが必要とする シェアードライブラリを探す必要があるのは、FreeBSD のシステムに Linux のプログラムをインストールする最初の数回だけでしょう。 それが過ぎれば、十分な Linux のシェアードライブラリがシステムにインストールされ、 新しくインストールした Linux のバイナリも余計な作業をせずに動作させることができるようになります。 シェアードライブラリの追加 linux_base port をインストールした後に、 アプリケーションが必要なライブラリが存在しないというエラーを出したらどうしたらよいでしょうか? Linux のバイナリがどのシェアードライブラリを必要とし、 そしてどこで入手できるか、どのように探したらよいでしょうか? 基本的には、以下の 2 種類の方法があります (以下の手順に従う場合には、 必要なインストール作業をおこなう FreeBSD システム上で root として作業をおこなう必要があります)。 Linux システムにアクセス可能ならば、 そのアプリケーションがどういうシェアードライブラリを必要としているのか調べ、 単に FreeBSD にそのライブラリをコピーするだけです。 次の例を見てみましょう。 FTP を使って Doom の Linux バイナリを取ってきて、 アクセスできる Linux システムに置いたとしましょう。 次のように ldd linuxdoom とするだけでどのシェアードライブラリが必要かチェックできます。 &prompt.user; ldd linuxxdoom libXt.so.3 (DLL Jump 3.1) => /usr/X11/lib/libXt.so.3.1.0 libX11.so.3 (DLL Jump 3.1) => /usr/X11/lib/libX11.so.3.1.0 libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29 最後のカラムに表示されているすべてのファイルを持って来て、 /compat/linux の下に置き、 最初のカラムに示されるファイル名にシンボリックリンクを張ります。 すなわち、FreeBSD システムでは以下のようなファイルが必要となります。 /compat/linux/usr/X11/lib/libXt.so.3.1.0 /compat/linux/usr/X11/lib/libXt.so.3 -> libXt.so.3.1.0 /compat/linux/usr/X11/lib/libX11.so.3.1.0 /compat/linux/usr/X11/lib/libX11.so.3 -> libX11.so.3.1.0 /compat/linux/lib/libc.so.4.6.29 /compat/linux/lib/libc.so.4 -> libc.so.4.6.29
最初のカラムに表示されているファイルとメジャーバージョンが同じ Linux シェアードライブラリを既にインストールしている場合は、 新たにコピーする 必要はありません。 既にあるライブラリで動作するはずです。 ただ、新しいバージョンのものをコピーすることをお奨めします。 新しいライブラリにシンボリックリンクを変更したら、 古いライブラリは削除してかまいません。 /compat/linux/lib/libc.so.4.6.27 /compat/linux/lib/libc.so.4 -> libc.so.4.6.27 従って、以上のようなライブラリがインストールされており、 新しいバイナリに対する ldd の出力が以下のようになる場合を考えます。 libc.so.4 (DLL Jump 4.5pl26) -> libc.so.4.6.29 このように最後の番号が 1 つか 2 つ古いだけならば、普通は /lib/libc.so.4.6.29 をコピーする必要はありません。わずかに古いライブラリでもプログラムは動作するはずだからです。 もちろん、以下のように新しいライブラリと置き換えても構いません。 /compat/linux/lib/libc.so.4.6.29 /compat/linux/lib/libc.so.4 -> libc.so.4.6.29
シンボリックリンクのメカニズムは Linux バイナリにのみ必要なことに注意してください。 FreeBSD のランタイムリンカはメジャーリビジョン番号の一致したライブラリを検索するので、 ユーザが気にする必要はありません。
Linux の ELF バイナリのインストール ELF のバイナリを使うためには、 マークをつける (branding) 作業が必要になります。 マークのない ELF バイナリを実行しようとすると以下のようなエラーメッセージを受けとってしまうことでしょう。 &prompt.user; ./my-linux-elf-binary ELF binary type not known Abort カーネルが FreeBSD の ELF バイナリと Linux のバイナリとを 見分けられるようにするためには、&man.brandelf.1; ユーティリティを以下のようにして使ってください。 &prompt.user; brandelf -t Linux my-linux-elf-binary 今では GNU のツールたちが ELF バイナリに自動的に適切なマークを付加するようになったので、 今後はこの作業もだんだんと必要なくなってゆくでしょう。 ホストネームリゾルバの設定 DNS がうまく動作しなかったり、 以下のようなエラーメッセージが表示され る場合は、/compat/linux/etc/host.conf ファイルを設定する必要があります。 resolv+: "bind" is an invalid keyword resolv+: "hosts" is an invalid keyword ファイルの内容を以下のように設定してください。 order hosts, bind multi on ここで、order は /etc/hosts を最初に検索し、 次に DNS を検索するように指定します。 /compat/linux/etc/host.conf がインストールされていない場合、 Linux アプリケーションは FreeBSD の /etc/host.conf を使用しようとして、 文法の違いによる警告を出力します。 /etc/resolv.conf を利用してネームサーバの設定をしていない場合には、 bind を削除してください。 Mathematica のインストール Mathematica 4.x 用に &a.murray; がアップデートし、Bojan Bistrovic bojanb@physics.odu.edu がマージしました。 この章では、Mathematica 4.X Linux 版の FreeBSD へのインストールについて説明します。 Linux 版の Mathematica は FreeBSD においても完璧に動きます。 ただ、実行する際に Linux ABI を用いる必要があることを FreeBSD に教えるために、Wolfram によって出荷されているバイナリにマーク付け (branded) をする必要があります。 Mathematica や Mathematica for Students の Linux 版は Wolfram (http://www.wolfram.com/) から直接注文することができます。 Linux バイナリへのマーク付け (branding) Linux 用バイナリは Wolfram の Mathematica CD-ROM の Unix ディレクトリにあります。 インストーラーを起動する前にこのディレクトリをローカルディスクにコピーし、 &man.brandelf.1; により Linux バイナリにマークを付けます。 &prompt.root; mount /cdrom &prompt.root; cp -rp /cdrom/Unix/ /localdir/ &prompt.root; brandelf -t Linux /localdir/Files/SystemFiles/Kernel/Binaries/Linux/* &prompt.root; brandelf -t Linux /localdir/Files/SystemFiles/FrontEnd/Binaries/Linux/* &prompt.root; brandelf -t Linux /localdir/Files/SystemFiles/Installation/Binaries/Linux/* &prompt.root; brandelf -t Linux /localdir/Files/SystemFiles/Graphics/Binaries/Linux/* &prompt.root; brandelf -t Linux /localdir/Files/SystemFiles/Converters/Binaries/Linux/* &prompt.root; brandelf -t Linux /localdir/Files/SystemFiles/LicenseManager/Binaries/Linux/mathlm &prompt.root; cd /localdir/Installers/Linux/ &prompt.root; ./MathInstaller また以下のようにすると、マーク付けされていない ELF バイナリすべての扱いを、デフォルトで Linux バイナリとすることが可能です。 &prompt.root; sysctl -w kern.fallback_elf_brand=3 これは FreeBSD システムに対して、 マーク付けされていない ELF バイナリが Linux ABI を利用するように設定します。こうすることで、 CDROM から直接インストーラを実行することが可能になります。 Mathematica パスワードの取得 Mathematica を起動する前に Wolfram から自分の マシン ID に対応したパスワードを取得しなければいけません。 一旦 Linux 互換ランタイムライブラリをインストールし、 Mathematica を展開すれば Install ディレクトリにある mathinfo プログラムを起動して マシン ID を得ることができます。 このマシン ID は、最初に見つかったイーサネットカードの MAC アドレスをベースに生成されます。 &prompt.root; cd /localdir/Files/SystemFiles/Installation/Binaries/Linux &prompt.root; mathinfo disco.example.com 7115-70839-20412 電子メールや電話、FAX などで Wolfram に登録する時にはこの マシン ID を渡します。 するといくつかの数字から構成されるパスワードが返されるので、 他の Mathematica プラットホームでするのと全く同じように最初に Mathematica を立ち上げる時にその情報を入力します。 ネットワーク経由での Mathematica フロントエンドの起動 Mathematica は標準フォントセットにない特別な記号 (積分記号、総和記号、 ギリシャ文字など) を表示するために特殊なフォントを使用します。 X プロトコルは、 これらのフォントがローカルマシンにインストールされていることを要求します。 これはつまり、ローカルマシンに (CD-ROM や Mathematica がインストールされているホストマシンから) そのフォントをコピーしなければならないということです。 これらのフォントは通常、CD-ROM の /cdrom/Unix/Files/SystemFiles/Fonts か、もしくはハードディスクの /usr/local/mathematica/SystemFiles/Fonts に置かれており、実際に使用されるフォントは Type1 と X のサブディレクトリに格納されています。 これらを利用するには次のような二つ方法があります。 一つは、フォントファイルをすべて /usr/X11R6/lib/X11/fonts/ 以下にある既存のフォントディレクトリにコピーする方法です。 この場合、fonts.dir にフォント名を追加し、 先頭行のフォント総数を変更することも必要になります。 あるいは、フォントをコピーしたディレクトリで mkfontdir を実行するだけでもかまいません。 もう一つの方法は、 /usr/X11R6/lib/X11/fonts/ にフォントディレクトリごとコピーする方法です。 &prompt.root; cd /usr/X11R6/lib/X11/fonts &prompt.root; mkdir X &prompt.root; mkdir MathType1 &prompt.root; cd /cdrom/Unix/Files/SystemFiles/Fonts &prompt.root; cp X/* /usr/X11R6/lib/X11/fonts/X &prompt.root; cp Type1/* /usr/X11R6/lib/X11/fonts/MathType1 &prompt.root; cd /usr/X11R6/lib/X11/fonts/X &prompt.root; mkfontdir &prompt.root; cd ../MathType1 -&prompt.root; mkfontdir +&prompt.root; mkfontdir そして、フォントパスに新しいフォントディレクトリを追加します。 &prompt.root; xset fp+ /usr/X11R6/lib/X11/fonts/X &prompt.root; xset fp+ /usr/X11R6/lib/X11/fonts/MathType1 &prompt.root; xset fp rehash XFree86 サーバを使用しているなら、 /etc/XF86Config に加えることでこれらのフォントを自動的に読み込むことができます。 /usr/X11R6/lib/X11/fonts/Type1 という ディレクトリが存在していない場合には、 上記例の MathType1 を Type1 とすることができます。 Oracle のインストール Marcel Moolenaar 寄贈 marcel@cup.hp.com はじめに このドキュメントでは Oracle 8.0.5 と Oracle 8.0.5.1 Enterprise Edition の Linux 版を FreeBSD にインストールするための手順を解説します。 Linux 環境のインストール まずは Ports Collection から linux_base と linux_devtools をインストールしてください。 これらの ports は FreeBSD 3.2 のリリース後にコレクションに加えられました。 もし FreeBSD 3.2 もしくはそれよりも古いものを使っている場合は ports コレクションをアップデートしましょう。ついでに FreeBSD をアップデートするのもいいでしょう。もし linux_base-6.1 や linux_devtools-6.1 でうまくいかなければ 5.2 を試してみてください。 もし賢いエージェント (intelligent agent) を起動したいなら Red Hat TCL パッケージ tcl-8.0.3-20.i386.rpm もインストールする必要があるでしょう。 公式の RPM パッケージをインストールするには一般的に次のようにします。 &prompt.root; rpm -i --ignoreos --root /compat/linux --dbpath /var/lib/rpm package パッケージのインストール時にエラーが出てはいけません。 Oracle 環境の構築 Oracleをインストールする前に、適切な環境を設定する必要があります。 このドキュメントでは、 Oracle のインストールガイドに書いてあるようなことではなく FreeBSD で Linux 用 Oracle を動かすために特別に必要なことのみを解説します。 カーネルのチューニング Oracle インストールガイドにあるように、 シェアードメモリーの最大サイズを設定しなければいけません。 FreeBSD では SHMMAX を使わないようにしてください。 SHMMAX は単に SHMMAXPGS と PGSIZE から計算されるだけなのです。 従って、SHMMAXPGS を使うようにしましょう。 インストールガイドに記述されている他のオプションは使えます。 例えば以下のようにします。 options SHMMAXPGS=10000 options SHMMNI=100 options SHMSEG=10 options SEMMNS=200 options SEMMNI=70 options SEMMSL=61 これらのオプションを意図した Oracle の使い方に合わせて設定してください。 また、 次のオプションがカーネルのコンフィギュレーションファイルにあることも確認します。 options SYSVSHM #SysV shared memory options SYSVSEM #SysV semaphores options SYSVMSG #SysV interprocess communication Oracle 用アカウント 他のアカウントを作るのと同じように Oracle 用のアカウントを作ります。 Oracle 用のアカウントに特別なのは Linux のシェルを割り当てるところだけです。 /etc/shells に /compat/linux/bin/bash を加え、Oracle 用のアカウントに設定します。 環境設定 ORACLE_HOME や ORACLE_SID といった通常の Oracle 用の変数の他に次の変数も設定しなければなりません。 変数 値 LD_LIBRARY_PATH $ORACLE_HOME/lib CLASSPATH $ORACLE_HOME/jdbc/lib/classes111.zip PATH /compat/linux/bin /compat/linux/sbin /compat/linux/usr/bin /compat/linux/usr/sbin /bin /sbin /usr/bin /usr/sbin /usr/local/bin $ORACLE_HOME/bin 全ての環境変数は .profile で設定することをお勧めします。 完璧なサンプルは以下の通りです。 ORACLE_BASE=/oracle; export ORACLE_BASE ORACLE_HOME=/oracle; export ORACLE_HOME LD_LIBRARY_PATH=$ORACLE_HOME/lib export LD_LIBRARY_PATH ORACLE_SID=ORCL; export ORACLE_SID ORACLE_TERM=386x; export ORACLE_TERM CLASSPATH=$ORACLE_HOME/jdbc/lib/classes111.zip export CLASSPATH PATH=/compat/linux/bin:/compat/linux/sbin:/compat/linux/usr/bin:/compat/linux/usr/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:$ORACLE_HOME/bin export PATH Oracle のインストール インストーラーを起動する前に、/var/tmp に .oracle という名前のディレクトリを作る必要がありますが、 これは Linux エミュレーターにおけるちょっとした不整合のためです。 このディレクトリは誰でもが書けるか、もしくは oracle ユーザーのものにしておきます。 これで特に問題なく Oracle がインストールできるでしょう。 もし問題が起こったら、まずは Oracle の配布物や設定をチェックしてください。 Oracle のインストールが終わったら次の二つのサブセクションで解説するパッチを当てます。 よくあるトラブルは、TCP プロトコルアダプターが正しくインストールされていないことです。 そのため、一切 TCP リスナーを起動することができないのです。 次の操作はこの問題を解決するのに役立ちます。 &prompt.root; cd $ORACLE_HOME/network/lib &prompt.root; make -f ins_network.mk ntcontab.o &prompt.root; cd $ORACLE_HOME/lib &prompt.root; ar r libnetwork.a ntcontab.o &prompt.root; cd $ORACLE_HOME/network/lib &prompt.root; make -f ins_network.mk install もう一度 root.sh を起動するのを忘れないように! root.sh へのパッチ Oracle をインストールする時、root で行なう必要のあるいくつかの操作は root.sh と呼ばれるシェルスクリプトに記録されます。 root.sh は orainst ディレクトリにあります。次のパッチを root.sh に当てて 正しい場所にある chown コマンドを使うようにするか、 代わりに Linux ネイティブなシェルのもとでスクリプトを走らせましょう。 *** orainst/root.sh.orig Tue Oct 6 21:57:33 1998 --- orainst/root.sh Mon Dec 28 15:58:53 1998 *************** *** 31,37 **** # This is the default value for CHOWN # It will redefined later in this script for those ports # which have it conditionally defined in ss_install.h ! CHOWN=/bin/chown # # Define variables to be used in this script --- 31,37 ---- # This is the default value for CHOWN # It will redefined later in this script for those ports # which have it conditionally defined in ss_install.h ! CHOWN=/usr/sbin/chown # # Define variables to be used in this script CD-ROM からのインストールでない場合は root.sh のソースにパッチを当ててもいいでしょう。 rthd.sh という名前でソースツリーの orainst というディレクトリにあります。 genclntsh へのパッチ genclntsh スクリプトは一つの共有クライアントライブラリを生成するのに用いられます。 これはデモを作る時に使われます。 PATH の定義をコメントアウトするために次のパッチを当ててください。 *** bin/genclntsh.orig Wed Sep 30 07:37:19 1998 --- bin/genclntsh Tue Dec 22 15:36:49 1998 *************** *** 32,38 **** # # Explicit path to ensure that we're using the correct commands #PATH=/usr/bin:/usr/ccs/bin export PATH ! PATH=/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin export PATH # # each product MUST provide a $PRODUCT/admin/shrept.lst --- 32,38 ---- # # Explicit path to ensure that we're using the correct commands #PATH=/usr/bin:/usr/ccs/bin export PATH ! #PATH=/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin export PATH # # each product MUST provide a $PRODUCT/admin/shrept.lst Oracle の起動 インストラクションに従えば、Linux でと同じように Oracle を起動できるでしょう。 高度なトピックス Linux バイナリ互換機能がどのような仕組みなのか興味がある人はこのセクションを読んでください。 以下の文章で説明されていることのほとんどは &a.chat; に投稿された Terry Lambert (tlambert@primenet.com) 氏のメール (Message ID: <199906020108.SAA07001@usr09.primenet.com>) をもとにしています。 どのように動くのでしょう? FreeBSD は、“実行クラスローダ (execution class loader) ” と呼ばれる抽象的な機構を持っています。これは &man.execve.2 システムコールへの楔という形で実装されています。 FreeBSD は、シェルインタプリタやシェルスクリプトを実行するための #! ローダを持った単一のプログラムローダではなく、 ローダのリストを持っているのです。 歴史的には、UNIX プラットフォーム上の唯一のローダーがマジックナンバー (一般的にはファイルの先頭の 4 ないし 8 バイトの部分) の検査を行ないシステムで実行できるバイナリかどうかを検査し、 もしそうならバイナリローダーを呼び出すというようになっていました。 もし、そのシステム用のバイナリでない場合には、 &man.execve.2; システムコールの呼び出しは失敗の戻り値を返し、 シェルがシェルコマンドとして実行しようと試みていたわけです。 この仮定は現在利用しているシェルがどのようなものであっても変わりません。 後に &man.sh.1; に変更が加えられ、先頭の 2 バイトを検査した結果 :\n であれば代わりに &man.csh.1; を呼び出す、 というようになりました (この変更は SCO が最初に行なったと思われます)。 現在の FreeBSD は、プログラムローダリストを走査します。 その際、空白文字までの文字列をインタプリタとして認識する、 通常の #! ローダを用いるため、 該当するものが存在しなければ最終的に /bin/sh がロードされます。 Linux ABI をサポートするため、FreeBSD は ELF バイナリを示すマジックナンバを確認します。 (ただし、この段階では FreeBSD、Solaris、Linux、そしてその他の ELF イメージ形式を使っている OS を区別することはできません)。 ELF ローダは、特殊なマーク (brand) があるかどうか探します。 このマークとは、ELF イメージのコメントセクションのことです。 SVR4/Solaris の ELF バイナリには、このセクションは存在しません。 Linux バイナリを実行するためには、 ELF バイナリに &man.brandelf.1; で説明されている Linux のマークが付けられていなければなりません。 &prompt.root; brandelf -t Linux file 上のようにすることで、指定されたファイルは Linux のマークが付けられ、 ELF ローダが認識できるようになります。 ELF ローダが Linux マークを確認すると、 ローダは proc 構造体内の ある一つのポインタを置き換えます。システムコールは全て、 このポインタ (伝統的な UNIX システムではこれは構造体の配列 sysent[] で、システムコールが含まれています) を通してインデックスされます。 さらに、そのプロセスには Linux カーネルモジュールに必要な シグナルトランポリンコード (訳注: シグナルの伝播を実現するコード) 用の特殊なトラップベクタの設定や、 他の (細かな) 調整のための設定が行なわれます。 Linux システムコールベクタは、 さまざまなデータに加えて sysent[] エントリーのリストを含んでおり、それらのアドレスはカーネルモジュール内にあります。 Linux バイナリがシステムコールを発行する際、トラップコードは proc 構造体を用いてシステムコール関数ポインタを 解釈します。そして FreeBSD ではなく Linux 用のシステムコールエントリポイントを得るわけです。 さらに、Linux モードは状況に応じてファイルシステム本来のルートマウントポイントを置き換えてファイルの参照を行ないます。 これは、union オプションを指定してマウントされたファイルシステム (unionfs ではありません!)が行なっていることと同じです。 ファイルを検索する際にはまず /compat/linux/original-path ディレクトリを、それから見つけられなかったときにのみ、 /original-path を調べます。 こうすることで、他のバイナリを要求するバイナリの実行を可能にしています (したがって、Linux 用プログラムツールは Linux ABI サポート環境下で完全に動作するわけです)。 またこれは、もし対応する Linux バイナリが存在しない場合に Linux バイナリが FreeBSD バイナリをロードしたり、実行したりすることが可能であること、 その Linux バイナリに自分自身が Linux 上で実行されていないことを 気付かせないようにする目的で、&man.uname.1; コマンドを /compat/linux ディレクトリに置くことができる、 ということを意味します。 要するに、Linux カーネルが FreeBSD カーネルの内部に存在しているわけです。 カーネルによって提供されるサービス全ての実装の基礎となるさまざまな関数は FreeBSD システムコールテーブルエントリと Linux システムコールテーブルエントリの両方で共通に利用されています。 これらにはファイルシステム処理、仮想メモリ処理、シグナル伝送、System V IPC などが含まれますが、 FreeBSD バイナリは FreeBSD グルー (訳注: glue; 二者の間を仲介するという意味) 関数群、 そして Linux バイナリは Linux グルー関数群を用いる、 という点だけが異なります (過去に存在したほとんどの OS は、 自分自身のためのグルー関数群しか備えていません。 前述したように、システムコールを発行する際、 各々のプロセスの proc 構造体内にある、 ローダによって動的に初期化されるポインタを参照してアドレスを得る代わりに、 静的でグローバルな sysent[] 構造体の配列に システムコール関数のアドレスが直接格納されているのです)。 さて、どちらを本来の FreeBSD ABI (訳注: Applications Binary Interface; 同じ CPU を利用したコンピュータ間でバイナリを共有するための規約のこと) と呼ぶべきなのでしょうか? 実は、どちらが本来のものであるかということを論ずることに意味はありません。 基本的に、FreeBSD グルー関数群はカーネルの中に静的にリンクされていて、 Linux グルー関数群は静的にリンクすることも、 カーネルモジュールを介して利用することもできるようになっている、 という違いがあるだけ (ただしこれは現時点においての話であり、 将来のリリースで変更される可能性がありますし、 おそらく実際に変更されるでしょう) です。 あ、「でもこれは本当にエミュレーションと呼べるのか」って? 答えは「いいえ」です。これは ABI の実装であり、 エミュレーションとは異なります。エミュレータが呼び出されているわけではありません (シミュレータでもないことをあらかじめ断っておきましょう)。 では、これがよく Linux エミュレーションと呼ばれるのは何故でしょうか? それはもちろん FreeBSD の売りにするため 8-) でもあるのですが、 実際には、次のような理由によります。 この機能が初めて実装された頃、 動作原理を説明する以外にこの機能を表現する言葉はありませんでした。 しかし、コードをコンパイルしたりモジュールをロードしない場合、 「FreeBSD 上で Linux バイナリを実行する」という表現は、 厳密に考えると適切ではありません。 そこで、その際にロードされているもの自身を表現する言葉 — すなわち Linux エミュレータが必要だったのです。 diff --git a/ja_JP.eucJP/books/handbook/pgpkeys/chapter.sgml b/ja_JP.eucJP/books/handbook/pgpkeys/chapter.sgml index 430118b6f1..b5aac7d794 100644 --- a/ja_JP.eucJP/books/handbook/pgpkeys/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/pgpkeys/chapter.sgml @@ -1,685 +1,700 @@ PGP 公開鍵 pgp公開鍵 これらは、署名を検証したり、 開発者やオフィサに暗号メールを送る必要がある場合に、 自由に使用できる PGP 公開鍵です。また、 http://www.FreeBSD.org/doc/pgpkeyring.txt から FreeBSD.org ユーザの完全なキーリングをダウンロードすることも 可能です。 オフィサ &a.security-officer; &pgpkey.security-officer; &a.core-secretary; &pgpkey.core-secretary; コアチームメンバ &a.imp; &pgpkey.imp; &a.kuriyama; &pgpkey.kuriyama; &a.murray; &pgpkey.murray; &a.peter; &pgpkey.peter; &a.wes; &pgpkey.wes; 開発者 &a.will; &pgpkey.will; &a.mat; &pgpkey.mat; &a.asami; &pgpkey.asami; &a.dougb; &pgpkey.dougb; &a.tobez; &pgpkey.tobez; &a.mbr; &pgpkey.mbr; &a.harti; &pgpkey.harti; &a.obraun; &pgpkey.obraun; &a.jmb; &pgpkey.jmb; &a.brueffer; &pgpkey.brueffer; &a.wilko; &pgpkey.wilko; &a.jon; &pgpkey.jon; &a.luoqi; &pgpkey.luoqi; &a.ache; &pgpkey.ache; &a.seanc; &pgpkey.seanc; &a.cjh; &pgpkey.cjh; &a.cjc; &pgpkey.cjc; &a.marcus; &pgpkey.marcus; &a.nik; &pgpkey.nik; &a.ceri; &pgpkey.ceri; &a.brooks; &pgpkey.brooks; &a.bsd; &pgpkey.bsd; &a.dd; &pgpkey.dd; &a.ue; &pgpkey.ue; &a.ru; &pgpkey.ru; &a.jedgar; &pgpkey.jedgar; &a.green; &pgpkey.green; &a.lioux; &pgpkey.lioux; &a.fanf; &pgpkey.fanf; &a.blackend; &pgpkey.blackend; &a.petef; &pgpkey.petef; &a.billf; &pgpkey.billf; &a.patrick; &pgpkey.patrick; &a.gioria; &pgpkey.gioria; &a.jmg; &pgpkey.jmg; &a.dannyboy; &pgpkey.dannyboy; &a.jhay; &pgpkey.jhay; &a.sheldonh; &pgpkey.sheldonh; &a.mikeh; &pgpkey.mikeh; &a.ghelmer; &pgpkey.ghelmer; &a.mux; &pgpkey.mux; &a.mich; &pgpkey.mich; &a.foxfair; &pgpkey.foxfair; &a.jkh; &pgpkey.jkh; &a.trevor; &pgpkey.trevor; &a.phk; &pgpkey.phk; &a.joe; &pgpkey.joe; &a.kris; &pgpkey.kris; &a.keramida; &pgpkey.keramida; &a.fjoe; &pgpkey.fjoe; &a.andreas; &pgpkey.andreas; + + &a.sergei; + &pgpkey.sergei; + + &a.maxim; &pgpkey.maxim; &a.jkoshy; &pgpkey.jkoshy; &a.rushani; &pgpkey.rushani; &a.alex; &pgpkey.alex; &a.erwin; &pgpkey.erwin; &a.leeym; &pgpkey.leeym; &a.netchild; &pgpkey.netchild; &a.ijliao; &pgpkey.ijliao; &a.clive; &pgpkey.clive; &a.arved; &pgpkey.arved; &a.scottl; &pgpkey.scottl; + + &a.pav; + &pgpkey.pav; + + &a.bmah; &pgpkey.bmah; &a.mtm; &pgpkey.mtm; &a.dwmalone; &pgpkey.dwmalone; &a.matusita; &pgpkey.matusita; &a.ken; &pgpkey.ken; &a.dinoex; &pgpkey.dinoex; &a.sanpei; &pgpkey.sanpei; &a.jim; &pgpkey.jim; &a.marcel; &pgpkey.marcel; &a.tmm; &pgpkey.tmm; &a.rich; &pgpkey.rich; &a.knu; &pgpkey.knu; &a.max; &pgpkey.max; &a.yoichi; &pgpkey.yoichi; &a.bland; &pgpkey.bland; &a.simon; &pgpkey.simon; &a.anders; &pgpkey.anders; &a.obrien; &pgpkey.obrien; &a.mp; &pgpkey.mp; &a.roam; &pgpkey.roam; &a.den; &pgpkey.den; &a.pirzyk; &pgpkey.pirzyk; &a.jdp; &pgpkey.jdp; &a.krion; &pgpkey.krion; &a.markp; &pgpkey.markp; &a.thomas; &pgpkey.thomas; &a.dfr; &pgpkey.dfr; &a.trhodes; &pgpkey.trhodes; &a.benno; &pgpkey.benno; &a.paul; &pgpkey.paul; &a.roberto; &pgpkey.roberto; &a.guido; &pgpkey.guido; &a.hrs; &pgpkey.hrs; &a.wosch; &pgpkey.wosch; &a.das; &pgpkey.das; &a.schweikh; &pgpkey.schweikh; &a.gshapiro; &pgpkey.gshapiro; &a.arun; &pgpkey.arun; &a.vanilla; &pgpkey.vanilla; &a.cshumway; &pgpkey.cshumway; &a.demon; &pgpkey.demon; &a.jesper; &pgpkey.jesper; &a.scop; &pgpkey.scop; + + &a.kensmith; + &pgpkey.kensmith; + + &a.ben; &pgpkey.ben; &a.des; &pgpkey.des; &a.sobomax; &pgpkey.sobomax; &a.dcs; &pgpkey.dcs; &a.brian; &pgpkey.brian; &a.nsouch; &pgpkey.nsouch; &a.gsutter; &pgpkey.gsutter; &a.nyan; &pgpkey.nyan; &a.mi; &pgpkey.mi; &a.gordon; &pgpkey.gordon; &a.nectar; &pgpkey.nectar; &a.adamw; &pgpkey.adamw; &a.nate; &pgpkey.nate; &a.wollman; &pgpkey.wollman; &a.joerg; &pgpkey.joerg; &a.phantom; &pgpkey.phantom;