diff --git a/ja/handbook/authors.sgml b/ja/handbook/authors.sgml index e5f2e90e6b..f62b8ffc18 100644 --- a/ja/handbook/authors.sgml +++ b/ja/handbook/authors.sgml @@ -1,421 +1,421 @@ - + "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> diff --git a/ja/handbook/basics.sgml b/ja/handbook/basics.sgml index 09eb64cb21..878cea4ff3 100644 --- a/ja/handbook/basics.sgml +++ b/ja/handbook/basics.sgml @@ -1,93 +1,93 @@ - + Unix の基礎知識

訳: &a.nakai;12 October 1996. オンラインマニュアル

FreeBSD についてのもっとも包括的なドキュメントは マニュアルページの形式になっているものです. FreeBSD システム上のほとんどすべてのプログラムには基本的な 操作方法とさまざまな引数を説明しているリファレンスマニュアル がついています。これらのマニュアルは man コマンドで見ることができます。 man コマンドの使い方は簡単です : man コマンド名 コマンド名のところには知りたいコマンドの名前を入れます。 たとえば、ls コマンドについて知りたい場合には 次のように入力します : % man ls

オンラインマニュアルは数字のついたセクションに分けられています : ユーザコマンド システムコールとエラー番号 C のライブラリ関数 デバイスドライバ ファイル形式 ゲームとほかのお楽しみ そのほかの情報 システムの管理と操作のためのコマンド 場合によっては, 同じことがらでもオンラインマニュアルでは 複数のセクションに記載されていることがあります。たとえば、 chmod ユーザコマンドと chmod() システムコールがあります。この場合、man コマンドでどちらを参照したいかをセクションで指定することが できます : % man 1 chmod とすればユーザコマンドとしての chmod のマニュアルページが表示されます。オンラインマニュアル上の特定の セクションへの参照は通常、書かれているドキュメントの 括弧の中に示されています。ですから、chmod(1) は chmod ユーザコマンドを、 chmod(2) はシステムコールの方を示しています。

コマンドの名前を知っていて, 単純にその使い方が分かる場合は よいのですが、もしコマンドの名前を思い出せない場合には どうしたらいいのでしょう? man に -k スイッチをつければ, コマンドデスクリプション中のキーワードから検索することができます : % man -k mail このコマンドを使うことで, 「mail」というキーワードを含むコマンドの 一覧を参照することができます。実を言うと apropos コマンドを使うのと機能的には同じです。

それから、/usr/bin にある優れたコマンドすべてを目にしても、 それらの大半がどういった働きをするのかまったく見当もつかないときは どうしたらよいでしょう。単純に、 % cd /usr/bin; man -f * あるいは同じ働きをする % cd /usr/bin; whatis * としましょう。 GNU の Info ファイル

FreeBSD には Free Software Foundation (FSF) によるアプリケーションや ユーティリティがたくさんあります。こうしたプログラムには manページに加えて、info ファイルと呼ばれる ハイパーテキスト形式のドキュメントが付属になっていて、info コマンドや、emacs をインストールしているなら emacs の info モードで見ることができます。 info(1) コマンドを使うには, 単にこう入力します。 % info おおまかなイントロダクションを 見るには、h と入力します。 クイックコマンドリファレンスは ? とします。 diff --git a/ja/handbook/bibliography.sgml b/ja/handbook/bibliography.sgml index c6269ebe0a..8b49f0e7a3 100644 --- a/ja/handbook/bibliography.sgml +++ b/ja/handbook/bibliography.sgml @@ -1,265 +1,265 @@ - + 参考図書

訳: &a.nakai;12 October 1996.

FreeBSD オペレーティングシステムの個々の部分については マニュアルページで定義のような説明がなされていますが, それらにはどうやってその部分どうしをつなぎあわせて オペレーティングシステム全体を円滑に動作させるかを 説明していないという欠点がよく指摘されます. それを補うためには UNIX システム管理についてのよい本や, すぐれた利用者向けのマニュアルが欠かせません. 利用者向けのガイド

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 has written a which is available online in HTML and postscript format. 管理者向けのガイド

Albitz, Paul and Liu, Cricket. DNS and BIND. O'Reilly & Associates, Inc., 1993. ISBN 1-56592-010-4 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. O'Reilly & Associates, Inc., 1993. ISBN 1-56592-056-2 Frisch, Æleen. Essential System Administration. O'Reilly & Associates, Inc., 1993. ISBN 0-937175-80-3 Hunt, Craig. TCP/IP Network Administration. O'Reilly & Associates, Inc., 1992. ISBN 0-937175-82-X Nemeth, Evi. UNIX System Administration Handbook. 2nd ed. Prentice Hall, 1995. ISBN 0131510517 プログラマ向けのガイド

Asente, Paul. X Window System Toolkit. Digital Press. ISBN 1-55558-051-3 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 Ellis, Margaret A. and Stroustrup, Bjarne. The Annotated C++ Reference Manual. Addison-Wesley, 1990. ISBN 0-201-51459-1 Harbison, Samuel P. and Steele, Guy L. Jr. C: A Reference Manual. 4rd ed. Prentice Hall, 1995. ISBN 0-13-326224-3 Kernighan, Brian and Dennis M. Ritchie. The C Programming Language.. PTR Prentice Hall, 1988. ISBN 0-13-110362-9 Plauger, P. J. The Standard C Library. Prentice Hall, 1992. ISBN 0-13-131509-9 Stevens, W. Richard. Advanced Programming in the UNIX Environment. Reading, Mass. : Addison-Wesley, 1992 ISBN 0-201-56317-7 Stevens, W. Richard. UNIX Network Programming. PTR Prentice Hall, 1990. ISBN 0-13-949876-1 Wells, Bill. "Writing Serial Drivers for UNIX". Dr. Dobb's Journal. 19(15), December 1994. pp68-71, 97-99. オペレーティングシステム内部

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 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 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 Stevens, W. Richard. TCP/IP Illustrated, Volume 1: The Protocols. Reading, Mass. : Addison-Wesley, 1996. ISBN 0-201-63346-9 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 Wright, Gary R. and W. Richard Stevens. TCP/IP Illustrated, Volume 2: The Implementation. Reading, Mass. : Addison-Wesley, 1995. ISBN 0-201-63354-X セキュリティの参考資料

Cheswick, William R. and Steven M. Bellovin. Firewalls and Internal Security: Repelling the Wily Hacker. Reading, Mass. : Addison-Wesley, 1995. ISBN 1-201-63357-4 Garfinkel, Simson and Gene Spafford. Practical UNIX Security. 2nd Ed. O'Reilly & Associates, Inc., 1996. ISBN 1-56592-148-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 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. 3rd ed. Reading, Mass. : Addison-Wesley, 1995. ISBN 0-201-40993-3 Van Gilluwe, Frank. The Undocumented PC. Reading, Mass: Addison-Wesley Pub. Co., 1994. ISBN 0-201-62277-7 UNIX の歴史

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 雑誌とジャーナル

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 diff --git a/ja/handbook/boothelp.sgml b/ja/handbook/boothelp.sgml index 4f0a349065..3b445ef7a0 100644 --- a/ja/handbook/boothelp.sgml +++ b/ja/handbook/boothelp.sgml @@ -1,51 +1,51 @@ - + %authors; %sections; ]> FreeBSD のインストール <author> <name></name> </author> <abstract>FreeBSD の世界へようこそ! このガイドは FreeBSD の インストール方法について説明しています. 矢印キーの<bf>上</bf>と<bf>下</bf>を使って このガイドの読みたいセクションに移動し, <bf>右矢印キー</bf>か<bf>リターンキー</bf>を使ってお読みください. 一度読んだことのあるセクションは<bf>左矢印キー</bf>で 戻って読みなおすことができます. </abstract> <chapt><heading>一般的な情報</heading> &nutshell; &history; &relnotes; &install; &troubleshooting; &bibliography; &eresources; &hw; &contrib; </book> </linuxdoc> diff --git a/ja/handbook/booting.sgml b/ja/handbook/booting.sgml index ffaf2c8f85..f90c576a9e 100644 --- a/ja/handbook/booting.sgml +++ b/ja/handbook/booting.sgml @@ -1,183 +1,183 @@ <!-- $FreeBSD$ --> <!-- The FreeBSD Japanese Documentation Project --> -<!-- Original revision: 1.11 --> +<!-- Original revision: 1.12 --> <!-- This is a SGML version of the text on FreeBSD boot procedures made by Poul-Henning Kamp <phk@FreeBSD.ORG> This conversion has been made by Ollivier Robert. <!DOCTYPE linuxdoc PUBLIC "-//FreeBSD//DTD linuxdoc//EN"> <article> <title>ブートの概要 Poul-Henning Kamp, v1.1, April 26th FreeBSDのブートには基本的に3つの段階があります: カーネルの読み込み、ルートのファイルシステムの決定、そして ユーザ領域にあるものの初期化です。このことは下に述べる いくつかの興味深い可能性につながっているのです... --> FreeBSDのブート処理の流れ

原作: &a.phk;. v1.1, April 26th.

訳: &a.nakai; September 6 1996. FreeBSDのブートには基本的に3つの段階があります: カーネルの読み込み, ルートのファイルシステムの決定, そして ユーザ領域にあるものの初期化です. このことは下に述べる いくつかの興味深い可能性につながっています。 カーネルの読み込み

現在, カーネルの読み込みには基本的に下に挙げる3つの方法が あります: これらはカーネルが次に何をしたらいいのかという情報をカーネルに 与えます. Biosboot Biosbootは「ブートブロック」に相当するもので, 2つのファイル から構成されており, フロッピーディスクやハードディスクのブートを 開始する側の 8K バイトにインストールされています。 Biosboot は FreeBSD のファイルシステムからカーネルを 読み込むことができます. Dosboot Dosbootは DI. Christian Gusenbauerによって書かれましたが, 不幸にしてこの場合には、コードのある一部分がマイクロソフトの コンパイラ向けに書かれているため、FreeBSD 単体ではコンパイル することはできません. Dosboot は MS-DOS のファイルから、またはディスクの FreeBSD ファイルシステムのパーティションからカーネルをブートします。 これは MS-DOS システムのハイメモリ領域に潜んでいるメモリマネージャ等の さまざまな怪しい代物とメモリの取り合いをして、なんとかブートしています. Netboot Netboot はサポートされているイーサネットカードを検出し、 BOOTP や TFTP、NFS を使ってブートするカーネルを探そうとします。 ルートファイルシステムの決定

カーネルが読み込まれ、ブートプログラムがカーネルに移行したら, カーネルは自身の初期化をし, どんなハードウェアが組み込まれいるか を決定し、それからルートファイルシステムを探さなくてはなりません。 現在サポートされているルートファイルシステムは次の通りです : UFS UFS は, もっとも一般的なタイプのルートシステムです。 フロッピーディスクやハードディスク上に存在します。 MSDOS 技術的に可能ですが、あまり有用ではありません。なぜならば、 ``FAT''ファイルシステムではリンクやデバイスノードなどの ``UNIX 主義''を実現できないからです。 MFS MFS はカーネル内部に組み込みになっている UFS ファイルシステムです。つまり MFS を機能させるのに ディスクやフロッピーディスクなどのハードウェアは 必要ではありません. CD9660 CD9660 は CD-ROM をルートファイルシステムに使用したものです。 NFS これはルートシステムにファイルサーバを使用していて、基本的に ディスクレスのマシンのためにあります。 ユーザ領域にあるものの初期化

ユーザ領域で動作させるようにするために、カーネルが初期化を終えると、 カーネルは``/sbin/init'' です。 /sbin/init を別なプログラム置き換えてしまうことは可能ですが、そのプロセス には以下のような制約があります: pid が 1 のプロセスには stdin/stdout/stderr は割り当てられていませんので、 プログラムは自分でこれらをオープンしないとなりません。 このプロセスが終了するとカーネルはパニックメッセージを表示して 停止します。 また、このプロセスに対するシグナル処理は特殊です。 この例として、インストール用のフロッピーディスクにある ``/stand/sysinstall''があります。 興味深い連係

カーネルを MFS でブートするのには次のような特別の/sbin/init を使います。 /C: にマウントします。 C:/freebsd.fs を /dev/vn0 にアタッチします。 /dev/vn0 を /rootfs にマウントします。 シンボリックリンクを作ります。 /rootfs/bin -> /bin /rootfs/etc -> /etc /rootfs/sbin -> /sbin (etc...) これでハードディスクのパーティションを切り直さずに FreeBSD を 使うことができます。 サーバ:˜you/FreeBSD を /nfsにマウントし、ルートディレクトリを /nfs に変更して, そこで/sbin/initを実行します。 これで FreeBSD をディスクレスで実行できますが、NFS サーバを コントロールできないままです... /dev/rwd0 のコピーを取って、リモートにあるテープ ステーションやファイルサーバに書き込んでください。 これで一年前に取っておくべきだったバックアップをやっと 取ることができました。 E -- ファイアウォール/Web サーバとして動作させる場合 (私の知っている範囲で...) これは特に面白いもので、書き込み禁止のフロッピーディスクから ブートができて、ルートのファイルシステムに書き込むことができる というものです。 diff --git a/ja/handbook/contrib.sgml b/ja/handbook/contrib.sgml index 6aa169d7b1..e4ebb35db4 100644 --- a/ja/handbook/contrib.sgml +++ b/ja/handbook/contrib.sgml @@ -1,481 +1,481 @@ - + FreeBSD へのコントリビュータ

原作: 不明

訳: &a.hanai;28 August 1996. BSD派生ソフトウェアへのコントリビュータ

このソフトウェアは最初は William F. Jolitz の 386BSD release 0.1 から派生しましたが, オリジナルの 386BSD に固有のコードはほとんど 残っていません. このソフトウェアは基本的にはカリフォルニア大学 バークレイ校の Computer Science Research Group (CSRG) とその共同研究者 たちによる 4.4BSD-Lite リリースから再実装されました. また, NetBSD の一部も FreeBSD に取り込まれています. したがって私たちは NetBSD へ貢献した人々すべてに感謝します.二つのグループの関係が ギクシャクすることも時にはありますが, 私たちは基本的には共に同じ目的 を持っています. すなわち, 人々のコンピュータにもっと BSD をベースに したオペレーティングシステムを! ということです. 私たちは NetBSD の努力が常に成功してほしいと思っています. ハードウェアのコントリビュータ

特に Walnut Creek CDROM にはネットワークへのアクセス及び他のハードウェア リソースの寄贈はいうまでもなく, 開発に使うための Pentium P5-90 と 486/DX2-66 EISA/VL システムを提供してくれたことについて感謝しています. 彼らのサポートがなければこのリリースをおこなうことは不可能であったで しょう. TRW Financial Sysytems社は, PC 130台,三つの 68 GB のファイルサーバ 12のイーサネット, ディスクレスコードのデバッグをおこなうための 二つのルータ及び ATM スイッチを提供してくれました. また, かれらは 2, 3人の FreeBSD ハッカーを雇って, FreeBSD に専念させて くれています. ありがとう! また, 東芝 XM3401B CDROM ドライブ を寄付してくれた Dermot McDonnell に感謝します. その CDROM ドライブはもっとも役に立ちました. 実験的な仕事としてフロッピーテープストリーマを寄付してくれた &a.chuck; に感謝します. wtドライバを改良するために Wangtek と Archive の QIC-02 テープドライブを提供してくれた Larry Altneu <larry@ALR.COM> と &a.wilko; に感謝します. このプロジェクトへ 2.88 MB のフロッピードライブを提供してくれた Ernst Winter <ewinter@lobo.muc.de> に感謝します. うまくいけば, これでフロッピーディスクドライバを書き直すための プレッシャーが増えるでしょう. ;-) また, FreeBSDプロジェクトへ資金やサービスを提供してくれた人々の リストは をご覧ください. FreeBSD コアチーム

(姓でアルファベット順): &a.asami &a.ache &a.dyson &a.bde &a.gibbs &a.davidg &a.jkh &a.phk &a.rich &a.gpalmer &a.sos &a.peter &a.wollman &a.joerg FreeBSD の開発者たち

(CVSの)commitする権利を持っていて, FreeBSD のソースツリーについて 作業をおこなっている人々がいます. すべてのコアチームのメンバはまた 開発者でもあります. &a.mbarkah; &a.torstenb; &a.gclarkii; &a.adam; &a.dufault; &a.uhclem; &a.sef; &a.julian; &a.se; &a.fenner; &a.jfieber; &a.jfitz; &a.lars; &a.scrappy; &a.tg; &a.graichen; &a.rgrimes; &a.jhay; &a.hsu; &a.ugen; &a.gj; &a.nsj; &a.ljo; &a.kato; &a.andreas; &a.erich; &a.imp; &a.smace; &a.mckay; &a.amurai; &a.markm; &a.max; &a.alex; &a.davidn; &a.obrien; &a.fsmp; &a.smpatel; &a.wpaul; &a.jmacd; &a.jdp; &a.steve; &a.mpp; &a.dfr; &a.jraynard; &a.csgr; &a.martin; &a.paul; &a.roberto; &a.chuckr; &a.dima; &a.wosch; &a.ats; &a.msmith; &a.karl; &a.pst; &a.guido; &a.swallace; &a.nate; &a.jmz; 担当者

FreeBSD ドキュメンテーションプロジェクト

FreeBSD ドキュメンテーションプロジェクトは複数のサービスを提供 しています. それぞれのサービスの担当者は以下のとおりです.

その他の FreeBSD へのコントリビュータ

(名前でアルファベット順に): A JOSEPH KOSHY <koshy@india.hp.com> ABURAYA Ryushirou <pcs51674@asciinet.or.jp> Adam Glass <glass@postgres.berkeley.edu> Adrian T. Filipi-Martin <atf3r@agate.cs.virginia.edu> Akito Fujita <fujita@zoo.ncl.omron.co.jp> Alain Kalker <A.C.P.M.Kalker@student.utwente.nl> Alan Cox <alc@cs.rice.edu> Andreas Kohout <shanee@rabbit.augusta.de> Andreas Lohr <andreas@marvin.RoBIN.de> Andrew Gordon <andrew.gordon@net-tel.co.uk> Andrew Herbert <andrew@werple.apana.org.au> Andrew McRae <amcrae@cisco.com> Andrew Moore <alm@FreeBSD.org> Andrew Stevenson <andrew@ugh.net.au> Andrew V. Stesin <stesin@elvisti.kiev.ua> Andrey Zakhvatov <andy@cgu.chel.su> Andy Whitcroft <andy@sarc.city.ac.uk> Anthony Yee-Hang Chan <yeehang@netcom.com> Bernd Rosauer <br@schiele-ct.de> Bill Kish <kish@osf.org> &a.wlloyd Bob Wilcox <bob@obiwan.uucp> Boyd Faulkner <faulkner@mpd.tandem.com> Brent J. Nordquist <nordquist@platinum.com> Brian Clapper <bmc@willscreek.com> Brian Tao <taob@risc.org> Charles Hannum <mycroft@ai.mit.edu> Charles Mott <cmott@srv.net> Chet Ramey <chet@odin.INS.CWRU.Edu> Chris G. Demetriou <cgd@postgres.berkeley.edu> Chris Stenton <jacs@gnome.co.uk> Chris Timmons <skynyrd@opus.cts.cwu.edu> Chris Torek <torek@ee.lbl.gov> Christian Gusenbauer <cg@fimp01.fim.uni-linz.ac.at> Christian Haury <Christian.Haury@sagem.fr> Christoph Robitschko <chmr@edvz.tu-graz.ac.at> Chuck Hein <chein@cisco.com> Conrad Sabatier <conrads@neosoft.com> Cornelis van der Laan <nils@guru.ims.uni-stuttgart.de> Craig Struble <cstruble@vt.edu> Cristian Ferretti <cfs@riemann.mat.puc.cl> Curt Mayer <curt@toad.com> Daniel Baker <dbaker@crash.ops.neosoft.com> Daniel M. Eischen <deischen@iworks.InterWorks.org> Danny J. Zerkel <dzerkel@feephi.phofarm.com> Dave Bodenstab <imdave@synet.net> Dave Burgess <burgess@hrd769.brooks.af.mil> Dave Chapeskie <dchapes@zeus.leitch.com> Dave Edmondson <davided@sco.com> Dave Rivers <rivers@ponds.uucp> David Dawes <dawes@physics.su.OZ.AU> David Leonard <d@scry.dstc.edu.au> Dean Huxley <dean@fsa.ca> Dirk Froemberg <dirk@hal.in-berlin.de> Dmitry Kohmanyuk <dk@farm.org> &a.whiteside; Don Yuniskis <dgy@rtd.com> Donald Burr <d_burr@ix.netcom.com> Doug Ambrisko <ambrisko@ambrisko.roble.com> Eric Blood <eblood@cs.unr.edu> Frank Bartels <knarf@camelot.de> Frank Maclachlan <fpm@crash.cts.com> Frank Nobis <fn@trinity.radio-do.de> FURUSAWA Kazuhisa <furusawa@com.cs.osakafu-u.ac.jp> Gary A. Browning <gab10@griffcd.amdahl.com> Gene Stark <stark@cs.sunysb.edu> Greg Ungerer <gerg@stallion.oz.au> Harlan Stenn <Harlan.Stenn@pfcs.com> Havard Eidnes <Havard.Eidnes@runit.sintef.no> Hideaki Ohmon <ohmon@tom.sfc.keio.ac.jp> Hidekazu Kuroki <hidekazu@cs.titech.ac.jp> Hidetoshi Shimokawa <simokawa@sat.t.u-tokyo.ac.jp> Holger Veit <Holger.Veit@gmd.de> Igor Vinokurov <igor@zynaps.ru> Ikuo Nakagawa <ikuo@isl.intec.co.jp> IMAMURA Tomoaki <tomoak-i@is.aist-nara.ac.jp> Ishii Masahiro <?> J.T. Conklin <jtc@cygnus.com> James Clark <jjc@jclark.com> James da Silva <jds@cs.umd.edu> et al Janusz Kokot <janek@gaja.ipan.lublin.pl> Jason Thorpe <thorpej@nas.nasa.gov> Javier Martin Rueda <jmrueda@diatel.upm.es> Jian-Da Li <jdli@csie.NCTU.edu.tw> Jim Lowe <james@cs.uwm.edu> Jim Wilson <wilson@moria.cygnus.com> Johann Tonsing <jtonsing@mikom.csir.co.za> John Capo <jc@irbs.com> John Perry <perry@vishnu.alias.net> John-Mark Gurney <gurney_j@efn.org> Juergen Lock <nox@jelal.hb.north.de> Juha Inkari <inkari@cc.hut.fi> Julian Assange <proff@suburbia.net> Julian Jenkins <kaveman@magna.com.au> Julian Stacey <jhs@freebsd.org> Kazuhiko Kiriyama <kiri@kiri.toba-cmt.ac.jp> Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp> Keith Bostic <bostic@toe.CS.Berkeley.EDU> Keith Moore <?> Kirk McKusick <mckusick@mckusick.com> Koichi Sato <copan@ppp.fastnet.or.jp> Kostya Lukin <lukin@okbmei.msk.su> Kurt Olsen <kurto@tiny.mcs.usu.edu> Lars Koeller <Lars_Koeller@odie.physik2.uni-rostock.de> Lucas James <Lucas.James@ldjpc.apana.org.au> Luigi Rizzo <luigi@iet.unipi.it> Manu Iyengar <iyengar@grunthos.pscwa.psca.com> Marc Frajola <marc@dev.com> Marc Ramirez <mrami@mramirez.sy.yale.edu Marc van Kempen <wmbfmk@urc.tue.nl> Mark Huizer <xaa@stack.nl> Mark J. Taylor <mtaylor@cybernet.com> Mark Tinguely <tinguely@plains.nodak.edu> <tinguely@hookie.cs.ndsu.NoDak.edu> Martin Birgmeier Masachika ISHIZUKA <ishizuka@isis.min.ntt.jp> Mats Lofkvist <mal@algonet.se> Matt Bartley <mbartley@lear35.cytex.com> Matt Thomas <thomas@lkg.dec.com> Matt White <mwhite+@CMU.EDU> Matthew N. Dodd <winter@jurai.net> Matthew Stein <matt@bdd.net> Michael Butschky <butsch@computi.erols.com> Michael Elbel <me@FreeBSD.ORG> Michael Searle <searle@longacre.demon.co.uk> Miguel Angel Sagreras <msagre@cactus.fi.uba.ar> Mikael Hybsch <micke@dynas.se> Mikhail Teterin <mi@aldan.ziplink.net> Mike McGaughey <mmcg@cs.monash.edu.au> Mike Peck <mike@binghamton.edu> MITA Yoshio <mita@jp.FreeBSD.ORG> MOROHOSHI Akihiko <moro@race.u-tokyo.ac.jp> Naoki Hamada <nao@tom-yam.or.jp> NIIMI Satoshi <sa2c@and.or.jp> Nick Sayer <nsayer@quack.kfu.com> Nisha Talagala <nisha@cs.berkeley.edu> Nobuhiro Yasutomi <nobu@psrc.isac.co.jp> Nobuyuki Koganemaru <kogane@kces.koganemaru.co.jp> Noritaka Ishizumi <graphite@taurus.bekkoame.or.jp> Oliver Oberdorf <oly@world.std.com> Paul Fox <pgf@foxharp.boston.ma.us> Paul Kranenburg <pk@cs.few.eur.nl> Paul Mackerras <paulus@cs.anu.edu.au> Pedro Giffuni <pgiffuni@fps.biblos.unal.edu.co> Peter Stubbs <PETERS@staidan.qld.edu.au> Philippe Charnier <charnier@lirmm.fr> R. Kym Horsell <?> Randall Hopper <rhh@stealth.ct.picker.com> Richard Stallman <rms@gnu.ai.mit.edu> Richard Wiwatowski <rjwiwat@adelaide.on.neti> Rob Mallory <rmallory@csusb.edu> Rob Shady <rls@id.net> Rob Snow <rsnow@txdirect.net> Robert Sanders <rsanders@mindspring.com> Robert Withrow <witr@rwwa.com> Ronald Kuehn <kuehn@rz.tu-clausthal.de> Sander Vesik <sander@haldjas.folklore.ee> Sandro Sigala <ssigala@globalnet.it> Sascha Blank <blank@fox.uni-trier.de> Sascha Wildner <swildner@channelz.GUN.de> Scott Blachowicz <scott@sabami.seaslug.org> Serge V. Vakulenko <vak@zebub.msk.su> Simon Marlow <simonm@dcs.gla.ac.uk> Soren Dayton <csdayton@midway.uchicago.edu> Stefan Moeding <moeding@bn.DeTeMobil.de> Steve Gerakines <steve2@genesis.tiac.net> Suzuki Yoshiaki <zensyo@ann.tama.kawasaki.jp> Tadashi Kumano <kumano@strl.nhk.or.jp> Taguchi Takeshi <taguchi@tohoku.iij.ad.jp> Tatsumi Hosokawa <hosokawa@mt.cs.keio.ac.jp> Terry Lambert <terry@lambert.org> Terry Lee <terry@uivlsi.csl.uiuc.edu> Theo Deraadt <deraadt@fsa.ca> Thomas König <Thomas.Koenig@ciw.uni-karlsruhe.de> Tim Kientzle <kientzle@netcom.com> Tim Vanderhoek <ac199@freenet.hamilton.on.ca> Tom Samplonius <tom@misery.sdf.com> Torbjorn Granlund <tege@matematik.su.se> Tor Egge <tegge@itea.ntnu.no> Toshihiro Kanda <candy@fct.kgc.co.jp> Ville Eerola <ve@sci.fi> Werner Griessl <werner@btp1da.phy.uni-bayreuth.de> Wes Santee <wsantee@wsantee.oz.net> Wolfgang Stanglmeier <wolf@kintaro.cologne.de> Yoshiro Mihira <sanpei@yy.cs.keio.ac.jp> Yukihiro Nakai <nakai@mlab.t.u-tokyo.ac.jp> Yuval Yarom <yval@cs.huji.ac.il> Yves Fonk <yves@cpcoup5.tn.tudelft.nl> 386BSD パッチキットへのパッチ提供者

(名前でアルファベット順): Adam Glass <glass@postgres.berkeley.edu> Adrian Hall <adrian@ibmpcug.co.uk> Andrey A. Chernov <ache@astral.msk.su> Andrew Herbert <andrew@werple.apana.org.au> Andrew Moore <alm@netcom.com> Andy Valencia <ajv@csd.mot.com> <jtk@netcom.com> Arne Henrik Juul <arnej@Lise.Unit.NO> Bakul Shah <bvs@bitblocks.com> Barry Lustig <barry@ictv.com> Bob Wilcox <bob@obiwan.uucp> Branko Lankester Brett Lymn <blymn@mulga.awadi.com.AU> Charles Hannum <mycroft@ai.mit.edu> Chris G. Demetriou <cgd@postgres.berkeley.edu> Chris Torek <torek@ee.lbl.gov> Christoph Robitschko <chmr@edvz.tu-graz.ac.at> Daniel Poirot <poirot@aio.jsc.nasa.gov> Dave Burgess <burgess@hrd769.brooks.af.mil> Dave Rivers <rivers@ponds.uucp> David Dawes <dawes@physics.su.OZ.AU> David Greenman <davidg@Root.COM> Eric J. Haug <ejh@slustl.slu.edu> Felix Gaehtgens <felix@escape.vsse.in-berlin.de> Frank Maclachlan <fpm@crash.cts.com> Gary A. Browning <gab10@griffcd.amdahl.com> Geoff Rehmet <csgr@alpha.ru.ac.za> Goran Hammarback <goran@astro.uu.se> Guido van Rooij <guido@gvr.win.tue.nl> Guy Harris <guy@auspex.com> Havard Eidnes <Havard.Eidnes@runit.sintef.no> Herb Peyerl <hpeyerl@novatel.cuc.ab.ca Holger Veit <Holger.Veit@gmd.de> Ishii Masahiro, R. Kym Horsell J.T. Conklin <jtc@cygnus.com> Jagane D Sundar < jagane@netcom.com > James Clark <jjc@jclark.com> James Jegers <jimj@miller.cs.uwm.edu> James W. Dolter James da Silva <jds@cs.umd.edu> et al Jay Fenlason <hack@datacube.com> Jim Wilson <wilson@moria.cygnus.com> Jörg Lohse <lohse@tech7.informatik.uni-hamburg.de> Jörg Wunsch <joerg_wunsch@uriah.heep.sax.de> John Dyson - <formerly dyson@ref.tfs.com> John Polstra <jdp@polstra.com> John Woods <jfw@eddie.mit.edu> Jordan K. Hubbard <jkh@whisker.hubbard.ie> Julian Elischer <julian@dialix.oz.au> Julian Stacey <jhs@freebsd.org> Karl Lehenbauer <karl@NeoSoft.com> <karl@one.neosoft.com> Keith Bostic <bostic@toe.CS.Berkeley.EDU> Ken Hughes Kent Talarico <kent@shipwreck.tsoft.net> Kevin Lahey <kml%rokkaku.UUCP@mathcs.emory.edu> <kml@mosquito.cis.ufl.edu> Marc Frajola <marc@dev.com> Mark Tinguely <tinguely@plains.nodak.edu> <tinguely@hookie.cs.ndsu.NoDak.edu> Martin Renters <martin@tdc.on.ca> Michael Clay <mclay@weareb.org> Michael Galassi <nerd@percival.rain.com> Mike Durkin <mdurkin@tsoft.sf-bay.org> Naoki Hamada <nao@tom-yam.or.jp> Nate Williams <nate@bsd.coe.montana.edu> Nick Handel <nhandel@NeoSoft.com> <nick@madhouse.neosoft.com> Pace Willisson <pace@blitz.com> Paul Kranenburg <pk@cs.few.eur.nl> Paul Mackerras <paulus@cs.anu.edu.au> Paul Popelka <paulp@uts.amdahl.com> Peter da Silva <peter@NeoSoft.com> Phil Sutherland <philsuth@mycroft.dialix.oz.au> Poul-Henning Kamp<phk@FreeBSD.ORG> Ralf Friedl <friedl@informatik.uni-kl.de> Rick Macklem <root@snowhite.cis.uoguelph.ca> Robert D. Thrush <rd@phoenix.aii.com> Rodney W. Grimes <rgrimes@cdrom.com> Rog Egge <?> Sascha Wildner <swildner@channelz.GUN.de> Scott Burris <scott@pita.cns.ucla.edu> Scott Reynolds <scott@clmqt.marquette.mi.us> Sean Eric Fagan <sef@kithrup.com> Simon J Gerraty <sjg@melb.bull.oz.au> <sjg@zen.void.oz.au> Stephen McKay <syssgm@devetir.qld.gov.au> Terry Lambert <terry@icarus.weber.edu> Terry Lee <terry@uivlsi.csl.uiuc.edu> Warren Toomey <wkt@csadfa.cs.adfa.oz.au> Wiljo Heinen <wiljo@freeside.ki.open.de> William Jolitz <withheld> Wolfgang Solfrank <ws@tools.de> Wolfgang Stanglmeier <wolf@dentaro.GUN.de> Yuval Yarom <yval@cs.huji.ac.il> diff --git a/ja/handbook/crypt.sgml b/ja/handbook/crypt.sgml index 63ab152c40..2af144a834 100644 --- a/ja/handbook/crypt.sgml +++ b/ja/handbook/crypt.sgml @@ -1,81 +1,81 @@ - + DES, MD5, と Crypt

原作: &a.wollman;24 September 1995.

訳: &a.hanai;12 September 1996.

歴史

UN*X システムにおいてパスワードを保護し, 簡単に覗かれるのを防 ぐために, 従来パスワードはある方法によりスクランブルされてきました. ベル研の Unix 第7版に始まって以来, パスワードはセキュリティの専門家がい うところの「一方向ハッシュ関数」というものを用いることにより暗号化されるようになりました. つまり, 可能な限りのパスワード空間を検索するという強引な 方法以外にそのオリジナルを得ることができない, といった方法でパスワードは変換 されるのです. 不幸なことに, その当時 AT&T の研究者たちが手に入れることができ た唯一の暗号化方法は DES(Data Encryption Standard) に基づいたものでし た. これは営利企業にとっては大して問題ではありませんが, FreeBSDのよ うにすべてのソースコードが自由に手に入るオペレーティングシステムにとっ ては重大な問題となります. なぜなら, 多くの政府は DES やその他の暗号化ソフ トウェアが国境を越えることに制限をつけようとしているからです.

ここで, FreeBSD チームは一つのジレンマに直面しました. つまり, どうす れば法に触れることなく国外にあるそれらの UNIX システムのすべてに互換性を持 たせることができるか, ということです. 私たちは ``dual track approach'' を 取ることに決めました. 規制されていないパスワードスクランブラのみを含む 配布用物件を作り, DES に基づいたパスワードハッシュを付加ライブラリ として分けて供給するのです. パスワードをスクランブルさせる関数は, C ライブラリから `libcrypt' と呼ばれる(それを実行する C 関数が `crypt' と いう名前だからです)別のライブラリへ移されました. FreeBSD 1.x 及び 2.0 のリリース前のスナップショットでは, その規制されていないスクランブラは Nate Williams によって書かれた安全でない関数を使っていますが, 次の リリースでは RSA Data Security 社の一方向ハッシュ関数の MD5 を使う方法 に置き換えられました. これらの関数はどれも暗号化を含んでいないため, 合衆国から持ち出し, 他の多くの国へ持ち込めるものであるとされています.

一方, DES に基づいたパスワードハッシュ関数に関する作業もまた進行中 でした, まず, 合衆国及び他の国で書かれたコードの同期をとりながら, 合衆国の外で書かれた `crypt' のあるバージョンが持ち込まれました. そしてライブラリは修正され, 二つにわけられました. すなわち DES `libcrypt' は一方向パスワードハッシュをおこなうのに必要なコード のみを含み, それとは別の `libcipher' は実際に暗号化をおこなう ためのエントリポイントとして生成されました. コンパイルされたライブラリに対 して国外に持ち出す許可を得るのを簡単にするために, コードはこのように分け られたのです.

`crypt' メカニズムを理解する

あるパスワード文字列を作るのに, DES に基づいたハッシュ関数を使っ たのか, MD5に基づいたハッシュ関数を使ったのかは非常に簡単にわかります. MD5 を使ったパスワード文字列は必ず `$1$' という文字 で始まります. DESを使ったパスワード文字列はどんな特定の文字も持っていま せんが, MD5を使ったパスワードよりも短く, `$' という文字 を持たない64文字のアルファベットで構成されています. したがって, ドル記号で 始まっていない比較的短い文字列は DES を使ったパスワードである可能性が非常 に高いです.

あなたのシステムで, どちらのライブラリが使われているかを決めるの は, スタティックにリンクされている `init' のようなもの(その ようなプログラムに対する唯一の方法はわかっているパスワードを試してみ て動くかどうかを確認することです.)を除いたほとんどのプログラムについ ては非常に簡単なことです. `crypt' を使うようなプログラムは `libcrypt' にリンクされています. そしてそれぞれのライブラリに 対する `libcrypt' は適切な実装へのシンボリックリンクとなってい ます. 例えば, DES 版を使っているようなシステムにおいては次のようになって います: $ cd /usr/lib $ ls -l /usr/lib/libcrypt* lrwxr-xr-x 1 bin bin 13 Sep 5 12:50 libcrypt.a -> libdescrypt.a lrwxr-xr-x 1 bin bin 18 Sep 5 12:50 libcrypt.so.2.0 -> libdescrypt.so.2.0 lrwxr-xr-x 1 bin bin 15 Sep 5 12:50 libcrypt_p.a -> libdescrypt_p.a MD5 に基づいたライブラリを使っているシステムにおいては, 同じようなリンクが 見られるでしょうが, そのターゲットは `libdescrypt' ではなく `libscrypt' になっているでしょう. diff --git a/ja/handbook/ctm.sgml b/ja/handbook/ctm.sgml index 5bfc26fcf9..8019f733e3 100644 --- a/ja/handbook/ctm.sgml +++ b/ja/handbook/ctm.sgml @@ -1,217 +1,217 @@ - + CTM

原作: &a.phk;. 更新: 16-Mar-1995.

訳: &a.hanai;5 November 1996. なぜ

を読むことを お勧めします.

二つのものが必要でしょう: ``/usr/src/usr.sbin/にあります. もしFreeBSDの2.0以前のバージョンなら, 最新の から入手できます. または、そのが/etc/aliasesからはじめて

デルタを適用するためには, 単に cd /where/ever/you/want/the/stuff?? ctm -v -v /where/you/store/your/deltas/src-cur.*?? とします.

重要なもの ソースツリーへのローカルな修正を可能にすること. これを実現 する一つの方法は次のようなものでしょう:

foo/bar.c''というファイルを変更しようと する時, 最初にfoo/bar.c#CTMというファイルがあるか どうかチェックします. もしこのファイルがあれば, それに デルタを適用します. このようにしてfoo/bar.c ファイルをローカルな要求に合うように変更しておくことができます. 「ファイル復活」のオプションを ctm -r src/sys/i386/wd.c /here/are/my/deltas/src-cur.* これは src-cur ファイルから 残念なことに私は非常に忙しいです. 従ってこれを行なうどんな手助け でも歓迎します. その際, 自分が何をやりたいかを私に 言うのを忘れずに. その他

「DESに染まった」(例えば, 国外への持ち出しが規制された)ソースは まったく含まれません. 手に入るのは「国際」バージョンだけです. もし興味のある人が多いようであれば, 我々は``ありがとう!

diff --git a/ja/handbook/current.sgml b/ja/handbook/current.sgml index acd24074e4..c189c5516c 100644 --- a/ja/handbook/current.sgml +++ b/ja/handbook/current.sgml @@ -1,161 +1,161 @@ - + 最新のFreeBSDを追いかける

原作: &a.jkh;.

訳: &a.hanai;6 November 1996. FreeBSD-currentってなに?

FreeBSD-currentとは，文字通りに，日々変更されているFreeBSDのソース のスナップショット以外の何ものでもありません．中には現在開発途上の ソフトウェア, 実験的な変更、あるいは過渡的な機能などが含まれています. また, この中に入っている機能がすべて次の公式リリースに入るとはかぎりません. FreeBSD-currentをソースからほとんど毎日コンパイルしている人はたくさん いますが, 時期によってはFreeBSD-currentはコンパイルさえできない状態に なっていることもあります. これらの問題は一般的には可能な限り素早く解決 されますが, FreeBSD-currentのソースが不幸をもたらすか, それとも非常に 素晴らしい機能をもたらすかというのは文字通り, ある与えられた24時間の間 のどの部分であなたがソースを手に入れたか, による場合もあります. 必要があるときには, 時折 FreeBSD-current の一部をバイナリとして提供する こともありますが, それはただ何かをテストしてほしいためであって, 我々が current をバイナリリリースとして提供することにしたわけではありません. 我々が提供していないならば, 要求しないで下さい! これは普段から行なうにはあまりにも時間がかかり過ぎるのです． 誰がFreeBSD-currentを必要としてるの?

FreeBSD-currentは次の3つのどれかにあてはまる人のために一般に公開してい ます. ソースツリーの，ある部分または別の部分に関して活発に作業して いるFreeBSDグループのメンバ．彼らにとっては`最新のもの'に維持して おくことは絶対的な要求なのです． FreeBSD-currentが出来るだけ健全である時間の割合を増やすために 様々な問題と戦うのに時間を費やすのを厭わず活発にテストを行なっている FreeBSDグループのメンバ．彼らはまた様々な変更に関する提案やFreeBSD の大まかな方向付けを行ないたいと思っている人々でもあります． 単に，様々な事に目を向け，参考のために(例えば，動かすためではなく 読むために)最新のソースを使いたいと思っているFreeBSD(または 他の)グループのまわりにいるメンバ．これらの人々はまた時によってコメ ントをしたりコードを寄稿したりします． FreeBSD-currentに期待してはいけないことは?

あなたが何か新しいカッコイイモノがあると聞き, あなたの 周りで最初にそれを持ちたいためにリリース前のコードの断片を 追いかけること. バグを修正するための素早い方法. いずれにしても我々によって``公式にサポートされている''. 私たちは3つの「公式な」FreeBSD-currentのグループの一つに実際に属する 人々を助けるのにベストを尽くしますが, 技術的なサポートを行なうには 単に「時間が足りない」のです. これは我々が外の人を助けるのが好きではないケチで意地悪い人間だと いうことではなく(もしそうなら FreeBSD なんかやっていません), 文字通り 我々は一日に400ものメッセージに答えかつ FreeBSD の作業をする ことなど出来ない! ということなのです. もし, たくさんの質問に答えるか それとも FreeBSD を良くする作業を続けるかという選択が与えられた場合, あなた方のほとんどは後者を支持する, と私は確信しています. FreeBSD-currentを使う

&a.current;と&a.cvsall;に加わって下さい. これは単に良い考えであるというだけでなく, 必須のことなのです. もしFreeBSD-currentメーリングリストに入っていなければ, 様々な人がシステムの現在の状態について述べているコメントを決して見ることは ありませんし, 従って他の人が既に見つけて解決している多くの問題に戸惑っ てあきらめてしまうでしょう. さらに言うと, 非常に不可欠な情報 (例えば, 「やぁ, みんな! /usr/srcを作り直す前にカーネルの 再構築をやらないといけないよ, さもないととんでもないクラッシュが起きるぜ!」)を見逃してしまうでしょう. cvs-allメーリングリストはそれぞれの変更についてそれに関して起 こり得る情報を見ることが出来ます. これらのメーリングリストに入るには, &a.majordomo;へ subscribe freebsd-current subscribe cvs-all と書いたメールを送って下さい. オプションとして本文に`help'と書けば Majordomo はあなたへ我々がサポ ートする様々なメーリングリストに参加/脱退する方法に関する詳しい ヘルプを送ります. ftp.FreeBSD.ORGからのソースの入手. 以下の3つの方法で行なうこと が出来ます. 下に述べられているを用いる. 均一なレートの, 良質の TCP/IP 接続を持っていない人には, これが一番いい方法でしょう. CMUのプログラム(Software Update Protocol)を用いる. これも後で述べられています. これは2番目に推薦される方法です. なぜなら, supによって一度全体 を入手し, 後は変更されたところだけを入手することが出来るからです. たくさんの人がsupをcronから起動し, 自動的にソースを最新のもの に保っています. ftpを使う. FreeBSD-currentのソースツリーは常に に公開されています. 我々はまた全体をcompress/tarして入手できる `wu-ftpd' を使ってい ます. 例えば, usr.bin/lex があったとすると, ftp> cd usr.bin ftp> get lex.tar.Z とすることにより, ディレクトリ全体(この場合, usr.bin/lex以下全体) をcompressされたtarファイルとして入手することができます. 以上のことをまとめると, 必要に応じて迅速なアクセスをする必要があり, 接続のバンド幅が問題ではなければsupかftpを使いましょう. そうではなければ CTMを使いましょう. もしソースを, 眺めるだけでなく走らせるために入手しているので あれば, 一部だけ選ぶのではなく, current の全体を手に入れてください. なぜなら, ソースの様々な部分が他の部分の更新に依存しており, 一部のみを コンパイルしようとすると, ほぼ間違いなくトラブルを起こすからです. current をコンパイルする前に /usr/src にある Makefile をよく読んでください. アップグレードの処理の一部として, 少なくとも一回は最初に `make world' を行なうべきでしょう. &a.current;を読めば, 次のリリースへ向けて, 時々必要になる 他のブートストラップの方法に関して常に最新情報を得ることが出来ます. アクティブになって下さい! もしFreeBSD-currentを走らせているなら 我々はそれに関するコメント, 特に拡張やバグ潰しに関する提案, を欲して います. コードを伴う提案はもっとも歓迎されるものです! diff --git a/ja/handbook/cvsup.sgml b/ja/handbook/cvsup.sgml index a474bc1613..9b29e2ba52 100644 --- a/ja/handbook/cvsup.sgml +++ b/ja/handbook/cvsup.sgml @@ -1,387 +1,387 @@ - + CVSup

原作: &a.jdp;.

訳: &a.iwasaki;.28 December 1996. CVSup の紹介

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 2.2 以降を使用している場合, CVSup をインストールするもっとも 簡単な方法は, FreeBSD の または対応する を使うことです. どちらを使うかは, CVSupを自分で作りたいかどうかによります.

FreeBSD-2.1.6 を使用している場合は, 残念ながら FreeBSD-2.1.6 には 存在しないバージョンの C ライブラリが必要となるため バイナリ package は使用できません. しかし, は FreeBSD 2.2 とまったく同じように簡単に使うことができます. 単に tar ファイルを展開し, cvsup ディレクトリへ cd して "make install" とタイプするだけです.

CVSup は で書かれているため, package と port 両方とも Modula-3 ランタイムライブラリがインストールされていることが必要です. これらは port の および package の にあります. これらのライブラリの port や package に対して cvsup と同じ管理方法を取っていれば, CVSup の port や package をインストールする際に, これらのライブラリも自動的に コンパイルそして/またはインストールされます.

Modula-3 ライブラリはかなり大きく, これらの転送やコンパイルはすぐに 終わるものではありません. この理由から, 三つめの選択肢が提供されています. 以下のところから, スタティックリンクされた CVSup の FreeBSD 用の実行形式が入手可能です: (client). (server).

ほとんどのユーザはクライアントのみが必要になるでしょう. これらの 実行形式は完全に自己完結しており, FreeBSD-2.1.0 から FreeBSD-current までの, どのバージョンでも動作します.

まとめると, CVSup をインストールするための選択肢は以下の通りです: FreeBSD-2.2以降: スタティックバイナリ, port, package FreeBSD-2.1.6: スタティックバイナリ, port FreeBSD-2.1.5 以前: スタティックバイナリ CVSup のコンフィグレーション

CVSup の動作は, "supfile" と呼ばれるコンフィグレーションファイルで 制御します. FreeBSD-2.2 からは, supfile のサンプルがディレクトリ の下にあります. 2.2 以前のシステムを使用している場合は, これらの サンプルを から入手することができます.

supfile には以下の cvsup に関する質問への答えを記述します:

次のセクションで, これらの質問に順番に答えながら典型的な supfile を組み立てていきます. 最初に supfile の全体構造を説明します.

supfile はテキストファイルです. コメントは "#" から行末までです. 空行とコメントだけの行は無視します.

残りの各行には, ユーザが受け取りたいファイル群について記述します. 行の始めは, サーバ側で定義した論理的なファイルのグループである 「コレクション」の名称です. コレクションの名称を指定して, 欲しいファイル群を サーバに伝えます. コレクション名の後には, ホワイトスペースで区切られた 0個以上のフィールドが続きます. これらのフィールドが上記の質問に対する 答えになります. フィールドには 2種類あります: flag フィールドと value フィールドです. flag フィールドは "delete" や "compress" のような 単独のキーワードから成ります. また, value フィールドもキーワードで 始まりますが, キーワードの後にはホワイトスペースは入らず, "=" と 二つめの単語が続きます. 例えば, "release=cvs" は value フィールドです.

通常, supfile には受け取りたいコレクションを一つ以上指定します. supfile を組み立てる一つの方法として, コレクション毎にすべての関係の あるフィールドを明示的に指定する方法があります. しかし, これでは supfile のすべてのコレクションに対してほとんどのフィールドが同じになるため, 行が非常に長くなってしまい不便になります. これらの問題を避けるため, CVSup ではデフォルトを指定することのできるメカニズムが提供されています. 特殊な擬似コレクション名 "*default" で始まる行は, supfile 中の後続の コレクションに対して使用する flag フィールドと value フィールドの デフォルトを設定するために利用できます. 個々のコレクションで固有の値を 指定すると, デフォルト値を無効にできます. また "*default" 行を追加すると, supfile の途中からデフォルト値の変更や追加が可能になります.

これまでの予備知識を基に, のメインのソースツリーを受け取って更新するための supfile を 組み立ててみましょう. どのファイルを受け取りたいのか?

sup の場合と同様に, CVSup を通して入手できるファイルは 「コレクション」と呼ばれる名前の付けられたグループにまとめられています. FreeBSD のソースツリーを構成しているコレクションについては の節で説明しています. ここでは, FreeBSD システムのメインのソースツリー全体を受け取るための設定例を紹介します. 輸出規制されている暗号化サポートのコード以外のすべてを含む "src-all" という 単一の大きなコレクションがあります. この例では私たちがアメリカ合衆国か カナダにいるものと仮定します. その場合, "src-eBones" および "src-secure" の二つの付化的なコレクションで暗号化コードを入手することができます. supfile を組み立てる最初のステップとして, これらのコレクションを一行に一つづつ 記述します: src-all src-eBones src-secure

どのバージョンのものが欲しいのか?

CVSup を使用すると, かつて存在していたことのある, 事実上どのバージョンの ソースでも受け取ることができます. これは cvsupd サーバがすべてのバージョンを含む CVS リポジトリに基づいて動作することにより, 実現されています. "tag=" および "date=" の value フィールドを使用して, 欲しいバージョンの 一つを指定します.

"tag=" フィールドはリポジトリ中のシンボリックタグを指定します. tag には revision tag と branch tag の二種類があります. revision tag は特定のリビジョンを指します. これは, 毎日同じ状態に保つことになります. 一方 branch tag は, ある時点での開発分流の最新のリビジョンを指します. branch tag は特定のリビジョンを指定している訳ではないので, 今日と明日では 異なるリビジョンを参照することになるかもしれません.

以下はユーザが興味を持っていると思われる branch tag です:

以下はユーザが興味を持っていると思われる revision tag です:

tag 名を示した通りにタイプされているか十分注意してください. CVSup は tag 名が正しいかどうかを見分けることはできません. tag が間違っていた場合, たまたまファイルがまったく存在しない正しい tag が指定されたものとしてCVSup は動作します. その場合は, 現在あるソースが 削除されるでしょう.

branch tag を指定した際には, 通常はその開発分流の最新バージョンの ファイルを受け取ります. いくらか前のバージョンを受け取りたい場合は, "date=" の value フィールドを使って日付を指定することで, これを実現することが できます. cvsup(1) のマニュアルページで, その方法を説明しています.

例として, FreeBSD-current を受け取りたいとします. 次の行を supfile の始めに追加します: *default tag=.

"tag=" フィールドも "date=" フィールドも指定しなかった場合に 動き出す重要な特殊なケースがあります. そのケースでは, 特定のバージョンの ファイルを受け取るのではなく, サーバの CVS リポジトリから実際の RCS ファイルを直接受け取ります. 一般的に開発者はこの処理のモードが 好きなようです. 彼らのシステム上にリポジトリそのもののコピーを維持することで, リビジョン履歴を閲覧し過去のバージョンのファイルを検査できるようになります. しかし, これには大きなディスクスペースが必要になります.

どこから入手したいのか?

これは簡単なことです. cvsup に第一の FreeBSD 配布サイト "cvsup.FreeBSD.org" から最新情報を持ってくるように伝える "host=" フィールドを使います: *default host=cvsup.FreeBSD.org

どのように cvsup を実行しても, この設定は "-h hostname" を 使用してコマンドラインで変更することができます.

自分のマシンのどこに置きたいのか?

"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" は ... 神秘的なものです. これについて本当に 知りたい人は, cvsup(1) のマニュアルページをご覧ください. でなければ, 何も考えずに指定してみてください.

"compress" は通信チャネルで gzip 形式の圧縮の使用を有効にします. ご使用のネットワーク接続が T1 speed 以上である場合, この圧縮を 使用しない方がよいかもしれません. そうでない場合は十分に役に立ちます.

supfile の例のまとめ:

以下は supfile の例の全体です: *default tag=. *default host=cvsup.FreeBSD.org *default prefix=/usr *default base=/usr/local/etc/cvsup *default release=cvs delete use-rel-suffix compress src-all src-eBones src-secure CVSup の実行

さて, 更新の準備ができました. これを実行するコマンドラインは 実に簡単です: cvsup supfile

もちろん, ここでの "supfile" は作成したばかりの supfile のファイル名です. X11 環境で実行するものと仮定して, cvsup は 通常の操作に必要なボタンを持つ GUI ウィンドウを表示します. "go" ボタンを押して, 実行を監視してください.

この例では実際の "/usr/src" ツリーを更新しているので, cvsup にファイルを更新するのに必要なパーミッションを与えるために, ユーザ root で実行する必要があります. コンフィグレーションファイルを作ったばかりで, しかも以前にこのプログラムを実行したことがないので, 神経質になるのは 無理もない話だと思います. 大切なファイルに触らずに試しに実行する簡単な 方法があります. どこか適当な場所に空のディレクトリを作成して, コマンドラインの引数で指定するだけです: mkdir /var/tmp/dest cvsup supfile /var/tmp/dest

指定したディレクトリは, すべての更新されるファイルの 更新先ディレクトリとして使用します. CVSup は "/usr/src" の下の ファイルを検査しますが, 変更や削除はまったくおこないません. かわりに "/var/tmp/dest/usr/src" に更新されたすべてのファイルが 置かれるようになります. この方法で実行した場合は, CVSup は base ディレクトリの status ファイルを更新せずにそのままにします. これらのファイルの新しいバージョンは指定されたディレクトリ に書き込まれます. "/usr/src" の読み取り許可がある限り, このような 試し実行のためにユーザ root になる必要はありません.

X11 を利用していないとか単に GUI が気に入らない場合は, cvsup 起動時にコマンドラインに二つほどオプションを追加する必要があります: cvsup -g -L 2 supfile

"-g" オプションは cvsup に GUI を使用しないように伝えます. X11 を利用していない場合には自動的に指定されますが, そうでない場合は 明示的に指定します.

"-L 2" オプションは cvsup にファイル更新中の詳細情報をプリントアウト するように伝えます. 冗長性には "-L 0" から "-L 2" までの三つのレベル があります. デフォルトは 0 であり, エラーメッセージ以外はまったく出力 しません.

たくさんの他のオプション変数があります. それらの簡単な一覧は "cvsup -H" で表示されます. より詳しい説明はマニュアルページをご覧ください.

動作している更新の方法に満足したら, cron(8) を使って cvsup を定期的に 実行させる準備をすることができます. cron から起動する際には, 明示的に cvsup が GUI を使わないようにする必要があります. CVSup のアナウンス, 質問およびバグ報告

CVSup のほとんどの FreeBSD 関連の議論は &a.hackers; で おこなわれています. ソフトウェアの新しいバージョンは &a.announce; で アナウンスされます.

質問とバグ報告はプログラムの作者, へ 送ってください. diff --git a/ja/handbook/cyclades.sgml b/ja/handbook/cyclades.sgml index 06dd083fc0..b8f0f647ee 100644 --- a/ja/handbook/cyclades.sgml +++ b/ja/handbook/cyclades.sgml @@ -1,58 +1,58 @@ - + cy ドライバのコンフィグ

原作: &a.alex;.6 June 1996.

訳: &a.yuki;.6 September 1996. Cyclades社のマルチポートカードは, 他のマルチポートカードが 使うsioの代わりにcyドライバを使います. コンフィグレーションは非常に簡単で, cy デバイスをあなたの に足します. (注意. あなたのirqやiomemの設定がが違っているかもしれません) device cy0 at isa? tty irq 10 iomem 0xd4000 iosiz 0x2000 vector cyintr 新しいカーネルの をします. を次(8ポートと仮定しています.)のように打って作ります: # cd /dev # for i in 0 1 2 3 4 5 6 7;do ./MAKEDEV cuac$i ttyc$i;done もし, 必要なら シリアルデバイス(ttyd)とそっくりにコピーして エントリを作り, ttyd 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 新しいカーネルで立ち上げます. diff --git a/ja/handbook/development.sgml b/ja/handbook/development.sgml index ad3b9aafe0..b73df0db53 100644 --- a/ja/handbook/development.sgml +++ b/ja/handbook/development.sgml @@ -1,104 +1,104 @@ - + FreeBSDの開発モデル

原作: &a.asami;. 18 October 1996.

訳: &a.asami;. 31 October 1996.

FreeBSDの開発は非常に開かれた, 柔軟性のあるプロセスです. を見ていただければわかる とおり, FreeBSDは文字通り世界中の何百という人々の努力によって開発され ています. 新しい開発者はいつでも大歓迎ですので, &a.hackers; にメールを 送ってください. また, 大勢で議論するよりは一人で静かに開発にふけりた いという人は私たちのFTPサイトを使ってパッチや開発中のソースを公開してくださっ て結構です. &a.announce; もありますので, 他のFreeBSDユーザに自分のやっ ていることを宣伝したい時にはどうぞ使ってください. あと, FreeBSDプロジェクトとその開発プロセスについて, どなたにも知って いていただきたいのは以下のようなことです. CVSリポジトリ

FreeBSDのソースツリーは (Concurrent Version System)によってメンテナンスされています. CVSはソー スコード管理用のフリーソフトウェアで, FreeBSDのリリースにも含まれてい ます. FreeBSDのは米国カリフォルニア州のコンコルド市に存在 し, そこから世界中のたくさんのミラーサイトにコピーされています. CVSツ リーそのもの, そしてそのチェックアウトされたバージョンであるとはあな たのマシンにも簡単に取ってくることができます. これについてはの章をご覧ください. ソースツリー管理者

はCVSツリー への書き込み権限を持っている人, つまりFreeBSDのソースに変更を加えるこ とができる人です. (CVSでリポジトリに変更を加えるにはcvs(1) ``commit'' というコマンドを使うので, これらの人々は英語では ``committers'' と呼ばれます.) 開発者にコードを送って見てもらうのに一 番いい方法はコマンドを使うことです. もし, 何か問題があって send-prが使えないならにメー ルを送っていただいても結構です. FreeBSDコアチーム

はFreeBSDプロジェク トが会社だとすると取締役会にあたるものです. コアチームとして一番重要 な役割はFreeBSDプロジェクトが全体としてよい方向に向かっていることを確 認することです. 責任感あふれる開発者を上記のソースツリー管理者として 招くこと, また仕事上の都合などでコアチームをやめた人たちの後任を見つけ ることもコアチームの役割です. 現在のコアチームのほとんどは最初は単な る一開発者としてプロジェクトに関わりはじめ, ずるずるといつのまにか深み にはまってしまった人です.

コアチームのうち何人かは特定の を持っており, システムのうち一部に特に重点をおいて面倒を見ています. また, 忘れてほしくないのはコアチームのほとんどはFreeBSDについてはボラ ンティアであり, FreeBSDプロジェクトからは何ら金銭的な支援を受けていな いということです. ですから, ここでの「責任」は「保証されたサポート」 ではありません. そういう意味で, 上記の取締役会という例えはあまりよく ないかもしれません. むしろ, FreeBSDのために人生を棒に振ってしまった人 の集まりといった方が正しいかも.... ;) その他のコントリビュータ

最後になりますが, もっとも重要で多数をしめる開発者はフィードバック やバグフィクスをどんどん送ってくれるユーザ自身です. FreeBSDの開発に外 郭から関わっていきたいという人は &a.hackers; (を見てください) に参加するといいでしょう. FreeBSDのソースツリーに入っている何かを書いた人のは日に日に長くなっています. あ なたも今日, 何か送ることからはじめてみませんか? :-)

もちろんFreeBSDに貢献するにはコードを書くほかにもいろいろな方法があ ります. 助けが求められている分野については, このハンドブックのの節を見てください. ひとことで言うと, FreeBSDの開発組織はゆるやかな同心円状になっています. ともすると中央集権的に見えがちなこの組織は, FreeBSDのユーザが きちんと管理されたコードベースを容易に追いかけられるようにデザインされ ているもので, 貢献したいという人を締め出す意図は全くありません! 私た ちの目標は安定したオペレーティングシステムと簡単にインストールして使う ことのできるを提供することであ り, この方法は結構うまくはたらくのです. これからFreeBSDの開発にたずさわろうという人に, 私たちが望むことはただ 一つです: FreeBSDの成功を継続的なものにするために, 現在の開発者と同じ ような情熱を持って接してください! diff --git a/ja/handbook/dialup.sgml b/ja/handbook/dialup.sgml index f8f3b7ec60..1062b90d99 100644 --- a/ja/handbook/dialup.sgml +++ b/ja/handbook/dialup.sgml @@ -1,821 +1,821 @@ - + ダイアルインサービス

原作: &a.ghelmer;.

訳: &a.max;.6 September 1996. このドキュメントでは, FreeBSD で外部からのモデムによるアクセスを受け付 けるための設定に関してまとめてあります. このドキュメントは筆者が FreeBSD 1.0, 1.1 および 1.1.5.1 での経験と, 他の UNIX 系 OS での経験を 基に書いたものですが, 必ずしも十分な内容でないかもしれませんし, 掲載し た実例もあなたが今お使いの環境とは一致しないかもしれません. また, 筆者 はこのドキュメントに従って行われた作業でデータが失われたりシステムが破 壊されるようなことがあっても, 一切責任をとれません. 設定を始める前に

筆者は, 読者が FreeBSD に関する基本的な知識をもっていることを仮定して このドキュメントをまとめました. まず, FreeBSD が既にインストールされ ていて, UNIX 系環境においてファイルの編集の方法やシステムに付属のマニュ アルを参照する方法を知っている必要があります. また, 以下に示すように, FreeBSD の特定のバージョンが必要となりますし, いくつかの用語に関する 知識, そしてモデムや多少の配線に関する知識も必要となります. FreeBSD のバージョン

まず, FreeBSD のバージョンは 1.1 以上を使用してください (バージョン 2.x でもかまいません. ). FreeBSD 1.0 には, 2種類のシリアル ドライバ が含まれているので, 混乱の元となり得ます. また, FreeBSD のシリアル ディバイス ドライバ (用語解説

以下, 簡単にいくつかの用語について解説しておきます. これらの用語やデータ通信一般に関して, より詳しい情報が必要な場合は, 外づけモデムと内蔵モデムについて

ダイアルアップのサービスに関していえば, 外づけのモデムの方が適している ようです. これは, 多くの外づけのモデムは設定を不揮発ラムに書き込んで半 永久的に保存することができますし, また RS-232 に関する重要な情報を知る ための点滅するライトによるインディケータが搭載されているからです. 点滅 するライトは, システムを見に来た訪問者に強い印象を与えるという効果だけ でなく, モデムが適切に動作しているかどうかを知るためにも有効です. 一方, たいていの内蔵型のモデムには不揮発性ラムが搭載されていないため, ディップ スイッチの変更以外に設定を保存する方法がありません. また, も しインディケータがついていても, おそらくコンピュータのケース カバーが 外されていなければその状態を確認するのは難しいでしょう. モデムとケーブル

以下のことに関して, 予め知っておく必要があります. コンピュータとモデムの間での通信が行えるようにするための接続方 法. (内蔵型の場合は接続の必要はありません) お使いのモデムのコマンドについての知識, あるいはコマンドの解説 の在処 (通信ソフトを使っての) モデムの不揮発ラムに保存可能な設定の変更 方法 1番目のモデムの接続はたいてい簡単に行えるはずです. ほとんどのストレー ト シリアル ケーブルが使えるでしょう. 使用すべきケーブルは, 両端に適 切なコネクタ (DB-25 または DB-9 の雄または雌) のついた, DCE-DTE 間接 続用のもので, 以下の信号線が接続されていなければなりません. Transmitted Data ( Received Data ( Request to Send ( Clear to Send ( Data Set Ready ( Data Terminal Ready ( Carrier Detect ( Signal Ground ( FreeBSD で 2400bps 以上の転送速度を利用する場合には, フロー制御のため に シリアル インタフェースについて

FreeBSD では, NS8250-, NS16450-, NS16550- および NS16550A- に基づ いた EIA RS-232C (CCITT V.24) 規格のシリアル インタフェースをサポート しています. 8250 および 16450 ベースのディバイスには1文字のキャラクタ バッファが搭載されています. また, 16550 系のディバイスには, 16文字分 のバッファが搭載されていて, はるかによいパフォーマンスを得られます. (ただし, 無印の 16550 では, バグがあって 16 文字バッファが利用できませ んので, 可能であれば 16550A 系のディバイスを利用してください. ) 1文字 のバッファの物は, 16550 系のものと比べて OS にかける負荷が大きいので, 16550A 系ディバイスの利用を強く推奨します. 多数のシリアル ポートを利 用する場合や, 負荷の高いシステムにおいては, 16550A 系ディバイスを使う ことで, エラー発生率を低く押さえることができます. 概要

FreeBSD は以下の手順でモデムからのログインを受付ます. /dev/ttyd0) がオープンされるのを辛抱強く待ちます. 4850 ?? I 0:00.09 /usr/libexec/getty V19200 ttyd0 ユーザがモデムに電話をかけ, モデム同士が接続されると, モデムの /usr/bin/login を起動して, パスワードの入力を要求し, その 後ユーザのシェルを起動します. それでは, 続いて設定についての解説です. Kernel の設定

通常, FreeBSD の kernel は, PC-DOS の世界で /sbin/dmesg コマンドを使って, ブート時の出力メッセージ を確認してください. 特に, /sbin/dmesg | grep 'sio' たとえば, シリアル ポートを四つ持つシステムの場合は, 以下のようなシリ アル ポートに関するメッセージが kernel によって表示されます. sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A sio2 at 0x3e8-0x3ef irq 5 on isa sio2: type 16550A sio3 at 0x2e8-0x2ef irq 9 on isa sio3: type 16550A もし, kernel に正常に認識されないポートがある場合は, おそらくカスタマ イズした kernel を構築する必要があるでしょう. kernel 構築と構築のための設定に関しては, BSD System Manager's Manual の ``Building Berkeley Kernels with Config (config コマンドによる BSD kernel の構築) '' [ソース ファイルは /usr/src/share/doc/smm にあります]と ``FreeBSD Configuration Options'' [ /sys/conf/options および /sys/arch/conf/options.arch の archの部分をたとえばi386としたファイル ] を参照 してください. kernel の設定と構築をするためには, kernel のソース (FreeBSD 1.1 では srcdist/srcsys.??, FreeBSD 1.1.5.1 では srcdist/sys.??, またFreeBSD 2.0 では総てのソース)を展開 する必要があります. まだ自分のシステムの kernel 用のコンフィギュレーション ファイルを作っ ていない場合は, /sys/i386/conf に device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr device sio2 at isa? port "IO_COM3" tty irq 5 vector siointr device sio3 at isa? port "IO_COM4" tty irq 9 vector siointr システムに搭載されていないディバイスに関する記述は, コメントアウトまた は削除してしまってかまいません. Boca の BB2016 のようなマルチポートの シリアル ボードをお持ちの場合は, できませんので注意が必要です. (マルチポートのシリアル ボードの 場合は, 複数の 16550A ベースのポートで一つまたは二つの IRQ を共有する ための機構を備えています. ) コンフィギュレーション ファイルの編集が終わったら, ``Building Berkeley Kernels with Config (config コマンドによる BSD kernel の構築)'' および ディバイス スペシャル ファイル

kernel に組み込まれているほとんどのディバイスは, /dev ディレ クトリにある, 「ディバイス スペシャル ファイル」を介してアクセスされ ます. /dev/ttyd? およ び, 発信用の /dev/cua0? が利用されます. さらに, FreeBSD の 1.1.5 以降では, 初期化ディバイス (/dev/ttyi? と /dev/cuai0?)およびロッキング ディバイス (/dev/ttyld? と /dev/cual0?) も合わせて利用されます. 初期化ディバイスは, 通信 ポートがオープンされる度に, そのポートの初期設定を行うために使われます. たとえば, CTS/RTS によるフロー制御を行うモデムが接続されてい る場合の ディバイス スペシャル ファイルの作成

ディバイス スペシャル ファイルの管理は, ディレクトリ /dev にあるシェル スクリプト /dev に /dev/ttyd? のディバイス ファイルだけでなく, /dev/cua0? (および FreeBSD 1.1.5 以降では総ての初期化ディバイ スとロッキング ディバイスのスペシャル ファイル) も作成します. さらに, もしシリアル端末用のスペシャル ファイル/dev/tty0? が存在すれ ば, それらの削除も行います. ディバイス スペシャル ファイルの作成後, これらのファイルのパーミション が適切に設定されていて, これらのディバイスを利用してもよいユーザのみが 読み書きできるようになっていることを確認してください. (特に /dev/cua* のパーミションには注意を払ってください. ) この確認 を怠ると, 一般のユーザがあなたのモデムを使うことができるようなことにな りかねません. デフォルトの /dev/cua* のパーミションは, 以下の ようになっていて, たいていの場合適切なものだと思います. crw-rw---- 1 uucp dialer 28, 129 Feb 15 14:38 /dev/cua01 crw-rw---- 1 uucp dialer 28, 161 Feb 15 14:38 /dev/cuai01 crw-rw---- 1 uucp dialer 28, 193 Feb 15 14:38 /dev/cual01 上の設定では, ユーザ 設定ファイル

FreeBSD のシステムへのダイアル アップによるアクセスを実現するために編 集が必要と思われる設定ファイルが, /etc ディレクトリに三つあ ります. まず, /etc/gettytab には, /usr/libexec/getty デーモンの設定を記述します. つぎに, /etc/ttys に保存されている情報から, /sbin/init はど の /etc/rc.serial スクリプトに, それ以前のものならば /etc/rc.local スクリプトにシリアル ポートの初期化のためのコマ ンドを記述することができます. UNIX にダイアル アップ モデムを接続する方法には, 二つの考え方がありま す. 一つの方法は, ダイアル インしてくるユーザの接続速度に関係なく, 常 にモデムとローカルのコンピュータの RS-232 インタフェースの接続速度を一 定に保つように設定する方法です. この設定の長所は, ユーザがダイアル イ ンして接続されると, 即座にシステムからのログイン プロンプトが送信され るということです. 短所は, システムが実際のモデム間の速度を知ることがで きないために, Emacs のようなフル スクリーンのプログラムが, 端末との接 続速度が遅い場合でも, そのような場合に効果的な方法で画面出力を行わない 点です. もう一つは, モデムの RS-232 インタフェースとコンピュータの接続速度を, モデム間の接続速度に応じて変化させるような設定です. たとえば, モデム間 の接続が V.32bis (14.4 Kbps) ならば, モデムとコンピュータの間の接続を 19.2 Kbps とし, モデム間の接続が 2400 bps の時には, モデムとコンピュー タ間も 2400 bps で接続するような設定をします. この場合, <Enter> キーを繰り返し押さなければならない ということを知っていると仮定しています. もし接続速度が間違っている場合, /etc/gettytab

/etc/gettytab は, 固定速度の設定

モデムとコンピュータ間の通信速度を固定して使う場合, おそらく /etc/gettytab に特に変更を加える必要はないはずです. 可変速度の設定

/etc/gettytab に記述する必要があります. もし, 2400 bps のモ デムをお使いになるのであれば, 既存の # # Fast dialup terminals, 2400/1200/300 rotary (can start either way) # D2400|d2400|Fast-Dial-2400:\ :nx=D1200:tc=2400-baud: 3|D1200|Fast-Dial-1200:\ :nx=D300:tc=1200-baud: 5|D300|Fast-Dial-300:\ :nx=D2400:tc=300-baud: 高速モデムをお使いの場合は, おそらく /etc/gettytab に新たなエ ントリを追加する必要があります. 以下の例は, 14.4 Kbps のモデムを, 最 大インタフェース速度を 19.2 Kbps として利用するためのエントリです. # # Additions for a V.32bis Modem # um|V300|High Speed Modem at 300,8-bit:\ :nx=V19200:tc=std.300: un|V1200|High Speed Modem at 1200,8-bit:\ :nx=V300:tc=std.1200: uo|V2400|High Speed Modem at 2400,8-bit:\ :nx=V1200:tc=std.2400: up|V9600|High Speed Modem at 9600,8-bit:\ :nx=V2400:tc=std.9600: uq|V19200|High Speed Modem at 19200,8-bit:\ :nx=V9600:tc=std.19200: 上記の例を利用した場合, FreeBSD 1.1.5 以降ではパリティなし, 8ビットの 接続が行われます. FreeBSD 1.1 では, のエントリに追加することで, パリティなし, 8ビットの接続が行われますが, このパラメータを追加しなければ接続は偶数 パリティ, 7ビットになります. 上記の例では, まず 19.2 Kbps (V.32bis) によるモデムとコンピュータ間の 接続を試み, 続いて 9600 bps (V.32), 2400 bps, 1200 bps, 300 bpsと順に 試み, 再び 19.2 Kbps による接続を試みるという循環に入ります. この接続 速度の循環は, # # Additions for a V.32bis or V.34 Modem # Starting at 57.6 Kbps # vm|VH300|Very High Speed Modem at 300,8-bit:\ :nx=VH57600:tc=std.300: vn|VH1200|Very High Speed Modem at 1200,8-bit:\ :nx=VH300:tc=std.1200: vo|VH2400|Very High Speed Modem at 2400,8-bit:\ :nx=VH1200:tc=std.2400: vp|VH9600|Very High Speed Modem at 9600,8-bit:\ :nx=VH2400:tc=std.9600: vq|VH57600|Very High Speed Modem at 57600,8-bit:\ :nx=VH9600:tc=std.57600: もし, お使いの CPU が低速のものであったり, CPU に対する負荷が高い場合 で, 16650A 系のシリアル ポートをお使いでない場合, 57.6 Kbps の接続に おいて, sio の ``slio'' エラーが発生するかもしれません. /etc/ttys

/etc/ttys には, /etc/ttys は, /etc/ttys の既存の行を変更するか, あるいは新しい行を追加して, ttyd0 "/usr/libexec/getty xxx" dialup on 1番目の項目は, このエントリで対象とするディバイス スペシャル ファイル です. 上の例では /dev/ttyd0 を "/usr/libexec/getty (/etc/ttys の修正がすんだら, 以下のようなコマンドを使って /etc/ttys を 読み込み直させてください. kill -1 1 ただ, もし初めてシステムを設定しているのであれば, モデムが適切に設定さ れて接続されるまでは, 固定速度の設定

速度を固定する設定では, /etc/ttys の中で, ttyd0 "/usr/libexec/getty std.19200" dialup on 別の速度でモデムのポートのスピードを固定したい場合は, /etc/gettytab から適切なエントリを選んで, 上の例の std. として, 適切な速度のも のに置き換えてください. 可変速度の設定

可変速度の設定では, /etc/gettytab の中の適切な「自動速度調整」の初期設定のエントリを参照していなければな りません. たとえば, もし前述の 19.2 Kbps から接続を試みる可変速度の設 定例 ( ttyd0 "/usr/libexec/getty V19200" dialup on /etc/rc.serial または /etc/rc.local

V.32, V.32bis または V.34 モデムのような高速モデムを利用する場合, ハー ドウェア (RTS/CTS) フロー制御を行う必要があります. FreeBSD kernel のモデム ポートにハードウェア フロー制御のフラグを設定するため の /etc/rc.serial に, FreeBSD 1.1 では /etc/rc.local に 記述できます. たとえば, FreeBSD 1.1.5.1 の /etc/rc.serial のサンプルは以下 のとおりです. #!/bin/sh # # Serial port initial configuration stty -f /dev/ttyid1 crtscts stty -f /dev/cuai01 crtscts この例では, /etc/rc.local に追加されていました. # Set serial ports to use RTS/CTS flow control stty -f /dev/ttyd0 crtscts stty -f /dev/ttyd1 crtscts stty -f /dev/ttyd2 crtscts stty -f /dev/ttyd3 crtscts FreeBSD 1.1 には初期化のためのディバイス スペシャル ファイルがないので, ディバイス ファイルそのものにフラグを設定して, その後はフラグをクリア してしまうような極悪人が現れないことを願うしかありません. モデムの設定

もし, あなたのモデムがパラメータを不揮発ラムに保存できるタイプならば, PC-DOS 上の Telix や FreeBSD 上の 接続時に 接続時に 送信時フロー制御には XON/XOFF によるフロー制御を行わない. 受信時のフロー制御は Quiet mode (リザルト コードを返さない) コマンド エコーを返さない. これらを実現するためのコマンドやディップ スイッチの設定に関しては, モ デムのマニュアルを参照してください. 以下に, USRobotics Sportster の 14,400 bps の外づけモデムの設定例を示 しておきます. ATZ AT&C1&D2&H1&I0&R2&W ことのついでに, たとえば, V42.bis や MNP5 のデータ圧縮を使用するかど うかなどのモデムの他の設定について確認, 調整しておくのもよいかもしれま せん. さらに, USRobotics Sportster の 14,400 bps の外づけモデムでは, 以下の ようなディップ スイッチの設定も必要です. 他のモデムをお使いの方も, 以 下の例を設定の参考にしてください. スイッチ1: UP - DTR 標準 スイッチ2: 無視 (リザルト コードを単語形式にするか数値形式にす るか) スイッチ3: UP - リザルト コードを返さない スイッチ4: DOWN - コマンド エコーを返さない スイッチ5: UP - 自動着信 スイッチ6: UP - CD 標準 スイッチ7: UP - 不揮発ラムからデフォルト値をロードする スイッチ8: 無視 (Smart Mode/Dumb Mode) リザルト コードを返さないように設定しておかないと, 固定速度の設定

固定速度の設定では, モデムとコンピュータ間の通信速度をモデムとモデム間 の接続速度に関係なく, 常に一定に保つように, モデムを設定する必要があり ます. USRobotics Sportster の 14,400 bps 外づけモデムの場合, 以下のコ マンドで, モデムとコンピュータ間の速度が, コマンド送信時の速度に固定さ れます. ATZ AT&B1&W 可変速度の設定

可変速度の設定では, シリアル ポートの速度が, 着信速度に応じて変化する ように設定しなければいけません. USRobotics Sporster の 14,400 bps 外 づけモデムの場合, 以下のコマンドで, エラー訂正機能を利用した通信の場合 は, コマンドを送信した時の通信速度にシリアル ポートの速度を固定し, エ ラー訂正機能を利用しない接続では, シリアル ポートの速度が変化するよう に設定されます. ATZ AT&B2&W モデムの設定の確認

ほとんどの高速モデムには, 現在の設定をある程度人間にも理解できる形式に して表示させるコマンドがあります. USRobotics Sporster の 14,400 bps 外づけモデムの場合は, トラブルシューティング

以下の手順でダイアル アップ モデムの動作を確認することができます. FreeBSD システムの動作確認

モデムを FreeBSD システムに接続し, システムをブートします. あなたのモ デムにモデムの状態を確認するためのインジケータがあれば, 114 ?? I 0:00.10 /usr/libexec/getty V19200 ttyd0 115 ?? I 0:00.10 /usr/libexec/getty V19200 ttyd1 モデムにまだ着信がない状態の時に, 以下のように上とは異なる出力があった 場合, 114 d0 I 0:00.10 /usr/libexec/getty V19200 ttyd0 ^^ /etc/ttys の内容を確認し, 書式などに誤りがないか 調べてみてください. また, ログ ファイル /var/log/messages に /etc/ttys , /etc/gettytab の二つの設定ファイルと, ディバイス スペシャル ファイル /dev/ttyd? を確認し, 記述に誤りがないか, 足りないエ ントリがないか, 足りないディバイス スペシャルファイルがないかといった 点について調べてみてください. モデムで接続してみる

実際にモデムを使って別のコンピュータから接続してみてください. この時, 8ビット, パリティなし, 1ストップ ビットで接続するようにしてください. 接続後すぐにプロンプトが返ってこない場合や, 無意味な文字列が表示される 場合は, 1秒に1回くらいの割合で <Enter> キーを押してみて ください. しばらくたって, なおも BREAK 信号を送信してみてください. この時, 端末側で使って いるモデムが高速モデムならば, このモデムのインタフェースの接続速度を固 定してから, 再度ダイアル インしてみてください. (たとえば, USRobotics Sportster の場合は, AT&B1) それでもまだ /etc/gettytab の以下の点について再度確認してみてください. /etc/ttys の対応する行の 2番目の項目で, /etc/gettytab の中で定義されているエントリが指定されているか 各 /etc/gettytab の中で定義されているもの が指定されているか 各 /etc/gettytab の中で定義されているもの が指定されているか もしダイアル インしても, FreeBSD システム側のモデムが応答しない場合は, FreeBSD 側のモデムが 謝辞

以下の方々から, 多くのコメントやアドバイスをいただきました. ここに謝意 を表します. diff --git a/ja/handbook/diskless.sgml b/ja/handbook/diskless.sgml index 109428ad43..f9c6157536 100644 --- a/ja/handbook/diskless.sgml +++ b/ja/handbook/diskless.sgml @@ -1,163 +1,163 @@ - + Diskless operation

Contributed by &a.martin;. 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 - hostnameの表示/セット kernel - カーネル名の表示/セット rootfs - root ファイルシステムの表示/セット swapfs - swap ファイルシステムの表示/セット swapsize - diskless swapsize を Kbytes単位でセット diskboot - ディスクからのブート autoboot - ブートプロセスの続行 trans - トランシーバのオン|オフ flags [bcdhsv] - ブートフラグの設定 完全にディスクレスな場合の一般的な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経由でスワッピングを行う場合 (完全にディスクレスな場合の設定)、 クライアントが dd で使用する swap ファイルを作成します。 もし、swapfs コマンドが上記の例のように 引数 /swapfsを持ちそのサイズが 20000 である場合、 myclientに対するスワップファイルは /swapfs/swap.X.X.X.X で呼び出されます。 ここで X.X.X.X はクライアントのIPアドレスです。 例: # dd if=/dev/zero of=/swapfs/swap.192.1.2.4 bs=1k count=20000 また、スワッピングが開始されるとクライアントのスワップスペースは センシティブな情報を含むようになるので、不正なアクセスを防止するため、 このファイルへの読み書きのアクセス制限がなされていることを確認して下さい: # 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を作成します。 / および /usr ファイルシステムを共有して使用する

今のところ、これを行う公式に認められた方法はありませんが、 私はそれぞれのクライアントで /usr ファイルシステムと 個々の / ファイルシステム を共有して使っています。 どなたかこれをきちんと行うやり方の提案がありましたら、 私に、もしくは &a.core; グループに知らせてください。 特定の設定についてnetbootをコンパイルする

/sys/i386/boot/netboot/Makefile の中の設定を変更して コンパイルすることで、netbootでNE1000/2000 カードをサポートします。 このファイルの先頭にあるコメントを見てください。 diff --git a/ja/handbook/dma.sgml b/ja/handbook/dma.sgml index f3c9be5273..6666d0ca1f 100644 --- a/ja/handbook/dma.sgml +++ b/ja/handbook/dma.sgml @@ -1,478 +1,478 @@ - + DMAとはどういったものでどういう働きをするのか

Copyright © 1995 &a.uhclem;, All Rights Reserved. 18 October 1995. 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回で 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コントローラに要求を伝えることで開始します. 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内のアドレスレジスタはインクリメントされ, 何バイト転送すればよいかを示すカウンタがデクリメントされます. カウンタが0になると, DMAはカウンタが0になったことを示すEOP信号を 送り, DMAコントローラがCPUによって再びプログラムされるまで これ以上データは転送されなくなります. このイベントはターミナルカウント(TC)とも呼ばれます. EOP信号は1本しかありません. なぜならどんな時もただ1つのDMAチャネル のみをアクティブにすることができるためです. もし, バッファの転送が完了した時に周辺機器から割り込みを発生させたい とき, 周辺機器は -DACK信号およびEOP信号の両方が同時に発信されたか どうかをテストします. それが生じると, DMACはCPUの介在がなければ これ以上はその周辺機器についての情報を転送しないことを意味します. すると周辺機器はプロセッサの注意を得るために割り込み信号のうちの1つを 発信します. 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操作が 終了するまでそこに保持されます. これらのラッチは「ページレジスタ」と呼ばれます. そのため上記に示した例では, DMACはアドレスの0x3456の部分をバス上に 置き, DMAチャネル2に対するページレジスタは, 0x0012xxxxをバス上に 置きます. これらの2つの値が組み合わされてアクセスされるメモリ中の完全な アドレスを形成します. ページレジスタのラッチはDMAチップとは独立であるので, 読み込まれる又は書き込まれるメモリ領域は, 64kの物理的境界を またいではなりません. もしDMACがメモリの0xffff番地をアクセスすると, DMACはアドレスレジスタを インクリメントします. 次にアクセスされるバイトは 0x0000番地に なるでしょう. 0x10000ではありません. これはおそらく意図されたものとは異なっているでしょう. 注: 「物理的な」 64Kの境界を 8086モードの 64k「セグメント」と混同してはいけません. セグメントは, セグメント レジスタにオフセットレジスタを加算して作られるものです. ページレジスタにはアドレスのオーバーラップはありません. さらに複雑なことには, PC/ATでは外部のDMAアドレスのラッチは 8ビットしか保持しません. よって8+16で24ビットになり, これは DMAが0から16メガの間のメモリ番地しか指し示せないことを 意味します. 16メガ以上のメモリを持ったより新しいマシンにおいても, PCコンパチブルなDMAでは16メガ以上の番地にはアクセスできません. この制限を避けるために, オペレーティングシステムは 16メガ以下にある物理的な64kの境界をまたがない領域にバッファを 予約します. そして, DMACはデータをそのバッファに読み出すように プログラムされます. 一旦DMACこのバッファにデータを動かすと, オペレーティングシステムは本当にデータを格納したいアドレスに バッファからデータをコピーします. 16メガを越えるアドレスからDMAベースの周辺機器にデータを 書き込む際には, データは16メガ以下に位置したバッファから最初に コピーされなくてはならず, その後, DMACはバッファからハードウェアに データをコピーすることができます. FreeBSDでは, これらの予約バッファは 「バウンスバッファ」と呼ばれます. MS-DOSの世界では, これらは「スマートバッファ」などと呼ばれます. DMA操作モードとその設定

8237 DMA はいくつかのモードで動作します. 主なモードは, 以下のとおりです. シングル転送モード シングルバイト(もしくはワード)が転送されます. DMAは1バイト毎にバスを開放し, 再び要求しなくてはなくてはなりません. これは一般に, すぐにはデータのブロック全てを転送できないデバイスに よって使用されます. 周辺装置は次の転送の準備ができる毎にDMAを要求します. フロッピーディスクコントローラは1バイトのバッファしか持たないので, このモードを使用します. ブロック/デマンド転送モード 一旦DMACがシステムバスを取得すると, 最大64kまでのデータブロック 全体が転送されます. もし周辺装置が余分に時間を必要とするときは, READY信号を有効に します. READY信号は過度に使われるべきではなく, 遅い周辺装置の転送の場合は シングル転送モードを代わりに使うべきです. ブロック転送モードとデマンド転送モードの違いは, 一旦ブロック転送が 始まると,転送カウンタか0になるまでそれが行われるところです. 1バイト転送するにはDRQが -DACK が有効になるまでの間だけ 有効であれば充分です. デマンドモードはDRQが有効な間は転送が続けられます. DRQが無効に なったことで中断された転送は, DRQがその後 有効になったときに, 転送が中断したところから再開されます. CPUを使ってデータを読み出した方が効率がよくなるくらい CPUの速度が向上するより前の 古いハードディスクコントローラはデマンドモードを使っていました. カスケード転送モード このメカニズムはDMAチャネルがバスを要求することを許可する ものですが, 接続されたデバイスはバス上のアドレス情報の配置に ついて責任を持ちます. これはいわゆる「バスマスタ」というものです. カスケードモードのDMAチャネルがバスのコントロールを受け取ると, DMAは通常行われるようなバス上のアドレスとI/Oコントロール信号の 出力を行いません. 代わりに, DMAはこのチャネルの -DACK信号を 有効にします. そして, アドレスとバスコントロール信号の供給は DMAチャネルに接続されたデバイスが担当します. 周辺機器はシステムバスの完全なコントロールを行い, 16メガ以下の任意のアドレスの読み込みおよび書き込みを行うことが できます. 周辺機器はバスの使用を終えると, DRQ線を無効にして, DMAコントローラはCPUもしくは他のDMAチャネルに制御を返します. カスケードモードは複数のDMAコントローラを相互接続するのに 使われます. PC内ではDMAチャネル4がまさにこの用途に使われています. 周辺機器がDMAチャネル0, 1, 2, 3でバスを要求すると, スレーブDMAコントローラは HLDREQ を有効にしますが, この線は実際にはプライマリDMAコントローラのDRQ4に接続されています. プライマリのDMAコントローラはその後 HLDREQ を使ってCPUにバスを 要求します. バスが与えられると, -DACK4が有効になり, この線は実際にはスレーブDMAコントローラの HLDA信号に接続されています. スレーブDMAコントローラはその後要求したDMAチャネルに対して データを転送するか, バスマスタリングを要求する周辺機器にバスを 許可します. このような配線がおこなわれているため, PC/ATシステムではDMAチャネルは 0, 1, 2, 3, 5, 6, 7のみが使用できます. 注: 初期のIBM PCコンピュータでは, DMAチャネル0は操作の リフレッシュのために予約されていますが, 最近のシステムでは通常, 周辺機器によって使用することができます. 周辺機器がバスマスタリングを行っている時は, システムバスを保持している間絶えずメモリにもしくはメモリから データを転送することが重要です.もし, 周辺機器がこのように できないときは, システムがメモリのリフレッシュを行なえるように しばしばバスを開放しなくてはなりません. メモリの読み込みと書き込みのサイクルはリフレッシュサイクルとして カウントされる(リフレッシュサイクルは実際には不完全なメモリ 読み込みサイクルになります)ので, 周辺機器のコントローラが連続するメモリ番地からデータの読み込み または書き込みを行う間は, メモリの全てをリフレッシュされます. バスマスタリングはいくつかの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 0x02 write Channel 0 starting word count 0x02 read Channel 0 remaining word count 0x04 write Channel 1 starting address 0x04 read Channel 1 current address 0x06 write Channel 1 starting word count 0x06 read Channel 1 remaining word count 0x08 write Channel 2 starting address 0x08 read Channel 2 current address 0x0a write Channel 2 starting word count 0x0a read Channel 2 remaining word count 0x0c write Channel 3 starting address 0x0c read Channel 3 current address 0x0e write Channel 3 starting word count 0x0e read Channel 3 remaining word count DMA コマンドレジスタ 0x10 write Command Register 0x10 read Status Register 0x12 write Request Register 0x12 read - 0x14 write Single Mask Register Bit 0x14 read - 0x16 write Mode Register 0x16 read - 0x18 write Clear LSB/MSB Flip-Flop 0x18 read - 0x1a write Master Clear/Reset 0x1a read Temporary Register 0x1c write Clear Mask Register 0x1c read - 0x1e write Write All Mask Register Bits 0x1e read - 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 0xdc write Clear Mask Register 0xdc read - 0xde write Write All Mask Register Bits 0xde read - 0x80 - 0x9f DMA ページレジスタ

0x87 r/w DMA Channel 0 0x83 r/w DMA Channel 1 0x81 r/w DMA Channel 2 0x82 r/w DMA Channel 3 0x8b r/w DMA Channel 5 0x89 r/w DMA Channel 6 0x8a r/w DMA Channel 7 0x8f Refresh diff --git a/ja/handbook/eresources.sgml b/ja/handbook/eresources.sgml index 974a039e04..7b6a6f15a6 100644 --- a/ja/handbook/eresources.sgml +++ b/ja/handbook/eresources.sgml @@ -1,375 +1,375 @@ - + インターネット上のリソース

原作: &a.jkh;.

訳: &a.yuki;.28 August 1996

FreeBSDの進歩が急速であるため, 最新の開発をフォローするためには, 印刷したメディアは実用的でなくなっています. 大抵の場合, 最新情報を入手する方法としては, 電子的なリソースが ベストです. FreeBSDはボランティアの努力によって, ユーザコミュニティ自体が, 一種の「テクニカルサポート部門」としての 役割も通常果たしており, 電子メールやUsenetのニュースがこれらのコミュ ニティにたどり着く最も効果的な方法になっています. 以下に, FreeBSD ユーザコミュニティに連絡を取る場合の最も重要な点についての 概略を示します. もしここに書かれていない他のリソースに気がついた場合は, それらを &a.doc に送って頂ければ, それらをここに含めるかもしれません. メーリングリスト

多くのFreeBSDの開発メンバはUSENETを読むことができますが, もし, comp.unix.bsd.freebsd.*のグループの一つに質問を投稿したとしても タイムリにその質問を受け取るということは保証できません. 質問を適切なメーリングリストに投稿すれば, 私たちかFreeBSDの関係者から, よりよい (そして少なくともより早い) 反応がいつでも得られることでしょう.

さまざまなメーリングリストの憲章をこのドキュメントの最後に記載します. 私たちは, メーリングリストの質, 特に技術面に関する質を高く保つために 努力しているので, メーリングリストに参加する前にその憲章を読んでください. メーリングリストはいずれもアーカイブされており, それらは で検索することができます. キーワード検索可能なアーカイブの提供は, 良くある質問に対する回答を見つけるすぐれた方法ですから, 質問を投稿する前に調べてみるべきでしょう. メーリングリストの概説

一般的なメーリングリスト: 以下のものは誰でも自由に参加できる 一般的なものです: リスト 目的 ---------------------------------------------------------------------- freebsd-announce 重要なイベントやプロジェクトのマイルストン freebsd-bugs バグレポート freebsd-chat FreeBSDコミュニティに関連する技術的ではない話題 freebsd-current FreeBSD-currentの使用に関連する議論 freebsd-stable FreeBSD-stableの使用に関連する議論 freebsd-isp FreeBSDを用いているインターネットサービスプロバイダの話題 freebsd-questions ユーザからの質問 技術的なメーリングリスト: 以下のメーリングリストは, 技術的な議論のためのものです. これらのメーリングリストに入る前には憲章を注意深く読むべきであり, メーリングリストに投稿するメッセージがガイドラインの範囲に収まるようにしてください. リスト 目的 ---------------------------------------------------------------------- freebsd-doc FreeBSDのドキュメンテーションプロジェクト freebsd-emulation Linux/DOS/Windowsのような他のシステムのエミュレーション freebsd-fs ファイルシステム freebsd-hackers 一般的な技術の議論 freebsd-hardware FreeBSDの走るハードウェアの一般的な議論 freebsd-mobile モーバイルコンピューティングについての議論 freebsd-multimedia マルチメディアの議論 freebsd-platforms Intel以外のアーキテクチャのプラットフォームへの移植 freebsd-ports portsコレクションに関する議論 freebsd-security セキュリティに関する話題 freebsd-security-notifications セキュリティに関する通知 (モデレーテッドメーリングリスト) freebsd-scsi SCSIサブシステム freebsd-smp 対称/非対称のマルチプロセッシングの設計に関する議論 制限されているメーリングリスト: 以下のメーリングリストは参加するには認可が必要ですが, 提案やコメントは誰でも自由に投稿することができます. これらの制限されているメーリングリストへの参加の伺いの前に, 技術的なメーリングリストで存在を確立するのがよい考えです. メーリングリスト 目的 ---------------------------------------------------------------------- freebsd-admin 管理に関する話題 freebsd-arch アーキテクチャや設計の議論 freebsd-core FreeBSDコアチーム freebsd-hubs ミラーサイトを運営している人達 (基盤のサポート) freebsd-install インストール関係の開発 freebsd-user-groups ユーザグループの調整 CVSメーリングリスト: 以下のメーリングリストはソースツリーの さまざまな場所の変更のログメッセージを見ることに興味のある人向けです. メーリングリスト ソースの範囲 (ソースの) 範囲の説明 ---------------------------------------------------------------------- cvs-CVSROOT /usr/src/[A-Z]* /usr/src/ 以下のトップレベルのファイルの変更 cvs-all /usr/src ツリーのすべての変更 (スーパーセット) cvs-bin /usr/src/bin システムバイナリ cvs-etc /usr/src/etc システムファイル cvs-games /usr/src/games ゲーム cvs-gnu /usr/src/gnu GPLにしたがったユーティリティ cvs-include /usr/src/include インクルードファイル cvs-kerberosIV /usr/src/kerberosIV Kerberos暗号化コード cvs-lib /usr/src/lib システムライブラリ cvs-libexec /usr/src/libexec システムバイナリ cvs-ports /usr/ports 移植済みソフトウェア cvs-sbin /usr/src/sbin システムバイナリ cvs-share /usr/src/share システム共有ファイル cvs-sys /usr/src/sys カーネル cvs-usrbin /usr/src/usr.bin ユーザバイナリ cvs-usrsbin /usr/src/usr.sbin システムバイナリ 参加方法

どのメーリングリストもFreeBSD.ORGにあるので, メーリングリストにメールを送るには, ただ listname@FreeBSD.ORG にメールを送るだけです. すると, メーリングリストに登録されている世界中のメンバに再配布されます. メーリングリストに参加するには, subscribe [] という内容をメッセージの本文に含むメールを &a.majordomo に送ります. 例えば, freebsd-announce に参加したい場合は次のようにします: % mail majordomo@FreeBSD.ORG subscribe freebsd-announce ^D もし, あなたが, 自分自身を違う名前 (メールアドレス) で登録したい場合, あるいは, ローカルなメーリングリスト (注意:もしあなたのサイトに, 興味を持った仲間がいるなら, これはより有効ですし, 私たちにとっても非常に嬉しいことです.) を登録する申し込みをおこないたいのであれば, 次のようにします: % mail majordomo@FreeBSD.ORG subscribe freebsd-announce local-announce@somesite.com ^D 最後に, majordomoに対して 他のタイプのコントロールメッセージを送ることで メーリングリストから脱退したり, メーリングリストの他のメンバのリストを 得たり, 再びメーリングリストのリストを見たりすることも可能です. 利用できるコマンドの完全なリストを入手するには, 次のようにします: % mail majordomo@FreeBSD.ORG help ^D 再度言いますが, 私たちは技術的なメーリングリストでは技術的な議論を保つよう 要求します. もし, 「高いレベル」にのみ興味があるなら, freebsd-announce に参加するように勧めます. これは少ないトラフィックの予定です. メーリングリストの憲章

管理上の話題 重要なイベント/マイルストン これは, 単にたまに発表される重要なfreebsdのイベントに関心がある人のための メーリングリストです. これは, スナップショットやその他のリリースについての アナウンスを含みます. そのアナウンスは新しいFreeBSDの機能のアナウンスを含んでいます. ボランティア等の呼びかけがあるかもしれません. これは流通量の少ないメーリングリストです. アーキテクチャと設計の議論 これは, FreeBSDの設計に関する議論をする人向けのメーリングリストです. これは, クローズドなリストで, 一般的には参加できません. バグレポート これは, FreeBSDのバグレポートのためのメーリングリストです. 可能である場合はいつでも, バグは ``send-pr'' を使って送られる必要があります. コミュニティに関する技術的ではない話題 このメーリングリストは技術的ではなく, 社会的な情報について, 他のメーリングリストでは取り扱わない話題を含みます. これは, Jordanがシロイタチに似ているかどうか, 大文字で打つかどうか, 誰がたくさんコーヒーを飲むか, どこのビールが一番うまいか, 誰が地下室でビールを作っているか, などについての議論を含みます. 時々重要なイベント (将来開催されるパーティーや, 結婚式, 誕生日, 新しい仕事など) のお知らせが, 技術的なメーリングリストから でてきます. しかし, フォローは直接 -chatメーリングリストにするべきです. FreeBSDコアチーム これは, コアメンバが使う内部メーリングリストです. FreeBSD-currentの使用に関する議論 これは freebsd-current のユーザのためのメーリングリストです. メーリングリストでの話題は, -current で登場した新しい機能について, その新機能によってユーザに影響することについての注意, および -current のままでいるために必要な手順についての説明を含みます. "current" を走らせている人はこのメーリングリストに登録しなくてはなりません. FreeBSD-currentの使用に関する議論 freebsd-currentメーリングリストのダイジェスト版です. このダイジェストはfreebsd-currentに送られたすべてのメッセージをまとめたものを, 1つのメールにして送り出します. 平均のサイズは約40kbyteです. FreeBSD-stableの使用に関する議論 これは freebsd-stable のユーザ用のメーリングリストです. メーリングリストでの話題は, -stable で登場した新しい機能について, そ の新機能によってユーザに影響することについての注意, および -stable のままでいるために必要な手順についての説明を含みます. "stable" を走らせている人はこのメーリングリストに登録すべきです. ドキュメンテーションプロジェクト このメーリングリストはFreeBSD Doc Projectに属し, ドキュメンテーションに関連する問題やプロジェクトの議論のためのものです. ファイルシステム FreeBSDのファイルシステムに関する議論 技術的な議論 これはFreeBSDに関する技術的な議論のためのフォーラムです. これは最もテクニカルなメーリングリストです. このメーリングリストは, FreeBSD 上でアクティブに活動をしている人のためのもので, 問題を持ち出したり, 代わりの解決法を議論します. 技術的な議論をフォローするのに興味がある人も歓迎します. 技術的な議論 freebsd-hackersメーリングリストのダイジェスト版です. このダイジェストはfreebsd-hackersに送られたすべてのメッセージをまとめたものを, 1つのメールにして送り出します. 平均のサイズは約40kbyteです. FreeBSDのハードウェアの一般的な議論 FreeBSDが走っているハードウェアのタイプや, 何を買ったり避けたりするかに関する様々な問題や, 提案に関する議論. インストールに関する議論 このメーリングリストは将来のリリースのインストールに関する開発の 議論のためのものです. インターネットサービスプロバイダのについての話題 このメーリングリストは, FreeBSDを用いたインターネット サービスプロバイダ (ISP) に関する話題の議論のためのものです. マルチメディアについての議論 このメーリングリストはFreeBSD上を用いたマルチメディアアプリケーションについてのフォーラムです. マルチメディアアプリケーションをとりまく議論の中心は, それらのインストール, 開発, そしてFreeBSDにおけるサポートについてです. Intel以外のプラットフォームへの移植 クロスプラットフォームのFreeBSDの問題. Intel以外のプラットフォームへのFreeBSDの移植についての一般的な議論や提案. ``ports'' の議論 FreeBSD の ``ports コレクション'' (/usr/ports) や, 移植の提案, ports コレクションの基盤の変更, 一般的な整合化活動についての議論. ユーザからの質問 FreeBSDに関する質問のためののメーリングリストです. その質問がかなり技術的だと思わないのであれば, 「どのようにして」という質問を技術的なメーリングリストに送るべきではありません. ユーザからの質問 freebsd-questionsメーリングリストのダイジェスト版です. このダイジェストはfreebsd-questionsに送られたすべてのメッセージをまとめたものを, 1つのメールにして送り出します. 平均のサイズは約40kbyteです. SCSIサブシステム これはFreeBSDのためのscsiサブシステムについて作業している人向けです. セキュリティの関連の話題 FreeBSDコンピュータのセキュリティの話題 (DES, Kerberos, よく知られている セキュリティホールや, それらのふさぎ方など) セキュリティ関連の通知 FreeBSD のセキュリティ問題や, 修正に関する通知を行ないます. このメーリングリストは議論を行なうためのメーリングリストではありません. 議論は FreeBSD-security で行ないます. ユーザグループの調整のメーリングリスト これは, ローカルなユーザグループがお互いに, または, コアチームが指定した個人と問題を議論する, それぞれのローカルエリアのユーザグループからの調整人向けの メーリングリストです. このメーリングリストはユーザグループ間の ミーティングの概要やプロジェクトの調整に制限されるべきです. Usenet ニュースグループ

2つのFreeBSD用のニュースグループがあります. ここでは FreeBSDの議論をするたくさんの様々な人がおり, 他にもFreeBSD関連するユーザがいます. これらのいくつかのニュースグループは Warren Toomey <wkt@cs.adfa.oz.au> によって で, 検索できるようになっています. BSD用のニュースグループ

関連する他のUnixのニュースグループ

X Window システム

World Wide Web サイト

- 本家のサーバ. - オーストラリア. - ブラジル. - カナダ. - チェコ. - デンマーク. - エストニア. - フィンランド. - ドイツ. - アイルランド. - 日本. - 韓国. - ニュージーランド. - ポルトガル. - スウェーデン. - 台湾. diff --git a/ja/handbook/esdi.sgml b/ja/handbook/esdi.sgml index 3e3ca2612a..bca286f33a 100644 --- a/ja/handbook/esdi.sgml +++ b/ja/handbook/esdi.sgml @@ -1,418 +1,418 @@ - + ESDIハードディスクの使い方

原作および Copyright © 1995, &a.wilko;.24 September 1995.

訳: &a.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のニュースグループ は, 詳しい情報を得ることができる注目すべきもので す. World Wide Web (WWW) もまた便利な情報源です. Adaptec社の ESDIコントロー ラについては を参照ください. Western Digital社のコントローラについては を参照ください. 感謝

Andrew Gordon氏より, テスト用の Adaptec 2320コントローラと ESDIディス クを送っていただきました. diff --git a/ja/handbook/firewalls.sgml b/ja/handbook/firewalls.sgml index d7e63cce10..7a23678d7f 100644 --- a/ja/handbook/firewalls.sgml +++ b/ja/handbook/firewalls.sgml @@ -1,579 +1,579 @@ - + ファイアウォール

原作: &a.gpalmer;, &a.alex;.

訳: &a.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 は, カーネル内部にあって パケットのフィルタリングとアカウンティングをおこなうシステムであり, ユーザ側のコントロールユーティリティである ipfw(8) を 含んでいます. ルーティングの決定をおこなう際に, これらは互いに協力して, カーネルで使用されるルールを定義したり, 現在使用されているルールを 問い合わせたりすることができます.

IPFW は互いに関連する二つの部分からなっています. ファイアウォールセクションはパケットフィルタリングをおこないます. また, IP アカウンティングセクションはファイアウォールセクションのものと 似たルールに基づいてルータの使用を追跡します. これにより, (例えば) 特定のマシンからルータへのトラフィックがどのくらい 発生しているか調べたり, どれだけの WWW (World Wide Web) トラフィックが フォワードされているかを知ることができます.

IPFW は, ルータではないマシンにおいても入出力コネクションの パケットフィルタリングのために使用することができるように設計されています. これは一般的な IPFW の使用法とは異なる特別な使い方ですが, こういった状況でも同じコマンドとテクニックが使用されます. FreeBSD で IPFW を有効にする

IPFW システムの中心となる部分はカーネル内部にあります. そのため, どのファシリティ (機能) を必要とするかによって, 一つまたは それ以上のオプションをカーネルコンフィグレーションファイルに追加し, カーネルを再コンパイルする必要があるでしょう. カーネルの再コンパイル方法の詳細については, を参照してください.

現在, IPFW に関係するカーネルコンフィグレーションオプションは 三つあります: syslogd(8) を通じて パケットのログを取るためのコードを有効にします. フィルタルールでパケットのログを取るように指定しても, このオプションが指定されていなければ, ログを取ることはできません. syslogd(8) を通じて ログを取るパケットの数をエントリ毎に制限します. 敵対的な環境においてファイアウォールの動作のログを取りたいけれど, syslog の洪水によるサービス拒絶攻撃に対し無防備でありたくないという場合に, このオプションを使用したいと思うことがあるかもしれません.

チェーンエントリのログが指定された制限数に達すると, そのエントリに関するログ取りは停止されます. ログ取りを再開するには, ipfw(8) ユーティリティを使用して 関連するカウンタをリセットする必要があります: ipfw zero 4500 4500 とは, ログ取りを続行したいチェーンエントリの番号です. 以前のバージョンの FreeBSD は IPFIREWALL_ACCT というオプションを 持っていました. しかし, ファイアウォールコードがアカウンティングファシリティ (機能) を 自動的に含むようになったため, 現在では使用されることはなくなっています. IPFW の設定

IPFW ソフトウェアの設定は ipfw(8) ユーティリティを 通じておこないます. このコマンドの構文は非常に複雑に見えますが, 一旦その構造を理解すれば比較的単純です.

このユーティリティでは今のところ四つの異なるコマンドカテゴリが 使用されています: それは追加 / 削除, 表示, フラッシュ, およびクリアです. 追加 / 削除はパケットの受け入れ, 拒絶, ログ取りをどのようにおこなうか というルールを構築するのに使用します. 表示はルールリスト (またはチェーン) と (アカウンティング用) パケットカウンタの 内容を調べるのに使用します. フラッシュはチェーンからすべてのエントリを取り除くのに使用します. クリアは一つまたはそれ以上のアカウンティングエントリをゼロにするのに 使用します. IPFW ルールの変更

この形式での使用法は: ipfw [-N] コマンド [index] アクション [log] プロトコル アドレス [ オプション ]

この形式で使用する際に有効なフラグは一つだけです: コマンド は一意である限り短縮可能です. 有効な コマンド は: 以前のバージョンの IPFW では, ファイアウォールエントリと パケットアカウンティングエントリが別々に利用されていました. 現在のバージョンでは, それぞれのファイアウォールエントリ毎に パケットアカウンティングエントリが備えられています.

index が指定されていると, エントリはチェーン中の index で示される位置に置かれます. index が指定されて いなければ, エントリは (65535 番のデフォルトルールである パケット拒絶を別にして) 最後のチェーンエントリの index に 100 を足した 位置 (チェーンの最後) に置かれます.

カーネルが IPFIREWALL_VERBOSE つきでコンパイルされている場合, log オプションはマッチしたルールをシステムコンソールに出力させます.

有効な アクション は: pass および accept)

それぞれの アクション は一意な先頭部分だけでも認識されます. 指定可能な プロトコル は以下の通り:

アドレス の指定は: from <address/mask>[port] to <address/mask>[port&rsqb [via <interface>]

port はポートをサポートする プロトコル (UDP と TCP) の 場合にだけ指定可能です.

via は必須ではなく, 特定のインターフェースを通ってきたパケット だけにマッチするように, IP アドレスまたはローカル IP インターフェースの ドメイン名, またはインターフェース名 (例えば ed0) を 指定することができます. インターフェースユニット番号はオプションで, ワイルドカードで指定することが できます. 例えば, ppp* はすべてのカーネル PPP インターフェースに マッチします.

<address/mask> の指定は: <address> または <address>/mask-bits または <address>:mask-pattern

IP アドレスのかわりに有効なホスト名を指定することも可能です. mask-bits はアドレスマスクで上位何ビットを１にするべきかを 示す十進数値です. 例えば次の指定, 192.216.222.1/24 はクラス C のサブネット (この場合 192.216.222) の任意のアドレスにマッチする マスクを作成します. mask-pattern は与えられたアドレスと 論理 AND される IP アドレスです. キーワード any は「任意の IP アドレス」を指定するために 使用することができます.

ブロックするポート番号は以下のように指定します: port[,port[,port[...]]] のように単独のポートまたはポートのリストを指定します. または port-port のようにポートの範囲を指定します. 単独のポートとポートのリストを 組み合わせて指定することも可能ですが, その場合は常に範囲の方を 最初に指定しなければなりません.

使用可能な オプション は: spec/IP ヘッダが spec に指定された カンマで区切られたオプションのリストを含んでいればマッチします. サポートされている IP オプションのリストは: ssrr (ストリクトソースルート), lsrr (ルーズソースルート), rr (レコードパケットルート), そして ts (タイムスタンプ) です. 特定のオプションを含まないことを指定するには '!' を先頭につけます. established ルールをチェーンの最初の方に置くことで, ファイアウォールのパフォーマンスを向上させることができます. flags/TCP ヘッダが flags に指定された カンマで区切られたフラグのリストを含んでいればマッチします. サポートされているフラグは, fin, syn, rst, psh, ack と urg です. 特定のフラグを含まないことを指定するには '!' を先頭につけます. types/ICMP タイプが types リストに 存在していればマッチします. リストはタイプの範囲または個々のタイプを カンマで区切った任意の組合せで指定できます. 一般的に使用されている ICMP タイプは: 0 エコーリプライ (ping リプライ), 5 リダイレクト, 8 エコーリクエスト (ping リクエスト), そして 11 時間超過 (traceroute(8) で使用されているように, TTL 満了を示すのに使用されます) です. IPFW ルールリストの表示

この形式での使用法は: ipfw [-atN] l

この形式で使用する際に有効なフラグは三つあります: ipfw(8) ユーティリティで使用される入力形式と 互換性がありません. IPFW ルールのフラッシュ

チェーンをフラッシュするには: ipfw flush

カーネルに固定されているデフォルトルール (インデックス 65535 番) 以外の, ファイアウォールチェーンの中のすべてのエントリを削除します. デフォルトではすべてのパケットが拒絶されるので, 一旦これを実行すると, パケットを許可するエントリがチェーンに追加されるまで, あなたのシステムがネットワークから切り放されてしまいます. そのため, ルールのフラッシュをおこなうときは注意が必要です. IPFW パケットカウンタのクリア

一つまたはそれ以上のパケットカウンタをクリアするためには: ipfw zero [index]

index が指定されていなければ, すべてのパケットカウンタが クリアされます. index が指定されていれば, 特定のチェーンエントリだけが クリアされます. ipfw に対するコマンドの例

このコマンドはルータを介して転送される, ホスト evil.hacker.org から ホスト nice.people.org の telnet ポートへの すべてのパケットを拒絶します: ipfw add deny tcp from evil.hacker.org to nice.people.org 23

次の例は, ネットワーク hacker.org (クラス C) 全体から マシン nice.people.org (の任意のポート) への 任意の TCP トラフィックを拒絶し, ログを取ります. ipfw add deny log tcp from evil.hacker.org/24 to nice.people.org あなたの内部ネットワーク (クラス C のサブネット) に対する X セッションを 張れないようにする場合, 以下のコマンドで必要なフィルタリングがおこなえます: ipfw add deny from any to my.org/28 6000 setup sup.FreeBSD.ORG の SUP サーバへのアクセスを許可するためには, 以下のコマンドを使用します: ipfw add accept from any to sup.FreeBSD.ORG 871 アカウンティングレコードを見るには: ipfw -a list または短縮形式で ipfw -a l 最後にチェーンエントリがマッチした時刻を見ることもできます. ipfw -at l パケットフィルタリングファイアウォールの構築

注: 以下の提案は, ただの提案にすぎません: 必要な処理はそれぞれのファイアウォールで異なるため, あなた独自の要求にあったファイアウォールを構築する方法を ここで述べることはできないのです.

最初にファイアウォールをセットアップするとき, コントロールされた環境でファイアウォールホストの設定がおこなえるような テストベンチセットアップが用意できない場合には, カーネルのログ取りを 有効にしてログ取り版のコマンドを使用することを強くおすすめします. そうすることで, 大した混乱や中断なしに問題となる範囲の特定と処置を 素早くおこなうことができます. 初期セットアップフェーズが完了してからであっても, アタックの可能性のあるアクセスをトレースしたり, 要求の変化に応じてファイアウォールルールを変更したりできるので, `deny' に対するログ取りをおこなうことをおすすめします. 注: accept コマンドのログ取りをおこなっていると, ファイアウォールをパケットが一つ通過する毎に 1 行のログが生成されるため 大量の ログデータが発生します. そのため, 大規模な ftp/http 転送などをおこなうと, システムが非常に 遅くなってしまいます. また, パケットが通過するまでにカーネルにより多くの仕事を要求するため, パケットのレイテンシ (latency) を増加させてしまいます. syslogd もログをディスクに記録するなど, より多くの CPU タイムを 使用し始め, 実に容易に /var/log が置かれているパーティションを パンクさせてしまう可能性があります.

現状では, FreeBSD はブート時にファイアウォールルールをロードする 能力を持っていません. 私は /etc/netstart スクリプトにロードをおこなうスクリプトを 追加することをおすすめします. IP インターフェースの設定がおこなわれる前に ファイアウォールの設定がおこなわれるように, netstart ファイル中の 充分に早い位置にルールをロードするスクリプトを配置してください. こうすることで, ネットワークがオープンな間は常に抜け道が塞がれている ことになります.

ルールをロードするために使用するスクリプトは, あなたが作成しなければなりません. 現在のところ ipfw は 1 コマンドで複数のルールを ロードするユーティリティをサポートしていません. 私が使用しているシステムでは以下のようにしています: # ipfw list ファイルに現在のルールリストを出力し, テキストエディタを使用して すべての行の前に ``ipfw '' と書き足します. こうすることで, このスクリプトを /bin/sh に与えてルールをカーネルに再読み込み させることができます. これは最も効率的な方法とはいえないかもしれませんが, きちんと動作しています.

次の問題は, ファイアウォールが実際には何を する べきかです ! これは外部からそのネットワークへのどんなアクセスを許したいか, また内部から外界へのアクセスをどのくらい許したいかに大きく依存します. いくつか一般的なルールを挙げると: 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 から 入手可能です.

前にも述べたように, これはただの ガイドライン にすぎません. ファイアウォールでどのようなフィルタルールを使用するかは, あなた自身が 決めなければなりません. これまでのアドバイスにしたがったにも関わらず, 誰かがあなたのネットワークに 侵入してきたとしても, 私は「いかなる」責任もとることはできません. diff --git a/ja/handbook/glossary.sgml b/ja/handbook/glossary.sgml index 93c3ae447e..723ae56e6c 100644 --- a/ja/handbook/glossary.sgml +++ b/ja/handbook/glossary.sgml @@ -1,6 +1,6 @@ - + * Glossary diff --git a/ja/handbook/goals.sgml b/ja/handbook/goals.sgml index add43951b1..5719183960 100644 --- a/ja/handbook/goals.sgml +++ b/ja/handbook/goals.sgml @@ -1,33 +1,33 @@ - + FreeBSDプロジェクトの目的

原作: &a.jkh;

訳: &a.kiroh;24 September 1996.

FreeBSDプロジェクトの目的は、いかなる用途にも使用でき、何ら制限のない ソフトウェアを供給することです。私たちの多くは、コード(そしてプロジェ クト)に対してかなりの投資をしてきており、これからも多少の無駄はあって も投資を続けて行くつもりです。ただ、他の人達にも同じような負担をするよ うに主張しているわけではありません。FreeBSD に興味を持っている一人の残 らず全ての人々に、目的を限定しないでコードを提供すること。これが、私た ちの最初のそして最大の``任務''であると信じています。そうすれば、コード は可能な限り広く使われ、最大の恩恵をもたらすことができるでしょう。これ が、私たちが熱烈に支持しているフリーソフトウェアの最も基本的な目的であ ると、私は信じています。

私たちのソースツリーに含まれるソースのうち、GNU一般公有使用許諾(GPL)ま たはGNUライブラリ一般公有使用許諾(GLPL)に従っているものについては、多 少制限が科されています。ただし、ソースコードへのアクセスの保証という、 一般の制限とはいわば逆の制限(訳注1)です。ただしGPLソフトウェアを商用で 利用する場合、さらに複雑になるのは避けられません。そのため、それらのソ フトウェアを、より制限の少ないBSD著作権に従ったソフトウェアで置き換え る努力を、可能な限り日々続けています。

(訳注1) GPL では、「ソースコードを実際に受け取るか、あるいは、希望しさ えすればそれを入手することが可能であること」を求めています。 diff --git a/ja/handbook/handbook.sgml b/ja/handbook/handbook.sgml index 4067da52cf..22cd1f057c 100644 --- a/ja/handbook/handbook.sgml +++ b/ja/handbook/handbook.sgml @@ -1,185 +1,185 @@ - + %authors; %jmembers; %lists; %sections; ]> FreeBSD ハンドブック FreeBSD ドキュメンテーションプロジェクト 1996年12月 FreeBSD へようこそ! このハンドブックはFreeBSD Release &rel.current;のインストールおよび, 日常での使い方について記述したもので, FreeBSD ドキュメンテーションプロジェクトによって編集されています. 日本語版の作成は FreeBSD 日本語ドキュメンテーションプロジェクトがおこなって います. 本書は現在進行中の作業であって, 多くの個人の手からなる 仕事です. 多くのセクションはまだ存在しませんし, いま存在するセクションの いくつかはアップデートが必要です. この FreeBSD ドキュメンテーション プロジェクトに協力したいと思ったら, &a.doc; まで (英語で) 電子メールを 送ってください. ハンドブックそのものに関する議論は, こちらで おこなわれています. (もちろん英語でです.) 日本語訳および, 日本語版のみに関することは &a.doc-jp; において日本語で 議論されています. 必要に応じて日本語ドキュメンテーションプロジェクトから 本家ドキュメンテーションプロジェクトに対してフィードバックをおこないますので, 英語が得意でない方は &a.doc-jp; まで日本語でコメントをお寄せください. このドキュメントの最新バージョンは, いつでも や から入手できますし, や, たくさんあるからプレインテキスト, postscript, HTML などの形式でダウンロードすることもできます. また, も可能です. 基礎 はじめに

FreeBSD は, Intel アーキテクチャ (x86) ベースの PC のための 4.4BSD-Lite をベースとしたオペレーティングシステムです. FreeBSD の概要については, をご覧ください. このプロジェクトの歴史については, をご覧ください. 最新のリリースについての記述は, をご覧ください. FreeBSD プロジェクトへの何らかの貢献 (ソースコード, 機器, 資金の提供など) について興味があれば, の章をご覧ください. &nutshell; &history; &goals; &development; &relnotes; &install; &basics; アプリケーションのインストール * パッケージのインストール &ports; システム管理 &kernelconfig; ユーザ, グループ, セキュリティ &crypt; &skey; &kerberos; &firewalls; &printing; "as; X ウィンドウシステム

この節の完成は保留にしてあります. から提供されるドキュメントを参考にしてください. &hw; ネットワーク通信 シリアル通信 &serial; &term; &dialup; &dialout; PPP と SLIP

もしあなたがモデムを使ってインターネットに接続したり, 他の人々に FreeBSD によるインターネットへのダイヤルアップ接続を 提供しようとしているのでしたら, PPP または SLIP 接続を選択することができます. PPP 接続には, 2 種類の方法が提供されています: ユーザPPP (iijppp とも呼ばれます) とカーネルPPP です. 両方の PPP の設定手順と, SLIP の設定方法については以下の章に書かれています. &userppp; &ppp; &slipc; &slips; 高度なネットワーク &routing; &nfs; &diskless; * イエローページ/NIS &isdn; &mail; さらに進んだ話題 ¤t; &stable; &synching; &submitters; &troubleshooting; &kerneldebug; &kernelopts; &linuxemu; FreeBSD の内部 &booting; &memoryuse; &dma; 付録 &mirrors; &bibliography; &eresources; &contrib; &policies; &pgpkeys; &jcontrib; diff --git a/ja/handbook/history.sgml b/ja/handbook/history.sgml index 5d764ab13a..f4ecd301ed 100644 --- a/ja/handbook/history.sgml +++ b/ja/handbook/history.sgml @@ -1,103 +1,103 @@ - + FreeBSD 小史

原作: &a.jkh;.

訳: &a.masaki;, &a.hino;.19 December 1996. FreeBSD プロジェクトは 1993年の始めに ``Unofficial 386BSD Patchkit'' の最後の 3人のまとめ役によって, 部分的に patchkit から派生する形で開始 されました. ここでの 3人のまとめ役というのは, Nate Williams と, Rod Grimes と, 私 (Jordan K. Hubbard) です. 私たちのもともとの目標は, patchkit という仕組みではもう十分に解 決できなくなってしまった 386BSD の数多くの問題を修正するための, 386BSD の暫定的なスナップショットを作成することでした. こういった経緯を経てい るので, このプロジェクトの初期の頃の名前が ``386BSD 0.5'' や ``386BSD 暫定版 (Interim)'' であったということを覚えている人もいるでしょう. 386BSD は, Bill Jolitz が (訳注: バークレイ Net/2 テープを基に) 作成し たオペレーティングシステムです. 当時の 386BSD は, ほぼ一年にわたって放っ ておかれていた (訳注: 作者がバグの報告を受けても何もしなかった) という ひどい状況に苦しんでいました. 作者の代わりに問題を修正し続けていた patchkit は日を追うごとに不快なまでに膨張してしまっていました. このよ うな状況に対して, このままではいけない, 何か行動を起こさなければ, とい うことで異議を唱えるものは私たちのなかにはいませんでした. そして私たち は挑戦することを決断し, 暫定的な「クリーンアップ」スナップショットを作 成することで Bill を手助けしようと決めたのです. しかし, この計画は唐突 に終了してしまいました. Bill Jolitz が, このプロジェクトに対する受け 入れ支持を取り下げることを突然決意し, なおかつこのプロジェクトの代わり に何をするのかを一切言明しなかったのです. たとえ Bill が支持してくれないとしても, われわれの目標には依然としてや る価値があると決心するのにさしたる時間はかかりませんでした. そこで David Greenman が考案した名称 ``FreeBSD'' を私たちのプロジェクトの名前 に採用し, 新たなスタートを切りました. この時点でのプロジェクトの初期目 標は, すでにこのシステム (訳注: 386BSD + Patchkit) を使っていた利用者 たちと相談して決められました. プロジェクトが実現に向けて軌道に乗ってき たことが明確になった時点で, 私は Walnut Creek CDROM 社に連絡してみまし た. CDROM を使って FreeBSD を配布することによって, インターネットに容 易に接続できない多くの人々が FreeBSD を簡単に入手できるようになると考 えたからです. Walnut Creek CDROM 社は FreeBSD を CD で配布するというア イデアを採用してくれたばかりか, 作業するためのマシンと高速なインターネッ ト回線を私たちのプロジェクトに提供してくれました. 当時は海のものとも山 のものともわからなかった私たちのプロジェクトに対して, Walnut Creek CDROM 社が信じられないほどの信頼を寄せてくれたおかげで, FreeBSD は短期 間のうちにここまで大きく成長したのです. CDROM による最初の配布 (そしてネットでの, ベータ版ではない最初の一般向 け配布) は FreeBSD 1.0 で, 1993年 12月に公開されました. これは カリフォ ルニア大学バークレイ校の 4.3BSD-Lite (``Net/2'') を基とし, 386BSD や Free Software Foundation からも多くの部分を取り入れたものです. これは 初めて公開したものとしては十分に成功しました. 続けて 1994年 5月に FreeBSD 1.1 を公開し, 非常に大きな成功を収めました. この時期, あまり予想していなかった嵐が遠くから接近してきていました. バー クレイ Net/2 テープの法的な位置づけについて, Novell 社と カリフォルニ ア大学バークレイ校との間の長期にわたる法廷論争において和解が成立したの です. 和解の内容は, Net/2 のかなりの部分が「権利つき (encumbered)」コー ドであり, それは Novell 社の所有物である, というバークレイ校側が譲歩し たものでした. なお, Novell 社はこれらの権利を裁判が始まる少し前に AT&T 社から買収していました. 和解における譲歩の見返りにバークレイ 校が得たのは, 4.4BSD-Lite が最終的に発表された時点で, 4.4BSD-Lite は権 利つきではないと公式に宣言されること, そしてすべての既存の Net/2 の利 用者が 4.4BSD-Lite の利用へと移行することが強く奨励されること, という Novell 社からの「ありがたき天からの恵み」でした. (訳注: 4.4BSD-Lite は その後 Novell 社のチェックを受けてから公開された.) FreeBSD も Net/2 を利 用していましたから, 1994年の 7月の終わりまでに Net/2 ベースの FreeBSD の出荷を停止するように言われました. ただし, このときの合意によって, 私 たちは締め切りまでに一回だけ最後の公開をすることを許されました. そして それは FreeBSD 1.1.5.1 となりました. それから FreeBSD プロジェクトは, まっさらでかなり不完全な 4.4BSD-Lite を基に, 文字どおり一から再度作り直すという, 難しくて大変な作業の準備を始めまし た. ``Lite'' バージョンは, 部分的には本当に軽くて, 中身がなかったので す. 起動し, 動作できるシステムを実際に作り上げるために必要となるプログ ラムコードのかなりの部分がバークレイ校 の CSRG (訳注: BSDを作っている グループ) によって (いろいろな法的要求のせいで) 削除されてしまっていた ということと, 4.4BSD の Intel アーキテクチャ対応が元々かなり不完全であっ たということがその理由です. この移行作業は結局 1994年の 12月までかかり ました. そして 1995年の 1月に FreeBSD 2.0 をネットと CDROM を通じて公 開しました. これは, かなり粗削りなところが残っていたにもかかわらず, か なりの成功を収めました. そしてその後に, より信頼性が高く, そしてインス トールが簡単になった FreeBSD 2.0.5 が 1995年の 6月に公開されました. これからのことについて 私たちは 1996年の 8月に FreeBSD 2.1.5 を公開しました. この出来が非常に 良く, 特に業務で運用しているサイトやISPでの人気が高かったので, 2.1-STABLE 開発分流からもう一回, 最後の公開を行なうことにメリットがあ ると考えました. それが FreeBSD 2.1.6 で, 2.1-STABLE 開発分流の最後を締 めくくるものとして, 1996年の 12月に公開されました. 2.1-STABLE 開発分流 は現在, 保守のみを行なう状態になっており, 今後は, セキュリティの改善や 他の何か重要なバグフィックスのみが行なわれるでしょう. FreeBSD 2.2 は現在, 公開へ向けた開発分流となっていて, 1997年 1月のデビュー に向けて開発が進められています. SMP のサポートから DEC ALPHA のサポー トまでのすべての長期的なプロジェクトは, 1996年 10月に 2.2 の開発分流か ら分岐した 3.0-CURRENT 開発分流において継続しています. 3.0 のスナップ ショットの公開は, 1997年のはやいうちに再開することが予定されています. diff --git a/ja/handbook/hw.sgml b/ja/handbook/hw.sgml index 117bded7aa..d72b0b884d 100644 --- a/ja/handbook/hw.sgml +++ b/ja/handbook/hw.sgml @@ -1,1523 +1,1523 @@ - + PC ハードウェアコンパチビリティ

訳: &a.yoshiaki; . 5 December 1996.

ハードウェアコンパチビリティの問題は現在のコンピュータ業界でもっ とも多く起きる種類の問題であり, FreeBSDもこれに無縁ではありません. 市場にある驚くほど多様な種類の製品をサポートしたことで,安価に普及し ている PCハードウェアで動かすことができるという FreeBSDの利点はこの 点では不利でもあります. FreeBSDのサポートするハードウェアを徹底的に調べて提供することは不 可能ですが, このセクションでは FreeBSDに含まれるデバイスドライバとそ のドライバがサポートするハードウェアのカタログを示します. 可能で適切 なものについては特定の製品についての注釈を含めました. FreeBSD はボランティアプロジェクトでテスト部門には資金がありません から, より多くの情報をこのカタログに載せるにはあなたがたユーザに 頼らなければなりません. あなた自身の経験により, あるハードウェアが FreeBSDで動くか動かないかがわかったとしたら&a.doc; へ e-mailして知らせてください. サポートされているハードウェアについて の質問は, &a.questions;(詳しいことは を参照してください) へ 宛ててください. 情報を提供したり質問をする時は FreeBSDのバージョンと使っ ているハードウェアのできるだけ詳しい情報を含めることを忘れないでくだ さい. インターネット上のリソース

以下のリンクはハードウェアを選ぶのに役に立ちます. FreeBSDに対して は必要のない (あるいは適用できない) ように見えるかもしれませんが, ここ からのハードウェアの情報のほとんどは OSに依存しないものです. 購入をする前にはあなたの選んだものがサポートされているか FreeBSDハード ウェアガイドを注意して読んでください.

訳注: 日本国内でFreeBSDの動くハードウェアの情報を提供してい るWWWサーバがあります. これ以外にも情報を提供しているサーバはあります. いくつかの URLについて は からたどることができます. 組合せの見本

以下のハードウェアの組合せのサンプルリストはハードウェアベンダや FreeBSD プロジェクトが保証するものではありません. この情 報は公共の利益のために公開しているものであり, 極めて数多くあるであろう 異なったハードウェアの組合せの中からのある経験のカタログに過ぎません. やり方はいろいろあります. 場合によってはうまく行かないこともあります. 十分気をつけてください. Jordan氏の選んだ組合せ

私の作ったワークステーションとサーバの構成はまずまずうまく行っ ています. 私はこれを保証できるわけでもありませんし, ここにあげた組 合せがずっと "best buys"であるわけではありません. 私はできればリス トを更新して行きますがそれがいつになるかはわかりません. 訳注: &a.jkh; 氏は FreeBSDプロジェクトのメンバです. マザーボード

はミッドレンジからハイエンドの Pentiumサーバやワークステーションシステムに はよい選択のようですが, より新しい 430HX (Triton-II) のボード (以下を参照してください) にほとんど置き換えられました. これらのボードを買うならば を使うといいでしょ う. 486クラスのマザーボードを探しているなら ASUSの を調べてみることをおすすめします (注: ASUSはこれら を既に製造していないのは明らかなのでこれらのものはだんだん手に入 りにくくなっています). 訳注: 96年10月現在 上で述べられているボードは日本でも手に入りにくい部類 になっているようです. 注: Intel チップセットベースのマザーボードでは メモリパリティチェック機能が提供されませんので, メモリエラーが起きても検出が不可能です. フォルトトレラントなシステムを構築したい場合には, より新しい 430HX (Triton II) ベースのマザーボードを買うことをおすすめしま す. こちらはよりよい性能, パリティチェックと ECC機能を提供してくれます. ECCを使うのであれば 82439HX Triton-II チップセットの A2以降のリビジョ ンを使ったマザーボードが必要です. 82371SBのリビジョンと混乱しないでくださ い - リビジョンがA2であれば 82439HXチップに "SU102"とマークされています. リビジョンがA1であれば Sで始まる番号はマークされていない, あるいは "SU087"とマークされています.

ハイエンドにおいては FreeBSDでは 200MHzの P6 (Pentium Pro) CPUを 使ったIntel/Venus Pro () マザーボー ドが非常によいようです. 最近の価格の下落 (急落と言った方がいいでしょ うか) で最近の米国内では P6システムは十分購入の候補になる程度に価格 が下がっています. また, 本格的なサーバ用途には Pentium Pro を考えて いいでしょう. 注: Intel のマザーボードは従来とは異る形状で, "ATX" ケースデザイン と呼ばれる従来とはまったく異る PCケースが必要になっています. 今あるシステムをアップグレードしようと考えているならこのことを十分 考えましょう - 私のこれまでに知る限りでは, 現在入手可能な ATXケース はすべて 「ミドルタワー (midi-tower)」で, ドライブなどの内蔵周辺機器 を格納するスペースに制限があります. 利点としては, ほとんどの ATXケー スは一般的な PCケースに比較して非常に品質の高いもののようであるとい うことがあります. ディスクコントローラ

これはいくらかトリッキーです. 私は ISAから PCIまですべてコンパチブ ルな コント ローラを使うようにすすめていましたが, 現在では ISAでは 1542CF, EISA では Bt747c, PCIでは Adaptec 2940 をすすめるよう変わってきています.

PCIマシンで2つ以上の SCSIコントローラが必要となるのであれば, PCIバスの不足を防ぐために Adaptec 3940 カードを考えてもいいでしょ う. これは1つのスロットで2台の SCSIコントローラ(と内部バス)を持ち ます. ディスクドライブ

私は,極々特殊な状況を除いて 「それだけのお金をかけることができる なら SCSIは IDEよりもよい」 と言っています. 小規模なデスクトップ構成 のシステムでも, SCSIであればディスクが安くなっていった時にサーバの (古い入れ換えた) ディスクを比較的簡単に移し替えることができます. あ なたが複数のマシンの管理をしているのであれば単純に容量について考え るのではなく, 食物連鎖のように考えましょう.

私は今のところは NFSサーバや NEWSサーバのようにマルチユーザに よる激しいディスク disk I/Oがおこなわれる用途以外ではお金をかけてま で SCSI WIDEドライブにする必要はないと考えています. CDROM ドライブ

私は SCSIの方が好みであるのでもちろん SCSI CDROMを選びました. XM-3501B (現 在はキャディレスモデルの XM-5401Bがリリースされています)ドライブは どんな時もうまく動いてくれていますが, 最近は の 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ドライブ (私は これらすべては結局は Philips社のドライブであるのではない かと考えているのですが) をサポートしています : Philips CDD 522 (Plasmon のドライブと同様の動作をします), PLASMON RF4100, HP 4020i です. 私は HP 4020i を CDROMを焼くのに使っています(2.2-current で 使っています - 2.1.5以前のリリースの SCSIコードでは動きません). 非常に調子よく動いています. 2.2 システムの を見てください. ISO9660ファイルシステムイメージ (RockRidge拡張) を作 るスクリプトと それをHP4020i CDR で焼くためのスクリプトの例があり ます. テープドライブ

私はたまたま の と の を持っています.

バックアップのためであれば, より本質的に丈夫な (また, より容量が大きい) Exabyteの 8mmテープの方がおすすめできます. ビデオカード

もし (米国では) 99USドルをかけて商品の Xサーバをから買うことができる なら間違いなく カードをおすすめします. フリーの Xサーバを使いたいの であれば の S3 Vision 868と 968 ベースのカード (the 9FX series) はわりあいと速く, の S3サーバで サポートされており, きっと問題も起きないでしょう. モニタ

私の持っている 非常に調子がいいので, 同じ (トリ ニトロン) ブラウン管を使っている Viewsonicをおすすめします. 17"よりも 大きなモニタ, 例えば 21"のモニタが実際に必要だとしたらこの文章の執 筆時点では 2,500USドル以下のものはまったくすすめられません. 20"以上のク ラスでよいモニタは(いくつも)ありますし, 20"クラスで安いモニタもあり ます. うまくいかないことに安くてよいモニタはありません!! ネットワーキング

私は ISAカードでは Ultra 16 コントローラを, PCIベースのカードでは SMC EtherPower と Compex ENET32カードをおすすめできます. この2種類の PCI カードは DECの DC21041イーサネットコントローラチップを使っています. また, このチップを使っている Zynx ZX342 や DEC DE435 などのカードも 一般的にはうまく動くでしょう. 100Mbit/sec のネットワークカードで は SMC SMC9332DST 10/100MB や Intel EtherExpress Pro/100B カードは 利用できるでしょう. もう一方, できるだけ低コストでそこその性能で動くものを探しているな ら, ほとんどの NE2000のクローンはよい選択です. (特殊な) シリアル

高速のシリアル ネットワーク インタフェース (同期シリアルカード) を探しているのであれば 製の シリーズのド ライバが今の FreeBSD-currentにあります. も 提供 するソフトウェアにより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がサポー トするいう点では の製品が最も信頼できるでしょう. この最大の理由はこ の会社が私たちに十分な評価用ボードとスペックを供給することを約束し てくれているからです. 私は Cyclom-16Y が最高の性能価格比であると聞 いていましたが最近は価格のチェックはしていません. 訳注: cycladesの WWWサーバでも Supported Operating Systemsに Linuxや BSDi, FreeBSD が明記されています. 他のマルチポートカードで評判がよいのは BOCAおよび ASTのカードと で, このカードには で非公式なドライバが提供されてい るようです. オーディオ

私は現在,高音質で全二重のオーディオ機能 (2DMAチャネル) を持つという 点から Ultrasound MAX を使っています. Windows NTや OS/2でのサポートはあま りよくありませんので, FreeBSD, NT, OS/2のすべてで使うには推薦できま せん. そのような場合には の AWE32 がいいでしょう. ビデオキャプチャー

ビデオキャプチャーについては事実上一つしか選択の余地がありません. カードです. FreeBSDはクリエィティブ ラボの古い video spigotカードの サポートはしていますがこれは手に入りにくくなっていますし, Meteor は 高速のPCIインタフェースを持った新しい世代の画像取り込みボードです. 私はこれを MBONEのビデオ放送に使っていますが, 非常にうまく動いていま す!! 中心部/プロセッサ マザーボード, バス, チップセット * ISA * EISA * VLB PCI

原作: &a.rgrimes;.25 April 1995.

更新: &a.jkh;.最終更新 26 August 1996.

訳: &a.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の公式の回答は 430FX チップセットへの 移行で, 「こちらでは修整した」ということです. 430FX (Triton I): 知られている キャッシュコヒーレンシ やバスマスタの問題はありませんがパリティチェック機能が ありません. パリティを使いたいような場合は, 可能であ れば 430HX (Triton-II) ベースのマザーボードを選びましょう. 430HX (Triton-II): このチップセット を使っているマザーボードに関するすべての報告によれば今の ところ好評です. しかし ECCメモリを利用するのであれば 82439HX チップの A2以降のリビジョンを手 にいれるように注意して下さい. 82371SBのリビジョンと混乱 しないでください - リビジョンがA2であれば 82439HXチップ に "SU102"とマークされています. リビジョンがA1であれば S で始まる番号はマークされていない, あるいは "SU087"とマー クされています. 430VX (誤って Triton-IIIと呼ばれることもあります) : 430VX は 430HXとは異るローコストの設計で, ビデオカード が自身のボード上のメモリの替りにメインメモリを使うこと ができるように設計されています. またメモリ空間は 128MB に制限されますが SDRAMのサポートが加えられています. しかし, 64MB以上のメモリについてはキャッシュされません. 450KX (Orion): このチップセットの初期 のバージョンでは PCI write-posting にバグがあり, 大量の PCIバストラフィッ クのあるアプリケーションでは性能の著しい低下があるとい う障害がありました. B0以降のリビジョンのチップセットで は問題はいくらか解決され, C0以降では完全に解決されて います. (Natoma):これは に対応したチップセットで, 初期の Orionチップセットにあったような問題は見られず, 問題なく動 いているようです. また, これは ECCやパリティを含んだ広い 種類のメモリに対応しています.

CPU/FPU * Pentium Pro クラス Pentium クラス クロックスピード

原作 &a.rgrimes;.1 October 1996.

Pentium クラスのマシンはシステムのいくつかの部分で異なったク ロックスピードを使っています. これは CPU, 外部メモリバス, PCI バスです. 別々のクロックスピードが使われるために 「高速な」 CPUを使ったシステムが 「低速な」システムよりも必ず しも速いとは限りません. それぞれの場合の違いを以下の表に示します.

CPUクロック 外部クロック 外部クロックと PCIバス とメモリバス 内部クロック クロック MHZ MHZ** の比 MHZ 60 60 1.0 30 66 66 1.0 33 75 50 1.5 25 90 60 1.5 30 100 50* 2 25 100 66 1.5 33 120 60 2 30 133 66 2 33 150 60 2.5 30 166 66 2.5 33 180 60 3 30 200 66 3 33 * Pentium 100 は 50MHzの外部クロックの 2倍または 66MHz の 1.5倍の両方で動かすことができます. ** 66 Mhz はおそらく実際には 66.667 MHzでしょう. しかし, そうだと決めつけてはいけません.

3倍クロックの CPUではメモリアクセス速度が不足気味であるとい う点を考えなければ 100, 133, 166, 200 MHzを使うのが最良でしょ う.

AMD K5 CPU は内部クロックではなく AMDが "PR" -- Pentium Rating とよんでいる評価値で表されます. したがって AMD PR133 のチップ は Intel Pentium 133 と同等です. 実際にはこの CPUは内部 100MHz, バス 66 MHz, クロック倍率 1.5 倍で動いています. * 486 クラス * 386 クラス 286 クラス

残念ながら, FreeBSDは 80286マシンでは動きません. 現在の巨大なフ ルスペックの UNIXをこのようなハードウェアで動かすことはほとんど 不可能でしょう. 上記の内容に加え, には FreeBSDをいろいろな CPUで動かし た場合の詳細な記述があります. メモリ

FreeBSDをインストールするのに最低限必要なメモリ量は 8 MBです. いったんシステムが起動してことができるならば, もっと少ないメモリ で動かすこともできます. FreeBSD 2.1, 2.1.5, 2.1.6 では必要なメモリ の最小値は 5MBです. boot4.flp を使えば 4 MB しかメモリがなくてもインストールできます.

いろいろなタイプのメモリについての詳細な記述が . にあります. * BIOS 入力/出力デバイス * ビデオカード * サウンドカード シリアルポートとマルチポートカード &uart; &sio; &cy; * パラレルカード * モデム * ネットワークカード * キーボード * マウス * その他 記憶装置 &esdi; &scsi; * ディスク/テープ コントローラ * SCSI * IDE * フロッピー * ハードディスクドライブ テープドライブ

原作: &a.jmb;.2 July 1996.

訳: &a.yoshiaki;.13 October 1996.

一般的なテープアクセスコマンド

mt(1) はテープドライブへの一般的なアクセス方法を提 供します. rewind, erase, statusなど の共通コマンドがあります. マニュアルページの mt(1)を見 てください. より詳しい解説があります. コントローラインタフェース

テープドライブにはいくつかの異なったインタフェースがあり ます. SCSI, IDE, フロッピー, パラレルポートのインタフェース です. 非常に多くの種類のテープドライブがこれらのインタフェー スで使えます. コントローラについての議論はにあります(訳注:現在未完成です). SCSI ドライブ

st(4) ドライバは 8mm (Exabyte), 4mm (DAT: Digital Audio Tape), QIC (1/4インチカートリッジ), DLT (デジタルリニアテー プ), QIC ミニカートリッジ, 9トラック (大きなリールがハリウッドの コンピュータルームで回っているのを見たことがあるでしょう)をサポー トします. st(4) マニュアルページにより詳しい解説があります.

以下のドライブリストは現在 FreeBSDコミュニティのメンバが 使っているものです. これらだけが FreeBSDで動くドライブという わけではありません. これらは単にたまたま私たちのうちの誰かが使っ ているというだけです. 4mm (DAT: Digital Audio Tape )

8mm (Exabyte)

QIC (1/4 インチカートリッジ)

DLT (Digital Linear Tape)

Mini-Cartridge

Autoloaders/Changers

* IDE ドライブ フロッピードライブ

* パラレルポートドライブ 詳細な情報

このドライブのブートメッセージの識別子は "ARCHIVE ANCDA 2750 28077 -003 type 1 removable SCSI 2"です.

これは QIC テープドライブです.

QIC-1350テープを利用した場合の標準の容量は 1.35GBです. このドライブは QIC-150 (DC6150), QIC-250 (DC6250), QIC-525 (DC6525) の テープを問題なく読み書きすることができます.

dump(8)を使った時のデータ転送レートは 350kB/sです. における転送レートは 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-XXX4ASB" "type 1 removable SCSI 2" "density code 0x8c, 512-byte blocks" です.

これは DDS-1 テープドライブです.

90m テープを使った場合の標準容量は 2.5GBです.

データ転送速度は不明です.

このドライブは Sun マイクロシステムが再パッケージして model 411として出しています.

報告者: Bob Bishop rb@gid.co.uk

このドライブのブートメッセージ識別子は "ARCHIVE VIPER 60 21116 -007" "type 1 removable SCSI 1"です.

これは QICテープドライブです.

標準の容量は 60MB です.

データ転送レートは不明です.

このドライブは生産中止になっています.

報告者: Philippe Regnauld regnauld@hsc.fr

このドライブのブートメッセージの識別子は "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テープデバイスドライバはあら かじめ (st(4)) にあらかじめ組み込まれています.

FreeBSD 2.2-currentでは, ブロックサイズの設定を設定するためmt blocksize 512としてください. (ファームウェアリビジョンが 21247 -005 である場合の問題です. 他のリビジョンのファームウェアでは異 なる場合があります.) これ以前の FreeBSDバージョンにはこの問題はありません.

このドライブは生産中止になっています.

報告者: Pedro A M Vazquez vazquez@IQM.Unicamp.BR

Mike Smith msmith@atrad.adelaide.edu.au

このドライブのブートメッセージの識別子は "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" 以前の物はバグが 多く, 正しく機能しません.

このドライブは生産中止になっています.

報告者: &a.hm;

このドライブのブートメッセージの識別子は "Conner tape" です.

これはフロッピーコントローラを使うミニカートリッジテープド ライブです.

標準容量は不明です.

データ転送レートは不明です.

このドライブは QIC-80テープドライブを使います.

報告者: Mark Hannon mark@seeware.DIALix.oz.au

このドライブのブートメッセージの識別子は "CONNER CTMS 3200 7.00" "type 1 removable SCSI 2" です.

これはミニカートリッジテープドライブです.

標準容量は不明です.

データ転送レートは不明です.

このドライブは QIC-3080テープカートリッジを使います.

報告者: Thomas S. Traylor tst@titan.cs.mci.com

このドライブのブートメッセージの識別子は "DEC TZ87 (C) DEC 9206" "type 1 removable SCSI 2" "density code 0x19" です.

これは DLTテープドライブです.

標準容量は 10GBです.

このドライブはハードウェアデータ圧縮の機能があります.

データ転送レートは 1.2MB/sです.

このドライブは Quantum DLT2000と同一の物です. このドライブ のファームウェアは Exabyteの 8mmドライブ等のよく知られたいくつかのドラ イブのエミュレートをおこなうよう設定ができます.

報告者: &a.wilko;

このドライブのブートメッセージ識別子は "EXABYTE EXB-2501"です.

これはミニカートリッジテープドライブです.

MC3000XLミニカートリッジを使った時の標準容量は 1GBです.

データ転送レートは不明です.

このドライブは DC2300 (550MB), DC2750 (750MB), MC3000 (750MB), MC3000XL (1GB) ミニカートリッジの読み書きができます.

注意: このドライブは SCSI-2の仕様に適合していません. このドライブは, フォーマット済みのテープ以外を入れた場合, SCSI MODE_SELCTコマンドで完全にロックアップしてしまいます. このドライブを使 う前に, テープブロックサイズを次のように設定します. mt -f /dev/st0ctl.0 blocksize 1024 ミニカートリッジは最初に使う前にフォーマットしなければなりません. FreeBSD 2.1.0-RELEASE およびそれ以前の場合は /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およびそれ以降の場合は /sbin/scsiformat -q -w /dev/rst0.ctl とします.

今のところ, FreeBSDではこのドライブはあまりおすすめできません.

報告者: Bob Beaulieu ez@eztravel.com

このドライブのブートメッセージの識別子は "EXABYTE EXB-8200 252X" "type 1 removable SCSI 1"です.

これは8mmテープドライブです.

標準容量は 2.3GBです.

データ転送レートは 270kB/sです.

このドライブはブート時の SCSIバスへの応答はわりあい遅いです. カスタムカーネルが必要かもしれません (SCSI_DELAYを 10秒に設定しましょう). 訳注: GENERICカーネルの設定では 15秒になっています.

このドライブには非常に多くのファームウェアの構成があります. あるドライブでは特定のベンダのハードウェアにカスタマイズしてあります. ファームウェアは EPROMを置き換えることで変更できます.

このドライブは生産中止になっています.

報告者: Mike Smith msmith@atrad.adelaide.edu.au

このドライブのブートメッセージの識別子は "EXABYTE EXB-8500-85Qanx0 0415" "type 1 removable SCSI 2" です.

これは 8mmテープドライブです.

標準容量は 5GBです.

データ転送レートは 300kB/sです.

報告者: Greg Lehey grog@lemis.de

このドライブのブートメッセージ識別子は "EXABYTE EXB-85058SQANXR1 05B0" "type 1 removable SCSI 2"です.

これは 圧縮機能を持った 8mmテープドライブで, EXB-5200 と EXB-8500に対する上位互換品です.

標準容量は 5GBです.

このドライブはハードウェアデータ圧縮機能があります.

データ転送レートは 300kB/sです.

報告者: Glen Foster gfoster@gfoster.com

このドライブのブートメッセージの識別子は "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にしておきます

注意: これらのドライブの品質管理は非常に幅がありま す. ある FreeBSDコアチームのメンバは このドライブを2つ返品しました.

報告者: &a.se;

このドライブのブートメッセージの識別子は "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 テープドライブ, C35470A DDS フォーマット DATドライブ, C1534A DDS フォーマット DATドライブ, HP C1536A DDS フォーマット DATドライブと 同じ機構を使用しています.

HP C1534A DDSフォーマット DATドライブはグリーンと黄色(アンバー) の2つの表示ランプがあります. グリーンのランプは動作状 態を示し, ローディング中はゆっくり点滅, ローディングが終了すると点灯, read/write動作中は速く点滅します. 黄色のランプは警告灯で, クリーニング が必要であるかまたはテープが寿命に近くなるとゆっくり点滅, 致命的なエラー の場合は点灯します(工場での修理が必要かもしれません).

報告者:Gary Crutcher gcrutchr@nightflight.com

このドライブのブートメッセージの識別子は未確認です.

これは DDS-2テープドライブです. DDS-2 とはデータ容量を増や すためにハードウェア圧縮と狭いトラックを採用したものです.

120mテープを使用した場合の標準容量は 24GB です. このドライブはハードウェアデータ圧縮機能があります.

データ転送レートは510kB/s (標準) です.

このドライブはヒューレットパッカード社の SureStore テープドライブに使われています.

このドライブはリアパネルに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"

このドライブのブートメッセージの識別子は"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

このドライブのブートメッセージの識別子は "HP HP35470A 9 09" type 1 removable SCSI 2"です.

これは DDS-1テープドライブです. DDS-1は最初の DAT テープフォーマットです.

90mテープを使用した時の標準容量は 2GBです.

データ転送レートは 183kB/sです.

これはヒューレットパッカード社の SureStore テープドライブ, C35470A DDSフォーマットDATドライブ, C1534A DDSフォーマットDATドライブ, HP C1536A DDS フォーマットDATドライブと同 じ機構が使われています.

注意: これらのドライブの品質管理には非常に大き な幅があります. ある FreeBSDコアチームのメンバは 5台のドライブを返品し ました. 9ヶ月以上もったものはありません.

報告者: David Dawes dawes@rf900.physics.usyd.edu.au (9 09)

このドライブのブートメッセージの識別子は "HP HP35480A 1009" "type 1 removable SCSI 2" "Sequential-Access density code 0x13" です.

これは DDS-DCテープドライブです. DDS-DCはハードウェアデータ 圧縮のついたDDS-1です. DDS-1は最初のDATテープフォーマットです.

90mテープを使った場合の標準容量は 2GBです. このドライブはハー ドウェア圧縮機能があります.

データ転送レートは 183kB/sです.

このドライブはヒューレットパッカード社の SureStore , テープドラ イブ, C35480A DDS フォーマット DAT ドライブと同じ機構を使っています.

このドライブは時々, テープの eject操作 (mt offline) を行っている時にハングアップすることがあります. テープをejectさせたり, ドライブを回復させるにはフロントパネルのボタンを押してください.

注意: HP 35480-03110 では特有の問題がありました. 少なくとも2回, FreeBSD 2.1.0 で IBM Server 320に 2940W SCSIコントローラ をつけてこのドライブを使っている時にすべての SCSIディスクのパーティショ ンが失われたことがあります. この問題は解析も解決もできていません.

これらには少なくとも 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 =08:" "type 1 removable SCSI 2"です.

このドライブはQIC テープドライブです.

標準容量は150/250MBです.

このドライブには奇妙な癖があることが知られていますが, SCSIテープドライバ (st(4)) には問題なく動くコードが含まれてい ます. 問題の修整とSCSI 2へのコンパチビリティを得るためにファームウェ アをある (具体的には不明の) バージョンより上にしてください.

データ転送レートは80kB/sです.

IBMと Emerald製品のユニットは動かないでしょう. 問題を解決するためにファームウェア EPROMを交換してください.

報告者: Michael Smith msmith@atrad.adelaide.edu.au

これはドライ ブに非常によく似ています.

報告者: &a.joerg;

このドライブのブートメッセージの識別子は "TANDBERG TDC 4222 =07" "type 1 removable SCSI 2"です.

これは QICテープドライブです.

標準容量は2.5GBです. このドライブは 60M (DC600A) 以上のすべての カートリッジを読むことができ, 150MB (DC6150) 以上のすべてのカートリッジを 読み書きできます. ハードウェア圧縮は 2.5GBカートリッジを使用した時のオプションとしてサポートされています.

このドライブには奇妙な癖がありますが, FreeBSDの2.2-current以降の SCSIテープデバイスドライバ (st(4)) には対応が組み込まれています. それ以前のバージョンの FreeBSDではmtを用いてテープから1ブロッ ク読み, テープを巻戻してからバックアッププログラムを実行してください. (mt fsr 1; mt rewind; dump ...).

データ転送レートは 600kB/s (データ圧縮時のベンダによる公称) で, start/stop モードでも 350kB/s にはなります. 容量の小さいカー トリッジを使った場合にはレートは下がります.

報告者: &a.joerg;

このドライブのブートメッセージの識別子は "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テープドライバ (st(4)) に組み込まれています.

他のファームウェアのリビジョンで動くことが確認されているも のは M75Dです.

報告者: Marc van Kempen marc@bowtie.nl "REV73R1" Andrew Gordon Andrew.Gordon@net-tel.co.uk "M75D"

このドライブのブートメッセージの識別子は "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 * 問題のあるドライブ * CD-ROM ドライブ * その他 * ディスクの追加と再設定 テープとバックアップ * フロッピーへのバックアップはいかが? テープメディア

4mm テープはワークステーションのバックアップメディアとして QICから置き換えられつつあります. この流れは QICドライブの製造のリーダ であった Archiveを Connerが買収し QICドライブの製造を中止したことで加 速しました. 4mmドライブは小型で静かですが 8mmドライブの持っているような信頼性の評判はありません. カートリッジは 8mmカートリッジよりも安価で小型 (3 x 2 x 0.5 インチ ; 76 x 51 x 12 mm) です. 4mmドライブ は 8mm同様にヘリカルスキャン (訳 注: VTRと同様の回転ヘッドを使う方式) を使用しているという理由でヘッド の寿命は短いです.

これらのドライブのデータスループットは 150kB/s程度から 500kB/s程度の範囲です. データ容量は 1.3GBから 2.0GBです. ハードウェア 圧縮が多くのドライブで可能で, およそ 2倍の容量になります. マルチドライ ブテープライブラリユニットは1つの筐体に 6ドライブを持つことができ自動的 にテープを交換します. ライブラリの容量は 240GBに達します.

4mmドライブは 8mmドライブ同様にヘリカルスキャンを使います. ヘリカルスキャンの利点と欠点は 4mmドライブ と 8mmドライブ共通です.

テープの寿命は 2000回のパスあるいは 100回のフルパックアップ です.

8mmテープは SCSIテープドライブとして最もよく使われているもの で, データ交換用として最良の選択です. ほとんどのサイトには Exabyteの 2GB 8mmテープドライブがあるでしょう (訳注: Unixワークステーションを何 台も置いているようなサイトには1台くらいはあるというような意味です). 8mmドライブは信頼性が高く, 使いやすく, 静かです. カートリッジは安価で 小型です (4.8 x3.3 x 0.6 インチ; 122 x 84 x 15 mm). ひとつの欠点は , テープとヘッドの相対的な速度が高速なために比較的ヘッドとテープの寿命 が短いことです.

データスループットは 250kB/s程度から 500kB/s程度の範囲です. データ容量は 300MBから 7GBです. ハードウェア圧縮が多くのドライブで可 能で,およそ 2倍の容量になります. 単一のユニットおよび,1つの筐体に6台の ドライブと 120巻のテープを持ったマルチドライブテープライブラリが利用可 能です. テープはユニットにより自動的に交換されます. ライブラリの容量は 840GB以上に達します.

データはヘッドがメディアに対してある傾き (約6度) を持って配置 されているヘッドによるヘリカルスキャンを使ってテープに記録されます. テープは ヘッドのある円筒の周の 270度にわたって接触します. テープが円筒面を走行 する間, 円筒は回転しています. この結果, トラックはテープの上端と下端の間に 角度を持って横切り, データは高密度に詰められることになります.

QIC-150テープとドライブはたぶん最も一般的に使われているドライブとメ ディアでしょう。QICテープドライブは現実的なバックアップドライブとして 少なくとも高価なものではありません. 欠点はメディアのコストです. QICテー プは 8mmや 4mmテープに比較して GBのデータの保存には5倍ほど高価です. しかしあなたの必要とする量が半ダース程のテープで十分であれば, QICは正 しい選択となるかもしれません. QICは 最も一般的なテープドライ ブです. すべてのサイトに QICドライブのどれかの容量のものがあります. 問題は, QICは同じようなテープ (まったく同じ場合もある) に多様な記録密度 があることです. QICドライブは静かではありません. これらのドライブはデー タ記録を開始する前に音をたててシークしますし, リード, ライト, シークの 時にはっきりと聞こえる音を出します. QICテープの大きさは (6 x 4 x 0.7 インチ; 152 x 102 x 17 mm). で使われている 1/4インチ幅のテープについては別に 議論します. テープライブラリやチェンジャはありません.

データスループットは 150kB/sから 500kB/sの範囲です. データ容量 の範囲は 40MBから 15GBです. ハードウェア圧縮が最近の多くのドライブで使 えるようになっています. QICドライブは DATドライブに置き換えられつつあ り,あまり多くインストールされなくなっています.

データは複数のトラックにわかれてテープに記録されます. トラックはテープメディアの長さ方向に沿っていて, 一端からもう一方の端ま でです. トラックの 数とそれにしたがうトラックの幅はテープの容量によって変わります. すべてではあ りませんがほとんどの最近のドライブは少なくとも読み出しについては (場合 によっては書き込みも) 下位互換性があります. QICはデータの安全性につ いてはよいといわれています (ヘリカルスキャンドライブに比べて機構は単純 でより丈夫です).

テープは 5000回のバックアップで寿命となるでしょう.

DLTはここに示したドライブのタイプの中で最高速のデータ転送レー トです. 1/2インチ (12.5mm) テープが単リールのカートリッジ (4 x 4 x 1 イン チ; 100 x 100 x 25 mm) に入っています. カートリッジのひとつの側面全体が スイングゲートになっています. ドライブの機構がこのゲートを開け, テープ リーダを引き出します. テープリーダには楕円形の穴があり, ドライブ がテープを引っ掛けるのに使います. 巻き取りのためのリールはドライブの中 にあります. ここに挙げた他のカートリッジはすべて (9トラックテープはただ 1つの例外です) 送りだしリールと巻き取りリールの両方がカートリッジの中 にあります. データスループットは約1.5MB/sで, 4mm, 8mm, QIC テープドライブ の3倍です. データ容量は単一のドライブで 10GBから 20GBの範囲です. マルチテープチェンジャ,マルチテープドライブ,5から 900巻のテープを1から 20ドライブで扱うマルチドライブテープライブラリがあり, 50GBから 9TBの容量が得 られます. データは (QICテープのように) テープの走行方向に並列なトラックに 記録されます. 2つのトラックが同時に書かれます. Read/Writeヘッドの寿命 は比較的長いと言えます. テープの走行が止まればヘッドとテープの間の相対 運動はありません. 新品のテープを最初に使う場合

新品の完全な空テープを読もうとしたり書き込もうとすると処理 は失敗するでしょう. 次のようなコンソールメッセージが出るでしょう. st0(ncr1:4:0): NOT READY asc:4,1 st0(ncr1:4:0): Logical unit is in process of becoming ready テープに識別ブロック (Identifire Block:block number 0) がありません. QIC-525標準の採用されている QICテープドライブのすべてで識別ブロックをテー プに書きます. 2つの解決方法があります.

(訳注: 方法1)mt fsf 1 によってテープドライブは識別 ブロックをテープに書きます.

(訳注: 方法2)フロントパネルのボタンを押してテープをとりだします.

再びテープを入れ,データをテープに dump(8)します.

dump(8) はそのうちに DUMP: End of tape detected と表示し, コンソールには HARDWARE FAILURE info:280 asc:80,96と表示されるでしょう.

mt rewindを使ってテープを巻戻します.

この次からはテープの操作は成功するでしょう. バックアッププログラム

よく使われる3つのプログラムはdump(8), tar(1), cpio(1)です. ダンプとリストア

dump(8) と restore(8) は伝統的な Unixのバッ クアッププログラムです. これらはドライブのファイルシステムによって作ら れたファイル,リンク,ディレクトリをディスクブロックの集まりとして処理し ます. dump(8)はデバイスやファイルシステム全体をバックアップし, 一部分のバックアップや, ln(1)によるソフトリンクや他のファイル システムをマウントを行った, 1つ以上のファイルシステムにまたがるディレ クトリツリーのバックアップはできません. dump(8)はファイルやディレクトリを構成するデータブロックをテー プに書くだけで, ファイルやディレクトリをテープに書くことはありません. dump(8)には初期の ATT UNIXのバージョン 6 (1975年ごろ) に由来する 癖が残っています. デフォルトのパラメタは 9トラックテープ (6250 bpi) に 適したものになっていて現在の高密度メディア (最大 62,182 ftpi) に適してい ません. 現在のテープドライブの容量を有効に利用するため, デフォルト値を コマンドラインで置き換えなければなりません.

rdump(8) と rrestore(8) は他のコンピュー タに接続されているテープドライブにネットワーク経由でバックアップをしま す.どちらのプログラムもリモートテープドライブにアクセスするために rcmd(3)と ruserok(3)に依存しています. このためユーザ がバックアップを実行するためには rhostsによるリモートアクセス が必要です.

rdump(8) と rrestore(8)の引数はリモー トコンピュータに適切なものを用います. rrestore(8)はリモートコンピュータから使うのに適しています. (例えば FreeBSDコンピュータより komodoという名前の Sunに接続されている Exabyteテープドライブへ /sbin/rdump 0dsbfu 54000 13000 126 komodo:/dev/nrst8 /dev/rsd0a 2>&1 として rdumpしたような場合の restoreに使います) 警告: セキュリティは rhostsの管理にかかっています. あなたの状況を注意深く調べてください. Tar

tar(1) ATT Unix のバージョン 6 (1975ごろ) にさかのぼ る事ができます. tar(1)はファイルシステムと協調して機能し, ファ イルやディレクトリをテープに書きます. tar(1)は cpio(1)で使えるようなフルレンジのオプションは持ちませんが cpio(1)で使うような奇妙なコマンドパイプラインは必要ありません.

tar(1) はネットワーク経由のバックアップの機能はあ りません. リモートテープドライブにはパイプラインと rsh(1)を使っ て送る事ができます. (コマンド使用例はまだです) Cpio

cpio(1) は本来の Unixファイルを磁気メディアへ移すた めのプログラムです. cpio(1)はバイトスワッピング, 多くの異な るアーカイブフォーマットの書き込みのオプション(それ以外にも多数のオプ ションがあります)がありパイプで他のプログラムにデータを渡す事もできま す. この最後に挙げた特徴により, cpio(1)はインストールメディア にとっては優れた選択です. cpio(1)はSTDINからの入力で なければならず,ディレクトリツリーの探索やファイルリストについての機能 はありません.

cpio(1)はネットワーク経由のバックアップの機能はあ りません. リモートテープドライブにはパイプラインと rsh(1)を使っ て送る事ができます. (コマンド使用例はまだです)

Amanda (Advanced Maryland Network Disk Archiver) は単一のプ ログラムではなくクライアント/サーバ型のバックアップシステムです. Amanda サー バは, Amandaクライアントであるネットワークでサーバに接続された複数のコン ピュータから一つのテープドライブへバックアップをおこないます. このような場合の一般的な問題はいくつもの大容量のディスクからデータディ レクトリをテープにバックアップするには時間がかかりすぎてしまうという事 です. Amanda はこの問題を解決します. Amandaは同時に複数のファイルシス テムのバックアップをおこなう時に 「ホールディングディスク」を使う事ができます. Amandaの設定ファイルに書いたすべてのファイルシステムのフルバックアップを ある間隔でとるためのテープグループである 「アーカイブセット」を作ります. これは Amandaの設定ファイルに書かれているすべてのファイルシステムが, ある 期間で作られるフルバックアップのテープのグループです. 「アーカイブセッ ト」には夜間に作られるすべてのファイルシステムの増分 (あるいは差分として ) のバックアップも含みます. 障害の起きたファイルシステムの回復に は最も新しいフルバックアップと増分のバックアップが必要です.

設定ファイルでバックアップのコントロールと Amandaによるネッ トワークトラフィック量を設定します. Amandaはデータをテープに書くのに バックアッププログラムのどれかを使うでしょう. Amandaはその一部分でも パッケージでも利用可能ですが, デフォルトではインストールされません. 何もしない

「何もしない」というのはコンピュータのプログラムではありませ んが, バックアップの戦略として最も広く採用されている物です. これには初 期投資が必要ありません. したがわなければならないバックアップスケジュールも ありません. ただ何もしないだけです. もしデータに何かが起きたら, 苦笑い して耐えてください.

あなたにとって時間やデータの価値が少ないかあるいはまったくない のであれば「何もしない」のはあなたのコンピュータに最も適したバックアッ ププログラムでしょう. しかし注意してください. Unixは便利なツールです. 6ヶ月も使っていれば価値のあるファイルの山ができ上がっているでしょう.

「何もしない」は /usr/obj やその他の, コンピュータに よってつくり出されたディレクトリツリーについては適切な方法です. 一つの 例はこのハンドブックのファイルで, これらは SGMLのファイルより 生成された物です. HTMLファイルのバックアップを作る必要はあ りません. SGMLのソースファイルは定期的にバックアップされます. どのバックアッププログラムが最適でしょう?

定期的に dump(8)しましょう. Elizabeth D. Zwicky はここで検討したプログラムすべてについて拷問的なテストをおこないま した. すべてのデータと Unixファイルシステムの状態すべてを保存するには明ら かに dump(8)でしょう. Elizabethは大きく変化に富んだ異常な状態 (いくつかはあまり異常でもない状態のものもあります) になっているファイ ルシステムで, それぞれのプログラムでファイルシステムのバックアップとリ ストアを行ってテストしました. 特色のある状態には, ホールを持つファイル, ホールとヌルブロックを持つファイル, 奇妙な文字をファイル名に持つファイ ル, 読み出し不可, 書き込み不可のファイル, デバイスファイル, バックアッ プ中にファイルのサイズを変更する, バックアップ中にファイルの作成/削除 をおこなうなどがあります. 彼女は1991年10月の LISA Vで結果の発表をしていま す. 緊急時のリストア手順 災難の起きる前に

起き得るどのような災難に対しても以下の4ステップだけが必要な 準備です.

ステップ 1では, ファイルシステムテーブル(/etc/fstab) やブートメッセージで示されるすべてのディスクの disklabelをそれぞれ2コピー づつプリント (例えば disklabel sd0 | lpr とする) します.

ステップ 2では, boot と fixitフロッピーにそのシステムのすべ てのデバイスドライバが含まれているか確認します. 最も簡単な確認の方法は, フロッ ピーをドライブに入れてリブートし, ブートメッセージを確認することです. あなた のシステムのデバイスがすべて含まれ, 機能していれば, step 3へ飛んでください.

そうでないなら, そのシステムのすべてのディスクをマウントでき, テープドライブにもアクセスできる 2種類のカスタムブートフロッピーディスクを作る必要 があります. これらのフロッピーには fdisk(8), disklabel(8), newfs(8), mount(8), と利用したい バックアッププログラムが入っていなければなりません. これらのプログラム はスタティックリンクされたプログラムである必要があります. dump(8)を使うのであればフロッピーに restore(8)を入れ る必要があります.

ステップ 3では, 通常の方法でバックアップを作ります. 最新のバックアップの後でおこなわれた変更は回復することはできません. バックアップテープにライトプロテクトをしてください.

ステップ 4では, フロッピー (boot.flp と fixit.flp あるいは ステップ 2で作った2枚のカスタムブートフロッピーディスクです) とバックアップテー プのテストをします. 手順のノートを作りましょう. このノートはブートフロッピーディスク,バックアッ プテープに入れておきプリントアウトしておきます. あなたがリストアをおこなう ような時はおそらく錯乱状態でしょうからこのノートはバックアップを破壊し てしまうようなことを防ぐのに役立つでしょう (どのようにして破壊するって? tar xvf /dev/rst0とする替りに偶然 tar cvf /dev/rst0 とタイプしてバックアップテープに上書きしてしまうかもしれません). 訳注: 上書きはライトプロテクトをしておけば防げますが, なんらかの原因で プロテクトがはずれているかもしれません. ちなみに訳者の経験から言えば上のようなミスタイプは結構起きます.

安全性を増すために, 毎回ブートフロッピーディスクを作り,2巻のバック アップテープを取ります. 一方を離れた場所に保管します. 離れた場所は同じ 建物の地下室ではいけません. 世界貿易センタービルにあった数多くの会社は 苦い経験よりこの教訓を得ました. 離れた場所とはコンピュータやディスク ドライブからかなり離れていて物理的に分離されていなければなりません.

ブートフロッピーディスクを作るスクリプトの一例 #!/bin/sh # # create a restore floppy リストアフロッピーの作成 # # format the floppy フロッピーのフォーマット # PATH=/bin:/sbin:/usr/sbin:/usr/bin fdformat -q fd0 if [ $? -ne 0 ] then echo "Bad floppy, please use a new one" exit 1 fi # place boot blocks on the floppy フロッピーにブートブロックを書く # disklabel -w -B -b /usr/mdec/fdboot -s /usr/mdec/bootfd /dev/rfd0c fd1440 # # newfs the one and only partition ただ1つのパーティションを newfs # newfs -t 2 -u 18 -l 1 -c 40 -i 5120 -m 5 -o space /dev/rfd0a # # mount the new floppy 新しいフロッピーをマウント # mount /dev/fd0a /mnt # # create required directories 必要なディレクトリの作成 # mkdir /mnt/dev mkdir /mnt/bin mkdir /mnt/sbin mkdir /mnt/etc mkdir /mnt/root mkdir /mnt/mnt # for the root partition mkdir /mnt/tmp mkdir /mnt/var # # populate the directories # # MINIカーネルがない場合は作ります if [ ! -x /sys/compile/MINI/kernel ] then cat << EOM The MINI kernel does not exist, please create one. Here is an example config file: # MINIカーネルの config fileの例 # MINI -- A kernel to get FreeBSD on onto a disk. # machine "i386" cpu "I486_CPU" ident MINI maxusers 5 options INET # needed for _tcp _icmpstat _ip stat # _udpstat _tcpstat _udb options FFS #Berkeley Fast File System options FAT_CURSOR #block cursor in syscons or pcc ons options SCSI_DELAY=15 #Be pessimistic about Joe SCSI device options NCONS=2 #1 virtual consoles options USERCONFIG #Allow user configuration with -c XXX config kernel root on sd0 swap on sd0 and sd1 dumps on sd0 controller isa0 controller pci0 controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr disk fd0 at fdc0 drive 0 controller ncr0 controller scbus0 device sc0 at isa? port "IO_KBD" tty irq 1 vector scintr device npx0 at isa? port "IO_NPX" irq 13 vector npxintr device sd0 device sd1 device sd2 device st0 pseudo-device loop # required by INET pseudo-device gzip # Exec gzipped a.out's EOM exit 1 fi cp -f /sys/compile/MINI/kernel /mnt gzip -c -best /sbin/init > /mnt/sbin/init gzip -c -best /sbin/fsck > /mnt/sbin/fsck gzip -c -best /sbin/mount > /mnt/sbin/mount gzip -c -best /sbin/halt > /mnt/sbin/halt gzip -c -best /sbin/restore > /mnt/sbin/restore gzip -c -best /bin/sh > /mnt/bin/sh gzip -c -best /bin/sync > /mnt/bin/sync cp /root/.profile /mnt/root cp -f /dev/MAKEDEV /mnt/dev chmod 755 /mnt/dev/MAKEDEV chmod 500 /mnt/sbin/init chmod 555 /mnt/sbin/fsck /mnt/sbin/mount /mnt/sbin/halt chmod 555 /mnt/bin/sh /mnt/bin/sync chmod 6555 /mnt/sbin/restore # # create the devices nodes デバイスノードを作る # cd /mnt/dev ./MAKEDEV std ./MAKEDEV sd0 ./MAKEDEV sd1 ./MAKEDEV sd2 ./MAKEDEV st0 ./MAKEDEV pty0 cd / # # create minimum filesystem table 最小限のファイルシステムテーブル # cat > /mnt/etc/fstab < /mnt/etc/passwd < /mnt/etc/master.passwd < 災難の後に

重要な問題は, ハードウェアが生き残ったかどうかです. 定期的なバックアップを取っていればソフトウェアについて心配する必要はあ りません.

ハードウェアがダメージを受けていたら, 最初にそのダメージを 受けた部品を交換してください.

ハードウェアに問題がなければ, フロッピーをチェックしてくださ い.カスタムブートフロッピーディスクを使っているのであればシングルユーザ ("boot:"プロンプトの出た時に "-s" とタイプしてください) でブートしてくださ い. それから次の「ファイルシステムを1つずつ回復する」を読んでください。

boot.flp と fixit.flp を使っているのであればこのまま読み続けてくださ い. boot.flp を入れてブートしてください. 本来のインストールメニューが表 示されるはずです. (ここで) "fixit XXX"オプションを選びます. 指示の通り fixit.flp を入れてください. restoreとその他の必要なプログラムは /mnt2/standに置かれています.

ファイルシステムを一つずつ回復する

最初のディスクのrootパーティションをmount(8) (例えば mount /dev/sd0a /mntのように) マウントして見てください. ディスクラベルが 破壊されている場合は disklabel(8)を使ってあらかじめプリントし ておいた通りにパーティションを作り直しラベルをつけてセーブしてください. newfs(8)を使いファイルシステムを作り直します. ルー トパーティションを読み書き可能にマウント ("mount -u -o rw /mnt") しなおします. バックアッププログラムとバックアップテープを 使ってこのファイルシステムのデータを回復します (例えば restore vrf /dev/st0とします). ファイルシステムをアンマウント (umount /mntなど) して, 障害を受けたファイルシステムそれぞれについて繰り返 してください.

システムが動き出したら, 新しいテープにデータをバックアップ してください. どのような理由で再び事故が起きたりデータが失われるかはわか りません. これに時間を費す事で, 後々の災難から救われる事になります. * 災難対策をしていませんでした. どうしたらいいでしょ う? * シリアルポート * サウンドカード * PCMCIA * その他 diff --git a/ja/handbook/install.sgml b/ja/handbook/install.sgml index 32b25ece32..c6556da7b5 100644 --- a/ja/handbook/install.sgml +++ b/ja/handbook/install.sgml @@ -1,843 +1,843 @@ - + FreeBSDのインストール

原作: 不明

訳: &a.mita;, &a.hanai;, &a.iwasaki;. 11 November 1996.

それでは, FreeBSD のインストールに挑戦してみましょう. この章には, あなたが何をする必要があるかの簡単なガイドが 書いてあります. FreeBSD は, CD-ROM, フロッピーディスク, 磁気テープ, MS-DOSのパーティション, ネットワーク接続しているところでは anonymous FTP や NFS を通じてインストールすることができます. どのインストールメディアを利用する場合も, まずインストールディスク をダウンロードするところから始まります. このディスクであなたの コンピュータを立ち上げることで, FreeBSD とあなたのハードウェアとの 相性に関する重要な情報を手に入れることができ, このハードウェアでは どんなインストールオプションが使えるかを指定することができます. もしもあなたが anonymous FTP を使用してインストールする予定なら, インストールディスクだけをダウンロードすればOKです. FreeBSDの配布に関する情報は, 付録の をご覧ください. 仕事にとりかかるには, 以下のような手順を踏みます. このインストールガイドの の節を読んで, あなたのハードウェアが FreeBSD でサポートされていることを確認します. SCSI コントローラだとか, イーサネットアダプタだとか, サウンドカードだとかの, あなたのマシンが 装備している特別なカードのリストを作っておくと便利です. この リストには, 割り込み番号 (IRQ) とか, IO ポートのアドレスとかの, カードに 関係する設定も書いておきましょう. ファイルをあなたの ハードディスクにダウンロードしてきます. ブラウザのコマンドでは, display ではなくて save を選ぶことに注意してください. 注意: このディスクイメージは, 1.44 メガバイトの 3.5 インチフロッピーディスクと, 1.2 メガバイトの 5.25 インチフロッピーディスク のどちらでも使用可能です. このイメージファイルからブートディスクを作成します, MS-DOSを使っている場合: をダウンロードして, これを実行します. C:\> rawrite このプログラムを実行すると, 書き込むフロッピードライブ (A: か B: か) を聞いてきて, その後に書き込むファイルの名前 (boot.flp) を聞いてきます.

注: rawrite.exe に関しては, Windows95 上では DOS モードで のみ動作し, Windows NT 上では全く動作しないという報告が多く寄せられて います. Windows NT マシンをお使いの場合は, 別のマシンを使ってフロッピー イメージを作成してください. また Windows95 をお使いでしたら, まず DOS モードで起動してから作業してください.

UNIX システムを使っている場合: % dd if=boot.flp of=disk_device を実行します. ここで, disk_device はフロッピードライブに 対応する /devの中のエントリです. FreeBSD では, /dev/fd0 が A:ドライブに, /dev/fd1 が B:ドライブに 対応しています. インストールディスクを A:ドライブに入れて, コンピュータを 立ち上げ直します. そうすると次のようなプロンプトが出てくるはずです. >> FreeBSD BOOT ... Usage: [[[0:][wd](0,a)]/kernel][-abcCdhrsv] Use 1:sd(0,a)kernel to boot sd0 if it is BIOS drive 1 Use ? for file list or press Enter for defaults Boot: ここで何もタイプしない場合, 5秒間の待ち時間の後に FreeBSD は 自動的にデフォルトの設定で立ち上がります. 立ち上げの際, どんな ハードウェアが装備されているかを検出 (プローブ) します. この結果は スクリーン上に表示されます. 立ち上げプロセスが終了したら, FreeBSD インストールメニューが 表示されます.

もしも問題が起こった場合

PC アーキテクチャの制限のため, 100パーセントの信頼をもって検出する ことは不可能です. もしもあなたのハードウェアが間違って認識されたり, 検出途中でコンピュータが固まってしまうようなことが起こった場合, まずこのガイドの の節を読んで, あなたのハードウェアが本当に FreeBSD でサポートされているかどうかを確かめてください.

ハードウェアがサポートされていた場合, リセットして Boot: プロンプトが出てきたところで, -c と打ち込んで ください. こうすると, FreeBSD はコンフィグレーションモードになり, ハードウェアに関する情報を FreeBSD に与えることができるようになります. インストールディスクの FreeBSD カーネルは, 多くのデバイスの IRQ, IO アドレスが工場出荷時の値に設定されているものと仮定して作られています. もしもあなたのハードウェアの設定を変更したなら, -c オプションで立ち上げて, 設定がどうなっているかを指定してあげること が必要になるでしょう.

存在しないデバイスを検出すると, 実際に存在している他のデバイスの 検出に失敗することが考えられます. そのような場合は, 衝突している デバイスを無効にしなくてはなりません.

コンフィグレーションモードでは, カーネルに組み込まれているデバイスドライバの一覧を表示する あなたのシステムにないハードウェアのデバイスドライバを無効にする デバイスドライバの IRQ, DRQ, IO ポートアドレスなどの変更する などができます.

config> プロンプトが出ているところで, help と打ち込むと, 使用可能なコマンドについての詳しい説明が出てきます. あなたのマシンのハードウェア設定に合うようにカーネルを変更したら, config> プロンプトが出たところで quit と打ち込んで, 新しい設定でマシンを立ち上げます. FreeBSD のインストールがひとたび終了した後は, コンフィグレーションモード での変更はずっと保持されますので, 立ち上げのたびに設定変更をする必要は なくなりますが, あなたのシステムの性能を高めるために, カスタムカーネルを作るのが好ましいでしょう. カスタムカーネルの作成に関しては, の章をご覧ください. サポートされている設定一覧

現在 FreeBSD は, ISA, VL, EISA, PCI バスや, 386SX から Pentium クラス までのさまざまな種類の PC で動作します (386SXはおすすめではありません). IDE, ESDIドライブや, さまざまな SCSI コントローラ, ネットワークカードや シリアルカードにも対応しています. FreeBSD を走らせるには, 最低 4メガバイトの RAM が必要です. X Window System を 走らせるには最低でも 8メガバイトの RAM が推奨されます. 以下のリストでは, FreeBSD で動作が確認されているディスクコントローラ やイーサネットカードです. 他の設定でもうまく動いてくれると 思いますが, 私たちのところには情報は入ってきていません. ディスクコントローラ

WD1003 (あらゆる MFM/RLL) WD1007 (あらゆる IDE/ESDI) IDE ATA Adaptec 152x シリーズ ISA SCSI コントローラ Adaptec 154x シリーズ ISA SCSI コントローラ Adaptec 174x シリーズ EISA SCSI コントローラ (スタンダード, エンハンスドモード) Adaptec 274x/284x/2940/3940 (Narrow/Wide/Twin) シリーズ EISA/VLB/PCI SCSI コントローラ Adaptec AIC7850 オンボード SCSI コントローラ Adaptec AIC-6360系のボード AHA-152x や SoundBlaster SCSI などがこれにあたります. 注意: Soundblaster カードには, オンボード BIOS が載っていないので, このカードからは FreeBSD を起動できません. オンボード BIOS とは, システム BIOS の I/O ベクタにブートデバイスを 登録するときに必要なものです. このカードは外部テープであるとか, CD-ROM であるとかその他の場合には十分利用可能です. 同じことは, ブート ROM の載っていない AIC-6x60 系のカードにもいえます. いくつかのシステムでは実際にブート ROM を持っています. それは電源を入れるかリセットしたとき, 最初に表示されます. 詳しくはあなたのシステムやボードの解説書をご覧ください. Buslogic 545S & 545c 注意: Buslogic社は古くは Bustek社といっていました. Buslogic 445S/445c VLバス SCSI コントローラ Buslogic 742A, 747S, 747c EISA SCSI コントローラ. Buslogic 946c PCI SCSI コントローラ Buslogic 956c PCI SCSI コントローラ NCR 53C810 , 53C825 PCI SCSI コントローラ. NCR5380/NCR53400 (``ProAudio Spectrum'') SCSI コントローラ. DTC 3290 EISA SCSI コントローラ (1542 エミュレーション) UltraStor 14F, 24F, 34F SCSI コントローラ. Seagate ST01/02 SCSI コントローラ. Future Domain 8xx/950 シリーズ SCSI コントローラ. WD7000 SCSI コントローラ. サポートされている SCSI コントローラのすべてで, ディスク, テープドライブ (含む DAT), CD-ROM ドライブなどの周辺機器との通信に SCSI-I, SCSI-II が利用可能です. 現在, 次にあげるタイプの CD-ROM ドライブがサポートされてます. Soundblaster SCSI , ProAudio Spectrum SCSI (cd) ミツミ (全モデル) 独自のインタフェース (mcd) 松下 / Panasonic (Creative) CR-562/CR-563 インタフェース (matcd) ソニー インタフェース (scd) ATAPI IDE インタフェース (まだまだお試し段階で, クオリティは低いです) (wcd) イーサネットカード

Allied-Telesis AT1700, RE2000 カード SMC Elite 16 WD8013 Ethernet インタフェース, その他多くの WD8003E, WD8003EBT, WD8003W, WD8013W, WD8003S, WD8003SBT や WD8013EBTなどの互換品. SMC Elite Ultra もサポートされています. DEC EtherWORKS III ネットワークインタフェースカード (DE203, DE204, DE205) DEC EtherWORKS II ネットワークインタフェースカード (DE200, DE201, DE202, DE422) DEC DC21140/DC21141/DC21140 ベースのネットワークインタフェースカード: ASUS PCI-L101-TB Accton ENI1203 Cogent EM960PCI Compex CPXPCI/32C D-Link DE-530 DEC DE435 Danpex EN-9400P3 JCIS Condor JC1260 Linksys EtherPCI Mylex LNP101 SMC EtherPower 10/100 (Model 9332) SMC EtherPower (Model 8432) SMC EtherPower (2) Zynx ZX342 DEC FDDI (DEFPA/DEFEA) ネットワークインタフェースカード 富士通 FMV-181, FMV-182 富士通 MB86960A/MB86965A Intel EtherExpress Intel EtherExpress Pro/100B 100Mbit. Isolan AT 4141-0 (16 bit) Isolink 4110 (8 bit) Novell NE1000, NE2000, NE2100 イーサネットインタフェース 3Com 3C501 カード 3Com 3C503 Etherlink II 3Com 3c505 Etherlink/+ 3Com 3C507 Etherlink 16/TP 3Com 3C509, 3C579, 3C589 (PCMCIA) Etherlink III 3Com 3C590, 3C595 Etherlink III HP PC Lan Plus (27247B と 27252A) 東芝 イーサネットカード IBM , National Semiconductor社 PCMCIA イーサネットカードもサポートされています.

注意: FreeBSD は今のところ, いくつかのイーサネットカードの PnP (プラグ&プレイ) 機能には対応していません. もし PnP で問題が起こる ようでしたら, PnP 機能を無効にしてください. その他のデバイス

AST 4 ポート シリアルカード (シェアード IRQ 使用) ARNET 8 ポート シリアルカード (シェアード IRQ 使用) BOCA IOAT66 6 ポート シリアルカード (シェアード IRQ 使用) BOCA 2016 16 ポート シリアルカード (シェアード IRQ 使用) Cyclades Cyclom-y シリアルボード STB 4 ポート カード (シェアード IRQ 使用) SDL Communications Riscom/8 シリアルボード SDL Communications RISCom/N2 と N2pci 同期シリアルカード Digiboard Sync/570i high-speed 同期シリアルカード Decision-Computer Intl. "Eight-Serial" 8 ポートシリアルカード (シェアード IRQ 使用) Adlib, SoundBlaster, SoundBlaster Pro, ProAudioSpectrum, Gravis UltraSound, Gravis UltraSound MAX Roland MPU-401 などのサウンドカード Matrox Meteor video フレームグラバー Creative Labs Video spigot フレームグラバー Omnimedia Talisman フレームグラバー X-10 power コントローラ PC ジョイスティックおよびスピーカ FreeBSD は今のところ, IBM社のマイクロチャネルアーキテクチャ (MCA) バスには 対応していません. インストールの下準備

FreeBSD のインストール方法はさまざまあります. それぞれの インストール方法に対して, どのような下準備が必要かをこれから説明します. CD-ROM からインストールする前に

あなたの CD-ROM ドライブがサポートされていないタイプの場合は, に飛んでください. Walnut Creek の FreeBSD CD-ROM からインストールする場合は, 大した下準備 をしないでもうまくインストールできることでしょう (その他の CD-ROM でもうまくいくでしょうが, その CD-ROM がどうやって作られているか, 私たち はわかりませんので確実なことは言えません). Walnut Creek の CD-ROM に収録されている, ``install.bat'' で直接 FreeBSD を立ち上げることもできますし, ``makeflp.bat'' でブートフロッピーディスクを つくることもできます. [注意: もし FreeBSD 2.1-RELEASE を使っていて IDE CD-ROM ドライブを持っている場合, install.bat のかわりに inst_ide.bat もしくは atapiflp.bat を使ってください. ] DOS から最も楽なインタフェースを使いたい場合は ``view'' と打ち込みます. そうすると DOS でのメニューが立ち上がって, 可能なオプション すべてを選択できます. あなたが UNIX マシンでブートフロッピーディスクを作成している場合は, を参考にしてください. DOS から, もしくはフロッピーディスクから起動をおこなうと, メニュー ``Media'' から, インストールメディアとして CDROM を 選択することで, 配布ファイルをロードすることができるようになります. 他の種類のインストールメディアは不要なはずです. システムインストールがすべて終了して, ハードディスクから起動 しなおしてからは, mount /cdrom とタイプする ことでいつでも CD-ROM のマウントをすることができるようになります. CD-ROM を取り出す前には 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://あなたのマシンのアドレス を入力します. フロッピーディスクからのインストールの前に

あなたがフロッピーディスクからのインストールをしなくては ならない場合, その理由はハードウェアがサポートされてなかったためか, 単にいばらの道を通ることを楽しんでいるからでしょうが, インストール用の フロッピーディスクを用意する必要があります. 最低でも bin (基本配布ファイル) ディレクトリ内のすべてのファイル を入れられるだけの 1.44 メガバイトか 1.2 メガバイトのフロッピーディスク が必要です. これらのフロッピーディスクを DOS で作成している場合は, フロッピーディスクは「MS-DOS の FORMAT コマンドでフォーマット」 されなくてはなりません. Windows をお使いの場合は, Windowsの ファイルマネージャの初期化コマンドを使用してください. 工場での初期化済みディスクを「信用しないでください」. 念のためにあなた 自身でフォーマットし直してください. ユーザからのトラブル報告の多くは ちゃんと初期化されていないディスクを使用していたことが原因となっています. 私が特にフォーマットし直してくださいと述べているのも, この理由からです. 他の FreeBSD マシンでフロッピーディスクを作成している場合, フォーマットすることは悪いことではありません. いちいち DOS ファイルシステムのフロッピーディスクを作成する必要はありませんので, `disklabel' コマンドと `newfs' コマンドを使って, 次のような手順で (3.5 インチ 1.44 メガバイトディスク用の) UFS ファイルシステムを 作成することもできます. fdformat -f 1440 fd0.1440 disklabel -w -r fd0.1440 floppy3 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 /S E:\BIN C:\FREEBSD\BIN\ C> XCOPY /S E:\MANPAGES C:\FREEBSD\MANPAGES\ ここで, C:ドライブには十分なディスクスペースが残っており, CD-ROM は E:ドライブに接続されているものとします. MS-DOS からたくさんの `配布ファイル (DISTS)' をインストールしたい (そしてディスクの余裕がある) 場合は, それぞれ C:\FREEBSD ディレクトリにコピーします - BIN 配布ファイルは, 最低限必要なものです. QIC/SCSI テープからのインストールの前に

テープからのインストールは, おそらく FTP を利用したオンライン インストールか, CD-ROM を利用したインストールができない場合の, もっとも簡単な方法でしょう. インストールプログラムは, 以下のような コマンドを使用して, 単純に配布ファイルがテープ上に tar されていることを 期待しています. cd /freebsd/distdir tar cvf /dev/rwt0 (または /dev/rst0) dist1 .. dist2 インストールに入る前に, テンポラリ (一時使用) ディレクトリに 十分なディスクスペースを確保して, 作成したテープのすべての ファイルを格納できることを確認してください (テンポラリディレクトリは 自分で選ぶことができます). テープの特性上, ランダムにアクセスするこ とができませんので, 一時的に極めて大量の容量を必要とします. テープに準備しただけの量のディスクスペースを一時的に使用することに 留意してください. 注意: インストールに入るときは, ブートフロッピーディスク から立ち上げる前にテープをドライブに入れておかなくてはなりません. さもないとインストール時のデバイス検出のときにテープを見つけられません. ネットワーク経由のインストールの前に

三つの物理的な接続形態で, ネットワーク経由のインストールを おこなうことができます. シリアルポート SLIP もしくは PPP 方式. パラレルポート PLIP (laplink ケーブル使用) イーサネット 標準的なイーサネットコントローラ (いくつかの PCMCIA カードにも対応) SLIP のサポートはまだまだ原始的とも呼べる方法なので, ラップトップと 他のコンピュータをシリアルケーブルで接続するといった具合いに, 直接接続してなくてはいけません. SLIP インストールは, ダイヤル機能を 持っていませんので, インストールするためには直接接続しなくてはなりません. PPP インストールではダイヤルアップ接続が可能ですので, できれば PPP 接続の 方を選択しましょう. もしもあなたがモデムを使用しているなら, あなたに残された選択肢は ほぼ間違いなく PPP インストールでしょう. インストール時に必要になりますので, サービスプロバイダ (ISP) に関する情報を用意しておきましょう. 少なくともプロバイダと, 可能ならあなたの IP アドレスを知っておかなくては なりません (IP アドレスの欄を空白にしておいて, PPP に IP アドレスの 割り当て処理をさせてもかまいません). PPP ダイヤルの際は, とても シンプルな端末エミュレータで作業することになりますので, お手持ちのモデムで ISP にダイヤルするために, ``ATコマンド'' の使い方を知っておく必要があります. FreeBSD (2.0R 以降) の動いている別のマシンと直接接続が可能でしたら, ``laplink'' パラレルポートケーブルで接続することを考えてみましょう. パラレルポート経由のデータ転送スピードは, シリアルラインでの 一般的なスピード (最高 50kbit/sec) よりもずっと高速ですので, 高速にインストールすることができます. 最後になりますが, ネットワークインストールのうちでもっとも高速なものとしては イーサネットアダプタを使用するのがあげられます. FreeBSD ではきわめて多くの PC イーサネットカードをサポートしています. サポートされている カードの表 (と, 必要な設定) は, に書いてあります. サポートされている PCMCIA カードを使っている場合には, ラップトップの電源を 入れる「前」に差し込んでおくことにも注意してください. 残念ながら今の FreeBSD は, インストール時の活線挿抜には対応していません. ネットワークでの IP アドレス, あなたのアドレスクラスに対応した ネットマスク, マシン名を知っておくことも必要です. ネットワーク管理者の方に たずねればどんな値を使ったらよいかを教えてくれるでしょう. もしも他のホストを IP アドレスではなくて名前で引きたい場合, ネームサーバとゲートウェイ のアドレスも知らなくてはなりません (PPP をご使用の場合は, プロバイダの IP アドレスになります). これらのうちのすべて, またはいくつかを 知らない場合は, イーサネット経由でのインストールを始める前に「まず」 ネットワーク管理者に相談してください. 何らかのネットワーク接続ができたら, 続けてインストールを NFS か FTP 経由でおこないます. 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 ファイルでは, このことは ``-alldirs'' オプションによって制御されています. 他の NFS サーバの場合だとまた話が違ってくるかもしれません. もしもサーバから `Permission Denied' というメッセージが 返ってくるようでしたら, サブディレクトリマウントをちゃんと 有効にできていないことが考えられます. FTP インストールのための下準備

FTP 経由のインストールは, FreeBSD &rel.current; の最新バージョンを ミラーしているどのサイトからでも可能です. 世界中の妥当な FTP サイトの 選択肢をメニューに並べておきました. このメニューに出ていない他の FTP サイトからインストール する場合や, ネームサーバの設定に問題が生じた場合は, メニューでサイト ``Other'' を選ぶところで, お好みの URL でサイトを指定することができます. URL として直接 IP アドレスで指定してもよく, 直接指定した場合はネームサーバ がなくても FTP インストールが可能になります. 例えば, ftp://192.216.222.4/pub/FreeBSD/&rel.current;-RELEASE のような感じですね. FTP 経由のインストールモードとして, このようなものが 使用可能です: FTP Active すべての FTP 転送の際に ``Active'' モードを使用します. ファイアウォール内部のマシンではうまく動きませんが, passive モードをサポートしていない古い FTP サーバでも 動作します. passive モードでの FTP 転送 (こちらが デフォルトです) が失敗した場合は, active を使ってください. FTP Passive すべての FTP 転送の際に ``Passive'' モードを使用します. このモードを使用することで, ランダムポートアクセスインを 許さないファイアウォールを越えることができるようになります. 注意: Active, passive モードは `proxy' 接続のような, FTP の proxy サーバがことなるポートを監視している ような接続とはまた違います. このような場合は, URL に例えば ftp://foo.bar.com:1234/pub/FreeBSD のような表記を使うことができます. ここで, ``1234'' は proxy FTP サーバのポート番号です. FreeBSD のインストール

インストールの下準備を適切に書き留めておけば, なんの 問題もなく FreeBSD のインストールができることと思います. 何かうまくいかなかった場合は, あなたが使おうとしている インストールメディアのことが書いてある箇所まで戻って もう一度読むとよいでしょう. おそらく最初読んだときに 見落していた, 有効なヒントがあるものと思います. ハードウェアの問題が出てきたとか, FreeBSD がまったく 立ち上がらない場合は, boot フロッピーディスクに提供されている Hardware Guide を読んで, 何か解決方法はないか探してください. FreeBSD のブートフロッピーディスクには, インストールをおこなうために 必要と思われるすべてのオンラインドキュメントを用意してあります. もしもそのドキュメントがお望みのものでないようでしたら, 私たちはあなたが何にもっとも困っているのかを知りたいと思います. コメントを &a.doc; にお送りください. FreeBSD のインストールプログラム (sysinstall) を, うっとうしい ``step-by-step'' ガイドなしに, プログラム自身で使用方法がわかるようにするのが最終目標です. 目標達成までには時間がかかりそうですが, ともかくそれが 目標なのであります. 閑話休題. ここに, 「典型的なインストールの手順」を まとめてみましたので, お役にたてるものと思います. ブートフロッピーディスクから起動します. ハードウェアの性能に よりますが, 起動には 30秒から 3分かかります. 起動したら 初期選択画面が出てくるでしょう, もしもフロッピーディスクから まったく起動しなかったり, どこかの段階で起動が止まってしまった 場合は, ハードウェアガイドの Q&A を読んで, 理由を 探ってみます. F1 キーを叩きます. メニューシステムとインストールプログラム 全般に対しての使い方が表示されます. このメニューシステムを 使ったことがない場合は, 「徹底的に」読んでください. Options を選択し, 他に必要な特別な選択を おこないます. 典型的なインストールでおまかせしたい方は Novice を, インストールのそれぞれの段階をいちいちコントロールしたい方は Custom を, (可能であれば適切なデフォルトを使用して) 簡単にさっさと済ませたい方は Express を, それぞれ好みに応じて選んでください. FreeBSD を初めて使う方には, Novice を一番におすすめします. final configuration メニューからは, メニュー形式のさらに 進んだ設定をおこなうことができます. ネットワーク周りの 設定は, 特に CD-ROM / テープ / フロッピーディスクから インストールして, まだネットワーク設定をおこなっていない 人にとっては特に重要でしょう. インストールの時点できちんと 設定しておけば, ハードディスクからシステムを立ち上げ直した 時点でネットワーク接続ができるようになっていることでしょう. MS-DOS ユーザのためのQ&A

多くのFreeBSD ユーザは, MS-DOS が入っている PC に FreeBSD を インストールしたいと考えます. そのようなシステムに FreeBSD をインストールする際によく聞かれる質問を集めて あります.

助けて! ディスクスペースが余ってないのです. 最初に MS-DOS のファイルを全部削除しないといけませんか? もしあなたのマシンですでに MS-DOS が走っていて, FreeBSD の インストール用の空きスペースが少ないか, まったくない場合でも 大丈夫です. FreeBSD の CD-ROM や, FTP サイトの tools ディレクトリに FIPS プログラムというのがありますが, これが非常に役立ちます. FIPS を使えば, すでに存在している MS-DOS のパーティションを 二つに分けることができ, さらにもともとのパーティションは 残してくれて, 二つめのパーティションを FreeBSD の インストールに使用することができるようになります. まず DOS6.xx についてくる DEFRAG か, Norton Disk ツールを使って, MS-DOS パーティションからフラグメント情報を取り去って, その後に FIPS を走らせます. FIPS ユーティリティから必要な情報が 手に入ります. その後マシンを立ち上げ直して, 空いた場所に FreeBSD をインストールします. どのくらいの空きスペースが インストールに必要かは, Distributions メニューを 参考にしてください. FreeBSD で MS-DOS の圧縮ファイルシステムにアクセス できますか? いいえ. もし Stacker(tm) や DoubleSpace(tm) のような ユーティリティをお使いの場合, FreeBSD は非圧縮の部分にしか アクセスできません. 残りの場所は一つの大きなファイルとして (stack された, もしくは doublespace されたファイルとして) 見えます. そのファイルを削除しないでください!! 削除してしまうと後できっと後悔します. 非圧縮の MS-DOS の基本区画を作って, そちらを MS-DOS と FreeBSD とのやり取りに使うのがよろしいでしょう. MS-DOS 拡張フォーマットをマウントできますか? はい. DOS 拡張パーティションは FreeBSD の他の「スライス」の最後に マップされます. 例えば D:ドライブ が /dev/sd0s5, E:ドライブが /dev/sd0s6, といった具合いです. もちろん, この例では拡張 パーティションが SCSI ドライブ 0 にあることを仮定しています. IDE ドライブでは当然, ``sd'' が ``wd'' となります. 他の DOS ドライブを マウントするのと同様に, 次のようにして拡張パーティションもちゃんと マウントできます: mount -t msdos /dev/sd0s5 /dos_d MS-DOS のバイナリを FreeBSD で実行できますか? まだです. この機能を実現するためのサポートを期待しているのですが, いまのところ実際にこの作業をしている人間はいません. BSDI には 寄贈された BSD 用の DOS エミュレータがあり, 徐々に FreeBSD-current に移植されつつあります. もしあなたがこの作業に加わりたいと思いましたら &a.emulation にご連絡ください. それまでの間, には, pcemu という素晴らしいアプリケーションがあり, これをつかうことで多くの MS-DOS のテキストモードで動くプログラムを完全な 8088CPU の エミュレーション環境で走らせることができます. diff --git a/ja/handbook/isdn.sgml b/ja/handbook/isdn.sgml index 7049295877..448c1e8720 100644 --- a/ja/handbook/isdn.sgml +++ b/ja/handbook/isdn.sgml @@ -1,231 +1,231 @@ - + ISDN

最終更新: &a.wlloyd;.

訳: &a.kiroh;.11 December 1996.

ISDN 技術とハードウェアに関しては, がよい参考になるでしょう. ISDN の導入手順は, 簡単にいって以下のようになります. ヨーロッパ在住の方は, ISDN カードの節に進んでください. ISDN を使って, インターネットプロバイダに(専用線は使用せず), ダ イアルアップ接続しようとしている場合は, ターミナルアダプタの使用を考え てみてください. この方法はもっとも柔軟性があり, プロバイダを変更した場 合の問題も少ないでしょう. 2つの LAN の間を接続しようする場合や, ISDN 専用線を使用する場合 には, スタンドアローンルータ/ブリッジの使用を勧めます.

どの方法を用いるかを決定するには, 費用が重要な要素になってきます. 以下に, 最も安価な方法から, 高価な方法まで順に説明していきます. ISDN カード

原著者:&a.hm;.

このセクションの記述は, ヨーロッパの ISDN ユーザにのみ有効です. サポートされているカードは, まだ北米の ISDN 標準には適合していないかもしれ ません(?).

このコードは, まだ大部分が開発段階にあります. とくにドライバに関し ては, 二つのメーカーのカードしかサポートしていません.

PC ISDN カードは, ISDN の最大のバンド幅 128Kbs をサポートします. こ れらのカードは, ISDN 機器のうちもっとも安価な部類に入ります.

FreeBSD 2.1.0 および 2.1.5 では, 初期の未完成の ISDN のためのコード が /usr/src/gnu/isdn に含まれていますが, 古いバージョンのものですの で使用しないでください. カーネルから ISDN をサポートしたい場合は, bisdn パッケージを入手してください. このコードは, FreeBSD 2.2 からメイ ンソースツリーから削除されています.

bisdn という ISDN パッケージが以下のURLから入手できます. FreeBSD 2.1R, FreeBSD-current, NetBSDがサポートされています. 最新のソースは, 上記のftpサーバの isdn ディレクトリから, bisdn-097.tar.gz という名前で入手できます. 以下のカードのドライバが存在します: EuroISDN (DSS1)および1TR6プロトコル用には, 現在すべての(passive) Teles カードおよびそのクローンがサポートされています. Dr. Nauhaus - Niccy 1016 bisdn には, いくつかの制限があります. 特に ISDN に関連する機能のうち, 以下の機能はサポートされません. PPP はサポートされません. raw hdlc のみです. すなわち, Cisco 製 など, ほとんどのスタンドアロンーンルータ等とは接続できません. ブリッジングコントロールプロトコルはサポートされません. 複数のカードは同時に使用できません. 動的なバンド幅の変更はできません. チャンネルのバンドリングはできません. majordomoによるメーリングリストが利用できます. 参加するには, 通常の majordomo リクエストを以下のメールアドレスまで送ってください. . ISDN ターミナルアダプタ

ターミナルアダプタ (TA) はISDN に対して, 通常の電話線に対するモデ ムに相当するものです.

ほとんどの TA は, 標準のヘイズ AT コマンドセットを使用しているので, 単にモデムと置き換えて使うことができます. TA は, 基本的にはモデムと同じように動作しますが, 接続方法は異なり, 通 信速度も古いモデムよりはるかに速くなります. の設定を, モデムの場合と同じように行ってください. とくにシリアル速度を 使用できる最高速度に設定するのを忘れないでください. プロバイダへの接続に TA を使用する最大のメリットは, 動的 PPP を行える ことです. 最近 IP アドレスが不足してきているため, ほとんどのプロバイダ は, 専用の IP アドレスを割り当てないようになっています. ほとんどのスタ ンドアローンルータは, 動的 IP アドレスに対応していません. 訳注: 最近の ISDN ルータでは, IP アドレスの動的割り当てに対応している ものも多いようです. ただし制限がある場合もありますので, 詳しくはメーカ に問い合わせてください. TA を使用した場合の機能や接続の安定性は, 使用している PPP デーモンに完 全に依存します. そのため, FreeBSD で PPP の設定が完了していれば, 使用 している既存のモデムを ISDN の TA に簡単にアップグレードすることができ ます. ただし, それまでの PPP のプログラムに問題があった場合, その問題 は TA に置き換えてもそのまま残ります. 最高の安定性を求めるのであれば, ユーザープロセス ではなく, カーネルを使用してく ださい.

以下の TA は, FreeBSD で動作確認ずみです. Motorola BitSurfer および Bitsurfer Pro Adtran 他の TA もほとんどの場合うまく動作するでしょう. TA のメーカーでは, TA がほとんどの標準モデム AT コマンドセットを受け付けるようにするよう, 努 力しているようです. 外部 TA を使う際の最大の問題点は, モデムの場合と同じく良いシリアルカー ドが必要であるということです. シリアルデバイスの詳細, そして非同期シリアルポートと同期シリアルポート の差については, ハンドブックの の 節を参照してください. 標準の PC シリアルポート(非同期)に接続された TA は, 128Kbs の接続を行っ ていても, 最大通信速度が 115.2Kbs に制限されてしまいます. 128Kbs の ISDN の性能を最大限に生かすためには, TA を同期シリアルカードに接続しな ければなりません. 内蔵 TA を購入して, 同期／非同期問題を片付けてしまおうとは思わないでく ださい. 内蔵 TA には, 単に標準 PC シリアルポートのチップが内蔵されてい るだけです. 内蔵 TA の利点といえば, シリアルケーブルを買わなくていいと いうことと, 電源コンセントが一つ少なくて済むということくらいでしょう. 同期カードと TA の組合せは 386 の FreeBSD マシンの場合でも, スタンドア ローンのルータと同程度の速度は確保できます. またこの組合せでは, ルータ より柔軟な設定が可能です. 同期カード/TA を選ぶか, スタンドアローンルータを選ぶかは, 多分に宗教的 な問題です. メーリングリストでもいくつか議論がありました. 議論の内容に ついては, を参照してください. スタンドアローン 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 などすべての プロトコルのパケットを中継することが可能です.

diff --git a/ja/handbook/kerberos.sgml b/ja/handbook/kerberos.sgml index be8f94d7ec..c8979f6f4d 100644 --- a/ja/handbook/kerberos.sgml +++ b/ja/handbook/kerberos.sgml @@ -1,492 +1,492 @@ - + Kerberos

原作: &a.markm; (&a.md; からの寄稿に基づいています). 訳: &a.arimura;. Kerberosは, サーバのサービスによってユーザが安全に認証を受けられる ようにするための, ネットワークの付加システム及びプロトコルです. リモートログイン, リモートコピー, システム間での安全なファイルのコピ ーやその他のリスクの高い仕事がかなり安全に, そしてこれまでより制御 できるようになります. 以下の文章は, FreeBSD用として配布されているKerberosをセットアップ する際のガイドとして読むことができます. しかし, 完全な説明が必要な場合には, マニュアルページを読んだ方がよい でしょう. FreeBSDのKerberosは, オリジナルの4.4BSD-Liteの配布に含まれている ものではなく, FreeBSD 1.1.5.1のときに移植されたeBonesです. これはアメリカ/カナダの外で作成されており, これら以外の国の人々にも 手に入れられるものです. このソフトウェアを合法的な配布物として得るために, アメリカも しくはカナダのサイトから持ってこないでください. でないと, そのサイトが大変な問題に巻き込まれます. 合法的な配布は, 南アフリカのskeleton.mikom.csir.co.zaから 入手することができます. 初期データベースの作成

この作業はKerberosサーバだけでおこないます. まず, 古いKerberosの データベースが存在しないことを確認してください. ディレクトリ/etc/kerberosIVに移って, 次のファイルだけが 存在することをチェックします: grunt# cd /etc/kerberosIV grunt# ls README krb.conf krb.realms

もし他のファイル (principal.*やmaster_key) が 存在する場合には, kdb_destroyというコマンドで古い Kerberosデータベースを消してください. Kerberosが走っていなければ, 単にrmで余計なファイルを消せ ばよいです. まず, krb.confとkrb.realmsを編集してKerberosの 管理領域 (realm) を定義してください. ここでは管理領域がGRONDAR.ZA で, サーバ名がgrunt.grondar.zaであるとします. krb.confというファイルを次のように編集してください: grunt# 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は次のようになります: grunt# 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コ マンドを次のように実行してください: grunt# 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コマンドを使用します. grunt# 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といったコマンドを実行したりできるよ うになります. それでは実際にこれらのエントリを追加しましょう: grunt# 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 , 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 , 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の運用において重要なも のです. grunt# ext_srvtab grunt Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Generating 'grunt-new-srvtab'....

このコマンドは一時的なファイルを作成するだけです. ファイル名をすべ てのサーバが読めるようなsrvtabという名前に変更しな ければなりません. mvコマンドを用いてシステムの場所に移動 してください. grunt# mv grunt-new-srvtab srvtab

そのファイルがクライアントに配るためのもので, ネットワークが安全で はないと思われる場合には, <client>-new-srvtabを移動 可能なメディアにコピーして物理的に安全な方法で運んでください. クラ イアントの/etc/kerberosIVディレクトリで, 名前を srvtabに変更し, modeを600にするのを忘れないでください: grumble# mv grumble-new-srvtab srvtab grumble# chmod 600 srvtab データベースへのユーザの追加

ここで, ユーザのエントリをデータベースに追加する必要があります. 始めに, ユーザjaneのエントリを作成してみましょう. kdb_editを用いて次のように作成してください: grunt# 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: , 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/sysconfigファイルを正しく編集してあれば, マシンを再 起動することでに自動的にデーモンが起動します. これはKerberosサー バでのみ必要です. Kerberosクライアントは/etc/kerberosIVか ら必要なものを自動的に入手します. grunt# kerberos & grunt# 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 grunt# kadmind -n & grunt# 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コマンドで得ることができます: grunt$ kinit jane MIT Project Athena (grunt.grondar.za) Kerberos Initialization for "jane" Password:

klistコマンドを用いてトークンを見て, きちんとチケットを持って いるかどうか確認してください: grunt$ 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データベースに対して認証されるかどうかチェックして ください: grunt$ passwd realm GRONDAR.ZA Old password for jane: New Password for jane: Verifying password New Password for jane: Password changed. su特権の追加

root権限が必要なユーザは誰でも, suコマンドのパス ワードをユーザ毎に別のものとして持つことができます. rootにsuできる権利を与えられたidを追加します. これは, principalに付いているrootというインスタンスに よって制御されています. kdb_editを用いて jane.rootというエントリをKerberosデータベースに作成します: grunt# 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 , 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: <---- 何も入力しないと終了します

実際にトークンをもらって, ちゃんと働いているかどうか確認しましょう: grunt# kinit jane.root MIT Project Athena (grunt.grondar.za) Kerberos Initialization for "jane.root" Password:

ここでrootユーザの.kloginファイルにユーザを追加する必要が あります. grunt# cat /root/.klogin jane.root@GRONDAR.ZA

suしてみましょう: [jane@grunt 10407] su Password: grunt# どのトークンを持っているか見てみましょう: grunt# 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することができま す. grunt# cat /root/.klogin jane.root@GRONDAR.ZA

同様に, ユーザのホームディレクトリの.kloginファイルに次の ような行がある場合には: [jane@grunt 10543] cat ~/.klogin jane@GRONDAR.ZA jack@GRONDAR.ZA

janeまたはjackという名前で (前述のkinit によって) 認証されているGRONDAR.ZAという管理領域のユーザ なら誰でもrloginやrsh, rcp等によってこ のシステム (grunt) のjaneのアカウントまたはファ イルにアクセスできます. 例えば, Janeが他のシステムにKerberosを用いてloginします: [jane@grumble 573] kinit MIT Project Athena (grunt.grondar.za) Password: [jane@grumble 574] 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 [jane@grunt 10567]

次の例では, Jackが同じマシンのJaneのアカウントにloginします. Janeは .kloginファイルを前述のように設定しており, Kerberosではjackというprincipalをインスタンスなしで設定してあ ります. [jack@grumble 573] kinit [jack@grumble 574] 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 [jane@grunt 10578] diff --git a/ja/handbook/kernelconfig.sgml b/ja/handbook/kernelconfig.sgml index 8aacdcc0c9..a2ef298e8e 100644 --- a/ja/handbook/kernelconfig.sgml +++ b/ja/handbook/kernelconfig.sgml @@ -1,1249 +1,1249 @@ - + FreeBSDカーネルのコンフィグレーション

原作: &a.jehamby;. 6 October 1995.

訳: &a.tomo;, &a.yoshiaki;. 2 November 1996. この章はシステムに合わせたカーネルの再構築の基礎について 述べたものです. この章は, システム管理の初心者から Unixシステム管理に十分な経験を積んだ人までを対象としています. なぜカスタムカーネルを作るか?

システムに合わせたカーネルはすべての Unixシステム管理者が 避けて通ることのできない最も重要な通過儀礼の1つです. この作業は, 多くの時間を必要としますが, あなたの FreeBSD システムに多くの利益をもたらします. GENERICカーネルは, めったに使われることのないハードウェアをサポートするとともに, 考えられるすべての SCSIカードやネットワークカードをサポート しなければなりませんが, システムに合わせたカーネルは あなたの PC のハードウェアのみをサポートします. これは, 次にあげるような利益をもたらします. あなたが持っていないハードウェアについては検出をおこなわな いので, ブートにかかる時間が短くなります. システムに合わせたカーネルは多くの場合メモリ使用量が 減ります. カーネルはいつもメモリ上に存在するので, 不必要なコードがあると本来プログラムが利用できるはずの RAM (実メモリ) を占めてしまいますのでこれは重要なことだ といえます. したがって, メモリが少ないシステムでは, カーネルの再構築は大変重要です. 必要に応じていくつかのカーネルオプションは調整すること ができ, またサウンドカードのような GENERICカーネルには ないデバイスドライバをカーネルに含めることが できます.

カスタムカーネルの構築とインストール

まず, カーネル再構築に必要なディレクトリをざっと見てみましょう. ここではディレクトリはすべて /usr/src/sys以下の相対位 置で示します. また, /sysからもアクセス可能です. ここには, カーネルの各部分を構成するサブディレクトリが いくつもあります. しかし, 私たちの目的では 最も重要なのは i386/confです. ここで, あなたの システムに合わせてカーネル コンフィグレーションを編集します. それから compileディレクトリ, ここはカーネルが作られる 場所です. サポートされているデバイスやファイルシステムのディレ クトリツリーがオプション毎にサブディレクトリに分かれている論理 的構成に注意してください. また, i386のディレクトリは PCのハードウェアのみを扱い, i386以外のディレクトリは FreeBSDが他のプラットフォームに移植される際には共有されるコー ドです. /usr/src/sys 以下のディレクトリがなければ, カーネルのソースが インストールされていません. パッケージのインストール手順にしたがっ て, システムにインストールしてください. つぎに, i386/confに移動して, GENERIC コンフィグレーションファイルをカーネルに与えたい名前に コピーしてください. たとえば： # cd /usr/src/sys/i386/conf # cp GENERIC MYKERNEL 慣習として, この名前はすべて大文字でつづられます. もし, いくつかの異なるハードウェアの FreeBSDマシンを扱うなら, この名前にホスト名を含めるとよいでしょう. ここでは, 例として MYKERNEL と呼ぶことにします. では, MYKERNELをあなたの好きなエディタで編集してください. もし, システムをインストールしたばかりならば, 利用できる エディタは viだけかもしれません. ここでは使い方 の説明はしませんが, にあるような多くの本で詳しく説明 されていますので, そちらを参照してください. まずファイルの最初の方のコメント行を編集し, あなたのコンフィグ レーションに合せて変更した点などを記述して GENERICと区別がつく ようにしておきましょう. もし SunOSや他の BSDオペレーティングシステムでカーネルの 再構築をしたことがあれば, このファイルはとても親しみ やすいでしょう. しかし, DOSのようなその他の オペレーティングシステムしか知らない人から見れば, GENERICコンフィグレーションファイルはとても なじみにくいものかもしれません. そのような場合は, の節をゆっくりと注意深く読んでください. config(8)を取ってくる必要があるかもしれません. これは /usr/src/usr. sbinにあります. したがってこれらのソースをダ ウンロードする必要があります. 次のコマンドを実行する前に (configを)作りインストールをしておいてください. 編集し終ったら, 次のコマンドによってコンパイル, インストール を行ってください. # /usr/sbin/config MYKERNEL # cd ../../compile/MYKERNEL # make depend # make # make install 新しいカーネルはルートディレクトリに /kernelという 名前でコピーされ, 今までのカーネルは /kernel.old という名前へ変更されます. では, システムをシャットダウン, リブー トして新しいカーネルを使ってください. うまく行かない場合は, この章の終りの を参照してください. この章の新しい 場合のリカバリの方法を注意深く読んでおいてください. /devディレクトリで デバイスノードを追加しなければならないかもしれません. 詳しくは, を読んでください. コンフィグレーション ファイル

コンフィグレーション ファイルの一般的なフォーマット はとてもシンプルです. 各行は1つのキーワードと1つ以上の 引数を含んでいます. 見やすくするために, ほとんどのキーワードは 引数を1つしか書いてありません. #に続くものはすべてコメントとして扱われ, 無視されます. ここでは, それぞれのキーワードについて だいたい GENERICに出てくる順番で説明します. しかし, お互いに関係のあるキーワードは, 実際には GENERICファイル上に バラバラに現れていても, (ネットワーキングのように)1つにまとめ てあります.

カーネルは現在, オプションを扱う方法をよりよい機構に移行しよ うとしています. 従来は, 各々のオプションは単純にカーネルの Makefile中の CFLAGS行の -Dスイッチに変換されて いました. 自然とオプションは際限なく増えて行きます. だれも実際に はどのオプションがどのファイルで参照されているかは知りません.

新しい方法では、すべてのオプション依存の #ifdefは当該オプショ ンを opt_foo.h (これらのファイルはconfigによって compileディレ クトリに作られます) から読み込むように変わりました. config の有効なオプションのリストは2つのファイルにお かれます. アーキテクチャに依存しないオプションは /sys/conf/optionsに置かれ, アーキテクチャ依存のオプショ ンは/sys/arch/conf/optionsに置かれま す. archの部分は例えば i386となります. 必須キーワード

ここにあるキーワードはカーネルの構築に必要不可欠です. machine ``i386''

最初のキーワードは machineです. FreeBSDは Intelの 386とその互換チップ上でしか 動かないので, i386を指定します. 注: 数字を含むキーワードはすべて クォーテーションマークで囲む必要があります. そうしないと, configは混乱し, 386を実際の数値として扱ってしまいます. cpu ``cpu_type''

次のキーワードは cpuです. FreeBSDでサポートしている CPUの中から記述します. cpu_typeとして指定可能な値は 次の通りです. I386_CPU I486_CPU I586_CPU I686_CPU GENERICカーネルのように cpuの行の cpu_typeが異なった値を持つものが 複数あってもかまいません. カスタムカーネルでは, あなたが持っている cpuを1つだけ指定するのが 一番です. 例えば, もし Intelの Pentiumを持っていれば, cpu_typeには, I586_CPU を使ってください. ident machine_name

次は, カーネルの識別名となるidentです. GENERICからあなたがカーネルに与えたい名前に 変えてください. ここでは, MYKERNELとします. identに与えた名前はカーネルの ブート時に表示されるので, 普段のカーネルとは別に カーネルに違う名前を与えたいとき(例えば, 実験用のカーネルを作りたい時など), 便利でしょう. 数字を含む名前にしたい場合は machineや cpuの時と同じようにクォーテーションマークで 囲む必要があります. Cコンパイラに -Dスイッチで渡されるので, DEBUGのような名前にしたり, vax といった他のCPUの名前など紛らわしい名前にしないで ください. maxusers number

これは, 重要なシステムテーブルのサイズを決めます. ここ で与えられる数字はマシンに同時にログインすると考えられ るおよそのユーザ数です. しかし, 通常の使用環境であれば, 特に X Window System を立ち上げたり, ソフトウェアを コンパイルするような使用であれば maxusersには少 なくとも4以上を指定したほうがいいでしょう. その理由は, maxusersで決るテーブルで最も重要なものはプロセス の最大数であるからです. プロセス最大数は 20 + 16 * maxusersで与えられ, maxusersを1 にすると36プロセスしか同時には持てません. この中にはブー ト時にシステムによって起動する18個ぐらいのプロセス, Xを 起動する時の15程度のプロセスも含みます. manページを読むという1つのタスクでさえ, フィ ルタやファイル伸長や表示のために9つのプロセスを起動し ます. maxusersを4にすれば, 同時に84個のプロセ スを持つことができるのでどんな人でも十分な数だといえる でしょう. それでも他のプログラムを起動した場合に, あるいは, (Walnut Creek CDROMのFTPサイトのように) 同時に多くの ユーザを抱えるサーバを走らせた場合に ``proc table full''というおぞましいエラーが起きる場合はこの値を増や し, カーネルを再構築してください. maxuserはあなたのマシン にログインできるユーザの数を制限するものでは ありません. 単に, あなたのシステムに ログインするユーザ数の最大値と各々のユーザが いくつのプロセスを走らせるかを考慮することに よってさまざまなテーブルの値を適切な値に設定 するだけです. これに対し, の remote loginsというキーワードは 同時にリモートログインできるユーザ数を制限 します. config kernel_name root on root_device

これはカーネルの位置と名前を特定します. 伝統的にカーネルは vmunixと呼ばれますが, FreeBSDでは kernelとふさわしい名前になりました. kernel_nameにはいつも kernelを 使ってください. 名前を変えると多くのシステム ユーティリティが使えなくなります. 2番目の部分は ルートファイルシステムとカーネルのあるディスクと パーティションを指定してください. SCSIドライブでなければ, wd0を, SCSIドライブならば sd0です. 一般的なオプション

以下はカーネルのサポートするさまざまなファイルシステムおよ びその他のオプションです.

これは, 数値演算コプロセッサがない コンピュータ (386や486SX) で数値演算コプロセッサ のエミュレーションを可能にします. もし, Pentiumや 486DX, あるいは387や487があれば, コメントアウト できます. 注: FreeBSD付属の数値演算 コプロセッサエミュレータはあまり正確では ありません. 非常に正確な計算をおこないたい ならば, より優れた GNUのエミュレータである GPL_MATH_EMULATEに変えることを おすすめします. これはライセンスの関係でデフォルトでは 含まれていません. options ``COMPAT_43''

4.3BSDとの互換性のためのオプションです. そのままにしておいてください. コメントアウトすると, いくつかのプログラムで動作がおかしくなります. options BOUNCE_BUFFERS

ISAデバイスやISA互換モードで動作する EISAデバイス では DMA (Direct Memory Access) は16MB以下のメモリに対し てのみ動作します. このオプションによりメモリが16MB以上 のシステムでDMAを使うデバイスを動作させることができます. options UCONSOLE

ユーザがコンソールを横取り (grab) できるようにします. これは X Window System 上で便利です. 例えば, コ ンソール xtermを xterm -Cとタイプして作ると, そこに `write', `talk'などのメッセージがカーネルからコ ンソールへ送られるメッセージと同じように表示されます. options SYSVSHM

このオプションは System V の共有メモリを提供します. 最もよく利用されるのは X Window System の XSHM拡張 です. これは多くのグラフィックを多用したプログラム (movie player の Xanimや Linux DOOMなど) では自動的に高速 になるという利点があります. X Window System を利用するのであればこれは間違いな く含めたくなるでしょう. options SYSVSEM

System V のセマフォをサポートします. 一般的に利用される ことは少ないですがカーネルサイズの増加は数百バイトだ けです. options SYSVMSG

System V のメッセージをサポートします. これを指定した場 合もカーネルサイズの増加は数百バイトだけです. ipcs(1) コマンドは これらの System V の機構を利用しているプロセスを表示し ます. 訳注: 共有メモリ, セマフォ, メッセージ(メッ セージキュー) は System V系 で一般的なプロセス間通信の機 構です. くわしくは System Vのプロセス間通信に関する文 献, 「詳解 UNIXプログラミング」 (ソフトバンク) , 「UNIXネッ トワークプログラミング」 (トッパン) などを参照してくださ い. ファイルシステムオプション

これらのオプションはさまざまなファイルシステムへのサポート を追加します. 少なくともブートするためのデバイスのサポートを含 める必要があります. 標準的にはハードディスクからブートするので あれば FFS , ディスクレスワークステーションとしてイー サネットからブートするのであれば NFSです. 一般的に利用される他のファイルシステムをカーネルに含め, あまり 利用しないファイルシステム (多分 MS-DOSファイルシステム?) のサポー トをコメントアウトすることができます. これは Loadable Kernel Module ディレクトリ /lkm から, 最初にそのタイプのファイ ルシステムがマウントされる時に動的にドライバがロードされるからです. options FFS

基本的なハードドライブ ファイルシステムです. ハードディ スクからブートする場合は残しておいてください. options NFS

ネットワーク ファイルシステムです. Ethernet経由で Unixファ イルサーバからパーティションをマウントする予定がない場 合はコメントアウトすることができます. options MSDOSFS

MS-DOS ファイルシステムです. ブート時に DOSフォーマット のハード ドライブをマウントする予定のない場合はコメン トアウトしても安全です. 先に示したように, DOSパーティ ションをマウントする時に自動的にロードされます. また (ports コレクションにある) mtools という素晴 らしいソフトウェアにより mount , unmountなしで DOSフロッ ピーにアクセスすることができます (これは MSDOSFSも必要 ありません). options ``CD9660''

CD-ROMのための ISO 9660 ファイルシステムです. CD-ROMを 持っていないか, 時々 データ CDをマウントするだけならコ メントアウトしましょう (データ CDを最初にマウントする 時に動的にロードされます). オーディオ CDはこのファイル システムは必要ありません. options PROCFS

プロセス ファイルシステムです. これは疑似的なファイルシ ステムで /procにマウントされ, ps(1)などのプロ グラムがプロセスに関してより詳しい情報を与えてくれるよ うになります. options MFS

メモリマップド ファイルシステムです. これは基本的に一時 ファイルを記憶するための高速な RAMディスクで, 大きな swap領域がある場合に有効です. MFSパーティションをマウ ントするに適した場所は多くのプログラムが一時ファイルを 置く /tmpです. MFS RAMディスクを /tmp にマウントするには以下の内容を /etc/fstabに追 加してリブートするか mount /tmpとタイプします. /dev/wd1s2b /tmp mfs rw 0 0 /dev/wd1s2bをあなたが使用して いるswap パーティションに置き換えてください. これは以 下のように /etc/fstabに書かれているでしょう. /dev/wd1s2b none swap sw 0 0 /tmpデ バイスにアクセスすることはできません). そのためいまの ところは使わない方が無難です. --> また, MFSファ イルシステムは動的にロードすることはできません . したがって使いたい場合はコンパイル時に カーネルに含める必要があります. options QUOTA

ディスククォータを有効にします. アクセスが公開されてい るシステムで (一人のユーザが) /homeパーティショ ン (全体) をあふれさせることができないようにそれぞれのユーザ にディスククォータを発行することができます. このコードはいくらかバグがありますので必要のない場合は 使わないでください. ディスククォータについての詳しい内 容はマニュアルページの quota(1)を見てください. 基本的なコントローラとデバイス

この節では FreeBSDでサポートされているディスク, テー プ, CD-ROMコントローラについて示します. コントローラと カードについ ては別の節になっています. controller isa0

FreeBSDのサポートするすべての PCで必要です. IBM PS/2 (マイ クロチャネルアーキテクチャ) では現時点では FreeBSDは動 きません. controller pci0

PCIバスを持つマザーボードの場合は含めます. これにより PCIカードの自動認識と PCIから ISAバスへのゲートウェイが 可能になります. controller fdc0

フロッピードライブコントローラです. fd0 は ``A:'' ドライブで fd1 は ``B:'' ドライブです. ft0 は フロッピーコントローラに接続する QIC-80 テープドライブで す. 対応するデバイスがない場合はそれぞれの行をコメント アウトしてください. ft(8)というフィルタプログラムが必要です. 詳し くはマニュアルページを見てください. controller wdc0

プライマリIDEコントローラです. wd0 と wd1はそれぞれマスタ, スレーブドライブで す. wdc1 は セカンダリの IDEコントローラで3台 目, 4台目のハードディスクまたは IDE CD-ROMのある場合に 使います. 利用しない行はコメントアウトしてください (例え ば, SCSIハードディスクのみを使う場合は6行全部をコメント アウトしてもよいかもしれません). device wcd0

このデバイスは IDE CD-ROMのサポートをします. wdc0を有効にしておく必要があり, もし 2つ以上の IDE コントローラがあり, そのうちの 2つ目のカードに CD-ROMを接 続する場合 options ATAPIを書いておく必要もあります. device npx0 at isa? port ``IO_NPX'' irq 13 vector npxintr

npx0はFreeBSDハードウェアコプロセッサとソフト ウェアエミュレータ両方の浮動小数点演算ユニットへのインタ フェースです. これは device wt0 at isa? port 0x300 bio irq 5 drq 1 vector wtintr

Wangtek と Archive の QIC-02/QIC-36 テープドライブのサポートです. Proprietary CD-ROM support

以下のようなドライブを proprietary(独自の) CD-ROMドライブと呼ぶことにします. これらのドライブは専 用のコントローラを持つか, サウンドブラスタ16などのサウ ンドカードに接続します. これらは IDEでも SCSIでもあ りません. 多くの標準速や2倍速の古い CD-ROMはこれら のインタフェースを持っていますが, より新しい四倍速の ものは か でしょう. device mcd0 at isa? port 0x300 bio irq 10 vector mcdintr

ミツミ製 CD-ROM (LU002, LU005, FX001D)です. device scd0 at isa? port 0x230 bio

ソニー製 CD-ROM (CDU31,CDU33A)です. controller matcd0 at isa? port ? bio

松下/パナソニック製 CD-ROM (サウンドブラスタ用 クリエィティブ ラボ製として販売されていました) です. SCSI デバイスのサポート

この節では FreeBSDのサポートするいろいろな SCSIコント ローラとデバイスのサポートについて書きます. SCSI コントローラ

以下の十数行は異る種類の SCSIコントローラのサポートです. 使用しているもの以外の部分はコメントアウトしてください. controller bt0 at isa? port ``IO_BT0'' bio irq ? vector btintr

ほとんどの Buslogic社のコントローラです. controller uha0 at isa? port ``IO_UHA0'' bio irq ? drq 5 vector uhaintr

UltraStor 14F と 34F です. controller ahc0

Adaptec 274x/284x/294x です. controller ahb0 at isa? bio irq ? vector ahbintr

Adaptec 174x です. controller aha0 at isa? port ``IO_AHA0'' bio irq ? drq 5 vector ahaintr

Adaptec 154x です. controller aic0 at isa? port 0x340 bio irq 11 vector aicintr

Adaptec 152x や サウンドカードなどに使われている Adaptec AIC-6360 チップです. (slow!) controller nca0 at isa? port 0x1f88 bio irq 10 vector ncaintr

NCR 5380を使っている ProAudioSpectrum や Trantor T130 で す. controller sea0 at isa? bio irq 5 iomem 0xc8000 iosiz 0x2000 vector seaintr

Seagate ST01/02 8 ビットコントローラです. (slow!) controller wds0 at isa? port 0x350 bio irq 15 drq 6 vector wdsintr

Western Digital WD7000コントローラです. controller ncr0

NCR 53C810, 53C815, 53C825, 53C860, 53C875 チップを使った PCI SCSI コントローラです. options ``SCSI_DELAY=15''

このオプションによりカーネルはそれぞれの SCSIデバイスを プローブする前に 15秒間待ちます. IDEドライブのみを使用 している場合は無視して構いません. ブートを速くするため にこの数値を 5秒ぐらいまで小さくしたいでしょう. そうし た場合, FreeBSDが SCSIデバイスを認識しにくくなるかもし れません. その時は、もちろんこのオプションの値は元に戻 さないといけません. controller scbus0

SCSIコントローラがある場合, この行で SCSI全般のサポー トを与えます. SCSIのない場合, この行と以下の3つの行をコメ ントにすることができます. device sd0

SCSIハードディスクのサポートです. device st0

SCSIテープドライブのサポートです. device cd0

SCSI CD-ROM のサポートです.

上のエントリについている 0はいくらか誤解を招き やすいかもしれません. これらのデバイスはすべてカーネルが 見つけた時に割り当てがおこなわれ, SCSIバスに何台つながってい るか, ターゲット IDが何番であるかはここの記述とは関係あ りません. 明示的に「固定的な」ターゲット IDの特定のデバイスへの 割り当てをおこないたい場合は LINT カーネルコンフィグレーションファイルの 該当する部分の説明を参照してください. コンソール, バスマウス, Xサーバのサポート

2つのタイプのコンソールからどちらか1つを選ぶ必要があります. また X Window System を利用する場合, XSERVERオプションを有効に します. またバスマウスとPS/2マウスのオプションもあります. device sc0 at isa? port ``IO_KBD' tty irq 1 vector scintr

sc0 はデフォルトのコンソールドライバで SCOコン ソールに似ています. このデバイス, あるいは VT220コンパ チブルドライバの vt0いずれを使う場合もほとんど のフルスクリーンプログラムは termcapなどのターミ ナルデータベースライブラリを通してアクセスしますので, あまり違いはないでしょう. このコンソールを使う場合でフルスクリーンプログラムでト ラブルが起きる場合にはログインした時に TERM変数の値を ``scoansi''にしてください. device vt0 at isa? port ``IO_KBD'' tty irq 1 vector pcrint

これはVT-220コンパチブルコンソールドライバで VT100/102の 上位互換です. これは sc0の使えない種類のラッ プトップ機でもうまく動きます. ログイン時に TERM変数の値 を``vt100'' か ``vt220''にしてください. また, このドラ イバはネットワークを介して多くの異るマシンから接続する 場合も便利です. sc0デバイスのための termcapや terminfoエントリは必ずしも 利用できるわけではありませんが -- ``vt100''はいずれの プラットフォームでも利用可能でしょう. options ``PCVT_FREEBSD=210''

vt0 コンソールドライバを使う場合に必要で す. options XSERVER

これは XFree86 X サーバを動かすのに必要な コードを含めます. device mse0 at isa? port 0x23c tty irq 5 vector ms

Logitech や ATIのバスマウス入力カードを利用する場合のデ バイスです. ポート(おそらくはCOM1)を有効にしてくだ さい. device psm0 at isa? port ``IO_KBD'' conflicts tty irq 12 vector psmintr

このデバイスは PS/2マウスポートにマウスを接続する場合に 使います. シリアル, パラレルポート

ほとんどすべてのシステムにこれらはあります. プリンタを接続す る場合は の章が非常 に役に立つでしょう. モデムを使う場合は に非常に詳しいシリアルポートの設定とデ バイスの使い方があります. device sio0 at isa? port ``IO_COM1'' tty irq 4 vector siointr

sio0からsio3は MS-DOSにおける COM1から COM4に相当する4本のシリアルポートです. COM4に内蔵モデムがあり COM2を使う場合, FreeBSDからアク セスするためにはモデムのIRQを2へ変更する必要があるとい うことを注意しておきます (技術的な理由より IRQ 2 = IRQ 9となります). マルチポートシリアルカードを使う場合にマニュアルページ のsio(4)にはこのオプションで使う値などのよ り多くの情報があります. ビデオカードの中には (特に S3 チップベースのものには) IOアドレスの 0x*2e8から を利用するものがあり, また多くの安価なシリアルカードは IOアドレス空間を16-bitフルデコードしていませんので, こ れらのカードは衝突します. この場合 COM4ポートは実質上 利用できません. それぞれのシリアルポートは (割込みの共有をサポートした マルチポートカードを利用していないのであれば) 別々の IRQ を割り当てる必要がありますので COM3と COM4のデフォルトの IRQは利用できません. device lpt0 at isa? port? tty irq 7 vector lptintr

lpt0 から lpt2は利用可能な3本のプリン タポートです. 多くの場合は1本のみですので他の2本はない のであればコメントアウトして構いません. ネットワーク

FreeBSDでは他の一般的な Unixと同様にネットワークが 非常に 重視されています. イーサネットカードが なくても必須のオプションとダイヤルアップ ネットワークのサポー トに注意してください. options INET ネットワーキングのサポートです. ネットワークに接続する予定がな くても残しておいてください. 多くのプログラムは少なくともループ バックネットワーキングが必要です(つまり, PCの中でネットワーク コネクションをおこないます). したがってこのオプションは本質的 に不可欠です. Ethernet cards

以下にさまざまなイーサネットカードを有効にするオプショ ンを示します. ネットワークカードがなければこれらすべてを コメントアウトすることができます. そうでなければ利用す る特定のイーサネットカードをサポートするオプションを残 しておきます. device de0

DECの DC21040, DC21041, DC21140チップを使った PCIイー サネットアダプタです. device fxp0

Intel EtherExpress Pro/100B 高速イーサネットカード です. device vx0

3Com の 3C590, 3C595です (いくらか bugがあります). device cx0 at isa? port 0x240 net irq 15 drq 7 vector cxintr

Cronyx/Sigma の マルチポート同期/非同期カードです. (with Cisco or PPP framing) device ed0 at isa? port 0x280 net irq 5 iomem 0xd8000 vector edintr

Western Digital と SMC の 80xx, 8216 Elite Ultra ; ノベル NE1000, NE2000; 3Com の 3C503; HPの PC Lan Plus (HP27247B とHP27252A) です. device el0 at isa? port 0x300 net irq 9 vector elintr

3Com の 3C501 です. (slow!) device eg0 at isa? port 0x310 net irq 5 vector egintr

3Com の 3C505です. device ep0 at isa? port 0x300 net irq 10 vector epintr

3Com の 3C509 です(バグがあります). device fe0 at isa? port 0x240 net irq ? vector feintr

富士通 MB86960A/MB86965A ベースのイーサネットカード です. device fea0 at isa? net irq ? vector feaintr

DEC DEFEA EISA FDDI アダプタです. device ie0 at isa? port 0x360 net irq 7 iomem 0xd0000 vector ieintr

AT&T StarLAN 10 と EN100; 3Com の 3C507; NI5210 です. device ix0 at isa? port 0x300 net irq 10 iomem 0xd0000 iosiz 32768 vector ixintr

Intel の EtherExpress 16です. device le0 at isa? port 0x300 net irq 5 iomem 0xd0000 vector le_intr

DEC の EtherWorks 2 and EtherWorks 3 (DEPCA, DE100, DE101, DE200, DE201, DE202, DE203, DE204, DE205, DE422)です. device lnc0 at isa? port 0x300 net irq 10 drq 0 vector lncintr

Lance/PCnet カード (Isolan, Novell NE2100, NE32-VL)です. device ze0 at isa? port 0x300 net irq 5 iomem 0xd8000 vector zeintr

IBM/ナショナルセミコンダクタの PCMCIA イーサネット コントローラです. device zp0 at isa? port 0x300 net irq 10 iomem 0xd8000 vector zpintr

3Com の PCMCIA Etherlink III です. pseudo-device loop

loop は TCP/IPの一般的なループバックデバイスで す. telnet や FTPを localhost (127.0.0.1) に対してかけるとこの疑似デバイスを通して帰ってきます. 不可欠です. pseudo-device ether

etherはイーサネットカードがある場合のみ必要で 一般的なイーサネットプロトコルを含めます. pseudo-device sl number

sl は SLIP (Serial Line Internet Protocol) をサポー トします. これはほとんど完全に, より簡単に設定ができ, モ デム to モデム接続に適した, よりパワフルな PPPに取って代 わられています. slの後の number は同 時にいくつの SLIPセッションをサポートするかを示します. SLIPの設定のより詳しい情報はこのハンドブックの 「PPPとSLIP」の章の と について書かれた節にあります。 pseudo-device ppp number

pppはダイヤルアップ インターネット接続のための カーネルモード PPP (Point-to-Point Protocol) をサポート します. ユーザアプリケーションとして tun を 利用する PPPの実装もあり, こちらはより柔軟性がありデマ ンドダイアリング(プログラムが接続要求を出した時に自動 的にダイヤルをおこなう)などの機能もあります. それでもこ の PPPドライバを利用したい場合は の節を読んでください. slデバイスと同じように numberは同時 に PPP接続できる数を示します. pseudo-device tun number

tun はユーザモード PPPソフトウェアが利用しま す. このプログラムは設定が簡単で非常に高速です. また自動ダイヤル オン デマンドなどの機能を持ちます. tunの後のnumber は同時におこなうことのできる PPPセッションの数を示します. の節により多くの情報があ ります. pseudo-device bpfilter number

バークレイ パケットフィルタです. この疑似デバイスはネッ トワークインタフェースを無差別 (promiscuous) モードにし てネットワーク (例えば単一のイーサネット) にブロードキャス トされるすべてのパケットを取り入れることを可能にします. こ れらのパケットはディスクに取り入れられたり tcpdump(1) によって検査されます. この機能の実現 はネットワーク全体のセキュリティとの微妙な妥協点であるこ とに注意してください. bpffilter の後の numberは同時に検査することの できるインタフェースの数を示します. 危険の可能性について十分解っている場合を除いてこのオプ ションは奨めません. すべてのネットワークカードでこの機能 をサポートをしてはいません. サウンドカード

ここは GENERICカーネルに含まれていない最初のセクションです. サウンドカードのサポートをするためには LINTコンフィグレーショ ンファイル(これにはすべてのデバイスが含まれています)か ら以下のような適切な行をコピーする必要があります. controller snd0

サウンドドライバ一般のコードです. pcaを除く以下のすべてのサウンドカードで必要で す. device pas0 at isa? port 0x388 irq 10 drq 6 vector pasintr

ProAudioSpectrum のオーディオ と MIDI です. device sb0 at isa? port 0x220 irq 7 conflicts drq 1 vector sbintr

SoundBlaster です. irq 7をirq 5に書き換え, キーワード conflictsを削除し てください. さらに options ``SBC_IRQ=5''の行を 加える必要があります. device sbxvi0 at isa? drq 5

SoundBlaster 16 の 16-bit オーディオです. drq 5を適切な値に書き直 して, (DMA 6の場合) options "SB16_DMA=6"を付け 加えてください. device sbmidi0 at isa? port 0x330

SoundBlaster 16 の MIDI インタフェースです. SoundBlaster 16を使う場合必ずこの行を含めてコンパイル してください. device gus0 at isa? port 0x220 irq 10 drq 1 vector gusintr

Gravis Ultrasound です. device mss0 at isa? port 0x530 irq 10 drq 1 vector adintr

Microsoft Sound System です. device opl0 at isa? port 0x388 conflicts

AdLib FMシンセサイザオーディオです. AdLib, SoundBlaster, ProAudioSpectrum を使い playmidi (ports にあります) などのプログラムで MIDIの演奏をしたい場合にこの行を含めます. device mpu0 at isa? port 0x330 irq 6 drq 0

Roland MPU-401 カードです. device uart0 at isa? port 0x330 irq 5 vector ``m6850intr''

MIDIインタフェースの 6850 UART です. device pca0 at isa? port ``IO_TIMER1'' tty

PC のスピーカーを使ったオーディオです. これは非常に品質 が悪く, CPUの性能, 負荷に強く依存します, と言っておき ます (サウンドカードは必要ありませんが). /usr/src/sys/i386/isa/sound/sound.docにあります. また, これらのデバイスを追加する場合は, サウンドを作る必要があり ます. 疑似デバイス

疑似デバイスドライバはデバイスドライバと同様に働きますがマ シン上に対応する実際のハードウェアがないカーネルの部分です. 関連の 疑似デバイスはそちらのセクションに示しました. ここでは残りにつ いて示します. pseudo-device gzip

gzipは gzipによって圧縮された FreeBSDの プログラムを実行できるようにします. /standにあるプログ ラムは圧縮されているのでカーネルにこのオプションをつけ ておくのはいい考えでしょう. pseudo-device log

log はカーネルエラーのログを取るのに使います. 不可欠です. pseudo-device pty number

pty は「仮想ターミナル」や仮想ログインポート です. 外部からの telnetや rloginセッ ション, xterm, emacsなどのアプリケーションが使います. numberは作ることのできる ptyの数を示 します. GENERICのデフォルトは16で, 同時の xtermウィンドウやリモー トログインのために増やす場合は最大で 64までです. pseudo-device snp number

スヌープデバイスです. この疑似デバイスはあるターミナル セッションが watch(8) commandによって他のター ミナルを監視することを可能にします. この機能の実現はセ キュリティとプライバシに対して極めて微妙な関係があり ます. snpの後の numberは同時におこなうことのでき るスヌープセッションの総数です. 選択可能です. pseudo-device vn

Vノードドライバです. ファイルを vnconfig(8)コマ ンドによってデバイスとして取り扱うことを可能にします. このドライバによりフロッピーディスクイメージを操作したりファ イルをスワップデバイスとして (MS Windowsのスワッ プファイルなどを)用いることができます. 選択可能です. pseudo-device ccd number

ccd (concatenated disk)デバイスはいくつかのディスクパーティ ションを融合して大きなディスクのように見せることができます. ccdの後の numberは同時に作ることのできる疑似ディスクの数です. (詳しいことは ccd(4)と ccdconfig(8)のマニュ アルを参照してください.) 選択可能です. ジョイスティック, スピーカー, その他

この節は FreeBSDのここまでに示した以外のハードウェア デバイスへのサポートについて示します. これらは GENERICカーネル には含まれませんのでこのハンドブックや LINT (このファイルには すべてのデバイスのサポートが含まれます) からコピーする必 要があります. device joy0 at isa? port ``IO_GAME''

PC のジョイスティックです. pseudo-device speaker

IBM BASIC スタイルの PC内蔵スピーカーのサポートです. シェルスクリプトで簡単な演奏をする /usr/sbin/spkrtest やキーボードを使って単純なピ アノのように演奏することができる /usr/games/piano (gamesパッケージをイ ンストールした場合にはあります) のようないくつかのプロ グラムで使われます. また素晴らしいテキストロールプレイ ングゲームである NetHack (ports コレクションにあります) はゲーム中の楽器の演奏でこのデバイスを使うように設定を することができます (訳注:日本語化されたJNetHackもportsに あります).

デバイスの 項も参照してください. デバイスノードを作る

カーネル内のほとんどすべてのデバイスは対応する ``node'' エント リが /dev ディレクトリにあります. これらのノードは普 通のファイルのように見えますが, 実際にはプログラムがデバイスに アクセスするのに用いるカーネル内への特別なエントリです. シェルスクリプトである /dev/MAKEDEVはオペレーティング システムを最初にインストールする時に実行され, サポートされてい る大部分のデバイスのノードを作ります. しかし, すべてのノードが作られるわけではありませんので 新しいデバイスのサポートを加える時は対応するエントリがこのディ レクトリにあるかどうか確認してもしなければ, 作ってください. 以下に例を示します. IDE CD-ROMのサポートをカーネルに加えるとします. 次の行 を加えます. controller wcd0 これにしたがって, /devディレクトリに wcd0で始ま るエントリを捜してください. 1文字が後ろにつくかもしれません. 後 ろについた文字が `c'であるか先に `r'のつくエントリは `raw'デバ イスを示します. それらのファイルがないことが明らかになったとします. そこで /dev ディレクトリに移動して次のようにタイプします. # sh MAKEDEV wcd0 スクリプトの実行が終ったら /devに wcd0c と rwcd0c エントリがあることを確認してください. これによ り正しく実行されたことがわかります. サウンドカードの場合のコマンドは次の通りです. # sh MAKEDEV snd0 これにより対応するエントリが作られます. 注: サウンドカードのようなデバイスのノードを作る場合で, もし他 の人がマシンにアクセスするようであれば, そのデバイスを /etc/fbtabファイルに追加して外部からのアクセスから 保護するのが望ましいでしょう. このファイルの詳細については man fbtab を参照してください. GENERICに含まれていないデバイスはエントリがありませんから,以上 の簡単な手順をおこなうことになります. /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 ファイルにはすべての成功した ブートのカーネルのメッセージやその他の記録があり, これ は助けになる情報の一つでしょう. また, dmesg(8)コマンドは現在のブート時のカーネルメッ セージを出力します. kernel. oldは新しいカーネルをインストールする 時に, その一つ前にインストールしたうまく動かないかもしれ ないカーネルで上書きされてしまいますので当てにできませ ん. またできる限り早く動作しているカーネルを本来の ``kernel''の位置に移動させてください. そうしないと ps(1)のようなコマンドが正しく動きません. make でインストールされたカーネルのファイルを (別のカーネルに戻すために) 「アンロック」するための特別 のコマンドは # chflags noschg /kernel です. また, 新しい置き換えたカーネルあるいは重要ファイ ルを動かしたり変更されないように「ロック」するには 次のようにします. # chflags schg /kernel カーネルは動くが ps は動かない!

システムユーティリティと異るバージョンのカーネルをインス トールした場合, 例えば 実験的に ``2.2.0''のカーネルを 2.1.0-RELEASEシステム上にインストールするような場合, ps(1)や vmstat(8)のような多くのシ ステムステータスコマンドは動かなくなります. libkvm を 再コンパイルしてこれらのユーティリティを作りなおす必要がありま す. これは, オペレーティングシステムのそれ以外の部分と異るバージョ ンのカーネルを使うことが普通はあまりよくない理由の一つです. diff --git a/ja/handbook/kerneldebug.sgml b/ja/handbook/kerneldebug.sgml index dae6ca61fc..8a905141d8 100644 --- a/ja/handbook/kerneldebug.sgml +++ b/ja/handbook/kerneldebug.sgml @@ -1,419 +1,419 @@ - + カーネルデバッグ

原作 &a.paul; and &a.joerg;

訳: &a.yoshiaki;. 2 November 1996. kgdbによるカーネルのクラッシュダンプのデバッグ

ここではクラッシュダンプ (crash dump : 訳注 この文脈では kernel 自身 の異常によって停止した場合に出力されるイメージを指します) によるカー ネルデバッグの方法を示します. ここではダンプするための十分なスワップ (swap) の容量があるものとし ます. もし複数のスワップパーティションを持ち, 最初のパーティションがダンプ を保持するのに十分な大きさを持たない場合は別のダンプデバイスを使うよ うに (config kernel 行で) カーネルのコンフィグをおこなうか, dumpon(8)コマンドを使って別のデバイスを示すことができます. スワップ をおこなわないデバイスへのダンプ, 例えばテープへのダンプは現在サポートさ れていません. カーネルのコンフィグは config -g によって行っ てください. には FreeBSDのカーネルの設定の詳細がありますので参照してください. dumpon(8)コマンドを使ってどこへダンプするかカーネルに伝えて ください(swapon(8)によってそのパーティションがスワップとして設定された 後でなければならないことに注意してください). これは普通は /etc/sysconfig や /etc/rcで設定されます. あるいは 別の方法としてカーネルコンフィグレーションファイルの `config'行の `dump'節 で ダンプデバイスをハードコードすることができます. この方法はあまりよくは ありません. カーネルがブート時に crash する場合のクラッシュダンプを取り たい時だけ使うべきです. Note: 以下では `kgdb'という用語は gdbを カーネルデバッグモードで動かしていることを意味します. gdbを -kオプションをつけて起動するか kgdbという名前でリン クして起動することでこのモードになります. デフォルトでは このリンク は作られていません. カーネルを作った時にそのコピーを kernel.debugという名前で作 りましょう. また, オリジナルに対して strip -dを実行します. オリジナルを普通にインストールします. また strip していないカーネル も同様にインストールすることができますが, シンボルテーブルの参照時間 がいくつかのプログラムでは劇的に増加するでしょう. また, カーネル全体 はブート時に読み込まれスワップアウトされないため数メガバイトの物理メ モリが無駄になります. 例えばブートプロンプトで新しいカーネルの名前をタイプすることによって, 新しいカーネルをテストした場合で, 再びシステムを動かすのに別のカーネ ルで立ち上げることが必要な場合はブートプロンプトで -sフラグ を使いシングルユーザの状態にしてください. そして以下のような操作をおこな います. fsck -p mount -a -t ufs # /var/crash 用のファイルシステムを書き込み可能にする savecore -N /kernel.panicked /var/crash exit # ...マルチユーザモードへ移行 ここに示した savecore(8)は (現在動いているものとは別の) カー ネルのシンボル名の抽出をおこなうために使っています. 抽出はデフォルトで は現在動いているカーネルに対しておこなわれ, クラッシュダンプとカーネルシンボ ルのくい違いのためにまったく何もしません (訳注:そのためにオプション で実際にダンプをおこしたカーネルを指定します). クラッシュダンプの起きた後に /sys/compile/WHATEVERへ行き kgdbを動かします. kgdb より次のようにします. symbol-file kernel.debug exec-file /var/crash/kernel.0 core-file /var/crash/vmcore.0 こうすると, クラッシュダンプを使ってカーネルソースを他のプログラムと同様に デバッグすることができます. 次に kgdb での手順のセッションのログを示します. 長い行は読 みやすくするために改行しました. また, 参照のために行番号を入れてあり ます. ただし, これは実際の pcvtコンソールドライバの開発中の実際のエ ラーのトレースです. 1:Script started on Fri Dec 30 23:15:22 1994 2:uriah # cd /sys/compile/URIAH 3:uriah # kgdb 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:uriah # exit 78:exit 79: 80:Script done on Fri Dec 30 23:18:04 1994 上の出力についてのコメントをします. trap()関数の位置で す. tp->t_lineはコンソールデバイスの規定 する行を参照しているので, もっと小さな整数でなければなりませ ん. ) 突然ダンプした場合の解析

カーネルが予想もしない時にコアダンプして config -g を行ってコンパイルされていなかった場合にはどうしたらよいでしょう. すべてが失われるわけではありません. パニックを起こさないでください. もちろん, クラッシュダンプを使えるようにする必要があります. 使い方は前述の部分を見てください. カーネルのコンパイルディレクトリで, (Makefileの) COPTFLAGS?=-Oとある行を編集します. -gオプショ ンをここに加えます(オプティマイズオプションのレベルは 変更しな いでください ). もし大まかにコードのどこで問題が起きているか (例 えば, 上の例では pcvtドライバ) わかっているのでしたら, その部 分のコードについてのすべてのオブジェクトファイルを消してください. カーネ ルを再構築しましょう. Makefileのタイムスタンプの変更により, 例えば trap.o などのいくつかの他のオブジェクトファイルも作り直さ れます. 少しの幸運があれば, -gオプションが追加されても作ら れるコードは変更されず, いくらかのデバッグシンボル以外には問題を 起こしたコードとそっくりな新しいカーネルを手に入れることができます. 少なくとも sizeコマンドで古い方と新しい方のサイズを比較すべ きです. これが食い違っていれば, 多分あきらめなければならないでしょう. ダンプを使って前述のように動かして調べます. デバッグシンボルは 必ずしも十分ではありません. 上の例ではスタックトレースでいくつかの関 数の行番号や引数リストが表示されないかもしれません. もしより多くのデ バッグシンボルが必要であれば,十分になるまで適切なオブジェクトファイ ルを消して (makeして) kgdbセッションを繰り返してください. これは必ずしもうまく動くと保証はできません. しかしほとんどの場合でう まくいくでしょう. DDBを使ったオンラインカーネルデバッグ

kgdb は非常に高レベルのユーザインタフェースを提 供するオフラインデバッガですが, いくつかのことはできません. (できないことの中で)極めて重要なことはカーネルコードへのブレークポイ ントの設定とシングルステップ実行です. カーネルの低レベルデバッグが必要であれば, DDBと呼ばれる on-lineデバッ ガが使えます. ブレークポイントの設定, シングルステップのカーネルの実 行, 変数の検査と変更などができます. ただし,これはカーネルのソースファ イルにアクセスすることはできません. kgdbのようにすべてのデ バッグ情報にはアクセスできず, globalと staticのシンボルにアクセス することができるだけです. カーネルに DDBを含めるためにはコンフィグファイルに次のようなオプショ ンを加えて, options DDB 再構築をおこないます. ( FreeBSDのカーネルの設定の詳細についてはを参照してくださ い. もしブートブロックが古いバージョンですと, デバッガのシンボルが完 全にはロードされないかもしれませんので注意してください. DDBシンボル がロードされるようにブートブロックを最新の物にアップデートしてくださ い) DDB カーネルの実行において, DDBに入るいくつかの方法があります. 最初 の, 最も早い方法はブートプロンプトが出ている時に-dのブート フラグをタイプすることです. カーネルはデバッグモードで起動し, デバ イスのプローブ以前に 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 によっておこなうことができます. Note: これは 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 値が出力されます. 動いているプロセスの ps(1)スタイルの概要は ps です. カーネルの失敗の原因の調査が終わったらリブートすべきです. それまでの 不具合によりカーネルのすべての部分が期待するような動作をしているわけ ではないということを忘れないでください. 以下のうちいずれかの方法でシ ステムのシャットダウンおよびリブートを行ってください. call diediedie() カーネルをコアダンプしてリブートしますので, 後で kgdbによってコアの高 レベル解析をすることができます. このコマンドは通常 `continue'命令にエイリアスされています. `panic'にエイリアスされている call boot(0) は動いているシステムを `clean' に shut downするよい方法です. すべて のディスクを sync()して最後にリブートします. ディスクとカー ネルのファイルシステムインタフェースが破損していない限り, ほぼ完全 に `clean'にシャットダウンするよい方法でしょう. call cpu_reset() は大惨事を防ぐための最後の手段で「赤い大きなボタン」を押すのとほとんど 同じです.(訳注: リセットボタンを押すのとほぼ同じであるという意味です) 短いコマンドの要約は help をタイプします. ただし, デバッグセッションのために ddb(4) の マニュアルページのプリントアウトを用意しておくことを強くお奨めします. カーネルのシングルステップ中にオンラインマニュアルを読むことは難しい ということを覚えておいてください. コンソールドライバのデバッグ

DDBを動かすためにはコンソールドライバが必要ですから, コンソールドラ イバ自身に不具合のある場合は複雑になります. シリアルコンソールを利 用する方法 (ブートブロックを変更するか Boot:プロンプトで -hと入力する) を思い出してください. そして標準ター ミナルを最初のシリアルポートに設定します. DDBは, もちろんシリアルコ ンソールを含むいずれのコンソールドライバの設定でも動作します. diff --git a/ja/handbook/kernelopts.sgml b/ja/handbook/kernelopts.sgml index 945d510e22..eb8a3a74b9 100644 --- a/ja/handbook/kernelopts.sgml +++ b/ja/handbook/kernelopts.sgml @@ -1,153 +1,153 @@ - + カーネルコンフィグレーションの新しいオプションを追加する

原作: &a.joerg;

訳: &a.yoshiaki; . 29 December 1996. の章の内容を 理解しておいてください. そもそもカーネル オプションって何?

カーネルオプションの使い方は基本的には の章に書いてあります. そこには「伝統的な形式」と「新しい形式」のオプションの説明があります. すべてのカーネルのオプションを新しい形式のものに置き換え, コンフィグファイル を修正して 基本的に, カーネルオプションはカーネルのコンパイルプロセスの C プリプロセッサのマクロの定義にすぎません. 実際に選択的に make できる ようにするためには, 対応する部分のカーネルソース (またはカーネルの #ifndef THIS_OPTION #define THIS_OPTION (some_default_value) #endif /* THIS_OPTION */

この場合, 管理者がコンフィグファイルのオプションに別の値を記述すれば, デフォルトの設定を打ち消して新しい値に置き換えられます. 当然, 新しい値はプリプロセッサによってソースコード中で置き換えられるため, デフォルトの値が使われていた場所において C の式として有効な値でなければ なりません.

また, 単に特定のコードを有効にするか無効にするかを設定するための 値を持たないオプションも作ることができます. #ifdef THAT_OPTION [あなたのコードが入ります] #endif

コンフィグファイルに C 言語にくわしい人であれば「コンフィグオプション」とされているもの は少なくとも一つの options notyet,notdef

このようにコンフィグファイルをしておくと, カーネルのコンパイルは うまく行きません. :-)

(訳注: たとえば MATH_EMULATE のように 有効/無効のためのパラメタを 持たないオプションの場合, 無効とするためのパラメタをつけて, オプション で「無効とする」と明示することはできないという意味です)

明らかに, 任意のオプション名がカーネルソースツリー全体でどのように 使われているかを追いかけることは非常に難しいことです. このことが opt_foo.h という名前に されます. この方法では, 通常の Makefile の依存関係が適用され, 古い形式のオプションの機構は, 局部的なオプションや実験的なオプション のような一時的に利用されると考えられるオプションにおいては有効です. つまり ではどのようにして追加するのでしょう?

最初に sys/conf/options (または sys/i386/conf/options.<arch>, たとえば sys/i386/conf/options.i386) を編集し, 新しいオプション を含めるのに最適な opt_foo.h ファイルを選びます.

新しいオプションの必要がなくなったとしたら, これを取り除きます. たとえば, SCSI サブシステムに関するすべてのふるまいについてのオプション の変更は 新しいオプションを加えるのに使えそうな opt_foo.h がない場合は新しい名前を作ってください. 意味のある名前を作り options[.<arch>] ファイル に新しいセクションのコメントをつけてください. 大量のオプションを一つの opt_foo.h にまとめると コンフィグファイルの一つのオプションを変更したときに多くのファイルが 再コンパイルされる原因になります.

新しいオプションに依存するカーネルファイルは最終的には見つけ出 されます. ただし, オプションを作っただけで対応するソースがどこにも ない場合は別です. find /usr/src/sys -name type f | xargs fgrep NEW_OPTION

オプションに対応するソースを見つけるのに上記のコマンドは便利です. 見つけたすべてのファイルで編集, 追加をおこないます. #include "opt_foo.h"

ファイルの先頭の, すべての #ifndef NEW_OPTION #define NEW_OPTION (something) #endif

システムヘッダファイル (たとえば /usr/include/sys/ にある ファイル) をオプションで置き換えることは, ほとんどの場合で失敗します. そうすると, ヘッダファイルを深刻な状態に破壊してしまうので, include しないとオプションの値によって不整合が起きてしまう場合を除き, それらの ファイルに opt_foo.h を include しないでください. そう, 現在このような例がいくつか存在していますが, 必ずしも正しい方法 ではありません. diff --git a/ja/handbook/linuxemu.sgml b/ja/handbook/linuxemu.sgml index 81b094c5f5..6014a2cae7 100644 --- a/ja/handbook/linuxemu.sgml +++ b/ja/handbook/linuxemu.sgml @@ -1,714 +1,714 @@ - + Linux エミュレーション

原作: &a.brian and &a.rich;

訳: &a.kiroh;.24 September 1996. Linux エミュレータのインストール

FreeBSD での Linux エミュレーションは, 大部分の Linux バイナリ(a.out および ELF フォーマット)を実行できる状態になっています. -STABLE ブラン チでのエミュレーションでは, Linux DOOM や Mathematica が実行できます. FreeBSD-current でのエミュレーションは, さらに強化されており, Linux 用 の Quake, Abuse, IDL, netrek など, 多数のソフトウェアが実行できます. Linux オペレーティングシステムには、特有の機能がいくつかあり, FreeBSD でサポートされていないものもあります. Linux の /proc ファイルシステム を使ったバイナリは, FreeBSD では実行できません (FreeBSD で使用可能な /proc ファイルシステムとは仕様が異なっているためです). また仮想8086モー ドを有効にするなど, i386 に特有なシステムコールを使っている場合も実行 できません.

カーネルが Linux エミュレーションを使用するように構築されているかを調 べるには, Linux のバイナリを実行してみるのが簡単です. linux-executable: Exec format error. Wrong Architecture. このようなエラーメッセージが表示されるようであれば, Linux との互換性は サポートされていません. カーネルを再構築してインストールする必要があり ます. Linux エミュレーションの設定方法は, 使用している FreeBSD のバージョン によって多少異なっています. 2.1-STABLE への Linux エミュレーションのインストール

2.1-STABLE の GENERIC カーネルは, Linux との互換性を保つように構築 されていません. カーネルの再構築が必要です. 再構築をおこなうには, 2つの方 法があります. 1つは, エミュレータをカーネル自体にスタティックリンクす る方法. もう1つは, 動的に Linux ローダブルカーネルモジュール(LKM)をロー ドするようにする方法です.

エミュレータを有効にするには, 以下をコンフィグレーションファイル (/sys/i386/conf/LINT など) に追加します. options COMPAT_LINUX Linux DOOM などのアプリケーションを実行したい場合は, 共有メモリも有効 にしておかなければなりません. 以下を追加します. options SYSVSHM Linux のシステムコールを使用するには, 4.3BSD のシステムコールとの互換 性が保たれていることが必要です. 以下の行が含まれていることを確認してく ださい. options "COMPAT_43" LKM を使用せずエミュレータをカーネルにスタティックにリンクしたい場合は, 以下の行を追加します. options LINUX の節の記述に したがって config と, 新しいカーネルのインストールをおこなってください. LKM を使用する場合は, ローダブルモジュールをインストールしなければなり ません. カーネルとローダブルモジュールのバージョンが異なると, カーネル がクラッシュする場合がありますので, 安全を期すためには, カーネルをイン ストールするごとに, LKM も再インストールしてください. % cd /usr/src/lkm/linux % make all install カーネルと LKM のインストールが終了したら, root で `linux' コマンドを 実行することで LKM をロードできます. % linux Linux emulator installed Module loaded as ID 0 % LKM がロードされたかどうかを確認するには, `modstat' を実行します. % modstat Type Id Off Loadaddr Size Info Rev Module Name EXEC 0 3 f0baf000 0018 f0bb4000 1 linux_emulator % システムブート時に, LKM をロードするようにするには, 2つの方法がありま す. FreeBSD-current または FreeBSD-STABLE では, /etc/sysconfig を, linux=YES のように, NO を YES に変更してください. FreeBSD 2.1 RELEASE およびそれ以 前のバージョンでは, そのような行はありませんので, /etc/rc.local に以下 の行を追加する必要があります. linux 2.2-current への Linux エミュレーションのインストール

-current では, ``options LINUX'' や ``options COMPAT_LINUX'' を指定する必要 はなくなりました. Linux エミュレーションは LKM(「ローダブルカーネルモジュール」) を使用して, リブートせず簡単にインストールできます. スタートアッ プファイルで以下のように指定します. /etc/sysconfig に以下の行が必要です. linux=YES これは結果的に, /etc/rc.i386 の以下の指定を有効にします. # Start the Linux binary emulation if requested. if [ "X${linux}" = X"YES" ]; then echo -n ' '; linux # XXX BOGUS - Linux script shouldn't make any output on success fi

実行されたかどうかを確認するには, modstat を使用します. % modstat Type Id Off Loadaddr Size Info Rev Module Name EXEC 0 4 f09e6000 001c f09ec010 1 linux_mod % FreeBSD-current システムの中には, modstat の実行がうまくいかないものがあ るという報告もあります. 何らかの理由で, Linux LKM がロードできな い場合は, options LINUX をカーネルの設定ファイルに指定して, エミュレータをスタティックにリンク してください. の節の記述にしたがって config と, 新しいカーネルのインストールをおこ なってください. Linux ランタイムライブラリのインストール linux_lib port を使用してのインストール

多くの Linux アプリケーションはシェアードライブラリを使用しますので, シェアードライブラリのインストールが終了しなければ, エミュレータのイン ストールは終わったことになりません. 手動でもインストールできますが, linux_lib port を使用するのが簡単です. % cd /usr/ports-current/emulators/linux_lib % make all install これで, Linux エミュレータが動作するようになったはずです. 伝説(とメー ルのアーカイブ :-) によれば, Linux エミュレーションは, ZMAGIC ライブラ リとリンクされている Linux バイナリに対して, 最もうまく動作するようで す. Slackware V2.0 などに使われている QMAGIC ライブラリだと, エミュレー タが胸やけするかもしれません. これを書いている時点(1996年5月)で, ELF エミュレーションは依然実験段階ですが, かなりうまく動作しているようです. マイナーバージョンの不一致などを報告するプログラムもありますが, 普通は 問題にならないようです. 手動でのライブラリのインストール

``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 以下にインストールする 必要があります. FreeBSD-current では, /compat/linux にかかわる動作が多少異なりま す. -current では, ライブラリだけでなくすべてのファイルが, ``shadow root'' /compat/linux から検索されます. Linux のプログラムが必要とするシェアードライブラリを探す必要があるのは, FreeBSD のシステムに Linux のプログラムをインストールする最初の数回だ けでしょう. それが過ぎれば, 十分な Linux のシェアードライブラリがシス テムにインストールされ, 新しくインストールした Linux のバイナリも, 余 計な作業をせずに動作させることができるようになります. シェアードライブラリの追加

linux_port をインストールした後に, アプリケーションが必要なライブラリ が存在しないというエラーを出したらどうしたらよいでしょうか? Linux のバ イナリがどのシェアードライブラリを必要とし, そしてどこで入手できるか, どのように探したらよいでしょうか? 基本的には, 以下の2種類の方法があり ます(以下の手順にしたがう場合には, 必要なインストール作業をおこなう FreeBSD シ ステム上で root として作業をおこなう必要があります).

Linux システムを使用でき, 必要なシェアードライブラリが調べられる場 合には, 単に FreeBSD のシステムにそのライブラリをコピーするだけで す. 例えば, DOOM の Linux バイナリを ftp で持ってきたとします. 使用で きる Linux システムの上に転送して, `ldd linuxxdoom' とやれば, 必要とす るシェアードライブラリがチェックできます. % 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 のランタイムリンカは, メジャーリビジョ ン番号の一致したライブラリを検索しますから, ユーザが気にする必要はあり ません. ld.so の設定 -- FreeBSD-current のみ

このセクションは, FreeBSD-current にのみ当てはまります. FreeBSD-STABLE を使用している方は, 飛ばしてください.

最後に, FreeBSD-current を使われている場合は, Linux のランタイムリンカと その設定ファイルがシステムに導入されていることを確認してください. これらのファイルは, FreeBSD システムの適切な位置(/compat/linux ツリー以 下)にコピーされている必要があります. /compat/linux/lib/ld.so /compat/linux/etc/ld.so.config

使用できる Linux システムがない場合は, 必要なファイルは近くの FTP サイ トから入手してください. 各種ファイルの入手先についての情報を, 後に付 けておきます. ここでは, 必要なファイルの入手先がわかっているものとしま す.

以下のファイルを取得します(バージョンの不一致を避けるために, すべて同一 の FTP サイトから入手してください). 取得したファイルを /compat/linux 以下にインストールしてください(例えば, /foo/bar は, /compat/linux/foo/bar にインストールされます). /sbin/ldconfig /usr/bin/ldd /lib/libc.so.x.y.z /lib/ld.so

ldconfig と ldd は, /compat/linux の下にある必要はありません. システム のどこにあっても構いません. ただ, FreeBSD の同名のコマンドと間違えないように 注意してください. /usr/local/bin の中に, ldconfig-linux, ldd-linux とし てインストールするのもよいアイディアでしょう.

/compat/linux/etc/ld.so.conf ファイルを作成し, Linux ラインタイムリンカ がシェアードライブラリを検索するディレクトリを記述してください. このファ イルはプレインテキストファイルで, それぞれの行にディレクトリ名を含みま す. /lib と /usr/lib は標準ですから, 以下のようなディレクトリが追加できま す. /usr/X11/lib /usr/local/lib

Linux バイナリが, /lib/libc.so というライブラリを開いた場合, エミュレー タは内部で, ファイル名を /compat/linux/lib/libc.so にマップします. エ ミュレータがライブラリを検索するために, すべての Linux のライブラリ (/compat/linux/lib/libc.so, /compat/linux/usr/X11/lib/libX11.so など) は, /compat/linux 以下にインストールされていなければなりません.

FreeBSD-current を使用している場合は, Linux の ldconfig プログラム を実行する必要があります. % cd /compat/linux/lib % /compat/linux/sbin/ldconfig

ldconfig はスタティックリンクされていますから, 実行するのにシェアードラ イブラリを必要としません. ldconfig は, /compat/linux/etc/ld.so.cache ファイルを作成し, すべてのシェアードライブラリの名前を格納します. ライ ブラリの追加をおこなった場合には, ldconfig を再実行して, このファイルを作り 直さなければなりません. FreeBSD-STABLE では, /compat/linux/etc/ld.so.cache をインストールしたり, ldconfig を実行したりしないでください. FreeBSD-stable では, システムコー ルの実装方法が異なるため, ldconfig は使用されません.

これで, libc シェアードライブラリを必要とする Linux バイナリを実行する設 定が終了しました. ldd を ldd 自身に実行してテストしてください. ldd-linux としてインストールしている場合は, 以下のような結果になるはず です. % ldd-linux `which ldd-linux` libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29

ここまで終了すれば, 新しい Linux のバイナリをインストールできます. 新しい Linux バイナリをインストールするときは, それがシェアードライブ ラリを必要とするかどうか確認してください. 必要とする場合は, /compat/linux 以下にインストールされているかどうか確認してください. こ れは, Linux の ldd を新しいプログラムに対して実行し, 出力を確認するこ とによりおこなえます. ldd(ldd(1)マニュアルページも参照してください)は, プ ログラムが必要とするシェアードライブラリのリストを, majorname (jumpversion) => fullname という形式で出力します.

fullname のかわりに ``not found'' と出力される場合は, ライブラリの追加をす る必要があります. 必要なライブラリの名前は, majorname に libXXXX.so.N.mm という形式で示されています. Linux の FTP サイトで libXXXX.so.N.mm を探し, インストールしてください. XXXX(名前)とN(メジャー リビジョン番号)は一致している必要があります. マイナー番号 mm は, それほ ど重要ではありませんが, なるべく最新のものをインストールするようにして ください. ホストネームリゾルバの設定

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' を削除してください.

最後になりますが, FreeBSD-STABLE を使用している場合は, RESOLV_HOST_CONF 環境変数を指定して, アプリケーションにホストテーブル の検索方法を指定する必要があります. FreeBSD-current を使用している場合 は, スキップしてください. /bin/csh を使っている場合は, 以下のようにし ます. setenv RESOLV_HOST_CONF /compat/linux/etc/host.conf /bin/shの場合は, 以下のようにします. RESOLV_HOST_CONF=/compat/linux/etc/host.conf; export RESOLV_HOST_CONF 必要なファイルを探すには

注意: 以下の情報は, この文書が書かれた時点では有効ですが, FTP サイトの 名前, ディレクトリ, 配布ファイル名などは, 変更されている可能性がありま す.

訳注: ここに取り上げられている FTP サイトは, 日本国内にもミラーサイト が多数存在します。なるべく近くの FTP サイトからファイルを入手してくだ さい.

Linux は, いくつかのグループが, それぞれ独自のバイナリ配布セットを作成 して配布しています. 配布セットは, ``Slackware'' や ``Yggdrasil'' など の名前がつけられています. これらの配布セットは, 多くの FTP サイトから 入手できます. ファイルが展開されており, 必要なファイルのみを取得できる 場合もありますが, 通常は圧縮された配布セットの形で入手できます. 配布 セットは, いくつかのサブディレクトリに, gzip で圧縮された tar ファイル として格納されています. それぞれの配布セットの一次配布先は, 以下の通り です. sunsite.unc.edu:/pub/Linux/distributions tsx-11.mit.edu:/pub/linux/distributions

ヨーロッパのミラーサイトの例: ftp.luth.se:/pub/linux/distributions ftp.demon.co.uk:/pub/linux/distributions src.doc.ic.ac.uk:/packages/linux/distributions

混乱を避けるために, ここでは Slackware だけを取り上げます. この配布セッ トは, 多くのサブディレクトリ内にある別々のパッケージから構成されていま す. 通常, パッケージはインストールプログラムにより自動的に制御されま すが, ``手動で''おこなうことも可能です. まず配布セットの中の, ``contents'' サブディレクトリの内容を書くにしてください. ここには多く の小さなテキストファイルが含まれおり, それぞれのパッケージの内容が記述 されています. 必要なファイルを探している場合は, まず contents 内のテキ ストファイルを取得し, そのファイルの中から grep を使用して検索するのが, 最も速い方法でしょう. 以下に必要となるであろうファイルを, grep を使用 して検索した例を示します. Library Package ld.so ldso ldconfig ldso ldd ldso libc.so.4 shlibs libX11.so.6.0 xf_lib libXt.so.6.0 xf_lib libX11.so.3 oldlibs libXt.so.3 oldlibs

この場合は, ldso, shlibs, xf_lib, oldlibs というパッケージが必要なこと がわかります. それぞれのcontentsファイルの中で, ``PACKAGE LOCATION'' と書いてある行を探してください. その行に, パッケージが含まれているディ スク, 今回の場合はサブディレクトリ名が書かれています. たとえば, 以下の ようになります. Package Location ldso diska2 shlibs diska2 oldlibs diskx6 xf_lib diskx9

``diskXX'' というのは, 配布セットの ``slackware/XX'' サブディレクトリ を示します. それ以外の場合は, ``contrib'' サブディレクトリに格納されて います. 今回の場合は, 以下のファイルを取得すればいいことがわかります (ファイル名は, 配布セットのルートディレクトリからの相対パスで示してあ ります). slakware/a2/ldso.tgz slakware/a2/shlibs.tgz slakware/x6/oldlibs/tgz slakware/x9/xf_lib.tgz

gzip で圧縮された tar ファイルから必要なファイルを /compat/linux ディ レクトリに格納してください(必要なファイルのみを展開するか, あるいは必 要でないファイルを後で削除してください). これで作業は終了です.

参照: ftp.freebsd.org:pub/FreeBSD/2.0.5-RELEASE/xperimnt/linux-emu/README /usr/src/sys/i386/ibcs2/README.iBCS2 FreeBSD への Mathematica のインストール

原作: &a.rich and &a.chuck

訳: &a.kiroh;. この文書は, Mathematica 2.2 の Linux バイナリディストリビューションを, FreeBSD 2.1 にインストールする方法について説明します.

Mathematica は, そのままでは FreeBSD をサポートしていませんが, Linux は サポートしています. ですから, Linux エミュレータの設定が終わってしまえ ば, Mathematica を動作させる環境はほとんど整ったことになります.

DOS 用のスチューデント版 Mathematica から Linux バージョンへのアップグレー ド価格は, 執筆時点 (1996年5月) では, $45.00 です. 直接 Wolfram(電話番号(217) 398-6500)に注文して, 支払いはクレジットカー ドでおこなえます。 Mathematica ディストリビューションの展開

バイナリは, Wolfram から CDROM で配布されています. CDROM には, 1ダー スほどの tar ファイルが含まれており, それぞれサポートされているアーキテ クチャに対応しています. Linux 用のファイルは, LINUX.TAR です. 例えば /usr/local/Mathematica 以下にインストールする場合は, 以下のようにしま す. % cd /usr/local % mkdir Mathematica % cd Mathematica % tar -xvf /cdrom/LINUX.TAR Mathematica パスワードの取得

Mathematica を実行する前に, 使用するマシンに対応した `machine ID' を Wolfram から取得する必要があります.

Linux 互換ランタイムライブラリがインストールされており, mathematica の展 開が終了したら, Install ディレクトリで `mathinfo' プログラムを使用す ることで `machine ID' を得ることができます. % cd /usr/local/Mathematica/Install % mathinfo LINUX: 'ioctl' fd=5, typ=0x89(), num=0x27 not implemented richc.isdn.bcm.tmc.edu 9845-03452-90255 % ここで, `richc' の `machine ID' は, `9845-03452-90255' となります. ioctl のメッセージは無視してください. まだ FreeBSD では実装されていません. Mathematica を実行するたびに同様のメッセージが表示されますが, 実際の使 用に問題はありませんので, 無視してかまいません.

電子メールや電話, ファックスなどで Wolfram に `machine ID' を知らせ て登録すると, いくつかの番号のグループからなるパスワードが送り返されて きます. パスワードを, マシン名, ライセンス番号とともに, mathpass ファ イルに追加します. 追加は, 以下のようにおこないます. % cd /usr/local/Mathematica/Install % math.install ライセンス番号と, Wolfram から送られてきたパスワードを入力を求めます. 入力を間違えたりして, math.install の実行が失敗しても大丈夫です. `mathpass' ファイルを手動で編集して, 情報を訂正してください.

パスワードの入力後, math.install では, インストール方法を, デフォルト 設定でのインストールか、自分で方法を指定するインストールから選ぶことが できます. 筆者のようにインストールプログラムを信用していない場合は, 自 分でディレクトリを指定する方を選択するでしょう. 自分で指定するインストー ルを選んだ場合, math.install 自身ではディレクトリの作成はおこないません. 注意してください. 別のウィンドウでシェルを開いて, 指定するディレクトリ を作成してください. 存在しないディレクトリを指定して, math.install が インストールに失敗した場合には, ディレクトリを作成し, math.install を 再び実行してください. 筆者らがインストール先に選んだディレクトリは, 以 下の通りです. くれぐれもあらかじめ作成してから, math.install で指定す るようにしてください. /usr/local/Mathematica/bin バイナリファイル /usr/local/Mathematica/man/man1 マニュアルページ /usr/local/Mathematica/lib/X11 XKeysymbファイル また, システムレコードファイルとして, /tmp/math.record を使用するように 設定することもできます. このファイルには, セッションのログが記録されま す. この設定が終了すると, math.install は残りのファイルを展開して, 必 要な場所に格納します.

Mathematica ノートブックの機能は, X フロントエンドとして本体とは別に含 まれています. X フロントエンドを正しくインストールするには, /usr/local/Mathematica/FrontEnd ディレクトリに移動し, ./xfe.install シェ ルスクリプトを実行します. インストール先を指定しなければなりませんが, あらかじめ作成する必要はありません. 必要なディレクトリは, すべて math.install によって作成されているからです. インストールが終了したら, /usr/local/Mathematica/bin ディレクトリに, ``mathematica'' という名前の シェルスクリプトが新たに作成されているはずです.

最後に, Mathematica がインストールしたシェルスクリプトを修正する必要 があります. /usr/local/Mathematica/bin に含まれるすべてのシェルスクリプ トの先頭部分に以下の行を追加します. XKEYSYMDB=/usr/local/Mathematica/lib/X11/XKeysymDB; export XKEYSYMDB これは, Mathematica が使用する Mathematica バージョンのキーマップファイル XKeysymDB の場所を指定するものです. FreeBSD-STABLE を使用している場合は, 以下の行も追加してください. RESOLV_HOST_CONF=/compat/linux/etc/host.conf; export RESOLV_HOST_CONF これは, Mathematica に Linux バージョンの host.conf を使用するように指定し ます. FreeBSD の host.conf の文法は, Linux のものと異なっているため, この 指定をおこなわないと, /etc/host.conf に関わるエラーが発生します.

新しいマニュアルページを利用したい場合は, さらに /etc/manpath.config ファイ ルを修正する必要があります. また自分の~/.cshrcを変更して, /usr/local/Mathematica/bin をパスに追加してください.

これでインストール作業はすべて終了です. ``mathematica'' とタイプすれば, 見栄えのする Mathematica ノートブックが表示されるはずです. Mathematica には, Motif ユーザインタフェースが含まれますが, スタティックにリンクさ れているため, Motif のライブラリは必要ありあません. 頑張って Mathematica をインストールしてください. バグ

ノートブックフロントエンドは, 以下のようなエラーメッセージを表示して, ハングすることがあることが知られています. File .../Untitled-1.mb appears to be broken for OMPR.257.0 今のところ原因はわかっていませんが, このバグが影響を及ぼすのは, ノートブッ クの X window フロントエンドのみです. Mathematica エンジン本体に影響は ありません. そのため, ``math'' によって起動されるコマンドラインのインタ フェースを使用している場合は, このバグは関係ありません. 謝辞

&a.sosと&a.peterに深く感謝します. Linuxエミュレーションが現在の形に あるのは, 彼らのおかげです. そして, 彼ら二人にハッパをかけて, 犬のよう に働かせた Michael Smithに. 今やLinuxエミュレーションは, linuxよりうま くlinuxバイナリを実行できます！ :-) diff --git a/ja/handbook/lists.sgml b/ja/handbook/lists.sgml index cbae01108a..87c1b87eef 100644 --- a/ja/handbook/lists.sgml +++ b/ja/handbook/lists.sgml @@ -1,66 +1,66 @@ - + "> "> "> "> "> "> "> "> "> "> "> "> "> "> diff --git a/ja/handbook/memoryuse.sgml b/ja/handbook/memoryuse.sgml index 980df97737..eccf14eb67 100644 --- a/ja/handbook/memoryuse.sgml +++ b/ja/handbook/memoryuse.sgml @@ -1,61 +1,61 @@ - + PC におけるメモリの利用

原作: &a.joerg;. 16 Apr 1995.

訳: &a.tomo;. 29 Oct 1996. FreeBSDがi386プラットフォーム上でどのようにメモリを使うかに ついての説明です. ブート部分は0:0x7c00にロードされ, すぐに自分自身を 0x7c0:0に移します. (これは手品ではなく, 単なる%cs セレクタのための調節であり, ljmpにより行われます. ) それから最初の15セクタを0x10000(biosbootのMakefileのなかの BOOTSEG部分)にロードし, 作業領域のスタックを0x1fff0以下に セットします. このあと, boot2 に飛びます. つまり, boot1 自身と (ダミーの) DOS パーティションテーブルを飛び越えて, %csセレクタを 調節します---この時点ではまだ16ビットモードです. boot2はブートファイルを要求し, a.outヘッダを調べます. 0x00ffffffによってファイルエントリポイントを (通常は0xf0100000に)マスクし, ロードします. このため, 通常のロードポイントは1MB(0x00100000)になります. ロードしている間, リアルモードでBIOSを使うため, ブートコードは, リアルモードとプロテクトモードの間を行ったり来たりします (訳注: これは, BIOSがリアルモード用に書かれていて, ロードすべき領域がリアルモードではアクセスできない1MBより上位の アドレスであることから, ブートコードがリアルモードと プロテクトモードを切り替えながら動作するためです). ブートコード自身はプロテクトモードで%csと%ds/%es用に セグメントセレクタ0x18と0x20を使い, リアルモードに戻るのに0x28を使います. 最終的にカーネルはアドレス空間全体をカバーできるようなダミーの ディスクリプタを参照して%cs 0x08と %ds/%es/%ss 0x10でスタートします. カーネルはそのロードポイントで起動されます. 別の(高位)アドレスにリンクされるので, ページテーブルやページディレクトリなどが適切に設定され, ページングが有効になり, カーネルがリンクされたアドレスで 動作するようになるまでは, カーネルはロードアドレスからの 相対アドレス (PIC: position independent code) を用いて 実行されなければなりません. 寄贈: &a.davidg;. 16 Apr 1995. カーネルの BSS セグメントの直後の物理ページ (実メモリ) に proc0 (訳注: プロセス番号 0, swapper) のページディレクトリや ページテーブル, Uページが配置されます. 仮想記憶機構が初期化された少しあと, 0x1000-0x9ffffの実メモリとカーネル (text + data + bss + 上記の proc0 に関わるもの + その他) の後ろの実メモリは, 通常の仮想記憶ページの形で利用可能となり, グローバルな空きページリストに追加されます. diff --git a/ja/handbook/mirrors.sgml b/ja/handbook/mirrors.sgml index 01e2b4b062..c6a953aa89 100644 --- a/ja/handbook/mirrors.sgml +++ b/ja/handbook/mirrors.sgml @@ -1,583 +1,583 @@ - + FreeBSD の入手方法

FreeBSD の公式な情報は anonymous FTP によって以下の場所から 入手できます: また Walnut Creek CDROM から出ている CD-ROM からも入手できます: Walnut Creek CDROM 1547 Palos Verdes Mall, Suite 260 Walnut Creek CA 94596 USA Phone: +1 510 674-0783 Fax: +1 510 674-0821 Email: WWW:

さらに, FreeBSD は以下のミラーサイトから anonymous FTP によって 入手できます. もし FreeBSD を anonymous FTP によって手にいれる場合は, 近くのサイトを利用するようにしてください. , , , , , , , , , , , , , , , , , , , , , , . 何か問題がある場合は, このドメインの に連絡してください. 何か問題がある場合は, このドメインの に連絡してください. 何か問題がある場合は, このドメインの に連絡してください. 連絡先: . 何か問題がある場合は, このドメインの に連絡してください. 何か問題がある場合は, このドメインの に連絡してください. 連絡先: . 何か問題がある場合は, このドメインの に連絡してください. 連絡先: . 何か問題がある場合は, このドメインの に連絡してください. 何か問題がある場合は, このドメインの に連絡してください. 何か問題がある場合は, このドメインの に連絡してください. 何か問題がある場合は, このドメインの に連絡してください. 何か問題がある場合は, このドメインの に連絡してください. 連絡先: . 連絡先: . 何か問題がある場合は, このドメインの に連絡してください. 連絡先: . 連絡先: . 何か問題がある場合は, このドメインの に連絡してください. 何か問題がある場合は, このドメインの に連絡してください. 何か問題がある場合は, このドメインの に連絡してください. 連絡先: . 何か問題がある場合は, このドメインの に連絡してください. 何か問題がある場合は, このドメインの に連絡してください. FreeBSD (2.0C またはそれ以降) の輸出規制コード (eBones と secure) の 最新のバージョンは以下の場所から入手できます. もしあなたがアメリカやカナダ以外にいるのであれば, secure (DES) と eBones (Kerberos) を 以下の外国向けの配布サイトから手にいれてください: 南アフリカ このドメインの . ブラジル このドメインの . フィンランド 連絡先: .

CTM/FreeBSD は以下のミラーサイトから anonymous FTP によって 入手できます. もし CTM を anonymous FTP によって手にいれる場合は, 近くのサイトを利用するようにしてください. 何か問題がある場合は, &a.phk;に連絡してください. カリフォルニア, サンフランシスコ近辺, 公式なソース ドイツ, ベルリン ドイツ, トリエル 南アフリカ, ctm, sup, CVSupなどの古い差分ファイルのバックアップサーバ 台湾/中華民国, チャーイー(嘉義) 近くにミラーサイトがない場合やミラーが不完全な場合は, の を試してください. FTP search はノルウェーの Trondheim にある, フリーの素晴らしい アーカイブサーバです. diff --git a/ja/handbook/nfs.sgml b/ja/handbook/nfs.sgml index 8387757548..2911f0dadb 100644 --- a/ja/handbook/nfs.sgml +++ b/ja/handbook/nfs.sgml @@ -1,88 +1,88 @@ - + NFS

原作: &a.jlind;.

訳: &a.tomo;.6 September 1996. ISA用のイーサネットアダプタの中には性能が悪いため, ネットワーク, 特に NFS で深刻な問題がおきるものがあります. これは FreeBSD に限ったことでは ありませんが, FreeBSD でも起こり得ます. この問題は, (FreeBSDを使用した)PCがシリコン・グラフィックス社やサン・マイクロ システムズ社などの高性能なWSにネットワーク接続されている場合に頻繁に 起こります. NFSマウントはうまく行きます. また, いくつかの操作もうまく 働きますが, 他のシステム(WS)に対する要求や応答は続いていても, 突然サーバ がクライアントの要求に対して反応しなくなります. これは, クライアントがFreeBSDか上記のWSであるとき, にクライアント側に起きる 現象です. 多くのシステムでは, いったんこの問題が起きたら解決できないので, 行儀よくシャットダウンするしかありません. 唯一の解決策は, この状況に陥る前にクライアントをリセットすることです. なぜなら, 一旦この状況に陥ると NFS を解除することさえできないからです. "正しい"解決法は, より高性能のイーサネットアダプタをFreeBSDシステムに インストールすることですが, 満足な操作ができるような簡単な方法があります. もし, FreeBSDシステムがサーバになるのなら, クライアントからのマウント時に "-w=1024"オプションをつけて下さい. もしFreeBSDシステムがクライアントになる のなら, NFSファイルシステムを"-r=1024"オプションつきでマウントして下さい. これらのオプションは自動的にマウントをおこなう場合には クライアントのfstabエントリの4番目のフィールドに指定してもよいですし, 手動マウントの場合はmountコマンドの"-o"パラメータで指定してもよいでしょう. NFSサーバとクライアントが別々のネットワーク上にあるような場合, これと間違えやすい他の問題が起きることに注意して下さい. そのような場合は, ルータが必要なUDP情報をきちんとルーティングしているかを確かめて下さい. そうでなければ, たとえあなたが何をしようと解決できないでしょう. 次の例では, "fastws"は高性能のWSのホスト (インタフェース)名で, "freebox"は低性能のイーサネットアダプタを備えた FreeBSDシステムのホスト(インタフェース)名です. また, "/sharedfs"はエクスポートされるNFSファイルシステムであり ("man exports"を見て下さい), "/project"はエクスポートされたファイル システムのクライアント上のマウントポイントとなります. 全ての場合において, "hard"や"soft", "bg"といった追加オプションが アプリケーションにより要求されるかもしれないことに注意して下さい. クライアント側FreeBSDシステム("freebox")の例は: freeboxの/etc/fstabに次のように書いて下さい: fastws:/sharedfs /project nfs rw,-r=1024 0 0 freebox上で手動でmountコマンドを実行する場合は次のようにして下さい: mount -t nfs -o -r=1024 fastws:/sharedfs /project サーバ側FreeBSDシステムの例は: fastwsの/etc/fstabに次のように書いて下さい: freebox:/sharedfs /project nfs rw,-w=1024 0 0 fastws上で手動でmountコマンドで実行する場合は次のようにして下さい: mount -t nfs -o -w=1024 freebox:/sharedfs /project 近いうちにどのような16ビットのイーサネットアダプタでも上記の読み出し, 書き込みサイズの制限なしの操作ができるようになるでしょう. 失敗が発生したとき何が起きているか関心のある人に, なぜ回復不可能なのか も含めて説明します. NFSは通常 (より小さいサイズへ分割されるかもしれませんが) 8Kの"ブロック" サイズで働きます. イーサネットのパケットサイズは最大1500バイト程度なので, 上位階層のコードにとっては1つのユニットのままなのですが, NFS"ブロック"は 複数のイーサネットパケットに分割されます. そして受信され, 組み立て直されてから 肯定応答されなければなりません. 高性能のWSは次々に NFSユニットを構成するパケットを, 基準の範囲内で間隔を詰めて 次々に送り出すことができます. 小さく, 容量の低いカードでは, 同じユニットの 前のパケットがホストに転送される前に, 後のパケットがそれを 「踏みつぶし」てしまいます. このため全体としてのユニットは再構成もされないし, 肯定応答もされません. その結果, WSはタイムアウトして再送を試みますが, 8Kのユニット全体を再送しようとするので, このプロセスは 際限無く繰り返されてしまいます. ユニットサイズをイーサネットのパケットサイズの制限以下に抑えることにより, 受信された完全なイーサネットパケットは個々に肯定応答を受けられることが 保証されるので, デッドロック状態を避けることができるようになります. 高性能のカードを使っている場合でも, 高性能なWSが力任せに次々と PCシステムにデータを送ったときには「踏みつぶし」が起きるかもしれません. そのような「踏みつぶし」はNFS"ユニット"では保証されていません. 「踏みつぶし」が起こったとき, 影響を受けたユニットは再送されます. そして受信され, 組み立てられ, 肯定応答される公平な機会が与えられるでしょう. diff --git a/ja/handbook/nutshell.sgml b/ja/handbook/nutshell.sgml index ab134178b4..d12e173550 100644 --- a/ja/handbook/nutshell.sgml +++ b/ja/handbook/nutshell.sgml @@ -1,153 +1,153 @@ - + FreeBSD とは

原作: 不明.

訳: &a.tomo;.

FreeBSDはIntel社の (SXやDXも含めた) 386や486, Pentiumプロセッサ といったCPUアーキテクチャに基づくパーソナルコンピュータ用としては 現在求めうる最高水準のオペレーティングシステムです. AMD社やCyrix社のIntel互換CPUもサポートされています. FreeBSDは, 以前は高価なコンピュータでしか利用できなかった多くの 高度な機能を提供します. FreeBSDには次のような機能があります: アプリケーションとユーザとの間で円滑かつ公平にコンピュータを 共有することを保証する, 優先度を動的に調節する機能を備えた プリエンプティブマルチタスキング. 多くの人々が1つのFreeBSDシステムをさまざまな目的で同時に 使うことを可能にするマルチユーザアクセス. また, プリンタやテープドライブのようなシステムの周辺機器も すべてのユーザ間で適切に共有されます. SLIPやPPP, NFS, NISのサポートを含んだ完全な TCP/IPネットワーキング. これによって, FreeBSDマシンが商用サーバと同じように相互に運用でき, NFS (リモートファイルアクセス) や電子メールサービスのような極めて 重要な機能を提供します. また, WWWやftp, ルーティング, ファイアウォール (セキュリティ) サービスを用いてインターネットと 接続できます. アプリケーション (あるいはユーザ) がお互いに干渉できない ようにするメモリ保護機能. アプリケーションがクラッシュしても, どのような場合でも 他のアプリケーションには影響を与えません. FreeBSDは32ビットのオペレーティングシステムであり, 最初からそのようにこつこつと設計されました. 業界標準であるX Windowシステム (X11R6) は, 普通のVGAカードやモニタでグラフィカルユーザ インタフェース (GUI) を提供し, すべてのソースコードも一緒に提供されます. SCOやBSDI, NetBSD, Linux, 386BSD用に作られた多くの プログラムにおけるバイナリ互換性. 何百ものすぐに実行可能なアプリケーションが FreeBSDのportsやpackagesコレクション で利用可能です. ここに用意されているものは ネットを探し回る必要がありません インターネット上で入手可能な, 移植が容易な 何千ものアプリケーションを追加できます. FreeBSDは最も評判の よい商用のUnixシステムとソースコードレベルで互換性があります. このため, ほとんどのアプリケーションは, もしあったとしてもほんの 少しの変更でコンパイルすることができます. デマンドページング仮想メモリとそれに`付随の VM/buffer キャッシュ'の設計は, 多くのメモリを要求する アプリケーションに対して効率よくメモリを与えるようにする一方で, 他のユーザに対しても対話的な応答を維持します. 共有ライブラリ (MS-WindowsのDLLと同等のUnixの 機能) によって, ディスクスペースとメモリを効果的に使用する ことができます. 完全なCやC++, Fortranの 開発ツール. 進んだ研究や開発のための多くの他の言語も portsやpackagesコレクションで提供されています. システム全体のソースコードが提供されているので, 要求に合わせて環境を最大限に適合させることができます. 真のオープンシステムが利用できるのですから, 所有権のある解決方法に 締めつけられ, ベンダのなすがままになる必要はありません. 膨大な量のオンラインドキュメント. もう書ききれません! FreeBSDはカリフォルニア大学バークレイ校のComputer Systems Research Group (CSRG) による4.4BSD-Liteリリースを基にしており, BSDシステムの開発の優れた伝統を守り続けています. CSRGによる素晴らしい活動に加えて, FreeBSDプロジェクトは何千時間もの時間を注ぎ込んで, 実際の使用の場において最大の性能と信頼性を 発揮するためにシステムのチューニングをおこなっています. 多くの大企業がPCオペレーティングシステムの分野で 実現しようと奮闘しているそのような機能や性能, 信頼性を FreeBSDは今すぐ提供できます! あなたの思いつく限りのアプリケーションは, 何でもFreeBSDで 実行できます. ソフトウェア開発から ファクトリオートメーション, 在庫制御から遠く離れた人工衛星の アンテナの方向調整まで; 商用UNIX製品でできることは, FreeBSDでも十分にできるのです! また, FreeBSDは世界中の研究センターや大学によって開発される 文字通り何千もの高品質で, たいていはほとんど無料で利用できる アプリケーションによる恩恵を得ることができます. 商用のアプリケーションも提供されており, 日々増え続けています. FreeBSDのソースコードは広く提供されているので, システムも特別なアプリケーションやプロジェクトに合わせて, いくらでもカスタマイズすることができます. これは 有名な商業ベンダから出ているほとんどのオペレーティング システムでは不可能なことです. 以下に現在FreeBSDを 使っている人々のアプリケーションの例をいくつか上げます: インターネットサービス: FreeBSDに組み込まれている 頑強なTCP/IPネットワーキング機能は次のようなさまざまなインターネット サービスの理想的なプラットフォームになります: FTP サーバ World Wide Web サーバ Gopher サーバ 電子メールサーバ USENET ニュース 電子掲示板システム さらにいろいろ... まずは高価ではない386クラスのPCで始めておいて, 仕事の成長に合わせてアップグレードできます. 教育: あなたは計算機科学または工学の学生ですか? オペレーティングシステムやコンピュータアーキテクチャ, ネットワーキングを学習するなら, FreeBSDを手に 経験するのが一番よい方法です. 自由に利用できるCADや数学, グラフィックデザインのパッケージもいくつもあり, コンピュータに関心を持った人が他の人の成果を 手に入れて利用するのにとても役に立ちます. 研究:システム全体のソースコードが利用できるため, FreeBSDはオペレーティングシステムの研究だけでなく, 計算機科学の他の部門においても優れたプラットフォームです. 自由に利用できるFreeBSDの特長は, オープンフォーラムで 議論される特別なライセンスの同意や制限について 心配することなく, 離れたグループでもアイディアや開発の共有に よる共同研究を可能にします. ネットワーキング:新しいルータが必要? ネームサーバ (DNS) は? 内部のネットワークを人々から守る ファイアウォールは? FreeBSDはすみに眠っている使われていない386や486のPCを簡単に 洗練されたパケットフィルタリング機能を持つ高級なルータに 変えることができます. X Windowワークステーション: 自由に利用できるXFree86サーバやX Inside社から提供される 優れた商業サーバを使うことによって, 安価なX端末 としてFreeBSDを使うこともできます. X端末とは違ってFreeBSDは 多くのアプリケーションをローカルに走らせることもでき, 中心のサーバの負荷を軽減することも可能です. FreeBSDは"ディスクレス"でもブート可能であり, 個々のワークステーションを安価で, 容易に管理することさえ 可能にします. ソフトウェア開発: 基本的なFreeBSDシステムには 有名なGNUのC/C++コンパイラやデバッガ含んだ完全な開発ツールが ついてきます. FreeBSDはCDROMまたはanonymous ftpによってソース, バイナリとも 利用可能です. 詳しくは, を見てください. diff --git a/ja/handbook/pgpkeys.sgml b/ja/handbook/pgpkeys.sgml index 2942574792..70f6b0a3f7 100644 --- a/ja/handbook/pgpkeys.sgml +++ b/ja/handbook/pgpkeys.sgml @@ -1,250 +1,250 @@ - + PGP 公開鍵

原作: 不明.

訳: &a.kiroh;.

署名を検証したり, コアチームメンバやオフィサに暗号メー ルを送りたい場合のために, PGPの公開鍵を添付します. オフィサ FreeBSD Security Officer <security-officer@freebsd.org>

FreeBSD Security Officer <security-officer@freebsd.org> Fingerprint = 41 08 4E BB DB 41 60 71 F9 E5 0E 98 73 AF 3F 11 -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3i mQCNAzF7MY4AAAEEAK7qBgPuBejER5HQbQlsOldk3ZVWXlRj54raz3IbuAUrDrQL h3g57T9QY++f3Mot2LAf5lDJbsMfWrtwPrPwCCFRYQd6XH778a+l4ju5axyjrt/L Ciw9RrOC+WaPv3lIdLuqYge2QRC1LvKACIPNbIcgbnLeRGLovFUuHi5z0oilAAUR tDdGcmVlQlNEIFNlY3VyaXR5IE9mZmljZXIgPHNlY3VyaXR5LW9mZmljZXJAZnJl ZWJzZC5vcmc+iQCVAwUQMX6yrOJgpPLZnQjrAQHyowQA1Nv2AY8vJIrdp2ttV6RU tZBYnI7gTO3sFC2bhIHsCvfVU3JphfqWQ7AnTXcD2yPjGcchUfc/EcL1tSlqW4y7 PMP4GHZp9vHog1NAsgLC9Y1P/1cOeuhZ0pDpZZ5zxTo6TQcCBjQA6KhiBFP4TJql 3olFfPBh3B/Tu3dqmEbSWpuJAJUDBRAxez3C9RVb+45ULV0BAak8A/9JIG/jRJaz QbKom6wMw852C/Z0qBLJy7KdN30099zMjQYeC9PnlkZ0USjQ4TSpC8UerYv6IfhV nNY6gyF2Hx4CbEFlopnfA1c4yxtXKti1kSN6wBy/ki3SmqtfDhPQ4Q31p63cSe5A 3aoHcjvWuqPLpW4ba2uHVKGP3g7SSt6AOYkAlQMFEDF8mz0ff6kIA1j8vQEBmZcD /REaUPDRx6qr1XRQlMs6pfgNKEwnKmcUzQLCvKBnYYGmD5ydPLxCPSFnPcPthaUb 5zVgMTjfjS2fkEiRrua4duGRgqN4xY7VRAsIQeMSITBOZeBZZf2oa9Ntidr5PumS 9uQ9bvdfWMpsemk2MaRG9BSoy5Wvy8VxROYYUwpT8Cf2iQCVAwUQMXsyqWtaZ42B sqd5AQHKjAQAvolI30Nyu3IyTfNeCb/DvOe9tlOn/o+VUDNJiE/PuBe1s2Y94a/P BfcohpKC2kza3NiW6lLTp00OWQsuu0QAPc02vYOyseZWy4y3Phnw60pWzLcFdemT 0GiYS5Xm1o9nAhPFciybn9j1q8UadIlIq0wbqWgdInBT8YI/l4f5sf6JAJUDBRAx ezKXVS4eLnPSiKUBAc5OBACIXTlKqQC3B53qt7bNMV46m81fuw1PhKaJEI033mCD ovzyEFFQeOyRXeu25Jg9Bq0Sn37ynISucHSmt2tUD5W0+p1MUGyTqnfqejMUWBzO v4Xhp6a8RtDdUMBOTtro16iulGiRrCKxzVgEl4i+9Z0ZiE6BWlg5AetoF5n3mGk1 lw== =ipyA -----END PGP PUBLIC KEY BLOCK----- コアチームメンバ &a.jkh

Jordan K. Hubbard <jkh@FreeBSD.org> Fingerprint = 3C F2 27 7E 4A 6C 09 0A 4B C9 47 CD 4F 4D 0B 20 -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2i mQCNAzFjX0IAAAEEAML+nm9/kDNPp43ZUZGjYkm2QLtoC1Wxr8JulZXqk7qmhYcQ jvX+fyoriJ6/7ZlnLe2oG5j9tZOnRLPvMaz0g9CpW6Dz3nkXrNPkmOFV9B8D94Mk tyFeRJFqnkCuqBj6D+H8FtBwEeeTecSh2tJ0bZZTXnAMhxeOdvUVW/uOVC1dAAUR tCNKb3JkYW4gSy4gSHViYmFyZCA8amtoQEZyZWVCU0Qub3JnPokAlQMFEDF75D1r WmeNgbKneQEBXtcD+gJIv8JzZRKlDZyTCQanK8iRgE+zMhxptI0kDObaGxT1BrpY 4/EPyiUN10G4k2Jb+DOc8Lg2xDQ3xmvgipFf9NMNV/ThaEuZ3wA31I6tW/arQEqB Tp8u6T3v20m62t7Afo9HaoE6MBpHQUk2TilxgAd5P57sporL3pgW9YojIO9ziQCV AwUQMXyV2h9/qQgDWPy9AQEMfgP/RmbSg2WlesATUQ4WuanjcdREduKPyfQatrXD 2xt+jg9X78dTyiNN1YvLqvT6msfs04MKSC0hA2mou6ozw8Xak+1QmP0fBOZKp9pP 8szO188Do9ByzJPvHF1eXT7jFMOXVq8ZIl9iwjxcIDLzlxOz49DC7LO6AT+LKQk7 UGeP+lqJAJUDBRAxe+UG9RVb+45ULV0BAXZ9A/9F9gLpGukVNkeOjaqxQdJGTS+a xh/Abk0c/nKhAEyxpAl5JyQ3ifYk6BHhPvlTi9LrZoXGA8sk/eU4eRTZVzvGEC4G +xsavlE/xzku8855QTLPpkCunUpQeu1wzaIrUUE6Zjh05imFbJYyQOBgTFpuqWsC rsUpl+2mr8IGIxG5rA== =LW9i -----END PGP PUBLIC KEY BLOCK----- &a.phk

Poul-Henning Kamp <phk@FreeBSD.org> Fingerprint = A3 F3 88 28 2F 9B 99 A2 49 F4 E2 FA 5A 78 8B 3E -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3i mQCNAzAdpMIAAAEEALHDgrFUwhZtb7PbXg3upELoDVEUPFRwnmpJH1rRqyROUGcI ooVe7u+FQlIs5OsXK8ECs/5Wpe2UrZSzHvjwBYOND5H42YtI5UULZLRCo5bFfTVA K9Rpo5icfTsYihrzU2nmnycwFMk+jYXyT/ZDYWDP/BM9iLjj0x9/qQgDWPy9AAUR tCNQb3VsLUhlbm5pbmcgS2FtcCA8cGhrQEZyZWVCU0Qub3JnPokAlQMFEDF+jX1r WmeNgbKneQEBCrID/i/ri8/eXUXRJp2fqJqzvrWGTP9Ix1O4vMguah9IILijgpYy OJYkezZKijjVCVmLX7EwfNXfYkqLAWUa08eov4QfJfJDgfe+Z/3/UoX7RcJoy2Aj TBZQzOI9JMkrzFdtFGYwMr/QXhOdVVpSGeZ/6Hkrs7pd2Z6MNNrRf81ZyJyYiQCV AwUQMXyV5/UVW/uOVC1dAQFyfAP/SujU+lS2WQuat4O2wZOQ1rswUt6CthG8MOsc 7A9kfXnZbaM9Sdxj54CtAlqR4eJMOYk2kVqAtmCWETRuonJxr5TAJdf7q6kByVYc QEyDZvKJYwyrI9UQSelSgczWwiSB01aV9ACaKlEF9iHYvIKBa9HwJu3A9ggW9SYa AHcxHzuJAJUDBRAxSx5cH3+pCANY/L0BAY+TA/9YQPISXYaS+5r0I60wCJ+i3a9P C69Zak2ikgTHQi97LhpVtEsP3SAYInDw4YMS2oU9w1XxoiLLd9hUpcZlmO8Ip3vN F+E2ZCfR4sNzKarY5fdo+sxzatGWRPgnHjbm6RHWCw6qJACDD3VpaFjx2XD8QrOT yiObnbHhWBdoEAIyNokAlQMFEDE5Q6DvYbnpEdWO1QEBsvgD/0c6flBrSWr20oj8 eRJ1zl8ZAP/rpV0IEBvb3ZFsHsJL8QzTsx1typFFghrT7SDBDc52xY90JWAflEiG n9aIL5Q+RHVxjw30yDaRPAl9ll82o34GBaWBEw83bsI6Fg2XxDfc2X0KkEutlYAE XjiM95PQS+9PM//llDtPvkSxgpiJiQCVAwUQMOavJADy2QnruxtBAQE92wQAsKPq /U4G4ksslOXGaauSoBk9XO3lB147cSpra1w9ZxTSeo+8dgzNlxnugWDnw1mxauFJ BAMgHl74rrlD+Hp0Ltb9oOyRl3riPG0TOdfaS3T8w6vw52wOKzUrZ/0pB+2sDHzU qZXBbhOq3OXs1ZMNe3jh8w62JsLBWry/YMWRMnI= =MDQ9 -----END PGP PUBLIC KEY BLOCK----- &a.joerg

Joerg Wunsch <j@uriah.heep.sax.de> Fingerprint = DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2i mQCNAzGCFeAAAAEEAKmRBU2Nvc7nZy1Ouid61HunA/5hF4O91cXm71/KPaT7dskz q5sFXvPJPpawwvqHPHfEbAK42ZaywyFp59L1GaYj87Pda+PlAYRJyY2DJl5/7JPe ziq+7B8MdvbX6D526sdmcR+jPXPbHznASjkx9DPmK+7TgFujyXW7bjh2o/exAAUR tCZKb2VyZyBXdW5zY2ggPGpAaW50ZXJmYWNlLWJ1c2luZXNzLmRlPokAlQMFEDGp bnd1u244dqP3sQEBJnQD/RVSAzgf4uorv3fpbosI0LE3LUufAYGBSJNJnskeKyud ZkNkI5zGGDwVneH/cSkKT4ORooeqcTBxKeMaMuXPVl30QahgNwWjfuTvl5OZ8ors QGGWIn5FhqYXsKkjEGxIOBOfvvlVQ0UbcR0N2+5F6Mb5GqrXZpIesn7jFJpkQKPU tC1Kb2VyZyBXdW5zY2ggPGpvZXJnX3d1bnNjaEB1cmlhaC5oZWVwLnNheC5kZT6J AJUDBRAyCIWZdbtuOHaj97EBAVMzA/41VIph36l+yO9WGKkEB+NYbYOz2W/kyi74 kXLvLdTXcRYFaCSZORSsQKPGNMrPZUoLoAKxE25AoCgl5towqr/sCcu0A0MMvJdd UvlQ2T+ylSpGmWchqoXCN7FdGyxrZ5zzxzLIvtcio6kaHd76XxyJpltCASupdD53 nEtxnu8sRrQxSm9lcmcgV3Vuc2NoIDxqb2VyZ193dW5zY2hAaW50ZXJmYWNlLWJ1 c2luZXNzLmRlPokAlQMFEDIIhfR1u244dqP3sQEBWoID/RhBm+qtW+hu2fqAj9d8 CVgEKJugrxZIpXuCKFvO+bCgQtogt9EX+TJh4s8UUdcFkyEIu8CT2C3Rrr1grvck fxvrTgzSzvtYyv1072X3GkVY+SlUMBMArdl1qNW23oT7Q558ajnsaL065XJ5m7Ha cgTTikiofYG8i1s7TrsEeq6PtCJKb2VyZyBXdW5zY2ggPGpAdXJpYWguaGVlcC5z YXguZGU+iQCVAwUQMalkbHW7bjh2o/exAQFwwQP+Pa82QeWpJE0m7f4DXd/DiYAv h/DeXWtub1fXQ9yqAL131n8OzsSLMb0PwG/qyZrpK61sT3bAvtVlNftaxmuD7yaf 1SUQ3rNmsBq5/oju/3EKEiFc4gtuyaXG74y7y1XASIstck/0byfvO2t4z0R7d1RR nKRYeCspMcUjYshsoJeJAJUDBRAxpL3UPiAdBSUb0JkBAZg7BACE+mKhsrd39/P6 NattCCOSg76Pf2CVgZdvbb7qK4SmsVGz+58pi2OWM1M0rcHgNZKTIg9rBy47gui2 KOnqOR7ZuyMVJJqyEZZywmWmfCy/sR4Ui1PehZNNNBAi09u03ItbozrEH6Msa1oC 8mp86XOA70Et8e4DYtj5a9tVbjjtJYkAlQMFEDGCUB31FVv7jlQtXQEB5KgD/iIJ Ze5lFkPr2B/Cr7BKMVBot1/JSu05NsHgJZ3uK15w4mVtNPZcFi/dKbn+qRM6LKDF e/GF0HZD/ZD1FJt8yQjzF2w340B+F2GGEOwnClqZDtEAqnIBzM/ECQQqH+6Bi8gp kFZrFgg5eON7ikqmusDnOlYStM/CBfgpSbR8kDmF =Bz4E -----END PGP PUBLIC KEY BLOCK----- &a.ache

Andrey A. Chernov <ache@FreeBSD.org> Fingerprint = 33 03 9F 48 33 7B 4A 15 63 48 88 0A C4 97 FD 49 -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3ia mQCNAiqUMGQAAAEEAPGhcD6A2Buey5LYz0sphDLpVgOZc/bb9UHAbaGKUAGXmafs Dcb2HnsuYGgX/zrQXuCi/wIGtXcZWB97APtKOhFsZnPinDR5n/dde/mw9FnuhwqD m+rKSL1HlN0z/Msa5y7g16760wHhSR6NoBSEG5wQAHIMMq7Q0uJgpPLZnQjrAAUT tCJBbmRyZXkgQS4gQ2hlcm5vdiA8YWNoZUBuYWd1YWwucnU+iQCVAwUQMcm5HeJg pPLZnQjrAQHwvQP9GdmAf1gdcuayHEgNkc11macPH11cwWjYjzA2YoecFMGV7iqK K8QYrr1MjbGXf8DAG8Ubfm0QbI8Lj8iG3NgqIru0c72UuHGSn/APfGGG0AtPX5UK /k7BgI0Ca2po6NA5nrSp8tDsdEz/4gyea84RXl2prtTf5Jj07hflbRstGXK0MkFu ZHJleSBBLiBDaGVybm92LCBCbGFjayBNYWdlIDxhY2hlQGFzdHJhbC5tc2suc3U+ iQCVAwUQMCsAo5/rGryoL8h3AQHq1QQAidyNFqA9hvrmMcjpY7csJVFlGvj574Wj 4GPao3pZeuQaMBmsWqaXLYnWU/Aldb6kTz6+nRcQX50zFH0THSPfApwEW7yybSTI 5apJmWT3qhKN2vmLNg2yNzhqLTzHLD1lH3i1pfQq8WevrNfjLUco5S/VuekTma/o snzCCw7fQzCJAJUDBRAwKvwoa1pnjYGyp3kBARihBACoXr3qfG65hFCyKJISmjOv aoGranxUIkeDS0yQdTHzhQ+dwB1OhhK15E0Nwr0MKajLMm90n6+Zdb5y/FIjpPri u8dIrlHrWZlewa88eEDM+Q/NxT1iYg+HaKDAE171jmLpSpCL0MiJtO0i36L3ekVD 7Hv8vffOZHPSHirIzJOZTYkAlQMFEDAau6zFLUdtDb+QbQEBQX8D/AxwkYeFaYxZ YMFODHIvSk23hAsjCmUA2Uil1FeWAusb+o8xRfPDc7TnosrIifJqbF5+fcHCG5VS TGlhBhd18YWUeabf/h9O2BsQX55yWRuB2x3diJ1xI/VVdG+rxlMCmE4ZR1Tl9x+M tun9KqKVpB39VlkCBYQ3hlgNt/TJUY4riQCVAwUQMBHMmyJRltlmbQBRAQFQkwP/ YC3ahs3ZMMoriOlt3ZxGNUUPTF7rIER3j+c7mqGG46dEnDB5sUrkzacpoLX5sj1t GR3bvz9a4vmk1Av3KFNNvrZZ3/BZFGpq3mCTiAC9zsyNYQ8L0AfGIUO5goCIjqwO TNQIAOpNsJ5S+nMAkQB4YmmNlI6GTb3D18zfhPZ6uciJAJUCBRAwD0sl4uW74fte FRkBAWsAA/9NYqBRBKbmltQDpyK4+jBAYjkXBJmARFXKJYTlnTgOHMpZqoVyW96x naa5MzxEiu7ZWm5oL10QDIp1krkBP2KcmvfSMMHb5aGCCQc2/P8NlfXAuHtNGzYi I0UAIwi8ih/S1liVfvnqF9uV3d3koE7VsQ9OA4Qo0ZL2ggW+/gEaYIkAlQMFEDAO z6qx/IyHe3rl4QEBIvYD/jIr8Xqo/2I5gncghSeFR01n0vELFIvaF4cHofGzyzBp YsfA+6pgFI1IM+LUF3kbUkAY/2uSf9U5ECcaMCTWCwVgJVO+oG075SHEM4buhrzu tZiM1dTyTaepaPpTyRMUUx9ZMMYJs7sbqLId1eDwrJxUPhrBNvf/w2W2sYHSY8cd iQCVAwUQMAzqgHcdkq6JcsfBAQGTxwQAtgeLFi2rhSOdllpDXUwz+SS6bEjFTWgR sWFMy9QnOcqryw7LyuFmWein4jasjY033JsODfWQPiPVNA3UEnXVg9+n8AvNMPO8 JkRvCn1eNg0VaJy9J368uArio93agd2Yf/R5r+QEuPjIssVk8hdcy/luEhSiXWf6 bLMVHEA0J+OJAJUDBRAwDUi+4mCk8tmdCOsBAatBBACHB+qtW880seRCDZLjl/bT 1b145po60U7u6a3PEBkY0NA72tWDQuRPF/Cn/0+VdFNxQUsgkrbwaJWOoi0KQsvl Om3RrsxKbn9uvEKLxExyKH3pxp76kvz/lEWwEeKvBK+84Pb1lzpG3W7u2XDfi3VQ PTi35SZMAHc6C0Ct/mjNlYkAlQMFEDAMrPD7wj+NsTMUOQEBJckD/ik4WsZzm2qO x9FwerGq7Zwchc+Jq1YeN5PxpzqSf4AG7+7dFIn+oe6X2FcIzgbYY+IfmgJIHEVj DHH5+uAXyb6l4iKc89eQawO3t88pfHLJWbTzmnvgz2cMrxt94HRvgkHfvcpGEgby ldq6EB33OunazFcfZFRIcXk1sfyLDvYE =4Yu3 -----END PGP PUBLIC KEY BLOCK----- &a.rich

Rich Murphey <rich@FreeBSD.org> fingerprint = AF A0 60 C4 84 D6 0C 73 D1 EF C0 E9 9D 21 DB E4 -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAy97V+MAAAEEALiNM3FCwm3qrCe81E20UOSlNclOWfZHNAyOyj1ahHeINvo1 FBF2Gd5Lbj0y8SLMno5yJ6P4F4r+x3jwHZrzAIwMs/lxDXRtB0VeVWnlj6a3Rezs wbfaTeSVyh5JohEcKdoYiMG5wjATOwK/NAwIPthB1RzRjnEeer3HI3ZYNEOpAAUR tCRSaWNoIE11cnBoZXkgPHJpY2hAbGFtcHJleS51dG1iLmVkdT6JAJUDBRAve15W vccjdlg0Q6kBAZTZBACcNd/LiVnMFURPrO4pVRn1sVQeokVX7izeWQ7siE31Iy7g Sb97WRLEYDi686osaGfsuKNA87Rm+q5F+jxeUV4w4szoqp60gGvCbD0KCB2hWraP /2s2qdVAxhfcoTin/Qp1ZWvXxFF7imGA/IjYIfB42VkaRYu6BwLEm3YAGfGcSw== =QoiM -----END PGP PUBLIC KEY BLOCK----- &a.peter

Peter Wemm <peter@FreeBSD.org> Fingerprint = 47 05 04 CA 4C EE F8 93 F6 DB 02 92 6D F5 58 8A -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3ia mQCNAy9/FJwAAAEEALxs9dE9tFd0Ru1TXdq301KfEoe5uYKKuldHRBOacG2Wny6/ W3Ill57hOi2+xmq5X/mHkapywxvy4cyLdt31i4GEKDvxpDvEzAYcy2n9dIup/eg2 kEhRBX9G5k/LKM4NQsRIieaIEGGgCZRm0lINqw495aZYrPpO4EqGN2HYnOMZAAUT tCVQZXRlciBXZW1tIDxwZXRlckBoYXl3aXJlLmRpYWxpeC5jb20+iQCVAwUQMbET 6kqGN2HYnOMZAQG1iwP/atRXZ55OLp6RkLBt9UG7a+AM2kA+ZvyRyOIEZkpm4+pb iTIDRt36TtOhnf2e7scgiQfKU7LdmvAv5YzmGcVk/ubks5EF3jIuXGHCNbGW1KZB 7Zqj1utt4a9Twd2SwNUyHE20FvjcybMUNT3OlxvXxpE/Vl0Ft14XrQD/o7lUwIS0 JVBldGVyIFdlbW0gPHBldGVyQHBlcnRoLmRpYWxpeC5vei5hdT6JAJUDBRAxsRQh SoY3Ydic4xkBAel5A/9hzsH7ha50FLXcBT1JILRKjXkq+uI0NzGs/MYBLW2sP8pt T24WwpN9dVFkKuPos2RNsZLR0xQpSX2jJ8VSH26D8rokhffSh4lp3/xrKXrdEu5v /kVyMGYtakqrwGp8TIgO5CoBUgpnIc2rPE0HMslx7Z/4Jfb9JISZG/3790dtG7Qe UGV0ZXIgV2VtbSA8cGV0ZXJARnJlZUJTRC5vcmc+iQCVAwUQMbESXUqGN2HYnOMZ AQGSVAP+IvzVh8+SyB/0eCBf91dy5XhcjBa+RDxWNP+JnL9r/o7vYG6zhDP8XeC5 T68dV6j3me+CUOivZh0euEYSke2SSfQPtdsq+XVaooXvddSsiymm/eKmVB2It+lk LtlbSxp8P7fCYOOH0Es2wReavYk83HzTmIUZEg9wXQ6wt5ZcsDu0JVBldGVyIFdl bW0gPHBldGVyQHNwaW5uZXIuZGlhbGl4LmNvbT6JAJUDBRAxsRItSoY3Ydic4xkB AXQOBACpjRZY/ERfR0LKCN1Gm572KgFjecAsBAeLvmX/M6ujh4nNt086CtUj5Zkn QRNXV10Bkumog5C0/sTnXnsDbO531CHB/wwY0rpJQDicypYlz0FuxJLijcMuHquW 5fo9xwdu4vlgV4Z+jmjTUGOu+CxmkeNRBquOFqOQE3CInIoP8w== =iB1t -----END PGP PUBLIC KEY BLOCK----- diff --git a/ja/handbook/policies.sgml b/ja/handbook/policies.sgml index 90fcbb4aaf..5f1a1c7e4d 100644 --- a/ja/handbook/policies.sgml +++ b/ja/handbook/policies.sgml @@ -1,206 +1,206 @@ - + ソースツリーのガイドラインおよび方針

原作: &a.phk;.

訳者: &a.mihoko; 6 September 1996 . 本章は, FreeBSD のソースツリーについてのさまざまなガイドラインや ポリシーについて書かれています. Makefile 中の MAINTAINER

1996年6月.

FreeBSD 配布物の特定の部分が, 一人の人やグループによって保守 されている場合は, ソースツリーの当該 Makefile に MAINTAINER= email-addresses

が付け加えられています. これを記述することによって, この部分が誰 に保守管理されているかを世界中のユーザに伝えることができます.

この意味は次のとおりです:

保守担当者がそのコードを所有し, そのコードに対する責任を持っ ています. すなわち, その人がそのコードに関するバグの修正やトラブル報告 に対する回答をします. また, そのコードが寄贈ソフトウェアの場合には, そのソフトウェアの新しいバージョンに適切に追従させる作業をその人が行い ます.

保守担当者が決められているディレクトリに対して変更をおこなう場合は, 変更をおこなう前に, その変更内容を保守担当者に送って, 保守担当者にレビューをしてもらってください. 保守担当者が, 電子メールに一定期間応答しない場合にのみ, 保守担当者がレビューすることなしに, 変更をおこなうことが認められます. しかしながら, そのような場合でも可能な限り, 変更点を第三者にレビュー してもらうようにしてください.

もちろん, この義務を引き受けることができない人やグループを 保守管理者として追加することはできません. また, 保守管理者がソースツリー管理者 ("committer") である必要は ありません. 寄贈ソフトウェア

1996年6月.

FreeBSD 配布物のうちのいくつかのソフトウェアは FreeBSD プロジェクト 以外のところで保守されています. 歴史的な経緯から, 私たちはこれを 寄贈 ソフトウェアと 呼んでいます. perl や gcc, patch などがその例です.

ここ数年来, この種のソフトウェアの取り扱いには, さまざまな方法が 取られてきましたが, どの方法にもいくつかの利点と欠点があります. これまで欠点のない明確な方法はありませんでした.

議論した結果, これらの方法のうちの一つが「公式な」方法として選択され ました. その方法が, 今後, この種のソフトウェアを取り込む場合に, 使用 されます. その上, この方法では, だれもが(cvs にアクセス権のない人でさえ)「公式」 バージョンのソースに対する差分を簡単に得ることができます. これは古い方法にはなかった大きな利点です. ですから, 既存の寄贈ソフトウェアも, この方法に収束していくことを強く望んでいます. この方法を使用することにより, 寄贈ソフトウェアの主な開発者に, 変更 点を返すのがとても容易になります.

しかしながら結局, 寄贈ソフトウェアの取扱は, 実際に作業を行って いる人々に委ねられています. もしこの方法を使用することが, その人が扱っているパッケージには 極端に合わないような場合には, コアチームの承認さえあれば, これらの ルールに反しても, 他の開発者の一般的な合意は得られるでしょう. 将来にわたってパッケージを保守できるということは, 大変重要な事柄に なってきます.

プログラミング言語 Tcl は, この方法が活用されているよい例になっています:

src/contrib/tcl には, このパッケージの保守管理者が 配布したソースが含まれています. この中からは FreeBSD に完全には適用 できない部分が削除されています. Tcl の場合は, "mac", "win", "compat" というサブディレクトリは, FreeBSD に取り込む前に削除されて いました.

src/lib/libtcl には, ライブラリを生成したり, ドキュ メントをインストールする際に使用される, 標準の bsd.lib.mk の 規則を使用した「bmake スタイル」の Makefile だけが 含まれています.

src/usr.bin/tclsh には, bsd.prog.mk 規則 を使用して, "tclsh" プログラムや関連するマニュアルページを生成 /インストール する bmake スタイルの Makefile だけが含まれています.

src/tools/tools/tcl_bmake には, tcl ソフトウェアを更新する必要が生じたときの助けになる2つのシェルス クリプトが含まれています. これらは, ソフトウェアを構築するのに使用し たり, インストール対象になるソフトウェアではありません.

ここ重要なのは, "src/contrib/tcl" ディレクトリが, 規則にしたがっ て作られているということです. つまり, できるだけ FreeBSD に特化した 変更をおこなわないようにしたソースを(CVS のベンダブランチに)おくようにし ています. freefall 上の「簡易取り込み」ツールは, 寄贈ソフトウェアを取り込む 手助けとなります. けれども, このツールの実行方法に疑問が生じた場合は, まずはじめに質問して, 失敗をしないようにしてください. そして, その疑問を「解決して」からツールを使用してください. CVS に寄贈ソフトウェアを取り込む際には, 事故があってはいけません. よくあるような間違いをおかさないように, 十分注意してください.

CVS には, 残念なことにベンダブランチという設計制限があります. このため, CVS に寄贈ソフトウェアを取り込むには, オリジナル配布ソースに 適用されるベンダからの「公式」パッチと, ベンダブランチに逆輸入された 結果が必要です. ベンダブランチの一貫性を破壊したり, 将来, 新しいバージョンを取り込む 時に衝突を起こしてしまったりというような 困難な事態に陥らないように しなければなりません. そのために, FreeBSD が管理しているバージョンに 対して, 公式パッチを決して当ててはいけませんし, 公式パッチを "commit" してはいけません.

多くのパッケージが, 他のアーキテクチャや他の環境と FreeBSD との互換性を保ためのファイルをいくつか含んでいます. そこで, スペースを節約するために, FreeBSD にとっては無意味な配布ツリー上の一 部を削除することが許されています. けれども, 削除されずに残ったファイルに対する, 著作権の通知やリリース ノートのような情報を含んだファイルは, 決して削除しては いけませ ん .

"bmake" Makefile が何らかのユーティリティによって, 配布ツリー から自動的に生成できると, うまくいけば, 新しいバージョンへの アップグレードをより簡単におこなうことができます. もしこのようなユーティリティを作成できた場合には, 将来の管理者に とって便利になるように, 移植の際に, src/tools ディレクトリ上に, (必要に応じて)そのユーティリティを必ずチェックインしてください.

src/contrib/tcl レベルのディレクトリには, README.FreeBSD と 呼ばれるファイルが追加されており, そのファイルでは 次のような内容が 記述されています. ディレクトリ上に存在するファイル オリジナルの配布物をどこから入手すればよいか また, 公式配布 サイトはどこか オリジナルの作者にパッチを送り返すためには, どこに送ればよいか FreeBSD に特化した変更点の概要 共有ライブラリ

Contributed by &a.asami;, &a.peter;, and &a.obrien;. 9 December 1996.

もしあなたが共有ライブラリをサポートする機能を port に追加した り, 共有ライブラリをサポートしていない他のソフトウェアに追加する 場合には, 共有ライブラリのバージョン番号を次の規則にしたがって つけてください. 一般的には, この規則は, ソフトウェアのリリースバージョンとは 全く関係ありません.

共有ライブラリを作成する三つの重要な規則は次の通りです: 1.0 から始める 過去のバージョンに互換性のある変更の場合は, マイナー番号を増やす 互換性のない変更の場合は, メジャー番号を増やす

例えば, 機能追加とバグ吸収の場合は, マイナー番号を増やします. 機能削除, 関数呼び出しのシンタックスなどが変更された場合は, 強制的にメジャー番号を変更します.

メジャー.マイナーー (x,y) の形式のバージョン番号を使用します. FreeBSD のダイナミックリンカは, x.y.z という形式のバージョン番号 は扱えません. この場合, 「y」の後のバージョン番号(つまり三つ目の数字)は, どのライブラリがリンクされているかを決めるために, 共有ライブラ リ番号を比較する際に, すべて無視されます. 「小さな」リビジョンだけが異なる二つの共有ライブラリが指定 されると, ld.so は, リビジョンの大きい方の共有ライブラリを リンクします. すなわち, もしあなたが libfoo.so.3.3.3 をリンク していたとすると, リンカは頭の 3.3 という部分だけを認識し, libfoo.so.3 ではじまり その後に 3 以上の数字が続くもののうち、 最も大きい番号の付いているライブラリをリンクします.

ld.so はいつも最も大きい「マイナー」リビジョンのものを使うことに 注意してください. 例えば, プログラムがはじめ libc.so.2.0 を リンクしていたとしても, libc.so.2.0 よりも libc.so.2.2 を優先 して使用します.

移植されていないライブラリに対しては, リリースごとに共有ライブラリの バージョン番号を一度だけ変更するのが私たちのポリシーです. あなたがシステムライブラリのバージョン番号を上げた場合は, Makefile の commit ログを確認してください. 結果としてそのリリースには, 共有ライブラリのバージョン番号が アップデートされた Makefile に入るので、最初にその変更を 確かめるのがソースツリー管理者 ("committer") の責務です. その後のどんな変更も, そのリリースには入りません. diff --git a/ja/handbook/porting.sgml b/ja/handbook/porting.sgml index c6a71c4310..076d7785ed 100644 --- a/ja/handbook/porting.sgml +++ b/ja/handbook/porting.sgml @@ -1,1379 +1,1379 @@ - + フリーソフトウェアの移植

原作: &a.jkh;, &a.gpalmer; &a.asami;. 7 November 1996.

訳: &a.simokawa;, &a.asami;. 10 November 1996.

フリーで手に入るソフトウェアを移植することは, 何かをゼロから自分で 作ることほどは人に感謝されないにしても, どこに手を入れれば動くのかわから ないような人でも使えるようにするという意味で, FreeBSDの発展のためにとて も重要なことです. 移植されたすべてのソフトウェアは「Portsコレク ション」(the Ports Collection) と呼ばれ, 階層的に分類されて集められ ています. これによって, 新しいユーザでも, 何がすぐに簡単にコンパイルで きる状態で手に入るのか, についての概要をつかむことができます. また, 移植されるソー スコードについては, そのほとんどを実際には含まず, FreeBSDで動かすためのほんのちょっ との差分ファイルといくつかの定義ファイルだけをソースツリーに入れることで, かなりのディスクスペースが節約できます.

これから, FreeBSD 2.x用のportを作る際の, いくつかのガイドラインを 説明します. 実際にportをコンパイルするときのほとんどの仕事は /usr/share/mk/bsd.port.mkというファイルでおこないます. Portsコレクションについてのさらに細かい内部の働きについては, そちらのファイルを 参照してください. 移植を始める前に

注意: ここでは, 変更可能な変数の一部についてのみ記述してい ます. ほとんどの変数はbsd.port.mkの始めに記述があり ます. また, このファイルは非標準のタブの設定になっていま す. Emacsはファイルのロード時にこれを認識しますが, viやexでは, ファイルをロードしたら `:set tabstop=4'のようにして正しい値を設定することがで きます.

Portの過程で, 修正や, どのバージョンのUNIXで動くかによる条件 つきコンパイルなどが必要なコードに出会うかもしれません. その ような条件つきコンパイルなどのための変更をおこなうときには, FreeBSD 1.x システムへの移植や, CSRGの4.4BSD, BSD/386, 386BSD, NetBSDなどの他のBSDシステムへの移植が可能なように, でき るだけ普遍的な変更をおこなうことを心がけてください.

4.3BSD/Renoおよびそれより新しいBSD版を古いバージョンと区別す るには `BSD' マクロを利用するのがよいでしょう. これは <sys/param.h>で定義されています. このファイルが すでにインクルードされていればよいのですが, もしそうでない場合 には以下のコードを, その.c ファイルの適当な場所に加 えて, MakefileのCFLAGSに-D_HAVE_PARAM_Hを加 えてください. #ifdef _HAVE_PARAM_H #include #endif そして, 次のようにしてそのコードが4.3 Net2コードベース, または それより新しいもの (例: FreeBSD 1.x, 4.3/Reno, NetBSD 0.9, 386BSD, BSD/386 1.1とそれ以前) の上でコンパイルされているかを検出できます. #if (defined(BSD) && (BSD >= 199103)) また, #if (defined(BSD) && (BSD >= 199306)) これは, 4.4コードベース, またはそれより新しいもの (例: FreeBSD 2.x, 4.4, NetBSD 1.0, BSD/386 2.0とそれ以後) の上でコンパイルさ れているかどうかを検出するために使用します.

以下は控え目に使ってください. __FreeBSD__ はFreeBSDのすべての版で定義されてい ます. 変更がFreeBSDだけに適用されるとき以外は使用しないでく ださい. Portでよくある, strerror() ではなく sys_errlist[] を使うなどは, FreeBSDでの変更ではなく, BSDの流儀です. FreeBSD 2.xでは__FreeBSD__が2と定義されていま す. それ以前の版では1になっています. もし, FreeBSD 1.xシステムとFreeBSD 2.xシステムを区別 する必要があれば, 上で述べたBSDマクロを使用するのが, 大抵の場合において正しい答です. もし, FreeBSD特有の変更であ れば (`ld' を使うときのシェアードライブラリ用のな オプションなど), __FreeBSD__を使い `#if __FreeBSD__ > 1' のようにFreeBSD 2.x システムを検出するのはかまいません. もし, 2.0-RELEASE以降のFreeBSDシステムを細かく検出したけれ ば, 以下を使用することができます. #if __FreeBSD__ >= 2 #include # if __FreeBSD_version >= 199504 /* 2.0.5+ release specific code here */ # endif #endif __FreeBSD_version の値は以下の通りです: 2.0-RELEASE: 199411 2.1-current's: 199501, 199503 2.0.5-RELEASE: 199504 2.2-current (2.1以前): 199508 2.1.0-RELEASE: 199511 2.2-current (2.1.5以前): 199512 2.1.5-RELEASE: 199607 2.2-current (2.1.6以前): 199608 2.1.6-RELEASE: 199612 2.2-RELEASE: 199701 3.0-current (1997年2月現在) 199702 (リリースが出る毎に変わります) 見ての通り, これは年・月というフォーマットになっています.

これまで, 何百ものportが作られてきましたが, __FreeBSD__が正しく使われたのは, 1つか2つの場合だけで しょう. 以前のportが誤った場所でそのマクロが使っているからと いって, それをまねする理由はありません. 3分porting

この節では, 簡単なportの方法について説明します. 多くの場合これ では不十分ですが, まあうまくいくかどうか試してみて損はないでしょ う.

まず, 元のtarファイルを${DISTDIR}に置きます. デフォルトは/usr/ports/distfilesです.

注: 以下では, ソフトウェアはそのままコンパイルされるとします. つまり, FreeBSDのマシンで動かすために, 変更がまったく必要ない とします. もしなにか変更が必要な場合には次の節も参照する必要 があります. Makefileの作成

最小限のMakefileは次のようなものです: # New ports collection makefile for: oneko # Version required: 1.1b # Date created: 5 December 1994 # Whom: asami # # $Id$ # DISTNAME= oneko-1.1b CATEGORIES= games MASTER_SITES= ftp://ftp.cs.columbia.edu/archives/X11R5/contrib/ MAINTAINER= asami@FreeBSD.ORG USE_IMAKE= yes .include

おわかりになりますでしょうか. $Id$があ る行の内容については, 気にしないでください. これはこのファイル がportsツリーに書き込まれるときにCVSによって自動的に書 き込まれます. もっと詳しい例が見たければ, の節をご覧ください. Package記述ファイルの作成

どのようなportでも, packageにするしないに関わらず, 3つ の記述ファイルが必要です. pkgサブディレクトリにある, COMMENT, DESCR, それにPLISTです. COMMENT

これには, そのportについての説明を1行で書きます. Package の名前, バージョン番号等は含めないでください. たとえば, こんな具合です: A cat chasing a mouse all over the screen DESCR

これは, そのソフトウェアについての, すこし長い説明を記述しま す. そのportが何をするのかについての数段落程度の簡潔な解説があれば 十分です. 注: このファイルはマニュアルでもなければ, 使用方 法やコンパイル方法についての細かい説明書ではありません. 特 に, READMEファイルを何も考えずにここにコピーするような ことはしないでください. (もちろん, READMEがそのソフトウ ェアの簡潔な説明になっている場合は別ですが.)

このファイルの最後にあなたの名前を書くことが推奨されています. たとえば, こんな具合です. This is a port of oneko, in which a cat chases a poor mouse all over the screen. : (うんぬん.) - Satoshi asami@cs.berkeley.edu PLIST

このファイルには, このportによってインストールされるファ イルが列挙されます. このファイルはpackageを作る際のリス トとして使われるため, `packing list' とも呼ばれます. ここ に書かれているファイル名は, インストール時のプレフィックス (普通は/usr/localか/usr/X11R6) からの 相対パスです.

簡単な例を載せておきましょう: bin/oneko man/man1/oneko.1.gz lib/X11/app-defaults/Oneko lib/X11/oneko/cat1.xpm lib/X11/oneko/cat2.xpm lib/X11/oneko/mouse.xpm

'Packing list'の詳細については, pkg_create(1)の マニュアルを参照してください. チェックサムファイルの作成

ただ, `make makesum' と入力するだけです. bsd.port.mkにルールがあるので, 自動的にfiles/md5が 生成されます. Portのテスト

そのportが正しく動くことを, package化を含めて確認してく ださい. まず, `make install', `make package' を試してください. また, `pkg_delete -d <pkgname>' をして,すべてのファイルが正しく消去さ れているかどうかを確認してください. それから, `pkg_add <pkgname>.tgz' をおこない, すべてのファイルが再び現 れ, 正しく動作することを確認してください. Portの送付

さあ, あなたのportに満足したら, あとはそれをFreeBSDのメイ ンのportsツリーに置いて, 皆に使ってもらうだけです. そのた めには, 必要なファイル (この節で述べたすべてのファイル -- た だし, オリジナルのソースファイル, `work' サブディレ クトリ, およびpackageは含みません) をまとめて .tar.gz ファイルにし, ftp://ftp.FreeBSD.ORG/pub/FreeBSD/incoming/ へ置き, send-pr(1) を使って私たちのところにメールを送っ てください (categoryは `ports', classは `change-request' を 使ってください). 私たちは, 何か不明な点があったらあなたに確 認したのち, それをツリーへ置きます. あなたの名前は, FreeBSD ハンドブックやその他のファイルの `Additional FreeBSD contributors' のリストにも載るでしょう. う〜ん, 素晴らし い. :) 本格的なport

残念ながら, 移植がそう簡単ではなく, 動かすために多少の変更が 必要な場合も多いでしょう. この節では, portsコレクション の方法論にのっとって, そのような場合にどのように変更を施し, 動 くようにしたらよいかを順を追って説明します. port構築の詳細

まず, あなたがportのディレクトリで `make' とタイ プしてから起こる一連の出来事について,順を追って説明しま す. ここを読むときには, 他のウィンドウで同時に bsd.port.mkも開いておくとよいかもしれません.

しかし, bsd.port.mkが何をしているのか, 完全に理解 できなくても心配する必要はありません. そう多くの人が理解して いるわけではないですから... f(^_^;) まず, fetchというターゲットが実行されます. このfetchターゲッ トはローカルディスクの${DISTDIR}に配布ファ イルがあるようにするのが役目です. もし, fetchが必要なファ イルを${DISTDIR}に見つけることができなけ れば, Makefileに指定されているURL ${MASTER_SITES}, そして私たちのFTPサイトで ある (ここ には, 私たちが取ってきたファイルをバックアップとして置いてあ ります) に探しにいきます. そして, ユーザのサイトがインター ネットに直接接続されている場合には, ${FETCH} を使って, その名前のファイルを取っ てきて, ${DISTDIR}に保存します. 次に実行されるのはextractターゲットです. これは, ${DISTDIR}にある, 配布ファイル (普通は gzipされたtarファイル) を読み, ソースを一時的な作業ディレ クトリ${WRKDIR} (デフォルトは work) に展開します. 次に, patchというターゲットが実行されます. まず, ${PATCHFILES}に定義されている, すべてのパッ チをあてます. 次にもし${PATCHDIR} (デフォ ルトはpatches サブディレクトリ) にパッチが存在す れば, これらをアルファベット順にあてます. 次に実行されるターゲットはconfigureです. これには, い ろいろな場合があります. もし存在すれば, scripts/configure が実行されます. もし, ${HAS_CONFIGURE} あるいは ${GNU_CONFIGURE} がセットされていれば, ${WRKSRC}/configure が実行されます. もし, ${USE_IMAKE} がセットされていれば, ${XMKMF} (デフォルト: `xmkmf -a') が実行されます. 最後に, buildというターゲットが実行されます. これは, そのport の専用の作業ディレクトリ (${WRKSRC}) にい き, コンパイルするのが役目です. もし ${USE_GMAKE} がセットされていれば, GNU makeが使用されます. さもなければFreeBSDの makeが使用されます.

上記はデフォルトのルールです. さらに, `pre-<何とか >や `post-<何とか>' というターゲット が定義してあったり, そのような名前のスクリプトが scripts サブディレクトリに置いてある場合には, それ らはデフォルトの動作の前後に実行されます.

たとえば, post-extractというターゲットがMakefile で定義されていて, pre-buildというファイルが, scriptsサブディレクトリにあるとすると, post-extractターゲットは, 通常の展開動作のあとに呼 び出され, pre-buildスクリプトはデフォルトのコンパイ ルのルールが実行される前に実行されます. もし動作が簡単であれ ば, Makefileのターゲットを使用することが推奨されています. な ぜならば, そのportが何らかのデフォルトではない動作を必要とす るのかどうかが一箇所にまとめて書いてあった方が他の人に理解しやす いからです.

デフォルトの動作はbsd.port.mk の `do-<何とか>' というターゲットでおこなわれます. たとえば, portを展開するコマンドは, `do-extract' というターゲットにあります. もし, デフォルトのターゲットに 不満があれば, `do-<something>' というターゲッ トを再定義することによって, どのようにでも直すことができます.

「メイン」のターゲット (例えば, extract, configure等) は, すべての前段階が実行されていること を確認して, 実際のターゲットやスクリプトを呼び出す以外のこと はしません. bsd.port.mkはこれらが変更されることは仮定してい ませんので, もし, 例えば, 展開の仕方を直したいときには, do-extract を直し, 絶対にextractには手を 触れないでください.

これで, ユーザが `make' と入力したときに何が起こ るのかが理解できたと思います. では, 完璧なportを手順を追っ て作ってみましょう. オリジナルのソースの入手

オリジナルのソースを, (普通は) 圧縮されたtarファイルの形 (<foo>.tar.gzあるいは <foo>.tar.Z) で入手して, それを ${DISTDIR} にコピーします. 可能なかぎり, 広 く使われている主流のソースを使用するようにしてください.

もし, ネットワークへの接続のよいFTP/HTTPサイトを見つけるこ とができなかったり, 頭にくるような非標準的な形式しか持ってい ないサイトしか見つけられないときには, 最後の手段として, 私たち 自身で, ftp://freefall.FreeBSD.ORG/pub/FreeBSD/LOCAL_PORTS/ に置くことができます. これについての問い合わせのメールは は &a.ports へお願いします.

もし, あなたのportに必要ないくつかの追加パッチがインター ネット上で手に入るのならば, それらも取ってきて, ${DISTDIR} に置きます. もし, それらがメイン のソースのtarファイルとは別のサイトにあっても, 心配する必要 はありません. そのような状況にはちゃんと対応できるようになっ ています. (以下のをご覧く ださい). Portの修正

適当なディレクトリにtarファイルを展開して, FreeBSDの最新の バージョン上で, 正しくコンパイルできるために必要なあらゆる変 更を施します. 最終的に処理は自動化するわけですから, 何をおこなっ たかを注意深く記録しておきましょう. あなたのport が完成した暁には, ファイルの削除, 追加, 修正を含むすべての処 理が, 自動化されたスクリプトやパッチファイルでおこなえるようになっ ていないといけません.

もし, あなたのportのコンパイルやインストールのために必要 な手作業があまりに多いようならば, Larry Wallの模範的な Configureスクリプトでも参考にしたほうがいいかもしれませ ん. 新しいportsコレクションは, 最小のディスクスペースで, 個々のportがエンドユーザにできるだけ「プラグ & プレ イ」の状態でmakeできることをめざしています.

注意: あなたが作成しFreeBSDのportsに寄付されたパッチファイル, スクリプトおよびその他のファイルは，明示的に記述されている場合 を除いては, BSDの標準的な著作権条件によりカバーされていると見な されます． パッチをあてる

portの過程で追加されたり変更されたファイルは再帰的diffで変 更点を取り出すことができます. パッチは適当にまとめて, `patch-<xx>' という名前のファイルに入れてくだ さい. <xx>はパッチが適用される順番を示します -- これらは, アルファベット順, つまり `aa' が 最初, つぎに `ab' などとなります. これらのファイル を${PATCHDIR}に置いておくと, 自動的に適用さ れるようになっています. すべてのパッチは ${WRKSRC} (通常は, portのtarファイルが展 開されるところで, makeが実行されるところと同じです) からの相 対パスになります. 修正やアップグレードを容易にするため, 2つ 以上のパッチが同じファイルを修正するのは避けてください. (例, patch-aaとpatch-abが共に${WRKSRC}/foobar.c を修正する, など.) コンフィグレーション

カスタマイズのために追加したいコマンドがあれば, configureという名前のスクリプトに入れて `scripts' サブディレクトリに置きます. 上で述べたよ うに, pre-configure あるいはpost-configure というMakefileのターゲットおよび/あるいはスクリプトで処理す ることもできます. ユーザからの入力の扱い

もし, そのportがビルド, コンフィグレーション, インストー ルの際にユーザからの入力を必要とするならば, Makefileで IS_INTERACTIVEをセットしてください. これによって, 深夜, 自動的にたくさんのportをコンパイルすることが可能にな ります. 環境変数BATCHがセットされていると IS_INTERACTIVEの定義されているportはスキップされ ます (そして, ユーザがINTERACTIVEという変数をセッ トすると入力を必要とするportのみコンパイルされま す). Makefileの作成

Makefileの作成は非常に単純です. 繰り返しになりますが, 始める まえに, すでにある例を見てみることをお奨めします. またこのハ ンドブックには があります. それを見て, Makefile内の変数の順番や空行を入れると ころなどの参考にしてください. そうすると他の人々にも読みやすい ものとなります.

では, Makefileをデザインするときに問題となるところを順に追っ て見てみましょう. オリジナルのソース

ソースは${DISTDIR}に, 標準的なgzipされた tarファイルとして置かれていますか? そうであれば, 次のステッ プに進めます. そうでなければ, 変数 ${EXTRACT_CMD}, ${EXTRACT_BEFORE_ARGS}, ${EXTRACT_AFTER_ARGS}, ${EXTRACT_SUFX}, ${DISTFILES}を適当に書き換えないといけません. どれだけ変更しないといけないかは, あなたのportの 配布ファイルがどの程度標準からかけはなれているかによりま す. (最もよくある場合は, gzipではなく普通のcompressコマンド でtarファイルが圧縮されている場合で, `EXTRACT_SUFX=.tar.Z' とするだけです.)

最悪の場合には, 自分で `do-extract' ターゲットを作 成して, デフォルトを上書きすることもできます. しかし, そこま でする必要があることはめったにないでしょう. DISTNAME

${DISTNAME}にはportの名前の基幹部分を入れ ます. デフォルトのルールでは, 配布ファイルのリスト (${DISTFILES}) は ${DISTNAME}${EXTRACT_SUFX}という名前 になっています. 例えば, `DISTNAME=foozolix-1.0'の場 合, 通常のtarファイルだと, foozolix-1.0.tar.gz のようになります. さらにデフォルトのルールでは, tarファイルは work/${DISTNAME}というサブディレクトリ に展開されることを仮定しています, 例えば work/foozolix-1.0/ といった具合いです. これらの動作はもちろんすべて変更可能です. デフォルトのルー ルは最も標準的な場合を仮定しているだけです. まず, portが複 数の配布ファイルを必要とするときには, 単に明示的に ${DISTFILES}を設定してください. もし, ${DISTFILES}の一部だけが実際に展開される場合 には, それらを${EXTRACT_ONLY} に設定してくだ さい. この変数が定義されている場合には, 展開時に ${DISTFILES}に優先して利用されます. 残りのファ イルも${DISTDIR}に取ってきますが, 展開時に はなにもせずに後で使うためにそのまま置いておかれます. CATEGORIES (分類)

完成したpackageの実体は/usr/ports/packages/All に置かれます. また, 1つかそれ以上の /usr/ports/packagesのサブディレクトリからのシンボリッ クリンクが作られます. それらのサブディレクトリの名前が ${CATEGORIES}という変数によって指定されます. これは, ユーザがFTPサイトやCD-ROMのpackageの山を渡り歩 くことを容易にするためです. 現在存在するカテゴリを見て, そ のportに適したもを選んでください. (などが参考になるでしょう). もしそのportが本当 に現在存在するすべてのものとは異なっている場合には, 新しいカテ ゴリ名を作ることもできます. MASTER_SITES

オリジナルの配布ファイルを指し示すFTPまたはHTTPのURLのディ レクトリ部分までを${MASTER_SITES}に記録しま す. スラッシュ (/) を最後につけることをお忘れなく.

配布ファイルがシステム上に存在しないときに, makeマクロは ${FETCH}でこの変数に指定されたサイトから取っ てきます.

複数の, できれば異なる大陸のサイトをこのリストに入れておく ことが推奨されています. これによって, 広域ネットワークにトラ ブルがあった場合でも成功する可能性が高くなります. 私たちはさら に, 自動的に最も近いマスタサイトを検出して, そこから取って くるメカニズムの導入を計画しています.

オリジナルのtar ファイルが, X-contrib, GNU, Perl CPAN, TeX CTAN または Linux Sunsite などの有名なアーカイブにある場合には, MASTER_SITE_XCONTRIB, MASTER_SITE_GNU, MASTER_SITE_PERL_CPAN, MASTER_SITE_TEX_CTAN および MASTER_SITE_SUNSITE を利用することで, 簡単にこれらのサイトを 指定することができます. あとは MASTER_SITE_SUBDIR にアーカイ ブ内でのパスを指定するだけです. 以下に例を示します. MASTER_SITES= ${MASTER_SITE_XCONTRIB} MASTER_SITE_SUBDIR= applications

ユーザは/etc/make.conf中で MASTER_SITE_* 変数を設定 することによって, デフォルトの FTP サイトではなく, これらの 有名なアーカイブのミラーの中で好みのものを使用することが可能 です. PATCHFILES

もし, オリジナルの配布ファイル以外にもFTPかHTTPで手に入る パッチが必要な場合には, ${PATCHFILES}にファ イル名を, ${PATCH_SITES}にサイトとディレクト リの名前を${MASTER_SITES}と同様に設定してく ださい.

そのパッチ内のファイル名ががソースツリーの一番上のディレク トリ (${WKRSRC}) からの相対パスになっていな い場合には, ${PATCH_DIST_STRIP}を指定してく ださい. 例えば, パッチ内のファイル名にすべて余計な `foozolix-1.0/' がついている場合には, `PATCH_DIST_STRIP=-p1'としてください.

これらのパッチは圧縮されていても大丈夫です. ファイル名が `.gz' か `.Z' で終わる場合には自動的に復元 されるようになっています.

もしパッチが, 文書などその他のファイルと一緒にgzipされた tarファイルで配布されている場合には，単純に ${PATCHFILES} を使うことはできません. このような場合には, このパッチの tar ファイルの名前と場所を ${DISTFILES} と ${MASTER_SITES} に加えます. それから, pre-patch ターゲットで, パッチコマンドを走らせるか, パッチファイルを ${PATCHDIR} ディレクトリに patch-<xx>という名前でコピーするかして, パッチを適用するようにします．(普通の gzip か compress された tar ファイルであれば，通常のソースファイルと一緒にその時までに 展開されていますので，明示的に展開する必要はありません．) もし，後者の方法を使用する場合には，すでにそのディレクトリにある なにかを上書きしないように, 注意する必要があります. さらに, pre-clean ターゲットにコピーしたパッチファイル を削除するコマンドを追加するのを忘れないでください. MAINTAINER

あなたのメールアドレスをここに入れてください. お願いします. :)

保守担当者(maintainer)の責任についての詳細は， の節をご覧ください． 依存関係

このプログラムが他のportに依存する場合には, 必要なものが 自動的に作られるようにすることができます. そのために, 以下の 5つの変数が用意されています. LIB_DEPENDS

Portが必要とする非標準の共有ライブラリをこの変数で指定 します. これは `lib:dir' という組のリストで, うち lib が共有ライブラリの名前, そしてdir がそのライブラリが見つからない場合にインストールするport のあるディレクトリです. 例えば, LIB_DEPENDS= jpeg\\.6\\.:${PORTSDIR}/graphics/jpeg と指定してあれば, まずメジャーバージョンが6のjpegライブ ラリがあるかどうか確認し, ない場合にはportsツリーの中の graphics/jpeg というサブディレクトリに移動し, そこ からインストールしようとします. 前半のlib 部分はそのまま `ldconfig -r | grep' へ引数として渡されることに注意してください. 特 に, ピリオド (.) の前には上記の例のようにバックスラッシュ を連続してつける必要があります. この依存関係はextract ステージのはじめでチェック されます. また, packageを作るときに必要となるportのpackage名 が記録され, pkg_addを使用すると自動的にそちら のpackageもインストールされるようになります. RUN_DEPENDS

Portを使用する際に必要となるファイルまたはプログラムがある ときにはこの変数で指定します. これは`path:dir' とい う組のリストで, path がファイルまたはプログラムの 名前, そしてdir がそれが見つからない場合に作成する ためのディレクトリ名です. Path の最初の文字がスラッ シュ (/) の場合にはファイルとみなし, その存在を `test -e' でチェックします; そうでない場合にはプ ログラムであると仮定し, `which -s' を使ってそのプ ログラムがユーザのサーチパス上にあるかどうか確認します.

例えばMakefileに以下のように書いてあるとします. RUN_DEPENDS= ${PREFIX}/etc/innd:${PORTSDIR}/news/inn \ wish:${PORTSDIR}/x11/tk まず, `/usr/local/etc/innd' というファイルが存在 するか確認し, ない場合にはportsツリーの中の news/inn というサブディレクトリから作られます. ま た, `wish' というプログラムがユーザのサーチパス中 にあるかどうか探し, ない場合には同じくportsツリーの x11/tk というサブディレクトリから作られます. (この例で, `innd' は実際にはプログラムです; この ように, プログラムであっても標準のサーチパス以外のところに あるようなものの場合には, 絶対パスで指定してください.) この依存関係はinstall ステージのはじめでチェック されます. また, packageを作る際に必要となるportのpackage名 が記録され, pkg_addを使用すると自動的にそちら のpackageもインストールされるようになります. BUILD_DEPENDS

Portのコンパイルに必要なファイルまたはプログラムがある ときは, この変数で指定してください. RUN_DEPENDSと同 様に, これは `path:dir' という組のリストです. 例 えば, BUILD_DEPENDS= unzip:${PORTSDIR}/archivers/unzip は `unzip' という名前のプログラムを探し, 見つから ない場合にはarchivers/unzip サブディレクトリで作 れという意味になります. ここでは「コンパイル」と一口にいいましたが, この変数は実際 にはファイルの展開から実際のコンパイル・リンクまで全部をま とめて面倒を見てくれます. この依存関係はextract ステージからチェックされます. FETCH_DEPENDS

この変数は, portを取ってくるのに必要なファイルまたはプロ グラムを指定するのに使います. 上の二つと同様に, これは `path:dir' という組のリストです. 例えば, FETCH_DEPENDS= ncftp2:${PORTSDIR}/net/ncftp2 としておけば, `ncftp2' という名前のプログラムを探 し, 見つからない場合にはnet/ncftp2 サブディレク トリにいってインストールします. この依存関係はfetchステージからチェックされます. DEPENDS

上の四つのいずれにもあてはまらないような依存関係がある場 合, または他のportのソースが展開されている必要がある場合 (インストールされているだけでは不十分な場合) にはこの変数 を使います. これはディレクトリ名のリストです (上の四つと違っ て特に「確認」するものがありませんので). コンパイル時の特別な指定

GNUのmakeを使う場合には, `USE_GMAKE=yes' と指定してください. PortにGNUのconfigureが含まれ ている場合には, `GNU_CONFIGURE=yes' を使います. GNU configureにデフォルトの `--prefix=${PREFIX}' 以外の引数を渡したい場 合には追加部分を${CONFIGURE_ARGS}で指定して ください.

X Window Systemのアプリケーションなど, imakeを 使ってImakefileからMakefileを作成するportの場合には `USE_IMAKE=yes' を指定してください. コンフィグレー ションステージで自動的にxmkmf -a が実行されます. も し `-a' フラグが問題をもたらすなら, さらに `XMKMF=xmkmf'としてください.

PortのMakefileが `all' 以外のものをメインのター ゲットとしている場合には, ${ALL_TARGET} でそ れを指定してください. `install' と ${INSTALL_TARGET} も同様です. NO_INSTALL_MANPAGES

あなたのportがimakeは使うものの `install.man' ターゲットを持っていない場合, `NO_INSTALL_MANPAGES=yes' を指定してください. つい でに, 作者を探し出して八つ裂きにするといいでしょ う. (-_-#) Motifを必要とするport

最近はコンパイルにMotifを必要とするアプリケーションが増えて きました. (Motif自体は有料のものがいくつかの会社から手に入りま すし, 無料の互換ライブラリを作ろうとしているグループが少なくと も一つあります.) Motifはかなり広く使われていますし, 製品のライ センスではライブラリを静的にリンクした実行形式は再配布が認めら れている場合が多いので, Motifを必要とするソフトウェアを簡単に 動的/静的にリンクできるようなしくみが用意されています. REQUIRES_MOTIF

MotifがないとコンパイルできないportのMakefileではこの変 数を指定してください. これによって, Motifを持っていない人が このportをコンパイルしようとするのを未然に防ぎます. ${MOTIFLIB}

この変数はbsd.port.mkによってMotifライブラリの指 定に置き換えられます. ソース内のMakefileやImakefileで Motifライブラリを指定しているところをこの変数に置き換えるよ うにパッチをあててください.

代表的な例としては以下の二つがあげられます: MakefileかImakefileの中でMotifライブラリが `-lXm' として使われている場合には, かわりに `${MOTIFLIB}' と書いてください. Imakefileの中で `XmClientLibs' が使われている 場合には, それを `${MOTIFLIB} ${XTOOLLIB} ${XLIB}' と書きかえてください.

${MOTIFLIB} は通常 `-L/usr/X11R6/lib -lXm' か `/usr/X11R6/lib/libXm.a' に置き換えら れます. したがって前に `-L' や `-l' をつけ る必要はありません. ライセンス上の問題

ソフトウェアによっては制限の厳しいライセンスがついてきたり, 法律的に問題があるものがあります (PKPの公開鍵暗号化, ITAR (暗 号化ソフトウェアの輸出) などが例としてあげられます). それらを どう扱えばいいかはライセンスの文面によってさまざまな場合があり ます.

ソフトウェア移植者として, あなたにはライセンスをよく読み, FreeBSDプロジェクトがFTPまたはCD-ROMで配布してはいけないソフ トウェアを配布してしまうことのないよう, 注意する義務があります. なにか疑問がある場合には, &a.ports;に聞いてみてください.

よく見られるケースに対処するために, 二つの変数が用意されてい ます: ソフトウェアに「有償再配布を禁ずる」という趣旨のライセン スがついてきた場合にはNO_CDROMという変数をセットして ください. 私たちはこれがついているportはCD-ROMリリースに入 れないようにしますが, オリジナルのソースファイルとpackage はFTPでは取れるようにしておきます. もしも, 生成される package が個々のサイトで独自に構築さ れる必要があったり, ライセンスによって生成されるバイナリが 配布できない場合には, NO_PACKAGE 変数を設定してくだ さい. そのような package が FTP サイトに置かれたり, リリース 時の CD-ROM へ入らないようにします. ただし, いずれの場合も distfile は(FTP や CD-ROM に)含まれるようになります. Portが, 使用者によっては法律上の問題が生じる時 (暗号化ソフ トウェアなど), または「商用利用を禁ずる」とライセンスに書い てある場合にはRESTRICTEDという変数にその理由を入れ てください. この場合には, ソースファイルやpackageは私たちの FTPサイトにも置かれません.

注: GNU一般公有使用許諾書 (GPL) はバージョン1, 2とも port作成上は何ら問題にはなりません.

注: もしあなたが，ソースツリー管理者 (committer) であれば， ソースツリーにこのようなportを入れる際に, ports/LEGALファイルを書き換えるのを忘れないようにし てください. アップグレード

Portのバージョンが原作者からのものに比べて古いことに気がつ いたら, まずはあなたの持っているportが私たちの最新のもの (ミラー サイトのports-currentというディレクトリにあります) であることを確認してください.

次に, portのMakefileにMAINTAINER (保守担当者) の アドレスが書いてある場合には, その人にメールを出してみましょう. 保守担当者の人がすでにアップグレードの準備をしているかもしれま せんし, (新しいバージョンの安定度に問題があるなど) あえてアッ プグレードをしない理由があるのかもしれません.

保守担当者にアップグレードをしてくれと頼まれた場合, あるいは そもそもportのMakefileに保守担当者が書いてない場合などは, あ なたがアップグレードをしてくださると助かります. その場合にはアッ プグレードをしたのち, 変更前と変更後のディレクトリの再帰的diff をとって送ってください. (例えば, 変更前のディレクトリが `superedit.bak' という名前でとってあり, 変更後のもの が `superedit' に入っているなら, `diff -ru superedit.bak superedit' の結果を送ってください. ) もし変 更点が多すぎて, パッチが新しいport全体より大きくなる場合には, 前に述べた手順にしたがって新しいport全体をしてください. いず れの場合にも, send-pr(1) を使ってメールを送るのを忘れ ないようにしてください. やっていいことといけないこと

この節では, ソフトウェアをportする上でよくある落し穴などにつ いて説明します. WRKDIR

大事なファイルをworkサブディレクトリに置き忘れな いようにしてください. うっかり `make clean' とやっ たらこのディレクトリはその下のファイルとともにあとかたも なく消え去ってしまいます! スクリプトやパッチ以外に必要 なファイルがある場合には, filesというサブディレクト リに入れ, post-extractターゲットでworkサ ブディレクトリにコピーするようにしてください. Package情報

Package情報, すなわちpkgディレクトリ内の三つ のファイルは必ず用意してください. これらはpackageを作る以 外にもいろいろ使われていますので, ${NO_PACKAGE}が指定してあってpackageを作 るのが禁止してあるportの場合でも必ず必要です. マニュアルの圧縮, バイナリのstrip

マニュアルは圧縮し, バイナリはstripしてください. オリジナル のソースがバイナリを stripしてくれる場合は良いですが, そうでない場合には post-installターゲットを指定して strip するようにするとよいでしょう. 例えば, こんな風になりま す: post-install: strip ${PREFIX}/bin/xdl

インストールされた実行形式がすでにstripされているかどうか はfileコマンドで確認できます. これが`not stripped' と言わなければ, stripされているということです.

MAN[1-9LN] 変数を使用すると, マニュアルの圧縮を自動的に行う ことができます. この方法を使うと, ユーザが /etc/make.conf中でNOMANCOMPRESSを設定し, マニュアルの圧縮を無効にしているかどうかを確認できます. これらの変数の指定は, MAINTAINER の指定の後 のセクションの一番最後で行ってください. こんな風に指定します: MAN1= foo.1 bar.1 MAN5= foo.conf.5 MAN8= baz.8

なお, 普通 Imake を使ってコンパイルされる X アプリケーショ ンの場合はこの指定は必要ありません.

PREFIX以外のディレクトリの下にマニュアルを置く ようなportではMANPREFIXを指定することが できます. さらに, 特定のセクションのマニュアルだけ, 標準では ない場所にインストールする場合(例えば多くの Perl のモ ジュールの ports の場合)には, 個々のマニュアルのパスを MANsectPREFIX (sectは, 1 から 9 または, L か N を表わします) によって指定できます. INSTALL_* マクロ

あなた自身の *-install ターゲットでファイルの正しいモードと オーナを保証するために, 必ずbsd.port.mkで提供されて いるマクロを使用してください. マクロは以下のようなものがあります. ${INSTALL_PROGRAM} は実行可能なバイナリを インストールするコマンドです． ${INSTALL_SCRIPT} は実行可能なスクリプトを インストールするコマンドです． ${INSTALL_DATA} は共有可能なデータを インストールするコマンドです． ${INSTALL_MAN} はマニュアルを インストールするコマンドです．(圧縮をしません)

これらは基本的にinstallコマンドに適当なフラグを与え たものです. どのようにこれらを使用するかは以下の例を見てください. INSTALL package スクリプト

バイナリパッケージが pkg_add でインストールされるときに, 実行 される必要があるコマンドがあれば, pkg/INSTALL スクリプトを使っ て実行することができます. このスクリプトは自動的に package に加えられ, pkg_add によって2度実行されます. はじめは `INSTALL ${PKGNAME} PRE-INSTALL' と実行され, 2度目 には, '`INSTALL ${PKGNAME} POST-INSTALL' と実行され ます. どちらのモードで実行されているかは, `$2' を調べることによってわかります. 環境変数 `PKG_PREFIX' には package がインストールさ れる directory が設定されます. 詳細は man pkg_add(1) を見てください. 注意すべきことは, port を `make install' で インストールするときには, このスクリプトは自動的に実行されな いということです. もし, 実行される必要があるならば, port の Makefile で明示的に呼ぶ必要があります. REQ package スクリプト

パッケージが(インストールされるシステムの状態によって) インストールされるべきか, されないべきか区別する必要があると きには, 「要件(requirements)」スクリプト pkg/REQ を作ること ができます. これは, インストール及びデインストール (package の削除)の時に自動的に実行され, それらが処理されるべ きかを決定します. 詳細は, man pkg_create(1) と man pkg_add(1) を見てください. 付加的ドキュメント

普通のマニュアルやinfoファイルのほかにユーザにとって有用だ と思えるようなドキュメントがある場合には, ${PREFIX}/share/docの下にインストールしてく ださい. これは前記と同様, post-installターゲットの 中からするのがいいでしょう.

まず, あなたのportのために新しいディレクトリを作りま す. どのportのドキュメントか簡単にわかるような名前にする必 要がありますので, 普通は${PKGNAME}からバージョ ン番号を除いた部分を使うといいでしょう. もちろん, ユーザが異 なるバージョンのものを同時に使うことが予想されるportの場合 には, ${PKGNAME}をそのまま使ってかまいません.

ユーザが/etc/make.confでこの部分を禁止するために NOPORTDOCSという変数をセットしている場合には， これらのドキュメントがインストールされないようにしてください. こんな具合です. post-install: .if !defined(NOPORTDOCS) ${MKDIR} -p ${PREFIX}/share/doc/xv ${INSTALL_DATA} ${WRKSRC}/docs/xvdocs.ps ${PREFIX}/share/doc/xv .endif

これらのファイルをpkg/PLISTに入れるのを忘れないよ うにしてください. (packageが/etc/make.conf内の 変数を読む方法は今のところ存在しませんので, NOPORTDOCSについては気にしないでください.)

(Packageの)インストールを行っているユーザに対してメッセージ を表示したい場合には, そのメッセージを pkg/MESSAGE に置くこともできます. この機能は, pkg_add したあとの 追加のインストール手順や, ライセンス情報を表示するのに便利で す. (注意: MESSAGE ファイルは pkg/PLIST に加える必要はありま せん. DIST_SUBDIR

/usr/ports/distfilesディレクトリ内をあまり散らかさ ないようにしてください. たくさんのファイルを取ってくるport や, 数は少なくてもほかのportのファイルと混同されるおそれが あるファイル (`Makefile' など) がある場合には, ${DIST_SUBDIR}にportの名前 (${PKGNAME}からバージョン番号を取った部分を 使うといいでしょう) を入れてください. すると, ${DISTDIR}がデフォルトの /usr/ports/distfilesから /usr/ports/distfiles/${DIST_SUBDIR}に変更さ れ, 取ってきたファイルはすべてそのサブディレクトリの中に置か れるようになります.

また, ファイルを取ってくるときにバックアップサイトとして使わ れるftp.freebsd.orgのディレクトリ名にもこの変数の 値が使われます. (${DISTDIR}を明示的に指定し た場合には, ローカルのファイルを置くところは変わりますが, こ のサイトのディレクトリ名は変わりませんので, 必ず ${DIST_SUBDIR}を使うようにしてください.)

この変数はMakefile中で明示的に指定された ${MASTER_SITES}には影響しないことに注意して ください. フィードバック

Portを作るためにソフトウェアに変更を加えたら, なるべく原 作者にその旨を伝えてパッチ等を送ってください. これらが次のリ リースに取り入れられれば, アップグレードが楽になります. RCS文字列

RCSが特別な意味を与えている文字列をパッチ内に入れないように してください. ファイルを私たちのソースツリーに入れる時にこれら の文字列はCVSによって書き換えられてしまい, あとでまたパッチ を使おうとした時にうまくいかないことがあります. RCS文字列は ドル記号 (`$') で囲まれており, `$Id' や `$RCS' などで始まり ます. パッチ作成上の注意

diffの再帰 (`-r') フラグを使って再帰的なパッ チを作るのは大変結構なのですが, でき上がったパッチは必ず目で チェックして余計なゴミが入っていないことを確認してくださ い. よくあるのはバックアップファイル同士の変更点, あるいは imakeやGNU configureを使うソフトウェアのMakefileの変更点が 入っている場合などです. また, ファイルをまるごと消す場合には パッチを使わずにpost-extractターゲットで消す方が簡 単です. PREFIX

なるべくportは${PREFIX}に対する相対パス にインストールすることができるように心がけてください. この変数の値は${USE_IMAKE}か ${USE_X11}が指定してある時には ${X11BASE} (デフォルト/usr/X11R6), そうでない場合には${LOCALBASE} (デフォルト/usr/local) にセットされます.

サイトによってフリーソフトウェアがインストールされる場所が 違いますので, ソース内で `/usr/local' や `/usr/X11R6' を明示的に書かないようにしてくださ い. Xのプログラムでimakeを使うものについては, これは問題に はなりません. それ以外の場合には, ソース中のMakefileやスク リプトで `/usr/local' (imakeを使わないXのプログラ ムは `/usr/X11R6') と書いてあるところを `${PREFIX}' に書き換えてください. この値は portのコンパイル, およびインストール時に自動的に環境変数として 下位makeに渡されます.

変数${PREFIX}の値はportのMakefileやユー ザの環境で変更することもできます. しかし, 個々のportが Makefileでこの変数の値を明示的に設定することはなるべくしない でください. (X のプログラムでimakeを使用しないport の場合は, USE_X11=yesとしてください; これは PREFIX=/usr/X11R6とするのとはかなり違います.)

また, 他のportからインストールされるプログラムやファイル を指定するときには, 上で述べた変数を使用してください. 例えば, lessのフルパスをPAGERというマクロに入れた い場合は, コンパイラに -DPAGER=\"/usr/local/bin/less\"と渡すかわりに -DPAGER=\"${PREFIX}/bin/less\" (Xを使う portの時は -DPAGER=\"${LOCALBASE}/bin/less\") を渡し てください. こうしておけば, `/usr/local' がまるごとどこか他 の場所に移してあるサイトでも, あなたのportがそのまま使える 可能性が高くなります. ディレクトリ構成

インストール時には${PREFIX}の正しいサブディ レクトリにファイルを置くように心がけてください. ソフトウェア によっては新しいディレクトリを一つ作ってファイルを全部それに 入れてしまうものがありますが, それはよくありません. また, バ イナリ, ヘッダファイルとマニュアル以外のすべてを `lib'というディレクトリに入れてしまうportもあります が, これもBSD的なファイルシステム構成からいうと正しくありま せん. これは以下のように分散すべきです. `etc' にセッ トアップ/コンフィグレーションファイル, `libexec' に 内部で使用されるプログラム (コマンドラインから呼ばれることの ないコマンド), `sbin' に管理者用のコマンド, `info' に GNU Info 用のドキュメント, そして `share' にアーキテクチャに依存しないファイルが入り ます. 詳細については man hier(7) を見てくださ い. /usrの構成方針はほとんどそのまま /usr/localにもあてはまります. ldconfig

共有ライブラリをインストールするときには, 共有ライブラリのキャッ シュを更新するためにportのMakefileのpost-install target から`/sbin/ldconfig -m' を走らせてください. このコマンドの引数は共有ライブラリのインストールしてあるディ レクトリ (通常 ${PREFIX}/lib) です.

また, pkg/PLISTに@exec行を入れ, package をインストールした場合にも共有ライブラリがすぐ使えるように してください. この行は共有ライブラリを指定する行のすぐ後に書 くのがいいでしょう: lib/libtcl.so.7.3 @exec /sbin/ldconfig -m %D/lib

絶対に引数なしでただ `ldconfig'とだけ書い てある行をMakefileやpkg/PLISTファイルに入れないでください. このコマンドを実行すると, 共有ライブラリのキャッシュが /usr/libの内容のみとなり, ユーザのマシンにさまざま な問題をもたらします (「ぎゃぁ! このportをインストールした らxinitが使えなくなっちゃった!」). この掟を破った者は, 永久 に地獄の底で苦しみ続けるように, 閻魔様に頼んでおきます. 困ったら....

私たちに質問を送る前に, 既存のportの例とbsd.port.mkを ちゃんと読んでください! ;)

それでもわからないことがあったら, 一人で悩まないでどんどん 質問してください! :) Makefileのお手本

これはportのMakefileを作る際のお手本です. かぎかっこ ([])内のコメントは忘れずに取ってください.

変数の順番, 段落の間の空行など, Makefileを作るときはなるべくこ の形式にしたがってください. 既存のportのMakefileがすべてこの形 式にしたがっているわけではありませんが, 今後はなるべく統一していき たいと考えています. この形式は重要な情報が簡単に見つけられるよ うに設計されています. [ヘッダ -- どのようなportのMakefileかすぐにわかるようになっています] # New ports collection makefile for: xdvi # Version required: pl18 ["1.5alpha" みたいなのでも結構です] # Date created: 26 May 1995 [これはこのソフトウェアを最初にFreeBSDにportした人の名前, つまり, このMakefileを書いた人です] # Whom: Satoshi Asami # # $Id$ [ ^^^^ この部分は, CVS ツリーに入れる時に自動的に RCS の ID 文字列に 置き換えられます.] # [Port自体, およびオリジナルのソースを取ってくるところを記述する部分. 最初は必ずDISTNAME, そして必要ならPKGNAME, CATEGORIES, 続いて MASTER_SITESがおかれ, さらに MASTER_SITE_SUBDIR がおかれることもあり ます. そのあと, EXTRACT_SUFX か DISTFILES を指定することも可能です] DISTNAME= xdvi PKGNAME= xdvi-pl18 CATEGORIES= print [最後のスラッシュを忘れないように ("/")!] MASTER_SITES= ${MASTER_SITE_XCONTRIB} MASTER_SITE_SUBDIR= applications [ソースファイルが標準の ".tar.gz" 形式でない時にこれを使いましょう] EXTRACT_SUFX= .tar.Z [配布パッチのセクション -- ない場合もあります] PATCH_SITES= ftp://ftp.sra.co.jp/pub/X11/japanese/ PATCHFILES= xdvi-18.patch1.gz xdvi-18.patch2.gz [保守責任者 -- これは *必ず* 必要です. 担当者 (あなた) 自身, あるいは 担当者に素早く連絡をとれる人のアドレスを書いてください. どうしてもこ こに自分のアドレスを書くのがいやな人は "ports@FreeBSD.ORG" と書いて もいいです] MAINTAINER= asami@FreeBSD.ORG [依存するport -- ない場合もあります] RUN_DEPENDS= gs:${PORTSDIR}/print/ghostscript LIB_DEPENDS= Xpm\\.4\\.:${PORTSDIR}/graphics/xpm [ここには標準のbsd.port.mkの変数で, 上のどれにもあてはまらないものを 書きます] [コンフィグレーション, コンパイル, インストールなどの時に質問をする なら...] IS_INTERACTIVE=yes [${DISTNAME}以外のディレクトリにソースが展開されるなら...] WRKSRC= ${WRKDIR}/xdvi-new [配布されているパッチが ${WRKSRC} に対する相対パスで作られてい ない場合にこの変数の指定が必要かも...] PATCH_DIST_STRIP= -p1 [GNU autoconfによって生成された "configure" スクリプトを走らせたいなら...] GNU_CONFIGURE= yes [/usr/bin/makeでなく, GNU makeを使わないといけないなら...] USE_GMAKE= yes [これがXのアプリケーションで "xmkmf -a" を走らせたいなら...] USE_IMAKE= yes [などなど] [下の方のルールで使う非標準の変数] MY_FAVORITE_RESPONSE= "yeah, right" [そして, 特別なターゲット, 使用順に] pre-fetch: i go fetch something, yeah post-patch: i need to do something after patch, great pre-install: and then some more stuff before installing, wow [最後には必ず] .include Packageの名前

Packageの名前は以下のルールにしたがってつけてください. こ れはpackageのディレクトリを見やすくするためで, 無秩序な名前 がたくさん並んでいるとユーザが使いづらくなるのではという心配か らです. (FTPサイトなどにはたくさんpackageがありますからね.)

Packageの名前は以下のようにしてください. [<言語>-]<名前>[[-]<オプション>]-<バージョン.番号>; ${DISTNAME} が上記の形式になっていない場合に は, ${PKGNAME} をそのようにしてください. FreeBSDはユーザの慣れ親しんだ言語のサポートに力を入れて います. 特定の言語のためのportのpackage名には `<言語>' に言語名の略称を入れてください. 例えば, 日本 語なら `jp', ロシア語なら `ru' といった具合です. `<名前>' の部分は原則的にはすべて英小文字 を使います. 例外はたくさんのプログラムが入っている巨大なport の場合で, XFree86 (ほんとにあるんですよ) やImageMagickな どがこれにあたります. そうでない場合には, 名前の大文字を小文 字に (少なくとも最初の一字だけは) 変えてください. また, その ソフトウェアの名前として通常使われるものに番号, ハイフン, あ るいは下線が入っている場合には, それらを使うことも構いません (`kinput2' など). コンパイル時に環境変数やmakeの引数などでいくつ か別のオプションをつけてコンパイルできる場合, `<compiled.specifics>' にそのオプションを入れてくださ い (ハイフンはあってもなくてもかまいません). 用紙のサイズ, あるいはフォントの解像度などがこれにあたります. バージョン番号は数字とアルファベットからなり, ピリオド (.) で区切ります. アルファベットは二文字以上続けてはいけませ ん. ただ一つの例外は「パッチレベル」を意味する `pl' で, それ 以外にバージョン番号がまったくついていない場合にのみ使うことがで きます.

では, ${DISTNAME}を正しい ${PKGNAME}に直す例を見てみましょう: DISTNAME PKGNAME 理由 mule-2.2.2 mule-2.2.2 まったく問題なし XFree86-3.1.2 XFree86-3.1.2 同上 EmiClock-1.0.2 emiclock-1.0.2 プログラム一つだけの時は小文字のみ gmod1.4 gmod-1.4 `<名前>' のあとにハイフンが必要 xmris.4.02 xmris-4.02 同上 rdist-1.3alpha rdist-1.3a `alpha'のような文字列は使えない es-0.9-beta1 es-0.9b1 同上 v3.3beta021.src tiff-3.3 なんなんでしょう ;) tvtwm tvtwm-pl11 バージョン番号は必ず必要 piewm piewm-1.0 同上 xvgr-2.10pl1 xvgr-2.10.1 `pl' が使えるのは他にバージョン番号がない場合のみ gawk-2.15.6 jp-gawk-2.15.6 日本語バージョン psutils-1.13 psutils-letter-1.13 コンパイル時に用紙のサイズを指定 pkfonts pkfonts300-1.0 300dpiフォント用のpackage

オリジナルのソースにまったくバージョン情報が見当たらず, また原作 者が新しいバージョンをリリースする可能性が低いときには, バージョ ン番号として `1.0' を使えばいいでしょう (上記のpiewmの例がこ れにあたります). そうでない場合には, 原作者に聞くか, 日付 (`年. 月.日') を使うなどしてください. やっとおしまい!

いやはや, 長い文章ですみません. ここまで読んでくださった方に は感謝, 感謝でございます. (_ _)

さあ, portの作り方がわかったところで, 世界中のソフトウェア をport化しましょう. FreeBSDプロジェクトに貢献するには, それ がもっとも簡単な方法です! :) diff --git a/ja/handbook/ports.sgml b/ja/handbook/ports.sgml index 9db8149d69..3d8ce8fce5 100644 --- a/ja/handbook/ports.sgml +++ b/ja/handbook/ports.sgml @@ -1,859 +1,859 @@ - + ports コレクション

原作: &a.jraynard;.

訳: &a.masaki;, &a.saeki;. 11 November 1996. FreeBSD の ports コレクションを利用すると, 最小限の労力で 非常に幅広くのアプリケーションのコンパイルとインストールがおこなえます.

やってみたことのある方はよくご存知でしょうが, オープンな規格とは 全くの誇大広告であって, あるプログラムを異なるバージョンの Unix 上で 動作させることは退屈で手間のかかる仕事です. 求めているプログラムが自分のシステムでうまくコンパイルでき, 正しいところにインストールできて, 完璧に動作するとしたらとてもラッキーです. しかし, あいにくこれは滅多にないことなのです. ほとんどのプログラムについて, あなたは髪を掻きむしることになるでしょうし, かなりのプログラムでは, 白髪混じりの頭になってしまったり, あるいは慢性の 脱毛症にすら なってしまうかもしれません...

いくつかのソフトウェアディストリビューションでは, 設定用のスクリプトを 配布することでこの問題を解決しようとしています. これらのスクリプトの中には非常に精巧なものもありますが, 残念ながら, 中にはこれまで聞いたこともないようなシステムの名前をしゃあしゃあと 言い放ったうえに, まるでシステムレベルの Unix プログラミングに関する 最終試験のような, たくさんの質問をしてくる場合があります. (例えば, 「このシステムの gethitlist 関数は fromboz への const ポインタを 返しますか? それとも const fromboz へのポインタを返しますか?」, 「このシステムには Foonix スタイルの, 容認できない例外処理をおこなう ルーチンがありますか? もしもないとしたら, それはなぜですか?」)

幸いなことに, ports コレクションがあれば, これらのきつい作業はすべて 完了しています. 'make install' とタイプするだけで, 動作するプログラムを 入手することができるのです. なぜ ports コレクションを作ったのか?

FreeBSD の基本システムは, 非常に多くのツールやユーティリティから 構成されています. しかし, よく使われるプログラムのうち多くのものが, この基本システムには含まれていません. その理由は:- 「私は x と y と z のプログラムがシステムにないと生きていけない」と いう類のプログラム (例えば Lisp ベースのエディタや DOS フロッピーを扱うための mtools など) は, 人によって全然違うから. (Emacs に我慢ならないという人や, DOS フロッピーをまったく使わないという人も大勢いるのです. そういう人は Emacs や mtools が基本システムに含まれていなくても何の問題もないでしょう.) 基本システムに組み込むには特殊すぎるから. (CAD やデータベースなど) 「時間があったら, ちょっと見てみようかな」というような類の, それがシステムに含まれていないことが致命的とは言えないプログラムだから. (おそらく, 何らかの言語などでしょう.) お楽しみのためのプログラムは, FreeBSD のような真面目な オペレーティングシステムといっしょに配布するべきではないから. ;-) たくさんのプログラムを基本システムに組み込んだとしても, もっともっと 組み込みたいという要求が出てくるので, どこかで制限を引かなくてはならないため. (そうしなければ FreeBSD の配布物は, とてつもなく膨大になってしまうでしょう.)

すべての人が自分のお気に入りのプログラムを手作業で移植しなければ ならないとしたら, (途方もない膨大な作業の繰り返しをさておいたとしても) それは明らかに不合理な話です. そこで, FreeBSD プロジェクトでは, 標準のツールを使って移植のプロセスを 自動化する巧妙な方法を考え出しました.

なお, これは単純ながら非常に柔軟なツールを組み合わせることで, 非常に強力な働きをさせるという「Unix 流」の作業の優れた実例です. ports コレクションはどのように動くのでしょうか?

インターネットでは通常, の形で プログラムが配布されています. これは, Makefile とソースコードで構成され, 普通は何らかの説明書 (あいにく, いつもわかりやすく書かれているとは 限りませんが) が付属しています. ことによるとコンフィグレーションスクリプトも含まれているかもしれません.

標準的な手順では, FTP で tarball を入手して, 適当なディレクトリで展開します. 次に説明書を読んで, 必要な変更をおこないます. そして, 設定スクリプトを実行し, 標準の make コマンドを使ってソースのコンパイルとインストールをおこないます.

FreeBSD の ports も tarball の仕組みを利用していますが, これはユーザが 苦労して作業することを期待したものではなく, どのようにすれば FreeBSD 上で そのプログラムが動くようになるかという「ノウハウ」を を使用して収めているものです. スケルトンは, カスタマイズ済みの も 提供していますので, ほとんどすべての ports は同じ手順でインストールすることが できます.

もしあなたが ( または にある) ports スケルトンを見ていて, そこに潜んでいる あらゆる種類の先端的なロケット工学的なものを見つけられると期待していると, つまらなそうなファイルやディレクトリがそこにあるだけなのを見て, がっかりするかもしれません. (ports を手に入れる方法については, すぐに の節でお話します.)

「一体どうしたらいいんだ? ここにはソースコードが全然ないじゃないか?」 というあなたの叫びが聞こえるようです.

心配いりません. おとなしく読んでいけば, すべてが (たぶん) 明らかに なるでしょう. 試しに ports をインストールして, 何が起きるのかを見てみましょう. かなり典型的な例だと思いますので, ここでは `bash' (Bourne-Again Shell として 知られています) を選びます. Note 自宅で試してみる場合には, root になる必要があるでしょう. # cd /usr/ports/shells/bash # make install Checksums OK. ===> Extracting for bash-1.14.5 ===> Patching for bash-1.14.5 ===> Applying FreeBSD patches for bash-1.14.5 ===> Configuring for bash-1.14.5 ===> Building for bash-1.14.5 [とてもとても大量のメッセージをコンパイラが出力します...] ===> Installing for bash-1.14.5 make -f bash-Makefile bindir=/usr/local/bin prefix=/usr/local install (cd ./documentation/; make ) rm -f builtins.txt nroff -man builtins.1 > builtins.txt install -c -o bin -g bin -m 555 bash /usr/local/bin/bash install -c -o bin -g bin -m 555 bashbug /usr/local/bin/bashbug ( cd ./documentation/ ; make mandir=/usr/local/man/man1 man3dir=/usr/local/man/man3 infodir=/usr/local/info install ) [ -d /usr/local/man/man1 ] || mkdir /usr/local/man/man1 [ -d /usr/local/info ] || mkdir /usr/local/info ../support/install.sh -c -m 644 bash.1 /usr/local/man/man1 ../support/install.sh -c -m 644 builtins.1 /usr/local/man/man1/bash_builtins.1 ../support/install.sh -c -m 644 features.info /usr/local/info/bash.info gzip -9nf /usr/local/man/man1/bash.1 /usr/local/man/man1/bash_builtins.1 ===> Registering installation for bash-1.14.5

ここではあなたが混乱しないように, コンパイル時とインストール時の出力を 多少省略してあります. もしもあなた自身で実行されたら, 最初にこのような 出力結果を得るはずです:-

`make' プログラムは, あなたの手元にソースコードがないことを検出し, 処理を続けられるようにソースを FTP でダウンロードしようとします. (結構すごいとは思いませんか? 8-)) この例では, あらかじめ手動でソースコードを用意してあったので, 持ってくる必要はありませんでした.

では, 続けて `make' プログラムが何をしているのか見てみましょう. ソースコード のありかを 確認します. 手元にファイルが存在しなければ, FTP サイトから入手しようとします. テストを実行して, その tarball が事故か何かで途中で切れていたり, 転送中にニュートリノに よって傷められたりして改変されたりしていないかどうかを確認します. tarball を一時的な作業用ディレクトリに展開します. FreeBSD 上でコンパイルしたり, 動作させるのに必要な すべての をソースコードに当てます. 構築のために必要なコンフィグレーションスクリプトを実行します. コンフィグレーションスクリプトの質問には正確に答えてください. (いよいよ!) ソースコードをコンパイルします. 実行形式のプログラム, マニュアル, その他のサポートファイルを, システムのプログラムと混ざってしまわないように /usr/local 以下に インストールします. ports はすべて同じ場所にインストールされ, システムのあちこちにばらまかれることはありません. インストール結果はデータベースに登録されます. これにより, インストールしたプログラムがもしも気に入らなかったときも, システムから すべての痕跡をきれいに することができます.

以上のステップが make の出力と一致するかどうか確認してください. 今まで確認していなかったのなら, 今からするようにしてください! FreeBSD ports コレクションの入手

あるプログラムの FreeBSD port を入手するには二つの方法があります. ひとつは を使う方法で, もうひとつは を使う方法です. CD-ROM からコンパイルする

FreeBSD をインストールしたときに, ``Do you want to link the ports collection to your CDROM'' という質問に yes と答えていたら, 初期設定は既に終わっています.

そうでない場合は, # mkdir /usr/ports # cd /usr/ports # ln -s /cdrom/ports/distfiles distfiles ports の make メカニズムが tarball を見つけることができるようになります. (ports は /usr/ports/distfiles に tarball があることを期待していますので, そこから CD-ROM の tarball ディレクトリにシンボリックリンクを張ったのです.)

さて, データベースディレクトリから gnats プログラムをインストールしようと しているとします. 方法は次のとおりです:- # cd /usr/ports # mkdir databases # cp -R /cdrom/ports/databases/gnats databases # cd databases/gnats # make install もしもあなたがまじめなデータベースユーザであって, ports コレクションの中の すべてのデータベースを比較したいと思っているならば, 次のようにしてください. # cd /usr/ports # cp -R /cdrom/ports/databases . # cd databases # make install (cp コマンドの最後のドットはドットそのものであって, もちろんタイプミスでは ありません. Unix でドットは現在自分自身がいるカレントディレクトリを 意味しています.)

ports make メカニズムは, データベースディレクトリのすべての ports を 自動的にコンパイルし, インストールをおこなってくれます.

この方法が気に入らない場合は, まったく違うやり方もあります:-

XFree86 の配布に含まれる lndir(1) コマンドを使用して 「リンクツリー」を作ります. ディスクの空き領域を見つけてディレクトリを作成し, /usr/ports からそのディレクトリへシンボリックリンクを張ります. そして CD-ROM 上の ``ports'' ディレクトリのフルパス名を引数として lndir(1) コマンドを実行します. (例えば lndir /cdrom/ports のように:) そして, 作成したリンクツリーの中で ports を構築することで, CD-ROM から 直接 ports を構築することができます.

ライセンスの制限により, いくつかの ports でオリジナルのソースコードを CD-ROM に入れることができなかったものがあることに注意してください. この場合, の 節を参照してください. インターネット経由で ports をコンパイルする

CD-ROM を持っていなかったり, その ports の最新バージョンを確実に入手したい 場合は, その ports の を ダウンロードする必要があります. ところで, これは落し穴 (誤ってパッチを pkg サブディレクトリに ダウンロードしてしまうような失敗) が たくさんある作業に見えるかもしれませんが, 実際には非常に簡単です.

ここで鍵になるのは, FreeBSD の FTP サイトが その場で を作成できるということです. どのように動作するのか, ここでは例として databases ディレクトリにある gnats プログラムを使って説明します. (角型かっこの中の文はコメントなので, 実際に実行する場合には, これをタイプしないでください!):- # cd /usr/ports # mkdir databases # cd databases # ftp ftp.freebsd.org [ユーザ名 `ftp' でログインし, パスワードを要求されたら, あなたの電子メール アドレスを入力してください. バイナリモードを (イメージモードと呼ばれることも あります) 使うのをお忘れなく!] > cd /pub/FreeBSD/ports/databases > get gnats.tar.gz [gnats スケルトンの tarballs を取得] > quit # tar xzf gnats.tar.gz [gnats スケルトンの展開] # cd gnats # make install [gnats の構築とインストール] さて何が起きるでしょうか? FTP サイトにいつも通りに接続して, データベースの サブディレクトリに移動します. `get gnats.tar.gz' とコマンドを入力すると, FTP サイトでは gnats ディレクトリを にして, 送信する前に圧縮までしてくれるのです. ですから, 圧縮をおこなわない場合よりも多少速く手に入ることでしょう.

gnats スケルトンを展開したら, gnats ディレクトリへ移動して ports を構築します. 説明したように, make の過程で 手元にソースコードがないことを検出すると, ソースコードを取得してから 展開し, パッチ当てと構築をおこないます.

それでは, 少し冒険をしてみましょう. 一つの ports スケルトンを 取得するかわりに, たとえば ports コレクションの中のデータベースの スケルトンをすべて, サブディレクトリ全体を取得してみましょう. やり方はほとんど同じです:- # cd /usr/ports # ftp ftp.freebsd.org [ユーザ名 `ftp' でログインし, パスワードを要求されたら, あなたの電子メール アドレスを入力してください. バイナリモードを (イメージモードと呼ばれることも あります) 使うのをお忘れなく!] > cd /pub/FreeBSD/ports > get databases.tar.gz [データベースディレクトリの tarballs を取得] > quit # tar xzf databases.tar.gz [すべてのスケルトンを展開] # cd databases # make install [データベース ports 全部の構築とインストール] わずかばかりの簡単なコマンドで, この FreeBSD マシン上にデータベース プログラムを一揃い手に入れてしまいました! 一つの ports スケルトンを取ってきて それを構築する場合との違いは, すべてのディレクトリを一度に取得して, 全部を一度にコンパイルしたということだけです. かなり感動的だと思いませんか?

もし一つや二つの ports だけでなく, もっと多くの ports をインストールする つもりなら, おそらくすべての ports ディレクトリをダウンロードしておく 価値があるでしょう. これは, 圧縮されていれば 2〜3 MB 程度の大きさです. しかし, distfiles ディレクトリの下にあるファイルも一緒にダウンロードする つもりがないのなら, 調子に乗って `get ports.tar.gz' とタイプしてはいけません. distfiles ディレクトリには, ほとんどすべての ports のソースコードが 置かれているので, すべてをダウンロードするには非常に長い時間がかかるでしょう! スケルトン

スケルトン (訳注: skeleton とは骸骨のことです) とは, 締め切りを守るため, 食事をするのを忘れるほど仕事にのめり込んだハッカーたちのなれの果ての ことでしょうか? FreeBSD の屋根裏に潜む, なにか気持ちの悪いものでしょうか? いいえ, ここでスケルトンの意味するところは, ports の魔術を実現するのに 必要とされるすべてのものを提供する最小の骨組みのことです. Makefile

スケルトンのもっとも重要な要素は Makefile です. Makefile は ports を どのようにコンパイルし, インストールをおこなうかを指示する いろいろな命令を含んでいます. 以下に bash の Makefile を示します:- # New ports collection makefile for: bash # Version required: 1.14.5 # Date created: 21 August 1994 # Whom: jkh # # Makefile,v 1.13 1995/10/04 14:45:01 asami Exp # DISTNAME= bash-1.14.5 CATEGORIES= shells MASTER_SITES= ftp://slc2.ins.cwru.edu/pub/dist/ MAINTAINER= ache@FreeBSD.ORG post-install: .if !defined(NOMANCOMPRESS) gzip -9nf ${PREFIX}/man/man1/bash.1 ${PREFIX}/man/man1/bash_builtins.1 .endif .include <bsd.port.mk> "#" で始まる行は, 人間のためのコメント行です. (ほとんどの Unix のスクリプトと同じですね.)

`DISTNAME" は の名前から拡張子を取ったものです.

`CATEGORIES" はこのプログラムの種類を示します.

`MASTER_SITES" はマスタ FTP サイトの URL です. もしローカルシステムに がない場合には, ここから取得します. これは信頼できると考えられているサイトで, 通常はそのプログラムを インターネット上で公式に配布しているサイトです. (そのソフトウェアがインターネット上で「公式に」配布されているとしたら)

`MAINTAINER" は, 例えば新しいバージョンのプログラムが出た場合に, 必要であればスケルトンの更新をおこなう保守担当者の電子メールアドレスです. (注: 「保守担当者」というのは, スケルトンの管理者という意味であって, プログラムのサポートをおこなう責任は を見つけた場合には, 電子メールは &a.ports; に送ってください. 保守担当者には 次の数行はとりあえず飛ばします. .include この行は, この ports に必要なその他の命令やコマンドは `bsd.port.mk" に 入っているということです. すべての ports で同じものなので, すべての Makefile に 書いておく必要はありません. そのため単一の標準ファイルにまとめられています.

ここでは Makefile がどう働くかを詳細に調査するのが目的ではありませんので, `post-install" で始まる行は, bsd.port.mk に書かれている, プログラムを インストールした後での処理を置き換えていて, 最終的な場所に man ページを 置いた後で圧縮するように指示している, と言っておくだけで充分でしょう. files ディレクトリ

ports のチェックサム算出には MD5 アルゴリズムを使用しているので, この を含んでいる ファイルは "md5" と呼ばれます. ちょっと混乱するかもしれませんが, このファイルは "files" という 名前のディレクトリに置かれています.

このディレクトリは, ports に必要だけれども, 他のどこにも属さない 雑多なファイルも含んでいます. patches ディレクトリ

このディレクトリには, FreeBSD ですべてを正常に動作させるのに 必要な が含まれています. pkg ディレクトリ

このディレクトリには, 非常に役立つ三つのファイルが含まれています:- COMMENT - プログラムについての 1 行の説明. DESCR - より詳細な説明. PLIST - プログラムのインストール時に作成される, すべてのファイルのリスト. あれ? 動かない!?

おやおや. では, 次の四つのどれかをやってみてください: 自分で修正する. 技術的な詳細については, をご覧ください. 苦情をいう. これは電子メールで * だけ * にしてください! Walnut Creekの人たちは, FreeBSD システムの機能 (あるいは欠陥) について, いっさい責任がありません. ほとんどサードパーティの貢献による ports システムなどは特にそうです. (これが信じられないならば, Walnut Creek のカタログをチェックしてください. 「このプロダクトに関するテクニカルサポートを提供することができません」と 明記してあります.) 電子メールのアドレスは &a.ports; です. あなたがどこから ports の ソースコードや配布ファイルを入手したのか, どんなエラーが発生したのかなど, 詳細を記述してください. 注: 執筆当時, lang/Sather は Pentium マシンでは, Intel の呪い (別名, 浮動小数点除算バグ) のために動作しません. 私たちは これについては関知しません. 苦情をいうなら Intel にどうぞ. これは彼らのバグなのですから! 忘れてしまう. これはほとんどの場合最も簡単な方法です. ports のプログラムのうち必要不可欠な物はごくわずかです. FTP サイトからコンパイル済みのパッケージを入手する. マスターパッケージコレクションは FreeBSD の FTP サイトの に置いてありますが, まずあなたの近くのローカルミラーサイトを確認してください! ソースからコンパイルに挑戦するよりパッケージを使ったほうが, (ほとんど全部が) ずっと確実に動作するでしょうし, より手っ取り早い方法でもあります. プログラムをシステムにインストールするには, pkg_add(1) を使ってください. ports 化したいプログラムがあるのですが...

すばらしい!具体的なやり方については に, 詳細な手順がありますので ご覧ください. 質問と回答集

Q. 私はモデムについての議論をしているのかと思っていました??!

A.なるほど, あなたはきっとコンピュータの背面についている シリアルポートのことだと思ってしまったのでしょう. あるバージョンの Unixから別のバージョンの Unix へとプログラムを 移殖することを `porting' というのですが, ここで我たちは `porting' の結果 という意味で `port' を使っています. (コンピュータに関わる人々の悪しき習慣として, ひとつの同じ言葉を複数の まったく違う意味として使うことがあるのです.) Q. 私は, 標準以外のプログラムのインストールには packages を使うと 思っていたのですが.

A. そのとおり. 通常は packages が最も手早くて簡単な方法です. Q. それではどうして面倒な ports があるのですか?

A. いくつかの理由があります:- いくつかのソフトウェアのライセンス条件には, バイナリではなくソースコードでの配布を求めているものがあります. バイナリ配布を信用していない人もいます. 少なくともソースコード があれば, ソースコードを読んで, (理論的には) 潜在的な問題点を自分で 見つけ出すこともできるはずです. ローカルなパッチを入手した場合, それを自分で追加するために ソースコードが必要になります. プログラムがいかにコンパイルされるべきかについて, あなたはパッケージを作った人とは異なる見解を持っているかもしれません. どんな最適化オプションをつけるべきかとか, デバッグバージョンを作ってから それを strip するべきだとか, いや, そうするべきでない, などなど, 確固たる見解を持っている人もいるでしょう. ソースコードを手元に置いておきたい人たちもいます. 彼らは, 退屈したときに眺めたり, あちこち解析してみたり, ソースコードを 借用したり (もちろん, ライセンスが許せばの話ですが) するのです. あなたがソースコードを持っていなければ, それはソフトウェアとは 言えませんね! ;-)

A. パッチとは, あるバージョンから他のバージョンへどのように変更するかを 示す, (通常は) 小さなファイルです. 「23 行目を削除」, 「468 行目の後に これらの 2 行を追加」, または「197 行目をこのように変更」というような 内容を含んでいます. これは, `diff' という名前のプログラムで生成されます.

A. .tar.gz という拡張子を持つファイルです. ( .tar.Z のようなバリエーションも ありますし, DOS のファイルシステム用に .tgz と短縮される場合もあります.)

これは基本的に, 一つのファイルに固めて (.tar) 圧縮した (.gz) ディレクトリ ツリーです. これは元々 これらのファイルの中身を見たり, 展開したりすることもできます. FreeBSD の基本システムに付属する Unix 標準の tar コマンドを使ってみると 次のようになります:- tar tvzf foobar.tar.gz # foobar.tar.gz の内容を見る tar xzvf foobar.tar.gz # カレントディレクトリに内容を展開する

A. これは, チェックしたいファイル中のすべてのデータを加えて生成した 数値です. 何か文字が書き換わっていたら, チェックサムが一致しなくなります. そのため, 単純な比較だけで違いを見つけることができるのです. (実際には, 文字の位置が入れ替わるなどの, 単純な加算ではわからない問題も 見つけることができる複雑な方法で計算されています.) Q. 私は, にしたがって ports をインストールしていました. kermit をインストールしようとするまではうまくいっていました:- # make install >> cku190.tar.gz doesn't seem to exist on this system. >> Attempting to fetch from ftp://kermit.columbia.edu/kermit/archives/. なぜ cku190.tar.gz が見つからないのでしょうか? 不良品の CD-ROM を買ってしまったのでしょうか?

A. Kermit の権利を持つチームは, 私たちの CDROM に kermit の tarball を 入れることを許可しませんでした. 申し分けありませんが, 手動でファイルを 入手してください. このようなエラーメッセージが出たのは, あなたがそのときインターネットに 接続していなかったためです. あらかじめ上記のサイトのいずれかからファイルを ダウンロードしておけば, プロセスを再開することができます. (ダウンロードの際には, あなたに最も近いサイトを選ぶようにしてください. そうすれば, 時間とインターネットの帯域の節約になります) Q. kermit の tarball を入手しましたが, /usr/ports/distfiles に ファイルを置こうとすると, 書き込み権がないというエラーがでます.

A. ports のしくみは /usr/ports/distfiles から tarball を探します. しかし, これは read-only の CD-ROM へのシンボリックリンクなので, ここにファイルを置くことはできません. 次のようにすれば, 他の場所を探すよう ports に指示することができます. DISTDIR=/where/you/put/it make install Q. ports では, すべてを /usr/ports に置いたときだけ動作するのでしょうか? システムの管理者によると, 私の個人的なファイルは /u/people/guests/wurzburger に入れなければならないのですが, これでは うまくいかないように思います.

A. PORTSDIR 変数と PREFIX 変数を変更することで, 違うディレクトリを 使用することができます. 例えば, PORTSDIR=/u/people/guests/wurzburger/ports make install とすると, ports は /u/people/guests/wurzburger/ports でコンパイルされ, すべて /usr/local 以下にインストールされます. PREFIX=/u/people/guests/wurzburger/local make install この場合, コンパイルは /usr/ports でおこない, /u/people/guests/wurzburger/local にインストールします. もちろん, 以下のように両者を組み合わせることも可能です. PORTSDIR=.../ports PREFIX=.../local make install (省略せずに記述したら, このページに収めるには長すぎるのですが, 考え方は理解していただけたと思います)

もし ports をインストールするたびに, これらを毎回タイプするのが 気に入らないのであれば, (正直に言って, 誰もそう思わないでしょう) これらを環境変数にセットしてしまうという手があります. Q. 私は, FreeBSD の CD-ROM を持っていませんが, 私はすべての tarball を 私のシステムに置いておきたいのです. そうすれば, 私は ports をインストール するたびに, 毎回ダウンロードが終わるのを待たなくてすむでしょう. これを一度におこなう簡単な方法はありませんか?

A. ports コレクション全体の tarball を持ってくるには, 次のようにしてください. # cd /usr/ports # make fetch ports の下のディレクトリひとつの tarball を持ってくるには, 次のように してください. # cd /usr/ports/directory # make fetch ports をひとつだけ持ってくる方法は, きっと既にご存知だと思います. Q. マスタ FTP サイトから tarball を持ってくるより, 近くにある FreeBSD の ミラーサイトから持ってきた方が速いはずです. MASTER_SITES に書かれている サイト以外から持ってくるように ports に指示する方法はありませんか?

A. もちろんあります. 例えば ftp.FreeBSD.ORG が MASTER_SITES に書かれている サイトより近いとしたら, 以下のようにしてください. # cd /usr/ports/directory # make MASTER_SITE_OVERRIDE=ftp://ftp.FreeBSD.ORG/pub/FreeBSD/distfiles/ fetch Q. ダウンロードをする前に, どんなファイルが必要なのか知りたいのですが.

A. 'make fetch-list' とすると, ports に必要なファイルの一覧を表示できます. Q. ports のコンパイルを途中で止める方法はありますか? 私はインストールをする前にいろいろとソースコードを解析したいのですが, 毎回 control-C を打たなければならないのが少し面倒です.

A. 'make extract' を実行すると, ファイル転送とソースコードの展開まで おこなったところで停止します. Q. 自分で ports を作ろうとしています. 私の作ったパッチが 正しく処理できることを確認できるように, コンパイルを止めたいのです. パッチのための 'make extract' のようなものはありませんか?

A. あります. 'make patch' があなたのお望みのものです. ところで, あなたの努力に感謝いたします!! Q. あるコンパイルオプションはバグの原因になるという話を聞きました. 本当なのでしょうか? どうやったら正しい設定で ports をコンパイルできますか?

A. 本当です. gcc の バージョン 2.6.3 (FreeBSDの 2.1.0 と 2.1.5 に付属している バージョン) では, -O2 オプションを -fno-strength-reduce オプションなしで 使うと, バグのあるコードを出力します (ほとんどの ports は -O2 オプションを 使いません). コンバイラオプションは次のように定義 # CFLAGS='-O2 -fno-strength-reduce' make install /etc/make.conf を編集することもできますが, すべての場合でこれが反映される 訳ではありません. もっとも確実なのは 'make configure' を実行し, ソースディレクトリの Makefile を見て手で修整することですが, ソースが 多くのサブディレクトリにわかれていて, 各々に Makefile がある場合は 大変な仕事になります. Q. ports がたくさんありすぎて, 私の欲しいものがなかなか見つけられません. どんな ports が使えるのか, リストはどこかにありませんか?

A. INDEX ファイルは /usr/ports の中にあります. Q. 'foo' ports をインストールしたいのですが, それはすぐに停止して, 'bar' ports のコンパイルが始まってしまいます. 一体どうして?

A. 'foo' ports が, 'bar' ports の提供する何らかの機能を必要としているからです. 例えば 'foo' が画像を使うとすると, 'bar' は画像処理に必要な ライブラリを持っている, などです. または, 'bar' は 'foo' をコンパイルするのに必要なツールなのかもしれません.

A. 大丈夫, 次のようにしてください. pkg_delete grizzle-6.5 Q. ちょっと待ってください. 削除しようとするコマンドのバージョン番号を 知っていなくてはならないのでしょうか? あなたは, 私がバージョン番号を 覚えていることを本気で当てにしているのでしょうか?

A. そんなことはありません. バージョン番号は次のようにすればわかります. pkg_info -a | grep grizzle そうすると次のように表示されます:- Information for grizzle-6.5: grizzle-6.5 - the combined piano tutorial, LOGO interpreter and shoot 'em up arcade game. Q. ディスク容量のことなのですが, ports のディレクトリは非常に膨大な容量を 使うように見えます. 残しておいた方がよいのでしょうか? 削除してしまっても よいのでしょうか?

A. はい. インストールが首尾よく終わり, もうソースコードが必要でないと思うなら, それらを残しておく理由はないでしょう. 一番よい方法は, 次の通りです. # cd /usr/ports # make clean これは, すべての ports のサブディレクトリを調べ, 各 ports のスケルトン以外の削除をおこないます. Q. これを試してみたのですが, tarball や ports で使われたファイルが distfiles ディレクトリに残っています. これも削除してしまっても大丈夫ですか?

A. はい. それを使った作業が終わったのであれば, 削除してしまっても大丈夫です. Q. 私はとてもとてもたくさんのプログラムを楽しみたいのです. 一度にすべての ports をインストールする方法はありませんか?

A. 次のようにしてください. # cd /usr/ports # make install Q. やってみました. 時間がとてもかかるだろうと思ったので, そのまま実行を 続けさせて, 私は寝ました. 翌朝コンピュータを見てみると, 三つ半の ports しか 処理が終わっていませんでした. なにか悪かったのでしょうか?

A. これは ports の中には私たちの決められないこと (例えば, あなたが A4 の 用紙に印刷したいのか, US レターサイズの用紙に印刷したいのかなど) について 質問してくるものがあるからです. それらの質問には手動で答える必要があります. Q. 私は一日中モニタの前に座って過ごしたりしたくないのですが. 何かよいアイデアはありませんか?

A. では, あなたが寝に / 仕事に / 公園にいく前に以下を実行してください:- # cd /usr/ports # make -DBATCH install これでユーザの入力を要求しないすべての ports をインストールします. そして, 戻ってきてから, 次のように実行してください. # cd /usr/ports # make -DIS_INTERACTIVE install そして, 残りの作業を実行してください. Q. 私たちは ports コレクションにある frobble を使っています. ですが, 私たちの必要に応じて ports を変更したところがあるのです. 自分でパッケージを作って, それを私たちのサイトのまわりに 簡単に配布できるような方法がありますか?

A. もちろんあります. 変更点をパッチにする方法は知っていますよね:- # cd /usr/ports/somewhere/frobble # make extract # cd work/frobble-2.8 [あなたのパッチを当ててください] # cd ../.. # make package Q. この ports の技術は本当に賢いですね. どのようにして動いているのか 私はどうしても知りたいと思います. その秘密は何ですか?

A. 秘密は一切ありません. にある bsd.ports.mk と bsd.ports.subdir.mk ファイルを見るだけです. (注: 複雑なシェルスクリプトを嫌う読者は, このリンクを追いかけないほうが よいでしょう.) diff --git a/ja/handbook/ppp.sgml b/ja/handbook/ppp.sgml index 207d1f66aa..26a7741768 100644 --- a/ja/handbook/ppp.sgml +++ b/ja/handbook/ppp.sgml @@ -1,429 +1,429 @@ - + カーネル PPP の設定

原作: &a.gena;.

訳: &a.graphite;.6 September 1996. 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 : # 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 : defaultroute # put this if you want that PPP server will be your # default router 接続方法: kermit (またはその他のモデム操作プログラム) を使ってリモートホストに ダイヤルし, 接続してください. そして, あなたのユーザ名とパスワード (必要 であれば, その他にもリモートホストで PPP を有効にするための操作) を入力 します. kermit を抜けてください. (回線を切断せずに) 下記のように入力します: /usr/src/usr.sbin/pppd.new/pppd /dev/tty01 19200 (通信速度とデバイス名には, あなたの環境に適したものを入れてください) これでこのコンピュータは PPP で接続されました. もし, なんらかの理由で 接続に失敗したならば, /etc/ppp/options ファイルに "debug" オプションを追加して, 問題点を突き止めるために, コンソールに表示される メッセージを調べてください. 下記の /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 を使う方法です. 原作: &a.rhuff;.

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 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 # 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 : 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 CONNECT "" TIMEOUT 10 ogin:-\\r-ogin: TIMEOUT 5 sword: 正しくインストールし編集した後は, 必要な事はこれだけです

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 mode 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: diff --git a/ja/handbook/printing.sgml b/ja/handbook/printing.sgml index 26e2cdda6c..26d74116c5 100644 --- a/ja/handbook/printing.sgml +++ b/ja/handbook/printing.sgml @@ -1,4179 +1,4179 @@ - + プリンタの利用

著者 &a.kelly;30 September 1995

訳者 &a.kimura;3 September 1996 FreeBSD でプリンタを使用するためには, バークレイラインプリンタ スプーリングシステム (LPDスプーリングシステムとしても知られて います) が機能するようにプリンタをセットアップする必要がありま す. 本節では, LPDスプーリングシステム (大抵の場合, 単にLPDと呼 ばれる) について紹介します. もし, LPDや他のプリンタスプーリングシステムについて既に詳しい 知識をお持ちの方は, 「」から読み始めて も結構です. スプーラは何をするか

LPDはあるホストのプリンタに関する制御の一切をおこないます. こ こで言う制御としては, 次のことが挙げられます. ホストに接続されたプリンタ, あるいはネットワーク 上の他ホストに接続されたプリンタに対するアクセスを制御しま す. ファイルをプリントする要求に対して許可を与えます. この要求は特に 各々のプリンタの シリアルポートに接続したプリンタ用に通信パラ メータを管理します. ネットワーク経由で他のホスト上の, 別のLPDスプーラにジョ ブを送ることができます. 様々なプリンタ言語やプリンタの能力に応じてジョブの 形式を整えるため, 特別なフィルタを起動することができます. プリンタの使用に対して課金をおこなうことができます. 設定ファイルを通して, また, 特別なフィルタプログラムを供給 することにより, 多種多様なプリンタ機器に対して, 上述の機能の 全部または一部をLPDシステムにおこなわせることができます. どうしてスプーラを使うべきなのか

あなたのシステムを利用するのがあなた一人だけだとしたら, ア クセス制御もヘッダページもプリンタ利用に対する課金も必要ないのに, なぜわざわざスプーラに煩わされなければならないのか疑問に思うか もしれません. プリンタに対する直接アクセスを許可することもできるので すが, とにかくスプーラを使用するべきです. その理由は, LPDはジョブをバックグラウンドで処理します. データが プリンタに送信されるまで待つ必要はありません. LPDではジョブをフィルタを通してプリントすることが簡 単にできます. これにより, 印刷物のヘッダに時刻や日付を入れ たり, 特別なファイル形式 (TeX の DVI ファイルなど) をプリン タが処理できる形式に変更することができます. これらの作業を 手動でおこなう必要がなくなります. プリント処理をおこなうフリーのまたは商用のプログラムの ほとんどは, システムのスプーラとやりとりするように作られて います. スプーリングシステムをセットアップすることで, 今後 加えるかもしれない, あるいは, 既に持っている別のソフトウエ アをより簡単にサポートすることができるでしょう. スプーリングシステムのセットアップ

LPDスプーリングシステムを用いてプリンタを使用するためには, プリンタ機器とLPD用ソフトウェアの両方を準備する必要があります. 本ドキュメントでは次の2段階のレベルに分けて説明をします. プリンタを接続する方法, プリンタにどの ように通信するかをLPDに指示する方法や, プレインテキスト をプリンタで印字する方法については, 「」をご覧ください. 様々な形式のファイルを印字する方法, ヘッダページを 印字する方法, ネットワーク経由でプリンタに印字する方法, プリンタを制御する方法, プリンタの使用に対する課金をおこなう 方法については「」をご覧ください. プリンタ設定導入編

この節では, プリンタ機器やプリンタを使用するためのLPD用ソフ トウェアを設定する方法について述べます. この節の概要は次の通り です. 「」では, プリンタをコンピュータに接 続するためのヒントがいくつか書かれています. 「」では, LPDのスプーラ設定ファイル /etc/printcapの設定方法について書かれています. データをプリンタに送るためにシリアルまたはパラレルインタフェー スではなく, ネットワークプロトコルを使用する場合は, 「」をご覧くださ い. この節のタイトルは「プリンタ設定導入編」ですが, 実際の設定は かなり複雑です. プリンタをコンピュータに接続し, LPDスプーラを 起動させることは一番困難な作業です. ヘッダページを出力させたり, 課金したりするオプションの設定は, 一度プリンタがうまく動くよう になれば, とても簡単です. プリンタ機器の設定

この節では, プリンタにPCを接続するための様々な方法について 説明しています. ここでは, ポートやケーブルの種類, FreeBSDが プリンタとの通信に必要なカーネルコンフィグレーションについて も言及しています. もし, プリンタが既に接続されていて, 他のオペレーティングシステ ム上でプリンタからの印字に成功している場合は, 「」まで読み飛 ばすことが多分できるでしょう. ポートとケーブル

最近のPC用のプリンタほとんどには次のインタフェースの一つ もしくは両方がついています. パラレルインタフェースは「セントロニクス」インタフェー スとして知られています. これは, プリンタ用のコネクタタ イプとして採用された後に名付けられました. シリアルインタフェースはパラレルインタフェースより も普通はデータの伝送速度が遅くなります. パラレルインタフェースで は, 通常, (コンピュータからプリンタへの) 単方向通信のみをおこな うのに対して, シリアルインタフェースは双方向通信をおこないます. 最近のパラレルポートの多くはプリンタ側からデータを受けとる こともできますが, コンピュータ側にデータを送り返すことが必 要となるプリンタはほとんどありません. さらに, FreeBSDでは 双方向のパラレル通信をまだサポートしていません. 通常, プリンタで双方向通信が必要となるのは, プリンタが PostScript 言語に対応しているときだけです. PostScript プリ ンタは非常に冗長に動作させることができます. 事実, PostScript によるジョブでは, プログラムを本当にプリンタ に送信します. このことは, 印字作業を必ずしもする必要がない ことを意味し, また, プログラムの結果をコンピュータに直接返 されるかもしれません. PostScript プリンタでは, 双方向 通信を使って, PostScript プログラムのエ ラーや紙づまりといった問題をコンピュータに報告します. ユー ザはそれらの情報を知りたいと思うかもしれません. さらに, PostScript プリンタで課金作業をもっとも効率よくおこなうため には双方向通信が必要となります. この方法では, まず, プ リンタの現在のページカウント (起動してから今まで何枚の紙を 印字したか) の情報を得ます. 次に, ユーザのジョブをおこない, 終 了後, 再びページカウントを得ます. この2数を差によって, 課 金対象となる紙の枚数を知ることができます. それでは, どちらのインタフェースを使うべきなのでしょうか. 双方向通信が必要なら, シリアルポートを使ってくださ い. FreeBSDではパラレルポート上での双方向通信はまだサポー トされていません. 双方向通信の必要がなく, パラレルかシリアルかの選 択ができる場合はパラレルインタフェースを使うのが好ましい です. これにより, シリアルポートを他の周辺機器 (端末やモ デムのなど) のために残しておくことができます. また, パラ レルインタフェースの方がほとんどの場合高速であり, 設定も より簡単になっています. 結局のところは動いてくれるものを使えばよいのです. パラレルポート

プリンタをパラレルインタフェースを使って接続する場合は, セントロニクスケーブルでプリンタとコンピュータをつないでくださ い. 詳しい説明はプリンタ, コンピュータ, あるいは両方に付属す る説明書に書かれているはずです. その際, どのパラレルポートを使用したかを覚えておいてください. FreeBSDでは最初のポートは /dev/lpt0, 2番目は /dev/lpt1 であ り, 3番目以降も同様に続きます. シリアルポート

シリアルインタフェースを使ってプリンタを使う場合は, 適切 なシリアルケーブルでプリンタとコンピュータを接続してください. 詳しい説明はプリンタ, コンピュータ, あるいは両方に付属する説 明書に書かれているはずです. 「適切なシリアルケーブル」がよくわからないときは, 次のどれか を試してみてください. A この他に, プリンタ用の通信パラメータを設定する必要がありま す. 通常, プリンタのフロントパネルやDIPスイッチによって制 御します. コンピュータとプリンタの双方で設定できる最高の通 信速度[bps] (ビット/秒. ソフトウェアの設定

本節ではFreeBSDのLPDスプーリングシステムで印字をおこなうために 必要となるソフトウェアの設定について説明しています. 本節の概要は次のようになります. プリンタで使用するポートのために, 必要があれば, カー ネルの書き変えをおこないます. 「」で, このためにしなくてはなら ないことを説明しています. パラレルポートを使用している場合は, パラレルポートの ための通信モードの設定します. 詳細は, 「」で説明しています. オペレーティングシステムからプリンタにデータが送ら れているかをテストします. 「」で, どのように テストするかの提案をいくつかおこなっています. ファイル/etc/printcapを変更し, LPDの設定を おこないます. 「」で, どのように変更するかを 説明しています. カーネルの変更

オペレーティングシステムのカーネルのコンパイルをおこなうこと によって, 指定されたのデバイスが機能するようになります. シリ アル, または, パラレルインタフェースをプリンタで使用する場合, 必要なデバイスがこの指定の中に含まれていなくてはなりません. したがって, 必要なデバイスがカーネルに組み込まれていない場合, 追 加のシリアル, または, パラレルポートをサポートするために, カー ネルの再コンパイルが必要となるかもしれません. シリアルポートが現在使用しているカーネルでサポートされている かどうかを調べるためには, 次のように入力します. dmesg | grep sio ここで, sio2 at 0x3e8-0x3ef irq 5 on isa sio2: type 16550A パラレルポートが現在使用しているカーネルでサポートされている かどうかを調べるためには, 次のように入力します. dmesg | grep lpt ここで, lpt0 at 0x378-0x37f on isa 上記の出力が得られない場合, プリンタを使うため, オペレーティ ングシステムにパラレル, または, シリアルポートを認識し, 使用 できるようにするためにはカーネルを変更する必要があります. シリアルポートをサポートさせるには, 「」の節をご覧く ださい. パラレルポートをサポートさせる場合も, その節と, ポート用エントリを /dev に追加する

カーネルがシリアル, または, パラレルポートを通じての通 信をサポートしていたとしても, システム上で動いているプログ ラムがデータの送受信をおこなうためのソフトウェアインタフェース がさらに必要になります. そのインタフェースは, /dev ディレクトリにあるエントリに相当します. /dev エントリにポートを加えるために /dev ディレクトリに移動します. cd /dev 次のように入力します. ./MAKEDEV ここで, 次を入力し, デバイスのエントリができたか確認し ます. ls -l パラレルポートの通信モードを設定する

パラレルインタフェースを使用している場合, FreeBSDでは, 割り込み駆動型にするか, プリンタとの通信の状況をカーネルに監 視させるかのいずれかを選択できます. GENERIC カーネルでは 割り込み駆動方式は, いくらか高速になりますが, 貴重な IRQ ラインを一つ消費します. うまく機能するものをお使いください. 通信モードを設定するためには2つの方法があります. 1つはカー ネルを変更することで, もう一つは カーネルを設定することによって, 通信モードを変更す る. カーネルコンフィグレーションファイルを変更しま す. イベント駆動方式にする場合は, device lpt0 at isa? port? tty irq ここで, 監視方式を使用する場合は, device lpt0 at isa? port? tty vector lptintr ファイルをセーブし, config プログラムを起動 し, カーネルの構築, インストールをおこないます. そして, リ ブートしてください. 詳細は, 「」を参照 してください. lptcontrol -i -u lptcontrol -p -u これらのコマンドを /etc/rc.local ファイルに追加 しておくと, システムをブートする度に通信モードを設定する ことができます. 詳細については, lptcontrol(8) をご覧くだ さい. プリンタとの通信状況を調べる

スプーリングシステムの設定に進む前に, オペレーティング システムがプリンタにデータを送ることに成功しているかどうか を確かめるべきでしょう. これにより, 印字がうまくいかないと き, プリンタとの通信が問題なのか, スプーリングシステムが問 題なのかを分けて調べることがかなり容易になります. プリンタをテストするためには, プリンタに何かのテキストを送 信してみます. 送信した文字をすぐに印字してくれるプリンタに は, %!PS 100 100 moveto 300 300 lineto stroke 310 310 moveto /Helvetica findfont 12 scalefont setfont (Is this thing working?) show showpage パラレルポートのプリンタとの接続を調べる

この節では, FreeBSDがパラレルポートに接続されたプリ ンタと通信できているかどうかを調べる方法について説明し ています. パラレルポートのプリンタをテストするために プリンタにデータを送ります. プリンタがプレインテキストを印字できる場 合, lptest > /dev/lpt ここで, プリンタが PostScript か他のプリンタ 言語を使用している場合, そのプリンタに簡単なプロ グラムを送信してください. 次のように入力します. cat > /dev/lpt そして, 一行一行, プログラムを もしくは, プログラムを入力したファイルがある 場合は, 次のように入力してください. cat /dev/lpt ここで, これで何かがプリントされることでしょう. 印字されたテキ ストがおかしくても心配しなくても構いません. それについ ては, 後で修正します. シリアルポートのプリンタとの接続を調べる

この節では, FreeBSDがシリアルポートに接続されたプリ ンタと通信できているかどうかを調べる方法について述べられ ています. シリアルポートのプリンタをテストするために /etc/remote ファイルを編集します. 次の エントリを加えてください. printer:dv=/dev/ ここで, 次の例は, プリンタをシリアルケーブルでパリティなし, 転送速度19200bpsで第3番目のシリアルポートに接続した場 合です. printer:dv=/dev/ttyd2:br#19200:pa=none tip printer これがうまくいかなかった場合は, /etc/remoteを 編集して, /dev/ttydの代わりに /dev/cuaaを試してみてください. プリンタにデータを送ります. プリンタがプレインテキストを印字できる場 合, ~$lptest プリンタが PostScript か他のプリンタ 言語を使用している場合, そのプリンタに簡単なプロ グラムを入力します. 一行一行, プログラムを もしくは, プログラムを入力したファイルがある 場合は, 次のように入力してください. ˜> ここで, これで何かがプリントされることでしょう. 印字されたテキ ストがおかしくても心配しなくても構いません. それについ ては, 後で修正します. スプーラに許可を与える: /etc/printcap ファイル

ここまでで, プリンタはコンピュータに接続され, (必要なら) プリンタと通信できるようにカーネルを変更し, 簡単なデータをプ リンタに送信することができているはずです. これで, LPDにプリ ンタへのアクセスを制御させる設定をおこなう準備が整いました. LPDの設定は /etc/printcap を編集することでおこないます. LPDスプーリングシステムはスプーラが使われる毎にこのファイル を参照します. そのため, ファイルを更新するとすぐにその変更が 反映されます. /etc/printcap の編集はお好みのテキストエディタをお 使いください. このファイルの書式は, /usr/share/misc/termcap や /etc/remote といった他のケイパビリティファイルと一致しています. この書式 のついての詳細な情報については cgetent(3) をご覧ください. スプーラの単純な設定法は, 次のステップでおこないます. プリンタに名前 (と簡単な別名2〜3個) を付け, それを /etc/printcap ファイルに記述します. これについ ては, 「」 を参照してください. 」 を参照してください. スプール用のディレクトリを作成し, その位置を 」 を参照してください. プリンタを使用するために /dev エントリを 設定し, /etc/printcap の 」 を参照してください. プリンタをシリアルポートに接続した場合は, 」 を参照してください. プレインテキスト用の入力フィルタのインストールを おこないます. 「」 を参照してください. と を参照してください. 」で, そ れをどのようにおこなえばよいのかが説明されています. プリンタに名前を付ける

最初の (簡単な) ステップで, プリンタの名前を考えます. プ リンタには別名をいくつか付けることもできるので, 機能的な名前 でも風変わりな名前でもどちらを選んでもまったく問題はありません. 少なくとも1つのプリンタには, /etc/printcap の中 で, /etc/printcap ファ イルに設定します. プリンタ名は一番左のカラムから書き始めま す. 別名はそれぞれ縦棒によって区切られ, 最後の別名の後ろに コロンを置きます. 次の例では, 2台のプリンタ (Diablo 630 ラインプリンタと Panasonic KX-P4455 PostScript レーザライタプリンタ) が定義 されている /etc/printcap のスケルトンを記しています. # # /etc/printcap for host rose # rattan|line|diablo|lp|Diablo 630 Line Printer: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4: この例では, 最初のプリンタに ヘッダページの印字を禁止する

LPDスプーリングシステムでは, デフォルトでジョブ毎に/etc/printcap にあるプリンタのエントリに /etc/printcap の例を示しま す. # # /etc/printcap for host rose - no header pages anywhere # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh: この書式を正しく使うための注意をしておきます. 最初の行は左 端のカラムから始まります. それに続く行は TAB ひとつ分だけ 字下げします. 最後の行以外のすべての行は, 行末にバックスラッ シュを記述します. スプーリングディレクトリの作成

スプーラの簡単な設定の次のステップでは, /var/spool の下に置きます. また, スプーリングディレクトリの内容はバックアップをす る必要はありません. mkdir /var/spool/printer-name しかしながら, ネットワーク上に使用可能なプリンタがたく さんあるならば, LPDで印字するための専用のディレクトリに スプーリングディレクトリを置きたいと思うかもしれません. 例に出てきたプリンタ mkdir /var/spool/lpd mkdir /var/spool/lpd/rattan mkdir /var/spool/lpd/bamboo chown daemon.daemon /var/spool/lpd/rattan chown daemon.daemon /var/spool/lpd/bamboo chmod 770 /var/spool/lpd/rattan chmod 770 /var/spool/lpd/bamboo 最後に, /etc/printcap ファイルで, これらのディ レクトリの位置を LPD に伝える必要があります. スプーリ ングディレクトリのパス名は # # /etc/printcap for host rose - added spooling directories # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo: プリンタ名が最初のカラムから始まっており, そのプリンタ に関して記述される他のエントリは TAB で字下げされてい ること, 各行がバックスラッシュで終わっていることに注意 してください. /var/spool/lpd デフォルト値として使用します. プリンタデバイスの特定

「」では, FreeBSD でプリン タとの通信に使用される /dev ディレクトリ内の エントリを特定します. そして, LPD にその情報を伝えま す. 印字するジョブを受け取ると, スプーリングシステムは, (プリンタにデータを渡す義務がある) フィルタプログラムに 代わって指定されたデバイスをオープンします. /etc/printcap ファイルで /dev エントリを記入します. ここでの例では, /etc/printcap には 次のようになります. # # /etc/printcap for host rose - identified what devices to use # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:\ :lp=/dev/ttyd5: /etc/printcap でプリンタの /dev/lp を使用します. /dev/lp は, 現在の FreeBSD には存在していません. 設置したプリンタがパラレルポートに接続されている場合は, 「」まで読み飛ばしてください. そうでない場合は, 次節の説明に続いてください. スプーラのための通信パラメータの設定

シリアルポートにプリンタを接続した場合, プリンタにデー タを送信するフィルタプログラムに代わり, 通信速度やパリ ティ, その他のシリアル通信パラメータを設定することがで きます. このことによる利点は, /etc/printcap を編集するだけで, 様々な 通信パラメータを試してみることができます. フィルタプロ グラムを再コンパイル必要はありません. スプーリングシステムで, シリアル通信の設定が異 なっているかもしれない複数のプリンタに同じフィルタプロ グラムを使うことが可能になります. 次の /etc/printcap の項目で, br#/ デバイスの通信速度を fc#/ デバイスをオープンした後で, fs#/ xc#/ デバイスをオープンした後で, ローカルモードビット xs#/ ローカルモードビット /usr/include/sys/ioctl_compat.h を参照してく ださい. 項目 bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:\ :lp=/dev/ttyd5:fs#0x82000c1:xs#0x820: テキストフィルタのインストール

ここまでで, プリンタにジョブを送るために使うテキストフィ ルタを LPD に設定する準備が整いました. 」をご覧ください. ここでの簡単なプリンタ設定では, プリンタにジョブを送るため, /bin/cat を実行するだけの簡単なシェルスクリプ トで間に合います. FreeBSD に標準で付属している 」で詳しく説明します. 最初に, 簡単なテキストフィルタであるシェルスクリプト /usr/local/libexec/if-simple を作ってみましょ う. 次のテキストをお好みのテキストエディタでファイルに 書き込んでください. #!/bin/sh # # if-simple - Simple text input filter for lpd # Installed in /usr/local/libexec/if-simple # # Simply copies stdin to stdout. Ignores all filter arguments. /bin/cat && exit 0 exit 2 そして, このファイルを実行可能にします. chmod 555 /usr/local/libexec/if-simple LPD にこのテキストフィルタを使うことを設定するためには, /etc/printcap に /etc/printcap の例のプリンタ 2台に, このフィルタを加えてみましょう. # # /etc/printcap for host rose - added text filter # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:\ :lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:\ :if=/usr/local/libexec/if-simple: 印字してみよう

簡単な LPD 設定も終わりにたどり着きました. 残念ながら, 設定はこれでおしまいというわけではありません. なぜなら, さらに, 設定をテストし, すべての問題点を解決しなくては ならないからです. 設定をテストするために, 何かを印字し てみましょう. LPD システムで印字をするためには, 」で紹介した, あるテスト用のテキストを生成してくれる 簡単な LPD 設定をテストするために:

次のように入力してください. lptest 20 5 | lpr -P ここで, /etc/printcap で指定したプリンタ名 (もしくはその別名) です. デフォルト のプリンタを使用する場合は, !"#$%&'()*+,-./01234 "#$%&'()*+,-./012345 #$%&'()*+,-./0123456 $%&'()*+,-./01234567 %&'()*+,-./012345678 更にプリンタをテストしたい場合は, (言語ベースのプリン タのための) もっと大きなプログラムを送信するか, 引数を 変えて 」をご覧ください. トラブルシューティング

/usr/local/libexec/if-simple を次のように変更して, プリンタへジョブを送信した後に FROM FEED 文字を印字させるようにします. #!/bin/sh # # if-simple - Simple text input filter for lpd # Installed in /usr/local/libexec/if-simple # # Simply copies stdin to stdout. Ignores all filter arguments. # Writes a form feed character (\f) after printing job. /bin/cat && printf "\f" && exit 0 exit 2 !"#$%&'()*+,-./01234 "#$%&'()*+,-./012345 #$%&'()*+,-./0123456 あなたは プリンタが CR を受け取ったとき CR 動作 (復帰) をおこなう. プリンタが LF を受け取ったとき CR + LF 動作 (復帰, 改行) をおこなう. このように動作させるための方法がいくつかあります. これらの文字の解釈を変えるために, プリンタ の設定スイッチかコントロールパネルを操作する方 法. どのようにして設定をするかはプリンタのマニュ アルを参照してください.

自動的に LF を CR+LF に変換してくれる FreeBSD 用のシリアルドライバを入手する方法. も ちろん, このドライバはプリンタ専用に接続される シリアルポート/etc/printcap ファ イルで対象プリンタの LF 文字の扱いを一時的に変更するための 次に, Hewlett Packard 社の PCL エスケープコー ドに対応しているプリンタのためのテキストフィル タの例を示します. このフィルタでは, プリンタ に LF 文字を LF と CR の2文字として扱わせます. その後に, プリンタにジョブを送ります. 最後に, ジョブの最終ページの紙を排出するため, FROM FEED 文字を送ります. このフィルタは Hewlett Packard 社のほとんどすべてのプリンタで機能するは ずです. #!/bin/sh # # hpif - Simple text input filter for lpd for HP-PCL based printers # Installed in /usr/local/libexec/hpif # # Simply copies stdin to stdout. Ignores all filter arguments. # Tells printer to treat LF as CR+LF. Writes a form feed character # after printing job. printf "\033&k2G" && cat && printf "\f" && exit 0 exit 2 ホスト orchid にある /etc/printcap の 例を以下に示します. ここには, 一番目のパラレル ポートにプリンタ (Hewlett Packard LaserJet 3Si) が一台接続されており, そのプリンタ名は # # /etc/printcap for host orchid # teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\ :lp=/dev/lpt0:sh:sd=/var/spool/lpd/teak:mx#0:\ :if=/usr/local/libexec/hpif: if-simple の cat の部分 を置き換えればよいわけです. 具体的にどのように するかは, 読者への練習問題としましょう. プリンタが CR を受け取ったとき CR 動作 (復帰) をおこなう. プリンタが LF を受け取ったとき CR + LF 動作 (復帰, 改行) をおこなう. if-simple の cat の部分を置き換えればよいわけ です. 具体的にどのようにするかは, 読者への練習問題とし ましょう. プリンタが XON/XOFF のフロー制御をサポート している場合は, 項目 プリンタがキャリアフロー制御をサポートして いる場合は, 項目 プリンタがフロー制御をまったくサポートしていな い場合は, 項目 /etc/printcap ファイルで設定した 内容と一致しているかどうかも確認してください. /etc/printcap ファイルで, デバッグしているプ リンタのエントリに ( rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple:\ :lf=/var/log/rattan.log 次に, もう一度印字をおこなってみます. そして, 発生したと思 われるエラーメッセージを見るためにログファイル (上記の 例では, /var/log/rattan.log) を調べます. そこ で見られたメッセージを元に, 問題を解決してみてください. 項目 /dev/console を使います. プリンタを使う

この節では, FreeBSD で設定したプリンタを使う方法について説明 します. ここでは, ユーザレベルでのコマンドを概説します. 管理者用コマンド 」に記 します. このコマンドは, プリンタやそのキューの制御のために用い られます. /etc/printcap のように操作の対象となるプリンタやキュー を指定します. これによって, 様々なプリンタに対してジョブを送る, 取り消す, 調査することができます. 印字する

ファイルを印字するためには, 次のように入力してください. lpr これにより, 入力されたファイルのそれぞれをデフォルトのプリンタ から印字します. ファイル名が与えられなかった場合, lpr /etc/host.conf /etc/hosts.equiv 印字させるプリンタを選択するためには, 次のように入力します. lpr -P 次の例では, プリンタ ls -l | lpr -P rattan 上記の 」をご 覧ください. ジョブの処理状況を調べる

lpq -P bamboo は, プリンタ bamboo is ready and printing Rank Owner Job Files Total Size active kelly 9 /etc/host.conf, /etc/hosts.equiv 88 bytes 2nd kelly 10 (standard input) 1635 bytes 3rd mary 11 ... 78519 bytes この例では, 」をご覧ください. ジョブ番号9のジョブは2つのファイルを処理します. すなわち, waiting for bamboo to become ready (offline ?) kelly: 1st [job 009rose] /etc/host.conf 73 bytes /etc/hosts.equiv 15 bytes kelly: 2nd [job 010rose] (standard input) 1635 bytes mary: 3rd [job 011rose] /home/orchid/mary/research/venus/alpha-regio/mapping 78519 bytes ジョブの削除

印字するようジョブを送った後で印字を中断したくなったときは, 特定のプリンタへのジョブを削除するときは, lprm -P bamboo 10 上記の略記法をデフォルトプリンタではなく特定のプリンタに対して おこなうときは, lprm -P rattan - rose% lpr -P rattan myfile rose% rlogin orchid orchid% lpq -P rattan Rank Owner Job Files Total Size active seeyan 12 ... 49123 bytes 2nd kelly 13 myfile 12 bytes orchid% lprm -P rattan 13 rose: Permission denied orchid% logout rose% lprm -P rattan 13 dfA013rose dequeued cfA013rose dequeued rose% その他の印字オプション

整形と変換に関するオプション

以下の lpr -P bamboo -d fish-report.dvi このオプションは, ジョブに含まれるすべてのファイルに対して適用さ れます. したがって, 1つのジョブに (例えば) DVI ファイルと ditroff ファイルを混在させることはできません. その代わりに, ファイルを 形式毎に別々のジョブに分け, それぞれのジョブでその形式用の変換 オプションを使って印字してください. 」で説明しています. 次の例では, zcat /usr/share/man/man1/ls.1.gz | troff -t -man | lpr -t ジョブに関するオプション

以下のオプションは, 」をご覧ください.

次の例では, デフォルトプリンタで lpr -#3 parser.c parser.h ヘッダページ用オプション

以下のオプションにより, ジョブのヘッダページに通常印字さ れるテキストを 」を参照してください. 」をご覧ください. プリンタを管理する

プリンタの管理者として, プリンタの設置, 設定, そして, それ らのテストをおこなう必要がありました. プリンタの起動, 停止をおこなう. キューへの入力の許可, 禁止をおこなう. それぞれのキューにあるジョブの順番を変更する. 最初に用語に関する注意をしておきます. プリンタが/etc/printcap 内に ある全プリンタに対しておこなわれることになります. コマンドラインから上記のコマンドを入力すると, プリンタ設定上級編

この節では, 特殊な形式のファイルを印字するためのフィルタ, ヘッ ダページ, ネットワーク越しのプリンタへの印字, そして, プリンタ 使用の制限や課金について説明しています. フィルタ

LPD では, ネットワークプロトコル, キュー, アクセス制御, そ して, 印字のためのその他の側面について扱いますが, 」を参照) しかしながら, 形式変換やプリンタ課金, 特定のプリンタの癖, など をうまく利用するためには, フィルタがどのように機能するかという ことを理解しておくべきです. これらの側面を扱うためには, 最終的 には, フィルタの責任であるからです. そして, これは悪い情報です が, ほとんどの場合において, /usr/libexec/lpr/lpf というフィルタが1つ付いています. (このフィルタはファイルに含まれるバックスペースやタブを扱いま す. また, 課金をすることもできますが, できることはこれだけしか ありません.) いくつかのフィルタとフィルタの構成要素が FreeBSD の ポート集にもあります. この節で述べることは次の通りです. 「」では, 印字の過程におけ るフィルタの役割を概説します. この節を読むことで, LPD がフィルタを使うときに, 「見えないところで」何が起こっている かが理解できるでしょう. このことを知っておくと, プリン タそれぞれに様々なフィルタをインストールしたときに遭遇 するかもしれない問題を予期したり, デバッグするときに役 立つでしょう. LPD では, すべてのプリンタからデフォルトでプレインテ キストを印字できることを期待しています. このことは, プ レインテキストを直接印字できない PostScript (また は他の言語用の) プリンタでは問題を引き起こします. 「」 で, この問題を克服する方法について述べます. PostScript プリンタをお持ちの方は, この節をお読みになること をお薦めします. PostScript は様々なプログラムのための有名な出 力形式です. ある人たちは (著者自身を含めて) PostScript のコードさえも直接書いてしまいます. しかし, PostScript プリンタは高価です. 「」では, PostScript データを 「」では, 図形や組版データといっ た特定のファイル形式を, プリンタが理解できる形式へ変換 する作業を自動的におこなわせる方法について述べます. この節 を読むと, troff のデータを印字するには 「」 では, あまり使われない LPD の機能のすべて, すなわち, 出力フィルタに関することが記述されています. ヘッダページ (「」参照) を印字させていない場合は, 多分, この節は飛ばしても構わないでしょう. 「」では, 「」では, 日本語を含むテキスト を印字するためのヒントを述べてます. --> フィルタはどのように機能しているか

既に言及したように, フィルタとは, プリンタにデータを送る 際に, デバイスに依存した部分を取り扱うために LPD によって起動 される実行プログラムです. LPD がジョブ中のファイルを印字しようとするとき, LPD はフィル タプログラムを起動します. このとき, フィルタの標準入力を印字す るファイルに, 標準出力をプリンタに, そして, 標準エラー出力をエ ラーログファイル (/etc/printcap 内の /dev/console) にセットします. LPD が起動するフィルタと, その引数が何であるかは, /etc/printcap ファイルの内容と, ジョブの起動時に ユーザが指定した 」をご覧ください). /etc/printcap で指定可能なフィルタは次の3種類がありま す. [-c] -w ここで, /etc/printcap で指定された 」 で, これらに関するすべてについて説明します. プリンタの課金をする必要がある場合は, 変換フィルタでも 印字ページを数える作業が必要となります. 変換フィルタは次の引数をとって起動されます. -x ここで, 」で, これらのことについて説明し ます. アウトプットフィルタに対する引数は次の2つだけです. -w ここで, フィルタは, 次に示すの終了状態をもってプログラムを FreeBSD に付属するテキストフィルタ /usr/libexec/lpr/lpf は, FROM FEED 文字が送られたと きやプリンタ使用に対する課金をどのようにするかを決定するために, ページ幅やページ長の引数を利用します. また, 課金用のエントリを 作成するため, ログイン名, ホスト名, 課金ファイル名の引数を利用 します. もし, フィルタの購入を検討しているならば, LPD と互換性がある かどうかを確認してください. もしそうならば, 上述の引数リストをサ ポートしていなければなりません. 一般向けの使用のためにフィルタ を作成する計画をしている場合は, 同じ引数リストと終了コードをサ ポートしてください. プレインテキストのジョブを PostScript プリン タで印字する

コンピュータと PostScript (または, 他の言語に対応し た) プリンタをあなたしか使用しない場合は, プリンタにプレ インテキストを絶対に送らない, そして, プリンタにプレインテキス トを送りたがっている様々なプログラムの機能を決して使わないこと にしてください. そうすれば, この節に書かれたことに心を煩わせる必 要はまったくなくなります. しかし, PostScript とプレインテキストの両方のジョブをプリン タへ送りたいと思っている場合は, プリンタ設定についての要求が増 えるでしょう. 両者をプリンタへ送信するためには, 到着 したジョブがプレインテキストであるか PostScript であるかを 検出するテキストフィルタが必要です. PostScript のジョブは すべて 」を参照してください). もちろん,自分自身でプログラムを取ってきて, コンパイルし, インストールす ることもできます. /etc/printcap の中のシリアル接続した PostScript プリンタのエントリに対して, 次を使ってください. :if=/usr/local/libexec/psif: LPD にプリンタをリード・ライトモードでオープンさせるために, #!/bin/sh # # psif - Print PostScript or plain text on a PostScript printer # Script version; NOT the version that comes with lprps # Installed in /usr/local/libexec/psif # read first_line first_two_chars=`expr "$first_line" : '\(..\)'` if [ "$first_two_chars" = "%!" ]; then # # PostScript job, print it. # echo $first_line && cat && printf "\004" && exit 0 exit 2 else # # Plain text, convert it, then print it. # ( echo $first_line; cat ) | /usr/local/bin/textps && printf "\004" && exit 0 exit 2 fi 上記のスクリプトにおいて, 」を参照してください) には, 非 PostScript プリンタで PostScript をシミュレートする

PostScript は質の高い組版と印字をおこなうための #!/bin/sh # # ifhp - Print Ghostscript-simulated PostScript on a DesJet 500 # Installed in /usr/local/libexec/hpif # # Treat LF as CR+LF: # printf "\033&k2G" || exit 2 # # Read first two characters of the file # read first_line first_two_chars=`expr "$first_line" : '\(..\)'` if [ "$first_two_chars" = "%!" ]; then # # It is PostScript; use Ghostscript to scan-convert and print it # /usr/local/bin/gs -dSAFER -dNOPAUSE -q -sDEVICE=djet500 -sOutputFile=- - \ && exit 0 else # # Plain text or HP/PCL, so just print it directly; print a form # at the end to eject the last page. # echo $first_line && cat && printf "\f" && exit 2 fi exit 2 最後に, :if=/usr/local/libexec/hpif: これでおしまいです. 変換フィルタ

「」 に書かれた簡単な設定が完了したら, 最初に, やってみたいと思 うことは, 多分(プレイン ASCII テキストに加えて) 好みのファイル形式 のための変換フィルタをインストールすることでしょう. なぜ, 変換フィルタをインストールするのか?

変換フィルタによって, 様々な種類のファイルを印字するこ とが簡単になります. 例えば, TeX 組版システムでたくさんの仕事 をしたと仮定しましょう. そして, PostScript プリンタが接続 されているとします. すると, TeX で DVI ファイルを作成する度に, DVI ファイルを印字するために, これを PostScript ファイルに 変換する必要があります. このコマンドは次のようになるでしょう. dvips seaweed-analysis.dvi lpr seaweed-analysis.ps DVI ファイル用の変換フィルタがインストールしてあると, LPD に 変換を肩代わりさせることで毎回毎回おこなわなければならなかった面倒 な変換作業を省くことができます. つまり, DVI を生成したら, 次のような1回のコマンド入力だけで, これが印字されます. lpr -d seaweed-analysis.dvi LPD に DVI ファイルの変換をさせるためには, 」に載せてあります. 変化のオプションのそれぞれをプリンタにサポートさせるためには, /etc/printcap の中で指定しなくてはなりません. 変換フィ ルタは, プレインテキストを印字する代わりに, フィルタはファイル をプリンタが理解できる形式に変換するところを除けば, 「プリンタ の簡単な設定」で説明したテキストファイル (「」 を見て下さい) に似ています. どの変換フィルタをインストールすべきか?

使いたいと思う変換フィルタをインストールすべきです. DVI のデータを頻繁に印字するならば, DVI 変換フィルタ をインストールするのが適切でしょう. 印字しなくてはなら ない troff を大量に抱えている場合は, 多分, troff フィ ルタが欲しくなるはずです. 次の表は, LPD で動作するフィルタと, /etc/printcap ファイルでのエントリする項目, そして, /etc/printcap ファイル形式 項目 lpr オプション ------------ ------------- ---------- cifplot cf -c DVI df -d plot gf -g ditroff nf -n FORTRAN text rf -f troff tf -t raster vf -v プレインテキスト if なし, -p, または -l 先の例のように, /etc/printcap 内のエントリで, 変換フィルタのインストール

変換フィルタは FreeBSD の基本システムのインストールとは別 にインストールするプログラムなので, 変換フィルタは, 多 分, /usr/local ディレクトリの下に置くべ きです. フィルタは LPD だけが実行する特別なプログラム, すなわち, 一般ユーザが実行する必要すらない プログラムなので, /usr/local/libexec ディレ クトリに置くのが普通です. 変換フィルタを使用可能にするためには, /etc/printcap の目的のプリンタの適切な項目に フィルタがあるパス名を指定します. DVI 変換フィルタをプリンタ /etc/printcap ファイルの例を以下 に再掲します. # # /etc/printcap for host rose - added df filter for bamboo # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:\ :lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf: DVI フィルタは /usr/local/libexec/psdf という 名前のシェルスクリプトです. このスクリプトは次のように なっています. #!bin/sh # # psdf - DVI to PostScript printer filter # Installed in /usr/local/libexec/psdf # # Invoked by lpd when user runs lpr -d # exec /usr/local/bin/dvips -f | /usr/local/libexec/lprps "$@" このスクリプトでは, 」 を参照してください) を LPD に与えられた引数を付けて起動 します. 変換フィルタのその他の例

変換フィルタのインストールには決まったステップがないの で, その代わりに, 例をもっと挙げることにします. これを, 自分でフィルタを作る際のガイドにしてください. 適当な例が あったら, それをそのまま使ってください. 次のスクリプト例は, Hewlett Packard LaserJet III-Si の ための, raster (ええと・・実は, GIF ファイル) 用の変 換フィルタです. #!/bin/sh # # hpvf - Convert GIF files into HP/PCL, then print # Installed in /usr/local/libexec/hpvf PATH=/usr/X11R6/bin:$PATH; export PATH giftopnm | ppmtopgm | pgmtopbm | pbmtolj -resolution 300 \ && exit 0 \ || exit 2 ここでは, GIF ファイルから PNM (portable anymap) 形式 に変換し, 次に PGM (portable graymap) 形式に変換してか ら, LaserJet/PCL-互換データに変換しています. 上記のフィルタを使うプリンタのためのエントリを付け加え た /etc/printcap ファイルは次のようになります. # # /etc/printcap for host orchid # teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\ :lp=/dev/lpt0:sh:sd=/var/spool/lpd/teak:mx#0:\ :if=/usr/local/libexec/hpif:\ :vf=/usr/local/libexec/hpvf: 次のスクリプトは, PostScript プリンタ #!/bin/sh # # pstf - Convert groff's troff data into PS, then print. # Installed in /usr/local/libexec/pstf # exec grops | /usr/local/libexec/lprps "$@" 上記のスクリプトではプリンタとの通信をおこなうため, #!/bin/sh # # pstf - Convert groff's troff data into PS, then print. # Installed in /usr/local/libexec/pstf # exec grops これで完成しました. 次に, フィルタを使用可能にするため に /etc/printcap に加える必要があるエントリを 示します. :tf=/usr/local/libexec/pstf: 次の例をみたら, FORTRAN のベテランは赤面するかもしれ ません. この FORTRAN テキストフィルタは, プレインテキ ストを直接印字できるすべてのプリンタで利用できます. この フィルタをプリンタ #!/bin/sh # # hprf - FORTRAN text filter for LaserJet 3si: # Installed in /usr/local/libexec/hprf # printf "\033&k2G" && fpr && printf "\f" && exit 0 exit 2 そして, このフィルタを使用可能にするため, 以下の行を /etc/printcap のプリンタ :rf=/usr/local/libexec/hprf: これが最後の, そして, 若干複雑な例です. 前に紹介した LaserJet プリンタ /etc/printcap に書 き加えます. :df=/usr/local/libexec/hpdf: さて, 難しい部分であるフィルタの作成をおこないます. このた めに, DVI から LaserJet/PCL への変換プログラムが必要 です. FreeBSD のポート集 (「」を参照してください) には, それがあ ります. /dev/fd/0 を使うのは問題がありま す. この問題は, (/dev/fd/0 に (シンボリックな) リンクを張る ことで回避することができます. これで, /tmp ディレクトリはスティッ キービットが立っています. フィルタはリンクを作ることが できます. しかし, リンクは別のユーザに所有されているた め, 作業が終了したとき, このリンクを削除することができ ません. その代わりに, シンボリックリンクは現在の作業ディレクト リ, すなわち, スプーリングディレクトリ (/etc/printcap の /tmp ディレクトリ よりもたくさんあるからです. 以下に示すのが最後のフィルタです. #!/bin/sh # # hpdf - Print DVI data on HP/PCL printer # Installed in /usr/local/libexec/hpdf PATH=/usr/local/bin:$PATH; export PATH # # Define a function to clean up our temporary files. These exist # in the current directory, which will be the spooling directory # for the printer. # cleanup() { rm -f hpdf$$.dvi } # # Define a function to handle fatal errors: print the given message # and exit 2. Exiting with 2 tells LPD to do not try to reprint the # job. # fatal() { echo "$@" 1>&2 cleanup exit 2 } # # If user removes the job, LPD will send SIGINT, so trap SIGINT # (and a few other signals) to clean up after ourselves. # trap cleanup 1 2 15 # # Make sure we are not colliding with any existing files. # cleanup # # Link the DVI input file to standard input (the file to print). # ln -s /dev/fd/0 hpdf$$.dvi || fatal "Cannot symlink /dev/fd/0" # # Make LF = CR+LF # printf "\033&k2G" || fatal "Cannot initialize printer" # # Convert and print. Return value from dvilj2p does not seem to be # reliable, so we ignore it. # dvilj2p -M1 -q -e- dfhp$$.dvi # # Clean up and exit # cleanup exit 0 自動変換: その他の変換フィルタ

ここまでに述べてきたフィルタによって, 印字環境の能率が 上がったことと思います. しかし, これはどのフィルタを使 うかを ( 出力フィルタ

LPD スプーリングシステムでは, ここまでにまだ取り上げていな いフィルタ形式, 出力フィルタをサポートしています. 出力 フィルタは, テキストフィルタのように, プレインテキスト のみを印字するために意図されたものですが, 非常に簡単化 されています. テキストフィルタを用いずに, 出力フィルタ を使っている場合は, 次のようになります. LPD はジョブ中の各ファイルに一度ではなく, ジョブ 全体に対して一度だけ出力フィルタを起動します. LPD は出力フィルタに対し, ジョブ中のファイルの先 頭や末尾を特定するための対策を一切おこなっていません. LPD はユーザのログイン名やホスト名をフィルタに渡 しません. したがって, 課金の処理をおこなうことは考えてい ません. 実際, 出力フィルタには, 以下2つの引数しか与え られません. -w ここで, 出力フィルタの簡便さに誘惑されてはいけません. もし, ジョ ブ中のそれぞれのファイルに別のページ番号を付加しようと しても, 出力フィルタは」をご覧ください. さらに, 出力 フィルタは, 実のところ, 」 を参照してください) だけを印字させるために, 出 力フィルタを起動させます. それから LPD では, アウトプッ トフィルタに2バイトの文字 (ASCII 031 の次に ASCII 001) を送ることで, 出力フィルタが テキストフィルタ

プログラム /usr/libexec/lpr/lpf は, FreeBSD の バイナリ配布に付属しているテキストフィルタ (入力フィル タ) で, 出力を字下げしたり (/etc/printcap ファイルの中の 」をご覧ください. ヘッダページ

あなたが管理するシステムのユーザが」をご覧ください. ヘッダページの印字を許可する

「」 では, /etc/printcap ファイルの #!/bin/sh # # hpof - Output filter for Hewlett Packard PCL-compatible printers # Installed in /usr/local/libexec/hpof printf "\033&k2G" || exit 2 exec /usr/libexec/lpr/lpf 」 をご覧ください. 次に, 以前紹介したプリンタ /etc/printcap ファイルの例を示します. ここでは, ヘッ ダページの印字を許可し, 上記の出力フィルタを追加しました. # # /etc/printcap for host orchid # teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\ :lp=/dev/lpt0:sd=/var/spool/lpd/teak:mx#0:\ :if=/usr/local/libexec/hpif:\ :vf=/usr/local/libexec/hpvf:\ :of=/usr/local/libexec/hpof: さて, ユーザが 」 をご覧ください. /etc/printcap 中の ヘッダページを制御する

ヘッダページの印字が許可されていると, LPD は k ll ll k l l k l l k k eeee l l y y k k e e l l y y k k eeeeee l l y y kk k e l l y y k k e e l l y yy k k eeee lll lll yyy y y y y yyyy ll t l i t l oooo u u ttttt l ii n nnn eeee o o u u t l i nn n e e o o u u t l i n n eeeeee o o u u t l i n n e o o u uu t t l i n n e e oooo uuu u tt lll iii n n eeee r rrr oooo ssss eeee rr r o o s s e e r o o ss eeeeee r o o ss e r o o s s e e r oooo ssss eeee Job: outline Date: Sun Sep 17 11:04:58 1995 LPD はこのテキストの終わりに FROM FEED 文字を加えます ので, ジョブは新しいページから開始されます (ただし, /etc/printcap で出力先のプリンタのエントリに /etc/printcap ファ イルの中で rose:kelly Job: outline Date: Sun Sep 17 11:07:51 1995 デフォルトでは, LPD はヘッダページを最初に印字し, 次 にジョブの印字をおこないます. この順番を逆にするときは, /etc/printcap で ヘッダページに対する課金

LPD に備わっているヘッダページ出力機能を使うと, 入力され たジョブに対して課金をおこなうことができても, ヘッダページは LPD のやり方を受け入れ, ヘッダページは無料とする. LPDng や PLP といった LPD の代替品をインストール する. LPD と入れ替えが可能な他のスプーリングソフトウェ アに関しては, 「」をご覧ください. /etc/printcap で PostScript プリンタでのヘッダページ

これまでに述べたように, LPD ではプレインテキストのヘッ ダページをたくさんのプリンタに合うように生成することができます. 残念ながら, PostScript プリンタは, プレインテキストを直接 印字することができません. ですから, LPD のヘッダページ機能は まったく役に立たない, あるいはほとんどの場合で役に立ちません. ヘッダページを出力するための自明な方法の1つに, すべての変換フィ ルタとテキストフィルタにヘッダページを生成させる方法があります. フィルタは, 適切なヘッダページを生成するために, ユーザ名とホス ト名の引数を使うべきです. この方法の欠点は, いつでも, #!/bin/sh # # make-ps-header - make a PostScript header page on stdout # Installed in /usr/local/libexec/make-ps-header # # # These are PostScript units (72 to the inch). Modify for A4 or # whatever size paper you are using: # page_width=612 page_height=792 border=72 # # Check arguments # if [ $# -ne 3 ]; then echo "Usage: `basename $0` " 1>&2 exit 1 fi # # Save these, mostly for readability in the PostScript, below. # user=$1 host=$2 job=$3 date=`date` # # Send the PostScript code to stdout. # exec cat < そして, 変換フィルタやテキストフィルタがそれぞれ, 最初にこのス クリプトを起動することで, ヘッダページが出力され, それから, ユー ザのジョブの印字をおこないます. 次に, このドキュメントの始めのほう で紹介した DVI 変換フィルタを, ヘッダページを印字するように変 更したものを示します. #!/bin/sh # # psdf - DVI to PostScript printer filter # Installed in /usr/local/libexec/psdf # # Invoked by lpd when user runs lpr -d # orig_args="$@" fail() { echo "$@" 1>&2 exit 2 } while getopts "x:y:n:h:" option; do case $option in x|y) ;; # Ignore n) login=$OPTARG ;; h) host=$OPTARG ;; *) echo "LPD started `basename $0` wrong." 1>&2 exit 2 ;; esac done [ "$login" ] || fail "No login name" [ "$host" ] || fail "No host name" ( /usr/local/libexec/make-ps-header $login $host "DVI File" /usr/local/bin/dvips -f ) | eval /usr/local/libexec/lprps $orig_args このフィルタがユーザ名やホスト名を決定するために引数リストをど のように解析しなくてはならないかという点に注意してください. こ の解析方法は他の変換フィルタに対しても同様です. しかしながら, テキストフィルタについては, 引数の設定が少し異なっています (こ れについては, 「」をご覧ください). 前述の通り, 上記の手法は, 極めて単純なのにも関らず, 」で紹介したトリックを使う必要があります. すな わち, LPD が生成するヘッダページの解析をおこない, PostScript 版のヘッダページを出力させる出力フィルタを作るのです. この場 合, ユーザが リモートプリンタからの出力

FreeBSD では, ネットワーク越しの印字, すなわち, ジョブをリ モートプリンタに送ることをサポートしています. リモートプリンタ からの出力をするには, 一般に, 次の2つを参照してください. リモートホストに接続されたプリンタにアクセスする方 法. プリンタがあるホストのシリアル, または, パラレルイ ンタフェースに接続されている場合, ネットワーク上の他の ホストからこのプリンタにアクセスできるように LPD を設 定します. 「」でどのよう にするかを説明します. ネットワークに直接接続されているプリンタにアクセ スする方法. プリンタに, 旧来のシリアル, または, パラレ ルインタフェースに加えて (もしくは, これらに代わって) ネッ トワーク用のインタフェースがある場合. そのようなプリン タは次のように動作するでしょう. そのプリンタが LPD のプロトコルを理解でき, リモー トホストからのジョブをキューに入れることさえできる場合. この場合, プリンタは, LPD が起動している一般のホスト のように振る舞います. そのようなプリンタを設定するため に, 「」と同様の手 順をおこなってください. そのプリンタが, データストリームによるネットワー ク接続をサポートしている場合. この場合, ネットワーク上 の1つのホストとしてプリンタを「接続」します. このホス トは, ジョブをスプーリングする責任を負い, スプーリング されたジョブはプリンタに送られます. そのようなプリンタ をインストールするためのいくつかの提案が「」にあります. リモートホストに接続されたプリンタ

LPD スプーリングシステムでは LPD (または LPD 互換のシス テム) が起動している他のホストへジョブを送る機能が始めからサポー トされています. この機能により, あるホストに接続されたプリンタ へ, 他のホストからアクセスできるようになります. また, LPD プ ロトコルを理解するネットワークインタフェースを持ったプリンタに 対しても, この機能は働きます. リモートプリンタへの出力を許可するためには, 最初に, あるホスト (これを, 」に書かれた簡単なプリンタの設定をおこなってください. 必要ならば, 「」にあ る, 更に進んだ設定をおこなってください. そして, そのプリンタをテス トしてうまく動作することを確認し, LPD に許可した機能がうまく働 くかどうかを見てください. LPD 互換のネットワークインタフェースを持つプリンタを使用してい る場合は, そのプリンタ自身が以下で説明する/etc/printcap ファイルに次にあげるエント リを作ります. 名前のエントリ. どんな名前でもよいのですが, 簡単 のため, 多分, プリンタホストで設定されたプリンタ名や別 名と同じものを使いたいと思うでしょう. スプーリングディレクトリを作成し, これで終わりです. 変換フィルタやページの大きさやその他の事項を /etc/printcap に加える必要はありません. 次に, リモートホストに接続されたプリンタで印字するための設定例 を示します. ホスト rose には2台のプリンタ /etc/printcap を示します (このファイルは, 「」で参照することができます). このファイルには, 既に, プリンタ # # /etc/printcap for host orchid - added (remote) printers on rose # # # teak is local; it is connected directly to orchid: # teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\ :lp=/dev/lpt0:sd=/var/spool/lpd/teak:mx#0:\ :if=/usr/local/libexec/ifhp:\ :vf=/usr/local/libexec/vfhp:\ :of=/usr/local/libexec/ofhp: # # rattan is connected to rose; send jobs for rattan to rose: # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :lp=:rm=rose:rp=rattan:sd=/var/spool/lpd/rattan: # # bamboo is connected to rose as well: # bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :lp=:rm=rose:rp=bamboo:sd=/var/spool/lpd/bamboo: orchid で必要となる作業はスプーリングディレクトリを作ることだ けです. mkdir -p /var/spool/lpd/rattan /var/spool/lpd/bamboo chmod 770 /var/spool/lpd/rattan /var/spool/lpd/bamboo chown daemon.daemon /var/spool/lpd/rattan /var/spool/lpd/bamboo これで, orchid のユーザが lpr -P bamboo -d sushi-review.dvi すると, orchid の LPD システムは, ジョブをスプーリングディレ クトリ /var/spool/lpd/bamboo にコピーし, これが DVI ファイルを印字するジョブであることを記録します. ホスト rose の ネットワークにおけるデータストリームのインタ フェースを持つプリンタ

プリンタのネットワークインタフェースカードは, 2種類に分 類することができます. 1つはスプーラをエミュレートするもの (高価) で, もう1つはシリアルやパラレルポートを使うようにプリンタにデー タを送ることができるだけのもの (安価) です. この節では, 後者の使 い方を説明します. 前者のプリンタは, 前節「」 の方法が適用できます. /etc/printcap ファイルでは, シリアルかパラレルのイン タフェースのどちらを使うのか, そして, (シリアルインタフェース を使う場合) そのボーレートはいくらであるか, フロー制御は使うのか, タブのための遅延を加えるのか, 改行文字を変換するかなどの指定を おこなうことができます. しかし, TCP/IP や他のネットワークポートか らデータを受け取るプリンタを接続するための指定をおこなうことはでき ません. ネットワーク接続されたプリンタにデータを送るためには, テキスト フィルタと変換フィルタから呼び出すことができる通信プログラムを 開発する必要があります. 以下に, そのようなプログラムの例を示し ます. スクリプト #!/usr/bin/perl # # netprint - Text filter for printer attached to network # Installed in /usr/local/libexec/netprint # $#ARGV eq 1 || die "Usage: $0 "; $printer_host = $ARGV[0]; $printer_port = $ARGV[1]; require 'sys/socket.ph'; ($ignore, $ignore, $protocol) = getprotobyname('tcp'); ($ignore, $ignore, $ignore, $ignore, $address) = gethostbyname($printer_host); $sockaddr = pack('S n a4 x8', &AF_INET, $printer_port, $address); socket(PRINTER, &PF_INET, &SOCK_STREAM, $protocol) || die "Can't create TCP/IP stream socket: $!"; connect(PRINTER, $sockaddr) || die "Can't contact $printer_host: $!"; while () { print PRINTER; } exit 0; このスクリプトは, 様々なフィルタが利用することができます. 仮に, Diablo 750-N ラインプリンタを持っており, これがネットワークに 接続されているとしましょう. プリンタはポート番号5100にて印字す るデータを受け取ります. プリンタのホスト名は scrivener としま す. このとき, このプリンタのテキストフィルタは次のようになりま す. #!/bin/sh # # diablo-if-net - Text filter for Diablo printer `scrivener' listening # on port 5100. Installed in /usr/local/libexec/diablo-if-net # exec /usr/libexec/lpr/lpf "$@" | /usr/local/libexec/netprint scrivener 5100 プリンタの利用に制約を与える

本節では, プリンタの利用に制約を与えるための情報を記して います. LPD システムでは, プリンタ (ローカル, リモートのいずれ に接続されていても) にアクセスできる人を制限する機能, 複数部の コピーの印字の可否を制御する機能, ジョブのサイズの最大値やプリ ンタキューに入るジョブの最大個数を制御する機能を提供しています. 複数部のコピーの印字を制限する

LPD システムではユーザが複数部のコピーの印字を簡単におこなう 機能を提供しています. ユーザが, (例えば) /etc/printcap ファイルに lpr: multiple copies are not allowed リモートホストからプリンタをアクセスできる設定にしている場合 (この 設定については, 「」をご覧ください), その リモートホストの /etc/printcap にも同じように /etc/printcap ファ イルは, ホスト rose のものです. プリンタ # # /etc/printcap for host rose - restrict multiple copies on bamboo # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:sc:\ :lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf: さらに, orchid の /etc/printcap にも # # /etc/printcap for host orchid - no multiple copies for local # printer teak or remote printer bamboo teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\ :lp=/dev/lpt0:sd=/var/spool/lpd/teak:mx#0:sc:\ :if=/usr/local/libexec/ifhp:\ :vf=/usr/local/libexec/vfhp:\ :of=/usr/local/libexec/ofhp: rattan|line|diablo|lp|Diablo 630 Line Printer:\ :lp=:rm=rose:rp=rattan:sd=/var/spool/lpd/rattan: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :lp=:rm=rose:rp=bamboo:sd=/var/spool/lpd/bamboo:sc: lpr forsale.sign forsale.sign forsale.sign forsale.sign forsale.sign このような悪用を防ぐ方法は (その指示を無視することも含めて) たく さんあります. 各自で調べてみてください. プリンタを使用できる人を限定する

それぞれのプリンタを使用できる人を限定するには, UNIX の グループ権限のメカニズムを利用し, さらに, /etc/printcap で lpr: Not a member of the restricted group 」をご覧ください), かつ, そ のホストでもプリンタを使用できる人を限定するのが妥当であると思 う場合は, そのホストの /etc/printcap にも /etc/printcap を示します. # # /etc/printcap for host rose - restricted group for bamboo # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:sc:rg=artists:\ :lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf: これ以外の /etc/printcap ファイル (ホスト orchidのもの) はそのままにしておくことにします. もちろん, orchid のユーザは 全員 入力可能なジョブのサイズを制限する

たくさんのユーザからプリンタが利用される場合には, 多分, ユーザが印字要求を出すことができるファイルのサイズに上限値を置 く必要が生じるでしょう. 結局のところ, スプーリングディレクトリ が置かれているファイルシステムの空き容量がその上限値になる訳で すが, あるユーザがこれを独占的に使用すること避けるために, 他ユー ザからのジョブ用の空き容量を確保する必要もあります. LPD では, # # /etc/printcap for host rose # # # No limit on job size: # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple: # # Limit of five megabytes: # bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:sc:rg=artists:mx#5000:\ :lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf: この場合もそうですが, この制限はローカル (ホスト rose) のユーザ のみに適用されます. リモートホストからプリンタを利用できるよう に設定している場合は, そのリモートホストのユーザはこの制限を受 けません. これらのユーザにも制限を加える場合は, リモートホスト の /etc/printcap の 」を参照してください. リモートホストに接続されたプリンタへのジョブのサイズを制限する 特別な方法は他にもあります. これについては, 「」を参照してください. リモートホストからのプリンタの利用を制限する

LPD スプーリングシステムでは, リモートホストから要求され たジョブの印字を制限するための方法がいくつか提供されています. /etc/hosts.equiv と /etc/hosts.lpd によって制御することができます. LPD では, あるホストから印字の要求がきたとき, このホス トの名前がこれら2つのファイルのどちらかに含まれている かどうかを調べます. これが含まれていない場合は, LPD はこの要求を拒否します. これらのファイルの形式は単純です. 各行にホストの名前を 1つずつ書いていきます. ファイル /etc/hosts.equiv の方は ruserok(3) プロトコル でも利用され, /etc/hosts.equiv の記述は慎重におこないましょう. 例として, 以下にホスト rose の /etc/hosts.lpd を示します. orchid violet madrigal.fishbaum.de この例では, rose はホスト orchid, violet, そして madrigal.fishbaum.de からの要求を受け付けることになり ます. その他のホストが rose の LPD にアクセスしようと しても, LPD はこれを拒否します (訳注:拒否されるのは, そのホストが /etc/hosts.equiv にも含まれてい ない場合です). /etc/printcap を調べてみましょ う. 以下に, bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:sc:rg=artists:mx#5000:\ :lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:mx#5000:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf: スプーリングディレクトリは echo 6144 > /var/spool/lpd/bamboo/minfree /etc/printcap の /usr/bin/false などを指定 して, これらのユーザのアカウントはプリンタ用の「形式的 な」ものとします. プリンタの利用に対する課金

という訳で, 印字するためには料金をとることが必要です. 取ら ない理由などありましょうか. 紙やインクにはお金がかかります. そ して, プリンタの維持費もかかります. プリンタには可動部分が搭載 されており, これらの部分は壊れやすいという傾向があります. プリ ンタや, その利用形態, 維持費について調査をし, 1ページ (1フィー ト, 1メートルなど) 当たりにかかるコストを調べておいてください. これに基づき, プリンタの利用に対する課金を, 実際に, どのように 始めればよいのでしょうか. さて, 残念ながら, この部分に関しては LPD スプーリングシステム はほとんど役に立ちません. 課金は使用しているプリンタの種類, 印 字するもののファイルの形式, プリンタの利用に対する課金での」をご覧く ださい. 一般に, 課金方式には次の2つがあります. LPD スプーリングシステムでは, 両方式を簡単にですがサポー トしています. これは, (ほとんどの場合で) 印字作業をフィ ルタがおこなっていたように, 課金作業もこのためのコードも用 意することで実現されています. しかし, 明るい面もありま す. それは, 課金方式に関して, 非常に大きな柔軟性が与え られたということです. 例えば, 「定期的に課金する方法」 か, 「利用毎に課金する方法」のどちらかを選びまず, そし て, どんな情報 (ユーザ名, ホスト名, ジョブのタイプ, 印 字された頁数, 使用した紙の大きさ, 印字をするために要した 時間など) をログに記録するかを決めます. 以上のことをおこな うには, 上記の情報を保持するために, フィルタを変更しな くてはなりません. 手軽なプリンタ課金方法

FreeBSD には, 「定期的に課金する方法」による課金をすぐに 設定できるように, 2個のプログラムを添付しています. そ の内の1つはテキストフィルタ 」をご覧ください. もう1つは, 」で述べたように, LPD では テキストフィルタや変換フィルタを起動しますが, そのコマ ンドラインで使用している課金データファイルの名前が指定 されます. 両フィルタはこの引数を使って, どの課金データ ファイルのエントリに書き込めばよいのかを知ることができ ます. このファイルの名前は /etc/printcap 中の 2.00 rose:andy 3.00 rose:kelly 3.00 orchid:mary 5.00 orchid:mary 2.00 orchid:zhang 課金データファイルはプリンタ毎に分けて作るべきです. こ れは, /etc/printcap 中の Login pages/feet runs price orchid:kelly 5.00 1 $ 0.10 orchid:mary 31.00 3 $ 0.62 orchid:zhang 9.00 1 $ 0.18 rose:andy 2.00 1 $ 0.04 rose:kelly 177.00 104 $ 3.54 rose:mary 87.00 32 $ 1.74 rose:root 26.00 12 $ 0.52 total 337.00 154 $ 6.74 /etc/printcap の /etc/printcap の Login pages/feet runs price andy 2.00 1 $ 0.04 kelly 182.00 105 $ 3.64 mary 118.00 35 $ 2.36 root 26.00 12 $ 0.52 zhang 9.00 1 $ 0.18 total 337.00 154 $ 6.74 課金額を決めるために, /etc/printcap ファ イルの pac -p1.50 このオプションを使うと, 実際の課金額を集計することができます. 最後に, 印字されたページ数をどのように数えるか?

課金を, リモートホストからの印字でさえも, 正確におこなうため には, ジョブで使用された紙が何ページであるかを特定でき る必要があります. このことは, プリンタ利用に対する課金 をおこなう上の根本的な問題です. プレインテキストのジョブの場合, 問題を解決するのはさほ ど難しくはありません. ジョブが何行であったかを数え, プ リンタがサポートしている紙1ページに印字できる最大の行 数と比較すればよいのです. 重ね打ちするために利用される ファイル中のバックスペース文字や, 物理的に複数の行に渡 る長い論理行に対する取り扱いを忘れずにおこなってください. (「」で紹介した) テキストフィルタ 標準スプーラの代替品

このマニュアルを最初から通読されている方ならば, ここまでで, FreeBSD 付属の LPD スプーリングシステムに関して知っておくべき ことすべてを学ばれたことと思います. 多分, このシステムに あるたくさんの欠点について認識できたことでしょう. すると, 「(FreeBSD 上で動作する) スプーリングシステムには他にどのような ものがあるのか」という疑問が自然と湧いてきます. 残念ながら, 著者は代替のスプーラを 」です. 「」にもあります. PLP は BSD LPD スプーラと極めて似ていますが, 以下のも のを含むホストの機能が自慢です. ネットワークサポートの強化. ネットワーク接続され るプリンタのサポートや NIS で管理可能な printcap ファ イル, NFS マウントされるスプーリングディレクトリの機 能が組み込まれています. 洗練されたなキュー管理. 1つのキューで複数のプリン タに対応可能. キュー間でジョブを転送したり, キューのリ ダイレクトができます. リモートプリンタの制御機能 ジョブの優先順位付け 拡張性のあるセキュリティとアクセスオプション 」です. 謝辞

このドキュメントの開発の手助けをして頂いた以下の方々に感謝の 意を表わしたいと思います. diff --git a/ja/handbook/quotas.sgml b/ja/handbook/quotas.sgml index 9fc117c6a4..6019f733e9 100644 --- a/ja/handbook/quotas.sgml +++ b/ja/handbook/quotas.sgml @@ -1,227 +1,226 @@ + + + + ディスク クォータ

原作: &a.mpp; 26 February 1996 .

訳者: &a.mihoko; 6 September 1996 . クォータシステムは、オペレーティングシステムのオプション機能で、 各ファイルシステム上で ユーザやグループのメンバが使用するディスク スペースの総量を規制したり、作成できるファイルの個数を制限したりす ることができます。 この機能は、各ユーザ、各グループごとに使用できる資源の総量を制限で きるようなタイムシェアリングシステム上でもっともよく使用されていま す。これは、一人のユーザが、使用可能な全てのディスクスペースを使い きってしまうことを防止できます。 ディスククォータを使用するための設定

ディスククォータを使用しようとする前に、あなたが使用しているカー ネルで、クォータが組み込まれているかどうかを確認する必要があります。 クォータを使用できるカーネルを構築するためには、カーネルコンフィギュ レーションファイルに、次の行を追加してください: options QUOTA 標準のGENERIC カーネルでは、この機能は有効になっていません。 したがって、ディスククォータを使用するためには、 カーネルをコンフィグレーションして構築しなおし、そのカーネ ルをインストールしなければいけません。カーネルの構築方法について の詳細情報は、 を参照してください。

次に、ファイル /etc/sysconfig の中で、ディスククォー タ機能を、使用可能に設定する必要があります。 そのためには、以下の行を変更します: quotas=NO を次のように: quotas=YES

最後に、各ファイルシステム毎にディスククォータを設定する ために、ファイル /etc/fstab を編集する必要があります。 全てのファイルシステムに対して、ユーザ又はグループのいずれかのクォー タを設定することも、ユーザとグループの両方のクォータを設定すること もできます。

ファイルシステム上で、ユーザ毎のクォータを設定するためには、 userquota オプションを、ファイル /etc/fstab の中 で、クォータを設定したいファイルシステムのエントリののオプションフィー ルドに追加してください。 例えば: /dev/sd1s2g /home ufs rw,userquota 1 2

同様に、グループのクォータを設定するためには、 groupquota オプションを userquota の代わりに使用 してください。ユーザとグループの両方のクォータを設定するためには、 次のようにエントリを変更してください: /dev/sd1s2g /home ufs rw,userquota,groupquota 1 2

デフォルトでは、クォータファイルは ファイルシステムの root ディ レクトリ上に、ユーザとグループのクォータに対して それぞれ quota.user と quota.group という名前で置いてあり ます。詳細情報は、man fstab を御覧ください。 man ページには、クォータファイルを別な場所に置くことができると書い てありますが、さまざまな クォータユーティリティのうち、この機能を 適切に処理できていないものがあるので、クォータファイルをデフォルト の場所以外に置くことは勧められません。

ここまで準備ができたら、新しいカーネルを使って、システムを立ち 上げ直してください。 /etc/rc ファイルが、自動的に適切なコマンドを起動してくれ 、あなたが /etc/fstab ファイルで使用可能にした全てのクォー タに対して、初期クォータファイルを作成してくれます。 したがって、手動で サイズ 0 のクォータファイルを作成する必要はあり ません。

通常の作業の流れでは、手動で quotacheck、 quotaon、または quotaoff コマンドを起動すべきで はありません。しかしながら、それらの作業について詳しく知りたい場合に は、man ページを御覧ください。 クォータ制限の設定

一旦システムのクォータを有効に設定したら、 本当にクォータが使用可能になっていることを確かめてください。 これを簡単に確かめるには、quota -v コマンドを実行してみて ください。ディスク使用量の総計と、クォータが設定されている各ファイ ルシステム毎の現在のクォータ制限が表示されます。

さてこれで、edquota コマンドによって、クォータ制限をか ける準備ができました。

ユーザまたはグループが使用できるディスクスペースの総計や、作成 することのできるファイル数に制限をかけるためのオプションがいくつか あります。 ディスクスペース容量規制 (ブロッククォータ) または ファイ ル数制限 (iノードクォータ) またはその両方を行うことができます。 これらの個々の制限は、二つのカテゴリ、すなわち ハード制限とソ フト制限、でもっと細かく分類できます。

ハード制限は越えることができません。ユーザがハード制限に到達す ると、該当するファイルシステム上でディスクスペースを確保することが できなくなります。 例えば、もしユーザがファイルシステム上で 500 ブ ロックのハード的制限をされていて、かつ、現在、490 ブロック使用して いたとすると、ユーザはあと 10 ブロックしか確保できません。 １１ブロック目を確保しようとすると、失敗します。

一方、ソフト制限は、定められたある一定の期間以内ならば制限を越 えることができます。この一定期間は、猶予期間と呼ばれています。 猶予期間のデフォルトは 1週間です。もし、ユーザが猶予期間を過ぎても ソフト制限を越えて使用し続けていた場合には、ソフト制限はハード制限 に切り替わり、もはやこれ以上は、ディスクスペースを確保できなくなり ます。ユーザのディスク使用量がソフト制限以下に戻った時に、猶予期間 がリセットされます。

以下は、edquota コマンドを実行した時の出力例です。 edquota コマンドが起動されると、EDITOR 環境変数 で定義されたエディタ、または、EDITOR 環境変数が設定されて いない場合には vi エディタが起動され、クォータ制限を編集 することができます。 # edquota -u test Quotas for user test: /usr: blocks in use: 65, limits (soft = 50, hard = 75) inodes in use: 7, limits (soft = 50, hard = 60) /usr/var: blocks in use: 0, limits (soft = 50, hard = 75) inodes in use: 0, limits (soft = 50, hard = 60) 通常は、クォータが設定されているファイルシステム毎に2行の表示が 行われます。1行は、ブロック制限に関する情報で、もう1行は、i ノード 制限に関する情報です。クォータ制限の値を変更したい値に書き換えてく ださい。例えば、ユーザのブロック制限を、50 ブロックまでのソ フト制限と 75 ブロックまでのハード制限から、500 ブロックまでのソフ ト制限と 600 ブロックまでのハード制限にしたい場合は、 次のように書き換えます: /usr: blocks in use: 65, limits (soft = 50, hard = 75) を次のように: /usr: blocks in use: 65, limits (soft = 500, hard = 600) 新しいクォータ制限は、エディタを終了した時に置き換えられます。

uid の範囲によってクォータを設定する個とも可能です。 そのためには edquota コマンドで、-p オプションを 使用します。まずはじめに、かけたいクォータ制限を、一人のユーザに対 して設定します。それから次のコマンドを実行します edquota -p protouser startuid-enduid。 例えば、もし、ユーザ test がクォータ制限をかけられていた とすると、次のコマンドは、同じ制限を、uid 10,000 から 19,999 まで のユーザにかけることができます: edquota -p test 10000-19999

uid の範囲によって制限をかけることができる機能は、2.1 がリリー スされたあとに追加されました。もし、2.1 のシステム上で、この機能を 必要とする場合には、新しい edquota を入手する必要があります。

詳細情報は man edquota を御覧ください。 クォータ制限およびディスク使用状況のチェック

クォータ制限およびディスク使用状況をチェックするには、 quota または repquota コマンドを使用することがで きます。quota コマンドは、各ユーザ、各グループ毎のクォー タ制限およびディスク使用状況をチェックすることができます。 スーパーユーザだけが、他のユーザまたは自分が所属していないグループに 関するクォータ制限とディスク使用状況を調べることができます。 repquota コマンドは、クォータが設定されているファイルシス テムに対する、全てのクォータ制限およびディスク使用状況の総計を表示 します。

以下は、2つのファイルシステム上でクォータ制限がかけられているユー ザに対して quota -v コマンドを実行した出力結果の例です。 Disk quotas for user test (uid 1002): Filesystem blocks quota limit grace files quota limit grace /usr 65* 50 75 5days 7 50 60 /usr/var 0 50 75 0 50 60 上の例では、/usr ファイルシステム上で、このユーザは現在 50 ブロックまでのソフト制限を 15 ブロック超過して使用しており、 残り 5 日間の猶予期間を設定されています。 アスタリスク (*) は、ユーザが現在クォータ制限を越えていることを示 しています。

通常、ユーザがディスクスペースを全く使用していないファイルシス テムは、 たとえ そのファイルシステムにクォータ制限が設定されていた としても、quota コマンドによる出力では表示されません。 -v オプションを付けると、上の例の /usr/var ファ イルシステムのように、これらのファイルシステムも表示します。 * NFS ファイルシステム上でのクォータ

このセクションはまだ作成中です。 diff --git a/ja/handbook/relnotes.sgml b/ja/handbook/relnotes.sgml index a426f90f4b..53fde571b5 100644 --- a/ja/handbook/relnotes.sgml +++ b/ja/handbook/relnotes.sgml @@ -1,575 +1,575 @@ - + 現在のリリースについて

FreeBSD は自由に利用でき Intel i386/i486/Pentium/PentiumPro (とその互換 CPU) の PCで動作する, 4.4BSD-Lite ベースの全ソー スつきのリリースです. これはもともとカリフォルニア大学バーク レイ校 CSRGグループのソフトウェアがベースとなっており, NetBSD, 386BSD, そして Free Software Foundation のソフトウェ アなどにより拡張されています. 95年1月の FreeBSD 2.0 のリリースからみると, FreeBSD は性能, 機能, 安定性の面で劇的に改善されました. もっとも大きな変化は VM システムに おける改良で, 統合化された VM/file バッファキャッシュを用いる ことで性能を向上させながらも FreeBSD のメモリの使用量を減らすことが できたことです. おかげで, 最低 5MB メモリという制約上でも動作する ようになりました. その他の拡張としては NIS のクライアントとサーバの 完全サポート, トランザクション TCP のサポート, ダイヤルオンデマンド PPP, 改良 SCSI サブシステム, ISDN の初期サポート, FDDI や Fast Ethernet (100Mbps) などのサポート, Adaptec 2940 (WIDE と narrow) のサポートの改良と数百件のバグの修正, などがあります. 私たちはたくさんのユーザからのコメントや提案をまじめに受け取り, 私たちが正しいと考え, かつ導入の手順が分かりやすいものを提供しようと 努力しています. この (継続的に進化する) プロセスに対するあなたの意見を 心からお待ちしています. FreeBSD では基本配布セットに加え, 移植されたソフトウェア集 として 数百の人気の高いプログラムを提供しています. 96年12月 初旬の時点で 700 以上の ports (移植ソフトウェア) が存在します. ports には http (WWW) サーバから, ゲーム, 言語, エディタまでありとあらゆるものが含まれています. portsはオリジナル ソースに対する「差分」という形で表現されており, すべての portsを 集めても 10MB程度にしかなりません. こうすることで ports の更新を 容易にし, portsに必要なディスクスペースを小さくすることができます. portsをコンパイルするには, インストールしたいと思っているプログラムの ディレクトリに移動し, ``make all'' と実行してコンパイルが成 功したら, ``make install'' とすると, あとはすべてシステムが やってくれます. どの portsもオリジナルの配布セットを動的に CDROM または近くの FTP サーバから取ってくるので, ディスクは 構築したいと思っている portsの分だけを準備しておけば十分です. ほとんどの portsは, すでにコンパイルされた状態で ``package'' として提供されており, ソースコードからコンパイルしたくない場 合, これを使うと (pkg_add というコマンドで) 簡単にインストー ルできます. FreeBSD 2.1 以降のマシンであれば, /usr/share/doc ディレクトリにインストールの手順や FreeBSD を利用する上で有用な ドキュメントがたくさんあります. これらのドキュメントは, HTML ブラウザを使って, 以下の URL から 参照することができます. FreeBSD ハンドブック (英文オリジナル) FreeBSD に関する FAQ また, にはマスタ (かなり頻繁に更新されます) がありますので, こちらも参照してください. 合衆国の輸出規制のため, FreeBSD のコア配布セットには DES のコードは 含まれていません. 合衆国国内に限り, DES を使うプログラムなどが, コア配布セットに加えるパッケージとして提供されています. 誰でも使えるパッケージは, 別途, 合衆国国外で提供されています. 合衆国国外からも自由に取得可能な DES の配布セットに関する 詳細は, にあります. FreeBSD 上で必要とされるセキュリティがパスワードだけであり, Sun や DEC などの別のホストから暗号化されたパスワードをコピーする必要が ないのであれば, FreeBSD の MD5 ベースのセキュリティで十分です. この標準のセキュリティモデルは DES よりも適していると私たちは思って いますし, また, やっかいな輸出規制にもひっかかることはありません. あなたが合衆国国外にいるなら (あるいは国内にいても) 一度試してみて ください! Since our first release of FreeBSD 1.0 nearly two years ago, FreeBSD has changed dramatically. Since release 2.0, FreeBSD has been based on the Berkeley 4.4BSD-Lite code rather than the Net2 code used for previous versions. In addition to clearing the legal issues that surrounded the Net2 code, the port to 4.4 has also brought in numerous new features, filesystems and enhanced driver support. Since our release of FreeBSD 2.0 in November of 1994, the performance, feature set, and stability of FreeBSD has improved dramatically. The largest change is a revamped Virtual Memory (VM) system with a merged virtual memory and file buffer cache. This increases performance while reducing FreeBSD's memory footprint, making a system with 4 megabytes of RAM a more acceptable minimum. Other enhancements include full NIS client and server support, transaction TCP support, dial on demand PPP, an improved SCSI subsystem, early support for ISDN, support for FDDI and 100Mbit Fast Ethernet adapters, improved support for the Adaptec 2940 and hundreds of bug fixes. We have also taken the comments and suggestions of many of our users to heart and have attempted to provide what we hope is a more sane and easily understood installation process. Your feedback on this constantly evolving process is especially welcome! In addition to the base distributions, FreeBSD offers a new ported software collection with some 270 commonly sought-after programs. The list of ports ranges from World Wide Web (http) servers, to games, languages, editors and almost everything in between. The entire ports collection requires only 10MB of storage because each port contains only the changes required for the source code to compile on FreeBSD and the information necessary to automatically retrieve the original sources. The original distribution for each port you build is automatically retrieved off of CD-ROM or a via anonymous ftp, so you need only enough disk space to build the ports you want. Each port is also provided as a pre-compiled package which can be installed with the pkg_add(1) command for those who do not wish to compile their own ports from source. See for a more complete description. The core of FreeBSD does not contain DES code which would inhibit its being exported outside the United States. An add-on package, for use only in the United States, contains the programs that normally use DES. The auxiliary packages provided separately can be used by anyone. A freely exportable European distribution of DES for our non-U.S. users also exists and is described in the . If password security for FreeBSD is all you need, and you have no requirement for copying encrypted passwords from other hosts using DES into FreeBSD password entries, then FreeBSD's MD5 based security may be all you require. We feel that our default security model is more than a match for DES, and without any messy export issues to deal with. FreeBSD 2.0.5 represents the culmination of 2 years of work and many thousands of man hours put in by an international development team. We hope you enjoy it! New feature highlights

The following features were added or substantially improved between the release of 2.0 and this 2.0.5 release. In order to facilitate better communication, the person, or persons, responsible for each enhancement is noted. Any questions regarding the new functionality should be directed to them first. Kernel

Merged VM-File Buffer Cache A merged VM/buffer cache design greatly enhances overall system performance and makes it possible to do a number of more optimal memory allocation strategies that were not possible before. Owner: &a.davidg; and &a.dyson; Network PCB hash optimization For systems with a great number of active TCP connections (WEB and ftp servers, for example), this greatly speeds up the lookup time required to match an incoming packet up to its associated connection. Owner: &a.davidg; Name cache optimization The name-cache would cache all files of the same name to the same bucket, which would put for instance all ".." entries in the same bucket. We added the parent directory version to frustrate the hash, and improved the management of the cache in various other ways while we were at it. Owner: &a.phk; and &a.davidg; Less restrictive swap-spaces The need to compile the names of the swap devices into the kernel has been removed. Now swapon(8) will accept any block devices, up to the maximum number of swap devices configured in the kernel. Owner: &a.phk; and &a.davidg; Hard Wired SCSI Devices Prior to 2.0.5, FreeBSD performed dynamic assignment of unit numbers to SCSI devices as they were probed, allowing a SCSI device failure to possibly change unit number assignment. This could cause filesystems other disks in the system to be incorrectly mounted, or not mounted at all. Hard wiring allows static allocation of unit numbers (and hence device names) to scsi devices based on SCSI ID and bus. SCSI configuration occurs in the kernel config file. Samples of the configuration syntax can be found in the scsi(4) man page or the LINT kernel config file. Owner: &a.dufault; Sources involved: sys/scsi/* usr.sbin/config/* Slice Support FreeBSD now supports a slice abstraction which enhances FreeBSD's ability to share disks with other operating systems. This support will allow FreeBSD to inhabit DOS extended partitions. Owner: &a.bde; Sources involved: sys/disklabel.h sys/diskslice.h sys/dkbad.h kern/subr_diskslice.c kern/subr_dkbad.c i386/isa/diskslice_machdep.c i386/isa/wd.c scsi/sd.c dev/vn/vn.c Support for Ontrack Disk Manager Version 6.0 Support has been added for disks which use Ontrack Disk Manager. The fdisk program does not know about it however, so make all changes using the install program on the boot.flp or the Ontrack Disk Manager tool under MS-DOS. Owner: &a.phk; Bad144 is back and working Bad144 works again, though the semantics are slightly different than before in that the bad-spots are kept relative to the slice rather than absolute on the disk. Owner: &a.bde; and &a.phk; New device support SCSI and CDROM devices

Matsushita/Panasonic (Creative) CD-ROM driver The Matsushita/Panasonic CR-562 and CR-563 drives are now supported when connected to a Sound Blaster or 100% compatible host adapter. Up to four host adapters are supported for a total of 16 CD-ROM drives. The audio functions are supported with the Karoke variable speed playback. Owner: &a.uhclem; Sources involved: isa/matcd Adaptec 2742/2842/2940 SCSI driver The original 274x/284x driver has evolved considerably since the 2.0 release of FreeBSD. We now offer full support for the 2940 series as well as the Wide models of these cards. The arbitration bug that caused problems with fast devices has been corrected and experimental tagged queuing support has been added (kernel option AHC_TAGENABLE). John Aycock has also released the sequencer code under a Berkeley style copyright making the driver entirely clean of the GPL. Owner: &a.gibbs; Sources involved: isa/aic7770.c pci/aic7870.c i386/scsi/* sys/dev/aic7xxx/* NCR5380/NCR53400 SCSI (ProAudio Spectrum) driver Owner: &a.core; Submitted by: Serge Vakulenko (vak@cronyx.ru) Sources involved: isa/ncr5380.c Sony CDROM driver Owner: &a.core; Submitted by: Mikael Hybsch (micke@dynas.se) Sources involved: isa/scd.c Serial devices

SDL Communications Riscom/8 Serial Board Driver Owner: &a.ache; Sources involved: isa/rc.c isa/rcreg.h Cyclades Cyclom-y Serial Board Driver Owner: &a.bde; Submitted by: Andrew Werple (andrew@werple.apana.org.au) and Heikki Suonsivu (hsu@cs.hut.fi) Obtained from: NetBSD Sources involved: isa/cy.c Cronyx/Sigma sync/async serial driver Owner: &a.core; Submitted by: Serge Vakulenko Sources involved: isa/cronyx.c Networking

Diskless booting Diskless booting in 2.0.5 is much improved over previous releases. The boot program is in src/sys/i386/boot/netboot, and can be run from an MS-DOS system or burned into an EPROM. WD, SMC, 3COM and Novell ethernet cards are currently supported. Local swapping is also supported. DEC DC21140 Fast Ethernet driver This driver supports any of the numerous NICs using the DC21140 chipset including the 100Mb DEC DE-500-XA and SMC 9332. Owner: &a.core; Submitted by: Matt Thomas (thomas@lkg.dec.com) Sources involved: pci/if_de.c pci/dc21040.h DEC FDDI (DEFPA/DEFEA) driver Owner: &a.core; Submitted by: Matt Thomas (thomas@lkg.dec.com) Sources involved: pci/if_pdq.c pci/pdq.c pci/pdq_os.h pci/pdqreg.h 3Com 3c505 (Etherlink/+) NIC driver Owner: &a.core; Submitted by: Dean Huxley (dean@fsa.ca) Obtained from: NetBSD Sources involved: isa/if_eg.c Fujitsu MB86960A family of NICs driver Owner: &a.core; Submitted by: M.S. (seki@sysrap.cs.fujitsu.co.jp) Sources involved: isa/if_fe.c Intel EtherExpress driver Owner: Rodney W. Grimes (rgrimes@FreeBSD.org) Sources involved: isa/if_ix.c isa/if_ixreg.h 3Com 3c589 driver Owner: &a.core; Submitted by: "HOSOKAWA Tatsumi" (hosokawa@mt.cs.keio.ac.jp), Seiji Murata (seiji@mt.cs.keio.ac.jp) and Noriyuki Takahashi (hor@aecl.ntt.jp) Sources involved: isa/if_zp.c IBM Credit Card Adapter driver Owner: &a.core; Submitted by: "HOSOKAWA Tatsumi" (hosokawa@mt.cs.keio.ac.jp), Sources involved: isa/pcic.c isa/pcic.h EDSS1 and 1TR6 ISDN interface driver Owner: &a.core; Submitted by: Dietmar Friede (dfriede@drnhh.neuhaus.de) and Juergen Krause (jkr@saarlink.de) Sources involved: gnu/isdn/* Miscellaneous drivers

Joystick driver Owner: &a.jmz; Sources involved: isa/joy.c National Instruments ``LabPC'' driver Owner: &a.dufault; Sources involved: isa/labpc.c WD7000 driver Owner: Olof Johansson (offe@ludd.luth.se) Pcvt Console driver Owner: &a.joerg; Submitted by: &a.hm; Sources involved: isa/pcvt/* BSD-audio emulator for VAT driver Owner: Amancio Hasty (ahasty@FreeBSD.org) and &a.pst; Sources involved: isa/sound/vat_audio.c isa/sound/vat_audioio.h National Instruments AT-GPIB and AT-GPIB/TNT GPIB driver Owner: &a.core; Submitted by: Fred Cawthorne (fcawth@delphi.umd.edu) Sources involved: isa/gpib.c isa/gpib.h isa/gpibreg.h Genius GS-4500 hand scanner driver Owner: &a.core; Submitted by: Gunther Schadow (gusw@fub46.zedat.fu-berlin.de) Sources involved: isa/gsc.c isa/gscreg.h CORTEX-I Frame Grabber Owner: &a.core; Submitted by: Paul S. LaFollette, Jr. ( Sources involved: isa/ctx.c isa/ctxreg.h Video Spigot video capture card Owner: Jim Lowe Experimental features

UNIONFS and LFS The unionfs and LFS file systems are known to be severely broken in FreeBSD 2.0.5. This is in part due to old bugs that we have not had time to resolve yet and the need to update these file systems to deal with the new VM system. We hope to address these issues in a later release of FreeBSD. iBCS2 Support FreeBSD now supports running iBCS2 compatible binaries. Currently SCO UNIX 3.2.2 and 3.2.4, and ISC 2.2 COFF are supported. The iBCS2 emulator is in its early stages and has not been extensively tested, but it is functional. Most of SCO's 3.2.2 binaries work, as does an old INFORMIX-2.10 for SCO. Further testing is necessary to complete this project. There is also work under way for ELF and XOUT loaders, and most of the svr4 syscall wrappers are written. Owner: &a.sos; and &a.sef; Sources involved: sys/i386/ibcs2/* and misc kernel changes. ]]> diff --git a/ja/handbook/routing.sgml b/ja/handbook/routing.sgml index 2563f31537..94c99b61a2 100644 --- a/ja/handbook/routing.sgml +++ b/ja/handbook/routing.sgml @@ -1,269 +1,269 @@ - + ゲートウェイとルート

原作: &a.gryphon;.6 October 1995.

訳: &a.yuki;.6 September 1996. ある計算機が他の計算機をみつけることができるようにするには, ある 計算機から他の計算機へ, どのようにたどり着くかを適切に記述するた めの仕組みが必要です. この仕組みをルーティングと呼びます. 「ルー ト(経路)」は 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について説明する必要があります. それぞれの経路は欄に示されているように違った属性をもっています. 以下にいくつかのフラグとこれらが何を意味しているかを示します. デフォルトルート

ローカルシステムからリモートホストにコネクションを張る 必要がある場合, 既知のパスが存在するかどうかを確認するためにル ーティングテーブルをチェッ クします. 到達するためのパスを知っているサブネットの内部にリモ ートホストがある場合 (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 情報とよく似た) システムがあり, そのインターネット バックボーンへの接続点を定義しています. 「バックボーン」 とは国を越え, 世界中のインターネットのトラフィックを運ぶ主要 な信用できる幹線のことです. どのバックボーンマシンも, あるネット ワークから特定のバックボーンのマシンへ向かうトラフィックと, そのバックボーンのマシンからあなたのネットワークに届くサービス プロバイダまでのチェーンのマスタテーブルのコピーを持っていま す. あなたのサイトが接続(プロバイダからみて内側にある ことになります) したということを, プロバイダからバックボー ンサイトへ通知することはプロバイダの仕事です. これが経 路の伝搬です. トラブルシューティング

ルーティングの伝搬に問題が生じて, いくつかのサイトが 接続をおこなうことができなくなることがあります. ルーティングがどこでおかしくなっているかを明らかにするのに 最も有効なコマンドはおそらくtraceroute(8)コマンドでしょ う. このコマンドは, あなたがリモートマシンに対して接続をおこなう ことができない(例えばping(8)に失敗するような場合) 場合も, 同じように有効です. traceroute(8)コマンドは, 接続を試みているリモートホスト を引数にして実行します. 試みているパスの経由する ゲートウェイホストを表示し, 最終的には目的のホストに たどり着くか, コネクションの欠如によって終ってしまうかのどちら かになります. より詳しい情報は, tracrouteのマニュアルページをみてください. diff --git a/ja/handbook/scsi.sgml b/ja/handbook/scsi.sgml index cd023e21d8..d29a689254 100644 --- a/ja/handbook/scsi.sgml +++ b/ja/handbook/scsi.sgml @@ -1,958 +1,958 @@ - + SCSIとは?

原作:&a.wilko;. July 6, 1996.

訳: &a.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線の信号線 のバスです. (もしシングルエンドの意味が分からなくても気にするこ とはありません. このドキュメントの中にその説明があります.) よ り新しい設計では 16 bit幅で平衡信号のバスを使います. この場合, 転送速度は 20Mbytes/second まで,ケーブルの長さは 25mまで可能です. SCSI-2では追加のケーブルを使った最大32 bitのバス幅までが含まれ ます. 早くも Ultra SCSI (Fast-20とも呼ばれます) と Ultra2 (Fast-40とも 呼ばれます) が現れています. Fast-20は1秒間に 2000万回の転送 (8bit バスで20Mbyte/sec), Fast-40は1秒間に 4000万回の転送 (8bitバスで 40Mbytes/sec) をおこないます. 訳注: ここでは電気的な用語としては平衡,不平衡を用いて,バ スの名称としては基本的にはシングルエンド,ディファレンシャルとしま した. もちろん 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の構成要素

インテリジェント インタフェース

(訳注:原文では smart interface です) 先に述べたように, 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後 - 本当は電線中の信号の伝達は 光速よりも少し遅くなるのでもう少し時間がかかりますが - に帰ってきます. 10MHzのクロックは1:1のパルスだとすると幅 50nsのパルスで, 反射波がやってくる時間とそれほど変わりません. このため, 場合によっては反射波によってクロックや信号が異常 になってしまう可能性があります. ターミネータはいろいろな - 洗練されたものもそうでないもの も - 実現方法があります. もちろん,内蔵のものと外部という 区別もあります. ほとんどすべての SCSIデバイスにはいくつかの ソケットがあり,その中には抵抗ネットワーク (集合抵抗) が入っ ているものもあるかもしれません (いや,おそらく間違いなくあ るでしょう). ターミネータを デバイスから外す時は大事にしまっておいてください. SCSIの接 続の変更をしようと思った時に必要になるかもしれません. ま た, それらしい抵抗ネットワークが見つからないこともあります. この場合, SCSIデバイスは内蔵ターミネータの有効と無効を切替 えるジャンパがあります. フラットケーブルに取り付ける特別 なターミネータもあります. 他には外部コネクタのような形をし たものやケーブルのないコネクタヘッドだけのものもあります. いろいろと見られるように多くの選択があります. どのような場合に単純な抵抗 (パッシブ) ターミネータからアクティ ブターミネータへ切替えるかという問題があります.アクティブ ターミネータはいくらか精巧な回路が信号をよりきれいにするた めに入っています. 一般的に一致する意見としては, 長いバス を使ったり 高速なデバイスを使う場合はアクティブターミネー タの有効性は増加すると言えます. SCSI バスですでに問題が起 きているならアクティブターミネータを試すことを考えていいで しょう. まず借りることができないか探してみてください. ア クティブターミネータは非常に高価だそうですから. ディファレンシャルとシングルエンドバスのターミネータは互換 性がないということを覚えておいてください. これらの2つの種 類を 混在させることはできません. OK, ではあなたはターミネータをどこに入れればいいでしょうか? これは SCSIで最も多く誤解されているところです. しかし, これ は極めて単純なことです.. ここでのルールは すべての SCSI バスは 2個のターミネータをそれぞれの両端に入れるとい うことです. つまり 2個であって1個でも3個でもありませ ん. このルールを受け入れてしたがってください. そうすれば終りの ない苦しみから救われるでしょう. なぜなら間違ったターミネー ションは不可解なバグを引き起こす可能性が非常に高いから です. よく陥りやすい落し穴はマシンの内部 (フラット) ケーブルと外部 ケーブルがコントローラにつながっている場合です. よく見られ るのはコントローラのターミネータを外すのを忘れることで す. ターミネータは最後の外部デバイスで必要で, コントローラ には必要ありません! 一般的に, SCSIバスの接続の変更をする場 合はこのようなことに注意をしなければなりません. 私自身は, すべてのデバイスとコントローラのターミネータを外し ています. 2個の外部ターミネータをセントロニクスタイプ (訳注: 日本ではケーブルに対してこういう言い方はあまりしないのでは ないでしょうか) 外部ケーブルと内部フラットケーブルのコネク タの両端に接続しています. こうすることにより接続の変更はか なり簡単になります. 最近のデバイスは, ICターミネータが使われることもあります. コントロールピンにより無効/有効を設定できる特別のICがあり ます. これは物理的にデバイスから外す必要がありません. 新し いホストアダプタではセットアップツール等を使ってソフトウェ ア的に設定をおこなう場合があります. マニュアルを調べてくださ い. ターミネータの電源

ここまでの章で議論したターミネータは正常に動作するためには 電源が必要です. SCSIバス上にはこの目的のために利用される線 があります. だから特に気にする必要はないと思いますか? ところがそうではないのです. それぞれのデバイスはデバイス上 にあるターミネータソケットに電源を供給することはできま す. けれども外部ターミネータがある場合やSCSIバスにターミネー タの電源を供給するデバイスのスイッチがオフになっているよう な場合にはトラブルが起きるかもしれません. イニシエータ (ここではバスの動作を開始-initiate-させるデバ イスを指します -- 訳注: 簡単に言えばホスト側のアダプタです がSCSIの規格によれば, 例えばディスク側がコマンドを発行する ようなシステムがあってもかまわないことになっているのでこう いう言い方をしています) はターミネータ電源を供給しなければ なりません. すべてのSCSIデバイスはターミネータの電源を供給す ることができます (必ずしも供給しなければならないというわけ ではありません). スイッチがオフになっているデバイスがバス上に存在することを 許すために, ターミネータの電源はダイオードを通して供給され なければなりません. これはスイッチを切ったデバイスに電流 が逆流することを防ぐためです. 最悪の事態を避けるために, ターミネータの電源は普通はヒュー ズが入っています. 当然ヒューズは飛ぶかもしれません. この 場合でもバスが機能停止するとは限りません. 複数のデバイスが ターミネータの電源を供給しているのであれば, ヒューズが一つ 飛んでも全体の機能には影響しません. ただ一つの供給線のヒュー ズが飛んだのであれば確かに問題になるでしょう. 外部ターミネー タによっては LEDでターミネータ電源が与えられていることを示 すものもあります. 最新の設計ではある程度の時間がたつと 「リセット」され自動復 帰するヒューズが使われることもあります. デバイス アドレッシング

SCSIバスでは接続された異なるデバイスを区別して指定できなけ ればなりません. これには SCSIではターゲットIDが使われます. それぞれのデバイ スは特定のターゲットIDを持ちます. デバイスの IDはジャンパや DIPスイッチなどで設定できます. より詳しい情報はデバイスの マニュアルを見てください. 複数のデバイスを使う場合は IDの重複に気をつけてください. 重 複すると普通は混乱状態になります. 同じ IDを共有しているデバ イスがI/Oリクエストに答えようと処理をおこなうことが落し穴にな ります. 8 bitバスでは, 最大8台のターゲットまで可能です. 最大8台で ある理由は, バスの8本のデータ線がデバイスの選択に使われる からです. バス幅の広いバスでは使えるデバイスの数は増えます. 同時にバス使用の要求が発生した場合, 最も IDの大きいデバイス が優先されるという調停がおこなわれます. このことは (ナローバス では) SCSIホストアダプタの IDは通常7番が使われる理由でもあり ます. さらにサブユニットとして, 規格では ロジカルユニット,短縮形 で LUNを持つことができます. 一つのターゲットIDが複数の LUNを 持つことができます. 例えば, テープチェンジャを持つテープ ドライブは LUN 0をテープドライブ自身, LUN 1をテープチェン ジャ に与えることができます. このようにして, ホストシス テムはテープチェンジャの目的のテープユニットの部分を指定す ることができます. バスレイアウト

SCSIバスは直線状です. つまり, Y接続, スター接続, クモの巣 状の接続などの直線以外の接続ではありません. 先に議論したターミネータの問題は直線状以外の場合ではより困 難になるだろうということに注意してください. 電気的特性はそのノイズマージンや全体の信頼性において,直線 状のバスのルールに強く依存しています. 直線状バスであるというルールにしたがってください! 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' とします. 簡単ですね? 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: 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), CD-ROM (cd) などです. これらのソースコードは/sys/scsiにあり ます. マニュアルページ (man) のセクション 4 にはより詳しい内 容があるので見てください. 多階層の設計は低レベルとより高位のレベルを分離させることがで きます. 新たに他の種類のハードウェアのサポートを加えることを より処理しやすい問題にします. カーネルコンフィグレーション

あなたのハードウェア構成にしたがって, カーネルのコンフィグファイ ルにホストアダプタについて 1行あるいは数行程度の記述をする 必要があります. これには I/O アドレスや割り込みなどについての内容も含 みます. あなたのアダプタのドライバについてのマニュアルページ にはより多くの情報があるのでよく読んでください. これとは別に /sys/i386/conf/LINT にはカーネルコンフィグファイルについての 概要があります. LINTには一般的なものについては可能なすべてのオ プションが含まれています. ただし, LINTでは実際に動作するカー ネルを作ることは できません. おそらく何をするかは明らかでしょう. カーネルコンフィグファイ ルは実際のハードウェア構成を反映すべきです. そのように割り込 みやI/Oアドレス等に合わせてカーネルコンフィグファイルを書か なければなりません. システムのブート時のメッセージは実際に 見つけたハードウェアの設定を表示します. 例として FreeBSD 2.0.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!) # bt: Most Buslogic controllers # nca: ProAudioSpectrum cards using the NCR 5380 or Trantor T130 # uha: UltraStore 14F and 34F # sea: Seagate ST01/02 8 bit controller (slow!) # wds: Western Digital WD7000 controller (no scatter/gather!). # [ Adaptec AHA274x, 284x などのコントローラ] controller ahc0 at isa? bio irq ? vector ahcintr # port??? iomem? [ Adaptec AHA174x コントローラ] controller ahb0 at isa? bio irq ? vector ahbintr [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 ahb0 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 [ahb0 上の SCSIディスク] tape st1 at scbus0 target 6 [SCSI テープ は ターゲット (ID)6] device cd0 at scbus? [最初に見つけた CDROM, 固定にしない] 上の例では カーネルは ahc (Adaptec 274x) コントローラをまず 探し, その次に Adaptec 174x のボードというように順番に探して 行きます. その下の行の 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 154xドライバの場合はman 4 aha にあります. カーネルセットアップでの 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: 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: 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 に あるデバッグレベルを変えてみてください. 検出はされるが 動かないのであれば, scsi(8)コマンドで (SCSIDEBUG をつけてmakeした) カーネルが動いている状態で動的にデバッグ レベルを設定することができます. これは guru (UNIXの達人) で も混乱してしまうほどの非常に大量のデバッグ情報を出すでしょ う. man 4 scsi にはより正確な情報があります. またman 8 scsi も見てください. さらに詳しい情報

もしあなたがいくらかは本気で SCSIハッキングをする気があるなら たぶん正規の規格を持っていたくなるでしょう. 承認ずみのアメリカ工業規格は ANSI から購入できます. 住所と電話 番号は11 West 42nd Street, 13th Floor, 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 (誰でも ファイルを取ってくることができる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 のニュースグループ と は特により多くの情報を得るには注目すべき場所です. また定期的に ポストされる SCSI-FAQをここから得ることができます. 多くの主要な SCSIデバイスとホストアダプタの供給元は FTP サイト や BBSを開いています. これらはあなたの持っているデバイスに関す る貴重な情報源となるでしょう. diff --git a/ja/handbook/sections.sgml b/ja/handbook/sections.sgml index 59529cedc3..2af5db85d4 100644 --- a/ja/handbook/sections.sgml +++ b/ja/handbook/sections.sgml @@ -1,64 +1,64 @@ - + diff --git a/ja/handbook/serial.sgml b/ja/handbook/serial.sgml index 0c4d4bab78..80e66166f6 100644 --- a/ja/handbook/serial.sgml +++ b/ja/handbook/serial.sgml @@ -1,76 +1,76 @@ + + + + シリアル接続の基礎

Assembled from FAQ. このセクションには, シリアルポートについての一般的な情報が書かれていま す. あなたが求めている情報が, もしここで見つからなかった場合には, ハン ドブックの端末とダイアルアップのセクションを見てください.

stty -a -f /dev/ttyd1 このデバイスの設定を変更した場合, その設定はデバイスが クローズされるまで有効です. デバイスが再びオープンされる時, デフォルトの設定値に戻ります. デフォルトの設定を変更するためには, 「初期状態」を設定した いデバイスをオープンして調節することができます. 例えば, ttyd5 というデバイスに対して, デフォルトで XON/XOFF フロー制御を行うように設定したい場合は, 次のようにします. stty -f /dev/ttyid5 clocal cs8 ixon ixoff このコマンドを記述するのに適しているファイルは, /etc/rc.serial です. アプリケーションが stty -f /dev/ttyld5 57600 これで、 - + sioドライバの設定

sio ドライバは, NS8250-, NS16450-, NS16550とNS16550A ベースの EIA RS-232C(CCITT V.24) 通信用インタフェースをサポートします. ま た, いくつかのマルチポートシリアルカードもサポートされています. 技術的 な詳細についてはマニュアルsio(4)を見てください. Digi International (DigiBoard) PC/8

原作: &a.awebster;. 1995年8月26日.

訳: &a.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 のボードではなく, 外付けのコネクタボックスの中に存在します. コネクタボックスを接続しないと, ポートの検出に失敗するでしょう. 私は, 接続しないまま起動したり, 後から接続しなおしたりした時にどうなるかをテ ストしていません. どちらも実行しないようお奨めします. もしあなたがカスタマイズ済みのカーネルコンフィグレーションファイルを持っ ていなければ, 一般的な事柄については, を参考にしてください. 以下にBoca 16のボード に関係する部分だけを記述します. この例では, あなたがMYKERNELという名前 のカーネルを使っていて, エディタには viを使っていることを仮定していま す. 次の1行をconfigファイルに追加してください. options COM_MULTIPORT この device sioxxxという行を, 必要に応じて 16 個のデバイス分を追加してください. 最後のデバイスにだけ, このボード の割り込みベクタを記述します. (詳細は 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の割り当てを使っていない限り 必ず 上記の例から変更してください. フラグは, 次のように設定します. 0xMYY の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) もしメッセージの表示が速くて読み取れないときは, dmesg | more とするとブート時のメッセージをゆっくり見ることができます. 次に, root になってから, デバイスにあわせたエントリを /dev/MAKEDEVスクリプトを使って/dev に追加します. # cd /dev # ./MAKEDEV tty1 # ./MAKEDEV cua1 (中略) # ./MAKEDEV ttyg # ./MAKEDEV cuag もし, 何らかの理由で発信するデバイスが不要な場合, cua* デバ イスを作らないで済ますこともできます. デバイスが確実に動作しているかどうか確認する手っ取り早い方法は, あなたが (rootになって) 各ポートにモデムを接続してみて, あなたが作成し た各デバイス毎にecho at> ttyd*とやってみてください. 各ポー トが動作していればRXの表示が光るのが見えるはず です. diff --git a/ja/handbook/skey.sgml b/ja/handbook/skey.sgml index ef493d30fd..540d6a0563 100644 --- a/ja/handbook/skey.sgml +++ b/ja/handbook/skey.sgml @@ -1,355 +1,355 @@ + - S/KEY

原作: &a.wollman;25 September 1995.

訳: &a.hino;.24 September 1996.

S/KEY は一方向ハッシュ関数 (ここで述べているバージョンでは, 過去と の互換性を保つために MD4 を用いています. S/KEY の他のバージョンでは MD5 や DES-MAC を用いているものもあります) を基にしたワンタイムパスワー ド方式です. S/KEY は, バージョン 1.1.5 以降のすべての FreeBSD に標準的 に含まれています. S/KEY は FreeBSD 以外の数多くのシステムの上でも利用 可能であり, その実装の数も増えています. S/KEY ば Bell Communications Research, Inc. の登録商標です.

以下の説明では, 三種類の異なる「パスワード」が使われます. まず一つ 目は, あなたが普段使っている普通の UNIX スタイルの, もしくは Kerberos でのパスワードです. ここではこれを ``UNIX パスワード'' と呼ぶことにし ます. 二つ目は, S/KEY の `秘密のパスフレーズは, UNIX パスワードと同じである必要はありませんし, また UNIX パスワードと何らかの関連性を持たなければならないということも ありません (両者を同一に設定することは可能ですが, お奨めしません). UNIX パスワードは長さが 8 文字に制限されています (訳注: FreeBSD で DES を導入していない場合はもっと長いパスワードも認識されます). これに対し, S/KEY では秘密のパスフレーズを好きなだけ長くすることができます (訳注: 実装上, `S/KEY システムでは他に二種類のデータを使用します. 一つは ``シード (種)'' または (混乱を招きますが) ``キー'' と呼ばれるもので, (訳注: デ フォルトでは) 二つの文字と五つの数字で構成されます. もう一つは ``シー ケンス番号'' で, 1 以上の整数です. シーケンス番号は特に指定しなければ 100以下です (訳注: ``次に, S/KEY 関連の四つのプログラムについて説明します. `/etc/skeykeys というファイルを調べて, このプログラムを起動し たユーザの現在のシーケンス番号とシードを表示します. 最後に, `このドキュメントでは, 四種類の異なる操作について説明します. 一つ目 は, `信頼できる通信路での初期化

信頼できる通信路 (例えばあるマシンのコンソール画面など) を利用して いるときに, S/KEY の初期化, S/KEY の秘密のパスフレーズの変更, またはシー ドの変更をおこなうことができます. そのためには, まずあなた自身がログイ ンし, ` $ keyinit Updating wollman: ) この部分は始めて S/KEY を使 Old key: ha73895 ) うときには表示されません. 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 wollman s/key is 99 ha73896 ) あとで説明します. SAG HAS FONT GOUT FATE BOOM )

上の例で出てきた事柄について説明しましょう. `Enter secret password:' というプロンプトに対してあなたが考えた秘密のパスフレーズを 入力します (筆者は 7 単語以上の文を秘密のパスフレーズにしています). こ の秘密のパスフレーズは後でログインするために必要になるものです. `ID' から始まる行は, S/KEY における一回分のパラメタであり, あなたのログイ ン名とシーケンス番号とシードです. (訳注: `信頼できない通信路での初期化

信頼できない通信路を使って S/KEY を初期化, または秘密のパスフレーズ やシードを変更するためには, 信頼できる通信路として, その信頼できない通 信路とは別のものを用意する必要があります. その信頼できる通信路は ` $ keyinit -s Updating wollman: Old key: kh94741 Reminder you need the 6 English words from the skey command. ) `keyinit' コマンドが出力する注意です. 訳すと, ) 注意 - skey コマンドの出力する 6 英単語が必要になります. Enter sequence count from 1 to 9999: 100 ) ここを入力. Enter new key [default kh94742]: ) リターンのみ入力. s/key 100 kh94742 デフォルトのシード (`keyinit' プログラムは困ったことにこれを `key' と 読んでいるのですが, 混乱しないよう注意してください) で構わなければ, リ ターンキーを押してください. 次に, あらかじめ用意しておいた信頼できる通 信路 (信頼できるマシンや信頼できる S/KEY デスクアクセサリなど) へ移っ て, 先ほどと同じパラメタを入力します. $ key 100 kh94742 Reminder - Do not use this program while logged in via telnet or rlogin. Enter secret password: ) ここで秘密のパスフレーズを入力します. HULL NAY YANG TREE TOUT VETO ここで信頼できない通信路の方に戻って, ` s/key access password: HULL NAY YANG TREE TOUT VETO ID wollman s/key is 100 kh94742 HULL NAY YANG TREE TOUT VETO 後は, 前章で説明したことと同様です. ちょっと寄り道: ログインプロンプトについて

どうやってワンタイムパスワードを生成するかを説明する前に, S/KEY を 使う場合のログインプロンプトを見ておいた方がよいでしょう. $ telnet himalia Trying 18.26.0.186... Connected to himalia.lcs.mit.edu. Escape character is '^]'. s/key 92 hi52030 Password: パスワードを要求する前に, ログインプログラムがシーケンス番号とシードを 表示していることがわかります. この二つのパラメタを使ってワンタイムパ スワードを計算することになります. ここではまだ使っていませんが, 便利な 機能がログインプログラムに備わっています:パスワードプロンプトに対して, 何も入力せずにリターンを押すとエコーモードに切り替わります. つまりタイ プした文字がそのまま見えるようになるのです. これは S/KEY のワンタイム パスワードを紙に印刷していた場合など, ワンタイムパスワードを手で入力し なければならない場合に特に役立つ機能です.

このログインしようとしてるマシンが, あなたが今使っているマシンから UNIX パスワードを使ってログインすることができないように設定されている 場合があります. その場合には, ログインプロンプトには S/KEY のワンタイ ムパスワードの利用が必要であることを示す `(s/key required)' という注釈が表示されます. ワンタイムパスワードを生成する

次に前章のログインプロンプトに対して入力するためのワンタイムパスワー ドを生成しましょう. そのために, 信頼できるマシンと ` $ key 92 hi52030 ) 前章の例からペースト. Reminder - Do not use this program while logged in via telnet or rlogin. Enter secret password: ) 秘密のパスフレーズを入力. ADEN BED WOLF HAW HOT STUN そして別のウィンドウで: s/key 92 hi52030 ) 前章の例の続き. Password: ) ここでリターンキーを押した. (turning echo on) Password:ADEN BED WOLF HAW HOT STUN Last login: Wed Jun 28 15:31:00 from halloran-eldar.l [以下略.] 以上の手順は, 信頼できるマシンが利用できる場合 複数のワンタイムパスワードを生成する

都合によっては, 信頼できるマシンや信頼できる通信路が一切確保できな いようなところで S/KEY を使う必要があるでしょう. このような場合には, ` $ key -n 25 57 zz99999 Reminder - Do not use this program while logged in via telnet or rlogin. Enter secret password: 33: WALT THY MALI DARN NIT HEAD 34: ASK RICE BEAU GINA DOUR STAG [...] 56: AMOS BOWL LUG FAT CAIN INCH 57: GROW HAYS TUN DISH CAR BALM `UNIX パスワードの利用を制限する

設定ファイル /etc/skey.access を使って UNIX パスワードの利 用を制限することができます. この場合の判断基準として, ログインを受け付 ける際のホスト名, ユーザ名, 端末のポート, IP アドレスなどが利用できま す. この設定ファイルの詳細に関してはマニュアル もし /etc/skey.access ファイルが存在しないならば (FreeBSD をインストールした直後の状態では存在しません), すべてのユーザが UNIX パスワードを利用することができます. 逆に, もしファイルが存在するならば, /etc/skey.access ファイルに明示的に記述されていない限り, すべ てのユーザは S/KEY の利用を要求されます. どちらの場合においても, その マシンのコンソールからはいつでも UNIX パスワードを使ってログインするこ とが可能です.

以下によく使われるであろう三種類の設定を含む設定ファイルの例を示し ます: permit internet 18.26.0.0 255.255.0.0 permit user jrl permit port ttyd0 はじめの行 (`二行目 (`三行目 (` - + SLIPクライアントのセットアップ

原作: &a.asami;8 Aug 1995.

訳: &a.hanai;8 August 1996. ここにはFreeBSDマシンを静的アドレスのネットワークにつなげる場合の SLIPのセットアップの一つの方法を書いてあります. ホスト名を動的に割り当てる(つまり, ダイヤルアップするたびにアドレスが かわる)ためには, おそらくもっと凝ったことが必要です. まず, モデムがどのシリアルポートにつながっているか決めましょう. 私は /dev/modem -> cuaa1というシンボリックリンクを張り, コンフィグレーションではその名前だけを使っています. /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 余談ですが, silviaというのは私が日本にいた時に持っていた 車の名前です(米国では2?0SXと呼ばれています). /etc/host.confファイル中で"hosts"が"bind"よりも前にあること を確認してください. さもないとヘンなことが起こるかもしれません. /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 で slattach -h -c -s 115200 /dev/modem と入力しましょう. もしルータの向う側のホストへ"ping"できるなら接続成功です! もしうまく いかなければslattachへの引数として"-c"の代わりに"-a"とやってみてください. 接続の切り方

slattachを殺すためにrootで "kill -INT `cat /var/run/slattach.modem.pid`" とタイプしてください. そしてkermitに戻り(もしkermitをサスペンドしていたなら "fg"), kermitから抜けてください("q"). slattachのマニュアルページにはインタフェースを落すために "ifconfig sl0 down"をしなければいけないと書いていますが, 私には差がないように見えます. ("ifconfig sl0"とやっても同じ結果が得られる.) 時にはモデムがキャリアを落すのを拒絶するかもしれません(私のは よくそうなります). その時は単にkermitをスタートしてまた終了 してください. 普通は2回目で落ちます. トラブルシューティング

もし動かなければ自由に私に質問してください. 今までいろんな人がつまずいた のは次のようなことです. slattachで"-c"や"-a"を使わなかった(私はなぜこれが致命的になり得るのか わかりませんが, このフラグを付けることで少なくとも一人の問題は解決しました.) "sl0"の代わりに"s10"を使った(いくつかのフォントでは見分けるのは難しい かもしれません). インタフェースの状態を見るために"ifconfig sl0"をやってみてください. 私は, silvia# ifconfig sl0 sl0: flags=10 inet 136.152.64.181 --> 136.152.64.1 netmask ffffff00 となります. また, pingが"no route to host"というメッセージを返す時には netstat -rでルーティングテーブルを確認しましょう。 私のは, silvia# 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) となります. (これはたくさんのファイルを転送した後でのもので, あなたの見る数字はもっと小さいかも しれません). diff --git a/ja/handbook/slips.sgml b/ja/handbook/slips.sgml index d2c40e42db..d56c6b758b 100644 --- a/ja/handbook/slips.sgml +++ b/ja/handbook/slips.sgml @@ -1,514 +1,514 @@ - + SLIPサーバのセットアップ方法

原作: &a.ghelmer;. v1.0, 15 May 1995.

訳: &a.ts;.6 September 1996. この文書の目的は, SLIPサーバ機能を FreeBSDシステムのもとで設定するため の助言を提供することです. SLIPサーバ機能を設定するということは, リモー トの SLIPクライアントがログインできるようにするために, 自動的に接続処 理をおこなうようにすることです. この文書は著者の経験に基づいておりますが, 実際のシステム構成や要望は異なりますから, すべての疑問にこの文書が答え ることはできません. なお, ここでの助言を試みた結果, あなたのシステムへ の悪影響やデータの損失が生じたとしても, 著者が責任を持つことはできませ んのでご了解をお願いします. 当初この文書は, FreeBSD 1.xシステムでの SLIPサーバ機能のために書きまし た. その後, FreeBSD 2.xの初期バージョンでのパス名の変更や SLIPインタフェー ス向け圧縮フラグの削除といった変更点を反映するために, 書き換えをおこないま した. これらが FreeBSDのバージョン間の主要な変更点だったからです. もし この文書の間違いを見つけられましたら, ぜひ, 訂正に十分な情報とともに電 子メールでお知らせいただければ助かります. 前提

この文書の内容はテクニカルなものなので, 前提知識が必要です. すなわち, 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/ におけるチュー トリアルの一覧を調べてください. あるいは, この文書を見つけた場所を調べ て, 概要

一般的な設定内容で FreeBSDを SLIPサーバとして利用すると, その動作は次 のようになります. まず, SLIPユーザが FreeBSD による SLIPサーバへ電話し て, SLIP専用IDでログインします. なお, このIDを持ったユーザはシェルとし て /usr/sbin/sliplogin を使います. この /etc/sliphome/slip.hosts の中から, ログインIDと一致する 記述行を探します. もし一致する行があれば, ログインしたシリアル回線を, 利用可能な SLIPインタフェースへ接続し, その後にシェルスクリプト /etc/sliphome/slip.login で SLIPインタフェースを設定します. SLIPサーバへのログイン例

仮に SLIPユーザIDが Shelmerg とします. すると, /etc/master.passwd における Shelmerg:password:1964:89::0:0:Guy Helmer - SLIP: /usr/users/Shelmerg:/usr/sbin/sliplogin sliplogin は, ファイル /etc/sliphome/slip.hosts からユーザIDと一致する行を探しま す. いま仮に, /etc/sliphome/slip.hosts に次のような記述がなさ れていたとします. Shelmerg dc-slip sl-helmer 0xfffffc00 autocomp /etc/sliphome/slip.login を実行します. /etc/sliphome/slip.login 0 19200 Shelmerg dc-slip sl-helmer 0xfffffc00 autocomp もし上記の手順が正常に処理されると, /etc/sliphome/slip.login は, slip.login で与えられたパラメタのうちで最初の値である SLIP インタフェース0である) に対して ifconfig を実行し, ローカル IPアドレス (dc-slip)をはじめ, リモート IPアドレス (sl-helmer), SLIPインタフェースへのネットワークマスク (0xfffffc00), およびその他のフラグ (autocomp)を設定 します. 逆に, さきほどの手順が正常に終了しなかった場合, 通常は /var/log/messages へ記録します ( syslogd(8) や 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 0.0.c0.2c.5f.4a 291311 0 174209 0 133 ed0 1500 138.247.224 ivory 291311 0 174209 0 133 lo0 65535 79 0 79 0 0 lo0 65535 loop localhost 79 0 79 0 0 sl0* 296 0 0 0 0 0 sl1* 296 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], and perhaps 1127 [A Perspective on the Host Requirements RFCs] ) に準拠して, FreeBSDによる SLIPサー バをルータとして動作させたいときには, /etc/sysconfig ファイル の gateway 変数を YES としてください. もし古いシステ ムのために /etc/sysconfig ファイルがないときには, 次のコマン ドを /etc/rc.local へ追加してください. sysctl -w net.inet.ip.forwarding = 1

この新しい設定を有効とするには, リブートする必要があります.

デフォルトのカーネルコンフィグレーションファイル (/sys/i386/conf/GENERIC) の最後の部分に, 次のような行がありま す. pseudo-device sl 2 この行によって, 使用可能な SLIPデバイスの総数が決まります. すなわち, 行 末の数値が, 同時に動作可能な SLIP接続の最大数となります. カーネルの再構築については, を参照ください. Sliploginのコンフィグレーション

すでにご説明したように, /usr/sbin/sliplogin のコンフィグレー ションのために, 3種類のファイルが/etc/sliphome ディレクトリに あります (sliplogin についての実際のマニュアルページとしては sliplogin(8) を参照のこと) . ファイル slip.hosts は SLIPユーザおよびその IPアドレスを決めます. 通常, ファイル slip.login は, SLIPインタフェースを設定することだけに使 用します. slip.logout はオプションのファイルで, slip.login で設定した内容を, シリアル接続が終了した時点で解除 するときに使用します. slip.hostsのコンフィグレーション

/etc/sliphome/slip.hosts には, 少なくとも 4 つの項目をホワイ トスペース (スペースやタブ) で区切って指定します. SLIPユーザのログインID SLIPリンクのローカル (SLIPサーバ側) アドレス SLIPリンクのリモートアドレス ネットワークマスク ホスト名をローカルおよびリモートのアドレスとして記述できます (IPアドレ スの決定は, /etc/host.conf の指定内容に応じて, /etc/hosts か DNSのいずれかによって決定される) . また, ネット ワークマスクも /etc/networks ファイルに記述された名前を参照す ることで, 指定することもできると思います. これまでの例としてあげたシス テムでの /etc/sliphome/slip.hosts は次のようになります. ----- begin /etc/sliphome/slip.hosts ----- # # login local-addr remote-addr mask opt1 opt2 # (normal,compress,noicmp) # Shelmerg dc-slip sl-helmerg 0xfffffc00 autocomp ----- end /etc/sliphome/slip.hosts ------ それぞれの行の最後には, 次に示すオプションを一つ以上指定できます. normal - ヘッダを圧縮しない compress - ヘッダを圧縮する autocomp - リモートの設定に応じて, ヘッダを圧縮する noicmp - ICMPパケットを禁止する (pingパケットは送出されず, バンド幅を占有しない) なお, FreeBSDバージョン2の初期リリースの の節で紹介した TCP/IP関連書籍を参考になさるか, またはあなたの IPネットワークを管理している方に相談なさるとよいでしょう. 独立したサブネットを SLIPクライアントへ適用するときには, すでに割り当 てられている IPネットワーク番号の範囲からサブネット番号を割り当て, 同 時にそのサブネットの範囲内で有効な IPアドレスを SLIPクライアントの IP 番号として割り当てる必要があります. さらに, この SLIPサブネットから SLIPサーバを経由して最も近い IPルータへの経路を静的に設定するか, また は gated を FreeBSDによる SLIPサーバへインストールして, 適当 なルーティングプロトコルを使って, SLIPサーバ経由のサブネットへの経路情 報をルータ群へ通知できるように設定するか, のいずれかをおこなう必要がありま す. 「プロキシ ARP」方式を採用するときには, SLIPクライアント向けの IPアドレス として, SLIPサーバのサブネットの範囲から選んで割り当てるとともに, arp(8) コマンドを使うために /etc/sliphome/slip.login と/etc/sliphome/slip.logout のスクリプトを修正して, SLIPサー バにおける ARPテーブル内のプロキシ ARPエントリへ反映させる必要がありま す. slip.loginのコンフィグレーション

ファイル /etc/sliphome/slip.login の一般的な内容は次にように なります. ----- begin /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 ----- end /etc/sliphome/slip.login ----- この slip.login ファイルの役目は単に, SLIPインタフェースにつ いてのローカルとリモートのアドレス, およびそのネットワークマスクを ifconfig コマンドで設定することです. もしプロキシ ARP方式を採用する (SLIPクライアントへ独立したサブネットを 使わない) ときには, ファイル /etc/sliphome/slip.login は次の ような内容になります. ----- begin /etc/sliphome/slip.login for "proxy ARP" ----- #!/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 ----- end /etc/sliphome/slip.login for "proxy ARP" ----- この 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 0.2.c1.28.5f.4a 191923 0 129457 0 116 ^^^^^^^^^^^^^^^ この例での Ethernet MACアドレスは 00:02:c1:28:5f:4a であると 読みます. なお arp(8) における MACアドレスの指定に際しては, コマンド netstat -i が付けた Ethernet MACアドレスのピリオド記 号をコロン記号と置き換え, かつ単一桁の 16 進数にはゼロを先頭に加える必 要があります. この指定についての正確な情報は arp(8) を参照く ださい. ご注意いただきたいのは, /etc/sliphome/slip.login と /etc/sliphome/slip.logout を作成したならば, ファイル属性の実 行ビット (すなわち chmod 755 /etc/sliphome/slip.login /etc/sliphome/slip.logout) を 設定しなければならないということです. さもなければ sliplogin が うまく実行されません. slip.logoutのコンフィグレーション

ファイル /etc/sliphome/slip.logout は必ずしも必要なものではあ りません (ただし「プロキシ ARP」を利用する場合を除く) . もしこのファイルを 作成するときには, 次に示す標準的な slip.logout スクリプト例を 参考にしてください. ----- begin /etc/sliphome/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 ----- end /etc/sliphome/slip.logout ----- 「プロキシ ARP」を利用する場合, この /etc/sliphome/slip.logout を 使って, 特定の SLIPクライアント向けの ARPエントリを削除したくなるよう なときがあります. ----- begin /etc/sliphome/slip.logout for "proxy 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 ----- end /etc/sliphome/slip.logout for "proxy ARP" ----- コマンド 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サブネッ トへ使うようにルータを設定しなければならないだけでなく, その静的経路を 他のどのルータへ知らせるのかもあらかじめ指定しておく必要がありますから, 静的経路に基づくルーティングを軌道に乗せるにはそれなりの専門的技術やト ラブルシューティングやコツが必要だと思います. gatedの稼働

静的経路についての頭痛への代替手段は, gated を FreeBSDによる SLIPサー バへインストールして, 適切なルーティングプロトコル (RIP/OSPF/BGP/EGP) を使って SLIPサブネットについての経路情報を他のルータへ知らせるように 設定することです. gated は, 匿名FTPを使って, ftp.gated.cornell.edu の /pub/gated ディレクトリから 入手できます. このチュートリアルを執筆時点の最新バージョンは gated-R3_5Alpha_8.tar.Z であり, このファイルだけで FreeBSDで 動作させることができます. gated についてのすべての情報と文書 は http://www.gated.cornell.edu/ からはじまる Web上で入手でき ます. gated のコンパイルとインストールを行ったならば, 独自の 設定のために /etc/gated.conf ファイルを記述してください. 次の 例は, 筆者が FreeBSDによる SLIPサーバで使っている内容と類似のものです. ----- begin sample /etc/gated.conf for gated version 3.5Alpha5 ----- # # 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 ; } ; ----- end sample /etc/gated.conf ----- この gated.conf ファイルの例では, SLIPのサブネット xxx.xxx.yy についての経路情報を RIPを使って Ethernetへブロー ドキャストしています. もし 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/handbook/stable.sgml b/ja/handbook/stable.sgml index ea0fee1a0c..adf0c2408e 100644 --- a/ja/handbook/stable.sgml +++ b/ja/handbook/stable.sgml @@ -1,107 +1,107 @@ - + FreeBSD の安定状態の持続

原作: &a.jkh;.

訳: &a.iwasaki;. FreeBSD-stable ってなに?

FreeBSD-stable は, 次の本流のリリースを目指した新機能をあまり採り入 れない保守的な変更のための開発の支流です. 実験的またはテスト未完の変更 はこの支流には取り入れられません ( 参照). 誰が FreeBSD-stable を必要としているの?

もしあなたが仕事で使用しているとか, なによりも FreeBSD システムの安 定性を最重要視するなら, stable を追いかけることを考えるべきで しょう. stableの支流は前のリリースに関して効果的にバグフィッ クスされた流れであるため, 最新のリリース ( 執筆時点) をインストールしているのであれば, 特に そうです.

stable ツリーが常に完全に互換性があり安定するように努力し ていますが, たまに間違いがあることに注意してください (結局, 内容が吟味 されずに素早く送られた変更を含むソースがまだあるのです). また, current を stable へ移行する前に完璧なテストフィック スに最善を尽くしますが, 私たちのテストはすべてのケースを十分に網羅して いるとは限りません. もし何か stable で不具合があるようでした ら, 私たちにすぐに教えてください (次の節参照). FreeBSD-stable を使う

&a.stable へ加わってください. このメーリングリスト では, stable の構築に関連する事柄や, その他の注意すべき点 に関する情報が流れています. また開発者は議論の余地がある修正や変更 を考えている場合に, このメーリングリストで公表し, 提案された変更に 関して問題が生じるかどうかを返答する機会をユーザに与えます. メーリングリストに参加するには, &a.majordomo へメッセージの本文に 次のように書いたメールを送ってください: subscribe freebsd-stable オプションとして本文に `help' と書けば, Majordomo は私たちがサポー トする様々なメーリングリストに参加 / 脱退する方法に関する詳しいヘ ルプを送付します. ftp.FreeBSD.ORG からのソースの入手. 以下の 3つの方法で おこなうことができます : 機能を使用する. 転送レートが 安定している TCP/IP 接続でない場合は, この方法が適して います. CMUの プログラム (ソフトウェア 更新プロトコル) を使用する. 一度コレクション全体を入手 してしまえば, 前回からの変更部分だけですむので, 2番目に 推奨される方法です. 多くの人が cron から sup を実行し, 自動的にソースコードを最新の状態に保っています. ftp を使用する. FreeBSD-stable 用のソースツリーは 常に次のところで「公開」されています :

私たちはまた, tar/compress でツリー全体を入手できる `wu-ftpd' を使用しています. 例えば : usr.bin/lex に対して: ftp> cd usr.bin ftp> get lex.tar.Z とすることにより, ディレクトリ全体を compress された tar ファイルとして入手することができます. 基本的には, ソースに迅速でオンデマンドなアクセスが必要で, 接続のバンド幅が問題でなければ, sup か ftp を使いましょう. そうで ない場合は CTM を使いましょう. stable をコンパイルする前に, /usr/src にある Makefile をよ く読んでください. 少なくとも一回はアップグレードの処理の一部として 最初に `make world' を実行するべきでしょう. &a.stable を読めば, 次 のリリースに移行するに当たって時々必要となる既存システムからの新シ ステムの構築手順についての最新情報が得られるでしょう. diff --git a/ja/handbook/submitters.sgml b/ja/handbook/submitters.sgml index 79bbf0a2b3..69d6b76947 100644 --- a/ja/handbook/submitters.sgml +++ b/ja/handbook/submitters.sgml @@ -1,583 +1,583 @@ - + FreeBSD への貢献

原作: &a.jkh;.

訳: &a.iwasaki;.13 December 1996.

あなたも何か FreeBSD のために貢献したくなりましたか? 素晴らしい! 私たちは常に支援を受ける用意がありますし, FreeBSD は生き残るためにユー ザベースの貢献に頼るようなシステムの一つです. あなたの貢献は 感謝されるだけではなく, FreeBSD が成長し続けるために極めて重要なものな のです!

一部の人達が言っているのとは逆に, 貢献を受け付けてもらうために腕利 きのプログラマーになるとか FreeBSD コアチームの人と親友になる必要はあ りません. FreeBSD プロジェクトの開発は, 多くのそして益々増加する世界中 の貢献者達によってなされており, 彼らの年齢, 専門技術分野は多岐に渡りま す. そして手の空いている人よりも成されるべき仕事の方が常に多いのです.

FreeBSD プロジェクトがカーネルや散在しているユーティリティよりも, オペレーティングシステム環境 (と, そのインストール) に対して責任を持つ ようになったため, 私たちの「TODO」リストはドキュメンテーション, ベータテ スト, 高度に専門化されたタイプのカーネル開発の好例を紹介するなど非常に 広い範囲のタスクに渡ります. あなたの技能レベルに関わらず, プロジェクト を支援できることが必ず何かあります!

FreeBSD 関連の事業に従事している商業団体が私たちにコンタクトすること も歓迎します. あなたの製品を (FreeBSD 上で) 動作させるには, 特別な拡張 が必要ではありませんか? あまりにも風変わりな要求でなければ, それを受け 入れる用意が私たちにあるとわかるはずです. 付加価値のある製品ですか? 私たちに知らせてください! 多分私たちは, ある 面において共同して作業をすることができるでしょう. フリーソフトウェア界 は, ソフトウェアがそのライフサイクルを通してどのように開発され, 売られ, 保守されていくかについて, 既存の仮説に挑戦しています. 少なくとももう一 度考慮してみることを私たちは強くお奨めします. 何が必要?

次のタスクとサブプロジェクトのリストは, コアチームの色々な TODO リ ストと最近2ヶ月で集めたユーザリクエストを合わせたものです. 可能なとこ ろでは, 緊急度によってタスクがランクづけされています. もしここにあるタ スクの実行に興味があるのでしたら, コーディネータの名前をクリックしてメー ルを送ってください. もしコーディネータが決まっていなければ, あなたがボ ランティアしてみませんか? 優先度の高いタスク

次のタスクは通常, ひどく壊れているとか, とても必要とされている何かを 表しているため, 急務と考えられています: 第3ステージ・ブート問題. 全体コーディネーション: &a.hackers

64MB を越えるメモリの正しい自動検出. userconfig (-c) の 第3ステージ・ブートへの移動. 第3ステージがディスクの BIOS ジオメトリの正確なマッピングを提供 できるように WinNT コンパチブルなドライブの追跡をおこなう. ファイルシステム問題. 全体コーディネーション: &a.fs MSDOS ファイルシステムの修正. nullfs ファイルシステムコードのクリーンアップと ドキュメンテーション. コーディネータ: &a.gibbs union ファイルシステムの修正. コーディネータ: &a.dyson LFS ファイルシステムの修正. コーディネータ: &a.dyson カーネル vm86 及びユーザ vm86 サポート実装. コーディネータ: &a.hackers Int13 vm86 ディスクドライバの実装. コーディネータ: &a.hackers SCSI ドライバ問題. 全体コーディネーション: &a.hackers

タグキューイングの一般的なサポート. 私たちのおこなっている コマンドキューイング方法の書換えが必要だが, とにかく優先度付けされた I/O にはこれが必要 (CD-R ライタ / スキャナ). エラー処理の改善 (ビジー・ステータスおよびリトライ). 統合された Scatter-Gather リスト生成コード. カーネル問題. 全体コーディネーション: &a.hackers

すべての現存ドライバの eisaconf 変換の達成. すべての割り込みルーチンをユニット番号を使う代わりに (void *) を 取るように変更. EISA/PCI/ISAの割り込み登録コードの統合. PCI/EISA/ISA デバイス検出を bt742a.c(WIP) のようなドライバから分割. syscons の ALT-TAB/vt 切替えによるハングの修正. コーディネータ: &a.sos syscons 用のマウスサポート. すべてのコンソールドライバ用のキーボードコードの統合. Intel Etherexpress 16 ドライバの書換え. 3c509と3c590 ドライバの統合 (本質的には PCI デバイス検出の ep.c への提供). Adaptec 3985 (シンプルな3チャネル SCSI カードとしては最初のもの) のサポート. コーディネータ: &a.gibbs Advansys SCSI コントローラ製品のサポート. コーディネータ: &a.gibbs 優先度がさほど高くないタスク

次のタスクはやっておくべきではありますが, 特にさし迫っているわけで はありません: DOS エミュレータ (DOS の実行ファイル用) コーディネータ: AFS (Andrew ファイルシステム) の FreeBSD への移植 コーディネータ: MCA サポート? これは続けるにしても止めてしまうにしても結論を出 すべき. 完全な LKM ベースのドライバのサポート / コンフィグレーションマネー ジャ.

ld なしですべての LKM の登録をおこなう方法を考案する. これは カーネル中にある種のシンボルテーブルを持たせることを意味します. 穏やかな方法でハードウェアを検知するコンフィグレーションマネージャ の作成 (第3ステージ・ブートの中に?). ハードウェアが必要とする LKM だけを 残す等. PCMCIA/PCCARD. コーディネータ: &a.nate と &a.phk ドキュメンテーション! pcic ドライバの信頼性のある操作 (テスト要). sio.c のリコグナイザとハンドラ (ほぼ完了). ed.c のリコグナイザとハンドラ (ほぼ完了). ep.c のリコグナイザとハンドラ (ほぼ完了). User-mode のリコグナイザとハンドラ (部分的に完了). 先進的なパワーマネージメント. コーディネータ: &a.nate と &a.phk APM サブドライバ (ほぼ完了). IDE/ATA ディスクサブドライバ (部分的に完了). syscons/pcvt サブドライバ. PCMCIA/PCCARD ドライバ群との統合 (サスペンド / レジューム). 優先度の低いタスク

次のタスクは全くのあら隠し, または誰もすぐにおこないそうもない投資 のような仕事を表します:

最初の20項目は Terry Lambert <terry@lambert.org> からのもので す. プロセッサ上で V86 モードを使用して, プロテクトモードからの BIOS コールができるようにし, マップされた割り込み IPC 機構を経由してプロテ クトモードの呼出し元に結果を返すようにする. DOS と同じように, 実際の下位ハードウェアから独立になるよう, BIOS コール機構を使用したカーネルの中に組み込まれたドライバ. これは DOS ベー スのローダプログラムで BSD がロードされる前に DOS にロードされていたネッ トワークドライバや ASPI ドライバも含みます. このことは潜在的なポーリン グ, つまりプロテクトモードカーネルによる V86 マシンのための DOS-not-busy 割り込みの生成を意味します. ハードウェア固有のプロテクトモードのドライバがロードされて活性化 された後で, デフォルトのカーネル実行形式の中の, そのようなドライバデー タとテキストエリアを追跡して, カーネルアドレス空間のその部分が回復され るようにするためのイメージ形式. これは個々の BIOS ベースのドライバを互いに分離することを含みます. なぜ なら全く実行しないよりも, すべてのケースにおいて BIOS ベースのドライバ と共に実行した方が良いためです. バスインタフェース機構の抽象化. 現在のところ, PCMCIA, EISA そし て PCI バスはブリッジで ISA バスに接続されていると仮定しています. こう いった仮定はおこなうべきではありません. パワーマネージメントイベント, カードの挿入, 取り出し, そしてバス (PNPISA と PCMCIA とのブリッジチップ) 対カードのレベルのイベント管理を 含む PNP イベントを解釈するコンフィグレーションマネージャ. 固定デバイスによる他の再割当可・不可のデバイス空間リソースの使用 と衝突しない, 再割当可能なアドレスの割り当てのためのトポロジカルソート 機構. ハードウェアサービス登録のための登録ベースの機構. 特にタイマ, サウンドおよび他のシステムクリティカルなサービス供給源のためのデバイス 中心の登録機構. 単一の独立していないサービス供給源の一つの例として Timer2, Timer0 そしてスピーカサービスを考慮する必要があります. 配置転換とシンボル空間操作をおこなう LKM ローダ機構からアクセス 可能な, カーネルのデータ空間内にあるエキスポートされたシンボル空間. こ のインタフェースの目的は, 必要な時にカーネルモジュールをロードして, 必 要がなくなればアンロードできる能力をサポートすることです. ネットワークカードと一緒に提供される ODI カードドライバを使用で きるようにする, NetWare サーバ (プロテクトモードの ODI ドライバ) ロー ダとサブサービス. NDIS ドライバと NetWare の SCSI ドライバについても同 様. 前のリビジョンの FreeBSD マシンではなく, Linux マシンで動作する 「アップグレード システム」オプション. 移植を簡単にするためと, X, ThinkPad, PS/2マウス, LED, コンソール スイッチング, しつこい NumLock などの問題を全部一度に片付けるためのコ ンソールドライバの抽象レイヤへの分割. 機会が許したら, 他の外部ドライバのための他のカーネルのエミュレー ション環境. SCO と Solaris は UnixWare などに続く良い候補です. 異なるアーキテクチャのバイナリの実行のためのプロセッサエミュレー ション環境. これはシステムコールインタフェースがあまり変わらなければ, 思ったより簡単です. 商用のストリームドライバを使用可能にするためのストリーム機構. カーネルのマルチスレッド化 (カーネルのプリエンプションが必要). カーネルのプリエンプション付き対称マルチプロセッシング (カーネル のプリエンプションが必要). ポータブルコンピュータのサポートにおける協調の試み. これは PCMCIA ブリッジング規則と電源管理イベント処理の変更により, いく らかは処理できます. しかし, 内蔵ディスプレイと外部ディスプレイの検出, この2種類のディスプレイがあるという事実に基づく異なる解像度の選択, マ シンがドックにある場合にはディスクのモータ停止を防止すること, マシンの ブート能力に影響を与えずにドックベースのカードの消滅を可能にすること (PCMCIA と同じ問題) などの問題があります. マルチプラットフォームへの移植のためのソースツリーの再組織化. 「make world」できちんと「世界を創造する」ができるようにする. (もし「make regress 訳注: 後退する」と呼び方が適当であれば, そのように 名前を変える) 最小必要メモリ 4MB 化 (もっと小さければなお良し!). 貢献の仕方

一般的に, システムへの貢献は次の6つのカテゴリの1つ以上に分類されま す: バグ報告と一般的な論評

報告するべきバグがあったり, 提案したいことがあれば: 一般的な技術的関心事に関するアイデアや提案は &a.hackers; へメールしてください. 同様に, このような事柄に興味のある (そして膨大なメー ル! に耐えられる) 人は, &a.majordomo; へメールを送って hackers メーリングリストに参加すると良いでしょう. 情報については を参照してください. 実際のバグ報告は send-pr(1) プログラムか を使用して提出してください. これは色々な項目についての 問い合わせをします. send-pr(1) プログラムの場合は, 単に <> で囲まれて表示されているものをあなた固有の情報 に置き換えて入力します. WEB ベースのインタフェースの場合は, そこで表示されているオプションメニューから適切な項目を選択し 必要項目を埋めるだけです.

あなたはバグ報告の確認とトラッキング番号をメールで受け取る はずです. このトラッキング番号を覚えておき後々の連絡に使用して, 他の人がその問題の詳細を素早く見つけられるようにしてください. また, にサブジェクト行に PR# を付けた メールを送って, より詳しい情報を既存のバグ報告に追加することも できます. もしタイムリに (あなたの電子メール接続形態にもよりますが, 3日から 1週間) 確認を受けとれないとか, 何らかの理由で send-pr(1) コマンドが使用できない場合には, &a.bugs へメールを送ってバグ報告を 提出してください. 文書の変更

文書の変更は &a.doc; が監督しています. 一般的にこれは「現存のソース コードの変更」のカテゴリで考慮されるべきマニュアルページの変更は含ん でいません. 現存のソースコードの変更

現存のソースコードへの追加または変更は, いくらかトリッキーな仕事で あり, core の FreeBSD 開発の現状にあなたがどれだけ通じているかに大 きく依存します. 「FreeBSD-current」として知られる FreeBSD の特別な 継続的リリースがあります. FreeBSD-current は開発者の積極的な活動の 便宜のために, 色々な方法で利用可能になっています. FreeBSD-current の入手と使用方法についての詳しい情報については を参照してください. 不幸にして古いソースをもとに仕事をすることは, 時々あなたの変更が時 代遅れ, または FreeBSD への簡単な再統合に合わなくなっていることを意 味します. システムの現状に関する議論がおこなわれている &a.announce と &a.current へ参加することで, この可能性を最小限にすることができます. 完全な最新のソースを変更のベースにできることが確実になったと仮定し て, 次のステップは FreeBSD の保守担当者へ送る差分ファイルの生成です. これは diff(1) コマンドを使用しておこないますが, 「context diff」形式が好まれるようです. 例えば: diff -c oldfile newfile または diff -c -r olddir newdir これで指定されたソースファイルまたはディレクトリ階層に対するコンテ キスト形式の差分が生成されます. 詳しい説明は diff(1) のマ ニュアルページを参照してください. 差分ファイル (patch(1) コマンドでテストできます) を作った ら, それらを電子メールのメッセージにバンドルして, 差分ファイルの目 的の簡単な説明と一緒に &a.hackers; へ送ってください. 誰かが24時間以 内にあなたにコンタクトを取ってくるでしょう. もちろん, あなたの差分 ファイルが興味深いものであると仮定していますが! :-) あなたの変更が差分ファイル単独でそれ自身を良く表現できない場合は (例えば, ファイルの追加, 削除または名称変更が必要など), 新たなファ イルをまとめて出した方が良いでしょう. 差分ファイルと他のファイルの 削除 / 名称変更の指示を tar ファイルに格納し, uuencode(1) プログラムにかけてから &a.hackers; へ送ってく ださい. このファイルのバンドル方法に関する詳しい情報については, tar(1) と uuencode(1) のマニュアルページを参照し てください. 例えばあなたがそれ自身のさらなる配布を管理するコピーライト問題を良 く分かっていないとか, 単に厳しいレビューをおこなっておらず, リリース する準備ができていないなど, あなたの変更が潜在的に不安定な性質をも つものである場合, &a.hackers よりむしろ &a.core; へ送ってください. コアチームメーリングリスト宛のメールは, 日々の仕 事のほとんどを FreeBSD でおこなっている人たちの, より小さなグルー プに届きます. このグループもまたとても忙しい ことに注意し て, hackers への投稿が本当に実際的でない場合に, コアチームの彼らに メールを送るだけにしてください. コーディングスタイルに関する情報は man 9 intro および man 9 style を参照してください. コードを提出する前には, 少なくともこの情報を意識しておいてくださるようお願いします. 新たなコードやメジャーな付加価値の高いパッケージ

重要な大きい仕事の寄贈や, 重要な新しいフィーチャーを FreeBSD に追加 する場合には, 変更点を tar/uuencode したファイルにして送るか, それ らを私たちの ftp サイト へアップロードす ることのどちらかが通常必要になります. 大量のコードを伴った仕事の場合, コピーライトの神経過敏な問題が常に 出てきます. FreeBSD に含めるコードのコピーライトとして受け入れるこ とができるのは, 以下の二つです: BSD コピーライト. このコピーライトは「権利に縛られない」性格 と商用企業にとって一般的な魅力をもつために最も好まれま す. FreeBSD プロジェクトは商用利用を阻んだりせず, 何かを FreeBSD へ投資する気になった商業関係者による参加を積極的に奨励 します. GNU一般公有使用許諾, または「GPL」. このライセンスはコード を商用目的に使用する場合に余分な努力が求められるため, 私たち にあまり評判が良いというわけではありません. しかし, 私たちは 既に GPL 下の高品質なコード (コンパイラ, アセンブラ, テキスト フォーマッタ等) の提供を受けており, 私たちは現在それを必要と しています. そのため, このライセンスによる新たな貢献を拒絶す るというのは愚かなことでしょう. GPL 下のコードはソースツリー の別の部分, 現在のところ /sys/gnu か /usr/src/gnu に入っています. そのため, GPL が問題と なるような人は, 誰でも簡単にそれとわかるようになっています.

これ以外のタイプのコピーライトによる寄贈は, FreeBSD へ含めることを 考慮する前に, 注意深いレビューを受けなければなりません. 作者が独自 のチャネルを通して配布しており, そのような変更をおこなうことを常に 奨励している場合でも, 特に限定的な商用のコピーライトが適用される寄 贈は一般に拒否されます. あなたの作品に「BSD-スタイル」のコピーライトを付けるには, 保護した いソースコードファイルすべての一番最初に以下のテキストを入れて, `%%' の間を適切な情報に置き換えください. Copyright (c) %%適切な年%% %%あなたの名前%%, %%あなたの州%% %%郵便番号%%. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer as the first lines of this file unmodified. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS SOFTWARE IS PROVIDED BY %%あなたの名前%% ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL %%あなたの名前%% BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. $Id$ 便宜をはかるため, このテキストのコピーは次の場所に置いてあります. /usr/share/examples/etc/bsd-style-copyright. &porting; 金銭, ハードウェアまたはインターネットアクセス

FreeBSD プロジェクトの目的を進めるための寄付や, 私たちと同じような ボランティアの細く長い ! 努力を, 私たちは常に喜んで受け入れています. また一般的に私たちは自分達で周辺機器を買う資金が不足しているため, 周辺機器のサポートを充実させるのにハードウェアの寄付はとても重要です. 資金の寄付

FreeBSD プロジェクトは501(C3) (非営利) 企業ではないため, いかなる寄 付に対しても特別な税金の優遇措置を提供することができません. このような 寄付はプロジェクトを代表して FreeBSD, Inc により感謝をもって受け入れら れるでしょう.

FreeBSD, Inc.は FreeBSD プロジェクトの推進とプロジェクトに企業とし ての最小限の体裁を持たせることを目的として, 1995年の初めに &a.jkh と &a.davidg により設立されました. 寄付されたすべての資金は (最終的に FreeBSD, Inc.によりもたらされるであろうすべての利益も同様に) プロジェク トの目標を推進するためだけに使われるでしょう. 支払い先を FreeBSD, Inc. とした小切手を, 次の住所気付けで送ってください: FreeBSD, Inc. c/o Jordan Hubbard 4041 Pike Lane, suite #D. Concord CA, 94520 [私書箱が開設されるまで一時的に Walnut Creek CDROM の住所を使用] 電信振替は次の所まで直接送れるでしょう: Bank Of America Concord Main Office P.O. Box 37176 San Francisco CA, 94137-5176 Routing #: 121-000-358 Account #: 01411-07441 (FreeBSD, Inc.) もし の節で匿名を希望される 方は, 寄付の際にその旨お伝えください. Thanks! ハードウェアの寄贈

FreeBSD プロジェクトは, 次の3つのカテゴリのどんなハードウェアの寄贈 も, 喜んで受け付けます: ディスクドライブ, メモリまたは完全なシステムといった一般用途のハー ドウェアは, 資金の寄付の節にある FreeBSD, Inc. の住所まで送っ てください. 進行中の受け入れテストのためのハードウェアが必要とされていま す. 新たなリリース毎に適切な逆行テストができるように, 私たちは現在, FreeBSD がサポートするすべてのコンポーネントのテストラボを設置しよう としています. 私たちにはまだ, たくさんの重要な部品 (ネットワークカード, マザーボードなど) が不足していますので, このような寄贈をしたいと思って いるならば, &a.davidg へコンタクトしてどの部品がまだ必要とされているか の情報を得てください. 現在 FreeBSD にサポートされていないハードウェアで, サポートに追 加して欲しいもの. 私たちがそれらの荷物を受けとる前にそのタスクを引き受け てくれる開発者を探す必要があるため, その部品を送る前に &a.core; にコンタクトを取ってください. インターネットアクセスの寄付

私たちは常に FTP, WWW や sup の新しいミラーサイトを募集しています. ミラーサイトになりたい場合には にコンタクトを取って, 詳し い情報を手に入れてください. 寄贈者ギャラリー

FreeBSD プロジェクトは次の寄贈者に恩義を受けており, ここに公表して 感謝の意を表したいと思います. は, FreeBSD のさらなる開発のための資金を気前良く寄付してくださいま した. は, FreeBSD の開発のための資金を気前 良く寄付してくださいました. は, FreeBSD の開発のための資金を気前良く寄付して くださいました. 日本の は, FreeBSD の NEC PC98 への移植である FreeBSD for PC98 CD の販売利益の一部を, 気前良く寄付 してくださいました. は, 言い表せないほど多くの寄付をしてくださいました (詳細はを参照). 特に, 私たちのプライマリ開発マシンである freefall.FreeBSD.ORG, 私たちのテストおよびビルドマシン であるthud.FreeBSD.ORG で使用しているハードウェアに対し 感謝したいと思います. また彼らには, 数年にわたる色々な貢献者への資金提供や, インターネッ トへの T1 コネクションの無制限使用を提供してもらったという恩義があり ます. は, &a.joerg; を根気良くサポートしてくださいました. 彼は本職より FreeBSD の仕事を好みがちであり, 彼個人の接続があまりに 遅くなったり途切れたりして仕事にならない時は必ず interface business の (非常に高価な) EUnet インターネット接続に頼ったものです... diff --git a/ja/handbook/sup.sgml b/ja/handbook/sup.sgml index 7d2e7edc3d..d80243dcb5 100644 --- a/ja/handbook/sup.sgml +++ b/ja/handbook/sup.sgml @@ -1,158 +1,158 @@ - + SUP

原作: &a.jkh; and &a.gclarkii;.

訳: &a.iwasaki;.28 December 1996. SUP は CMU で開発されたネットワークベースのソフトウェア更新ツールです. この文書の目的は初心者が sup を利用できるようにすることです. SUP のコンフィグレーション

SUP は supfile と呼ばれるコンフィグレーションファイルから, 実行す るのに必要な情報を取得します. FreeBSD のソースリリースによって提供さ れる異なる supfile の見本があります. は最新の標準 FreeBSD ソース配布ファイルの sup 情報を含んでいます - このファイルは sup に, 何のコレクションが更新かつ / またはインストールされるか, ど こにインストールされるかを伝えます. 特にこの supfile を使用している 人は, を sup することになります.

ports に関しては, に目を通してください.

もしソースツリーを構築する files ファイルの入手に興味があるのでしたら, を参照してください.

むしろ -stable 支流への変更を追いかけたいのであれば, 代わりに を参照してください. アメリカ合衆国内に住んでいる方は, DES コードを持ってくるために `secure' と `eBones' コレクションの行のコメントを外してください. 合衆国国外にいる方は, 合衆国の輸出規制を犯すことになるので, このコー ドをsup.FreeBSD.ORG から sup すべきではありません. この代わりに sup examples ディレクトリ内にある を使用してください. これは secure 配布ファイ ルを含む国際的な sup サイトへ接続します. 受けとりたくない配布ファイ ルは, 配布ファイルの行の先頭にて &num でコメントアウトすることができ ます. 代替の sup サーバの一覧は, を参照してください. 現在, 上 記の見本ファイルにあるデフォルトの sup サーバ (sup.FreeBSD.ORG) は超 負荷の状態であるので, どんなトラフィックでも他のホストへ乗り換えられ れば, いくらか重荷が軽減できるでしょう. このセットアップが終れば準備完了です. sup の起動は: sup supfile とタイプします. sup が何をしているかを「冗長に」に見たいなら, 次のように -v を与えてください: sup -v supfile 以上です! あなたが current を実行しているかどうか, standard-supfile で sup するときに得られるものが何かを覚えておき, &a.current へ参加して ください. -current ユーザとしてのあなたに対して, 私たちが何ができて 何ができないかの重要な情報として, を 読んでおいた方がよいでしょう. stable-supfile をお使いの方は, &a.stable へ参加し を 読んでください. SUP 配布ファイル

standard-supfile を使用したメインの FreeBSD 配布ファイルは: src-base: /usr/src/... /usr/src のトップにあるその他のファイル src-bin: /usr/src/bin ユーザとシステムのバイナリ src-secure: /usr/src/secure DES のソース (US/Canada ONLY) src-eBones: /usr/src/eBones Kerberos と DES (US/Canada ONLY) src-etc: /usr/src/etc システムファイル src-games: /usr/src/games ゲーム src-gnu: /usr/src/gnu GNU Public License 下にあるソース src-include: /usr/src/include インクルードファイル src-sys: /usr/src/sys カーネルのソース src-lib: /usr/src/lib ライブラリ src-libexec: /usr/src/libexec システムバイナリ src-release: /usr/src/release release を構築するために必要なソース src-share: /usr/src/share 色々な共有リソース src-sbin: /usr/src/sbin シングルユーザのシステムバイナリ src-tools: /usr/src/tools 色々な管理ツール src-usrbin: /usr/src/usr.bin ユーザバイナリ src-usrsbin: /usr/src/usr.sbin システムバイナリ

secure-supfile を使用した国際的な FreeBSD 配布ファイルは: src-secure: /usr/src/secure DES のソース src-eBones: /usr/src/eBones Kerberos と DES

また, 輸出規制のあるソフトウェア (たとえば, src-secure と src-eBones コレクション) の両方のバージョン (合衆国内または 国外) を除く, 上記すべてを含むコレクションがあります: src-all: /usr/src オペレーティングシステム全体 (ほぼすべて)

そして ports コレクションは: ports-base: /usr/ports/... /usr/ports のトップにあるその他のファイル ports-archivers: /usr/ports/archivers アーカイビングのツール ports-astro: /usr/ports/astro 天文学関連の ports ports-audio: /usr/ports/audio サウンドサポート ports-benchmarks: /usr/ports/benchmarks ベンチマークプログラム ports-cad: /usr/ports/cad CAD ツール ports-chinese: /usr/ports/chinese 中国語サポート ports-comms: /usr/ports/comms 通信ソフトウェア ports-databases: /usr/ports/databases データベース ports-devel: /usr/ports/devel 開発ユーティリティ ports-editors: /usr/ports/editors エディタ ports-emulators: /usr/ports/emulators 他の OS のエミュレータ ports-games: /usr/ports/games ゲーム ports-graphics: /usr/ports/graphics 色々なグラフィックユーティリティ ports-japanese: /usr/ports/japanese 日本語サポート ports-lang: /usr/ports/lang プログラミング言語 ports-mail: /usr/ports/mail メールソフトウェア ports-math: /usr/ports/math 数値計算ソフトウェア ports-mbone: /usr/ports/mbone MBone アプリケーション ports-misc: /usr/ports/misc 色々なユーティリティ ports-net: /usr/ports/net ネットワーキングソフトウェア ports-news: /usr/ports/news USENET ニュースのソフトウェア ports-plan9: /usr/ports/plan9 Plan9 からの色々なプログラム ports-print: /usr/ports/print 印刷ソフトウェア ports-russian: /usr/ports/russian ロシア語サポート ports-security: /usr/ports/security よりよい (悪い?) 「セキュリティ」関連のユーティリティ ports-shells: /usr/ports/shells 色々な UN*X シェル ports-sysutils: /usr/ports/sysutils システムユーティリティ ports-vietnamese: /usr/ports/vietnamese ベトナム語サポート ports-www: /usr/ports/www WWW 関連のソフトウェア ports-x11: /usr/ports/x11 X11 のソフトウェア

また, 上記すべてを含むコレクションがあります: ports-all: /usr/ports ports ツリー全体 diff --git a/ja/handbook/synching.sgml b/ja/handbook/synching.sgml index 86f5d0223b..10606864ef 100644 --- a/ja/handbook/synching.sgml +++ b/ja/handbook/synching.sgml @@ -1,52 +1,52 @@ - + インターネットを通じたソースツリーの同期

原作: &a.jkh;.

訳: &a.iwasaki;.28 December 1996.

インターネット接続 (または電子メール) を使用して, あなたの興味の対 象によって FreeBSD プロジェクトのソースのある一部分または全体の最新を 追いかける方法は色々あります. 私たちが提供している基本的なサービスは CVSup と CTM です:

CVSup は目下売り出し中で, sup のすべての機能プラスαをそな え, 要求するサーバのディスクスペースとネットワーク資源の観点からずっと 効果的に動作します. このため, CVSup は FreeBSD プロジェクトにおいて の大部分を置き換えました. また, sup のように pull 同期モデルで動作します.

一方, CTM はあなたが持っているソースとマスタアーカイブ上に あるそれとの対話的な比較をおこないません. そのかわりに, 前回の実行時からの変更を認識するスクリプトがマスタアーカ イブ上で一日に数回実行され, すべての変更を compress して通し番号を振り, さらに電子メールで転送できるようにエンコードします (印字可能な ASCII キャラクタのみです). 受信した後は, これらの「CTM のデルタ」は自動 的にデコード, 検査してユーザのソースのコピーに変更を適用する ctm_rmail(1) によって処理可能となります. この処理は CVSup よりずっと効率 的であり, pull モデルというよりむしろ push モデルで あるため, 私たちのサーバ資源の負荷は軽くなります.

もちろん他のトレードオフもあります. あなたが CVSup でうっかりアーカイブ の一部を消してしまっても, CVSup は壊れた部分を検出して再構築してくれます. CTM はこれをやってくれません. もしソースツリーの一部を消してしまったら, 一からやり直して (最新の CVS 「ベースデルタ」から) すべてを再構築しなければ なりません. CVSup と CTM, あるいは今では時代遅れとなってしまった sup についての 詳しい情報については, 以下の節を参照してください: &ctm; &cvsup; ⊃ diff --git a/ja/handbook/term.sgml b/ja/handbook/term.sgml index e7d676d9c7..d51941f6ed 100644 --- a/ja/handbook/term.sgml +++ b/ja/handbook/term.sgml @@ -1,527 +1,527 @@ - + シリアル端末

原作: &a.kelly;28 July 1996

訳: &a.max; シリアル端末を利用することで, コンピュータのコンソールのそばにいないと きや, 手近にネットワーク接続されているコンピュータがないときでも, FreeBSD の機能を便利に, かつ安価に利用することができます. ここでは, FreeBSD にシリアル端末を接続する方法を解説します. 端末の種類と利用方法

もともと Unix システムにはコンソールがありませんでした. ユー ザはコンピュータのシリアル ポートに接続された端末からログインして プログラムを利用していました. ちょうどモデムと通信ソフトを使ってリモート のコンピュータにログインし, テキスト ベースのプログラムを利用するのと よく似ています. 最近の PC は, 高品質の画像を表示できるコンソールを搭載していま すが, ほとんどすべての Unix 系 OS には未だにシリアル ポートを使ってログ インするための機能があり, FreeBSD でもこの機能がサポートされています. 現在使用されていないシリアル ポートに端末を接続することでシステムに ログインし, 通常はコンソールや Xウィンドウ システムの 以下は, それぞれについての解説です. ダム端末

ダム端末は, シリアルライン経由でのコンピュータとの接続専 用のハードウェアです. ダム端末は, テキストの送受信および表示ができる 程度の計算能力しかもっていないので, ``dumb'' (間抜け) というように呼ば れています. この端末上でプログラムを実行することはできません. テキスト エディタ, コンパイラ, E-mail, ゲームなどなどのプログラムを実行するのは, ダム端末を接続しているコンピュータの方です. Digital Equipment社の VT-100 や, Wyse社の WY-75 を初めとして, 多くのメーカが何百種類もの ダム端末を作っています. ほとんどどんな種 類のダム端末でも FreeBSD に接続して使用できます. さらに, 高性能の端 末の中には画像を取り扱えるものもありますが, 限られた数のソフトウェア パッケージしかこういった機能には対応していません. ダム端末は, X ウィンドウ システムで提供されるようなグラ フィックアプリケーションを必要としない職場で広く用いられています. PC を端末として利用する

がテキストの表示およ び送受信の機能をそなえただけのものならば, 言うまでもなく, どんなPC もダム端末になり得ます. 必要なものは適切なケーブルと, そのPCの上 で動作するX 端末

X 端末は, 既存のものの中で最も洗練された種類の端末といえ ます. X 端末は, たいていの場合シリアル ポートで゜はなく, イーサネッ トのようなネットワークを利用した接続をおこないます. また, アプリケーション の利用においても, テキストベースのものだけでなく, X アプリケーション の利用が可能です. ここでは, 参考までに 端末について紹介しただけで, X 端 末の設定や利用についての解説はケーブルとポート

シリアル端末を FreeBSD システムに接続するためには, 適切なケー ブルと, 端末を接続するためのシリアルポートが必要です. ここでは, これ らについて説明します. もし既にあなたの利用したい端末と, その端末 を接続するためのケーブルについてよく理解していれば, の章まで読み飛ばしてください. ケーブル

端末の接続は, シリアルポートを利用します. そこで, 端末を FreeBSD システムに接続するためには, シリアルケーブル (RS-232C ケーブ ルとも呼ばれています) が必要となります. シリアルケーブルには2種類のケーブルがあります. どちらの種類の ケーブルを使わなければいけないかは, どんな端末を接続したいかによります. もし, PC を端末として利用したい場合は, ケーブル (リバースケーブルもしくは クロスケーブルと呼ばれることもしばしばあります) を使用してください. ヌルモデムケーブルは, コンピュータ同士や端末同士を接続するために用い られるケーブルです. もし, 本物の端末を接続するのであれば, その端末につい てきたドキュメントからどのようなケーブルを使うべきか調べてください. も しドキュメントがない場合は, まず ケーブルを試してみて, うまくいかない場合は ケーブル (しばしばストレートケーブルと呼 ばれます) を試してみてください. また, 端末側と FreeBSD 側の ヌルモデムケーブル

ヌルモデムケーブル (またはリバースケーブルあるいはクロ スケーブル) は, たとえば ``signal ground'' 信号のように, いくつかの信 号はそのまま通しますが, 他の信号は途中で入れ替えて通します. たとえば, ``send data'' 信号のピンは, 反対側のコネクタの ``receive data'' 信号の ピンと繋がっています. 自分で使うケーブルは自分で作りたいということであれば, 以下にター ミナルを接続する際に推奨されるヌルモデムケーブルの結線を示しておきま す. この表では, RS-232C の信号線の名前と, DB-25 コネクタ上のピンの番 号を示しています. Signal Pin# Pin# Signal TxD 2 ----------------------- 3 RxD RxD 3 ----------------------- 2 TxD DTR 20 ----------------------- 6 DSR DSR 6 ----------------------- 20 DTR SG 7 ----------------------- 7 SG DCD 8 ----------------------+ 4 RTS* *RTS 4 + + 5 CTS* *CTS 5 +---------------------- 8 DCD * まず, コネクタ内部でピン4を5に接続し, そして逆側のコネクタのピン8と接 続します. スタンダード RS-232C ケーブル

スタンダードシリアルケーブル (またはストレートケーブル) の場合は, すべての RS-232C 信号をそのまま通します. つまり, 片方の ``send data'' 信号のピンは, 逆側の ``send data'' 信号のピンと繋がっています. モデムを FreeBSD に接続するときや, 一部の端末を接続するときにこのタイプの ケーブルを使用します. ポート

シリアルポートは, FreeBSDが動作しているホスト コンピュータと端 末の間でデータのやりとりを行うために用いるデバイスです. ここでは, 現在存在するポートの種類と FreeBSD でのポートのアクセス方法について解 説します. ポートの種類

シリアルポートには何種類かのものがあります. ケーブルを購 入したり自作したりする前に, そのケーブルのコネクタの形状が端末および FreeBSD システムのポートの形状と一致していることを確認してください. ほとんどの端末は DB25 ポートを搭載しています. FreeBSDが動作しているも のを含めて, PCは DB25 または DB9 ポートを搭載しています. マルチポート のシリアルカードの場合は, RJ-12 や RJ-45 のポートを搭載しているかもし れません. 利用されているポートの種類に関しては, ハードウェアについてきたドキュメ ントを参照してください. また, 多くの場合, ポートの形状から判断すること もできるでしょう. ポートの名前

FreeBSDでは, /dev ディレクトリ内のエントリを介 してシリアルポートへのアクセスがおこなわれます. 2種類の異なったエン トリがあります. 着信用のポートの名前は, /dev/ttyd (発信用のポートの名前は, /dev/cuaa となっています. 発信用のポートは普通モデムの接続に用い, 端末の接続には 利用しません. ただ, ケーブルまたは端末がキャリア検出信号を使えない タイプのものの場合は, 発信用のポートを使うとよいでしょう. 詳しくは, sio(4) のマニュアルをご覧ください. たとえば, 端末を一つ目のシリアルポート (DOS でいうところの COM1) に接 続したとすると, /dev/ttyd0 がこの端末を指すことになります. また, 二つ目のシリアルポート (COM2) ならば /dev/ttyd1 となり, 以下この形式のデバイスエントリを使います. 各シリアルポート, 特にマルチポートのシリアルカードを利用する ために, kernel の設定をおこなう必要がある場合がありますので, 注意してくだ さい. 詳しくは, をご覧ください. 設定

ここでは, 端末からのログインを可能にするために必要な FreeBSD 側の設定について解説します. 既に端末を接続するポートが利用できるように kernel の設定をおこない, 端末が接続されているものと考えて, 解説を進め ます. 簡単に言えば, プロセス管理や初期化をおこなっている /etc/ttys の内容を編集する必要があります. まず, /etc/ttys に以下の 変更を加えてください. 端末を接続するポートの /dev のエントリが含ま れている行がまだ存在しなければ, これを /etc/ttys に追加してく ださい. /usr/libexec/getty が対象となるポートに対して 実行されるように指定してください. また, /etc/gettytab ファイ ル内の適切な デフォルトのターミナルタイプを指定してください. 対象となるポートを ``on'' に設定してください. そのポートが ``secure'' であるかどうかを指定してくださ い. /etc/ttys を読み込みなおさせてく ださい. また, 必要に応じて /etc/gettytab を変更し, 上の 2で使用する /etc/ttys について, より詳しくは, ttys(5) のマニュアルをご覧 ください. /etc/ttys へのエントリの追加

既にエントリがある場合を除いて, まず初めに /etc/ttys にエントリを追加しなければいけません. /etc/ttys には, FreeBSDシステム上のログインを許可するすべての ポートを記述します. たとえば, 一つ目の仮想コンソール /dev のエントリを, /dev の部分 を省略して記述します. FreeBSD のインストール当初の状態では, /etc/ttys に記述され ています. これらのポートのいずれかに端末を接続する場合は, 新たなエント リを追加する必要はありません. ここで紹介している例では, 既にファイルにエントリが存在する 2番目のシリ アルポート, /etc/ttys か ら抜粋して示します. ttyd1 "/usr/libexec/getty std.9600" unknown off secure ttyd5

次に, 端末からのログインを処理するプログラムの指定をおこな います. FreeBSDでは, 標準的には /usr/libexec/getty をこの目的 で利用しています. /etc/gettytab から 読み込みます. ファイル /etc/gettytab には, 新旧の端末に関する多数のエントリ が記述されています. ほとんどの場合, /etc/ttys の /etc/ttys の設定です. ttyd1 "/usr/libexec/getty std.38400" unknown off secure ttyd5 "/usr/libexec/getty std.19200" ここで, 実行するプログラムを指定している 2番目のフィールドが, ダブルクォー テーションに囲まれていることに注意してください. こうしないと, デフォルトのターミナルタイプの指定

/etc/ttys の 3番目のフィールドには, そのポートのター ミナルタイプのデフォルトを指定します. ダイアルアップ用のポートの場合 は, ユーザがどのタイプの端末あるいは通信ソフトを利用してダイアルアップ してくるかは分からないので, /etc/ttys の中でターミナルタイプが指定されていれば, このプロンプトを表示せずに先に進むことが可能です. FreeBSD 上で, どのターミナルタイプを利用できるかは, /usr/share/misc/termcap をご覧ください. このファイルには, お よそ 600 のターミナルタイプが定義されています. 必要ならば, 新たなエン トリを追加することも可能です. 詳しくは termcap(5) のマニュアルをご覧く ださい. 紹介している例では, Wyse-50 のターミナルタイプは Wyse-50 です (もっ とも他のタイプをエミュレートすることも可能ですが, ここでは Wyse-50 モー ドで使用します. ). また, 286マシン上では Procomm が VT-100 エミュレー ションをおこなうように設定されています. 以下が, まだ未完成の /etc/ttys の関連部分です. ttyd1 "/usr/libexec/getty std.38400" wy50 off secure ttyd5 "/usr/libexec/getty std.19200" vt100 ポートを利用可能にする

/etc/ttys のつぎのフィールド, つまり 4番目のフィー ルドは, そのポートをアクティブにするかどうかの設定です. このフィールド に ``on'' を指定すると, /etc/ttys です. それぞれのポートを ttyd1 "/usr/libexec/getty std.38400" wy50 on secure ttyd5 "/usr/libexec/getty std.19200" vt100 on ``secure'' なポートの指定

とうとう最後のフィールドの設定です. (実際にはここでは触れ ませんが, オプショナルな/etc/ttys のエントリに端末の場所を表 すコメントを追加したものを示します. ttyd1 "/usr/libexec/getty std.38400" wy50 on insecure # Kitchen ttyd5 "/usr/libexec/getty std.19200" vt100 on insecure # Guest bathroom /etc/ttys の再読み 込みをさせる

FreeBSD をブートすると, 最初に起動されるプロセス, /etc/ttys を読み込んで, 記述されているプログラムを利用可能な ポートに対して実行し, ログインプロンプトを送り出させます. /etc/ttys の編集が終わった後, /etc/ttys を読み込みなおすようになっています. /etc/ttys の変更を保存したら, 以下のようなコマンドを実行して, kill -HUP 1 (トラブルシューティング

細心の注意を払って設定をおこなっても, ときには端末の接続がう まくいかない場合があるでしょう. 以下に, よく見られる問題とその解決方法 を示します. ps -axww|grep getty その端末に対する /etc/gettytab 中の 22189 d1 Is+ 0:00.03 /usr/libexec/getty std.38400 ttyd1 もし, /etc/ttys の中で, そのポートを利用可能にする設定をしたかどう か確かめてください. また, /etc/ttys を修正し てから, diff --git a/ja/handbook/troubleshooting.sgml b/ja/handbook/troubleshooting.sgml index 2e02c5e9af..853ed82e50 100644 --- a/ja/handbook/troubleshooting.sgml +++ b/ja/handbook/troubleshooting.sgml @@ -1,65 +1,65 @@ - + トラブルシューティング

原作: 不明.

訳: &a.iwasaki;.

インストールに失敗している (あるいは失敗してしまった) 人がうまく いくようにするのに役立つヒントやコツを以下に示します. 注意深く読ん でください. ハードウェアコンフリクトまたはコンフィグレーションのミス

問題: デバイスが他のものとコンフリクトを起こす, また は IRQ やアドレスがカーネルのコンパイル時に設定したものと合って いません. 原因: 今ではほとんどの FreeBSD のデバイスドライバは, 動的にハードウェアの設定に合わせるように十分賢くなっていますが, 中には動作する前にコンパイル時に設定した (そしてハードウェアに 合致する) パラメタをあい変わらず要求するものがまだ少しあります. しぶとく残っているそれらをできる限り多く取り除くように一所懸命 作業しいていますが, 必ずしも見た目ほど簡単なわけではありません. 解決策: 可能な解決策がいくつかあります. 最初に, そし て最も簡単なものは -c フラグをつけてカーネルをブートす ることです. 初期ブートプロンプト (フロッピーディスクかハードディ スクから起動) で: /kernel -c とタイプしてください. メモリのサイジングコードを過ぎてから動的カーネル設定ユーティリ ティが起動されます. コマンドの一覧を見るには, プロンプトで `?' とタイプします. このユーティリティを使用して, IRQ, メモリアドレス, IO アドレスまたはデバイスのたくさんの他の設定パ ラメタを再設定することができます. また動作させたいデバイスに問 題を引き起こすデバイス全体を無効にすることもできます. もう一つの解決策は, 当り前のことですが, 問題のあるハードウェア を取り外すか, 何も考えずに (うまくいけば) 問題がなくなるまでシ ステムを基本的な部品だけの状態に取り去っていくことです. 一度起 動してしまえば, 上に述べたのと同じことができます --- ハードウェ アにより一層合うようにカーネルをコンパイルしたり, 動かなかった もともとのハードウェア設定の原因は何かを一つ一つ明らかにするこ とができます. 初めてブートしたときに, まだ /386bsd を探しています!

原因: 古い FreeBSD 1.x のブートブロックが, まだディスクのブート パーティションに残っています. 解決策: インストールのプロセスをもう一度おこない, (F)disk エディタ を起動して (W)rite オプションを選択する必要があります. すでに存在 するインストレーションに害を与えずに, 確実に新しいブートブロックを ドライブに書き込むことができます. もし初めてインストールしているの でしたら, 新しいブロックを (W)rite することを忘れないでください! :-) diff --git a/ja/handbook/uart.sgml b/ja/handbook/uart.sgml index d31a2302c1..a399bba6d0 100644 --- a/ja/handbook/uart.sgml +++ b/ja/handbook/uart.sgml @@ -1,1093 +1,1093 @@ - + UART とは何か, そしてどのように動作するか

Copyright © 1996 &a.uhclem;, All Rights Reserved. 13 January 1996.

訳: &a.saeki;, &a.iwasaki;. 11 November 1996.

( ここからは &a.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 コネクタを 使っているので, このことは しばしば混乱を引き起こします.) 以下は DB25 および DB9 コネクタにおける RS-232C 信号の割り当て表です. DB25 DB9 EIA CCITT 一般 信号源 説明 RS-232C IBM PC 回路 回路 名称 端子 端子 符号 符号 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.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

訳注: 具体的なパッケージ形状についての情報は を参照 してください. 「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 MSD ユーティリティの 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 からの相違点の単純なカウントが, 何の相違点が重要であり どれがそうでないのかについて多くを明らかにしないことを理解すること が大切です. 例えば, 内蔵の UART を持つ上記の二つのモデムで報告され た相違点の約半分が, 5及び6ビットキャラクタモードをサポートしないク ローンの UART によって引き起こされました. 本物の 16550, 16450 そし て 8250 UART すべてはこれらのモードをサポートし, COMTEST はこれらの モードの機能性をチェックするので, 50を越える相違点が報告されました. しかし, 5及び6ビットキャラクタモードをサポートするモデムは殆どなく, 特ににこれらはエラー修正と圧縮機能付のものです. これは5及び6ビット キャラクタモードに関連した相違点は差し引いて考えることができること を意味しています. COMTEST が報告した相違点の多くは, タイミングに関する点でしょう. 多くのクローンの設計では, ホストが一つのポートから読み込んだ時に他 のあるポートのステータスビットは, 本当の NS16550AFN と同じ 長さの時間内で更新されない (あるものは速く, あるものは遅く) かもしれ ませんが, COMTEST はこれらの相違点を探します. これは相違点の数は誤 解を招き易いものです. あるデバイスには一つか二つの相違点しかありま せんがそれらは非常に重大かもしれません. また別のデバイスは基準部品 と比べて速くまたは遅く status レジスタを更新するために (適切に書か れたドライバの操作にはまったく影響しないかもしれません) 多くの相違点を 報告されるかもしれません. * この文書の著者は今まで, COMTEST プログラムを使用して相違点がゼロ と報告されるナショナル・セミコンダクタ以外の部品を一つも発見しませ んでした. ナショナル・セミコンダクタは長年に渡り 16550 の五つのバー ジョンを持っており, 最新の部品は機能性のために, ベンチマークを考慮 した古い NS16550AFN と少し異なる振る舞いをすることに注意するべきで す. COMTEST はナショナル・セミコンダクタの製品ラインの相違点につい ては見て見ぬふりをするようになり, 部品のリビジョン A, B そして C にあるバグが記述されている公式な正誤表がある時でも, (オリジナルの 16550 を除いては) ナショナル・セミコンダクタの部品についてエラーを 報告しなくなったので, この COMTEST のひいきを考慮にいれるべきです. 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 Transmit Holding Register (THR) (DLAB==0) このポートに書き込まれた情報はデータ命令として 処理され, UART により送信されます. +0x00 read Receive Buffer Register (RBR) (DLAB==0) シリアル接続から UART によって受信されたすべての データ命令は, このポートを読むことによってホス トによりアクセスされます. +0x00 write/read Divisor Latch LSB (DLL) (DLAB==1) マスタ入力クロックの周波数をこのレジスタに入っ ている値で割ることにより, UART の周波数が決定 されます (IBM PCでは, マスタクロックの周波数は 1.8432MHzです). このレジスタには上記の除数の下 位8ビットが入っています. +0x01 write/read Divisor Latch MSB (DLH) (DLAB==1) マスタ入力クロックの周波数をこのレジスタに入っ ている値で割ることにより, UART の周波数が決定 されます (IBM PCでは, マスタクロックの周波数は 1.8432MHzです). このレジスタには上記の除数の上 位8ビットが入っています. +0x01 write/read Interrupt Enable Register (IER) (DLAB==0) 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 (IIR) 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 を使用する必要はありません. これにより設計者は, より良い 性能特性を持つ部品が自由に利用できます. diff --git a/ja/handbook/userppp.sgml b/ja/handbook/userppp.sgml index f5c35b9ef9..edc8a14dda 100644 --- a/ja/handbook/userppp.sgml +++ b/ja/handbook/userppp.sgml @@ -1,391 +1,391 @@ - + ユーザ PPP のセットアップ

原作: &a.nik; 28 July 1995.

訳: &a.saeki; 11 November 1996.

ユーザ PPP は FreeBSD 2.0.5-RELEASE において, 既存のカーネル実装版の PPP に加えて導入されました. それでは, この新しい PPP が追加された理由となる ppp との違いは何でしょう ? マニュアルから引用すると: これはユーザプロセス PPP ソフトウェアパッケージです. 通常 PPP は (例えば pppd でそうなっているように) カーネルの一部として 実装されています. そのためデバッグや動作の変更が幾分困難です. しかしこの実装では, PPP はトンネルデバイスドライバ (tun) の 補助により, ユーザプロセスとして実装されています. これは本質として, 常に PPP デーモンを実行しておかないでも, 必要な時に ppp プログラムを実行できるということを意味します. このプログラムはカーネルとのデータ送受のために一般のトンネルデバイスを 使うことができるため, PPP インターフェースをカーネルに組み込んでおく 必要がありません. 以降では, ユーザ ppp と他の PPP クライアント / サーバソフトウェアとを 区別する必要がないので, ユーザ ppp を単に ppp とだけ呼びます. 特に断らない限り, このセクションのすべてのコマンドは root 権限で 実行されるべきです. このセクションでアスタリスクマーク (*) のついている部分は不完全です. コメントや提案は歓迎しますので, &a.nik; まで送ってください. 私が最初にユーザ ppp を実験していた時に, 価値ある情報の宝庫となってくれた Rob Snow <rsnow@txdirect.net> に感謝します. 訳者注: このユーザ ppp は iij-ppp0.94(beta2?) に由来しています. 作者の大野さんは日本の方ですので, iij-ppp には詳細な日本語 ドキュメントが附属しています. オリジナルアーカイブ (iij-ppp0.94beta2.tar.gz) を入手して, そちらを参照されることを 強くおすすめします. スタートの前に

このドキュメントでは, あなたが大体以下のような状況にあると仮定しています: PPP 接続の使えるインターネットサービスプロバイダ (ISP) のアカウントを 持っている. さらに, 接続済みのモデム (または他のデバイス) があり, プロバイダとの接続が可能なように正しく設定されている. 以下の情報を手に入れておく必要があるでしょう: プロバイダのゲートウェイの IP アドレス プロバイダのネットマスク設定 一つ以上のネームサーバの IP アドレス もしプロバイダが固定の IP アドレスとホスト名を割り当ててくれるなら, 同様にそれも必要でしょう. そうでなければ, どの IP アドレス範囲から 割り当てがおこなわれるかを知っておく必要があるでしょう. もしこれらの情報のうち不明なものがあれば, プロバイダに連絡して確認しておいてください. 同様に, カーネルを再コンパイルするためのファイルが必要になるかもしれません. これらを手に入れる方法の詳細については を参照してください. 加えて, インターネットへの接続は常時おこなわれているものではなく, そのためネームサーバ (named(8)) を立ち上げていないと仮定しています. ppp 対応カーネルの構築

説明でも述べているように, ``ppp'' はカーネルの ``tun'' デバイスを使います. そのため, このデバイスがカーネルに組み込まれていることの確認が不可欠です. これを確認するためには, カーネルコンパイルディレクトリ (おそらく /sys/i386/conf) に移動して, カーネルコンフィグレーション ファイルを調べます. 以下の行がどこかに含まれている必要があります. pseudo-device tun 1 元々の GENERIC カーネルは標準でこれを含んでいますので, カスタムカーネルを インストールしていなければ, 何も変更する必要はありません. あなたのカーネルコンフィグレーションファイルに この行が含まれていなければ, この行を追加して カーネルの再コンパイルとインストールをおこなう必要があります. この新しいカーネルを使ってブートしてください. カーネルコンフィグレーションの詳細については, を参照してください. tun デバイスのチェック

私は一つの ``tun'' デバイス (tun0) による ppp の経験しかありません. より多くのデバイスを使う場合 (すなわち, カーネルコンフィグレーション ファイルで疑似デバイスの行に `1' 以外の数値が指定されている場合), 以下のすべての ``tun0'' に対する参照を, あなたが使うデバイスの番号に あわせて変更してください. tun0 デバイスが正しく設定されていることを確認する最も簡単な方法は, それを作り直すことです. そのためには, 以下のコマンドを実行します: # cd /dev # ./MAKEDEV tun0 PPP の設定

これが問題の核心です. まぎらわしいことに, ユーザ ppp と pppd (カーネルレベルの PPP 実装) は ともに, 設定ファイルが /etc/ppp に置かれていると仮定しているようです. しかし, 提供されているサンプル設定ファイルはユーザ ppp 用のものですので, 参照のため手元に置いておきます. これをおこなう最も簡単な方法は, 以下の通りです: # cd /etc # mv ppp ppp.orig # mkdir ppp ppp を設定するためには, 必要に応じて一〜三つのファイルを 編集する必要があります. 書き込む内容はプロバイダが静的に IP アドレスを 割り当てる (すなわち, 一つの IP アドレスが与えられて, 常にそれを使う) か, または動的に IP アドレスを割り当てる (すなわち, PPP セッション毎に IP アドレスが異なる可能性がある) かにある程度依存します. しかし, 静的な IP アドレスを使うか動的な IP アドレスを使うかにかかわらず, 最初にやらなければならないことがいくつかあります. resolver(5) の設定

リゾルバ (resolver) はネットワーキングシステムの一部分で, IP アドレスと ホスト名の変換をおこないます. これは, IP アドレスとホスト名を対応づける マップを二つの場所のうちの一つから探すように設定できます. 一つめの場所は /etc/hosts (man 5 hosts) と呼ばれる ファイルです. 二つめの場所は, 分散データベースである, インターネットドメイン ネームサービスです. これに関する議論はこのドキュメントの範囲を 越えています. リゾルバはマッピングをおこなうシステムコールの集合です. どこからマッピング情報を得ればよいかはあなたが指示しなければなりません. これは /etc/host.conf ファイルを編集することでおこないます. 混乱する可能性があるので, このファイルを /etc/hosts.conf と 呼んでは いけません (余分な ``s'' に注意). このファイルは以下の 2 行を含んでいるはずです. hosts bind これは, 最初に /etc/hosts ファイルを調べ, 目的の名前が見つからなければ DNS を引きにいくようリゾルバに指示します. このマシンで ``named'' サービスが走っていないことを確認しておいた方が 良いでしょう. /etc/sysconfig ファイルをチェックして ``namedflags'' の行を探し, 以下のようになっていることを確認します. namedflags="NO" /etc/hosts(5) ファイルの作成

このファイルはローカルネットワーク上に存在するマシンの IP アドレスと ホスト名を含んでいるはずです. 最低でも ppp を動作させるマシンのエントリを 含んでいなければなりません. あなたのマシンのホスト名が foo.bar.com で, IP アドレスが 10.0.0.1 であると仮定すると, /etc/hosts は 以下の行を含んでいなければなりません: 127.0.0.1 localhost 10.0.0.1 foo.bar.com foo 最初の行は別名 ``localhost'' を現在のマシンの同義語として定義しています. 固有の IP アドレスによらず, この行の IP アドレスは常に 127.0.0.1 で なければなりません. 二つめの行はホスト名 ``foo.bar.com'' (そして別名 ``foo'') を IP アドレス 10.0.0.1 にマップします. もしプロバイダが固定の IP アドレスを割り当ててくれるなら, それを 10.0.0.1 のかわりに使ってください. /etc/resolv.conf ファイルの作成

/etc/resolv.conf はネームサーバをそのマシンで走らせていない場合に 必要となる特別な情報を含んでいます. これは実際のネームサーバの位置を リゾルバルーチンに指示したり, その他いくつかの情報を指定したりします. 少なくとも /etc/resolv.conf は問い合わせ可能なネームサーバを 示す 1 行を含んでいる必要があります. これは (ホスト名ではなく) IP アドレスで書かれていなければなりません. 私の /etc/resolv.conf は以下の行を含んでいます: nameserver 158.152.1.193 nameserver 158.152.1.65 これはプロバイダ Demon Internet の二つのネームサーバです. あなたのプロバイダのネームサーバ行をすべて書いてください. PPP と静的 IP アドレス

これはおそらく設定が最も楽でしょう. 必要なのは /etc/ppp ディレクトリにファイルを三つ作成することだけです. 一つめのファイルは ppp.conf です. 以下の例と似たような ものになるでしょう. ``:'' で終る行は 1 カラム目から始まり, その他の行は この例の通りにインデントされるべきだということに注意してください. /etc/ppp/ppp.conf 1 default: 2 set device /dev/cuaa0 3 set speed 9600 4 disable lqr 5 deny lqr 6 set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" ATE1Q0 OK-AT-OK \\dATDT\\T TIMEOUT 40 CONNECT" 7 provider: 8 set phone 01234567890 9 set login "TIMEOUT 10 gin:-BREAK-gin: foo word: bar col: ppp" 10 set timeout 120 11 set ifaddr x.x.x.x y.y.y.y 行番号はファイルには含めないでください. これは説明のためのものです. /dev/cuaa0 で, COM2: は /dev/cuaa1 です. chat(8) 言語を 使用します. この言語の仕様についての情報はマニュアルを 参照してください. J. Random Provider login: foo password: bar protocol: ppp このスクリプトを必要に応じて書き換える必要があるでしょう. これは chat(8) 言語で書かれています. 次に /etc/ppp/ppp.linkup ファイルを編集しなければなりません: x.x.x.x: add 0 0 HISADDR 先ほどと同じように x.x.x.x をあなたの IP アドレスで置き換えます. このファイルは, あなたのマシンからプロバイダ (HISADDR マクロは プロバイダのアドレスで自動的に置き換えられます) へのルートを デフォルトルートとして自動的に追加するのに使われます. 最後に, /etc/ppp/ppp.secret ファイルを作成します. 同じ ppp システムを使う他のユーザの不正使用を防ぐためパスワードを 設定します. どれだけの人がこの ppp システムを触るかによって, これを設定したいと思うかもしれません. PPP と動的 IP 設定

プロバイダから静的な IP アドレスの割り当てを受けていない場合, ローカル IP アドレスとして 0 を指定することで ppp が リモートホストとの交渉によりローカルアドレスを決定するように設定できます. set ifaddr 0 0 詳細については ppp(8) のマニュアルを参照してください. システムの最終設定

これで PPP の設定は終りました. しかし PPP の動作準備が完了するのには もう少し必要なことがあります. それはすべて /etc/sysconfig ファイルの編集に含まれています. このファイルを上から順に設定していきます. まず ``hostname='' の行が 設定されていることを確認します. 例えば, hostname=foo.bar.com 次に network_interfaces 変数を探し, tun0 デバイスがリストに追加されて いることを確認します. 私の設定では以下のようになっています. network_interfaces="lo0 tun0 ep0" 他に私はイーサネットカード (ep0) も持っているので, 同様に設定しています. 次に tun0 デバイスのための ifconfig 行を追加します. それは以下のようなものになるでしょう. ifconfig_tun0="inet foo.bar.com y.y.y.y netmask 0xffffffff" 先ほどと同じように, ``foo.bar.com'' はあなたのホスト名に, y.y.y.y はプロバイダのゲートウェイの IP アドレスに, 0xffffffff は (16 進で) プロバイダから指定されたネットマスクに変更します. ネットマスクとしては以下の二つの値がよく用いられます. 255.255.255.255 = 0xffffffff 255.255.255.0 = 0xffffff00 routed フラグを以下のように ``-s'' に設定します. routedflags=-s ``sendmail_flags'' 行が ``-q'' オプションを含まないようにしておくことは, おそらく, やっておくだけの価値があるでしょう. さもなければ, ネットワークからアドレスを引こうとして sendmail が 時々発信をおこなってしまうでしょう. 私の sendmail 行は次の通りです. sendmail_flags="-bd" この結果, 私は PPP リンクを立ち上げた時はいつでも以下のようにタイプして, sendmail に mailqueue を調べ直させなければなりません. # /usr/sbin/sendmail -q これが静的 IP アドレスで PPP を動作させるために必要なすべてのはずです. 後はマシンをリブートするだけです. スタートアップの間に tun0 デバイスが 検出され, 以下のような 2 行が表示されると思います. tun0: flags=51 mtu 1500 inet x.x.x.x --> y.y.y.y netmask 0xffffffff この時点で, ppp は完全に動作するはずです. 以下のうち好きなほうを タイプしてください. # ppp その後 PPP セッションを開始させるために ``dial provider'' をタイプします. または, 外向きのトラフィックが発生した時に ppp が自動的にセッションを 確立してくれるようにしたければ, 以下をタイプします. # ppp -auto provider この行を /etc/rc.local ファイルに追加しておくのも良いでしょう. diff --git a/ja_JP.EUC/handbook/authors.sgml b/ja_JP.EUC/handbook/authors.sgml index e5f2e90e6b..f62b8ffc18 100644 --- a/ja_JP.EUC/handbook/authors.sgml +++ b/ja_JP.EUC/handbook/authors.sgml @@ -1,421 +1,421 @@ - + "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> "> diff --git a/ja_JP.EUC/handbook/basics.sgml b/ja_JP.EUC/handbook/basics.sgml index 09eb64cb21..878cea4ff3 100644 --- a/ja_JP.EUC/handbook/basics.sgml +++ b/ja_JP.EUC/handbook/basics.sgml @@ -1,93 +1,93 @@ - + Unix の基礎知識

訳: &a.nakai;12 October 1996. オンラインマニュアル

FreeBSD についてのもっとも包括的なドキュメントは マニュアルページの形式になっているものです. FreeBSD システム上のほとんどすべてのプログラムには基本的な 操作方法とさまざまな引数を説明しているリファレンスマニュアル がついています。これらのマニュアルは man コマンドで見ることができます。 man コマンドの使い方は簡単です : man コマンド名 コマンド名のところには知りたいコマンドの名前を入れます。 たとえば、ls コマンドについて知りたい場合には 次のように入力します : % man ls

オンラインマニュアルは数字のついたセクションに分けられています : ユーザコマンド システムコールとエラー番号 C のライブラリ関数 デバイスドライバ ファイル形式 ゲームとほかのお楽しみ そのほかの情報 システムの管理と操作のためのコマンド 場合によっては, 同じことがらでもオンラインマニュアルでは 複数のセクションに記載されていることがあります。たとえば、 chmod ユーザコマンドと chmod() システムコールがあります。この場合、man コマンドでどちらを参照したいかをセクションで指定することが できます : % man 1 chmod とすればユーザコマンドとしての chmod のマニュアルページが表示されます。オンラインマニュアル上の特定の セクションへの参照は通常、書かれているドキュメントの 括弧の中に示されています。ですから、chmod(1) は chmod ユーザコマンドを、 chmod(2) はシステムコールの方を示しています。

コマンドの名前を知っていて, 単純にその使い方が分かる場合は よいのですが、もしコマンドの名前を思い出せない場合には どうしたらいいのでしょう? man に -k スイッチをつければ, コマンドデスクリプション中のキーワードから検索することができます : % man -k mail このコマンドを使うことで, 「mail」というキーワードを含むコマンドの 一覧を参照することができます。実を言うと apropos コマンドを使うのと機能的には同じです。

それから、/usr/bin にある優れたコマンドすべてを目にしても、 それらの大半がどういった働きをするのかまったく見当もつかないときは どうしたらよいでしょう。単純に、 % cd /usr/bin; man -f * あるいは同じ働きをする % cd /usr/bin; whatis * としましょう。 GNU の Info ファイル

FreeBSD には Free Software Foundation (FSF) によるアプリケーションや ユーティリティがたくさんあります。こうしたプログラムには manページに加えて、info ファイルと呼ばれる ハイパーテキスト形式のドキュメントが付属になっていて、info コマンドや、emacs をインストールしているなら emacs の info モードで見ることができます。 info(1) コマンドを使うには, 単にこう入力します。 % info おおまかなイントロダクションを 見るには、h と入力します。 クイックコマンドリファレンスは ? とします。 diff --git a/ja_JP.EUC/handbook/bibliography.sgml b/ja_JP.EUC/handbook/bibliography.sgml index c6269ebe0a..8b49f0e7a3 100644 --- a/ja_JP.EUC/handbook/bibliography.sgml +++ b/ja_JP.EUC/handbook/bibliography.sgml @@ -1,265 +1,265 @@ - + 参考図書

訳: &a.nakai;12 October 1996.

FreeBSD オペレーティングシステムの個々の部分については マニュアルページで定義のような説明がなされていますが, それらにはどうやってその部分どうしをつなぎあわせて オペレーティングシステム全体を円滑に動作させるかを 説明していないという欠点がよく指摘されます. それを補うためには UNIX システム管理についてのよい本や, すぐれた利用者向けのマニュアルが欠かせません. 利用者向けのガイド

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 has written a which is available online in HTML and postscript format. 管理者向けのガイド

Albitz, Paul and Liu, Cricket. DNS and BIND. O'Reilly & Associates, Inc., 1993. ISBN 1-56592-010-4 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. O'Reilly & Associates, Inc., 1993. ISBN 1-56592-056-2 Frisch, Æleen. Essential System Administration. O'Reilly & Associates, Inc., 1993. ISBN 0-937175-80-3 Hunt, Craig. TCP/IP Network Administration. O'Reilly & Associates, Inc., 1992. ISBN 0-937175-82-X Nemeth, Evi. UNIX System Administration Handbook. 2nd ed. Prentice Hall, 1995. ISBN 0131510517 プログラマ向けのガイド

Asente, Paul. X Window System Toolkit. Digital Press. ISBN 1-55558-051-3 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 Ellis, Margaret A. and Stroustrup, Bjarne. The Annotated C++ Reference Manual. Addison-Wesley, 1990. ISBN 0-201-51459-1 Harbison, Samuel P. and Steele, Guy L. Jr. C: A Reference Manual. 4rd ed. Prentice Hall, 1995. ISBN 0-13-326224-3 Kernighan, Brian and Dennis M. Ritchie. The C Programming Language.. PTR Prentice Hall, 1988. ISBN 0-13-110362-9 Plauger, P. J. The Standard C Library. Prentice Hall, 1992. ISBN 0-13-131509-9 Stevens, W. Richard. Advanced Programming in the UNIX Environment. Reading, Mass. : Addison-Wesley, 1992 ISBN 0-201-56317-7 Stevens, W. Richard. UNIX Network Programming. PTR Prentice Hall, 1990. ISBN 0-13-949876-1 Wells, Bill. "Writing Serial Drivers for UNIX". Dr. Dobb's Journal. 19(15), December 1994. pp68-71, 97-99. オペレーティングシステム内部

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 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 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 Stevens, W. Richard. TCP/IP Illustrated, Volume 1: The Protocols. Reading, Mass. : Addison-Wesley, 1996. ISBN 0-201-63346-9 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 Wright, Gary R. and W. Richard Stevens. TCP/IP Illustrated, Volume 2: The Implementation. Reading, Mass. : Addison-Wesley, 1995. ISBN 0-201-63354-X セキュリティの参考資料

Cheswick, William R. and Steven M. Bellovin. Firewalls and Internal Security: Repelling the Wily Hacker. Reading, Mass. : Addison-Wesley, 1995. ISBN 1-201-63357-4 Garfinkel, Simson and Gene Spafford. Practical UNIX Security. 2nd Ed. O'Reilly & Associates, Inc., 1996. ISBN 1-56592-148-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 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. 3rd ed. Reading, Mass. : Addison-Wesley, 1995. ISBN 0-201-40993-3 Van Gilluwe, Frank. The Undocumented PC. Reading, Mass: Addison-Wesley Pub. Co., 1994. ISBN 0-201-62277-7 UNIX の歴史

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 雑誌とジャーナル

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 diff --git a/ja_JP.EUC/handbook/boothelp.sgml b/ja_JP.EUC/handbook/boothelp.sgml index 4f0a349065..3b445ef7a0 100644 --- a/ja_JP.EUC/handbook/boothelp.sgml +++ b/ja_JP.EUC/handbook/boothelp.sgml @@ -1,51 +1,51 @@ - + %authors; %sections; ]> FreeBSD のインストール <author> <name></name> </author> <abstract>FreeBSD の世界へようこそ! このガイドは FreeBSD の インストール方法について説明しています. 矢印キーの<bf>上</bf>と<bf>下</bf>を使って このガイドの読みたいセクションに移動し, <bf>右矢印キー</bf>か<bf>リターンキー</bf>を使ってお読みください. 一度読んだことのあるセクションは<bf>左矢印キー</bf>で 戻って読みなおすことができます. </abstract> <chapt><heading>一般的な情報</heading> &nutshell; &history; &relnotes; &install; &troubleshooting; &bibliography; &eresources; &hw; &contrib; </book> </linuxdoc> diff --git a/ja_JP.EUC/handbook/booting.sgml b/ja_JP.EUC/handbook/booting.sgml index ffaf2c8f85..f90c576a9e 100644 --- a/ja_JP.EUC/handbook/booting.sgml +++ b/ja_JP.EUC/handbook/booting.sgml @@ -1,183 +1,183 @@ <!-- $FreeBSD$ --> <!-- The FreeBSD Japanese Documentation Project --> -<!-- Original revision: 1.11 --> +<!-- Original revision: 1.12 --> <!-- This is a SGML version of the text on FreeBSD boot procedures made by Poul-Henning Kamp <phk@FreeBSD.ORG> This conversion has been made by Ollivier Robert. <!DOCTYPE linuxdoc PUBLIC "-//FreeBSD//DTD linuxdoc//EN"> <article> <title>ブートの概要 Poul-Henning Kamp, v1.1, April 26th FreeBSDのブートには基本的に3つの段階があります: カーネルの読み込み、ルートのファイルシステムの決定、そして ユーザ領域にあるものの初期化です。このことは下に述べる いくつかの興味深い可能性につながっているのです... --> FreeBSDのブート処理の流れ

原作: &a.phk;. v1.1, April 26th.

訳: &a.nakai; September 6 1996. FreeBSDのブートには基本的に3つの段階があります: カーネルの読み込み, ルートのファイルシステムの決定, そして ユーザ領域にあるものの初期化です. このことは下に述べる いくつかの興味深い可能性につながっています。 カーネルの読み込み

現在, カーネルの読み込みには基本的に下に挙げる3つの方法が あります: これらはカーネルが次に何をしたらいいのかという情報をカーネルに 与えます. Biosboot Biosbootは「ブートブロック」に相当するもので, 2つのファイル から構成されており, フロッピーディスクやハードディスクのブートを 開始する側の 8K バイトにインストールされています。 Biosboot は FreeBSD のファイルシステムからカーネルを 読み込むことができます. Dosboot Dosbootは DI. Christian Gusenbauerによって書かれましたが, 不幸にしてこの場合には、コードのある一部分がマイクロソフトの コンパイラ向けに書かれているため、FreeBSD 単体ではコンパイル することはできません. Dosboot は MS-DOS のファイルから、またはディスクの FreeBSD ファイルシステムのパーティションからカーネルをブートします。 これは MS-DOS システムのハイメモリ領域に潜んでいるメモリマネージャ等の さまざまな怪しい代物とメモリの取り合いをして、なんとかブートしています. Netboot Netboot はサポートされているイーサネットカードを検出し、 BOOTP や TFTP、NFS を使ってブートするカーネルを探そうとします。 ルートファイルシステムの決定

カーネルが読み込まれ、ブートプログラムがカーネルに移行したら, カーネルは自身の初期化をし, どんなハードウェアが組み込まれいるか を決定し、それからルートファイルシステムを探さなくてはなりません。 現在サポートされているルートファイルシステムは次の通りです : UFS UFS は, もっとも一般的なタイプのルートシステムです。 フロッピーディスクやハードディスク上に存在します。 MSDOS 技術的に可能ですが、あまり有用ではありません。なぜならば、 ``FAT''ファイルシステムではリンクやデバイスノードなどの ``UNIX 主義''を実現できないからです。 MFS MFS はカーネル内部に組み込みになっている UFS ファイルシステムです。つまり MFS を機能させるのに ディスクやフロッピーディスクなどのハードウェアは 必要ではありません. CD9660 CD9660 は CD-ROM をルートファイルシステムに使用したものです。 NFS これはルートシステムにファイルサーバを使用していて、基本的に ディスクレスのマシンのためにあります。 ユーザ領域にあるものの初期化

ユーザ領域で動作させるようにするために、カーネルが初期化を終えると、 カーネルは``/sbin/init'' です。 /sbin/init を別なプログラム置き換えてしまうことは可能ですが、そのプロセス には以下のような制約があります: pid が 1 のプロセスには stdin/stdout/stderr は割り当てられていませんので、 プログラムは自分でこれらをオープンしないとなりません。 このプロセスが終了するとカーネルはパニックメッセージを表示して 停止します。 また、このプロセスに対するシグナル処理は特殊です。 この例として、インストール用のフロッピーディスクにある ``/stand/sysinstall''があります。 興味深い連係

カーネルを MFS でブートするのには次のような特別の/sbin/init を使います。 /C: にマウントします。 C:/freebsd.fs を /dev/vn0 にアタッチします。 /dev/vn0 を /rootfs にマウントします。 シンボリックリンクを作ります。 /rootfs/bin -> /bin /rootfs/etc -> /etc /rootfs/sbin -> /sbin (etc...) これでハードディスクのパーティションを切り直さずに FreeBSD を 使うことができます。 サーバ:˜you/FreeBSD を /nfsにマウントし、ルートディレクトリを /nfs に変更して, そこで/sbin/initを実行します。 これで FreeBSD をディスクレスで実行できますが、NFS サーバを コントロールできないままです... /dev/rwd0 のコピーを取って、リモートにあるテープ ステーションやファイルサーバに書き込んでください。 これで一年前に取っておくべきだったバックアップをやっと 取ることができました。 E -- ファイアウォール/Web サーバとして動作させる場合 (私の知っている範囲で...) これは特に面白いもので、書き込み禁止のフロッピーディスクから ブートができて、ルートのファイルシステムに書き込むことができる というものです。 diff --git a/ja_JP.EUC/handbook/contrib.sgml b/ja_JP.EUC/handbook/contrib.sgml index 6aa169d7b1..e4ebb35db4 100644 --- a/ja_JP.EUC/handbook/contrib.sgml +++ b/ja_JP.EUC/handbook/contrib.sgml @@ -1,481 +1,481 @@ - + FreeBSD へのコントリビュータ

原作: 不明

訳: &a.hanai;28 August 1996. BSD派生ソフトウェアへのコントリビュータ

このソフトウェアは最初は William F. Jolitz の 386BSD release 0.1 から派生しましたが, オリジナルの 386BSD に固有のコードはほとんど 残っていません. このソフトウェアは基本的にはカリフォルニア大学 バークレイ校の Computer Science Research Group (CSRG) とその共同研究者 たちによる 4.4BSD-Lite リリースから再実装されました. また, NetBSD の一部も FreeBSD に取り込まれています. したがって私たちは NetBSD へ貢献した人々すべてに感謝します.二つのグループの関係が ギクシャクすることも時にはありますが, 私たちは基本的には共に同じ目的 を持っています. すなわち, 人々のコンピュータにもっと BSD をベースに したオペレーティングシステムを! ということです. 私たちは NetBSD の努力が常に成功してほしいと思っています. ハードウェアのコントリビュータ

特に Walnut Creek CDROM にはネットワークへのアクセス及び他のハードウェア リソースの寄贈はいうまでもなく, 開発に使うための Pentium P5-90 と 486/DX2-66 EISA/VL システムを提供してくれたことについて感謝しています. 彼らのサポートがなければこのリリースをおこなうことは不可能であったで しょう. TRW Financial Sysytems社は, PC 130台,三つの 68 GB のファイルサーバ 12のイーサネット, ディスクレスコードのデバッグをおこなうための 二つのルータ及び ATM スイッチを提供してくれました. また, かれらは 2, 3人の FreeBSD ハッカーを雇って, FreeBSD に専念させて くれています. ありがとう! また, 東芝 XM3401B CDROM ドライブ を寄付してくれた Dermot McDonnell に感謝します. その CDROM ドライブはもっとも役に立ちました. 実験的な仕事としてフロッピーテープストリーマを寄付してくれた &a.chuck; に感謝します. wtドライバを改良するために Wangtek と Archive の QIC-02 テープドライブを提供してくれた Larry Altneu <larry@ALR.COM> と &a.wilko; に感謝します. このプロジェクトへ 2.88 MB のフロッピードライブを提供してくれた Ernst Winter <ewinter@lobo.muc.de> に感謝します. うまくいけば, これでフロッピーディスクドライバを書き直すための プレッシャーが増えるでしょう. ;-) また, FreeBSDプロジェクトへ資金やサービスを提供してくれた人々の リストは をご覧ください. FreeBSD コアチーム

(姓でアルファベット順): &a.asami &a.ache &a.dyson &a.bde &a.gibbs &a.davidg &a.jkh &a.phk &a.rich &a.gpalmer &a.sos &a.peter &a.wollman &a.joerg FreeBSD の開発者たち

(CVSの)commitする権利を持っていて, FreeBSD のソースツリーについて 作業をおこなっている人々がいます. すべてのコアチームのメンバはまた 開発者でもあります. &a.mbarkah; &a.torstenb; &a.gclarkii; &a.adam; &a.dufault; &a.uhclem; &a.sef; &a.julian; &a.se; &a.fenner; &a.jfieber; &a.jfitz; &a.lars; &a.scrappy; &a.tg; &a.graichen; &a.rgrimes; &a.jhay; &a.hsu; &a.ugen; &a.gj; &a.nsj; &a.ljo; &a.kato; &a.andreas; &a.erich; &a.imp; &a.smace; &a.mckay; &a.amurai; &a.markm; &a.max; &a.alex; &a.davidn; &a.obrien; &a.fsmp; &a.smpatel; &a.wpaul; &a.jmacd; &a.jdp; &a.steve; &a.mpp; &a.dfr; &a.jraynard; &a.csgr; &a.martin; &a.paul; &a.roberto; &a.chuckr; &a.dima; &a.wosch; &a.ats; &a.msmith; &a.karl; &a.pst; &a.guido; &a.swallace; &a.nate; &a.jmz; 担当者

FreeBSD ドキュメンテーションプロジェクト

FreeBSD ドキュメンテーションプロジェクトは複数のサービスを提供 しています. それぞれのサービスの担当者は以下のとおりです.

その他の FreeBSD へのコントリビュータ

(名前でアルファベット順に): A JOSEPH KOSHY <koshy@india.hp.com> ABURAYA Ryushirou <pcs51674@asciinet.or.jp> Adam Glass <glass@postgres.berkeley.edu> Adrian T. Filipi-Martin <atf3r@agate.cs.virginia.edu> Akito Fujita <fujita@zoo.ncl.omron.co.jp> Alain Kalker <A.C.P.M.Kalker@student.utwente.nl> Alan Cox <alc@cs.rice.edu> Andreas Kohout <shanee@rabbit.augusta.de> Andreas Lohr <andreas@marvin.RoBIN.de> Andrew Gordon <andrew.gordon@net-tel.co.uk> Andrew Herbert <andrew@werple.apana.org.au> Andrew McRae <amcrae@cisco.com> Andrew Moore <alm@FreeBSD.org> Andrew Stevenson <andrew@ugh.net.au> Andrew V. Stesin <stesin@elvisti.kiev.ua> Andrey Zakhvatov <andy@cgu.chel.su> Andy Whitcroft <andy@sarc.city.ac.uk> Anthony Yee-Hang Chan <yeehang@netcom.com> Bernd Rosauer <br@schiele-ct.de> Bill Kish <kish@osf.org> &a.wlloyd Bob Wilcox <bob@obiwan.uucp> Boyd Faulkner <faulkner@mpd.tandem.com> Brent J. Nordquist <nordquist@platinum.com> Brian Clapper <bmc@willscreek.com> Brian Tao <taob@risc.org> Charles Hannum <mycroft@ai.mit.edu> Charles Mott <cmott@srv.net> Chet Ramey <chet@odin.INS.CWRU.Edu> Chris G. Demetriou <cgd@postgres.berkeley.edu> Chris Stenton <jacs@gnome.co.uk> Chris Timmons <skynyrd@opus.cts.cwu.edu> Chris Torek <torek@ee.lbl.gov> Christian Gusenbauer <cg@fimp01.fim.uni-linz.ac.at> Christian Haury <Christian.Haury@sagem.fr> Christoph Robitschko <chmr@edvz.tu-graz.ac.at> Chuck Hein <chein@cisco.com> Conrad Sabatier <conrads@neosoft.com> Cornelis van der Laan <nils@guru.ims.uni-stuttgart.de> Craig Struble <cstruble@vt.edu> Cristian Ferretti <cfs@riemann.mat.puc.cl> Curt Mayer <curt@toad.com> Daniel Baker <dbaker@crash.ops.neosoft.com> Daniel M. Eischen <deischen@iworks.InterWorks.org> Danny J. Zerkel <dzerkel@feephi.phofarm.com> Dave Bodenstab <imdave@synet.net> Dave Burgess <burgess@hrd769.brooks.af.mil> Dave Chapeskie <dchapes@zeus.leitch.com> Dave Edmondson <davided@sco.com> Dave Rivers <rivers@ponds.uucp> David Dawes <dawes@physics.su.OZ.AU> David Leonard <d@scry.dstc.edu.au> Dean Huxley <dean@fsa.ca> Dirk Froemberg <dirk@hal.in-berlin.de> Dmitry Kohmanyuk <dk@farm.org> &a.whiteside; Don Yuniskis <dgy@rtd.com> Donald Burr <d_burr@ix.netcom.com> Doug Ambrisko <ambrisko@ambrisko.roble.com> Eric Blood <eblood@cs.unr.edu> Frank Bartels <knarf@camelot.de> Frank Maclachlan <fpm@crash.cts.com> Frank Nobis <fn@trinity.radio-do.de> FURUSAWA Kazuhisa <furusawa@com.cs.osakafu-u.ac.jp> Gary A. Browning <gab10@griffcd.amdahl.com> Gene Stark <stark@cs.sunysb.edu> Greg Ungerer <gerg@stallion.oz.au> Harlan Stenn <Harlan.Stenn@pfcs.com> Havard Eidnes <Havard.Eidnes@runit.sintef.no> Hideaki Ohmon <ohmon@tom.sfc.keio.ac.jp> Hidekazu Kuroki <hidekazu@cs.titech.ac.jp> Hidetoshi Shimokawa <simokawa@sat.t.u-tokyo.ac.jp> Holger Veit <Holger.Veit@gmd.de> Igor Vinokurov <igor@zynaps.ru> Ikuo Nakagawa <ikuo@isl.intec.co.jp> IMAMURA Tomoaki <tomoak-i@is.aist-nara.ac.jp> Ishii Masahiro <?> J.T. Conklin <jtc@cygnus.com> James Clark <jjc@jclark.com> James da Silva <jds@cs.umd.edu> et al Janusz Kokot <janek@gaja.ipan.lublin.pl> Jason Thorpe <thorpej@nas.nasa.gov> Javier Martin Rueda <jmrueda@diatel.upm.es> Jian-Da Li <jdli@csie.NCTU.edu.tw> Jim Lowe <james@cs.uwm.edu> Jim Wilson <wilson@moria.cygnus.com> Johann Tonsing <jtonsing@mikom.csir.co.za> John Capo <jc@irbs.com> John Perry <perry@vishnu.alias.net> John-Mark Gurney <gurney_j@efn.org> Juergen Lock <nox@jelal.hb.north.de> Juha Inkari <inkari@cc.hut.fi> Julian Assange <proff@suburbia.net> Julian Jenkins <kaveman@magna.com.au> Julian Stacey <jhs@freebsd.org> Kazuhiko Kiriyama <kiri@kiri.toba-cmt.ac.jp> Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp> Keith Bostic <bostic@toe.CS.Berkeley.EDU> Keith Moore <?> Kirk McKusick <mckusick@mckusick.com> Koichi Sato <copan@ppp.fastnet.or.jp> Kostya Lukin <lukin@okbmei.msk.su> Kurt Olsen <kurto@tiny.mcs.usu.edu> Lars Koeller <Lars_Koeller@odie.physik2.uni-rostock.de> Lucas James <Lucas.James@ldjpc.apana.org.au> Luigi Rizzo <luigi@iet.unipi.it> Manu Iyengar <iyengar@grunthos.pscwa.psca.com> Marc Frajola <marc@dev.com> Marc Ramirez <mrami@mramirez.sy.yale.edu Marc van Kempen <wmbfmk@urc.tue.nl> Mark Huizer <xaa@stack.nl> Mark J. Taylor <mtaylor@cybernet.com> Mark Tinguely <tinguely@plains.nodak.edu> <tinguely@hookie.cs.ndsu.NoDak.edu> Martin Birgmeier Masachika ISHIZUKA <ishizuka@isis.min.ntt.jp> Mats Lofkvist <mal@algonet.se> Matt Bartley <mbartley@lear35.cytex.com> Matt Thomas <thomas@lkg.dec.com> Matt White <mwhite+@CMU.EDU> Matthew N. Dodd <winter@jurai.net> Matthew Stein <matt@bdd.net> Michael Butschky <butsch@computi.erols.com> Michael Elbel <me@FreeBSD.ORG> Michael Searle <searle@longacre.demon.co.uk> Miguel Angel Sagreras <msagre@cactus.fi.uba.ar> Mikael Hybsch <micke@dynas.se> Mikhail Teterin <mi@aldan.ziplink.net> Mike McGaughey <mmcg@cs.monash.edu.au> Mike Peck <mike@binghamton.edu> MITA Yoshio <mita@jp.FreeBSD.ORG> MOROHOSHI Akihiko <moro@race.u-tokyo.ac.jp> Naoki Hamada <nao@tom-yam.or.jp> NIIMI Satoshi <sa2c@and.or.jp> Nick Sayer <nsayer@quack.kfu.com> Nisha Talagala <nisha@cs.berkeley.edu> Nobuhiro Yasutomi <nobu@psrc.isac.co.jp> Nobuyuki Koganemaru <kogane@kces.koganemaru.co.jp> Noritaka Ishizumi <graphite@taurus.bekkoame.or.jp> Oliver Oberdorf <oly@world.std.com> Paul Fox <pgf@foxharp.boston.ma.us> Paul Kranenburg <pk@cs.few.eur.nl> Paul Mackerras <paulus@cs.anu.edu.au> Pedro Giffuni <pgiffuni@fps.biblos.unal.edu.co> Peter Stubbs <PETERS@staidan.qld.edu.au> Philippe Charnier <charnier@lirmm.fr> R. Kym Horsell <?> Randall Hopper <rhh@stealth.ct.picker.com> Richard Stallman <rms@gnu.ai.mit.edu> Richard Wiwatowski <rjwiwat@adelaide.on.neti> Rob Mallory <rmallory@csusb.edu> Rob Shady <rls@id.net> Rob Snow <rsnow@txdirect.net> Robert Sanders <rsanders@mindspring.com> Robert Withrow <witr@rwwa.com> Ronald Kuehn <kuehn@rz.tu-clausthal.de> Sander Vesik <sander@haldjas.folklore.ee> Sandro Sigala <ssigala@globalnet.it> Sascha Blank <blank@fox.uni-trier.de> Sascha Wildner <swildner@channelz.GUN.de> Scott Blachowicz <scott@sabami.seaslug.org> Serge V. Vakulenko <vak@zebub.msk.su> Simon Marlow <simonm@dcs.gla.ac.uk> Soren Dayton <csdayton@midway.uchicago.edu> Stefan Moeding <moeding@bn.DeTeMobil.de> Steve Gerakines <steve2@genesis.tiac.net> Suzuki Yoshiaki <zensyo@ann.tama.kawasaki.jp> Tadashi Kumano <kumano@strl.nhk.or.jp> Taguchi Takeshi <taguchi@tohoku.iij.ad.jp> Tatsumi Hosokawa <hosokawa@mt.cs.keio.ac.jp> Terry Lambert <terry@lambert.org> Terry Lee <terry@uivlsi.csl.uiuc.edu> Theo Deraadt <deraadt@fsa.ca> Thomas König <Thomas.Koenig@ciw.uni-karlsruhe.de> Tim Kientzle <kientzle@netcom.com> Tim Vanderhoek <ac199@freenet.hamilton.on.ca> Tom Samplonius <tom@misery.sdf.com> Torbjorn Granlund <tege@matematik.su.se> Tor Egge <tegge@itea.ntnu.no> Toshihiro Kanda <candy@fct.kgc.co.jp> Ville Eerola <ve@sci.fi> Werner Griessl <werner@btp1da.phy.uni-bayreuth.de> Wes Santee <wsantee@wsantee.oz.net> Wolfgang Stanglmeier <wolf@kintaro.cologne.de> Yoshiro Mihira <sanpei@yy.cs.keio.ac.jp> Yukihiro Nakai <nakai@mlab.t.u-tokyo.ac.jp> Yuval Yarom <yval@cs.huji.ac.il> Yves Fonk <yves@cpcoup5.tn.tudelft.nl> 386BSD パッチキットへのパッチ提供者

(名前でアルファベット順): Adam Glass <glass@postgres.berkeley.edu> Adrian Hall <adrian@ibmpcug.co.uk> Andrey A. Chernov <ache@astral.msk.su> Andrew Herbert <andrew@werple.apana.org.au> Andrew Moore <alm@netcom.com> Andy Valencia <ajv@csd.mot.com> <jtk@netcom.com> Arne Henrik Juul <arnej@Lise.Unit.NO> Bakul Shah <bvs@bitblocks.com> Barry Lustig <barry@ictv.com> Bob Wilcox <bob@obiwan.uucp> Branko Lankester Brett Lymn <blymn@mulga.awadi.com.AU> Charles Hannum <mycroft@ai.mit.edu> Chris G. Demetriou <cgd@postgres.berkeley.edu> Chris Torek <torek@ee.lbl.gov> Christoph Robitschko <chmr@edvz.tu-graz.ac.at> Daniel Poirot <poirot@aio.jsc.nasa.gov> Dave Burgess <burgess@hrd769.brooks.af.mil> Dave Rivers <rivers@ponds.uucp> David Dawes <dawes@physics.su.OZ.AU> David Greenman <davidg@Root.COM> Eric J. Haug <ejh@slustl.slu.edu> Felix Gaehtgens <felix@escape.vsse.in-berlin.de> Frank Maclachlan <fpm@crash.cts.com> Gary A. Browning <gab10@griffcd.amdahl.com> Geoff Rehmet <csgr@alpha.ru.ac.za> Goran Hammarback <goran@astro.uu.se> Guido van Rooij <guido@gvr.win.tue.nl> Guy Harris <guy@auspex.com> Havard Eidnes <Havard.Eidnes@runit.sintef.no> Herb Peyerl <hpeyerl@novatel.cuc.ab.ca Holger Veit <Holger.Veit@gmd.de> Ishii Masahiro, R. Kym Horsell J.T. Conklin <jtc@cygnus.com> Jagane D Sundar < jagane@netcom.com > James Clark <jjc@jclark.com> James Jegers <jimj@miller.cs.uwm.edu> James W. Dolter James da Silva <jds@cs.umd.edu> et al Jay Fenlason <hack@datacube.com> Jim Wilson <wilson@moria.cygnus.com> Jörg Lohse <lohse@tech7.informatik.uni-hamburg.de> Jörg Wunsch <joerg_wunsch@uriah.heep.sax.de> John Dyson - <formerly dyson@ref.tfs.com> John Polstra <jdp@polstra.com> John Woods <jfw@eddie.mit.edu> Jordan K. Hubbard <jkh@whisker.hubbard.ie> Julian Elischer <julian@dialix.oz.au> Julian Stacey <jhs@freebsd.org> Karl Lehenbauer <karl@NeoSoft.com> <karl@one.neosoft.com> Keith Bostic <bostic@toe.CS.Berkeley.EDU> Ken Hughes Kent Talarico <kent@shipwreck.tsoft.net> Kevin Lahey <kml%rokkaku.UUCP@mathcs.emory.edu> <kml@mosquito.cis.ufl.edu> Marc Frajola <marc@dev.com> Mark Tinguely <tinguely@plains.nodak.edu> <tinguely@hookie.cs.ndsu.NoDak.edu> Martin Renters <martin@tdc.on.ca> Michael Clay <mclay@weareb.org> Michael Galassi <nerd@percival.rain.com> Mike Durkin <mdurkin@tsoft.sf-bay.org> Naoki Hamada <nao@tom-yam.or.jp> Nate Williams <nate@bsd.coe.montana.edu> Nick Handel <nhandel@NeoSoft.com> <nick@madhouse.neosoft.com> Pace Willisson <pace@blitz.com> Paul Kranenburg <pk@cs.few.eur.nl> Paul Mackerras <paulus@cs.anu.edu.au> Paul Popelka <paulp@uts.amdahl.com> Peter da Silva <peter@NeoSoft.com> Phil Sutherland <philsuth@mycroft.dialix.oz.au> Poul-Henning Kamp<phk@FreeBSD.ORG> Ralf Friedl <friedl@informatik.uni-kl.de> Rick Macklem <root@snowhite.cis.uoguelph.ca> Robert D. Thrush <rd@phoenix.aii.com> Rodney W. Grimes <rgrimes@cdrom.com> Rog Egge <?> Sascha Wildner <swildner@channelz.GUN.de> Scott Burris <scott@pita.cns.ucla.edu> Scott Reynolds <scott@clmqt.marquette.mi.us> Sean Eric Fagan <sef@kithrup.com> Simon J Gerraty <sjg@melb.bull.oz.au> <sjg@zen.void.oz.au> Stephen McKay <syssgm@devetir.qld.gov.au> Terry Lambert <terry@icarus.weber.edu> Terry Lee <terry@uivlsi.csl.uiuc.edu> Warren Toomey <wkt@csadfa.cs.adfa.oz.au> Wiljo Heinen <wiljo@freeside.ki.open.de> William Jolitz <withheld> Wolfgang Solfrank <ws@tools.de> Wolfgang Stanglmeier <wolf@dentaro.GUN.de> Yuval Yarom <yval@cs.huji.ac.il> diff --git a/ja_JP.EUC/handbook/crypt.sgml b/ja_JP.EUC/handbook/crypt.sgml index 63ab152c40..2af144a834 100644 --- a/ja_JP.EUC/handbook/crypt.sgml +++ b/ja_JP.EUC/handbook/crypt.sgml @@ -1,81 +1,81 @@ - + DES, MD5, と Crypt

原作: &a.wollman;24 September 1995.

訳: &a.hanai;12 September 1996.

歴史

UN*X システムにおいてパスワードを保護し, 簡単に覗かれるのを防 ぐために, 従来パスワードはある方法によりスクランブルされてきました. ベル研の Unix 第7版に始まって以来, パスワードはセキュリティの専門家がい うところの「一方向ハッシュ関数」というものを用いることにより暗号化されるようになりました. つまり, 可能な限りのパスワード空間を検索するという強引な 方法以外にそのオリジナルを得ることができない, といった方法でパスワードは変換 されるのです. 不幸なことに, その当時 AT&T の研究者たちが手に入れることができ た唯一の暗号化方法は DES(Data Encryption Standard) に基づいたものでし た. これは営利企業にとっては大して問題ではありませんが, FreeBSDのよ うにすべてのソースコードが自由に手に入るオペレーティングシステムにとっ ては重大な問題となります. なぜなら, 多くの政府は DES やその他の暗号化ソフ トウェアが国境を越えることに制限をつけようとしているからです.

ここで, FreeBSD チームは一つのジレンマに直面しました. つまり, どうす れば法に触れることなく国外にあるそれらの UNIX システムのすべてに互換性を持 たせることができるか, ということです. 私たちは ``dual track approach'' を 取ることに決めました. 規制されていないパスワードスクランブラのみを含む 配布用物件を作り, DES に基づいたパスワードハッシュを付加ライブラリ として分けて供給するのです. パスワードをスクランブルさせる関数は, C ライブラリから `libcrypt' と呼ばれる(それを実行する C 関数が `crypt' と いう名前だからです)別のライブラリへ移されました. FreeBSD 1.x 及び 2.0 のリリース前のスナップショットでは, その規制されていないスクランブラは Nate Williams によって書かれた安全でない関数を使っていますが, 次の リリースでは RSA Data Security 社の一方向ハッシュ関数の MD5 を使う方法 に置き換えられました. これらの関数はどれも暗号化を含んでいないため, 合衆国から持ち出し, 他の多くの国へ持ち込めるものであるとされています.

一方, DES に基づいたパスワードハッシュ関数に関する作業もまた進行中 でした, まず, 合衆国及び他の国で書かれたコードの同期をとりながら, 合衆国の外で書かれた `crypt' のあるバージョンが持ち込まれました. そしてライブラリは修正され, 二つにわけられました. すなわち DES `libcrypt' は一方向パスワードハッシュをおこなうのに必要なコード のみを含み, それとは別の `libcipher' は実際に暗号化をおこなう ためのエントリポイントとして生成されました. コンパイルされたライブラリに対 して国外に持ち出す許可を得るのを簡単にするために, コードはこのように分け られたのです.

`crypt' メカニズムを理解する

あるパスワード文字列を作るのに, DES に基づいたハッシュ関数を使っ たのか, MD5に基づいたハッシュ関数を使ったのかは非常に簡単にわかります. MD5 を使ったパスワード文字列は必ず `$1$' という文字 で始まります. DESを使ったパスワード文字列はどんな特定の文字も持っていま せんが, MD5を使ったパスワードよりも短く, `$' という文字 を持たない64文字のアルファベットで構成されています. したがって, ドル記号で 始まっていない比較的短い文字列は DES を使ったパスワードである可能性が非常 に高いです.

あなたのシステムで, どちらのライブラリが使われているかを決めるの は, スタティックにリンクされている `init' のようなもの(その ようなプログラムに対する唯一の方法はわかっているパスワードを試してみ て動くかどうかを確認することです.)を除いたほとんどのプログラムについ ては非常に簡単なことです. `crypt' を使うようなプログラムは `libcrypt' にリンクされています. そしてそれぞれのライブラリに 対する `libcrypt' は適切な実装へのシンボリックリンクとなってい ます. 例えば, DES 版を使っているようなシステムにおいては次のようになって います: $ cd /usr/lib $ ls -l /usr/lib/libcrypt* lrwxr-xr-x 1 bin bin 13 Sep 5 12:50 libcrypt.a -> libdescrypt.a lrwxr-xr-x 1 bin bin 18 Sep 5 12:50 libcrypt.so.2.0 -> libdescrypt.so.2.0 lrwxr-xr-x 1 bin bin 15 Sep 5 12:50 libcrypt_p.a -> libdescrypt_p.a MD5 に基づいたライブラリを使っているシステムにおいては, 同じようなリンクが 見られるでしょうが, そのターゲットは `libdescrypt' ではなく `libscrypt' になっているでしょう. diff --git a/ja_JP.EUC/handbook/ctm.sgml b/ja_JP.EUC/handbook/ctm.sgml index 5bfc26fcf9..8019f733e3 100644 --- a/ja_JP.EUC/handbook/ctm.sgml +++ b/ja_JP.EUC/handbook/ctm.sgml @@ -1,217 +1,217 @@ - + CTM

原作: &a.phk;. 更新: 16-Mar-1995.

訳: &a.hanai;5 November 1996. なぜ

を読むことを お勧めします.

二つのものが必要でしょう: ``/usr/src/usr.sbin/にあります. もしFreeBSDの2.0以前のバージョンなら, 最新の から入手できます. または、そのが/etc/aliasesからはじめて

デルタを適用するためには, 単に cd /where/ever/you/want/the/stuff?? ctm -v -v /where/you/store/your/deltas/src-cur.*?? とします.

重要なもの ソースツリーへのローカルな修正を可能にすること. これを実現 する一つの方法は次のようなものでしょう:

foo/bar.c''というファイルを変更しようと する時, 最初にfoo/bar.c#CTMというファイルがあるか どうかチェックします. もしこのファイルがあれば, それに デルタを適用します. このようにしてfoo/bar.c ファイルをローカルな要求に合うように変更しておくことができます. 「ファイル復活」のオプションを ctm -r src/sys/i386/wd.c /here/are/my/deltas/src-cur.* これは src-cur ファイルから 残念なことに私は非常に忙しいです. 従ってこれを行なうどんな手助け でも歓迎します. その際, 自分が何をやりたいかを私に 言うのを忘れずに. その他

「DESに染まった」(例えば, 国外への持ち出しが規制された)ソースは まったく含まれません. 手に入るのは「国際」バージョンだけです. もし興味のある人が多いようであれば, 我々は``ありがとう!

diff --git a/ja_JP.EUC/handbook/current.sgml b/ja_JP.EUC/handbook/current.sgml index acd24074e4..c189c5516c 100644 --- a/ja_JP.EUC/handbook/current.sgml +++ b/ja_JP.EUC/handbook/current.sgml @@ -1,161 +1,161 @@ - + 最新のFreeBSDを追いかける

原作: &a.jkh;.

訳: &a.hanai;6 November 1996. FreeBSD-currentってなに?

FreeBSD-currentとは，文字通りに，日々変更されているFreeBSDのソース のスナップショット以外の何ものでもありません．中には現在開発途上の ソフトウェア, 実験的な変更、あるいは過渡的な機能などが含まれています. また, この中に入っている機能がすべて次の公式リリースに入るとはかぎりません. FreeBSD-currentをソースからほとんど毎日コンパイルしている人はたくさん いますが, 時期によってはFreeBSD-currentはコンパイルさえできない状態に なっていることもあります. これらの問題は一般的には可能な限り素早く解決 されますが, FreeBSD-currentのソースが不幸をもたらすか, それとも非常に 素晴らしい機能をもたらすかというのは文字通り, ある与えられた24時間の間 のどの部分であなたがソースを手に入れたか, による場合もあります. 必要があるときには, 時折 FreeBSD-current の一部をバイナリとして提供する こともありますが, それはただ何かをテストしてほしいためであって, 我々が current をバイナリリリースとして提供することにしたわけではありません. 我々が提供していないならば, 要求しないで下さい! これは普段から行なうにはあまりにも時間がかかり過ぎるのです． 誰がFreeBSD-currentを必要としてるの?

FreeBSD-currentは次の3つのどれかにあてはまる人のために一般に公開してい ます. ソースツリーの，ある部分または別の部分に関して活発に作業して いるFreeBSDグループのメンバ．彼らにとっては`最新のもの'に維持して おくことは絶対的な要求なのです． FreeBSD-currentが出来るだけ健全である時間の割合を増やすために 様々な問題と戦うのに時間を費やすのを厭わず活発にテストを行なっている FreeBSDグループのメンバ．彼らはまた様々な変更に関する提案やFreeBSD の大まかな方向付けを行ないたいと思っている人々でもあります． 単に，様々な事に目を向け，参考のために(例えば，動かすためではなく 読むために)最新のソースを使いたいと思っているFreeBSD(または 他の)グループのまわりにいるメンバ．これらの人々はまた時によってコメ ントをしたりコードを寄稿したりします． FreeBSD-currentに期待してはいけないことは?

あなたが何か新しいカッコイイモノがあると聞き, あなたの 周りで最初にそれを持ちたいためにリリース前のコードの断片を 追いかけること. バグを修正するための素早い方法. いずれにしても我々によって``公式にサポートされている''. 私たちは3つの「公式な」FreeBSD-currentのグループの一つに実際に属する 人々を助けるのにベストを尽くしますが, 技術的なサポートを行なうには 単に「時間が足りない」のです. これは我々が外の人を助けるのが好きではないケチで意地悪い人間だと いうことではなく(もしそうなら FreeBSD なんかやっていません), 文字通り 我々は一日に400ものメッセージに答えかつ FreeBSD の作業をする ことなど出来ない! ということなのです. もし, たくさんの質問に答えるか それとも FreeBSD を良くする作業を続けるかという選択が与えられた場合, あなた方のほとんどは後者を支持する, と私は確信しています. FreeBSD-currentを使う

&a.current;と&a.cvsall;に加わって下さい. これは単に良い考えであるというだけでなく, 必須のことなのです. もしFreeBSD-currentメーリングリストに入っていなければ, 様々な人がシステムの現在の状態について述べているコメントを決して見ることは ありませんし, 従って他の人が既に見つけて解決している多くの問題に戸惑っ てあきらめてしまうでしょう. さらに言うと, 非常に不可欠な情報 (例えば, 「やぁ, みんな! /usr/srcを作り直す前にカーネルの 再構築をやらないといけないよ, さもないととんでもないクラッシュが起きるぜ!」)を見逃してしまうでしょう. cvs-allメーリングリストはそれぞれの変更についてそれに関して起 こり得る情報を見ることが出来ます. これらのメーリングリストに入るには, &a.majordomo;へ subscribe freebsd-current subscribe cvs-all と書いたメールを送って下さい. オプションとして本文に`help'と書けば Majordomo はあなたへ我々がサポ ートする様々なメーリングリストに参加/脱退する方法に関する詳しい ヘルプを送ります. ftp.FreeBSD.ORGからのソースの入手. 以下の3つの方法で行なうこと が出来ます. 下に述べられているを用いる. 均一なレートの, 良質の TCP/IP 接続を持っていない人には, これが一番いい方法でしょう. CMUのプログラム(Software Update Protocol)を用いる. これも後で述べられています. これは2番目に推薦される方法です. なぜなら, supによって一度全体 を入手し, 後は変更されたところだけを入手することが出来るからです. たくさんの人がsupをcronから起動し, 自動的にソースを最新のもの に保っています. ftpを使う. FreeBSD-currentのソースツリーは常に に公開されています. 我々はまた全体をcompress/tarして入手できる `wu-ftpd' を使ってい ます. 例えば, usr.bin/lex があったとすると, ftp> cd usr.bin ftp> get lex.tar.Z とすることにより, ディレクトリ全体(この場合, usr.bin/lex以下全体) をcompressされたtarファイルとして入手することができます. 以上のことをまとめると, 必要に応じて迅速なアクセスをする必要があり, 接続のバンド幅が問題ではなければsupかftpを使いましょう. そうではなければ CTMを使いましょう. もしソースを, 眺めるだけでなく走らせるために入手しているので あれば, 一部だけ選ぶのではなく, current の全体を手に入れてください. なぜなら, ソースの様々な部分が他の部分の更新に依存しており, 一部のみを コンパイルしようとすると, ほぼ間違いなくトラブルを起こすからです. current をコンパイルする前に /usr/src にある Makefile をよく読んでください. アップグレードの処理の一部として, 少なくとも一回は最初に `make world' を行なうべきでしょう. &a.current;を読めば, 次のリリースへ向けて, 時々必要になる 他のブートストラップの方法に関して常に最新情報を得ることが出来ます. アクティブになって下さい! もしFreeBSD-currentを走らせているなら 我々はそれに関するコメント, 特に拡張やバグ潰しに関する提案, を欲して います. コードを伴う提案はもっとも歓迎されるものです! diff --git a/ja_JP.EUC/handbook/cvsup.sgml b/ja_JP.EUC/handbook/cvsup.sgml index a474bc1613..9b29e2ba52 100644 --- a/ja_JP.EUC/handbook/cvsup.sgml +++ b/ja_JP.EUC/handbook/cvsup.sgml @@ -1,387 +1,387 @@ - + CVSup

原作: &a.jdp;.

訳: &a.iwasaki;.28 December 1996. CVSup の紹介

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 2.2 以降を使用している場合, CVSup をインストールするもっとも 簡単な方法は, FreeBSD の または対応する を使うことです. どちらを使うかは, CVSupを自分で作りたいかどうかによります.

FreeBSD-2.1.6 を使用している場合は, 残念ながら FreeBSD-2.1.6 には 存在しないバージョンの C ライブラリが必要となるため バイナリ package は使用できません. しかし, は FreeBSD 2.2 とまったく同じように簡単に使うことができます. 単に tar ファイルを展開し, cvsup ディレクトリへ cd して "make install" とタイプするだけです.

CVSup は で書かれているため, package と port 両方とも Modula-3 ランタイムライブラリがインストールされていることが必要です. これらは port の および package の にあります. これらのライブラリの port や package に対して cvsup と同じ管理方法を取っていれば, CVSup の port や package をインストールする際に, これらのライブラリも自動的に コンパイルそして/またはインストールされます.

Modula-3 ライブラリはかなり大きく, これらの転送やコンパイルはすぐに 終わるものではありません. この理由から, 三つめの選択肢が提供されています. 以下のところから, スタティックリンクされた CVSup の FreeBSD 用の実行形式が入手可能です: (client). (server).

ほとんどのユーザはクライアントのみが必要になるでしょう. これらの 実行形式は完全に自己完結しており, FreeBSD-2.1.0 から FreeBSD-current までの, どのバージョンでも動作します.

まとめると, CVSup をインストールするための選択肢は以下の通りです: FreeBSD-2.2以降: スタティックバイナリ, port, package FreeBSD-2.1.6: スタティックバイナリ, port FreeBSD-2.1.5 以前: スタティックバイナリ CVSup のコンフィグレーション

CVSup の動作は, "supfile" と呼ばれるコンフィグレーションファイルで 制御します. FreeBSD-2.2 からは, supfile のサンプルがディレクトリ の下にあります. 2.2 以前のシステムを使用している場合は, これらの サンプルを から入手することができます.

supfile には以下の cvsup に関する質問への答えを記述します:

次のセクションで, これらの質問に順番に答えながら典型的な supfile を組み立てていきます. 最初に supfile の全体構造を説明します.

supfile はテキストファイルです. コメントは "#" から行末までです. 空行とコメントだけの行は無視します.

残りの各行には, ユーザが受け取りたいファイル群について記述します. 行の始めは, サーバ側で定義した論理的なファイルのグループである 「コレクション」の名称です. コレクションの名称を指定して, 欲しいファイル群を サーバに伝えます. コレクション名の後には, ホワイトスペースで区切られた 0個以上のフィールドが続きます. これらのフィールドが上記の質問に対する 答えになります. フィールドには 2種類あります: flag フィールドと value フィールドです. flag フィールドは "delete" や "compress" のような 単独のキーワードから成ります. また, value フィールドもキーワードで 始まりますが, キーワードの後にはホワイトスペースは入らず, "=" と 二つめの単語が続きます. 例えば, "release=cvs" は value フィールドです.

通常, supfile には受け取りたいコレクションを一つ以上指定します. supfile を組み立てる一つの方法として, コレクション毎にすべての関係の あるフィールドを明示的に指定する方法があります. しかし, これでは supfile のすべてのコレクションに対してほとんどのフィールドが同じになるため, 行が非常に長くなってしまい不便になります. これらの問題を避けるため, CVSup ではデフォルトを指定することのできるメカニズムが提供されています. 特殊な擬似コレクション名 "*default" で始まる行は, supfile 中の後続の コレクションに対して使用する flag フィールドと value フィールドの デフォルトを設定するために利用できます. 個々のコレクションで固有の値を 指定すると, デフォルト値を無効にできます. また "*default" 行を追加すると, supfile の途中からデフォルト値の変更や追加が可能になります.

これまでの予備知識を基に, のメインのソースツリーを受け取って更新するための supfile を 組み立ててみましょう. どのファイルを受け取りたいのか?

sup の場合と同様に, CVSup を通して入手できるファイルは 「コレクション」と呼ばれる名前の付けられたグループにまとめられています. FreeBSD のソースツリーを構成しているコレクションについては の節で説明しています. ここでは, FreeBSD システムのメインのソースツリー全体を受け取るための設定例を紹介します. 輸出規制されている暗号化サポートのコード以外のすべてを含む "src-all" という 単一の大きなコレクションがあります. この例では私たちがアメリカ合衆国か カナダにいるものと仮定します. その場合, "src-eBones" および "src-secure" の二つの付化的なコレクションで暗号化コードを入手することができます. supfile を組み立てる最初のステップとして, これらのコレクションを一行に一つづつ 記述します: src-all src-eBones src-secure

どのバージョンのものが欲しいのか?

CVSup を使用すると, かつて存在していたことのある, 事実上どのバージョンの ソースでも受け取ることができます. これは cvsupd サーバがすべてのバージョンを含む CVS リポジトリに基づいて動作することにより, 実現されています. "tag=" および "date=" の value フィールドを使用して, 欲しいバージョンの 一つを指定します.

"tag=" フィールドはリポジトリ中のシンボリックタグを指定します. tag には revision tag と branch tag の二種類があります. revision tag は特定のリビジョンを指します. これは, 毎日同じ状態に保つことになります. 一方 branch tag は, ある時点での開発分流の最新のリビジョンを指します. branch tag は特定のリビジョンを指定している訳ではないので, 今日と明日では 異なるリビジョンを参照することになるかもしれません.

以下はユーザが興味を持っていると思われる branch tag です:

以下はユーザが興味を持っていると思われる revision tag です:

tag 名を示した通りにタイプされているか十分注意してください. CVSup は tag 名が正しいかどうかを見分けることはできません. tag が間違っていた場合, たまたまファイルがまったく存在しない正しい tag が指定されたものとしてCVSup は動作します. その場合は, 現在あるソースが 削除されるでしょう.

branch tag を指定した際には, 通常はその開発分流の最新バージョンの ファイルを受け取ります. いくらか前のバージョンを受け取りたい場合は, "date=" の value フィールドを使って日付を指定することで, これを実現することが できます. cvsup(1) のマニュアルページで, その方法を説明しています.

例として, FreeBSD-current を受け取りたいとします. 次の行を supfile の始めに追加します: *default tag=.

"tag=" フィールドも "date=" フィールドも指定しなかった場合に 動き出す重要な特殊なケースがあります. そのケースでは, 特定のバージョンの ファイルを受け取るのではなく, サーバの CVS リポジトリから実際の RCS ファイルを直接受け取ります. 一般的に開発者はこの処理のモードが 好きなようです. 彼らのシステム上にリポジトリそのもののコピーを維持することで, リビジョン履歴を閲覧し過去のバージョンのファイルを検査できるようになります. しかし, これには大きなディスクスペースが必要になります.

どこから入手したいのか?

これは簡単なことです. cvsup に第一の FreeBSD 配布サイト "cvsup.FreeBSD.org" から最新情報を持ってくるように伝える "host=" フィールドを使います: *default host=cvsup.FreeBSD.org

どのように cvsup を実行しても, この設定は "-h hostname" を 使用してコマンドラインで変更することができます.

自分のマシンのどこに置きたいのか?

"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" は ... 神秘的なものです. これについて本当に 知りたい人は, cvsup(1) のマニュアルページをご覧ください. でなければ, 何も考えずに指定してみてください.

"compress" は通信チャネルで gzip 形式の圧縮の使用を有効にします. ご使用のネットワーク接続が T1 speed 以上である場合, この圧縮を 使用しない方がよいかもしれません. そうでない場合は十分に役に立ちます.

supfile の例のまとめ:

以下は supfile の例の全体です: *default tag=. *default host=cvsup.FreeBSD.org *default prefix=/usr *default base=/usr/local/etc/cvsup *default release=cvs delete use-rel-suffix compress src-all src-eBones src-secure CVSup の実行

さて, 更新の準備ができました. これを実行するコマンドラインは 実に簡単です: cvsup supfile

もちろん, ここでの "supfile" は作成したばかりの supfile のファイル名です. X11 環境で実行するものと仮定して, cvsup は 通常の操作に必要なボタンを持つ GUI ウィンドウを表示します. "go" ボタンを押して, 実行を監視してください.

この例では実際の "/usr/src" ツリーを更新しているので, cvsup にファイルを更新するのに必要なパーミッションを与えるために, ユーザ root で実行する必要があります. コンフィグレーションファイルを作ったばかりで, しかも以前にこのプログラムを実行したことがないので, 神経質になるのは 無理もない話だと思います. 大切なファイルに触らずに試しに実行する簡単な 方法があります. どこか適当な場所に空のディレクトリを作成して, コマンドラインの引数で指定するだけです: mkdir /var/tmp/dest cvsup supfile /var/tmp/dest

指定したディレクトリは, すべての更新されるファイルの 更新先ディレクトリとして使用します. CVSup は "/usr/src" の下の ファイルを検査しますが, 変更や削除はまったくおこないません. かわりに "/var/tmp/dest/usr/src" に更新されたすべてのファイルが 置かれるようになります. この方法で実行した場合は, CVSup は base ディレクトリの status ファイルを更新せずにそのままにします. これらのファイルの新しいバージョンは指定されたディレクトリ に書き込まれます. "/usr/src" の読み取り許可がある限り, このような 試し実行のためにユーザ root になる必要はありません.

X11 を利用していないとか単に GUI が気に入らない場合は, cvsup 起動時にコマンドラインに二つほどオプションを追加する必要があります: cvsup -g -L 2 supfile

"-g" オプションは cvsup に GUI を使用しないように伝えます. X11 を利用していない場合には自動的に指定されますが, そうでない場合は 明示的に指定します.

"-L 2" オプションは cvsup にファイル更新中の詳細情報をプリントアウト するように伝えます. 冗長性には "-L 0" から "-L 2" までの三つのレベル があります. デフォルトは 0 であり, エラーメッセージ以外はまったく出力 しません.

たくさんの他のオプション変数があります. それらの簡単な一覧は "cvsup -H" で表示されます. より詳しい説明はマニュアルページをご覧ください.

動作している更新の方法に満足したら, cron(8) を使って cvsup を定期的に 実行させる準備をすることができます. cron から起動する際には, 明示的に cvsup が GUI を使わないようにする必要があります. CVSup のアナウンス, 質問およびバグ報告

CVSup のほとんどの FreeBSD 関連の議論は &a.hackers; で おこなわれています. ソフトウェアの新しいバージョンは &a.announce; で アナウンスされます.

質問とバグ報告はプログラムの作者, へ 送ってください. diff --git a/ja_JP.EUC/handbook/cyclades.sgml b/ja_JP.EUC/handbook/cyclades.sgml index 06dd083fc0..b8f0f647ee 100644 --- a/ja_JP.EUC/handbook/cyclades.sgml +++ b/ja_JP.EUC/handbook/cyclades.sgml @@ -1,58 +1,58 @@ - + cy ドライバのコンフィグ

原作: &a.alex;.6 June 1996.

訳: &a.yuki;.6 September 1996. Cyclades社のマルチポートカードは, 他のマルチポートカードが 使うsioの代わりにcyドライバを使います. コンフィグレーションは非常に簡単で, cy デバイスをあなたの に足します. (注意. あなたのirqやiomemの設定がが違っているかもしれません) device cy0 at isa? tty irq 10 iomem 0xd4000 iosiz 0x2000 vector cyintr 新しいカーネルの をします. を次(8ポートと仮定しています.)のように打って作ります: # cd /dev # for i in 0 1 2 3 4 5 6 7;do ./MAKEDEV cuac$i ttyc$i;done もし, 必要なら シリアルデバイス(ttyd)とそっくりにコピーして エントリを作り, ttyd 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 新しいカーネルで立ち上げます. diff --git a/ja_JP.EUC/handbook/development.sgml b/ja_JP.EUC/handbook/development.sgml index ad3b9aafe0..b73df0db53 100644 --- a/ja_JP.EUC/handbook/development.sgml +++ b/ja_JP.EUC/handbook/development.sgml @@ -1,104 +1,104 @@ - + FreeBSDの開発モデル

原作: &a.asami;. 18 October 1996.

訳: &a.asami;. 31 October 1996.

FreeBSDの開発は非常に開かれた, 柔軟性のあるプロセスです. を見ていただければわかる とおり, FreeBSDは文字通り世界中の何百という人々の努力によって開発され ています. 新しい開発者はいつでも大歓迎ですので, &a.hackers; にメールを 送ってください. また, 大勢で議論するよりは一人で静かに開発にふけりた いという人は私たちのFTPサイトを使ってパッチや開発中のソースを公開してくださっ て結構です. &a.announce; もありますので, 他のFreeBSDユーザに自分のやっ ていることを宣伝したい時にはどうぞ使ってください. あと, FreeBSDプロジェクトとその開発プロセスについて, どなたにも知って いていただきたいのは以下のようなことです. CVSリポジトリ

FreeBSDのソースツリーは (Concurrent Version System)によってメンテナンスされています. CVSはソー スコード管理用のフリーソフトウェアで, FreeBSDのリリースにも含まれてい ます. FreeBSDのは米国カリフォルニア州のコンコルド市に存在 し, そこから世界中のたくさんのミラーサイトにコピーされています. CVSツ リーそのもの, そしてそのチェックアウトされたバージョンであるとはあな たのマシンにも簡単に取ってくることができます. これについてはの章をご覧ください. ソースツリー管理者

はCVSツリー への書き込み権限を持っている人, つまりFreeBSDのソースに変更を加えるこ とができる人です. (CVSでリポジトリに変更を加えるにはcvs(1) ``commit'' というコマンドを使うので, これらの人々は英語では ``committers'' と呼ばれます.) 開発者にコードを送って見てもらうのに一 番いい方法はコマンドを使うことです. もし, 何か問題があって send-prが使えないならにメー ルを送っていただいても結構です. FreeBSDコアチーム

はFreeBSDプロジェク トが会社だとすると取締役会にあたるものです. コアチームとして一番重要 な役割はFreeBSDプロジェクトが全体としてよい方向に向かっていることを確 認することです. 責任感あふれる開発者を上記のソースツリー管理者として 招くこと, また仕事上の都合などでコアチームをやめた人たちの後任を見つけ ることもコアチームの役割です. 現在のコアチームのほとんどは最初は単な る一開発者としてプロジェクトに関わりはじめ, ずるずるといつのまにか深み にはまってしまった人です.

コアチームのうち何人かは特定の を持っており, システムのうち一部に特に重点をおいて面倒を見ています. また, 忘れてほしくないのはコアチームのほとんどはFreeBSDについてはボラ ンティアであり, FreeBSDプロジェクトからは何ら金銭的な支援を受けていな いということです. ですから, ここでの「責任」は「保証されたサポート」 ではありません. そういう意味で, 上記の取締役会という例えはあまりよく ないかもしれません. むしろ, FreeBSDのために人生を棒に振ってしまった人 の集まりといった方が正しいかも.... ;) その他のコントリビュータ

最後になりますが, もっとも重要で多数をしめる開発者はフィードバック やバグフィクスをどんどん送ってくれるユーザ自身です. FreeBSDの開発に外 郭から関わっていきたいという人は &a.hackers; (を見てください) に参加するといいでしょう. FreeBSDのソースツリーに入っている何かを書いた人のは日に日に長くなっています. あ なたも今日, 何か送ることからはじめてみませんか? :-)

もちろんFreeBSDに貢献するにはコードを書くほかにもいろいろな方法があ ります. 助けが求められている分野については, このハンドブックのの節を見てください. ひとことで言うと, FreeBSDの開発組織はゆるやかな同心円状になっています. ともすると中央集権的に見えがちなこの組織は, FreeBSDのユーザが きちんと管理されたコードベースを容易に追いかけられるようにデザインされ ているもので, 貢献したいという人を締め出す意図は全くありません! 私た ちの目標は安定したオペレーティングシステムと簡単にインストールして使う ことのできるを提供することであ り, この方法は結構うまくはたらくのです. これからFreeBSDの開発にたずさわろうという人に, 私たちが望むことはただ 一つです: FreeBSDの成功を継続的なものにするために, 現在の開発者と同じ ような情熱を持って接してください! diff --git a/ja_JP.EUC/handbook/dialup.sgml b/ja_JP.EUC/handbook/dialup.sgml index f8f3b7ec60..1062b90d99 100644 --- a/ja_JP.EUC/handbook/dialup.sgml +++ b/ja_JP.EUC/handbook/dialup.sgml @@ -1,821 +1,821 @@ - + ダイアルインサービス

原作: &a.ghelmer;.

訳: &a.max;.6 September 1996. このドキュメントでは, FreeBSD で外部からのモデムによるアクセスを受け付 けるための設定に関してまとめてあります. このドキュメントは筆者が FreeBSD 1.0, 1.1 および 1.1.5.1 での経験と, 他の UNIX 系 OS での経験を 基に書いたものですが, 必ずしも十分な内容でないかもしれませんし, 掲載し た実例もあなたが今お使いの環境とは一致しないかもしれません. また, 筆者 はこのドキュメントに従って行われた作業でデータが失われたりシステムが破 壊されるようなことがあっても, 一切責任をとれません. 設定を始める前に

筆者は, 読者が FreeBSD に関する基本的な知識をもっていることを仮定して このドキュメントをまとめました. まず, FreeBSD が既にインストールされ ていて, UNIX 系環境においてファイルの編集の方法やシステムに付属のマニュ アルを参照する方法を知っている必要があります. また, 以下に示すように, FreeBSD の特定のバージョンが必要となりますし, いくつかの用語に関する 知識, そしてモデムや多少の配線に関する知識も必要となります. FreeBSD のバージョン

まず, FreeBSD のバージョンは 1.1 以上を使用してください (バージョン 2.x でもかまいません. ). FreeBSD 1.0 には, 2種類のシリアル ドライバ が含まれているので, 混乱の元となり得ます. また, FreeBSD のシリアル ディバイス ドライバ (用語解説

以下, 簡単にいくつかの用語について解説しておきます. これらの用語やデータ通信一般に関して, より詳しい情報が必要な場合は, 外づけモデムと内蔵モデムについて

ダイアルアップのサービスに関していえば, 外づけのモデムの方が適している ようです. これは, 多くの外づけのモデムは設定を不揮発ラムに書き込んで半 永久的に保存することができますし, また RS-232 に関する重要な情報を知る ための点滅するライトによるインディケータが搭載されているからです. 点滅 するライトは, システムを見に来た訪問者に強い印象を与えるという効果だけ でなく, モデムが適切に動作しているかどうかを知るためにも有効です. 一方, たいていの内蔵型のモデムには不揮発性ラムが搭載されていないため, ディップ スイッチの変更以外に設定を保存する方法がありません. また, も しインディケータがついていても, おそらくコンピュータのケース カバーが 外されていなければその状態を確認するのは難しいでしょう. モデムとケーブル

以下のことに関して, 予め知っておく必要があります. コンピュータとモデムの間での通信が行えるようにするための接続方 法. (内蔵型の場合は接続の必要はありません) お使いのモデムのコマンドについての知識, あるいはコマンドの解説 の在処 (通信ソフトを使っての) モデムの不揮発ラムに保存可能な設定の変更 方法 1番目のモデムの接続はたいてい簡単に行えるはずです. ほとんどのストレー ト シリアル ケーブルが使えるでしょう. 使用すべきケーブルは, 両端に適 切なコネクタ (DB-25 または DB-9 の雄または雌) のついた, DCE-DTE 間接 続用のもので, 以下の信号線が接続されていなければなりません. Transmitted Data ( Received Data ( Request to Send ( Clear to Send ( Data Set Ready ( Data Terminal Ready ( Carrier Detect ( Signal Ground ( FreeBSD で 2400bps 以上の転送速度を利用する場合には, フロー制御のため に シリアル インタフェースについて

FreeBSD では, NS8250-, NS16450-, NS16550- および NS16550A- に基づ いた EIA RS-232C (CCITT V.24) 規格のシリアル インタフェースをサポート しています. 8250 および 16450 ベースのディバイスには1文字のキャラクタ バッファが搭載されています. また, 16550 系のディバイスには, 16文字分 のバッファが搭載されていて, はるかによいパフォーマンスを得られます. (ただし, 無印の 16550 では, バグがあって 16 文字バッファが利用できませ んので, 可能であれば 16550A 系のディバイスを利用してください. ) 1文字 のバッファの物は, 16550 系のものと比べて OS にかける負荷が大きいので, 16550A 系ディバイスの利用を強く推奨します. 多数のシリアル ポートを利 用する場合や, 負荷の高いシステムにおいては, 16550A 系ディバイスを使う ことで, エラー発生率を低く押さえることができます. 概要

FreeBSD は以下の手順でモデムからのログインを受付ます. /dev/ttyd0) がオープンされるのを辛抱強く待ちます. 4850 ?? I 0:00.09 /usr/libexec/getty V19200 ttyd0 ユーザがモデムに電話をかけ, モデム同士が接続されると, モデムの /usr/bin/login を起動して, パスワードの入力を要求し, その 後ユーザのシェルを起動します. それでは, 続いて設定についての解説です. Kernel の設定

通常, FreeBSD の kernel は, PC-DOS の世界で /sbin/dmesg コマンドを使って, ブート時の出力メッセージ を確認してください. 特に, /sbin/dmesg | grep 'sio' たとえば, シリアル ポートを四つ持つシステムの場合は, 以下のようなシリ アル ポートに関するメッセージが kernel によって表示されます. sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A sio2 at 0x3e8-0x3ef irq 5 on isa sio2: type 16550A sio3 at 0x2e8-0x2ef irq 9 on isa sio3: type 16550A もし, kernel に正常に認識されないポートがある場合は, おそらくカスタマ イズした kernel を構築する必要があるでしょう. kernel 構築と構築のための設定に関しては, BSD System Manager's Manual の ``Building Berkeley Kernels with Config (config コマンドによる BSD kernel の構築) '' [ソース ファイルは /usr/src/share/doc/smm にあります]と ``FreeBSD Configuration Options'' [ /sys/conf/options および /sys/arch/conf/options.arch の archの部分をたとえばi386としたファイル ] を参照 してください. kernel の設定と構築をするためには, kernel のソース (FreeBSD 1.1 では srcdist/srcsys.??, FreeBSD 1.1.5.1 では srcdist/sys.??, またFreeBSD 2.0 では総てのソース)を展開 する必要があります. まだ自分のシステムの kernel 用のコンフィギュレーション ファイルを作っ ていない場合は, /sys/i386/conf に device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr device sio2 at isa? port "IO_COM3" tty irq 5 vector siointr device sio3 at isa? port "IO_COM4" tty irq 9 vector siointr システムに搭載されていないディバイスに関する記述は, コメントアウトまた は削除してしまってかまいません. Boca の BB2016 のようなマルチポートの シリアル ボードをお持ちの場合は, できませんので注意が必要です. (マルチポートのシリアル ボードの 場合は, 複数の 16550A ベースのポートで一つまたは二つの IRQ を共有する ための機構を備えています. ) コンフィギュレーション ファイルの編集が終わったら, ``Building Berkeley Kernels with Config (config コマンドによる BSD kernel の構築)'' および ディバイス スペシャル ファイル

kernel に組み込まれているほとんどのディバイスは, /dev ディレ クトリにある, 「ディバイス スペシャル ファイル」を介してアクセスされ ます. /dev/ttyd? およ び, 発信用の /dev/cua0? が利用されます. さらに, FreeBSD の 1.1.5 以降では, 初期化ディバイス (/dev/ttyi? と /dev/cuai0?)およびロッキング ディバイス (/dev/ttyld? と /dev/cual0?) も合わせて利用されます. 初期化ディバイスは, 通信 ポートがオープンされる度に, そのポートの初期設定を行うために使われます. たとえば, CTS/RTS によるフロー制御を行うモデムが接続されてい る場合の ディバイス スペシャル ファイルの作成

ディバイス スペシャル ファイルの管理は, ディレクトリ /dev にあるシェル スクリプト /dev に /dev/ttyd? のディバイス ファイルだけでなく, /dev/cua0? (および FreeBSD 1.1.5 以降では総ての初期化ディバイ スとロッキング ディバイスのスペシャル ファイル) も作成します. さらに, もしシリアル端末用のスペシャル ファイル/dev/tty0? が存在すれ ば, それらの削除も行います. ディバイス スペシャル ファイルの作成後, これらのファイルのパーミション が適切に設定されていて, これらのディバイスを利用してもよいユーザのみが 読み書きできるようになっていることを確認してください. (特に /dev/cua* のパーミションには注意を払ってください. ) この確認 を怠ると, 一般のユーザがあなたのモデムを使うことができるようなことにな りかねません. デフォルトの /dev/cua* のパーミションは, 以下の ようになっていて, たいていの場合適切なものだと思います. crw-rw---- 1 uucp dialer 28, 129 Feb 15 14:38 /dev/cua01 crw-rw---- 1 uucp dialer 28, 161 Feb 15 14:38 /dev/cuai01 crw-rw---- 1 uucp dialer 28, 193 Feb 15 14:38 /dev/cual01 上の設定では, ユーザ 設定ファイル

FreeBSD のシステムへのダイアル アップによるアクセスを実現するために編 集が必要と思われる設定ファイルが, /etc ディレクトリに三つあ ります. まず, /etc/gettytab には, /usr/libexec/getty デーモンの設定を記述します. つぎに, /etc/ttys に保存されている情報から, /sbin/init はど の /etc/rc.serial スクリプトに, それ以前のものならば /etc/rc.local スクリプトにシリアル ポートの初期化のためのコマ ンドを記述することができます. UNIX にダイアル アップ モデムを接続する方法には, 二つの考え方がありま す. 一つの方法は, ダイアル インしてくるユーザの接続速度に関係なく, 常 にモデムとローカルのコンピュータの RS-232 インタフェースの接続速度を一 定に保つように設定する方法です. この設定の長所は, ユーザがダイアル イ ンして接続されると, 即座にシステムからのログイン プロンプトが送信され るということです. 短所は, システムが実際のモデム間の速度を知ることがで きないために, Emacs のようなフル スクリーンのプログラムが, 端末との接 続速度が遅い場合でも, そのような場合に効果的な方法で画面出力を行わない 点です. もう一つは, モデムの RS-232 インタフェースとコンピュータの接続速度を, モデム間の接続速度に応じて変化させるような設定です. たとえば, モデム間 の接続が V.32bis (14.4 Kbps) ならば, モデムとコンピュータの間の接続を 19.2 Kbps とし, モデム間の接続が 2400 bps の時には, モデムとコンピュー タ間も 2400 bps で接続するような設定をします. この場合, <Enter> キーを繰り返し押さなければならない ということを知っていると仮定しています. もし接続速度が間違っている場合, /etc/gettytab

/etc/gettytab は, 固定速度の設定

モデムとコンピュータ間の通信速度を固定して使う場合, おそらく /etc/gettytab に特に変更を加える必要はないはずです. 可変速度の設定

/etc/gettytab に記述する必要があります. もし, 2400 bps のモ デムをお使いになるのであれば, 既存の # # Fast dialup terminals, 2400/1200/300 rotary (can start either way) # D2400|d2400|Fast-Dial-2400:\ :nx=D1200:tc=2400-baud: 3|D1200|Fast-Dial-1200:\ :nx=D300:tc=1200-baud: 5|D300|Fast-Dial-300:\ :nx=D2400:tc=300-baud: 高速モデムをお使いの場合は, おそらく /etc/gettytab に新たなエ ントリを追加する必要があります. 以下の例は, 14.4 Kbps のモデムを, 最 大インタフェース速度を 19.2 Kbps として利用するためのエントリです. # # Additions for a V.32bis Modem # um|V300|High Speed Modem at 300,8-bit:\ :nx=V19200:tc=std.300: un|V1200|High Speed Modem at 1200,8-bit:\ :nx=V300:tc=std.1200: uo|V2400|High Speed Modem at 2400,8-bit:\ :nx=V1200:tc=std.2400: up|V9600|High Speed Modem at 9600,8-bit:\ :nx=V2400:tc=std.9600: uq|V19200|High Speed Modem at 19200,8-bit:\ :nx=V9600:tc=std.19200: 上記の例を利用した場合, FreeBSD 1.1.5 以降ではパリティなし, 8ビットの 接続が行われます. FreeBSD 1.1 では, のエントリに追加することで, パリティなし, 8ビットの接続が行われますが, このパラメータを追加しなければ接続は偶数 パリティ, 7ビットになります. 上記の例では, まず 19.2 Kbps (V.32bis) によるモデムとコンピュータ間の 接続を試み, 続いて 9600 bps (V.32), 2400 bps, 1200 bps, 300 bpsと順に 試み, 再び 19.2 Kbps による接続を試みるという循環に入ります. この接続 速度の循環は, # # Additions for a V.32bis or V.34 Modem # Starting at 57.6 Kbps # vm|VH300|Very High Speed Modem at 300,8-bit:\ :nx=VH57600:tc=std.300: vn|VH1200|Very High Speed Modem at 1200,8-bit:\ :nx=VH300:tc=std.1200: vo|VH2400|Very High Speed Modem at 2400,8-bit:\ :nx=VH1200:tc=std.2400: vp|VH9600|Very High Speed Modem at 9600,8-bit:\ :nx=VH2400:tc=std.9600: vq|VH57600|Very High Speed Modem at 57600,8-bit:\ :nx=VH9600:tc=std.57600: もし, お使いの CPU が低速のものであったり, CPU に対する負荷が高い場合 で, 16650A 系のシリアル ポートをお使いでない場合, 57.6 Kbps の接続に おいて, sio の ``slio'' エラーが発生するかもしれません. /etc/ttys

/etc/ttys には, /etc/ttys は, /etc/ttys の既存の行を変更するか, あるいは新しい行を追加して, ttyd0 "/usr/libexec/getty xxx" dialup on 1番目の項目は, このエントリで対象とするディバイス スペシャル ファイル です. 上の例では /dev/ttyd0 を "/usr/libexec/getty (/etc/ttys の修正がすんだら, 以下のようなコマンドを使って /etc/ttys を 読み込み直させてください. kill -1 1 ただ, もし初めてシステムを設定しているのであれば, モデムが適切に設定さ れて接続されるまでは, 固定速度の設定

速度を固定する設定では, /etc/ttys の中で, ttyd0 "/usr/libexec/getty std.19200" dialup on 別の速度でモデムのポートのスピードを固定したい場合は, /etc/gettytab から適切なエントリを選んで, 上の例の std. として, 適切な速度のも のに置き換えてください. 可変速度の設定

可変速度の設定では, /etc/gettytab の中の適切な「自動速度調整」の初期設定のエントリを参照していなければな りません. たとえば, もし前述の 19.2 Kbps から接続を試みる可変速度の設 定例 ( ttyd0 "/usr/libexec/getty V19200" dialup on /etc/rc.serial または /etc/rc.local

V.32, V.32bis または V.34 モデムのような高速モデムを利用する場合, ハー ドウェア (RTS/CTS) フロー制御を行う必要があります. FreeBSD kernel のモデム ポートにハードウェア フロー制御のフラグを設定するため の /etc/rc.serial に, FreeBSD 1.1 では /etc/rc.local に 記述できます. たとえば, FreeBSD 1.1.5.1 の /etc/rc.serial のサンプルは以下 のとおりです. #!/bin/sh # # Serial port initial configuration stty -f /dev/ttyid1 crtscts stty -f /dev/cuai01 crtscts この例では, /etc/rc.local に追加されていました. # Set serial ports to use RTS/CTS flow control stty -f /dev/ttyd0 crtscts stty -f /dev/ttyd1 crtscts stty -f /dev/ttyd2 crtscts stty -f /dev/ttyd3 crtscts FreeBSD 1.1 には初期化のためのディバイス スペシャル ファイルがないので, ディバイス ファイルそのものにフラグを設定して, その後はフラグをクリア してしまうような極悪人が現れないことを願うしかありません. モデムの設定

もし, あなたのモデムがパラメータを不揮発ラムに保存できるタイプならば, PC-DOS 上の Telix や FreeBSD 上の 接続時に 接続時に 送信時フロー制御には XON/XOFF によるフロー制御を行わない. 受信時のフロー制御は Quiet mode (リザルト コードを返さない) コマンド エコーを返さない. これらを実現するためのコマンドやディップ スイッチの設定に関しては, モ デムのマニュアルを参照してください. 以下に, USRobotics Sportster の 14,400 bps の外づけモデムの設定例を示 しておきます. ATZ AT&C1&D2&H1&I0&R2&W ことのついでに, たとえば, V42.bis や MNP5 のデータ圧縮を使用するかど うかなどのモデムの他の設定について確認, 調整しておくのもよいかもしれま せん. さらに, USRobotics Sportster の 14,400 bps の外づけモデムでは, 以下の ようなディップ スイッチの設定も必要です. 他のモデムをお使いの方も, 以 下の例を設定の参考にしてください. スイッチ1: UP - DTR 標準 スイッチ2: 無視 (リザルト コードを単語形式にするか数値形式にす るか) スイッチ3: UP - リザルト コードを返さない スイッチ4: DOWN - コマンド エコーを返さない スイッチ5: UP - 自動着信 スイッチ6: UP - CD 標準 スイッチ7: UP - 不揮発ラムからデフォルト値をロードする スイッチ8: 無視 (Smart Mode/Dumb Mode) リザルト コードを返さないように設定しておかないと, 固定速度の設定

固定速度の設定では, モデムとコンピュータ間の通信速度をモデムとモデム間 の接続速度に関係なく, 常に一定に保つように, モデムを設定する必要があり ます. USRobotics Sportster の 14,400 bps 外づけモデムの場合, 以下のコ マンドで, モデムとコンピュータ間の速度が, コマンド送信時の速度に固定さ れます. ATZ AT&B1&W 可変速度の設定

可変速度の設定では, シリアル ポートの速度が, 着信速度に応じて変化する ように設定しなければいけません. USRobotics Sporster の 14,400 bps 外 づけモデムの場合, 以下のコマンドで, エラー訂正機能を利用した通信の場合 は, コマンドを送信した時の通信速度にシリアル ポートの速度を固定し, エ ラー訂正機能を利用しない接続では, シリアル ポートの速度が変化するよう に設定されます. ATZ AT&B2&W モデムの設定の確認

ほとんどの高速モデムには, 現在の設定をある程度人間にも理解できる形式に して表示させるコマンドがあります. USRobotics Sporster の 14,400 bps 外づけモデムの場合は, トラブルシューティング

以下の手順でダイアル アップ モデムの動作を確認することができます. FreeBSD システムの動作確認

モデムを FreeBSD システムに接続し, システムをブートします. あなたのモ デムにモデムの状態を確認するためのインジケータがあれば, 114 ?? I 0:00.10 /usr/libexec/getty V19200 ttyd0 115 ?? I 0:00.10 /usr/libexec/getty V19200 ttyd1 モデムにまだ着信がない状態の時に, 以下のように上とは異なる出力があった 場合, 114 d0 I 0:00.10 /usr/libexec/getty V19200 ttyd0 ^^ /etc/ttys の内容を確認し, 書式などに誤りがないか 調べてみてください. また, ログ ファイル /var/log/messages に /etc/ttys , /etc/gettytab の二つの設定ファイルと, ディバイス スペシャル ファイル /dev/ttyd? を確認し, 記述に誤りがないか, 足りないエ ントリがないか, 足りないディバイス スペシャルファイルがないかといった 点について調べてみてください. モデムで接続してみる

実際にモデムを使って別のコンピュータから接続してみてください. この時, 8ビット, パリティなし, 1ストップ ビットで接続するようにしてください. 接続後すぐにプロンプトが返ってこない場合や, 無意味な文字列が表示される 場合は, 1秒に1回くらいの割合で <Enter> キーを押してみて ください. しばらくたって, なおも BREAK 信号を送信してみてください. この時, 端末側で使って いるモデムが高速モデムならば, このモデムのインタフェースの接続速度を固 定してから, 再度ダイアル インしてみてください. (たとえば, USRobotics Sportster の場合は, AT&B1) それでもまだ /etc/gettytab の以下の点について再度確認してみてください. /etc/ttys の対応する行の 2番目の項目で, /etc/gettytab の中で定義されているエントリが指定されているか 各 /etc/gettytab の中で定義されているもの が指定されているか 各 /etc/gettytab の中で定義されているもの が指定されているか もしダイアル インしても, FreeBSD システム側のモデムが応答しない場合は, FreeBSD 側のモデムが 謝辞

以下の方々から, 多くのコメントやアドバイスをいただきました. ここに謝意 を表します. diff --git a/ja_JP.EUC/handbook/diskless.sgml b/ja_JP.EUC/handbook/diskless.sgml index 109428ad43..f9c6157536 100644 --- a/ja_JP.EUC/handbook/diskless.sgml +++ b/ja_JP.EUC/handbook/diskless.sgml @@ -1,163 +1,163 @@ - + Diskless operation

Contributed by &a.martin;. 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 - hostnameの表示/セット kernel - カーネル名の表示/セット rootfs - root ファイルシステムの表示/セット swapfs - swap ファイルシステムの表示/セット swapsize - diskless swapsize を Kbytes単位でセット diskboot - ディスクからのブート autoboot - ブートプロセスの続行 trans - トランシーバのオン|オフ flags [bcdhsv] - ブートフラグの設定 完全にディスクレスな場合の一般的な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経由でスワッピングを行う場合 (完全にディスクレスな場合の設定)、 クライアントが dd で使用する swap ファイルを作成します。 もし、swapfs コマンドが上記の例のように 引数 /swapfsを持ちそのサイズが 20000 である場合、 myclientに対するスワップファイルは /swapfs/swap.X.X.X.X で呼び出されます。 ここで X.X.X.X はクライアントのIPアドレスです。 例: # dd if=/dev/zero of=/swapfs/swap.192.1.2.4 bs=1k count=20000 また、スワッピングが開始されるとクライアントのスワップスペースは センシティブな情報を含むようになるので、不正なアクセスを防止するため、 このファイルへの読み書きのアクセス制限がなされていることを確認して下さい: # 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を作成します。 / および /usr ファイルシステムを共有して使用する

今のところ、これを行う公式に認められた方法はありませんが、 私はそれぞれのクライアントで /usr ファイルシステムと 個々の / ファイルシステム を共有して使っています。 どなたかこれをきちんと行うやり方の提案がありましたら、 私に、もしくは &a.core; グループに知らせてください。 特定の設定についてnetbootをコンパイルする

/sys/i386/boot/netboot/Makefile の中の設定を変更して コンパイルすることで、netbootでNE1000/2000 カードをサポートします。 このファイルの先頭にあるコメントを見てください。 diff --git a/ja_JP.EUC/handbook/dma.sgml b/ja_JP.EUC/handbook/dma.sgml index f3c9be5273..6666d0ca1f 100644 --- a/ja_JP.EUC/handbook/dma.sgml +++ b/ja_JP.EUC/handbook/dma.sgml @@ -1,478 +1,478 @@ - + DMAとはどういったものでどういう働きをするのか

Copyright © 1995 &a.uhclem;, All Rights Reserved. 18 October 1995. 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回で 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コントローラに要求を伝えることで開始します. 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内のアドレスレジスタはインクリメントされ, 何バイト転送すればよいかを示すカウンタがデクリメントされます. カウンタが0になると, DMAはカウンタが0になったことを示すEOP信号を 送り, DMAコントローラがCPUによって再びプログラムされるまで これ以上データは転送されなくなります. このイベントはターミナルカウント(TC)とも呼ばれます. EOP信号は1本しかありません. なぜならどんな時もただ1つのDMAチャネル のみをアクティブにすることができるためです. もし, バッファの転送が完了した時に周辺機器から割り込みを発生させたい とき, 周辺機器は -DACK信号およびEOP信号の両方が同時に発信されたか どうかをテストします. それが生じると, DMACはCPUの介在がなければ これ以上はその周辺機器についての情報を転送しないことを意味します. すると周辺機器はプロセッサの注意を得るために割り込み信号のうちの1つを 発信します. 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操作が 終了するまでそこに保持されます. これらのラッチは「ページレジスタ」と呼ばれます. そのため上記に示した例では, DMACはアドレスの0x3456の部分をバス上に 置き, DMAチャネル2に対するページレジスタは, 0x0012xxxxをバス上に 置きます. これらの2つの値が組み合わされてアクセスされるメモリ中の完全な アドレスを形成します. ページレジスタのラッチはDMAチップとは独立であるので, 読み込まれる又は書き込まれるメモリ領域は, 64kの物理的境界を またいではなりません. もしDMACがメモリの0xffff番地をアクセスすると, DMACはアドレスレジスタを インクリメントします. 次にアクセスされるバイトは 0x0000番地に なるでしょう. 0x10000ではありません. これはおそらく意図されたものとは異なっているでしょう. 注: 「物理的な」 64Kの境界を 8086モードの 64k「セグメント」と混同してはいけません. セグメントは, セグメント レジスタにオフセットレジスタを加算して作られるものです. ページレジスタにはアドレスのオーバーラップはありません. さらに複雑なことには, PC/ATでは外部のDMAアドレスのラッチは 8ビットしか保持しません. よって8+16で24ビットになり, これは DMAが0から16メガの間のメモリ番地しか指し示せないことを 意味します. 16メガ以上のメモリを持ったより新しいマシンにおいても, PCコンパチブルなDMAでは16メガ以上の番地にはアクセスできません. この制限を避けるために, オペレーティングシステムは 16メガ以下にある物理的な64kの境界をまたがない領域にバッファを 予約します. そして, DMACはデータをそのバッファに読み出すように プログラムされます. 一旦DMACこのバッファにデータを動かすと, オペレーティングシステムは本当にデータを格納したいアドレスに バッファからデータをコピーします. 16メガを越えるアドレスからDMAベースの周辺機器にデータを 書き込む際には, データは16メガ以下に位置したバッファから最初に コピーされなくてはならず, その後, DMACはバッファからハードウェアに データをコピーすることができます. FreeBSDでは, これらの予約バッファは 「バウンスバッファ」と呼ばれます. MS-DOSの世界では, これらは「スマートバッファ」などと呼ばれます. DMA操作モードとその設定

8237 DMA はいくつかのモードで動作します. 主なモードは, 以下のとおりです. シングル転送モード シングルバイト(もしくはワード)が転送されます. DMAは1バイト毎にバスを開放し, 再び要求しなくてはなくてはなりません. これは一般に, すぐにはデータのブロック全てを転送できないデバイスに よって使用されます. 周辺装置は次の転送の準備ができる毎にDMAを要求します. フロッピーディスクコントローラは1バイトのバッファしか持たないので, このモードを使用します. ブロック/デマンド転送モード 一旦DMACがシステムバスを取得すると, 最大64kまでのデータブロック 全体が転送されます. もし周辺装置が余分に時間を必要とするときは, READY信号を有効に します. READY信号は過度に使われるべきではなく, 遅い周辺装置の転送の場合は シングル転送モードを代わりに使うべきです. ブロック転送モードとデマンド転送モードの違いは, 一旦ブロック転送が 始まると,転送カウンタか0になるまでそれが行われるところです. 1バイト転送するにはDRQが -DACK が有効になるまでの間だけ 有効であれば充分です. デマンドモードはDRQが有効な間は転送が続けられます. DRQが無効に なったことで中断された転送は, DRQがその後 有効になったときに, 転送が中断したところから再開されます. CPUを使ってデータを読み出した方が効率がよくなるくらい CPUの速度が向上するより前の 古いハードディスクコントローラはデマンドモードを使っていました. カスケード転送モード このメカニズムはDMAチャネルがバスを要求することを許可する ものですが, 接続されたデバイスはバス上のアドレス情報の配置に ついて責任を持ちます. これはいわゆる「バスマスタ」というものです. カスケードモードのDMAチャネルがバスのコントロールを受け取ると, DMAは通常行われるようなバス上のアドレスとI/Oコントロール信号の 出力を行いません. 代わりに, DMAはこのチャネルの -DACK信号を 有効にします. そして, アドレスとバスコントロール信号の供給は DMAチャネルに接続されたデバイスが担当します. 周辺機器はシステムバスの完全なコントロールを行い, 16メガ以下の任意のアドレスの読み込みおよび書き込みを行うことが できます. 周辺機器はバスの使用を終えると, DRQ線を無効にして, DMAコントローラはCPUもしくは他のDMAチャネルに制御を返します. カスケードモードは複数のDMAコントローラを相互接続するのに 使われます. PC内ではDMAチャネル4がまさにこの用途に使われています. 周辺機器がDMAチャネル0, 1, 2, 3でバスを要求すると, スレーブDMAコントローラは HLDREQ を有効にしますが, この線は実際にはプライマリDMAコントローラのDRQ4に接続されています. プライマリのDMAコントローラはその後 HLDREQ を使ってCPUにバスを 要求します. バスが与えられると, -DACK4が有効になり, この線は実際にはスレーブDMAコントローラの HLDA信号に接続されています. スレーブDMAコントローラはその後要求したDMAチャネルに対して データを転送するか, バスマスタリングを要求する周辺機器にバスを 許可します. このような配線がおこなわれているため, PC/ATシステムではDMAチャネルは 0, 1, 2, 3, 5, 6, 7のみが使用できます. 注: 初期のIBM PCコンピュータでは, DMAチャネル0は操作の リフレッシュのために予約されていますが, 最近のシステムでは通常, 周辺機器によって使用することができます. 周辺機器がバスマスタリングを行っている時は, システムバスを保持している間絶えずメモリにもしくはメモリから データを転送することが重要です.もし, 周辺機器がこのように できないときは, システムがメモリのリフレッシュを行なえるように しばしばバスを開放しなくてはなりません. メモリの読み込みと書き込みのサイクルはリフレッシュサイクルとして カウントされる(リフレッシュサイクルは実際には不完全なメモリ 読み込みサイクルになります)ので, 周辺機器のコントローラが連続するメモリ番地からデータの読み込み または書き込みを行う間は, メモリの全てをリフレッシュされます. バスマスタリングはいくつかの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 0x02 write Channel 0 starting word count 0x02 read Channel 0 remaining word count 0x04 write Channel 1 starting address 0x04 read Channel 1 current address 0x06 write Channel 1 starting word count 0x06 read Channel 1 remaining word count 0x08 write Channel 2 starting address 0x08 read Channel 2 current address 0x0a write Channel 2 starting word count 0x0a read Channel 2 remaining word count 0x0c write Channel 3 starting address 0x0c read Channel 3 current address 0x0e write Channel 3 starting word count 0x0e read Channel 3 remaining word count DMA コマンドレジスタ 0x10 write Command Register 0x10 read Status Register 0x12 write Request Register 0x12 read - 0x14 write Single Mask Register Bit 0x14 read - 0x16 write Mode Register 0x16 read - 0x18 write Clear LSB/MSB Flip-Flop 0x18 read - 0x1a write Master Clear/Reset 0x1a read Temporary Register 0x1c write Clear Mask Register 0x1c read - 0x1e write Write All Mask Register Bits 0x1e read - 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 0xdc write Clear Mask Register 0xdc read - 0xde write Write All Mask Register Bits 0xde read - 0x80 - 0x9f DMA ページレジスタ

0x87 r/w DMA Channel 0 0x83 r/w DMA Channel 1 0x81 r/w DMA Channel 2 0x82 r/w DMA Channel 3 0x8b r/w DMA Channel 5 0x89 r/w DMA Channel 6 0x8a r/w DMA Channel 7 0x8f Refresh diff --git a/ja_JP.EUC/handbook/eresources.sgml b/ja_JP.EUC/handbook/eresources.sgml index 974a039e04..7b6a6f15a6 100644 --- a/ja_JP.EUC/handbook/eresources.sgml +++ b/ja_JP.EUC/handbook/eresources.sgml @@ -1,375 +1,375 @@ - + インターネット上のリソース

原作: &a.jkh;.

訳: &a.yuki;.28 August 1996

FreeBSDの進歩が急速であるため, 最新の開発をフォローするためには, 印刷したメディアは実用的でなくなっています. 大抵の場合, 最新情報を入手する方法としては, 電子的なリソースが ベストです. FreeBSDはボランティアの努力によって, ユーザコミュニティ自体が, 一種の「テクニカルサポート部門」としての 役割も通常果たしており, 電子メールやUsenetのニュースがこれらのコミュ ニティにたどり着く最も効果的な方法になっています. 以下に, FreeBSD ユーザコミュニティに連絡を取る場合の最も重要な点についての 概略を示します. もしここに書かれていない他のリソースに気がついた場合は, それらを &a.doc に送って頂ければ, それらをここに含めるかもしれません. メーリングリスト

多くのFreeBSDの開発メンバはUSENETを読むことができますが, もし, comp.unix.bsd.freebsd.*のグループの一つに質問を投稿したとしても タイムリにその質問を受け取るということは保証できません. 質問を適切なメーリングリストに投稿すれば, 私たちかFreeBSDの関係者から, よりよい (そして少なくともより早い) 反応がいつでも得られることでしょう.

さまざまなメーリングリストの憲章をこのドキュメントの最後に記載します. 私たちは, メーリングリストの質, 特に技術面に関する質を高く保つために 努力しているので, メーリングリストに参加する前にその憲章を読んでください. メーリングリストはいずれもアーカイブされており, それらは で検索することができます. キーワード検索可能なアーカイブの提供は, 良くある質問に対する回答を見つけるすぐれた方法ですから, 質問を投稿する前に調べてみるべきでしょう. メーリングリストの概説

一般的なメーリングリスト: 以下のものは誰でも自由に参加できる 一般的なものです: リスト 目的 ---------------------------------------------------------------------- freebsd-announce 重要なイベントやプロジェクトのマイルストン freebsd-bugs バグレポート freebsd-chat FreeBSDコミュニティに関連する技術的ではない話題 freebsd-current FreeBSD-currentの使用に関連する議論 freebsd-stable FreeBSD-stableの使用に関連する議論 freebsd-isp FreeBSDを用いているインターネットサービスプロバイダの話題 freebsd-questions ユーザからの質問 技術的なメーリングリスト: 以下のメーリングリストは, 技術的な議論のためのものです. これらのメーリングリストに入る前には憲章を注意深く読むべきであり, メーリングリストに投稿するメッセージがガイドラインの範囲に収まるようにしてください. リスト 目的 ---------------------------------------------------------------------- freebsd-doc FreeBSDのドキュメンテーションプロジェクト freebsd-emulation Linux/DOS/Windowsのような他のシステムのエミュレーション freebsd-fs ファイルシステム freebsd-hackers 一般的な技術の議論 freebsd-hardware FreeBSDの走るハードウェアの一般的な議論 freebsd-mobile モーバイルコンピューティングについての議論 freebsd-multimedia マルチメディアの議論 freebsd-platforms Intel以外のアーキテクチャのプラットフォームへの移植 freebsd-ports portsコレクションに関する議論 freebsd-security セキュリティに関する話題 freebsd-security-notifications セキュリティに関する通知 (モデレーテッドメーリングリスト) freebsd-scsi SCSIサブシステム freebsd-smp 対称/非対称のマルチプロセッシングの設計に関する議論 制限されているメーリングリスト: 以下のメーリングリストは参加するには認可が必要ですが, 提案やコメントは誰でも自由に投稿することができます. これらの制限されているメーリングリストへの参加の伺いの前に, 技術的なメーリングリストで存在を確立するのがよい考えです. メーリングリスト 目的 ---------------------------------------------------------------------- freebsd-admin 管理に関する話題 freebsd-arch アーキテクチャや設計の議論 freebsd-core FreeBSDコアチーム freebsd-hubs ミラーサイトを運営している人達 (基盤のサポート) freebsd-install インストール関係の開発 freebsd-user-groups ユーザグループの調整 CVSメーリングリスト: 以下のメーリングリストはソースツリーの さまざまな場所の変更のログメッセージを見ることに興味のある人向けです. メーリングリスト ソースの範囲 (ソースの) 範囲の説明 ---------------------------------------------------------------------- cvs-CVSROOT /usr/src/[A-Z]* /usr/src/ 以下のトップレベルのファイルの変更 cvs-all /usr/src ツリーのすべての変更 (スーパーセット) cvs-bin /usr/src/bin システムバイナリ cvs-etc /usr/src/etc システムファイル cvs-games /usr/src/games ゲーム cvs-gnu /usr/src/gnu GPLにしたがったユーティリティ cvs-include /usr/src/include インクルードファイル cvs-kerberosIV /usr/src/kerberosIV Kerberos暗号化コード cvs-lib /usr/src/lib システムライブラリ cvs-libexec /usr/src/libexec システムバイナリ cvs-ports /usr/ports 移植済みソフトウェア cvs-sbin /usr/src/sbin システムバイナリ cvs-share /usr/src/share システム共有ファイル cvs-sys /usr/src/sys カーネル cvs-usrbin /usr/src/usr.bin ユーザバイナリ cvs-usrsbin /usr/src/usr.sbin システムバイナリ 参加方法

どのメーリングリストもFreeBSD.ORGにあるので, メーリングリストにメールを送るには, ただ listname@FreeBSD.ORG にメールを送るだけです. すると, メーリングリストに登録されている世界中のメンバに再配布されます. メーリングリストに参加するには, subscribe [] という内容をメッセージの本文に含むメールを &a.majordomo に送ります. 例えば, freebsd-announce に参加したい場合は次のようにします: % mail majordomo@FreeBSD.ORG subscribe freebsd-announce ^D もし, あなたが, 自分自身を違う名前 (メールアドレス) で登録したい場合, あるいは, ローカルなメーリングリスト (注意:もしあなたのサイトに, 興味を持った仲間がいるなら, これはより有効ですし, 私たちにとっても非常に嬉しいことです.) を登録する申し込みをおこないたいのであれば, 次のようにします: % mail majordomo@FreeBSD.ORG subscribe freebsd-announce local-announce@somesite.com ^D 最後に, majordomoに対して 他のタイプのコントロールメッセージを送ることで メーリングリストから脱退したり, メーリングリストの他のメンバのリストを 得たり, 再びメーリングリストのリストを見たりすることも可能です. 利用できるコマンドの完全なリストを入手するには, 次のようにします: % mail majordomo@FreeBSD.ORG help ^D 再度言いますが, 私たちは技術的なメーリングリストでは技術的な議論を保つよう 要求します. もし, 「高いレベル」にのみ興味があるなら, freebsd-announce に参加するように勧めます. これは少ないトラフィックの予定です. メーリングリストの憲章

管理上の話題 重要なイベント/マイルストン これは, 単にたまに発表される重要なfreebsdのイベントに関心がある人のための メーリングリストです. これは, スナップショットやその他のリリースについての アナウンスを含みます. そのアナウンスは新しいFreeBSDの機能のアナウンスを含んでいます. ボランティア等の呼びかけがあるかもしれません. これは流通量の少ないメーリングリストです. アーキテクチャと設計の議論 これは, FreeBSDの設計に関する議論をする人向けのメーリングリストです. これは, クローズドなリストで, 一般的には参加できません. バグレポート これは, FreeBSDのバグレポートのためのメーリングリストです. 可能である場合はいつでも, バグは ``send-pr'' を使って送られる必要があります. コミュニティに関する技術的ではない話題 このメーリングリストは技術的ではなく, 社会的な情報について, 他のメーリングリストでは取り扱わない話題を含みます. これは, Jordanがシロイタチに似ているかどうか, 大文字で打つかどうか, 誰がたくさんコーヒーを飲むか, どこのビールが一番うまいか, 誰が地下室でビールを作っているか, などについての議論を含みます. 時々重要なイベント (将来開催されるパーティーや, 結婚式, 誕生日, 新しい仕事など) のお知らせが, 技術的なメーリングリストから でてきます. しかし, フォローは直接 -chatメーリングリストにするべきです. FreeBSDコアチーム これは, コアメンバが使う内部メーリングリストです. FreeBSD-currentの使用に関する議論 これは freebsd-current のユーザのためのメーリングリストです. メーリングリストでの話題は, -current で登場した新しい機能について, その新機能によってユーザに影響することについての注意, および -current のままでいるために必要な手順についての説明を含みます. "current" を走らせている人はこのメーリングリストに登録しなくてはなりません. FreeBSD-currentの使用に関する議論 freebsd-currentメーリングリストのダイジェスト版です. このダイジェストはfreebsd-currentに送られたすべてのメッセージをまとめたものを, 1つのメールにして送り出します. 平均のサイズは約40kbyteです. FreeBSD-stableの使用に関する議論 これは freebsd-stable のユーザ用のメーリングリストです. メーリングリストでの話題は, -stable で登場した新しい機能について, そ の新機能によってユーザに影響することについての注意, および -stable のままでいるために必要な手順についての説明を含みます. "stable" を走らせている人はこのメーリングリストに登録すべきです. ドキュメンテーションプロジェクト このメーリングリストはFreeBSD Doc Projectに属し, ドキュメンテーションに関連する問題やプロジェクトの議論のためのものです. ファイルシステム FreeBSDのファイルシステムに関する議論 技術的な議論 これはFreeBSDに関する技術的な議論のためのフォーラムです. これは最もテクニカルなメーリングリストです. このメーリングリストは, FreeBSD 上でアクティブに活動をしている人のためのもので, 問題を持ち出したり, 代わりの解決法を議論します. 技術的な議論をフォローするのに興味がある人も歓迎します. 技術的な議論 freebsd-hackersメーリングリストのダイジェスト版です. このダイジェストはfreebsd-hackersに送られたすべてのメッセージをまとめたものを, 1つのメールにして送り出します. 平均のサイズは約40kbyteです. FreeBSDのハードウェアの一般的な議論 FreeBSDが走っているハードウェアのタイプや, 何を買ったり避けたりするかに関する様々な問題や, 提案に関する議論. インストールに関する議論 このメーリングリストは将来のリリースのインストールに関する開発の 議論のためのものです. インターネットサービスプロバイダのについての話題 このメーリングリストは, FreeBSDを用いたインターネット サービスプロバイダ (ISP) に関する話題の議論のためのものです. マルチメディアについての議論 このメーリングリストはFreeBSD上を用いたマルチメディアアプリケーションについてのフォーラムです. マルチメディアアプリケーションをとりまく議論の中心は, それらのインストール, 開発, そしてFreeBSDにおけるサポートについてです. Intel以外のプラットフォームへの移植 クロスプラットフォームのFreeBSDの問題. Intel以外のプラットフォームへのFreeBSDの移植についての一般的な議論や提案. ``ports'' の議論 FreeBSD の ``ports コレクション'' (/usr/ports) や, 移植の提案, ports コレクションの基盤の変更, 一般的な整合化活動についての議論. ユーザからの質問 FreeBSDに関する質問のためののメーリングリストです. その質問がかなり技術的だと思わないのであれば, 「どのようにして」という質問を技術的なメーリングリストに送るべきではありません. ユーザからの質問 freebsd-questionsメーリングリストのダイジェスト版です. このダイジェストはfreebsd-questionsに送られたすべてのメッセージをまとめたものを, 1つのメールにして送り出します. 平均のサイズは約40kbyteです. SCSIサブシステム これはFreeBSDのためのscsiサブシステムについて作業している人向けです. セキュリティの関連の話題 FreeBSDコンピュータのセキュリティの話題 (DES, Kerberos, よく知られている セキュリティホールや, それらのふさぎ方など) セキュリティ関連の通知 FreeBSD のセキュリティ問題や, 修正に関する通知を行ないます. このメーリングリストは議論を行なうためのメーリングリストではありません. 議論は FreeBSD-security で行ないます. ユーザグループの調整のメーリングリスト これは, ローカルなユーザグループがお互いに, または, コアチームが指定した個人と問題を議論する, それぞれのローカルエリアのユーザグループからの調整人向けの メーリングリストです. このメーリングリストはユーザグループ間の ミーティングの概要やプロジェクトの調整に制限されるべきです. Usenet ニュースグループ

2つのFreeBSD用のニュースグループがあります. ここでは FreeBSDの議論をするたくさんの様々な人がおり, 他にもFreeBSD関連するユーザがいます. これらのいくつかのニュースグループは Warren Toomey <wkt@cs.adfa.oz.au> によって で, 検索できるようになっています. BSD用のニュースグループ

関連する他のUnixのニュースグループ

X Window システム

World Wide Web サイト

- 本家のサーバ. - オーストラリア. - ブラジル. - カナダ. - チェコ. - デンマーク. - エストニア. - フィンランド. - ドイツ. - アイルランド. - 日本. - 韓国. - ニュージーランド. - ポルトガル. - スウェーデン. - 台湾. diff --git a/ja_JP.EUC/handbook/esdi.sgml b/ja_JP.EUC/handbook/esdi.sgml index 3e3ca2612a..bca286f33a 100644 --- a/ja_JP.EUC/handbook/esdi.sgml +++ b/ja_JP.EUC/handbook/esdi.sgml @@ -1,418 +1,418 @@ - + ESDIハードディスクの使い方

原作および Copyright © 1995, &a.wilko;.24 September 1995.

訳: &a.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のニュースグループ は, 詳しい情報を得ることができる注目すべきもので す. World Wide Web (WWW) もまた便利な情報源です. Adaptec社の ESDIコントロー ラについては を参照ください. Western Digital社のコントローラについては を参照ください. 感謝

Andrew Gordon氏より, テスト用の Adaptec 2320コントローラと ESDIディス クを送っていただきました. diff --git a/ja_JP.EUC/handbook/firewalls.sgml b/ja_JP.EUC/handbook/firewalls.sgml index d7e63cce10..7a23678d7f 100644 --- a/ja_JP.EUC/handbook/firewalls.sgml +++ b/ja_JP.EUC/handbook/firewalls.sgml @@ -1,579 +1,579 @@ - + ファイアウォール

原作: &a.gpalmer;, &a.alex;.

訳: &a.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 は, カーネル内部にあって パケットのフィルタリングとアカウンティングをおこなうシステムであり, ユーザ側のコントロールユーティリティである ipfw(8) を 含んでいます. ルーティングの決定をおこなう際に, これらは互いに協力して, カーネルで使用されるルールを定義したり, 現在使用されているルールを 問い合わせたりすることができます.

IPFW は互いに関連する二つの部分からなっています. ファイアウォールセクションはパケットフィルタリングをおこないます. また, IP アカウンティングセクションはファイアウォールセクションのものと 似たルールに基づいてルータの使用を追跡します. これにより, (例えば) 特定のマシンからルータへのトラフィックがどのくらい 発生しているか調べたり, どれだけの WWW (World Wide Web) トラフィックが フォワードされているかを知ることができます.

IPFW は, ルータではないマシンにおいても入出力コネクションの パケットフィルタリングのために使用することができるように設計されています. これは一般的な IPFW の使用法とは異なる特別な使い方ですが, こういった状況でも同じコマンドとテクニックが使用されます. FreeBSD で IPFW を有効にする

IPFW システムの中心となる部分はカーネル内部にあります. そのため, どのファシリティ (機能) を必要とするかによって, 一つまたは それ以上のオプションをカーネルコンフィグレーションファイルに追加し, カーネルを再コンパイルする必要があるでしょう. カーネルの再コンパイル方法の詳細については, を参照してください.

現在, IPFW に関係するカーネルコンフィグレーションオプションは 三つあります: syslogd(8) を通じて パケットのログを取るためのコードを有効にします. フィルタルールでパケットのログを取るように指定しても, このオプションが指定されていなければ, ログを取ることはできません. syslogd(8) を通じて ログを取るパケットの数をエントリ毎に制限します. 敵対的な環境においてファイアウォールの動作のログを取りたいけれど, syslog の洪水によるサービス拒絶攻撃に対し無防備でありたくないという場合に, このオプションを使用したいと思うことがあるかもしれません.

チェーンエントリのログが指定された制限数に達すると, そのエントリに関するログ取りは停止されます. ログ取りを再開するには, ipfw(8) ユーティリティを使用して 関連するカウンタをリセットする必要があります: ipfw zero 4500 4500 とは, ログ取りを続行したいチェーンエントリの番号です. 以前のバージョンの FreeBSD は IPFIREWALL_ACCT というオプションを 持っていました. しかし, ファイアウォールコードがアカウンティングファシリティ (機能) を 自動的に含むようになったため, 現在では使用されることはなくなっています. IPFW の設定

IPFW ソフトウェアの設定は ipfw(8) ユーティリティを 通じておこないます. このコマンドの構文は非常に複雑に見えますが, 一旦その構造を理解すれば比較的単純です.

このユーティリティでは今のところ四つの異なるコマンドカテゴリが 使用されています: それは追加 / 削除, 表示, フラッシュ, およびクリアです. 追加 / 削除はパケットの受け入れ, 拒絶, ログ取りをどのようにおこなうか というルールを構築するのに使用します. 表示はルールリスト (またはチェーン) と (アカウンティング用) パケットカウンタの 内容を調べるのに使用します. フラッシュはチェーンからすべてのエントリを取り除くのに使用します. クリアは一つまたはそれ以上のアカウンティングエントリをゼロにするのに 使用します. IPFW ルールの変更

この形式での使用法は: ipfw [-N] コマンド [index] アクション [log] プロトコル アドレス [ オプション ]

この形式で使用する際に有効なフラグは一つだけです: コマンド は一意である限り短縮可能です. 有効な コマンド は: 以前のバージョンの IPFW では, ファイアウォールエントリと パケットアカウンティングエントリが別々に利用されていました. 現在のバージョンでは, それぞれのファイアウォールエントリ毎に パケットアカウンティングエントリが備えられています.

index が指定されていると, エントリはチェーン中の index で示される位置に置かれます. index が指定されて いなければ, エントリは (65535 番のデフォルトルールである パケット拒絶を別にして) 最後のチェーンエントリの index に 100 を足した 位置 (チェーンの最後) に置かれます.

カーネルが IPFIREWALL_VERBOSE つきでコンパイルされている場合, log オプションはマッチしたルールをシステムコンソールに出力させます.

有効な アクション は: pass および accept)

それぞれの アクション は一意な先頭部分だけでも認識されます. 指定可能な プロトコル は以下の通り:

アドレス の指定は: from <address/mask>[port] to <address/mask>[port&rsqb [via <interface>]

port はポートをサポートする プロトコル (UDP と TCP) の 場合にだけ指定可能です.

via は必須ではなく, 特定のインターフェースを通ってきたパケット だけにマッチするように, IP アドレスまたはローカル IP インターフェースの ドメイン名, またはインターフェース名 (例えば ed0) を 指定することができます. インターフェースユニット番号はオプションで, ワイルドカードで指定することが できます. 例えば, ppp* はすべてのカーネル PPP インターフェースに マッチします.

<address/mask> の指定は: <address> または <address>/mask-bits または <address>:mask-pattern

IP アドレスのかわりに有効なホスト名を指定することも可能です. mask-bits はアドレスマスクで上位何ビットを１にするべきかを 示す十進数値です. 例えば次の指定, 192.216.222.1/24 はクラス C のサブネット (この場合 192.216.222) の任意のアドレスにマッチする マスクを作成します. mask-pattern は与えられたアドレスと 論理 AND される IP アドレスです. キーワード any は「任意の IP アドレス」を指定するために 使用することができます.

ブロックするポート番号は以下のように指定します: port[,port[,port[...]]] のように単独のポートまたはポートのリストを指定します. または port-port のようにポートの範囲を指定します. 単独のポートとポートのリストを 組み合わせて指定することも可能ですが, その場合は常に範囲の方を 最初に指定しなければなりません.

使用可能な オプション は: spec/IP ヘッダが spec に指定された カンマで区切られたオプションのリストを含んでいればマッチします. サポートされている IP オプションのリストは: ssrr (ストリクトソースルート), lsrr (ルーズソースルート), rr (レコードパケットルート), そして ts (タイムスタンプ) です. 特定のオプションを含まないことを指定するには '!' を先頭につけます. established ルールをチェーンの最初の方に置くことで, ファイアウォールのパフォーマンスを向上させることができます. flags/TCP ヘッダが flags に指定された カンマで区切られたフラグのリストを含んでいればマッチします. サポートされているフラグは, fin, syn, rst, psh, ack と urg です. 特定のフラグを含まないことを指定するには '!' を先頭につけます. types/ICMP タイプが types リストに 存在していればマッチします. リストはタイプの範囲または個々のタイプを カンマで区切った任意の組合せで指定できます. 一般的に使用されている ICMP タイプは: 0 エコーリプライ (ping リプライ), 5 リダイレクト, 8 エコーリクエスト (ping リクエスト), そして 11 時間超過 (traceroute(8) で使用されているように, TTL 満了を示すのに使用されます) です. IPFW ルールリストの表示

この形式での使用法は: ipfw [-atN] l

この形式で使用する際に有効なフラグは三つあります: ipfw(8) ユーティリティで使用される入力形式と 互換性がありません. IPFW ルールのフラッシュ

チェーンをフラッシュするには: ipfw flush

カーネルに固定されているデフォルトルール (インデックス 65535 番) 以外の, ファイアウォールチェーンの中のすべてのエントリを削除します. デフォルトではすべてのパケットが拒絶されるので, 一旦これを実行すると, パケットを許可するエントリがチェーンに追加されるまで, あなたのシステムがネットワークから切り放されてしまいます. そのため, ルールのフラッシュをおこなうときは注意が必要です. IPFW パケットカウンタのクリア

一つまたはそれ以上のパケットカウンタをクリアするためには: ipfw zero [index]

index が指定されていなければ, すべてのパケットカウンタが クリアされます. index が指定されていれば, 特定のチェーンエントリだけが クリアされます. ipfw に対するコマンドの例

このコマンドはルータを介して転送される, ホスト evil.hacker.org から ホスト nice.people.org の telnet ポートへの すべてのパケットを拒絶します: ipfw add deny tcp from evil.hacker.org to nice.people.org 23

次の例は, ネットワーク hacker.org (クラス C) 全体から マシン nice.people.org (の任意のポート) への 任意の TCP トラフィックを拒絶し, ログを取ります. ipfw add deny log tcp from evil.hacker.org/24 to nice.people.org あなたの内部ネットワーク (クラス C のサブネット) に対する X セッションを 張れないようにする場合, 以下のコマンドで必要なフィルタリングがおこなえます: ipfw add deny from any to my.org/28 6000 setup sup.FreeBSD.ORG の SUP サーバへのアクセスを許可するためには, 以下のコマンドを使用します: ipfw add accept from any to sup.FreeBSD.ORG 871 アカウンティングレコードを見るには: ipfw -a list または短縮形式で ipfw -a l 最後にチェーンエントリがマッチした時刻を見ることもできます. ipfw -at l パケットフィルタリングファイアウォールの構築

注: 以下の提案は, ただの提案にすぎません: 必要な処理はそれぞれのファイアウォールで異なるため, あなた独自の要求にあったファイアウォールを構築する方法を ここで述べることはできないのです.

最初にファイアウォールをセットアップするとき, コントロールされた環境でファイアウォールホストの設定がおこなえるような テストベンチセットアップが用意できない場合には, カーネルのログ取りを 有効にしてログ取り版のコマンドを使用することを強くおすすめします. そうすることで, 大した混乱や中断なしに問題となる範囲の特定と処置を 素早くおこなうことができます. 初期セットアップフェーズが完了してからであっても, アタックの可能性のあるアクセスをトレースしたり, 要求の変化に応じてファイアウォールルールを変更したりできるので, `deny' に対するログ取りをおこなうことをおすすめします. 注: accept コマンドのログ取りをおこなっていると, ファイアウォールをパケットが一つ通過する毎に 1 行のログが生成されるため 大量の ログデータが発生します. そのため, 大規模な ftp/http 転送などをおこなうと, システムが非常に 遅くなってしまいます. また, パケットが通過するまでにカーネルにより多くの仕事を要求するため, パケットのレイテンシ (latency) を増加させてしまいます. syslogd もログをディスクに記録するなど, より多くの CPU タイムを 使用し始め, 実に容易に /var/log が置かれているパーティションを パンクさせてしまう可能性があります.

現状では, FreeBSD はブート時にファイアウォールルールをロードする 能力を持っていません. 私は /etc/netstart スクリプトにロードをおこなうスクリプトを 追加することをおすすめします. IP インターフェースの設定がおこなわれる前に ファイアウォールの設定がおこなわれるように, netstart ファイル中の 充分に早い位置にルールをロードするスクリプトを配置してください. こうすることで, ネットワークがオープンな間は常に抜け道が塞がれている ことになります.

ルールをロードするために使用するスクリプトは, あなたが作成しなければなりません. 現在のところ ipfw は 1 コマンドで複数のルールを ロードするユーティリティをサポートしていません. 私が使用しているシステムでは以下のようにしています: # ipfw list ファイルに現在のルールリストを出力し, テキストエディタを使用して すべての行の前に ``ipfw '' と書き足します. こうすることで, このスクリプトを /bin/sh に与えてルールをカーネルに再読み込み させることができます. これは最も効率的な方法とはいえないかもしれませんが, きちんと動作しています.

次の問題は, ファイアウォールが実際には何を する べきかです ! これは外部からそのネットワークへのどんなアクセスを許したいか, また内部から外界へのアクセスをどのくらい許したいかに大きく依存します. いくつか一般的なルールを挙げると: 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 から 入手可能です.

前にも述べたように, これはただの ガイドライン にすぎません. ファイアウォールでどのようなフィルタルールを使用するかは, あなた自身が 決めなければなりません. これまでのアドバイスにしたがったにも関わらず, 誰かがあなたのネットワークに 侵入してきたとしても, 私は「いかなる」責任もとることはできません. diff --git a/ja_JP.EUC/handbook/glossary.sgml b/ja_JP.EUC/handbook/glossary.sgml index 93c3ae447e..723ae56e6c 100644 --- a/ja_JP.EUC/handbook/glossary.sgml +++ b/ja_JP.EUC/handbook/glossary.sgml @@ -1,6 +1,6 @@ - + * Glossary diff --git a/ja_JP.EUC/handbook/goals.sgml b/ja_JP.EUC/handbook/goals.sgml index add43951b1..5719183960 100644 --- a/ja_JP.EUC/handbook/goals.sgml +++ b/ja_JP.EUC/handbook/goals.sgml @@ -1,33 +1,33 @@ - + FreeBSDプロジェクトの目的

原作: &a.jkh;

訳: &a.kiroh;24 September 1996.

FreeBSDプロジェクトの目的は、いかなる用途にも使用でき、何ら制限のない ソフトウェアを供給することです。私たちの多くは、コード(そしてプロジェ クト)に対してかなりの投資をしてきており、これからも多少の無駄はあって も投資を続けて行くつもりです。ただ、他の人達にも同じような負担をするよ うに主張しているわけではありません。FreeBSD に興味を持っている一人の残 らず全ての人々に、目的を限定しないでコードを提供すること。これが、私た ちの最初のそして最大の``任務''であると信じています。そうすれば、コード は可能な限り広く使われ、最大の恩恵をもたらすことができるでしょう。これ が、私たちが熱烈に支持しているフリーソフトウェアの最も基本的な目的であ ると、私は信じています。

私たちのソースツリーに含まれるソースのうち、GNU一般公有使用許諾(GPL)ま たはGNUライブラリ一般公有使用許諾(GLPL)に従っているものについては、多 少制限が科されています。ただし、ソースコードへのアクセスの保証という、 一般の制限とはいわば逆の制限(訳注1)です。ただしGPLソフトウェアを商用で 利用する場合、さらに複雑になるのは避けられません。そのため、それらのソ フトウェアを、より制限の少ないBSD著作権に従ったソフトウェアで置き換え る努力を、可能な限り日々続けています。

(訳注1) GPL では、「ソースコードを実際に受け取るか、あるいは、希望しさ えすればそれを入手することが可能であること」を求めています。 diff --git a/ja_JP.EUC/handbook/handbook.sgml b/ja_JP.EUC/handbook/handbook.sgml index 4067da52cf..22cd1f057c 100644 --- a/ja_JP.EUC/handbook/handbook.sgml +++ b/ja_JP.EUC/handbook/handbook.sgml @@ -1,185 +1,185 @@ - + %authors; %jmembers; %lists; %sections; ]> FreeBSD ハンドブック FreeBSD ドキュメンテーションプロジェクト 1996年12月 FreeBSD へようこそ! このハンドブックはFreeBSD Release &rel.current;のインストールおよび, 日常での使い方について記述したもので, FreeBSD ドキュメンテーションプロジェクトによって編集されています. 日本語版の作成は FreeBSD 日本語ドキュメンテーションプロジェクトがおこなって います. 本書は現在進行中の作業であって, 多くの個人の手からなる 仕事です. 多くのセクションはまだ存在しませんし, いま存在するセクションの いくつかはアップデートが必要です. この FreeBSD ドキュメンテーション プロジェクトに協力したいと思ったら, &a.doc; まで (英語で) 電子メールを 送ってください. ハンドブックそのものに関する議論は, こちらで おこなわれています. (もちろん英語でです.) 日本語訳および, 日本語版のみに関することは &a.doc-jp; において日本語で 議論されています. 必要に応じて日本語ドキュメンテーションプロジェクトから 本家ドキュメンテーションプロジェクトに対してフィードバックをおこないますので, 英語が得意でない方は &a.doc-jp; まで日本語でコメントをお寄せください. このドキュメントの最新バージョンは, いつでも や から入手できますし, や, たくさんあるからプレインテキスト, postscript, HTML などの形式でダウンロードすることもできます. また, も可能です. 基礎 はじめに

FreeBSD は, Intel アーキテクチャ (x86) ベースの PC のための 4.4BSD-Lite をベースとしたオペレーティングシステムです. FreeBSD の概要については, をご覧ください. このプロジェクトの歴史については, をご覧ください. 最新のリリースについての記述は, をご覧ください. FreeBSD プロジェクトへの何らかの貢献 (ソースコード, 機器, 資金の提供など) について興味があれば, の章をご覧ください. &nutshell; &history; &goals; &development; &relnotes; &install; &basics; アプリケーションのインストール * パッケージのインストール &ports; システム管理 &kernelconfig; ユーザ, グループ, セキュリティ &crypt; &skey; &kerberos; &firewalls; &printing; "as; X ウィンドウシステム

この節の完成は保留にしてあります. から提供されるドキュメントを参考にしてください. &hw; ネットワーク通信 シリアル通信 &serial; &term; &dialup; &dialout; PPP と SLIP

もしあなたがモデムを使ってインターネットに接続したり, 他の人々に FreeBSD によるインターネットへのダイヤルアップ接続を 提供しようとしているのでしたら, PPP または SLIP 接続を選択することができます. PPP 接続には, 2 種類の方法が提供されています: ユーザPPP (iijppp とも呼ばれます) とカーネルPPP です. 両方の PPP の設定手順と, SLIP の設定方法については以下の章に書かれています. &userppp; &ppp; &slipc; &slips; 高度なネットワーク &routing; &nfs; &diskless; * イエローページ/NIS &isdn; &mail; さらに進んだ話題 ¤t; &stable; &synching; &submitters; &troubleshooting; &kerneldebug; &kernelopts; &linuxemu; FreeBSD の内部 &booting; &memoryuse; &dma; 付録 &mirrors; &bibliography; &eresources; &contrib; &policies; &pgpkeys; &jcontrib; diff --git a/ja_JP.EUC/handbook/history.sgml b/ja_JP.EUC/handbook/history.sgml index 5d764ab13a..f4ecd301ed 100644 --- a/ja_JP.EUC/handbook/history.sgml +++ b/ja_JP.EUC/handbook/history.sgml @@ -1,103 +1,103 @@ - + FreeBSD 小史

原作: &a.jkh;.

訳: &a.masaki;, &a.hino;.19 December 1996. FreeBSD プロジェクトは 1993年の始めに ``Unofficial 386BSD Patchkit'' の最後の 3人のまとめ役によって, 部分的に patchkit から派生する形で開始 されました. ここでの 3人のまとめ役というのは, Nate Williams と, Rod Grimes と, 私 (Jordan K. Hubbard) です. 私たちのもともとの目標は, patchkit という仕組みではもう十分に解 決できなくなってしまった 386BSD の数多くの問題を修正するための, 386BSD の暫定的なスナップショットを作成することでした. こういった経緯を経てい るので, このプロジェクトの初期の頃の名前が ``386BSD 0.5'' や ``386BSD 暫定版 (Interim)'' であったということを覚えている人もいるでしょう. 386BSD は, Bill Jolitz が (訳注: バークレイ Net/2 テープを基に) 作成し たオペレーティングシステムです. 当時の 386BSD は, ほぼ一年にわたって放っ ておかれていた (訳注: 作者がバグの報告を受けても何もしなかった) という ひどい状況に苦しんでいました. 作者の代わりに問題を修正し続けていた patchkit は日を追うごとに不快なまでに膨張してしまっていました. このよ うな状況に対して, このままではいけない, 何か行動を起こさなければ, とい うことで異議を唱えるものは私たちのなかにはいませんでした. そして私たち は挑戦することを決断し, 暫定的な「クリーンアップ」スナップショットを作 成することで Bill を手助けしようと決めたのです. しかし, この計画は唐突 に終了してしまいました. Bill Jolitz が, このプロジェクトに対する受け 入れ支持を取り下げることを突然決意し, なおかつこのプロジェクトの代わり に何をするのかを一切言明しなかったのです. たとえ Bill が支持してくれないとしても, われわれの目標には依然としてや る価値があると決心するのにさしたる時間はかかりませんでした. そこで David Greenman が考案した名称 ``FreeBSD'' を私たちのプロジェクトの名前 に採用し, 新たなスタートを切りました. この時点でのプロジェクトの初期目 標は, すでにこのシステム (訳注: 386BSD + Patchkit) を使っていた利用者 たちと相談して決められました. プロジェクトが実現に向けて軌道に乗ってき たことが明確になった時点で, 私は Walnut Creek CDROM 社に連絡してみまし た. CDROM を使って FreeBSD を配布することによって, インターネットに容 易に接続できない多くの人々が FreeBSD を簡単に入手できるようになると考 えたからです. Walnut Creek CDROM 社は FreeBSD を CD で配布するというア イデアを採用してくれたばかりか, 作業するためのマシンと高速なインターネッ ト回線を私たちのプロジェクトに提供してくれました. 当時は海のものとも山 のものともわからなかった私たちのプロジェクトに対して, Walnut Creek CDROM 社が信じられないほどの信頼を寄せてくれたおかげで, FreeBSD は短期 間のうちにここまで大きく成長したのです. CDROM による最初の配布 (そしてネットでの, ベータ版ではない最初の一般向 け配布) は FreeBSD 1.0 で, 1993年 12月に公開されました. これは カリフォ ルニア大学バークレイ校の 4.3BSD-Lite (``Net/2'') を基とし, 386BSD や Free Software Foundation からも多くの部分を取り入れたものです. これは 初めて公開したものとしては十分に成功しました. 続けて 1994年 5月に FreeBSD 1.1 を公開し, 非常に大きな成功を収めました. この時期, あまり予想していなかった嵐が遠くから接近してきていました. バー クレイ Net/2 テープの法的な位置づけについて, Novell 社と カリフォルニ ア大学バークレイ校との間の長期にわたる法廷論争において和解が成立したの です. 和解の内容は, Net/2 のかなりの部分が「権利つき (encumbered)」コー ドであり, それは Novell 社の所有物である, というバークレイ校側が譲歩し たものでした. なお, Novell 社はこれらの権利を裁判が始まる少し前に AT&T 社から買収していました. 和解における譲歩の見返りにバークレイ 校が得たのは, 4.4BSD-Lite が最終的に発表された時点で, 4.4BSD-Lite は権 利つきではないと公式に宣言されること, そしてすべての既存の Net/2 の利 用者が 4.4BSD-Lite の利用へと移行することが強く奨励されること, という Novell 社からの「ありがたき天からの恵み」でした. (訳注: 4.4BSD-Lite は その後 Novell 社のチェックを受けてから公開された.) FreeBSD も Net/2 を利 用していましたから, 1994年の 7月の終わりまでに Net/2 ベースの FreeBSD の出荷を停止するように言われました. ただし, このときの合意によって, 私 たちは締め切りまでに一回だけ最後の公開をすることを許されました. そして それは FreeBSD 1.1.5.1 となりました. それから FreeBSD プロジェクトは, まっさらでかなり不完全な 4.4BSD-Lite を基に, 文字どおり一から再度作り直すという, 難しくて大変な作業の準備を始めまし た. ``Lite'' バージョンは, 部分的には本当に軽くて, 中身がなかったので す. 起動し, 動作できるシステムを実際に作り上げるために必要となるプログ ラムコードのかなりの部分がバークレイ校 の CSRG (訳注: BSDを作っている グループ) によって (いろいろな法的要求のせいで) 削除されてしまっていた ということと, 4.4BSD の Intel アーキテクチャ対応が元々かなり不完全であっ たということがその理由です. この移行作業は結局 1994年の 12月までかかり ました. そして 1995年の 1月に FreeBSD 2.0 をネットと CDROM を通じて公 開しました. これは, かなり粗削りなところが残っていたにもかかわらず, か なりの成功を収めました. そしてその後に, より信頼性が高く, そしてインス トールが簡単になった FreeBSD 2.0.5 が 1995年の 6月に公開されました. これからのことについて 私たちは 1996年の 8月に FreeBSD 2.1.5 を公開しました. この出来が非常に 良く, 特に業務で運用しているサイトやISPでの人気が高かったので, 2.1-STABLE 開発分流からもう一回, 最後の公開を行なうことにメリットがあ ると考えました. それが FreeBSD 2.1.6 で, 2.1-STABLE 開発分流の最後を締 めくくるものとして, 1996年の 12月に公開されました. 2.1-STABLE 開発分流 は現在, 保守のみを行なう状態になっており, 今後は, セキュリティの改善や 他の何か重要なバグフィックスのみが行なわれるでしょう. FreeBSD 2.2 は現在, 公開へ向けた開発分流となっていて, 1997年 1月のデビュー に向けて開発が進められています. SMP のサポートから DEC ALPHA のサポー トまでのすべての長期的なプロジェクトは, 1996年 10月に 2.2 の開発分流か ら分岐した 3.0-CURRENT 開発分流において継続しています. 3.0 のスナップ ショットの公開は, 1997年のはやいうちに再開することが予定されています. diff --git a/ja_JP.EUC/handbook/hw.sgml b/ja_JP.EUC/handbook/hw.sgml index 117bded7aa..d72b0b884d 100644 --- a/ja_JP.EUC/handbook/hw.sgml +++ b/ja_JP.EUC/handbook/hw.sgml @@ -1,1523 +1,1523 @@ - + PC ハードウェアコンパチビリティ

訳: &a.yoshiaki; . 5 December 1996.

ハードウェアコンパチビリティの問題は現在のコンピュータ業界でもっ とも多く起きる種類の問題であり, FreeBSDもこれに無縁ではありません. 市場にある驚くほど多様な種類の製品をサポートしたことで,安価に普及し ている PCハードウェアで動かすことができるという FreeBSDの利点はこの 点では不利でもあります. FreeBSDのサポートするハードウェアを徹底的に調べて提供することは不 可能ですが, このセクションでは FreeBSDに含まれるデバイスドライバとそ のドライバがサポートするハードウェアのカタログを示します. 可能で適切 なものについては特定の製品についての注釈を含めました. FreeBSD はボランティアプロジェクトでテスト部門には資金がありません から, より多くの情報をこのカタログに載せるにはあなたがたユーザに 頼らなければなりません. あなた自身の経験により, あるハードウェアが FreeBSDで動くか動かないかがわかったとしたら&a.doc; へ e-mailして知らせてください. サポートされているハードウェアについて の質問は, &a.questions;(詳しいことは を参照してください) へ 宛ててください. 情報を提供したり質問をする時は FreeBSDのバージョンと使っ ているハードウェアのできるだけ詳しい情報を含めることを忘れないでくだ さい. インターネット上のリソース

以下のリンクはハードウェアを選ぶのに役に立ちます. FreeBSDに対して は必要のない (あるいは適用できない) ように見えるかもしれませんが, ここ からのハードウェアの情報のほとんどは OSに依存しないものです. 購入をする前にはあなたの選んだものがサポートされているか FreeBSDハード ウェアガイドを注意して読んでください.

訳注: 日本国内でFreeBSDの動くハードウェアの情報を提供してい るWWWサーバがあります. これ以外にも情報を提供しているサーバはあります. いくつかの URLについて は からたどることができます. 組合せの見本

以下のハードウェアの組合せのサンプルリストはハードウェアベンダや FreeBSD プロジェクトが保証するものではありません. この情 報は公共の利益のために公開しているものであり, 極めて数多くあるであろう 異なったハードウェアの組合せの中からのある経験のカタログに過ぎません. やり方はいろいろあります. 場合によってはうまく行かないこともあります. 十分気をつけてください. Jordan氏の選んだ組合せ

私の作ったワークステーションとサーバの構成はまずまずうまく行っ ています. 私はこれを保証できるわけでもありませんし, ここにあげた組 合せがずっと "best buys"であるわけではありません. 私はできればリス トを更新して行きますがそれがいつになるかはわかりません. 訳注: &a.jkh; 氏は FreeBSDプロジェクトのメンバです. マザーボード

はミッドレンジからハイエンドの Pentiumサーバやワークステーションシステムに はよい選択のようですが, より新しい 430HX (Triton-II) のボード (以下を参照してください) にほとんど置き換えられました. これらのボードを買うならば を使うといいでしょ う. 486クラスのマザーボードを探しているなら ASUSの を調べてみることをおすすめします (注: ASUSはこれら を既に製造していないのは明らかなのでこれらのものはだんだん手に入 りにくくなっています). 訳注: 96年10月現在 上で述べられているボードは日本でも手に入りにくい部類 になっているようです. 注: Intel チップセットベースのマザーボードでは メモリパリティチェック機能が提供されませんので, メモリエラーが起きても検出が不可能です. フォルトトレラントなシステムを構築したい場合には, より新しい 430HX (Triton II) ベースのマザーボードを買うことをおすすめしま す. こちらはよりよい性能, パリティチェックと ECC機能を提供してくれます. ECCを使うのであれば 82439HX Triton-II チップセットの A2以降のリビジョ ンを使ったマザーボードが必要です. 82371SBのリビジョンと混乱しないでくださ い - リビジョンがA2であれば 82439HXチップに "SU102"とマークされています. リビジョンがA1であれば Sで始まる番号はマークされていない, あるいは "SU087"とマークされています.

ハイエンドにおいては FreeBSDでは 200MHzの P6 (Pentium Pro) CPUを 使ったIntel/Venus Pro () マザーボー ドが非常によいようです. 最近の価格の下落 (急落と言った方がいいでしょ うか) で最近の米国内では P6システムは十分購入の候補になる程度に価格 が下がっています. また, 本格的なサーバ用途には Pentium Pro を考えて いいでしょう. 注: Intel のマザーボードは従来とは異る形状で, "ATX" ケースデザイン と呼ばれる従来とはまったく異る PCケースが必要になっています. 今あるシステムをアップグレードしようと考えているならこのことを十分 考えましょう - 私のこれまでに知る限りでは, 現在入手可能な ATXケース はすべて 「ミドルタワー (midi-tower)」で, ドライブなどの内蔵周辺機器 を格納するスペースに制限があります. 利点としては, ほとんどの ATXケー スは一般的な PCケースに比較して非常に品質の高いもののようであるとい うことがあります. ディスクコントローラ

これはいくらかトリッキーです. 私は ISAから PCIまですべてコンパチブ ルな コント ローラを使うようにすすめていましたが, 現在では ISAでは 1542CF, EISA では Bt747c, PCIでは Adaptec 2940 をすすめるよう変わってきています.

PCIマシンで2つ以上の SCSIコントローラが必要となるのであれば, PCIバスの不足を防ぐために Adaptec 3940 カードを考えてもいいでしょ う. これは1つのスロットで2台の SCSIコントローラ(と内部バス)を持ち ます. ディスクドライブ

私は,極々特殊な状況を除いて 「それだけのお金をかけることができる なら SCSIは IDEよりもよい」 と言っています. 小規模なデスクトップ構成 のシステムでも, SCSIであればディスクが安くなっていった時にサーバの (古い入れ換えた) ディスクを比較的簡単に移し替えることができます. あ なたが複数のマシンの管理をしているのであれば単純に容量について考え るのではなく, 食物連鎖のように考えましょう.

私は今のところは NFSサーバや NEWSサーバのようにマルチユーザに よる激しいディスク disk I/Oがおこなわれる用途以外ではお金をかけてま で SCSI WIDEドライブにする必要はないと考えています. CDROM ドライブ

私は SCSIの方が好みであるのでもちろん SCSI CDROMを選びました. XM-3501B (現 在はキャディレスモデルの XM-5401Bがリリースされています)ドライブは どんな時もうまく動いてくれていますが, 最近は の 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ドライブ (私は これらすべては結局は Philips社のドライブであるのではない かと考えているのですが) をサポートしています : Philips CDD 522 (Plasmon のドライブと同様の動作をします), PLASMON RF4100, HP 4020i です. 私は HP 4020i を CDROMを焼くのに使っています(2.2-current で 使っています - 2.1.5以前のリリースの SCSIコードでは動きません). 非常に調子よく動いています. 2.2 システムの を見てください. ISO9660ファイルシステムイメージ (RockRidge拡張) を作 るスクリプトと それをHP4020i CDR で焼くためのスクリプトの例があり ます. テープドライブ

私はたまたま の と の を持っています.

バックアップのためであれば, より本質的に丈夫な (また, より容量が大きい) Exabyteの 8mmテープの方がおすすめできます. ビデオカード

もし (米国では) 99USドルをかけて商品の Xサーバをから買うことができる なら間違いなく カードをおすすめします. フリーの Xサーバを使いたいの であれば の S3 Vision 868と 968 ベースのカード (the 9FX series) はわりあいと速く, の S3サーバで サポートされており, きっと問題も起きないでしょう. モニタ

私の持っている 非常に調子がいいので, 同じ (トリ ニトロン) ブラウン管を使っている Viewsonicをおすすめします. 17"よりも 大きなモニタ, 例えば 21"のモニタが実際に必要だとしたらこの文章の執 筆時点では 2,500USドル以下のものはまったくすすめられません. 20"以上のク ラスでよいモニタは(いくつも)ありますし, 20"クラスで安いモニタもあり ます. うまくいかないことに安くてよいモニタはありません!! ネットワーキング

私は ISAカードでは Ultra 16 コントローラを, PCIベースのカードでは SMC EtherPower と Compex ENET32カードをおすすめできます. この2種類の PCI カードは DECの DC21041イーサネットコントローラチップを使っています. また, このチップを使っている Zynx ZX342 や DEC DE435 などのカードも 一般的にはうまく動くでしょう. 100Mbit/sec のネットワークカードで は SMC SMC9332DST 10/100MB や Intel EtherExpress Pro/100B カードは 利用できるでしょう. もう一方, できるだけ低コストでそこその性能で動くものを探しているな ら, ほとんどの NE2000のクローンはよい選択です. (特殊な) シリアル

高速のシリアル ネットワーク インタフェース (同期シリアルカード) を探しているのであれば 製の シリーズのド ライバが今の FreeBSD-currentにあります. も 提供 するソフトウェアにより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がサポー トするいう点では の製品が最も信頼できるでしょう. この最大の理由はこ の会社が私たちに十分な評価用ボードとスペックを供給することを約束し てくれているからです. 私は Cyclom-16Y が最高の性能価格比であると聞 いていましたが最近は価格のチェックはしていません. 訳注: cycladesの WWWサーバでも Supported Operating Systemsに Linuxや BSDi, FreeBSD が明記されています. 他のマルチポートカードで評判がよいのは BOCAおよび ASTのカードと で, このカードには で非公式なドライバが提供されてい るようです. オーディオ

私は現在,高音質で全二重のオーディオ機能 (2DMAチャネル) を持つという 点から Ultrasound MAX を使っています. Windows NTや OS/2でのサポートはあま りよくありませんので, FreeBSD, NT, OS/2のすべてで使うには推薦できま せん. そのような場合には の AWE32 がいいでしょう. ビデオキャプチャー

ビデオキャプチャーについては事実上一つしか選択の余地がありません. カードです. FreeBSDはクリエィティブ ラボの古い video spigotカードの サポートはしていますがこれは手に入りにくくなっていますし, Meteor は 高速のPCIインタフェースを持った新しい世代の画像取り込みボードです. 私はこれを MBONEのビデオ放送に使っていますが, 非常にうまく動いていま す!! 中心部/プロセッサ マザーボード, バス, チップセット * ISA * EISA * VLB PCI

原作: &a.rgrimes;.25 April 1995.

更新: &a.jkh;.最終更新 26 August 1996.

訳: &a.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の公式の回答は 430FX チップセットへの 移行で, 「こちらでは修整した」ということです. 430FX (Triton I): 知られている キャッシュコヒーレンシ やバスマスタの問題はありませんがパリティチェック機能が ありません. パリティを使いたいような場合は, 可能であ れば 430HX (Triton-II) ベースのマザーボードを選びましょう. 430HX (Triton-II): このチップセット を使っているマザーボードに関するすべての報告によれば今の ところ好評です. しかし ECCメモリを利用するのであれば 82439HX チップの A2以降のリビジョンを手 にいれるように注意して下さい. 82371SBのリビジョンと混乱 しないでください - リビジョンがA2であれば 82439HXチップ に "SU102"とマークされています. リビジョンがA1であれば S で始まる番号はマークされていない, あるいは "SU087"とマー クされています. 430VX (誤って Triton-IIIと呼ばれることもあります) : 430VX は 430HXとは異るローコストの設計で, ビデオカード が自身のボード上のメモリの替りにメインメモリを使うこと ができるように設計されています. またメモリ空間は 128MB に制限されますが SDRAMのサポートが加えられています. しかし, 64MB以上のメモリについてはキャッシュされません. 450KX (Orion): このチップセットの初期 のバージョンでは PCI write-posting にバグがあり, 大量の PCIバストラフィッ クのあるアプリケーションでは性能の著しい低下があるとい う障害がありました. B0以降のリビジョンのチップセットで は問題はいくらか解決され, C0以降では完全に解決されて います. (Natoma):これは に対応したチップセットで, 初期の Orionチップセットにあったような問題は見られず, 問題なく動 いているようです. また, これは ECCやパリティを含んだ広い 種類のメモリに対応しています.

CPU/FPU * Pentium Pro クラス Pentium クラス クロックスピード

原作 &a.rgrimes;.1 October 1996.

Pentium クラスのマシンはシステムのいくつかの部分で異なったク ロックスピードを使っています. これは CPU, 外部メモリバス, PCI バスです. 別々のクロックスピードが使われるために 「高速な」 CPUを使ったシステムが 「低速な」システムよりも必ず しも速いとは限りません. それぞれの場合の違いを以下の表に示します.

CPUクロック 外部クロック 外部クロックと PCIバス とメモリバス 内部クロック クロック MHZ MHZ** の比 MHZ 60 60 1.0 30 66 66 1.0 33 75 50 1.5 25 90 60 1.5 30 100 50* 2 25 100 66 1.5 33 120 60 2 30 133 66 2 33 150 60 2.5 30 166 66 2.5 33 180 60 3 30 200 66 3 33 * Pentium 100 は 50MHzの外部クロックの 2倍または 66MHz の 1.5倍の両方で動かすことができます. ** 66 Mhz はおそらく実際には 66.667 MHzでしょう. しかし, そうだと決めつけてはいけません.

3倍クロックの CPUではメモリアクセス速度が不足気味であるとい う点を考えなければ 100, 133, 166, 200 MHzを使うのが最良でしょ う.

AMD K5 CPU は内部クロックではなく AMDが "PR" -- Pentium Rating とよんでいる評価値で表されます. したがって AMD PR133 のチップ は Intel Pentium 133 と同等です. 実際にはこの CPUは内部 100MHz, バス 66 MHz, クロック倍率 1.5 倍で動いています. * 486 クラス * 386 クラス 286 クラス

残念ながら, FreeBSDは 80286マシンでは動きません. 現在の巨大なフ ルスペックの UNIXをこのようなハードウェアで動かすことはほとんど 不可能でしょう. 上記の内容に加え, には FreeBSDをいろいろな CPUで動かし た場合の詳細な記述があります. メモリ

FreeBSDをインストールするのに最低限必要なメモリ量は 8 MBです. いったんシステムが起動してことができるならば, もっと少ないメモリ で動かすこともできます. FreeBSD 2.1, 2.1.5, 2.1.6 では必要なメモリ の最小値は 5MBです. boot4.flp を使えば 4 MB しかメモリがなくてもインストールできます.

いろいろなタイプのメモリについての詳細な記述が . にあります. * BIOS 入力/出力デバイス * ビデオカード * サウンドカード シリアルポートとマルチポートカード &uart; &sio; &cy; * パラレルカード * モデム * ネットワークカード * キーボード * マウス * その他 記憶装置 &esdi; &scsi; * ディスク/テープ コントローラ * SCSI * IDE * フロッピー * ハードディスクドライブ テープドライブ

原作: &a.jmb;.2 July 1996.

訳: &a.yoshiaki;.13 October 1996.

一般的なテープアクセスコマンド

mt(1) はテープドライブへの一般的なアクセス方法を提 供します. rewind, erase, statusなど の共通コマンドがあります. マニュアルページの mt(1)を見 てください. より詳しい解説があります. コントローラインタフェース

テープドライブにはいくつかの異なったインタフェースがあり ます. SCSI, IDE, フロッピー, パラレルポートのインタフェース です. 非常に多くの種類のテープドライブがこれらのインタフェー スで使えます. コントローラについての議論はにあります(訳注:現在未完成です). SCSI ドライブ

st(4) ドライバは 8mm (Exabyte), 4mm (DAT: Digital Audio Tape), QIC (1/4インチカートリッジ), DLT (デジタルリニアテー プ), QIC ミニカートリッジ, 9トラック (大きなリールがハリウッドの コンピュータルームで回っているのを見たことがあるでしょう)をサポー トします. st(4) マニュアルページにより詳しい解説があります.

以下のドライブリストは現在 FreeBSDコミュニティのメンバが 使っているものです. これらだけが FreeBSDで動くドライブという わけではありません. これらは単にたまたま私たちのうちの誰かが使っ ているというだけです. 4mm (DAT: Digital Audio Tape )

8mm (Exabyte)

QIC (1/4 インチカートリッジ)

DLT (Digital Linear Tape)

Mini-Cartridge

Autoloaders/Changers

* IDE ドライブ フロッピードライブ

* パラレルポートドライブ 詳細な情報

このドライブのブートメッセージの識別子は "ARCHIVE ANCDA 2750 28077 -003 type 1 removable SCSI 2"です.

これは QIC テープドライブです.

QIC-1350テープを利用した場合の標準の容量は 1.35GBです. このドライブは QIC-150 (DC6150), QIC-250 (DC6250), QIC-525 (DC6525) の テープを問題なく読み書きすることができます.

dump(8)を使った時のデータ転送レートは 350kB/sです. における転送レートは 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-XXX4ASB" "type 1 removable SCSI 2" "density code 0x8c, 512-byte blocks" です.

これは DDS-1 テープドライブです.

90m テープを使った場合の標準容量は 2.5GBです.

データ転送速度は不明です.

このドライブは Sun マイクロシステムが再パッケージして model 411として出しています.

報告者: Bob Bishop rb@gid.co.uk

このドライブのブートメッセージ識別子は "ARCHIVE VIPER 60 21116 -007" "type 1 removable SCSI 1"です.

これは QICテープドライブです.

標準の容量は 60MB です.

データ転送レートは不明です.

このドライブは生産中止になっています.

報告者: Philippe Regnauld regnauld@hsc.fr

このドライブのブートメッセージの識別子は "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テープデバイスドライバはあら かじめ (st(4)) にあらかじめ組み込まれています.

FreeBSD 2.2-currentでは, ブロックサイズの設定を設定するためmt blocksize 512としてください. (ファームウェアリビジョンが 21247 -005 である場合の問題です. 他のリビジョンのファームウェアでは異 なる場合があります.) これ以前の FreeBSDバージョンにはこの問題はありません.

このドライブは生産中止になっています.

報告者: Pedro A M Vazquez vazquez@IQM.Unicamp.BR

Mike Smith msmith@atrad.adelaide.edu.au

このドライブのブートメッセージの識別子は "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" 以前の物はバグが 多く, 正しく機能しません.

このドライブは生産中止になっています.

報告者: &a.hm;

このドライブのブートメッセージの識別子は "Conner tape" です.

これはフロッピーコントローラを使うミニカートリッジテープド ライブです.

標準容量は不明です.

データ転送レートは不明です.

このドライブは QIC-80テープドライブを使います.

報告者: Mark Hannon mark@seeware.DIALix.oz.au

このドライブのブートメッセージの識別子は "CONNER CTMS 3200 7.00" "type 1 removable SCSI 2" です.

これはミニカートリッジテープドライブです.

標準容量は不明です.

データ転送レートは不明です.

このドライブは QIC-3080テープカートリッジを使います.

報告者: Thomas S. Traylor tst@titan.cs.mci.com

このドライブのブートメッセージの識別子は "DEC TZ87 (C) DEC 9206" "type 1 removable SCSI 2" "density code 0x19" です.

これは DLTテープドライブです.

標準容量は 10GBです.

このドライブはハードウェアデータ圧縮の機能があります.

データ転送レートは 1.2MB/sです.

このドライブは Quantum DLT2000と同一の物です. このドライブ のファームウェアは Exabyteの 8mmドライブ等のよく知られたいくつかのドラ イブのエミュレートをおこなうよう設定ができます.

報告者: &a.wilko;

このドライブのブートメッセージ識別子は "EXABYTE EXB-2501"です.

これはミニカートリッジテープドライブです.

MC3000XLミニカートリッジを使った時の標準容量は 1GBです.

データ転送レートは不明です.

このドライブは DC2300 (550MB), DC2750 (750MB), MC3000 (750MB), MC3000XL (1GB) ミニカートリッジの読み書きができます.

注意: このドライブは SCSI-2の仕様に適合していません. このドライブは, フォーマット済みのテープ以外を入れた場合, SCSI MODE_SELCTコマンドで完全にロックアップしてしまいます. このドライブを使 う前に, テープブロックサイズを次のように設定します. mt -f /dev/st0ctl.0 blocksize 1024 ミニカートリッジは最初に使う前にフォーマットしなければなりません. FreeBSD 2.1.0-RELEASE およびそれ以前の場合は /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およびそれ以降の場合は /sbin/scsiformat -q -w /dev/rst0.ctl とします.

今のところ, FreeBSDではこのドライブはあまりおすすめできません.

報告者: Bob Beaulieu ez@eztravel.com

このドライブのブートメッセージの識別子は "EXABYTE EXB-8200 252X" "type 1 removable SCSI 1"です.

これは8mmテープドライブです.

標準容量は 2.3GBです.

データ転送レートは 270kB/sです.

このドライブはブート時の SCSIバスへの応答はわりあい遅いです. カスタムカーネルが必要かもしれません (SCSI_DELAYを 10秒に設定しましょう). 訳注: GENERICカーネルの設定では 15秒になっています.

このドライブには非常に多くのファームウェアの構成があります. あるドライブでは特定のベンダのハードウェアにカスタマイズしてあります. ファームウェアは EPROMを置き換えることで変更できます.

このドライブは生産中止になっています.

報告者: Mike Smith msmith@atrad.adelaide.edu.au

このドライブのブートメッセージの識別子は "EXABYTE EXB-8500-85Qanx0 0415" "type 1 removable SCSI 2" です.

これは 8mmテープドライブです.

標準容量は 5GBです.

データ転送レートは 300kB/sです.

報告者: Greg Lehey grog@lemis.de

このドライブのブートメッセージ識別子は "EXABYTE EXB-85058SQANXR1 05B0" "type 1 removable SCSI 2"です.

これは 圧縮機能を持った 8mmテープドライブで, EXB-5200 と EXB-8500に対する上位互換品です.

標準容量は 5GBです.

このドライブはハードウェアデータ圧縮機能があります.

データ転送レートは 300kB/sです.

報告者: Glen Foster gfoster@gfoster.com

このドライブのブートメッセージの識別子は "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にしておきます

注意: これらのドライブの品質管理は非常に幅がありま す. ある FreeBSDコアチームのメンバは このドライブを2つ返品しました.

報告者: &a.se;

このドライブのブートメッセージの識別子は "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 テープドライブ, C35470A DDS フォーマット DATドライブ, C1534A DDS フォーマット DATドライブ, HP C1536A DDS フォーマット DATドライブと 同じ機構を使用しています.

HP C1534A DDSフォーマット DATドライブはグリーンと黄色(アンバー) の2つの表示ランプがあります. グリーンのランプは動作状 態を示し, ローディング中はゆっくり点滅, ローディングが終了すると点灯, read/write動作中は速く点滅します. 黄色のランプは警告灯で, クリーニング が必要であるかまたはテープが寿命に近くなるとゆっくり点滅, 致命的なエラー の場合は点灯します(工場での修理が必要かもしれません).

報告者:Gary Crutcher gcrutchr@nightflight.com

このドライブのブートメッセージの識別子は未確認です.

これは DDS-2テープドライブです. DDS-2 とはデータ容量を増や すためにハードウェア圧縮と狭いトラックを採用したものです.

120mテープを使用した場合の標準容量は 24GB です. このドライブはハードウェアデータ圧縮機能があります.

データ転送レートは510kB/s (標準) です.

このドライブはヒューレットパッカード社の SureStore テープドライブに使われています.

このドライブはリアパネルに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"

このドライブのブートメッセージの識別子は"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

このドライブのブートメッセージの識別子は "HP HP35470A 9 09" type 1 removable SCSI 2"です.

これは DDS-1テープドライブです. DDS-1は最初の DAT テープフォーマットです.

90mテープを使用した時の標準容量は 2GBです.

データ転送レートは 183kB/sです.

これはヒューレットパッカード社の SureStore テープドライブ, C35470A DDSフォーマットDATドライブ, C1534A DDSフォーマットDATドライブ, HP C1536A DDS フォーマットDATドライブと同 じ機構が使われています.

注意: これらのドライブの品質管理には非常に大き な幅があります. ある FreeBSDコアチームのメンバは 5台のドライブを返品し ました. 9ヶ月以上もったものはありません.

報告者: David Dawes dawes@rf900.physics.usyd.edu.au (9 09)

このドライブのブートメッセージの識別子は "HP HP35480A 1009" "type 1 removable SCSI 2" "Sequential-Access density code 0x13" です.

これは DDS-DCテープドライブです. DDS-DCはハードウェアデータ 圧縮のついたDDS-1です. DDS-1は最初のDATテープフォーマットです.

90mテープを使った場合の標準容量は 2GBです. このドライブはハー ドウェア圧縮機能があります.

データ転送レートは 183kB/sです.

このドライブはヒューレットパッカード社の SureStore , テープドラ イブ, C35480A DDS フォーマット DAT ドライブと同じ機構を使っています.

このドライブは時々, テープの eject操作 (mt offline) を行っている時にハングアップすることがあります. テープをejectさせたり, ドライブを回復させるにはフロントパネルのボタンを押してください.

注意: HP 35480-03110 では特有の問題がありました. 少なくとも2回, FreeBSD 2.1.0 で IBM Server 320に 2940W SCSIコントローラ をつけてこのドライブを使っている時にすべての SCSIディスクのパーティショ ンが失われたことがあります. この問題は解析も解決もできていません.

これらには少なくとも 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 =08:" "type 1 removable SCSI 2"です.

このドライブはQIC テープドライブです.

標準容量は150/250MBです.

このドライブには奇妙な癖があることが知られていますが, SCSIテープドライバ (st(4)) には問題なく動くコードが含まれてい ます. 問題の修整とSCSI 2へのコンパチビリティを得るためにファームウェ アをある (具体的には不明の) バージョンより上にしてください.

データ転送レートは80kB/sです.

IBMと Emerald製品のユニットは動かないでしょう. 問題を解決するためにファームウェア EPROMを交換してください.

報告者: Michael Smith msmith@atrad.adelaide.edu.au

これはドライ ブに非常によく似ています.

報告者: &a.joerg;

このドライブのブートメッセージの識別子は "TANDBERG TDC 4222 =07" "type 1 removable SCSI 2"です.

これは QICテープドライブです.

標準容量は2.5GBです. このドライブは 60M (DC600A) 以上のすべての カートリッジを読むことができ, 150MB (DC6150) 以上のすべてのカートリッジを 読み書きできます. ハードウェア圧縮は 2.5GBカートリッジを使用した時のオプションとしてサポートされています.

このドライブには奇妙な癖がありますが, FreeBSDの2.2-current以降の SCSIテープデバイスドライバ (st(4)) には対応が組み込まれています. それ以前のバージョンの FreeBSDではmtを用いてテープから1ブロッ ク読み, テープを巻戻してからバックアッププログラムを実行してください. (mt fsr 1; mt rewind; dump ...).

データ転送レートは 600kB/s (データ圧縮時のベンダによる公称) で, start/stop モードでも 350kB/s にはなります. 容量の小さいカー トリッジを使った場合にはレートは下がります.

報告者: &a.joerg;

このドライブのブートメッセージの識別子は "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テープドライバ (st(4)) に組み込まれています.

他のファームウェアのリビジョンで動くことが確認されているも のは M75Dです.

報告者: Marc van Kempen marc@bowtie.nl "REV73R1" Andrew Gordon Andrew.Gordon@net-tel.co.uk "M75D"

このドライブのブートメッセージの識別子は "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 * 問題のあるドライブ * CD-ROM ドライブ * その他 * ディスクの追加と再設定 テープとバックアップ * フロッピーへのバックアップはいかが? テープメディア

4mm テープはワークステーションのバックアップメディアとして QICから置き換えられつつあります. この流れは QICドライブの製造のリーダ であった Archiveを Connerが買収し QICドライブの製造を中止したことで加 速しました. 4mmドライブは小型で静かですが 8mmドライブの持っているような信頼性の評判はありません. カートリッジは 8mmカートリッジよりも安価で小型 (3 x 2 x 0.5 インチ ; 76 x 51 x 12 mm) です. 4mmドライブ は 8mm同様にヘリカルスキャン (訳 注: VTRと同様の回転ヘッドを使う方式) を使用しているという理由でヘッド の寿命は短いです.

これらのドライブのデータスループットは 150kB/s程度から 500kB/s程度の範囲です. データ容量は 1.3GBから 2.0GBです. ハードウェア 圧縮が多くのドライブで可能で, およそ 2倍の容量になります. マルチドライ ブテープライブラリユニットは1つの筐体に 6ドライブを持つことができ自動的 にテープを交換します. ライブラリの容量は 240GBに達します.

4mmドライブは 8mmドライブ同様にヘリカルスキャンを使います. ヘリカルスキャンの利点と欠点は 4mmドライブ と 8mmドライブ共通です.

テープの寿命は 2000回のパスあるいは 100回のフルパックアップ です.

8mmテープは SCSIテープドライブとして最もよく使われているもの で, データ交換用として最良の選択です. ほとんどのサイトには Exabyteの 2GB 8mmテープドライブがあるでしょう (訳注: Unixワークステーションを何 台も置いているようなサイトには1台くらいはあるというような意味です). 8mmドライブは信頼性が高く, 使いやすく, 静かです. カートリッジは安価で 小型です (4.8 x3.3 x 0.6 インチ; 122 x 84 x 15 mm). ひとつの欠点は , テープとヘッドの相対的な速度が高速なために比較的ヘッドとテープの寿命 が短いことです.

データスループットは 250kB/s程度から 500kB/s程度の範囲です. データ容量は 300MBから 7GBです. ハードウェア圧縮が多くのドライブで可 能で,およそ 2倍の容量になります. 単一のユニットおよび,1つの筐体に6台の ドライブと 120巻のテープを持ったマルチドライブテープライブラリが利用可 能です. テープはユニットにより自動的に交換されます. ライブラリの容量は 840GB以上に達します.

データはヘッドがメディアに対してある傾き (約6度) を持って配置 されているヘッドによるヘリカルスキャンを使ってテープに記録されます. テープは ヘッドのある円筒の周の 270度にわたって接触します. テープが円筒面を走行 する間, 円筒は回転しています. この結果, トラックはテープの上端と下端の間に 角度を持って横切り, データは高密度に詰められることになります.

QIC-150テープとドライブはたぶん最も一般的に使われているドライブとメ ディアでしょう。QICテープドライブは現実的なバックアップドライブとして 少なくとも高価なものではありません. 欠点はメディアのコストです. QICテー プは 8mmや 4mmテープに比較して GBのデータの保存には5倍ほど高価です. しかしあなたの必要とする量が半ダース程のテープで十分であれば, QICは正 しい選択となるかもしれません. QICは 最も一般的なテープドライ ブです. すべてのサイトに QICドライブのどれかの容量のものがあります. 問題は, QICは同じようなテープ (まったく同じ場合もある) に多様な記録密度 があることです. QICドライブは静かではありません. これらのドライブはデー タ記録を開始する前に音をたててシークしますし, リード, ライト, シークの 時にはっきりと聞こえる音を出します. QICテープの大きさは (6 x 4 x 0.7 インチ; 152 x 102 x 17 mm). で使われている 1/4インチ幅のテープについては別に 議論します. テープライブラリやチェンジャはありません.

データスループットは 150kB/sから 500kB/sの範囲です. データ容量 の範囲は 40MBから 15GBです. ハードウェア圧縮が最近の多くのドライブで使 えるようになっています. QICドライブは DATドライブに置き換えられつつあ り,あまり多くインストールされなくなっています.

データは複数のトラックにわかれてテープに記録されます. トラックはテープメディアの長さ方向に沿っていて, 一端からもう一方の端ま でです. トラックの 数とそれにしたがうトラックの幅はテープの容量によって変わります. すべてではあ りませんがほとんどの最近のドライブは少なくとも読み出しについては (場合 によっては書き込みも) 下位互換性があります. QICはデータの安全性につ いてはよいといわれています (ヘリカルスキャンドライブに比べて機構は単純 でより丈夫です).

テープは 5000回のバックアップで寿命となるでしょう.

DLTはここに示したドライブのタイプの中で最高速のデータ転送レー トです. 1/2インチ (12.5mm) テープが単リールのカートリッジ (4 x 4 x 1 イン チ; 100 x 100 x 25 mm) に入っています. カートリッジのひとつの側面全体が スイングゲートになっています. ドライブの機構がこのゲートを開け, テープ リーダを引き出します. テープリーダには楕円形の穴があり, ドライブ がテープを引っ掛けるのに使います. 巻き取りのためのリールはドライブの中 にあります. ここに挙げた他のカートリッジはすべて (9トラックテープはただ 1つの例外です) 送りだしリールと巻き取りリールの両方がカートリッジの中 にあります. データスループットは約1.5MB/sで, 4mm, 8mm, QIC テープドライブ の3倍です. データ容量は単一のドライブで 10GBから 20GBの範囲です. マルチテープチェンジャ,マルチテープドライブ,5から 900巻のテープを1から 20ドライブで扱うマルチドライブテープライブラリがあり, 50GBから 9TBの容量が得 られます. データは (QICテープのように) テープの走行方向に並列なトラックに 記録されます. 2つのトラックが同時に書かれます. Read/Writeヘッドの寿命 は比較的長いと言えます. テープの走行が止まればヘッドとテープの間の相対 運動はありません. 新品のテープを最初に使う場合

新品の完全な空テープを読もうとしたり書き込もうとすると処理 は失敗するでしょう. 次のようなコンソールメッセージが出るでしょう. st0(ncr1:4:0): NOT READY asc:4,1 st0(ncr1:4:0): Logical unit is in process of becoming ready テープに識別ブロック (Identifire Block:block number 0) がありません. QIC-525標準の採用されている QICテープドライブのすべてで識別ブロックをテー プに書きます. 2つの解決方法があります.

(訳注: 方法1)mt fsf 1 によってテープドライブは識別 ブロックをテープに書きます.

(訳注: 方法2)フロントパネルのボタンを押してテープをとりだします.

再びテープを入れ,データをテープに dump(8)します.

dump(8) はそのうちに DUMP: End of tape detected と表示し, コンソールには HARDWARE FAILURE info:280 asc:80,96と表示されるでしょう.

mt rewindを使ってテープを巻戻します.

この次からはテープの操作は成功するでしょう. バックアッププログラム

よく使われる3つのプログラムはdump(8), tar(1), cpio(1)です. ダンプとリストア

dump(8) と restore(8) は伝統的な Unixのバッ クアッププログラムです. これらはドライブのファイルシステムによって作ら れたファイル,リンク,ディレクトリをディスクブロックの集まりとして処理し ます. dump(8)はデバイスやファイルシステム全体をバックアップし, 一部分のバックアップや, ln(1)によるソフトリンクや他のファイル システムをマウントを行った, 1つ以上のファイルシステムにまたがるディレ クトリツリーのバックアップはできません. dump(8)はファイルやディレクトリを構成するデータブロックをテー プに書くだけで, ファイルやディレクトリをテープに書くことはありません. dump(8)には初期の ATT UNIXのバージョン 6 (1975年ごろ) に由来する 癖が残っています. デフォルトのパラメタは 9トラックテープ (6250 bpi) に 適したものになっていて現在の高密度メディア (最大 62,182 ftpi) に適してい ません. 現在のテープドライブの容量を有効に利用するため, デフォルト値を コマンドラインで置き換えなければなりません.

rdump(8) と rrestore(8) は他のコンピュー タに接続されているテープドライブにネットワーク経由でバックアップをしま す.どちらのプログラムもリモートテープドライブにアクセスするために rcmd(3)と ruserok(3)に依存しています. このためユーザ がバックアップを実行するためには rhostsによるリモートアクセス が必要です.

rdump(8) と rrestore(8)の引数はリモー トコンピュータに適切なものを用います. rrestore(8)はリモートコンピュータから使うのに適しています. (例えば FreeBSDコンピュータより komodoという名前の Sunに接続されている Exabyteテープドライブへ /sbin/rdump 0dsbfu 54000 13000 126 komodo:/dev/nrst8 /dev/rsd0a 2>&1 として rdumpしたような場合の restoreに使います) 警告: セキュリティは rhostsの管理にかかっています. あなたの状況を注意深く調べてください. Tar

tar(1) ATT Unix のバージョン 6 (1975ごろ) にさかのぼ る事ができます. tar(1)はファイルシステムと協調して機能し, ファ イルやディレクトリをテープに書きます. tar(1)は cpio(1)で使えるようなフルレンジのオプションは持ちませんが cpio(1)で使うような奇妙なコマンドパイプラインは必要ありません.

tar(1) はネットワーク経由のバックアップの機能はあ りません. リモートテープドライブにはパイプラインと rsh(1)を使っ て送る事ができます. (コマンド使用例はまだです) Cpio

cpio(1) は本来の Unixファイルを磁気メディアへ移すた めのプログラムです. cpio(1)はバイトスワッピング, 多くの異な るアーカイブフォーマットの書き込みのオプション(それ以外にも多数のオプ ションがあります)がありパイプで他のプログラムにデータを渡す事もできま す. この最後に挙げた特徴により, cpio(1)はインストールメディア にとっては優れた選択です. cpio(1)はSTDINからの入力で なければならず,ディレクトリツリーの探索やファイルリストについての機能 はありません.

cpio(1)はネットワーク経由のバックアップの機能はあ りません. リモートテープドライブにはパイプラインと rsh(1)を使っ て送る事ができます. (コマンド使用例はまだです)

Amanda (Advanced Maryland Network Disk Archiver) は単一のプ ログラムではなくクライアント/サーバ型のバックアップシステムです. Amanda サー バは, Amandaクライアントであるネットワークでサーバに接続された複数のコン ピュータから一つのテープドライブへバックアップをおこないます. このような場合の一般的な問題はいくつもの大容量のディスクからデータディ レクトリをテープにバックアップするには時間がかかりすぎてしまうという事 です. Amanda はこの問題を解決します. Amandaは同時に複数のファイルシス テムのバックアップをおこなう時に 「ホールディングディスク」を使う事ができます. Amandaの設定ファイルに書いたすべてのファイルシステムのフルバックアップを ある間隔でとるためのテープグループである 「アーカイブセット」を作ります. これは Amandaの設定ファイルに書かれているすべてのファイルシステムが, ある 期間で作られるフルバックアップのテープのグループです. 「アーカイブセッ ト」には夜間に作られるすべてのファイルシステムの増分 (あるいは差分として ) のバックアップも含みます. 障害の起きたファイルシステムの回復に は最も新しいフルバックアップと増分のバックアップが必要です.

設定ファイルでバックアップのコントロールと Amandaによるネッ トワークトラフィック量を設定します. Amandaはデータをテープに書くのに バックアッププログラムのどれかを使うでしょう. Amandaはその一部分でも パッケージでも利用可能ですが, デフォルトではインストールされません. 何もしない

「何もしない」というのはコンピュータのプログラムではありませ んが, バックアップの戦略として最も広く採用されている物です. これには初 期投資が必要ありません. したがわなければならないバックアップスケジュールも ありません. ただ何もしないだけです. もしデータに何かが起きたら, 苦笑い して耐えてください.

あなたにとって時間やデータの価値が少ないかあるいはまったくない のであれば「何もしない」のはあなたのコンピュータに最も適したバックアッ ププログラムでしょう. しかし注意してください. Unixは便利なツールです. 6ヶ月も使っていれば価値のあるファイルの山ができ上がっているでしょう.

「何もしない」は /usr/obj やその他の, コンピュータに よってつくり出されたディレクトリツリーについては適切な方法です. 一つの 例はこのハンドブックのファイルで, これらは SGMLのファイルより 生成された物です. HTMLファイルのバックアップを作る必要はあ りません. SGMLのソースファイルは定期的にバックアップされます. どのバックアッププログラムが最適でしょう?

定期的に dump(8)しましょう. Elizabeth D. Zwicky はここで検討したプログラムすべてについて拷問的なテストをおこないま した. すべてのデータと Unixファイルシステムの状態すべてを保存するには明ら かに dump(8)でしょう. Elizabethは大きく変化に富んだ異常な状態 (いくつかはあまり異常でもない状態のものもあります) になっているファイ ルシステムで, それぞれのプログラムでファイルシステムのバックアップとリ ストアを行ってテストしました. 特色のある状態には, ホールを持つファイル, ホールとヌルブロックを持つファイル, 奇妙な文字をファイル名に持つファイ ル, 読み出し不可, 書き込み不可のファイル, デバイスファイル, バックアッ プ中にファイルのサイズを変更する, バックアップ中にファイルの作成/削除 をおこなうなどがあります. 彼女は1991年10月の LISA Vで結果の発表をしていま す. 緊急時のリストア手順 災難の起きる前に

起き得るどのような災難に対しても以下の4ステップだけが必要な 準備です.

ステップ 1では, ファイルシステムテーブル(/etc/fstab) やブートメッセージで示されるすべてのディスクの disklabelをそれぞれ2コピー づつプリント (例えば disklabel sd0 | lpr とする) します.

ステップ 2では, boot と fixitフロッピーにそのシステムのすべ てのデバイスドライバが含まれているか確認します. 最も簡単な確認の方法は, フロッ ピーをドライブに入れてリブートし, ブートメッセージを確認することです. あなた のシステムのデバイスがすべて含まれ, 機能していれば, step 3へ飛んでください.

そうでないなら, そのシステムのすべてのディスクをマウントでき, テープドライブにもアクセスできる 2種類のカスタムブートフロッピーディスクを作る必要 があります. これらのフロッピーには fdisk(8), disklabel(8), newfs(8), mount(8), と利用したい バックアッププログラムが入っていなければなりません. これらのプログラム はスタティックリンクされたプログラムである必要があります. dump(8)を使うのであればフロッピーに restore(8)を入れ る必要があります.

ステップ 3では, 通常の方法でバックアップを作ります. 最新のバックアップの後でおこなわれた変更は回復することはできません. バックアップテープにライトプロテクトをしてください.

ステップ 4では, フロッピー (boot.flp と fixit.flp あるいは ステップ 2で作った2枚のカスタムブートフロッピーディスクです) とバックアップテー プのテストをします. 手順のノートを作りましょう. このノートはブートフロッピーディスク,バックアッ プテープに入れておきプリントアウトしておきます. あなたがリストアをおこなう ような時はおそらく錯乱状態でしょうからこのノートはバックアップを破壊し てしまうようなことを防ぐのに役立つでしょう (どのようにして破壊するって? tar xvf /dev/rst0とする替りに偶然 tar cvf /dev/rst0 とタイプしてバックアップテープに上書きしてしまうかもしれません). 訳注: 上書きはライトプロテクトをしておけば防げますが, なんらかの原因で プロテクトがはずれているかもしれません. ちなみに訳者の経験から言えば上のようなミスタイプは結構起きます.

安全性を増すために, 毎回ブートフロッピーディスクを作り,2巻のバック アップテープを取ります. 一方を離れた場所に保管します. 離れた場所は同じ 建物の地下室ではいけません. 世界貿易センタービルにあった数多くの会社は 苦い経験よりこの教訓を得ました. 離れた場所とはコンピュータやディスク ドライブからかなり離れていて物理的に分離されていなければなりません.

ブートフロッピーディスクを作るスクリプトの一例 #!/bin/sh # # create a restore floppy リストアフロッピーの作成 # # format the floppy フロッピーのフォーマット # PATH=/bin:/sbin:/usr/sbin:/usr/bin fdformat -q fd0 if [ $? -ne 0 ] then echo "Bad floppy, please use a new one" exit 1 fi # place boot blocks on the floppy フロッピーにブートブロックを書く # disklabel -w -B -b /usr/mdec/fdboot -s /usr/mdec/bootfd /dev/rfd0c fd1440 # # newfs the one and only partition ただ1つのパーティションを newfs # newfs -t 2 -u 18 -l 1 -c 40 -i 5120 -m 5 -o space /dev/rfd0a # # mount the new floppy 新しいフロッピーをマウント # mount /dev/fd0a /mnt # # create required directories 必要なディレクトリの作成 # mkdir /mnt/dev mkdir /mnt/bin mkdir /mnt/sbin mkdir /mnt/etc mkdir /mnt/root mkdir /mnt/mnt # for the root partition mkdir /mnt/tmp mkdir /mnt/var # # populate the directories # # MINIカーネルがない場合は作ります if [ ! -x /sys/compile/MINI/kernel ] then cat << EOM The MINI kernel does not exist, please create one. Here is an example config file: # MINIカーネルの config fileの例 # MINI -- A kernel to get FreeBSD on onto a disk. # machine "i386" cpu "I486_CPU" ident MINI maxusers 5 options INET # needed for _tcp _icmpstat _ip stat # _udpstat _tcpstat _udb options FFS #Berkeley Fast File System options FAT_CURSOR #block cursor in syscons or pcc ons options SCSI_DELAY=15 #Be pessimistic about Joe SCSI device options NCONS=2 #1 virtual consoles options USERCONFIG #Allow user configuration with -c XXX config kernel root on sd0 swap on sd0 and sd1 dumps on sd0 controller isa0 controller pci0 controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr disk fd0 at fdc0 drive 0 controller ncr0 controller scbus0 device sc0 at isa? port "IO_KBD" tty irq 1 vector scintr device npx0 at isa? port "IO_NPX" irq 13 vector npxintr device sd0 device sd1 device sd2 device st0 pseudo-device loop # required by INET pseudo-device gzip # Exec gzipped a.out's EOM exit 1 fi cp -f /sys/compile/MINI/kernel /mnt gzip -c -best /sbin/init > /mnt/sbin/init gzip -c -best /sbin/fsck > /mnt/sbin/fsck gzip -c -best /sbin/mount > /mnt/sbin/mount gzip -c -best /sbin/halt > /mnt/sbin/halt gzip -c -best /sbin/restore > /mnt/sbin/restore gzip -c -best /bin/sh > /mnt/bin/sh gzip -c -best /bin/sync > /mnt/bin/sync cp /root/.profile /mnt/root cp -f /dev/MAKEDEV /mnt/dev chmod 755 /mnt/dev/MAKEDEV chmod 500 /mnt/sbin/init chmod 555 /mnt/sbin/fsck /mnt/sbin/mount /mnt/sbin/halt chmod 555 /mnt/bin/sh /mnt/bin/sync chmod 6555 /mnt/sbin/restore # # create the devices nodes デバイスノードを作る # cd /mnt/dev ./MAKEDEV std ./MAKEDEV sd0 ./MAKEDEV sd1 ./MAKEDEV sd2 ./MAKEDEV st0 ./MAKEDEV pty0 cd / # # create minimum filesystem table 最小限のファイルシステムテーブル # cat > /mnt/etc/fstab < /mnt/etc/passwd < /mnt/etc/master.passwd < 災難の後に

重要な問題は, ハードウェアが生き残ったかどうかです. 定期的なバックアップを取っていればソフトウェアについて心配する必要はあ りません.

ハードウェアがダメージを受けていたら, 最初にそのダメージを 受けた部品を交換してください.

ハードウェアに問題がなければ, フロッピーをチェックしてくださ い.カスタムブートフロッピーディスクを使っているのであればシングルユーザ ("boot:"プロンプトの出た時に "-s" とタイプしてください) でブートしてくださ い. それから次の「ファイルシステムを1つずつ回復する」を読んでください。

boot.flp と fixit.flp を使っているのであればこのまま読み続けてくださ い. boot.flp を入れてブートしてください. 本来のインストールメニューが表 示されるはずです. (ここで) "fixit XXX"オプションを選びます. 指示の通り fixit.flp を入れてください. restoreとその他の必要なプログラムは /mnt2/standに置かれています.

ファイルシステムを一つずつ回復する

最初のディスクのrootパーティションをmount(8) (例えば mount /dev/sd0a /mntのように) マウントして見てください. ディスクラベルが 破壊されている場合は disklabel(8)を使ってあらかじめプリントし ておいた通りにパーティションを作り直しラベルをつけてセーブしてください. newfs(8)を使いファイルシステムを作り直します. ルー トパーティションを読み書き可能にマウント ("mount -u -o rw /mnt") しなおします. バックアッププログラムとバックアップテープを 使ってこのファイルシステムのデータを回復します (例えば restore vrf /dev/st0とします). ファイルシステムをアンマウント (umount /mntなど) して, 障害を受けたファイルシステムそれぞれについて繰り返 してください.

システムが動き出したら, 新しいテープにデータをバックアップ してください. どのような理由で再び事故が起きたりデータが失われるかはわか りません. これに時間を費す事で, 後々の災難から救われる事になります. * 災難対策をしていませんでした. どうしたらいいでしょ う? * シリアルポート * サウンドカード * PCMCIA * その他 diff --git a/ja_JP.EUC/handbook/install.sgml b/ja_JP.EUC/handbook/install.sgml index 32b25ece32..c6556da7b5 100644 --- a/ja_JP.EUC/handbook/install.sgml +++ b/ja_JP.EUC/handbook/install.sgml @@ -1,843 +1,843 @@ - + FreeBSDのインストール

原作: 不明

訳: &a.mita;, &a.hanai;, &a.iwasaki;. 11 November 1996.

それでは, FreeBSD のインストールに挑戦してみましょう. この章には, あなたが何をする必要があるかの簡単なガイドが 書いてあります. FreeBSD は, CD-ROM, フロッピーディスク, 磁気テープ, MS-DOSのパーティション, ネットワーク接続しているところでは anonymous FTP や NFS を通じてインストールすることができます. どのインストールメディアを利用する場合も, まずインストールディスク をダウンロードするところから始まります. このディスクであなたの コンピュータを立ち上げることで, FreeBSD とあなたのハードウェアとの 相性に関する重要な情報を手に入れることができ, このハードウェアでは どんなインストールオプションが使えるかを指定することができます. もしもあなたが anonymous FTP を使用してインストールする予定なら, インストールディスクだけをダウンロードすればOKです. FreeBSDの配布に関する情報は, 付録の をご覧ください. 仕事にとりかかるには, 以下のような手順を踏みます. このインストールガイドの の節を読んで, あなたのハードウェアが FreeBSD でサポートされていることを確認します. SCSI コントローラだとか, イーサネットアダプタだとか, サウンドカードだとかの, あなたのマシンが 装備している特別なカードのリストを作っておくと便利です. この リストには, 割り込み番号 (IRQ) とか, IO ポートのアドレスとかの, カードに 関係する設定も書いておきましょう. ファイルをあなたの ハードディスクにダウンロードしてきます. ブラウザのコマンドでは, display ではなくて save を選ぶことに注意してください. 注意: このディスクイメージは, 1.44 メガバイトの 3.5 インチフロッピーディスクと, 1.2 メガバイトの 5.25 インチフロッピーディスク のどちらでも使用可能です. このイメージファイルからブートディスクを作成します, MS-DOSを使っている場合: をダウンロードして, これを実行します. C:\> rawrite このプログラムを実行すると, 書き込むフロッピードライブ (A: か B: か) を聞いてきて, その後に書き込むファイルの名前 (boot.flp) を聞いてきます.

注: rawrite.exe に関しては, Windows95 上では DOS モードで のみ動作し, Windows NT 上では全く動作しないという報告が多く寄せられて います. Windows NT マシンをお使いの場合は, 別のマシンを使ってフロッピー イメージを作成してください. また Windows95 をお使いでしたら, まず DOS モードで起動してから作業してください.

UNIX システムを使っている場合: % dd if=boot.flp of=disk_device を実行します. ここで, disk_device はフロッピードライブに 対応する /devの中のエントリです. FreeBSD では, /dev/fd0 が A:ドライブに, /dev/fd1 が B:ドライブに 対応しています. インストールディスクを A:ドライブに入れて, コンピュータを 立ち上げ直します. そうすると次のようなプロンプトが出てくるはずです. >> FreeBSD BOOT ... Usage: [[[0:][wd](0,a)]/kernel][-abcCdhrsv] Use 1:sd(0,a)kernel to boot sd0 if it is BIOS drive 1 Use ? for file list or press Enter for defaults Boot: ここで何もタイプしない場合, 5秒間の待ち時間の後に FreeBSD は 自動的にデフォルトの設定で立ち上がります. 立ち上げの際, どんな ハードウェアが装備されているかを検出 (プローブ) します. この結果は スクリーン上に表示されます. 立ち上げプロセスが終了したら, FreeBSD インストールメニューが 表示されます.

もしも問題が起こった場合

PC アーキテクチャの制限のため, 100パーセントの信頼をもって検出する ことは不可能です. もしもあなたのハードウェアが間違って認識されたり, 検出途中でコンピュータが固まってしまうようなことが起こった場合, まずこのガイドの の節を読んで, あなたのハードウェアが本当に FreeBSD でサポートされているかどうかを確かめてください.

ハードウェアがサポートされていた場合, リセットして Boot: プロンプトが出てきたところで, -c と打ち込んで ください. こうすると, FreeBSD はコンフィグレーションモードになり, ハードウェアに関する情報を FreeBSD に与えることができるようになります. インストールディスクの FreeBSD カーネルは, 多くのデバイスの IRQ, IO アドレスが工場出荷時の値に設定されているものと仮定して作られています. もしもあなたのハードウェアの設定を変更したなら, -c オプションで立ち上げて, 設定がどうなっているかを指定してあげること が必要になるでしょう.

存在しないデバイスを検出すると, 実際に存在している他のデバイスの 検出に失敗することが考えられます. そのような場合は, 衝突している デバイスを無効にしなくてはなりません.

コンフィグレーションモードでは, カーネルに組み込まれているデバイスドライバの一覧を表示する あなたのシステムにないハードウェアのデバイスドライバを無効にする デバイスドライバの IRQ, DRQ, IO ポートアドレスなどの変更する などができます.

config> プロンプトが出ているところで, help と打ち込むと, 使用可能なコマンドについての詳しい説明が出てきます. あなたのマシンのハードウェア設定に合うようにカーネルを変更したら, config> プロンプトが出たところで quit と打ち込んで, 新しい設定でマシンを立ち上げます. FreeBSD のインストールがひとたび終了した後は, コンフィグレーションモード での変更はずっと保持されますので, 立ち上げのたびに設定変更をする必要は なくなりますが, あなたのシステムの性能を高めるために, カスタムカーネルを作るのが好ましいでしょう. カスタムカーネルの作成に関しては, の章をご覧ください. サポートされている設定一覧

現在 FreeBSD は, ISA, VL, EISA, PCI バスや, 386SX から Pentium クラス までのさまざまな種類の PC で動作します (386SXはおすすめではありません). IDE, ESDIドライブや, さまざまな SCSI コントローラ, ネットワークカードや シリアルカードにも対応しています. FreeBSD を走らせるには, 最低 4メガバイトの RAM が必要です. X Window System を 走らせるには最低でも 8メガバイトの RAM が推奨されます. 以下のリストでは, FreeBSD で動作が確認されているディスクコントローラ やイーサネットカードです. 他の設定でもうまく動いてくれると 思いますが, 私たちのところには情報は入ってきていません. ディスクコントローラ

WD1003 (あらゆる MFM/RLL) WD1007 (あらゆる IDE/ESDI) IDE ATA Adaptec 152x シリーズ ISA SCSI コントローラ Adaptec 154x シリーズ ISA SCSI コントローラ Adaptec 174x シリーズ EISA SCSI コントローラ (スタンダード, エンハンスドモード) Adaptec 274x/284x/2940/3940 (Narrow/Wide/Twin) シリーズ EISA/VLB/PCI SCSI コントローラ Adaptec AIC7850 オンボード SCSI コントローラ Adaptec AIC-6360系のボード AHA-152x や SoundBlaster SCSI などがこれにあたります. 注意: Soundblaster カードには, オンボード BIOS が載っていないので, このカードからは FreeBSD を起動できません. オンボード BIOS とは, システム BIOS の I/O ベクタにブートデバイスを 登録するときに必要なものです. このカードは外部テープであるとか, CD-ROM であるとかその他の場合には十分利用可能です. 同じことは, ブート ROM の載っていない AIC-6x60 系のカードにもいえます. いくつかのシステムでは実際にブート ROM を持っています. それは電源を入れるかリセットしたとき, 最初に表示されます. 詳しくはあなたのシステムやボードの解説書をご覧ください. Buslogic 545S & 545c 注意: Buslogic社は古くは Bustek社といっていました. Buslogic 445S/445c VLバス SCSI コントローラ Buslogic 742A, 747S, 747c EISA SCSI コントローラ. Buslogic 946c PCI SCSI コントローラ Buslogic 956c PCI SCSI コントローラ NCR 53C810 , 53C825 PCI SCSI コントローラ. NCR5380/NCR53400 (``ProAudio Spectrum'') SCSI コントローラ. DTC 3290 EISA SCSI コントローラ (1542 エミュレーション) UltraStor 14F, 24F, 34F SCSI コントローラ. Seagate ST01/02 SCSI コントローラ. Future Domain 8xx/950 シリーズ SCSI コントローラ. WD7000 SCSI コントローラ. サポートされている SCSI コントローラのすべてで, ディスク, テープドライブ (含む DAT), CD-ROM ドライブなどの周辺機器との通信に SCSI-I, SCSI-II が利用可能です. 現在, 次にあげるタイプの CD-ROM ドライブがサポートされてます. Soundblaster SCSI , ProAudio Spectrum SCSI (cd) ミツミ (全モデル) 独自のインタフェース (mcd) 松下 / Panasonic (Creative) CR-562/CR-563 インタフェース (matcd) ソニー インタフェース (scd) ATAPI IDE インタフェース (まだまだお試し段階で, クオリティは低いです) (wcd) イーサネットカード

Allied-Telesis AT1700, RE2000 カード SMC Elite 16 WD8013 Ethernet インタフェース, その他多くの WD8003E, WD8003EBT, WD8003W, WD8013W, WD8003S, WD8003SBT や WD8013EBTなどの互換品. SMC Elite Ultra もサポートされています. DEC EtherWORKS III ネットワークインタフェースカード (DE203, DE204, DE205) DEC EtherWORKS II ネットワークインタフェースカード (DE200, DE201, DE202, DE422) DEC DC21140/DC21141/DC21140 ベースのネットワークインタフェースカード: ASUS PCI-L101-TB Accton ENI1203 Cogent EM960PCI Compex CPXPCI/32C D-Link DE-530 DEC DE435 Danpex EN-9400P3 JCIS Condor JC1260 Linksys EtherPCI Mylex LNP101 SMC EtherPower 10/100 (Model 9332) SMC EtherPower (Model 8432) SMC EtherPower (2) Zynx ZX342 DEC FDDI (DEFPA/DEFEA) ネットワークインタフェースカード 富士通 FMV-181, FMV-182 富士通 MB86960A/MB86965A Intel EtherExpress Intel EtherExpress Pro/100B 100Mbit. Isolan AT 4141-0 (16 bit) Isolink 4110 (8 bit) Novell NE1000, NE2000, NE2100 イーサネットインタフェース 3Com 3C501 カード 3Com 3C503 Etherlink II 3Com 3c505 Etherlink/+ 3Com 3C507 Etherlink 16/TP 3Com 3C509, 3C579, 3C589 (PCMCIA) Etherlink III 3Com 3C590, 3C595 Etherlink III HP PC Lan Plus (27247B と 27252A) 東芝 イーサネットカード IBM , National Semiconductor社 PCMCIA イーサネットカードもサポートされています.

注意: FreeBSD は今のところ, いくつかのイーサネットカードの PnP (プラグ&プレイ) 機能には対応していません. もし PnP で問題が起こる ようでしたら, PnP 機能を無効にしてください. その他のデバイス

AST 4 ポート シリアルカード (シェアード IRQ 使用) ARNET 8 ポート シリアルカード (シェアード IRQ 使用) BOCA IOAT66 6 ポート シリアルカード (シェアード IRQ 使用) BOCA 2016 16 ポート シリアルカード (シェアード IRQ 使用) Cyclades Cyclom-y シリアルボード STB 4 ポート カード (シェアード IRQ 使用) SDL Communications Riscom/8 シリアルボード SDL Communications RISCom/N2 と N2pci 同期シリアルカード Digiboard Sync/570i high-speed 同期シリアルカード Decision-Computer Intl. "Eight-Serial" 8 ポートシリアルカード (シェアード IRQ 使用) Adlib, SoundBlaster, SoundBlaster Pro, ProAudioSpectrum, Gravis UltraSound, Gravis UltraSound MAX Roland MPU-401 などのサウンドカード Matrox Meteor video フレームグラバー Creative Labs Video spigot フレームグラバー Omnimedia Talisman フレームグラバー X-10 power コントローラ PC ジョイスティックおよびスピーカ FreeBSD は今のところ, IBM社のマイクロチャネルアーキテクチャ (MCA) バスには 対応していません. インストールの下準備

FreeBSD のインストール方法はさまざまあります. それぞれの インストール方法に対して, どのような下準備が必要かをこれから説明します. CD-ROM からインストールする前に

あなたの CD-ROM ドライブがサポートされていないタイプの場合は, に飛んでください. Walnut Creek の FreeBSD CD-ROM からインストールする場合は, 大した下準備 をしないでもうまくインストールできることでしょう (その他の CD-ROM でもうまくいくでしょうが, その CD-ROM がどうやって作られているか, 私たち はわかりませんので確実なことは言えません). Walnut Creek の CD-ROM に収録されている, ``install.bat'' で直接 FreeBSD を立ち上げることもできますし, ``makeflp.bat'' でブートフロッピーディスクを つくることもできます. [注意: もし FreeBSD 2.1-RELEASE を使っていて IDE CD-ROM ドライブを持っている場合, install.bat のかわりに inst_ide.bat もしくは atapiflp.bat を使ってください. ] DOS から最も楽なインタフェースを使いたい場合は ``view'' と打ち込みます. そうすると DOS でのメニューが立ち上がって, 可能なオプション すべてを選択できます. あなたが UNIX マシンでブートフロッピーディスクを作成している場合は, を参考にしてください. DOS から, もしくはフロッピーディスクから起動をおこなうと, メニュー ``Media'' から, インストールメディアとして CDROM を 選択することで, 配布ファイルをロードすることができるようになります. 他の種類のインストールメディアは不要なはずです. システムインストールがすべて終了して, ハードディスクから起動 しなおしてからは, mount /cdrom とタイプする ことでいつでも CD-ROM のマウントをすることができるようになります. CD-ROM を取り出す前には 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://あなたのマシンのアドレス を入力します. フロッピーディスクからのインストールの前に

あなたがフロッピーディスクからのインストールをしなくては ならない場合, その理由はハードウェアがサポートされてなかったためか, 単にいばらの道を通ることを楽しんでいるからでしょうが, インストール用の フロッピーディスクを用意する必要があります. 最低でも bin (基本配布ファイル) ディレクトリ内のすべてのファイル を入れられるだけの 1.44 メガバイトか 1.2 メガバイトのフロッピーディスク が必要です. これらのフロッピーディスクを DOS で作成している場合は, フロッピーディスクは「MS-DOS の FORMAT コマンドでフォーマット」 されなくてはなりません. Windows をお使いの場合は, Windowsの ファイルマネージャの初期化コマンドを使用してください. 工場での初期化済みディスクを「信用しないでください」. 念のためにあなた 自身でフォーマットし直してください. ユーザからのトラブル報告の多くは ちゃんと初期化されていないディスクを使用していたことが原因となっています. 私が特にフォーマットし直してくださいと述べているのも, この理由からです. 他の FreeBSD マシンでフロッピーディスクを作成している場合, フォーマットすることは悪いことではありません. いちいち DOS ファイルシステムのフロッピーディスクを作成する必要はありませんので, `disklabel' コマンドと `newfs' コマンドを使って, 次のような手順で (3.5 インチ 1.44 メガバイトディスク用の) UFS ファイルシステムを 作成することもできます. fdformat -f 1440 fd0.1440 disklabel -w -r fd0.1440 floppy3 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 /S E:\BIN C:\FREEBSD\BIN\ C> XCOPY /S E:\MANPAGES C:\FREEBSD\MANPAGES\ ここで, C:ドライブには十分なディスクスペースが残っており, CD-ROM は E:ドライブに接続されているものとします. MS-DOS からたくさんの `配布ファイル (DISTS)' をインストールしたい (そしてディスクの余裕がある) 場合は, それぞれ C:\FREEBSD ディレクトリにコピーします - BIN 配布ファイルは, 最低限必要なものです. QIC/SCSI テープからのインストールの前に

テープからのインストールは, おそらく FTP を利用したオンライン インストールか, CD-ROM を利用したインストールができない場合の, もっとも簡単な方法でしょう. インストールプログラムは, 以下のような コマンドを使用して, 単純に配布ファイルがテープ上に tar されていることを 期待しています. cd /freebsd/distdir tar cvf /dev/rwt0 (または /dev/rst0) dist1 .. dist2 インストールに入る前に, テンポラリ (一時使用) ディレクトリに 十分なディスクスペースを確保して, 作成したテープのすべての ファイルを格納できることを確認してください (テンポラリディレクトリは 自分で選ぶことができます). テープの特性上, ランダムにアクセスするこ とができませんので, 一時的に極めて大量の容量を必要とします. テープに準備しただけの量のディスクスペースを一時的に使用することに 留意してください. 注意: インストールに入るときは, ブートフロッピーディスク から立ち上げる前にテープをドライブに入れておかなくてはなりません. さもないとインストール時のデバイス検出のときにテープを見つけられません. ネットワーク経由のインストールの前に

三つの物理的な接続形態で, ネットワーク経由のインストールを おこなうことができます. シリアルポート SLIP もしくは PPP 方式. パラレルポート PLIP (laplink ケーブル使用) イーサネット 標準的なイーサネットコントローラ (いくつかの PCMCIA カードにも対応) SLIP のサポートはまだまだ原始的とも呼べる方法なので, ラップトップと 他のコンピュータをシリアルケーブルで接続するといった具合いに, 直接接続してなくてはいけません. SLIP インストールは, ダイヤル機能を 持っていませんので, インストールするためには直接接続しなくてはなりません. PPP インストールではダイヤルアップ接続が可能ですので, できれば PPP 接続の 方を選択しましょう. もしもあなたがモデムを使用しているなら, あなたに残された選択肢は ほぼ間違いなく PPP インストールでしょう. インストール時に必要になりますので, サービスプロバイダ (ISP) に関する情報を用意しておきましょう. 少なくともプロバイダと, 可能ならあなたの IP アドレスを知っておかなくては なりません (IP アドレスの欄を空白にしておいて, PPP に IP アドレスの 割り当て処理をさせてもかまいません). PPP ダイヤルの際は, とても シンプルな端末エミュレータで作業することになりますので, お手持ちのモデムで ISP にダイヤルするために, ``ATコマンド'' の使い方を知っておく必要があります. FreeBSD (2.0R 以降) の動いている別のマシンと直接接続が可能でしたら, ``laplink'' パラレルポートケーブルで接続することを考えてみましょう. パラレルポート経由のデータ転送スピードは, シリアルラインでの 一般的なスピード (最高 50kbit/sec) よりもずっと高速ですので, 高速にインストールすることができます. 最後になりますが, ネットワークインストールのうちでもっとも高速なものとしては イーサネットアダプタを使用するのがあげられます. FreeBSD ではきわめて多くの PC イーサネットカードをサポートしています. サポートされている カードの表 (と, 必要な設定) は, に書いてあります. サポートされている PCMCIA カードを使っている場合には, ラップトップの電源を 入れる「前」に差し込んでおくことにも注意してください. 残念ながら今の FreeBSD は, インストール時の活線挿抜には対応していません. ネットワークでの IP アドレス, あなたのアドレスクラスに対応した ネットマスク, マシン名を知っておくことも必要です. ネットワーク管理者の方に たずねればどんな値を使ったらよいかを教えてくれるでしょう. もしも他のホストを IP アドレスではなくて名前で引きたい場合, ネームサーバとゲートウェイ のアドレスも知らなくてはなりません (PPP をご使用の場合は, プロバイダの IP アドレスになります). これらのうちのすべて, またはいくつかを 知らない場合は, イーサネット経由でのインストールを始める前に「まず」 ネットワーク管理者に相談してください. 何らかのネットワーク接続ができたら, 続けてインストールを NFS か FTP 経由でおこないます. 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 ファイルでは, このことは ``-alldirs'' オプションによって制御されています. 他の NFS サーバの場合だとまた話が違ってくるかもしれません. もしもサーバから `Permission Denied' というメッセージが 返ってくるようでしたら, サブディレクトリマウントをちゃんと 有効にできていないことが考えられます. FTP インストールのための下準備

FTP 経由のインストールは, FreeBSD &rel.current; の最新バージョンを ミラーしているどのサイトからでも可能です. 世界中の妥当な FTP サイトの 選択肢をメニューに並べておきました. このメニューに出ていない他の FTP サイトからインストール する場合や, ネームサーバの設定に問題が生じた場合は, メニューでサイト ``Other'' を選ぶところで, お好みの URL でサイトを指定することができます. URL として直接 IP アドレスで指定してもよく, 直接指定した場合はネームサーバ がなくても FTP インストールが可能になります. 例えば, ftp://192.216.222.4/pub/FreeBSD/&rel.current;-RELEASE のような感じですね. FTP 経由のインストールモードとして, このようなものが 使用可能です: FTP Active すべての FTP 転送の際に ``Active'' モードを使用します. ファイアウォール内部のマシンではうまく動きませんが, passive モードをサポートしていない古い FTP サーバでも 動作します. passive モードでの FTP 転送 (こちらが デフォルトです) が失敗した場合は, active を使ってください. FTP Passive すべての FTP 転送の際に ``Passive'' モードを使用します. このモードを使用することで, ランダムポートアクセスインを 許さないファイアウォールを越えることができるようになります. 注意: Active, passive モードは `proxy' 接続のような, FTP の proxy サーバがことなるポートを監視している ような接続とはまた違います. このような場合は, URL に例えば ftp://foo.bar.com:1234/pub/FreeBSD のような表記を使うことができます. ここで, ``1234'' は proxy FTP サーバのポート番号です. FreeBSD のインストール

インストールの下準備を適切に書き留めておけば, なんの 問題もなく FreeBSD のインストールができることと思います. 何かうまくいかなかった場合は, あなたが使おうとしている インストールメディアのことが書いてある箇所まで戻って もう一度読むとよいでしょう. おそらく最初読んだときに 見落していた, 有効なヒントがあるものと思います. ハードウェアの問題が出てきたとか, FreeBSD がまったく 立ち上がらない場合は, boot フロッピーディスクに提供されている Hardware Guide を読んで, 何か解決方法はないか探してください. FreeBSD のブートフロッピーディスクには, インストールをおこなうために 必要と思われるすべてのオンラインドキュメントを用意してあります. もしもそのドキュメントがお望みのものでないようでしたら, 私たちはあなたが何にもっとも困っているのかを知りたいと思います. コメントを &a.doc; にお送りください. FreeBSD のインストールプログラム (sysinstall) を, うっとうしい ``step-by-step'' ガイドなしに, プログラム自身で使用方法がわかるようにするのが最終目標です. 目標達成までには時間がかかりそうですが, ともかくそれが 目標なのであります. 閑話休題. ここに, 「典型的なインストールの手順」を まとめてみましたので, お役にたてるものと思います. ブートフロッピーディスクから起動します. ハードウェアの性能に よりますが, 起動には 30秒から 3分かかります. 起動したら 初期選択画面が出てくるでしょう, もしもフロッピーディスクから まったく起動しなかったり, どこかの段階で起動が止まってしまった 場合は, ハードウェアガイドの Q&A を読んで, 理由を 探ってみます. F1 キーを叩きます. メニューシステムとインストールプログラム 全般に対しての使い方が表示されます. このメニューシステムを 使ったことがない場合は, 「徹底的に」読んでください. Options を選択し, 他に必要な特別な選択を おこないます. 典型的なインストールでおまかせしたい方は Novice を, インストールのそれぞれの段階をいちいちコントロールしたい方は Custom を, (可能であれば適切なデフォルトを使用して) 簡単にさっさと済ませたい方は Express を, それぞれ好みに応じて選んでください. FreeBSD を初めて使う方には, Novice を一番におすすめします. final configuration メニューからは, メニュー形式のさらに 進んだ設定をおこなうことができます. ネットワーク周りの 設定は, 特に CD-ROM / テープ / フロッピーディスクから インストールして, まだネットワーク設定をおこなっていない 人にとっては特に重要でしょう. インストールの時点できちんと 設定しておけば, ハードディスクからシステムを立ち上げ直した 時点でネットワーク接続ができるようになっていることでしょう. MS-DOS ユーザのためのQ&A

多くのFreeBSD ユーザは, MS-DOS が入っている PC に FreeBSD を インストールしたいと考えます. そのようなシステムに FreeBSD をインストールする際によく聞かれる質問を集めて あります.

助けて! ディスクスペースが余ってないのです. 最初に MS-DOS のファイルを全部削除しないといけませんか? もしあなたのマシンですでに MS-DOS が走っていて, FreeBSD の インストール用の空きスペースが少ないか, まったくない場合でも 大丈夫です. FreeBSD の CD-ROM や, FTP サイトの tools ディレクトリに FIPS プログラムというのがありますが, これが非常に役立ちます. FIPS を使えば, すでに存在している MS-DOS のパーティションを 二つに分けることができ, さらにもともとのパーティションは 残してくれて, 二つめのパーティションを FreeBSD の インストールに使用することができるようになります. まず DOS6.xx についてくる DEFRAG か, Norton Disk ツールを使って, MS-DOS パーティションからフラグメント情報を取り去って, その後に FIPS を走らせます. FIPS ユーティリティから必要な情報が 手に入ります. その後マシンを立ち上げ直して, 空いた場所に FreeBSD をインストールします. どのくらいの空きスペースが インストールに必要かは, Distributions メニューを 参考にしてください. FreeBSD で MS-DOS の圧縮ファイルシステムにアクセス できますか? いいえ. もし Stacker(tm) や DoubleSpace(tm) のような ユーティリティをお使いの場合, FreeBSD は非圧縮の部分にしか アクセスできません. 残りの場所は一つの大きなファイルとして (stack された, もしくは doublespace されたファイルとして) 見えます. そのファイルを削除しないでください!! 削除してしまうと後できっと後悔します. 非圧縮の MS-DOS の基本区画を作って, そちらを MS-DOS と FreeBSD とのやり取りに使うのがよろしいでしょう. MS-DOS 拡張フォーマットをマウントできますか? はい. DOS 拡張パーティションは FreeBSD の他の「スライス」の最後に マップされます. 例えば D:ドライブ が /dev/sd0s5, E:ドライブが /dev/sd0s6, といった具合いです. もちろん, この例では拡張 パーティションが SCSI ドライブ 0 にあることを仮定しています. IDE ドライブでは当然, ``sd'' が ``wd'' となります. 他の DOS ドライブを マウントするのと同様に, 次のようにして拡張パーティションもちゃんと マウントできます: mount -t msdos /dev/sd0s5 /dos_d MS-DOS のバイナリを FreeBSD で実行できますか? まだです. この機能を実現するためのサポートを期待しているのですが, いまのところ実際にこの作業をしている人間はいません. BSDI には 寄贈された BSD 用の DOS エミュレータがあり, 徐々に FreeBSD-current に移植されつつあります. もしあなたがこの作業に加わりたいと思いましたら &a.emulation にご連絡ください. それまでの間, には, pcemu という素晴らしいアプリケーションがあり, これをつかうことで多くの MS-DOS のテキストモードで動くプログラムを完全な 8088CPU の エミュレーション環境で走らせることができます. diff --git a/ja_JP.EUC/handbook/isdn.sgml b/ja_JP.EUC/handbook/isdn.sgml index 7049295877..448c1e8720 100644 --- a/ja_JP.EUC/handbook/isdn.sgml +++ b/ja_JP.EUC/handbook/isdn.sgml @@ -1,231 +1,231 @@ - + ISDN

最終更新: &a.wlloyd;.

訳: &a.kiroh;.11 December 1996.

ISDN 技術とハードウェアに関しては, がよい参考になるでしょう. ISDN の導入手順は, 簡単にいって以下のようになります. ヨーロッパ在住の方は, ISDN カードの節に進んでください. ISDN を使って, インターネットプロバイダに(専用線は使用せず), ダ イアルアップ接続しようとしている場合は, ターミナルアダプタの使用を考え てみてください. この方法はもっとも柔軟性があり, プロバイダを変更した場 合の問題も少ないでしょう. 2つの LAN の間を接続しようする場合や, ISDN 専用線を使用する場合 には, スタンドアローンルータ/ブリッジの使用を勧めます.

どの方法を用いるかを決定するには, 費用が重要な要素になってきます. 以下に, 最も安価な方法から, 高価な方法まで順に説明していきます. ISDN カード

原著者:&a.hm;.

このセクションの記述は, ヨーロッパの ISDN ユーザにのみ有効です. サポートされているカードは, まだ北米の ISDN 標準には適合していないかもしれ ません(?).

このコードは, まだ大部分が開発段階にあります. とくにドライバに関し ては, 二つのメーカーのカードしかサポートしていません.

PC ISDN カードは, ISDN の最大のバンド幅 128Kbs をサポートします. こ れらのカードは, ISDN 機器のうちもっとも安価な部類に入ります.

FreeBSD 2.1.0 および 2.1.5 では, 初期の未完成の ISDN のためのコード が /usr/src/gnu/isdn に含まれていますが, 古いバージョンのものですの で使用しないでください. カーネルから ISDN をサポートしたい場合は, bisdn パッケージを入手してください. このコードは, FreeBSD 2.2 からメイ ンソースツリーから削除されています.

bisdn という ISDN パッケージが以下のURLから入手できます. FreeBSD 2.1R, FreeBSD-current, NetBSDがサポートされています. 最新のソースは, 上記のftpサーバの isdn ディレクトリから, bisdn-097.tar.gz という名前で入手できます. 以下のカードのドライバが存在します: EuroISDN (DSS1)および1TR6プロトコル用には, 現在すべての(passive) Teles カードおよびそのクローンがサポートされています. Dr. Nauhaus - Niccy 1016 bisdn には, いくつかの制限があります. 特に ISDN に関連する機能のうち, 以下の機能はサポートされません. PPP はサポートされません. raw hdlc のみです. すなわち, Cisco 製 など, ほとんどのスタンドアロンーンルータ等とは接続できません. ブリッジングコントロールプロトコルはサポートされません. 複数のカードは同時に使用できません. 動的なバンド幅の変更はできません. チャンネルのバンドリングはできません. majordomoによるメーリングリストが利用できます. 参加するには, 通常の majordomo リクエストを以下のメールアドレスまで送ってください. . ISDN ターミナルアダプタ

ターミナルアダプタ (TA) はISDN に対して, 通常の電話線に対するモデ ムに相当するものです.

ほとんどの TA は, 標準のヘイズ AT コマンドセットを使用しているので, 単にモデムと置き換えて使うことができます. TA は, 基本的にはモデムと同じように動作しますが, 接続方法は異なり, 通 信速度も古いモデムよりはるかに速くなります. の設定を, モデムの場合と同じように行ってください. とくにシリアル速度を 使用できる最高速度に設定するのを忘れないでください. プロバイダへの接続に TA を使用する最大のメリットは, 動的 PPP を行える ことです. 最近 IP アドレスが不足してきているため, ほとんどのプロバイダ は, 専用の IP アドレスを割り当てないようになっています. ほとんどのスタ ンドアローンルータは, 動的 IP アドレスに対応していません. 訳注: 最近の ISDN ルータでは, IP アドレスの動的割り当てに対応している ものも多いようです. ただし制限がある場合もありますので, 詳しくはメーカ に問い合わせてください. TA を使用した場合の機能や接続の安定性は, 使用している PPP デーモンに完 全に依存します. そのため, FreeBSD で PPP の設定が完了していれば, 使用 している既存のモデムを ISDN の TA に簡単にアップグレードすることができ ます. ただし, それまでの PPP のプログラムに問題があった場合, その問題 は TA に置き換えてもそのまま残ります. 最高の安定性を求めるのであれば, ユーザープロセス ではなく, カーネルを使用してく ださい.

以下の TA は, FreeBSD で動作確認ずみです. Motorola BitSurfer および Bitsurfer Pro Adtran 他の TA もほとんどの場合うまく動作するでしょう. TA のメーカーでは, TA がほとんどの標準モデム AT コマンドセットを受け付けるようにするよう, 努 力しているようです. 外部 TA を使う際の最大の問題点は, モデムの場合と同じく良いシリアルカー ドが必要であるということです. シリアルデバイスの詳細, そして非同期シリアルポートと同期シリアルポート の差については, ハンドブックの の 節を参照してください. 標準の PC シリアルポート(非同期)に接続された TA は, 128Kbs の接続を行っ ていても, 最大通信速度が 115.2Kbs に制限されてしまいます. 128Kbs の ISDN の性能を最大限に生かすためには, TA を同期シリアルカードに接続しな ければなりません. 内蔵 TA を購入して, 同期／非同期問題を片付けてしまおうとは思わないでく ださい. 内蔵 TA には, 単に標準 PC シリアルポートのチップが内蔵されてい るだけです. 内蔵 TA の利点といえば, シリアルケーブルを買わなくていいと いうことと, 電源コンセントが一つ少なくて済むということくらいでしょう. 同期カードと TA の組合せは 386 の FreeBSD マシンの場合でも, スタンドア ローンのルータと同程度の速度は確保できます. またこの組合せでは, ルータ より柔軟な設定が可能です. 同期カード/TA を選ぶか, スタンドアローンルータを選ぶかは, 多分に宗教的 な問題です. メーリングリストでもいくつか議論がありました. 議論の内容に ついては, を参照してください. スタンドアローン 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 などすべての プロトコルのパケットを中継することが可能です.

diff --git a/ja_JP.EUC/handbook/kerberos.sgml b/ja_JP.EUC/handbook/kerberos.sgml index be8f94d7ec..c8979f6f4d 100644 --- a/ja_JP.EUC/handbook/kerberos.sgml +++ b/ja_JP.EUC/handbook/kerberos.sgml @@ -1,492 +1,492 @@ - + Kerberos

原作: &a.markm; (&a.md; からの寄稿に基づいています). 訳: &a.arimura;. Kerberosは, サーバのサービスによってユーザが安全に認証を受けられる ようにするための, ネットワークの付加システム及びプロトコルです. リモートログイン, リモートコピー, システム間での安全なファイルのコピ ーやその他のリスクの高い仕事がかなり安全に, そしてこれまでより制御 できるようになります. 以下の文章は, FreeBSD用として配布されているKerberosをセットアップ する際のガイドとして読むことができます. しかし, 完全な説明が必要な場合には, マニュアルページを読んだ方がよい でしょう. FreeBSDのKerberosは, オリジナルの4.4BSD-Liteの配布に含まれている ものではなく, FreeBSD 1.1.5.1のときに移植されたeBonesです. これはアメリカ/カナダの外で作成されており, これら以外の国の人々にも 手に入れられるものです. このソフトウェアを合法的な配布物として得るために, アメリカも しくはカナダのサイトから持ってこないでください. でないと, そのサイトが大変な問題に巻き込まれます. 合法的な配布は, 南アフリカのskeleton.mikom.csir.co.zaから 入手することができます. 初期データベースの作成

この作業はKerberosサーバだけでおこないます. まず, 古いKerberosの データベースが存在しないことを確認してください. ディレクトリ/etc/kerberosIVに移って, 次のファイルだけが 存在することをチェックします: grunt# cd /etc/kerberosIV grunt# ls README krb.conf krb.realms

もし他のファイル (principal.*やmaster_key) が 存在する場合には, kdb_destroyというコマンドで古い Kerberosデータベースを消してください. Kerberosが走っていなければ, 単にrmで余計なファイルを消せ ばよいです. まず, krb.confとkrb.realmsを編集してKerberosの 管理領域 (realm) を定義してください. ここでは管理領域がGRONDAR.ZA で, サーバ名がgrunt.grondar.zaであるとします. krb.confというファイルを次のように編集してください: grunt# 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は次のようになります: grunt# 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コ マンドを次のように実行してください: grunt# 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コマンドを使用します. grunt# 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といったコマンドを実行したりできるよ うになります. それでは実際にこれらのエントリを追加しましょう: grunt# 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 , 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 , 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の運用において重要なも のです. grunt# ext_srvtab grunt Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Generating 'grunt-new-srvtab'....

このコマンドは一時的なファイルを作成するだけです. ファイル名をすべ てのサーバが読めるようなsrvtabという名前に変更しな ければなりません. mvコマンドを用いてシステムの場所に移動 してください. grunt# mv grunt-new-srvtab srvtab

そのファイルがクライアントに配るためのもので, ネットワークが安全で はないと思われる場合には, <client>-new-srvtabを移動 可能なメディアにコピーして物理的に安全な方法で運んでください. クラ イアントの/etc/kerberosIVディレクトリで, 名前を srvtabに変更し, modeを600にするのを忘れないでください: grumble# mv grumble-new-srvtab srvtab grumble# chmod 600 srvtab データベースへのユーザの追加

ここで, ユーザのエントリをデータベースに追加する必要があります. 始めに, ユーザjaneのエントリを作成してみましょう. kdb_editを用いて次のように作成してください: grunt# 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: , 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/sysconfigファイルを正しく編集してあれば, マシンを再 起動することでに自動的にデーモンが起動します. これはKerberosサー バでのみ必要です. Kerberosクライアントは/etc/kerberosIVか ら必要なものを自動的に入手します. grunt# kerberos & grunt# 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 grunt# kadmind -n & grunt# 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コマンドで得ることができます: grunt$ kinit jane MIT Project Athena (grunt.grondar.za) Kerberos Initialization for "jane" Password:

klistコマンドを用いてトークンを見て, きちんとチケットを持って いるかどうか確認してください: grunt$ 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データベースに対して認証されるかどうかチェックして ください: grunt$ passwd realm GRONDAR.ZA Old password for jane: New Password for jane: Verifying password New Password for jane: Password changed. su特権の追加

root権限が必要なユーザは誰でも, suコマンドのパス ワードをユーザ毎に別のものとして持つことができます. rootにsuできる権利を与えられたidを追加します. これは, principalに付いているrootというインスタンスに よって制御されています. kdb_editを用いて jane.rootというエントリをKerberosデータベースに作成します: grunt# 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 , 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: <---- 何も入力しないと終了します

実際にトークンをもらって, ちゃんと働いているかどうか確認しましょう: grunt# kinit jane.root MIT Project Athena (grunt.grondar.za) Kerberos Initialization for "jane.root" Password:

ここでrootユーザの.kloginファイルにユーザを追加する必要が あります. grunt# cat /root/.klogin jane.root@GRONDAR.ZA

suしてみましょう: [jane@grunt 10407] su Password: grunt# どのトークンを持っているか見てみましょう: grunt# 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することができま す. grunt# cat /root/.klogin jane.root@GRONDAR.ZA

同様に, ユーザのホームディレクトリの.kloginファイルに次の ような行がある場合には: [jane@grunt 10543] cat ~/.klogin jane@GRONDAR.ZA jack@GRONDAR.ZA

janeまたはjackという名前で (前述のkinit によって) 認証されているGRONDAR.ZAという管理領域のユーザ なら誰でもrloginやrsh, rcp等によってこ のシステム (grunt) のjaneのアカウントまたはファ イルにアクセスできます. 例えば, Janeが他のシステムにKerberosを用いてloginします: [jane@grumble 573] kinit MIT Project Athena (grunt.grondar.za) Password: [jane@grumble 574] 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 [jane@grunt 10567]

次の例では, Jackが同じマシンのJaneのアカウントにloginします. Janeは .kloginファイルを前述のように設定しており, Kerberosではjackというprincipalをインスタンスなしで設定してあ ります. [jack@grumble 573] kinit [jack@grumble 574] 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 [jane@grunt 10578] diff --git a/ja_JP.EUC/handbook/kernelconfig.sgml b/ja_JP.EUC/handbook/kernelconfig.sgml index 8aacdcc0c9..a2ef298e8e 100644 --- a/ja_JP.EUC/handbook/kernelconfig.sgml +++ b/ja_JP.EUC/handbook/kernelconfig.sgml @@ -1,1249 +1,1249 @@ - + FreeBSDカーネルのコンフィグレーション

原作: &a.jehamby;. 6 October 1995.

訳: &a.tomo;, &a.yoshiaki;. 2 November 1996. この章はシステムに合わせたカーネルの再構築の基礎について 述べたものです. この章は, システム管理の初心者から Unixシステム管理に十分な経験を積んだ人までを対象としています. なぜカスタムカーネルを作るか?

システムに合わせたカーネルはすべての Unixシステム管理者が 避けて通ることのできない最も重要な通過儀礼の1つです. この作業は, 多くの時間を必要としますが, あなたの FreeBSD システムに多くの利益をもたらします. GENERICカーネルは, めったに使われることのないハードウェアをサポートするとともに, 考えられるすべての SCSIカードやネットワークカードをサポート しなければなりませんが, システムに合わせたカーネルは あなたの PC のハードウェアのみをサポートします. これは, 次にあげるような利益をもたらします. あなたが持っていないハードウェアについては検出をおこなわな いので, ブートにかかる時間が短くなります. システムに合わせたカーネルは多くの場合メモリ使用量が 減ります. カーネルはいつもメモリ上に存在するので, 不必要なコードがあると本来プログラムが利用できるはずの RAM (実メモリ) を占めてしまいますのでこれは重要なことだ といえます. したがって, メモリが少ないシステムでは, カーネルの再構築は大変重要です. 必要に応じていくつかのカーネルオプションは調整すること ができ, またサウンドカードのような GENERICカーネルには ないデバイスドライバをカーネルに含めることが できます.

カスタムカーネルの構築とインストール

まず, カーネル再構築に必要なディレクトリをざっと見てみましょう. ここではディレクトリはすべて /usr/src/sys以下の相対位 置で示します. また, /sysからもアクセス可能です. ここには, カーネルの各部分を構成するサブディレクトリが いくつもあります. しかし, 私たちの目的では 最も重要なのは i386/confです. ここで, あなたの システムに合わせてカーネル コンフィグレーションを編集します. それから compileディレクトリ, ここはカーネルが作られる 場所です. サポートされているデバイスやファイルシステムのディレ クトリツリーがオプション毎にサブディレクトリに分かれている論理 的構成に注意してください. また, i386のディレクトリは PCのハードウェアのみを扱い, i386以外のディレクトリは FreeBSDが他のプラットフォームに移植される際には共有されるコー ドです. /usr/src/sys 以下のディレクトリがなければ, カーネルのソースが インストールされていません. パッケージのインストール手順にしたがっ て, システムにインストールしてください. つぎに, i386/confに移動して, GENERIC コンフィグレーションファイルをカーネルに与えたい名前に コピーしてください. たとえば： # cd /usr/src/sys/i386/conf # cp GENERIC MYKERNEL 慣習として, この名前はすべて大文字でつづられます. もし, いくつかの異なるハードウェアの FreeBSDマシンを扱うなら, この名前にホスト名を含めるとよいでしょう. ここでは, 例として MYKERNEL と呼ぶことにします. では, MYKERNELをあなたの好きなエディタで編集してください. もし, システムをインストールしたばかりならば, 利用できる エディタは viだけかもしれません. ここでは使い方 の説明はしませんが, にあるような多くの本で詳しく説明 されていますので, そちらを参照してください. まずファイルの最初の方のコメント行を編集し, あなたのコンフィグ レーションに合せて変更した点などを記述して GENERICと区別がつく ようにしておきましょう. もし SunOSや他の BSDオペレーティングシステムでカーネルの 再構築をしたことがあれば, このファイルはとても親しみ やすいでしょう. しかし, DOSのようなその他の オペレーティングシステムしか知らない人から見れば, GENERICコンフィグレーションファイルはとても なじみにくいものかもしれません. そのような場合は, の節をゆっくりと注意深く読んでください. config(8)を取ってくる必要があるかもしれません. これは /usr/src/usr. sbinにあります. したがってこれらのソースをダ ウンロードする必要があります. 次のコマンドを実行する前に (configを)作りインストールをしておいてください. 編集し終ったら, 次のコマンドによってコンパイル, インストール を行ってください. # /usr/sbin/config MYKERNEL # cd ../../compile/MYKERNEL # make depend # make # make install 新しいカーネルはルートディレクトリに /kernelという 名前でコピーされ, 今までのカーネルは /kernel.old という名前へ変更されます. では, システムをシャットダウン, リブー トして新しいカーネルを使ってください. うまく行かない場合は, この章の終りの を参照してください. この章の新しい 場合のリカバリの方法を注意深く読んでおいてください. /devディレクトリで デバイスノードを追加しなければならないかもしれません. 詳しくは, を読んでください. コンフィグレーション ファイル

コンフィグレーション ファイルの一般的なフォーマット はとてもシンプルです. 各行は1つのキーワードと1つ以上の 引数を含んでいます. 見やすくするために, ほとんどのキーワードは 引数を1つしか書いてありません. #に続くものはすべてコメントとして扱われ, 無視されます. ここでは, それぞれのキーワードについて だいたい GENERICに出てくる順番で説明します. しかし, お互いに関係のあるキーワードは, 実際には GENERICファイル上に バラバラに現れていても, (ネットワーキングのように)1つにまとめ てあります.

カーネルは現在, オプションを扱う方法をよりよい機構に移行しよ うとしています. 従来は, 各々のオプションは単純にカーネルの Makefile中の CFLAGS行の -Dスイッチに変換されて いました. 自然とオプションは際限なく増えて行きます. だれも実際に はどのオプションがどのファイルで参照されているかは知りません.

新しい方法では、すべてのオプション依存の #ifdefは当該オプショ ンを opt_foo.h (これらのファイルはconfigによって compileディレ クトリに作られます) から読み込むように変わりました. config の有効なオプションのリストは2つのファイルにお かれます. アーキテクチャに依存しないオプションは /sys/conf/optionsに置かれ, アーキテクチャ依存のオプショ ンは/sys/arch/conf/optionsに置かれま す. archの部分は例えば i386となります. 必須キーワード

ここにあるキーワードはカーネルの構築に必要不可欠です. machine ``i386''

最初のキーワードは machineです. FreeBSDは Intelの 386とその互換チップ上でしか 動かないので, i386を指定します. 注: 数字を含むキーワードはすべて クォーテーションマークで囲む必要があります. そうしないと, configは混乱し, 386を実際の数値として扱ってしまいます. cpu ``cpu_type''

次のキーワードは cpuです. FreeBSDでサポートしている CPUの中から記述します. cpu_typeとして指定可能な値は 次の通りです. I386_CPU I486_CPU I586_CPU I686_CPU GENERICカーネルのように cpuの行の cpu_typeが異なった値を持つものが 複数あってもかまいません. カスタムカーネルでは, あなたが持っている cpuを1つだけ指定するのが 一番です. 例えば, もし Intelの Pentiumを持っていれば, cpu_typeには, I586_CPU を使ってください. ident machine_name

次は, カーネルの識別名となるidentです. GENERICからあなたがカーネルに与えたい名前に 変えてください. ここでは, MYKERNELとします. identに与えた名前はカーネルの ブート時に表示されるので, 普段のカーネルとは別に カーネルに違う名前を与えたいとき(例えば, 実験用のカーネルを作りたい時など), 便利でしょう. 数字を含む名前にしたい場合は machineや cpuの時と同じようにクォーテーションマークで 囲む必要があります. Cコンパイラに -Dスイッチで渡されるので, DEBUGのような名前にしたり, vax といった他のCPUの名前など紛らわしい名前にしないで ください. maxusers number

これは, 重要なシステムテーブルのサイズを決めます. ここ で与えられる数字はマシンに同時にログインすると考えられ るおよそのユーザ数です. しかし, 通常の使用環境であれば, 特に X Window System を立ち上げたり, ソフトウェアを コンパイルするような使用であれば maxusersには少 なくとも4以上を指定したほうがいいでしょう. その理由は, maxusersで決るテーブルで最も重要なものはプロセス の最大数であるからです. プロセス最大数は 20 + 16 * maxusersで与えられ, maxusersを1 にすると36プロセスしか同時には持てません. この中にはブー ト時にシステムによって起動する18個ぐらいのプロセス, Xを 起動する時の15程度のプロセスも含みます. manページを読むという1つのタスクでさえ, フィ ルタやファイル伸長や表示のために9つのプロセスを起動し ます. maxusersを4にすれば, 同時に84個のプロセ スを持つことができるのでどんな人でも十分な数だといえる でしょう. それでも他のプログラムを起動した場合に, あるいは, (Walnut Creek CDROMのFTPサイトのように) 同時に多くの ユーザを抱えるサーバを走らせた場合に ``proc table full''というおぞましいエラーが起きる場合はこの値を増や し, カーネルを再構築してください. maxuserはあなたのマシン にログインできるユーザの数を制限するものでは ありません. 単に, あなたのシステムに ログインするユーザ数の最大値と各々のユーザが いくつのプロセスを走らせるかを考慮することに よってさまざまなテーブルの値を適切な値に設定 するだけです. これに対し, の remote loginsというキーワードは 同時にリモートログインできるユーザ数を制限 します. config kernel_name root on root_device

これはカーネルの位置と名前を特定します. 伝統的にカーネルは vmunixと呼ばれますが, FreeBSDでは kernelとふさわしい名前になりました. kernel_nameにはいつも kernelを 使ってください. 名前を変えると多くのシステム ユーティリティが使えなくなります. 2番目の部分は ルートファイルシステムとカーネルのあるディスクと パーティションを指定してください. SCSIドライブでなければ, wd0を, SCSIドライブならば sd0です. 一般的なオプション

以下はカーネルのサポートするさまざまなファイルシステムおよ びその他のオプションです.

これは, 数値演算コプロセッサがない コンピュータ (386や486SX) で数値演算コプロセッサ のエミュレーションを可能にします. もし, Pentiumや 486DX, あるいは387や487があれば, コメントアウト できます. 注: FreeBSD付属の数値演算 コプロセッサエミュレータはあまり正確では ありません. 非常に正確な計算をおこないたい ならば, より優れた GNUのエミュレータである GPL_MATH_EMULATEに変えることを おすすめします. これはライセンスの関係でデフォルトでは 含まれていません. options ``COMPAT_43''

4.3BSDとの互換性のためのオプションです. そのままにしておいてください. コメントアウトすると, いくつかのプログラムで動作がおかしくなります. options BOUNCE_BUFFERS

ISAデバイスやISA互換モードで動作する EISAデバイス では DMA (Direct Memory Access) は16MB以下のメモリに対し てのみ動作します. このオプションによりメモリが16MB以上 のシステムでDMAを使うデバイスを動作させることができます. options UCONSOLE

ユーザがコンソールを横取り (grab) できるようにします. これは X Window System 上で便利です. 例えば, コ ンソール xtermを xterm -Cとタイプして作ると, そこに `write', `talk'などのメッセージがカーネルからコ ンソールへ送られるメッセージと同じように表示されます. options SYSVSHM

このオプションは System V の共有メモリを提供します. 最もよく利用されるのは X Window System の XSHM拡張 です. これは多くのグラフィックを多用したプログラム (movie player の Xanimや Linux DOOMなど) では自動的に高速 になるという利点があります. X Window System を利用するのであればこれは間違いな く含めたくなるでしょう. options SYSVSEM

System V のセマフォをサポートします. 一般的に利用される ことは少ないですがカーネルサイズの増加は数百バイトだ けです. options SYSVMSG

System V のメッセージをサポートします. これを指定した場 合もカーネルサイズの増加は数百バイトだけです. ipcs(1) コマンドは これらの System V の機構を利用しているプロセスを表示し ます. 訳注: 共有メモリ, セマフォ, メッセージ(メッ セージキュー) は System V系 で一般的なプロセス間通信の機 構です. くわしくは System Vのプロセス間通信に関する文 献, 「詳解 UNIXプログラミング」 (ソフトバンク) , 「UNIXネッ トワークプログラミング」 (トッパン) などを参照してくださ い. ファイルシステムオプション

これらのオプションはさまざまなファイルシステムへのサポート を追加します. 少なくともブートするためのデバイスのサポートを含 める必要があります. 標準的にはハードディスクからブートするので あれば FFS , ディスクレスワークステーションとしてイー サネットからブートするのであれば NFSです. 一般的に利用される他のファイルシステムをカーネルに含め, あまり 利用しないファイルシステム (多分 MS-DOSファイルシステム?) のサポー トをコメントアウトすることができます. これは Loadable Kernel Module ディレクトリ /lkm から, 最初にそのタイプのファイ ルシステムがマウントされる時に動的にドライバがロードされるからです. options FFS

基本的なハードドライブ ファイルシステムです. ハードディ スクからブートする場合は残しておいてください. options NFS

ネットワーク ファイルシステムです. Ethernet経由で Unixファ イルサーバからパーティションをマウントする予定がない場 合はコメントアウトすることができます. options MSDOSFS

MS-DOS ファイルシステムです. ブート時に DOSフォーマット のハード ドライブをマウントする予定のない場合はコメン トアウトしても安全です. 先に示したように, DOSパーティ ションをマウントする時に自動的にロードされます. また (ports コレクションにある) mtools という素晴 らしいソフトウェアにより mount , unmountなしで DOSフロッ ピーにアクセスすることができます (これは MSDOSFSも必要 ありません). options ``CD9660''

CD-ROMのための ISO 9660 ファイルシステムです. CD-ROMを 持っていないか, 時々 データ CDをマウントするだけならコ メントアウトしましょう (データ CDを最初にマウントする 時に動的にロードされます). オーディオ CDはこのファイル システムは必要ありません. options PROCFS

プロセス ファイルシステムです. これは疑似的なファイルシ ステムで /procにマウントされ, ps(1)などのプロ グラムがプロセスに関してより詳しい情報を与えてくれるよ うになります. options MFS

メモリマップド ファイルシステムです. これは基本的に一時 ファイルを記憶するための高速な RAMディスクで, 大きな swap領域がある場合に有効です. MFSパーティションをマウ ントするに適した場所は多くのプログラムが一時ファイルを 置く /tmpです. MFS RAMディスクを /tmp にマウントするには以下の内容を /etc/fstabに追 加してリブートするか mount /tmpとタイプします. /dev/wd1s2b /tmp mfs rw 0 0 /dev/wd1s2bをあなたが使用して いるswap パーティションに置き換えてください. これは以 下のように /etc/fstabに書かれているでしょう. /dev/wd1s2b none swap sw 0 0 /tmpデ バイスにアクセスすることはできません). そのためいまの ところは使わない方が無難です. --> また, MFSファ イルシステムは動的にロードすることはできません . したがって使いたい場合はコンパイル時に カーネルに含める必要があります. options QUOTA

ディスククォータを有効にします. アクセスが公開されてい るシステムで (一人のユーザが) /homeパーティショ ン (全体) をあふれさせることができないようにそれぞれのユーザ にディスククォータを発行することができます. このコードはいくらかバグがありますので必要のない場合は 使わないでください. ディスククォータについての詳しい内 容はマニュアルページの quota(1)を見てください. 基本的なコントローラとデバイス

この節では FreeBSDでサポートされているディスク, テー プ, CD-ROMコントローラについて示します. コントローラと カードについ ては別の節になっています. controller isa0

FreeBSDのサポートするすべての PCで必要です. IBM PS/2 (マイ クロチャネルアーキテクチャ) では現時点では FreeBSDは動 きません. controller pci0

PCIバスを持つマザーボードの場合は含めます. これにより PCIカードの自動認識と PCIから ISAバスへのゲートウェイが 可能になります. controller fdc0

フロッピードライブコントローラです. fd0 は ``A:'' ドライブで fd1 は ``B:'' ドライブです. ft0 は フロッピーコントローラに接続する QIC-80 テープドライブで す. 対応するデバイスがない場合はそれぞれの行をコメント アウトしてください. ft(8)というフィルタプログラムが必要です. 詳し くはマニュアルページを見てください. controller wdc0

プライマリIDEコントローラです. wd0 と wd1はそれぞれマスタ, スレーブドライブで す. wdc1 は セカンダリの IDEコントローラで3台 目, 4台目のハードディスクまたは IDE CD-ROMのある場合に 使います. 利用しない行はコメントアウトしてください (例え ば, SCSIハードディスクのみを使う場合は6行全部をコメント アウトしてもよいかもしれません). device wcd0

このデバイスは IDE CD-ROMのサポートをします. wdc0を有効にしておく必要があり, もし 2つ以上の IDE コントローラがあり, そのうちの 2つ目のカードに CD-ROMを接 続する場合 options ATAPIを書いておく必要もあります. device npx0 at isa? port ``IO_NPX'' irq 13 vector npxintr

npx0はFreeBSDハードウェアコプロセッサとソフト ウェアエミュレータ両方の浮動小数点演算ユニットへのインタ フェースです. これは device wt0 at isa? port 0x300 bio irq 5 drq 1 vector wtintr

Wangtek と Archive の QIC-02/QIC-36 テープドライブのサポートです. Proprietary CD-ROM support

以下のようなドライブを proprietary(独自の) CD-ROMドライブと呼ぶことにします. これらのドライブは専 用のコントローラを持つか, サウンドブラスタ16などのサウ ンドカードに接続します. これらは IDEでも SCSIでもあ りません. 多くの標準速や2倍速の古い CD-ROMはこれら のインタフェースを持っていますが, より新しい四倍速の ものは か でしょう. device mcd0 at isa? port 0x300 bio irq 10 vector mcdintr

ミツミ製 CD-ROM (LU002, LU005, FX001D)です. device scd0 at isa? port 0x230 bio

ソニー製 CD-ROM (CDU31,CDU33A)です. controller matcd0 at isa? port ? bio

松下/パナソニック製 CD-ROM (サウンドブラスタ用 クリエィティブ ラボ製として販売されていました) です. SCSI デバイスのサポート

この節では FreeBSDのサポートするいろいろな SCSIコント ローラとデバイスのサポートについて書きます. SCSI コントローラ

以下の十数行は異る種類の SCSIコントローラのサポートです. 使用しているもの以外の部分はコメントアウトしてください. controller bt0 at isa? port ``IO_BT0'' bio irq ? vector btintr

ほとんどの Buslogic社のコントローラです. controller uha0 at isa? port ``IO_UHA0'' bio irq ? drq 5 vector uhaintr

UltraStor 14F と 34F です. controller ahc0

Adaptec 274x/284x/294x です. controller ahb0 at isa? bio irq ? vector ahbintr

Adaptec 174x です. controller aha0 at isa? port ``IO_AHA0'' bio irq ? drq 5 vector ahaintr

Adaptec 154x です. controller aic0 at isa? port 0x340 bio irq 11 vector aicintr

Adaptec 152x や サウンドカードなどに使われている Adaptec AIC-6360 チップです. (slow!) controller nca0 at isa? port 0x1f88 bio irq 10 vector ncaintr

NCR 5380を使っている ProAudioSpectrum や Trantor T130 で す. controller sea0 at isa? bio irq 5 iomem 0xc8000 iosiz 0x2000 vector seaintr

Seagate ST01/02 8 ビットコントローラです. (slow!) controller wds0 at isa? port 0x350 bio irq 15 drq 6 vector wdsintr

Western Digital WD7000コントローラです. controller ncr0

NCR 53C810, 53C815, 53C825, 53C860, 53C875 チップを使った PCI SCSI コントローラです. options ``SCSI_DELAY=15''

このオプションによりカーネルはそれぞれの SCSIデバイスを プローブする前に 15秒間待ちます. IDEドライブのみを使用 している場合は無視して構いません. ブートを速くするため にこの数値を 5秒ぐらいまで小さくしたいでしょう. そうし た場合, FreeBSDが SCSIデバイスを認識しにくくなるかもし れません. その時は、もちろんこのオプションの値は元に戻 さないといけません. controller scbus0

SCSIコントローラがある場合, この行で SCSI全般のサポー トを与えます. SCSIのない場合, この行と以下の3つの行をコメ ントにすることができます. device sd0

SCSIハードディスクのサポートです. device st0

SCSIテープドライブのサポートです. device cd0

SCSI CD-ROM のサポートです.

上のエントリについている 0はいくらか誤解を招き やすいかもしれません. これらのデバイスはすべてカーネルが 見つけた時に割り当てがおこなわれ, SCSIバスに何台つながってい るか, ターゲット IDが何番であるかはここの記述とは関係あ りません. 明示的に「固定的な」ターゲット IDの特定のデバイスへの 割り当てをおこないたい場合は LINT カーネルコンフィグレーションファイルの 該当する部分の説明を参照してください. コンソール, バスマウス, Xサーバのサポート

2つのタイプのコンソールからどちらか1つを選ぶ必要があります. また X Window System を利用する場合, XSERVERオプションを有効に します. またバスマウスとPS/2マウスのオプションもあります. device sc0 at isa? port ``IO_KBD' tty irq 1 vector scintr

sc0 はデフォルトのコンソールドライバで SCOコン ソールに似ています. このデバイス, あるいは VT220コンパ チブルドライバの vt0いずれを使う場合もほとんど のフルスクリーンプログラムは termcapなどのターミ ナルデータベースライブラリを通してアクセスしますので, あまり違いはないでしょう. このコンソールを使う場合でフルスクリーンプログラムでト ラブルが起きる場合にはログインした時に TERM変数の値を ``scoansi''にしてください. device vt0 at isa? port ``IO_KBD'' tty irq 1 vector pcrint

これはVT-220コンパチブルコンソールドライバで VT100/102の 上位互換です. これは sc0の使えない種類のラッ プトップ機でもうまく動きます. ログイン時に TERM変数の値 を``vt100'' か ``vt220''にしてください. また, このドラ イバはネットワークを介して多くの異るマシンから接続する 場合も便利です. sc0デバイスのための termcapや terminfoエントリは必ずしも 利用できるわけではありませんが -- ``vt100''はいずれの プラットフォームでも利用可能でしょう. options ``PCVT_FREEBSD=210''

vt0 コンソールドライバを使う場合に必要で す. options XSERVER

これは XFree86 X サーバを動かすのに必要な コードを含めます. device mse0 at isa? port 0x23c tty irq 5 vector ms

Logitech や ATIのバスマウス入力カードを利用する場合のデ バイスです. ポート(おそらくはCOM1)を有効にしてくだ さい. device psm0 at isa? port ``IO_KBD'' conflicts tty irq 12 vector psmintr

このデバイスは PS/2マウスポートにマウスを接続する場合に 使います. シリアル, パラレルポート

ほとんどすべてのシステムにこれらはあります. プリンタを接続す る場合は の章が非常 に役に立つでしょう. モデムを使う場合は に非常に詳しいシリアルポートの設定とデ バイスの使い方があります. device sio0 at isa? port ``IO_COM1'' tty irq 4 vector siointr

sio0からsio3は MS-DOSにおける COM1から COM4に相当する4本のシリアルポートです. COM4に内蔵モデムがあり COM2を使う場合, FreeBSDからアク セスするためにはモデムのIRQを2へ変更する必要があるとい うことを注意しておきます (技術的な理由より IRQ 2 = IRQ 9となります). マルチポートシリアルカードを使う場合にマニュアルページ のsio(4)にはこのオプションで使う値などのよ り多くの情報があります. ビデオカードの中には (特に S3 チップベースのものには) IOアドレスの 0x*2e8から を利用するものがあり, また多くの安価なシリアルカードは IOアドレス空間を16-bitフルデコードしていませんので, こ れらのカードは衝突します. この場合 COM4ポートは実質上 利用できません. それぞれのシリアルポートは (割込みの共有をサポートした マルチポートカードを利用していないのであれば) 別々の IRQ を割り当てる必要がありますので COM3と COM4のデフォルトの IRQは利用できません. device lpt0 at isa? port? tty irq 7 vector lptintr

lpt0 から lpt2は利用可能な3本のプリン タポートです. 多くの場合は1本のみですので他の2本はない のであればコメントアウトして構いません. ネットワーク

FreeBSDでは他の一般的な Unixと同様にネットワークが 非常に 重視されています. イーサネットカードが なくても必須のオプションとダイヤルアップ ネットワークのサポー トに注意してください. options INET ネットワーキングのサポートです. ネットワークに接続する予定がな くても残しておいてください. 多くのプログラムは少なくともループ バックネットワーキングが必要です(つまり, PCの中でネットワーク コネクションをおこないます). したがってこのオプションは本質的 に不可欠です. Ethernet cards

以下にさまざまなイーサネットカードを有効にするオプショ ンを示します. ネットワークカードがなければこれらすべてを コメントアウトすることができます. そうでなければ利用す る特定のイーサネットカードをサポートするオプションを残 しておきます. device de0

DECの DC21040, DC21041, DC21140チップを使った PCIイー サネットアダプタです. device fxp0

Intel EtherExpress Pro/100B 高速イーサネットカード です. device vx0

3Com の 3C590, 3C595です (いくらか bugがあります). device cx0 at isa? port 0x240 net irq 15 drq 7 vector cxintr

Cronyx/Sigma の マルチポート同期/非同期カードです. (with Cisco or PPP framing) device ed0 at isa? port 0x280 net irq 5 iomem 0xd8000 vector edintr

Western Digital と SMC の 80xx, 8216 Elite Ultra ; ノベル NE1000, NE2000; 3Com の 3C503; HPの PC Lan Plus (HP27247B とHP27252A) です. device el0 at isa? port 0x300 net irq 9 vector elintr

3Com の 3C501 です. (slow!) device eg0 at isa? port 0x310 net irq 5 vector egintr

3Com の 3C505です. device ep0 at isa? port 0x300 net irq 10 vector epintr

3Com の 3C509 です(バグがあります). device fe0 at isa? port 0x240 net irq ? vector feintr

富士通 MB86960A/MB86965A ベースのイーサネットカード です. device fea0 at isa? net irq ? vector feaintr

DEC DEFEA EISA FDDI アダプタです. device ie0 at isa? port 0x360 net irq 7 iomem 0xd0000 vector ieintr

AT&T StarLAN 10 と EN100; 3Com の 3C507; NI5210 です. device ix0 at isa? port 0x300 net irq 10 iomem 0xd0000 iosiz 32768 vector ixintr

Intel の EtherExpress 16です. device le0 at isa? port 0x300 net irq 5 iomem 0xd0000 vector le_intr

DEC の EtherWorks 2 and EtherWorks 3 (DEPCA, DE100, DE101, DE200, DE201, DE202, DE203, DE204, DE205, DE422)です. device lnc0 at isa? port 0x300 net irq 10 drq 0 vector lncintr

Lance/PCnet カード (Isolan, Novell NE2100, NE32-VL)です. device ze0 at isa? port 0x300 net irq 5 iomem 0xd8000 vector zeintr

IBM/ナショナルセミコンダクタの PCMCIA イーサネット コントローラです. device zp0 at isa? port 0x300 net irq 10 iomem 0xd8000 vector zpintr

3Com の PCMCIA Etherlink III です. pseudo-device loop

loop は TCP/IPの一般的なループバックデバイスで す. telnet や FTPを localhost (127.0.0.1) に対してかけるとこの疑似デバイスを通して帰ってきます. 不可欠です. pseudo-device ether

etherはイーサネットカードがある場合のみ必要で 一般的なイーサネットプロトコルを含めます. pseudo-device sl number

sl は SLIP (Serial Line Internet Protocol) をサポー トします. これはほとんど完全に, より簡単に設定ができ, モ デム to モデム接続に適した, よりパワフルな PPPに取って代 わられています. slの後の number は同 時にいくつの SLIPセッションをサポートするかを示します. SLIPの設定のより詳しい情報はこのハンドブックの 「PPPとSLIP」の章の と について書かれた節にあります。 pseudo-device ppp number

pppはダイヤルアップ インターネット接続のための カーネルモード PPP (Point-to-Point Protocol) をサポート します. ユーザアプリケーションとして tun を 利用する PPPの実装もあり, こちらはより柔軟性がありデマ ンドダイアリング(プログラムが接続要求を出した時に自動 的にダイヤルをおこなう)などの機能もあります. それでもこ の PPPドライバを利用したい場合は の節を読んでください. slデバイスと同じように numberは同時 に PPP接続できる数を示します. pseudo-device tun number

tun はユーザモード PPPソフトウェアが利用しま す. このプログラムは設定が簡単で非常に高速です. また自動ダイヤル オン デマンドなどの機能を持ちます. tunの後のnumber は同時におこなうことのできる PPPセッションの数を示します. の節により多くの情報があ ります. pseudo-device bpfilter number

バークレイ パケットフィルタです. この疑似デバイスはネッ トワークインタフェースを無差別 (promiscuous) モードにし てネットワーク (例えば単一のイーサネット) にブロードキャス トされるすべてのパケットを取り入れることを可能にします. こ れらのパケットはディスクに取り入れられたり tcpdump(1) によって検査されます. この機能の実現 はネットワーク全体のセキュリティとの微妙な妥協点であるこ とに注意してください. bpffilter の後の numberは同時に検査することの できるインタフェースの数を示します. 危険の可能性について十分解っている場合を除いてこのオプ ションは奨めません. すべてのネットワークカードでこの機能 をサポートをしてはいません. サウンドカード

ここは GENERICカーネルに含まれていない最初のセクションです. サウンドカードのサポートをするためには LINTコンフィグレーショ ンファイル(これにはすべてのデバイスが含まれています)か ら以下のような適切な行をコピーする必要があります. controller snd0

サウンドドライバ一般のコードです. pcaを除く以下のすべてのサウンドカードで必要で す. device pas0 at isa? port 0x388 irq 10 drq 6 vector pasintr

ProAudioSpectrum のオーディオ と MIDI です. device sb0 at isa? port 0x220 irq 7 conflicts drq 1 vector sbintr

SoundBlaster です. irq 7をirq 5に書き換え, キーワード conflictsを削除し てください. さらに options ``SBC_IRQ=5''の行を 加える必要があります. device sbxvi0 at isa? drq 5

SoundBlaster 16 の 16-bit オーディオです. drq 5を適切な値に書き直 して, (DMA 6の場合) options "SB16_DMA=6"を付け 加えてください. device sbmidi0 at isa? port 0x330

SoundBlaster 16 の MIDI インタフェースです. SoundBlaster 16を使う場合必ずこの行を含めてコンパイル してください. device gus0 at isa? port 0x220 irq 10 drq 1 vector gusintr

Gravis Ultrasound です. device mss0 at isa? port 0x530 irq 10 drq 1 vector adintr

Microsoft Sound System です. device opl0 at isa? port 0x388 conflicts

AdLib FMシンセサイザオーディオです. AdLib, SoundBlaster, ProAudioSpectrum を使い playmidi (ports にあります) などのプログラムで MIDIの演奏をしたい場合にこの行を含めます. device mpu0 at isa? port 0x330 irq 6 drq 0

Roland MPU-401 カードです. device uart0 at isa? port 0x330 irq 5 vector ``m6850intr''

MIDIインタフェースの 6850 UART です. device pca0 at isa? port ``IO_TIMER1'' tty

PC のスピーカーを使ったオーディオです. これは非常に品質 が悪く, CPUの性能, 負荷に強く依存します, と言っておき ます (サウンドカードは必要ありませんが). /usr/src/sys/i386/isa/sound/sound.docにあります. また, これらのデバイスを追加する場合は, サウンドを作る必要があり ます. 疑似デバイス

疑似デバイスドライバはデバイスドライバと同様に働きますがマ シン上に対応する実際のハードウェアがないカーネルの部分です. 関連の 疑似デバイスはそちらのセクションに示しました. ここでは残りにつ いて示します. pseudo-device gzip

gzipは gzipによって圧縮された FreeBSDの プログラムを実行できるようにします. /standにあるプログ ラムは圧縮されているのでカーネルにこのオプションをつけ ておくのはいい考えでしょう. pseudo-device log

log はカーネルエラーのログを取るのに使います. 不可欠です. pseudo-device pty number

pty は「仮想ターミナル」や仮想ログインポート です. 外部からの telnetや rloginセッ ション, xterm, emacsなどのアプリケーションが使います. numberは作ることのできる ptyの数を示 します. GENERICのデフォルトは16で, 同時の xtermウィンドウやリモー トログインのために増やす場合は最大で 64までです. pseudo-device snp number

スヌープデバイスです. この疑似デバイスはあるターミナル セッションが watch(8) commandによって他のター ミナルを監視することを可能にします. この機能の実現はセ キュリティとプライバシに対して極めて微妙な関係があり ます. snpの後の numberは同時におこなうことのでき るスヌープセッションの総数です. 選択可能です. pseudo-device vn

Vノードドライバです. ファイルを vnconfig(8)コマ ンドによってデバイスとして取り扱うことを可能にします. このドライバによりフロッピーディスクイメージを操作したりファ イルをスワップデバイスとして (MS Windowsのスワッ プファイルなどを)用いることができます. 選択可能です. pseudo-device ccd number

ccd (concatenated disk)デバイスはいくつかのディスクパーティ ションを融合して大きなディスクのように見せることができます. ccdの後の numberは同時に作ることのできる疑似ディスクの数です. (詳しいことは ccd(4)と ccdconfig(8)のマニュ アルを参照してください.) 選択可能です. ジョイスティック, スピーカー, その他

この節は FreeBSDのここまでに示した以外のハードウェア デバイスへのサポートについて示します. これらは GENERICカーネル には含まれませんのでこのハンドブックや LINT (このファイルには すべてのデバイスのサポートが含まれます) からコピーする必 要があります. device joy0 at isa? port ``IO_GAME''

PC のジョイスティックです. pseudo-device speaker

IBM BASIC スタイルの PC内蔵スピーカーのサポートです. シェルスクリプトで簡単な演奏をする /usr/sbin/spkrtest やキーボードを使って単純なピ アノのように演奏することができる /usr/games/piano (gamesパッケージをイ ンストールした場合にはあります) のようないくつかのプロ グラムで使われます. また素晴らしいテキストロールプレイ ングゲームである NetHack (ports コレクションにあります) はゲーム中の楽器の演奏でこのデバイスを使うように設定を することができます (訳注:日本語化されたJNetHackもportsに あります).

デバイスの 項も参照してください. デバイスノードを作る

カーネル内のほとんどすべてのデバイスは対応する ``node'' エント リが /dev ディレクトリにあります. これらのノードは普 通のファイルのように見えますが, 実際にはプログラムがデバイスに アクセスするのに用いるカーネル内への特別なエントリです. シェルスクリプトである /dev/MAKEDEVはオペレーティング システムを最初にインストールする時に実行され, サポートされてい る大部分のデバイスのノードを作ります. しかし, すべてのノードが作られるわけではありませんので 新しいデバイスのサポートを加える時は対応するエントリがこのディ レクトリにあるかどうか確認してもしなければ, 作ってください. 以下に例を示します. IDE CD-ROMのサポートをカーネルに加えるとします. 次の行 を加えます. controller wcd0 これにしたがって, /devディレクトリに wcd0で始ま るエントリを捜してください. 1文字が後ろにつくかもしれません. 後 ろについた文字が `c'であるか先に `r'のつくエントリは `raw'デバ イスを示します. それらのファイルがないことが明らかになったとします. そこで /dev ディレクトリに移動して次のようにタイプします. # sh MAKEDEV wcd0 スクリプトの実行が終ったら /devに wcd0c と rwcd0c エントリがあることを確認してください. これによ り正しく実行されたことがわかります. サウンドカードの場合のコマンドは次の通りです. # sh MAKEDEV snd0 これにより対応するエントリが作られます. 注: サウンドカードのようなデバイスのノードを作る場合で, もし他 の人がマシンにアクセスするようであれば, そのデバイスを /etc/fbtabファイルに追加して外部からのアクセスから 保護するのが望ましいでしょう. このファイルの詳細については man fbtab を参照してください. GENERICに含まれていないデバイスはエントリがありませんから,以上 の簡単な手順をおこなうことになります. /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 ファイルにはすべての成功した ブートのカーネルのメッセージやその他の記録があり, これ は助けになる情報の一つでしょう. また, dmesg(8)コマンドは現在のブート時のカーネルメッ セージを出力します. kernel. oldは新しいカーネルをインストールする 時に, その一つ前にインストールしたうまく動かないかもしれ ないカーネルで上書きされてしまいますので当てにできませ ん. またできる限り早く動作しているカーネルを本来の ``kernel''の位置に移動させてください. そうしないと ps(1)のようなコマンドが正しく動きません. make でインストールされたカーネルのファイルを (別のカーネルに戻すために) 「アンロック」するための特別 のコマンドは # chflags noschg /kernel です. また, 新しい置き換えたカーネルあるいは重要ファイ ルを動かしたり変更されないように「ロック」するには 次のようにします. # chflags schg /kernel カーネルは動くが ps は動かない!

システムユーティリティと異るバージョンのカーネルをインス トールした場合, 例えば 実験的に ``2.2.0''のカーネルを 2.1.0-RELEASEシステム上にインストールするような場合, ps(1)や vmstat(8)のような多くのシ ステムステータスコマンドは動かなくなります. libkvm を 再コンパイルしてこれらのユーティリティを作りなおす必要がありま す. これは, オペレーティングシステムのそれ以外の部分と異るバージョ ンのカーネルを使うことが普通はあまりよくない理由の一つです. diff --git a/ja_JP.EUC/handbook/kerneldebug.sgml b/ja_JP.EUC/handbook/kerneldebug.sgml index dae6ca61fc..8a905141d8 100644 --- a/ja_JP.EUC/handbook/kerneldebug.sgml +++ b/ja_JP.EUC/handbook/kerneldebug.sgml @@ -1,419 +1,419 @@ - + カーネルデバッグ

原作 &a.paul; and &a.joerg;

訳: &a.yoshiaki;. 2 November 1996. kgdbによるカーネルのクラッシュダンプのデバッグ

ここではクラッシュダンプ (crash dump : 訳注 この文脈では kernel 自身 の異常によって停止した場合に出力されるイメージを指します) によるカー ネルデバッグの方法を示します. ここではダンプするための十分なスワップ (swap) の容量があるものとし ます. もし複数のスワップパーティションを持ち, 最初のパーティションがダンプ を保持するのに十分な大きさを持たない場合は別のダンプデバイスを使うよ うに (config kernel 行で) カーネルのコンフィグをおこなうか, dumpon(8)コマンドを使って別のデバイスを示すことができます. スワップ をおこなわないデバイスへのダンプ, 例えばテープへのダンプは現在サポートさ れていません. カーネルのコンフィグは config -g によって行っ てください. には FreeBSDのカーネルの設定の詳細がありますので参照してください. dumpon(8)コマンドを使ってどこへダンプするかカーネルに伝えて ください(swapon(8)によってそのパーティションがスワップとして設定された 後でなければならないことに注意してください). これは普通は /etc/sysconfig や /etc/rcで設定されます. あるいは 別の方法としてカーネルコンフィグレーションファイルの `config'行の `dump'節 で ダンプデバイスをハードコードすることができます. この方法はあまりよくは ありません. カーネルがブート時に crash する場合のクラッシュダンプを取り たい時だけ使うべきです. Note: 以下では `kgdb'という用語は gdbを カーネルデバッグモードで動かしていることを意味します. gdbを -kオプションをつけて起動するか kgdbという名前でリン クして起動することでこのモードになります. デフォルトでは このリンク は作られていません. カーネルを作った時にそのコピーを kernel.debugという名前で作 りましょう. また, オリジナルに対して strip -dを実行します. オリジナルを普通にインストールします. また strip していないカーネル も同様にインストールすることができますが, シンボルテーブルの参照時間 がいくつかのプログラムでは劇的に増加するでしょう. また, カーネル全体 はブート時に読み込まれスワップアウトされないため数メガバイトの物理メ モリが無駄になります. 例えばブートプロンプトで新しいカーネルの名前をタイプすることによって, 新しいカーネルをテストした場合で, 再びシステムを動かすのに別のカーネ ルで立ち上げることが必要な場合はブートプロンプトで -sフラグ を使いシングルユーザの状態にしてください. そして以下のような操作をおこな います. fsck -p mount -a -t ufs # /var/crash 用のファイルシステムを書き込み可能にする savecore -N /kernel.panicked /var/crash exit # ...マルチユーザモードへ移行 ここに示した savecore(8)は (現在動いているものとは別の) カー ネルのシンボル名の抽出をおこなうために使っています. 抽出はデフォルトで は現在動いているカーネルに対しておこなわれ, クラッシュダンプとカーネルシンボ ルのくい違いのためにまったく何もしません (訳注:そのためにオプション で実際にダンプをおこしたカーネルを指定します). クラッシュダンプの起きた後に /sys/compile/WHATEVERへ行き kgdbを動かします. kgdb より次のようにします. symbol-file kernel.debug exec-file /var/crash/kernel.0 core-file /var/crash/vmcore.0 こうすると, クラッシュダンプを使ってカーネルソースを他のプログラムと同様に デバッグすることができます. 次に kgdb での手順のセッションのログを示します. 長い行は読 みやすくするために改行しました. また, 参照のために行番号を入れてあり ます. ただし, これは実際の pcvtコンソールドライバの開発中の実際のエ ラーのトレースです. 1:Script started on Fri Dec 30 23:15:22 1994 2:uriah # cd /sys/compile/URIAH 3:uriah # kgdb 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:uriah # exit 78:exit 79: 80:Script done on Fri Dec 30 23:18:04 1994 上の出力についてのコメントをします. trap()関数の位置で す. tp->t_lineはコンソールデバイスの規定 する行を参照しているので, もっと小さな整数でなければなりませ ん. ) 突然ダンプした場合の解析

カーネルが予想もしない時にコアダンプして config -g を行ってコンパイルされていなかった場合にはどうしたらよいでしょう. すべてが失われるわけではありません. パニックを起こさないでください. もちろん, クラッシュダンプを使えるようにする必要があります. 使い方は前述の部分を見てください. カーネルのコンパイルディレクトリで, (Makefileの) COPTFLAGS?=-Oとある行を編集します. -gオプショ ンをここに加えます(オプティマイズオプションのレベルは 変更しな いでください ). もし大まかにコードのどこで問題が起きているか (例 えば, 上の例では pcvtドライバ) わかっているのでしたら, その部 分のコードについてのすべてのオブジェクトファイルを消してください. カーネ ルを再構築しましょう. Makefileのタイムスタンプの変更により, 例えば trap.o などのいくつかの他のオブジェクトファイルも作り直さ れます. 少しの幸運があれば, -gオプションが追加されても作ら れるコードは変更されず, いくらかのデバッグシンボル以外には問題を 起こしたコードとそっくりな新しいカーネルを手に入れることができます. 少なくとも sizeコマンドで古い方と新しい方のサイズを比較すべ きです. これが食い違っていれば, 多分あきらめなければならないでしょう. ダンプを使って前述のように動かして調べます. デバッグシンボルは 必ずしも十分ではありません. 上の例ではスタックトレースでいくつかの関 数の行番号や引数リストが表示されないかもしれません. もしより多くのデ バッグシンボルが必要であれば,十分になるまで適切なオブジェクトファイ ルを消して (makeして) kgdbセッションを繰り返してください. これは必ずしもうまく動くと保証はできません. しかしほとんどの場合でう まくいくでしょう. DDBを使ったオンラインカーネルデバッグ

kgdb は非常に高レベルのユーザインタフェースを提 供するオフラインデバッガですが, いくつかのことはできません. (できないことの中で)極めて重要なことはカーネルコードへのブレークポイ ントの設定とシングルステップ実行です. カーネルの低レベルデバッグが必要であれば, DDBと呼ばれる on-lineデバッ ガが使えます. ブレークポイントの設定, シングルステップのカーネルの実 行, 変数の検査と変更などができます. ただし,これはカーネルのソースファ イルにアクセスすることはできません. kgdbのようにすべてのデ バッグ情報にはアクセスできず, globalと staticのシンボルにアクセス することができるだけです. カーネルに DDBを含めるためにはコンフィグファイルに次のようなオプショ ンを加えて, options DDB 再構築をおこないます. ( FreeBSDのカーネルの設定の詳細についてはを参照してくださ い. もしブートブロックが古いバージョンですと, デバッガのシンボルが完 全にはロードされないかもしれませんので注意してください. DDBシンボル がロードされるようにブートブロックを最新の物にアップデートしてくださ い) DDB カーネルの実行において, DDBに入るいくつかの方法があります. 最初 の, 最も早い方法はブートプロンプトが出ている時に-dのブート フラグをタイプすることです. カーネルはデバッグモードで起動し, デバ イスのプローブ以前に 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 によっておこなうことができます. Note: これは 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 値が出力されます. 動いているプロセスの ps(1)スタイルの概要は ps です. カーネルの失敗の原因の調査が終わったらリブートすべきです. それまでの 不具合によりカーネルのすべての部分が期待するような動作をしているわけ ではないということを忘れないでください. 以下のうちいずれかの方法でシ ステムのシャットダウンおよびリブートを行ってください. call diediedie() カーネルをコアダンプしてリブートしますので, 後で kgdbによってコアの高 レベル解析をすることができます. このコマンドは通常 `continue'命令にエイリアスされています. `panic'にエイリアスされている call boot(0) は動いているシステムを `clean' に shut downするよい方法です. すべて のディスクを sync()して最後にリブートします. ディスクとカー ネルのファイルシステムインタフェースが破損していない限り, ほぼ完全 に `clean'にシャットダウンするよい方法でしょう. call cpu_reset() は大惨事を防ぐための最後の手段で「赤い大きなボタン」を押すのとほとんど 同じです.(訳注: リセットボタンを押すのとほぼ同じであるという意味です) 短いコマンドの要約は help をタイプします. ただし, デバッグセッションのために ddb(4) の マニュアルページのプリントアウトを用意しておくことを強くお奨めします. カーネルのシングルステップ中にオンラインマニュアルを読むことは難しい ということを覚えておいてください. コンソールドライバのデバッグ

DDBを動かすためにはコンソールドライバが必要ですから, コンソールドラ イバ自身に不具合のある場合は複雑になります. シリアルコンソールを利 用する方法 (ブートブロックを変更するか Boot:プロンプトで -hと入力する) を思い出してください. そして標準ター ミナルを最初のシリアルポートに設定します. DDBは, もちろんシリアルコ ンソールを含むいずれのコンソールドライバの設定でも動作します. diff --git a/ja_JP.EUC/handbook/kernelopts.sgml b/ja_JP.EUC/handbook/kernelopts.sgml index 945d510e22..eb8a3a74b9 100644 --- a/ja_JP.EUC/handbook/kernelopts.sgml +++ b/ja_JP.EUC/handbook/kernelopts.sgml @@ -1,153 +1,153 @@ - + カーネルコンフィグレーションの新しいオプションを追加する

原作: &a.joerg;

訳: &a.yoshiaki; . 29 December 1996. の章の内容を 理解しておいてください. そもそもカーネル オプションって何?

カーネルオプションの使い方は基本的には の章に書いてあります. そこには「伝統的な形式」と「新しい形式」のオプションの説明があります. すべてのカーネルのオプションを新しい形式のものに置き換え, コンフィグファイル を修正して 基本的に, カーネルオプションはカーネルのコンパイルプロセスの C プリプロセッサのマクロの定義にすぎません. 実際に選択的に make できる ようにするためには, 対応する部分のカーネルソース (またはカーネルの #ifndef THIS_OPTION #define THIS_OPTION (some_default_value) #endif /* THIS_OPTION */

この場合, 管理者がコンフィグファイルのオプションに別の値を記述すれば, デフォルトの設定を打ち消して新しい値に置き換えられます. 当然, 新しい値はプリプロセッサによってソースコード中で置き換えられるため, デフォルトの値が使われていた場所において C の式として有効な値でなければ なりません.

また, 単に特定のコードを有効にするか無効にするかを設定するための 値を持たないオプションも作ることができます. #ifdef THAT_OPTION [あなたのコードが入ります] #endif

コンフィグファイルに C 言語にくわしい人であれば「コンフィグオプション」とされているもの は少なくとも一つの options notyet,notdef

このようにコンフィグファイルをしておくと, カーネルのコンパイルは うまく行きません. :-)

(訳注: たとえば MATH_EMULATE のように 有効/無効のためのパラメタを 持たないオプションの場合, 無効とするためのパラメタをつけて, オプション で「無効とする」と明示することはできないという意味です)

明らかに, 任意のオプション名がカーネルソースツリー全体でどのように 使われているかを追いかけることは非常に難しいことです. このことが opt_foo.h という名前に されます. この方法では, 通常の Makefile の依存関係が適用され, 古い形式のオプションの機構は, 局部的なオプションや実験的なオプション のような一時的に利用されると考えられるオプションにおいては有効です. つまり ではどのようにして追加するのでしょう?

最初に sys/conf/options (または sys/i386/conf/options.<arch>, たとえば sys/i386/conf/options.i386) を編集し, 新しいオプション を含めるのに最適な opt_foo.h ファイルを選びます.

新しいオプションの必要がなくなったとしたら, これを取り除きます. たとえば, SCSI サブシステムに関するすべてのふるまいについてのオプション の変更は 新しいオプションを加えるのに使えそうな opt_foo.h がない場合は新しい名前を作ってください. 意味のある名前を作り options[.<arch>] ファイル に新しいセクションのコメントをつけてください. 大量のオプションを一つの opt_foo.h にまとめると コンフィグファイルの一つのオプションを変更したときに多くのファイルが 再コンパイルされる原因になります.

新しいオプションに依存するカーネルファイルは最終的には見つけ出 されます. ただし, オプションを作っただけで対応するソースがどこにも ない場合は別です. find /usr/src/sys -name type f | xargs fgrep NEW_OPTION

オプションに対応するソースを見つけるのに上記のコマンドは便利です. 見つけたすべてのファイルで編集, 追加をおこないます. #include "opt_foo.h"

ファイルの先頭の, すべての #ifndef NEW_OPTION #define NEW_OPTION (something) #endif

システムヘッダファイル (たとえば /usr/include/sys/ にある ファイル) をオプションで置き換えることは, ほとんどの場合で失敗します. そうすると, ヘッダファイルを深刻な状態に破壊してしまうので, include しないとオプションの値によって不整合が起きてしまう場合を除き, それらの ファイルに opt_foo.h を include しないでください. そう, 現在このような例がいくつか存在していますが, 必ずしも正しい方法 ではありません. diff --git a/ja_JP.EUC/handbook/linuxemu.sgml b/ja_JP.EUC/handbook/linuxemu.sgml index 81b094c5f5..6014a2cae7 100644 --- a/ja_JP.EUC/handbook/linuxemu.sgml +++ b/ja_JP.EUC/handbook/linuxemu.sgml @@ -1,714 +1,714 @@ - + Linux エミュレーション

原作: &a.brian and &a.rich;

訳: &a.kiroh;.24 September 1996. Linux エミュレータのインストール

FreeBSD での Linux エミュレーションは, 大部分の Linux バイナリ(a.out および ELF フォーマット)を実行できる状態になっています. -STABLE ブラン チでのエミュレーションでは, Linux DOOM や Mathematica が実行できます. FreeBSD-current でのエミュレーションは, さらに強化されており, Linux 用 の Quake, Abuse, IDL, netrek など, 多数のソフトウェアが実行できます. Linux オペレーティングシステムには、特有の機能がいくつかあり, FreeBSD でサポートされていないものもあります. Linux の /proc ファイルシステム を使ったバイナリは, FreeBSD では実行できません (FreeBSD で使用可能な /proc ファイルシステムとは仕様が異なっているためです). また仮想8086モー ドを有効にするなど, i386 に特有なシステムコールを使っている場合も実行 できません.

カーネルが Linux エミュレーションを使用するように構築されているかを調 べるには, Linux のバイナリを実行してみるのが簡単です. linux-executable: Exec format error. Wrong Architecture. このようなエラーメッセージが表示されるようであれば, Linux との互換性は サポートされていません. カーネルを再構築してインストールする必要があり ます. Linux エミュレーションの設定方法は, 使用している FreeBSD のバージョン によって多少異なっています. 2.1-STABLE への Linux エミュレーションのインストール

2.1-STABLE の GENERIC カーネルは, Linux との互換性を保つように構築 されていません. カーネルの再構築が必要です. 再構築をおこなうには, 2つの方 法があります. 1つは, エミュレータをカーネル自体にスタティックリンクす る方法. もう1つは, 動的に Linux ローダブルカーネルモジュール(LKM)をロー ドするようにする方法です.

エミュレータを有効にするには, 以下をコンフィグレーションファイル (/sys/i386/conf/LINT など) に追加します. options COMPAT_LINUX Linux DOOM などのアプリケーションを実行したい場合は, 共有メモリも有効 にしておかなければなりません. 以下を追加します. options SYSVSHM Linux のシステムコールを使用するには, 4.3BSD のシステムコールとの互換 性が保たれていることが必要です. 以下の行が含まれていることを確認してく ださい. options "COMPAT_43" LKM を使用せずエミュレータをカーネルにスタティックにリンクしたい場合は, 以下の行を追加します. options LINUX の節の記述に したがって config と, 新しいカーネルのインストールをおこなってください. LKM を使用する場合は, ローダブルモジュールをインストールしなければなり ません. カーネルとローダブルモジュールのバージョンが異なると, カーネル がクラッシュする場合がありますので, 安全を期すためには, カーネルをイン ストールするごとに, LKM も再インストールしてください. % cd /usr/src/lkm/linux % make all install カーネルと LKM のインストールが終了したら, root で `linux' コマンドを 実行することで LKM をロードできます. % linux Linux emulator installed Module loaded as ID 0 % LKM がロードされたかどうかを確認するには, `modstat' を実行します. % modstat Type Id Off Loadaddr Size Info Rev Module Name EXEC 0 3 f0baf000 0018 f0bb4000 1 linux_emulator % システムブート時に, LKM をロードするようにするには, 2つの方法がありま す. FreeBSD-current または FreeBSD-STABLE では, /etc/sysconfig を, linux=YES のように, NO を YES に変更してください. FreeBSD 2.1 RELEASE およびそれ以 前のバージョンでは, そのような行はありませんので, /etc/rc.local に以下 の行を追加する必要があります. linux 2.2-current への Linux エミュレーションのインストール

-current では, ``options LINUX'' や ``options COMPAT_LINUX'' を指定する必要 はなくなりました. Linux エミュレーションは LKM(「ローダブルカーネルモジュール」) を使用して, リブートせず簡単にインストールできます. スタートアッ プファイルで以下のように指定します. /etc/sysconfig に以下の行が必要です. linux=YES これは結果的に, /etc/rc.i386 の以下の指定を有効にします. # Start the Linux binary emulation if requested. if [ "X${linux}" = X"YES" ]; then echo -n ' '; linux # XXX BOGUS - Linux script shouldn't make any output on success fi

実行されたかどうかを確認するには, modstat を使用します. % modstat Type Id Off Loadaddr Size Info Rev Module Name EXEC 0 4 f09e6000 001c f09ec010 1 linux_mod % FreeBSD-current システムの中には, modstat の実行がうまくいかないものがあ るという報告もあります. 何らかの理由で, Linux LKM がロードできな い場合は, options LINUX をカーネルの設定ファイルに指定して, エミュレータをスタティックにリンク してください. の節の記述にしたがって config と, 新しいカーネルのインストールをおこ なってください. Linux ランタイムライブラリのインストール linux_lib port を使用してのインストール

多くの Linux アプリケーションはシェアードライブラリを使用しますので, シェアードライブラリのインストールが終了しなければ, エミュレータのイン ストールは終わったことになりません. 手動でもインストールできますが, linux_lib port を使用するのが簡単です. % cd /usr/ports-current/emulators/linux_lib % make all install これで, Linux エミュレータが動作するようになったはずです. 伝説(とメー ルのアーカイブ :-) によれば, Linux エミュレーションは, ZMAGIC ライブラ リとリンクされている Linux バイナリに対して, 最もうまく動作するようで す. Slackware V2.0 などに使われている QMAGIC ライブラリだと, エミュレー タが胸やけするかもしれません. これを書いている時点(1996年5月)で, ELF エミュレーションは依然実験段階ですが, かなりうまく動作しているようです. マイナーバージョンの不一致などを報告するプログラムもありますが, 普通は 問題にならないようです. 手動でのライブラリのインストール

``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 以下にインストールする 必要があります. FreeBSD-current では, /compat/linux にかかわる動作が多少異なりま す. -current では, ライブラリだけでなくすべてのファイルが, ``shadow root'' /compat/linux から検索されます. Linux のプログラムが必要とするシェアードライブラリを探す必要があるのは, FreeBSD のシステムに Linux のプログラムをインストールする最初の数回だ けでしょう. それが過ぎれば, 十分な Linux のシェアードライブラリがシス テムにインストールされ, 新しくインストールした Linux のバイナリも, 余 計な作業をせずに動作させることができるようになります. シェアードライブラリの追加

linux_port をインストールした後に, アプリケーションが必要なライブラリ が存在しないというエラーを出したらどうしたらよいでしょうか? Linux のバ イナリがどのシェアードライブラリを必要とし, そしてどこで入手できるか, どのように探したらよいでしょうか? 基本的には, 以下の2種類の方法があり ます(以下の手順にしたがう場合には, 必要なインストール作業をおこなう FreeBSD シ ステム上で root として作業をおこなう必要があります).

Linux システムを使用でき, 必要なシェアードライブラリが調べられる場 合には, 単に FreeBSD のシステムにそのライブラリをコピーするだけで す. 例えば, DOOM の Linux バイナリを ftp で持ってきたとします. 使用で きる Linux システムの上に転送して, `ldd linuxxdoom' とやれば, 必要とす るシェアードライブラリがチェックできます. % 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 のランタイムリンカは, メジャーリビジョ ン番号の一致したライブラリを検索しますから, ユーザが気にする必要はあり ません. ld.so の設定 -- FreeBSD-current のみ

このセクションは, FreeBSD-current にのみ当てはまります. FreeBSD-STABLE を使用している方は, 飛ばしてください.

最後に, FreeBSD-current を使われている場合は, Linux のランタイムリンカと その設定ファイルがシステムに導入されていることを確認してください. これらのファイルは, FreeBSD システムの適切な位置(/compat/linux ツリー以 下)にコピーされている必要があります. /compat/linux/lib/ld.so /compat/linux/etc/ld.so.config

使用できる Linux システムがない場合は, 必要なファイルは近くの FTP サイ トから入手してください. 各種ファイルの入手先についての情報を, 後に付 けておきます. ここでは, 必要なファイルの入手先がわかっているものとしま す.

以下のファイルを取得します(バージョンの不一致を避けるために, すべて同一 の FTP サイトから入手してください). 取得したファイルを /compat/linux 以下にインストールしてください(例えば, /foo/bar は, /compat/linux/foo/bar にインストールされます). /sbin/ldconfig /usr/bin/ldd /lib/libc.so.x.y.z /lib/ld.so

ldconfig と ldd は, /compat/linux の下にある必要はありません. システム のどこにあっても構いません. ただ, FreeBSD の同名のコマンドと間違えないように 注意してください. /usr/local/bin の中に, ldconfig-linux, ldd-linux とし てインストールするのもよいアイディアでしょう.

/compat/linux/etc/ld.so.conf ファイルを作成し, Linux ラインタイムリンカ がシェアードライブラリを検索するディレクトリを記述してください. このファ イルはプレインテキストファイルで, それぞれの行にディレクトリ名を含みま す. /lib と /usr/lib は標準ですから, 以下のようなディレクトリが追加できま す. /usr/X11/lib /usr/local/lib

Linux バイナリが, /lib/libc.so というライブラリを開いた場合, エミュレー タは内部で, ファイル名を /compat/linux/lib/libc.so にマップします. エ ミュレータがライブラリを検索するために, すべての Linux のライブラリ (/compat/linux/lib/libc.so, /compat/linux/usr/X11/lib/libX11.so など) は, /compat/linux 以下にインストールされていなければなりません.

FreeBSD-current を使用している場合は, Linux の ldconfig プログラム を実行する必要があります. % cd /compat/linux/lib % /compat/linux/sbin/ldconfig

ldconfig はスタティックリンクされていますから, 実行するのにシェアードラ イブラリを必要としません. ldconfig は, /compat/linux/etc/ld.so.cache ファイルを作成し, すべてのシェアードライブラリの名前を格納します. ライ ブラリの追加をおこなった場合には, ldconfig を再実行して, このファイルを作り 直さなければなりません. FreeBSD-STABLE では, /compat/linux/etc/ld.so.cache をインストールしたり, ldconfig を実行したりしないでください. FreeBSD-stable では, システムコー ルの実装方法が異なるため, ldconfig は使用されません.

これで, libc シェアードライブラリを必要とする Linux バイナリを実行する設 定が終了しました. ldd を ldd 自身に実行してテストしてください. ldd-linux としてインストールしている場合は, 以下のような結果になるはず です. % ldd-linux `which ldd-linux` libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29

ここまで終了すれば, 新しい Linux のバイナリをインストールできます. 新しい Linux バイナリをインストールするときは, それがシェアードライブ ラリを必要とするかどうか確認してください. 必要とする場合は, /compat/linux 以下にインストールされているかどうか確認してください. こ れは, Linux の ldd を新しいプログラムに対して実行し, 出力を確認するこ とによりおこなえます. ldd(ldd(1)マニュアルページも参照してください)は, プ ログラムが必要とするシェアードライブラリのリストを, majorname (jumpversion) => fullname という形式で出力します.

fullname のかわりに ``not found'' と出力される場合は, ライブラリの追加をす る必要があります. 必要なライブラリの名前は, majorname に libXXXX.so.N.mm という形式で示されています. Linux の FTP サイトで libXXXX.so.N.mm を探し, インストールしてください. XXXX(名前)とN(メジャー リビジョン番号)は一致している必要があります. マイナー番号 mm は, それほ ど重要ではありませんが, なるべく最新のものをインストールするようにして ください. ホストネームリゾルバの設定

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' を削除してください.

最後になりますが, FreeBSD-STABLE を使用している場合は, RESOLV_HOST_CONF 環境変数を指定して, アプリケーションにホストテーブル の検索方法を指定する必要があります. FreeBSD-current を使用している場合 は, スキップしてください. /bin/csh を使っている場合は, 以下のようにし ます. setenv RESOLV_HOST_CONF /compat/linux/etc/host.conf /bin/shの場合は, 以下のようにします. RESOLV_HOST_CONF=/compat/linux/etc/host.conf; export RESOLV_HOST_CONF 必要なファイルを探すには

注意: 以下の情報は, この文書が書かれた時点では有効ですが, FTP サイトの 名前, ディレクトリ, 配布ファイル名などは, 変更されている可能性がありま す.

訳注: ここに取り上げられている FTP サイトは, 日本国内にもミラーサイト が多数存在します。なるべく近くの FTP サイトからファイルを入手してくだ さい.

Linux は, いくつかのグループが, それぞれ独自のバイナリ配布セットを作成 して配布しています. 配布セットは, ``Slackware'' や ``Yggdrasil'' など の名前がつけられています. これらの配布セットは, 多くの FTP サイトから 入手できます. ファイルが展開されており, 必要なファイルのみを取得できる 場合もありますが, 通常は圧縮された配布セットの形で入手できます. 配布 セットは, いくつかのサブディレクトリに, gzip で圧縮された tar ファイル として格納されています. それぞれの配布セットの一次配布先は, 以下の通り です. sunsite.unc.edu:/pub/Linux/distributions tsx-11.mit.edu:/pub/linux/distributions

ヨーロッパのミラーサイトの例: ftp.luth.se:/pub/linux/distributions ftp.demon.co.uk:/pub/linux/distributions src.doc.ic.ac.uk:/packages/linux/distributions

混乱を避けるために, ここでは Slackware だけを取り上げます. この配布セッ トは, 多くのサブディレクトリ内にある別々のパッケージから構成されていま す. 通常, パッケージはインストールプログラムにより自動的に制御されま すが, ``手動で''おこなうことも可能です. まず配布セットの中の, ``contents'' サブディレクトリの内容を書くにしてください. ここには多く の小さなテキストファイルが含まれおり, それぞれのパッケージの内容が記述 されています. 必要なファイルを探している場合は, まず contents 内のテキ ストファイルを取得し, そのファイルの中から grep を使用して検索するのが, 最も速い方法でしょう. 以下に必要となるであろうファイルを, grep を使用 して検索した例を示します. Library Package ld.so ldso ldconfig ldso ldd ldso libc.so.4 shlibs libX11.so.6.0 xf_lib libXt.so.6.0 xf_lib libX11.so.3 oldlibs libXt.so.3 oldlibs

この場合は, ldso, shlibs, xf_lib, oldlibs というパッケージが必要なこと がわかります. それぞれのcontentsファイルの中で, ``PACKAGE LOCATION'' と書いてある行を探してください. その行に, パッケージが含まれているディ スク, 今回の場合はサブディレクトリ名が書かれています. たとえば, 以下の ようになります. Package Location ldso diska2 shlibs diska2 oldlibs diskx6 xf_lib diskx9

``diskXX'' というのは, 配布セットの ``slackware/XX'' サブディレクトリ を示します. それ以外の場合は, ``contrib'' サブディレクトリに格納されて います. 今回の場合は, 以下のファイルを取得すればいいことがわかります (ファイル名は, 配布セットのルートディレクトリからの相対パスで示してあ ります). slakware/a2/ldso.tgz slakware/a2/shlibs.tgz slakware/x6/oldlibs/tgz slakware/x9/xf_lib.tgz

gzip で圧縮された tar ファイルから必要なファイルを /compat/linux ディ レクトリに格納してください(必要なファイルのみを展開するか, あるいは必 要でないファイルを後で削除してください). これで作業は終了です.

参照: ftp.freebsd.org:pub/FreeBSD/2.0.5-RELEASE/xperimnt/linux-emu/README /usr/src/sys/i386/ibcs2/README.iBCS2 FreeBSD への Mathematica のインストール

原作: &a.rich and &a.chuck

訳: &a.kiroh;. この文書は, Mathematica 2.2 の Linux バイナリディストリビューションを, FreeBSD 2.1 にインストールする方法について説明します.

Mathematica は, そのままでは FreeBSD をサポートしていませんが, Linux は サポートしています. ですから, Linux エミュレータの設定が終わってしまえ ば, Mathematica を動作させる環境はほとんど整ったことになります.

DOS 用のスチューデント版 Mathematica から Linux バージョンへのアップグレー ド価格は, 執筆時点 (1996年5月) では, $45.00 です. 直接 Wolfram(電話番号(217) 398-6500)に注文して, 支払いはクレジットカー ドでおこなえます。 Mathematica ディストリビューションの展開

バイナリは, Wolfram から CDROM で配布されています. CDROM には, 1ダー スほどの tar ファイルが含まれており, それぞれサポートされているアーキテ クチャに対応しています. Linux 用のファイルは, LINUX.TAR です. 例えば /usr/local/Mathematica 以下にインストールする場合は, 以下のようにしま す. % cd /usr/local % mkdir Mathematica % cd Mathematica % tar -xvf /cdrom/LINUX.TAR Mathematica パスワードの取得

Mathematica を実行する前に, 使用するマシンに対応した `machine ID' を Wolfram から取得する必要があります.

Linux 互換ランタイムライブラリがインストールされており, mathematica の展 開が終了したら, Install ディレクトリで `mathinfo' プログラムを使用す ることで `machine ID' を得ることができます. % cd /usr/local/Mathematica/Install % mathinfo LINUX: 'ioctl' fd=5, typ=0x89(), num=0x27 not implemented richc.isdn.bcm.tmc.edu 9845-03452-90255 % ここで, `richc' の `machine ID' は, `9845-03452-90255' となります. ioctl のメッセージは無視してください. まだ FreeBSD では実装されていません. Mathematica を実行するたびに同様のメッセージが表示されますが, 実際の使 用に問題はありませんので, 無視してかまいません.

電子メールや電話, ファックスなどで Wolfram に `machine ID' を知らせ て登録すると, いくつかの番号のグループからなるパスワードが送り返されて きます. パスワードを, マシン名, ライセンス番号とともに, mathpass ファ イルに追加します. 追加は, 以下のようにおこないます. % cd /usr/local/Mathematica/Install % math.install ライセンス番号と, Wolfram から送られてきたパスワードを入力を求めます. 入力を間違えたりして, math.install の実行が失敗しても大丈夫です. `mathpass' ファイルを手動で編集して, 情報を訂正してください.

パスワードの入力後, math.install では, インストール方法を, デフォルト 設定でのインストールか、自分で方法を指定するインストールから選ぶことが できます. 筆者のようにインストールプログラムを信用していない場合は, 自 分でディレクトリを指定する方を選択するでしょう. 自分で指定するインストー ルを選んだ場合, math.install 自身ではディレクトリの作成はおこないません. 注意してください. 別のウィンドウでシェルを開いて, 指定するディレクトリ を作成してください. 存在しないディレクトリを指定して, math.install が インストールに失敗した場合には, ディレクトリを作成し, math.install を 再び実行してください. 筆者らがインストール先に選んだディレクトリは, 以 下の通りです. くれぐれもあらかじめ作成してから, math.install で指定す るようにしてください. /usr/local/Mathematica/bin バイナリファイル /usr/local/Mathematica/man/man1 マニュアルページ /usr/local/Mathematica/lib/X11 XKeysymbファイル また, システムレコードファイルとして, /tmp/math.record を使用するように 設定することもできます. このファイルには, セッションのログが記録されま す. この設定が終了すると, math.install は残りのファイルを展開して, 必 要な場所に格納します.

Mathematica ノートブックの機能は, X フロントエンドとして本体とは別に含 まれています. X フロントエンドを正しくインストールするには, /usr/local/Mathematica/FrontEnd ディレクトリに移動し, ./xfe.install シェ ルスクリプトを実行します. インストール先を指定しなければなりませんが, あらかじめ作成する必要はありません. 必要なディレクトリは, すべて math.install によって作成されているからです. インストールが終了したら, /usr/local/Mathematica/bin ディレクトリに, ``mathematica'' という名前の シェルスクリプトが新たに作成されているはずです.

最後に, Mathematica がインストールしたシェルスクリプトを修正する必要 があります. /usr/local/Mathematica/bin に含まれるすべてのシェルスクリプ トの先頭部分に以下の行を追加します. XKEYSYMDB=/usr/local/Mathematica/lib/X11/XKeysymDB; export XKEYSYMDB これは, Mathematica が使用する Mathematica バージョンのキーマップファイル XKeysymDB の場所を指定するものです. FreeBSD-STABLE を使用している場合は, 以下の行も追加してください. RESOLV_HOST_CONF=/compat/linux/etc/host.conf; export RESOLV_HOST_CONF これは, Mathematica に Linux バージョンの host.conf を使用するように指定し ます. FreeBSD の host.conf の文法は, Linux のものと異なっているため, この 指定をおこなわないと, /etc/host.conf に関わるエラーが発生します.

新しいマニュアルページを利用したい場合は, さらに /etc/manpath.config ファイ ルを修正する必要があります. また自分の~/.cshrcを変更して, /usr/local/Mathematica/bin をパスに追加してください.

これでインストール作業はすべて終了です. ``mathematica'' とタイプすれば, 見栄えのする Mathematica ノートブックが表示されるはずです. Mathematica には, Motif ユーザインタフェースが含まれますが, スタティックにリンクさ れているため, Motif のライブラリは必要ありあません. 頑張って Mathematica をインストールしてください. バグ

ノートブックフロントエンドは, 以下のようなエラーメッセージを表示して, ハングすることがあることが知られています. File .../Untitled-1.mb appears to be broken for OMPR.257.0 今のところ原因はわかっていませんが, このバグが影響を及ぼすのは, ノートブッ クの X window フロントエンドのみです. Mathematica エンジン本体に影響は ありません. そのため, ``math'' によって起動されるコマンドラインのインタ フェースを使用している場合は, このバグは関係ありません. 謝辞

&a.sosと&a.peterに深く感謝します. Linuxエミュレーションが現在の形に あるのは, 彼らのおかげです. そして, 彼ら二人にハッパをかけて, 犬のよう に働かせた Michael Smithに. 今やLinuxエミュレーションは, linuxよりうま くlinuxバイナリを実行できます！ :-) diff --git a/ja_JP.EUC/handbook/lists.sgml b/ja_JP.EUC/handbook/lists.sgml index cbae01108a..87c1b87eef 100644 --- a/ja_JP.EUC/handbook/lists.sgml +++ b/ja_JP.EUC/handbook/lists.sgml @@ -1,66 +1,66 @@ - + "> "> "> "> "> "> "> "> "> "> "> "> "> "> diff --git a/ja_JP.EUC/handbook/memoryuse.sgml b/ja_JP.EUC/handbook/memoryuse.sgml index 980df97737..eccf14eb67 100644 --- a/ja_JP.EUC/handbook/memoryuse.sgml +++ b/ja_JP.EUC/handbook/memoryuse.sgml @@ -1,61 +1,61 @@ - + PC におけるメモリの利用

原作: &a.joerg;. 16 Apr 1995.

訳: &a.tomo;. 29 Oct 1996. FreeBSDがi386プラットフォーム上でどのようにメモリを使うかに ついての説明です. ブート部分は0:0x7c00にロードされ, すぐに自分自身を 0x7c0:0に移します. (これは手品ではなく, 単なる%cs セレクタのための調節であり, ljmpにより行われます. ) それから最初の15セクタを0x10000(biosbootのMakefileのなかの BOOTSEG部分)にロードし, 作業領域のスタックを0x1fff0以下に セットします. このあと, boot2 に飛びます. つまり, boot1 自身と (ダミーの) DOS パーティションテーブルを飛び越えて, %csセレクタを 調節します---この時点ではまだ16ビットモードです. boot2はブートファイルを要求し, a.outヘッダを調べます. 0x00ffffffによってファイルエントリポイントを (通常は0xf0100000に)マスクし, ロードします. このため, 通常のロードポイントは1MB(0x00100000)になります. ロードしている間, リアルモードでBIOSを使うため, ブートコードは, リアルモードとプロテクトモードの間を行ったり来たりします (訳注: これは, BIOSがリアルモード用に書かれていて, ロードすべき領域がリアルモードではアクセスできない1MBより上位の アドレスであることから, ブートコードがリアルモードと プロテクトモードを切り替えながら動作するためです). ブートコード自身はプロテクトモードで%csと%ds/%es用に セグメントセレクタ0x18と0x20を使い, リアルモードに戻るのに0x28を使います. 最終的にカーネルはアドレス空間全体をカバーできるようなダミーの ディスクリプタを参照して%cs 0x08と %ds/%es/%ss 0x10でスタートします. カーネルはそのロードポイントで起動されます. 別の(高位)アドレスにリンクされるので, ページテーブルやページディレクトリなどが適切に設定され, ページングが有効になり, カーネルがリンクされたアドレスで 動作するようになるまでは, カーネルはロードアドレスからの 相対アドレス (PIC: position independent code) を用いて 実行されなければなりません. 寄贈: &a.davidg;. 16 Apr 1995. カーネルの BSS セグメントの直後の物理ページ (実メモリ) に proc0 (訳注: プロセス番号 0, swapper) のページディレクトリや ページテーブル, Uページが配置されます. 仮想記憶機構が初期化された少しあと, 0x1000-0x9ffffの実メモリとカーネル (text + data + bss + 上記の proc0 に関わるもの + その他) の後ろの実メモリは, 通常の仮想記憶ページの形で利用可能となり, グローバルな空きページリストに追加されます. diff --git a/ja_JP.EUC/handbook/mirrors.sgml b/ja_JP.EUC/handbook/mirrors.sgml index 01e2b4b062..c6a953aa89 100644 --- a/ja_JP.EUC/handbook/mirrors.sgml +++ b/ja_JP.EUC/handbook/mirrors.sgml @@ -1,583 +1,583 @@ - + FreeBSD の入手方法

FreeBSD の公式な情報は anonymous FTP によって以下の場所から 入手できます: また Walnut Creek CDROM から出ている CD-ROM からも入手できます: Walnut Creek CDROM 1547 Palos Verdes Mall, Suite 260 Walnut Creek CA 94596 USA Phone: +1 510 674-0783 Fax: +1 510 674-0821 Email: WWW:

さらに, FreeBSD は以下のミラーサイトから anonymous FTP によって 入手できます. もし FreeBSD を anonymous FTP によって手にいれる場合は, 近くのサイトを利用するようにしてください. , , , , , , , , , , , , , , , , , , , , , , . 何か問題がある場合は, このドメインの に連絡してください. 何か問題がある場合は, このドメインの に連絡してください. 何か問題がある場合は, このドメインの に連絡してください. 連絡先: . 何か問題がある場合は, このドメインの に連絡してください. 何か問題がある場合は, このドメインの に連絡してください. 連絡先: . 何か問題がある場合は, このドメインの に連絡してください. 連絡先: . 何か問題がある場合は, このドメインの に連絡してください. 何か問題がある場合は, このドメインの に連絡してください. 何か問題がある場合は, このドメインの に連絡してください. 何か問題がある場合は, このドメインの に連絡してください. 何か問題がある場合は, このドメインの に連絡してください. 連絡先: . 連絡先: . 何か問題がある場合は, このドメインの に連絡してください. 連絡先: . 連絡先: . 何か問題がある場合は, このドメインの に連絡してください. 何か問題がある場合は, このドメインの に連絡してください. 何か問題がある場合は, このドメインの に連絡してください. 連絡先: . 何か問題がある場合は, このドメインの に連絡してください. 何か問題がある場合は, このドメインの に連絡してください. FreeBSD (2.0C またはそれ以降) の輸出規制コード (eBones と secure) の 最新のバージョンは以下の場所から入手できます. もしあなたがアメリカやカナダ以外にいるのであれば, secure (DES) と eBones (Kerberos) を 以下の外国向けの配布サイトから手にいれてください: 南アフリカ このドメインの . ブラジル このドメインの . フィンランド 連絡先: .

CTM/FreeBSD は以下のミラーサイトから anonymous FTP によって 入手できます. もし CTM を anonymous FTP によって手にいれる場合は, 近くのサイトを利用するようにしてください. 何か問題がある場合は, &a.phk;に連絡してください. カリフォルニア, サンフランシスコ近辺, 公式なソース ドイツ, ベルリン ドイツ, トリエル 南アフリカ, ctm, sup, CVSupなどの古い差分ファイルのバックアップサーバ 台湾/中華民国, チャーイー(嘉義) 近くにミラーサイトがない場合やミラーが不完全な場合は, の を試してください. FTP search はノルウェーの Trondheim にある, フリーの素晴らしい アーカイブサーバです. diff --git a/ja_JP.EUC/handbook/nfs.sgml b/ja_JP.EUC/handbook/nfs.sgml index 8387757548..2911f0dadb 100644 --- a/ja_JP.EUC/handbook/nfs.sgml +++ b/ja_JP.EUC/handbook/nfs.sgml @@ -1,88 +1,88 @@ - + NFS

原作: &a.jlind;.

訳: &a.tomo;.6 September 1996. ISA用のイーサネットアダプタの中には性能が悪いため, ネットワーク, 特に NFS で深刻な問題がおきるものがあります. これは FreeBSD に限ったことでは ありませんが, FreeBSD でも起こり得ます. この問題は, (FreeBSDを使用した)PCがシリコン・グラフィックス社やサン・マイクロ システムズ社などの高性能なWSにネットワーク接続されている場合に頻繁に 起こります. NFSマウントはうまく行きます. また, いくつかの操作もうまく 働きますが, 他のシステム(WS)に対する要求や応答は続いていても, 突然サーバ がクライアントの要求に対して反応しなくなります. これは, クライアントがFreeBSDか上記のWSであるとき, にクライアント側に起きる 現象です. 多くのシステムでは, いったんこの問題が起きたら解決できないので, 行儀よくシャットダウンするしかありません. 唯一の解決策は, この状況に陥る前にクライアントをリセットすることです. なぜなら, 一旦この状況に陥ると NFS を解除することさえできないからです. "正しい"解決法は, より高性能のイーサネットアダプタをFreeBSDシステムに インストールすることですが, 満足な操作ができるような簡単な方法があります. もし, FreeBSDシステムがサーバになるのなら, クライアントからのマウント時に "-w=1024"オプションをつけて下さい. もしFreeBSDシステムがクライアントになる のなら, NFSファイルシステムを"-r=1024"オプションつきでマウントして下さい. これらのオプションは自動的にマウントをおこなう場合には クライアントのfstabエントリの4番目のフィールドに指定してもよいですし, 手動マウントの場合はmountコマンドの"-o"パラメータで指定してもよいでしょう. NFSサーバとクライアントが別々のネットワーク上にあるような場合, これと間違えやすい他の問題が起きることに注意して下さい. そのような場合は, ルータが必要なUDP情報をきちんとルーティングしているかを確かめて下さい. そうでなければ, たとえあなたが何をしようと解決できないでしょう. 次の例では, "fastws"は高性能のWSのホスト (インタフェース)名で, "freebox"は低性能のイーサネットアダプタを備えた FreeBSDシステムのホスト(インタフェース)名です. また, "/sharedfs"はエクスポートされるNFSファイルシステムであり ("man exports"を見て下さい), "/project"はエクスポートされたファイル システムのクライアント上のマウントポイントとなります. 全ての場合において, "hard"や"soft", "bg"といった追加オプションが アプリケーションにより要求されるかもしれないことに注意して下さい. クライアント側FreeBSDシステム("freebox")の例は: freeboxの/etc/fstabに次のように書いて下さい: fastws:/sharedfs /project nfs rw,-r=1024 0 0 freebox上で手動でmountコマンドを実行する場合は次のようにして下さい: mount -t nfs -o -r=1024 fastws:/sharedfs /project サーバ側FreeBSDシステムの例は: fastwsの/etc/fstabに次のように書いて下さい: freebox:/sharedfs /project nfs rw,-w=1024 0 0 fastws上で手動でmountコマンドで実行する場合は次のようにして下さい: mount -t nfs -o -w=1024 freebox:/sharedfs /project 近いうちにどのような16ビットのイーサネットアダプタでも上記の読み出し, 書き込みサイズの制限なしの操作ができるようになるでしょう. 失敗が発生したとき何が起きているか関心のある人に, なぜ回復不可能なのか も含めて説明します. NFSは通常 (より小さいサイズへ分割されるかもしれませんが) 8Kの"ブロック" サイズで働きます. イーサネットのパケットサイズは最大1500バイト程度なので, 上位階層のコードにとっては1つのユニットのままなのですが, NFS"ブロック"は 複数のイーサネットパケットに分割されます. そして受信され, 組み立て直されてから 肯定応答されなければなりません. 高性能のWSは次々に NFSユニットを構成するパケットを, 基準の範囲内で間隔を詰めて 次々に送り出すことができます. 小さく, 容量の低いカードでは, 同じユニットの 前のパケットがホストに転送される前に, 後のパケットがそれを 「踏みつぶし」てしまいます. このため全体としてのユニットは再構成もされないし, 肯定応答もされません. その結果, WSはタイムアウトして再送を試みますが, 8Kのユニット全体を再送しようとするので, このプロセスは 際限無く繰り返されてしまいます. ユニットサイズをイーサネットのパケットサイズの制限以下に抑えることにより, 受信された完全なイーサネットパケットは個々に肯定応答を受けられることが 保証されるので, デッドロック状態を避けることができるようになります. 高性能のカードを使っている場合でも, 高性能なWSが力任せに次々と PCシステムにデータを送ったときには「踏みつぶし」が起きるかもしれません. そのような「踏みつぶし」はNFS"ユニット"では保証されていません. 「踏みつぶし」が起こったとき, 影響を受けたユニットは再送されます. そして受信され, 組み立てられ, 肯定応答される公平な機会が与えられるでしょう. diff --git a/ja_JP.EUC/handbook/nutshell.sgml b/ja_JP.EUC/handbook/nutshell.sgml index ab134178b4..d12e173550 100644 --- a/ja_JP.EUC/handbook/nutshell.sgml +++ b/ja_JP.EUC/handbook/nutshell.sgml @@ -1,153 +1,153 @@ - + FreeBSD とは

原作: 不明.

訳: &a.tomo;.

FreeBSDはIntel社の (SXやDXも含めた) 386や486, Pentiumプロセッサ といったCPUアーキテクチャに基づくパーソナルコンピュータ用としては 現在求めうる最高水準のオペレーティングシステムです. AMD社やCyrix社のIntel互換CPUもサポートされています. FreeBSDは, 以前は高価なコンピュータでしか利用できなかった多くの 高度な機能を提供します. FreeBSDには次のような機能があります: アプリケーションとユーザとの間で円滑かつ公平にコンピュータを 共有することを保証する, 優先度を動的に調節する機能を備えた プリエンプティブマルチタスキング. 多くの人々が1つのFreeBSDシステムをさまざまな目的で同時に 使うことを可能にするマルチユーザアクセス. また, プリンタやテープドライブのようなシステムの周辺機器も すべてのユーザ間で適切に共有されます. SLIPやPPP, NFS, NISのサポートを含んだ完全な TCP/IPネットワーキング. これによって, FreeBSDマシンが商用サーバと同じように相互に運用でき, NFS (リモートファイルアクセス) や電子メールサービスのような極めて 重要な機能を提供します. また, WWWやftp, ルーティング, ファイアウォール (セキュリティ) サービスを用いてインターネットと 接続できます. アプリケーション (あるいはユーザ) がお互いに干渉できない ようにするメモリ保護機能. アプリケーションがクラッシュしても, どのような場合でも 他のアプリケーションには影響を与えません. FreeBSDは32ビットのオペレーティングシステムであり, 最初からそのようにこつこつと設計されました. 業界標準であるX Windowシステム (X11R6) は, 普通のVGAカードやモニタでグラフィカルユーザ インタフェース (GUI) を提供し, すべてのソースコードも一緒に提供されます. SCOやBSDI, NetBSD, Linux, 386BSD用に作られた多くの プログラムにおけるバイナリ互換性. 何百ものすぐに実行可能なアプリケーションが FreeBSDのportsやpackagesコレクション で利用可能です. ここに用意されているものは ネットを探し回る必要がありません インターネット上で入手可能な, 移植が容易な 何千ものアプリケーションを追加できます. FreeBSDは最も評判の よい商用のUnixシステムとソースコードレベルで互換性があります. このため, ほとんどのアプリケーションは, もしあったとしてもほんの 少しの変更でコンパイルすることができます. デマンドページング仮想メモリとそれに`付随の VM/buffer キャッシュ'の設計は, 多くのメモリを要求する アプリケーションに対して効率よくメモリを与えるようにする一方で, 他のユーザに対しても対話的な応答を維持します. 共有ライブラリ (MS-WindowsのDLLと同等のUnixの 機能) によって, ディスクスペースとメモリを効果的に使用する ことができます. 完全なCやC++, Fortranの 開発ツール. 進んだ研究や開発のための多くの他の言語も portsやpackagesコレクションで提供されています. システム全体のソースコードが提供されているので, 要求に合わせて環境を最大限に適合させることができます. 真のオープンシステムが利用できるのですから, 所有権のある解決方法に 締めつけられ, ベンダのなすがままになる必要はありません. 膨大な量のオンラインドキュメント. もう書ききれません! FreeBSDはカリフォルニア大学バークレイ校のComputer Systems Research Group (CSRG) による4.4BSD-Liteリリースを基にしており, BSDシステムの開発の優れた伝統を守り続けています. CSRGによる素晴らしい活動に加えて, FreeBSDプロジェクトは何千時間もの時間を注ぎ込んで, 実際の使用の場において最大の性能と信頼性を 発揮するためにシステムのチューニングをおこなっています. 多くの大企業がPCオペレーティングシステムの分野で 実現しようと奮闘しているそのような機能や性能, 信頼性を FreeBSDは今すぐ提供できます! あなたの思いつく限りのアプリケーションは, 何でもFreeBSDで 実行できます. ソフトウェア開発から ファクトリオートメーション, 在庫制御から遠く離れた人工衛星の アンテナの方向調整まで; 商用UNIX製品でできることは, FreeBSDでも十分にできるのです! また, FreeBSDは世界中の研究センターや大学によって開発される 文字通り何千もの高品質で, たいていはほとんど無料で利用できる アプリケーションによる恩恵を得ることができます. 商用のアプリケーションも提供されており, 日々増え続けています. FreeBSDのソースコードは広く提供されているので, システムも特別なアプリケーションやプロジェクトに合わせて, いくらでもカスタマイズすることができます. これは 有名な商業ベンダから出ているほとんどのオペレーティング システムでは不可能なことです. 以下に現在FreeBSDを 使っている人々のアプリケーションの例をいくつか上げます: インターネットサービス: FreeBSDに組み込まれている 頑強なTCP/IPネットワーキング機能は次のようなさまざまなインターネット サービスの理想的なプラットフォームになります: FTP サーバ World Wide Web サーバ Gopher サーバ 電子メールサーバ USENET ニュース 電子掲示板システム さらにいろいろ... まずは高価ではない386クラスのPCで始めておいて, 仕事の成長に合わせてアップグレードできます. 教育: あなたは計算機科学または工学の学生ですか? オペレーティングシステムやコンピュータアーキテクチャ, ネットワーキングを学習するなら, FreeBSDを手に 経験するのが一番よい方法です. 自由に利用できるCADや数学, グラフィックデザインのパッケージもいくつもあり, コンピュータに関心を持った人が他の人の成果を 手に入れて利用するのにとても役に立ちます. 研究:システム全体のソースコードが利用できるため, FreeBSDはオペレーティングシステムの研究だけでなく, 計算機科学の他の部門においても優れたプラットフォームです. 自由に利用できるFreeBSDの特長は, オープンフォーラムで 議論される特別なライセンスの同意や制限について 心配することなく, 離れたグループでもアイディアや開発の共有に よる共同研究を可能にします. ネットワーキング:新しいルータが必要? ネームサーバ (DNS) は? 内部のネットワークを人々から守る ファイアウォールは? FreeBSDはすみに眠っている使われていない386や486のPCを簡単に 洗練されたパケットフィルタリング機能を持つ高級なルータに 変えることができます. X Windowワークステーション: 自由に利用できるXFree86サーバやX Inside社から提供される 優れた商業サーバを使うことによって, 安価なX端末 としてFreeBSDを使うこともできます. X端末とは違ってFreeBSDは 多くのアプリケーションをローカルに走らせることもでき, 中心のサーバの負荷を軽減することも可能です. FreeBSDは"ディスクレス"でもブート可能であり, 個々のワークステーションを安価で, 容易に管理することさえ 可能にします. ソフトウェア開発: 基本的なFreeBSDシステムには 有名なGNUのC/C++コンパイラやデバッガ含んだ完全な開発ツールが ついてきます. FreeBSDはCDROMまたはanonymous ftpによってソース, バイナリとも 利用可能です. 詳しくは, を見てください. diff --git a/ja_JP.EUC/handbook/pgpkeys.sgml b/ja_JP.EUC/handbook/pgpkeys.sgml index 2942574792..70f6b0a3f7 100644 --- a/ja_JP.EUC/handbook/pgpkeys.sgml +++ b/ja_JP.EUC/handbook/pgpkeys.sgml @@ -1,250 +1,250 @@ - + PGP 公開鍵

原作: 不明.

訳: &a.kiroh;.

署名を検証したり, コアチームメンバやオフィサに暗号メー ルを送りたい場合のために, PGPの公開鍵を添付します. オフィサ FreeBSD Security Officer <security-officer@freebsd.org>

FreeBSD Security Officer <security-officer@freebsd.org> Fingerprint = 41 08 4E BB DB 41 60 71 F9 E5 0E 98 73 AF 3F 11 -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3i mQCNAzF7MY4AAAEEAK7qBgPuBejER5HQbQlsOldk3ZVWXlRj54raz3IbuAUrDrQL h3g57T9QY++f3Mot2LAf5lDJbsMfWrtwPrPwCCFRYQd6XH778a+l4ju5axyjrt/L Ciw9RrOC+WaPv3lIdLuqYge2QRC1LvKACIPNbIcgbnLeRGLovFUuHi5z0oilAAUR tDdGcmVlQlNEIFNlY3VyaXR5IE9mZmljZXIgPHNlY3VyaXR5LW9mZmljZXJAZnJl ZWJzZC5vcmc+iQCVAwUQMX6yrOJgpPLZnQjrAQHyowQA1Nv2AY8vJIrdp2ttV6RU tZBYnI7gTO3sFC2bhIHsCvfVU3JphfqWQ7AnTXcD2yPjGcchUfc/EcL1tSlqW4y7 PMP4GHZp9vHog1NAsgLC9Y1P/1cOeuhZ0pDpZZ5zxTo6TQcCBjQA6KhiBFP4TJql 3olFfPBh3B/Tu3dqmEbSWpuJAJUDBRAxez3C9RVb+45ULV0BAak8A/9JIG/jRJaz QbKom6wMw852C/Z0qBLJy7KdN30099zMjQYeC9PnlkZ0USjQ4TSpC8UerYv6IfhV nNY6gyF2Hx4CbEFlopnfA1c4yxtXKti1kSN6wBy/ki3SmqtfDhPQ4Q31p63cSe5A 3aoHcjvWuqPLpW4ba2uHVKGP3g7SSt6AOYkAlQMFEDF8mz0ff6kIA1j8vQEBmZcD /REaUPDRx6qr1XRQlMs6pfgNKEwnKmcUzQLCvKBnYYGmD5ydPLxCPSFnPcPthaUb 5zVgMTjfjS2fkEiRrua4duGRgqN4xY7VRAsIQeMSITBOZeBZZf2oa9Ntidr5PumS 9uQ9bvdfWMpsemk2MaRG9BSoy5Wvy8VxROYYUwpT8Cf2iQCVAwUQMXsyqWtaZ42B sqd5AQHKjAQAvolI30Nyu3IyTfNeCb/DvOe9tlOn/o+VUDNJiE/PuBe1s2Y94a/P BfcohpKC2kza3NiW6lLTp00OWQsuu0QAPc02vYOyseZWy4y3Phnw60pWzLcFdemT 0GiYS5Xm1o9nAhPFciybn9j1q8UadIlIq0wbqWgdInBT8YI/l4f5sf6JAJUDBRAx ezKXVS4eLnPSiKUBAc5OBACIXTlKqQC3B53qt7bNMV46m81fuw1PhKaJEI033mCD ovzyEFFQeOyRXeu25Jg9Bq0Sn37ynISucHSmt2tUD5W0+p1MUGyTqnfqejMUWBzO v4Xhp6a8RtDdUMBOTtro16iulGiRrCKxzVgEl4i+9Z0ZiE6BWlg5AetoF5n3mGk1 lw== =ipyA -----END PGP PUBLIC KEY BLOCK----- コアチームメンバ &a.jkh

Jordan K. Hubbard <jkh@FreeBSD.org> Fingerprint = 3C F2 27 7E 4A 6C 09 0A 4B C9 47 CD 4F 4D 0B 20 -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2i mQCNAzFjX0IAAAEEAML+nm9/kDNPp43ZUZGjYkm2QLtoC1Wxr8JulZXqk7qmhYcQ jvX+fyoriJ6/7ZlnLe2oG5j9tZOnRLPvMaz0g9CpW6Dz3nkXrNPkmOFV9B8D94Mk tyFeRJFqnkCuqBj6D+H8FtBwEeeTecSh2tJ0bZZTXnAMhxeOdvUVW/uOVC1dAAUR tCNKb3JkYW4gSy4gSHViYmFyZCA8amtoQEZyZWVCU0Qub3JnPokAlQMFEDF75D1r WmeNgbKneQEBXtcD+gJIv8JzZRKlDZyTCQanK8iRgE+zMhxptI0kDObaGxT1BrpY 4/EPyiUN10G4k2Jb+DOc8Lg2xDQ3xmvgipFf9NMNV/ThaEuZ3wA31I6tW/arQEqB Tp8u6T3v20m62t7Afo9HaoE6MBpHQUk2TilxgAd5P57sporL3pgW9YojIO9ziQCV AwUQMXyV2h9/qQgDWPy9AQEMfgP/RmbSg2WlesATUQ4WuanjcdREduKPyfQatrXD 2xt+jg9X78dTyiNN1YvLqvT6msfs04MKSC0hA2mou6ozw8Xak+1QmP0fBOZKp9pP 8szO188Do9ByzJPvHF1eXT7jFMOXVq8ZIl9iwjxcIDLzlxOz49DC7LO6AT+LKQk7 UGeP+lqJAJUDBRAxe+UG9RVb+45ULV0BAXZ9A/9F9gLpGukVNkeOjaqxQdJGTS+a xh/Abk0c/nKhAEyxpAl5JyQ3ifYk6BHhPvlTi9LrZoXGA8sk/eU4eRTZVzvGEC4G +xsavlE/xzku8855QTLPpkCunUpQeu1wzaIrUUE6Zjh05imFbJYyQOBgTFpuqWsC rsUpl+2mr8IGIxG5rA== =LW9i -----END PGP PUBLIC KEY BLOCK----- &a.phk

Poul-Henning Kamp <phk@FreeBSD.org> Fingerprint = A3 F3 88 28 2F 9B 99 A2 49 F4 E2 FA 5A 78 8B 3E -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3i mQCNAzAdpMIAAAEEALHDgrFUwhZtb7PbXg3upELoDVEUPFRwnmpJH1rRqyROUGcI ooVe7u+FQlIs5OsXK8ECs/5Wpe2UrZSzHvjwBYOND5H42YtI5UULZLRCo5bFfTVA K9Rpo5icfTsYihrzU2nmnycwFMk+jYXyT/ZDYWDP/BM9iLjj0x9/qQgDWPy9AAUR tCNQb3VsLUhlbm5pbmcgS2FtcCA8cGhrQEZyZWVCU0Qub3JnPokAlQMFEDF+jX1r WmeNgbKneQEBCrID/i/ri8/eXUXRJp2fqJqzvrWGTP9Ix1O4vMguah9IILijgpYy OJYkezZKijjVCVmLX7EwfNXfYkqLAWUa08eov4QfJfJDgfe+Z/3/UoX7RcJoy2Aj TBZQzOI9JMkrzFdtFGYwMr/QXhOdVVpSGeZ/6Hkrs7pd2Z6MNNrRf81ZyJyYiQCV AwUQMXyV5/UVW/uOVC1dAQFyfAP/SujU+lS2WQuat4O2wZOQ1rswUt6CthG8MOsc 7A9kfXnZbaM9Sdxj54CtAlqR4eJMOYk2kVqAtmCWETRuonJxr5TAJdf7q6kByVYc QEyDZvKJYwyrI9UQSelSgczWwiSB01aV9ACaKlEF9iHYvIKBa9HwJu3A9ggW9SYa AHcxHzuJAJUDBRAxSx5cH3+pCANY/L0BAY+TA/9YQPISXYaS+5r0I60wCJ+i3a9P C69Zak2ikgTHQi97LhpVtEsP3SAYInDw4YMS2oU9w1XxoiLLd9hUpcZlmO8Ip3vN F+E2ZCfR4sNzKarY5fdo+sxzatGWRPgnHjbm6RHWCw6qJACDD3VpaFjx2XD8QrOT yiObnbHhWBdoEAIyNokAlQMFEDE5Q6DvYbnpEdWO1QEBsvgD/0c6flBrSWr20oj8 eRJ1zl8ZAP/rpV0IEBvb3ZFsHsJL8QzTsx1typFFghrT7SDBDc52xY90JWAflEiG n9aIL5Q+RHVxjw30yDaRPAl9ll82o34GBaWBEw83bsI6Fg2XxDfc2X0KkEutlYAE XjiM95PQS+9PM//llDtPvkSxgpiJiQCVAwUQMOavJADy2QnruxtBAQE92wQAsKPq /U4G4ksslOXGaauSoBk9XO3lB147cSpra1w9ZxTSeo+8dgzNlxnugWDnw1mxauFJ BAMgHl74rrlD+Hp0Ltb9oOyRl3riPG0TOdfaS3T8w6vw52wOKzUrZ/0pB+2sDHzU qZXBbhOq3OXs1ZMNe3jh8w62JsLBWry/YMWRMnI= =MDQ9 -----END PGP PUBLIC KEY BLOCK----- &a.joerg

Joerg Wunsch <j@uriah.heep.sax.de> Fingerprint = DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2i mQCNAzGCFeAAAAEEAKmRBU2Nvc7nZy1Ouid61HunA/5hF4O91cXm71/KPaT7dskz q5sFXvPJPpawwvqHPHfEbAK42ZaywyFp59L1GaYj87Pda+PlAYRJyY2DJl5/7JPe ziq+7B8MdvbX6D526sdmcR+jPXPbHznASjkx9DPmK+7TgFujyXW7bjh2o/exAAUR tCZKb2VyZyBXdW5zY2ggPGpAaW50ZXJmYWNlLWJ1c2luZXNzLmRlPokAlQMFEDGp bnd1u244dqP3sQEBJnQD/RVSAzgf4uorv3fpbosI0LE3LUufAYGBSJNJnskeKyud ZkNkI5zGGDwVneH/cSkKT4ORooeqcTBxKeMaMuXPVl30QahgNwWjfuTvl5OZ8ors QGGWIn5FhqYXsKkjEGxIOBOfvvlVQ0UbcR0N2+5F6Mb5GqrXZpIesn7jFJpkQKPU tC1Kb2VyZyBXdW5zY2ggPGpvZXJnX3d1bnNjaEB1cmlhaC5oZWVwLnNheC5kZT6J AJUDBRAyCIWZdbtuOHaj97EBAVMzA/41VIph36l+yO9WGKkEB+NYbYOz2W/kyi74 kXLvLdTXcRYFaCSZORSsQKPGNMrPZUoLoAKxE25AoCgl5towqr/sCcu0A0MMvJdd UvlQ2T+ylSpGmWchqoXCN7FdGyxrZ5zzxzLIvtcio6kaHd76XxyJpltCASupdD53 nEtxnu8sRrQxSm9lcmcgV3Vuc2NoIDxqb2VyZ193dW5zY2hAaW50ZXJmYWNlLWJ1 c2luZXNzLmRlPokAlQMFEDIIhfR1u244dqP3sQEBWoID/RhBm+qtW+hu2fqAj9d8 CVgEKJugrxZIpXuCKFvO+bCgQtogt9EX+TJh4s8UUdcFkyEIu8CT2C3Rrr1grvck fxvrTgzSzvtYyv1072X3GkVY+SlUMBMArdl1qNW23oT7Q558ajnsaL065XJ5m7Ha cgTTikiofYG8i1s7TrsEeq6PtCJKb2VyZyBXdW5zY2ggPGpAdXJpYWguaGVlcC5z YXguZGU+iQCVAwUQMalkbHW7bjh2o/exAQFwwQP+Pa82QeWpJE0m7f4DXd/DiYAv h/DeXWtub1fXQ9yqAL131n8OzsSLMb0PwG/qyZrpK61sT3bAvtVlNftaxmuD7yaf 1SUQ3rNmsBq5/oju/3EKEiFc4gtuyaXG74y7y1XASIstck/0byfvO2t4z0R7d1RR nKRYeCspMcUjYshsoJeJAJUDBRAxpL3UPiAdBSUb0JkBAZg7BACE+mKhsrd39/P6 NattCCOSg76Pf2CVgZdvbb7qK4SmsVGz+58pi2OWM1M0rcHgNZKTIg9rBy47gui2 KOnqOR7ZuyMVJJqyEZZywmWmfCy/sR4Ui1PehZNNNBAi09u03ItbozrEH6Msa1oC 8mp86XOA70Et8e4DYtj5a9tVbjjtJYkAlQMFEDGCUB31FVv7jlQtXQEB5KgD/iIJ Ze5lFkPr2B/Cr7BKMVBot1/JSu05NsHgJZ3uK15w4mVtNPZcFi/dKbn+qRM6LKDF e/GF0HZD/ZD1FJt8yQjzF2w340B+F2GGEOwnClqZDtEAqnIBzM/ECQQqH+6Bi8gp kFZrFgg5eON7ikqmusDnOlYStM/CBfgpSbR8kDmF =Bz4E -----END PGP PUBLIC KEY BLOCK----- &a.ache

Andrey A. Chernov <ache@FreeBSD.org> Fingerprint = 33 03 9F 48 33 7B 4A 15 63 48 88 0A C4 97 FD 49 -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3ia mQCNAiqUMGQAAAEEAPGhcD6A2Buey5LYz0sphDLpVgOZc/bb9UHAbaGKUAGXmafs Dcb2HnsuYGgX/zrQXuCi/wIGtXcZWB97APtKOhFsZnPinDR5n/dde/mw9FnuhwqD m+rKSL1HlN0z/Msa5y7g16760wHhSR6NoBSEG5wQAHIMMq7Q0uJgpPLZnQjrAAUT tCJBbmRyZXkgQS4gQ2hlcm5vdiA8YWNoZUBuYWd1YWwucnU+iQCVAwUQMcm5HeJg pPLZnQjrAQHwvQP9GdmAf1gdcuayHEgNkc11macPH11cwWjYjzA2YoecFMGV7iqK K8QYrr1MjbGXf8DAG8Ubfm0QbI8Lj8iG3NgqIru0c72UuHGSn/APfGGG0AtPX5UK /k7BgI0Ca2po6NA5nrSp8tDsdEz/4gyea84RXl2prtTf5Jj07hflbRstGXK0MkFu ZHJleSBBLiBDaGVybm92LCBCbGFjayBNYWdlIDxhY2hlQGFzdHJhbC5tc2suc3U+ iQCVAwUQMCsAo5/rGryoL8h3AQHq1QQAidyNFqA9hvrmMcjpY7csJVFlGvj574Wj 4GPao3pZeuQaMBmsWqaXLYnWU/Aldb6kTz6+nRcQX50zFH0THSPfApwEW7yybSTI 5apJmWT3qhKN2vmLNg2yNzhqLTzHLD1lH3i1pfQq8WevrNfjLUco5S/VuekTma/o snzCCw7fQzCJAJUDBRAwKvwoa1pnjYGyp3kBARihBACoXr3qfG65hFCyKJISmjOv aoGranxUIkeDS0yQdTHzhQ+dwB1OhhK15E0Nwr0MKajLMm90n6+Zdb5y/FIjpPri u8dIrlHrWZlewa88eEDM+Q/NxT1iYg+HaKDAE171jmLpSpCL0MiJtO0i36L3ekVD 7Hv8vffOZHPSHirIzJOZTYkAlQMFEDAau6zFLUdtDb+QbQEBQX8D/AxwkYeFaYxZ YMFODHIvSk23hAsjCmUA2Uil1FeWAusb+o8xRfPDc7TnosrIifJqbF5+fcHCG5VS TGlhBhd18YWUeabf/h9O2BsQX55yWRuB2x3diJ1xI/VVdG+rxlMCmE4ZR1Tl9x+M tun9KqKVpB39VlkCBYQ3hlgNt/TJUY4riQCVAwUQMBHMmyJRltlmbQBRAQFQkwP/ YC3ahs3ZMMoriOlt3ZxGNUUPTF7rIER3j+c7mqGG46dEnDB5sUrkzacpoLX5sj1t GR3bvz9a4vmk1Av3KFNNvrZZ3/BZFGpq3mCTiAC9zsyNYQ8L0AfGIUO5goCIjqwO TNQIAOpNsJ5S+nMAkQB4YmmNlI6GTb3D18zfhPZ6uciJAJUCBRAwD0sl4uW74fte FRkBAWsAA/9NYqBRBKbmltQDpyK4+jBAYjkXBJmARFXKJYTlnTgOHMpZqoVyW96x naa5MzxEiu7ZWm5oL10QDIp1krkBP2KcmvfSMMHb5aGCCQc2/P8NlfXAuHtNGzYi I0UAIwi8ih/S1liVfvnqF9uV3d3koE7VsQ9OA4Qo0ZL2ggW+/gEaYIkAlQMFEDAO z6qx/IyHe3rl4QEBIvYD/jIr8Xqo/2I5gncghSeFR01n0vELFIvaF4cHofGzyzBp YsfA+6pgFI1IM+LUF3kbUkAY/2uSf9U5ECcaMCTWCwVgJVO+oG075SHEM4buhrzu tZiM1dTyTaepaPpTyRMUUx9ZMMYJs7sbqLId1eDwrJxUPhrBNvf/w2W2sYHSY8cd iQCVAwUQMAzqgHcdkq6JcsfBAQGTxwQAtgeLFi2rhSOdllpDXUwz+SS6bEjFTWgR sWFMy9QnOcqryw7LyuFmWein4jasjY033JsODfWQPiPVNA3UEnXVg9+n8AvNMPO8 JkRvCn1eNg0VaJy9J368uArio93agd2Yf/R5r+QEuPjIssVk8hdcy/luEhSiXWf6 bLMVHEA0J+OJAJUDBRAwDUi+4mCk8tmdCOsBAatBBACHB+qtW880seRCDZLjl/bT 1b145po60U7u6a3PEBkY0NA72tWDQuRPF/Cn/0+VdFNxQUsgkrbwaJWOoi0KQsvl Om3RrsxKbn9uvEKLxExyKH3pxp76kvz/lEWwEeKvBK+84Pb1lzpG3W7u2XDfi3VQ PTi35SZMAHc6C0Ct/mjNlYkAlQMFEDAMrPD7wj+NsTMUOQEBJckD/ik4WsZzm2qO x9FwerGq7Zwchc+Jq1YeN5PxpzqSf4AG7+7dFIn+oe6X2FcIzgbYY+IfmgJIHEVj DHH5+uAXyb6l4iKc89eQawO3t88pfHLJWbTzmnvgz2cMrxt94HRvgkHfvcpGEgby ldq6EB33OunazFcfZFRIcXk1sfyLDvYE =4Yu3 -----END PGP PUBLIC KEY BLOCK----- &a.rich

Rich Murphey <rich@FreeBSD.org> fingerprint = AF A0 60 C4 84 D6 0C 73 D1 EF C0 E9 9D 21 DB E4 -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAy97V+MAAAEEALiNM3FCwm3qrCe81E20UOSlNclOWfZHNAyOyj1ahHeINvo1 FBF2Gd5Lbj0y8SLMno5yJ6P4F4r+x3jwHZrzAIwMs/lxDXRtB0VeVWnlj6a3Rezs wbfaTeSVyh5JohEcKdoYiMG5wjATOwK/NAwIPthB1RzRjnEeer3HI3ZYNEOpAAUR tCRSaWNoIE11cnBoZXkgPHJpY2hAbGFtcHJleS51dG1iLmVkdT6JAJUDBRAve15W vccjdlg0Q6kBAZTZBACcNd/LiVnMFURPrO4pVRn1sVQeokVX7izeWQ7siE31Iy7g Sb97WRLEYDi686osaGfsuKNA87Rm+q5F+jxeUV4w4szoqp60gGvCbD0KCB2hWraP /2s2qdVAxhfcoTin/Qp1ZWvXxFF7imGA/IjYIfB42VkaRYu6BwLEm3YAGfGcSw== =QoiM -----END PGP PUBLIC KEY BLOCK----- &a.peter

Peter Wemm <peter@FreeBSD.org> Fingerprint = 47 05 04 CA 4C EE F8 93 F6 DB 02 92 6D F5 58 8A -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3ia mQCNAy9/FJwAAAEEALxs9dE9tFd0Ru1TXdq301KfEoe5uYKKuldHRBOacG2Wny6/ W3Ill57hOi2+xmq5X/mHkapywxvy4cyLdt31i4GEKDvxpDvEzAYcy2n9dIup/eg2 kEhRBX9G5k/LKM4NQsRIieaIEGGgCZRm0lINqw495aZYrPpO4EqGN2HYnOMZAAUT tCVQZXRlciBXZW1tIDxwZXRlckBoYXl3aXJlLmRpYWxpeC5jb20+iQCVAwUQMbET 6kqGN2HYnOMZAQG1iwP/atRXZ55OLp6RkLBt9UG7a+AM2kA+ZvyRyOIEZkpm4+pb iTIDRt36TtOhnf2e7scgiQfKU7LdmvAv5YzmGcVk/ubks5EF3jIuXGHCNbGW1KZB 7Zqj1utt4a9Twd2SwNUyHE20FvjcybMUNT3OlxvXxpE/Vl0Ft14XrQD/o7lUwIS0 JVBldGVyIFdlbW0gPHBldGVyQHBlcnRoLmRpYWxpeC5vei5hdT6JAJUDBRAxsRQh SoY3Ydic4xkBAel5A/9hzsH7ha50FLXcBT1JILRKjXkq+uI0NzGs/MYBLW2sP8pt T24WwpN9dVFkKuPos2RNsZLR0xQpSX2jJ8VSH26D8rokhffSh4lp3/xrKXrdEu5v /kVyMGYtakqrwGp8TIgO5CoBUgpnIc2rPE0HMslx7Z/4Jfb9JISZG/3790dtG7Qe UGV0ZXIgV2VtbSA8cGV0ZXJARnJlZUJTRC5vcmc+iQCVAwUQMbESXUqGN2HYnOMZ AQGSVAP+IvzVh8+SyB/0eCBf91dy5XhcjBa+RDxWNP+JnL9r/o7vYG6zhDP8XeC5 T68dV6j3me+CUOivZh0euEYSke2SSfQPtdsq+XVaooXvddSsiymm/eKmVB2It+lk LtlbSxp8P7fCYOOH0Es2wReavYk83HzTmIUZEg9wXQ6wt5ZcsDu0JVBldGVyIFdl bW0gPHBldGVyQHNwaW5uZXIuZGlhbGl4LmNvbT6JAJUDBRAxsRItSoY3Ydic4xkB AXQOBACpjRZY/ERfR0LKCN1Gm572KgFjecAsBAeLvmX/M6ujh4nNt086CtUj5Zkn QRNXV10Bkumog5C0/sTnXnsDbO531CHB/wwY0rpJQDicypYlz0FuxJLijcMuHquW 5fo9xwdu4vlgV4Z+jmjTUGOu+CxmkeNRBquOFqOQE3CInIoP8w== =iB1t -----END PGP PUBLIC KEY BLOCK----- diff --git a/ja_JP.EUC/handbook/policies.sgml b/ja_JP.EUC/handbook/policies.sgml index 90fcbb4aaf..5f1a1c7e4d 100644 --- a/ja_JP.EUC/handbook/policies.sgml +++ b/ja_JP.EUC/handbook/policies.sgml @@ -1,206 +1,206 @@ - + ソースツリーのガイドラインおよび方針

原作: &a.phk;.

訳者: &a.mihoko; 6 September 1996 . 本章は, FreeBSD のソースツリーについてのさまざまなガイドラインや ポリシーについて書かれています. Makefile 中の MAINTAINER

1996年6月.

FreeBSD 配布物の特定の部分が, 一人の人やグループによって保守 されている場合は, ソースツリーの当該 Makefile に MAINTAINER= email-addresses

が付け加えられています. これを記述することによって, この部分が誰 に保守管理されているかを世界中のユーザに伝えることができます.

この意味は次のとおりです:

保守担当者がそのコードを所有し, そのコードに対する責任を持っ ています. すなわち, その人がそのコードに関するバグの修正やトラブル報告 に対する回答をします. また, そのコードが寄贈ソフトウェアの場合には, そのソフトウェアの新しいバージョンに適切に追従させる作業をその人が行い ます.

保守担当者が決められているディレクトリに対して変更をおこなう場合は, 変更をおこなう前に, その変更内容を保守担当者に送って, 保守担当者にレビューをしてもらってください. 保守担当者が, 電子メールに一定期間応答しない場合にのみ, 保守担当者がレビューすることなしに, 変更をおこなうことが認められます. しかしながら, そのような場合でも可能な限り, 変更点を第三者にレビュー してもらうようにしてください.

もちろん, この義務を引き受けることができない人やグループを 保守管理者として追加することはできません. また, 保守管理者がソースツリー管理者 ("committer") である必要は ありません. 寄贈ソフトウェア

1996年6月.

FreeBSD 配布物のうちのいくつかのソフトウェアは FreeBSD プロジェクト 以外のところで保守されています. 歴史的な経緯から, 私たちはこれを 寄贈 ソフトウェアと 呼んでいます. perl や gcc, patch などがその例です.

ここ数年来, この種のソフトウェアの取り扱いには, さまざまな方法が 取られてきましたが, どの方法にもいくつかの利点と欠点があります. これまで欠点のない明確な方法はありませんでした.

議論した結果, これらの方法のうちの一つが「公式な」方法として選択され ました. その方法が, 今後, この種のソフトウェアを取り込む場合に, 使用 されます. その上, この方法では, だれもが(cvs にアクセス権のない人でさえ)「公式」 バージョンのソースに対する差分を簡単に得ることができます. これは古い方法にはなかった大きな利点です. ですから, 既存の寄贈ソフトウェアも, この方法に収束していくことを強く望んでいます. この方法を使用することにより, 寄贈ソフトウェアの主な開発者に, 変更 点を返すのがとても容易になります.

しかしながら結局, 寄贈ソフトウェアの取扱は, 実際に作業を行って いる人々に委ねられています. もしこの方法を使用することが, その人が扱っているパッケージには 極端に合わないような場合には, コアチームの承認さえあれば, これらの ルールに反しても, 他の開発者の一般的な合意は得られるでしょう. 将来にわたってパッケージを保守できるということは, 大変重要な事柄に なってきます.

プログラミング言語 Tcl は, この方法が活用されているよい例になっています:

src/contrib/tcl には, このパッケージの保守管理者が 配布したソースが含まれています. この中からは FreeBSD に完全には適用 できない部分が削除されています. Tcl の場合は, "mac", "win", "compat" というサブディレクトリは, FreeBSD に取り込む前に削除されて いました.

src/lib/libtcl には, ライブラリを生成したり, ドキュ メントをインストールする際に使用される, 標準の bsd.lib.mk の 規則を使用した「bmake スタイル」の Makefile だけが 含まれています.

src/usr.bin/tclsh には, bsd.prog.mk 規則 を使用して, "tclsh" プログラムや関連するマニュアルページを生成 /インストール する bmake スタイルの Makefile だけが含まれています.

src/tools/tools/tcl_bmake には, tcl ソフトウェアを更新する必要が生じたときの助けになる2つのシェルス クリプトが含まれています. これらは, ソフトウェアを構築するのに使用し たり, インストール対象になるソフトウェアではありません.

ここ重要なのは, "src/contrib/tcl" ディレクトリが, 規則にしたがっ て作られているということです. つまり, できるだけ FreeBSD に特化した 変更をおこなわないようにしたソースを(CVS のベンダブランチに)おくようにし ています. freefall 上の「簡易取り込み」ツールは, 寄贈ソフトウェアを取り込む 手助けとなります. けれども, このツールの実行方法に疑問が生じた場合は, まずはじめに質問して, 失敗をしないようにしてください. そして, その疑問を「解決して」からツールを使用してください. CVS に寄贈ソフトウェアを取り込む際には, 事故があってはいけません. よくあるような間違いをおかさないように, 十分注意してください.

CVS には, 残念なことにベンダブランチという設計制限があります. このため, CVS に寄贈ソフトウェアを取り込むには, オリジナル配布ソースに 適用されるベンダからの「公式」パッチと, ベンダブランチに逆輸入された 結果が必要です. ベンダブランチの一貫性を破壊したり, 将来, 新しいバージョンを取り込む 時に衝突を起こしてしまったりというような 困難な事態に陥らないように しなければなりません. そのために, FreeBSD が管理しているバージョンに 対して, 公式パッチを決して当ててはいけませんし, 公式パッチを "commit" してはいけません.

多くのパッケージが, 他のアーキテクチャや他の環境と FreeBSD との互換性を保ためのファイルをいくつか含んでいます. そこで, スペースを節約するために, FreeBSD にとっては無意味な配布ツリー上の一 部を削除することが許されています. けれども, 削除されずに残ったファイルに対する, 著作権の通知やリリース ノートのような情報を含んだファイルは, 決して削除しては いけませ ん .

"bmake" Makefile が何らかのユーティリティによって, 配布ツリー から自動的に生成できると, うまくいけば, 新しいバージョンへの アップグレードをより簡単におこなうことができます. もしこのようなユーティリティを作成できた場合には, 将来の管理者に とって便利になるように, 移植の際に, src/tools ディレクトリ上に, (必要に応じて)そのユーティリティを必ずチェックインしてください.

src/contrib/tcl レベルのディレクトリには, README.FreeBSD と 呼ばれるファイルが追加されており, そのファイルでは 次のような内容が 記述されています. ディレクトリ上に存在するファイル オリジナルの配布物をどこから入手すればよいか また, 公式配布 サイトはどこか オリジナルの作者にパッチを送り返すためには, どこに送ればよいか FreeBSD に特化した変更点の概要 共有ライブラリ

Contributed by &a.asami;, &a.peter;, and &a.obrien;. 9 December 1996.

もしあなたが共有ライブラリをサポートする機能を port に追加した り, 共有ライブラリをサポートしていない他のソフトウェアに追加する 場合には, 共有ライブラリのバージョン番号を次の規則にしたがって つけてください. 一般的には, この規則は, ソフトウェアのリリースバージョンとは 全く関係ありません.

共有ライブラリを作成する三つの重要な規則は次の通りです: 1.0 から始める 過去のバージョンに互換性のある変更の場合は, マイナー番号を増やす 互換性のない変更の場合は, メジャー番号を増やす

例えば, 機能追加とバグ吸収の場合は, マイナー番号を増やします. 機能削除, 関数呼び出しのシンタックスなどが変更された場合は, 強制的にメジャー番号を変更します.

メジャー.マイナーー (x,y) の形式のバージョン番号を使用します. FreeBSD のダイナミックリンカは, x.y.z という形式のバージョン番号 は扱えません. この場合, 「y」の後のバージョン番号(つまり三つ目の数字)は, どのライブラリがリンクされているかを決めるために, 共有ライブラ リ番号を比較する際に, すべて無視されます. 「小さな」リビジョンだけが異なる二つの共有ライブラリが指定 されると, ld.so は, リビジョンの大きい方の共有ライブラリを リンクします. すなわち, もしあなたが libfoo.so.3.3.3 をリンク していたとすると, リンカは頭の 3.3 という部分だけを認識し, libfoo.so.3 ではじまり その後に 3 以上の数字が続くもののうち、 最も大きい番号の付いているライブラリをリンクします.

ld.so はいつも最も大きい「マイナー」リビジョンのものを使うことに 注意してください. 例えば, プログラムがはじめ libc.so.2.0 を リンクしていたとしても, libc.so.2.0 よりも libc.so.2.2 を優先 して使用します.

移植されていないライブラリに対しては, リリースごとに共有ライブラリの バージョン番号を一度だけ変更するのが私たちのポリシーです. あなたがシステムライブラリのバージョン番号を上げた場合は, Makefile の commit ログを確認してください. 結果としてそのリリースには, 共有ライブラリのバージョン番号が アップデートされた Makefile に入るので、最初にその変更を 確かめるのがソースツリー管理者 ("committer") の責務です. その後のどんな変更も, そのリリースには入りません. diff --git a/ja_JP.EUC/handbook/porting.sgml b/ja_JP.EUC/handbook/porting.sgml index c6a71c4310..076d7785ed 100644 --- a/ja_JP.EUC/handbook/porting.sgml +++ b/ja_JP.EUC/handbook/porting.sgml @@ -1,1379 +1,1379 @@ - + フリーソフトウェアの移植

原作: &a.jkh;, &a.gpalmer; &a.asami;. 7 November 1996.

訳: &a.simokawa;, &a.asami;. 10 November 1996.

フリーで手に入るソフトウェアを移植することは, 何かをゼロから自分で 作ることほどは人に感謝されないにしても, どこに手を入れれば動くのかわから ないような人でも使えるようにするという意味で, FreeBSDの発展のためにとて も重要なことです. 移植されたすべてのソフトウェアは「Portsコレク ション」(the Ports Collection) と呼ばれ, 階層的に分類されて集められ ています. これによって, 新しいユーザでも, 何がすぐに簡単にコンパイルで きる状態で手に入るのか, についての概要をつかむことができます. また, 移植されるソー スコードについては, そのほとんどを実際には含まず, FreeBSDで動かすためのほんのちょっ との差分ファイルといくつかの定義ファイルだけをソースツリーに入れることで, かなりのディスクスペースが節約できます.

これから, FreeBSD 2.x用のportを作る際の, いくつかのガイドラインを 説明します. 実際にportをコンパイルするときのほとんどの仕事は /usr/share/mk/bsd.port.mkというファイルでおこないます. Portsコレクションについてのさらに細かい内部の働きについては, そちらのファイルを 参照してください. 移植を始める前に

注意: ここでは, 変更可能な変数の一部についてのみ記述してい ます. ほとんどの変数はbsd.port.mkの始めに記述があり ます. また, このファイルは非標準のタブの設定になっていま す. Emacsはファイルのロード時にこれを認識しますが, viやexでは, ファイルをロードしたら `:set tabstop=4'のようにして正しい値を設定することがで きます.

Portの過程で, 修正や, どのバージョンのUNIXで動くかによる条件 つきコンパイルなどが必要なコードに出会うかもしれません. その ような条件つきコンパイルなどのための変更をおこなうときには, FreeBSD 1.x システムへの移植や, CSRGの4.4BSD, BSD/386, 386BSD, NetBSDなどの他のBSDシステムへの移植が可能なように, でき るだけ普遍的な変更をおこなうことを心がけてください.

4.3BSD/Renoおよびそれより新しいBSD版を古いバージョンと区別す るには `BSD' マクロを利用するのがよいでしょう. これは <sys/param.h>で定義されています. このファイルが すでにインクルードされていればよいのですが, もしそうでない場合 には以下のコードを, その.c ファイルの適当な場所に加 えて, MakefileのCFLAGSに-D_HAVE_PARAM_Hを加 えてください. #ifdef _HAVE_PARAM_H #include #endif そして, 次のようにしてそのコードが4.3 Net2コードベース, または それより新しいもの (例: FreeBSD 1.x, 4.3/Reno, NetBSD 0.9, 386BSD, BSD/386 1.1とそれ以前) の上でコンパイルされているかを検出できます. #if (defined(BSD) && (BSD >= 199103)) また, #if (defined(BSD) && (BSD >= 199306)) これは, 4.4コードベース, またはそれより新しいもの (例: FreeBSD 2.x, 4.4, NetBSD 1.0, BSD/386 2.0とそれ以後) の上でコンパイルさ れているかどうかを検出するために使用します.

以下は控え目に使ってください. __FreeBSD__ はFreeBSDのすべての版で定義されてい ます. 変更がFreeBSDだけに適用されるとき以外は使用しないでく ださい. Portでよくある, strerror() ではなく sys_errlist[] を使うなどは, FreeBSDでの変更ではなく, BSDの流儀です. FreeBSD 2.xでは__FreeBSD__が2と定義されていま す. それ以前の版では1になっています. もし, FreeBSD 1.xシステムとFreeBSD 2.xシステムを区別 する必要があれば, 上で述べたBSDマクロを使用するのが, 大抵の場合において正しい答です. もし, FreeBSD特有の変更であ れば (`ld' を使うときのシェアードライブラリ用のな オプションなど), __FreeBSD__を使い `#if __FreeBSD__ > 1' のようにFreeBSD 2.x システムを検出するのはかまいません. もし, 2.0-RELEASE以降のFreeBSDシステムを細かく検出したけれ ば, 以下を使用することができます. #if __FreeBSD__ >= 2 #include # if __FreeBSD_version >= 199504 /* 2.0.5+ release specific code here */ # endif #endif __FreeBSD_version の値は以下の通りです: 2.0-RELEASE: 199411 2.1-current's: 199501, 199503 2.0.5-RELEASE: 199504 2.2-current (2.1以前): 199508 2.1.0-RELEASE: 199511 2.2-current (2.1.5以前): 199512 2.1.5-RELEASE: 199607 2.2-current (2.1.6以前): 199608 2.1.6-RELEASE: 199612 2.2-RELEASE: 199701 3.0-current (1997年2月現在) 199702 (リリースが出る毎に変わります) 見ての通り, これは年・月というフォーマットになっています.

これまで, 何百ものportが作られてきましたが, __FreeBSD__が正しく使われたのは, 1つか2つの場合だけで しょう. 以前のportが誤った場所でそのマクロが使っているからと いって, それをまねする理由はありません. 3分porting

この節では, 簡単なportの方法について説明します. 多くの場合これ では不十分ですが, まあうまくいくかどうか試してみて損はないでしょ う.

まず, 元のtarファイルを${DISTDIR}に置きます. デフォルトは/usr/ports/distfilesです.

注: 以下では, ソフトウェアはそのままコンパイルされるとします. つまり, FreeBSDのマシンで動かすために, 変更がまったく必要ない とします. もしなにか変更が必要な場合には次の節も参照する必要 があります. Makefileの作成

最小限のMakefileは次のようなものです: # New ports collection makefile for: oneko # Version required: 1.1b # Date created: 5 December 1994 # Whom: asami # # $Id$ # DISTNAME= oneko-1.1b CATEGORIES= games MASTER_SITES= ftp://ftp.cs.columbia.edu/archives/X11R5/contrib/ MAINTAINER= asami@FreeBSD.ORG USE_IMAKE= yes .include

おわかりになりますでしょうか. $Id$があ る行の内容については, 気にしないでください. これはこのファイル がportsツリーに書き込まれるときにCVSによって自動的に書 き込まれます. もっと詳しい例が見たければ, の節をご覧ください. Package記述ファイルの作成

どのようなportでも, packageにするしないに関わらず, 3つ の記述ファイルが必要です. pkgサブディレクトリにある, COMMENT, DESCR, それにPLISTです. COMMENT

これには, そのportについての説明を1行で書きます. Package の名前, バージョン番号等は含めないでください. たとえば, こんな具合です: A cat chasing a mouse all over the screen DESCR

これは, そのソフトウェアについての, すこし長い説明を記述しま す. そのportが何をするのかについての数段落程度の簡潔な解説があれば 十分です. 注: このファイルはマニュアルでもなければ, 使用方 法やコンパイル方法についての細かい説明書ではありません. 特 に, READMEファイルを何も考えずにここにコピーするような ことはしないでください. (もちろん, READMEがそのソフトウ ェアの簡潔な説明になっている場合は別ですが.)

このファイルの最後にあなたの名前を書くことが推奨されています. たとえば, こんな具合です. This is a port of oneko, in which a cat chases a poor mouse all over the screen. : (うんぬん.) - Satoshi asami@cs.berkeley.edu PLIST

このファイルには, このportによってインストールされるファ イルが列挙されます. このファイルはpackageを作る際のリス トとして使われるため, `packing list' とも呼ばれます. ここ に書かれているファイル名は, インストール時のプレフィックス (普通は/usr/localか/usr/X11R6) からの 相対パスです.

簡単な例を載せておきましょう: bin/oneko man/man1/oneko.1.gz lib/X11/app-defaults/Oneko lib/X11/oneko/cat1.xpm lib/X11/oneko/cat2.xpm lib/X11/oneko/mouse.xpm

'Packing list'の詳細については, pkg_create(1)の マニュアルを参照してください. チェックサムファイルの作成

ただ, `make makesum' と入力するだけです. bsd.port.mkにルールがあるので, 自動的にfiles/md5が 生成されます. Portのテスト

そのportが正しく動くことを, package化を含めて確認してく ださい. まず, `make install', `make package' を試してください. また, `pkg_delete -d <pkgname>' をして,すべてのファイルが正しく消去さ れているかどうかを確認してください. それから, `pkg_add <pkgname>.tgz' をおこない, すべてのファイルが再び現 れ, 正しく動作することを確認してください. Portの送付

さあ, あなたのportに満足したら, あとはそれをFreeBSDのメイ ンのportsツリーに置いて, 皆に使ってもらうだけです. そのた めには, 必要なファイル (この節で述べたすべてのファイル -- た だし, オリジナルのソースファイル, `work' サブディレ クトリ, およびpackageは含みません) をまとめて .tar.gz ファイルにし, ftp://ftp.FreeBSD.ORG/pub/FreeBSD/incoming/ へ置き, send-pr(1) を使って私たちのところにメールを送っ てください (categoryは `ports', classは `change-request' を 使ってください). 私たちは, 何か不明な点があったらあなたに確 認したのち, それをツリーへ置きます. あなたの名前は, FreeBSD ハンドブックやその他のファイルの `Additional FreeBSD contributors' のリストにも載るでしょう. う〜ん, 素晴らし い. :) 本格的なport

残念ながら, 移植がそう簡単ではなく, 動かすために多少の変更が 必要な場合も多いでしょう. この節では, portsコレクション の方法論にのっとって, そのような場合にどのように変更を施し, 動 くようにしたらよいかを順を追って説明します. port構築の詳細

まず, あなたがportのディレクトリで `make' とタイ プしてから起こる一連の出来事について,順を追って説明しま す. ここを読むときには, 他のウィンドウで同時に bsd.port.mkも開いておくとよいかもしれません.

しかし, bsd.port.mkが何をしているのか, 完全に理解 できなくても心配する必要はありません. そう多くの人が理解して いるわけではないですから... f(^_^;) まず, fetchというターゲットが実行されます. このfetchターゲッ トはローカルディスクの${DISTDIR}に配布ファ イルがあるようにするのが役目です. もし, fetchが必要なファ イルを${DISTDIR}に見つけることができなけ れば, Makefileに指定されているURL ${MASTER_SITES}, そして私たちのFTPサイトで ある (ここ には, 私たちが取ってきたファイルをバックアップとして置いてあ ります) に探しにいきます. そして, ユーザのサイトがインター ネットに直接接続されている場合には, ${FETCH} を使って, その名前のファイルを取っ てきて, ${DISTDIR}に保存します. 次に実行されるのはextractターゲットです. これは, ${DISTDIR}にある, 配布ファイル (普通は gzipされたtarファイル) を読み, ソースを一時的な作業ディレ クトリ${WRKDIR} (デフォルトは work) に展開します. 次に, patchというターゲットが実行されます. まず, ${PATCHFILES}に定義されている, すべてのパッ チをあてます. 次にもし${PATCHDIR} (デフォ ルトはpatches サブディレクトリ) にパッチが存在す れば, これらをアルファベット順にあてます. 次に実行されるターゲットはconfigureです. これには, い ろいろな場合があります. もし存在すれば, scripts/configure が実行されます. もし, ${HAS_CONFIGURE} あるいは ${GNU_CONFIGURE} がセットされていれば, ${WRKSRC}/configure が実行されます. もし, ${USE_IMAKE} がセットされていれば, ${XMKMF} (デフォルト: `xmkmf -a') が実行されます. 最後に, buildというターゲットが実行されます. これは, そのport の専用の作業ディレクトリ (${WRKSRC}) にい き, コンパイルするのが役目です. もし ${USE_GMAKE} がセットされていれば, GNU makeが使用されます. さもなければFreeBSDの makeが使用されます.

上記はデフォルトのルールです. さらに, `pre-<何とか >や `post-<何とか>' というターゲット が定義してあったり, そのような名前のスクリプトが scripts サブディレクトリに置いてある場合には, それ らはデフォルトの動作の前後に実行されます.

たとえば, post-extractというターゲットがMakefile で定義されていて, pre-buildというファイルが, scriptsサブディレクトリにあるとすると, post-extractターゲットは, 通常の展開動作のあとに呼 び出され, pre-buildスクリプトはデフォルトのコンパイ ルのルールが実行される前に実行されます. もし動作が簡単であれ ば, Makefileのターゲットを使用することが推奨されています. な ぜならば, そのportが何らかのデフォルトではない動作を必要とす るのかどうかが一箇所にまとめて書いてあった方が他の人に理解しやす いからです.

デフォルトの動作はbsd.port.mk の `do-<何とか>' というターゲットでおこなわれます. たとえば, portを展開するコマンドは, `do-extract' というターゲットにあります. もし, デフォルトのターゲットに 不満があれば, `do-<something>' というターゲッ トを再定義することによって, どのようにでも直すことができます.

「メイン」のターゲット (例えば, extract, configure等) は, すべての前段階が実行されていること を確認して, 実際のターゲットやスクリプトを呼び出す以外のこと はしません. bsd.port.mkはこれらが変更されることは仮定してい ませんので, もし, 例えば, 展開の仕方を直したいときには, do-extract を直し, 絶対にextractには手を 触れないでください.

これで, ユーザが `make' と入力したときに何が起こ るのかが理解できたと思います. では, 完璧なportを手順を追っ て作ってみましょう. オリジナルのソースの入手

オリジナルのソースを, (普通は) 圧縮されたtarファイルの形 (<foo>.tar.gzあるいは <foo>.tar.Z) で入手して, それを ${DISTDIR} にコピーします. 可能なかぎり, 広 く使われている主流のソースを使用するようにしてください.

もし, ネットワークへの接続のよいFTP/HTTPサイトを見つけるこ とができなかったり, 頭にくるような非標準的な形式しか持ってい ないサイトしか見つけられないときには, 最後の手段として, 私たち 自身で, ftp://freefall.FreeBSD.ORG/pub/FreeBSD/LOCAL_PORTS/ に置くことができます. これについての問い合わせのメールは は &a.ports へお願いします.

もし, あなたのportに必要ないくつかの追加パッチがインター ネット上で手に入るのならば, それらも取ってきて, ${DISTDIR} に置きます. もし, それらがメイン のソースのtarファイルとは別のサイトにあっても, 心配する必要 はありません. そのような状況にはちゃんと対応できるようになっ ています. (以下のをご覧く ださい). Portの修正

適当なディレクトリにtarファイルを展開して, FreeBSDの最新の バージョン上で, 正しくコンパイルできるために必要なあらゆる変 更を施します. 最終的に処理は自動化するわけですから, 何をおこなっ たかを注意深く記録しておきましょう. あなたのport が完成した暁には, ファイルの削除, 追加, 修正を含むすべての処 理が, 自動化されたスクリプトやパッチファイルでおこなえるようになっ ていないといけません.

もし, あなたのportのコンパイルやインストールのために必要 な手作業があまりに多いようならば, Larry Wallの模範的な Configureスクリプトでも参考にしたほうがいいかもしれませ ん. 新しいportsコレクションは, 最小のディスクスペースで, 個々のportがエンドユーザにできるだけ「プラグ & プレ イ」の状態でmakeできることをめざしています.

注意: あなたが作成しFreeBSDのportsに寄付されたパッチファイル, スクリプトおよびその他のファイルは，明示的に記述されている場合 を除いては, BSDの標準的な著作権条件によりカバーされていると見な されます． パッチをあてる

portの過程で追加されたり変更されたファイルは再帰的diffで変 更点を取り出すことができます. パッチは適当にまとめて, `patch-<xx>' という名前のファイルに入れてくだ さい. <xx>はパッチが適用される順番を示します -- これらは, アルファベット順, つまり `aa' が 最初, つぎに `ab' などとなります. これらのファイル を${PATCHDIR}に置いておくと, 自動的に適用さ れるようになっています. すべてのパッチは ${WRKSRC} (通常は, portのtarファイルが展 開されるところで, makeが実行されるところと同じです) からの相 対パスになります. 修正やアップグレードを容易にするため, 2つ 以上のパッチが同じファイルを修正するのは避けてください. (例, patch-aaとpatch-abが共に${WRKSRC}/foobar.c を修正する, など.) コンフィグレーション

カスタマイズのために追加したいコマンドがあれば, configureという名前のスクリプトに入れて `scripts' サブディレクトリに置きます. 上で述べたよ うに, pre-configure あるいはpost-configure というMakefileのターゲットおよび/あるいはスクリプトで処理す ることもできます. ユーザからの入力の扱い

もし, そのportがビルド, コンフィグレーション, インストー ルの際にユーザからの入力を必要とするならば, Makefileで IS_INTERACTIVEをセットしてください. これによって, 深夜, 自動的にたくさんのportをコンパイルすることが可能にな ります. 環境変数BATCHがセットされていると IS_INTERACTIVEの定義されているportはスキップされ ます (そして, ユーザがINTERACTIVEという変数をセッ トすると入力を必要とするportのみコンパイルされま す). Makefileの作成

Makefileの作成は非常に単純です. 繰り返しになりますが, 始める まえに, すでにある例を見てみることをお奨めします. またこのハ ンドブックには があります. それを見て, Makefile内の変数の順番や空行を入れると ころなどの参考にしてください. そうすると他の人々にも読みやすい ものとなります.

では, Makefileをデザインするときに問題となるところを順に追っ て見てみましょう. オリジナルのソース

ソースは${DISTDIR}に, 標準的なgzipされた tarファイルとして置かれていますか? そうであれば, 次のステッ プに進めます. そうでなければ, 変数 ${EXTRACT_CMD}, ${EXTRACT_BEFORE_ARGS}, ${EXTRACT_AFTER_ARGS}, ${EXTRACT_SUFX}, ${DISTFILES}を適当に書き換えないといけません. どれだけ変更しないといけないかは, あなたのportの 配布ファイルがどの程度標準からかけはなれているかによりま す. (最もよくある場合は, gzipではなく普通のcompressコマンド でtarファイルが圧縮されている場合で, `EXTRACT_SUFX=.tar.Z' とするだけです.)

最悪の場合には, 自分で `do-extract' ターゲットを作 成して, デフォルトを上書きすることもできます. しかし, そこま でする必要があることはめったにないでしょう. DISTNAME

${DISTNAME}にはportの名前の基幹部分を入れ ます. デフォルトのルールでは, 配布ファイルのリスト (${DISTFILES}) は ${DISTNAME}${EXTRACT_SUFX}という名前 になっています. 例えば, `DISTNAME=foozolix-1.0'の場 合, 通常のtarファイルだと, foozolix-1.0.tar.gz のようになります. さらにデフォルトのルールでは, tarファイルは work/${DISTNAME}というサブディレクトリ に展開されることを仮定しています, 例えば work/foozolix-1.0/ といった具合いです. これらの動作はもちろんすべて変更可能です. デフォルトのルー ルは最も標準的な場合を仮定しているだけです. まず, portが複 数の配布ファイルを必要とするときには, 単に明示的に ${DISTFILES}を設定してください. もし, ${DISTFILES}の一部だけが実際に展開される場合 には, それらを${EXTRACT_ONLY} に設定してくだ さい. この変数が定義されている場合には, 展開時に ${DISTFILES}に優先して利用されます. 残りのファ イルも${DISTDIR}に取ってきますが, 展開時に はなにもせずに後で使うためにそのまま置いておかれます. CATEGORIES (分類)

完成したpackageの実体は/usr/ports/packages/All に置かれます. また, 1つかそれ以上の /usr/ports/packagesのサブディレクトリからのシンボリッ クリンクが作られます. それらのサブディレクトリの名前が ${CATEGORIES}という変数によって指定されます. これは, ユーザがFTPサイトやCD-ROMのpackageの山を渡り歩 くことを容易にするためです. 現在存在するカテゴリを見て, そ のportに適したもを選んでください. (などが参考になるでしょう). もしそのportが本当 に現在存在するすべてのものとは異なっている場合には, 新しいカテ ゴリ名を作ることもできます. MASTER_SITES

オリジナルの配布ファイルを指し示すFTPまたはHTTPのURLのディ レクトリ部分までを${MASTER_SITES}に記録しま す. スラッシュ (/) を最後につけることをお忘れなく.

配布ファイルがシステム上に存在しないときに, makeマクロは ${FETCH}でこの変数に指定されたサイトから取っ てきます.

複数の, できれば異なる大陸のサイトをこのリストに入れておく ことが推奨されています. これによって, 広域ネットワークにトラ ブルがあった場合でも成功する可能性が高くなります. 私たちはさら に, 自動的に最も近いマスタサイトを検出して, そこから取って くるメカニズムの導入を計画しています.

オリジナルのtar ファイルが, X-contrib, GNU, Perl CPAN, TeX CTAN または Linux Sunsite などの有名なアーカイブにある場合には, MASTER_SITE_XCONTRIB, MASTER_SITE_GNU, MASTER_SITE_PERL_CPAN, MASTER_SITE_TEX_CTAN および MASTER_SITE_SUNSITE を利用することで, 簡単にこれらのサイトを 指定することができます. あとは MASTER_SITE_SUBDIR にアーカイ ブ内でのパスを指定するだけです. 以下に例を示します. MASTER_SITES= ${MASTER_SITE_XCONTRIB} MASTER_SITE_SUBDIR= applications

ユーザは/etc/make.conf中で MASTER_SITE_* 変数を設定 することによって, デフォルトの FTP サイトではなく, これらの 有名なアーカイブのミラーの中で好みのものを使用することが可能 です. PATCHFILES

もし, オリジナルの配布ファイル以外にもFTPかHTTPで手に入る パッチが必要な場合には, ${PATCHFILES}にファ イル名を, ${PATCH_SITES}にサイトとディレクト リの名前を${MASTER_SITES}と同様に設定してく ださい.

そのパッチ内のファイル名ががソースツリーの一番上のディレク トリ (${WKRSRC}) からの相対パスになっていな い場合には, ${PATCH_DIST_STRIP}を指定してく ださい. 例えば, パッチ内のファイル名にすべて余計な `foozolix-1.0/' がついている場合には, `PATCH_DIST_STRIP=-p1'としてください.

これらのパッチは圧縮されていても大丈夫です. ファイル名が `.gz' か `.Z' で終わる場合には自動的に復元 されるようになっています.

もしパッチが, 文書などその他のファイルと一緒にgzipされた tarファイルで配布されている場合には，単純に ${PATCHFILES} を使うことはできません. このような場合には, このパッチの tar ファイルの名前と場所を ${DISTFILES} と ${MASTER_SITES} に加えます. それから, pre-patch ターゲットで, パッチコマンドを走らせるか, パッチファイルを ${PATCHDIR} ディレクトリに patch-<xx>という名前でコピーするかして, パッチを適用するようにします．(普通の gzip か compress された tar ファイルであれば，通常のソースファイルと一緒にその時までに 展開されていますので，明示的に展開する必要はありません．) もし，後者の方法を使用する場合には，すでにそのディレクトリにある なにかを上書きしないように, 注意する必要があります. さらに, pre-clean ターゲットにコピーしたパッチファイル を削除するコマンドを追加するのを忘れないでください. MAINTAINER

あなたのメールアドレスをここに入れてください. お願いします. :)

保守担当者(maintainer)の責任についての詳細は， の節をご覧ください． 依存関係

このプログラムが他のportに依存する場合には, 必要なものが 自動的に作られるようにすることができます. そのために, 以下の 5つの変数が用意されています. LIB_DEPENDS

Portが必要とする非標準の共有ライブラリをこの変数で指定 します. これは `lib:dir' という組のリストで, うち lib が共有ライブラリの名前, そしてdir がそのライブラリが見つからない場合にインストールするport のあるディレクトリです. 例えば, LIB_DEPENDS= jpeg\\.6\\.:${PORTSDIR}/graphics/jpeg と指定してあれば, まずメジャーバージョンが6のjpegライブ ラリがあるかどうか確認し, ない場合にはportsツリーの中の graphics/jpeg というサブディレクトリに移動し, そこ からインストールしようとします. 前半のlib 部分はそのまま `ldconfig -r | grep' へ引数として渡されることに注意してください. 特 に, ピリオド (.) の前には上記の例のようにバックスラッシュ を連続してつける必要があります. この依存関係はextract ステージのはじめでチェック されます. また, packageを作るときに必要となるportのpackage名 が記録され, pkg_addを使用すると自動的にそちら のpackageもインストールされるようになります. RUN_DEPENDS

Portを使用する際に必要となるファイルまたはプログラムがある ときにはこの変数で指定します. これは`path:dir' とい う組のリストで, path がファイルまたはプログラムの 名前, そしてdir がそれが見つからない場合に作成する ためのディレクトリ名です. Path の最初の文字がスラッ シュ (/) の場合にはファイルとみなし, その存在を `test -e' でチェックします; そうでない場合にはプ ログラムであると仮定し, `which -s' を使ってそのプ ログラムがユーザのサーチパス上にあるかどうか確認します.

例えばMakefileに以下のように書いてあるとします. RUN_DEPENDS= ${PREFIX}/etc/innd:${PORTSDIR}/news/inn \ wish:${PORTSDIR}/x11/tk まず, `/usr/local/etc/innd' というファイルが存在 するか確認し, ない場合にはportsツリーの中の news/inn というサブディレクトリから作られます. ま た, `wish' というプログラムがユーザのサーチパス中 にあるかどうか探し, ない場合には同じくportsツリーの x11/tk というサブディレクトリから作られます. (この例で, `innd' は実際にはプログラムです; この ように, プログラムであっても標準のサーチパス以外のところに あるようなものの場合には, 絶対パスで指定してください.) この依存関係はinstall ステージのはじめでチェック されます. また, packageを作る際に必要となるportのpackage名 が記録され, pkg_addを使用すると自動的にそちら のpackageもインストールされるようになります. BUILD_DEPENDS

Portのコンパイルに必要なファイルまたはプログラムがある ときは, この変数で指定してください. RUN_DEPENDSと同 様に, これは `path:dir' という組のリストです. 例 えば, BUILD_DEPENDS= unzip:${PORTSDIR}/archivers/unzip は `unzip' という名前のプログラムを探し, 見つから ない場合にはarchivers/unzip サブディレクトリで作 れという意味になります. ここでは「コンパイル」と一口にいいましたが, この変数は実際 にはファイルの展開から実際のコンパイル・リンクまで全部をま とめて面倒を見てくれます. この依存関係はextract ステージからチェックされます. FETCH_DEPENDS

この変数は, portを取ってくるのに必要なファイルまたはプロ グラムを指定するのに使います. 上の二つと同様に, これは `path:dir' という組のリストです. 例えば, FETCH_DEPENDS= ncftp2:${PORTSDIR}/net/ncftp2 としておけば, `ncftp2' という名前のプログラムを探 し, 見つからない場合にはnet/ncftp2 サブディレク トリにいってインストールします. この依存関係はfetchステージからチェックされます. DEPENDS

上の四つのいずれにもあてはまらないような依存関係がある場 合, または他のportのソースが展開されている必要がある場合 (インストールされているだけでは不十分な場合) にはこの変数 を使います. これはディレクトリ名のリストです (上の四つと違っ て特に「確認」するものがありませんので). コンパイル時の特別な指定

GNUのmakeを使う場合には, `USE_GMAKE=yes' と指定してください. PortにGNUのconfigureが含まれ ている場合には, `GNU_CONFIGURE=yes' を使います. GNU configureにデフォルトの `--prefix=${PREFIX}' 以外の引数を渡したい場 合には追加部分を${CONFIGURE_ARGS}で指定して ください.

X Window Systemのアプリケーションなど, imakeを 使ってImakefileからMakefileを作成するportの場合には `USE_IMAKE=yes' を指定してください. コンフィグレー ションステージで自動的にxmkmf -a が実行されます. も し `-a' フラグが問題をもたらすなら, さらに `XMKMF=xmkmf'としてください.

PortのMakefileが `all' 以外のものをメインのター ゲットとしている場合には, ${ALL_TARGET} でそ れを指定してください. `install' と ${INSTALL_TARGET} も同様です. NO_INSTALL_MANPAGES

あなたのportがimakeは使うものの `install.man' ターゲットを持っていない場合, `NO_INSTALL_MANPAGES=yes' を指定してください. つい でに, 作者を探し出して八つ裂きにするといいでしょ う. (-_-#) Motifを必要とするport

最近はコンパイルにMotifを必要とするアプリケーションが増えて きました. (Motif自体は有料のものがいくつかの会社から手に入りま すし, 無料の互換ライブラリを作ろうとしているグループが少なくと も一つあります.) Motifはかなり広く使われていますし, 製品のライ センスではライブラリを静的にリンクした実行形式は再配布が認めら れている場合が多いので, Motifを必要とするソフトウェアを簡単に 動的/静的にリンクできるようなしくみが用意されています. REQUIRES_MOTIF

MotifがないとコンパイルできないportのMakefileではこの変 数を指定してください. これによって, Motifを持っていない人が このportをコンパイルしようとするのを未然に防ぎます. ${MOTIFLIB}

この変数はbsd.port.mkによってMotifライブラリの指 定に置き換えられます. ソース内のMakefileやImakefileで Motifライブラリを指定しているところをこの変数に置き換えるよ うにパッチをあててください.

代表的な例としては以下の二つがあげられます: MakefileかImakefileの中でMotifライブラリが `-lXm' として使われている場合には, かわりに `${MOTIFLIB}' と書いてください. Imakefileの中で `XmClientLibs' が使われている 場合には, それを `${MOTIFLIB} ${XTOOLLIB} ${XLIB}' と書きかえてください.

${MOTIFLIB} は通常 `-L/usr/X11R6/lib -lXm' か `/usr/X11R6/lib/libXm.a' に置き換えら れます. したがって前に `-L' や `-l' をつけ る必要はありません. ライセンス上の問題

ソフトウェアによっては制限の厳しいライセンスがついてきたり, 法律的に問題があるものがあります (PKPの公開鍵暗号化, ITAR (暗 号化ソフトウェアの輸出) などが例としてあげられます). それらを どう扱えばいいかはライセンスの文面によってさまざまな場合があり ます.

ソフトウェア移植者として, あなたにはライセンスをよく読み, FreeBSDプロジェクトがFTPまたはCD-ROMで配布してはいけないソフ トウェアを配布してしまうことのないよう, 注意する義務があります. なにか疑問がある場合には, &a.ports;に聞いてみてください.

よく見られるケースに対処するために, 二つの変数が用意されてい ます: ソフトウェアに「有償再配布を禁ずる」という趣旨のライセン スがついてきた場合にはNO_CDROMという変数をセットして ください. 私たちはこれがついているportはCD-ROMリリースに入 れないようにしますが, オリジナルのソースファイルとpackage はFTPでは取れるようにしておきます. もしも, 生成される package が個々のサイトで独自に構築さ れる必要があったり, ライセンスによって生成されるバイナリが 配布できない場合には, NO_PACKAGE 変数を設定してくだ さい. そのような package が FTP サイトに置かれたり, リリース 時の CD-ROM へ入らないようにします. ただし, いずれの場合も distfile は(FTP や CD-ROM に)含まれるようになります. Portが, 使用者によっては法律上の問題が生じる時 (暗号化ソフ トウェアなど), または「商用利用を禁ずる」とライセンスに書い てある場合にはRESTRICTEDという変数にその理由を入れ てください. この場合には, ソースファイルやpackageは私たちの FTPサイトにも置かれません.

注: GNU一般公有使用許諾書 (GPL) はバージョン1, 2とも port作成上は何ら問題にはなりません.

注: もしあなたが，ソースツリー管理者 (committer) であれば， ソースツリーにこのようなportを入れる際に, ports/LEGALファイルを書き換えるのを忘れないようにし てください. アップグレード

Portのバージョンが原作者からのものに比べて古いことに気がつ いたら, まずはあなたの持っているportが私たちの最新のもの (ミラー サイトのports-currentというディレクトリにあります) であることを確認してください.

次に, portのMakefileにMAINTAINER (保守担当者) の アドレスが書いてある場合には, その人にメールを出してみましょう. 保守担当者の人がすでにアップグレードの準備をしているかもしれま せんし, (新しいバージョンの安定度に問題があるなど) あえてアッ プグレードをしない理由があるのかもしれません.

保守担当者にアップグレードをしてくれと頼まれた場合, あるいは そもそもportのMakefileに保守担当者が書いてない場合などは, あ なたがアップグレードをしてくださると助かります. その場合にはアッ プグレードをしたのち, 変更前と変更後のディレクトリの再帰的diff をとって送ってください. (例えば, 変更前のディレクトリが `superedit.bak' という名前でとってあり, 変更後のもの が `superedit' に入っているなら, `diff -ru superedit.bak superedit' の結果を送ってください. ) もし変 更点が多すぎて, パッチが新しいport全体より大きくなる場合には, 前に述べた手順にしたがって新しいport全体をしてください. いず れの場合にも, send-pr(1) を使ってメールを送るのを忘れ ないようにしてください. やっていいことといけないこと

この節では, ソフトウェアをportする上でよくある落し穴などにつ いて説明します. WRKDIR

大事なファイルをworkサブディレクトリに置き忘れな いようにしてください. うっかり `make clean' とやっ たらこのディレクトリはその下のファイルとともにあとかたも なく消え去ってしまいます! スクリプトやパッチ以外に必要 なファイルがある場合には, filesというサブディレクト リに入れ, post-extractターゲットでworkサ ブディレクトリにコピーするようにしてください. Package情報

Package情報, すなわちpkgディレクトリ内の三つ のファイルは必ず用意してください. これらはpackageを作る以 外にもいろいろ使われていますので, ${NO_PACKAGE}が指定してあってpackageを作 るのが禁止してあるportの場合でも必ず必要です. マニュアルの圧縮, バイナリのstrip

マニュアルは圧縮し, バイナリはstripしてください. オリジナル のソースがバイナリを stripしてくれる場合は良いですが, そうでない場合には post-installターゲットを指定して strip するようにするとよいでしょう. 例えば, こんな風になりま す: post-install: strip ${PREFIX}/bin/xdl

インストールされた実行形式がすでにstripされているかどうか はfileコマンドで確認できます. これが`not stripped' と言わなければ, stripされているということです.

MAN[1-9LN] 変数を使用すると, マニュアルの圧縮を自動的に行う ことができます. この方法を使うと, ユーザが /etc/make.conf中でNOMANCOMPRESSを設定し, マニュアルの圧縮を無効にしているかどうかを確認できます. これらの変数の指定は, MAINTAINER の指定の後 のセクションの一番最後で行ってください. こんな風に指定します: MAN1= foo.1 bar.1 MAN5= foo.conf.5 MAN8= baz.8

なお, 普通 Imake を使ってコンパイルされる X アプリケーショ ンの場合はこの指定は必要ありません.

PREFIX以外のディレクトリの下にマニュアルを置く ようなportではMANPREFIXを指定することが できます. さらに, 特定のセクションのマニュアルだけ, 標準では ない場所にインストールする場合(例えば多くの Perl のモ ジュールの ports の場合)には, 個々のマニュアルのパスを MANsectPREFIX (sectは, 1 から 9 または, L か N を表わします) によって指定できます. INSTALL_* マクロ

あなた自身の *-install ターゲットでファイルの正しいモードと オーナを保証するために, 必ずbsd.port.mkで提供されて いるマクロを使用してください. マクロは以下のようなものがあります. ${INSTALL_PROGRAM} は実行可能なバイナリを インストールするコマンドです． ${INSTALL_SCRIPT} は実行可能なスクリプトを インストールするコマンドです． ${INSTALL_DATA} は共有可能なデータを インストールするコマンドです． ${INSTALL_MAN} はマニュアルを インストールするコマンドです．(圧縮をしません)

これらは基本的にinstallコマンドに適当なフラグを与え たものです. どのようにこれらを使用するかは以下の例を見てください. INSTALL package スクリプト

バイナリパッケージが pkg_add でインストールされるときに, 実行 される必要があるコマンドがあれば, pkg/INSTALL スクリプトを使っ て実行することができます. このスクリプトは自動的に package に加えられ, pkg_add によって2度実行されます. はじめは `INSTALL ${PKGNAME} PRE-INSTALL' と実行され, 2度目 には, '`INSTALL ${PKGNAME} POST-INSTALL' と実行され ます. どちらのモードで実行されているかは, `$2' を調べることによってわかります. 環境変数 `PKG_PREFIX' には package がインストールさ れる directory が設定されます. 詳細は man pkg_add(1) を見てください. 注意すべきことは, port を `make install' で インストールするときには, このスクリプトは自動的に実行されな いということです. もし, 実行される必要があるならば, port の Makefile で明示的に呼ぶ必要があります. REQ package スクリプト

パッケージが(インストールされるシステムの状態によって) インストールされるべきか, されないべきか区別する必要があると きには, 「要件(requirements)」スクリプト pkg/REQ を作ること ができます. これは, インストール及びデインストール (package の削除)の時に自動的に実行され, それらが処理されるべ きかを決定します. 詳細は, man pkg_create(1) と man pkg_add(1) を見てください. 付加的ドキュメント

普通のマニュアルやinfoファイルのほかにユーザにとって有用だ と思えるようなドキュメントがある場合には, ${PREFIX}/share/docの下にインストールしてく ださい. これは前記と同様, post-installターゲットの 中からするのがいいでしょう.

まず, あなたのportのために新しいディレクトリを作りま す. どのportのドキュメントか簡単にわかるような名前にする必 要がありますので, 普通は${PKGNAME}からバージョ ン番号を除いた部分を使うといいでしょう. もちろん, ユーザが異 なるバージョンのものを同時に使うことが予想されるportの場合 には, ${PKGNAME}をそのまま使ってかまいません.

ユーザが/etc/make.confでこの部分を禁止するために NOPORTDOCSという変数をセットしている場合には， これらのドキュメントがインストールされないようにしてください. こんな具合です. post-install: .if !defined(NOPORTDOCS) ${MKDIR} -p ${PREFIX}/share/doc/xv ${INSTALL_DATA} ${WRKSRC}/docs/xvdocs.ps ${PREFIX}/share/doc/xv .endif

これらのファイルをpkg/PLISTに入れるのを忘れないよ うにしてください. (packageが/etc/make.conf内の 変数を読む方法は今のところ存在しませんので, NOPORTDOCSについては気にしないでください.)

(Packageの)インストールを行っているユーザに対してメッセージ を表示したい場合には, そのメッセージを pkg/MESSAGE に置くこともできます. この機能は, pkg_add したあとの 追加のインストール手順や, ライセンス情報を表示するのに便利で す. (注意: MESSAGE ファイルは pkg/PLIST に加える必要はありま せん. DIST_SUBDIR

/usr/ports/distfilesディレクトリ内をあまり散らかさ ないようにしてください. たくさんのファイルを取ってくるport や, 数は少なくてもほかのportのファイルと混同されるおそれが あるファイル (`Makefile' など) がある場合には, ${DIST_SUBDIR}にportの名前 (${PKGNAME}からバージョン番号を取った部分を 使うといいでしょう) を入れてください. すると, ${DISTDIR}がデフォルトの /usr/ports/distfilesから /usr/ports/distfiles/${DIST_SUBDIR}に変更さ れ, 取ってきたファイルはすべてそのサブディレクトリの中に置か れるようになります.

また, ファイルを取ってくるときにバックアップサイトとして使わ れるftp.freebsd.orgのディレクトリ名にもこの変数の 値が使われます. (${DISTDIR}を明示的に指定し た場合には, ローカルのファイルを置くところは変わりますが, こ のサイトのディレクトリ名は変わりませんので, 必ず ${DIST_SUBDIR}を使うようにしてください.)

この変数はMakefile中で明示的に指定された ${MASTER_SITES}には影響しないことに注意して ください. フィードバック

Portを作るためにソフトウェアに変更を加えたら, なるべく原 作者にその旨を伝えてパッチ等を送ってください. これらが次のリ リースに取り入れられれば, アップグレードが楽になります. RCS文字列

RCSが特別な意味を与えている文字列をパッチ内に入れないように してください. ファイルを私たちのソースツリーに入れる時にこれら の文字列はCVSによって書き換えられてしまい, あとでまたパッチ を使おうとした時にうまくいかないことがあります. RCS文字列は ドル記号 (`$') で囲まれており, `$Id' や `$RCS' などで始まり ます. パッチ作成上の注意

diffの再帰 (`-r') フラグを使って再帰的なパッ チを作るのは大変結構なのですが, でき上がったパッチは必ず目で チェックして余計なゴミが入っていないことを確認してくださ い. よくあるのはバックアップファイル同士の変更点, あるいは imakeやGNU configureを使うソフトウェアのMakefileの変更点が 入っている場合などです. また, ファイルをまるごと消す場合には パッチを使わずにpost-extractターゲットで消す方が簡 単です. PREFIX

なるべくportは${PREFIX}に対する相対パス にインストールすることができるように心がけてください. この変数の値は${USE_IMAKE}か ${USE_X11}が指定してある時には ${X11BASE} (デフォルト/usr/X11R6), そうでない場合には${LOCALBASE} (デフォルト/usr/local) にセットされます.

サイトによってフリーソフトウェアがインストールされる場所が 違いますので, ソース内で `/usr/local' や `/usr/X11R6' を明示的に書かないようにしてくださ い. Xのプログラムでimakeを使うものについては, これは問題に はなりません. それ以外の場合には, ソース中のMakefileやスク リプトで `/usr/local' (imakeを使わないXのプログラ ムは `/usr/X11R6') と書いてあるところを `${PREFIX}' に書き換えてください. この値は portのコンパイル, およびインストール時に自動的に環境変数として 下位makeに渡されます.

変数${PREFIX}の値はportのMakefileやユー ザの環境で変更することもできます. しかし, 個々のportが Makefileでこの変数の値を明示的に設定することはなるべくしない でください. (X のプログラムでimakeを使用しないport の場合は, USE_X11=yesとしてください; これは PREFIX=/usr/X11R6とするのとはかなり違います.)

また, 他のportからインストールされるプログラムやファイル を指定するときには, 上で述べた変数を使用してください. 例えば, lessのフルパスをPAGERというマクロに入れた い場合は, コンパイラに -DPAGER=\"/usr/local/bin/less\"と渡すかわりに -DPAGER=\"${PREFIX}/bin/less\" (Xを使う portの時は -DPAGER=\"${LOCALBASE}/bin/less\") を渡し てください. こうしておけば, `/usr/local' がまるごとどこか他 の場所に移してあるサイトでも, あなたのportがそのまま使える 可能性が高くなります. ディレクトリ構成

インストール時には${PREFIX}の正しいサブディ レクトリにファイルを置くように心がけてください. ソフトウェア によっては新しいディレクトリを一つ作ってファイルを全部それに 入れてしまうものがありますが, それはよくありません. また, バ イナリ, ヘッダファイルとマニュアル以外のすべてを `lib'というディレクトリに入れてしまうportもあります が, これもBSD的なファイルシステム構成からいうと正しくありま せん. これは以下のように分散すべきです. `etc' にセッ トアップ/コンフィグレーションファイル, `libexec' に 内部で使用されるプログラム (コマンドラインから呼ばれることの ないコマンド), `sbin' に管理者用のコマンド, `info' に GNU Info 用のドキュメント, そして `share' にアーキテクチャに依存しないファイルが入り ます. 詳細については man hier(7) を見てくださ い. /usrの構成方針はほとんどそのまま /usr/localにもあてはまります. ldconfig

共有ライブラリをインストールするときには, 共有ライブラリのキャッ シュを更新するためにportのMakefileのpost-install target から`/sbin/ldconfig -m' を走らせてください. このコマンドの引数は共有ライブラリのインストールしてあるディ レクトリ (通常 ${PREFIX}/lib) です.

また, pkg/PLISTに@exec行を入れ, package をインストールした場合にも共有ライブラリがすぐ使えるように してください. この行は共有ライブラリを指定する行のすぐ後に書 くのがいいでしょう: lib/libtcl.so.7.3 @exec /sbin/ldconfig -m %D/lib

絶対に引数なしでただ `ldconfig'とだけ書い てある行をMakefileやpkg/PLISTファイルに入れないでください. このコマンドを実行すると, 共有ライブラリのキャッシュが /usr/libの内容のみとなり, ユーザのマシンにさまざま な問題をもたらします (「ぎゃぁ! このportをインストールした らxinitが使えなくなっちゃった!」). この掟を破った者は, 永久 に地獄の底で苦しみ続けるように, 閻魔様に頼んでおきます. 困ったら....

私たちに質問を送る前に, 既存のportの例とbsd.port.mkを ちゃんと読んでください! ;)

それでもわからないことがあったら, 一人で悩まないでどんどん 質問してください! :) Makefileのお手本

これはportのMakefileを作る際のお手本です. かぎかっこ ([])内のコメントは忘れずに取ってください.

変数の順番, 段落の間の空行など, Makefileを作るときはなるべくこ の形式にしたがってください. 既存のportのMakefileがすべてこの形 式にしたがっているわけではありませんが, 今後はなるべく統一していき たいと考えています. この形式は重要な情報が簡単に見つけられるよ うに設計されています. [ヘッダ -- どのようなportのMakefileかすぐにわかるようになっています] # New ports collection makefile for: xdvi # Version required: pl18 ["1.5alpha" みたいなのでも結構です] # Date created: 26 May 1995 [これはこのソフトウェアを最初にFreeBSDにportした人の名前, つまり, このMakefileを書いた人です] # Whom: Satoshi Asami # # $Id$ [ ^^^^ この部分は, CVS ツリーに入れる時に自動的に RCS の ID 文字列に 置き換えられます.] # [Port自体, およびオリジナルのソースを取ってくるところを記述する部分. 最初は必ずDISTNAME, そして必要ならPKGNAME, CATEGORIES, 続いて MASTER_SITESがおかれ, さらに MASTER_SITE_SUBDIR がおかれることもあり ます. そのあと, EXTRACT_SUFX か DISTFILES を指定することも可能です] DISTNAME= xdvi PKGNAME= xdvi-pl18 CATEGORIES= print [最後のスラッシュを忘れないように ("/")!] MASTER_SITES= ${MASTER_SITE_XCONTRIB} MASTER_SITE_SUBDIR= applications [ソースファイルが標準の ".tar.gz" 形式でない時にこれを使いましょう] EXTRACT_SUFX= .tar.Z [配布パッチのセクション -- ない場合もあります] PATCH_SITES= ftp://ftp.sra.co.jp/pub/X11/japanese/ PATCHFILES= xdvi-18.patch1.gz xdvi-18.patch2.gz [保守責任者 -- これは *必ず* 必要です. 担当者 (あなた) 自身, あるいは 担当者に素早く連絡をとれる人のアドレスを書いてください. どうしてもこ こに自分のアドレスを書くのがいやな人は "ports@FreeBSD.ORG" と書いて もいいです] MAINTAINER= asami@FreeBSD.ORG [依存するport -- ない場合もあります] RUN_DEPENDS= gs:${PORTSDIR}/print/ghostscript LIB_DEPENDS= Xpm\\.4\\.:${PORTSDIR}/graphics/xpm [ここには標準のbsd.port.mkの変数で, 上のどれにもあてはまらないものを 書きます] [コンフィグレーション, コンパイル, インストールなどの時に質問をする なら...] IS_INTERACTIVE=yes [${DISTNAME}以外のディレクトリにソースが展開されるなら...] WRKSRC= ${WRKDIR}/xdvi-new [配布されているパッチが ${WRKSRC} に対する相対パスで作られてい ない場合にこの変数の指定が必要かも...] PATCH_DIST_STRIP= -p1 [GNU autoconfによって生成された "configure" スクリプトを走らせたいなら...] GNU_CONFIGURE= yes [/usr/bin/makeでなく, GNU makeを使わないといけないなら...] USE_GMAKE= yes [これがXのアプリケーションで "xmkmf -a" を走らせたいなら...] USE_IMAKE= yes [などなど] [下の方のルールで使う非標準の変数] MY_FAVORITE_RESPONSE= "yeah, right" [そして, 特別なターゲット, 使用順に] pre-fetch: i go fetch something, yeah post-patch: i need to do something after patch, great pre-install: and then some more stuff before installing, wow [最後には必ず] .include Packageの名前

Packageの名前は以下のルールにしたがってつけてください. こ れはpackageのディレクトリを見やすくするためで, 無秩序な名前 がたくさん並んでいるとユーザが使いづらくなるのではという心配か らです. (FTPサイトなどにはたくさんpackageがありますからね.)

Packageの名前は以下のようにしてください. [<言語>-]<名前>[[-]<オプション>]-<バージョン.番号>; ${DISTNAME} が上記の形式になっていない場合に は, ${PKGNAME} をそのようにしてください. FreeBSDはユーザの慣れ親しんだ言語のサポートに力を入れて います. 特定の言語のためのportのpackage名には `<言語>' に言語名の略称を入れてください. 例えば, 日本 語なら `jp', ロシア語なら `ru' といった具合です. `<名前>' の部分は原則的にはすべて英小文字 を使います. 例外はたくさんのプログラムが入っている巨大なport の場合で, XFree86 (ほんとにあるんですよ) やImageMagickな どがこれにあたります. そうでない場合には, 名前の大文字を小文 字に (少なくとも最初の一字だけは) 変えてください. また, その ソフトウェアの名前として通常使われるものに番号, ハイフン, あ るいは下線が入っている場合には, それらを使うことも構いません (`kinput2' など). コンパイル時に環境変数やmakeの引数などでいくつ か別のオプションをつけてコンパイルできる場合, `<compiled.specifics>' にそのオプションを入れてくださ い (ハイフンはあってもなくてもかまいません). 用紙のサイズ, あるいはフォントの解像度などがこれにあたります. バージョン番号は数字とアルファベットからなり, ピリオド (.) で区切ります. アルファベットは二文字以上続けてはいけませ ん. ただ一つの例外は「パッチレベル」を意味する `pl' で, それ 以外にバージョン番号がまったくついていない場合にのみ使うことがで きます.

では, ${DISTNAME}を正しい ${PKGNAME}に直す例を見てみましょう: DISTNAME PKGNAME 理由 mule-2.2.2 mule-2.2.2 まったく問題なし XFree86-3.1.2 XFree86-3.1.2 同上 EmiClock-1.0.2 emiclock-1.0.2 プログラム一つだけの時は小文字のみ gmod1.4 gmod-1.4 `<名前>' のあとにハイフンが必要 xmris.4.02 xmris-4.02 同上 rdist-1.3alpha rdist-1.3a `alpha'のような文字列は使えない es-0.9-beta1 es-0.9b1 同上 v3.3beta021.src tiff-3.3 なんなんでしょう ;) tvtwm tvtwm-pl11 バージョン番号は必ず必要 piewm piewm-1.0 同上 xvgr-2.10pl1 xvgr-2.10.1 `pl' が使えるのは他にバージョン番号がない場合のみ gawk-2.15.6 jp-gawk-2.15.6 日本語バージョン psutils-1.13 psutils-letter-1.13 コンパイル時に用紙のサイズを指定 pkfonts pkfonts300-1.0 300dpiフォント用のpackage

オリジナルのソースにまったくバージョン情報が見当たらず, また原作 者が新しいバージョンをリリースする可能性が低いときには, バージョ ン番号として `1.0' を使えばいいでしょう (上記のpiewmの例がこ れにあたります). そうでない場合には, 原作者に聞くか, 日付 (`年. 月.日') を使うなどしてください. やっとおしまい!

いやはや, 長い文章ですみません. ここまで読んでくださった方に は感謝, 感謝でございます. (_ _)

さあ, portの作り方がわかったところで, 世界中のソフトウェア をport化しましょう. FreeBSDプロジェクトに貢献するには, それ がもっとも簡単な方法です! :) diff --git a/ja_JP.EUC/handbook/ports.sgml b/ja_JP.EUC/handbook/ports.sgml index 9db8149d69..3d8ce8fce5 100644 --- a/ja_JP.EUC/handbook/ports.sgml +++ b/ja_JP.EUC/handbook/ports.sgml @@ -1,859 +1,859 @@ - + ports コレクション

原作: &a.jraynard;.

訳: &a.masaki;, &a.saeki;. 11 November 1996. FreeBSD の ports コレクションを利用すると, 最小限の労力で 非常に幅広くのアプリケーションのコンパイルとインストールがおこなえます.

やってみたことのある方はよくご存知でしょうが, オープンな規格とは 全くの誇大広告であって, あるプログラムを異なるバージョンの Unix 上で 動作させることは退屈で手間のかかる仕事です. 求めているプログラムが自分のシステムでうまくコンパイルでき, 正しいところにインストールできて, 完璧に動作するとしたらとてもラッキーです. しかし, あいにくこれは滅多にないことなのです. ほとんどのプログラムについて, あなたは髪を掻きむしることになるでしょうし, かなりのプログラムでは, 白髪混じりの頭になってしまったり, あるいは慢性の 脱毛症にすら なってしまうかもしれません...

いくつかのソフトウェアディストリビューションでは, 設定用のスクリプトを 配布することでこの問題を解決しようとしています. これらのスクリプトの中には非常に精巧なものもありますが, 残念ながら, 中にはこれまで聞いたこともないようなシステムの名前をしゃあしゃあと 言い放ったうえに, まるでシステムレベルの Unix プログラミングに関する 最終試験のような, たくさんの質問をしてくる場合があります. (例えば, 「このシステムの gethitlist 関数は fromboz への const ポインタを 返しますか? それとも const fromboz へのポインタを返しますか?」, 「このシステムには Foonix スタイルの, 容認できない例外処理をおこなう ルーチンがありますか? もしもないとしたら, それはなぜですか?」)

幸いなことに, ports コレクションがあれば, これらのきつい作業はすべて 完了しています. 'make install' とタイプするだけで, 動作するプログラムを 入手することができるのです. なぜ ports コレクションを作ったのか?

FreeBSD の基本システムは, 非常に多くのツールやユーティリティから 構成されています. しかし, よく使われるプログラムのうち多くのものが, この基本システムには含まれていません. その理由は:- 「私は x と y と z のプログラムがシステムにないと生きていけない」と いう類のプログラム (例えば Lisp ベースのエディタや DOS フロッピーを扱うための mtools など) は, 人によって全然違うから. (Emacs に我慢ならないという人や, DOS フロッピーをまったく使わないという人も大勢いるのです. そういう人は Emacs や mtools が基本システムに含まれていなくても何の問題もないでしょう.) 基本システムに組み込むには特殊すぎるから. (CAD やデータベースなど) 「時間があったら, ちょっと見てみようかな」というような類の, それがシステムに含まれていないことが致命的とは言えないプログラムだから. (おそらく, 何らかの言語などでしょう.) お楽しみのためのプログラムは, FreeBSD のような真面目な オペレーティングシステムといっしょに配布するべきではないから. ;-) たくさんのプログラムを基本システムに組み込んだとしても, もっともっと 組み込みたいという要求が出てくるので, どこかで制限を引かなくてはならないため. (そうしなければ FreeBSD の配布物は, とてつもなく膨大になってしまうでしょう.)

すべての人が自分のお気に入りのプログラムを手作業で移植しなければ ならないとしたら, (途方もない膨大な作業の繰り返しをさておいたとしても) それは明らかに不合理な話です. そこで, FreeBSD プロジェクトでは, 標準のツールを使って移植のプロセスを 自動化する巧妙な方法を考え出しました.

なお, これは単純ながら非常に柔軟なツールを組み合わせることで, 非常に強力な働きをさせるという「Unix 流」の作業の優れた実例です. ports コレクションはどのように動くのでしょうか?

インターネットでは通常, の形で プログラムが配布されています. これは, Makefile とソースコードで構成され, 普通は何らかの説明書 (あいにく, いつもわかりやすく書かれているとは 限りませんが) が付属しています. ことによるとコンフィグレーションスクリプトも含まれているかもしれません.

標準的な手順では, FTP で tarball を入手して, 適当なディレクトリで展開します. 次に説明書を読んで, 必要な変更をおこないます. そして, 設定スクリプトを実行し, 標準の make コマンドを使ってソースのコンパイルとインストールをおこないます.

FreeBSD の ports も tarball の仕組みを利用していますが, これはユーザが 苦労して作業することを期待したものではなく, どのようにすれば FreeBSD 上で そのプログラムが動くようになるかという「ノウハウ」を を使用して収めているものです. スケルトンは, カスタマイズ済みの も 提供していますので, ほとんどすべての ports は同じ手順でインストールすることが できます.

もしあなたが ( または にある) ports スケルトンを見ていて, そこに潜んでいる あらゆる種類の先端的なロケット工学的なものを見つけられると期待していると, つまらなそうなファイルやディレクトリがそこにあるだけなのを見て, がっかりするかもしれません. (ports を手に入れる方法については, すぐに の節でお話します.)

「一体どうしたらいいんだ? ここにはソースコードが全然ないじゃないか?」 というあなたの叫びが聞こえるようです.

心配いりません. おとなしく読んでいけば, すべてが (たぶん) 明らかに なるでしょう. 試しに ports をインストールして, 何が起きるのかを見てみましょう. かなり典型的な例だと思いますので, ここでは `bash' (Bourne-Again Shell として 知られています) を選びます. Note 自宅で試してみる場合には, root になる必要があるでしょう. # cd /usr/ports/shells/bash # make install Checksums OK. ===> Extracting for bash-1.14.5 ===> Patching for bash-1.14.5 ===> Applying FreeBSD patches for bash-1.14.5 ===> Configuring for bash-1.14.5 ===> Building for bash-1.14.5 [とてもとても大量のメッセージをコンパイラが出力します...] ===> Installing for bash-1.14.5 make -f bash-Makefile bindir=/usr/local/bin prefix=/usr/local install (cd ./documentation/; make ) rm -f builtins.txt nroff -man builtins.1 > builtins.txt install -c -o bin -g bin -m 555 bash /usr/local/bin/bash install -c -o bin -g bin -m 555 bashbug /usr/local/bin/bashbug ( cd ./documentation/ ; make mandir=/usr/local/man/man1 man3dir=/usr/local/man/man3 infodir=/usr/local/info install ) [ -d /usr/local/man/man1 ] || mkdir /usr/local/man/man1 [ -d /usr/local/info ] || mkdir /usr/local/info ../support/install.sh -c -m 644 bash.1 /usr/local/man/man1 ../support/install.sh -c -m 644 builtins.1 /usr/local/man/man1/bash_builtins.1 ../support/install.sh -c -m 644 features.info /usr/local/info/bash.info gzip -9nf /usr/local/man/man1/bash.1 /usr/local/man/man1/bash_builtins.1 ===> Registering installation for bash-1.14.5

ここではあなたが混乱しないように, コンパイル時とインストール時の出力を 多少省略してあります. もしもあなた自身で実行されたら, 最初にこのような 出力結果を得るはずです:-

`make' プログラムは, あなたの手元にソースコードがないことを検出し, 処理を続けられるようにソースを FTP でダウンロードしようとします. (結構すごいとは思いませんか? 8-)) この例では, あらかじめ手動でソースコードを用意してあったので, 持ってくる必要はありませんでした.

では, 続けて `make' プログラムが何をしているのか見てみましょう. ソースコード のありかを 確認します. 手元にファイルが存在しなければ, FTP サイトから入手しようとします. テストを実行して, その tarball が事故か何かで途中で切れていたり, 転送中にニュートリノに よって傷められたりして改変されたりしていないかどうかを確認します. tarball を一時的な作業用ディレクトリに展開します. FreeBSD 上でコンパイルしたり, 動作させるのに必要な すべての をソースコードに当てます. 構築のために必要なコンフィグレーションスクリプトを実行します. コンフィグレーションスクリプトの質問には正確に答えてください. (いよいよ!) ソースコードをコンパイルします. 実行形式のプログラム, マニュアル, その他のサポートファイルを, システムのプログラムと混ざってしまわないように /usr/local 以下に インストールします. ports はすべて同じ場所にインストールされ, システムのあちこちにばらまかれることはありません. インストール結果はデータベースに登録されます. これにより, インストールしたプログラムがもしも気に入らなかったときも, システムから すべての痕跡をきれいに することができます.

以上のステップが make の出力と一致するかどうか確認してください. 今まで確認していなかったのなら, 今からするようにしてください! FreeBSD ports コレクションの入手

あるプログラムの FreeBSD port を入手するには二つの方法があります. ひとつは を使う方法で, もうひとつは を使う方法です. CD-ROM からコンパイルする

FreeBSD をインストールしたときに, ``Do you want to link the ports collection to your CDROM'' という質問に yes と答えていたら, 初期設定は既に終わっています.

そうでない場合は, # mkdir /usr/ports # cd /usr/ports # ln -s /cdrom/ports/distfiles distfiles ports の make メカニズムが tarball を見つけることができるようになります. (ports は /usr/ports/distfiles に tarball があることを期待していますので, そこから CD-ROM の tarball ディレクトリにシンボリックリンクを張ったのです.)

さて, データベースディレクトリから gnats プログラムをインストールしようと しているとします. 方法は次のとおりです:- # cd /usr/ports # mkdir databases # cp -R /cdrom/ports/databases/gnats databases # cd databases/gnats # make install もしもあなたがまじめなデータベースユーザであって, ports コレクションの中の すべてのデータベースを比較したいと思っているならば, 次のようにしてください. # cd /usr/ports # cp -R /cdrom/ports/databases . # cd databases # make install (cp コマンドの最後のドットはドットそのものであって, もちろんタイプミスでは ありません. Unix でドットは現在自分自身がいるカレントディレクトリを 意味しています.)

ports make メカニズムは, データベースディレクトリのすべての ports を 自動的にコンパイルし, インストールをおこなってくれます.

この方法が気に入らない場合は, まったく違うやり方もあります:-

XFree86 の配布に含まれる lndir(1) コマンドを使用して 「リンクツリー」を作ります. ディスクの空き領域を見つけてディレクトリを作成し, /usr/ports からそのディレクトリへシンボリックリンクを張ります. そして CD-ROM 上の ``ports'' ディレクトリのフルパス名を引数として lndir(1) コマンドを実行します. (例えば lndir /cdrom/ports のように:) そして, 作成したリンクツリーの中で ports を構築することで, CD-ROM から 直接 ports を構築することができます.

ライセンスの制限により, いくつかの ports でオリジナルのソースコードを CD-ROM に入れることができなかったものがあることに注意してください. この場合, の 節を参照してください. インターネット経由で ports をコンパイルする

CD-ROM を持っていなかったり, その ports の最新バージョンを確実に入手したい 場合は, その ports の を ダウンロードする必要があります. ところで, これは落し穴 (誤ってパッチを pkg サブディレクトリに ダウンロードしてしまうような失敗) が たくさんある作業に見えるかもしれませんが, 実際には非常に簡単です.

ここで鍵になるのは, FreeBSD の FTP サイトが その場で を作成できるということです. どのように動作するのか, ここでは例として databases ディレクトリにある gnats プログラムを使って説明します. (角型かっこの中の文はコメントなので, 実際に実行する場合には, これをタイプしないでください!):- # cd /usr/ports # mkdir databases # cd databases # ftp ftp.freebsd.org [ユーザ名 `ftp' でログインし, パスワードを要求されたら, あなたの電子メール アドレスを入力してください. バイナリモードを (イメージモードと呼ばれることも あります) 使うのをお忘れなく!] > cd /pub/FreeBSD/ports/databases > get gnats.tar.gz [gnats スケルトンの tarballs を取得] > quit # tar xzf gnats.tar.gz [gnats スケルトンの展開] # cd gnats # make install [gnats の構築とインストール] さて何が起きるでしょうか? FTP サイトにいつも通りに接続して, データベースの サブディレクトリに移動します. `get gnats.tar.gz' とコマンドを入力すると, FTP サイトでは gnats ディレクトリを にして, 送信する前に圧縮までしてくれるのです. ですから, 圧縮をおこなわない場合よりも多少速く手に入ることでしょう.

gnats スケルトンを展開したら, gnats ディレクトリへ移動して ports を構築します. 説明したように, make の過程で 手元にソースコードがないことを検出すると, ソースコードを取得してから 展開し, パッチ当てと構築をおこないます.

それでは, 少し冒険をしてみましょう. 一つの ports スケルトンを 取得するかわりに, たとえば ports コレクションの中のデータベースの スケルトンをすべて, サブディレクトリ全体を取得してみましょう. やり方はほとんど同じです:- # cd /usr/ports # ftp ftp.freebsd.org [ユーザ名 `ftp' でログインし, パスワードを要求されたら, あなたの電子メール アドレスを入力してください. バイナリモードを (イメージモードと呼ばれることも あります) 使うのをお忘れなく!] > cd /pub/FreeBSD/ports > get databases.tar.gz [データベースディレクトリの tarballs を取得] > quit # tar xzf databases.tar.gz [すべてのスケルトンを展開] # cd databases # make install [データベース ports 全部の構築とインストール] わずかばかりの簡単なコマンドで, この FreeBSD マシン上にデータベース プログラムを一揃い手に入れてしまいました! 一つの ports スケルトンを取ってきて それを構築する場合との違いは, すべてのディレクトリを一度に取得して, 全部を一度にコンパイルしたということだけです. かなり感動的だと思いませんか?

もし一つや二つの ports だけでなく, もっと多くの ports をインストールする つもりなら, おそらくすべての ports ディレクトリをダウンロードしておく 価値があるでしょう. これは, 圧縮されていれば 2〜3 MB 程度の大きさです. しかし, distfiles ディレクトリの下にあるファイルも一緒にダウンロードする つもりがないのなら, 調子に乗って `get ports.tar.gz' とタイプしてはいけません. distfiles ディレクトリには, ほとんどすべての ports のソースコードが 置かれているので, すべてをダウンロードするには非常に長い時間がかかるでしょう! スケルトン

スケルトン (訳注: skeleton とは骸骨のことです) とは, 締め切りを守るため, 食事をするのを忘れるほど仕事にのめり込んだハッカーたちのなれの果ての ことでしょうか? FreeBSD の屋根裏に潜む, なにか気持ちの悪いものでしょうか? いいえ, ここでスケルトンの意味するところは, ports の魔術を実現するのに 必要とされるすべてのものを提供する最小の骨組みのことです. Makefile

スケルトンのもっとも重要な要素は Makefile です. Makefile は ports を どのようにコンパイルし, インストールをおこなうかを指示する いろいろな命令を含んでいます. 以下に bash の Makefile を示します:- # New ports collection makefile for: bash # Version required: 1.14.5 # Date created: 21 August 1994 # Whom: jkh # # Makefile,v 1.13 1995/10/04 14:45:01 asami Exp # DISTNAME= bash-1.14.5 CATEGORIES= shells MASTER_SITES= ftp://slc2.ins.cwru.edu/pub/dist/ MAINTAINER= ache@FreeBSD.ORG post-install: .if !defined(NOMANCOMPRESS) gzip -9nf ${PREFIX}/man/man1/bash.1 ${PREFIX}/man/man1/bash_builtins.1 .endif .include <bsd.port.mk> "#" で始まる行は, 人間のためのコメント行です. (ほとんどの Unix のスクリプトと同じですね.)

`DISTNAME" は の名前から拡張子を取ったものです.

`CATEGORIES" はこのプログラムの種類を示します.

`MASTER_SITES" はマスタ FTP サイトの URL です. もしローカルシステムに がない場合には, ここから取得します. これは信頼できると考えられているサイトで, 通常はそのプログラムを インターネット上で公式に配布しているサイトです. (そのソフトウェアがインターネット上で「公式に」配布されているとしたら)

`MAINTAINER" は, 例えば新しいバージョンのプログラムが出た場合に, 必要であればスケルトンの更新をおこなう保守担当者の電子メールアドレスです. (注: 「保守担当者」というのは, スケルトンの管理者という意味であって, プログラムのサポートをおこなう責任は を見つけた場合には, 電子メールは &a.ports; に送ってください. 保守担当者には 次の数行はとりあえず飛ばします. .include この行は, この ports に必要なその他の命令やコマンドは `bsd.port.mk" に 入っているということです. すべての ports で同じものなので, すべての Makefile に 書いておく必要はありません. そのため単一の標準ファイルにまとめられています.

ここでは Makefile がどう働くかを詳細に調査するのが目的ではありませんので, `post-install" で始まる行は, bsd.port.mk に書かれている, プログラムを インストールした後での処理を置き換えていて, 最終的な場所に man ページを 置いた後で圧縮するように指示している, と言っておくだけで充分でしょう. files ディレクトリ

ports のチェックサム算出には MD5 アルゴリズムを使用しているので, この を含んでいる ファイルは "md5" と呼ばれます. ちょっと混乱するかもしれませんが, このファイルは "files" という 名前のディレクトリに置かれています.

このディレクトリは, ports に必要だけれども, 他のどこにも属さない 雑多なファイルも含んでいます. patches ディレクトリ

このディレクトリには, FreeBSD ですべてを正常に動作させるのに 必要な が含まれています. pkg ディレクトリ

このディレクトリには, 非常に役立つ三つのファイルが含まれています:- COMMENT - プログラムについての 1 行の説明. DESCR - より詳細な説明. PLIST - プログラムのインストール時に作成される, すべてのファイルのリスト. あれ? 動かない!?

おやおや. では, 次の四つのどれかをやってみてください: 自分で修正する. 技術的な詳細については, をご覧ください. 苦情をいう. これは電子メールで * だけ * にしてください! Walnut Creekの人たちは, FreeBSD システムの機能 (あるいは欠陥) について, いっさい責任がありません. ほとんどサードパーティの貢献による ports システムなどは特にそうです. (これが信じられないならば, Walnut Creek のカタログをチェックしてください. 「このプロダクトに関するテクニカルサポートを提供することができません」と 明記してあります.) 電子メールのアドレスは &a.ports; です. あなたがどこから ports の ソースコードや配布ファイルを入手したのか, どんなエラーが発生したのかなど, 詳細を記述してください. 注: 執筆当時, lang/Sather は Pentium マシンでは, Intel の呪い (別名, 浮動小数点除算バグ) のために動作しません. 私たちは これについては関知しません. 苦情をいうなら Intel にどうぞ. これは彼らのバグなのですから! 忘れてしまう. これはほとんどの場合最も簡単な方法です. ports のプログラムのうち必要不可欠な物はごくわずかです. FTP サイトからコンパイル済みのパッケージを入手する. マスターパッケージコレクションは FreeBSD の FTP サイトの に置いてありますが, まずあなたの近くのローカルミラーサイトを確認してください! ソースからコンパイルに挑戦するよりパッケージを使ったほうが, (ほとんど全部が) ずっと確実に動作するでしょうし, より手っ取り早い方法でもあります. プログラムをシステムにインストールするには, pkg_add(1) を使ってください. ports 化したいプログラムがあるのですが...

すばらしい!具体的なやり方については に, 詳細な手順がありますので ご覧ください. 質問と回答集

Q. 私はモデムについての議論をしているのかと思っていました??!

A.なるほど, あなたはきっとコンピュータの背面についている シリアルポートのことだと思ってしまったのでしょう. あるバージョンの Unixから別のバージョンの Unix へとプログラムを 移殖することを `porting' というのですが, ここで我たちは `porting' の結果 という意味で `port' を使っています. (コンピュータに関わる人々の悪しき習慣として, ひとつの同じ言葉を複数の まったく違う意味として使うことがあるのです.) Q. 私は, 標準以外のプログラムのインストールには packages を使うと 思っていたのですが.

A. そのとおり. 通常は packages が最も手早くて簡単な方法です. Q. それではどうして面倒な ports があるのですか?

A. いくつかの理由があります:- いくつかのソフトウェアのライセンス条件には, バイナリではなくソースコードでの配布を求めているものがあります. バイナリ配布を信用していない人もいます. 少なくともソースコード があれば, ソースコードを読んで, (理論的には) 潜在的な問題点を自分で 見つけ出すこともできるはずです. ローカルなパッチを入手した場合, それを自分で追加するために ソースコードが必要になります. プログラムがいかにコンパイルされるべきかについて, あなたはパッケージを作った人とは異なる見解を持っているかもしれません. どんな最適化オプションをつけるべきかとか, デバッグバージョンを作ってから それを strip するべきだとか, いや, そうするべきでない, などなど, 確固たる見解を持っている人もいるでしょう. ソースコードを手元に置いておきたい人たちもいます. 彼らは, 退屈したときに眺めたり, あちこち解析してみたり, ソースコードを 借用したり (もちろん, ライセンスが許せばの話ですが) するのです. あなたがソースコードを持っていなければ, それはソフトウェアとは 言えませんね! ;-)

A. パッチとは, あるバージョンから他のバージョンへどのように変更するかを 示す, (通常は) 小さなファイルです. 「23 行目を削除」, 「468 行目の後に これらの 2 行を追加」, または「197 行目をこのように変更」というような 内容を含んでいます. これは, `diff' という名前のプログラムで生成されます.

A. .tar.gz という拡張子を持つファイルです. ( .tar.Z のようなバリエーションも ありますし, DOS のファイルシステム用に .tgz と短縮される場合もあります.)

これは基本的に, 一つのファイルに固めて (.tar) 圧縮した (.gz) ディレクトリ ツリーです. これは元々 これらのファイルの中身を見たり, 展開したりすることもできます. FreeBSD の基本システムに付属する Unix 標準の tar コマンドを使ってみると 次のようになります:- tar tvzf foobar.tar.gz # foobar.tar.gz の内容を見る tar xzvf foobar.tar.gz # カレントディレクトリに内容を展開する

A. これは, チェックしたいファイル中のすべてのデータを加えて生成した 数値です. 何か文字が書き換わっていたら, チェックサムが一致しなくなります. そのため, 単純な比較だけで違いを見つけることができるのです. (実際には, 文字の位置が入れ替わるなどの, 単純な加算ではわからない問題も 見つけることができる複雑な方法で計算されています.) Q. 私は, にしたがって ports をインストールしていました. kermit をインストールしようとするまではうまくいっていました:- # make install >> cku190.tar.gz doesn't seem to exist on this system. >> Attempting to fetch from ftp://kermit.columbia.edu/kermit/archives/. なぜ cku190.tar.gz が見つからないのでしょうか? 不良品の CD-ROM を買ってしまったのでしょうか?

A. Kermit の権利を持つチームは, 私たちの CDROM に kermit の tarball を 入れることを許可しませんでした. 申し分けありませんが, 手動でファイルを 入手してください. このようなエラーメッセージが出たのは, あなたがそのときインターネットに 接続していなかったためです. あらかじめ上記のサイトのいずれかからファイルを ダウンロードしておけば, プロセスを再開することができます. (ダウンロードの際には, あなたに最も近いサイトを選ぶようにしてください. そうすれば, 時間とインターネットの帯域の節約になります) Q. kermit の tarball を入手しましたが, /usr/ports/distfiles に ファイルを置こうとすると, 書き込み権がないというエラーがでます.

A. ports のしくみは /usr/ports/distfiles から tarball を探します. しかし, これは read-only の CD-ROM へのシンボリックリンクなので, ここにファイルを置くことはできません. 次のようにすれば, 他の場所を探すよう ports に指示することができます. DISTDIR=/where/you/put/it make install Q. ports では, すべてを /usr/ports に置いたときだけ動作するのでしょうか? システムの管理者によると, 私の個人的なファイルは /u/people/guests/wurzburger に入れなければならないのですが, これでは うまくいかないように思います.

A. PORTSDIR 変数と PREFIX 変数を変更することで, 違うディレクトリを 使用することができます. 例えば, PORTSDIR=/u/people/guests/wurzburger/ports make install とすると, ports は /u/people/guests/wurzburger/ports でコンパイルされ, すべて /usr/local 以下にインストールされます. PREFIX=/u/people/guests/wurzburger/local make install この場合, コンパイルは /usr/ports でおこない, /u/people/guests/wurzburger/local にインストールします. もちろん, 以下のように両者を組み合わせることも可能です. PORTSDIR=.../ports PREFIX=.../local make install (省略せずに記述したら, このページに収めるには長すぎるのですが, 考え方は理解していただけたと思います)

もし ports をインストールするたびに, これらを毎回タイプするのが 気に入らないのであれば, (正直に言って, 誰もそう思わないでしょう) これらを環境変数にセットしてしまうという手があります. Q. 私は, FreeBSD の CD-ROM を持っていませんが, 私はすべての tarball を 私のシステムに置いておきたいのです. そうすれば, 私は ports をインストール するたびに, 毎回ダウンロードが終わるのを待たなくてすむでしょう. これを一度におこなう簡単な方法はありませんか?

A. ports コレクション全体の tarball を持ってくるには, 次のようにしてください. # cd /usr/ports # make fetch ports の下のディレクトリひとつの tarball を持ってくるには, 次のように してください. # cd /usr/ports/directory # make fetch ports をひとつだけ持ってくる方法は, きっと既にご存知だと思います. Q. マスタ FTP サイトから tarball を持ってくるより, 近くにある FreeBSD の ミラーサイトから持ってきた方が速いはずです. MASTER_SITES に書かれている サイト以外から持ってくるように ports に指示する方法はありませんか?

A. もちろんあります. 例えば ftp.FreeBSD.ORG が MASTER_SITES に書かれている サイトより近いとしたら, 以下のようにしてください. # cd /usr/ports/directory # make MASTER_SITE_OVERRIDE=ftp://ftp.FreeBSD.ORG/pub/FreeBSD/distfiles/ fetch Q. ダウンロードをする前に, どんなファイルが必要なのか知りたいのですが.

A. 'make fetch-list' とすると, ports に必要なファイルの一覧を表示できます. Q. ports のコンパイルを途中で止める方法はありますか? 私はインストールをする前にいろいろとソースコードを解析したいのですが, 毎回 control-C を打たなければならないのが少し面倒です.

A. 'make extract' を実行すると, ファイル転送とソースコードの展開まで おこなったところで停止します. Q. 自分で ports を作ろうとしています. 私の作ったパッチが 正しく処理できることを確認できるように, コンパイルを止めたいのです. パッチのための 'make extract' のようなものはありませんか?

A. あります. 'make patch' があなたのお望みのものです. ところで, あなたの努力に感謝いたします!! Q. あるコンパイルオプションはバグの原因になるという話を聞きました. 本当なのでしょうか? どうやったら正しい設定で ports をコンパイルできますか?

A. 本当です. gcc の バージョン 2.6.3 (FreeBSDの 2.1.0 と 2.1.5 に付属している バージョン) では, -O2 オプションを -fno-strength-reduce オプションなしで 使うと, バグのあるコードを出力します (ほとんどの ports は -O2 オプションを 使いません). コンバイラオプションは次のように定義 # CFLAGS='-O2 -fno-strength-reduce' make install /etc/make.conf を編集することもできますが, すべての場合でこれが反映される 訳ではありません. もっとも確実なのは 'make configure' を実行し, ソースディレクトリの Makefile を見て手で修整することですが, ソースが 多くのサブディレクトリにわかれていて, 各々に Makefile がある場合は 大変な仕事になります. Q. ports がたくさんありすぎて, 私の欲しいものがなかなか見つけられません. どんな ports が使えるのか, リストはどこかにありませんか?

A. INDEX ファイルは /usr/ports の中にあります. Q. 'foo' ports をインストールしたいのですが, それはすぐに停止して, 'bar' ports のコンパイルが始まってしまいます. 一体どうして?

A. 'foo' ports が, 'bar' ports の提供する何らかの機能を必要としているからです. 例えば 'foo' が画像を使うとすると, 'bar' は画像処理に必要な ライブラリを持っている, などです. または, 'bar' は 'foo' をコンパイルするのに必要なツールなのかもしれません.

A. 大丈夫, 次のようにしてください. pkg_delete grizzle-6.5 Q. ちょっと待ってください. 削除しようとするコマンドのバージョン番号を 知っていなくてはならないのでしょうか? あなたは, 私がバージョン番号を 覚えていることを本気で当てにしているのでしょうか?

A. そんなことはありません. バージョン番号は次のようにすればわかります. pkg_info -a | grep grizzle そうすると次のように表示されます:- Information for grizzle-6.5: grizzle-6.5 - the combined piano tutorial, LOGO interpreter and shoot 'em up arcade game. Q. ディスク容量のことなのですが, ports のディレクトリは非常に膨大な容量を 使うように見えます. 残しておいた方がよいのでしょうか? 削除してしまっても よいのでしょうか?

A. はい. インストールが首尾よく終わり, もうソースコードが必要でないと思うなら, それらを残しておく理由はないでしょう. 一番よい方法は, 次の通りです. # cd /usr/ports # make clean これは, すべての ports のサブディレクトリを調べ, 各 ports のスケルトン以外の削除をおこないます. Q. これを試してみたのですが, tarball や ports で使われたファイルが distfiles ディレクトリに残っています. これも削除してしまっても大丈夫ですか?

A. はい. それを使った作業が終わったのであれば, 削除してしまっても大丈夫です. Q. 私はとてもとてもたくさんのプログラムを楽しみたいのです. 一度にすべての ports をインストールする方法はありませんか?

A. 次のようにしてください. # cd /usr/ports # make install Q. やってみました. 時間がとてもかかるだろうと思ったので, そのまま実行を 続けさせて, 私は寝ました. 翌朝コンピュータを見てみると, 三つ半の ports しか 処理が終わっていませんでした. なにか悪かったのでしょうか?

A. これは ports の中には私たちの決められないこと (例えば, あなたが A4 の 用紙に印刷したいのか, US レターサイズの用紙に印刷したいのかなど) について 質問してくるものがあるからです. それらの質問には手動で答える必要があります. Q. 私は一日中モニタの前に座って過ごしたりしたくないのですが. 何かよいアイデアはありませんか?

A. では, あなたが寝に / 仕事に / 公園にいく前に以下を実行してください:- # cd /usr/ports # make -DBATCH install これでユーザの入力を要求しないすべての ports をインストールします. そして, 戻ってきてから, 次のように実行してください. # cd /usr/ports # make -DIS_INTERACTIVE install そして, 残りの作業を実行してください. Q. 私たちは ports コレクションにある frobble を使っています. ですが, 私たちの必要に応じて ports を変更したところがあるのです. 自分でパッケージを作って, それを私たちのサイトのまわりに 簡単に配布できるような方法がありますか?

A. もちろんあります. 変更点をパッチにする方法は知っていますよね:- # cd /usr/ports/somewhere/frobble # make extract # cd work/frobble-2.8 [あなたのパッチを当ててください] # cd ../.. # make package Q. この ports の技術は本当に賢いですね. どのようにして動いているのか 私はどうしても知りたいと思います. その秘密は何ですか?

A. 秘密は一切ありません. にある bsd.ports.mk と bsd.ports.subdir.mk ファイルを見るだけです. (注: 複雑なシェルスクリプトを嫌う読者は, このリンクを追いかけないほうが よいでしょう.) diff --git a/ja_JP.EUC/handbook/ppp.sgml b/ja_JP.EUC/handbook/ppp.sgml index 207d1f66aa..26a7741768 100644 --- a/ja_JP.EUC/handbook/ppp.sgml +++ b/ja_JP.EUC/handbook/ppp.sgml @@ -1,429 +1,429 @@ - + カーネル PPP の設定

原作: &a.gena;.

訳: &a.graphite;.6 September 1996. 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 : # 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 : defaultroute # put this if you want that PPP server will be your # default router 接続方法: kermit (またはその他のモデム操作プログラム) を使ってリモートホストに ダイヤルし, 接続してください. そして, あなたのユーザ名とパスワード (必要 であれば, その他にもリモートホストで PPP を有効にするための操作) を入力 します. kermit を抜けてください. (回線を切断せずに) 下記のように入力します: /usr/src/usr.sbin/pppd.new/pppd /dev/tty01 19200 (通信速度とデバイス名には, あなたの環境に適したものを入れてください) これでこのコンピュータは PPP で接続されました. もし, なんらかの理由で 接続に失敗したならば, /etc/ppp/options ファイルに "debug" オプションを追加して, 問題点を突き止めるために, コンソールに表示される メッセージを調べてください. 下記の /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 を使う方法です. 原作: &a.rhuff;.

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 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 # 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 : 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 CONNECT "" TIMEOUT 10 ogin:-\\r-ogin: TIMEOUT 5 sword: 正しくインストールし編集した後は, 必要な事はこれだけです

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 mode 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: diff --git a/ja_JP.EUC/handbook/printing.sgml b/ja_JP.EUC/handbook/printing.sgml index 26e2cdda6c..26d74116c5 100644 --- a/ja_JP.EUC/handbook/printing.sgml +++ b/ja_JP.EUC/handbook/printing.sgml @@ -1,4179 +1,4179 @@ - + プリンタの利用

著者 &a.kelly;30 September 1995

訳者 &a.kimura;3 September 1996 FreeBSD でプリンタを使用するためには, バークレイラインプリンタ スプーリングシステム (LPDスプーリングシステムとしても知られて います) が機能するようにプリンタをセットアップする必要がありま す. 本節では, LPDスプーリングシステム (大抵の場合, 単にLPDと呼 ばれる) について紹介します. もし, LPDや他のプリンタスプーリングシステムについて既に詳しい 知識をお持ちの方は, 「」から読み始めて も結構です. スプーラは何をするか

LPDはあるホストのプリンタに関する制御の一切をおこないます. こ こで言う制御としては, 次のことが挙げられます. ホストに接続されたプリンタ, あるいはネットワーク 上の他ホストに接続されたプリンタに対するアクセスを制御しま す. ファイルをプリントする要求に対して許可を与えます. この要求は特に 各々のプリンタの シリアルポートに接続したプリンタ用に通信パラ メータを管理します. ネットワーク経由で他のホスト上の, 別のLPDスプーラにジョ ブを送ることができます. 様々なプリンタ言語やプリンタの能力に応じてジョブの 形式を整えるため, 特別なフィルタを起動することができます. プリンタの使用に対して課金をおこなうことができます. 設定ファイルを通して, また, 特別なフィルタプログラムを供給 することにより, 多種多様なプリンタ機器に対して, 上述の機能の 全部または一部をLPDシステムにおこなわせることができます. どうしてスプーラを使うべきなのか

あなたのシステムを利用するのがあなた一人だけだとしたら, ア クセス制御もヘッダページもプリンタ利用に対する課金も必要ないのに, なぜわざわざスプーラに煩わされなければならないのか疑問に思うか もしれません. プリンタに対する直接アクセスを許可することもできるので すが, とにかくスプーラを使用するべきです. その理由は, LPDはジョブをバックグラウンドで処理します. データが プリンタに送信されるまで待つ必要はありません. LPDではジョブをフィルタを通してプリントすることが簡 単にできます. これにより, 印刷物のヘッダに時刻や日付を入れ たり, 特別なファイル形式 (TeX の DVI ファイルなど) をプリン タが処理できる形式に変更することができます. これらの作業を 手動でおこなう必要がなくなります. プリント処理をおこなうフリーのまたは商用のプログラムの ほとんどは, システムのスプーラとやりとりするように作られて います. スプーリングシステムをセットアップすることで, 今後 加えるかもしれない, あるいは, 既に持っている別のソフトウエ アをより簡単にサポートすることができるでしょう. スプーリングシステムのセットアップ

LPDスプーリングシステムを用いてプリンタを使用するためには, プリンタ機器とLPD用ソフトウェアの両方を準備する必要があります. 本ドキュメントでは次の2段階のレベルに分けて説明をします. プリンタを接続する方法, プリンタにどの ように通信するかをLPDに指示する方法や, プレインテキスト をプリンタで印字する方法については, 「」をご覧ください. 様々な形式のファイルを印字する方法, ヘッダページを 印字する方法, ネットワーク経由でプリンタに印字する方法, プリンタを制御する方法, プリンタの使用に対する課金をおこなう 方法については「」をご覧ください. プリンタ設定導入編

この節では, プリンタ機器やプリンタを使用するためのLPD用ソフ トウェアを設定する方法について述べます. この節の概要は次の通り です. 「」では, プリンタをコンピュータに接 続するためのヒントがいくつか書かれています. 「」では, LPDのスプーラ設定ファイル /etc/printcapの設定方法について書かれています. データをプリンタに送るためにシリアルまたはパラレルインタフェー スではなく, ネットワークプロトコルを使用する場合は, 「」をご覧くださ い. この節のタイトルは「プリンタ設定導入編」ですが, 実際の設定は かなり複雑です. プリンタをコンピュータに接続し, LPDスプーラを 起動させることは一番困難な作業です. ヘッダページを出力させたり, 課金したりするオプションの設定は, 一度プリンタがうまく動くよう になれば, とても簡単です. プリンタ機器の設定

この節では, プリンタにPCを接続するための様々な方法について 説明しています. ここでは, ポートやケーブルの種類, FreeBSDが プリンタとの通信に必要なカーネルコンフィグレーションについて も言及しています. もし, プリンタが既に接続されていて, 他のオペレーティングシステ ム上でプリンタからの印字に成功している場合は, 「」まで読み飛 ばすことが多分できるでしょう. ポートとケーブル

最近のPC用のプリンタほとんどには次のインタフェースの一つ もしくは両方がついています. パラレルインタフェースは「セントロニクス」インタフェー スとして知られています. これは, プリンタ用のコネクタタ イプとして採用された後に名付けられました. シリアルインタフェースはパラレルインタフェースより も普通はデータの伝送速度が遅くなります. パラレルインタフェースで は, 通常, (コンピュータからプリンタへの) 単方向通信のみをおこな うのに対して, シリアルインタフェースは双方向通信をおこないます. 最近のパラレルポートの多くはプリンタ側からデータを受けとる こともできますが, コンピュータ側にデータを送り返すことが必 要となるプリンタはほとんどありません. さらに, FreeBSDでは 双方向のパラレル通信をまだサポートしていません. 通常, プリンタで双方向通信が必要となるのは, プリンタが PostScript 言語に対応しているときだけです. PostScript プリ ンタは非常に冗長に動作させることができます. 事実, PostScript によるジョブでは, プログラムを本当にプリンタ に送信します. このことは, 印字作業を必ずしもする必要がない ことを意味し, また, プログラムの結果をコンピュータに直接返 されるかもしれません. PostScript プリンタでは, 双方向 通信を使って, PostScript プログラムのエ ラーや紙づまりといった問題をコンピュータに報告します. ユー ザはそれらの情報を知りたいと思うかもしれません. さらに, PostScript プリンタで課金作業をもっとも効率よくおこなうため には双方向通信が必要となります. この方法では, まず, プ リンタの現在のページカウント (起動してから今まで何枚の紙を 印字したか) の情報を得ます. 次に, ユーザのジョブをおこない, 終 了後, 再びページカウントを得ます. この2数を差によって, 課 金対象となる紙の枚数を知ることができます. それでは, どちらのインタフェースを使うべきなのでしょうか. 双方向通信が必要なら, シリアルポートを使ってくださ い. FreeBSDではパラレルポート上での双方向通信はまだサポー トされていません. 双方向通信の必要がなく, パラレルかシリアルかの選 択ができる場合はパラレルインタフェースを使うのが好ましい です. これにより, シリアルポートを他の周辺機器 (端末やモ デムのなど) のために残しておくことができます. また, パラ レルインタフェースの方がほとんどの場合高速であり, 設定も より簡単になっています. 結局のところは動いてくれるものを使えばよいのです. パラレルポート

プリンタをパラレルインタフェースを使って接続する場合は, セントロニクスケーブルでプリンタとコンピュータをつないでくださ い. 詳しい説明はプリンタ, コンピュータ, あるいは両方に付属す る説明書に書かれているはずです. その際, どのパラレルポートを使用したかを覚えておいてください. FreeBSDでは最初のポートは /dev/lpt0, 2番目は /dev/lpt1 であ り, 3番目以降も同様に続きます. シリアルポート

シリアルインタフェースを使ってプリンタを使う場合は, 適切 なシリアルケーブルでプリンタとコンピュータを接続してください. 詳しい説明はプリンタ, コンピュータ, あるいは両方に付属する説 明書に書かれているはずです. 「適切なシリアルケーブル」がよくわからないときは, 次のどれか を試してみてください. A この他に, プリンタ用の通信パラメータを設定する必要がありま す. 通常, プリンタのフロントパネルやDIPスイッチによって制 御します. コンピュータとプリンタの双方で設定できる最高の通 信速度[bps] (ビット/秒. ソフトウェアの設定

本節ではFreeBSDのLPDスプーリングシステムで印字をおこなうために 必要となるソフトウェアの設定について説明しています. 本節の概要は次のようになります. プリンタで使用するポートのために, 必要があれば, カー ネルの書き変えをおこないます. 「」で, このためにしなくてはなら ないことを説明しています. パラレルポートを使用している場合は, パラレルポートの ための通信モードの設定します. 詳細は, 「」で説明しています. オペレーティングシステムからプリンタにデータが送ら れているかをテストします. 「」で, どのように テストするかの提案をいくつかおこなっています. ファイル/etc/printcapを変更し, LPDの設定を おこないます. 「」で, どのように変更するかを 説明しています. カーネルの変更

オペレーティングシステムのカーネルのコンパイルをおこなうこと によって, 指定されたのデバイスが機能するようになります. シリ アル, または, パラレルインタフェースをプリンタで使用する場合, 必要なデバイスがこの指定の中に含まれていなくてはなりません. したがって, 必要なデバイスがカーネルに組み込まれていない場合, 追 加のシリアル, または, パラレルポートをサポートするために, カー ネルの再コンパイルが必要となるかもしれません. シリアルポートが現在使用しているカーネルでサポートされている かどうかを調べるためには, 次のように入力します. dmesg | grep sio ここで, sio2 at 0x3e8-0x3ef irq 5 on isa sio2: type 16550A パラレルポートが現在使用しているカーネルでサポートされている かどうかを調べるためには, 次のように入力します. dmesg | grep lpt ここで, lpt0 at 0x378-0x37f on isa 上記の出力が得られない場合, プリンタを使うため, オペレーティ ングシステムにパラレル, または, シリアルポートを認識し, 使用 できるようにするためにはカーネルを変更する必要があります. シリアルポートをサポートさせるには, 「」の節をご覧く ださい. パラレルポートをサポートさせる場合も, その節と, ポート用エントリを /dev に追加する

カーネルがシリアル, または, パラレルポートを通じての通 信をサポートしていたとしても, システム上で動いているプログ ラムがデータの送受信をおこなうためのソフトウェアインタフェース がさらに必要になります. そのインタフェースは, /dev ディレクトリにあるエントリに相当します. /dev エントリにポートを加えるために /dev ディレクトリに移動します. cd /dev 次のように入力します. ./MAKEDEV ここで, 次を入力し, デバイスのエントリができたか確認し ます. ls -l パラレルポートの通信モードを設定する

パラレルインタフェースを使用している場合, FreeBSDでは, 割り込み駆動型にするか, プリンタとの通信の状況をカーネルに監 視させるかのいずれかを選択できます. GENERIC カーネルでは 割り込み駆動方式は, いくらか高速になりますが, 貴重な IRQ ラインを一つ消費します. うまく機能するものをお使いください. 通信モードを設定するためには2つの方法があります. 1つはカー ネルを変更することで, もう一つは カーネルを設定することによって, 通信モードを変更す る. カーネルコンフィグレーションファイルを変更しま す. イベント駆動方式にする場合は, device lpt0 at isa? port? tty irq ここで, 監視方式を使用する場合は, device lpt0 at isa? port? tty vector lptintr ファイルをセーブし, config プログラムを起動 し, カーネルの構築, インストールをおこないます. そして, リ ブートしてください. 詳細は, 「」を参照 してください. lptcontrol -i -u lptcontrol -p -u これらのコマンドを /etc/rc.local ファイルに追加 しておくと, システムをブートする度に通信モードを設定する ことができます. 詳細については, lptcontrol(8) をご覧くだ さい. プリンタとの通信状況を調べる

スプーリングシステムの設定に進む前に, オペレーティング システムがプリンタにデータを送ることに成功しているかどうか を確かめるべきでしょう. これにより, 印字がうまくいかないと き, プリンタとの通信が問題なのか, スプーリングシステムが問 題なのかを分けて調べることがかなり容易になります. プリンタをテストするためには, プリンタに何かのテキストを送 信してみます. 送信した文字をすぐに印字してくれるプリンタに は, %!PS 100 100 moveto 300 300 lineto stroke 310 310 moveto /Helvetica findfont 12 scalefont setfont (Is this thing working?) show showpage パラレルポートのプリンタとの接続を調べる

この節では, FreeBSDがパラレルポートに接続されたプリ ンタと通信できているかどうかを調べる方法について説明し ています. パラレルポートのプリンタをテストするために プリンタにデータを送ります. プリンタがプレインテキストを印字できる場 合, lptest > /dev/lpt ここで, プリンタが PostScript か他のプリンタ 言語を使用している場合, そのプリンタに簡単なプロ グラムを送信してください. 次のように入力します. cat > /dev/lpt そして, 一行一行, プログラムを もしくは, プログラムを入力したファイルがある 場合は, 次のように入力してください. cat /dev/lpt ここで, これで何かがプリントされることでしょう. 印字されたテキ ストがおかしくても心配しなくても構いません. それについ ては, 後で修正します. シリアルポートのプリンタとの接続を調べる

この節では, FreeBSDがシリアルポートに接続されたプリ ンタと通信できているかどうかを調べる方法について述べられ ています. シリアルポートのプリンタをテストするために /etc/remote ファイルを編集します. 次の エントリを加えてください. printer:dv=/dev/ ここで, 次の例は, プリンタをシリアルケーブルでパリティなし, 転送速度19200bpsで第3番目のシリアルポートに接続した場 合です. printer:dv=/dev/ttyd2:br#19200:pa=none tip printer これがうまくいかなかった場合は, /etc/remoteを 編集して, /dev/ttydの代わりに /dev/cuaaを試してみてください. プリンタにデータを送ります. プリンタがプレインテキストを印字できる場 合, ~$lptest プリンタが PostScript か他のプリンタ 言語を使用している場合, そのプリンタに簡単なプロ グラムを入力します. 一行一行, プログラムを もしくは, プログラムを入力したファイルがある 場合は, 次のように入力してください. ˜> ここで, これで何かがプリントされることでしょう. 印字されたテキ ストがおかしくても心配しなくても構いません. それについ ては, 後で修正します. スプーラに許可を与える: /etc/printcap ファイル

ここまでで, プリンタはコンピュータに接続され, (必要なら) プリンタと通信できるようにカーネルを変更し, 簡単なデータをプ リンタに送信することができているはずです. これで, LPDにプリ ンタへのアクセスを制御させる設定をおこなう準備が整いました. LPDの設定は /etc/printcap を編集することでおこないます. LPDスプーリングシステムはスプーラが使われる毎にこのファイル を参照します. そのため, ファイルを更新するとすぐにその変更が 反映されます. /etc/printcap の編集はお好みのテキストエディタをお 使いください. このファイルの書式は, /usr/share/misc/termcap や /etc/remote といった他のケイパビリティファイルと一致しています. この書式 のついての詳細な情報については cgetent(3) をご覧ください. スプーラの単純な設定法は, 次のステップでおこないます. プリンタに名前 (と簡単な別名2〜3個) を付け, それを /etc/printcap ファイルに記述します. これについ ては, 「」 を参照してください. 」 を参照してください. スプール用のディレクトリを作成し, その位置を 」 を参照してください. プリンタを使用するために /dev エントリを 設定し, /etc/printcap の 」 を参照してください. プリンタをシリアルポートに接続した場合は, 」 を参照してください. プレインテキスト用の入力フィルタのインストールを おこないます. 「」 を参照してください. と を参照してください. 」で, そ れをどのようにおこなえばよいのかが説明されています. プリンタに名前を付ける

最初の (簡単な) ステップで, プリンタの名前を考えます. プ リンタには別名をいくつか付けることもできるので, 機能的な名前 でも風変わりな名前でもどちらを選んでもまったく問題はありません. 少なくとも1つのプリンタには, /etc/printcap の中 で, /etc/printcap ファ イルに設定します. プリンタ名は一番左のカラムから書き始めま す. 別名はそれぞれ縦棒によって区切られ, 最後の別名の後ろに コロンを置きます. 次の例では, 2台のプリンタ (Diablo 630 ラインプリンタと Panasonic KX-P4455 PostScript レーザライタプリンタ) が定義 されている /etc/printcap のスケルトンを記しています. # # /etc/printcap for host rose # rattan|line|diablo|lp|Diablo 630 Line Printer: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4: この例では, 最初のプリンタに ヘッダページの印字を禁止する

LPDスプーリングシステムでは, デフォルトでジョブ毎に/etc/printcap にあるプリンタのエントリに /etc/printcap の例を示しま す. # # /etc/printcap for host rose - no header pages anywhere # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh: この書式を正しく使うための注意をしておきます. 最初の行は左 端のカラムから始まります. それに続く行は TAB ひとつ分だけ 字下げします. 最後の行以外のすべての行は, 行末にバックスラッ シュを記述します. スプーリングディレクトリの作成

スプーラの簡単な設定の次のステップでは, /var/spool の下に置きます. また, スプーリングディレクトリの内容はバックアップをす る必要はありません. mkdir /var/spool/printer-name しかしながら, ネットワーク上に使用可能なプリンタがたく さんあるならば, LPDで印字するための専用のディレクトリに スプーリングディレクトリを置きたいと思うかもしれません. 例に出てきたプリンタ mkdir /var/spool/lpd mkdir /var/spool/lpd/rattan mkdir /var/spool/lpd/bamboo chown daemon.daemon /var/spool/lpd/rattan chown daemon.daemon /var/spool/lpd/bamboo chmod 770 /var/spool/lpd/rattan chmod 770 /var/spool/lpd/bamboo 最後に, /etc/printcap ファイルで, これらのディ レクトリの位置を LPD に伝える必要があります. スプーリ ングディレクトリのパス名は # # /etc/printcap for host rose - added spooling directories # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo: プリンタ名が最初のカラムから始まっており, そのプリンタ に関して記述される他のエントリは TAB で字下げされてい ること, 各行がバックスラッシュで終わっていることに注意 してください. /var/spool/lpd デフォルト値として使用します. プリンタデバイスの特定

「」では, FreeBSD でプリン タとの通信に使用される /dev ディレクトリ内の エントリを特定します. そして, LPD にその情報を伝えま す. 印字するジョブを受け取ると, スプーリングシステムは, (プリンタにデータを渡す義務がある) フィルタプログラムに 代わって指定されたデバイスをオープンします. /etc/printcap ファイルで /dev エントリを記入します. ここでの例では, /etc/printcap には 次のようになります. # # /etc/printcap for host rose - identified what devices to use # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:\ :lp=/dev/ttyd5: /etc/printcap でプリンタの /dev/lp を使用します. /dev/lp は, 現在の FreeBSD には存在していません. 設置したプリンタがパラレルポートに接続されている場合は, 「」まで読み飛ばしてください. そうでない場合は, 次節の説明に続いてください. スプーラのための通信パラメータの設定

シリアルポートにプリンタを接続した場合, プリンタにデー タを送信するフィルタプログラムに代わり, 通信速度やパリ ティ, その他のシリアル通信パラメータを設定することがで きます. このことによる利点は, /etc/printcap を編集するだけで, 様々な 通信パラメータを試してみることができます. フィルタプロ グラムを再コンパイル必要はありません. スプーリングシステムで, シリアル通信の設定が異 なっているかもしれない複数のプリンタに同じフィルタプロ グラムを使うことが可能になります. 次の /etc/printcap の項目で, br#/ デバイスの通信速度を fc#/ デバイスをオープンした後で, fs#/ xc#/ デバイスをオープンした後で, ローカルモードビット xs#/ ローカルモードビット /usr/include/sys/ioctl_compat.h を参照してく ださい. 項目 bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:\ :lp=/dev/ttyd5:fs#0x82000c1:xs#0x820: テキストフィルタのインストール

ここまでで, プリンタにジョブを送るために使うテキストフィ ルタを LPD に設定する準備が整いました. 」をご覧ください. ここでの簡単なプリンタ設定では, プリンタにジョブを送るため, /bin/cat を実行するだけの簡単なシェルスクリプ トで間に合います. FreeBSD に標準で付属している 」で詳しく説明します. 最初に, 簡単なテキストフィルタであるシェルスクリプト /usr/local/libexec/if-simple を作ってみましょ う. 次のテキストをお好みのテキストエディタでファイルに 書き込んでください. #!/bin/sh # # if-simple - Simple text input filter for lpd # Installed in /usr/local/libexec/if-simple # # Simply copies stdin to stdout. Ignores all filter arguments. /bin/cat && exit 0 exit 2 そして, このファイルを実行可能にします. chmod 555 /usr/local/libexec/if-simple LPD にこのテキストフィルタを使うことを設定するためには, /etc/printcap に /etc/printcap の例のプリンタ 2台に, このフィルタを加えてみましょう. # # /etc/printcap for host rose - added text filter # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:\ :lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:\ :if=/usr/local/libexec/if-simple: 印字してみよう

簡単な LPD 設定も終わりにたどり着きました. 残念ながら, 設定はこれでおしまいというわけではありません. なぜなら, さらに, 設定をテストし, すべての問題点を解決しなくては ならないからです. 設定をテストするために, 何かを印字し てみましょう. LPD システムで印字をするためには, 」で紹介した, あるテスト用のテキストを生成してくれる 簡単な LPD 設定をテストするために:

次のように入力してください. lptest 20 5 | lpr -P ここで, /etc/printcap で指定したプリンタ名 (もしくはその別名) です. デフォルト のプリンタを使用する場合は, !"#$%&'()*+,-./01234 "#$%&'()*+,-./012345 #$%&'()*+,-./0123456 $%&'()*+,-./01234567 %&'()*+,-./012345678 更にプリンタをテストしたい場合は, (言語ベースのプリン タのための) もっと大きなプログラムを送信するか, 引数を 変えて 」をご覧ください. トラブルシューティング

/usr/local/libexec/if-simple を次のように変更して, プリンタへジョブを送信した後に FROM FEED 文字を印字させるようにします. #!/bin/sh # # if-simple - Simple text input filter for lpd # Installed in /usr/local/libexec/if-simple # # Simply copies stdin to stdout. Ignores all filter arguments. # Writes a form feed character (\f) after printing job. /bin/cat && printf "\f" && exit 0 exit 2 !"#$%&'()*+,-./01234 "#$%&'()*+,-./012345 #$%&'()*+,-./0123456 あなたは プリンタが CR を受け取ったとき CR 動作 (復帰) をおこなう. プリンタが LF を受け取ったとき CR + LF 動作 (復帰, 改行) をおこなう. このように動作させるための方法がいくつかあります. これらの文字の解釈を変えるために, プリンタ の設定スイッチかコントロールパネルを操作する方 法. どのようにして設定をするかはプリンタのマニュ アルを参照してください.

自動的に LF を CR+LF に変換してくれる FreeBSD 用のシリアルドライバを入手する方法. も ちろん, このドライバはプリンタ専用に接続される シリアルポート/etc/printcap ファ イルで対象プリンタの LF 文字の扱いを一時的に変更するための 次に, Hewlett Packard 社の PCL エスケープコー ドに対応しているプリンタのためのテキストフィル タの例を示します. このフィルタでは, プリンタ に LF 文字を LF と CR の2文字として扱わせます. その後に, プリンタにジョブを送ります. 最後に, ジョブの最終ページの紙を排出するため, FROM FEED 文字を送ります. このフィルタは Hewlett Packard 社のほとんどすべてのプリンタで機能するは ずです. #!/bin/sh # # hpif - Simple text input filter for lpd for HP-PCL based printers # Installed in /usr/local/libexec/hpif # # Simply copies stdin to stdout. Ignores all filter arguments. # Tells printer to treat LF as CR+LF. Writes a form feed character # after printing job. printf "\033&k2G" && cat && printf "\f" && exit 0 exit 2 ホスト orchid にある /etc/printcap の 例を以下に示します. ここには, 一番目のパラレル ポートにプリンタ (Hewlett Packard LaserJet 3Si) が一台接続されており, そのプリンタ名は # # /etc/printcap for host orchid # teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\ :lp=/dev/lpt0:sh:sd=/var/spool/lpd/teak:mx#0:\ :if=/usr/local/libexec/hpif: if-simple の cat の部分 を置き換えればよいわけです. 具体的にどのように するかは, 読者への練習問題としましょう. プリンタが CR を受け取ったとき CR 動作 (復帰) をおこなう. プリンタが LF を受け取ったとき CR + LF 動作 (復帰, 改行) をおこなう. if-simple の cat の部分を置き換えればよいわけ です. 具体的にどのようにするかは, 読者への練習問題とし ましょう. プリンタが XON/XOFF のフロー制御をサポート している場合は, 項目 プリンタがキャリアフロー制御をサポートして いる場合は, 項目 プリンタがフロー制御をまったくサポートしていな い場合は, 項目 /etc/printcap ファイルで設定した 内容と一致しているかどうかも確認してください. /etc/printcap ファイルで, デバッグしているプ リンタのエントリに ( rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple:\ :lf=/var/log/rattan.log 次に, もう一度印字をおこなってみます. そして, 発生したと思 われるエラーメッセージを見るためにログファイル (上記の 例では, /var/log/rattan.log) を調べます. そこ で見られたメッセージを元に, 問題を解決してみてください. 項目 /dev/console を使います. プリンタを使う

この節では, FreeBSD で設定したプリンタを使う方法について説明 します. ここでは, ユーザレベルでのコマンドを概説します. 管理者用コマンド 」に記 します. このコマンドは, プリンタやそのキューの制御のために用い られます. /etc/printcap のように操作の対象となるプリンタやキュー を指定します. これによって, 様々なプリンタに対してジョブを送る, 取り消す, 調査することができます. 印字する

ファイルを印字するためには, 次のように入力してください. lpr これにより, 入力されたファイルのそれぞれをデフォルトのプリンタ から印字します. ファイル名が与えられなかった場合, lpr /etc/host.conf /etc/hosts.equiv 印字させるプリンタを選択するためには, 次のように入力します. lpr -P 次の例では, プリンタ ls -l | lpr -P rattan 上記の 」をご 覧ください. ジョブの処理状況を調べる

lpq -P bamboo は, プリンタ bamboo is ready and printing Rank Owner Job Files Total Size active kelly 9 /etc/host.conf, /etc/hosts.equiv 88 bytes 2nd kelly 10 (standard input) 1635 bytes 3rd mary 11 ... 78519 bytes この例では, 」をご覧ください. ジョブ番号9のジョブは2つのファイルを処理します. すなわち, waiting for bamboo to become ready (offline ?) kelly: 1st [job 009rose] /etc/host.conf 73 bytes /etc/hosts.equiv 15 bytes kelly: 2nd [job 010rose] (standard input) 1635 bytes mary: 3rd [job 011rose] /home/orchid/mary/research/venus/alpha-regio/mapping 78519 bytes ジョブの削除

印字するようジョブを送った後で印字を中断したくなったときは, 特定のプリンタへのジョブを削除するときは, lprm -P bamboo 10 上記の略記法をデフォルトプリンタではなく特定のプリンタに対して おこなうときは, lprm -P rattan - rose% lpr -P rattan myfile rose% rlogin orchid orchid% lpq -P rattan Rank Owner Job Files Total Size active seeyan 12 ... 49123 bytes 2nd kelly 13 myfile 12 bytes orchid% lprm -P rattan 13 rose: Permission denied orchid% logout rose% lprm -P rattan 13 dfA013rose dequeued cfA013rose dequeued rose% その他の印字オプション

整形と変換に関するオプション

以下の lpr -P bamboo -d fish-report.dvi このオプションは, ジョブに含まれるすべてのファイルに対して適用さ れます. したがって, 1つのジョブに (例えば) DVI ファイルと ditroff ファイルを混在させることはできません. その代わりに, ファイルを 形式毎に別々のジョブに分け, それぞれのジョブでその形式用の変換 オプションを使って印字してください. 」で説明しています. 次の例では, zcat /usr/share/man/man1/ls.1.gz | troff -t -man | lpr -t ジョブに関するオプション

以下のオプションは, 」をご覧ください.

次の例では, デフォルトプリンタで lpr -#3 parser.c parser.h ヘッダページ用オプション

以下のオプションにより, ジョブのヘッダページに通常印字さ れるテキストを 」を参照してください. 」をご覧ください. プリンタを管理する

プリンタの管理者として, プリンタの設置, 設定, そして, それ らのテストをおこなう必要がありました. プリンタの起動, 停止をおこなう. キューへの入力の許可, 禁止をおこなう. それぞれのキューにあるジョブの順番を変更する. 最初に用語に関する注意をしておきます. プリンタが/etc/printcap 内に ある全プリンタに対しておこなわれることになります. コマンドラインから上記のコマンドを入力すると, プリンタ設定上級編

この節では, 特殊な形式のファイルを印字するためのフィルタ, ヘッ ダページ, ネットワーク越しのプリンタへの印字, そして, プリンタ 使用の制限や課金について説明しています. フィルタ

LPD では, ネットワークプロトコル, キュー, アクセス制御, そ して, 印字のためのその他の側面について扱いますが, 」を参照) しかしながら, 形式変換やプリンタ課金, 特定のプリンタの癖, など をうまく利用するためには, フィルタがどのように機能するかという ことを理解しておくべきです. これらの側面を扱うためには, 最終的 には, フィルタの責任であるからです. そして, これは悪い情報です が, ほとんどの場合において, /usr/libexec/lpr/lpf というフィルタが1つ付いています. (このフィルタはファイルに含まれるバックスペースやタブを扱いま す. また, 課金をすることもできますが, できることはこれだけしか ありません.) いくつかのフィルタとフィルタの構成要素が FreeBSD の ポート集にもあります. この節で述べることは次の通りです. 「」では, 印字の過程におけ るフィルタの役割を概説します. この節を読むことで, LPD がフィルタを使うときに, 「見えないところで」何が起こっている かが理解できるでしょう. このことを知っておくと, プリン タそれぞれに様々なフィルタをインストールしたときに遭遇 するかもしれない問題を予期したり, デバッグするときに役 立つでしょう. LPD では, すべてのプリンタからデフォルトでプレインテ キストを印字できることを期待しています. このことは, プ レインテキストを直接印字できない PostScript (また は他の言語用の) プリンタでは問題を引き起こします. 「」 で, この問題を克服する方法について述べます. PostScript プリンタをお持ちの方は, この節をお読みになること をお薦めします. PostScript は様々なプログラムのための有名な出 力形式です. ある人たちは (著者自身を含めて) PostScript のコードさえも直接書いてしまいます. しかし, PostScript プリンタは高価です. 「」では, PostScript データを 「」では, 図形や組版データといっ た特定のファイル形式を, プリンタが理解できる形式へ変換 する作業を自動的におこなわせる方法について述べます. この節 を読むと, troff のデータを印字するには 「」 では, あまり使われない LPD の機能のすべて, すなわち, 出力フィルタに関することが記述されています. ヘッダページ (「」参照) を印字させていない場合は, 多分, この節は飛ばしても構わないでしょう. 「」では, 「」では, 日本語を含むテキスト を印字するためのヒントを述べてます. --> フィルタはどのように機能しているか

既に言及したように, フィルタとは, プリンタにデータを送る 際に, デバイスに依存した部分を取り扱うために LPD によって起動 される実行プログラムです. LPD がジョブ中のファイルを印字しようとするとき, LPD はフィル タプログラムを起動します. このとき, フィルタの標準入力を印字す るファイルに, 標準出力をプリンタに, そして, 標準エラー出力をエ ラーログファイル (/etc/printcap 内の /dev/console) にセットします. LPD が起動するフィルタと, その引数が何であるかは, /etc/printcap ファイルの内容と, ジョブの起動時に ユーザが指定した 」をご覧ください). /etc/printcap で指定可能なフィルタは次の3種類がありま す. [-c] -w ここで, /etc/printcap で指定された 」 で, これらに関するすべてについて説明します. プリンタの課金をする必要がある場合は, 変換フィルタでも 印字ページを数える作業が必要となります. 変換フィルタは次の引数をとって起動されます. -x ここで, 」で, これらのことについて説明し ます. アウトプットフィルタに対する引数は次の2つだけです. -w ここで, フィルタは, 次に示すの終了状態をもってプログラムを FreeBSD に付属するテキストフィルタ /usr/libexec/lpr/lpf は, FROM FEED 文字が送られたと きやプリンタ使用に対する課金をどのようにするかを決定するために, ページ幅やページ長の引数を利用します. また, 課金用のエントリを 作成するため, ログイン名, ホスト名, 課金ファイル名の引数を利用 します. もし, フィルタの購入を検討しているならば, LPD と互換性がある かどうかを確認してください. もしそうならば, 上述の引数リストをサ ポートしていなければなりません. 一般向けの使用のためにフィルタ を作成する計画をしている場合は, 同じ引数リストと終了コードをサ ポートしてください. プレインテキストのジョブを PostScript プリン タで印字する

コンピュータと PostScript (または, 他の言語に対応し た) プリンタをあなたしか使用しない場合は, プリンタにプレ インテキストを絶対に送らない, そして, プリンタにプレインテキス トを送りたがっている様々なプログラムの機能を決して使わないこと にしてください. そうすれば, この節に書かれたことに心を煩わせる必 要はまったくなくなります. しかし, PostScript とプレインテキストの両方のジョブをプリン タへ送りたいと思っている場合は, プリンタ設定についての要求が増 えるでしょう. 両者をプリンタへ送信するためには, 到着 したジョブがプレインテキストであるか PostScript であるかを 検出するテキストフィルタが必要です. PostScript のジョブは すべて 」を参照してください). もちろん,自分自身でプログラムを取ってきて, コンパイルし, インストールす ることもできます. /etc/printcap の中のシリアル接続した PostScript プリンタのエントリに対して, 次を使ってください. :if=/usr/local/libexec/psif: LPD にプリンタをリード・ライトモードでオープンさせるために, #!/bin/sh # # psif - Print PostScript or plain text on a PostScript printer # Script version; NOT the version that comes with lprps # Installed in /usr/local/libexec/psif # read first_line first_two_chars=`expr "$first_line" : '\(..\)'` if [ "$first_two_chars" = "%!" ]; then # # PostScript job, print it. # echo $first_line && cat && printf "\004" && exit 0 exit 2 else # # Plain text, convert it, then print it. # ( echo $first_line; cat ) | /usr/local/bin/textps && printf "\004" && exit 0 exit 2 fi 上記のスクリプトにおいて, 」を参照してください) には, 非 PostScript プリンタで PostScript をシミュレートする

PostScript は質の高い組版と印字をおこなうための #!/bin/sh # # ifhp - Print Ghostscript-simulated PostScript on a DesJet 500 # Installed in /usr/local/libexec/hpif # # Treat LF as CR+LF: # printf "\033&k2G" || exit 2 # # Read first two characters of the file # read first_line first_two_chars=`expr "$first_line" : '\(..\)'` if [ "$first_two_chars" = "%!" ]; then # # It is PostScript; use Ghostscript to scan-convert and print it # /usr/local/bin/gs -dSAFER -dNOPAUSE -q -sDEVICE=djet500 -sOutputFile=- - \ && exit 0 else # # Plain text or HP/PCL, so just print it directly; print a form # at the end to eject the last page. # echo $first_line && cat && printf "\f" && exit 2 fi exit 2 最後に, :if=/usr/local/libexec/hpif: これでおしまいです. 変換フィルタ

「」 に書かれた簡単な設定が完了したら, 最初に, やってみたいと思 うことは, 多分(プレイン ASCII テキストに加えて) 好みのファイル形式 のための変換フィルタをインストールすることでしょう. なぜ, 変換フィルタをインストールするのか?

変換フィルタによって, 様々な種類のファイルを印字するこ とが簡単になります. 例えば, TeX 組版システムでたくさんの仕事 をしたと仮定しましょう. そして, PostScript プリンタが接続 されているとします. すると, TeX で DVI ファイルを作成する度に, DVI ファイルを印字するために, これを PostScript ファイルに 変換する必要があります. このコマンドは次のようになるでしょう. dvips seaweed-analysis.dvi lpr seaweed-analysis.ps DVI ファイル用の変換フィルタがインストールしてあると, LPD に 変換を肩代わりさせることで毎回毎回おこなわなければならなかった面倒 な変換作業を省くことができます. つまり, DVI を生成したら, 次のような1回のコマンド入力だけで, これが印字されます. lpr -d seaweed-analysis.dvi LPD に DVI ファイルの変換をさせるためには, 」に載せてあります. 変化のオプションのそれぞれをプリンタにサポートさせるためには, /etc/printcap の中で指定しなくてはなりません. 変換フィ ルタは, プレインテキストを印字する代わりに, フィルタはファイル をプリンタが理解できる形式に変換するところを除けば, 「プリンタ の簡単な設定」で説明したテキストファイル (「」 を見て下さい) に似ています. どの変換フィルタをインストールすべきか?

使いたいと思う変換フィルタをインストールすべきです. DVI のデータを頻繁に印字するならば, DVI 変換フィルタ をインストールするのが適切でしょう. 印字しなくてはなら ない troff を大量に抱えている場合は, 多分, troff フィ ルタが欲しくなるはずです. 次の表は, LPD で動作するフィルタと, /etc/printcap ファイルでのエントリする項目, そして, /etc/printcap ファイル形式 項目 lpr オプション ------------ ------------- ---------- cifplot cf -c DVI df -d plot gf -g ditroff nf -n FORTRAN text rf -f troff tf -t raster vf -v プレインテキスト if なし, -p, または -l 先の例のように, /etc/printcap 内のエントリで, 変換フィルタのインストール

変換フィルタは FreeBSD の基本システムのインストールとは別 にインストールするプログラムなので, 変換フィルタは, 多 分, /usr/local ディレクトリの下に置くべ きです. フィルタは LPD だけが実行する特別なプログラム, すなわち, 一般ユーザが実行する必要すらない プログラムなので, /usr/local/libexec ディレ クトリに置くのが普通です. 変換フィルタを使用可能にするためには, /etc/printcap の目的のプリンタの適切な項目に フィルタがあるパス名を指定します. DVI 変換フィルタをプリンタ /etc/printcap ファイルの例を以下 に再掲します. # # /etc/printcap for host rose - added df filter for bamboo # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:\ :lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf: DVI フィルタは /usr/local/libexec/psdf という 名前のシェルスクリプトです. このスクリプトは次のように なっています. #!bin/sh # # psdf - DVI to PostScript printer filter # Installed in /usr/local/libexec/psdf # # Invoked by lpd when user runs lpr -d # exec /usr/local/bin/dvips -f | /usr/local/libexec/lprps "$@" このスクリプトでは, 」 を参照してください) を LPD に与えられた引数を付けて起動 します. 変換フィルタのその他の例

変換フィルタのインストールには決まったステップがないの で, その代わりに, 例をもっと挙げることにします. これを, 自分でフィルタを作る際のガイドにしてください. 適当な例が あったら, それをそのまま使ってください. 次のスクリプト例は, Hewlett Packard LaserJet III-Si の ための, raster (ええと・・実は, GIF ファイル) 用の変 換フィルタです. #!/bin/sh # # hpvf - Convert GIF files into HP/PCL, then print # Installed in /usr/local/libexec/hpvf PATH=/usr/X11R6/bin:$PATH; export PATH giftopnm | ppmtopgm | pgmtopbm | pbmtolj -resolution 300 \ && exit 0 \ || exit 2 ここでは, GIF ファイルから PNM (portable anymap) 形式 に変換し, 次に PGM (portable graymap) 形式に変換してか ら, LaserJet/PCL-互換データに変換しています. 上記のフィルタを使うプリンタのためのエントリを付け加え た /etc/printcap ファイルは次のようになります. # # /etc/printcap for host orchid # teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\ :lp=/dev/lpt0:sh:sd=/var/spool/lpd/teak:mx#0:\ :if=/usr/local/libexec/hpif:\ :vf=/usr/local/libexec/hpvf: 次のスクリプトは, PostScript プリンタ #!/bin/sh # # pstf - Convert groff's troff data into PS, then print. # Installed in /usr/local/libexec/pstf # exec grops | /usr/local/libexec/lprps "$@" 上記のスクリプトではプリンタとの通信をおこなうため, #!/bin/sh # # pstf - Convert groff's troff data into PS, then print. # Installed in /usr/local/libexec/pstf # exec grops これで完成しました. 次に, フィルタを使用可能にするため に /etc/printcap に加える必要があるエントリを 示します. :tf=/usr/local/libexec/pstf: 次の例をみたら, FORTRAN のベテランは赤面するかもしれ ません. この FORTRAN テキストフィルタは, プレインテキ ストを直接印字できるすべてのプリンタで利用できます. この フィルタをプリンタ #!/bin/sh # # hprf - FORTRAN text filter for LaserJet 3si: # Installed in /usr/local/libexec/hprf # printf "\033&k2G" && fpr && printf "\f" && exit 0 exit 2 そして, このフィルタを使用可能にするため, 以下の行を /etc/printcap のプリンタ :rf=/usr/local/libexec/hprf: これが最後の, そして, 若干複雑な例です. 前に紹介した LaserJet プリンタ /etc/printcap に書 き加えます. :df=/usr/local/libexec/hpdf: さて, 難しい部分であるフィルタの作成をおこないます. このた めに, DVI から LaserJet/PCL への変換プログラムが必要 です. FreeBSD のポート集 (「」を参照してください) には, それがあ ります. /dev/fd/0 を使うのは問題がありま す. この問題は, (/dev/fd/0 に (シンボリックな) リンクを張る ことで回避することができます. これで, /tmp ディレクトリはスティッ キービットが立っています. フィルタはリンクを作ることが できます. しかし, リンクは別のユーザに所有されているた め, 作業が終了したとき, このリンクを削除することができ ません. その代わりに, シンボリックリンクは現在の作業ディレクト リ, すなわち, スプーリングディレクトリ (/etc/printcap の /tmp ディレクトリ よりもたくさんあるからです. 以下に示すのが最後のフィルタです. #!/bin/sh # # hpdf - Print DVI data on HP/PCL printer # Installed in /usr/local/libexec/hpdf PATH=/usr/local/bin:$PATH; export PATH # # Define a function to clean up our temporary files. These exist # in the current directory, which will be the spooling directory # for the printer. # cleanup() { rm -f hpdf$$.dvi } # # Define a function to handle fatal errors: print the given message # and exit 2. Exiting with 2 tells LPD to do not try to reprint the # job. # fatal() { echo "$@" 1>&2 cleanup exit 2 } # # If user removes the job, LPD will send SIGINT, so trap SIGINT # (and a few other signals) to clean up after ourselves. # trap cleanup 1 2 15 # # Make sure we are not colliding with any existing files. # cleanup # # Link the DVI input file to standard input (the file to print). # ln -s /dev/fd/0 hpdf$$.dvi || fatal "Cannot symlink /dev/fd/0" # # Make LF = CR+LF # printf "\033&k2G" || fatal "Cannot initialize printer" # # Convert and print. Return value from dvilj2p does not seem to be # reliable, so we ignore it. # dvilj2p -M1 -q -e- dfhp$$.dvi # # Clean up and exit # cleanup exit 0 自動変換: その他の変換フィルタ

ここまでに述べてきたフィルタによって, 印字環境の能率が 上がったことと思います. しかし, これはどのフィルタを使 うかを ( 出力フィルタ

LPD スプーリングシステムでは, ここまでにまだ取り上げていな いフィルタ形式, 出力フィルタをサポートしています. 出力 フィルタは, テキストフィルタのように, プレインテキスト のみを印字するために意図されたものですが, 非常に簡単化 されています. テキストフィルタを用いずに, 出力フィルタ を使っている場合は, 次のようになります. LPD はジョブ中の各ファイルに一度ではなく, ジョブ 全体に対して一度だけ出力フィルタを起動します. LPD は出力フィルタに対し, ジョブ中のファイルの先 頭や末尾を特定するための対策を一切おこなっていません. LPD はユーザのログイン名やホスト名をフィルタに渡 しません. したがって, 課金の処理をおこなうことは考えてい ません. 実際, 出力フィルタには, 以下2つの引数しか与え られません. -w ここで, 出力フィルタの簡便さに誘惑されてはいけません. もし, ジョ ブ中のそれぞれのファイルに別のページ番号を付加しようと しても, 出力フィルタは」をご覧ください. さらに, 出力 フィルタは, 実のところ, 」 を参照してください) だけを印字させるために, 出 力フィルタを起動させます. それから LPD では, アウトプッ トフィルタに2バイトの文字 (ASCII 031 の次に ASCII 001) を送ることで, 出力フィルタが テキストフィルタ

プログラム /usr/libexec/lpr/lpf は, FreeBSD の バイナリ配布に付属しているテキストフィルタ (入力フィル タ) で, 出力を字下げしたり (/etc/printcap ファイルの中の 」をご覧ください. ヘッダページ

あなたが管理するシステムのユーザが」をご覧ください. ヘッダページの印字を許可する

「」 では, /etc/printcap ファイルの #!/bin/sh # # hpof - Output filter for Hewlett Packard PCL-compatible printers # Installed in /usr/local/libexec/hpof printf "\033&k2G" || exit 2 exec /usr/libexec/lpr/lpf 」 をご覧ください. 次に, 以前紹介したプリンタ /etc/printcap ファイルの例を示します. ここでは, ヘッ ダページの印字を許可し, 上記の出力フィルタを追加しました. # # /etc/printcap for host orchid # teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\ :lp=/dev/lpt0:sd=/var/spool/lpd/teak:mx#0:\ :if=/usr/local/libexec/hpif:\ :vf=/usr/local/libexec/hpvf:\ :of=/usr/local/libexec/hpof: さて, ユーザが 」 をご覧ください. /etc/printcap 中の ヘッダページを制御する

ヘッダページの印字が許可されていると, LPD は k ll ll k l l k l l k k eeee l l y y k k e e l l y y k k eeeeee l l y y kk k e l l y y k k e e l l y yy k k eeee lll lll yyy y y y y yyyy ll t l i t l oooo u u ttttt l ii n nnn eeee o o u u t l i nn n e e o o u u t l i n n eeeeee o o u u t l i n n e o o u uu t t l i n n e e oooo uuu u tt lll iii n n eeee r rrr oooo ssss eeee rr r o o s s e e r o o ss eeeeee r o o ss e r o o s s e e r oooo ssss eeee Job: outline Date: Sun Sep 17 11:04:58 1995 LPD はこのテキストの終わりに FROM FEED 文字を加えます ので, ジョブは新しいページから開始されます (ただし, /etc/printcap で出力先のプリンタのエントリに /etc/printcap ファ イルの中で rose:kelly Job: outline Date: Sun Sep 17 11:07:51 1995 デフォルトでは, LPD はヘッダページを最初に印字し, 次 にジョブの印字をおこないます. この順番を逆にするときは, /etc/printcap で ヘッダページに対する課金

LPD に備わっているヘッダページ出力機能を使うと, 入力され たジョブに対して課金をおこなうことができても, ヘッダページは LPD のやり方を受け入れ, ヘッダページは無料とする. LPDng や PLP といった LPD の代替品をインストール する. LPD と入れ替えが可能な他のスプーリングソフトウェ アに関しては, 「」をご覧ください. /etc/printcap で PostScript プリンタでのヘッダページ

これまでに述べたように, LPD ではプレインテキストのヘッ ダページをたくさんのプリンタに合うように生成することができます. 残念ながら, PostScript プリンタは, プレインテキストを直接 印字することができません. ですから, LPD のヘッダページ機能は まったく役に立たない, あるいはほとんどの場合で役に立ちません. ヘッダページを出力するための自明な方法の1つに, すべての変換フィ ルタとテキストフィルタにヘッダページを生成させる方法があります. フィルタは, 適切なヘッダページを生成するために, ユーザ名とホス ト名の引数を使うべきです. この方法の欠点は, いつでも, #!/bin/sh # # make-ps-header - make a PostScript header page on stdout # Installed in /usr/local/libexec/make-ps-header # # # These are PostScript units (72 to the inch). Modify for A4 or # whatever size paper you are using: # page_width=612 page_height=792 border=72 # # Check arguments # if [ $# -ne 3 ]; then echo "Usage: `basename $0` " 1>&2 exit 1 fi # # Save these, mostly for readability in the PostScript, below. # user=$1 host=$2 job=$3 date=`date` # # Send the PostScript code to stdout. # exec cat < そして, 変換フィルタやテキストフィルタがそれぞれ, 最初にこのス クリプトを起動することで, ヘッダページが出力され, それから, ユー ザのジョブの印字をおこないます. 次に, このドキュメントの始めのほう で紹介した DVI 変換フィルタを, ヘッダページを印字するように変 更したものを示します. #!/bin/sh # # psdf - DVI to PostScript printer filter # Installed in /usr/local/libexec/psdf # # Invoked by lpd when user runs lpr -d # orig_args="$@" fail() { echo "$@" 1>&2 exit 2 } while getopts "x:y:n:h:" option; do case $option in x|y) ;; # Ignore n) login=$OPTARG ;; h) host=$OPTARG ;; *) echo "LPD started `basename $0` wrong." 1>&2 exit 2 ;; esac done [ "$login" ] || fail "No login name" [ "$host" ] || fail "No host name" ( /usr/local/libexec/make-ps-header $login $host "DVI File" /usr/local/bin/dvips -f ) | eval /usr/local/libexec/lprps $orig_args このフィルタがユーザ名やホスト名を決定するために引数リストをど のように解析しなくてはならないかという点に注意してください. こ の解析方法は他の変換フィルタに対しても同様です. しかしながら, テキストフィルタについては, 引数の設定が少し異なっています (こ れについては, 「」をご覧ください). 前述の通り, 上記の手法は, 極めて単純なのにも関らず, 」で紹介したトリックを使う必要があります. すな わち, LPD が生成するヘッダページの解析をおこない, PostScript 版のヘッダページを出力させる出力フィルタを作るのです. この場 合, ユーザが リモートプリンタからの出力

FreeBSD では, ネットワーク越しの印字, すなわち, ジョブをリ モートプリンタに送ることをサポートしています. リモートプリンタ からの出力をするには, 一般に, 次の2つを参照してください. リモートホストに接続されたプリンタにアクセスする方 法. プリンタがあるホストのシリアル, または, パラレルイ ンタフェースに接続されている場合, ネットワーク上の他の ホストからこのプリンタにアクセスできるように LPD を設 定します. 「」でどのよう にするかを説明します. ネットワークに直接接続されているプリンタにアクセ スする方法. プリンタに, 旧来のシリアル, または, パラレ ルインタフェースに加えて (もしくは, これらに代わって) ネッ トワーク用のインタフェースがある場合. そのようなプリン タは次のように動作するでしょう. そのプリンタが LPD のプロトコルを理解でき, リモー トホストからのジョブをキューに入れることさえできる場合. この場合, プリンタは, LPD が起動している一般のホスト のように振る舞います. そのようなプリンタを設定するため に, 「」と同様の手 順をおこなってください. そのプリンタが, データストリームによるネットワー ク接続をサポートしている場合. この場合, ネットワーク上 の1つのホストとしてプリンタを「接続」します. このホス トは, ジョブをスプーリングする責任を負い, スプーリング されたジョブはプリンタに送られます. そのようなプリンタ をインストールするためのいくつかの提案が「」にあります. リモートホストに接続されたプリンタ

LPD スプーリングシステムでは LPD (または LPD 互換のシス テム) が起動している他のホストへジョブを送る機能が始めからサポー トされています. この機能により, あるホストに接続されたプリンタ へ, 他のホストからアクセスできるようになります. また, LPD プ ロトコルを理解するネットワークインタフェースを持ったプリンタに 対しても, この機能は働きます. リモートプリンタへの出力を許可するためには, 最初に, あるホスト (これを, 」に書かれた簡単なプリンタの設定をおこなってください. 必要ならば, 「」にあ る, 更に進んだ設定をおこなってください. そして, そのプリンタをテス トしてうまく動作することを確認し, LPD に許可した機能がうまく働 くかどうかを見てください. LPD 互換のネットワークインタフェースを持つプリンタを使用してい る場合は, そのプリンタ自身が以下で説明する/etc/printcap ファイルに次にあげるエント リを作ります. 名前のエントリ. どんな名前でもよいのですが, 簡単 のため, 多分, プリンタホストで設定されたプリンタ名や別 名と同じものを使いたいと思うでしょう. スプーリングディレクトリを作成し, これで終わりです. 変換フィルタやページの大きさやその他の事項を /etc/printcap に加える必要はありません. 次に, リモートホストに接続されたプリンタで印字するための設定例 を示します. ホスト rose には2台のプリンタ /etc/printcap を示します (このファイルは, 「」で参照することができます). このファイルには, 既に, プリンタ # # /etc/printcap for host orchid - added (remote) printers on rose # # # teak is local; it is connected directly to orchid: # teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\ :lp=/dev/lpt0:sd=/var/spool/lpd/teak:mx#0:\ :if=/usr/local/libexec/ifhp:\ :vf=/usr/local/libexec/vfhp:\ :of=/usr/local/libexec/ofhp: # # rattan is connected to rose; send jobs for rattan to rose: # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :lp=:rm=rose:rp=rattan:sd=/var/spool/lpd/rattan: # # bamboo is connected to rose as well: # bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :lp=:rm=rose:rp=bamboo:sd=/var/spool/lpd/bamboo: orchid で必要となる作業はスプーリングディレクトリを作ることだ けです. mkdir -p /var/spool/lpd/rattan /var/spool/lpd/bamboo chmod 770 /var/spool/lpd/rattan /var/spool/lpd/bamboo chown daemon.daemon /var/spool/lpd/rattan /var/spool/lpd/bamboo これで, orchid のユーザが lpr -P bamboo -d sushi-review.dvi すると, orchid の LPD システムは, ジョブをスプーリングディレ クトリ /var/spool/lpd/bamboo にコピーし, これが DVI ファイルを印字するジョブであることを記録します. ホスト rose の ネットワークにおけるデータストリームのインタ フェースを持つプリンタ

プリンタのネットワークインタフェースカードは, 2種類に分 類することができます. 1つはスプーラをエミュレートするもの (高価) で, もう1つはシリアルやパラレルポートを使うようにプリンタにデー タを送ることができるだけのもの (安価) です. この節では, 後者の使 い方を説明します. 前者のプリンタは, 前節「」 の方法が適用できます. /etc/printcap ファイルでは, シリアルかパラレルのイン タフェースのどちらを使うのか, そして, (シリアルインタフェース を使う場合) そのボーレートはいくらであるか, フロー制御は使うのか, タブのための遅延を加えるのか, 改行文字を変換するかなどの指定を おこなうことができます. しかし, TCP/IP や他のネットワークポートか らデータを受け取るプリンタを接続するための指定をおこなうことはでき ません. ネットワーク接続されたプリンタにデータを送るためには, テキスト フィルタと変換フィルタから呼び出すことができる通信プログラムを 開発する必要があります. 以下に, そのようなプログラムの例を示し ます. スクリプト #!/usr/bin/perl # # netprint - Text filter for printer attached to network # Installed in /usr/local/libexec/netprint # $#ARGV eq 1 || die "Usage: $0 "; $printer_host = $ARGV[0]; $printer_port = $ARGV[1]; require 'sys/socket.ph'; ($ignore, $ignore, $protocol) = getprotobyname('tcp'); ($ignore, $ignore, $ignore, $ignore, $address) = gethostbyname($printer_host); $sockaddr = pack('S n a4 x8', &AF_INET, $printer_port, $address); socket(PRINTER, &PF_INET, &SOCK_STREAM, $protocol) || die "Can't create TCP/IP stream socket: $!"; connect(PRINTER, $sockaddr) || die "Can't contact $printer_host: $!"; while () { print PRINTER; } exit 0; このスクリプトは, 様々なフィルタが利用することができます. 仮に, Diablo 750-N ラインプリンタを持っており, これがネットワークに 接続されているとしましょう. プリンタはポート番号5100にて印字す るデータを受け取ります. プリンタのホスト名は scrivener としま す. このとき, このプリンタのテキストフィルタは次のようになりま す. #!/bin/sh # # diablo-if-net - Text filter for Diablo printer `scrivener' listening # on port 5100. Installed in /usr/local/libexec/diablo-if-net # exec /usr/libexec/lpr/lpf "$@" | /usr/local/libexec/netprint scrivener 5100 プリンタの利用に制約を与える

本節では, プリンタの利用に制約を与えるための情報を記して います. LPD システムでは, プリンタ (ローカル, リモートのいずれ に接続されていても) にアクセスできる人を制限する機能, 複数部の コピーの印字の可否を制御する機能, ジョブのサイズの最大値やプリ ンタキューに入るジョブの最大個数を制御する機能を提供しています. 複数部のコピーの印字を制限する

LPD システムではユーザが複数部のコピーの印字を簡単におこなう 機能を提供しています. ユーザが, (例えば) /etc/printcap ファイルに lpr: multiple copies are not allowed リモートホストからプリンタをアクセスできる設定にしている場合 (この 設定については, 「」をご覧ください), その リモートホストの /etc/printcap にも同じように /etc/printcap ファ イルは, ホスト rose のものです. プリンタ # # /etc/printcap for host rose - restrict multiple copies on bamboo # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:sc:\ :lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf: さらに, orchid の /etc/printcap にも # # /etc/printcap for host orchid - no multiple copies for local # printer teak or remote printer bamboo teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\ :lp=/dev/lpt0:sd=/var/spool/lpd/teak:mx#0:sc:\ :if=/usr/local/libexec/ifhp:\ :vf=/usr/local/libexec/vfhp:\ :of=/usr/local/libexec/ofhp: rattan|line|diablo|lp|Diablo 630 Line Printer:\ :lp=:rm=rose:rp=rattan:sd=/var/spool/lpd/rattan: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :lp=:rm=rose:rp=bamboo:sd=/var/spool/lpd/bamboo:sc: lpr forsale.sign forsale.sign forsale.sign forsale.sign forsale.sign このような悪用を防ぐ方法は (その指示を無視することも含めて) たく さんあります. 各自で調べてみてください. プリンタを使用できる人を限定する

それぞれのプリンタを使用できる人を限定するには, UNIX の グループ権限のメカニズムを利用し, さらに, /etc/printcap で lpr: Not a member of the restricted group 」をご覧ください), かつ, そ のホストでもプリンタを使用できる人を限定するのが妥当であると思 う場合は, そのホストの /etc/printcap にも /etc/printcap を示します. # # /etc/printcap for host rose - restricted group for bamboo # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:sc:rg=artists:\ :lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf: これ以外の /etc/printcap ファイル (ホスト orchidのもの) はそのままにしておくことにします. もちろん, orchid のユーザは 全員 入力可能なジョブのサイズを制限する

たくさんのユーザからプリンタが利用される場合には, 多分, ユーザが印字要求を出すことができるファイルのサイズに上限値を置 く必要が生じるでしょう. 結局のところ, スプーリングディレクトリ が置かれているファイルシステムの空き容量がその上限値になる訳で すが, あるユーザがこれを独占的に使用すること避けるために, 他ユー ザからのジョブ用の空き容量を確保する必要もあります. LPD では, # # /etc/printcap for host rose # # # No limit on job size: # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple: # # Limit of five megabytes: # bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:sc:rg=artists:mx#5000:\ :lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf: この場合もそうですが, この制限はローカル (ホスト rose) のユーザ のみに適用されます. リモートホストからプリンタを利用できるよう に設定している場合は, そのリモートホストのユーザはこの制限を受 けません. これらのユーザにも制限を加える場合は, リモートホスト の /etc/printcap の 」を参照してください. リモートホストに接続されたプリンタへのジョブのサイズを制限する 特別な方法は他にもあります. これについては, 「」を参照してください. リモートホストからのプリンタの利用を制限する

LPD スプーリングシステムでは, リモートホストから要求され たジョブの印字を制限するための方法がいくつか提供されています. /etc/hosts.equiv と /etc/hosts.lpd によって制御することができます. LPD では, あるホストから印字の要求がきたとき, このホス トの名前がこれら2つのファイルのどちらかに含まれている かどうかを調べます. これが含まれていない場合は, LPD はこの要求を拒否します. これらのファイルの形式は単純です. 各行にホストの名前を 1つずつ書いていきます. ファイル /etc/hosts.equiv の方は ruserok(3) プロトコル でも利用され, /etc/hosts.equiv の記述は慎重におこないましょう. 例として, 以下にホスト rose の /etc/hosts.lpd を示します. orchid violet madrigal.fishbaum.de この例では, rose はホスト orchid, violet, そして madrigal.fishbaum.de からの要求を受け付けることになり ます. その他のホストが rose の LPD にアクセスしようと しても, LPD はこれを拒否します (訳注:拒否されるのは, そのホストが /etc/hosts.equiv にも含まれてい ない場合です). /etc/printcap を調べてみましょ う. 以下に, bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:sc:rg=artists:mx#5000:\ :lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:mx#5000:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf: スプーリングディレクトリは echo 6144 > /var/spool/lpd/bamboo/minfree /etc/printcap の /usr/bin/false などを指定 して, これらのユーザのアカウントはプリンタ用の「形式的 な」ものとします. プリンタの利用に対する課金

という訳で, 印字するためには料金をとることが必要です. 取ら ない理由などありましょうか. 紙やインクにはお金がかかります. そ して, プリンタの維持費もかかります. プリンタには可動部分が搭載 されており, これらの部分は壊れやすいという傾向があります. プリ ンタや, その利用形態, 維持費について調査をし, 1ページ (1フィー ト, 1メートルなど) 当たりにかかるコストを調べておいてください. これに基づき, プリンタの利用に対する課金を, 実際に, どのように 始めればよいのでしょうか. さて, 残念ながら, この部分に関しては LPD スプーリングシステム はほとんど役に立ちません. 課金は使用しているプリンタの種類, 印 字するもののファイルの形式, プリンタの利用に対する課金での」をご覧く ださい. 一般に, 課金方式には次の2つがあります. LPD スプーリングシステムでは, 両方式を簡単にですがサポー トしています. これは, (ほとんどの場合で) 印字作業をフィ ルタがおこなっていたように, 課金作業もこのためのコードも用 意することで実現されています. しかし, 明るい面もありま す. それは, 課金方式に関して, 非常に大きな柔軟性が与え られたということです. 例えば, 「定期的に課金する方法」 か, 「利用毎に課金する方法」のどちらかを選びまず, そし て, どんな情報 (ユーザ名, ホスト名, ジョブのタイプ, 印 字された頁数, 使用した紙の大きさ, 印字をするために要した 時間など) をログに記録するかを決めます. 以上のことをおこな うには, 上記の情報を保持するために, フィルタを変更しな くてはなりません. 手軽なプリンタ課金方法

FreeBSD には, 「定期的に課金する方法」による課金をすぐに 設定できるように, 2個のプログラムを添付しています. そ の内の1つはテキストフィルタ 」をご覧ください. もう1つは, 」で述べたように, LPD では テキストフィルタや変換フィルタを起動しますが, そのコマ ンドラインで使用している課金データファイルの名前が指定 されます. 両フィルタはこの引数を使って, どの課金データ ファイルのエントリに書き込めばよいのかを知ることができ ます. このファイルの名前は /etc/printcap 中の 2.00 rose:andy 3.00 rose:kelly 3.00 orchid:mary 5.00 orchid:mary 2.00 orchid:zhang 課金データファイルはプリンタ毎に分けて作るべきです. こ れは, /etc/printcap 中の Login pages/feet runs price orchid:kelly 5.00 1 $ 0.10 orchid:mary 31.00 3 $ 0.62 orchid:zhang 9.00 1 $ 0.18 rose:andy 2.00 1 $ 0.04 rose:kelly 177.00 104 $ 3.54 rose:mary 87.00 32 $ 1.74 rose:root 26.00 12 $ 0.52 total 337.00 154 $ 6.74 /etc/printcap の /etc/printcap の Login pages/feet runs price andy 2.00 1 $ 0.04 kelly 182.00 105 $ 3.64 mary 118.00 35 $ 2.36 root 26.00 12 $ 0.52 zhang 9.00 1 $ 0.18 total 337.00 154 $ 6.74 課金額を決めるために, /etc/printcap ファ イルの pac -p1.50 このオプションを使うと, 実際の課金額を集計することができます. 最後に, 印字されたページ数をどのように数えるか?

課金を, リモートホストからの印字でさえも, 正確におこなうため には, ジョブで使用された紙が何ページであるかを特定でき る必要があります. このことは, プリンタ利用に対する課金 をおこなう上の根本的な問題です. プレインテキストのジョブの場合, 問題を解決するのはさほ ど難しくはありません. ジョブが何行であったかを数え, プ リンタがサポートしている紙1ページに印字できる最大の行 数と比較すればよいのです. 重ね打ちするために利用される ファイル中のバックスペース文字や, 物理的に複数の行に渡 る長い論理行に対する取り扱いを忘れずにおこなってください. (「」で紹介した) テキストフィルタ 標準スプーラの代替品

このマニュアルを最初から通読されている方ならば, ここまでで, FreeBSD 付属の LPD スプーリングシステムに関して知っておくべき ことすべてを学ばれたことと思います. 多分, このシステムに あるたくさんの欠点について認識できたことでしょう. すると, 「(FreeBSD 上で動作する) スプーリングシステムには他にどのような ものがあるのか」という疑問が自然と湧いてきます. 残念ながら, 著者は代替のスプーラを 」です. 「」にもあります. PLP は BSD LPD スプーラと極めて似ていますが, 以下のも のを含むホストの機能が自慢です. ネットワークサポートの強化. ネットワーク接続され るプリンタのサポートや NIS で管理可能な printcap ファ イル, NFS マウントされるスプーリングディレクトリの機 能が組み込まれています. 洗練されたなキュー管理. 1つのキューで複数のプリン タに対応可能. キュー間でジョブを転送したり, キューのリ ダイレクトができます. リモートプリンタの制御機能 ジョブの優先順位付け 拡張性のあるセキュリティとアクセスオプション 」です. 謝辞

このドキュメントの開発の手助けをして頂いた以下の方々に感謝の 意を表わしたいと思います. diff --git a/ja_JP.EUC/handbook/quotas.sgml b/ja_JP.EUC/handbook/quotas.sgml index 9fc117c6a4..6019f733e9 100644 --- a/ja_JP.EUC/handbook/quotas.sgml +++ b/ja_JP.EUC/handbook/quotas.sgml @@ -1,227 +1,226 @@ + + + + ディスク クォータ

原作: &a.mpp; 26 February 1996 .

訳者: &a.mihoko; 6 September 1996 . クォータシステムは、オペレーティングシステムのオプション機能で、 各ファイルシステム上で ユーザやグループのメンバが使用するディスク スペースの総量を規制したり、作成できるファイルの個数を制限したりす ることができます。 この機能は、各ユーザ、各グループごとに使用できる資源の総量を制限で きるようなタイムシェアリングシステム上でもっともよく使用されていま す。これは、一人のユーザが、使用可能な全てのディスクスペースを使い きってしまうことを防止できます。 ディスククォータを使用するための設定

ディスククォータを使用しようとする前に、あなたが使用しているカー ネルで、クォータが組み込まれているかどうかを確認する必要があります。 クォータを使用できるカーネルを構築するためには、カーネルコンフィギュ レーションファイルに、次の行を追加してください: options QUOTA 標準のGENERIC カーネルでは、この機能は有効になっていません。 したがって、ディスククォータを使用するためには、 カーネルをコンフィグレーションして構築しなおし、そのカーネ ルをインストールしなければいけません。カーネルの構築方法について の詳細情報は、 を参照してください。

次に、ファイル /etc/sysconfig の中で、ディスククォー タ機能を、使用可能に設定する必要があります。 そのためには、以下の行を変更します: quotas=NO を次のように: quotas=YES

最後に、各ファイルシステム毎にディスククォータを設定する ために、ファイル /etc/fstab を編集する必要があります。 全てのファイルシステムに対して、ユーザ又はグループのいずれかのクォー タを設定することも、ユーザとグループの両方のクォータを設定すること もできます。

ファイルシステム上で、ユーザ毎のクォータを設定するためには、 userquota オプションを、ファイル /etc/fstab の中 で、クォータを設定したいファイルシステムのエントリののオプションフィー ルドに追加してください。 例えば: /dev/sd1s2g /home ufs rw,userquota 1 2

同様に、グループのクォータを設定するためには、 groupquota オプションを userquota の代わりに使用 してください。ユーザとグループの両方のクォータを設定するためには、 次のようにエントリを変更してください: /dev/sd1s2g /home ufs rw,userquota,groupquota 1 2

デフォルトでは、クォータファイルは ファイルシステムの root ディ レクトリ上に、ユーザとグループのクォータに対して それぞれ quota.user と quota.group という名前で置いてあり ます。詳細情報は、man fstab を御覧ください。 man ページには、クォータファイルを別な場所に置くことができると書い てありますが、さまざまな クォータユーティリティのうち、この機能を 適切に処理できていないものがあるので、クォータファイルをデフォルト の場所以外に置くことは勧められません。

ここまで準備ができたら、新しいカーネルを使って、システムを立ち 上げ直してください。 /etc/rc ファイルが、自動的に適切なコマンドを起動してくれ 、あなたが /etc/fstab ファイルで使用可能にした全てのクォー タに対して、初期クォータファイルを作成してくれます。 したがって、手動で サイズ 0 のクォータファイルを作成する必要はあり ません。

通常の作業の流れでは、手動で quotacheck、 quotaon、または quotaoff コマンドを起動すべきで はありません。しかしながら、それらの作業について詳しく知りたい場合に は、man ページを御覧ください。 クォータ制限の設定

一旦システムのクォータを有効に設定したら、 本当にクォータが使用可能になっていることを確かめてください。 これを簡単に確かめるには、quota -v コマンドを実行してみて ください。ディスク使用量の総計と、クォータが設定されている各ファイ ルシステム毎の現在のクォータ制限が表示されます。

さてこれで、edquota コマンドによって、クォータ制限をか ける準備ができました。

ユーザまたはグループが使用できるディスクスペースの総計や、作成 することのできるファイル数に制限をかけるためのオプションがいくつか あります。 ディスクスペース容量規制 (ブロッククォータ) または ファイ ル数制限 (iノードクォータ) またはその両方を行うことができます。 これらの個々の制限は、二つのカテゴリ、すなわち ハード制限とソ フト制限、でもっと細かく分類できます。

ハード制限は越えることができません。ユーザがハード制限に到達す ると、該当するファイルシステム上でディスクスペースを確保することが できなくなります。 例えば、もしユーザがファイルシステム上で 500 ブ ロックのハード的制限をされていて、かつ、現在、490 ブロック使用して いたとすると、ユーザはあと 10 ブロックしか確保できません。 １１ブロック目を確保しようとすると、失敗します。

一方、ソフト制限は、定められたある一定の期間以内ならば制限を越 えることができます。この一定期間は、猶予期間と呼ばれています。 猶予期間のデフォルトは 1週間です。もし、ユーザが猶予期間を過ぎても ソフト制限を越えて使用し続けていた場合には、ソフト制限はハード制限 に切り替わり、もはやこれ以上は、ディスクスペースを確保できなくなり ます。ユーザのディスク使用量がソフト制限以下に戻った時に、猶予期間 がリセットされます。

以下は、edquota コマンドを実行した時の出力例です。 edquota コマンドが起動されると、EDITOR 環境変数 で定義されたエディタ、または、EDITOR 環境変数が設定されて いない場合には vi エディタが起動され、クォータ制限を編集 することができます。 # edquota -u test Quotas for user test: /usr: blocks in use: 65, limits (soft = 50, hard = 75) inodes in use: 7, limits (soft = 50, hard = 60) /usr/var: blocks in use: 0, limits (soft = 50, hard = 75) inodes in use: 0, limits (soft = 50, hard = 60) 通常は、クォータが設定されているファイルシステム毎に2行の表示が 行われます。1行は、ブロック制限に関する情報で、もう1行は、i ノード 制限に関する情報です。クォータ制限の値を変更したい値に書き換えてく ださい。例えば、ユーザのブロック制限を、50 ブロックまでのソ フト制限と 75 ブロックまでのハード制限から、500 ブロックまでのソフ ト制限と 600 ブロックまでのハード制限にしたい場合は、 次のように書き換えます: /usr: blocks in use: 65, limits (soft = 50, hard = 75) を次のように: /usr: blocks in use: 65, limits (soft = 500, hard = 600) 新しいクォータ制限は、エディタを終了した時に置き換えられます。

uid の範囲によってクォータを設定する個とも可能です。 そのためには edquota コマンドで、-p オプションを 使用します。まずはじめに、かけたいクォータ制限を、一人のユーザに対 して設定します。それから次のコマンドを実行します edquota -p protouser startuid-enduid。 例えば、もし、ユーザ test がクォータ制限をかけられていた とすると、次のコマンドは、同じ制限を、uid 10,000 から 19,999 まで のユーザにかけることができます: edquota -p test 10000-19999

uid の範囲によって制限をかけることができる機能は、2.1 がリリー スされたあとに追加されました。もし、2.1 のシステム上で、この機能を 必要とする場合には、新しい edquota を入手する必要があります。

詳細情報は man edquota を御覧ください。 クォータ制限およびディスク使用状況のチェック

クォータ制限およびディスク使用状況をチェックするには、 quota または repquota コマンドを使用することがで きます。quota コマンドは、各ユーザ、各グループ毎のクォー タ制限およびディスク使用状況をチェックすることができます。 スーパーユーザだけが、他のユーザまたは自分が所属していないグループに 関するクォータ制限とディスク使用状況を調べることができます。 repquota コマンドは、クォータが設定されているファイルシス テムに対する、全てのクォータ制限およびディスク使用状況の総計を表示 します。

以下は、2つのファイルシステム上でクォータ制限がかけられているユー ザに対して quota -v コマンドを実行した出力結果の例です。 Disk quotas for user test (uid 1002): Filesystem blocks quota limit grace files quota limit grace /usr 65* 50 75 5days 7 50 60 /usr/var 0 50 75 0 50 60 上の例では、/usr ファイルシステム上で、このユーザは現在 50 ブロックまでのソフト制限を 15 ブロック超過して使用しており、 残り 5 日間の猶予期間を設定されています。 アスタリスク (*) は、ユーザが現在クォータ制限を越えていることを示 しています。

通常、ユーザがディスクスペースを全く使用していないファイルシス テムは、 たとえ そのファイルシステムにクォータ制限が設定されていた としても、quota コマンドによる出力では表示されません。 -v オプションを付けると、上の例の /usr/var ファ イルシステムのように、これらのファイルシステムも表示します。 * NFS ファイルシステム上でのクォータ

このセクションはまだ作成中です。 diff --git a/ja_JP.EUC/handbook/relnotes.sgml b/ja_JP.EUC/handbook/relnotes.sgml index a426f90f4b..53fde571b5 100644 --- a/ja_JP.EUC/handbook/relnotes.sgml +++ b/ja_JP.EUC/handbook/relnotes.sgml @@ -1,575 +1,575 @@ - + 現在のリリースについて

FreeBSD は自由に利用でき Intel i386/i486/Pentium/PentiumPro (とその互換 CPU) の PCで動作する, 4.4BSD-Lite ベースの全ソー スつきのリリースです. これはもともとカリフォルニア大学バーク レイ校 CSRGグループのソフトウェアがベースとなっており, NetBSD, 386BSD, そして Free Software Foundation のソフトウェ アなどにより拡張されています. 95年1月の FreeBSD 2.0 のリリースからみると, FreeBSD は性能, 機能, 安定性の面で劇的に改善されました. もっとも大きな変化は VM システムに おける改良で, 統合化された VM/file バッファキャッシュを用いる ことで性能を向上させながらも FreeBSD のメモリの使用量を減らすことが できたことです. おかげで, 最低 5MB メモリという制約上でも動作する ようになりました. その他の拡張としては NIS のクライアントとサーバの 完全サポート, トランザクション TCP のサポート, ダイヤルオンデマンド PPP, 改良 SCSI サブシステム, ISDN の初期サポート, FDDI や Fast Ethernet (100Mbps) などのサポート, Adaptec 2940 (WIDE と narrow) のサポートの改良と数百件のバグの修正, などがあります. 私たちはたくさんのユーザからのコメントや提案をまじめに受け取り, 私たちが正しいと考え, かつ導入の手順が分かりやすいものを提供しようと 努力しています. この (継続的に進化する) プロセスに対するあなたの意見を 心からお待ちしています. FreeBSD では基本配布セットに加え, 移植されたソフトウェア集 として 数百の人気の高いプログラムを提供しています. 96年12月 初旬の時点で 700 以上の ports (移植ソフトウェア) が存在します. ports には http (WWW) サーバから, ゲーム, 言語, エディタまでありとあらゆるものが含まれています. portsはオリジナル ソースに対する「差分」という形で表現されており, すべての portsを 集めても 10MB程度にしかなりません. こうすることで ports の更新を 容易にし, portsに必要なディスクスペースを小さくすることができます. portsをコンパイルするには, インストールしたいと思っているプログラムの ディレクトリに移動し, ``make all'' と実行してコンパイルが成 功したら, ``make install'' とすると, あとはすべてシステムが やってくれます. どの portsもオリジナルの配布セットを動的に CDROM または近くの FTP サーバから取ってくるので, ディスクは 構築したいと思っている portsの分だけを準備しておけば十分です. ほとんどの portsは, すでにコンパイルされた状態で ``package'' として提供されており, ソースコードからコンパイルしたくない場 合, これを使うと (pkg_add というコマンドで) 簡単にインストー ルできます. FreeBSD 2.1 以降のマシンであれば, /usr/share/doc ディレクトリにインストールの手順や FreeBSD を利用する上で有用な ドキュメントがたくさんあります. これらのドキュメントは, HTML ブラウザを使って, 以下の URL から 参照することができます. FreeBSD ハンドブック (英文オリジナル) FreeBSD に関する FAQ また, にはマスタ (かなり頻繁に更新されます) がありますので, こちらも参照してください. 合衆国の輸出規制のため, FreeBSD のコア配布セットには DES のコードは 含まれていません. 合衆国国内に限り, DES を使うプログラムなどが, コア配布セットに加えるパッケージとして提供されています. 誰でも使えるパッケージは, 別途, 合衆国国外で提供されています. 合衆国国外からも自由に取得可能な DES の配布セットに関する 詳細は, にあります. FreeBSD 上で必要とされるセキュリティがパスワードだけであり, Sun や DEC などの別のホストから暗号化されたパスワードをコピーする必要が ないのであれば, FreeBSD の MD5 ベースのセキュリティで十分です. この標準のセキュリティモデルは DES よりも適していると私たちは思って いますし, また, やっかいな輸出規制にもひっかかることはありません. あなたが合衆国国外にいるなら (あるいは国内にいても) 一度試してみて ください! Since our first release of FreeBSD 1.0 nearly two years ago, FreeBSD has changed dramatically. Since release 2.0, FreeBSD has been based on the Berkeley 4.4BSD-Lite code rather than the Net2 code used for previous versions. In addition to clearing the legal issues that surrounded the Net2 code, the port to 4.4 has also brought in numerous new features, filesystems and enhanced driver support. Since our release of FreeBSD 2.0 in November of 1994, the performance, feature set, and stability of FreeBSD has improved dramatically. The largest change is a revamped Virtual Memory (VM) system with a merged virtual memory and file buffer cache. This increases performance while reducing FreeBSD's memory footprint, making a system with 4 megabytes of RAM a more acceptable minimum. Other enhancements include full NIS client and server support, transaction TCP support, dial on demand PPP, an improved SCSI subsystem, early support for ISDN, support for FDDI and 100Mbit Fast Ethernet adapters, improved support for the Adaptec 2940 and hundreds of bug fixes. We have also taken the comments and suggestions of many of our users to heart and have attempted to provide what we hope is a more sane and easily understood installation process. Your feedback on this constantly evolving process is especially welcome! In addition to the base distributions, FreeBSD offers a new ported software collection with some 270 commonly sought-after programs. The list of ports ranges from World Wide Web (http) servers, to games, languages, editors and almost everything in between. The entire ports collection requires only 10MB of storage because each port contains only the changes required for the source code to compile on FreeBSD and the information necessary to automatically retrieve the original sources. The original distribution for each port you build is automatically retrieved off of CD-ROM or a via anonymous ftp, so you need only enough disk space to build the ports you want. Each port is also provided as a pre-compiled package which can be installed with the pkg_add(1) command for those who do not wish to compile their own ports from source. See for a more complete description. The core of FreeBSD does not contain DES code which would inhibit its being exported outside the United States. An add-on package, for use only in the United States, contains the programs that normally use DES. The auxiliary packages provided separately can be used by anyone. A freely exportable European distribution of DES for our non-U.S. users also exists and is described in the . If password security for FreeBSD is all you need, and you have no requirement for copying encrypted passwords from other hosts using DES into FreeBSD password entries, then FreeBSD's MD5 based security may be all you require. We feel that our default security model is more than a match for DES, and without any messy export issues to deal with. FreeBSD 2.0.5 represents the culmination of 2 years of work and many thousands of man hours put in by an international development team. We hope you enjoy it! New feature highlights

The following features were added or substantially improved between the release of 2.0 and this 2.0.5 release. In order to facilitate better communication, the person, or persons, responsible for each enhancement is noted. Any questions regarding the new functionality should be directed to them first. Kernel

Merged VM-File Buffer Cache A merged VM/buffer cache design greatly enhances overall system performance and makes it possible to do a number of more optimal memory allocation strategies that were not possible before. Owner: &a.davidg; and &a.dyson; Network PCB hash optimization For systems with a great number of active TCP connections (WEB and ftp servers, for example), this greatly speeds up the lookup time required to match an incoming packet up to its associated connection. Owner: &a.davidg; Name cache optimization The name-cache would cache all files of the same name to the same bucket, which would put for instance all ".." entries in the same bucket. We added the parent directory version to frustrate the hash, and improved the management of the cache in various other ways while we were at it. Owner: &a.phk; and &a.davidg; Less restrictive swap-spaces The need to compile the names of the swap devices into the kernel has been removed. Now swapon(8) will accept any block devices, up to the maximum number of swap devices configured in the kernel. Owner: &a.phk; and &a.davidg; Hard Wired SCSI Devices Prior to 2.0.5, FreeBSD performed dynamic assignment of unit numbers to SCSI devices as they were probed, allowing a SCSI device failure to possibly change unit number assignment. This could cause filesystems other disks in the system to be incorrectly mounted, or not mounted at all. Hard wiring allows static allocation of unit numbers (and hence device names) to scsi devices based on SCSI ID and bus. SCSI configuration occurs in the kernel config file. Samples of the configuration syntax can be found in the scsi(4) man page or the LINT kernel config file. Owner: &a.dufault; Sources involved: sys/scsi/* usr.sbin/config/* Slice Support FreeBSD now supports a slice abstraction which enhances FreeBSD's ability to share disks with other operating systems. This support will allow FreeBSD to inhabit DOS extended partitions. Owner: &a.bde; Sources involved: sys/disklabel.h sys/diskslice.h sys/dkbad.h kern/subr_diskslice.c kern/subr_dkbad.c i386/isa/diskslice_machdep.c i386/isa/wd.c scsi/sd.c dev/vn/vn.c Support for Ontrack Disk Manager Version 6.0 Support has been added for disks which use Ontrack Disk Manager. The fdisk program does not know about it however, so make all changes using the install program on the boot.flp or the Ontrack Disk Manager tool under MS-DOS. Owner: &a.phk; Bad144 is back and working Bad144 works again, though the semantics are slightly different than before in that the bad-spots are kept relative to the slice rather than absolute on the disk. Owner: &a.bde; and &a.phk; New device support SCSI and CDROM devices

Matsushita/Panasonic (Creative) CD-ROM driver The Matsushita/Panasonic CR-562 and CR-563 drives are now supported when connected to a Sound Blaster or 100% compatible host adapter. Up to four host adapters are supported for a total of 16 CD-ROM drives. The audio functions are supported with the Karoke variable speed playback. Owner: &a.uhclem; Sources involved: isa/matcd Adaptec 2742/2842/2940 SCSI driver The original 274x/284x driver has evolved considerably since the 2.0 release of FreeBSD. We now offer full support for the 2940 series as well as the Wide models of these cards. The arbitration bug that caused problems with fast devices has been corrected and experimental tagged queuing support has been added (kernel option AHC_TAGENABLE). John Aycock has also released the sequencer code under a Berkeley style copyright making the driver entirely clean of the GPL. Owner: &a.gibbs; Sources involved: isa/aic7770.c pci/aic7870.c i386/scsi/* sys/dev/aic7xxx/* NCR5380/NCR53400 SCSI (ProAudio Spectrum) driver Owner: &a.core; Submitted by: Serge Vakulenko (vak@cronyx.ru) Sources involved: isa/ncr5380.c Sony CDROM driver Owner: &a.core; Submitted by: Mikael Hybsch (micke@dynas.se) Sources involved: isa/scd.c Serial devices

SDL Communications Riscom/8 Serial Board Driver Owner: &a.ache; Sources involved: isa/rc.c isa/rcreg.h Cyclades Cyclom-y Serial Board Driver Owner: &a.bde; Submitted by: Andrew Werple (andrew@werple.apana.org.au) and Heikki Suonsivu (hsu@cs.hut.fi) Obtained from: NetBSD Sources involved: isa/cy.c Cronyx/Sigma sync/async serial driver Owner: &a.core; Submitted by: Serge Vakulenko Sources involved: isa/cronyx.c Networking

Diskless booting Diskless booting in 2.0.5 is much improved over previous releases. The boot program is in src/sys/i386/boot/netboot, and can be run from an MS-DOS system or burned into an EPROM. WD, SMC, 3COM and Novell ethernet cards are currently supported. Local swapping is also supported. DEC DC21140 Fast Ethernet driver This driver supports any of the numerous NICs using the DC21140 chipset including the 100Mb DEC DE-500-XA and SMC 9332. Owner: &a.core; Submitted by: Matt Thomas (thomas@lkg.dec.com) Sources involved: pci/if_de.c pci/dc21040.h DEC FDDI (DEFPA/DEFEA) driver Owner: &a.core; Submitted by: Matt Thomas (thomas@lkg.dec.com) Sources involved: pci/if_pdq.c pci/pdq.c pci/pdq_os.h pci/pdqreg.h 3Com 3c505 (Etherlink/+) NIC driver Owner: &a.core; Submitted by: Dean Huxley (dean@fsa.ca) Obtained from: NetBSD Sources involved: isa/if_eg.c Fujitsu MB86960A family of NICs driver Owner: &a.core; Submitted by: M.S. (seki@sysrap.cs.fujitsu.co.jp) Sources involved: isa/if_fe.c Intel EtherExpress driver Owner: Rodney W. Grimes (rgrimes@FreeBSD.org) Sources involved: isa/if_ix.c isa/if_ixreg.h 3Com 3c589 driver Owner: &a.core; Submitted by: "HOSOKAWA Tatsumi" (hosokawa@mt.cs.keio.ac.jp), Seiji Murata (seiji@mt.cs.keio.ac.jp) and Noriyuki Takahashi (hor@aecl.ntt.jp) Sources involved: isa/if_zp.c IBM Credit Card Adapter driver Owner: &a.core; Submitted by: "HOSOKAWA Tatsumi" (hosokawa@mt.cs.keio.ac.jp), Sources involved: isa/pcic.c isa/pcic.h EDSS1 and 1TR6 ISDN interface driver Owner: &a.core; Submitted by: Dietmar Friede (dfriede@drnhh.neuhaus.de) and Juergen Krause (jkr@saarlink.de) Sources involved: gnu/isdn/* Miscellaneous drivers

Joystick driver Owner: &a.jmz; Sources involved: isa/joy.c National Instruments ``LabPC'' driver Owner: &a.dufault; Sources involved: isa/labpc.c WD7000 driver Owner: Olof Johansson (offe@ludd.luth.se) Pcvt Console driver Owner: &a.joerg; Submitted by: &a.hm; Sources involved: isa/pcvt/* BSD-audio emulator for VAT driver Owner: Amancio Hasty (ahasty@FreeBSD.org) and &a.pst; Sources involved: isa/sound/vat_audio.c isa/sound/vat_audioio.h National Instruments AT-GPIB and AT-GPIB/TNT GPIB driver Owner: &a.core; Submitted by: Fred Cawthorne (fcawth@delphi.umd.edu) Sources involved: isa/gpib.c isa/gpib.h isa/gpibreg.h Genius GS-4500 hand scanner driver Owner: &a.core; Submitted by: Gunther Schadow (gusw@fub46.zedat.fu-berlin.de) Sources involved: isa/gsc.c isa/gscreg.h CORTEX-I Frame Grabber Owner: &a.core; Submitted by: Paul S. LaFollette, Jr. ( Sources involved: isa/ctx.c isa/ctxreg.h Video Spigot video capture card Owner: Jim Lowe Experimental features

UNIONFS and LFS The unionfs and LFS file systems are known to be severely broken in FreeBSD 2.0.5. This is in part due to old bugs that we have not had time to resolve yet and the need to update these file systems to deal with the new VM system. We hope to address these issues in a later release of FreeBSD. iBCS2 Support FreeBSD now supports running iBCS2 compatible binaries. Currently SCO UNIX 3.2.2 and 3.2.4, and ISC 2.2 COFF are supported. The iBCS2 emulator is in its early stages and has not been extensively tested, but it is functional. Most of SCO's 3.2.2 binaries work, as does an old INFORMIX-2.10 for SCO. Further testing is necessary to complete this project. There is also work under way for ELF and XOUT loaders, and most of the svr4 syscall wrappers are written. Owner: &a.sos; and &a.sef; Sources involved: sys/i386/ibcs2/* and misc kernel changes. ]]> diff --git a/ja_JP.EUC/handbook/routing.sgml b/ja_JP.EUC/handbook/routing.sgml index 2563f31537..94c99b61a2 100644 --- a/ja_JP.EUC/handbook/routing.sgml +++ b/ja_JP.EUC/handbook/routing.sgml @@ -1,269 +1,269 @@ - + ゲートウェイとルート

原作: &a.gryphon;.6 October 1995.

訳: &a.yuki;.6 September 1996. ある計算機が他の計算機をみつけることができるようにするには, ある 計算機から他の計算機へ, どのようにたどり着くかを適切に記述するた めの仕組みが必要です. この仕組みをルーティングと呼びます. 「ルー ト(経路)」は 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について説明する必要があります. それぞれの経路は欄に示されているように違った属性をもっています. 以下にいくつかのフラグとこれらが何を意味しているかを示します. デフォルトルート

ローカルシステムからリモートホストにコネクションを張る 必要がある場合, 既知のパスが存在するかどうかを確認するためにル ーティングテーブルをチェッ クします. 到達するためのパスを知っているサブネットの内部にリモ ートホストがある場合 (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 情報とよく似た) システムがあり, そのインターネット バックボーンへの接続点を定義しています. 「バックボーン」 とは国を越え, 世界中のインターネットのトラフィックを運ぶ主要 な信用できる幹線のことです. どのバックボーンマシンも, あるネット ワークから特定のバックボーンのマシンへ向かうトラフィックと, そのバックボーンのマシンからあなたのネットワークに届くサービス プロバイダまでのチェーンのマスタテーブルのコピーを持っていま す. あなたのサイトが接続(プロバイダからみて内側にある ことになります) したということを, プロバイダからバックボー ンサイトへ通知することはプロバイダの仕事です. これが経 路の伝搬です. トラブルシューティング

ルーティングの伝搬に問題が生じて, いくつかのサイトが 接続をおこなうことができなくなることがあります. ルーティングがどこでおかしくなっているかを明らかにするのに 最も有効なコマンドはおそらくtraceroute(8)コマンドでしょ う. このコマンドは, あなたがリモートマシンに対して接続をおこなう ことができない(例えばping(8)に失敗するような場合) 場合も, 同じように有効です. traceroute(8)コマンドは, 接続を試みているリモートホスト を引数にして実行します. 試みているパスの経由する ゲートウェイホストを表示し, 最終的には目的のホストに たどり着くか, コネクションの欠如によって終ってしまうかのどちら かになります. より詳しい情報は, tracrouteのマニュアルページをみてください. diff --git a/ja_JP.EUC/handbook/scsi.sgml b/ja_JP.EUC/handbook/scsi.sgml index cd023e21d8..d29a689254 100644 --- a/ja_JP.EUC/handbook/scsi.sgml +++ b/ja_JP.EUC/handbook/scsi.sgml @@ -1,958 +1,958 @@ - + SCSIとは?

原作:&a.wilko;. July 6, 1996.

訳: &a.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線の信号線 のバスです. (もしシングルエンドの意味が分からなくても気にするこ とはありません. このドキュメントの中にその説明があります.) よ り新しい設計では 16 bit幅で平衡信号のバスを使います. この場合, 転送速度は 20Mbytes/second まで,ケーブルの長さは 25mまで可能です. SCSI-2では追加のケーブルを使った最大32 bitのバス幅までが含まれ ます. 早くも Ultra SCSI (Fast-20とも呼ばれます) と Ultra2 (Fast-40とも 呼ばれます) が現れています. Fast-20は1秒間に 2000万回の転送 (8bit バスで20Mbyte/sec), Fast-40は1秒間に 4000万回の転送 (8bitバスで 40Mbytes/sec) をおこないます. 訳注: ここでは電気的な用語としては平衡,不平衡を用いて,バ スの名称としては基本的にはシングルエンド,ディファレンシャルとしま した. もちろん 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の構成要素

インテリジェント インタフェース

(訳注:原文では smart interface です) 先に述べたように, 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後 - 本当は電線中の信号の伝達は 光速よりも少し遅くなるのでもう少し時間がかかりますが - に帰ってきます. 10MHzのクロックは1:1のパルスだとすると幅 50nsのパルスで, 反射波がやってくる時間とそれほど変わりません. このため, 場合によっては反射波によってクロックや信号が異常 になってしまう可能性があります. ターミネータはいろいろな - 洗練されたものもそうでないもの も - 実現方法があります. もちろん,内蔵のものと外部という 区別もあります. ほとんどすべての SCSIデバイスにはいくつかの ソケットがあり,その中には抵抗ネットワーク (集合抵抗) が入っ ているものもあるかもしれません (いや,おそらく間違いなくあ るでしょう). ターミネータを デバイスから外す時は大事にしまっておいてください. SCSIの接 続の変更をしようと思った時に必要になるかもしれません. ま た, それらしい抵抗ネットワークが見つからないこともあります. この場合, SCSIデバイスは内蔵ターミネータの有効と無効を切替 えるジャンパがあります. フラットケーブルに取り付ける特別 なターミネータもあります. 他には外部コネクタのような形をし たものやケーブルのないコネクタヘッドだけのものもあります. いろいろと見られるように多くの選択があります. どのような場合に単純な抵抗 (パッシブ) ターミネータからアクティ ブターミネータへ切替えるかという問題があります.アクティブ ターミネータはいくらか精巧な回路が信号をよりきれいにするた めに入っています. 一般的に一致する意見としては, 長いバス を使ったり 高速なデバイスを使う場合はアクティブターミネー タの有効性は増加すると言えます. SCSI バスですでに問題が起 きているならアクティブターミネータを試すことを考えていいで しょう. まず借りることができないか探してみてください. ア クティブターミネータは非常に高価だそうですから. ディファレンシャルとシングルエンドバスのターミネータは互換 性がないということを覚えておいてください. これらの2つの種 類を 混在させることはできません. OK, ではあなたはターミネータをどこに入れればいいでしょうか? これは SCSIで最も多く誤解されているところです. しかし, これ は極めて単純なことです.. ここでのルールは すべての SCSI バスは 2個のターミネータをそれぞれの両端に入れるとい うことです. つまり 2個であって1個でも3個でもありませ ん. このルールを受け入れてしたがってください. そうすれば終りの ない苦しみから救われるでしょう. なぜなら間違ったターミネー ションは不可解なバグを引き起こす可能性が非常に高いから です. よく陥りやすい落し穴はマシンの内部 (フラット) ケーブルと外部 ケーブルがコントローラにつながっている場合です. よく見られ るのはコントローラのターミネータを外すのを忘れることで す. ターミネータは最後の外部デバイスで必要で, コントローラ には必要ありません! 一般的に, SCSIバスの接続の変更をする場 合はこのようなことに注意をしなければなりません. 私自身は, すべてのデバイスとコントローラのターミネータを外し ています. 2個の外部ターミネータをセントロニクスタイプ (訳注: 日本ではケーブルに対してこういう言い方はあまりしないのでは ないでしょうか) 外部ケーブルと内部フラットケーブルのコネク タの両端に接続しています. こうすることにより接続の変更はか なり簡単になります. 最近のデバイスは, ICターミネータが使われることもあります. コントロールピンにより無効/有効を設定できる特別のICがあり ます. これは物理的にデバイスから外す必要がありません. 新し いホストアダプタではセットアップツール等を使ってソフトウェ ア的に設定をおこなう場合があります. マニュアルを調べてくださ い. ターミネータの電源

ここまでの章で議論したターミネータは正常に動作するためには 電源が必要です. SCSIバス上にはこの目的のために利用される線 があります. だから特に気にする必要はないと思いますか? ところがそうではないのです. それぞれのデバイスはデバイス上 にあるターミネータソケットに電源を供給することはできま す. けれども外部ターミネータがある場合やSCSIバスにターミネー タの電源を供給するデバイスのスイッチがオフになっているよう な場合にはトラブルが起きるかもしれません. イニシエータ (ここではバスの動作を開始-initiate-させるデバ イスを指します -- 訳注: 簡単に言えばホスト側のアダプタです がSCSIの規格によれば, 例えばディスク側がコマンドを発行する ようなシステムがあってもかまわないことになっているのでこう いう言い方をしています) はターミネータ電源を供給しなければ なりません. すべてのSCSIデバイスはターミネータの電源を供給す ることができます (必ずしも供給しなければならないというわけ ではありません). スイッチがオフになっているデバイスがバス上に存在することを 許すために, ターミネータの電源はダイオードを通して供給され なければなりません. これはスイッチを切ったデバイスに電流 が逆流することを防ぐためです. 最悪の事態を避けるために, ターミネータの電源は普通はヒュー ズが入っています. 当然ヒューズは飛ぶかもしれません. この 場合でもバスが機能停止するとは限りません. 複数のデバイスが ターミネータの電源を供給しているのであれば, ヒューズが一つ 飛んでも全体の機能には影響しません. ただ一つの供給線のヒュー ズが飛んだのであれば確かに問題になるでしょう. 外部ターミネー タによっては LEDでターミネータ電源が与えられていることを示 すものもあります. 最新の設計ではある程度の時間がたつと 「リセット」され自動復 帰するヒューズが使われることもあります. デバイス アドレッシング

SCSIバスでは接続された異なるデバイスを区別して指定できなけ ればなりません. これには SCSIではターゲットIDが使われます. それぞれのデバイ スは特定のターゲットIDを持ちます. デバイスの IDはジャンパや DIPスイッチなどで設定できます. より詳しい情報はデバイスの マニュアルを見てください. 複数のデバイスを使う場合は IDの重複に気をつけてください. 重 複すると普通は混乱状態になります. 同じ IDを共有しているデバ イスがI/Oリクエストに答えようと処理をおこなうことが落し穴にな ります. 8 bitバスでは, 最大8台のターゲットまで可能です. 最大8台で ある理由は, バスの8本のデータ線がデバイスの選択に使われる からです. バス幅の広いバスでは使えるデバイスの数は増えます. 同時にバス使用の要求が発生した場合, 最も IDの大きいデバイス が優先されるという調停がおこなわれます. このことは (ナローバス では) SCSIホストアダプタの IDは通常7番が使われる理由でもあり ます. さらにサブユニットとして, 規格では ロジカルユニット,短縮形 で LUNを持つことができます. 一つのターゲットIDが複数の LUNを 持つことができます. 例えば, テープチェンジャを持つテープ ドライブは LUN 0をテープドライブ自身, LUN 1をテープチェン ジャ に与えることができます. このようにして, ホストシス テムはテープチェンジャの目的のテープユニットの部分を指定す ることができます. バスレイアウト

SCSIバスは直線状です. つまり, Y接続, スター接続, クモの巣 状の接続などの直線以外の接続ではありません. 先に議論したターミネータの問題は直線状以外の場合ではより困 難になるだろうということに注意してください. 電気的特性はそのノイズマージンや全体の信頼性において,直線 状のバスのルールに強く依存しています. 直線状バスであるというルールにしたがってください! 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' とします. 簡単ですね? 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: 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), CD-ROM (cd) などです. これらのソースコードは/sys/scsiにあり ます. マニュアルページ (man) のセクション 4 にはより詳しい内 容があるので見てください. 多階層の設計は低レベルとより高位のレベルを分離させることがで きます. 新たに他の種類のハードウェアのサポートを加えることを より処理しやすい問題にします. カーネルコンフィグレーション

あなたのハードウェア構成にしたがって, カーネルのコンフィグファイ ルにホストアダプタについて 1行あるいは数行程度の記述をする 必要があります. これには I/O アドレスや割り込みなどについての内容も含 みます. あなたのアダプタのドライバについてのマニュアルページ にはより多くの情報があるのでよく読んでください. これとは別に /sys/i386/conf/LINT にはカーネルコンフィグファイルについての 概要があります. LINTには一般的なものについては可能なすべてのオ プションが含まれています. ただし, LINTでは実際に動作するカー ネルを作ることは できません. おそらく何をするかは明らかでしょう. カーネルコンフィグファイ ルは実際のハードウェア構成を反映すべきです. そのように割り込 みやI/Oアドレス等に合わせてカーネルコンフィグファイルを書か なければなりません. システムのブート時のメッセージは実際に 見つけたハードウェアの設定を表示します. 例として FreeBSD 2.0.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!) # bt: Most Buslogic controllers # nca: ProAudioSpectrum cards using the NCR 5380 or Trantor T130 # uha: UltraStore 14F and 34F # sea: Seagate ST01/02 8 bit controller (slow!) # wds: Western Digital WD7000 controller (no scatter/gather!). # [ Adaptec AHA274x, 284x などのコントローラ] controller ahc0 at isa? bio irq ? vector ahcintr # port??? iomem? [ Adaptec AHA174x コントローラ] controller ahb0 at isa? bio irq ? vector ahbintr [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 ahb0 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 [ahb0 上の SCSIディスク] tape st1 at scbus0 target 6 [SCSI テープ は ターゲット (ID)6] device cd0 at scbus? [最初に見つけた CDROM, 固定にしない] 上の例では カーネルは ahc (Adaptec 274x) コントローラをまず 探し, その次に Adaptec 174x のボードというように順番に探して 行きます. その下の行の 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 154xドライバの場合はman 4 aha にあります. カーネルセットアップでの 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: 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: 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 に あるデバッグレベルを変えてみてください. 検出はされるが 動かないのであれば, scsi(8)コマンドで (SCSIDEBUG をつけてmakeした) カーネルが動いている状態で動的にデバッグ レベルを設定することができます. これは guru (UNIXの達人) で も混乱してしまうほどの非常に大量のデバッグ情報を出すでしょ う. man 4 scsi にはより正確な情報があります. またman 8 scsi も見てください. さらに詳しい情報

もしあなたがいくらかは本気で SCSIハッキングをする気があるなら たぶん正規の規格を持っていたくなるでしょう. 承認ずみのアメリカ工業規格は ANSI から購入できます. 住所と電話 番号は11 West 42nd Street, 13th Floor, 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 (誰でも ファイルを取ってくることができる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 のニュースグループ と は特により多くの情報を得るには注目すべき場所です. また定期的に ポストされる SCSI-FAQをここから得ることができます. 多くの主要な SCSIデバイスとホストアダプタの供給元は FTP サイト や BBSを開いています. これらはあなたの持っているデバイスに関す る貴重な情報源となるでしょう. diff --git a/ja_JP.EUC/handbook/sections.sgml b/ja_JP.EUC/handbook/sections.sgml index 59529cedc3..2af5db85d4 100644 --- a/ja_JP.EUC/handbook/sections.sgml +++ b/ja_JP.EUC/handbook/sections.sgml @@ -1,64 +1,64 @@ - + diff --git a/ja_JP.EUC/handbook/serial.sgml b/ja_JP.EUC/handbook/serial.sgml index 0c4d4bab78..80e66166f6 100644 --- a/ja_JP.EUC/handbook/serial.sgml +++ b/ja_JP.EUC/handbook/serial.sgml @@ -1,76 +1,76 @@ + + + + シリアル接続の基礎

Assembled from FAQ. このセクションには, シリアルポートについての一般的な情報が書かれていま す. あなたが求めている情報が, もしここで見つからなかった場合には, ハン ドブックの端末とダイアルアップのセクションを見てください.

stty -a -f /dev/ttyd1 このデバイスの設定を変更した場合, その設定はデバイスが クローズされるまで有効です. デバイスが再びオープンされる時, デフォルトの設定値に戻ります. デフォルトの設定を変更するためには, 「初期状態」を設定した いデバイスをオープンして調節することができます. 例えば, ttyd5 というデバイスに対して, デフォルトで XON/XOFF フロー制御を行うように設定したい場合は, 次のようにします. stty -f /dev/ttyid5 clocal cs8 ixon ixoff このコマンドを記述するのに適しているファイルは, /etc/rc.serial です. アプリケーションが stty -f /dev/ttyld5 57600 これで、 - + sioドライバの設定

sio ドライバは, NS8250-, NS16450-, NS16550とNS16550A ベースの EIA RS-232C(CCITT V.24) 通信用インタフェースをサポートします. ま た, いくつかのマルチポートシリアルカードもサポートされています. 技術的 な詳細についてはマニュアルsio(4)を見てください. Digi International (DigiBoard) PC/8

原作: &a.awebster;. 1995年8月26日.

訳: &a.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 のボードではなく, 外付けのコネクタボックスの中に存在します. コネクタボックスを接続しないと, ポートの検出に失敗するでしょう. 私は, 接続しないまま起動したり, 後から接続しなおしたりした時にどうなるかをテ ストしていません. どちらも実行しないようお奨めします. もしあなたがカスタマイズ済みのカーネルコンフィグレーションファイルを持っ ていなければ, 一般的な事柄については, を参考にしてください. 以下にBoca 16のボード に関係する部分だけを記述します. この例では, あなたがMYKERNELという名前 のカーネルを使っていて, エディタには viを使っていることを仮定していま す. 次の1行をconfigファイルに追加してください. options COM_MULTIPORT この device sioxxxという行を, 必要に応じて 16 個のデバイス分を追加してください. 最後のデバイスにだけ, このボード の割り込みベクタを記述します. (詳細は 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の割り当てを使っていない限り 必ず 上記の例から変更してください. フラグは, 次のように設定します. 0xMYY の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) もしメッセージの表示が速くて読み取れないときは, dmesg | more とするとブート時のメッセージをゆっくり見ることができます. 次に, root になってから, デバイスにあわせたエントリを /dev/MAKEDEVスクリプトを使って/dev に追加します. # cd /dev # ./MAKEDEV tty1 # ./MAKEDEV cua1 (中略) # ./MAKEDEV ttyg # ./MAKEDEV cuag もし, 何らかの理由で発信するデバイスが不要な場合, cua* デバ イスを作らないで済ますこともできます. デバイスが確実に動作しているかどうか確認する手っ取り早い方法は, あなたが (rootになって) 各ポートにモデムを接続してみて, あなたが作成し た各デバイス毎にecho at> ttyd*とやってみてください. 各ポー トが動作していればRXの表示が光るのが見えるはず です. diff --git a/ja_JP.EUC/handbook/skey.sgml b/ja_JP.EUC/handbook/skey.sgml index ef493d30fd..540d6a0563 100644 --- a/ja_JP.EUC/handbook/skey.sgml +++ b/ja_JP.EUC/handbook/skey.sgml @@ -1,355 +1,355 @@ + - S/KEY

原作: &a.wollman;25 September 1995.

訳: &a.hino;.24 September 1996.

S/KEY は一方向ハッシュ関数 (ここで述べているバージョンでは, 過去と の互換性を保つために MD4 を用いています. S/KEY の他のバージョンでは MD5 や DES-MAC を用いているものもあります) を基にしたワンタイムパスワー ド方式です. S/KEY は, バージョン 1.1.5 以降のすべての FreeBSD に標準的 に含まれています. S/KEY は FreeBSD 以外の数多くのシステムの上でも利用 可能であり, その実装の数も増えています. S/KEY ば Bell Communications Research, Inc. の登録商標です.

以下の説明では, 三種類の異なる「パスワード」が使われます. まず一つ 目は, あなたが普段使っている普通の UNIX スタイルの, もしくは Kerberos でのパスワードです. ここではこれを ``UNIX パスワード'' と呼ぶことにし ます. 二つ目は, S/KEY の `秘密のパスフレーズは, UNIX パスワードと同じである必要はありませんし, また UNIX パスワードと何らかの関連性を持たなければならないということも ありません (両者を同一に設定することは可能ですが, お奨めしません). UNIX パスワードは長さが 8 文字に制限されています (訳注: FreeBSD で DES を導入していない場合はもっと長いパスワードも認識されます). これに対し, S/KEY では秘密のパスフレーズを好きなだけ長くすることができます (訳注: 実装上, `S/KEY システムでは他に二種類のデータを使用します. 一つは ``シード (種)'' または (混乱を招きますが) ``キー'' と呼ばれるもので, (訳注: デ フォルトでは) 二つの文字と五つの数字で構成されます. もう一つは ``シー ケンス番号'' で, 1 以上の整数です. シーケンス番号は特に指定しなければ 100以下です (訳注: ``次に, S/KEY 関連の四つのプログラムについて説明します. `/etc/skeykeys というファイルを調べて, このプログラムを起動し たユーザの現在のシーケンス番号とシードを表示します. 最後に, `このドキュメントでは, 四種類の異なる操作について説明します. 一つ目 は, `信頼できる通信路での初期化

信頼できる通信路 (例えばあるマシンのコンソール画面など) を利用して いるときに, S/KEY の初期化, S/KEY の秘密のパスフレーズの変更, またはシー ドの変更をおこなうことができます. そのためには, まずあなた自身がログイ ンし, ` $ keyinit Updating wollman: ) この部分は始めて S/KEY を使 Old key: ha73895 ) うときには表示されません. 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 wollman s/key is 99 ha73896 ) あとで説明します. SAG HAS FONT GOUT FATE BOOM )

上の例で出てきた事柄について説明しましょう. `Enter secret password:' というプロンプトに対してあなたが考えた秘密のパスフレーズを 入力します (筆者は 7 単語以上の文を秘密のパスフレーズにしています). こ の秘密のパスフレーズは後でログインするために必要になるものです. `ID' から始まる行は, S/KEY における一回分のパラメタであり, あなたのログイ ン名とシーケンス番号とシードです. (訳注: `信頼できない通信路での初期化

信頼できない通信路を使って S/KEY を初期化, または秘密のパスフレーズ やシードを変更するためには, 信頼できる通信路として, その信頼できない通 信路とは別のものを用意する必要があります. その信頼できる通信路は ` $ keyinit -s Updating wollman: Old key: kh94741 Reminder you need the 6 English words from the skey command. ) `keyinit' コマンドが出力する注意です. 訳すと, ) 注意 - skey コマンドの出力する 6 英単語が必要になります. Enter sequence count from 1 to 9999: 100 ) ここを入力. Enter new key [default kh94742]: ) リターンのみ入力. s/key 100 kh94742 デフォルトのシード (`keyinit' プログラムは困ったことにこれを `key' と 読んでいるのですが, 混乱しないよう注意してください) で構わなければ, リ ターンキーを押してください. 次に, あらかじめ用意しておいた信頼できる通 信路 (信頼できるマシンや信頼できる S/KEY デスクアクセサリなど) へ移っ て, 先ほどと同じパラメタを入力します. $ key 100 kh94742 Reminder - Do not use this program while logged in via telnet or rlogin. Enter secret password: ) ここで秘密のパスフレーズを入力します. HULL NAY YANG TREE TOUT VETO ここで信頼できない通信路の方に戻って, ` s/key access password: HULL NAY YANG TREE TOUT VETO ID wollman s/key is 100 kh94742 HULL NAY YANG TREE TOUT VETO 後は, 前章で説明したことと同様です. ちょっと寄り道: ログインプロンプトについて

どうやってワンタイムパスワードを生成するかを説明する前に, S/KEY を 使う場合のログインプロンプトを見ておいた方がよいでしょう. $ telnet himalia Trying 18.26.0.186... Connected to himalia.lcs.mit.edu. Escape character is '^]'. s/key 92 hi52030 Password: パスワードを要求する前に, ログインプログラムがシーケンス番号とシードを 表示していることがわかります. この二つのパラメタを使ってワンタイムパ スワードを計算することになります. ここではまだ使っていませんが, 便利な 機能がログインプログラムに備わっています:パスワードプロンプトに対して, 何も入力せずにリターンを押すとエコーモードに切り替わります. つまりタイ プした文字がそのまま見えるようになるのです. これは S/KEY のワンタイム パスワードを紙に印刷していた場合など, ワンタイムパスワードを手で入力し なければならない場合に特に役立つ機能です.

このログインしようとしてるマシンが, あなたが今使っているマシンから UNIX パスワードを使ってログインすることができないように設定されている 場合があります. その場合には, ログインプロンプトには S/KEY のワンタイ ムパスワードの利用が必要であることを示す `(s/key required)' という注釈が表示されます. ワンタイムパスワードを生成する

次に前章のログインプロンプトに対して入力するためのワンタイムパスワー ドを生成しましょう. そのために, 信頼できるマシンと ` $ key 92 hi52030 ) 前章の例からペースト. Reminder - Do not use this program while logged in via telnet or rlogin. Enter secret password: ) 秘密のパスフレーズを入力. ADEN BED WOLF HAW HOT STUN そして別のウィンドウで: s/key 92 hi52030 ) 前章の例の続き. Password: ) ここでリターンキーを押した. (turning echo on) Password:ADEN BED WOLF HAW HOT STUN Last login: Wed Jun 28 15:31:00 from halloran-eldar.l [以下略.] 以上の手順は, 信頼できるマシンが利用できる場合 複数のワンタイムパスワードを生成する

都合によっては, 信頼できるマシンや信頼できる通信路が一切確保できな いようなところで S/KEY を使う必要があるでしょう. このような場合には, ` $ key -n 25 57 zz99999 Reminder - Do not use this program while logged in via telnet or rlogin. Enter secret password: 33: WALT THY MALI DARN NIT HEAD 34: ASK RICE BEAU GINA DOUR STAG [...] 56: AMOS BOWL LUG FAT CAIN INCH 57: GROW HAYS TUN DISH CAR BALM `UNIX パスワードの利用を制限する

設定ファイル /etc/skey.access を使って UNIX パスワードの利 用を制限することができます. この場合の判断基準として, ログインを受け付 ける際のホスト名, ユーザ名, 端末のポート, IP アドレスなどが利用できま す. この設定ファイルの詳細に関してはマニュアル もし /etc/skey.access ファイルが存在しないならば (FreeBSD をインストールした直後の状態では存在しません), すべてのユーザが UNIX パスワードを利用することができます. 逆に, もしファイルが存在するならば, /etc/skey.access ファイルに明示的に記述されていない限り, すべ てのユーザは S/KEY の利用を要求されます. どちらの場合においても, その マシンのコンソールからはいつでも UNIX パスワードを使ってログインするこ とが可能です.

以下によく使われるであろう三種類の設定を含む設定ファイルの例を示し ます: permit internet 18.26.0.0 255.255.0.0 permit user jrl permit port ttyd0 はじめの行 (`二行目 (`三行目 (` - + SLIPクライアントのセットアップ

原作: &a.asami;8 Aug 1995.

訳: &a.hanai;8 August 1996. ここにはFreeBSDマシンを静的アドレスのネットワークにつなげる場合の SLIPのセットアップの一つの方法を書いてあります. ホスト名を動的に割り当てる(つまり, ダイヤルアップするたびにアドレスが かわる)ためには, おそらくもっと凝ったことが必要です. まず, モデムがどのシリアルポートにつながっているか決めましょう. 私は /dev/modem -> cuaa1というシンボリックリンクを張り, コンフィグレーションではその名前だけを使っています. /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 余談ですが, silviaというのは私が日本にいた時に持っていた 車の名前です(米国では2?0SXと呼ばれています). /etc/host.confファイル中で"hosts"が"bind"よりも前にあること を確認してください. さもないとヘンなことが起こるかもしれません. /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 で slattach -h -c -s 115200 /dev/modem と入力しましょう. もしルータの向う側のホストへ"ping"できるなら接続成功です! もしうまく いかなければslattachへの引数として"-c"の代わりに"-a"とやってみてください. 接続の切り方

slattachを殺すためにrootで "kill -INT `cat /var/run/slattach.modem.pid`" とタイプしてください. そしてkermitに戻り(もしkermitをサスペンドしていたなら "fg"), kermitから抜けてください("q"). slattachのマニュアルページにはインタフェースを落すために "ifconfig sl0 down"をしなければいけないと書いていますが, 私には差がないように見えます. ("ifconfig sl0"とやっても同じ結果が得られる.) 時にはモデムがキャリアを落すのを拒絶するかもしれません(私のは よくそうなります). その時は単にkermitをスタートしてまた終了 してください. 普通は2回目で落ちます. トラブルシューティング

もし動かなければ自由に私に質問してください. 今までいろんな人がつまずいた のは次のようなことです. slattachで"-c"や"-a"を使わなかった(私はなぜこれが致命的になり得るのか わかりませんが, このフラグを付けることで少なくとも一人の問題は解決しました.) "sl0"の代わりに"s10"を使った(いくつかのフォントでは見分けるのは難しい かもしれません). インタフェースの状態を見るために"ifconfig sl0"をやってみてください. 私は, silvia# ifconfig sl0 sl0: flags=10 inet 136.152.64.181 --> 136.152.64.1 netmask ffffff00 となります. また, pingが"no route to host"というメッセージを返す時には netstat -rでルーティングテーブルを確認しましょう。 私のは, silvia# 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) となります. (これはたくさんのファイルを転送した後でのもので, あなたの見る数字はもっと小さいかも しれません). diff --git a/ja_JP.EUC/handbook/slips.sgml b/ja_JP.EUC/handbook/slips.sgml index d2c40e42db..d56c6b758b 100644 --- a/ja_JP.EUC/handbook/slips.sgml +++ b/ja_JP.EUC/handbook/slips.sgml @@ -1,514 +1,514 @@ - + SLIPサーバのセットアップ方法

原作: &a.ghelmer;. v1.0, 15 May 1995.

訳: &a.ts;.6 September 1996. この文書の目的は, SLIPサーバ機能を FreeBSDシステムのもとで設定するため の助言を提供することです. SLIPサーバ機能を設定するということは, リモー トの SLIPクライアントがログインできるようにするために, 自動的に接続処 理をおこなうようにすることです. この文書は著者の経験に基づいておりますが, 実際のシステム構成や要望は異なりますから, すべての疑問にこの文書が答え ることはできません. なお, ここでの助言を試みた結果, あなたのシステムへ の悪影響やデータの損失が生じたとしても, 著者が責任を持つことはできませ んのでご了解をお願いします. 当初この文書は, FreeBSD 1.xシステムでの SLIPサーバ機能のために書きまし た. その後, FreeBSD 2.xの初期バージョンでのパス名の変更や SLIPインタフェー ス向け圧縮フラグの削除といった変更点を反映するために, 書き換えをおこないま した. これらが FreeBSDのバージョン間の主要な変更点だったからです. もし この文書の間違いを見つけられましたら, ぜひ, 訂正に十分な情報とともに電 子メールでお知らせいただければ助かります. 前提

この文書の内容はテクニカルなものなので, 前提知識が必要です. すなわち, 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/ におけるチュー トリアルの一覧を調べてください. あるいは, この文書を見つけた場所を調べ て, 概要

一般的な設定内容で FreeBSDを SLIPサーバとして利用すると, その動作は次 のようになります. まず, SLIPユーザが FreeBSD による SLIPサーバへ電話し て, SLIP専用IDでログインします. なお, このIDを持ったユーザはシェルとし て /usr/sbin/sliplogin を使います. この /etc/sliphome/slip.hosts の中から, ログインIDと一致する 記述行を探します. もし一致する行があれば, ログインしたシリアル回線を, 利用可能な SLIPインタフェースへ接続し, その後にシェルスクリプト /etc/sliphome/slip.login で SLIPインタフェースを設定します. SLIPサーバへのログイン例

仮に SLIPユーザIDが Shelmerg とします. すると, /etc/master.passwd における Shelmerg:password:1964:89::0:0:Guy Helmer - SLIP: /usr/users/Shelmerg:/usr/sbin/sliplogin sliplogin は, ファイル /etc/sliphome/slip.hosts からユーザIDと一致する行を探しま す. いま仮に, /etc/sliphome/slip.hosts に次のような記述がなさ れていたとします. Shelmerg dc-slip sl-helmer 0xfffffc00 autocomp /etc/sliphome/slip.login を実行します. /etc/sliphome/slip.login 0 19200 Shelmerg dc-slip sl-helmer 0xfffffc00 autocomp もし上記の手順が正常に処理されると, /etc/sliphome/slip.login は, slip.login で与えられたパラメタのうちで最初の値である SLIP インタフェース0である) に対して ifconfig を実行し, ローカル IPアドレス (dc-slip)をはじめ, リモート IPアドレス (sl-helmer), SLIPインタフェースへのネットワークマスク (0xfffffc00), およびその他のフラグ (autocomp)を設定 します. 逆に, さきほどの手順が正常に終了しなかった場合, 通常は /var/log/messages へ記録します ( syslogd(8) や 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 0.0.c0.2c.5f.4a 291311 0 174209 0 133 ed0 1500 138.247.224 ivory 291311 0 174209 0 133 lo0 65535 79 0 79 0 0 lo0 65535 loop localhost 79 0 79 0 0 sl0* 296 0 0 0 0 0 sl1* 296 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], and perhaps 1127 [A Perspective on the Host Requirements RFCs] ) に準拠して, FreeBSDによる SLIPサー バをルータとして動作させたいときには, /etc/sysconfig ファイル の gateway 変数を YES としてください. もし古いシステ ムのために /etc/sysconfig ファイルがないときには, 次のコマン ドを /etc/rc.local へ追加してください. sysctl -w net.inet.ip.forwarding = 1

この新しい設定を有効とするには, リブートする必要があります.

デフォルトのカーネルコンフィグレーションファイル (/sys/i386/conf/GENERIC) の最後の部分に, 次のような行がありま す. pseudo-device sl 2 この行によって, 使用可能な SLIPデバイスの総数が決まります. すなわち, 行 末の数値が, 同時に動作可能な SLIP接続の最大数となります. カーネルの再構築については, を参照ください. Sliploginのコンフィグレーション

すでにご説明したように, /usr/sbin/sliplogin のコンフィグレー ションのために, 3種類のファイルが/etc/sliphome ディレクトリに あります (sliplogin についての実際のマニュアルページとしては sliplogin(8) を参照のこと) . ファイル slip.hosts は SLIPユーザおよびその IPアドレスを決めます. 通常, ファイル slip.login は, SLIPインタフェースを設定することだけに使 用します. slip.logout はオプションのファイルで, slip.login で設定した内容を, シリアル接続が終了した時点で解除 するときに使用します. slip.hostsのコンフィグレーション

/etc/sliphome/slip.hosts には, 少なくとも 4 つの項目をホワイ トスペース (スペースやタブ) で区切って指定します. SLIPユーザのログインID SLIPリンクのローカル (SLIPサーバ側) アドレス SLIPリンクのリモートアドレス ネットワークマスク ホスト名をローカルおよびリモートのアドレスとして記述できます (IPアドレ スの決定は, /etc/host.conf の指定内容に応じて, /etc/hosts か DNSのいずれかによって決定される) . また, ネット ワークマスクも /etc/networks ファイルに記述された名前を参照す ることで, 指定することもできると思います. これまでの例としてあげたシス テムでの /etc/sliphome/slip.hosts は次のようになります. ----- begin /etc/sliphome/slip.hosts ----- # # login local-addr remote-addr mask opt1 opt2 # (normal,compress,noicmp) # Shelmerg dc-slip sl-helmerg 0xfffffc00 autocomp ----- end /etc/sliphome/slip.hosts ------ それぞれの行の最後には, 次に示すオプションを一つ以上指定できます. normal - ヘッダを圧縮しない compress - ヘッダを圧縮する autocomp - リモートの設定に応じて, ヘッダを圧縮する noicmp - ICMPパケットを禁止する (pingパケットは送出されず, バンド幅を占有しない) なお, FreeBSDバージョン2の初期リリースの の節で紹介した TCP/IP関連書籍を参考になさるか, またはあなたの IPネットワークを管理している方に相談なさるとよいでしょう. 独立したサブネットを SLIPクライアントへ適用するときには, すでに割り当 てられている IPネットワーク番号の範囲からサブネット番号を割り当て, 同 時にそのサブネットの範囲内で有効な IPアドレスを SLIPクライアントの IP 番号として割り当てる必要があります. さらに, この SLIPサブネットから SLIPサーバを経由して最も近い IPルータへの経路を静的に設定するか, また は gated を FreeBSDによる SLIPサーバへインストールして, 適当 なルーティングプロトコルを使って, SLIPサーバ経由のサブネットへの経路情 報をルータ群へ通知できるように設定するか, のいずれかをおこなう必要がありま す. 「プロキシ ARP」方式を採用するときには, SLIPクライアント向けの IPアドレス として, SLIPサーバのサブネットの範囲から選んで割り当てるとともに, arp(8) コマンドを使うために /etc/sliphome/slip.login と/etc/sliphome/slip.logout のスクリプトを修正して, SLIPサー バにおける ARPテーブル内のプロキシ ARPエントリへ反映させる必要がありま す. slip.loginのコンフィグレーション

ファイル /etc/sliphome/slip.login の一般的な内容は次にように なります. ----- begin /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 ----- end /etc/sliphome/slip.login ----- この slip.login ファイルの役目は単に, SLIPインタフェースにつ いてのローカルとリモートのアドレス, およびそのネットワークマスクを ifconfig コマンドで設定することです. もしプロキシ ARP方式を採用する (SLIPクライアントへ独立したサブネットを 使わない) ときには, ファイル /etc/sliphome/slip.login は次の ような内容になります. ----- begin /etc/sliphome/slip.login for "proxy ARP" ----- #!/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 ----- end /etc/sliphome/slip.login for "proxy ARP" ----- この 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 0.2.c1.28.5f.4a 191923 0 129457 0 116 ^^^^^^^^^^^^^^^ この例での Ethernet MACアドレスは 00:02:c1:28:5f:4a であると 読みます. なお arp(8) における MACアドレスの指定に際しては, コマンド netstat -i が付けた Ethernet MACアドレスのピリオド記 号をコロン記号と置き換え, かつ単一桁の 16 進数にはゼロを先頭に加える必 要があります. この指定についての正確な情報は arp(8) を参照く ださい. ご注意いただきたいのは, /etc/sliphome/slip.login と /etc/sliphome/slip.logout を作成したならば, ファイル属性の実 行ビット (すなわち chmod 755 /etc/sliphome/slip.login /etc/sliphome/slip.logout) を 設定しなければならないということです. さもなければ sliplogin が うまく実行されません. slip.logoutのコンフィグレーション

ファイル /etc/sliphome/slip.logout は必ずしも必要なものではあ りません (ただし「プロキシ ARP」を利用する場合を除く) . もしこのファイルを 作成するときには, 次に示す標準的な slip.logout スクリプト例を 参考にしてください. ----- begin /etc/sliphome/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 ----- end /etc/sliphome/slip.logout ----- 「プロキシ ARP」を利用する場合, この /etc/sliphome/slip.logout を 使って, 特定の SLIPクライアント向けの ARPエントリを削除したくなるよう なときがあります. ----- begin /etc/sliphome/slip.logout for "proxy 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 ----- end /etc/sliphome/slip.logout for "proxy ARP" ----- コマンド 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サブネッ トへ使うようにルータを設定しなければならないだけでなく, その静的経路を 他のどのルータへ知らせるのかもあらかじめ指定しておく必要がありますから, 静的経路に基づくルーティングを軌道に乗せるにはそれなりの専門的技術やト ラブルシューティングやコツが必要だと思います. gatedの稼働

静的経路についての頭痛への代替手段は, gated を FreeBSDによる SLIPサー バへインストールして, 適切なルーティングプロトコル (RIP/OSPF/BGP/EGP) を使って SLIPサブネットについての経路情報を他のルータへ知らせるように 設定することです. gated は, 匿名FTPを使って, ftp.gated.cornell.edu の /pub/gated ディレクトリから 入手できます. このチュートリアルを執筆時点の最新バージョンは gated-R3_5Alpha_8.tar.Z であり, このファイルだけで FreeBSDで 動作させることができます. gated についてのすべての情報と文書 は http://www.gated.cornell.edu/ からはじまる Web上で入手でき ます. gated のコンパイルとインストールを行ったならば, 独自の 設定のために /etc/gated.conf ファイルを記述してください. 次の 例は, 筆者が FreeBSDによる SLIPサーバで使っている内容と類似のものです. ----- begin sample /etc/gated.conf for gated version 3.5Alpha5 ----- # # 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 ; } ; ----- end sample /etc/gated.conf ----- この gated.conf ファイルの例では, SLIPのサブネット xxx.xxx.yy についての経路情報を RIPを使って Ethernetへブロー ドキャストしています. もし 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.EUC/handbook/stable.sgml b/ja_JP.EUC/handbook/stable.sgml index ea0fee1a0c..adf0c2408e 100644 --- a/ja_JP.EUC/handbook/stable.sgml +++ b/ja_JP.EUC/handbook/stable.sgml @@ -1,107 +1,107 @@ - + FreeBSD の安定状態の持続

原作: &a.jkh;.

訳: &a.iwasaki;. FreeBSD-stable ってなに?

FreeBSD-stable は, 次の本流のリリースを目指した新機能をあまり採り入 れない保守的な変更のための開発の支流です. 実験的またはテスト未完の変更 はこの支流には取り入れられません ( 参照). 誰が FreeBSD-stable を必要としているの?

もしあなたが仕事で使用しているとか, なによりも FreeBSD システムの安 定性を最重要視するなら, stable を追いかけることを考えるべきで しょう. stableの支流は前のリリースに関して効果的にバグフィッ クスされた流れであるため, 最新のリリース ( 執筆時点) をインストールしているのであれば, 特に そうです.

stable ツリーが常に完全に互換性があり安定するように努力し ていますが, たまに間違いがあることに注意してください (結局, 内容が吟味 されずに素早く送られた変更を含むソースがまだあるのです). また, current を stable へ移行する前に完璧なテストフィック スに最善を尽くしますが, 私たちのテストはすべてのケースを十分に網羅して いるとは限りません. もし何か stable で不具合があるようでした ら, 私たちにすぐに教えてください (次の節参照). FreeBSD-stable を使う

&a.stable へ加わってください. このメーリングリスト では, stable の構築に関連する事柄や, その他の注意すべき点 に関する情報が流れています. また開発者は議論の余地がある修正や変更 を考えている場合に, このメーリングリストで公表し, 提案された変更に 関して問題が生じるかどうかを返答する機会をユーザに与えます. メーリングリストに参加するには, &a.majordomo へメッセージの本文に 次のように書いたメールを送ってください: subscribe freebsd-stable オプションとして本文に `help' と書けば, Majordomo は私たちがサポー トする様々なメーリングリストに参加 / 脱退する方法に関する詳しいヘ ルプを送付します. ftp.FreeBSD.ORG からのソースの入手. 以下の 3つの方法で おこなうことができます : 機能を使用する. 転送レートが 安定している TCP/IP 接続でない場合は, この方法が適して います. CMUの プログラム (ソフトウェア 更新プロトコル) を使用する. 一度コレクション全体を入手 してしまえば, 前回からの変更部分だけですむので, 2番目に 推奨される方法です. 多くの人が cron から sup を実行し, 自動的にソースコードを最新の状態に保っています. ftp を使用する. FreeBSD-stable 用のソースツリーは 常に次のところで「公開」されています :

私たちはまた, tar/compress でツリー全体を入手できる `wu-ftpd' を使用しています. 例えば : usr.bin/lex に対して: ftp> cd usr.bin ftp> get lex.tar.Z とすることにより, ディレクトリ全体を compress された tar ファイルとして入手することができます. 基本的には, ソースに迅速でオンデマンドなアクセスが必要で, 接続のバンド幅が問題でなければ, sup か ftp を使いましょう. そうで ない場合は CTM を使いましょう. stable をコンパイルする前に, /usr/src にある Makefile をよ く読んでください. 少なくとも一回はアップグレードの処理の一部として 最初に `make world' を実行するべきでしょう. &a.stable を読めば, 次 のリリースに移行するに当たって時々必要となる既存システムからの新シ ステムの構築手順についての最新情報が得られるでしょう. diff --git a/ja_JP.EUC/handbook/submitters.sgml b/ja_JP.EUC/handbook/submitters.sgml index 79bbf0a2b3..69d6b76947 100644 --- a/ja_JP.EUC/handbook/submitters.sgml +++ b/ja_JP.EUC/handbook/submitters.sgml @@ -1,583 +1,583 @@ - + FreeBSD への貢献

原作: &a.jkh;.

訳: &a.iwasaki;.13 December 1996.

あなたも何か FreeBSD のために貢献したくなりましたか? 素晴らしい! 私たちは常に支援を受ける用意がありますし, FreeBSD は生き残るためにユー ザベースの貢献に頼るようなシステムの一つです. あなたの貢献は 感謝されるだけではなく, FreeBSD が成長し続けるために極めて重要なものな のです!

一部の人達が言っているのとは逆に, 貢献を受け付けてもらうために腕利 きのプログラマーになるとか FreeBSD コアチームの人と親友になる必要はあ りません. FreeBSD プロジェクトの開発は, 多くのそして益々増加する世界中 の貢献者達によってなされており, 彼らの年齢, 専門技術分野は多岐に渡りま す. そして手の空いている人よりも成されるべき仕事の方が常に多いのです.

FreeBSD プロジェクトがカーネルや散在しているユーティリティよりも, オペレーティングシステム環境 (と, そのインストール) に対して責任を持つ ようになったため, 私たちの「TODO」リストはドキュメンテーション, ベータテ スト, 高度に専門化されたタイプのカーネル開発の好例を紹介するなど非常に 広い範囲のタスクに渡ります. あなたの技能レベルに関わらず, プロジェクト を支援できることが必ず何かあります!

FreeBSD 関連の事業に従事している商業団体が私たちにコンタクトすること も歓迎します. あなたの製品を (FreeBSD 上で) 動作させるには, 特別な拡張 が必要ではありませんか? あまりにも風変わりな要求でなければ, それを受け 入れる用意が私たちにあるとわかるはずです. 付加価値のある製品ですか? 私たちに知らせてください! 多分私たちは, ある 面において共同して作業をすることができるでしょう. フリーソフトウェア界 は, ソフトウェアがそのライフサイクルを通してどのように開発され, 売られ, 保守されていくかについて, 既存の仮説に挑戦しています. 少なくとももう一 度考慮してみることを私たちは強くお奨めします. 何が必要?

次のタスクとサブプロジェクトのリストは, コアチームの色々な TODO リ ストと最近2ヶ月で集めたユーザリクエストを合わせたものです. 可能なとこ ろでは, 緊急度によってタスクがランクづけされています. もしここにあるタ スクの実行に興味があるのでしたら, コーディネータの名前をクリックしてメー ルを送ってください. もしコーディネータが決まっていなければ, あなたがボ ランティアしてみませんか? 優先度の高いタスク

次のタスクは通常, ひどく壊れているとか, とても必要とされている何かを 表しているため, 急務と考えられています: 第3ステージ・ブート問題. 全体コーディネーション: &a.hackers

64MB を越えるメモリの正しい自動検出. userconfig (-c) の 第3ステージ・ブートへの移動. 第3ステージがディスクの BIOS ジオメトリの正確なマッピングを提供 できるように WinNT コンパチブルなドライブの追跡をおこなう. ファイルシステム問題. 全体コーディネーション: &a.fs MSDOS ファイルシステムの修正. nullfs ファイルシステムコードのクリーンアップと ドキュメンテーション. コーディネータ: &a.gibbs union ファイルシステムの修正. コーディネータ: &a.dyson LFS ファイルシステムの修正. コーディネータ: &a.dyson カーネル vm86 及びユーザ vm86 サポート実装. コーディネータ: &a.hackers Int13 vm86 ディスクドライバの実装. コーディネータ: &a.hackers SCSI ドライバ問題. 全体コーディネーション: &a.hackers

タグキューイングの一般的なサポート. 私たちのおこなっている コマンドキューイング方法の書換えが必要だが, とにかく優先度付けされた I/O にはこれが必要 (CD-R ライタ / スキャナ). エラー処理の改善 (ビジー・ステータスおよびリトライ). 統合された Scatter-Gather リスト生成コード. カーネル問題. 全体コーディネーション: &a.hackers

すべての現存ドライバの eisaconf 変換の達成. すべての割り込みルーチンをユニット番号を使う代わりに (void *) を 取るように変更. EISA/PCI/ISAの割り込み登録コードの統合. PCI/EISA/ISA デバイス検出を bt742a.c(WIP) のようなドライバから分割. syscons の ALT-TAB/vt 切替えによるハングの修正. コーディネータ: &a.sos syscons 用のマウスサポート. すべてのコンソールドライバ用のキーボードコードの統合. Intel Etherexpress 16 ドライバの書換え. 3c509と3c590 ドライバの統合 (本質的には PCI デバイス検出の ep.c への提供). Adaptec 3985 (シンプルな3チャネル SCSI カードとしては最初のもの) のサポート. コーディネータ: &a.gibbs Advansys SCSI コントローラ製品のサポート. コーディネータ: &a.gibbs 優先度がさほど高くないタスク

次のタスクはやっておくべきではありますが, 特にさし迫っているわけで はありません: DOS エミュレータ (DOS の実行ファイル用) コーディネータ: AFS (Andrew ファイルシステム) の FreeBSD への移植 コーディネータ: MCA サポート? これは続けるにしても止めてしまうにしても結論を出 すべき. 完全な LKM ベースのドライバのサポート / コンフィグレーションマネー ジャ.

ld なしですべての LKM の登録をおこなう方法を考案する. これは カーネル中にある種のシンボルテーブルを持たせることを意味します. 穏やかな方法でハードウェアを検知するコンフィグレーションマネージャ の作成 (第3ステージ・ブートの中に?). ハードウェアが必要とする LKM だけを 残す等. PCMCIA/PCCARD. コーディネータ: &a.nate と &a.phk ドキュメンテーション! pcic ドライバの信頼性のある操作 (テスト要). sio.c のリコグナイザとハンドラ (ほぼ完了). ed.c のリコグナイザとハンドラ (ほぼ完了). ep.c のリコグナイザとハンドラ (ほぼ完了). User-mode のリコグナイザとハンドラ (部分的に完了). 先進的なパワーマネージメント. コーディネータ: &a.nate と &a.phk APM サブドライバ (ほぼ完了). IDE/ATA ディスクサブドライバ (部分的に完了). syscons/pcvt サブドライバ. PCMCIA/PCCARD ドライバ群との統合 (サスペンド / レジューム). 優先度の低いタスク

次のタスクは全くのあら隠し, または誰もすぐにおこないそうもない投資 のような仕事を表します:

最初の20項目は Terry Lambert <terry@lambert.org> からのもので す. プロセッサ上で V86 モードを使用して, プロテクトモードからの BIOS コールができるようにし, マップされた割り込み IPC 機構を経由してプロテ クトモードの呼出し元に結果を返すようにする. DOS と同じように, 実際の下位ハードウェアから独立になるよう, BIOS コール機構を使用したカーネルの中に組み込まれたドライバ. これは DOS ベー スのローダプログラムで BSD がロードされる前に DOS にロードされていたネッ トワークドライバや ASPI ドライバも含みます. このことは潜在的なポーリン グ, つまりプロテクトモードカーネルによる V86 マシンのための DOS-not-busy 割り込みの生成を意味します. ハードウェア固有のプロテクトモードのドライバがロードされて活性化 された後で, デフォルトのカーネル実行形式の中の, そのようなドライバデー タとテキストエリアを追跡して, カーネルアドレス空間のその部分が回復され るようにするためのイメージ形式. これは個々の BIOS ベースのドライバを互いに分離することを含みます. なぜ なら全く実行しないよりも, すべてのケースにおいて BIOS ベースのドライバ と共に実行した方が良いためです. バスインタフェース機構の抽象化. 現在のところ, PCMCIA, EISA そし て PCI バスはブリッジで ISA バスに接続されていると仮定しています. こう いった仮定はおこなうべきではありません. パワーマネージメントイベント, カードの挿入, 取り出し, そしてバス (PNPISA と PCMCIA とのブリッジチップ) 対カードのレベルのイベント管理を 含む PNP イベントを解釈するコンフィグレーションマネージャ. 固定デバイスによる他の再割当可・不可のデバイス空間リソースの使用 と衝突しない, 再割当可能なアドレスの割り当てのためのトポロジカルソート 機構. ハードウェアサービス登録のための登録ベースの機構. 特にタイマ, サウンドおよび他のシステムクリティカルなサービス供給源のためのデバイス 中心の登録機構. 単一の独立していないサービス供給源の一つの例として Timer2, Timer0 そしてスピーカサービスを考慮する必要があります. 配置転換とシンボル空間操作をおこなう LKM ローダ機構からアクセス 可能な, カーネルのデータ空間内にあるエキスポートされたシンボル空間. こ のインタフェースの目的は, 必要な時にカーネルモジュールをロードして, 必 要がなくなればアンロードできる能力をサポートすることです. ネットワークカードと一緒に提供される ODI カードドライバを使用で きるようにする, NetWare サーバ (プロテクトモードの ODI ドライバ) ロー ダとサブサービス. NDIS ドライバと NetWare の SCSI ドライバについても同 様. 前のリビジョンの FreeBSD マシンではなく, Linux マシンで動作する 「アップグレード システム」オプション. 移植を簡単にするためと, X, ThinkPad, PS/2マウス, LED, コンソール スイッチング, しつこい NumLock などの問題を全部一度に片付けるためのコ ンソールドライバの抽象レイヤへの分割. 機会が許したら, 他の外部ドライバのための他のカーネルのエミュレー ション環境. SCO と Solaris は UnixWare などに続く良い候補です. 異なるアーキテクチャのバイナリの実行のためのプロセッサエミュレー ション環境. これはシステムコールインタフェースがあまり変わらなければ, 思ったより簡単です. 商用のストリームドライバを使用可能にするためのストリーム機構. カーネルのマルチスレッド化 (カーネルのプリエンプションが必要). カーネルのプリエンプション付き対称マルチプロセッシング (カーネル のプリエンプションが必要). ポータブルコンピュータのサポートにおける協調の試み. これは PCMCIA ブリッジング規則と電源管理イベント処理の変更により, いく らかは処理できます. しかし, 内蔵ディスプレイと外部ディスプレイの検出, この2種類のディスプレイがあるという事実に基づく異なる解像度の選択, マ シンがドックにある場合にはディスクのモータ停止を防止すること, マシンの ブート能力に影響を与えずにドックベースのカードの消滅を可能にすること (PCMCIA と同じ問題) などの問題があります. マルチプラットフォームへの移植のためのソースツリーの再組織化. 「make world」できちんと「世界を創造する」ができるようにする. (もし「make regress 訳注: 後退する」と呼び方が適当であれば, そのように 名前を変える) 最小必要メモリ 4MB 化 (もっと小さければなお良し!). 貢献の仕方

一般的に, システムへの貢献は次の6つのカテゴリの1つ以上に分類されま す: バグ報告と一般的な論評

報告するべきバグがあったり, 提案したいことがあれば: 一般的な技術的関心事に関するアイデアや提案は &a.hackers; へメールしてください. 同様に, このような事柄に興味のある (そして膨大なメー ル! に耐えられる) 人は, &a.majordomo; へメールを送って hackers メーリングリストに参加すると良いでしょう. 情報については を参照してください. 実際のバグ報告は send-pr(1) プログラムか を使用して提出してください. これは色々な項目についての 問い合わせをします. send-pr(1) プログラムの場合は, 単に <> で囲まれて表示されているものをあなた固有の情報 に置き換えて入力します. WEB ベースのインタフェースの場合は, そこで表示されているオプションメニューから適切な項目を選択し 必要項目を埋めるだけです.

あなたはバグ報告の確認とトラッキング番号をメールで受け取る はずです. このトラッキング番号を覚えておき後々の連絡に使用して, 他の人がその問題の詳細を素早く見つけられるようにしてください. また, にサブジェクト行に PR# を付けた メールを送って, より詳しい情報を既存のバグ報告に追加することも できます. もしタイムリに (あなたの電子メール接続形態にもよりますが, 3日から 1週間) 確認を受けとれないとか, 何らかの理由で send-pr(1) コマンドが使用できない場合には, &a.bugs へメールを送ってバグ報告を 提出してください. 文書の変更

文書の変更は &a.doc; が監督しています. 一般的にこれは「現存のソース コードの変更」のカテゴリで考慮されるべきマニュアルページの変更は含ん でいません. 現存のソースコードの変更

現存のソースコードへの追加または変更は, いくらかトリッキーな仕事で あり, core の FreeBSD 開発の現状にあなたがどれだけ通じているかに大 きく依存します. 「FreeBSD-current」として知られる FreeBSD の特別な 継続的リリースがあります. FreeBSD-current は開発者の積極的な活動の 便宜のために, 色々な方法で利用可能になっています. FreeBSD-current の入手と使用方法についての詳しい情報については を参照してください. 不幸にして古いソースをもとに仕事をすることは, 時々あなたの変更が時 代遅れ, または FreeBSD への簡単な再統合に合わなくなっていることを意 味します. システムの現状に関する議論がおこなわれている &a.announce と &a.current へ参加することで, この可能性を最小限にすることができます. 完全な最新のソースを変更のベースにできることが確実になったと仮定し て, 次のステップは FreeBSD の保守担当者へ送る差分ファイルの生成です. これは diff(1) コマンドを使用しておこないますが, 「context diff」形式が好まれるようです. 例えば: diff -c oldfile newfile または diff -c -r olddir newdir これで指定されたソースファイルまたはディレクトリ階層に対するコンテ キスト形式の差分が生成されます. 詳しい説明は diff(1) のマ ニュアルページを参照してください. 差分ファイル (patch(1) コマンドでテストできます) を作った ら, それらを電子メールのメッセージにバンドルして, 差分ファイルの目 的の簡単な説明と一緒に &a.hackers; へ送ってください. 誰かが24時間以 内にあなたにコンタクトを取ってくるでしょう. もちろん, あなたの差分 ファイルが興味深いものであると仮定していますが! :-) あなたの変更が差分ファイル単独でそれ自身を良く表現できない場合は (例えば, ファイルの追加, 削除または名称変更が必要など), 新たなファ イルをまとめて出した方が良いでしょう. 差分ファイルと他のファイルの 削除 / 名称変更の指示を tar ファイルに格納し, uuencode(1) プログラムにかけてから &a.hackers; へ送ってく ださい. このファイルのバンドル方法に関する詳しい情報については, tar(1) と uuencode(1) のマニュアルページを参照し てください. 例えばあなたがそれ自身のさらなる配布を管理するコピーライト問題を良 く分かっていないとか, 単に厳しいレビューをおこなっておらず, リリース する準備ができていないなど, あなたの変更が潜在的に不安定な性質をも つものである場合, &a.hackers よりむしろ &a.core; へ送ってください. コアチームメーリングリスト宛のメールは, 日々の仕 事のほとんどを FreeBSD でおこなっている人たちの, より小さなグルー プに届きます. このグループもまたとても忙しい ことに注意し て, hackers への投稿が本当に実際的でない場合に, コアチームの彼らに メールを送るだけにしてください. コーディングスタイルに関する情報は man 9 intro および man 9 style を参照してください. コードを提出する前には, 少なくともこの情報を意識しておいてくださるようお願いします. 新たなコードやメジャーな付加価値の高いパッケージ

重要な大きい仕事の寄贈や, 重要な新しいフィーチャーを FreeBSD に追加 する場合には, 変更点を tar/uuencode したファイルにして送るか, それ らを私たちの ftp サイト へアップロードす ることのどちらかが通常必要になります. 大量のコードを伴った仕事の場合, コピーライトの神経過敏な問題が常に 出てきます. FreeBSD に含めるコードのコピーライトとして受け入れるこ とができるのは, 以下の二つです: BSD コピーライト. このコピーライトは「権利に縛られない」性格 と商用企業にとって一般的な魅力をもつために最も好まれま す. FreeBSD プロジェクトは商用利用を阻んだりせず, 何かを FreeBSD へ投資する気になった商業関係者による参加を積極的に奨励 します. GNU一般公有使用許諾, または「GPL」. このライセンスはコード を商用目的に使用する場合に余分な努力が求められるため, 私たち にあまり評判が良いというわけではありません. しかし, 私たちは 既に GPL 下の高品質なコード (コンパイラ, アセンブラ, テキスト フォーマッタ等) の提供を受けており, 私たちは現在それを必要と しています. そのため, このライセンスによる新たな貢献を拒絶す るというのは愚かなことでしょう. GPL 下のコードはソースツリー の別の部分, 現在のところ /sys/gnu か /usr/src/gnu に入っています. そのため, GPL が問題と なるような人は, 誰でも簡単にそれとわかるようになっています.

これ以外のタイプのコピーライトによる寄贈は, FreeBSD へ含めることを 考慮する前に, 注意深いレビューを受けなければなりません. 作者が独自 のチャネルを通して配布しており, そのような変更をおこなうことを常に 奨励している場合でも, 特に限定的な商用のコピーライトが適用される寄 贈は一般に拒否されます. あなたの作品に「BSD-スタイル」のコピーライトを付けるには, 保護した いソースコードファイルすべての一番最初に以下のテキストを入れて, `%%' の間を適切な情報に置き換えください. Copyright (c) %%適切な年%% %%あなたの名前%%, %%あなたの州%% %%郵便番号%%. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer as the first lines of this file unmodified. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS SOFTWARE IS PROVIDED BY %%あなたの名前%% ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL %%あなたの名前%% BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. $Id$ 便宜をはかるため, このテキストのコピーは次の場所に置いてあります. /usr/share/examples/etc/bsd-style-copyright. &porting; 金銭, ハードウェアまたはインターネットアクセス

FreeBSD プロジェクトの目的を進めるための寄付や, 私たちと同じような ボランティアの細く長い ! 努力を, 私たちは常に喜んで受け入れています. また一般的に私たちは自分達で周辺機器を買う資金が不足しているため, 周辺機器のサポートを充実させるのにハードウェアの寄付はとても重要です. 資金の寄付

FreeBSD プロジェクトは501(C3) (非営利) 企業ではないため, いかなる寄 付に対しても特別な税金の優遇措置を提供することができません. このような 寄付はプロジェクトを代表して FreeBSD, Inc により感謝をもって受け入れら れるでしょう.

FreeBSD, Inc.は FreeBSD プロジェクトの推進とプロジェクトに企業とし ての最小限の体裁を持たせることを目的として, 1995年の初めに &a.jkh と &a.davidg により設立されました. 寄付されたすべての資金は (最終的に FreeBSD, Inc.によりもたらされるであろうすべての利益も同様に) プロジェク トの目標を推進するためだけに使われるでしょう. 支払い先を FreeBSD, Inc. とした小切手を, 次の住所気付けで送ってください: FreeBSD, Inc. c/o Jordan Hubbard 4041 Pike Lane, suite #D. Concord CA, 94520 [私書箱が開設されるまで一時的に Walnut Creek CDROM の住所を使用] 電信振替は次の所まで直接送れるでしょう: Bank Of America Concord Main Office P.O. Box 37176 San Francisco CA, 94137-5176 Routing #: 121-000-358 Account #: 01411-07441 (FreeBSD, Inc.) もし の節で匿名を希望される 方は, 寄付の際にその旨お伝えください. Thanks! ハードウェアの寄贈

FreeBSD プロジェクトは, 次の3つのカテゴリのどんなハードウェアの寄贈 も, 喜んで受け付けます: ディスクドライブ, メモリまたは完全なシステムといった一般用途のハー ドウェアは, 資金の寄付の節にある FreeBSD, Inc. の住所まで送っ てください. 進行中の受け入れテストのためのハードウェアが必要とされていま す. 新たなリリース毎に適切な逆行テストができるように, 私たちは現在, FreeBSD がサポートするすべてのコンポーネントのテストラボを設置しよう としています. 私たちにはまだ, たくさんの重要な部品 (ネットワークカード, マザーボードなど) が不足していますので, このような寄贈をしたいと思って いるならば, &a.davidg へコンタクトしてどの部品がまだ必要とされているか の情報を得てください. 現在 FreeBSD にサポートされていないハードウェアで, サポートに追 加して欲しいもの. 私たちがそれらの荷物を受けとる前にそのタスクを引き受け てくれる開発者を探す必要があるため, その部品を送る前に &a.core; にコンタクトを取ってください. インターネットアクセスの寄付

私たちは常に FTP, WWW や sup の新しいミラーサイトを募集しています. ミラーサイトになりたい場合には にコンタクトを取って, 詳し い情報を手に入れてください. 寄贈者ギャラリー

FreeBSD プロジェクトは次の寄贈者に恩義を受けており, ここに公表して 感謝の意を表したいと思います. は, FreeBSD のさらなる開発のための資金を気前良く寄付してくださいま した. は, FreeBSD の開発のための資金を気前 良く寄付してくださいました. は, FreeBSD の開発のための資金を気前良く寄付して くださいました. 日本の は, FreeBSD の NEC PC98 への移植である FreeBSD for PC98 CD の販売利益の一部を, 気前良く寄付 してくださいました. は, 言い表せないほど多くの寄付をしてくださいました (詳細はを参照). 特に, 私たちのプライマリ開発マシンである freefall.FreeBSD.ORG, 私たちのテストおよびビルドマシン であるthud.FreeBSD.ORG で使用しているハードウェアに対し 感謝したいと思います. また彼らには, 数年にわたる色々な貢献者への資金提供や, インターネッ トへの T1 コネクションの無制限使用を提供してもらったという恩義があり ます. は, &a.joerg; を根気良くサポートしてくださいました. 彼は本職より FreeBSD の仕事を好みがちであり, 彼個人の接続があまりに 遅くなったり途切れたりして仕事にならない時は必ず interface business の (非常に高価な) EUnet インターネット接続に頼ったものです... diff --git a/ja_JP.EUC/handbook/sup.sgml b/ja_JP.EUC/handbook/sup.sgml index 7d2e7edc3d..d80243dcb5 100644 --- a/ja_JP.EUC/handbook/sup.sgml +++ b/ja_JP.EUC/handbook/sup.sgml @@ -1,158 +1,158 @@ - + SUP

原作: &a.jkh; and &a.gclarkii;.

訳: &a.iwasaki;.28 December 1996. SUP は CMU で開発されたネットワークベースのソフトウェア更新ツールです. この文書の目的は初心者が sup を利用できるようにすることです. SUP のコンフィグレーション

SUP は supfile と呼ばれるコンフィグレーションファイルから, 実行す るのに必要な情報を取得します. FreeBSD のソースリリースによって提供さ れる異なる supfile の見本があります. は最新の標準 FreeBSD ソース配布ファイルの sup 情報を含んでいます - このファイルは sup に, 何のコレクションが更新かつ / またはインストールされるか, ど こにインストールされるかを伝えます. 特にこの supfile を使用している 人は, を sup することになります.

ports に関しては, に目を通してください.

もしソースツリーを構築する files ファイルの入手に興味があるのでしたら, を参照してください.

むしろ -stable 支流への変更を追いかけたいのであれば, 代わりに を参照してください. アメリカ合衆国内に住んでいる方は, DES コードを持ってくるために `secure' と `eBones' コレクションの行のコメントを外してください. 合衆国国外にいる方は, 合衆国の輸出規制を犯すことになるので, このコー ドをsup.FreeBSD.ORG から sup すべきではありません. この代わりに sup examples ディレクトリ内にある を使用してください. これは secure 配布ファイ ルを含む国際的な sup サイトへ接続します. 受けとりたくない配布ファイ ルは, 配布ファイルの行の先頭にて &num でコメントアウトすることができ ます. 代替の sup サーバの一覧は, を参照してください. 現在, 上 記の見本ファイルにあるデフォルトの sup サーバ (sup.FreeBSD.ORG) は超 負荷の状態であるので, どんなトラフィックでも他のホストへ乗り換えられ れば, いくらか重荷が軽減できるでしょう. このセットアップが終れば準備完了です. sup の起動は: sup supfile とタイプします. sup が何をしているかを「冗長に」に見たいなら, 次のように -v を与えてください: sup -v supfile 以上です! あなたが current を実行しているかどうか, standard-supfile で sup するときに得られるものが何かを覚えておき, &a.current へ参加して ください. -current ユーザとしてのあなたに対して, 私たちが何ができて 何ができないかの重要な情報として, を 読んでおいた方がよいでしょう. stable-supfile をお使いの方は, &a.stable へ参加し を 読んでください. SUP 配布ファイル

standard-supfile を使用したメインの FreeBSD 配布ファイルは: src-base: /usr/src/... /usr/src のトップにあるその他のファイル src-bin: /usr/src/bin ユーザとシステムのバイナリ src-secure: /usr/src/secure DES のソース (US/Canada ONLY) src-eBones: /usr/src/eBones Kerberos と DES (US/Canada ONLY) src-etc: /usr/src/etc システムファイル src-games: /usr/src/games ゲーム src-gnu: /usr/src/gnu GNU Public License 下にあるソース src-include: /usr/src/include インクルードファイル src-sys: /usr/src/sys カーネルのソース src-lib: /usr/src/lib ライブラリ src-libexec: /usr/src/libexec システムバイナリ src-release: /usr/src/release release を構築するために必要なソース src-share: /usr/src/share 色々な共有リソース src-sbin: /usr/src/sbin シングルユーザのシステムバイナリ src-tools: /usr/src/tools 色々な管理ツール src-usrbin: /usr/src/usr.bin ユーザバイナリ src-usrsbin: /usr/src/usr.sbin システムバイナリ

secure-supfile を使用した国際的な FreeBSD 配布ファイルは: src-secure: /usr/src/secure DES のソース src-eBones: /usr/src/eBones Kerberos と DES

また, 輸出規制のあるソフトウェア (たとえば, src-secure と src-eBones コレクション) の両方のバージョン (合衆国内または 国外) を除く, 上記すべてを含むコレクションがあります: src-all: /usr/src オペレーティングシステム全体 (ほぼすべて)

そして ports コレクションは: ports-base: /usr/ports/... /usr/ports のトップにあるその他のファイル ports-archivers: /usr/ports/archivers アーカイビングのツール ports-astro: /usr/ports/astro 天文学関連の ports ports-audio: /usr/ports/audio サウンドサポート ports-benchmarks: /usr/ports/benchmarks ベンチマークプログラム ports-cad: /usr/ports/cad CAD ツール ports-chinese: /usr/ports/chinese 中国語サポート ports-comms: /usr/ports/comms 通信ソフトウェア ports-databases: /usr/ports/databases データベース ports-devel: /usr/ports/devel 開発ユーティリティ ports-editors: /usr/ports/editors エディタ ports-emulators: /usr/ports/emulators 他の OS のエミュレータ ports-games: /usr/ports/games ゲーム ports-graphics: /usr/ports/graphics 色々なグラフィックユーティリティ ports-japanese: /usr/ports/japanese 日本語サポート ports-lang: /usr/ports/lang プログラミング言語 ports-mail: /usr/ports/mail メールソフトウェア ports-math: /usr/ports/math 数値計算ソフトウェア ports-mbone: /usr/ports/mbone MBone アプリケーション ports-misc: /usr/ports/misc 色々なユーティリティ ports-net: /usr/ports/net ネットワーキングソフトウェア ports-news: /usr/ports/news USENET ニュースのソフトウェア ports-plan9: /usr/ports/plan9 Plan9 からの色々なプログラム ports-print: /usr/ports/print 印刷ソフトウェア ports-russian: /usr/ports/russian ロシア語サポート ports-security: /usr/ports/security よりよい (悪い?) 「セキュリティ」関連のユーティリティ ports-shells: /usr/ports/shells 色々な UN*X シェル ports-sysutils: /usr/ports/sysutils システムユーティリティ ports-vietnamese: /usr/ports/vietnamese ベトナム語サポート ports-www: /usr/ports/www WWW 関連のソフトウェア ports-x11: /usr/ports/x11 X11 のソフトウェア

また, 上記すべてを含むコレクションがあります: ports-all: /usr/ports ports ツリー全体 diff --git a/ja_JP.EUC/handbook/synching.sgml b/ja_JP.EUC/handbook/synching.sgml index 86f5d0223b..10606864ef 100644 --- a/ja_JP.EUC/handbook/synching.sgml +++ b/ja_JP.EUC/handbook/synching.sgml @@ -1,52 +1,52 @@ - + インターネットを通じたソースツリーの同期

原作: &a.jkh;.

訳: &a.iwasaki;.28 December 1996.

インターネット接続 (または電子メール) を使用して, あなたの興味の対 象によって FreeBSD プロジェクトのソースのある一部分または全体の最新を 追いかける方法は色々あります. 私たちが提供している基本的なサービスは CVSup と CTM です:

CVSup は目下売り出し中で, sup のすべての機能プラスαをそな え, 要求するサーバのディスクスペースとネットワーク資源の観点からずっと 効果的に動作します. このため, CVSup は FreeBSD プロジェクトにおいて の大部分を置き換えました. また, sup のように pull 同期モデルで動作します.

一方, CTM はあなたが持っているソースとマスタアーカイブ上に あるそれとの対話的な比較をおこないません. そのかわりに, 前回の実行時からの変更を認識するスクリプトがマスタアーカ イブ上で一日に数回実行され, すべての変更を compress して通し番号を振り, さらに電子メールで転送できるようにエンコードします (印字可能な ASCII キャラクタのみです). 受信した後は, これらの「CTM のデルタ」は自動 的にデコード, 検査してユーザのソースのコピーに変更を適用する ctm_rmail(1) によって処理可能となります. この処理は CVSup よりずっと効率 的であり, pull モデルというよりむしろ push モデルで あるため, 私たちのサーバ資源の負荷は軽くなります.

もちろん他のトレードオフもあります. あなたが CVSup でうっかりアーカイブ の一部を消してしまっても, CVSup は壊れた部分を検出して再構築してくれます. CTM はこれをやってくれません. もしソースツリーの一部を消してしまったら, 一からやり直して (最新の CVS 「ベースデルタ」から) すべてを再構築しなければ なりません. CVSup と CTM, あるいは今では時代遅れとなってしまった sup についての 詳しい情報については, 以下の節を参照してください: &ctm; &cvsup; ⊃ diff --git a/ja_JP.EUC/handbook/term.sgml b/ja_JP.EUC/handbook/term.sgml index e7d676d9c7..d51941f6ed 100644 --- a/ja_JP.EUC/handbook/term.sgml +++ b/ja_JP.EUC/handbook/term.sgml @@ -1,527 +1,527 @@ - + シリアル端末

原作: &a.kelly;28 July 1996

訳: &a.max; シリアル端末を利用することで, コンピュータのコンソールのそばにいないと きや, 手近にネットワーク接続されているコンピュータがないときでも, FreeBSD の機能を便利に, かつ安価に利用することができます. ここでは, FreeBSD にシリアル端末を接続する方法を解説します. 端末の種類と利用方法

もともと Unix システムにはコンソールがありませんでした. ユー ザはコンピュータのシリアル ポートに接続された端末からログインして プログラムを利用していました. ちょうどモデムと通信ソフトを使ってリモート のコンピュータにログインし, テキスト ベースのプログラムを利用するのと よく似ています. 最近の PC は, 高品質の画像を表示できるコンソールを搭載していま すが, ほとんどすべての Unix 系 OS には未だにシリアル ポートを使ってログ インするための機能があり, FreeBSD でもこの機能がサポートされています. 現在使用されていないシリアル ポートに端末を接続することでシステムに ログインし, 通常はコンソールや Xウィンドウ システムの 以下は, それぞれについての解説です. ダム端末

ダム端末は, シリアルライン経由でのコンピュータとの接続専 用のハードウェアです. ダム端末は, テキストの送受信および表示ができる 程度の計算能力しかもっていないので, ``dumb'' (間抜け) というように呼ば れています. この端末上でプログラムを実行することはできません. テキスト エディタ, コンパイラ, E-mail, ゲームなどなどのプログラムを実行するのは, ダム端末を接続しているコンピュータの方です. Digital Equipment社の VT-100 や, Wyse社の WY-75 を初めとして, 多くのメーカが何百種類もの ダム端末を作っています. ほとんどどんな種 類のダム端末でも FreeBSD に接続して使用できます. さらに, 高性能の端 末の中には画像を取り扱えるものもありますが, 限られた数のソフトウェア パッケージしかこういった機能には対応していません. ダム端末は, X ウィンドウ システムで提供されるようなグラ フィックアプリケーションを必要としない職場で広く用いられています. PC を端末として利用する

がテキストの表示およ び送受信の機能をそなえただけのものならば, 言うまでもなく, どんなPC もダム端末になり得ます. 必要なものは適切なケーブルと, そのPCの上 で動作するX 端末

X 端末は, 既存のものの中で最も洗練された種類の端末といえ ます. X 端末は, たいていの場合シリアル ポートで゜はなく, イーサネッ トのようなネットワークを利用した接続をおこないます. また, アプリケーション の利用においても, テキストベースのものだけでなく, X アプリケーション の利用が可能です. ここでは, 参考までに 端末について紹介しただけで, X 端 末の設定や利用についての解説はケーブルとポート

シリアル端末を FreeBSD システムに接続するためには, 適切なケー ブルと, 端末を接続するためのシリアルポートが必要です. ここでは, これ らについて説明します. もし既にあなたの利用したい端末と, その端末 を接続するためのケーブルについてよく理解していれば, の章まで読み飛ばしてください. ケーブル

端末の接続は, シリアルポートを利用します. そこで, 端末を FreeBSD システムに接続するためには, シリアルケーブル (RS-232C ケーブ ルとも呼ばれています) が必要となります. シリアルケーブルには2種類のケーブルがあります. どちらの種類の ケーブルを使わなければいけないかは, どんな端末を接続したいかによります. もし, PC を端末として利用したい場合は, ケーブル (リバースケーブルもしくは クロスケーブルと呼ばれることもしばしばあります) を使用してください. ヌルモデムケーブルは, コンピュータ同士や端末同士を接続するために用い られるケーブルです. もし, 本物の端末を接続するのであれば, その端末につい てきたドキュメントからどのようなケーブルを使うべきか調べてください. も しドキュメントがない場合は, まず ケーブルを試してみて, うまくいかない場合は ケーブル (しばしばストレートケーブルと呼 ばれます) を試してみてください. また, 端末側と FreeBSD 側の ヌルモデムケーブル

ヌルモデムケーブル (またはリバースケーブルあるいはクロ スケーブル) は, たとえば ``signal ground'' 信号のように, いくつかの信 号はそのまま通しますが, 他の信号は途中で入れ替えて通します. たとえば, ``send data'' 信号のピンは, 反対側のコネクタの ``receive data'' 信号の ピンと繋がっています. 自分で使うケーブルは自分で作りたいということであれば, 以下にター ミナルを接続する際に推奨されるヌルモデムケーブルの結線を示しておきま す. この表では, RS-232C の信号線の名前と, DB-25 コネクタ上のピンの番 号を示しています. Signal Pin# Pin# Signal TxD 2 ----------------------- 3 RxD RxD 3 ----------------------- 2 TxD DTR 20 ----------------------- 6 DSR DSR 6 ----------------------- 20 DTR SG 7 ----------------------- 7 SG DCD 8 ----------------------+ 4 RTS* *RTS 4 + + 5 CTS* *CTS 5 +---------------------- 8 DCD * まず, コネクタ内部でピン4を5に接続し, そして逆側のコネクタのピン8と接 続します. スタンダード RS-232C ケーブル

スタンダードシリアルケーブル (またはストレートケーブル) の場合は, すべての RS-232C 信号をそのまま通します. つまり, 片方の ``send data'' 信号のピンは, 逆側の ``send data'' 信号のピンと繋がっています. モデムを FreeBSD に接続するときや, 一部の端末を接続するときにこのタイプの ケーブルを使用します. ポート

シリアルポートは, FreeBSDが動作しているホスト コンピュータと端 末の間でデータのやりとりを行うために用いるデバイスです. ここでは, 現在存在するポートの種類と FreeBSD でのポートのアクセス方法について解 説します. ポートの種類

シリアルポートには何種類かのものがあります. ケーブルを購 入したり自作したりする前に, そのケーブルのコネクタの形状が端末および FreeBSD システムのポートの形状と一致していることを確認してください. ほとんどの端末は DB25 ポートを搭載しています. FreeBSDが動作しているも のを含めて, PCは DB25 または DB9 ポートを搭載しています. マルチポート のシリアルカードの場合は, RJ-12 や RJ-45 のポートを搭載しているかもし れません. 利用されているポートの種類に関しては, ハードウェアについてきたドキュメ ントを参照してください. また, 多くの場合, ポートの形状から判断すること もできるでしょう. ポートの名前

FreeBSDでは, /dev ディレクトリ内のエントリを介 してシリアルポートへのアクセスがおこなわれます. 2種類の異なったエン トリがあります. 着信用のポートの名前は, /dev/ttyd (発信用のポートの名前は, /dev/cuaa となっています. 発信用のポートは普通モデムの接続に用い, 端末の接続には 利用しません. ただ, ケーブルまたは端末がキャリア検出信号を使えない タイプのものの場合は, 発信用のポートを使うとよいでしょう. 詳しくは, sio(4) のマニュアルをご覧ください. たとえば, 端末を一つ目のシリアルポート (DOS でいうところの COM1) に接 続したとすると, /dev/ttyd0 がこの端末を指すことになります. また, 二つ目のシリアルポート (COM2) ならば /dev/ttyd1 となり, 以下この形式のデバイスエントリを使います. 各シリアルポート, 特にマルチポートのシリアルカードを利用する ために, kernel の設定をおこなう必要がある場合がありますので, 注意してくだ さい. 詳しくは, をご覧ください. 設定

ここでは, 端末からのログインを可能にするために必要な FreeBSD 側の設定について解説します. 既に端末を接続するポートが利用できるように kernel の設定をおこない, 端末が接続されているものと考えて, 解説を進め ます. 簡単に言えば, プロセス管理や初期化をおこなっている /etc/ttys の内容を編集する必要があります. まず, /etc/ttys に以下の 変更を加えてください. 端末を接続するポートの /dev のエントリが含ま れている行がまだ存在しなければ, これを /etc/ttys に追加してく ださい. /usr/libexec/getty が対象となるポートに対して 実行されるように指定してください. また, /etc/gettytab ファイ ル内の適切な デフォルトのターミナルタイプを指定してください. 対象となるポートを ``on'' に設定してください. そのポートが ``secure'' であるかどうかを指定してくださ い. /etc/ttys を読み込みなおさせてく ださい. また, 必要に応じて /etc/gettytab を変更し, 上の 2で使用する /etc/ttys について, より詳しくは, ttys(5) のマニュアルをご覧 ください. /etc/ttys へのエントリの追加

既にエントリがある場合を除いて, まず初めに /etc/ttys にエントリを追加しなければいけません. /etc/ttys には, FreeBSDシステム上のログインを許可するすべての ポートを記述します. たとえば, 一つ目の仮想コンソール /dev のエントリを, /dev の部分 を省略して記述します. FreeBSD のインストール当初の状態では, /etc/ttys に記述され ています. これらのポートのいずれかに端末を接続する場合は, 新たなエント リを追加する必要はありません. ここで紹介している例では, 既にファイルにエントリが存在する 2番目のシリ アルポート, /etc/ttys か ら抜粋して示します. ttyd1 "/usr/libexec/getty std.9600" unknown off secure ttyd5

次に, 端末からのログインを処理するプログラムの指定をおこな います. FreeBSDでは, 標準的には /usr/libexec/getty をこの目的 で利用しています. /etc/gettytab から 読み込みます. ファイル /etc/gettytab には, 新旧の端末に関する多数のエントリ が記述されています. ほとんどの場合, /etc/ttys の /etc/ttys の設定です. ttyd1 "/usr/libexec/getty std.38400" unknown off secure ttyd5 "/usr/libexec/getty std.19200" ここで, 実行するプログラムを指定している 2番目のフィールドが, ダブルクォー テーションに囲まれていることに注意してください. こうしないと, デフォルトのターミナルタイプの指定

/etc/ttys の 3番目のフィールドには, そのポートのター ミナルタイプのデフォルトを指定します. ダイアルアップ用のポートの場合 は, ユーザがどのタイプの端末あるいは通信ソフトを利用してダイアルアップ してくるかは分からないので, /etc/ttys の中でターミナルタイプが指定されていれば, このプロンプトを表示せずに先に進むことが可能です. FreeBSD 上で, どのターミナルタイプを利用できるかは, /usr/share/misc/termcap をご覧ください. このファイルには, お よそ 600 のターミナルタイプが定義されています. 必要ならば, 新たなエン トリを追加することも可能です. 詳しくは termcap(5) のマニュアルをご覧く ださい. 紹介している例では, Wyse-50 のターミナルタイプは Wyse-50 です (もっ とも他のタイプをエミュレートすることも可能ですが, ここでは Wyse-50 モー ドで使用します. ). また, 286マシン上では Procomm が VT-100 エミュレー ションをおこなうように設定されています. 以下が, まだ未完成の /etc/ttys の関連部分です. ttyd1 "/usr/libexec/getty std.38400" wy50 off secure ttyd5 "/usr/libexec/getty std.19200" vt100 ポートを利用可能にする

/etc/ttys のつぎのフィールド, つまり 4番目のフィー ルドは, そのポートをアクティブにするかどうかの設定です. このフィールド に ``on'' を指定すると, /etc/ttys です. それぞれのポートを ttyd1 "/usr/libexec/getty std.38400" wy50 on secure ttyd5 "/usr/libexec/getty std.19200" vt100 on ``secure'' なポートの指定

とうとう最後のフィールドの設定です. (実際にはここでは触れ ませんが, オプショナルな/etc/ttys のエントリに端末の場所を表 すコメントを追加したものを示します. ttyd1 "/usr/libexec/getty std.38400" wy50 on insecure # Kitchen ttyd5 "/usr/libexec/getty std.19200" vt100 on insecure # Guest bathroom /etc/ttys の再読み 込みをさせる

FreeBSD をブートすると, 最初に起動されるプロセス, /etc/ttys を読み込んで, 記述されているプログラムを利用可能な ポートに対して実行し, ログインプロンプトを送り出させます. /etc/ttys の編集が終わった後, /etc/ttys を読み込みなおすようになっています. /etc/ttys の変更を保存したら, 以下のようなコマンドを実行して, kill -HUP 1 (トラブルシューティング

細心の注意を払って設定をおこなっても, ときには端末の接続がう まくいかない場合があるでしょう. 以下に, よく見られる問題とその解決方法 を示します. ps -axww|grep getty その端末に対する /etc/gettytab 中の 22189 d1 Is+ 0:00.03 /usr/libexec/getty std.38400 ttyd1 もし, /etc/ttys の中で, そのポートを利用可能にする設定をしたかどう か確かめてください. また, /etc/ttys を修正し てから, diff --git a/ja_JP.EUC/handbook/troubleshooting.sgml b/ja_JP.EUC/handbook/troubleshooting.sgml index 2e02c5e9af..853ed82e50 100644 --- a/ja_JP.EUC/handbook/troubleshooting.sgml +++ b/ja_JP.EUC/handbook/troubleshooting.sgml @@ -1,65 +1,65 @@ - + トラブルシューティング

原作: 不明.

訳: &a.iwasaki;.

インストールに失敗している (あるいは失敗してしまった) 人がうまく いくようにするのに役立つヒントやコツを以下に示します. 注意深く読ん でください. ハードウェアコンフリクトまたはコンフィグレーションのミス

問題: デバイスが他のものとコンフリクトを起こす, また は IRQ やアドレスがカーネルのコンパイル時に設定したものと合って いません. 原因: 今ではほとんどの FreeBSD のデバイスドライバは, 動的にハードウェアの設定に合わせるように十分賢くなっていますが, 中には動作する前にコンパイル時に設定した (そしてハードウェアに 合致する) パラメタをあい変わらず要求するものがまだ少しあります. しぶとく残っているそれらをできる限り多く取り除くように一所懸命 作業しいていますが, 必ずしも見た目ほど簡単なわけではありません. 解決策: 可能な解決策がいくつかあります. 最初に, そし て最も簡単なものは -c フラグをつけてカーネルをブートす ることです. 初期ブートプロンプト (フロッピーディスクかハードディ スクから起動) で: /kernel -c とタイプしてください. メモリのサイジングコードを過ぎてから動的カーネル設定ユーティリ ティが起動されます. コマンドの一覧を見るには, プロンプトで `?' とタイプします. このユーティリティを使用して, IRQ, メモリアドレス, IO アドレスまたはデバイスのたくさんの他の設定パ ラメタを再設定することができます. また動作させたいデバイスに問 題を引き起こすデバイス全体を無効にすることもできます. もう一つの解決策は, 当り前のことですが, 問題のあるハードウェア を取り外すか, 何も考えずに (うまくいけば) 問題がなくなるまでシ ステムを基本的な部品だけの状態に取り去っていくことです. 一度起 動してしまえば, 上に述べたのと同じことができます --- ハードウェ アにより一層合うようにカーネルをコンパイルしたり, 動かなかった もともとのハードウェア設定の原因は何かを一つ一つ明らかにするこ とができます. 初めてブートしたときに, まだ /386bsd を探しています!

原因: 古い FreeBSD 1.x のブートブロックが, まだディスクのブート パーティションに残っています. 解決策: インストールのプロセスをもう一度おこない, (F)disk エディタ を起動して (W)rite オプションを選択する必要があります. すでに存在 するインストレーションに害を与えずに, 確実に新しいブートブロックを ドライブに書き込むことができます. もし初めてインストールしているの でしたら, 新しいブロックを (W)rite することを忘れないでください! :-) diff --git a/ja_JP.EUC/handbook/uart.sgml b/ja_JP.EUC/handbook/uart.sgml index d31a2302c1..a399bba6d0 100644 --- a/ja_JP.EUC/handbook/uart.sgml +++ b/ja_JP.EUC/handbook/uart.sgml @@ -1,1093 +1,1093 @@ - + UART とは何か, そしてどのように動作するか

Copyright © 1996 &a.uhclem;, All Rights Reserved. 13 January 1996.

訳: &a.saeki;, &a.iwasaki;. 11 November 1996.

( ここからは &a.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 コネクタを 使っているので, このことは しばしば混乱を引き起こします.) 以下は DB25 および DB9 コネクタにおける RS-232C 信号の割り当て表です. DB25 DB9 EIA CCITT 一般 信号源 説明 RS-232C IBM PC 回路 回路 名称 端子 端子 符号 符号 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.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

訳注: 具体的なパッケージ形状についての情報は を参照 してください. 「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 MSD ユーティリティの 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 からの相違点の単純なカウントが, 何の相違点が重要であり どれがそうでないのかについて多くを明らかにしないことを理解すること が大切です. 例えば, 内蔵の UART を持つ上記の二つのモデムで報告され た相違点の約半分が, 5及び6ビットキャラクタモードをサポートしないク ローンの UART によって引き起こされました. 本物の 16550, 16450 そし て 8250 UART すべてはこれらのモードをサポートし, COMTEST はこれらの モードの機能性をチェックするので, 50を越える相違点が報告されました. しかし, 5及び6ビットキャラクタモードをサポートするモデムは殆どなく, 特ににこれらはエラー修正と圧縮機能付のものです. これは5及び6ビット キャラクタモードに関連した相違点は差し引いて考えることができること を意味しています. COMTEST が報告した相違点の多くは, タイミングに関する点でしょう. 多くのクローンの設計では, ホストが一つのポートから読み込んだ時に他 のあるポートのステータスビットは, 本当の NS16550AFN と同じ 長さの時間内で更新されない (あるものは速く, あるものは遅く) かもしれ ませんが, COMTEST はこれらの相違点を探します. これは相違点の数は誤 解を招き易いものです. あるデバイスには一つか二つの相違点しかありま せんがそれらは非常に重大かもしれません. また別のデバイスは基準部品 と比べて速くまたは遅く status レジスタを更新するために (適切に書か れたドライバの操作にはまったく影響しないかもしれません) 多くの相違点を 報告されるかもしれません. * この文書の著者は今まで, COMTEST プログラムを使用して相違点がゼロ と報告されるナショナル・セミコンダクタ以外の部品を一つも発見しませ んでした. ナショナル・セミコンダクタは長年に渡り 16550 の五つのバー ジョンを持っており, 最新の部品は機能性のために, ベンチマークを考慮 した古い NS16550AFN と少し異なる振る舞いをすることに注意するべきで す. COMTEST はナショナル・セミコンダクタの製品ラインの相違点につい ては見て見ぬふりをするようになり, 部品のリビジョン A, B そして C にあるバグが記述されている公式な正誤表がある時でも, (オリジナルの 16550 を除いては) ナショナル・セミコンダクタの部品についてエラーを 報告しなくなったので, この COMTEST のひいきを考慮にいれるべきです. 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 Transmit Holding Register (THR) (DLAB==0) このポートに書き込まれた情報はデータ命令として 処理され, UART により送信されます. +0x00 read Receive Buffer Register (RBR) (DLAB==0) シリアル接続から UART によって受信されたすべての データ命令は, このポートを読むことによってホス トによりアクセスされます. +0x00 write/read Divisor Latch LSB (DLL) (DLAB==1) マスタ入力クロックの周波数をこのレジスタに入っ ている値で割ることにより, UART の周波数が決定 されます (IBM PCでは, マスタクロックの周波数は 1.8432MHzです). このレジスタには上記の除数の下 位8ビットが入っています. +0x01 write/read Divisor Latch MSB (DLH) (DLAB==1) マスタ入力クロックの周波数をこのレジスタに入っ ている値で割ることにより, UART の周波数が決定 されます (IBM PCでは, マスタクロックの周波数は 1.8432MHzです). このレジスタには上記の除数の上 位8ビットが入っています. +0x01 write/read Interrupt Enable Register (IER) (DLAB==0) 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 (IIR) 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 を使用する必要はありません. これにより設計者は, より良い 性能特性を持つ部品が自由に利用できます. diff --git a/ja_JP.EUC/handbook/userppp.sgml b/ja_JP.EUC/handbook/userppp.sgml index f5c35b9ef9..edc8a14dda 100644 --- a/ja_JP.EUC/handbook/userppp.sgml +++ b/ja_JP.EUC/handbook/userppp.sgml @@ -1,391 +1,391 @@ - + ユーザ PPP のセットアップ

原作: &a.nik; 28 July 1995.

訳: &a.saeki; 11 November 1996.

ユーザ PPP は FreeBSD 2.0.5-RELEASE において, 既存のカーネル実装版の PPP に加えて導入されました. それでは, この新しい PPP が追加された理由となる ppp との違いは何でしょう ? マニュアルから引用すると: これはユーザプロセス PPP ソフトウェアパッケージです. 通常 PPP は (例えば pppd でそうなっているように) カーネルの一部として 実装されています. そのためデバッグや動作の変更が幾分困難です. しかしこの実装では, PPP はトンネルデバイスドライバ (tun) の 補助により, ユーザプロセスとして実装されています. これは本質として, 常に PPP デーモンを実行しておかないでも, 必要な時に ppp プログラムを実行できるということを意味します. このプログラムはカーネルとのデータ送受のために一般のトンネルデバイスを 使うことができるため, PPP インターフェースをカーネルに組み込んでおく 必要がありません. 以降では, ユーザ ppp と他の PPP クライアント / サーバソフトウェアとを 区別する必要がないので, ユーザ ppp を単に ppp とだけ呼びます. 特に断らない限り, このセクションのすべてのコマンドは root 権限で 実行されるべきです. このセクションでアスタリスクマーク (*) のついている部分は不完全です. コメントや提案は歓迎しますので, &a.nik; まで送ってください. 私が最初にユーザ ppp を実験していた時に, 価値ある情報の宝庫となってくれた Rob Snow <rsnow@txdirect.net> に感謝します. 訳者注: このユーザ ppp は iij-ppp0.94(beta2?) に由来しています. 作者の大野さんは日本の方ですので, iij-ppp には詳細な日本語 ドキュメントが附属しています. オリジナルアーカイブ (iij-ppp0.94beta2.tar.gz) を入手して, そちらを参照されることを 強くおすすめします. スタートの前に

このドキュメントでは, あなたが大体以下のような状況にあると仮定しています: PPP 接続の使えるインターネットサービスプロバイダ (ISP) のアカウントを 持っている. さらに, 接続済みのモデム (または他のデバイス) があり, プロバイダとの接続が可能なように正しく設定されている. 以下の情報を手に入れておく必要があるでしょう: プロバイダのゲートウェイの IP アドレス プロバイダのネットマスク設定 一つ以上のネームサーバの IP アドレス もしプロバイダが固定の IP アドレスとホスト名を割り当ててくれるなら, 同様にそれも必要でしょう. そうでなければ, どの IP アドレス範囲から 割り当てがおこなわれるかを知っておく必要があるでしょう. もしこれらの情報のうち不明なものがあれば, プロバイダに連絡して確認しておいてください. 同様に, カーネルを再コンパイルするためのファイルが必要になるかもしれません. これらを手に入れる方法の詳細については を参照してください. 加えて, インターネットへの接続は常時おこなわれているものではなく, そのためネームサーバ (named(8)) を立ち上げていないと仮定しています. ppp 対応カーネルの構築

説明でも述べているように, ``ppp'' はカーネルの ``tun'' デバイスを使います. そのため, このデバイスがカーネルに組み込まれていることの確認が不可欠です. これを確認するためには, カーネルコンパイルディレクトリ (おそらく /sys/i386/conf) に移動して, カーネルコンフィグレーション ファイルを調べます. 以下の行がどこかに含まれている必要があります. pseudo-device tun 1 元々の GENERIC カーネルは標準でこれを含んでいますので, カスタムカーネルを インストールしていなければ, 何も変更する必要はありません. あなたのカーネルコンフィグレーションファイルに この行が含まれていなければ, この行を追加して カーネルの再コンパイルとインストールをおこなう必要があります. この新しいカーネルを使ってブートしてください. カーネルコンフィグレーションの詳細については, を参照してください. tun デバイスのチェック

私は一つの ``tun'' デバイス (tun0) による ppp の経験しかありません. より多くのデバイスを使う場合 (すなわち, カーネルコンフィグレーション ファイルで疑似デバイスの行に `1' 以外の数値が指定されている場合), 以下のすべての ``tun0'' に対する参照を, あなたが使うデバイスの番号に あわせて変更してください. tun0 デバイスが正しく設定されていることを確認する最も簡単な方法は, それを作り直すことです. そのためには, 以下のコマンドを実行します: # cd /dev # ./MAKEDEV tun0 PPP の設定

これが問題の核心です. まぎらわしいことに, ユーザ ppp と pppd (カーネルレベルの PPP 実装) は ともに, 設定ファイルが /etc/ppp に置かれていると仮定しているようです. しかし, 提供されているサンプル設定ファイルはユーザ ppp 用のものですので, 参照のため手元に置いておきます. これをおこなう最も簡単な方法は, 以下の通りです: # cd /etc # mv ppp ppp.orig # mkdir ppp ppp を設定するためには, 必要に応じて一〜三つのファイルを 編集する必要があります. 書き込む内容はプロバイダが静的に IP アドレスを 割り当てる (すなわち, 一つの IP アドレスが与えられて, 常にそれを使う) か, または動的に IP アドレスを割り当てる (すなわち, PPP セッション毎に IP アドレスが異なる可能性がある) かにある程度依存します. しかし, 静的な IP アドレスを使うか動的な IP アドレスを使うかにかかわらず, 最初にやらなければならないことがいくつかあります. resolver(5) の設定

リゾルバ (resolver) はネットワーキングシステムの一部分で, IP アドレスと ホスト名の変換をおこないます. これは, IP アドレスとホスト名を対応づける マップを二つの場所のうちの一つから探すように設定できます. 一つめの場所は /etc/hosts (man 5 hosts) と呼ばれる ファイルです. 二つめの場所は, 分散データベースである, インターネットドメイン ネームサービスです. これに関する議論はこのドキュメントの範囲を 越えています. リゾルバはマッピングをおこなうシステムコールの集合です. どこからマッピング情報を得ればよいかはあなたが指示しなければなりません. これは /etc/host.conf ファイルを編集することでおこないます. 混乱する可能性があるので, このファイルを /etc/hosts.conf と 呼んでは いけません (余分な ``s'' に注意). このファイルは以下の 2 行を含んでいるはずです. hosts bind これは, 最初に /etc/hosts ファイルを調べ, 目的の名前が見つからなければ DNS を引きにいくようリゾルバに指示します. このマシンで ``named'' サービスが走っていないことを確認しておいた方が 良いでしょう. /etc/sysconfig ファイルをチェックして ``namedflags'' の行を探し, 以下のようになっていることを確認します. namedflags="NO" /etc/hosts(5) ファイルの作成

このファイルはローカルネットワーク上に存在するマシンの IP アドレスと ホスト名を含んでいるはずです. 最低でも ppp を動作させるマシンのエントリを 含んでいなければなりません. あなたのマシンのホスト名が foo.bar.com で, IP アドレスが 10.0.0.1 であると仮定すると, /etc/hosts は 以下の行を含んでいなければなりません: 127.0.0.1 localhost 10.0.0.1 foo.bar.com foo 最初の行は別名 ``localhost'' を現在のマシンの同義語として定義しています. 固有の IP アドレスによらず, この行の IP アドレスは常に 127.0.0.1 で なければなりません. 二つめの行はホスト名 ``foo.bar.com'' (そして別名 ``foo'') を IP アドレス 10.0.0.1 にマップします. もしプロバイダが固定の IP アドレスを割り当ててくれるなら, それを 10.0.0.1 のかわりに使ってください. /etc/resolv.conf ファイルの作成

/etc/resolv.conf はネームサーバをそのマシンで走らせていない場合に 必要となる特別な情報を含んでいます. これは実際のネームサーバの位置を リゾルバルーチンに指示したり, その他いくつかの情報を指定したりします. 少なくとも /etc/resolv.conf は問い合わせ可能なネームサーバを 示す 1 行を含んでいる必要があります. これは (ホスト名ではなく) IP アドレスで書かれていなければなりません. 私の /etc/resolv.conf は以下の行を含んでいます: nameserver 158.152.1.193 nameserver 158.152.1.65 これはプロバイダ Demon Internet の二つのネームサーバです. あなたのプロバイダのネームサーバ行をすべて書いてください. PPP と静的 IP アドレス

これはおそらく設定が最も楽でしょう. 必要なのは /etc/ppp ディレクトリにファイルを三つ作成することだけです. 一つめのファイルは ppp.conf です. 以下の例と似たような ものになるでしょう. ``:'' で終る行は 1 カラム目から始まり, その他の行は この例の通りにインデントされるべきだということに注意してください. /etc/ppp/ppp.conf 1 default: 2 set device /dev/cuaa0 3 set speed 9600 4 disable lqr 5 deny lqr 6 set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" ATE1Q0 OK-AT-OK \\dATDT\\T TIMEOUT 40 CONNECT" 7 provider: 8 set phone 01234567890 9 set login "TIMEOUT 10 gin:-BREAK-gin: foo word: bar col: ppp" 10 set timeout 120 11 set ifaddr x.x.x.x y.y.y.y 行番号はファイルには含めないでください. これは説明のためのものです. /dev/cuaa0 で, COM2: は /dev/cuaa1 です. chat(8) 言語を 使用します. この言語の仕様についての情報はマニュアルを 参照してください. J. Random Provider login: foo password: bar protocol: ppp このスクリプトを必要に応じて書き換える必要があるでしょう. これは chat(8) 言語で書かれています. 次に /etc/ppp/ppp.linkup ファイルを編集しなければなりません: x.x.x.x: add 0 0 HISADDR 先ほどと同じように x.x.x.x をあなたの IP アドレスで置き換えます. このファイルは, あなたのマシンからプロバイダ (HISADDR マクロは プロバイダのアドレスで自動的に置き換えられます) へのルートを デフォルトルートとして自動的に追加するのに使われます. 最後に, /etc/ppp/ppp.secret ファイルを作成します. 同じ ppp システムを使う他のユーザの不正使用を防ぐためパスワードを 設定します. どれだけの人がこの ppp システムを触るかによって, これを設定したいと思うかもしれません. PPP と動的 IP 設定

プロバイダから静的な IP アドレスの割り当てを受けていない場合, ローカル IP アドレスとして 0 を指定することで ppp が リモートホストとの交渉によりローカルアドレスを決定するように設定できます. set ifaddr 0 0 詳細については ppp(8) のマニュアルを参照してください. システムの最終設定

これで PPP の設定は終りました. しかし PPP の動作準備が完了するのには もう少し必要なことがあります. それはすべて /etc/sysconfig ファイルの編集に含まれています. このファイルを上から順に設定していきます. まず ``hostname='' の行が 設定されていることを確認します. 例えば, hostname=foo.bar.com 次に network_interfaces 変数を探し, tun0 デバイスがリストに追加されて いることを確認します. 私の設定では以下のようになっています. network_interfaces="lo0 tun0 ep0" 他に私はイーサネットカード (ep0) も持っているので, 同様に設定しています. 次に tun0 デバイスのための ifconfig 行を追加します. それは以下のようなものになるでしょう. ifconfig_tun0="inet foo.bar.com y.y.y.y netmask 0xffffffff" 先ほどと同じように, ``foo.bar.com'' はあなたのホスト名に, y.y.y.y はプロバイダのゲートウェイの IP アドレスに, 0xffffffff は (16 進で) プロバイダから指定されたネットマスクに変更します. ネットマスクとしては以下の二つの値がよく用いられます. 255.255.255.255 = 0xffffffff 255.255.255.0 = 0xffffff00 routed フラグを以下のように ``-s'' に設定します. routedflags=-s ``sendmail_flags'' 行が ``-q'' オプションを含まないようにしておくことは, おそらく, やっておくだけの価値があるでしょう. さもなければ, ネットワークからアドレスを引こうとして sendmail が 時々発信をおこなってしまうでしょう. 私の sendmail 行は次の通りです. sendmail_flags="-bd" この結果, 私は PPP リンクを立ち上げた時はいつでも以下のようにタイプして, sendmail に mailqueue を調べ直させなければなりません. # /usr/sbin/sendmail -q これが静的 IP アドレスで PPP を動作させるために必要なすべてのはずです. 後はマシンをリブートするだけです. スタートアップの間に tun0 デバイスが 検出され, 以下のような 2 行が表示されると思います. tun0: flags=51 mtu 1500 inet x.x.x.x --> y.y.y.y netmask 0xffffffff この時点で, ppp は完全に動作するはずです. 以下のうち好きなほうを タイプしてください. # ppp その後 PPP セッションを開始させるために ``dial provider'' をタイプします. または, 外向きのトラフィックが発生した時に ppp が自動的にセッションを 確立してくれるようにしたければ, 以下をタイプします. # ppp -auto provider この行を /etc/rc.local ファイルに追加しておくのも良いでしょう. diff --git a/ja_JP.eucJP/books/handbook/book.sgml b/ja_JP.eucJP/books/handbook/book.sgml index 4067da52cf..22cd1f057c 100644 --- a/ja_JP.eucJP/books/handbook/book.sgml +++ b/ja_JP.eucJP/books/handbook/book.sgml @@ -1,185 +1,185 @@ - + %authors; %jmembers; %lists; %sections; ]> FreeBSD ハンドブック FreeBSD ドキュメンテーションプロジェクト 1996年12月 FreeBSD へようこそ! このハンドブックはFreeBSD Release &rel.current;のインストールおよび, 日常での使い方について記述したもので, FreeBSD ドキュメンテーションプロジェクトによって編集されています. 日本語版の作成は FreeBSD 日本語ドキュメンテーションプロジェクトがおこなって います. 本書は現在進行中の作業であって, 多くの個人の手からなる 仕事です. 多くのセクションはまだ存在しませんし, いま存在するセクションの いくつかはアップデートが必要です. この FreeBSD ドキュメンテーション プロジェクトに協力したいと思ったら, &a.doc; まで (英語で) 電子メールを 送ってください. ハンドブックそのものに関する議論は, こちらで おこなわれています. (もちろん英語でです.) 日本語訳および, 日本語版のみに関することは &a.doc-jp; において日本語で 議論されています. 必要に応じて日本語ドキュメンテーションプロジェクトから 本家ドキュメンテーションプロジェクトに対してフィードバックをおこないますので, 英語が得意でない方は &a.doc-jp; まで日本語でコメントをお寄せください. このドキュメントの最新バージョンは, いつでも や から入手できますし, や, たくさんあるからプレインテキスト, postscript, HTML などの形式でダウンロードすることもできます. また, も可能です. 基礎 はじめに

FreeBSD は, Intel アーキテクチャ (x86) ベースの PC のための 4.4BSD-Lite をベースとしたオペレーティングシステムです. FreeBSD の概要については, をご覧ください. このプロジェクトの歴史については, をご覧ください. 最新のリリースについての記述は, をご覧ください. FreeBSD プロジェクトへの何らかの貢献 (ソースコード, 機器, 資金の提供など) について興味があれば, の章をご覧ください. &nutshell; &history; &goals; &development; &relnotes; &install; &basics; アプリケーションのインストール * パッケージのインストール &ports; システム管理 &kernelconfig; ユーザ, グループ, セキュリティ &crypt; &skey; &kerberos; &firewalls; &printing; "as; X ウィンドウシステム

この節の完成は保留にしてあります. から提供されるドキュメントを参考にしてください. &hw; ネットワーク通信 シリアル通信 &serial; &term; &dialup; &dialout; PPP と SLIP

もしあなたがモデムを使ってインターネットに接続したり, 他の人々に FreeBSD によるインターネットへのダイヤルアップ接続を 提供しようとしているのでしたら, PPP または SLIP 接続を選択することができます. PPP 接続には, 2 種類の方法が提供されています: ユーザPPP (iijppp とも呼ばれます) とカーネルPPP です. 両方の PPP の設定手順と, SLIP の設定方法については以下の章に書かれています. &userppp; &ppp; &slipc; &slips; 高度なネットワーク &routing; &nfs; &diskless; * イエローページ/NIS &isdn; &mail; さらに進んだ話題 ¤t; &stable; &synching; &submitters; &troubleshooting; &kerneldebug; &kernelopts; &linuxemu; FreeBSD の内部 &booting; &memoryuse; &dma; 付録 &mirrors; &bibliography; &eresources; &contrib; &policies; &pgpkeys; &jcontrib;