diff --git a/ja_JP.eucJP/articles/contributors/article.sgml b/ja_JP.eucJP/articles/contributors/article.sgml
index 2312e51c25..66a2148ddd 100644
--- a/ja_JP.eucJP/articles/contributors/article.sgml
+++ b/ja_JP.eucJP/articles/contributors/article.sgml
@@ -1,735 +1,735 @@
%man;
%ja-authors;
%authors;
%teams;
%mailing-lists;
%ja-trademarks;
%trademarks;
%contrib.ent;
]>
FreeBSD への貢献者
$FreeBSD$
&tm-attrib.freebsd;
&tm-attrib.sun;
&tm-attrib.general;
この文書は FreeBSD に貢献した個人や組織を列記したものです。
寄贈者ギャラリー
FreeBSD プロジェクトは次の寄贈者に恩義を受けており、
ここに公表して感謝の意を表したいと思います。
セントラルサーバプロジェクトへの寄贈者:
次にあげる個人および企業からは、
新しいセントラルサーバマシンのための部品の寄贈を頂きました。
これにより、freefall.FreeBSD.org
をリプレースして、新しい FreeBSD サーバマシンを
構築することができました。
&a.mbarkah
と彼の所属する
Hemisphere Online
は、Pentium Pro (P6) 200MHz CPU
を寄贈してくださいました。
ASA
Computers は、Tyan 1662
マザーボード
を寄贈してくださいました。
ViaNet
Communications の Joe McGuckin
joe@via.net は、Kingston
イーサネットコントローラ
を寄贈してくださいました。
Jack O'Neill
jack@diamond.xtalwind.net は、
NCR 53C875 SCSI コントローラカード
を寄贈してくださいました。
Alameda
Networks の Ulf Zimmermann
ulf@Alameda.net は、128 MB
のメモリ、そして 4 GB
のディスクドライブと匡体
を寄贈してくださいました。
直接的な資金提供
次にあげる個人および企業からは FreeBSD
プロジェクトに対する直接的な
資金提供を頂いています。
Annelise Anderson
ANDRSN@HOOVER.STANFORD.EDU
&a.dillon;
Blue Mountain
Arts
Epilogue Technology Corporation
&a.sef;
Global Technology
Associates, Inc
Don Scott Wilde
Gianmarco Giovannelli
gmarco@masternet.it
Josef C. Grosch joeg@truenorth.org
Robert T. Morris
&a.chuckr;
Imaginary Landscape, LLC.
の Kenneth P. Stox
ken@stox.sa.enteract.com
Dmitry S. Kohmanyuk dk@dog.farm.org
日本の
Laser5
は、さまざまな種類の FreeBSD CD の販売利益の一部を
寄付してくれました。
蕗出版 は、はじめての FreeBSD
の売り上げの一部を FreeBSD プロジェクト及び
XFree86 プロジェクトへ寄付してくれました。
アスキー
は FreeBSD 関連の書籍の売り上げの一部を FreeBSD
プロジェクトおよび FreeBSD 友の会へ寄付してくれました。
横河電機株式会社 からは FreeBSD
プロジェクトへ多大な寄付をいただきました。
BuffNET
Pacific
Solutions
Siemens AG,
Andre Albsmeier
andre.albsmeier@mchp.siemens.de
Chris Silva ras@interaccess.com
ハードウェアの寄贈者
次にあげる個人および企業からは、
テストやデバイスドライバの開発 / サポート
のためのハードウェアの寄贈を頂いています。
BSDi は、
ネットワークへのアクセスおよび
他のハードウェアリソースの寄贈はいうまでもなく、
開発に使うための Pentium P5-90 と 486/DX2-66 EISA/VL
のシステム数台を提供してくださいました。
Compaq
から、さまざまな種類の Alpha システムを
FreeBSD プロジェクトに寄贈していただきました。
この豊富な寄贈品の中には
AlphaStation DS10 4 台、AlphaServer DS20 1 台、
AlphaServer 2100 数台、AlphaServer 4100 1 台、
500Mhz の CPU を搭載したパーソナルワークステーション 8 台、
433Mhz の CPU を搭載したパーソナルワークステーション 4 台が含まれ、
それ以外にも数々の支援をいただきました。
上記のマシンは、FreeBSD/Alpha における
リリースエンジニアリング作業、package 構築、SMP の開発、
そして一般的な開発に利用されています。
TRW Financial Sysytems 社は、PC 130 台、68 GB
のファイルサーバ 3 台、12 のイーサネット、
ディスクレスコードのデバッグをおこなうための ルータ
2台及び ATM スイッチを提供してくださいました。また、
彼らは 2、3 人の FreeBSD ハッカーを雇って、FreeBSD
に専念させてくださっております。
ありがとうございます!
Dermot McDonnell は、東芝 XM3401B CD-ROM ドライブを
寄贈してくださいました。その CD-ROM ドライブは現在
freefall で使用されています。
Chuck Robey chuckr@glue.umd.edu
は、実験用のフロッピーテープストリーマを
寄付してくださいました。
Larry Altneu larry@ALR.COM と
&a.wilko;は、wt
ドライバを改良するために Wangtek と Archive の QIC-02
テープドライブを提供してくださいました。
Ernst Winter ewinter@lobo.muc.de は、
このプロジェクトへ 2.88 MB
のフロッピードライブを提供してくださいました。
うまくいけば、
これでフロッピーディスクドライバを書き直すための
プレッシャーが増えるでしょう。
Tekram
Technologies は NCR ドライバや AMD
ドライバと自社のカードの逆行テストのため FAST/ULTRA
SCSI ホストアダプタ DC-390、DC-390U、DC-390F を
各１枚提供してくださいました。また、フリーな OS
のためのドライバの ソースを自社の FTP サーバ
で公開されていることも称賛に値するでしょう。
Larry M. Augustin
は Symbios Sym8751S SCSI
カードを寄贈してくださっただけでなく、Ultra-2 や LVD
をサポートする次期チップ Sym53c895 のものを含む
データブックのセットと、最新の Symbios SCSI
チップが持つ先進的機能を安全に使う方法について書かれた
最新のプログラミングマニュアルも寄贈してくださいました。
本当にありがとうございます!
Christoph Kukulies kuku@FreeBSD.org
は、IDE CD-ROM ドライバ開発用の FX120 12 倍速 Mitsumi
CD-ROM ドライブを提供してくださいました。
Mike Tancsa mike@sentex.ca は、
拡張カードの対応と、netatm ATM スタックの開発作業のために
4 枚の ATM PCI カードを寄贈してくれました。
特筆すべき寄贈者
BSDi
(かつての Walnut Creek CDROM) は、
言い表せないほど多くの寄付をしてくださいました (詳細は
FreeBSD ハンドブックの
「FreeBSD プロジェクトについて」の章をご覧ください)。
特に、私たちのもともとのプライマリ開発マシンである
freefall.FreeBSD.org、
テストおよびビルドマシンである
thud.FreeBSD.org
で使用しているハードウェアに対し感謝したいと思います。
また彼らには、数年にわたる色々な貢献者への資金提供や、
インターネットへの T1 コネクションの無制限使用を提供して
頂いた恩義があります。
interface
business GmbH, Dresden は、&a.joerg;
を根気よくサポートしてくださいました。彼は本職より
FreeBSD の仕事を好みがちであり、彼個人の接続があまりに
遅くなったり途切れたりして仕事にならない時は必ず
interface business の (非常に高価な) EUnet
インターネット接続に頼ったものです…。
Berkeley Software
Design, Inc. は、同社の DOS
エミュレータのコードを
BSD コミュニティ全体に対して提供してくれました。このコードは、
doscmd
コマンドに利用されています。
FreeBSD コアチーム
FreeBSD コアチームは、
プロジェクトの 運用委員会
を形成し、FreeBSD
プロジェクトの全般的な目的や方針の決定を行います。さらに、
FreeBSDプロジェクトの
特定の分野の
運用も行っています。
(姓でアルファベット順):
&contrib.core;
FreeBSD の開発者たち
(CVS の) commitする権利を持っていて、FreeBSD
のソースツリーについて 作業をおこなっている人々がいます。
すべてのコアチームのメンバはまた開発者でもあります。
(姓でアルファベット順)
&contrib.committers;
FreeBSD ドキュメンテーションプロジェクト
FreeBSD
ドキュメンテーションプロジェクトは複数のサービスを提供
しています。それぞれのサービスは、以下の担当者とその
副担当者によって運用されています。
ドキュメンテーションプロジェクト担当
&a.nik;
ハンドブック編集担当
&a.doc;
FAQ 編集担当
&a.doc;
ニュースフラッシュ編集担当
&a.jim;
In the Press 編集担当
&a.jkoshy;
FreeBSD Really-Quick NewsLetter編集担当
Chris Coleman chrisc@vmunix.com
ギャラリーページ担当
&a.phantom;
商用ベンダーページ担当
&a.ceri;
ユーザグループ担当
&a.grog;
FreeBSD &java; プロジェクト
&a.patrick;
LinuxDoc から DocBook への移行
&a.nik;
担当者
ドキュメンテーションプロジェクト担当
&a.nik;
CVSup ミラーサイトコーディネータ
&a.cvsup-master;
担当:
&a.kuriyama; (責任者),
&a.jdp; (アドバイザ)
- 国際化
+ 地域化
&a.ache;
ポストマスタ
&a.jmb;
リリースコーディネーション
&a.re; (リーダは &a.murray;)
広報および渉外担当
空席
セキュリティオフィサ
&a.security-officer; (リーダは &a.nectar;)
CVS ツリー管理者
責任者: &a.peter;
副責任者: &a.markm;, &a.joe;
ウェブサイト管理者
&a.www;
Ports Collection 担当
&a.portmgr;
以下のメンバで構成されています。
&a.asami;,
&a.knu;,
&a.kris;,
&a.lioux;,
&a.marcus;,
&a.sobomax;,
&a.steve;,
&a.will;
標準化担当
&a.wollman;
XFree86 Project, Inc. との渉外担当
&a.rich;
GNATS 管理者
&a.steve;
Bugmeister
&a.ceri;
寄贈品受付事務局
&a.donations;
以下のメンバで構成されています。
&a.mwlucas
&a.nsayer
&a.obrien
&a.rwatson
&a.trhodes
コアチームの卒業生
コアチーム (core team)
次にあげる人々は () で記した期間、FreeBSD
コアチームのメンバーでした。FreeBSD
プロジェクトにおける彼らの努力に感謝の意を表します。
だいたいの年代順
&contrib.corealumni;
開発チームの卒業生
開発チーム (development team)
次にあげるのは、かつて FreeBSD
開発チームの一員だった人々です。
FreeBSD プロジェクトに貢献してくださった彼らに感謝します。
ほぼ年代順に:
&contrib.develalumni;
BSD 派生ソフトウェアへの貢献者
このソフトウェアは最初は William F. Jolitz の 386BSD release
0.1 から派生しましたが、オリジナルの 386BSD
に固有のコードはほとんど残っていません。
このソフトウェアは基本的にはカリフォルニア大学 バークレイ校の
Computer Science Research Group (CSRG) とその共同研究者
たちによる 4.4BSD-Lite リリースから再実装されました。
また、NetBSD や OpenBSD の一部も FreeBSD
に取り込まれています。したがって私たちは NetBSD と OpenBSD
へ貢献した人々すべてに感謝します。
その他の FreeBSD への貢献者
(名前でアルファベット順)
&contrib.additional;
386BSD パッチキットへのパッチ提供者
(名前でアルファベット順):
&contrib.386bsd;
diff --git a/ja_JP.eucJP/articles/fbsd-from-scratch/article.sgml b/ja_JP.eucJP/articles/fbsd-from-scratch/article.sgml
index e12b066d17..4cfee7ea08 100644
--- a/ja_JP.eucJP/articles/fbsd-from-scratch/article.sgml
+++ b/ja_JP.eucJP/articles/fbsd-from-scratch/article.sgml
@@ -1,641 +1,639 @@
%man;
%freebsd;
%ja-trademarks;
%trademarks;
FreeBSD をゼロから設定する">
]>
FreeBSD をゼロから設定するには
Jens
Schweikhardt
schweikh@FreeBSD.org
2002
Jens Schweikhardt
$FreeBSD$
&tm-attrib.freebsd;
&tm-attrib.adobe;
&tm-attrib.general;
この記事は、「&scratch.ap; (FreeBSD From Scratch)」という、
わたしの個人的な経験をまとめたものです。
カスタマイズした &os; システムをソースからコンパイルし、
さらに好みの ports のコンパイルして、
あなたが望む構成のシステムの、
完全に自動化されたインストールを実現します。
make world
がすばらしい考え方だとお思いの方にとって、
「&scratch.ap;」は、まさに make world を
make evenmore (さらにその先)
へと広げるものになることでしょう。
はじめに
今までに make world
を使ってシステムをアップグレードした経験はあるでしょうか?
もしディスクに一つのシステムしか入れていない場合は問題です。
installworld が途中で止まってしまったら、
あなたのシステムは壊れたまま、もう起動しなくなってしまうかも知れません。
あるいは、installworld が正常に終了しても、
新しいカーネルは起動に失敗してしまうかも知れません。
さて、そうなってしまったら、Fixit CD
を取り出して半年前のバックアップを戻す、
なんてはめになってしまうかも知れませんよね。
わたしは、アップグレードの時はディスクを初期化する
という方法がよいと考えています。パーティションではなくディスク全体のデータを
消去することで、アップグレードの手順では無視されるような古いデータが
残ってしまうことを防ぐことができます。ただ、
パーティションを全部初期化するということは、
ports/packages をすべて再コンパイル・再インストールしなければならず、
設定ファイルも注意深く作成し直さなければならないということです。
こういう作業を自動化したいと思いませんか?
そう思う人は、この先を読み進めましょう。
どうして「&scratch.ap;」(あるいは「〜しない」)
ことが必要なのか
これはもっともな質問です。
すでに sysinstall がありますし、
カーネルとユーザランドツールをコンパイルする方法には、
もっと有名な方法が他にもあるからです。
sysinstall
の問題は、「何を、どこに、
どうやってインストールするのか」が非常に限定されているという点です。
sysinstall
は通常、構築ずみの配布物セットと packages を
(CD, DVD, FTP などの)
別の場所からインストールする時に使われるものであり、
make buildworld
の結果をインストールできるようにはできていません。
現在稼働中のシステム中にあるディレクトリに、
新しいシステムをインストールすることはできません。
Vinum
パーティションへのインストールはできません。
構築ずみの packages はインストールできますが、
ports を構築することはできません。
スクリプトを使ったり、
インストール後に変更するための処理を自由に入れることは困難です。
最後の大きな理由として、sysinstall
が、公式にもう積極的に使わないプログラムと考えられている、
ということがあげられます。
システム全体を構築してインストールする方法は、
ハンドブックにある方法が有名です。
これはデフォルトで既存のシステムを置き換えるもので、
カーネルとモジュールだけが保存され、
システムバイナリ、ヘッダ、その他の多くのファイルは上書きされます。
使われなくなった古いファイルはそのまま残り、
動作に問題が出ることもあります。
何らかの理由でアップグレードに失敗すると、
システムを元の状態に戻することは不可能か、できても非常に困難です。
「&scratch.ap;」方法は、これらの問題をすべて解決できます。
考え方は単純です。
稼働中のシステムを使って空のディレクトリにシステムをインストールします。
その時、その新しいシステムのディレクトリツリーには、
新しいパーティションを適切にマウントしておaきます。
数多くある設定ファイルは、コピーできるものは適切な場所にコピーし、
それができないものには &man.mergemaster.8; を使います。
新しいシステムに対するインストール後の設定は、
古いシステムを動作させながら、新しいシステムに対して chroot して
自由に行なうことができます。具体的には、
シェルスクリプト、もしくは make
の実行で構成される、次の 3 段階でこれらを実現します。
stage_1.sh:
新しい起動可能なシステムを空のディレクトリ以下に作成し、
必要なファイルをマージ、もしくはコピーします。
そして、新しいシステムを起動します。
stage_2.sh:
必要な ports をインストールします。
stage_3.mk:
ひとつ前の段階でインストールしたソフトウェアの、
インストール後の設定を行ないます。
新しいシステムを構築するために「&scratch.ap;」方法を使い、
それが数週間、満足する程度に動作していることを確認したら、
もう一度それを使って、大元のシステムを再インストールすることができます。
これからはいつでも好きな時にシステムを更新して、
初期化・再インストールしたパーティションに切り替えるだけでよくなるわけです。
Linux From Scratch
(もしくは省略して LFS) について耳にしたり、試された方がいらっしゃるかも知れません。
LFS も同じように、稼働中のシステムを使ってシステムをゼロから構築し、
空のパーティションにインストールする方法が書かれています。
LFS が話題の中心としているのは、(カーネル、コンパイラ、デバイス、
シェル、端末データベースなどの) 各システムコンポーネントの役割と、
それらのインストールの詳細を見せることのようです。
この「&scratch.ap;」では、そのような詳細には触れません。
わたしの目的は、インストールを終わりまで自動化することであり、
システム構築時の泥くさい過程を全部説明することではありません。
&os; をそのようなレベルで掘り下げてみたい人は、
/usr/src/Makefile を読んで、
make buildworld
の動作を追いかけるところから始めましょう。
また、「&scratch.ap;」方法にも、
次のような欠点があることを心に留めておいてください。
第 2 段階で ports をコンパイルしている間、
システムは通常の用途に使用することができません。
もしプロダクションサーバを運用しているなら、
第 2 段階でダウンタイムが発生することを考慮に入れなければなりません。
stage_2.sh の ports のコンパイルには、
AMD1800+、10,000rpm SCSI、1GB の RAM を搭載したシステムで、
約 4 時間かかります。
前提とする環境
「&scratch.ap;」方法を実行するには、
次のものが必要です。
ソースと ports ツリーを含む、稼働中の &os; システム
新しいシステムをインストールするための、
最低 1 個の未使用パーティション
&man.mergemaster.8; を実行した経験。もしくは、
それを実行する勇気。
インターネット接続環境がない、あるいは遅い場合には、
インストールしたい ports の配布ファイル
Bourne シェル (&man.sh.1;)
を使ってシェルスクリプトを作成するための基礎知識
新しいシステムを起動する方法を、
対話的あるいは設定ファイルを使ってブートローダに
教えることができること
第 1 段階: システムのインストール
次に紹介するのは、わたしが作成した stage_1.sh
です。あなたが求めているシステム
に合うように、
カスタマイズしてください。カスタマイズしなければならないところには、
なるべく詳細なコメントを付けてあります。重要なポイントは、
以下のとおりです。
パーティションの配置
わたしは、システム全体を一つの大きな
パーティションに入れるという考え方が好きではないので、
普通は
/、
/usr、
/var の
パーティションを分割し、/tmp を
/var/tmp のシンボリックリンクにしています。
また、/home (ユーザのホームディレクトリ)、
/home/ncvs (&os; CVS リポジトリの複製),
/usr/ports (ports ツリー),
/src (チェックアウトした src ツリー)、
/share (news スプールなど、バックアップする必要がない、
その他の共有データ) といったファイルシステムを、
古いシステムと新しいシステムで共有しています。
その他の項目
これは、新しいシステムの起動後にすぐに実行したいことや、
第 2 段階の前に実行したい内容のことです。
わたしの場合は、/etc/passwd に
ログインシェルとして shells/zsh
が登録してあるので、それになります。
厳密には、この「その他の項目」を実行する必要は必ずしもありません。
root ユーザでログインして、次の段階を実行できさえすればよいからです。
第 1 段階で単純に好みの ports をすべてインストールしないのは、
理論的、あるいは実践的な面においてブートストラップ問題と依存問題があるからです。
第 1 段階では古いカーネルが動作しているのですが、
chroot した環境では新しいバイナリとヘッダが含まれています。
たとえば、新しいシステムが (新しいヘッダに従って)
新しいシステムコールをサポートしていた場合、
configure スクリプトがそれを使おうとしてしまうかも知れません。
そうすると、古いカーネルは対応していないので異常終了してしまうでしょう。
わたしが lang/perl5
をコンパイルした時には、他にも問題が発生するのを確認しています。
stage_1.sh を実行する前に、
make installworld installkernel
を実行するために通常行なう作業を完了させておいてください。
これらは、たとえば次のようなものです。
カーネルコンフィグファイルの設定
make buildworld
を正常終了させておくこと
make buildkernel
KERNCONF=whatever
を正常終了させておくこと
初めて stage_1.sh を実行した場合は、
稼働中のシステムから新しいシステムへとコピーされる設定ファイルは
/usr/src のものと比べると古いので、
mergemaster がどうするかを聞いてきます。
おすすめは、ここで変更点を統合しておくことです。
もし、何度も質問に答えるのが面倒であれば、
稼働中のシステムのファイルを更新しておきましょう
(ただしこれは、そうできればの話です。
-STABLE のシステムを実行していて、
-CURRENT を構築する、
もしくはその逆のようなケースでは、そうしてはいけません)。
次に mergemaster を実行した時、
RCS バージョン ID が /usr/src
にあるファイルと一致しているものは、処理が飛ばされるようになります。
stage_1.sh スクリプトは
set -e が指定されており、
最初のコマンドが失敗 (終了コードが 0 以外) すると停止します。
そのため、エラーを見逃してしまうということはないでしょう。
次に進む前に、stage_1.sh
にあるエラーを全部修正しておいてください。
stage_1.sh では
mergemaster が実行されます。
統合作業をしなければならないファイルが一つもない状態でも、
実行の終わりに次のメッセージが表示されます。
*** Comparison complete
Do you wish to delete what is left of /var/tmp/temproot.stage1? [no] no
no と答えるか、
単に Enter を押してください。
なぜかと言うと、mergemaster
は /var/tmp/temproot.stage1
にサイズが 0 のファイルをいくつか残すからです。
これは、後で新しいシステムに (存在しなければ) コピーされます。
この後、インストールされたファイルのリストがページャ
(デフォルトでは &man.more.1; です。&man.less.1; を使うこともできます)
に表示されます。
*** You chose the automatic install option for files that did not
exist on your system. The following were installed for you:
/newroot/etc/defaults/rc.conf
...
/newroot/COPYRIGHT
(END)
q を入力してページャを終了します。
すると login.conf に関して、次のように表示されます。
*** You installed a login.conf file, so make sure that you run
'/usr/bin/cap_mkdb /newroot/etc/login.conf'
to rebuild your login.conf database
Would you like to run it now? y or n [n]
これに対する答えはどちらでも構いません。
どう答えても、スクリプトから &man.cap.mkdb.1; が実行されます。
ちゃんと予想どおりに動いているかチェックできるよう、
stage_1.sh で行なわれたことは、
すべて stage_1.log に記録されます。
次に示すのは、筆者の使っている stage_1.sh です。
特にステップ 1, 2, 5, 6 は書き換える必要があるでしょう。
&man.newfs.8; コマンドには注意してください。
マウントずみのパーティションに新しいファイルシステムを作成することはできないものの、
このスクリプトはマウントされていない
/dev/da3s1a, /dev/vinum/var_a,
/dev/vinum/usr_a をすべて削除します。
ひとつ間違えれば、あなたの環境を破壊してしまう可能性がありますので、
デバイス名の変更は注意深く行なってください。
このスクリプトを実行すると、
起動した時に次のような状態になっているシステムがインストールされます。
稼働中のシステムと同じユーザとグループ
Ethernet と PPP を経由した、
ファイアウォールありのインターネット接続環境
正しいタイムゾーンと NTP 設定
/etc/ttys や
inetd など、その他の細かな設定。
他の部分に対する設定は、第 2 段階が終わるまで動作しません。
たとえば、プリンタや X11 の設定ファイルもコピーされますが、
プリンタは &postscript; ユーティリティなど、
ベースシステムに含まれないアプリケーションを使うことが多いでしょう。
X11 はサーバ、ライブラリ、プログラムをコンパイルしないと動作しません。
第 2 段階: ports のインストール
この段階で ports をコンパイルするのではなく、
(コンパイルずみの) packages をインストールすることもできます。
その場合、stage_2.sh は
単に pkg_add コマンドを羅列するだけになるでしょう。
読者のみなさんにとって、そういうスクリプトを書くのは難しくないと思いますので、
ここではもっと柔軟で、ports
を使った伝統的な方法について考えることにします。
次に紹介する stage_2.sh スクリプトは、
わたしが好みの ports をインストールするために使ったものです。
これは何度でも実行でき、インストールずみの ports があれば、
飛ばして処理されます。スクリプトは 実行せず、実行される内容だけ
を表示する (dryrun) オプション ()
があります。ports リストの編集や、環境変数の設定を変更しましょう。
ports リストは、空白で区切られた 2 個以上のキーワードからなっています。
カテゴリ、port 名に始まり、オプションとして
port をコンパイルしてインストールするためのコマンド
(デフォルトは make install) が続きます。
空白行と # から始まる行は無視されます。
おそらく多くの場合に考えなければならないのは、カテゴリ名と port 名だけでしょう。
ports によっては、たとえば次のように
make 変数を使って微調整することができます。
www mozilla make WITHOUT_MAILNEWS=yes WITHOUT_CHATZILLA=yes install
mail procmail make BATCH=yes install
実際には任意のシェルコマンドを指定できますので、
make を使う以外にも応用は可能です。
java linux-sun-jdk13 yes | make install
news inn-stable CONFIGURE_ARGS="--enable-uucp-rnews --enable-setgid-inews" make install
news/inn-stable の行は、
CONFIGURE_ARGS という シェル変数を定義した例です。
この port の Makefile は、
この指定した値を変数の初期値として、その他の必須の引数と一緒に使います。
これと
news inn-stable make CONFIGURE_ARGS="--enable-uucp-rnews --enable-setgid-inews" install
のようにして
- make 変数をコマンドラインに設定した場合との違いは、
+ make 変数をコマンドラインに設定した場合との違いは、
こちらの場合に変数そのものを完全に上書きしてしまうという点です。
どの方法を使えばいいのかについては、各 port によります。
インストールしたい ports が、
対話的インストールを使っていないことを確認してください。
ports は、あなたが標準入力に明示的に指定したもの以外、
標準入力を読み込む動作をしてはいけません。
もし ports がそのように作られていると、ports はヒアドキュメントにある
ports リストの次の行を読み込んで混乱してしまいます。
stage_2.sh を実行した時、
ある port が飛ばされたり、動作が止まってしまうようなことがあれば、
おそらくこれが原因でしょう。
次に示すのが、実際の stage_2.sh です。
これは、インストールされる port それぞれに対して
LOGDIR/category+port
という名前のログファイルを作成します。
stage_2.sh が共有パーティションになければ、
実行前に新しいシステムにこれをコピーするようにしてください。
第 3 段階
第 2 段階で、好みの ports がインストールされましたが、
ports には、設定を必要とするものがあります。
第 3 段階は、インストール後の設定を行なう段階です。
stage_2.sh の最後にこの段階を統合することもできたのですが、
わたしは port をインストールすることと初期設定を変更することが異なる工程であると考えたため、
独立した段階としています。
第 3 段階は、Makefile として実装しています。
これは、次のように実行することで、設定対象を簡単に選ぶことができるからです。
&prompt.root; make -f stage_3.mk target
stage_2.sh の段階で、
stage_3.mk を共有パーティションに置くか、
新しいシステムのどこかにコピーするなどして、
新しいシステムが起動した時に
stage_3.mk が使えるようにしておきましょう。
制限事項
対話的で、かつ make BATCH=YES install
でのインストールに対応していない port
の自動インストールは難しいかも知れません。
対話的にインストールする ports には、ライセンス条項の同意を尋ねられた時に
yes と入力するだけのものがいくつかあります。
そのように入力が標準入力から読みとられる場合は、
適切な回答をインストールコマンド (通常は make
install) にパイプで渡すことができます
(stage_2.sh の
java/linux-sun-jdk13
でとった方法がそうです)。
しかしこの方法は、たとえば editors/staroffice52 の場合にはうまく動きません。
これは X11 が実行されていることを要求するからです。
インストール手順には多くのクリックや文字入力が必要なので、
他の ports のように自動化することはできません。
わたしは、次のようにして問題を回避しました。
最初に古いシステムで staroffice の package を作成し、
&prompt.root; cd /usr/ports/editors/staroffice52
&prompt.root; make package
===> Building package for staroffice-5.2_1
Creating package /usr/ports/editors/staroffice52/staroffice-5.2_1.tbz
Registering depends:.
Creating bzip'd tar ball in '/usr/ports/editors/staroffice52/staroffice-5.2_1.tbz'
その後、第 2 段階で次のようにしたわけです。
&prompt.root; pkg_add /usr/ports/editors/staroffice52/staroffice-5.2_1.tbz
その他に、設定ファイルのアップグレード問題に気をつける必要があります。
一般的に、設定ファイルの書式や内容がいつ変更されるかを知ることはできません。
新しいグループが /etc/group
に追加されるかも知れませんし、/etc/passwd
に新しいフィールドが追加されるかも知れません。
このような例は、実際に過去にありました。
単純に古いシステムから新しいシステムに設定ファイルをコピーするだけで
ほとんどの場合は十分なのですが、時には不都合な場合もあります。
古いファイルを上書きする方法でシステムをアップグレードしたら、
ローカルにある設定ファイルに新しく追加されたかも知れない項目を統合する目的で
mergemaster を使うと思います。
しかし残念なことに、mergemaster
はベースシステムに存在するファイルだけで、インストールした
ports については何も処理を行なってくれません。
サードパーティ製ソフトウェアには、
リリースのたびに設定ファイルのフォーマットが変更され、
わたしをイライラさせるようなものもあります。
注意すること以外にできることはありませんが、
特にメジャーバージョンがあがった時は気を付けてください。
わたしは以前、ウェブサーバ、
ニュースサーバ、ニュースリーダのファイルを書き換えたり、
書き直すはめになったことがあります。
活発に開発が進められているソフトウェアはすべて、
設定ファイルの書式が変更されていないか確認しておきましょう。
わたしは
5-CURRENT から 5-CURRENT
に更新するために
「&scratch.ap;」方法を数回使いましたが、
4-STABLE と 5-CURRENT
の間で更新を行なった経験はありません。
異なるメジャーリリース番号の間は、非常の多数の変更が行なわれているため、
更新作業はもっと複雑なものになると思います。
(試したわけではないのですが)
4-STABLE から 4-STABLE
への更新であれば、「&scratch.ap;」方法は問題なく動作するはずです。
4-STABLE のユーザは、次の点を考慮してください。
-
-
- デバイスファイルシステム
- (devfs) を使ってなければ、
- 第 1 段階のステップ 6 で &man.MAKEDEV.8; を使い、
- ハードウェア用のデバイスファイルを作成するとよいでしょう。
-
-
+
+ デバイスファイルシステム (&man.devfs.5;) を使ってなければ、
+ 第 1 段階のステップ 6 で &man.MAKEDEV.8; を使い、
+ ハードウェア用のデバイスファイルを作成するとよいでしょう。
+
+
diff --git a/ja_JP.eucJP/articles/zip-drive/article.sgml b/ja_JP.eucJP/articles/zip-drive/article.sgml
index 32c5b27d3c..2e78fe6aed 100644
--- a/ja_JP.eucJP/articles/zip-drive/article.sgml
+++ b/ja_JP.eucJP/articles/zip-drive/article.sgml
@@ -1,329 +1,342 @@
%man;
%freebsd;
+
+%ja-trademarks;
+
+%trademarks;
]>
- ZIPドライブ
+ &iomegazip; ドライブ
Jason
Bacon
acadix@execpc.com
+
+
+ &tm-attrib.freebsd;
+ &tm-attrib.adaptec;
+ &tm-attrib.iomega;
+ &tm-attrib.microsoft;
+ &tm-attrib.opengroup;
+ &tm-attrib.general;
+
- ZIP ドライブの基礎
+ &iomegazip; ドライブの基礎
- ZIP ディスクは、アイオメガ社から発売されている
+ &iomegazip; ディスクは、アイオメガ社から発売されている
ZIP ディスクドライブで読み書き可能な大容量のリムーバブル磁気ディスクです。
ZIP ディスクはフロッピーディスクと似ていますが、
ZIP ディスクの方が非常に高速で比較にならないほど大容量です。
というのはフロッピーディスクの容量が大抵
1.44M バイトであるのに対し、ZIP
ディスクの容量は、100M バイトか
250M バイトの二種類あります。
120M バイトの容量を持ち、
従来の 1.44M バイトのディスクも使用できる
SuperDisk というフロッピーがありますが、ZIP
ディスクとは混同しないでください。
- アイオメガ社は、JAZZ
+ アイオメガ社は、&jaz;/JAZZ
ドライブというさらに大容量で優れた性能を持ったディスクドライブも発売しています。
JAZZ ドライブの容量は 1G バイトか 2G バイトの二種類です。
ZIP ドライブには、以下の 3 種類のインタフェースが用意されており、
内蔵も外付けも可能です。
SCSI (Small Computer Standard Interface)
は最も高速・精巧で拡張性も高く、
そして最も高価なインタフェースです。
SCSI インタフェースは、
ディスクドライブ、テープドライブ、
スキャナーなどといったすべてのタイプの周辺機器と接続するために、
PC から RISC ワークステーション、
ミニコンに至るまで、ほとんどのコンピュータで使用されてきました。
SCSI 対応 ZIP ドライブは、
内蔵も (もし SCSI ホストアダプタに外付けコネクタがあれば)
外付けも可能です。
SCSI で接続された外付けの装置を使用する際、
動作中に SCSI バスからケーブルを抜き差ししないでください。
さもないと、挿入されていたディスクのファイルシステムを損傷
する恐れがあります。
最高のパフォーマンスとセットアップの手軽さを望むなら、
SCSI はベストチョイスです。
一部のハイエンドサーバを除き、多くの PC はビルトインの
SCSI をサポートしていないため、
SCSI ホストアダプタを追加で購入する必要があります。
種類にもよりますが、SCSI ホストアダプタは 7 台か 15 台の
SCSI デバイスを接続することができます。
それぞれの SCSI デバイスはそれ自身のコントローラを持っており、
そしてそれらは非常に賢く、よく標準化されているので
(SCSI の 2 番目の "S" は "標準" を表します)、
OS は SCSI のディスクドライブをすべて同じように扱うことができ、
またそれは SCSI のテープドライブなども同様です。
SCSI デバイスを使用するためには、ホストアダプタ用のドライバと
SCSI ディスクドライブ用ドライバ、
SCSI テープドライブ用ドライバといった装置に対応する標準のドライバを用意するだけで良いのです。
さらに機種に特化したドライバ (たとえば DAT
ドライブなど) も存在しますが、
大抵標準のドライバを使用しても動作します。
そういった特別なドライバは、
機種特有の機能を利用するために書かれたものです。
ZIP ドライブを使用するためには、
単に /dev
の中から ZIP ドライブのデバイスファイルを見つけるだけで良いのです。
ZIP ドライブのデバイスファイルは起動時に表示されるブートメッセージか、
/var/log/messages の中から
da1: <IOMEGA ZIP 100 D.13> Removable Direct Access
SCSI-2 Device
というメッセージを見つけることで特定できます。
上の例の場合、
ZIP ドライブのデバイスファイルは
/dev/da1
であるということを表しています。
IDE (Integrated Drive Electronics) インタフェースは、
多くのデスクトップ PC で使用されている低価格なインタフェースです。
ほとんどの IDE デバイスは必ず内蔵になっています。
IDE 接続の ZIP ドライブの性能は
SCSI 接続の ZIP ドライブに匹敵します。
(IDE インタフェースは SCSI より高速ではないのですが、
ZIP ドライブの性能は、接続されているバスインタフェースよりも
むしろ ZIP ドライブそのものの性能に大きく依存するためです)。
IDE インタフェースの欠点は、
その規格が定めた制限事項そのものです。
ほとんどの IDE アダプタは 2 つのデバイスしかサポートしておらず、
大抵長い期間を経て設計されたものではありません。
たとえば元来の IDE インタフェースは、
多くの人々にアップグレードを強いた
1024 シリンダ以上のハードディスクをサポートしていません。
もし ZIP ドライブの他のディスクドライブやテープドライブ、
スキャナーなどといった装置を PC に追加することを計画しているなら、
将来起こるであろう問題を回避するためにも、
SCSI ホストアダプタと
SCSI 接続用 ZIP ドライブに投資した方がよいかも知れません。
FreeBSDにおいて、IDEデバイスの先頭文字は a です。
たとえば、IDEのハードディスクドライブは
/dev/ad0 で、IDE (ATAPI) のCD-ROMドライブは
/dev/acd1 といった具合です。
パラレルポートインタフェースは、
実際に多くのコンピューターが標準パラレルポートを備えているため
(普段はプリンタ接続に使われます)
ZIP ドライブやスキャナといった、
ポータブルな外付けデバイスの接続においてポピュラーなインタフェイスです。
そのため ZIP ドライブを持ち運んで、
簡単にコンピュータ間のファイルのやりとりすることができます。
一般に、パラレルポート接続の ZIP
ドライブはパラレルポートの速度によって転送速度が制限されるため、
SCSI や IDE で接続された場合より低速です。
パラレルポートの速度はコンピュータによって非常にまちまちで、
また BIOS から設定することもできます。
また双方向通信を使用可能にするために
BIOS の設定が必要となるマシンもあります
(パラレルポートは元来、
プリンタへの出力のみを目的に設計されたものです)。
パラレルポートに接続する: <devicename>vpo</devicename> ドライバ
ZIP ドライブをパラレルポートに接続して使用するには、
カーネルに
vpo ドライバが設定されている必要があります。
パラレルポート接続の ZIP ドライブはビルトインの
SCSI コントローラを持っており、
vpoドライバを使用するとパラレルポートを通じて
ZIP ドライブの SCSI コントローラを読み込むことができます。
vpo は標準のカーネルオプションではないため
(FreeBSD 3.2 現在)
デバイスを使用可能にするためにカーネルを再構築する必要があります。
カーネル再構築の詳細な手順については他のセクションで説明します。
以下は、vpo ドライバを使用可能にするための大まかな手順です。
まず、/stand/sysinstall
を実行し、システムにカーネルのソースコードをインストールしてください。
次に、
vpo ドライバを含むカーネルコンフィグファイルを作ります:
&prompt.root; cd /sys/i386/conf
&prompt.root; cp GENERIC MYKERNEL
この MYKERNEL
を編集し、
ident の行を MYKERNEL
に変更します。
そして vpo ドライバについて書かれた行のコメントを解除してください。
もしパラレルポートが二つある場合、それに用いる
ppc1 デバイスファイルを作るために
ppc0 をコピーする必要がある場合があります。
二つ目のパラレルポートは普通 IRQ5 と
I/O ポートアドレス 378 番を使用します。
カーネルコンフィグファイルに記述する必要があるのは IRQ だけです。
もしルートのハードディスクドライブが
SCSI 接続であった場合、起動ディスクの読み込み順序に誤りが生じ、
システムが ZIP ドライブから起動しようとしてしまう場合があります。
こうなったら、あなたが ZIP ディスクに
FreeBSD のルートファイルシステムでも書き込まない限り、
起動には失敗するでしょう!
そうした場合は、ルートのディスクを「つなぎかえ (wire down)」
、
すなわち、カーネルに特定のデバイスを
SCSI ハードディスク /dev/da0
に強制的にバインドさせる必要があります。
そうすれば、ZIP ディスクドライブは二番目の
SCSI デバイス、つまり
/dev/da1 としてきちんと認識されます。
SCSI ハードディスクを
da0 に「つなぎかえ」するには、
device da0
の行を
disk da0 at scbus0 target 0 unit 0
に変更してください。
その際、ハードディスクの SCSI ID に合うように
上記の行を変更する必要があるかも知れません。
- たとえば、Adaptec 15xx コントローラの載った SCSI
+ たとえば、&adaptec; 15xx コントローラの載った SCSI
ホストアダプタをお持ちなら、下のように
scbus0 を SCSI コントローラにつなぎかえてください。
controller scbus0
を
controller scbus0 at aha0
に変更します。
最後に、カーネルコンフィグファイルを作成したら、
不要なドライバをすべて削除することができます。
その際には細心の注意を払う必要がありますが、
あとはコンフィグファイルの更新が成功することを信用するしかありません。
不要なドライバを削除することでカーネルのサイズを小さくすることができ、
アプリケーションに割り当てられるメモリの領域を拡大することができます。
不要なドライバを特定するために、
/var/log/messages
の最後の方の行で「not found」と書かれている部分を見つけ、
それらのデバイスをコメントアウトします。
カーネルのサイズを縮小し、
読み込みを早くするために他のオプションを削ることも考えられます。
カーネル再構築の際に表示されるメッセージから、
不要なオプションに関してのさらに詳しい情報が得られます。
ではカーネルを完成させましょう。
&prompt.root; /usr/sbin/config MYKERNEL
&prompt.root; cd ../../compile/MYKERNEL
&prompt.root; make clean depend && make all
install
カーネルが再構築されたら、再起動します。
起動が開始する前に、ZIP
ドライブがパラレルポートに接続されているかどうか確認してください。
ブートメッセージの中で ZIP ドライブが
vpo0 や vpo1
(これらは接続されているパラレルポートに依存する)
として認識されているか確認してください。
これが ZIP ドライブのデバイスファイルです。
ここで表示される ZIP のデバイスファイルは、
もしシステムに他の SCSI ディスクがない場合は
/dev/da0 となり、
SCSI ハードディスクドライブがルートデバイスとしてつなぎかえられているならば
/dev/da1 となります。
ZIP ディスクをマウントする
ZIP ディスクにアクセスするには、
他の種類のディスクと同じようにマウントするだけです。
デバイス上のファイルシステムがスライス 4 となっていて、
SCSI もしくはパラレル接続の ZIP ディスクなら、
&prompt.root; mount_msdos /dev/da1s4 /mnt
IDE 接続の ZIP ドライブなら、
&prompt.root; mount_msdos /dev/ad1s4 /mnt
/etc/fstab を更新すれば、
マウントはさらに簡単になります。
自分のシステムに合うように編集して、以下のような行を加えましょう。
/dev/da1s4 /zip msdos rw,noauto 0 0
そしてディレクトリ /zip を作成します。
マウントするには、
&prompt.root; mount /zip
マウントを解除するには、
&prompt.root; umount /zip
/etc/fstab
のフォーマットに関する詳細は、&man.fstab.5; を参照してください。
また、ZIP ディスク上に FreeBSD
のファイルシステムを作成するには &man.newfs.8; を参照してください。
ただし、このディスクは FreeBSD か、FreeBSD
を認識するごく少数の &unix; クローンのみにおいて使用することができます
- (DOS や Windows 上では使用できません)。
+ (DOS や &windows; 上では使用できません)。