diff --git a/ja_JP.eucJP/books/handbook/basics/chapter.sgml b/ja_JP.eucJP/books/handbook/basics/chapter.sgml index 7b99254bbe..248d35f16d 100644 --- a/ja_JP.eucJP/books/handbook/basics/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/basics/chapter.sgml @@ -1,1563 +1,1562 @@ Chris Shumway 改訂 Unix の基礎知識 訳: &a.jp.nakai;, 1996 年 10 月 12 日. この章では 基礎知識(basics) 改訂: Chris Shumway cshumway@osd.bsdi.com, 2000 年 3 月 10 日. この章では FreeBSD オペレーティングシステムの基本的なコマンドと機能について記述しています。 ここに書かれてあることのほとんどは、 どんな Unix オペレーティングシステムにもあてはまります。 この章に書いてあることに馴染みがあるなら、 この章は気軽に流し読みしてください。 あなたが FreeBSD の初心者なら、 何か質問する前にこの章を読んでおいた方がきっといいはずです。 この章を読んで分かることは、次のようなことです。 Unix のファイルの許可属性の仕組み プロセス、デーモンとシグナルとはなにか シェルとはなにか。 また、デフォルトのログイン環境を変える方法 テキストエディタの基本的な使い方 さらに詳しい情報を得るためのマニュアルページの読み方 許可属性 Unix FreeBSD は BSD Unix の直系の子孫であり、 いくつかの鍵となる Unix 思想にもとづいています。 まず最も際だった特徴として最初に言えるのは、FreeBSD がマルチユーザのオペレーティングシステムだということです。 FreeBSD は同時に働いている複数のユーザすべてを、 完全に分離したタスク上で処理する能力を持っています。 また FreeBSD は、ハードウェアデバイス、周辺装置、メモリ、 CPU 時間等への要求を、各ユーザが平等に利用できるように適切に共有し、 管理する役割を担っています。 システムがマルチユーザをサポートしているため、 システムが管理する資源はすべて、 誰がその資源を読み・書き・実行できるかを支配する、 一組の許可属性を持っています。 これらの許可属性は 3 つの部分からなる 2 桁の 8 進数の形で格納されています。 それはそのファイルの所有者(owner)に対するもの、 そのファイルが所属するグループ(group)に対するもの、 その他(others)に対するものの 3 つです。 これを数字を使って表現すると、次のようになります。 許可属性(permissions) ファイルの許可属性(permissions) 値 許可属性 ディレクトリの表示 0 読み込み不可、書き込み不可、実行不可 --- 1 読み込み不可、書き込み不可、実行可能 --x 2 読み込み不可、書き込み可能、実行不可 -w- 3 読み込み不可、書き込み可能、実行可能 -wx 4 読み込み可能、書き込み不可、実行不可 r-- 5 読み込み可能、書き込み不可、実行可能 r-x 6 読み込み可能、書き込み可能、実行不可 rw- 7 読み込み可能、書き込み可能、実行可能 rwx ls ディレクトリ &man.ls.1; に対してコマンドライン引数 を使うと、 詳細なディレクトリリストを見ることができ、 ファイルの所有者、グループ、その他への許可属性を示す欄があるのがわかります。 次に示すのは、ls -l の最初の部分だけ抜き出したものです。 -rw-r--r-- 最初の(一番左の)文字は、それが 普通のファイルなのか、ディレクトリなのか、 キャラクタ型のデバイス特殊ファイルなのか、 ブロック型のデバイス特殊ファイルなのか、 ソケットなのか、 その他の特殊な疑似ファイルデバイスなのかといった種類を示す特別な文字です。 この場合、- という文字は、 普通のファイルであることを示します。 この例でその次に来る rw- と書かれた 3 文字は、 そのファイルの所有者に許可を与えるものです。 その次の r-- の 3 文字は、 そのファイルが所属しているグループに許可を与えます。 最後の r-- の 3 文字は、 システムに存在するその他のユーザに許可を与えます。 - は許可が与えられていないことを示します。 このファイルの例では、ファイルの所有者はこのファイルを読み書きでき、 ファイルの所属しているグループに属するユーザはファイルを読むことだけでき、 そのどちらでもないユーザは、 このファイルを読むだけできるように許可属性が与えられています。 上の表によれば、このファイルに与えられた許可属性は 644 となります。 ここで各数字は、このファイルの許可属性の 3 つの部分を表しています。 ファイルについてはここまでの説明で十分です。 しかし、 デバイスの場合の許可属性はどのようにコントロールされているのでしょうか? FreeBSD は、大部分のハードウェアをファイルとして取り扱います。 そのため、プログラムからは普通のファイルとまったく同じようにオープンし、 データの読み書きができるようになっています。 これらのデバイス特殊ファイルは /dev ディレクトリに収められています。 ディレクトリもまた、ファイルと同様に扱われます。 それは読み込み/書き込み/実行の許可属性を持ちます。 ディレクトリの実行ビットはファイルのそれとは少し違った意味を持ちます。 ディレクトリが実行可能になっているとき、 そのディレクトリに移動することができます。 つまり、そのディレクトリに cd することが可能です。 また、実行可能属性がついているディレクトリでは、 名前が分かっているファイルにアクセスすることもできます (もちろんそのファイル自体の許可属性によります)。 特に、ディレクトリの中の一覧を表示させるためには、 そのディレクトリに読み込み属性が設定されていなければなりません。 一方、名前が分かっているファイルを削除するためには、 そのファイルが含まれているディレクトリに 書き込み属性と実行属性 の両方が必要です。 この他にも許可属性ビットはありますが、いずれも setuid バイナリや sticky ディレクトリなどといった特殊な状況で使われます。 ファイルの許可属性そのものについて、 また、それらの設定のしかたに関する詳しい情報は、 &man.chmod.1; マニュアルページを参照してください。 ディレクトリ構造 ディレクトリの階層構造 FreeBSD のディレクトリ構造は、 システム全体を理解するに当たって重要です。 把握しておくべき最も重要なものは、/ ディレクトリです。 このディレクトリは起動時に一番最初にマウントされ、 オペレーティングシステムをマルチユーザで動作させるために 必要な基本システムが含まれています。 また、ルートディレクトリには、 他のファイルシステムをマウントするためのマウントポイントも含まれます。 マウントポイントとはルートファイルシステムに存在する、 追加のファイルシステムと接続するためのディレクトリのことです。 標準的なマウントポイントには /usr, /var, /mnt, /cdrom があります。 通常これらのディレクトリについては、 /etc/fstab というファイル中のエントリが参照されます。 /etc/fstab - さまざまなファイルシステムとマウントポイントの表であり、 + はさまざまなファイルシステムとマウントポイントの表であり、 システムが参照します。 /etc/fstab に書かれたファイルシステムは オプションが指定されていなければ、 起動時に &man.rc.8; スクリプトによって自動的にマウントされます。 /etc/fstab ファイルの書式やオプションに関しての詳細は &man.fstab.5; をご覧ください。 ファイルシステム構造を網羅した説明は &man.hier.7; に書かれています。 ここでは、もっともよく使われるディレクトリについて簡単に 見るだけで十分でしょう。 ディレクトリ 説明 / ファイルシステムのルートディレクトリ /bin/ シングルユーザ環境とマルチユーザ環境の両方で重要な ユーザユーティリティ /boot/ オペレーティングシステムの起動時に使われるプログラムと設定ファイル /boot/defaults/ デフォルトの起動設定ファイル; &man.loader.conf.5; 参照 /dev/ デバイスノード; &man.intro.4; 参照 /etc/ システム設定ファイルとスクリプト /etc/defaults/ デフォルトのシステム設定ファイル; &man.rc.8; 参照 /etc/mail/ &man.sendmail.8; のようなメール転送エージェントの設定ファイル /etc/namedb/ named 設定ファイル; &man.named.8; 参照 /etc/periodic/ &man.cron.8; 経由で毎日・毎週・毎月実行されるスクリプト; &man.periodic.8; 参照 /etc/ppp/ ppp 設定ファイル; &man.ppp.8; 参照 /mnt/ システム管理者が一時的なマウントポイントとしてよく使う 空のディレクトリ /proc/ プロセスファイルシステム; &man.procfs.5; と &man.mount.procfs.8; 参照 /root/ root アカウントのホームディレクトリ /sbin/ シングルユーザ環境とマルチユーザ環境の両方で重要な システムプログラムと管理ユーティリティ /stand/ スタンドアロン環境で使われるプログラム /tmp/ 一時的なファイル、&man.mfs.8; メモリファイルシステムであることが多い (普通 /tmp の内容はシステムの再起動で失われる) /usr/ 大部分のユーザユーティリティとアプリケーション /usr/bin/ よく使うユーティリティとプログラミングツールとアプリケーション /usr/include/ C の標準ヘッダファイル /usr/lib/ ライブラリ /usr/libdata/ いろいろなユーティリティのデータファイル /usr/libexec/ システムデーモンとシステムユーティリティ (他のプログラムから実行される) /usr/local/ ローカルのプログラムやライブラリなど。 FreeBSD ports 構成のデフォルトインストール先としても使われます。 /usr/local 内では、 &man.hier.7; に書かれている /usr のための一般構造が使われます。 例外は man ディレクトリで、 /usr/local/share の下ではなく /usr/local の下に直接置かれ、 ports 関係文書は share/doc/port にあります。 /usr/obj/ /usr/src ツリーのビルドで作られる アーキテクチャ依存のターゲットツリー /usr/ports FreeBSD ports 集 (インストールしなくてもよい)。 /usr/sbin/ (ユーザが実行する)システムデーモンとシステムユーティリティ /usr/share/ アーキテクチャに依存しないファイル /usr/src/ BSD のソースファイルまたはローカルのソースファイル、 あるいは両方 /usr/X11R6/ X11R6 のプログラム、ライブラリなど(インストールしなくてもよい) /var/ ログ・一時的なファイル・スプールファイルなどいろいろな用途 /var/log/ いろいろなシステムログファイル /var/mail/ ユーザのメールボックスファイル /var/spool/ プリンタとメールシステムのスプールディレクトリなどなど /var/tmp/ システムが再起動しても消えない一時的なファイル /var/yp NIS のマップ ファイルシステムのマウントとアンマウント ファイルシステムは / をルート (根) とする木構造として考えると視覚的に理解しやすいでしょう。 ルートディレクトリにある /dev や /usr、 その他のディレクトリは枝に相当し、 それらには、/usr/local などのように、さらに枝分かれすることができます。 ルートファイルシステム さまざまな理由がありますが、 ディレクトリをいくつかの異なるファイルシステム上に構築するのが良いでしょう。 たとえば /var には、 log/ や spool/ など、さまざまな種類の一時ファイルを置くディレクトリがあるため、 あふれてしまう可能性があります。 ルートファイルシステムをあふれさせるのは得策ではありませんので、 普通は /var を / から分離します。 また、次のような場合も、ディレクトリツリーを 別のファイルシステムに置く理由として良くあげられます。 それは、たとえば物理的に別のディスクにディレクトリツリーを置く場合、 ネットワークファイルシステム (Network File System) や CDROM ドライブのような別の仮想ディスクに置くという場合です。 <filename>fstab</filename> ファイル ファイルシステム fstab を使ったマウント /etc/fstab に書かれているファイルシステムは ( オプションがなければ) 起動プロセスの途中で 自動的にマウントされます。 /etc/fstab ファイルは、 次のような書式で書かれた行のリストになっています。 device /mount-point fstype options dumpfreq passno device デバイスの名前 (存在していなければなりません)。 に説明があります。 mount-point ファイルシステムがマウントするディレクトリの名前 (存在していなければなりません)。 fstype &man.mount.8; に渡されるファイルシステムタイプ。 FreeBSD ファイルシステムのデフォルトは ufs です。 options 読み書きするファイルシステムには 、読み込み専用のファイルシステムには を、必要な他のオプションの前に指定します。 よく使われるオプションは で、 起動時にはマウントされないファイルシステムに使います。 その他のオプションは &man.mount.8; マニュアルページに載っています。 dumpfreq これは &man.dump.8; が使うもので、 どのファイルシステムにダンプが必要なのかを決めます。 この項目がなければ、0 であるものとみなされます。 passno これはファイルシステムをチェックする順番を決めます。 ファイルシステムチェックを飛ばしたいファイルシステムには、 passno を 0 に設定してください。 ルートファイルシステム (どれよりも先にチェックしなければなりません) は passno を 1 に設定してください。 他のファイルシステムの passno は 1 以上に設定してください。 同じ passno のファイルシステムがあった場合、 &man.fsck.8; は可能であれば並行してファイルシステムのチェック を行なおうとします。 <command>mount</command> コマンド ファイルシステム マウント &man.mount.8; コマンドは、 ファイルシステムをマウントするために使われるものです。 基本的には、次のように使います。 &prompt.root; mount device mountpoint &man.mount.8; マニュアルページにはたくさんのオプションが書かれていますが、 いちばんよく使われるのは次のものです。 マウントオプション /etc/fstab にある全てのファイルシステムをマウントします。 例外は noauto の印がついているものと、 フラグで除外されたものと、 すでにマウントされているファイルシステムです。 実際にシステムコールする以外の全てのことをします。 このオプションは フラグと組み合わせて使い、 &man.mount.8; が実際なにをしようとしているのか調べるのに便利です。 クリーンでないファイルシステムを強制的にマウントします (危険です)。もしくは、ファイルシステムのマウント状態を 読み書き可能から読み込みのみに変更するとき、 書き込みアクセスを強制的に取り消します。 ファイルシステムを読み込み専用でマウントします。 これは 引数を オプションに使うのと同じです。 fstype ファイルシステムを指定のファイルシステムタイプでマウントします。 または、 を使った場合、 指定したタイプのファイルシステムのみマウントします。 デフォルトのファイルシステムタイプは ufs です。 ファイルシステムのマウントオプションを更新します。 詳細な出力にします。 ファイルシステムを読み書き可能にマウントします。 には、 次のようなオプションを複数カンマで区切って指定します。 以下に挙げるのはその一部です。 nodev ファイルシステム上のスペシャルデバイスを解釈しません。 セキュリティのために有用なオプションです。 noexec そのファイルシステム上のバイナリの実行を禁止します。 セキュリティのために有用なオプションです。 nosuid そのファイルシステム上の setuid や setgid フラグを解釈しません。 これもセキュリティのために有用なオプションです。 <command>umount</command> コマンド ファイルシステム アンマウント &man.umount.8; コマンドは、パラメータとしてマウントポイントの一つ、 デバイス名、もしくは や といったオプションを取ります。 いずれの形式でも で強制的なアンマウントを行ない、 で詳細な出力を出します。 ただしほとんどの場合、 は使わないほうがよいでしょう。 強制的にファイルシステムをアンマウントすると、 計算機がクラッシュしたりファイルシステム上部のデータが 破壊されたりする恐れがあるためです。 オプション と はマウントされているファイルシステムすべてをアンマウントするのに使います。 にファイルシステムタイプを指定すると、 指定されたものだけがアンマウントされます。 また、 を使うとルートファイルシステムはアンマウントしません。 プロセス FreeBSD はマルチタスクのオペレーティングシステムです。 つまり、1つ以上のプログラムがあたかも同時に動いているかのように見える、 ということです。動作中のプログラムはそれぞれ プロセス と呼ばれます。 コマンドを実行すると、最低でも1つの新しいプロセスがスタートします。 システムを正常に機能させるために常に動作しているシステムプロセスもたくさんあります。 各プロセスはプロセス ID、もしくは PID と呼ばれる数字でただ一つに識別されます。 また、ファイルのように各プロセスには所有者とグループがあります。 所有者とグループの情報は、 これまでに見たファイル許可属性を用い、 そのプロセスが開けるファイルやデバイスを決定するために使われます。 多くのプロセスには親プロセスもあります。 親プロセスとは、そのプロセスをスタートさせたプロセスのことです。 例えば、シェルにコマンドを打ち込んでいるときはシェルがプロセスで、 動かすコマンドもまたどれもプロセスです。 このようにして起動するプロセスはそれぞれシェルが親プロセスになります。 これの例外は init という特別なプロセスです。 init は常に最初のプロセスなので、 PID は必ず 1 になります。 init は FreeBSD がスタートするときカーネルによって自動的に起動されます。 &man.ps.1; と &man.top.1; という2つのコマンドが システム上のプロセスを確認するために特に便利です。 &man.ps.1; コマンドは現在動作中のプロセスのリストを見るために使い、 PID やプロセスが使っているメモリの量、 どういうコマンドラインで起動されたのか、 などを表示させることができます。 &man.top.1; コマンドは動作中の全てのプロセスを表示し、 数秒ごとに表示を更新するので、 計算機がなにをしているのかインタラクティブに知ることができます。 デフォルトでは、&man.ps.1; は動作中かつ所有者が自分のコマンドのみを表示します。 例えば: &prompt.user; ps PID TT STAT TIME COMMAND 298 p0 Ss 0:01.10 tcsh 7078 p0 S 2:40.88 xemacs mdoc.xsl (xemacs-21.1.14) 37393 p0 I 0:03.11 xemacs freebsd.dsl (xemacs-21.1.14) 48630 p0 S 2:50.89 /usr/local/lib/netscape-linux/navigator-linux-4.77.bi 48730 p0 IW 0:00.00 (dns helper) (navigator-linux-) 72210 p0 R+ 0:00.00 ps 390 p1 Is 0:01.14 tcsh 7059 p2 Is+ 1:36.18 /usr/local/bin/mutt -y 6688 p3 IWs 0:00.00 tcsh 10735 p4 IWs 0:00.00 tcsh 20256 p5 IWs 0:00.00 tcsh 262 v0 IWs 0:00.00 -tcsh (tcsh) 270 v0 IW+ 0:00.00 /bin/sh /usr/X11R6/bin/startx -- -bpp 16 280 v0 IW+ 0:00.00 xinit /home/nik/.xinitrc -- -bpp 16 284 v0 IW 0:00.00 /bin/sh /home/nik/.xinitrc 285 v0 S 0:38.45 /usr/X11R6/bin/sawfish この例で分かるとおり、 &man.ps.1; の出力はいくつかの行に整形されています。 PID は先ほど見たプロセス ID です。 PID は 1 から順に 99999 まで割り当てられ、 足りなくなると最初に戻って使い回されます。 TT はプログラムが動いている tty を示します。 差し当たって無視してもかまわないでしょう。 STAT はプログラムの状態を示しますが、 これもまた無視してよいでしょう。 TIME はプログラムがその CPU 上で動いている時間の長さです—これはプログラムをスタートさせたとき からの経過時間であるとはかぎりません。 CPU 上で時間を使う必要があるまでかなりの時間を費すようなプログラムもあるからです。 最後に、COMMAND はそのプログラムを起動するのに使われたコマンドラインとなります。 &man.ps.1; は表示する情報を変えるためのオプションをたくさんサポートしています。 いちばん便利なのは auxww でしょう。 は自分のプロセスだけではなく、 動作中のプロセス全部についての情報を表示します。 はプロセスの所有者の名前をメモリ使用量と同様に表示します。 はデーモンプロセスについての情報を表示し、 で、スクリーンに入りきらないほど長くなったコマンドラインでも省略せず、 &man.ps.1; に全コマンドラインを表示させます。 &man.top.1; の出力も同様です。 例は以下の通りです。 &prompt.user; top last pid: 72257; load averages: 0.13, 0.09, 0.03 up 0+13:38:33 22:39:10 47 processes: 1 running, 46 sleeping CPU states: 12.6% user, 0.0% nice, 7.8% system, 0.0% interrupt, 79.7% idle Mem: 36M Active, 5256K Inact, 13M Wired, 6312K Cache, 15M Buf, 408K Free Swap: 256M Total, 38M Used, 217M Free, 15% Inuse PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 72257 nik 28 0 1960K 1044K RUN 0:00 14.86% 1.42% top 7078 nik 2 0 15280K 10960K select 2:54 0.88% 0.88% xemacs-21.1.14 281 nik 2 0 18636K 7112K select 5:36 0.73% 0.73% XF86_SVGA 296 nik 2 0 3240K 1644K select 0:12 0.05% 0.05% xterm 48630 nik 2 0 29816K 9148K select 3:18 0.00% 0.00% navigator-linu 175 root 2 0 924K 252K select 1:41 0.00% 0.00% syslogd 7059 nik 2 0 7260K 4644K poll 1:38 0.00% 0.00% mutt ... 出力は2つのセクションに分かれています。 ヘッダ(最初の5行です)は動作している最新のプロセスの PID、 システムの平均負荷(システムがどれくらい忙しいかの指標)、 システムの稼働時間(最後の再起動からの時間) と現在の時刻を示します。 ヘッダの中の他の数字は動作中のプロセスの数(この場合 47 ですね)、 使われているメモリとスワップ領域の量、 そしてシステムが異なる CPU 状態に消費した時間と関係します。 その下には &man.ps.1; の出力と同じような情報を持った行が続きます。 前と同様 PID にユーザ名、消費 CPU 時間と実行中のコマンドを知ることができます。 &man.top.1; を使うとデフォルトでプロセスが使っているメモリ容量も分かります。 メモリ使用量の欄は2項目に分かれており、 一方は合計使用量、 そしてもう一方は実使用量です—合計使用量はアプリケーションが必要としているメモリ量で、 実使用量はその時点で実際に使われているメモリ量です。 この例では、Netscape がだいたい 30MB の RAM を必要としていますが、 いまのところ 9MB しか使っていないことが分かります。 &man.top.1; は自動的に2秒ごとに画面を更新します。 オプションを使えば更新間隔を変更することができます。 デーモン、シグナルとプロセス終了 エディタを使っている場合、エディタを操作するのは簡単です。 ファイルを開く、などと動かせばよいのです。 このように操作できるのは、エディタにそういった機能があり、 かつエディタが端末に関連づけられているからです。 一方、ユーザから始終入力があるように設計されていないプログラムもあり、 そういったプログラムは最初から端末と切り離されます。 例えば、ウェブサーバは一日中ウェブのリクエストばかり処理するので、 通常全く入力を必要としません。 サイトからサイトへとメールを転送するプログラムも、 こういった種類のアプリケーションの一例です。 このようなプログラムは、デーモンと呼ばれます。 デーモンはギリシャ神話の登場人物で、 善でも悪でもなく、大雑把にいうと、 人間のために役立つことをしてくれる小さな妖精さんです。 今日の便利なウェブサーバやメールサーバととてもよく似ていますね。 このため、長い間 BSD のマスコットはスニーカーをはいてフォークを携えた かわいらしい姿のデーモンなのです。 通常デーモンとして動作するプログラムには末尾に d を持った名前をつける慣習があります。 BIND は Berkeley Internet Name Daemon ですし (実際実行されるプログラムは named という名前です)、 Apache ウェブサーバのプログラムは httpd と呼ばれますし、 ラインプリンタスプーリングデーモンは lpd、 などなどです。 これは単なる慣習で、しっかりがっちりとしたルールではありません。 例えば、Sendmail アプリケーションの主なメールデーモンは sendmail という名前で、 連想しそうな maild ではありません。 時々、デーモンプロセスと通信したいときがあります。 この通信はシグナルと呼ばれ、 デーモンにシグナルを送ることによってデーモン (に限らずどんな動作中のプロセスでも)と通信することができます。 送信可能なシグナルはたくさんあります—特別な意味があるものもあれば、 アプリケーションによって解釈されるものもありますし、 アプリケーションがシグナルをどう解釈するかは そのアプリケーションの文章を読めば分かるでしょう。 自分が持っているプロセスにしかシグナルを送ることはできません。 他人のプロセスに &man.kill.1; や &man.kill.2; を使ってシグナルを送っても、許可されないでしょう。 これの例外は root ユーザで、 ルートユーザは誰のプロセスでもシグナルを送ることができます。 FreeBSD もアプリケーションにシグナルを送ることがあります。 アプリケーションを下手に書くと、 予想外のメモリにアクセスしようとするので、 FreeBSD がプロセスに セグメンテーション違反 シグナル (SIGSEGV) を送ります。 ある程度の時間が経ったら &man.alarm.3; システムコールを使って警告してもらうようなアプリケーションには、 警告シグナル (SIGALRM) が送信される、 などです。 プロセスを止めるためには2つのシグナル、 SIGTERM か SIGKILL を使います。 SIGTERM は穏かにプロセスを終了させる方法です。 プロセスはシグナルを受け取ることができ、 終了させたいのだなということを理解し、 開いているログファイルを全部を閉じ、 一般的に終了前にしていたことを終えることができます。 中断できない処理の途中だと、SIGTERM をプロセスが無視することもあるかもしれません。 プロセスは SIGKILL を無視することができません。 これは、なにをしていようが構わないから今すぐ止まれ というシグナルです。 プロセスに SIGKILL を送ると、 FreeBSD はそのプロセスをそこで止めます 正確ではありません—中断できないものはわずかながら存在します。 例えば、プロセスがネットワーク上の別の計算機にあるファイルを読もうとして、 その計算機がなんらかの理由 (電源を落とされたとか、ネットワークに問題があるとか) でいなくなった場合、そのプロセスは中断不可能と言われます。 最終的にはそのプロセスはタイムアウトします。普通は2分後です。 タイムアウトした直後、そのプロセスは終了します。 。 使う可能性のあるシグナルは、他に SIGHUP、SIGUSR1、と SIGUSR2 があります。 これらは一般的な用途のシグナルで、 このシグナルが送信されたときアプリケーションによって別のことをします。 ウェブサーバの設定ファイルを変更したとしましょう—ウェブサーバに新しい設定を再読み込みさせたいですね。 httpd を止めて再起動することもできますが、 そうするとウェブサーバは一瞬ながら停止してしまいますし、 ちょっとでも止まってほしくないこともあるでしょう。 ほとんどのデーモンは SIGHUP シグナルに対して設定ファイルを再読み込みする反応を返すよう書かれています。 従って、httpd を止めて再起動する代わりに、 SIGHUP シグナルを送りましょう。 これらのシグナルへの標準的な反応というものがないために、 デーモンごとに行動が違うので、 疑問があれば必ずそのデーモンの文書を読んでください。 &man.kill.1; コマンドを使って送るシグナルはこの例をご覧ください。 プロセスにシグナルを送る この例では、&man.inetd.8; にシグナルを送る方法を示します。 &man.inetd.8; の設定ファイルは /etc/inetd.conf で、 &man.inetd.8; は SIGHUP が送信されるとこの設定ファイルを再読み込みします。 シグナルを送りたいプロセスのプロセス ID を探します。 それには &man.ps.1; と &man.grep.1; を使います。 &man.grep.1; コマンドは出力を検索するために使い、 指定した文字列を探します。 このコマンドは一般ユーザで実行しますが、 &man.inetd.8; は root で実行されているので、 &man.ps.1; には オプションを与える必要があります。 &prompt.user; ps -ax | grep inetd 198 ?? IWs 0:00.00 inetd -wW ということで、&man.inetd.8; の PID は 198 です。 grep inetd コマンドがこの出力に出てくる場合もあります。 それは、&man.ps.1; が動作中のプロセスのリストを見つける方法によります。 &man.kill.1; を使ってシグナルを送ります。 &man.inetd.8; は root で起動されているために、 まず &man.su.1; を使って root にならなければなりません。 &prompt.user; su Password: &prompt.root; /bin/kill -s HUP 198 大部分の Unix コマンドと同じく、 成功したら &man.kill.1; は何の出力も表示しません。 自分のものではないプロセスにシグナルを送ると、 kill: PID: Operation not permitted と表示されます。 PID を打ち間違えると、 悪いことに間違ったプロセスにシグナルを送ってしまうか、 もしくは運がよければその時点で使われていない PID にシグナルを送ったことになり、kill: PID: No such process と表示されます。 なぜ <command>/bin/kill</command> を使うんでしょう? 多くのシェルは kill コマンドを組み込みコマンドとして備えています。 つまり、/bin/kill を実行するのではなく、 シェルが直接シグナルを送ります。 これはとても便利なのですが、 シェルが違うと送るシグナルの名前の指定の仕方が違います。 シェルによって異なるシグナルの指定の仕方を全部覚えようとはせずに、 /bin/kill ... コマンドを直接使うほうが簡単です。 他のシグナルの送り方はほとんど同じで、 コマンドラインの TERM や KILL を必要に応じて変えるだけです。 システム上のランダムプロセスを終了させるのはよくありません。 特に、プロセス ID が 1 の &man.init.8; は特別です。 - Running /bin/kill -s KILL 1 を使うといとも簡単にシステムをシャットダウンさせることができます。 Return を押す前に &man.kill.1; を実行する引数を二重にチェックする癖をつけてください。 シェル シェル(shell) コマンドライン FreeBSD では日々の作業のほとんどは、 「シェル」と呼ばれるコマンドラインインタフェイスを通して行われます。 シェルの主な仕事はコマンドを入力チャンネルから受け取り、 そしてそれらを実行することです。 大部分のシェルはさらに組み込みの機能を持っていて、日々の作業、 ファイル管理やファイル名の展開、コマンドライン編集、 コマンドマクロ、環境変数などに便利です。 FreeBSD には sh (Bourne Shell) や tcsh (高機能 C-shell) が含まれています。 また、 これ以外にも zsh や bash などたくさんのシェルが FreeBSD Ports Collection から利用可能です。 「あなたは、どのシェルを使いますか?」という質問は、 まったく趣味の問題です。 あなたが C のプログラマだったとすれば、 tcsh のような C 風のシェルの方が落ち着くかもしれません。 Linux から来た人や Unix のコマンドラインインタフェイスになじみがなければ、 bash を試すのも良いでしょう。 ポイントは、それぞれのシェルは、 あなたの好みの作業環境で利用できる(もしくはできない)独自の機能を持っているということ、 そして、どのシェルを使うことにするかを決めるのはあなた自身だということです。 シェルの一般的な機能の一つに、ファイル名の補完があります。 コマンドやファイル名の最初の数文字を与えて Tab キーを押すことで、 シェルにコマンドやファイル名の残りの部分を自動的に補完させることができます。 例をあげましょう。 二つのファイル foobar, foo.bar が あったとします。 ここで foo.bar の方を削除するには、 rm fo[Tab].[Tab] と入力します。 環境変数(environment variables) するとシェルは rm foo[BEEP].bar と出力するでしょう。 [BEEP] のところはコンソールのベル(訳注: 通常はビープ音が鳴ります)です。 これは複数のファイルがマッチしたため、 ファイル名の補完を完全に行なえなかったことを伝えています。 foobar と foo.bar は 両方とも fo ではじまるため、 補完できるのは foo までです。 ここで . を入力して Tab を押せば、 シェルはファイル名の残りの部分を補完できます。 もう一つあげられるシェルの特徴として、環境変数があります。 環境変数とは、シェルの環境変数空間におけるキーと値とのペアです。 この変数空間は、そのシェルから起動されたプログラムから参照でき、 それを利用してプログラムの設定を保存するのに利用されます。 下の表は、一般的な環境変数とその意味を示したものです。 環境変数(environment variables) 変数名 意味 USER 現在のログインユーザのユーザ名。 PATH コロンで区切られた実行ファイル探索のための ディレクトリのリスト。 DISPLAY 接続する X11 ディスプレイのネットワーク名(存在する場合のみ)。 SHELL 現在のシェル。 TERM ユーザの端末名。 端末のケーパビリティを決定するのに使われる。 TERMCAP 種々の端末の機能を実現する端末のエスケープコードの データベースのエントリ。 OSTYPE オペレーティングシステムの種別。 たとえば FreeBSD。 MACHTYPE システムが動作している CPU のアーキテクチャ。 EDITOR ユーザの選んだテキストエディタ。 PAGER ユーザの選んだテキストページャ。 MANPATH コロンで区切られたマニュアルページ探索のための ディレクトリのリスト。 Bourne シェル(Bourne shells) 環境変数をセットする方法は、 それぞれのシェルごとに多少異なります。 たとえば、tcsh や csh 等の C シェルでは setenv を使います。 sh や bash 等の Bourne シェルでは set と export を使います。 たとえば csh か tcsh で EDITOR 環境変数の値を /usr/local/bin/emacs に セットするか変更するには、次のようにします。 &prompt.user; setenv EDITOR /usr/local/bin/emacs Bourne シェルでは次のようになります。 &prompt.user; export EDITOR="/usr/local/bin/emacs" ほとんどのシェルでは、 コマンドライン中の変数名の前に $ 文字を置くことで、 環境変数を展開させることができます。 たとえば、 echo $TERM は $TERM が セットされている内容を表示します。 それはシェルが $TERM を展開して echo に渡しているからです。 シェルはさまざまな特殊文字を、特別なデータを表すものとして扱います。 その特殊文字はメタキャラクタと呼ばれます。 もっとも一般的なものは * で、 これはファイル名に含まれる、あらゆる文字を表します。 これらの特殊なメタキャラクタはファイル名の展開に使われます。 たとえば、echo * と入力すると ls と入力したのとほとんど同じ結果を得られます。 これはシェルが * とマッチするすべてのファイルを 受け取って echo のコマンドラインに渡し、表示するからです。 これらの特殊文字をシェルに解釈させないようにするため、 特殊文字の前にバックスラッシュ文字 (\) を置くことができます。 echo $TERM は、 あなたの端末が何にセットされているかを表示します。 echo \$TERM は $TERM と そのまま表示します。 シェルの変更 シェルを変更する一番簡単な方法は chsh コマンドを使うことです。 chsh を実行すると 環境変数 EDITOR で示されたエディタが立ち上がります。 環境変数をセットしていなかった時は vi が立ち上がります。 Shell: の行を適宜変更してください。 chsh に オプションをつけると、 エディタを起動せずにシェルを変更することが可能です。 たとえば、シェルを bash に変えたいなら、次のようにしてください。 &prompt.user; chsh -s /usr/local/bin/bash chsh をパラメータなしで実行し、 エディタでシェルを変更しても同じことができます。 使おうと思っているシェルは必ず /etc/shells 中に書かれているものでなければなりません。 シェルを Ports コレクションから インストールしていたのであれば、すでにそれは行なわれていますが、 手動でインストールした場合は、それを忘れずに行ってください。 たとえば、bash を手動で /usr/local/bin にインストールした場合 以下のようにする必要があります。 &prompt.root; echo "/usr/local/bin/bash" >> /etc/shells そして chsh を実行してください。 テキストエディタ テキストエディタ エディタ さまざまな FreeBSD の設定は、テキストファイルを編集することで行われます。 そのため、テキストエディタの扱いに慣れると良いでしょう。 FreeBSD には、基本システムの一部として二、三提供されるものと、 Ports collection から利用できる、たくさんのテキストエディタが用意されています。 ee 最も学習が簡単なエディタは、 easy editor の略で ee と呼ばれるものです。 ee を立ち上げるには、コマンドラインから ee filename と入力します。 ここで filename は、 編集しようとしているファイルの名前です。 たとえば、/etc/rc.conf を編集するには ee /etc/rc.conf と入力します。 一旦 ee の中に入れば、 エディタの機能を操作するコマンドはすべてディスプレイの上部に 表示されています。キャレット ^ 文字は キーボードの Ctrl キーを意味しますので、 ^e はキーのコンビネーション Ctrle を押すという意味になります。 ee を終了するには Esc キーを押し、 そして leave editor を選びます。 ファイルが更新されていたときは、 エディタは変更をセーブするかどうかプロンプトを出します。 vi エディタ vi emacs エディタ emacs FreeBSD には、基本システムの一部として vi、 一方 emacs や vim といった他のエディタは Ports Collection の一部として、 より強力なテキストエディタが用意されています。 これらのエディタはやや学習が複雑ですが、より強力で高い機能性を提供します。 しかし、あなたが多量のテキストを編集することを考えているなら、 vim や emacs といった強力なエディタを習得することは、 より多くの時間を節約することでしょう。 デバイスとデバイスノード デバイスとはシステム上のハードウェアに関するものに対してよく使われる用語で、 ディスクやプリンタ、グラフィックカードやキーボードが含まれます。 FreeBSD が起動するとき、FreeBSD が表示しているものの大部分は検出されたデバイスです。 /var/run/dmesg.boot を眺めれば起動メッセージを読み直すことができます。 例えば、acd0 は最初の IDE CDROM ドライブで、kbd0 はキーボードを表します。 Unix オペレーティングシステムにおけるデバイスのほとんどは、 デバイスノードと呼ばれる /dev ディレクトリにあるスペシャルファイルを通してアクセスしなければなりません。 デバイスノードを作成する 新しいデバイスをシステムにつけ足したり、 追加デバイスのサポートをコンパイルして加えたりするときは、 デバイスノードを追加で作成しなければならない場合があります。 MAKEDEV スクリプト DEVFS がないシステムでは、 以下に示すように &man.MAKEDEV.8; スクリプトを使ってデバイスノードを作成します。 &prompt.root; cd /dev &prompt.root; sh MAKEDEV ad1 この例では、取りつけられたとき2番目に当たる IDE ドライブにとって適切なデバイスノードを作ります。 <literal>DEVFS</literal> (デバイスファイルシステム: Device File System) デバイスファイルシステム DEVFS は、 グローバルファイルシステム名前空間の中のカーネルデバイス名前空間へのアクセスを提供します。 デバイスノードを作成したり変更したりするのではなく、 DEVFS がこの特別なファイルシステムを管理するのです。 詳しくは &man.devfs.5; マニュアルページをご覧ください。 FreeBSD 5.0 では DEVFS がデフォルトで使われています。 さらに詳しい情報を得るには... オンラインマニュアル マニュアルページ FreeBSD についてのもっとも包括的な文書は、 マニュアルページの形式になっているものです。 FreeBSD システム上のほとんどすべてのプログラムには、 基本的な操作方法とさまざまな引数を説明しているリファレンスマニュアルが添付されています。 これらのマニュアルは man コマンドで見ることができます。man コマンドの使い方は簡単です。 &prompt.user; man コマンド名 コマンド名 のところには、知りたいコマンドの名前を入れます。 たとえば ls コマンドについて知りたい場合には、 次のように入力します。 &prompt.user; man ls オンラインマニュアルは、 セクション番号で分類されています。 ユーザコマンド システムコールとエラー番号 C のライブラリ関数 デバイスドライバ ファイル形式 ゲームや娯楽 さまざまな情報 システムの管理と操作のためのコマンド カーネル開発者のための情報 時折、 同じトピックがオンラインマニュアルの複数のセクションに記載されている場合があります。 たとえば、chmod ユーザコマンドと chmod() システムコールの場合がそれに該当します。 この場合、man コマンドにセクション番号を与えることで、 どちらを参照したいかを指定することができます。 &prompt.user; man 1 chmod 上のようにすれば、 ユーザコマンド chmod のマニュアルページが表示されます。 オンラインマニュアルの特定セクションへの参照は、 慣習的に書かれている文書で括弧の中に示されます。 すなわち、&man.chmod.1; は chmod ユーザコマンドを、&man.chmod.2; はシステムコールの方を示しています。 コマンドの名前を知っていて、 単純にその使い方を知りたい場合はここまでの説明で十分でしょう。 しかし、 もしコマンドの名前を思い出せない場合にはどうしたら良いのでしょうか? man に スイッチをつければ、 コマンド解説(description)の文章から、 指定したキーワードを検索することができます。 &prompt.user; man -k mail このコマンドにより、 mail というキーワードをコマンド解説に含むコマンドの一覧が表示されます。 実際には、これは apropos コマンドを使う場合と同等の機能です。 それでは、/usr/bin にあるさまざまなコマンドすべてを見ていて、 それらが実際にどう働くのかが、まったく見当もつかないときには どうしたら良いでしょう? そのときは単純に、 &prompt.user; cd /usr/bin &prompt.user; man -f * とするか、あるいは同じ働きをする &prompt.user; cd /usr/bin &prompt.user; whatis * としてください。 GNU の Info ファイル Free Software Foundation FreeBSD には Free Software Foundation (FSF) によるアプリケーションや ユーティリティがたくさん含まれています。 これらのプログラムには、マニュアルページに加えて info ファイルと呼ばれる ハイパーテキスト形式の文書が付属しています。 この文書は info コマンド、 あるいは emacs をインストールしているなら emacs の info モードで読むことができます。 &man.info.1; コマンドを使うには、単に次のように入力します。 &prompt.user; info h と入力すると、 簡単な手引きを読むことができます。 クイックコマンドリファレンスは ? を入力してください。 diff --git a/ja_JP.eucJP/books/handbook/boot/chapter.sgml b/ja_JP.eucJP/books/handbook/boot/chapter.sgml index 68f12d7e99..9b4729d9d7 100644 --- a/ja_JP.eucJP/books/handbook/boot/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/boot/chapter.sgml @@ -1,869 +1,869 @@ FreeBSD の起動のプロセス この章では 起動 ブートストラップ (bootstrap) 計算機を起動しオペレーティングシステムをロードするプロセスは、 ブートストラッププロセス、 もしくは単に 起動 と呼ばれます。 FreeBSD の起動プロセスを使えば、 システムをスタートするときに起きることを かなり柔軟にカスタマイズすることができます。 同じ計算機にインストールされた 別のオペレーティングシステムを選択することもできますし、 同じオペレーティングシステムの違うバージョンを選択することも、 インストールされた別のカーネルを選択することさえできます。 この章では、指定できる設定オプションと FreeBSD の起動プロセスのカスタマイズ方法について詳しく述べます。 この章では FreeBSD カーネルがスタートし、デバイスを検出し、 &man.init.8; を起動するまでに起きることすべてを扱います。 どの最中のことだかはっきりしていない人のために補足すると、 テキストの色が明るい白から灰色に変わるまでに起きていることです。 この章を読むと、以下のことが分かります。 どのように FreeBSD のブートストラップシステムが構成され、 そしてそれらが互いにどう関係しているのか 起動プロセスを制御するために FreeBSD のブートストラップの各要素に付加できるオプション &man.device.hints.5; の基本的な記述方法 x86 限定 この章では Intel x86 システム上で動作する FreeBSD の起動プロセスだけを扱います。 起動時の問題 計算機の電源を入れ、オペレーティングシステムをスタートさせるのには、 おもしろいジレンマがあります。 定義により、計算機は オペレーティングシステムがスタートするまで何もする方法を知りません。 ディスクからプログラムを動かすのも含みます。 では、計算機はオペレーティングシステムなしに ディスクからプログラムを実行することができず、 オペレーティングシステムのプログラムがディスク上にあるのなら、 どうやってオペレーティングシステムをスタートさせるのでしょう? この問題はほらふき男爵の冒険という本の中に 書かれている問題ととてもよく似ています。 登場人物がマンホールの下に半分落っこちて、 靴紐 (ブートストラップ) をつかんで自分を引っぱり、持ち上げるのです。 計算機の黎明期には、ブートストラップ という用語でオペレーティングシステムをロードする 機構のことを指していたのですが、 いまは短く 起動 (ブート) と言います。 x86 ハードウェアでは、基本入出力システム (Basic Input/Output System: BIOS) にオペレーティングシステムをロードする責任があります。 オペレーティングシステムをロードするために、 BIOS がハードディスク上のマスターブートレコード (Master Boot Record: MBR) を探します。 MBR はハードディスク上の特定の場所になければなりません。 BIOS には MBR をロードし起動するのに十分な知識があり、 オペレーティングシステムをロードするために必要な作業の残りは MBR が実行できることを仮定しています。 BIOS 基本入出力システム (Basic Input/Output System) ディスク上にオペレーティングシステムを一つだけ インストールしているなら、標準の MBR で十分です。 この MBR はディスク上の最初の起動可能なスライスを探し、 そのスライスにあるコードを起動して 残りのオペレーティングシステムをロードします。 ディスク上にオペレーティングシステムを複数インストールしているなら、 別の MBR — 複数のオペレーティングシステムのリストを表示できて、 起動するオペレーティングシステムを選択できるような MBR — をインストールすることができます。 FreeBSD はそのような MBR とともに配布されており、 この MBR をインストールすることもできます。 他のオペレーティングシステムのベンダも 標準 MBR に代わる MBR を提供しています。 FreeBSD ブートストラップシステムの残りは 3 段階に分かれます。 第 1 ステージは MBR によって起動されるもので、 MBR は計算機を特定の状態にするために必要なことだけ知っていて、 第 2 ステージを起動します。 第 2 ステージでは、第 3 ステージを起動する前に、 もうちょっとやることができます。 第 3 ステージでオペレーティングシステムのロード作業を完了します。 起動作業がこれらの 3 段階に分かれているのは、 PC の規格がステージ 1 とステージ 2 で実行できるプログラムのサイズに制限を課しているからです。 これらの作業をつなぎ合わせることによって、 FreeBSD はより柔軟なローダ (loader) を提供しているのです。 カーネル (kernel) init その後カーネルが起動し、デバイスの検出と初期化を開始します。 そしてカーネルの起動が終わると、制御はユーザープロセスの &man.init.8; へ移されます。&man.init.8; はまず ディスクが利用可能であることを確かめ、 ファイルシステムのマウント、 ネットワークで利用するネットワークカードのセットアップ、 そして通常 FreeBSD システムで初期時に起動されるすべてのプロセスの起動、 といったユーザーレベルでのリソース (資源) 設定を行ないます。 MBR、起動ステージ 1、2 および 3 MBR、<filename>/boot/boot0</filename> マスターブートレコード (MBR) FreeBSD の MBR は /boot/boot0 にあります。これは MBR のコピーであり、 本当の MBR はディスク上の特別な部分、 つまり FreeBSD 領域の外に置く必要があります。 boot0 は非常に単純なプログラムです。 これは、MBR にあるプログラムは 512 バイトの大きさでなければならないという制限があるためです。 FreeBSD の MBR をインストールし、 かつハードディスク上に複数のオペレーティングシステムをインストールした場合、 起動時にこれと同じような画面が出るでしょう。 <filename>boot0</filename> のスクリーンショット F1 DOS F2 FreeBSD F3 Linux F4 ?? F5 Drive 1 Default: F2 他のオペレーティングシステム、特に &windows; 95 は、 既存の MBR を自らの MBR で上書きしてしまうことで知られています。 もしそうなってしまったら、 もしくは既存の MBR を FreeBSD の MBR で置き換えたいのなら、 次のコマンドを使ってください。 &prompt.root; fdisk -B -b /boot/boot0 device device は起動するデバイス名で、 たとえば 1 番目の IDE ディスクは ad0、 2 番目の IDE コントローラに接続されている 1 番目の IDE ディスクは ad2、 1 番目の SCSI ディスクは da0 などとなります。 しかしながら、もしあなたが Linux ユーザで、 LILO で起動プロセスを制御したいのなら、 FreeBSD 用に /etc/lilo.conf を編集して、 FreeBSD のインストールの際 を選択します。 FreeBSD のブートマネジャをインストールしたのであれば、 Linux を起動し直して LILO の設定ファイル /etc/lilo.conf を変更し、 次のオプションを加えることができます: other=/dev/hdXY table=/dev/hdb loader=/boot/chain.b label=FreeBSD こうすれば、LILO から FreeBSD と Linux を起動することができます。 この例では、ドライブ番号とパーティションを示すために XY を使っています。 SCSI ドライブを使っているのであれば、 /dev/hdXY を /dev/sdXY のように読み替えてください。 XY の指定方法は同じです。 は同じドライブ上に両方のオペレーティングシステムを置いてあるのであれば不要です。 これで /sbin/lilo -v を実行すると システムに新しい変更が反映されるので、 画面のメッセージを見て確認します。 起動ステージ 1 <filename>/boot/boot1</filename> と起動ステージ 2 <filename>/boot/boot2</filename> 概念上、第 1 ステージと第 2 ステージは ハードディスクの同じ領域上の同一のプログラムの部分部分です。 スペースの制約のため 2 つに分割されていますが、 いつも一緒にインストールします。 第 1 ステージと第 2 ステージは起動スライス (slice) の起動セクタにあります。 起動セクタとは、 MBR 上にある boot0 もしくは他のプログラムが、起動のプロセスを続けるために 必要なプログラムがあると想定している場所です。 /boot ディレクトリにあるファイルは実際に使われるファイルのコピーで、 実際のファイルは FreeBSD ファイルシステムの外部に格納されています。 boot1 も非常に単純なプログラムです。 これは boot0 同様に、 512 バイトの大きさでなければならないという制限があるためです。 boot1 は boot2 を検索し、 実行するため、そのスライスの情報を保持する FreeBSD のディスクラベル (disklabel) に関する最低限の情報を持っています。 boot2 はもう少し高機能です。 これは FreeBSDのファイルシステム上でファイルを見つける能力を持ち、 実行するカーネルやローダを指定するための 簡単なインタフェイスを提供します。 ローダ (loader) はさらに高機能なもので、 使いやすく簡単な起動設定が行なえる手段を提供します。 boot2 は通常それを起動します。 以前の boot2 には、 カーネルを直接起動する機能しかありませんでした。 <filename>boot2</filename> のスクリーンショット >> FreeBSD/i386 BOOT Default: 0:ad(0,a)/kernel boot: もし仮にインストールされた boot1 と boot2 を変更したいのであれば、 &man.disklabel.8; を使ってください。 &prompt.root; disklabel -B diskslice diskslice は起動するディスクとスライスで、 たとえば最初の IDE ディスクの 1 番目のスライスは ad0s1 となります。 Dangerously Dedicated Mode &man.disklabel.8; を使うとき、 ad0 のようにディスク名だけを指定すると、 スライスを持たない危険な専用ディスクを作成してしまいます。 たぶん間違いなく、そうしたいわけではないでしょうから、 必ず Return キーを押す前に &man.disklabel.8; コマンドを二重にチェックしてください。 起動ステージ 3 <filename>/boot/loader</filename> ブートローダ (boot-loader) ローダは三段階の起動プロセスの最終段階です。 ローダは通常、ファイルシステム上の /boot/loader として存在しています。 ローダは、よりさまざまなコマンド群をサポートした 強力なインタプリタによって提供される簡易組み込みコマンド群を利用することで、 ユーザが利用しやすい設定手段となるように設計されています。 ローダプログラムの処理の流れ ローダは初期化の際にコンソールとディスクの検出を行ない、 どのディスクから起動しているかを調べます。 そして必要な変数を設定してからインタプリタを起動し、 スクリプトからコマンドを送ったり手でコマンドを入力したりできます。 ローダ ローダの設定 ローダは次に /boot/loader.rc を読み込み、通常、変数の標準値を定義した /boot/defaults/loader.conf と、そのマシンにローカルな変数を定義した /boot/loader.conf を読み込みます。 loader.rc はそれらの変数にもとづき、 選択されたモジュールとカーネルをロードします。 ローダは最後に、標準設定で 10 秒のキー入力待ち時間を用意し、 入力がなければカーネルを起動します。 入力があった場合、簡易コマンド群が使えるプロンプトが表示され、 ユーザは変数を調整したり、 すべてのモジュールをアンロードしたり、 モジュールをロードしたりすることができます。 その後、最終的な起動や再起動へ移行します。 ローダの組み込みコマンド もっともよく使われるローダのコマンドを以下に示します。 利用可能なコマンドをすべて知りたい場合、 &man.loader.8; を参照してください。 autoboot seconds seconds で与えられた時間内に入力がなければ、 カーネルの起動へと進みます。 カウントダウンを表示し、標準設定では 10 秒間です。 boot -options kernelname すぐにカーネルの起動へ進みます。 オプション、カーネル名が指定されている場合は、 それらが使われます。 boot-conf すべてのモジュールの設定を、 起動時と同じように変数にもとづいて自動的に行ないます。 このコマンドは、まず unload を行なって、 変数—普通 kernel など—を変更した場合にのみ有効に働きます。 help topic /boot/loader.help を読み込み、ヘルプメッセージを表示します。 topic に index 指定された場合、 利用可能な topic を表示します。 include filename … 指定されたファイル名のファイルを処理します。 ローダはファイルを読み込み、行単位で解釈します。 エラーが発生した場合、 include コマンドの実行はその時点で停止します。 load type filename 指定されたファイル名のカーネル、 カーネルモジュール、あるいは type に指定された種類のファイルをロードします。 ファイル名以降に指定された引数はファイルへと渡されます。 ls path 指定された path にあるファイルを表示します。 path が指定されていなければ、ルートディレクトリを表示します。 が指定されていればファイルサイズも表示されます。 lsdev モジュールがロード可能なすべてのデバイスを表示します。 もし が指定されていれば、 より詳細な出力がされます。 lsmod ロード済みのモジュールを表示します。 が指定されていれば、 より詳細な内容が出力されます。 more filename LINES 単位でスクロールを停止しながら指定されたファイルを表示します。 reboot すぐにシステムを再起動します。 set variable set variable=value ローダの環境変数を設定します。 unload すべてのロード済みモジュールを削除します。 ローダの使用例 次にあげるのは、ローダの実践的な使用例です。 シングルユーザモード 普段使っているカーネルをシングルユーザモードで起動します。 boot -s 普段使っているカーネルとモジュールをアンロードし、 古い (もしくは別の) カーネルをロードします。 kernel.old unload load kernel.old kernel.GENERIC とすると、 インストールディスクに入っていた generic カーネルを指定することができます。 また、直前にインストールされていたカーネル (たとえば、 カーネルを自分で設定したり、 アップグレードしたりした場合) を指定するには kernel.old とします。 普段のカーネルで使っているモジュールを 指定したカーネルでロードする場合は、下のようにします。 unload set kernel="kernel.old" boot-conf カーネルの設定スクリプト (通常、 カーネル起動時に設定される内容を自動化するスクリプト) をロードします。 load -t userconfig_script /boot/kernel.conf カーネル起動時の応答 カーネル (kernel) 起動時の応答 カーネルがローダ (通常は) かboot2 (ローダを迂回して) によってロードされると、 起動フラグを調べます。 もし起動フラグがあれば、それに応じて動作を調整します。 カーネル起動フラグ カーネル (kernel) 起動フラグ 良く使われる起動フラグは次のとおりです。 カーネル初期化中に、 ルートファイルシステムとしてマウントするデバイスを尋ねます。 CDROM から起動します。 起動時にカーネルコンフィグレーションを行なう UserConfig を実行します。 シングルユーザモードで起動します。 カーネル起動時により詳細な情報を表示します。 起動フラグはこの他にもあります。 それらについては &man.boot.8; を参照してください。 Tom Rhodes 寄稿: device.hints Device Hints これは FreeBSD 5.0 以降の機能です。 これ以前のバージョンには存在しません。 起動プロセスの間に &man.loader.8; は &man.device.hints.5; を読み込みます。 このファイルにはカーネル起動の環境変数が格納されており、 これらの環境変数は device hints と呼ばれることがあります。 device hints はデバイスを設定するために デバイスドライバが使用します。 device hints は ステージ 3 ブートローダ でも設定できます。device hints は set コマンドを用いて追加することが、 unset コマンドを用いて削除することができます。 show コマンドを用いて一覧を見ることもできます。 /boot/device.hints に設定されている変数は このときに上書きすることができます。 ローダで設定した device hints の効果は一時的なものであるため、 次回起動するときには無効になります。 システムが起動すると、&man.kenv.1; コマンドでカーネル環境変数を ダンプすることができます。 /boot/device.hints は 1 行につき一つの変数を設定でき、 行頭の # はその行がコメントであることを示しています。 書式は次の通りです。 hint.driver.unit.keyword="value" ステージ 3 ブートローダ で設定するときの書式は次の通りです。 set hint.driver.unit.keyword=value driver はデバイスドライバの名前、 unit はデバイスドライバのユニット番号、 keyword はヒントキーワードです。 キーワードは次の設定を指定します: at: デバイスがどのバスに接続されているか指定します。 port: 使用する I/O ポートの開始アドレスを指定します。 irq: 使用する IRQ を指定します。 drq: 使用する DMA チャネルを指定します。 maddr: 使用する物理メモリアドレスを指定します。 flags: デバイスに対してさまざまなフラグを設定します。 disabled: 1 が設定されていると、そのデバイスは無効になります。 デバイスドライバはこのリスト以外の変数を設定できるかもしれませんし、 このリスト以外の変数を必要とするかもしれません。 したがって、デバイスドライバのマニュアルを読むことをおすすめします。 より多くの情報を知りたければ、&man.device.hints.5;, &man.kenv.1;, &man.loader.conf.5;, &man.loader.8; などのマニュアルを参照してください。 init init: プロセス制御の初期化 カーネルの起動が完了すると、&man.init.8; というユーザプロセスに制御が移されます。 これは /sbin/init、 もしくは loader の init_path 変数で指定される場所にあります。 自動再起動 (automatic reboot)の動作 自動再起動では、 システム上で利用できるファイルシステムの一慣性を確認します。 もしそれに問題があって &man.fsck.8; がその不一致を修復できなければ、 管理者に直接対処させるため &man.init.8; はシステムをシングルユーザモードへと移行させます。 シングルユーザモード シングルユーザモード コンソール (console) このモードには、 自動再起動の処理中か、 ユーザが起動時に オプションを指定した場合、 あるいは loader で boot_single 変数を設定することによって移行します。 また、 マルチユーザモードから 再起動オプション () や停止 (halt) オプション () なしで &man.shutdown.8; を呼び出すとこのモードに移行します。 /etc/ttys でシステムコンソール console が insecure に設定されている場合、 システムはシングルユーザモードに移行する前に root のパスワードを入力するように求めます。 <filename>/etc/ttys</filename> の insecure コンソール # name getty type status comments # # If console is marked "insecure", then init will ask for the root password # when going to single-user mode. # # 訳) console に "insecure" という印をつけると、シングルユーザモードへ移行する # 際に init が root のパスワードを要求するようになります。 # console none unknown off insecure insecure コンソールとは、 あなた自身、コンソールが物理的に安全でないと考えていて、 root のパスワードを知る人だけがシングルユーザモードを 使えるようにしたいという意味であり、 コンソールを安全でない状態で使いたいという意味ではありません。 そのため、安全性を求めるならば secure でなく insecure を選んでください。 マルチユーザモード マルチユーザモード &man.init.8; がファイルシステムが正常であると判断するか、 ユーザがシングルユーザモードを終了すると、 システムはマルチユーザモードへ移行し、 リソースの設定を始めます。 リソース設定 (rc) rc ファイル群 リソース設定システムはデフォルト設定を /etc/defaults/rc.conf から、 そのシステム独自の細かな設定を /etc/rc.conf から読み込みます。 そして /etc/fstab に記述されるシステムファイルシステムをマウントし、 ネットワークサービスの開始、 さまざまなシステムデーモンの開始、 そして最後に、ローカルにインストールされた package の起動スクリプトの実行へと進みます。 - リソース設定システムのに関する参考資料は、&man.rc.8; にあります。 + リソース設定システムに関する参考資料は、&man.rc.8; にあります。 これはスクリプトそのものを調べることと同じくらい優れたものです。 シャットダウン動作 shutdown &man.shutdown.8; を用いてシステムを意図的にシャットダウンした場合、 &man.init.8; は /etc/rc.shutdown というスクリプトの実行を試みます。 そして、すべてのプロセスへ TERM シグナルを送り、続いてうまく終了できなかったプロセスへ KILL シグナルを送ります。 電源管理機能を持ったシステムで稼働している FreeBSD では shutdown -p now コマンドによって、 直ちに電源を落とすことができます。FreeBSD を再起動するには、 shutdown -r now を実行するだけです。 &man.shutdown.8; を実行するには、root であるか、operator グループのメンバ でなければなりません。&man.halt.8; や &man.reboot.8; コマンドを 利用することもできますが、より多くの情報を知るために、 それらと &man.shutdown.8; のマニュアルページを参照してください。 電源管理機能は FreeBSD 5.X の &man.acpi.4; がカーネルに組み込まれているか、 モジュールが読み込まれていることを必要とし、 FreeBSD 4.X の &man.apm.4; を必要とします。 diff --git a/ja_JP.eucJP/books/handbook/config/chapter.sgml b/ja_JP.eucJP/books/handbook/config/chapter.sgml index b21b061532..c5158b9e5a 100644 --- a/ja_JP.eucJP/books/handbook/config/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/config/chapter.sgml @@ -1,866 +1,866 @@ 設定とチューニング この章は &a.msmith; と &a.dillon; によって書かれたものをもとに、 &a.chern; と &a.murray によって書かれました。 この章では System configuration System optimization システムを正しく設定することは、 作業の量を減らしメンテナンスや将来の更新の際の困難を減らします。 この章では FreeBSD システムの管理上の設定の側面について記述します。 またこの章では FreeBSD システムのパフォーマンスを最適化する チューンについても記述します。 初期設定 パーティションのレイアウト パーティションレイアウト /etc /var /usr 基本パーティション ファイルシステムのレイアウトを &man.disklabel.8; や &man.sysinstall.8; で行う際、ハードディスクの外周部は 内周部よりもデータ転送が速いということを覚えておくことが大事です。 これに従えば、 ルートやスワップのような小さくて激しくアクセスされるファイルシステムを外周付近に、 /usr のようなより大きなパーティションはその内側に配置すべきでしょう。 そうするなら、パーティションを作成する際には、ルート、スワップ、 /var、/usr のような順で作ってゆくのがよいでしょう。 /var パーティションのサイズは あなたが計算機をどのように使おうとしているかを反映します。 /var は主としてメールボックスやプリントスプール、 ログファイルの保持に使われます。 特にメールボックスとログファイルは、 あなたのシステムのユーザ数やログの保持期間に依存して予期し得ぬサイズにまで成長します。 もしあなたがメールサーバを運用する予定なら /var パーティションはギガバイト以上のものがよいでしょう。 さらに、/var/tmp は追加したくなるかもしれない パッケージを収められるだけの大きさが必要です。 /usr パーティションはシステムを サポートするのに必要なファイル群と、 &man.ports.7; 階層からインストールされたファイル群を収める /usr/local と呼ばれるサブディレクトリを その中に含みます。 ports をまったく使わずシステムのソース (/usr/src) も不要だというのであれば、1 ギガバイトの /usr パーティションだけで充分です。 しかし、ports (特にウィンドウマネージャや Linux エミュレーションを使うバイナリ) を少なからずインストールするのであれば 少なくとも /usr に 2 ギガバイトを薦め、 システムのソースも置こうというなら 3 ギガバイトの /usr を推奨します。 このパーティションで必要になる量を過小評価してはいけません。 それは驚く程に蔓延るものなのです! パーティションのサイズを考える時、 必要量にシステムの成長分を見込んでおいてください。 別のパーティションには潤沢にスペースが余っているのに、 あるパーティションでスペースが足らないままというのは フラストレーションがたまるものです。 &man.sysinstall.8; の Auto-defaults パーティションサイズを使ったことのある人なら、 そのルートや /var パーティションが 小さすぎることを知っているでしょう。 賢明かつ気前よくパーティションを切ってください。 スワップパーティション swap サイズ swap パーティション 経験からスワップサイズはメインメモリの 2 倍というのが一般的です。 つまり、計算機のメモリが 128 メガバイトならばスワップファイルは 256 メガバイトになります。 メモリの少ないシステムでは、 もっとスワップを増した方が性能がよくなります。 256 メガバイト未満のスワップでシステムを設計することはお薦めできません。 またスワップサイズを決める時に、 将来のメモリ増設のことも考えておくべきです。 カーネルの VM (訳註: virtual memory(仮想メモリ)) ページングアルゴリズムはスワップパーティションがメインメモリの 2 倍以上存在するときに最も性能を発揮するように設計されています。 スワップが少なすぎる設定は、 あなたが後にメモリを増設したときに問題を起すばかりではなく、 VM ページスキャニングのコードの能率を落します。 最後に、複数の SCSI ディスク (や異なるコントローラで操作される複数の IDE ディスク) を持つ大規模なシステムでは、それぞれのドライブ (4 台まで) にスワップを設定することを強く推奨します。 各ドライブのスワップパーティションはほぼ同一サイズであるべきです。 カーネルは任意のサイズを扱うことができますが、 内部のデータ構造は最大のスワップパーティションの 4 倍に調節されます。 スワップパーティションをほぼ同一のサイズにしておくことで カーネルはスワップスペースを最適なかたちで ディスクをまたいでストライブさせることができます。 こだわりすぎる必要はありません。 スワップスペースは UNIX のつつましい美点です。 あなたが通常スワップをたくさん使わないとしても、 プログラムが暴走してもリブートさせられる前に回復する時間を多く得られます。 何故パーティション化するのか? 何故パーティション化してしまうのでしょう? 何故巨大な root パーティション一発では駄目なのでしょう? そうすれば容量が溢れるかもと心配しなくてもすむのに! いくつかの理由からそれはよいアイデアとは言えません。 まず各パーティションはアクセスの特徴がそれぞれ異なっていて、 分離しておくことでそれぞれの特徴に応じたチューンができるようになるからです。 root パーティションや /usr パーティションはほとんどが読み出しでわずかな書き込みがあるだけですが /var や /var/tmp パーティションでは大量の読み書きが発生します。 システムを適切にパーティション化することで 小さいが書き込みの激しいパーティションによって引き起こされる フラグメント化を読み出し専門のパーティションにまで波及させずにすみます。 また書き込みの激しいパーティションをディスクの周辺部に配置することで、 たとえばパーティションテーブル内で大きなパーティションの後のかわりに前に配置することで、 それが最も必要とされているパーティションの I/O パフォーマンスを増大させることができます。 大きなパーティション内の I/O パフォーマンスもまた必要とされているでしょうが、 それらは大きすぎてディスク周辺部へ移動させてやったとしても /var を周辺部に移動させることによって大きな効果が得られたのとは対照的に 意味のあるパフォーマンスの増加は見込めないでしょう。 基本的にリードオンリーな root パーティションを小さくまとめておくことで 不幸なクラッシュを生き延びるチャンスが増大します。 中核となる設定 rc files rc.conf システムの設定情報が収められている主な場所は /etc/rc.conf です。 このファイルにはシステムの起動時にシステムの設定を行なうものをはじめ 多岐に渡る設定情報が含まれています。 そのファイル名はダイレクトに、それが rc* ファイル群の設定情報であることを示しています。 管理者は /etc/defaults/rc.conf のデフォルトの設定を rc.conf ファイルにエントリを作ることで上書きすべきです。 デフォルトのファイルをそのまま /etc にコピーするのはやめるべきです。 それはデフォルト値であってサンプルではないのです。 システム固有のすべての変更は rc.conf ファイルの中でするべきです。 管理の手間を減らす為、クラスター化されたアプリケーションには サイト共通の設定とシステム固有の設定を分離する様々な戦略が適用できます。 推奨されるアプローチは、サイト共通の設定は /etc/rc.conf.site のような別のファイルに置き、 それをシステム固有の設定情報しか含ませない /etc/rc.conf からインクルードすることです。 rc.conf は &man.sh.1; によって読み込まれているので、これはじつに簡単に達成できます。 たとえば、 rc.conf: . rc.conf.site hostname="node15.webcompany.com" network_interfaces="fxp0 lo0" ifconfig_fxp0="inet 10.1.1.1" rc.conf.site: defaultrouter="10.1.1.254" saver="daemon" blanktime="100" rc.conf.site ファイルは rsync 等を使うことで全システムに配布でき、 一方 rc.conf ファイルはユニークなままを保つことができます。 システムを &man.sysinstall.8; や 'make world' 等で 更新した場合 rc.conf ファイルは上書きされません。 なのでシステムの設定情報が失われることもありません。 アプリケーションの設定 基本的に、インストールされたアプリケーションは独自の文法を持つ 固有の設定ファイルを持ちます。 これらのファイルがベースシステムから分離されているということは重要で、 このためパッケージ管理ツールによる配置と管理が容易になっています。 /usr/local/etc 基本的に、それらのファイルは /usr/local/etc にインストールされます。 設定ファイルの数が多数にのぼるアプリケーションに対しては、 それら用にサブディレクトリが作られます。 通常、ports やパッケージがインストールされると 設定ファイルのサンプルが一緒にインストールされます。 大抵、識別のためにサフィックスとして ".default" がついています。 アプリケーションのための設定ファイルがまだ存在していなければ、 .defaults ファイルをコピーすることで作成できます。 以下は /usr/local/etc/apache の例です。 -rw-r--r-- 1 root wheel 2184 May 20 1998 access.conf -rw-r--r-- 1 root wheel 2184 May 20 1998 access.conf.default -rw-r--r-- 1 root wheel 9555 May 20 1998 httpd.conf -rw-r--r-- 1 root wheel 9555 May 20 1998 httpd.conf.default -rw-r--r-- 1 root wheel 12205 May 20 1998 magic -rw-r--r-- 1 root wheel 12205 May 20 1998 magic.default -rw-r--r-- 1 root wheel 2700 May 20 1998 mime.types -rw-r--r-- 1 root wheel 2700 May 20 1998 mime.types.default -rw-r--r-- 1 root wheel 7980 May 20 1998 srm.conf -rw-r--r-- 1 root wheel 7933 May 20 1998 srm.conf.default srm.conf ファイルだけが変更されていることが即座に見てとれるでしょう。 後に apache を更新した時にも、 この変更されたファイルは上書きされることはありません。 サービスの起動 サービス 一つのシステムでサービスをいくつも立ち上げているということは よくあることです。 それらには独自の立ち上げかたがあることがあり、 それぞれ有利な点があります。 /usr/local/etc/rc.d Ports collection やパッケージからインストールしたソフトウェアは しばしば /usr/local/etc/rc.d にスクリプトを置き、 システムが起動した時には 'start'、システムをシャットダウンする時には 'stop' の引数をつけてこれを実行します。 これは root によって実行されるべきであるようなシステムワイドな サービスを起動する場合に推奨される方法です。 これらのスクリプトはパッケージの一部としてインストール時に記録され、 パッケージとともに削除されます。 /usr/local/etc/rc.d にある 一般的なスクリプトは次のようなものです。 #!/bin/sh echo -n ' FooBar' case "$1" in start) /usr/local/bin/foobar ;; stop) kill -9 `cat /var/run/foobar.pid` ;; *) echo "Usage: `basename $0` {start|stop}" >&2 exit 64 ;; esac exit 0 このスクリプトはその目的を果すべく起動時に 、 シャットダウン時に をつけて呼ばれます。 サービスの中には固有のポートに接続を受けたときに &man.inetd.8; から起動されるものもあります。 これはメールリーダサーバ (POP や IMAP 等) の場合によくあります。 これらのサービスは /etc/inetd.conf ファイルを編集することで有効化されます。 このファイルの編集に関する詳細は &man.inetd.8; を見てください。 これらの他に /etc/rc.conf による有効化/無効化がカバーされていないサービスもあります。 それらは伝統的に /etc/rc.local にコマンドを書き込むことで実行されていました。 FreeBSD 3.1 にはデフォルトの /etc/rc.local は存在していません。 もし管理者によって作られていれば、 その時は一般的なやりかたとして認められるべきでしょう。 rc.local は最後の場所と考えられているということを 知っておいてください。 サービスを起動させるのにもっといい場所があるなら そこから始めてください。 /etc/rc.conf でその他のコマンドを実行しないでください。 そのかわり、デーモンの起動やブート時のコマンド実行は /usr/local/etc/rc.d にスクリプトを配置してください。 この他にサービスの起動に &man.cron.8; を利用することもできます。 このアプローチには、cron がそのプロセスを crontab のオーナ権限で実行したり、サービスが非特権ユーザによって 立ち上げられ管理されるなどといった有利な点がいくつもあります。 これで cron の文書化されていない機能の利点を得ることができます。 日時の指定を '@reboot' で置き換えることでジョブは システムがブートした直後、cron が起動した時に実行されます。 バーチャルホスト バーチャルホスト ip aliases FreeBSD の非常にありふれた用途の一つにバーチャルサイトの ホスティングがあります。 これは一つのサーバがネットワークには複数のサーバとして現れるものです。 これは一つのネットワークインタフェイスに 複数のアドレスを割当てることで実現されます。 ネットワークインタフェイスは "真の" アドレスを一つと "別名" のアドレスを複数持ちます。 これらの別名は通常 /etc/rc.conf に別名のエントリを置くことで追加されます。 'fxp0' インタフェイスへの別名のエントリは以下の様なものです。 ifconfig_fxp0_alias0="inet xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx" 別名のエントリは alias0 から始まり _alias1、_alias2 の様に増加してゆかなければなりません。 設定プロセスは 最初に欠けた番号のところで停まります。 別名のネットマスクの計算は重要ですが、幸いなことに非常に簡単です。 個々のインタフェイスについてそのネットワークのネットマスクを正しく 表現しているアドレスが必ず一つ必要です。 そのネットワークに所属しているそれ以外のアドレスのネットマスクは 全て 1 でなければなりません。 例として、fxp0 インタフェイスが二つのネットワークに接続されている ものを考えてみましょう。 一つはネットマスクが 255.255.255.0 である 10.1.1.0 ネットワークで、もう一つはネットマスクが 255.255.255.240 である 202.0.75.16 ネットワークです。 システムは 10.1.1.0 には 10.1.1.1 として、 202.0.75.20 には 202.0.75.17 として現れるようにします。 以下のエントリはネットワークインタフェイスを上述の環境に正しく 設定するものです。 ifconfig_fxp0="inet 10.1.1.1 netmask 255.255.255.0" ifconfig_fxp0_alias0="inet 10.1.1.2 netmask 255.255.255.255" ifconfig_fxp0_alias1="inet 10.1.1.3 netmask 255.255.255.255" ifconfig_fxp0_alias2="inet 10.1.1.4 netmask 255.255.255.255" ifconfig_fxp0_alias3="inet 10.1.1.5 netmask 255.255.255.255" ifconfig_fxp0_alias4="inet 202.0.75.17 netmask 255.255.255.240" ifconfig_fxp0_alias5="inet 202.0.75.18 netmask 255.255.255.255" ifconfig_fxp0_alias6="inet 202.0.75.19 netmask 255.255.255.255" ifconfig_fxp0_alias7="inet 202.0.75.20 netmask 255.255.255.255" 設定ファイル <filename>/etc</filename> のレイアウト 設定のための情報が含まれているディレクトリはたくさんあります。 それぞれ以下のものを含んでいます。 /etc システム全般の設定情報。 ここにあるデータはシステム 固有のものです。 /etc/defaults デフォルトのシステム設定ファイル。 /etc/mail 追加的な sendmail の設定、他の MTA の設定ファイル。 /etc/ppp ユーザモード、およびカーネルモードの ppp プログラムの設定。 /etc/namedb bind(8) のデータのデフォルトの置場。 通常 boot ファイルはここに置かれ、/var/db に置かれた他のデータを 参照するディレクティブを含みます。 /usr/local/etc インストールされたアプリケーションの設定ファイル。 アプリケーションごとのサブディレクトリを含んでいることがあります。 /usr/local/etc/rc.d インストールされたアプリケーションの起動/停止スクリプト。 /var/db 永続的なシステム固有のデータファイル。 たとえば bind(8) のゾーンファイル、データベースファイル等。 ホスト名 hostnames DNS /etc/resolv.conf resolv.conf /etc/resolv.conf は FreeBSD に インターネットドメインネームシステム (DNS) にどのようにアクセスするかを指定します。 resolv.conf の最もよくあるエントリは nameserver リゾルバが問い合わせるべきネームサーバの IP アドレス。 サーバはリストの順に 3 番目まで問い合わせられます。 search ホスト名をルックアップする検索リスト。 通常、ローカルなホスト名のドメインから決定されます。 domain ローカルドメイン名。 基本的な resolv.conf。 search foobar.com nameserver 147.11.1.11 +nameserver 147.11.100.30 &man.dhclient.8; は通常 resolv.conf を DHCP サーバから受け取った情報で書き換えます。 <filename>/etc/hosts</filename> hosts /etc/hosts は古きインターネットを 偲ばせるシンプルなテキストのデータベースです。 これはホスト名と IP アドレスをマッピングする DNS や NIS と組み合わせて使われます。 LAN でつながれているローカルな計算機は、 名前引きを簡単にするために &man.named.8; サーバを立ち上げるかわりにここに書くことができます。 さらに /etc/hosts はインターネット名のローカルなレコードを提供し、 よくアクセスされる名前を外部に問い合わせるのを減らすためにも使えます。 # $FreeBSD$ # # Host Database # This file should contain the addresses and aliases # for local hosts that share this file. # In the presence of the domain name service or NIS, this file may # not be consulted at all; see /etc/nsswitch.conf for the resolution order. # # ::1 localhost localhost.my.domain myname.my.domain 127.0.0.1 localhost localhost.my.domain myname.my.domain # # Imaginary network. #10.0.0.2 myname.my.domain myname #10.0.0.3 myfriend.my.domain myfriend # # According to RFC 1918, you can use the following IP networks for # private nets which will never be connected to the Internet: # # 10.0.0.0 - 10.255.255.255 # 172.16.0.0 - 172.31.255.255 # 192.168.0.0 - 192.168.255.255 # # In case you want to be able to connect to the Internet, you need # real official assigned numbers. PLEASE PLEASE PLEASE do not try # to invent your own network numbers but instead get one from your # network provider (if any) or from the Internet Registry (ftp to # rs.internic.net, directory `/templates'). # /etc/hosts は、 次のようなごく簡単なフォーマットになっています。 [インターネットアドレス] [正式なホスト名] [別名1] [別名2] ... 例: 10.0.0.1 myRealHostname.foobar.com myRealHostname foobar1 foobar2 これ以上の情報は &man.hosts.5; をあたってください。 ログファイルに関係する設定 log files <filename>syslog.conf</filename> syslog.conf syslog.conf は &man.syslogd.8; プログラムのための設定ファイルです。 これはどのタイプの syslog メッセージを対応する ログファイルに記録するかを指定します。 # $FreeBSD$ # # Spaces ARE valid field separators in this file. However, # other *nix-like systems still insist on using tabs as field # separators. If you are sharing this file between systems, you # may want to use only tabs as field separators here. # Consult the syslog.conf(5) manpage. *.err;kern.debug;auth.notice;mail.crit /dev/console *.notice;kern.debug;lpr.info;mail.crit;news.err /var/log/messages security.* /var/log/security mail.info /var/log/maillog lpr.info /var/log/lpd-errs cron.* /var/log/cron *.err root *.notice;news.err root *.alert root *.emerg * # uncomment this to log all writes to /dev/console to /var/log/console.log #console.info /var/log/console.log # uncomment this to enable logging of all log messages to /var/log/all.log #*.* /var/log/all.log # uncomment this to enable logging to a remote loghost named loghost #*.* @loghost # uncomment these if you're running inn # news.crit /var/log/news/news.crit # news.err /var/log/news/news.err # news.notice /var/log/news/news.notice !startslip *.* /var/log/slip.log !ppp *.* /var/log/ppp.log これ以上の情報は &man.syslog.conf.5; のマニュアルページに あたってください。 <filename>newsyslog.conf</filename> newsyslog.conf newsyslog.conf は &man.newsyslog.8; のための設定ファイルで、 通常 &man.cron.8; によって実行されるプログラム &man.newsyslog.8; がログファイルをいつ保存して再編するかを決定します。 logfile は logfile.1 に移され、logfile.1 は logfile.2 に、そして以下同様に移されます。 さらにログファイルを gzip 形式で保存することもできます。 この場合ファイル名は logfile.0.gz、logfile.1.gz の様になります。 newsyslog.conf はどのログファイルが管理され、どのくらいの期間保存され、 そしていつ touch されるかを指定します。 ログファイルはあるサイズに到達するか、ある決められた時刻・ 日時で再編されあるいは保存されます。 # configuration file for newsyslog # $FreeBSD$ # # logfilename [owner:group] mode count size when [ZB] [/pid_file] [sig_num] /var/log/cron 600 3 100 * Z /var/log/amd.log 644 7 100 * Z /var/log/kerberos.log 644 7 100 * Z /var/log/lpd-errs 644 7 100 * Z /var/log/maillog 644 7 * @T00 Z /var/log/sendmail.st 644 10 * 168 B /var/log/messages 644 5 100 * Z /var/log/all.log 600 7 * @T00 Z /var/log/slip.log 600 3 100 * Z /var/log/ppp.log 600 3 100 * Z /var/log/security 600 10 100 * Z /var/log/wtmp 644 3 * @01T05 B /var/log/daily.log 640 7 * @T00 Z /var/log/weekly.log 640 5 1 $W6D0 Z /var/log/monthly.log 640 12 * $M1D0 Z /var/log/console.log 640 5 100 * Z これ以上の情報は &man.newsyslog.8; のマニュアルページに あたってください。 <filename>sysctl.conf</filename> sysctl.conf sysctl sysctl.conf は rc.conf によく似ています。 値は変数=値のかたちでセットされます。 指定された値はシステムがマルチユーザモードに移行した後でセットされます。 すべての変数がこのモードで設定可能というわけではありません。 以下は sysctl.conf のサンプルで 致命的なシグナルを記録しないように、また Linux プログラムに それらが実際は FreeBSD 上で動いていることを知らせる様に チューニングしています。 kern.logsigexit=0 # Do not log fatal signal exits (e.g. sig 11) compat.linux.osname=FreeBSD compat.linux.osrelease=4.3-STABLE sysctl によるチューニング sysctl sysctl によるチューニング &man.sysctl.8; は稼働中の FreeBSD システムに変更を加えるためのインタフェイスです。 これには経験を積んだ管理者用の TCP/IP スタックへや 仮想メモリシステムのパフォーマンスを劇的に改善する 先進的なオプションが含まれます。 500 を越えるシステム変数を &man.sysctl.8; で読んだり - セットしたりできます + セットしたりできます。 中心において &man.sysctl.8; の機能は以下の二つに尽きます。 すなわちシステムの設定を読んで変更することです。 読むことができるすべての変数を表示するには以下のようにします。 &prompt.user; sysctl -a 個々の変数、たとえば kern.maxproc を読むには以下のようにします。 &prompt.user; sysctl kern.maxproc kern.maxproc: 1044 個々の変数をセットするには = オプションを使います。 &prompt.root; sysctl kern.maxfiles=5000 kern.maxfiles: 2088 -> 5000 sysctl 変数の値は通常、文字列、数値、真偽値のいずれかです。 真偽値は yes の場合には 1 で no の場合には 0 です。 ディスクのチューニング sysctl 変数 vfs.vmiodirenable vfs.vmiodirenable vfs.vmiodirenable sysctl はデフォルトは 0 (オフ) であり (しかし近いうちにデフォルトが 1 になるでしょう)、0 (オフ) または 1 (オン) にセットすることができます。 このパラメータはディレクトリがシステムによってどのように キャッシュされるかを制御します。 ほとんどのディレクトリは小さく、 ファイルシステムにおいては単一フラグメント (典型的には 1K) であり、バッファキャッシュではさらに小さくなっています (典型的には 512 バイト)。 しかしデフォルトモードで動作している時は、 大量のメモリを搭載していても バッファキャッシュは固定数のディレクトリしかキャッシュしません。 この sysctl をオンにすると、バッファキャッシュが VM ページキャッシュを、 ディレクトリをキャッシュするために使うことを可能にします。 これによる利点は、全てのメモリがディレクトリを キャッシュするのに使えるようになるということです。 欠点は、キャッシュに使われる最小のメモリの大きさが 512 バイトではなく 物理ページサイズ (大抵は 4K) になることです。 多数のファイルを操作するサービスを稼動しているなら、 常にこのオプションをオンにすることを推奨します。 そのようなサービスには、web キャッシュや大規模なメールシステム、 ニューズシステムなどが含まれます。 このオプションは一般にメモリを消費しますが、 性能を削減することはありません。 ただし実験して調べてみるべきでしょう。 hw.ata.wc hw.ata.wc FreeBSD 4.3 では IDE のライトキャッシュがオフになりました。 これは IDE ディスクへの書き込み帯域幅を減らしてしまうことになりますが、 ハードドライブベンダに起因するデータの一貫性に関する 重大な問題のために必要なことだと考えられました。 基本的には、書き込み完了時期について IDE ドライブが嘘をつくという問題です。 IDE ライトキャッシュがオンであると IDE ハードドライブはデータを順番に書きこまないばかりか、 ディスクの負荷が高い時にはいくつかのブロックの書き込みを 無期限に延期してしまいます。 クラッシュや電源故障の場合、 ファイルシステムの重大な破壊をもたらします。 したがって私たちはデフォルトを安全側に変更しました。 残念ながらこれは大変な性能の低下をもたらし、 私たちはあきらめてこのリリース後にオンに戻しました。 hw.ata.wc sysctl 変数を見てデフォルトをチェックしてみるべきです。 もし IDE ライトキャッシュがオフになっていたら、 hw.ata.wc カーネル変数を 1 に戻すことでオンに戻すことができます。 これはブート時にブートローダから行わなければなりません。 カーネルがブートした後に行っても効果はありません。 &man.ata.4; を見てください。 ソフトアップデート ソフトアップデート tunefs &man.tunefs.8; はファイルシステムを fine チューンするのに使えます。 この目的においてはソフトアップデートをオンオフすることを 考えるだけですみます。 以下の様にしてトグルします。 &prompt.root; tunefs -n enable /filesystem &prompt.root; tunefs -n disable /filesystem ファイルシステムはマウントされているあいだは &man.tunefs.8; で変更することができません。 ソフトアップデートを有効にする いい機会はシングルユーザモードでどのパーティションもマウント されていない時です。 softupdates はメタデータの性能、 主にファイルの作成と削除の性能を劇的に改善します。 全てのファイルシステムで softupdates を有効にすることを推奨します。 softupdates に関して、2 つの欠点を意識すべきです。 1 つめは、softupdates はクラッシュ時におけるファイルシステムの一貫性は保証しますが、 物理ディスクの更新が何秒か (1 分になることもあります!) 遅れる可能性が高いことです。 クラッシュした場合、より多くの成果が消えてしまうかもしれません。 2 つめは、softupdates はファイルシステムブロックを解放するのを遅らせるということです。 あるファイルシステム (例えばルートファイルシステム) が満杯近くの時に それに対する大規模な更新、たとえば make installworld をすると、空き領域を使い果たして更新が失敗してしまうことがあります。 kernel の制限をチューニングする kernel の制限をチューニングする File/process 制限 kern.maxfiles kern.maxfiles kern.maxfiles はあなたのシステムの要求に 応じて増減させることができます。 この変数はあなたのシステムのファイル記述子の最大値を示します。 ファイル記述子テーブルが溢れるような時には dmesg に頻繁に file: table is full と表示されます。 ファイル、ソケット、パイプ(fifo) は それぞれオープンされるとファイル記述子を一つ消費します。 大規模なプロダクションサーバでは その時実行されているサービスの種類や数に応じては あっさり数千のファイル記述子が必要になります。 kern.maxfile のデフォルト値は kernel config ファイルの maxusers オプションで決ります。 kern.maxfiles は maxusers の値に応じて増加します。 diff --git a/ja_JP.eucJP/books/handbook/disks/chapter.sgml b/ja_JP.eucJP/books/handbook/disks/chapter.sgml index 545c75c824..f98c004349 100644 --- a/ja_JP.eucJP/books/handbook/disks/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/disks/chapter.sgml @@ -1,3304 +1,3304 @@ ストレージ この章では この章では、FreeBSD におけるディスクの使用方法を説明します。 これにはメモリディスク、ネットワークに接続されたディスク、 および標準的な SCSI/IDE 記憶デバイスが含まれます。 この章では、以下の分野について説明します。 物理ディスク上のデータ構成 について記述するために FreeBSD が使用する用語 (パーティションおよびスライス) システムにハードディスクを追加する方法 メモリディスクのような仮想ファイルシステムを設定する方法 使用できるディスク容量を制限するためにクォータを設定する方法 攻撃者から保護するためにディスクを暗号化する方法 FreeBSD で CD や DVD を作成する方法 バックアップのためのさまざまな記憶メディアオプション FreeBSD で利用できるバックアッププログラムの使用方法 フロッピーディスクにバックアップする方法 スナップショットとは何か、そしてそれを効果的に使用する方法 デバイス名 以下は、FreeBSD で対応している物理記憶デバイスとそれに対応するデバイス名のリストです。 物理ディスクへの名前付け ドライブの種類 ドライブのデバイス名 IDE ハードドライブ ad IDE CD-ROM ドライブ acd SCSI ハードドライブおよび USB 大容量記憶デバイス da SCSI CD-ROM ドライブ cd その他の非標準的 CD-ROM ドライブ ミツミ CD-ROM は mcd, Sony CD-ROM は scd, 松下/パナソニック CD-ROM は matcd &man.matcd.4; ドライバは 2002 年 10 月 5 日に FreeBSD 4.X ブランチから削除されました。 また、FreeBSD 5.0 および 5.1 リリースには存在しませんが、 2003 年 6 月 16 日に FreeBSD 5.X ブランチに復帰しました。 フロッピードライブ fd SCSI テープドライブ sa IDE テープドライブ ast フラッシュドライブ &diskonchip; フラッシュデバイスは fla RAID ドライブ &adaptec; AdvancedRAID は aacd, &mylex; は mlxd および mlyd, AMI &megaraid; は amrd, Compaq Smart RAID は idad, &tm.3ware; RAID はtwed
David O'Brien 原作: ディスクの追加 ディスク 追加 現在一つしかドライブがない計算機に新しく SCSI ディスクを追加したいとしましょう。まずコンピュータの電源を切り、 コンピュータやコントローラ、 ドライブの製造元の説明書に従ってドライブを取り付けます。 このあたりの手順は非常に多岐にわたるため、 詳細はこの文書の範囲外です。 root ユーザでログインします。 ドライブの取り付け後は /var/run/dmesg.boot を調べて新しいディスクが見つかっていることを確認しておきます。 この例では、新しく付けたドライブは da1 で、 我々はそれを /1 にマウントしたいとしましょう (もし IDE ドライブを付けようとしているのなら、デバイス名は 4.0 以前のシステムでは wd1, ほとんどの 4.x システムでは ad1 になるでしょう)。 パーティション スライス fdisk FreeBSD は IBM-PC 互換のコンピュータで動くため、 PC BIOS のパーティションを考慮に入れる必要があります。 これは従来の BSD パーティションとは異なります。PC ディスクは 4 つまでの BIOS パーティションエントリを持つことができます。 もしそのディスクを本当に FreeBSD 専用にしたい場合には 専用 モードで用いることもできます。 そうでない場合には、FreeBSD は PC BIOS パーティションのどれか一つの中に入れることになります。 FreeBSD では、従来の BSD パーティションと混乱しないように PC BIOS パーティションのことをスライスと呼びます。 また、別の OS がインストールされていたコンピュータで使われていたが FreeBSD 専用にするディスク上でもスライスを用いることができます。 これは、他の OS の fdisk ユーティリティを混乱させないためです。 スライスの場合、ドライブは /dev/da1s1e として加えられるでしょう。これは、SCSI ディスクでユニット番号は 1 (二つめの SCSI ディスク), スライスは 1 (PC BIOS のパーティションが 1) で BSD パーティション e, と読みます。 専用ディスクの場合だと単純に /dev/da1e として加えられるでしょう。 &man.sysinstall.8; の利用 sysinstall ディスクの追加 su <application>sysinstall</application> の操作 sysinstall の使い易いメニューを利用して、 新しいディスクのパーティション分けやラベル付けを行なうことができます。 root ユーザでログインするか su コマンドを用いるかして root 権限を取得します。 /stand/sysinstall を実行して Configure メニューに入ります。FreeBSD Configuration Menu の中でスクロールダウンして Fdisk の項目を選びます。 <application>fdisk</application> パーティションエディタ fdisk では、ディスク全体を FreeBSD で使うために A を入力します。 remain cooperative with any future possible operating systems と聞かれたら YES と答えます。 W で変更をディスクに書き込みます。ここで q と入力して FDISK エディタを抜けます。 次にマスタブートレコードについて聞かれます。 ここでは既に動いているシステムにディスクを追加しようとしているので None を選びます。 ディスクラベルエディタ BSD パーティション 次に sysinstall を終了し、 もう一度起動する必要があります。同じ手順を踏んで今度は Label オプションを選択し、 Disk Label Editor に入ります。 ここでは従来の BSD パーティションを作成します。 一つのディスクは a から h までのラベルがついた最大 8 つのパーティションを持つことができます。 いくつかのパーティションラベルは特別な用途に用いられます。 a パーティションはルートパーティション (/) です。したがって、システムディスク (つまり起動ディスク) のみに a パーティションがあるべきです。b パーティションはスワップパーティションに用いられ、 複数のディスクにスワップパーティションを作ることができます。 c は専用モードにおけるディスク全体、 もしくはスライスモードにおけるスライス全体を指します。 他のパーティションは汎用的に用いられます。 sysinstall のラベルエディタ は、ルートパーティションでもスワップパーティションでもないパーティションには、e パーティションを採用しようとします。ラベルエディタでファイルシステムを作成するには C を入力してください。 FS (ファイルシステム) かスワップかを聞かれたら FS を選びマウントポイント (たとえば /mnt) を入力します。 インストール後のモードでディスクを追加する場合、 sysinstall は /etc/fstab にエントリを追加しないため、 ここで指定するマウントポイントはそれほど重要ではありません。 さて、ディスクに新しいラベルを書き込み、 そこにファイルシステムを作る準備が整いました。早速 W を叩いて実行しましょう。 sysinstall からの、 新しいパーティションをマウントできない、 というエラーは無視してください。Label Editor から抜け、 sysinstall を終了します。 終了 最後に /etc/fstab を編集し、 新しいディスクのエントリを追加します。 コマンドラインユーティリティの利用 スライスの利用 このセットアップ方法では、 すでにコンピュータに他のオペレーティングシステムがインストールされていても 正しく協調動作することが可能で、他のオペレーティングシステムの fdisk ユーティリティを混乱させることもありません。 新しいディスクにインストールする場合は、 この方法を用いることが推奨されています。 後述する 専用モード は、 そうしなければならない理由がある時にのみ、 利用するようにしてください。 &prompt.root; dd if=/dev/zero of=/dev/da1 bs=1k count=1 &prompt.root; fdisk -BI da1 # 新しいディスクの初期化 &prompt.root; disklabel -B -w -r da1s1 auto # ディスクにラベルを付ける &prompt.root; disklabel -e da1s1 # 作成したディスクラベルを編集し、パーティションを追加する &prompt.root; mkdir -p /1 &prompt.root; newfs /dev/da1s1e # 作成したすべてのパーティションに対してこれを繰り返す &prompt.root; mount /dev/da1s1e /1 # パーティションをマウントする &prompt.root; vi /etc/fstab # /etc/fstab に適切なエントリを追加する IDE ディスクを使う場合は da の部分を ad とします。4.X より前のシステムでは、 (訳注: ad ではなく) wd としてください。 専用モード OS/2 新しいドライブを他の OS と共有しない場合には 専用 モードを用いることもできます。 このモードはマイクロソフトの OS を混乱させることを憶えておいてください (しかし、それらによって壊されることはありません)。 一方、IBM の &os2; はどんなパーティションでも見つけたら理解できなくても 専有 します。 &prompt.root; dd if=/dev/zero of=/dev/da1 bs=1k count=1 &prompt.root; disklabel -Brw da1 auto &prompt.root; disklabel -e da1 # `e' パーティションの作成 &prompt.root; newfs -d0 /dev/da1e &prompt.root; mkdir -p /1 &prompt.root; vi /etc/fstab # /dev/da1e エントリの追加 &prompt.root; mount /1 もう一つの方法は次の通り。 &prompt.root; dd if=/dev/zero of=/dev/da1 count=2 &prompt.root; disklabel /dev/da1 | disklabel -BrR da1 /dev/stdin &prompt.root; newfs /dev/da1e &prompt.root; mkdir -p /1 &prompt.root; vi /etc/fstab # /dev/da1e エントリの追加 &prompt.root; mount /1 &os; 5.1-RELEASE から、従来の &man.disklabel.8; プログラムは &man.bsdlabel.8; ユーティリティに置き換えられました。&man.bsdlabel.8; では、 使用されていない数多くのオプションやパラメタが削除されました。 たとえば オプションは &man.bsdlabel.8; では取り除かれました。詳細については &man.bsdlabel.8; のマニュアルページを参照してください。 RAID ソフトウェア RAID Christopher Shumway 原作: Jim Brown 改訂: RAID ソフトウェア RAID CCD Concatenated Disk Driver (CCD) の設定 大容量記録に関する解決法を選択する際にもっとも重視すべき要素は、 速度、信頼性、そして費用です。 三つを同時にバランスよく実現することは稀です。 通常、速くて信頼性のある大容量記録装置は高価であり、 費用を抑えようとすると速度または信頼性のどちらかが犠牲になります。 ここで例にあげるシステムの設計においては、 費用が最も重要な要素として、次に速度、最後に信頼性が選択されています。 このシステムでのデータ転送速度は結局のところネットワークによって制限されます。 信頼性は大変重要です。ただし、以下で説明する CCD ドライブは、 データ自体はすでに CD-R に完全にバックアップしてあるもの (したがって交換は簡単にできます) の、オンラインデータの役割をさせています。 あなた自身の要求事項を決定することは、 大容量記録に関する解決法を選択することの最初の段階です。 もしあなたの要求事項が費用より速度または信頼性を優先するなら、 解決法はこのシステムとは違うものになるでしょう。 ハードウェアのインストール IDE システムディスクに加えて、Western Digital 製の 30GB, 5400RPM の IDE ディスク三台を使って、 以下に説明されているような約 90GB のオンラインストレージとなる CCD ディスクを作成しました。各 IDE ディスクがそれぞれの IDE コントローラとケーブルをもっていることが理想的ですが、 費用を最低限にするために、 IDE コントローラを追加していません。その代わり、それぞれの IDE コントローラがマスタデバイスを一つ、 スレーブデバイスを一つ持つように、 ディスクはジャンパを使って設定されています。 再起動の際に、システム BIOS が接続されたディスクを自動的に検出するように設定されました。 より重要なことは、FreeBSD が再起動の際にそれらを検出することです。 ad0: 19574MB <WDC WD205BA> [39770/16/63] at ata0-master UDMA33 ad1: 29333MB <WDC WD307AA> [59598/16/63] at ata0-slave UDMA33 ad2: 29333MB <WDC WD307AA> [59598/16/63] at ata1-master UDMA33 ad3: 29333MB <WDC WD307AA> [59598/16/63] at ata1-slave UDMA33 FreeBSD がディスクをすべて検出しないときは、 ジャンパを正しく設定してあるか確認してください。多くの IDE ドライブは ケーブルセレクト ジャンパを持っています。 これはマスタ/スレーブの関係を設定するジャンパでは ありません。ドライブの文書を参照して、 正しいジャンパ設定を見つけてください。 次に、ファイルシステムの一部分として、 それらをどのように接続するのかを考慮します。&man.vinum.8; および &man.ccd.4; の両方を検討すべきでしょう。この設定では、&man.ccd.4; を選択しました。 CCD の設定 &man.ccd.4; ドライバは、いくつかの同じディスクを使って、 一つの論理的ファイルシステムに連結することができます。 &man.ccd.4; を使用するためには、カーネルが &man.ccd.4; に対応している必要があります。 次の行をカーネルコンフィギュレーションファイルに追加して、 カーネルを再構築し、再インストールしてください。 pseudo-device ccd 4 5.X システムでは、 上記の代わりに次の行を追加しなければなりません。 device ccd FreeBSD 5.X では &man.ccd.4; デバイスの数を指定する必要はありません。&man.ccd.4; デバイスドライバは自己複製するようになりました — 新しいデバイスインスタンスは、 必要に応じてその都度自動的に作成されます。 FreeBSD 3.0 以降では、 カーネルモジュールを読み込んで &man.ccd.4; に対応することもできます。 &man.ccd.4; を設定するために、まず &man.disklabel.8; を使用してディスクにラベルを書き込まなくてはなりません。 disklabel -r -w ad1 auto disklabel -r -w ad2 auto disklabel -r -w ad3 auto このコマンドはディスク全体を示す ad1c, ad2c および ad3c に対するディスクラベルを作成します。 &os; 5.1-RELEASE から、従来の &man.disklabel.8; プログラムは &man.bsdlabel.8; ユーティリティに置き換えられました。&man.bsdlabel.8; では、 使用されていない数多くのオプションやパラメタが削除されました。 たとえば オプションは &man.bsdlabel.8; では取り除かれました。詳細については &man.bsdlabel.8; のマニュアルページを参照してください。 次に、ディスクラベルのタイプを変更します。 &man.disklabel.8; を使用してディスクラベルを編集してください。 disklabel -e ad1 disklabel -e ad2 disklabel -e ad3 このコマンドは EDITOR 環境変数に設定されているエディタ (一般的には &man.vi.1;) でそれぞれのディスクの現在のディスクラベルを開きます。 変更されていないディスクラベルは以下のようになります。 8 partitions: # size offset fstype [fsize bsize bps/cpg] c: 60074784 0 unused 0 0 0 # (Cyl. 0 - 59597) &man.ccd.4; で使用する e パーティションを作成します。通常では c パーティションの行をコピーすれば良いでしょう。しかし、 は 4.2BSD でなければ なりません。 ディスクラベルは以下のようになるでしょう。 8 partitions: # size offset fstype [fsize bsize bps/cpg] c: 60074784 0 unused 0 0 0 # (Cyl. 0 - 59597) e: 60074784 0 4.2BSD 0 0 0 # (Cyl. 0 - 59597) ファイルシステムの構築 ccd0c デバイスノードはまだ存在していないかも知れません。 そのときは、次のコマンドを実行して作成してください。 cd /dev sh MAKEDEV ccd0 FreeBSD 5.0 では &man.devfs.5; が /dev 以下のデバイスノードを自動的に管理するので、 MAKEDEVを使用する必要はありません。 すべてのディスクにラベルを書き込んだので、 &man.ccd.4; を構築してください。 これを行うためには、以下のようなオプションで &man.ccdconfig.8; を使います。 ccdconfig ccd0 32 0 /dev/ad1e /dev/ad2e /dev/ad3e 各オプションの使用法と意味は以下の通りです。 一番目の引数は設定するデバイスです。この例の場合は /dev/ccd0c です。 /dev/ の部分はオプションです。 ファイルシステムに対するインタリーブです。インタリーブは、 ディスクブロック内のストライプサイズを定義します。 ディスクブロックは通常 512 バイトです。したがって 32 インタリーブは 16,384 バイトとなります。 これは &man.ccdconfig.8; に対するフラグです。 ドライブミラーリングを有効にしたい場合、 ここにフラグを指定します。 この設定では &man.ccd.4; に対するミラーリングは提供しませんので、 0 (ゼロ) を指定しています。 この &man.ccdconfig.8; に対する最後の引数は、 アレイ内に置くデバイスです。 それぞれのデバイスに対する完全なパス名を使用します。 &man.ccdconfig.8; を実行すると &man.ccd.4; が設定されます。 これでファイルシステムをインストールすることが可能です。 オプションについて &man.newfs.8; を参照するか、 次のように実行してください。 newfs /dev/ccd0c 自動的に設定する 一般的に、再起動するたびに &man.ccd.4; をマウントしたいと思うでしょう。これを行うために、 まず設定をしなければなりません。次のコマンドを用いて、 現在の設定を /etc/ccd.conf に書き出します。 ccdconfig -g > /etc/ccd.conf /etc/ccd.conf が存在すると、 再起動の際に /etc/rc スクリプトが ccdconfig -C を実行します。これにより、 &man.ccd.4; は自動的に設定された後、マウントされます。 シングルユーザモードで起動している場合には、 &man.ccd.4; を &man.mount.8; する前に、 アレイを設定するために次のコマンドを実行する必要があります。 ccdconfig -C 自動的に &man.ccd.4; をマウントするには、 /etc/fstab に &man.ccd.4; のエントリ追加します。このように設定すると起動時にマウントされます。 /dev/ccd0c /media ufs rw 2 2 Vinum ボリュームマネージャ RAID ソフトウェア RAID Vinum Vinum ボリュームマネージャは、 仮想ディスクドライブを実装したブロックデバイスドライバです。 Vinum は、ディスクハードウェアをブロックデバイスインタフェースから 分離し、データを配置します。 その結果、ディスク記憶装置を従来のスライスで扱うのと比較して、 柔軟性、性能および信頼性が向上しています。 &man.vinum.8; は RAID-0, RAID-1 および RAID-5 モデル、 そしてそれぞれの組合せを実装しています。 &man.vinum.8; の詳細については Vinum ボリュームマネジャ を参照してください。 ハードウェア RAID RAID ハードウェア FreeBSD は、さまざまなハードウェア RAID コントローラにも対応しています。これらのデバイスはアレイを制御するための 特別なソフトウェアを FreeBSD で必要することなく、 RAID サブシステムを制御します。 カード上の BIOS を使用して、 カードはそれ自身でディスク操作のほとんどを制御します。以下は Promise IDE RAID コントローラを使用した設定の簡単な説明です。 このカードがインストールされ、システムが起動したときには、 情報の入力を促すプロンプトを表示します。 指示にしたがってカードの設定画面に進んでください。 接続されたドライブを組み合わせるように設定することができます。 設定後、ディスクは FreeBSD に対して単一のドライブのように見えます。 他の RAID レベルは適宜設定できます。 ATA RAID1 アレイの再構築 FreeBSD はアレイ内の障害ディスクを動作中に交換できます。 ただし、再起動前にそれを検知していることが必要です。 /var/log/messages または &man.dmesg.8; の出力に次のような行があるでしょう。 ad6 on monster1 suffered a hard error. ad6: READ command timeout tag=0 serv=0 - resetting ad6: trying fallback to PIO mode ata3: resetting devices .. done ad6: hard error reading fsbn 1116119 of 0-7 (ad6 bn 1116119; cn 1107 tn 4 sn 11) status=59 error=40 ar0: WARNING - mirror lost &man.atacontrol.8; を使用して詳細を調べてください。 &prompt.root; atacontrol list ATA channel 0: Master: no device present Slave: acd0 <HL-DT-ST CD-ROM GCR-8520B/1.00> ATA/ATAPI rev 0 ATA channel 1: Master: no device present Slave: no device present ATA channel 2: Master: ad4 <MAXTOR 6L080J4/A93.0500> ATA/ATAPI rev 5 Slave: no device present ATA channel 3: Master: ad6 <MAXTOR 6L080J4/A93.0500> ATA/ATAPI rev 5 Slave: no device present &prompt.root; atacontrol status ar0 ar0: ATA RAID1 subdisks: ad4 ad6 status: DEGRADED ディスクを安全に取り外すために、 まずアレイから切り離します。 &prompt.root; atacontrol detach 3 ディスクを取り外します。 スペアのディスクを取り付けます。 &prompt.root; atacontrol attach 3 Master: ad6 <MAXTOR 6L080J4/A93.0500> ATA/ATAPI rev 5 Slave: no device present アレイを再構築します。 &prompt.root; atacontrol rebuild ar0 再構築コマンドは完了するまで他の操作を受け付けません。しかし、 もう一つ別のターミナルを (Alt Fn を押して) 開き、 次のコマンドを実行すると進行状態を確認することができます。 &prompt.root; dmesg | tail -10 [output removed] ad6: removed from configuration ad6: deleted from ar0 disk1 ad6: inserted into ar0 disk1 as spare &prompt.root; atacontrol status ar0 ar0: ATA RAID1 subdisks: ad4 ad6 status: REBUILDING 0% completed 操作が完了するまでお待ちください。 Mike Meyer 寄稿: 光メディア (CD & DVD) の作成と使用 CDROM 作成 はじめに CD は他の一般的なディスクと異なる様々な特徴を持っています。 そもそもユーザが書き込むことができません。 また遅延なしで連続的に読み出せるように、 トラック間をヘッドが移動しないですむようにデザインされています。 さらにこのサイズのメディアの中ではシステムをまたぐデータの 移動が比較的簡単でもあります。 CD はトラックの概念を持っていますが、 これはデータを連続的に読み出すためのものであってディスクの物理特性ではありません。 FreeBSD で CD を作成するには、まず CD のトラックとなるデータファイルを用意し、 そのトラックを CD に書き込みます。 ISO 9660 ファイルシステム ISO 9660 ISO 9660 ファイルシステムはこの様な差異を扱うべく設計されました。 その結果、ファイルシステムは一般的に使用するのに差しつかえない程度に 制限されて標準化されています。幸いなことに、ISO 9660 ファイルシステムには拡張機構が提供されています。適切に書かれた CD は、 拡張機構に対応したシステムでは拡張を利用して、そうでないシステムでは 拡張機構を使用しない範囲で動作するようになっています。 sysutils/mkisofs sysutils/mkisofs プログラムは ISO 9660 ファイルシステムを含むデータファイルを作成するのに使われます。 これには様々な拡張をサポートするオプションがあり、 以下で説明します。 このソフトウェアは、ports の sysutils/mkisofs からインストールすることができます。 CD ライタ ATAPI CD に書き込むためのツールは、お使いの CD ライタが ATAPI 接続か否かにも依存します。ATAPI CD ライタなら、ベースシステムの一部である burncd プログラムを使います。SCSI や USB の CD ライタなら、ports の sysutils/cdrecord をインストールして cdrecord プログラムを使うべきでしょう。 burncd が対応しているドライブは限定されています。 ドライブが対応されているかどうかを確認するには、 CD-R/RW supported drives にある一覧を見てください。 CD ライタ ATAPI/CAM ドライバ &os; 5.X または &os; 4.8-RELEASE 以降のバージョンを使用している場合、 ATAPI/CAM モジュール を使用すると ATAPI ハードウェア上で SCSI ドライブ用の cdrecord および他のツールを使用できるようになります。 mkisofs sysutils/mkisofs は &unix; ファイルシステムの名前空間におけるディレクトリツリーのイメージとして ISO 9660 ファイルシステムを作成します。 最も簡単な使い方は以下の通りです。 &prompt.root; mkisofs -o imagefile.iso /path/to/tree ファイルシステム ISO 9660 このコマンドは /path/to/tree 以下のディレクトリツリーのコピーである ISO 9660 ファイルシステムを含んだ imagefile.iso ファイルを作成します。この過程において、ファイル名は標準的な ISO 9660 ファイルシステムの制限に適合するようなファイル名に対応づけられ、 ISO ファイルシステムでファイル名を文字化できないファイルは除外されます。 ファイルシステム HFS ファイルシステム Joliet この制限を回避するために利用できるオプションはいくつもあります。 特に オプションは &unix; システムで標準的な Rock Ridge 拡張を有効にします。 オプションは Microsoft のシステムで標準的な Joliet 拡張を有効にし、 オプションは &macos; で使用されている HFS ファイルシステムを作成するために使われます。 FreeBSD でしか使わないのであれば、 オプションを使用するとあらゆるファイル名制限を無効にできます。 さらに オプションとともに使うことで FreeBSD と同一のファイルシステムイメージを作成できますが、 これは ISO 9660 標準の多くを無視しています。 CDROM ブータブル (起動可能な) CDROM の作成 一般的に使われる最後のオプションは オプションです。 これは El Torito ブータブル CD を作成するのに使う起動イメージのありかを指定します。 このオプションは引数として起動イメージへのパスを、 CD に書き込まれるディレクトリツリーの頂点からの相対位置で取ります。 したがって /tmp/myboot がブート可能な FreeBSD システムで /tmp/myboot/boot/cdboot にブートイメージがあるならば、以下のようにすることで ISO 9660 ファイルシステムのイメージを /tmp/bootable.iso に作成することができます。 &prompt.root; mkisofs -U -R -b boot/cdboot -o /tmp/bootable.iso /tmp/myboot この後、カーネルで vn (FreeBSD 4.X) または md (FreeBSD 5.X) が設定されていれば、 ファイルシステムを以下のようにしてマウントすることができます。 &prompt.root; vnconfig -e vn0c /tmp/bootable.iso &prompt.root; mount -t cd9660 /dev/vn0c /mnt FreeBSD 4.X および FreeBSD 5.X に対しては以下の通りです。 &prompt.root; mdconfig -a -t vnode -f /tmp/bootable.iso -u 0 &prompt.root; mount -t cd9660 /dev/md0 /mnt /mnt と /tmp/myboot が同一かどうか確認してください。 sysutils/mkisofs には挙動を細かく制御するために他にもたくさんのオプションがあります。 特に、ISO 9660 レイアウトの変更や Joliet および HFS ディスク作成などの 詳細は &man.mkisofs.8; のマニュアルページをご覧ください。 burncd CDROM 書き込み あなたが持っているのが ATAPI CD ライタなら、CD に ISO イメージを書き込むために burncd コマンドが使えます。 burncd はベースシステムの一部で /usr/sbin/burncd としてインストールされています。 使い方はとても単純でオプションも少ししかありません。 &prompt.root; burncd -f cddevice data imagefile.iso fixate 以上のコマンドは imagefile.iso のコピーを cddevice に書き込みます。 デフォルトのデバイスは /dev/acd0c です。 書き込み速度や操作完了後に CD を自動的に取り出す方法、 オーディオデータの書き込みなどのオプションについては &man.burncd.8; を見てください。 cdrecord あなたが持っている CD ライタが ATAPI ではなければ、 CD を書き込むのに cdrecord を使う必要があります。 cdrecord はベースシステムの一部ではなく、 sysutils/cdrtools の port または 適切な package を利用してインストールしなければなりません。 なお、ベースシステムを変更するとバイナリに矛盾が発生し、 コースター を作ってしまうおそれがあります。 したがって、システムをアップグレードする度にこの port も作り直すか、 あるいはFreeBSD の安定版を追いかけているのならば、 新しいバージョンが利用できるようになった時に ports をアップグレードする必要があります。 cdrecord にはたくさんのオプションがありますが、 基本的な使い方は burncd よりもさらに簡単です。 ISO 9660 イメージを書き込むには以下のようにします。 &prompt.root; cdrecord dev=device imagefile.iso cdrecord のトリッキーな部分は、使用する を見つけるところにあります。 適切な設定を見つけるためには cdrecord の フラグを使います。 たとえば、以下のような結果が出力されるでしょう。 CDROM 書き込み &prompt.root; cdrecord -scanbus Cdrecord 1.9 (i386-unknown-freebsd4.2) Copyright (C) 1995-2000 Jörg Schilling Using libscg version 'schily-0.1' scsibus0: 0,0,0 0) 'SEAGATE ' 'ST39236LW ' '0004' Disk 0,1,0 1) 'SEAGATE ' 'ST39173W ' '5958' Disk 0,2,0 2) * 0,3,0 3) 'iomega ' 'jaz 1GB ' 'J.86' Removable Disk 0,4,0 4) 'NEC ' 'CD-ROM DRIVE:466' '1.26' Removable CD-ROM 0,5,0 5) * 0,6,0 6) * 0,7,0 7) * scsibus1: 1,0,0 100) * 1,1,0 101) * 1,2,0 102) * 1,3,0 103) * 1,4,0 104) * 1,5,0 105) 'YAMAHA ' 'CRW4260 ' '1.0q' Removable CD-ROM 1,6,0 106) 'ARTEC ' 'AM12S ' '1.06' Scanner 1,7,0 107) * リストにあるデバイスに対する適切な の値がここに示されています。あなたの CD ライタをこのリストから見つけ、 カンマで区切られた 3 つの数値を の値として使ってください。この例では CRW デバイスは 1,5,0 なので、適切な入力は となります。 値を明示するもっと簡単な方法もあります。詳細は &man.cdrecord.1; を見てください。そこにはオーディオトラックを書き込む方法や、 書き込み速度その他を操作する方法も書かれています。 オーディオ CD の複製 CD からオーディオデータを連続したファイルに展開し、ブランク CD にこれらのファイルを書き込むことで、オーディオ CD を複製することができます。 この手順は ATAPI および SCSI ドライブの間で少し異なります。 SCSI ドライブ cdda2wav を使用してオーディオを展開します。 &prompt.user; cdda2wav -v255 -D2,0 -B -Owav cdrecord を使用して .wav ファイルに書き出します。 &prompt.user; cdrecord -v dev=2,0 -dao -useinfo *.wav に説明されているように 2.0 が適切に指定されていることを確かめてください。 ATAPI ドライブ ATAPI CD ドライバでは、それぞれのトラックを /dev/acddtnn のように利用できます。 ここで d はドライブ番号であり、 nn は二桁十進のトラック番号です。 一桁の場合 0 を前に付加する必要があります。 したがって、一番目のディスクの一番目のトラックは /dev/acd0t01、二番目のトラックは /dev/acd0t02、三番目のトラックは /dev/acd0t03 などとなります。 適切なデバイスファイルが /dev に存在することを確かめてください。 存在しなければ、たとえば次のようにして作成します。 &prompt.root; cd /dev &prompt.root; sh MAKEDEV acd0t99 FreeBSD 5.0 では &man.devfs.5; が /dev にエントリを自動的に作成、 管理するので、MAKEDEV を使用する必要はありません。 &man.dd.1; を使用して各トラックを展開します。 ファイルを展開する際、ブロックサイズを指定しなければなりません。 &prompt.root; dd if=/dev/acd0t01 of=track1.cdr bs=2352 &prompt.root; dd if=/dev/acd0t02 of=track2.cdr bs=2352 ... burncd を使用して、 展開したファイルをディスクに書き込みます。 これらがオーディオファイルであること、 そして書き込みが終了したときに burncd がディスクを固定 (fixate) することを明示しなければなりません。 &prompt.root; burncd -f /dev/acd0c audio track1.cdr track2.cdr ... fixate データ CD の複製 データ CD を、sysutils/mkisofs を用いて作成されたイメージファイルと機能的に等価なイメージファイルにコピーできます。 これを使用して、すべてのデータ CD を複製することができます。 ここでの例は CDROM デバイスが acd0 であるとしています。あなたの CDROM デバイスに読み替えてください。 CDROM の場合には、パーティション全体またはディスク全体 を指定するために c をデバイス名の後に追加しなければなりません。 &prompt.root; dd if=/dev/acd0c of=file.iso bs=2048 これでディスクイメージを取り出すことができました。 すでに説明した方法を用いて CD に書き込むことができます。 データ CD の使用 さて、標準的なデータ CDROM を作成したので、 おそらく次はそれをマウントしてデータを読み出したいと思うでしょう。 デフォルトでは &man.mount.8; は、ファイルシステムタイプを ufs としています。 次のように実行しようとすると、 &prompt.root; mount /dev/cd0c /mnt Incorrect super block というエラーが返されてマウントできないでしょう。 CDROM は UFS ファイルシステムではないために、 このような手順でマウントしようすると失敗します。 ファイルシステムのタイプが ISO9660 であると &man.mount.8; に教えさえすれば、すべてはうまく動作します。 &man.mount.8; に オプションを指定することでこれを行います。 たとえば /dev/cd0c の CDROM デバイスを /mnt にマウントしたい場合は、 以下のように実行します。 &prompt.root; mount -t cd9660 /dev/cd0c /mnt 使用している CDROM インタフェースによっては、 デバイス名 (この例では /dev/cd0c) が異なるかもしれないことに注意してください。 また、 オプションは、単に &man.mount.cd9660.8; を実行します。 この例を以下のように短縮することもできます。 &prompt.root; mount_cd9660 /dev/cd0c /mnt 一般的にこの方法では、すべてのメーカの データ CDROM を使用することができます。しかしながら、特定の ISO 9660 拡張が施されたディスクでは奇妙な動作をするかもしれません。 たとえば Joliet ディスクは、 すべてのファイル名を 2 バイトの Unicode 文字で格納します。 FreeBSD カーネルは (まだ) Unicode を理解できないので、 非英語文字はクエスチョンマークで表示されます (FreeBSD 4.3 以降を使用している場合、CD9660 ドライバには適切な Unicode 変換表を読み込むための急ごしらえのフックが含まれています。 いくつかの共通のエンコードに対するモジュールは sysutils/cd9660_unicode port から利用可能です)。 CDROM をマウントしようとする時に、 Device not configured と表示されるかもしれません。これは、ディスクがトレーにないと CDROM ドライブが判断しているか、 ドライブがバス上に認識できないことを通常意味します。 ディスクが挿入されたことを CDROM ドライブが認識するには数秒かかりますので、 辛抱強く待ってください。 バスのリセットに返答するためのタイムアウトが短いために、時々 SCSI CDROM は認識に失敗するかもしれません。SCSI CDROM を持っている場合は、 次のオプションをカーネルコンフィギュレーションファイルに追加して、 カーネルを再構築してください。 options SCSI_DELAY=15000 これより、SCSI バスを起動時に 15 秒間停止させて、 CDROM ドライブがバスリセットに応答する機会を与えます。 Raw データ CD の書き込み ISO 9660 ファイルシステムを作成すること無く、 ファイルを直接 CD に書き込むこともできます。 この方法をバックアップ目的に使用している人もいます。 これは、標準 CD を書き込むよりもさらに速く実行することができます。 &prompt.root; burncd -f /dev/acd1c -s 12 data archive.tar.gz fixate このように CD に書き込まれたデータを取得するには、 raw デバイスノードからデータを読み込まなくてはなりません。 &prompt.root; tar xzvf /dev/acd1c このディスクを通常の CDROM としてマウントすることはできません。 このような CDROM は FreeBSD を除いて、 他のすべてのオペレーティングシステムでは読み込むことはできません。 CD をマウントしたいか、 その他のオペレーティングシステムとデータを共有したい場合は、 上記に説明したように sysutils/mkisofs を使用しなくてはなりません。 CD ライタ ATAPI/CAM ドライバ ATAPI/CAM ドライバの使用 このドライバは、ATAPI デバイス (CD-ROM, CD-RW, DVD ドライブなど) へ SCSI サブシステムを通じてアクセスすることを可能にします。 これにより、sysutils/cdrdao または &man.cdrecord.1; のようなアプリケーションが使用できるようになります。 このドライバを使用するためには、 カーネルコンフィギュレーションファイルに次の行を追加する必要があります。 device atapicam device scbus device cd device pass 次の行もカーネルコンフィギュレーションファイルに必要です。 device ata device atapicd 両方がすでに存在しなければなりません。 それから再構築し、新しいカーネルをインストールし、 コンピュータを再起動します。 起動プロセス中にディスクライタは以下のように表示されるでしょう。 acd0: CD-RW <MATSHITA CD-RW/DVD-ROM UJDA740> at ata1-master PIO4 cd0 at ata1 bus 0 target 0 lun 0 cd0: <MATSHITA CDRW/DVD UJDA740 1.00> Removable CD-ROM SCSI-0 device cd0: 16.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed ドライブは /dev/cd0 デバイスを通じてアクセスすることが可能となります。 たとえば、次のようにして CD-ROM を /mnt にマウントします。 &prompt.root; mount -t cd9660 /dev/cd0c /mnt root 権限で次のコマンドを実行して、 ライタの SCSI アドレスを得ることができます。 &prompt.root; camcontrol devlist <MATSHITA CDRW/DVD UJDA740 1.00> at scbus1 target 0 lun 0 (pass0,cd0) したがって、1,0,0 が &man.cdrecord.1; およびその他の SCSI アプリケーションで使用する SCSI アドレスです。 ATAPI/CAM および SCSI システムの詳細は &man.atapicam.4; および &man.cam.4; マニュアルページを参照してください。 Julio Merino 原作: Martin Karlsson 改訂: フロッピーディスクの作成と使用 フロッピーディスクにデータを格納することはしばしば役にたちます。 たとえば、ある人が他のリムーバブル記録メディアを何も持っていないときや、 小さなデータを他のコンピュータに移動させる必要があるときです。 この節では、FreeBSD におけるフロッピーディスクの使用方法を説明します。 主に 3.5 インチの DOS フロッピーのフォーマットと操作方法を扱いますが、 他のフロッピーディスクの形式についても概念は似ています。 フロッピーのフォーマット デバイス 他のデバイスと同様に、フロッピーディスクは /dev にあるエントリを通じてアクセスされます。4.X およびそれ以前のリリースにおいて raw フロッピーディスクにアクセスするには /dev/fdN または /dev/fdNX を使用します。N はドライブ番号を表し、 大抵は 0 です。X は文字を表します。 5.0 およびそれ以降のリリースでは、単に - /dev/fdN を使用します。/para> + /dev/fdN を使用します。 4.X およびそれ以前のリリースでのディスクサイズ /dev/fdN.size というデバイスもあります。 size はフロッピーディスクのサイズをキロバイトで示したものです。 これらのエントリは低レベルフォーマットの際に、 ディスクサイズを決定するのに使用されます。 1440kB は以下の例で使用されるサイズです。 時々 /dev 下のエントリは (再) 作成されなければなりません。次のコマンドでこれを行います。 &prompt.root; cd /dev && ./MAKEDEV "fd*" 5.X およびそれ以降のリリースでのディスクサイズ FreeBSD 5.0 では &man.devfs.5; が /dev 内のエントリを自動的に管理するので、 MAKEDEVを使用する必要はありません。 所望のディスクサイズは &man.fdformat.1; に フラグを通して渡されます。対応しているサイズは &man.fdcontrol.8; のマニュアルページに掲載されていますが、最良に動作するのは 1440kB だと助言しておきます。 フォーマット フロッピーディスクは、 使用前に低レベルフォーマットをする必要があります。 通常、ベンダは低レベルフォーマット済みのディスクを出荷していますが、 フォーマットはメディアの品質を確認するよい方法です。 より大きな (または小さな) ディスクサイズにすることも可能ですが、 ほとんどのフロッピーディスクのサイズは 1440kB で動作するように設計されています。 フロッピーディスクを低レベルフォーマットするには &man.fdformat.1; を使用する必要があります。 このユーティリティは引数としてデバイス名を指定します。 ディスクが良好かあるいは不良であるかを決定するのに役立つので、 エラーメッセージをすべてメモに取っておいてください。 4.X 以前のリリースでのフォーマット /dev/fdN.size デバイスを使ってフロッピーをフォーマットします。 新しい 3.5 インチフロッピーディスクをドライブに挿入し、 以下のコマンドを実行してください。 &prompt.root; /usr/sbin/fdformat /dev/fd0.1440 5.0 以降のリリースでのフォーマット /dev/fdN デバイスを使用してフロッピーをフォーマットします。 新しい 3.5 インチフロッピーディスクをドライブに挿入し、 以下のコマンドを実行してください。 &prompt.root; /usr/sbin/fdformat -f 1440 /dev/fd0 ディスクラベル ディスクを低レベルフォーマットしたら、 次にディスクラベルを作成する必要があります。 ディスクラベルは後で破棄されますが、 システムがディスクのサイズとジオメトリを決定するのに必要になります。 新しいディスクラベルはディスク全体を引き継ぎ、 フロッピーのジオメトリに関する適切な情報のすべてが含まれます。 ディスクラベルに対するジオメトリの値は /etc/disktab に掲載されています。 次のように &man.disklabel.8; を実行できます。 &prompt.root; /sbin/disklabel -B -r -w /dev/fd0 fd1440 &os; 5.1-RELEASE から、従来の &man.disklabel.8; プログラムは &man.bsdlabel.8; ユーティリティに置き換えられました。&man.bsdlabel.8; では、 使用されていないオプションおよびパラメタの数多くが削除されました。 たとえば オプションは &man.bsdlabel.8; では取り除かれました。詳細については &man.bsdlabel.8; マニュアルページを参照してください。 ファイルシステム これでフロッピーを高レベルフォーマットする準備ができました。これは FreeBSD がディスクを読み書きする新しいファイルシステムを作成します。 新しいファイルシステムを作成するとディスクラベルは破棄されます。 したがって、ディスクを再フォーマットするときには、 ディスクラベルを再作成しなくてはなりません。 フロッピーのファイルシステムには UFS または FAT を使用できます。 フロッピーに対しては FAT が一般的によりよい選択です。 フロッピー上に新しいファイルシステムを作成するには次のようにします。 &prompt.root; /sbin/newfs_msdos /dev/fd0 これでディスクが使用できるようになりました。 フロッピーの使用 フロッピーを使用するために、&man.mount.msdos.8; (4.X 以前のリリース) または &man.mount.msdosfs.8; (5.0 以後のリリース) を用いてマウントします。 Ports Collection から emulators/mtools を使用することもできます。 データテープの作成と使用 テープメディア 主要なテープメディアは 4mm, 8mm, QIC, ミニカートリッジ および DLT です。 4mm (DDS: Digital Data Storage) テープメディア DDS (4mm) テープ テープメディア QIC テープ 4mm テープはワークステーションのバックアップメディアの選択として QIC に取って代わりつつあります。Conner が QIC ドライブの主要なメーカである Archive を買収し、 QIC ドライブの製造を中止した時にこの傾向は非常に強まりました。4mm ドライブは小さくて静かですが、8mm ドライブが持っている信頼性ほど、その評判は良くありません。 また、4mm カートリッジは 8mm カートリッジに比べて安価でより小さくなっています (3 x 2 x 0.5 インチ、76 x 51 x 12 mm)。 ただし、8mm と同様に、4mm のヘッドはヘリカルスキャン方式 (訳注: VTR と同様の回転ヘッドの方式) を採用しているため、比較的短寿命です。 ドライブのデータスループットは、150 kB/s から 最大で 500 kB/s 程度です。 データ容量は 1.3 GB から 2.0  GB です。ドライブのほとんどで利用可能なハードウェア圧縮を使用すると、 容量が約二倍になります。 複数ドライブのテープライブラリユニットは単一のキャビネットに 6 つのドライブを収容可能で、自動的にテープの交換ができます。ライブラリの容量は 240 GB に達します。 DDS-3 標準は現在では 12 GB (圧縮により 24 GB) までの容量に対応しています。 8mm ドライブと同様に 4mm ドライブはヘリカルスキャンを使用します。 ヘリカルスキャン方式の利点および欠点はすべて 4mm および 8mm ドライブの両方に当てはまります。 テープは 2,000 回のパスあるいは 100 回のフルバックアップした後には交換するべきです。 8mm (Exabyte) テープメディア Exabyte (8mm) テープ 8mm テープはもっとも一般的な SCSI テープドライブです。 これらは交換型テープの最良の選択です。ほとんどすべてのサイトが Exabyte 2 GB 8mm テープドライブを所有しています。8mm ドライブは信頼性があり、便利で静かです。カートリッジは安価で小型です (4.8 x 3.3 x 0.6 インチ、122 x 84 x 15 mm)。8mm テープの欠点の一つは、ヘッドを横切るテープの高い相対動作率により、 ヘッドとテープは比較的短寿命ということです。 データのスループットは 250 kB/s から 500 kB/s 程度です。 データサイズは 300 MB から 7 GB までです。 ほとんどのドライブで利用可能なハードウェア圧縮を利用すると、 容量が約二倍になります。 これらのドライブは単一のユニット、または 6 つのドライブと 120 のテープを一つのキャビネットに収容可能な複数のドライブのテープライブラリとして利用可能です。 テープはユニットによって自動的に取り換えられます。 ライブラリの容量は 840 GB 強に達します。 Exabyte の Mammoth モデルは 一つのテープで 12 GB (圧縮により 24 GB) に対応し、 従来のテープドライブと比べ費用は約二倍になります。 データはヘリカルスキャンを用いてテープに記録されます。 ヘッダはメディアに対してある角度 (約 6 度) で配置されます。 テープはヘッドのある円筒の周の 270 度に渡って接触します。 テープが円筒面を走行する間、円筒は回転しています。 この結果、高密度のデータのつまったトラックは、 狭い間隔でテープの上端と下端の間を斜めに横切ります。 QIC テープメディア QIC-150 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 ドライブに置き換えられつつあり、 あまり頻繁には利用されなくなっています。 データは複数のトラックに分かれてテープに記録されます。 トラックはテープメディアの長さ方向の一端からもう一方の端までです (訳注: 1 トラックの read/write が終わるとテープの走行方向を反転させ 次のトラックの read/write を行います)。トラックの数と、 それに対応するトラックの幅はテープの容量によって変わります。 すべてではありませんが、 ほとんどの最近のドライブは少なくとも読み出しについては (場合によっては書き込みも) 下位互換性があります。 QIC はデータの安全性についてはよいといわれています (ヘリカルスキャンドライブに比べて機構は単純でより丈夫です)。 テープは 5000 回のバックアップで寿命となるでしょう。 XXX* ミニカートリッジ DLT テープメディア DLT DLT はここに示したドライブのタイプの中で最高速のデータ転送レートを発揮します。 1/2 インチ (12.5mm) テープが単リールのカートリッジ (4 x 4 x 1 インチ、100 x 100 x 25 mm) に入っています。 カートリッジのひとつの側面全体がスイングゲートになっています。 ドライブの機構がこのゲートを開け、テープリーダを引き出します。 テープリーダには楕円形の穴があり、 ドライブがテープを 引っ掛ける のに使います。 巻き取りのためのリールはドライブの中にあります。 ここに挙げた他のカートリッジはすべて (9 トラックテープはただ 1 つの例外です) 送りだしリールと巻き取りリールの両方がカートリッジの中にあります。 データスループットは約 1.5 MB/s で、4mm, 8mm, QIC テープドライブの 3 倍です。データ容量は単一のドライブで 10 GB から 20 GB の範囲です。マルチテープチェンジャ、 マルチテープドライブ、5 から 900 巻のテープを 1 から 20 ドライブで扱うマルチドライブテープライブラリがあり、 50 GB から 9 TB の容量が得られます。 圧縮によって、DLT タイプ 4 フォーマットは 70 GB の容量まで対応しています。 データは (QICテープのように) テープの走行方向と平行に複数ある トラックへ記録されます。2 つのトラックに同時書き込みを行います。 read/write ヘッドの寿命は比較的長いと言えます。 テープの走行が止まればヘッドとテープの間の相対運動は無いからです。 AIT テープメディア AIT AIT は、テープ一巻あたり (圧縮を用いて) 50 GB まで格納できる Sony が開発した新しい形式です。 テープにはメモリチップが搭載されており、 テープの内容のインデックスを保持しています。 他のテープではテープ上のファイルの位置を把握するのに数分必要とするのですが、 このテープドライブではインデックスを読んで直ちに決定することができます。 SAMS:Alexandria のようなソフトウェアは、テープのメモリチップと直接通信して、 スクリーンに内容を表示し、 どのファイルがどのテープにバックアップされたかを判断し、 正しいテープを見つけ、読み込み、 テープからデータを復元することができます。このソフトウェアを使うと、 40 以上の AIT テープライブラリを制御できます。 このようなライブラリは大体 $20,000 くらいするので、 愛好家が購入できる価格帯からは外れてしまいますが。 新品のテープを初めて使う場合 全く新品の空テープを読もうとしたり書き込もうとすると、 処理は失敗するでしょう。次のようなメッセージがコンソールに出力されるでしょう。 sa0(ncr1:4:0): NOT READY asc:4,1 sa0(ncr1:4:0): Logical unit is in process of becoming ready テープに識別ブロック (Identifier Block:block number 0) がありません。QIC-525 標準を採用したすべての QIC テープドライブは識別ブロックをテープに書き込みます。 2 つの解決方法があります。 mt fsf 1 によりテープドライブはテープに識別ブロックを書き込みます。 フロントパネルのボタンを押してテープを取り出します。 再びテープを挿入し、データをテープに dump します。 dump は DUMP: End of tape detected と報告し、 コンソールには HARDWARE FAILURE info:280 asc:80,96 と表示されるでしょう。 mt rewind を使ってテープを巻戻します。 次からはテープの操作はうまくいくでしょう。 フロッピーへのバックアップ データをバックアップするのにフロッピーは使えますか? バックアップフロッピー フロッピーディスク フロッピーディスクは以下の理由によって、 実際にバックアップをつくるための適切なメディアではありません。 メディアの信頼性が (特に長期間の場合) 低い。 バックアップとリストアがとても遅い。 容量が非常に小さい (ハードディスク全体の日々のバックアップに 1 ダース、 長期間なら本当にたくさん)。 しかしながら、データをバックアップするのに他の方法がないのなら、 バックアップを取らないよりもフロッピーディスクを使う方がよいでしょう。 フロッピーディスクを使用せざるを得ないときは、 品質のよいディスクを使用してください。 事務所のその辺に数年転がっていたフロッピーは使わない方が良いでしょう。 評判のよいメーカからの新しいディスクを使用することが理想です。 それではどうやってデータをフロッピーにバックアップするのですか? フロッピーにバックアップする一番の方法は (マルチボリューム) オプション付きで &man.tar.1; コマンドを使用することです。これにより、 複数のフロッピーにわたってバックアップすることが可能になります。 カレントディレクトリとサブディレクトリのすべてのファイルをバックアップするには以下のコマンドを (root 権限で) 使用します。 &prompt.root; tar Mcvf /dev/fd0 * 始めのフロッピーが一杯になったときには、 &man.tar.1; は次のボリュームを挿入するように要求します (&man.tar.1; はさまざまなメディアを扱えるので、 ボリューム (この場合フロッピーディスク) と表記します)。 Prepare volume #2 for /dev/fd0 and hit return: 指定したファイルがすべて保存されるまで (ボリューム番号を増やしながら) 繰り返されます。 バックアップを圧縮できますか? tar gzip 圧縮 残念なことに &man.tar.1; はマルチボリュームアーカイブに対して、 オプションを使うことができません。 もちろん、すべてのファイルを &man.gzip.1; で圧縮し、 それらを &man.tar.1; を用いてフロッピーに保存して、 それから再び &man.gunzip.1; を用いることは可能です。 どのようにしてバックアップをリストアしたらいいのでしょうか? すべてのアーカイブをリストアするには以下のようにします。 &prompt.root; tar Mxvf /dev/fd0 特定のファイルだけをリストアするには二つの方法があります。 まず始めに、一番目のフロッピーを用いて以下のようにします。 &prompt.root; tar Mxvf /dev/fd0 filename &man.tar.1; ユーティリティは、必要なファイルを見つけるまで次のディスクを挿入するように要求します。 二つ目の方法は、 必要なファイルがどのフロッピーに保存されているか分かっている場合、 単純にそのフロッピーを挿入して上記と同じコマンドを使用します。 あるフロッピー上にある一番目のファイルが、 その前のフロッピーから続いている場合は、 そのファイルのリストアを要求していなくても &man.tar.1; はそれをリストアできないと警告することに注意してください! バックアップの基本 主要なバックアッププログラムは &man.dump.8;, &man.tar.1;, &man.cpio.1; の三つです。 ダンプとリストア バックアップソフトウェア ダンプ / リストア dump restore 伝統的な &unix; のバックアッププログラムは dump および restore です。 これらはファイルシステムによって作成されたファイル、リンク、 ディレクトリの下位の抽象的概念であるディスクブロックの集合としてドライブを操作します。dump はデバイス上のすべてのファイルシステムをバックアップします。 ファイルシステムの一部分だけ、または二つ以上のファイルシステムにわたるディレクトリツリーをバックアップすることはできません。dump はファイルおよびディレクトリをテープに書き込みませんが、 ファイルおよびディレクトリを含んだ raw データブロックを書き込みます。 ルートディレクトリで dump を使用した場合、 /home, /usr や他のディレクトリの多くをバックアップしなくてもよいでしょう。 通常これらは他のファイルシステムへのマウントポイントであるか、 シンボリックリンクであるからです。 dump には AT&T UNIX のバージョン 6 (およそ 1975 年) の初期から残る奇癖があります。 デフォルトのパラメタは、現在利用可能な高密度メディア (最大 62,182 ftpi) ではなく、9 トラックテープ (6250 bpi) に最適な値となっています。 現在のテープドライブの容量を利用するために、 これらのデフォルトはコマンドライン上でオーバライドしなくてはいけません。 .rhosts rdump および rrestore を用いて他のコンピュータに接続されているテープドライブにネットワーク経由でデータをバックアップすることも可能です。 どちらのプログラムもリモートのテープドライブにアクセスするために rcmd および ruserok に依存しています。 したがって、バックアップを実行するユーザがリモートコンピュータの .rhosts ファイルに書かれていなければなりません。 rdump および rrestore の引数はリモートコンピュータに適切なものを用いなければなりません。 FreeBSD コンピュータから komodo と呼ばれる Sun に接続されている Exabyte テープへ rdump するには以下のようにします。 &prompt.root; /sbin/rdump 0dsbfu 54000 13000 126 komodo:/dev/nsa8 /dev/da0a 2>&1 注意: ここではセキュリティが確保されており、 .rhosts ファイルによる認証が許可されているものと暗黙的に仮定しています。 あなたの状況がこれにあてはまるか注意深く調べてください。 さらなる安全のために ssh 上で dump および restore を使用することも可能です。 <application>ssh</application> 上で <command>dump</command> を使用する &prompt.root; /sbin/dump -0uan -f - /usr | gzip -2 | ssh1 -c blowfish \ targetuser@targetmachine.example.com dd of=/mybigfiles/dump-usr-l0.gz <command>tar</command> バックアップソフトウェア tar &man.tar.1; は AT&T UNIX の バージョン 6 (1975 年ごろ) にまでさかのぼることができます。tar はファイルシステムと協調して動作し、 ファイルとディレクトリをテープに書き込みます。tar は &man.cpio.1; で使用可能なフルレンジのオプションには対応していませんが、 tar は cpio が使用するような奇妙なコマンドパイプラインを必要ありません。 tar tar の多くの版はネットワーク経由のバックアップには対応してません。 FreeBSD が使用している GNU 版の tar は、 rdump と同様の構文でリモートデバイスに対応しています。 komodo と呼ばれる Sun に接続された Exabyte テープドライブに tar を実行するには以下のようにします。 &prompt.root; /usr/bin/tar cf komodo:/dev/nsa8 . 2>&1 リモートデバイスに対応していない版に対しては、パイプラインと rsh を使用してリモートテープドライブにデータを送ることができます。 &prompt.root; tar cf - . | rsh hostname dd of=tape-device obs=20b ネットワークを越えたバックアップのセキュリティを懸念しているなら、 rsh の代わりに ssh を使用するべきです。 <command>cpio</command> バックアップソフトウェア cpio &man.cpio.1; は本来 &unix; ファイルを磁気メディアで交換するためのプログラムです。 cpio はバイトスワッピング、 多くの異なるアーカイブフォーマットの書き込みオプション (他にも多数のオプションがあります) があり、 パイプで他のプログラムにデータを渡すこともできます。 この最後にあげた特徴により、cpio はインストールメディアとしては優れた選択です。cpio はディレクトリツリーの探索の機能はなく、ファイルリストは stdin からの入力でなくてはなりません。 cpio cpio はネットワーク経由のバックアップには対応していません。 以下のようにパイプラインと rsh を用いてリモートテープドライブにデータを送ることができます。 &prompt.root; for f in directory_list; do find $f >> backup.list done &prompt.root; cpio -v -o --format=newc < backup.list | ssh user@host "cat > backup_device" directory_list はバックアップしたいディレクトリのリストで、 user@host はバックアップを実行したいユーザとホスト名の組であり、 backup_device はバックアップを書き込みたいデバイスです (たとえば /dev/nsa0)。 <command>pax</command> バックアップソフトウェア pax pax POSIX IEEE &man.pax.1; は tar と cpio に対する IEEE/&posix; の答えです。長年の間、さまざまな版の tar および cpio は互いにわずかながら非互換性を有していました。 それらをしらみ潰しに標準化する代わりに、&posix; は新しいアーカイブユーティリティを作りました。 pax は専用に開発された新しいフォーマットに加えて、 いくつもの cpio や tar のフォーマットの読み書きに対応しようと試みています。コマンド群は tar よりも cpio の方にいくぶん似ています。 <application>Amanda</application> バックアップソフトウェア Amanda Amanda Amanda (Advanced Maryland Network Disk Archiver) は単一のプログラムではなく、 クライアント/サーバ型のバックアップシステムです。 Amanda サーバは、 Amanda クライアントを有する ネットワークに接続されたコンピュータからデータを受け取り、 備え付けられたテープドライブにバックアップします。 いくつもの大容量ディスクを備えたサイトでの共通の問題は、 データディレクトリをテープにバックアップするのに時間がかかりすぎることです。 Amanda はこの問題を解決します。 Amanda は ホールディングディスク を使用して、 同時に複数のファイルシステムのバックアップを行うことができます。 Amanda の設定ファイルにかかれたすべてのファイルシステムのフルバックアップを特定の間隔でとるために アーカイブセット と呼ばれるテープグループを作成します。 アーカイブセット には 夜間に作成されるすべてのファイルシステムの増分 (または差分) のバックアップも含まれます。 障害が起きたファイルシステムのリストアには、 最も新しいフルバックアップと増分のバックアップが必要です。 設定ファイルでバックアップの制御と Amanda によるネットワークトラフィック量を設定します。 Amanda は上記のバックアッププログラムのいずれかを使用してデータをテープに書き込みます。 Amanda は port または package として利用可能です。デフォルトではインストールされていません。 何もしない 何もしない というのはコンピュータのプログラムではありませんが、 バックアップの戦略として最も広く採用されています。 これには初期投資が必要ありません。 従わなければならないバックアップスケジュールもありません。 ただ何もしないだけです。データに何か起きたら苦笑いして耐えてください! あなたにとって時間やデータの価値が少ないか、 あるいはまったくないのであれば 何もしない のはあなたのコンピュータに最も適したバックアッププログラムでしょう。 しかし注意してください。&unix; は便利なツールです。6 ヵ月も使用していれば価値のあるファイルの山が出来上がっているでしょう。 何もしない のはコンピュータによって正確に再作成される /usr/obj やその他のディレクトリツリーについては適切なバックアップ方法です。 HTML または &postscript; 版のこのハンドブックが一つの例です。 これらの文書形式は SGML ファイルから作成されたものです。 HTML または &postscript; ファイルのバックアップは必要ありません。 SGML ファイルは定期的にバックアップされます。 どのバックアッププログラムが最適ですか? LISA 定期的に &man.dump.8; しましょう。 Elizabeth D. Zwicky はここで検討したプログラムすべてについて拷問的なテストを行いました。 すべてのデータと &unix; ファイルシステムの状態すべてを保存するのに最適なのは、明らかに dump でしょう。 Elizabeth は大きく変化に富んだ異常な状態 (いくつかはあまり異常でない状態のものもあります) のファイルシステムを作成し、それぞれのプログラムを用いてそれらのファイルシステムのバックアップとリストアのテストを行いました。特色のある状態には、 ホールを持つファイル、ホールとヌルブロックを持つファイル、 奇妙な文字をファイル名に持つファイル、読み込み不可、 書き込み不可のファイル、デバイスファイル、 バックアップ中のファイルのサイズ変更、 バックアップ中のファイルの作成および削除、などがあります。 彼女は 1991 年 10 月の LISA V で結果の発表をしています。 torture-testing Backup and Archive Programs を参照してください。 緊急時のリストア手順 惨事の起きる前に 起き得るどのような惨事に対しても、 必要な手順は以下の 4 ステップだけです。 disklabel まず始めに、 各ディスクのディスクラベルとファイルシステムテーブル (/etc/fstab)、 すべてのブートメッセージをそれぞれ 2 枚ずつ印刷します (たとえば disklabel da0 | lpr)。 fix-it フロッピー 次に、ブートフロッピーと fix-it フロッピー (boot.flp および fixit.flp) にそのシステムのデバイスがすべて含まれているか確認します。 最も簡単に確認する方法は、フロッピーをドライブに入れてマシンをリブートしてブートメッセージを確認することです。 あなたのシステムのデバイスのすべてが含まれ、 機能していれば次のステップに進んでください。 そうでないなら、あなたのディスクのすべてをマウントでき、 テープドライブにもアクセスできるカスタムブートフロッピーを二つ作成する必要があります。 これらのフロッピーは fdisk, disklabel, newfs, mount および利用したいバックアッププログラムを含んでいなければなりません。 これらのプログラムをスタティックリンクされていなければなりません。 dump を使用するのなら、このフロッピーに restore も含まれていなければなりません。 続いて、定期的にバックアップテープを作成します。 最後のバックアップの後で行われた変更は回復することができないかもしれません。 バックアップテープにライトプロテクトをしてください。 最後に、フロッピー (boot.flp と fixit.flp または上記で作成した二枚のカスタムブートフロッピーディスク) およびバックアップテープのテストをします。手順のメモを作りましょう。 このメモはブートフロッピーとバックアップテープにいれておき、 印刷しておきます。 リストアを行うときはおそらく取り乱しているでしょうから、 このメモはバックアップテープを壊すようなことを防ぐのに役立つでしょう (どのように破壊してしまうのでしょう? tar xvf /dev/sa0 とする代わりに、偶然 tar cvf /dev/sa0 と入力してバックアップテープを上書きしてしまうかもしれません)。 訳注 上書きはライトプロテクトをしておけば防げますが、 何らかの原因でプロテクトがはずれているかもしれません。 ちなみに訳者の経験から言えば、 上のようなミスタイプは結構起きます。 安全性を増すために、 ブートフロッピーと二巻のバックアップテープを毎回とります。 一方を離れた場所に保管します。 離れた場所は同じ事務所の建物の地下室ではいけません。 世界貿易センタービルにあった数多くの会社は、 苦い経験によりこの教訓を得ました。 離れた場所とは、コンピュータやディスクドライブからかなり離れて、 物理的に分離されされていなければなりません。 ブートフロッピーを作成するスクリプト /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 da0 ./MAKEDEV da1 ./MAKEDEV da2 ./MAKEDEV sa0 ./MAKEDEV pty0 cd / # # create minimum file system table # cat > /mnt/etc/fstab < /mnt/etc/passwd < /mnt/etc/master.passwd < 惨事の後は 重要な問題は、ハードウェアが生き残ったかどうかです。 定期的にバックアップを取っていれば、 ソフトウェアについて心配する必要はありません。 ハードウェアに障害があれば、 コンピュータを使用する前にその部品を交換してください。 ハードウェアに問題が無ければ、フロッピーを確認してください。 カスタムブートフロッピーディスクを使用しているのであれば、 シングルユーザモードでブートしてください (boot: プロンプトで -s を入力します)。 それから次の項に進んでください。 boot.flp と fixit.flp を使用しているのであればこのまま読み進めてください。 boot.flp フロッピーをフロッピードライブに入れて、 コンピュータを起動してください。 本来のインストールメニューが画面に表示されます。 Fixit--Repair mode with CDROM or floppy. オプションを選択します。指示された通り fixit.flp をいれてください。 restore と必要となるその他のプログラムは /mnt2/stand にあります。 そして、ファイルシステムを一つずつ回復します。 mount root パーティション disklabel newfs 最初のディスクのルートパーティションを mount してみてください (たとえば mount /dev/da0a /mnt)。 ディスクラベルが破壊されている場合は、disklabel を用いてあらかじめ印刷して保存しておいた通りにパーティションを作り直し、ディスクラベルを作成してください。 newfs を使用してファイルシステムを作り直します。 ルートパーティションを読み書き可能にマウントし直します (mount -u -o rw /mnt)。 バックアッププログラムとバックアップテープを使用して、 このファイルシステムのデータを回復します (たとえば restore vrf /dev/sa0)。 ファイルシステムをアンマウントします (たとえば umount /mnt)。 障害を受けたファイルシステムそれぞれについて繰り返してください。 システムが動き出したら、 新しいテープにデータをバックアップしてください。 どのような理由で再び事故が起きたり、データが失われるかわかりません。 これに数時間を費すことで、後々の災難から救われます。 * I Did Not Prepare for the Disaster, What Now? ]]> Marc Fonvieille 再構成および追記: ネットワーク、メモリ、そしてファイルベースのファイルシステム 仮想ディスク ディスク 仮想 FreeBSD にはフロッピーや CD, ハードディスクなどの手元の計算機に取り付けたディスクの他に、 別の形態のディスク、仮想ディスク、もあります。 NFS Coda ディスク メモリ これには、Network File System のようなネットワークファイルシステムや Coda, メモリベースのファイルシステムおよびファイルベースのファイルシステムがあります。 稼働させている FreeBSD のバージョンによって、 ファイルベースおよびメモリベースのファイルシステムを作成したり操作するために、異なるツールを使用しなければならないでしょう。 FreeBSD 4.X の使用者は必要なデバイスを作成するために &man.MAKEDEV.8; を使用しなければならないでしょう。FreeBSD 5.0 以降では、&man.devfs.5; がデバイスノードを自動的に割り当ててくれるので、 使用者が意識する必要はありません。 FreeBSD 4.X でファイル中に構築されるファイルシステム ディスク ファイルベース (4.X) &man.vnconfig.8; ユーティリティを使えば擬似ディスクデバイスを設定し、 有効にすることができます。 vnode とはファイルの内部的な表現方法であり、 ファイルに関する操作の中心となるものです。つまり、&man.vnconfig.8; はファイルシステムを生成したり操作したりするためにファイルを用いるのです。 一つ例を挙げると、 ファイルに収められたフロッピーや CD-ROM のイメージをマウントするために用いることができます。 &man.vnconfig.8; を使用するためには、 カーネルが &man.vn.4; デバイスに対応している必要があります。 そうでなければ、カーネルコンフィギュレーションファイルに 次の行を追加してカーネルを再構築し、システムを再起動してください。 pseudo-device vn 既にあるファイルシステムイメージのマウント FreeBSD 4.X での vnconfig を用いた既存のファイルシステムイメージのマウント &prompt.root; vnconfig vn0 diskimage &prompt.root; mount /dev/vn0c /mnt &man.vnconfig.8; を用いたファイルシステムイメージの新規作成 <command>vnconfig</command> を用いたファイルベースディスクの新規作成 &prompt.root; dd if=/dev/zero of=newimage bs=1k count=5k 5120+0 records in 5120+0 records out &prompt.root; vnconfig -s labels -c vn0 newimage &prompt.root; disklabel -r -w vn0 auto &prompt.root; newfs vn0c Warning: 2048 sector(s) in last cylinder unallocated /dev/vn0c: 10240 sectors in 3 cylinders of 1 tracks, 4096 sectors 5.0MB in 1 cyl groups (16 c/g, 32.00MB/g, 1280 i/g) super-block backups (for fsck -b #) at: 32 &prompt.root; mount /dev/vn0c /mnt &prompt.root; df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/vn0c 4927 1 4532 0% /mnt FreeBSD 5.X でファイル中に構築されるファイルシステム ディスク ファイルベース (5.X) &man.mdconfig.8; ユーティリティは FreeBSD 5.X において メモリディスク (&man.md.4;) を設定し、有効にするために使用されます。 &man.mdconfig.8; を使用するためには &man.md.4; モジュールを読み込むか、 カーネルコンフィギュレーションファイルに &man.md.4; デバイスを追加してカーネルを再構築し、システムを再起動してください。 device md &man.mdconfig.8; コマンドは、 三つのタイプのメモリベース仮想ディスクに対応しています。 &man.malloc.9; を用いて割り当てられたメモリディスク、 ファイルをベースにしたメモリディスク、 およびスワップ領域をベースにしたメモリディスクです。 想定される使用法は、ファイル内に保持されたフロッピーイメージまたは CD イメージをマウントすることです。 既にあるファイルシステムイメージのマウント FreeBSD 5.X での <command>mdconfig</command> を用いた既存のファイルシステムイメージのマウント &prompt.root; mdconfig -a -t vnode -f diskimage -u 0 &prompt.root; mount /dev/md0c /mnt &man.mdconfig.8; を用いたファイルシステムイメージの新規作成 <command>mdconfig</command> を用いたファイルシステムイメージの新規作成 &prompt.root; dd if=/dev/zero of=newimage bs=1k count=5k 5120+0 records in 5120+0 records out &prompt.root; mdconfig -a -t vnode -f newimage -u 0 &prompt.root; disklabel -r -w md0 auto &prompt.root; newfs md0c /dev/md0c: 5.0MB (10240 sectors) block size 16384, fragment size 2048 using 4 cylinder groups of 1.27MB, 81 blks, 256 inodes. super-block backups (for fsck -b #) at: 32, 2624, 5216, 7808 &prompt.root; mount /dev/md0c /mnt &prompt.root; df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/md0c 4846 2 4458 0% /mnt オプションを用いて ユニット番号を指定しない場合、&man.mdconfig.8; は未使用のデバイスを自動的に選択するために &man.md.4; デバイスの auto-unit 機能を使用します。 割り当てられたユニットの名前は md4 のように標準出力に出力されます。&man.mdconfig.8; の詳細についてはマニュアルページを参照してください。 &os; 5.1-RELEASE から、従来の &man.disklabel.8; プログラムは &man.bsdlabel.8; ユーティリティに置き換えられました。&man.bsdlabel.8; では、 使用されていないオプションおよびパラメタの数多くが削除されました。 たとえば オプションは &man.bsdlabel.8; では取り除かれました。詳細については &man.bsdlabel.8; マニュアルページを参照してください。 &man.mdconfig.8; ユーティリティは大変役に立ちますが、 ファイルベースのファイルシステムを作成するために、 多くのコマンドの入力が必要となります。FreeBSD 5.0 では &man.mdmfs.8; と呼ばれるツールも用意されています。このプログラムは &man.mdconfig.8; を用いて &man.md.4; ディスクを設定し、&man.newfs.8; を用いて UFS ファイルシステムを作成し、&man.mount.8; を用いてマウントします。たとえば、上記と同じファイルシステムを作成し、 マウントしたい場合は、下記のように入力するだけです。 &prompt.root; dd if=/dev/zero of=newimage bs=1k count=5k 5120+0 records in 5120+0 records in 5120+0 records out &prompt.root; mdmfs -F newimage -s 5m md0 /mnt &prompt.root; df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/md0 4846 2 4458 0% /mnt ユニット番号を指定せずに オプションを使用した場合、&man.mdmfs.8; は未使用のデバイスを自動的に選択するために &man.md.4; デバイスの auto-unit 機能を使用します。&man.mdmfs.8; についての詳細はマニュアルページを参照してください。 FreeBSD 4.X でのメモリベースのファイルシステム ディスク メモリファイルシステム (4.X) &man.md.4; ドライバは FreeBSD 4.X においてメモリファイルシステムを作成するために単純で効果的な手段です。 メモリを割り当てるために &man.malloc.9; 関数が使用されます。 &man.vnconfig.8; を用いて作成したファイルシステムを例に取ると、 以下のようにします。 FreeBSD 4.X での md メモリディスク &prompt.root; dd if=newimage of=/dev/md0 5120+0 records in 5120+0 records out &prompt.root; mount /dev/md0c /mnt &prompt.root; df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/md0c 4927 1 4532 0% /mnt 詳細については &man.md.4; マニュアルページを参照してください。 FreeBSD 5.X でのメモリベースのファイルシステム ディスク メモリファイルシステム (5.X) メモリベースおよびファイルベースのファイルシステムに対しても 同じツール (&man.mdconfig.8; または &man.mdmfs.8;) を使用できます。 メモリベースのファイルシステムに対する記憶領域は &man.malloc.9; 関数を用いて割り当てられます。 <command>mdconfig</command> を用いたメモリベースディスクの新規作成 &prompt.root; mdconfig -a -t malloc -s 5m -u 1 &prompt.root; newfs -U md1 /dev/md1: 5.0MB (10240 sectors) block size 16384, fragment size 2048 using 4 cylinder groups of 1.27MB, 81 blks, 256 inodes. with soft updates super-block backups (for fsck -b #) at: 32, 2624, 5216, 7808 &prompt.root; mount /dev/md1 /mnt &prompt.root; df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/md1 4846 2 4458 0% /mnt <command>mdmfs</command> を用いたメモリベースディスクの新規作成 &prompt.root; mdmfs -M -s 5m md2 /mnt &prompt.root; df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/md2 4846 2 4458 0% /mnt &man.mdconfig.8; のコマンドラインの を に置き換えることで、&man.malloc.9; 関数によるファイルシステムを使用する代わりに スワップ領域を使用することが可能です。デフォルトでは &man.mdmfs.8; ユーティリティはスワップベースのディスクを作成します ( なし)。詳細は &man.mdconfig.8; および &man.mdmfs.8; マニュアルページを参照してください。 システムからメモリディスクを切り離す ディスク メモリディスクの切り離し メモリベースまたはファイルベースのファイルシステムが使用されていない場合、 すべてのリソースをシステムに開放するべきです。 はじめにファイルシステムをアンマウントします。 次にシステムからディスクを切り離し、リソースを開放するために &man.mdconfig.8; を使用します。 たとえば /dev/md4 によって使用されたすべてのリソースを切り離し、開放するには以下のようにします。 &prompt.root; mdconfig -d -u 4 mdconfig -l コマンドを使用することによって、 設定された &man.md.4; デバイスについての情報を表示することが可能です。 FreeBSD 4.X では &man.vnconfig.8; はデバイスを切り離すのに使用されます。たとえば /dev/vn4 によって使用されたすべてのリソースを切り離し、開放するには以下のようにします。 &prompt.root; vnconfig -u vn4 Tom Rhodes 寄稿: ファイルシステムのスナップショット ファイルシステム スナップショット FreeBSD 5.0 は Soft Updates と協調するファイルシステムスナップショットという新しい機能を提供します。 スナップショットは指定したファイルシステムのイメージを作成し、 また、ファイルとして扱うことができるようになります。 スナップショットファイルはアクションが実行されるファイルシステム内で作成されなければなりません。 また、ユーザは一つのファイルシステムあたり 20 までスナップショットを作成することができます。 有効なスナップショットはスーパーブロック内に記録されるので、 リブートしてから永続的にアンマウントおよびリマウントを記録します。 スナップショットが必要無くなったときは、 標準の &man.rm.1; コマンドを用いて削除することができます。 スナップショットはどんな順番で削除してもよいのですが、 その他のスナップショットが開放されたブロックのうちいくらかをおそらく必要とするので、 使用されていたすべてのスペースを得られるとは限りません。 初めてスナップショットを作成すると、root でさえも書き込めないように フラグ (&man.chflags.1; のマニュアルページを参照) が設定されます。 &man.unlink.1; コマンドは、スナップショットに フラグが設定されていてもそれらを削除することのできる例外です。 したがって、スナップショットファイルを削除する前に、 フラグをクリアする必要はありません。 スナップショットは &man.mount.8; コマンドを用いて作成されます。 /var のスナップショットを /var/snapshot/snap に作成したいときは、 以下のコマンドを使用します。 &prompt.root; mount -u -o snapshot /var/snapshot/snap /var スナップショットにはいくつかの利用法があります。 スナップショットをバックアップ目的に使用する管理者もいます。 なぜならスナップショットは CD やテープに転送できるからです。 ファイルの完全性を検証するために、 &man.fsck.8; をスナップショットに実行してもよいでしょう。 スナップショットをマウントしたときにそのファイルシステムがクリーンであったとすると、 そのスナップショットをマウントするときはいつでもクリーンな (そして変更のない) 結果を得るでしょう。 これは本質的には バックグラウンド &man.fsck.8; が行うことです。 スナップショット上で &man.dump.8; ユーティリティを実行すると、 スナップショットのファイルシステムとタイムスタンプが一致するダンプが返されるでしょう。 &man.dump.8; は オプションを使用することで、 一つのコマンドでスナップショットをとり、ダンプイメージを作成して、スナップショットを削除することが可能です。 ファイルシステムの 凍結された イメージとしてスナップショットを &man.mount.8; します。 /var/snapshot/snap のスナップショットを &man.mount.8; するには以下のようにします。 &prompt.root; mdconfig -a -t vnode -f /var/snapshot/snap -u 4 &prompt.root; mount -r /dev/md4 /mnt これで /mnt にマウントした 凍結状態の /var ファイルシステム構造を探索できます。 すべてがスナップショットが作成された時と同じ状態になるはずです。ただし、 以前に作成されたスナップショットがサイズ 0 のファイルとして現れることが唯一の例外です。 スナップショットの使用を終えた場合、以下のようにアンマウントできます。 &prompt.root; umount /mnt &prompt.root; mdconfig -d -u 4 およびファイルシステムスナップショットに関する詳細については、 http://www.mckusick.com/ にある Marshall Kirk McKusick のウェブサイトを参照してください。 ここには技術的な論文もあります。 ファイルシステムクォータ アカウンティング ディスク領域 ディスククォータ クォータは OS の持っているオプショナルな機能であり、 ファイルシステム毎にユーザやグループのメンバが使用するディスク容量やファイルの数を制限することができます。 この機能は、あるユーザやグループに割り当てられるリソースの量を制限することが望ましいようなタイムシェアリングシステムにおいてよく用いられます。 この機能を用いることによって使用可能なディスク容量の全てを一人のユーザやユーザのグループが使ってしまうことを防ぐことができます。 ディスククォータを使うためのシステム設定 ディスククォータの設定を始める前に、 まずはカーネルにクォータが組み込まれていることを確認しましょう。 カーネルのコンフィグレーションファイルに次の行を入れます。 options QUOTA 標準の GENERIC カーネルでは、 この機能は有効になっていませんので、 ディスククォータを利用するためには上記を設定後カーネルを構築しなおし、 作成されたカスタムカーネルをインストールしなければいけません。 カーネルのコンフィグレーションに関しては をご覧ください。 次に /etc/rc.conf でディスククォータを有効にする必要があります。 次の行を加えましょう。 enable_quotas="YES" ディスククォータ チェック 起動時の動作をさらに細かくコントロールするためにもう一つ設定用の変数があります。 通常、起動時には &man.quotacheck.8; によりそれぞれのファイルシステムのクォータの整合性がチェックされます。 &man.quotacheck.8; の役割は、 クォータデータベースのデータが正しくファイルシステム上のデータを反映しているか確認することです。 これはかなり時間を食う処理であり、 起動にかかる時間に大きな影響を及ぼします。 このステップをとばしたい人のために /etc/rc.conf に次の変数が用意されています。 check_quotas="NO" もし 3.2-RELEASE よりも前の FreeBSD を使っているならば設定はもっと単純で、一つの変数のみです。 次の行を /etc/rc.conf で設定してください。 check_quotas="YES" 最後に、ファイルシステム毎にディスククォータを有効にするために /etc/fstab を編集する必要があります。 ここでユーザもしくはグループ、 あるいはその両方にクォータを設定することができるのです。 あるファイルシステム上にユーザ毎のクォータを有効にする場合には、 /etc/fstab 中でクォータを有効にしたいファイルシステムエントリのオプション部に を加えます。 例えば次のようになります。 /dev/da1s2g /home ufs rw,userquota 1 2 同様に、グループクォータを有効にするには キーワードの代わりに を用います。 ユーザとグループの両方のクォータを有効にするには次のようにします。 /dev/da1s2g /home ufs rw,userquota,groupquota 1 2 デフォルトでは、 クォータファイルはそのファイルシステムのルートディレクトリに ユーザ用、グループ用それぞれ quota.user, quota.group という名前で置かれます。さらに詳しい情報は &man.fstab.5; をご覧ください。&man.fstab.5; マニュアルには別の場所を指定することができると書いてはありますが、 あまり勧められません。なぜなら、 様々なクォータ関係のユーティリティがそれにうまく対処できるようにないためです。 この時点で、 一度システムを再起動して新しいカーネルで立ち上げましょう。 /etc/rc が自動的に適当なコマンドを実行し、 /etc/fstab で有効にした全てのクォータ用に初期ファイルを作ってくれます。 従って、空のクォータファイルを手で作る必要は一切ありません。 通常の運用では &man.quotacheck.8; や &man.quotaon.8;, &man.quotaoff.8; といったコマンドを手で動かす必要はないのですが、 慣れるためにもこれらのマニュアルは読んでおきましょう。 クォータリミットの設定 ディスククォータ 制限 一旦クォータを有効にしたら本当に有効になっているのか確認しておきましょう。簡単な方法は次のコマンドを実行することです。 &prompt.root; quota -v ディスクの使用状況と、クォータが有効になっているファイルシステムのクォータリミットが一行にまとめて出力されるでしょう。 さあ、&man.edquota.8; でクォータリミットを設定する準備ができました。 ユーザやグループが使用できるディスク容量や作成できるファイルの数に制限をかけるにはいくつかのオプションがあります。割り当てディスク容量を制限 (ブロッククォータ) することもファイル数を制限 (inode クォータ) することも、両者を組み合わせることもできるのです。 これらの制限はそれぞれさらに二つのカテゴリ、 ハードリミットとソフトリミット、に分けることができます。 ハードリミット ハードリミットを越えることはできません。 あるユーザが一旦ハードリミットにたっした場合、 そのファイルシステムではそれ以上の割り当ては望めません。 例えばあるファイルシステム上に 500 ブロックのハードリミットが設定されており現在 490 ブロックを使用している場合、さらに 10 ブロックしか使えないのです。 11 ブロックを使おうとすると失敗します。 ソフトリミット 一方、 ソフトリミットはある限られた時間内であれば越えることができます。 この時間は猶予期間として知られており、デフォルトでは 1 週間です。 あるユーザが自分のソフトリミットを猶予期間よりも長い間越えているとソフトリミットはハードリミットに変わり、それ以上使用することはできなくなります。 ユーザがソフトリミットよりも減らせば猶予期間はリセットされます。 以下は &man.edquota.8; コマンドを実行した時に見ることになるであろう例です。 &man.edquota.8; コマンドが起動されると環境変数 EDITOR で指定されるエディタに入ります。 EDITOR が設定されていない場合には vi が起動されます。 ここでクォータリミットを編集します。 &prompt.root; 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 行あります。 一つはブロックリミット用でもう一つは inode リミット用です。 クォータリミットを変更したいところを書き変えるだけでかまいません。 たとえばこのユーザのブロックリミットを、ソフトリミットは 50 から 500 へ、ハードリミットは 75 から 600 に変更する場合、 /usr: blocks in use: 65, limits (soft = 50, hard = 75) から /usr: blocks in use: 65, limits (soft = 500, hard = 600) へ書き換えます。新しいクォータリミットはエディタを終了すれば設定されます。 ある範囲の UID に対してクォータリミットを設定したい場合がありますが、このような時には &man.edquota.8; コマンドの オプションを使うといいでしょう。まず、 あるユーザに割り当てたいクォータリミットを設定し、次に edquota -p protouser startuid-enduid を実行するのです。例えばユーザ test にお望みのクォータリミットが付いているとしましょう。 次のコマンドにより 10,000 から 19,999 の間の UID に対して同じクォータリミットを付けることができるのです。 &prompt.root; edquota -p test 10000-19999 さらに詳しいことは &man.edquota.8; のマニュアルページをご覧ください。 クォータリミットとディスク使用状況のチェック ディスククォータ チェック &man.quota.1; または &man.repquota.8; といったコマンドを使ってクォータリミットやディスクの利用状況を確認することができます。 &man.quota.1; コマンドは個々のユーザやグループのクォータやディスク利用状況を確認するのに使えます。 ユーザは自身のクォータ、そして所属するグループのグループのみ確認することができます。 スーパーユーザのみが他のユーザや所属していないグループのクォータと利用状況を見ることができます。 &man.repquota.8; コマンドを使うと、クォータが有効になっているファイルシステム用の全てのクォータやディスク容量のサマリを得ることができます。 以下は二つのファイルシステムにクォータ制限がかけられているユーザに対する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 日間の猶予期間が残っています。アスタリスク * はクォータリミットを越えているユーザを示していることに注意してください。 通常、そのユーザが全く使っていないファイルシステムは、 クォータリミットが付けられているとしても &man.quota.1; コマンドの出力には現われません。 オプションを用いればそのようなファイルシステム、 上の例では /usr/var、 を表示することができます。 NFS 上の クォータ NFS クォータは NFS サーバ上のクォータサブシステムにより実行されます。 &man.rpc.rquotad.8; デーモンにより、NFS クライアント上の &man.quota.1; コマンドは情報を得ることができ、クライアントマシン上のユーザが自分のクォータの統計を見ることができます。 /etc/inetd.conf において以下のように rpc.rquotad を有効にしましょう。 rquotad/1 dgram rpc/udp wait root /usr/libexec/rpc.rquotad rpc.rquotad そして以下のように inetd を再起動します。 &prompt.root; kill -HUP `cat /var/run/inetd.pid` Lucky Green 寄稿:
shamrock@cypherpunks.to
 ディスクパーティションの暗号化 ディスク 暗号化 FreeBSD は無許可のデータアクセスに対する優れたオンライン保護機能を提供します。 ファイルのパーミッションおよび強制的アクセスコントロール (MAC: Mandatory Access Control) (Mandatory Access Control (MAC) を参照) は、コンピュータが動作中で、OS が実行中であるときに、 無許可の第三者がデータにアクセスするのを防ぐことに役立ちます。 しかしながら、攻撃者がコンピュータに物理的にアクセスし、 機密データをコピーし分析するためにコンピュータのハードドライブを別のシステムに移動させることができれば、 OS によって強化された許可属性は意味をなさなくなります。 攻撃者が電源の落ちたコンピュータや ハードドライブを手にいれる手段にかかわらず、 GEOM ベースのディスク暗号化 (gbde: GEOM Based Disk Encryption) は、著しい資源を持ち本気で攻撃を仕掛けるつもりでやってきた攻撃者からさえもコンピュータのファイルシステム上にあるデータを保護することができます。 個々のファイルだけを暗号化する煩わしい方法と異なり、 gbde は全ファイルシステムを透過的に暗号化します。 平文テキストは決してハードドライブのプラッタに関係しません。 カーネルで gbde を有効にする <username>root</username> になる gbde の設定をするにはスーパユーザの権限が必要になります。 以下のコマンドを実行して、 root になってください。 &prompt.user; su - Password: オペレーティングシステムのバージョンを確かめる &man.gbde.4; が動作するには FreeBSD 5.0 以降が必要です。 以下のコマンドを実行して、 オペレーティングシステムのバージョンを確認してください。 &prompt.root; uname -r 5.0-RELEASE カーネルコンフィギュレーションファイルに &man.gbde.4; 対応を追加する お好みのテキストエディタを使用して、 以下の行をカーネルコンフィギュレーションファイルに加えます。 options GEOM_BDE FreeBSD カーネルを設定、再コンパイル、インストールします。 この手順は で説明されています。 新しいカーネルで再起動します。 暗号化されたハードドライブの準備 以下の例では、システムに新しいハードディスクを追加しようとしています。このシステムは単一の暗号化されたパーティションを保持することになります。 このパーティションは /private としてマウントされます。gbde は /home および /var/mail を暗号化するのにも使用できますが、 より複雑な指示を必要となるのでこの解説の範疇を越えています。 新しいハードドライブを追加する で説明されている通りに新しいドライブをシステムに設置します。 この例では、新しいハードドライブは /dev/ad4s1c パーティションに 加えられたものとします。 /dev/ad0s1* デバイスは、この例のシステム上に存在する標準的な FreeBSD パーティションを表します。 &prompt.root; ls /dev/ad* /dev/ad0 /dev/ad0s1b /dev/ad0s1e /dev/ad4s1 /dev/ad0s1 /dev/ad0s1c /dev/ad0s1f /dev/ad4s1c /dev/ad0s1a /dev/ad0s1d /dev/ad4 gbde ロックファイルを保持するディレクトリを作成する &prompt.root; mkdir /etc/gbde gbde ロックファイルには、 暗号化されたパーティションにアクセスするのに必要となる情報が格納されています。 ロックファイルにアクセスしない場合、 gbde は 膨大な手動による介在なしには (ソフトウェアは対応していません)、暗号化されたパーティションに含まれるデータを解読することはできないでしょう。 それぞれの暗号化されたパーティションは別々のロックファイルを使用します。 gbde パーティションを初期化する gbde パーティションは使用する前に初期化されなければなりません。 この初期化は一度だけ実行される必要があります。 &prompt.root; gbde init /dev/ad4s1c -i -L /etc/gbde/ad4s1c エディタが開くので、 テンプレートをもとにさまざまなオプションを設定してください。 UFS1 または UFS2 で使用するには、sector_size を 2048 に設定してください。 $FreeBSD: src/sbin/gbde/template.txt,v 1.1 2002/10/20 11:16:13 phk Exp $ # # Sector size is the smallest unit of data which can be read or written. # Making it too small decreases performance and decreases available space. # Making it too large may prevent filesystems from working. 512 is the # minimum and always safe. For UFS, use the fragment size # sector_size = 2048 [...] &man.gbde.8; はデータを保護するのに使用するパスフレーズを二度尋ます。 パスフレーズはそれぞれ同じでなければなりません。 データを保護する gbde の能力は、 - あなたが選択したパスフレーズの品質にまったく依存します。 + あなたが選択したパスフレーズの品質に完全に依存します。 記憶するのが簡単で、 安全なパスフレーズを選択する方法については、 Diceware Passphrase ウェブサイトを参照してください。 gbde init コマンドは gbde パーティションに対するロックファイルを作成します。この例では /etc/gbde/ad4s1c に格納されます。 gbde ロックファイルは、 すべての暗号化されたパーティションの内容とともにバックアップされなければ なりません。 ロックファイルだけを削除している間、 ロックファイルなしでは信念の固い攻撃者が gbde パーティションを解読することを防ぐことができない一方で、 正当な所有者は、&man.gbde.8; およびこの設計者にまったく支持されない膨大な量の作業なしには、 暗号化されたパーティション上のデータにアクセスすることができないでしょう。 カーネルに暗号化されたパーティションを接続する &prompt.root; gbde attach /dev/ad4s1c -l /etc/gbde/ad4s1c 暗号化されたパーティションを初期化する際に選択したパスフレーズを入力するように求められます。 新しい暗号化デバイスは /dev に /dev/device_name.bde として現れます。 &prompt.root; ls /dev/ad* /dev/ad0 /dev/ad0s1b /dev/ad0s1e /dev/ad4s1 /dev/ad0s1 /dev/ad0s1c /dev/ad0s1f /dev/ad4s1c /dev/ad0s1a /dev/ad0s1d /dev/ad4 /dev/ad4s1c.bde 暗号化デバイス上にファイルシステムを作成する カーネルに暗号化デバイスが接続されると、 デバイス上にファイルシステムを作成できます。 暗号化デバイス上にファイルシステムを作成するには &man.newfs.8; を使用します。従来の UFS1 ファイルシステムで初期化するより、 新しい UFS2 ファイルシステムで初期化した方が高速なので、 オプションとともに &man.newfs.8; を使用することが推奨されています。 &os; 5.1-RELEASE 以降では、 オプションはデフォルトです。 &prompt.root; newfs -U -O2 /dev/ad4s1c.bde &man.newfs.8; は、デバイス名に *.bde 拡張子によって認識される、 接続された gbde パーティションに対して実行されなければなりません。 暗号化パーティションをマウントする 暗号化ファイルシステムに対するマウントポイントを作成します。 &prompt.root; mkdir /private 暗号化ファイルシステムをマウントします。 &prompt.root; mount /dev/ad4s1c.bde /private 暗号化ファイルシステムが利用可能か確かめる これで暗号化ファイルシステムは &man.df.1; で見ることができ、 利用する準備ができました。 &prompt.user; df -H Filesystem Size Used Avail Capacity Mounted on /dev/ad0s1a 1037M 72M 883M 8% / /devfs 1.0K 1.0K 0B 100% /dev /dev/ad0s1f 8.1G 55K 7.5G 0% /home /dev/ad0s1e 1037M 1.1M 953M 0% /tmp /dev/ad0s1d 6.1G 1.9G 3.7G 35% /usr /dev/ad4s1c.bde 150G 4.1K 138G 0% /private 存在する暗号化ファイルシステムをマウントする システムを起動する度に、すべての暗号化ファイルシステムは 使用前にカーネルに接続し、 エラーの有無をチェックし、マウントする必要があります。 必要なコマンドは root ユーザとして実行されなければなりません。 カーネルに gbde パーティションを接続する &prompt.root; gbde attach /dev/ad4s1c -l /etc/gbde/ad4s1c パーティションの暗号化を初期化する際に選択したパスフレーズを入力するように求められるでしょう。 ファイルシステムのエラーをチェックする 暗号化ファイルシステムを自動的にマウントするために /etc/fstab に設定を掲載することはまだできないため、 マウントする前に &man.fsck.8; を実行して、 ファイルシステムのエラーをチェックしなければなりません。 &prompt.root; fsck -p -t ffs /dev/ad4s1c.bde 暗号化ファイルをマウントする &prompt.root; mount /dev/ad4s1c.bde /private これで暗号化ファイルシステムが利用できるようになりました。 暗号化パーティションを自動的にマウントする スクリプトを作成して、暗号化パーティションを自動的に接続、 チェック、マウントすることは可能です。しかしながら、 安全上の理由によりスクリプトに &man.gbde.8; パスワードを含めるべきではありません。その代わりに、コンソールまたは &man.ssh.1; による接続からパスワードを入力するようなスクリプトが手動で実行されることが推奨されます。 gbde が採用した暗号の保護 &man.gbde.8; は 128bit AES の CBC モードを使用してセクタペイロードを暗号化します。 ディスク上のそれぞれのセクタは異なる AES 鍵で暗号化されます。 セクタ鍵がユーザが入力したパスフレーズからどのように導き出されるかを含め、 gbde の暗号手法の設計についての詳細は、 &man.gbde.4; を参照してください。 互換性に関する問題 &man.sysinstall.8; は gbde 暗号化デバイスと互換性がありません。 &man.sysinstall.8; を実行する前に *.bde デバイスはすべてカーネルから切断されなければなりません。 そうしないと、&man.sysinstall.8; が初めにデバイスを走査する際にクラッシュしてしまうでしょう。 暗号化デバイスを切断するには、以下のコマンドを使用します。 &prompt.root; gbde detach /dev/ad4s1c &man.vinum.4; は &man.geom.4; サブシステムを使用しないので、 vinum ボリュームと gbde を併用できないことにも注意してください。 diff --git a/ja_JP.eucJP/books/handbook/hw/chapter.sgml b/ja_JP.eucJP/books/handbook/hw/chapter.sgml index a7b2a129c9..7c8215cc3b 100644 --- a/ja_JP.eucJP/books/handbook/hw/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/hw/chapter.sgml @@ -1,6648 +1,6648 @@ PC ハードウェアコンパチビリティ 訳: &a.jp.yoshiaki;, 1998 年 3 月 23 日. ハードウェアコンパチビリティの問題は現在の コンピュータ業界でもっとも多く起きる種類の問題であり, FreeBSDもこれに無縁ではありません. 安価に普及している PC ハードウェアで動かすことができるという FreeBSDの利点は, 市場にある驚くほど多様な種類の製品の サポートの義務というマイナス点でもあります. FreeBSDのサポートするハードウェアを徹底的に調べて提供することは不 可能ですが, このセクションでは FreeBSDに含まれるデバイスドライバとそ のドライバがサポートするハードウェアのカタログを示します. 可能で適切 なものについては特定の製品についての注釈を含めました. また, このハンドブックの コンフィグレーション ファイル のセクションにも サポートされているデバイスのリストがありますので そちらもご覧ください. FreeBSD はボランティアプロジェクトでテスト部門には資金がありません から, より多くの情報をこのカタログに載せるにはあなたがたユーザに 頼らなければなりません. あなた自身の経験により, あるハードウェアが FreeBSDで動くか動かないかがわかったとしたら&a.doc; へ e-mailして知らせてください. サポートされているハードウェアについて の質問は, &a.questions;(詳しいことは メーリングリスト を参照してください) へ 宛ててください. 情報を提供したり質問をする時は FreeBSDのバージョンと使っ ているハードウェアのできるだけ詳しい情報を含めることを 忘れないでください. インターネット上のリソース 以下のリンクはハードウェアを選ぶのに役に立ちます. FreeBSDに対して は必要のない (あるいは適用できない) ように見えるかもしれませんが, ここ からのハードウェアの情報のほとんどは OSに依存しないものです. 購入をする前にはあなたの選んだものがサポートされているか FreeBSDハード ウェアガイドを注意して読んでください. Toms's Hardware & Performance Guide 訳注: 日本国内でFreeBSDの動くハードウェアの情報を提供してい るWWWサーバがあります. FreeBSD POWERED hardwares これ以外にも情報を提供しているサーバはあります. いくつかの URLについて はFreeBSD Japan. からたどることができます. 組合せの見本 以下のハードウェアの組合せのサンプルリストは ハードウェアベンダや FreeBSD プロジェクトが保証するものではありません. この情 報は公共の利益のために公開しているものであり, 極めて数多くあるであろう 異なったハードウェアの組合せの中からのある経験の カタログに過ぎません. やり方はいろいろあります. 場合によってはうまく行かないこともあります. 十分気をつけてください. Jordan氏の選んだ組合せ 私の作ったワークステーションとサーバの構成は まずまずうまく行っ ています. 私はこれを保証できるわけでもありませんし, ここにあげた組 合せがずっと best buysであるわけではありません. 私はできればリス トを更新して行きますがそれがいつになるかはわかりません. 訳注: &a.jkh; 氏は FreeBSDプロジェクト FreeBSD コアチームのメンバです. マザーボード Pentium Pro (P6)システム用で気に入っているのは Tyan S1668 デュアルプロセッサマザーボードです. これは Intel PR440FX 同様 オンボードの WIDE SCSI と 100/10MB Intel Etherexpress NIC が ついています. これを使えば最高の小型のシングルあるいは デュアルプロセッサシステム (FreeBSD 3.0ではサポートされています)を作ることができます. Pentium Pro 180/256K チップの価格は非常に安くなっていますが, いつまで手にはいるかはわかりません.. Pentium II には, どちらかと言えばひいき目ですが, Adaptec SCSI WIDE コントローラのついた ASUS P2l97-S マザーボードです. For Pentium machines, the ASUS http://www.asus.com.tw/Products/Motherboard/Pentium/P55tp4/index.html はミッドレンジからハイエンドの Pentium サーバあるいはワークステーションシステムには よい選択です. フォルトトレラントシステムを構築したいのであれば パリティメモリを 使い, 真に24時間/週7日間動作させ続けるアプリケーションであれば ECCメモリを使うべきでしょう. ECCメモリはいくらか性能のトレードオ フがあります (それが重要なものであるかそうでないかはあなたのアプ リケーションによりますが). しかし, メモリエラーに対しては明らかに フォルトトレランス性が強化されます. ディスクコントローラ これはいくらかトリッキーです. 私は ISAから PCIまですべてコンパチブルな Buslogic コント ローラを使うようにすすめていましたが, 現在では ISAでは Adaptec 1542CF, EISA では Bt747c, PCIでは Adaptec 2940UW をすすめるよう変わってきています. NCR/Symbios の PCIカードも私のところではうまく動いています, ただ し BIOS-less モデルのボード(SCSI ボード上に ROMらしいものがない 場合は, マザーボード上に SCSIアダプタのための BIOSが必要な ボードである可能性があります 訳注: SC-200など) を使うのであれば マザーボードがそれをサポートしているかどうか 注意しなくてはなりません. PCIマシンで2つ以上の SCSIコントローラが必要となるのであれば, PCIバスの不足を防ぐために Adaptec 3940 カードを考えてもいいでしょう. これは1つのスロットで2台の SCSIコントローラ(と内部バス)を持ちます. ます. 市場には2つのタイプの 3940 がありますので 注意しましょう. — 古いモデルでは AIC 7880 チップを使っていますが, 新しいモデルでは AIC 7895 を使っています. 新しいモデルでは CAM ドライバのサポートが必要です. これはまだ FreeBSD の一部では ありません. 自分で付け加えるか, CAM binary snapshot リリースから インストールする必要があります(URLを参照してください). ディスクドライブ 私は, 極々特殊な状況を除いて それだけのお金をかけることができる なら SCSIは IDEよりもよい と言っています. 小規模なデスクトップ構成 のシステムでも, SCSIであればディスクが安くなっていった時にサーバの (古い入れ換えた) ディスクを比較的簡単に移し替えることができます. あ なたが複数のマシンの管理をしているのであれば単純に 容量について考えるのではなく, 食物連鎖のように考えましょう. 重要なサーバの場合は議論の余地はありません. SCSI機器と品質の良いケーブルを使いましょう. CDROM ドライブ 私は SCSIの方が好みますのでもちろん SCSI CDROMを選びました. 東芝 のドライブは 常に(スピードがどうであっても)お気に入りでしたが, 古い Plextor PX-12CS ドライブも好きです. 高々12倍速のドライブですが, 高い性能と信頼性を提供してくれています. 一般的には, 大部分の SCSI CDROM ドライブは私の見た限りではほとんどしっかりした構造ですので 多分 HPや NECの SCSI CDROMでも問題が起き ることはないでしょう. SCSI CDROM の価格はここ数ヶ月でかなり下落したようで, 技術的に 優れた方法でありながら 現在では IDE CDROMと同じ程度の価 格になっています. もし IDE と SCSI の CDROM ドライブの間で選択することができるのなら, 特に IDE を選ぶ理由はないでしょう. CD-R (CD Recordable: WORM) ドライブ この原稿を書いている時点で, FreeBSDは 3種類の CDRドライブ (私は これらすべては結局は Phillips社のドライブであるのではないかと考えているのですが) をサポートしています : Phillips CDD 522 (Plasmon のドライブと同様の動作をします), PLASMON RF4100, HP 6020i です. 私は HP 6020i を CDROMを焼くのに使っています(2.2 以降の システムで動きます. — それ以前のリリースの SCSIコードでは動きません). 非常に調子よく動いています. システムの /usr/share/examples/worm を見てください. ISO9660ファイルシステムイメージ (RockRidge拡張) を作るスクリプトと それを HP6020i CDR で焼くためのスクリプトの例があります. テープドライブ 私はたまたま Exabyte の 8mm drives と HP の 4mm (DAT) を持っています. バックアップのためであれば, より本質的に丈夫な (また, より容量が大きい) Exabyteの 8mmテープの方がおすすめできます. ビデオカード もし (米国では) 99USドルをかけて商品の XサーバをXi Graphics, Inc. (以前の X Inside, Inc.)から買うことができる なら間違いなく Matrox Millenium IIカードをおすすめします. このカードは無償提供されている XFree86 (現在のバージョンは 3.3.2です) のサーバでも非常によく動きます. Number 9の S3 Vision 868と 968 ベースのカード (the 9FX series) はわりあいと速く, XFree86の S3サーバで うまくサポートされています, 加えて現在では非常に低価格です. まず問題も起きないでしょう. モニタ 私の持っている Sony Multiscan 17seII monitors は非常に調子がいいので, 同じ (トリニトロン) ブラウン管を使っている Viewsonic をおすすめします. 17"よりも 大きなモニタ, 例えば 21" のモニタが実際に必要だとしたらこの文章の執筆時点では 2,000USドル以下のもの (20"のモニタでは 1,700USドル以下のもの) はまったくすすめられません. 20" 以上のクラスでよいモニタは(いくつも) ありますし, 20" クラスで安いモニタもあり ます. うまくいかないことに安くてよいモニタはほとんどありません! ネットワーキング まず最初に, Intel EtherExpress Pro/100B カードをすすめます. ISA カードでは SMC Ultra 16 コントローラ, いくらか安めのPCIベースのカード では SMC 9392DST, SMC EtherPower と Compex ENET32カードがおすすめ できます. 一般的に DECの DC2104x イーサネットコントローラチップを 使っている Znyx ZX342 や DEC DE435/450 などのカードはうまく動くでしょうし, (firewall や roouter に便利な) 2-port 品や 4-port 品を よく見つけることができますが, Pro/100B カードは最も少ない オーバーヘッドで最高の性能を出すでしょう. もう一方, できるだけ低コストでそこその性能で動くものを探しているなら, ほとんどの NE2000のクローンは極めて低価格で うまく動いてくれます. (特殊な) シリアル 高速のシリアル ネットワーク インタフェース (同期シリアルカード) を探しているのであれば Digi International製の SYNC/570 シリーズのド ライバが今の FreeBSD-CURRENT にあります. Emerging Technologies も 提供 するソフトウェアにより T1/E1 の性能が得られるボードを製造しています. もっとも私が直接これらの製品を動かした 経験があるわけではありません. 訳注:Emerging TechnologiesのWeb ページを見るとカードのスペックに Operating Systems: MS-DOS, MS-WINDOWS, System V UNIX, BSD/OS, FreeBSD, NetBSD and Linux と書いてあります. また "BSD/OS, FreeBSD and LINUX Router Card Solutions" というページ もあってサポートは良さそうです. マルチポートカードの選択の幅はかなり広いですが, FreeBSDがサポー トするいう点では Cyclades の製品が最も信頼できるでしょう. この最大の理由はこ の会社が私たちに十分な評価用ボードとスペックを 供給することを約束してくれているからです. 私は Cyclom-16Y が最高の性能価格比であると聞 いていましたが最近は価格のチェックはしていません. 訳注: cycladesの WWWサーバでも Supported Operating Systemsに Linuxや BSDi, FreeBSD が明記されています. 他のマルチポートカードで評判がよいのは BOCAおよび ASTのカードと Stallion Technologiesで, このカードには ここ で非公式なドライバが提供されているようです. オーディオ 私は現在 Creative Labs AWE32 を 使っています. もっともクリエイティブラボ製品が現在一般的にうまく 動いているから, ということにすぎませんが. 他のタイプのサウンド カードは同様にうまくは動かないと聞いています. 単に私の経験が 乏しいということにすぎないと言うことなのかも知れませんが. (私は以前は GUS のファンでしたが, Gravis はサウンドカード から撤退してしまいました). ビデオキャプチャー ビデオキャプチャーについては2つのいい選択肢があります — Hauppauge や WinTV などの Brooktree BT848 チップベースのボードは FreeBSD で非常にうまく動きます. もう一つの動作するボードは Matrox Meteor カードです. FreeBSD はクリエィティブラボの古い video spigotカードの サポートはしていますがこれは見つけるのは非常に むずかしいでしょう. Meteor は 440FX チップセットベースのマザーボードでは 動きませんので注意してください. 詳細はマザーボードの節を参照してください. このような場合には BT848 ベースの ボードを使った方がよいでしょう. 中心部/プロセッサ マザーボード, バス, チップセット * ISA * EISA * VLB PCI 原作: &a.obrien; 投稿者: &a.rgrimes;. 25 April 1995. 更新: &a.jkh;.最終更新 26 August 1996. 訳: &a.jp.yoshiaki;. 12 October 1996. Intelの PCIチップセットについて, 以下にさまざまな種類 の既知の不具合と問題の程度のリストを示します. Mercury: ISAバスマスタがISAとPCIブリッジの向 こう側にある場合は,キャッシュコヒーレンシ(一貫性)の 問題があります. このハードウェア欠陥に対処してうま く動かす方法はキャッシュを offにする以外にはありません. Saturn-I (82424ZX の rev 0, 1 ,2): ライトバックキャッシュのコヒーレンシに 問題があります. このハードウェア欠陥に対処してうまく動かす方法は 外部キャッ シュをライトスルーにすること以外にはありませ ん. Saturn-IIにアップデートしましょう. Saturn-II (82424ZX の rev 3 or 4): 問題なく動きます. ただし多くのマザーボードではライトバック動作に必要な 外部ダーティビット SRAMが実装されていません. 対策としてはライトスルーモードで動かすか, ダーティ ビット SRAMをインストールするかがあります. (これは ASUS PCI/I-486SP3G の rev 1.6 以降で使われています) Neptune: 2つより多くの(3台以上の)バスマスタデ バイスを動かすことができません. Intelは設計の欠陥を 認めています. 2つを越えるバスマスタを許さない, 特別な 設計のハードウェアで PCIバスアービタを置き換えることに より解決されています. (Intelの Altair boardや他にはい くつかの Intelサーバグループマザーボードに見られます). そして, もちろん Intelの公式の回答は Triton チップセットへの 移行で, こちらでは修整したということです. Triton (430FX): 知られているキャッシュコヒーレンシ やバスマスタの問題はありませんがパリティチェック機能が ありません. パリティを使いたいような場合は, 可能であ れば Triton-II ベースのマザーボードを選びましょう. Triton-II (430HX): このチップセット を使っているマザーボードに関するすべての 報告によれば今の ところ好評です. 既知の問題はありません. Orion: このチップセットの初期のバージョンでは PCI write-posting にバグがあり, 大量の PCIバストラフィッ クのあるアプリケーションでは性能の著しい低下があるとい う障害がありました. B0以降のリビジョンのチップセットで は問題は解決されています. 440FX: これは Pentium Pro に対応したチップセットで, 初期の Orion チップセットにあったような問題は見られず, 問題なく動 いているようです. また, これは ECCやパリティを含んだ広い 種類のメモリに対応しています. 既知の問題は Matrox Meteor ビデオキャプチャカードに関するものだけです. CPU/FPU 原作 &a.asami;. 27 December 1997. P6 クラス (Pentium Pro/Pentium II) Pentim Pro, Pentim IIとも FreeBSDで使うのにまったく問題はありません. 実際, わたしたちのメイン FTP サイトである ftp.FreeBSD.org (世界一大きな FTP サイト "ftp.cdrom.com" としても知られています) では Pentium Pro で FreeBSD を使っています. 興味のある方向けに 設定の詳細が公開されています. Pentium クラス Intel Pentium (P54C), Pentium MMX (P55C), AMD K6と Cyrix/IBM 6x86MXプロセッサは全て FreeBSDで動作確認がされています. どの CPUが速いかということはここでは述べません. インターネットを探せばあれが 速いとかこっちの方がいいとか教えてくれるサイトは いっぱいありますので, そちらをご覧ください. :) 一つ注意しないといけないのは, CPU によって必要な電源電圧や冷却の仕様が 異なるということです. マザーボードが指定された電圧を供給できることを 必ず確認しましょう. 例えば, 最近の MMX チップにはコアと入出力で違う電圧を使うもの (コア 2.9V, 入出力 3.3V など) がたくさんあります. また, AMDと Cyrix/IBMのチップには Intelの製品より熱くなるものがいくつかあります. その場合には強力なヒートシンク／ファンを使いましょう. (各社のホームページにお勧めの部品のリストがあります.) クロックスピード 原作 &a.rgrimes;. 1 October 1996. 更新 &a.asami;. 最終更新 27 December 1997. Pentium クラスのマシンはシステムの いくつかの部分で異なったクロックスピードを使っています. これは CPU, 外部メモリバス, PCIバスです. 別々のクロックスピードが使われるために高速な CPUを使ったシステムが 低速な システムよりも必ずしも速いとは限りません. それぞれの場合の違いを以下の表に示します. CPUクロック MHz 外部クロックとメモリバス MHz 外部クロックと内部クロックの比 PCIバスクロック MHz 6060 1.030 6666 1.033 7550 1.525 9060 1.530 10050 225 10066 1.533 12060 230 13366 233 15060 2.530 (Intel, AMD) 15075 237.5 (Cyrix/IBM 6x86MX) 16666 2.533 16666 2.533 18060 330 20066 333 23366 3.533 66 MHz は実際には 66.667 MHzかもしれませんが, そうだと決まっているわけでもありません. Pentium 100 は 50MHzの外部クロックの 2 倍または 66MHz の 1.5 倍の両方で 動かすことができます. 3 倍クロック以上の CPU ではメモリアクセス速度が 不足気味であるという点には注意していただきたいですが, 上の表を見るかぎりでは 100, 133, 166, 200, 233 MHzを使うのが最良だというのがわかります. AMD K6のバグ AMDの K6プロセッサで大きなコンパイルをすると, セグメンテーションフォルトで プロセスが落ちることがあるという事例が 1997年に多数報告されました. これは '97年の第3四半期に直ったようです. 情報を総合すると, チップ上の製造年週が 9733 (97年の 第33週に製造) 以降のものは大丈夫ということのようです. * 486 クラス * 386 クラス 286 クラス FreeBSDは 80286マシンでは動きません. 現在の巨大なフ ルスペックの UNIXをこのようなハードウェアで動かすことはほとんど 不可能でしょう. メモリ FreeBSDをインストールするのに最低限必要なメモリ量は 5 MBです. いったんシステムが起動してカスタムカーネルを 作ることができるならば, もっと少ないメモリ で動かすこともできます. boot4.flp を使えば 4 MB しかメモリがなく てもインストールできます. * BIOS 入力/出力デバイス * ビデオカード * サウンドカード シリアルポートとマルチポートカード UART とは何か, そしてどのように動作するか Copyright © 1996 &a.uhclem;, All Rights Reserved. 13 January 1996. 訳: &a.jp.saeki;, &a.jp.iwasaki;. 11 November 1996. ( ここからは &a.jp.saeki; が翻訳を担当) 汎用非同期送受信コントローラ (UART) はコンピュータのシリアル通信 サブシステムの鍵となる部品です. UART は何バイトかのデータを受けとり, これを 1 ビットずつ順番に送信します. 受信側では, もう一つの UART が このビット列を完全なバイト列に組み立て直します. シリアル転送は, モデムやコンピュータ間の非ネットワーク型の通信, ターミナルその他のデバイスで広く使われています. シリアル転送には主に同期と非同期という 二つの形式があります: 通信サブシステムの名前は, そのハードウェアでサポートされている 通信モードによって変化します. 通常, 非同期通信をサポートしているものは文字 A を含み, 同期通信をサポートしているものは文字 S を含みます. 以下で両方の形式について詳しく説明します. 通常使われている略号は以下の通りです:
UART 汎用非同期送受信装置 (Universal Asynchronous Receiver/Transmitter)
USART 汎用同期-非同期送受信装置 (Universal Synchronous-Asynchronous Receiver/Transmitter)
同期シリアル転送 同期シリアル転送では, 送信側と受信側がクロックを共有している 必要があります. さもなければ, 送信側がストローブまたは その他のタイミング信号を供給して, 受信側にデータの次のビットを いつ読み込 めばよいのかを知らせる必要があります. ほとんどの同期シリアル通信では, 常に何らかのデータが転送され続けます. そのため, 転送のタイミングまでに送信データが用意できていなければ, 通常のデータのかわりに「埋め草」 (fill character) が送られます. 同期通信では, 送信側と受信側との間でデータビットのみが転送されるため, 同じビット速度の非同期シリアル通信に比べて効率的です. しかし, 送信側と受信側でクロック信号を共有するために余分な電線と 回路が必要となる場合には, よりコスト高となる可能性があります. プリンタやハードディスクでも同期転送の 一種が使用されています. このときデータが 1 組みの電線で送られる一方, クロック信号または ストローブ信号が別の電線で送られます. プリンタやハードディスクは通常, シリアルデバイスではありません. ほとんどのハードディスクのインタフェース規格では, データを送るための 線とは別にクロックまたはストローブ信号を 送るための線を持っていて, ストローブ 1 回毎に一つのデータ全体を送ります. PC 産業界では, これらはパラレルデバイスとして知られています. PC の標準的なシリアル通信ハードウェアは, 同期モードをサポートして いません. ここで同期モードについて述べたのは, 非同期モードとの 比較のために過ぎません. 非同期シリアル転送 非同期転送は, 送信側がクロック信号を受信側に送らなくても データを転送することができます. そのかわり, 送信側と受信側は あらかじめタイミングパラメータや同期のために追加される 特別なビットについて 取り決めをおこなっておかなければなりません. 非同期転送をおこなうために UART にデータが与えられると, 「スタートビット」 と呼ばれるビットが転送データの先頭に追加されます. スタートビットはデータの転送開始を受信側に 知らせるために使われ, これにより受信側のクロックを送信側のクロックに 同期させます. この二つのクロックは, 転送データの残りのビットを転送する間に 10% 以上ふらつかないように正確なものでなければなりません. (この条件は機械式テレタイプの時代に定められたものなので, 現代の電子装置であれば容易に満足させることができます). スタートビットが送られた後, データの各ビットが最下位 (LSB) から 順番に送られます. 転送されるビットの長さはすべて同じになっていて, 受信側はそれぞれのビットの中央部でそれが 1 か 0 かを判断します. 例えば, 仮に 1 ビットを送るのに 2 秒かかるとすると, 受信側は スタートビットの始まりを認識した 1 秒後に信号が 1 か 0 かを調べ, その後 2 秒ごとに次のビットの値を調べるという動作を繰り返します. 送信側は, いつ受信側がビットの値を 見た のかはわかりません. 送信側はクロックにしたがって 次々にビットを転送するだけです. 設定によっては, 1 ワードのデータ全体が送られたあとに 送信側が内部で生成したパリティビットを 付加する場合があります. パリティビットは受信側で簡単なエラーチェックを するために使われます. その後に, 最低でも 1 ビットのストップビットが送られます. 1 ワードのすべてのビットを受信すると, 受信側がパリティビットの チェックをおこなうように設定することができます. (パリティビットを 使用するかどうか, 送信側と受信側であらかじめ取り決めておかなければ なりません). それから受信側はストップビットをチェックします. もしもストップビットが期待通りの位置に存在しなければ, UART は 転送エラーが発生したと判断して, ホストがデータを読もうとした時に フレーミングエラーが起きたと報告します. 通常, フレーミングエラーは 送信側と受信側のクロックが一致していなかったり, 信号に割り込みが 入った時に起こります. データが正しく受信されたかどうかにかかわらず, UART はスタート, パリティ, ストップビットを自動的に捨てます. 送信側と受信側で設定が正しく一致していれば, これらのビットが 誤ってホストに転送されることはありません. 1 回の転送が終了する前に次のデータの転送準備ができていれば, 前のデータのストップビットを送った後, 間を空けずに 次のデータのスタートビットを送ることができます. 非同期転送データは自己同期なので, 転送するべきデータがない場合は 転送路は空き状態になります. UART のその他の機能 転送のためにデータをパラレルからシリアルに変換し, 受信時に シリアルからパラレルに戻すという基本的な機能の他に, UART は通常, 転送路の状態を示したり, リモートデバイスで次のデータを受けとる準備が できていない場合にデータの流れを抑制するのに 使われる信号のための 付加回路も持っています. 例えば UART に接続されているデバイスがモデムの場合, モデムは 回線上に搬送波 (carrier) が存在していることを報告するかもしれません. 一方, コンピュータはこれらの付加信号を操作することにより モデムのリセットをおこなったり, かかってきた電話を取らないように モデムに指示するかもしれません. これらの付加信号の機能はそれぞれ EIA RE232-C 規格で定義されています. RS-232C と V.24 規格 ほとんどのコンピュータシステムでは, UART は EIA RS-232C 規格に 準拠した信号を生成するための回路に接続されています. また, RS-232C の仕様を反映した, V.24 という CCITT 規格に 準拠したシステムも存在しています. RS-232C のビット割り当て (マークとスペース) RS-232C では, 1 の値をマーク, 0 の値をスペースと 呼びます. 通信路にデータが流れていない時, 回線はマーキング であるとか, 1 の値を連続して転送し続けているとか言われます. スタートビットは常に 0 (スペース) で, ストップビットは常に 1 (マーク) です. このことは, たとえ複数のデータが連続して転送されている場合でも, それぞれのデータの転送開始時には必ず, マーク (1) から スペース (0) への遷移が回線上で起こるということを意味しています. これによって, 転送されるデータビットの内容にかかわらず, 送信側と受信側の クロックを同期させることができるのです. ストップビットとスタートビットの間の空き時間は, その通信路で 1 ビットを転送するのに必要な時間の正確な倍数である 必要はありません. (倍数にはゼロを含みます). しかし, ほとんどの UART では 設計の単純化のために, 倍数になるように設計されています. RS-232C では, 「マーク」信号 (1) は -2V から -12V の間の電圧で, 「スペース」信号 (0) は 0V から +12V の間の電圧で示されます. 送信部は +12V または -12V を送ることになっていて, 受信部では 長いケーブルによるいくらかの電圧ロスを 許容するように定められています. (ポータブルコンピュータなどで使用されている) 低消費電力デバイスの 送信部では しばしば +5V と -5V のみを使用していますが, 短いケーブルを使用するならば, これらの電圧も RS-232C 受信部の 許容範囲に入っています. RS-232C のブレーク信号 RS-232C は ブレーク と呼ばれる信号についても定めています. これは (スタートビットもストップビットも無しで) 連続して スペースの値を送ることで発生されます. データ回路に電流が流れていない場合は, 回線は ブレーク を送り続けているものと解釈されます. ブレーク 信号は完全な 1 バイトとスタート, ストップ, パリティ ビットを送るために必要な時間よりも 長い間続かなければなりません. ほとんどの UART はフレーミングエラーとブレークを区別することが できますが, もしも これを区別できない UART があった場合, フレーミングエラーの検出をブレークの識別のために 使用することができます. テレタイプの時代には, 国中でおびただしい数のテレタイプが (ニュースサービスなどで) 電線で直列に接続されていました. 任意のテレタイプユニットは, 電流が流れないように一時的に回路を オープンにすることで ブレーク 信号を発生させることができました. これは, 他のテレタイプが情報を送信している間に, 緊急ニュースを 送る必要のあるテレタイプが 割り込みをかけるために使われました. 現在のシステムでは, ブレーク信号には二つのタイプがあります. もしブレーク信号が 1.6 秒よりも長ければ, それは 「モデムブレーク」であると解釈されます. モデムがこの信号を検出すると, 通信を終了して電話を切ったり, コマンドモードに入るように プログラムされていることがあります. もしブレーク信号が 1.6 秒よりも短ければ, それはデータブレークを 示します. この信号に応答するのはリモートコンピュータの仕事です. この形のブレークは, しばしば注意喚起または割り込みのための信号として 使われ, ASCII の CONTROL-C 文字の代用とされることもあります. マークとスペースは紙テープシステムでの 穴空き と 穴無し に 相当しています. ブレーク信号は, 紙テープまたはその他のバイト列から生成できない ことに注意してください. なぜならバイト列は常にスタートビットや ストップビットとともに送られるからです. UART には通常, ホストプロセッサからの特別なコマンドにより 連続したスペース信号を生成する能力があります. RS-232C の DTE デバイスおよび DCE デバイス RS-232C 規格は二つのタイプの装置を定めています: それはデータターミナル装置 (DTE) とデータキャリア装置 (DCE) です. 通常, DTE デバイスはターミナル (またはコンピュータ) で, DCE は モデムです. 電話回線を介した通信のもう一方の端である受信側のモデムも また DCE デバイスで, そのモデムに接続されているコンピュータは DTE デバイスです. DCE デバイスが信号を受け取るピンは DTE デバイスが 信号を送るピンであり, また逆も同様です. 二つのデバイスがともに DTE であったり, ともに DCE であって, モデムやそれに類似したメディア変換装置を介さずに 接続する必要が ある場合, ヌルモデム (NULL modem) を使わなければなりません. ヌルモデムはケーブルを電気的に再配列し, 一方のデバイスの送信出力が もう一方のデバイスの受信入力に接続され, その逆もまた同様に 接続されるようにしてくれます. 同様の変換はすべての制御信号についておこなわれ, それぞれのデバイスが 他方のデバイスからの DCE (または DTE) 信号を受けとれるようになります. DTE デバイスと DCE デバイスで生成される信号の数は等しくありません. DTE デバイスが DCE デバイスのために生成する信号の数は, DTE デバイスが DCE デバイスから受けとる信号の数よりも 少なくなっています. RS-232C のピン割当て EIA の RS-232C 規格 (およびこれに相当する ITU の V.24 規格) は 25 ピンのコネクタ (通常 DB25 が使われます) を要求し, そのコネクタのほとんどのピンの 使用目的を定義しています. IBM PC および類似のシステムでは, RS-232C 信号のサブセットが 9 ピンのコネクタ (DB9) で提供されています. 主に同期モードで使用される信号は PC のコネクタには含まれていませんが, もともと この転送モードは IBM が IBM PC で使用することにした UART ではサポートされていません. メーカーによっては RS-232C 用のコネクタに DB25 か DB9, またはその両タイプのコネクタを使っている場合があります. (IBM PC はパラレルプリンタインタフェースにも DB25 コネクタを 使っているので, このことは しばしば混乱を引き起こします.) 以下は DB25 および DB9 コネクタにおける RS-232C 信号の割り当て表です. DB25 RS232-C 端子 DB9 IBM PC 端子 EIA 回路符号 CCITT 回路符号 一般名称 信号源 説明 1 - AA 101 PG/FG - 保安用接地 2 3 BA 103 TD DTE 送信データ 3 2 BB 104 RD DCE 受信データ 4 7 CA 105 RTS DTE 送信要求 5 8 CB 106 CTS DCE 送信可 6 6 CC 107 DSR DCE データセットレディ 7 5 AV 102 SG/GND - 信号用接地 8 1 CF 109 DCD/CD DCE 受信キャリア検出 9 - - - - - 予約 (テスト用) 10 - - - - - 予約 (テスト用) 11 - - - - - 未割当て 12 - CI 122 SRLSD DCE 従局受信キャリア検出 13 - SCB 121 SCTS DCE 従局送信可 14 - SBA 118 STD DTE 従局送信データ 15 - DB 114 TSET DCE 送信信号エレメントタイミング 16 - SBB 119 SRD DCE 従局受信データ 17 - DD 115 RSET DCE 受信信号エレメントタイミング 18 - - 141 LOOP DTE ローカルループバック 19 - SCA 120 SRS DTE 従局送信要求 20 4 CD 108.2 DTR DTE データ端末レディ 21 - - - RDL DTE リモートデジタルループバック 22 9 CE 125 RI DCE 被呼表示 23 - CH 111 DSRS DTE データ信号速度選択 24 - DA 113 TSET DTE 送信信号エレメントタイミング 25 - - 142 - DCE テストモード ビット, ボー, そしてシンボル ボーとは非同期通信における転送速度の単位です. モデム通信技術の進歩により, 新しいデバイスのデータ速度を 表記するにあたって, この用語が しばしば誤って使われるようになりました. ボーレートは伝統的に, 通信路を通して実際に送られるビットの数を 表します. ある DTE デバイスからもう一方へと実際に移動した データの量を表すものではありません. ボーレートは, 送信側 UART で生成されて受信側 UART で取り除かれる スタート, ストップ, パリティといったオーバーヘッドビットをも 含んでいます. これは 1 ワード 7 ビットのデータを送るためには, 実際には 10 ビットの データが完全に転送される必要があるということを意味します. そのため, もしパリティを使い, スタートビットとストップビットが それぞれ 1 ビットずつ存在する場合には, 1 秒あたり 300 ビットの 転送能力を持つモデムでは, 7 ビットのワードを通常 30 個しか 転送することができません. もし 1 ワード 8 ビットのデータとパリティビットを使用する場合には, データ転送速度は 1 秒あたり 27.27 ワードまで低下します. なぜなら 8 ビットのワードを送るのに 11 ビットが必要で, このモデムは 1 秒間に 300 ビットしか送ることができないからです. 1 秒あたりの転送バイト数をボーレートに変換したり, その逆をおこなう 計算式は, エラー訂正をおこなうモデムが現れるまでは単純でした. エラー訂正をおこなうモデムは, ホストコンピュータの UART から シリアルのビット列を受けとり, それをバイト列に戻します. (内蔵モデムを使用している場合でさえ, データは今まで通り 頻繁にシリアル化されます) その後これらのバイトはパケットに変換され, 同期転送方式を用いて 電話回線を通じて送信されます. これは DTE (コンピュータ) 中の UART で追加されたストップ, スタート およびパリティビットは, モデムから送り出される前に, モデムによって 取り除かれるということを意味します. これらのバイト列がリモートモデムに受信されると, リモートモデムは スタート, ストップおよびパリティビットを追加して, それらを シリアル形式に変換し, リモートコンピュータの受信側 UART に送ります. そしてリモートコンピュータの UART はスタート, ストップおよび パリティビットを取り除きます. これらの特別な変換はすべて, 二つのモデムの間でエラー訂正が 実行できるようにするためおこなわれています. エラー訂正とは, 受信側のモデムが正しいチェックサムで 受信できなかったデータブロックの再送を, 送信側のモデムに要求することができるということです. この作業はモデムにより処理されて, DTE デバイスは このようなプロセスがおこなわれていることに, 通常気がつきません. スタート, ストップおよびパリティビットを取り除くことにより, エラー訂正のために二つのモデムの間で共有しなければならない 追加のビットを, 実効転送速度を低下させずに送ることができます. そのため, 送受信 DTE にはエラー訂正がおこなわれているかどうかが ほとんど見えなくなります. 例えば, もしモデムが 10 個の 7 ビットデータをもう一方のモデムに送る 際に, スタート, ストップ, およびパリティビットを送る必要がなければ, その分の 30 ビットの情報を, 真のデータの転送速度に影響を与えることなく エラー訂正のために追加することができるわけです. データ圧縮をおこなうモデムでは, ボーという言葉の使い方は さらに混乱することになります. 例えば電話回線を通じて送られた二つの 8 ビットデータは, 送信側モデムに送られた 12 バイトのデータを表すかもしれません. 受信側モデムはそのデータを本来の内容に展開し, 受信側の DTE に渡します. また, 最近のモデムはバッファを内蔵しており, (DCE から DCE へ) 電話線を 流れるデータの転送速度と, 両端の DTE と DCE の間で流れるデータの 転送速度とを別々に設定することができます. モデムによる圧縮を使用する場合, 通常は DTE と DCE の間の速度を DCE と DCE の間の速度より速くしておきます. 1 バイトを記述するのに必要なビットの数は, 二つのマシンの間でも DTE-DCE と DCE-DCE のリンクでそれぞれ変化する場合がありますし, そのうえ, それぞれのビット転送速度が異なる場合もあります. そのため, 全体としての通信速度を表現するために ボーという言葉を使うことは 問題でもありますし, 真の転送速度を正しく伝えない場合があります. 1 秒あたりの転送ビット数 (bps) は DCE と DCE の間のインタフェースに おける転送速度を記述するために使うなら正しい用語ですし, ボーまたは 1 秒あたりのビット数は, 二つのシステムが電線で直接 接続されていたり, エラー訂正や圧縮をおこなわないモデムが 使われている場合には, 許容可能な用語です. 最近の高速モデム (2400, 9600, 14,400, 19,200bps などのもの) も, 実際には 2,400 ボー (正確には 2,400 シンボル/秒) か, それ以下の 速度で通信しています. 高速モデムでは, 複数のビットを一つのシンボルで 伝送する技術 (多値符合化など) を用いて, シンボル速度 (シンボル/秒) よりも 高い通信速度 (ビット/秒) を達成しています. これが電話の限られた音声帯域で 高い伝送速度を得られる理由です. 28,800bps やそれ以上のモデムでは, シンボル速度自体が 可変になっていますが, それ以外は同様の技術が用いられています. IBM PC の UART 元祖 IBM PC を設計した際に, IBM はナショナル・セミコンダクタ社の INS8250 UART を IBM PC パラレル/シリアルアダプタで使用することに 決めました. IBM 自身やその他のベンダが作っている後継世代の AT 互換機でも, INS8250 そのものやナショナル・セミコンダクタの UART ファミリの 改良版を使い続けられています. ナショナル・セミコンダクタの UART ファミリ系統図 INS8250 UART にはいくつかのバージョンと後継の部品があります. 主要なバージョンを以下に示します. INS8250 -> INS8250B \ \ \-> INS8250A -> INS82C50A \ \ \-> NS16450 -> NS16C450 \ \ \-> NS16550 -> NS16550A -> PC16550D INS8250 この部品は元祖 IBM PC と IBM PC/XT で 使われていました. この部品は本来 INS8250 ACE (Asynchronous Communications Element) と いう名前で, NMOS 技術で作られていました. 8250 は八つの I/O ポートを占有し, 送信バッファ 1 バイトと 受信バッファ 1 バイトを持っています. この元祖の UART はいくつかの 競合状態などに関する欠陥を持っています. 元祖の IBM BIOS はこれらの欠陥を回避してうまく動くようなコードを 含んでいましたが, そのために BIOS が欠陥の存在に依存するように なってしまいました. このため, 元祖 IBM PC や IBM PC/XT では 8250A, 16450, または 16550 のような後継部品を使うことは できませんでした. INS8250-B これは NMOS 技術で作られた INS8250 の低速版です. これもオリジナルの INS8250 と同じ問題を含んでいます. INS8250A XMOS 技術を使い, さまざまな機能的欠陥を修正した INS8250 の改良版です. INS8250A は当初, クリーンな BIOS を 使用したベンダの PC クローンで使用されていました. なぜなら欠陥が修正されたことにより, この部品は INS8250 や INS8250B の ために書かれた BIOS で使うことはできなかったからです. INS82C50A これは INS8250A の CMOS 版 (低消費電力版) で, INS8250A と同じ機能特性を持っています. NS16450 より高速な CPU バスにも対応できるように 改良されたこと以外は NS8250A と同じです. IBM はこの部品を IBM AT で使うことに決め, もはや IBM BIOS が INS8250 のバグに依存しなくなるように 変更をおこないました. NS16C450 これは NS16450 の CMOS 版 (低消費電力版) です. NS16550 送信バッファと受信バッファをそれぞれ 16 バイトに 変更したこと以外は NS16450 と同じですが, バッファの設計に 欠陥があるため, 信頼して使用することはできません. NS16550A バッファの欠陥が修正されたこと以外は NS16550 と 同じです. 割り込みへの反応が遅い OS でも高い信頼性で高速なデータを 扱うことができることから, 16550A とその後継部品は PC 産業界で 最も一般的に使われる UART となりました. NS16C552 これは 2 個の NS16C550A CMOS UARTを 一つのパッケージに入れた部品です. PC16550D ささいな欠陥が修正されたこと以外は NS16550A と 同じです. これは 16550 ファミリの D リビジョンで, ナショナル・セミコンダクタ社から 提供されている最新の部品です. NS16550AFとPC16550Dは同じもの ( ここからは &a.jp.iwasaki; が翻訳を担当) ナショナル・セミコンダクタは 数年前に部品番号体系を再編成して おり, NS16550AFN という名称はもはや存在しません. (もしあなたが NS16550AFN を持っていたら, 部品の日付コードを見てください. それは 通常 9 から始まる4桁の数字です. 最初の2桁の数字は年度, 次の2桁 は部品がパッケージされた年度の週です. あなたの持っている NS16550AFN は, おそらく数年前のものでしょう.) 新しい番号は PC16550DV の様に, パッケージ材料と形状により接尾辞 に小さな違いがあります (番号体系についての記述は後述します). ここで注意しなければいけないことがあります. 例えば, ある店に行って 1990年製の NS16550AFN を15米ドルで売っているとします. ところが, そのすぐ隣には ナショナル・セミコンダクタが AFN を生産開始してから それにマイナーな変更を加えて作った PC16550DN があり, そちらは 最近 6ヶ月に作られたものなのに, 簡単に入手できるため NS16550AFN の 半額 (たくさん一度に買うと 5米ドルまで下がることもあります) 位で 買えたりすることがあるのです. NS16550AFN のチップ供給は減少し続けているため, PC16550DN が古い 部品番号のものとまったく同じ機能を持っていることに, より多くの人が 気付いて受け入れるまでは, 価格はおそらく上昇し続けるでしょう. ナショナル・セミコンダクタの部品番号体系 古い NSnnnnnrqp の部品番号は, 現在 PCnnnnnrgp というフォーマットになっています. r はリビジョンのフィールドです. 現在のナショナルセ ミコンダクタの 16550 のリビジョンはDです. p はパッケージタイプのフィールドです. タイプは以下 の通りです: "F" QFP (quad flat pack) L lead type "N" DIP (dual inline package) through hole straight lead type "V" LPCC (lead plastic chip carrier) J lead type 訳注: 具体的なパッケージ形状についての情報は http://www.national.com/packaging/plastic.html を参照 してください. g は製品グレードのフィールドです. もしパッケージタイ プの文字の前にIがあれば, 工業用グレード部品を表し, 標準 部品より高いスペックを持ちますが, Miltary 仕様 (Milspec) ほど高 くはありません. これは付加的なフィールドです. 私たちがかつて NS16550AFN (DIP パッケージ) と呼んでいたものは, 現在 は PC16550DN または PC16550DIN と呼ばれています. 他のベンダと類似の UART 長年に渡り, 8250, 8250A, 16450 そして 16550 はライセンスされ, または他のチップベンダにコピーされてきました. 8250, 8250A そして 16450 の場合は, そのものの回路 (megacell: LSIの中に組み込む ことのできるライブラリ化された回路の大規模な物) が Western Digital と Intel を含むたくさんのベンダにライセンスされまし た. 他のベンダは部品を リバースエンジニアリングした物か同じように 動作する互換品を製造しました. 内蔵モデムにおいては, モデム設計者はモデムのマイクロプロセッサで 8250A/16450 をエミュレートすることはよくおこなわれます. このエミュレート による (互換の) UART は数百バイトの隠れたバッファを持つでしょう. バッファのサイズのため, このような互換品は高速データ処理の能力では 16550A と変わらない信頼性を持つことができます. しかし, それでも ほとんどのオペレーティングシステムは UART は 8250A か 16450 である と報告し, 特殊なドライバが使用されなければ エミュレートによる UART の余分に存在する バッファリングの効果的な使用はおこないません. 幾つかのモデムメーカーは, 市場における競争を有利にするために数百バ イトのバッファを持ち 16550A の置き換えができるはずの設計を, たとえ 性能が低下する事になったとしても 棄てざるを得なくなるような市場の圧 力を受けています. 一般的にある誤解は, 16550A と書かれたすべての部品が同じ性能であると いうことです. それらは異なるものであり, 状況によってはまちがいなく 欠陥と呼べるものがこれらの 16550A クローンのほとんどにあります. NS16550 が開発された時に, ナショナル・セミコンダクタは設計に関する 幾つかの特許を取得し, 彼らはライセンスを制限して他のベンダが類似 の特徴を持つチップを供給することを困難にしました. 特許のため, リバー スエンジニアリングによる設計とエミュレーションは, 特許がカバーする 請求権を侵害を回避しなくてはなりませんでした. 結果として, これらの コピーのほとんどは, 多くのコンピュータとモデムのメーカーは支払いた くはない程の価格であった本物の部品の NS16550A または PC16550D とまった く同じような動作をさせることはできませんでした. 16550A のクローンに存在する相違点のうち いくつかは些細なものですが, そのほかに 特定のオペレーティングシステムやドライバでは 全然使いものにならないような相違が存在する場合もあります. あるドライバでは問題なく動作しても, 別のドライバを使用した場合には 問題が発生することもありますし, Windows のドライバにおいても 充分にテストや考慮がおこなわれなかったイベントの組合わせが 起こった場合には, これらの相違点が明らかになるかもしれません. これはほとんどのモデムベンダと 16550 クローンメーカーが, NS16550A との互換性のプライマリテストとして Windows for Workgroups 3.11 と Microsoft MS-DOS ユーティリティの Microsoft ドライバを使用しているか らです. この安易過ぎる規準は, もし異なるオペレーティングシステムが 使用されたらクローンと 本物の部品の微妙な違いのために問題が発生し得 る, ということを意味しています. ナショナル・セミコンダクタは, どんな OS のドライバからも独立した互 換性テストを実行する COMTEST という名前の入手可能なプログラムを作 成しました. このタイプのプログラムの目的は, 競合製品にある欠陥のデ モンストレーションであることをおぼえておくべきです. ですからそのプ ログラムは, テスト中の部品の動作の重要な問題と極めてささいな相違を 同じように報告するでしょう. この文書の著者が 1994 年に実行した一連のテストでは, ナショナルセミ コンダクタ, TI, StarTech そして CMD が製造した部品は megacell 及び COMTEST でテストされた内蔵モデムに埋め込まれたエミュレーションと同 等です. これらの部品の幾つかで注目される相違点を以下に示します. これらのテストは1994年に実行されたので, これらはベンダから供給さ れた製品の現在の性能には反映されないでしょう. 極端に多くの問題やあるタイプの問題が検出された場合に, COMTEST は通 常は実行を中止することに注意してください. このテストの一部では, たと え何回相違点に遭遇しても中止しないように COMTEST を修正しました. ベンダ 部品番号 報告された「相違点」として知られるエラー National (PC16550DV) 0 National (NS16550AFN) 0 National (NS16C552V) 0 TI (TL16550AFN) 3 CMD (16C550PE) 19 StarTech (ST16C550J) 23 Rockwell Reference modem with internal 16550 or an emulation (RC144DPi/C3000-25) 117 Sierra Modem with an internal 16550 (SC11951/SC11351) 91 この文書の著者は今まで, COMTEST プログラムを 使用して相違点がゼロと報告されるナショナル・ セミコンダクタ以外の部品を一つも発見しませんでした. ナショナル・セミコンダクタは長年に渡り 16550 の五つのバージョンを持っており, 最新の部品は 機能性のために, ベンチマークを考慮した古い NS16550AFN と少し異なる振る舞いをすることに 注意するべきです. COMTEST はナショナル・セミコンダクタの製品ラインの 相違点については見て見ぬふりをするようになり, 部品のリビジョン A, B そして C にあるバグが 記述されている公式な正誤表がある時でも, (オリジナルの 16550 を除いては) ナショナル・ セミコンダクタの部品についてエラーを 報告しなくなったので, この COMTEST のひいきを 考慮にいれるべきです. COMTEST からの相違点の単純なカウントが, 何の相違点が重要であり どれがそうでないのかについて 多くを明らかにしないことを 理解すること が大切です. 例えば, 内蔵の UART を持つ上記の二つのモデムで報告され た相違点の約半分が, 5及び6ビットキャラクタモードをサポートしないク ローンの UART によって引き起こされました. 本物の 16550, 16450 そし て 8250 UART すべてはこれらのモードをサポートし, COMTEST はこれらの モードの機能性をチェックするので, 50を越える相違点が報告されました. しかし, 5及び6ビットキャラクタモードを サポートするモデムは殆どなく, 特にこれらはエラー修正と圧縮機能付のものです. これは5及び6ビット キャラクタモードに関連した相違点は 差し引いて考えることができること を意味しています. COMTEST が報告した相違点の多くは, タイミングに関する点でしょう. 多くのクローンの設計では, ホストが一つのポートから読み込んだ時に他 のあるポートのステータスビットは, 本当の NS16550AFN と同じ 長さの時間内で更新されない (あるものは速く, あるものは遅く) かもしれ ませんが, COMTEST はこれらの相違点を探します. これは相違点の数は誤 解を招き易いものです. あるデバイスには一つか二つの相違点しかありま せんがそれらは非常に重大かもしれません. また別のデバイスは基準部品 と比べて速くまたは遅く status レジスタを更新するために (適切に書か れたドライバの操作にはまったく影響しないかもしれません) 多くの相違点を 報告されるかもしれません. COMTEST は問題を引き起こすかも知れない, または特殊なケースとして処 理しなければならない潜在的に矛盾した部品の存在に対して, 管理者に警 告を出すスクリーニングツールとして使用できます. もしモデムの中にある 16550 やシリアルポート接続されているモデムに 対して COMTEST を実行する場合, モデムがテストキャラクタをエコーし ないように最初に ATE0&W コマンドをモデムに発行する必要がありま す. これをおこなうことを忘れた場合, COMTEST は少なくともこの相違点を 報告するでしょう: Error (6)...Timeout interrupt failed: IIR = c1 LSR = 61 8250/16450/16550 のレジスタ 8250/16450/16550 UART は八つの連続する I/O ポートアドレスを予約 しています. IBM PC ではこれらの八つのポートに対して二つの定義された 位置があり, それらは集合的に COM1 と COM2 として知られています. PC クローンとアドオンカードのメーカーは COM3 と COM4 として知られる二つ の付加的な領域を作成しましたが, 幾つかのシステムではこれらの余分な COM ポートは他のハードウェアと衝突します. 最もよく起きるものは IBM 8514 エミュレーションを提供するビデオアダプタとの衝突です. COM1 には 0x3f8 から 0x3ff が割り当てられ, 通常 IRQ 4 が使用されます. COM2 には 0x2f8 から 0x2ff が割り当てられ, 通常 IRQ 3 が使用されます. COM3 には 0x3e8 から 0x3ef が割り当てられ, IRQ は標準化されていません. COM4 には 0x2e8 から 0x2ef が割り当てられ, IRQ は標準化されていません. 8250/16450/16550 UART のI/Oポートの詳細は以下に提供されています. I/O ポート 許可されたアクセス 説明 +0x00 write (DLAB==0) Transmit Holding Register (THR). このポートに書き込まれた情報は データ命令として 処理され, UART により送信されます. +0x00 read (DLAB==0) Receive Buffer Register (RBR). シリアル接続から UART によって受信されたすべての データ命令は, このポートを読むことによってホス トによりアクセスされます. +0x00 write/read (DLAB==1) Divisor Latch LSB (DLL) マスタ入力クロックの周波数を このレジスタに入っ ている値で割ることにより, UART の周波数が決定 されます (IBM PCでは, マスタクロックの周波数は 1.8432MHzです). このレジスタには上記の除数の下 位8ビットが入っています. +0x01 write/read (DLAB==1) Divisor Latch MSB (DLH) マスタ入力クロックの周波数をこの レジスタに入っ ている値で割ることにより, UART の周波数が決定 されます (IBM PCでは, マスタクロックの周波数は 1.8432MHzです). このレジスタには上記の除数の上 位8ビットが入っています. +0x01 write/read (DLAB==0) Interrupt Enable Register (IER) 8250/16450/16550 の UART はイベントを四つのカテ ゴリの一つに分類します. それぞれのカテゴリは設 定可能です. それぞれのカテゴリは, どんな類のイ ベントの発生時に割り込みを 生成するように設定可 能です. 8250/16450/16550 の UART は, 有効になっ ているカテゴリ内でいくつの イベントが発生してい るかに関わらず, 単一の外部割り込みシグナルを生 成します. 割り込みに応答し有効になっている割り 込みカテゴリ (通常すべてのカテゴリが有効になって いる割り込みを持ちます) を割り込みの本当の原因 を決定するためにポーリングするかは, ホストのプ ロセッサ次第です. Bit 7 予約済み, 常に 0. Bit 6 予約済み, 常に 0. Bit 5 予約済み, 常に 0. Bit 4 予約済み, 常に 0. Bit 3 Enable Modem Status Interrupt (EDSSI). このビットを「1」に設定することで, 一つ以上の状態ラインで変更が発生した時 に, UART が割り込みを生成可能となりま す. Bit 2 Enable Receiver Line Status Interrupt (ELSI) このビットを「1」に設定することで, 入っ てくるデータにエラー (または BREAK シ グナル) が検知された時に, UART が割り 込みを生成するようになります. Bit 1 Enable Transmitter Holding Register Empty Interrupt (ETBEI) このビットを「1」に設定することで, UART に送信される一つ以上の付加的な文 字に対する空きが生じた時に, UART が割 り込みを生成するようになります. Bit 0 Enable Received Data Available Interrupt (ERBFI) このビットを「1」に設定することで, UART が FIFO のトリガーレベルを越え る十分な文字を受け取るか, FIFO のタイ マが期限切れとなるか (古くなったデータ), FIFO が無効の場合にシグナル文字が受信 された時に, UART が割り込みを生成する ようになります. +0x02 write FIFO Control Register (FCR) (このポートは 8250 と 16450 の UART では 存在しません.) Bit 7 Receiver Trigger Bit #1 Bit 6 Receiver Trigger Bit #0この二つのビットは FIFO が機能している 場合にレシーバがどの時点で割り込みを生 成するかを制御します. 7 6 割り込み生成前にいくつの命令 が 受信されたか. 0 0 1 0 1 4 1 0 8 1 1 14 Bit 5 予約済み, 常に 0. Bit 4 予約済み, 常に 0. Bit 3 DMA Mode Select. Bit 0 が「1」 (FIFO 有効) に設定されて いる場合, このビットの設定は -RXRDY と -TXRDY の処理を Mode 0 から Mode 1 へ 変更します. Bit 2 Transmit FIFO Reset. このビットに「1」が書き込まれている場 合, FIFO の内容は破棄されます. 現在送 信されているすべての命令は損なわれずに送 られるでしょう. この機能は送信中止の場 合に役に立ちます. Bit 1 Receiver FIFO Reset. このビットに「1」が書き込まれている場 合, FIFO の内容は破棄されます. 現在 shift レジスタ内で組み立てられているすべ ての命令は損なわれずに受信されるでしょ う. Bit 0 16550 FIFO Enable. 設定されている場合, 送信 / 受信両方の FIFO が有効になります. holding レジス タ, shift レジスタまたは FIFO 内のすべて の内容は, FIFO が有効または無効になっ た時点で失われます. +0x02 read Interrupt Identification Register Bit 7 FIFO有効. 8250/16450 UART では, このビットはゼロ. Bit 6 FIFO有効. 8250/16450 UART では, このビットはゼロ. Bit 5 予約済み, 常に0. Bit 4 予約済み, 常に0. Bit 3 Interrupt ID Bit #2. 8250/16450 UART では, このビットはゼロ. Bit 2 Interrupt ID Bit #1 Bit 1 Interrupt ID Bit #0. これらの3つのビットは進行中の割り込み を引き起こしたイベントのカテゴリを併せ て報告します. これらのカテゴリは優先度 を持つため, イベントの複数のカテゴリが 同時に発生した場合, UART は最初に最も 重要なイベントを報告し, ホストは報告さ れた順に解決するでしょう. 現在の割り込 みを引き起こしたすべてのイベントは, 新し い割り込みが生成される前に解決されなけ ればなりません (これは PC のアーキテク チャの制限です). 2 1 0 優先度 説明 0 1 1 First レシーバエラー (OE, PE, BI, また FE) 0 1 0 Second 有効な受信データ 1 1 0 Second トリガーレベル識別子 (受信バッファ中の古いデータ) 0 0 1 Third トランスミッタに 命令用の空きがある (THRE) 0 0 0 Fourth モデムの状態が 変わった (-CTS, -DSR, -RI, または -DCD) Bit 0 Interrupt Pending Bit. このビットが「0」に設定されている場合, 少なくとも一つの割り込みがペンディング されています. +0x03 write/read Line Control Register (LCR) Bit 7 Divisor Latch Access Bit (DLAB). 設定されている場合, transmit/receive register (THR/RBR) と Interrupt Enable Register (IER) へのアクセスが無効にな ります. 現在これらのポートへのすべてのア クセスは Divisor Latch Register へリダ イレクトされます. このビットの設定, Divisor Register のローディング, そし て DLAB のクリアは割り込みが無効になっ ている状態でおこなわれるべきです. Bit 6 Set Break. 「1」に設定されている場合, トランスミッ タはこのビットが「0」に設定されるまで スペースを切り目なく送信します. これは 送信されている文字のすべてのビットに優先 します. Bit 5 Stick Parity. parity が有効になっている場合, このビッ トの設定はビット4の値に基づき parity を常に「1」か「0」にします. Bit 4 Even Parity Select (EPS). parity が有効でビット5が「0」の場合, このビットの設定は偶数 parity が送信そ して要求されるようにします. そうでなけ れば奇数 parity が使用されます. Bit 3 Parity Enable (PEN). 「1」に設定されている場合, データの最 後のビットとストップビットの間に parity ビットが挿入されます. また UART は受信データに存在する parity を要求す るでしょう. Bit 2 Number of Stop Bits (STB). 「1」に設定されている場合, 5-bit デー タ命令を使用して, 1.5の Stop ビットが 送信され各データ命令内に要求されま す. 6, 7 そして 8-bit データ命令に対し ては, 2つの Stop ビットが送信され要求 されます. このビットが「0」に設定され ている場合, 1つの Stop ビットが各デー タ命令で使用されます. Bit 1 Word Length Select Bit #1 (WLSB1) Bit 0 Word Length Select Bit #0 (WLSB0) これらのビットは共に 各データ命令内のビッ トの数を指定します. 1 0 命令長 0 0 5 Data Bits 0 1 6 Data Bits 1 0 7 Data Bits 1 1 8 Data Bits +0x04 write/read Modem Control Register (MCR) Bit 7 予約済み, 常に 0. Bit 6 予約済み, 常に 0. Bit 5 予約済み, 常に 0. Bit 4 Loop-Back Enable. 「1」に設定されている場合, UART のトラ ンスミッタとレシーバは診断処理のために 内部的に相互に接続されます. 付け加えて UART のモデム制御出力はモデム制御入力 に接続されます. CTS は RTS へ, DTR は DSRへ, OUT 1 は R1 へ, OUT 2 は DCD へ 各々接続されます. Bit 3 OUT 2. ホストのプロセッサが high または low に設定するであろう補助的な出力. IBM PC のシリアルアダプタ (とクローンの殆ど) では, OUT 2 は 8250/16450/16550 UART からの割り込み信号をハイインピーダンス (無効) にするのに使用されます. Bit 2 OUT 1. ホストのプロセッサが high または low に設定するであろう補助的な出力. IBM PC のシリアルアダプタではこの出力は使用 されません. Bit 1 Request to Send (RTS). 「1」に設定されている場合, UART の -RTS ラインの出力は Low (有効) となり ます. Bit 0 Data Terminal Ready (DTR). 「1」に設定されている場合, UART の -DTR ラインの出力は Low (有効) となり ます. +0x05 write/read Line Status Register (LSR) Bit 7 Error in Receiver FIFO. 8250/16450 UART では, このビットはゼロ です. FIFOの中に次のエラー条件が一つ以 上含まれている場合, このビットは「1」 に設定されます: PE, FE, または BI. Bit 6 Transmitter Empty (TEMT). 「1」に設定されている場合, 送信 FIFO または送信 shift レジスタ中に残ってい る命令はありません. トランスミッタは完 全に働いていません. Bit 5 Transmitter Holding Register Empty (THRE). 「1」に設定されている場合, 現在 FIFO (または holding レジスタ) には少なくと も一つの送信される付加的な命令に対する 空きあります. このビットが「1」に設定 されている時は, 多分トランスミッタはま だ送信しています. Bit 4 Break Interrupt (BI). レシーバは Break シグナルを検知しました. Bit 3 Framing Error (FE). Start ビットが検知されましたが, Stop ビットは要求された時間内には現れません でした. 受信された命令はおそらく勝手に 解釈されます. Bit 2 Parity Error (PE). parity ビットが受信された命令に対して 不正です. Bit 1 Overrun Error (OE). 新しい命令が受信され, 受信バッファに空 きがありませんでした. shift レジスタに 新たに到着した命令は破棄されます. 8250/16450 UART では, holding レジスタ 内の命令は破棄され新たに到着した命令は holding レジスタに置かれます. Bit 0 Data Ready (DR) 一つ以上の命令がホストが読むであろう受 信 FIFO にあります. このビットが設定さ れる前に, 命令は完全に受信され shift レジスタから FIFO (または 8250/16450 の設計では holding レジスタ) へ移動さ れなければなりません. +0x06 write/read Modem Status Register (MSR) Bit 7 Data Carrier Detect (DCD). UART の DCD ラインの状態を反映します. Bit 6 Ring Indicator (RI). UART の RI ラインの状態を反映します. Bit 5 Data Set Ready (DSR). UART の DSR ラインの状態を反映します. Bit 4 Clear To Send (CTS). UART の CTS ラインの状態を反映します. Bit 3 Delta Data Carrier Detect (DDCD). ホストによって MSR が最後に読み込まれ た時点から, -DCD ラインが状態を一回以 上変えた場合に「1」に設定されます. Bit 2 Trailing Edge Ring Indicator (TERI). ホストによって MSR が最後に読み込まれ た時点から, -RI ラインが low から high へ移り変わった場合に「1」に設定されま す. Bit 1 Delta Data Set Ready (DDSR). ホストによって MSR が最後に読み込まれ た時点から, -DSR ラインが状態を一回以 上変えた場合に「1」に設定されます. Bit 0 Delta Clear To Send (DCTS). ホストによって MSR が最後に読み込まれ た時点から, -CTS ラインが状態を一回以 上変えた場合に「1」に設定されます. +0x07 write/read Scratch Register (SCR). このレジスタは UART では機能しません. この場所 には どんな値でもホストによって書き込まれるこ とができ, その後ホストによって読み込むことが可 能です. 16550A UART を越えて ナショナル・セミコンダクタは付加的な機能を持つ 16550 と互換 性のある部品を提供していませんが, 色々な他のベンダがそれを持っ ています. これらの部品の幾つかは以下に記述されています. 効果的 にこれらの改良を使用するためには, 殆どのポピュラーなオペレーティ ングシステムが 16550 が提供する機能以上のものをサポートしない ため, ドライバはチップベンダから提供されなければならないことを 理解しておく必要があります. ST16650 デフォルトではこの部品は NS16550A と似ていますが, 拡 張された32バイトの送受信バッファを オプションで有効にで きます. StarTech により製造されました. TIL16660 デフォルトではこの部品は NS16550A と類似した振舞いを しますが, 拡張された64バイトの送受信バッファをオプショ ンで有効にできます. Texas Instruments により製造されま した. Hayes ESP この専売特許のプラグインカードは, 2048バイトの送受 信バッファを含み, 230.4Kbit/sec のデータレートをサポー トします. Hayes により製造されました. これらのダムUART に加え, たくさんのベンダがインテリジェ ントシリアルコミニュケーションボードを製造しています. こ のタイプの設計は通常マイクロプロセッサを提供しており, このマイ クロプロセッサは幾つかの UART へのインタフェースとなってデータ を処理 / バッファリングし, そして必要な時にメインの PC のプロセッ サへ警告を出します. UART はこのタイプのコミニュケーションシ ステムにおいて PC のプロセッサによって直接アクセスされないため, ベンダにとっては 8250, 16450, または 16550 UART と互換性のある UART を使用する必要はありません. これにより設計者は, より良い 性能特性を持つ部品が自由に利用できます. <devicename>sio</devicename>ドライバの設定 sio ドライバは, NS8250-, NS16450-, NS16550とNS16550A ベースの EIA RS-232C(CCITT V.24) 通信用インタフェースをサポートします. ま た, いくつかのマルチポートシリアルカードもサポートされています. 技術的 な詳細についてはマニュアル &man.sio.4; を見てください. Digi International (DigiBoard) PC/8 原作: &a.awebster;. 1995年8月26日. 訳: &a.jp.masaki;.6 September 1996. 以下にDigi International PC/8Dと16550チップを動作させるための, カーネ ルconfigの部分を示します. このボードは, 8本の回線にすべてモデムを接続 した場合でも良好に動作します. options COM_MULTIPORT を加えるのを忘れないでください. 忘れる とうまく動作しません! device sio4 at isa? port 0x100 tty flags 0xb05 device sio5 at isa? port 0x108 tty flags 0xb05 device sio6 at isa? port 0x110 tty flags 0xb05 device sio7 at isa? port 0x118 tty flags 0xb05 device sio8 at isa? port 0x120 tty flags 0xb05 device sio9 at isa? port 0x128 tty flags 0xb05 device sio10 at isa? port 0x130 tty flags 0xb05 device sio11 at isa? port 0x138 tty flags 0xb05 irq 9 vector siointr ここで各 SIO ポートが割り込みを共有する一つのグループであることを表現 するために, トリッキーな設定をしなければなりません. フラグ (flags の後 ろの 16 進数) の下から 2 バイト目にこのグループの最後の SIO ポートの番 号を設定します. この例では 11 (16進数では 0x0b) ですから, 各デバイスの フラグは 0xb05 となります. Boca 16 寄稿: &a.whiteside;. 1995年8月26日 FreeBSD で Boca 16pord のボードを動かすことは簡単ですが, そのた めにはいくつかの作業が必要です. : 2.0.5 のデフォルトのカーネルは, マルチポートのサポートをして いない ので, あなたは各ポート毎にデバイスエントリを追加する必要が あります. つまり必要なオプションを付けて, カーネルの再構築をしなければ なりません. そのためには, あなたのマシンにカーネルのソースコードが既に インストールされているか, あなたの替わりの誰かにカーネル再構築をやって もらう必要があります. 2番目に, あなたはカーネルオプションを正しく設定するために, あな たのBoca Boardの IO と割り込みの値を知っている必要があります. ひとつ重要なことがあります. Boca 16 に使われている実際の UART チップ は, Boca 16 のボードではなく, 外付けのコネクタボックスの中に存在します. コネクタボックスを接続しないと, ポートの検出に失敗するでしょう. 私は, 接続しないまま起動したり, 後から接続しなおしたりした時にどうなるかをテ ストしていません. どちらも実行しないようお奨めします. もしあなたがカスタマイズ済みのカーネル コンフィグレーションファイルを持っ ていなければ, 一般的な事柄については, FreeBSD カーネルのコンフィグレーション を参考にしてください. 以下にBoca 16のボード に関係する部分だけを記述します. この例では, あなたがMYKERNELという名前 のカーネルを使っていて, エディタには viを使っていることを仮定していま す. 次の1行をconfigファイルに追加してください. options COM_MULTIPORT この device sionという行を, 必要に応じて 16 個のデバイス分を追加してください. 最後のデバイスにだけ, このボード の割り込みベクタを記述します. (詳細は &man.sio.4; のマニュア ルページを参照してください.) 以下の例は, 割り込み 3, ベース IO アドレス 100h の値を持つ Boca Board の場合です. 各ポートのための IO アドレスは, 100h, 108h, 110h, ... のよ うに 16 進法で 8 づつ加えていきます. device sio1 at isa? port 0x100 tty flags 0x1005 device sio2 at isa? port 0x108 tty flags 0x1005 device sio3 at isa? port 0x110 tty flags 0x1005 device sio4 at isa? port 0x118 tty flags 0x1005 … device sio15 at isa? port 0x170 tty flags 0x1005 device sio16 at isa? port 0x178 tty flags 0x1005 irq 3 vector siointr フラグエントリは, あなたが全く同じsioの割り当てを使っていない限り 必ず 上記の例から変更してください. フラグは, 次のように設定します. 0x M YY のMは, マスタポート (Boca 16に搭載された最後 のポート)のマイナー番号を指定します. さらに YY の部分はFIFOが 有効または無効であること (この場合は有効), 割り込みを (ボード内で) 共 有しているか (この場合はYES), そして, AST/4 と互換性のある持つ割り込み 制御レジスタを持っているか (この場合はNO) を指定します. この例では, flags 0x1005 というフラグによって, マスタポートが sio16 であることを示します. も し同じボードをもう一枚追加し, sio17 から sio28 を割り当てるなら, 新しい方の ボードに対応する 16 個のポートのフラグはすべて 0x1C05 に なります. 28 (== 0x1C) は新しいボードのマスタポートのマイナー番号で す. フラグの 05 の部分は変更しないでください. カーネルコンフィグレーションファイルを 保存してカーネルの設定を完了しま す. カーネルをコンパイル後, インストールし, 新しいカーネルでリブートし てください. 再コンパイルされたカーネルがうまくインストールされて, そのカーネルに正 しいアドレスと割り込みが設定されていたならば, ブートメッセージは次の ように Boca ポートの検出に成功するはずです: (sioの番号, IOとIRQの値は, この例とは異なっているでしょう) sio1 at 0x100-0x107 flags 0x1005 on isa sio1: type 16550A (multiport) sio2 at 0x108-0x10f flags 0x1005 on isa sio2: type 16550A (multiport) sio3 at 0x110-0x117 flags 0x1005 on isa sio3: type 16550A (multiport) sio4 at 0x118-0x11f flags 0x1005 on isa sio4: type 16550A (multiport) sio5 at 0x120-0x127 flags 0x1005 on isa sio5: type 16550A (multiport) sio6 at 0x128-0x12f flags 0x1005 on isa sio6: type 16550A (multiport) sio7 at 0x130-0x137 flags 0x1005 on isa sio7: type 16550A (multiport) sio8 at 0x138-0x13f flags 0x1005 on isa sio8: type 16550A (multiport) sio9 at 0x140-0x147 flags 0x1005 on isa sio9: type 16550A (multiport) sio10 at 0x148-0x14f flags 0x1005 on isa sio10: type 16550A (multiport) sio11 at 0x150-0x157 flags 0x1005 on isa sio11: type 16550A (multiport) sio12 at 0x158-0x15f flags 0x1005 on isa sio12: type 16550A (multiport) sio13 at 0x160-0x167 flags 0x1005 on isa sio13: type 16550A (multiport) sio14 at 0x168-0x16f flags 0x1005 on isa sio14: type 16550A (multiport) sio15 at 0x170-0x177 flags 0x1005 on isa sio15: type 16550A (multiport) sio16 at 0x178-0x17f irq 3 flags 0x1005 on isa sio16: type 16550A (multiport master) もしメッセージの表示が速くて読み取れないときは, &prompt.root; dmesg | more とするとブート時のメッセージを ゆっくり見ることができます. 次に, root になってから, デバイスにあわせたエントリを /dev/MAKEDEV スクリプトを使って/dev に追加します. &prompt.root; cd /dev &prompt.root; ./MAKEDEV tty1 &prompt.root; ./MAKEDEV cua1 (中略) &prompt.root; ./MAKEDEV ttyg &prompt.root; ./MAKEDEV cuag もし, 何らかの理由で発信するデバイスが不要な場合, cua* デバ イスを作らないで済ますこともできます. デバイスが確実に動作しているかどうか 確認する手っ取り早い方法は, あなたが (rootになって) 各ポートにモデムを接続してみて, あなたが作成し た各デバイス毎に &prompt.root; echo at> ttyd* とやってみてください. 各ポー トが動作していれば RXの表示が光るのが見えるはず です. 安価な Multi-UART カードのサポート 寄稿: Helge Oldach hmo@sep.hamburg.com, September 1999 二つ(またはもっと多くの) COM ポートを備えた 20$ のマルチ I/O カードでの IRQ 共有が, FreeBSD でサポートされているか心配ですって? 次のようにすれば使うことができます. 通常, この種のボードをサポートする場合には, 各ポートに対して個別に IRQ を割り当てて利用します. 例えば, マザーボード上に COM1 ポート (sio0–I/O アドレス 0x3F8, IRQ 4) があり, 二つの UART ポートがついている拡張カードがあるとしましょう. その場合, この二つのポートには, 二番目のポートを COM2(sio1–I/O アドレス 0x2F8, IRQ 3) に, 三番目のポート(sio2)を I/O アドレス 0x3E8, IRQ 5 に設定する必要があります. しかしすぐわかるとおり, この方法では IRQ 資源を無駄に浪費します. 基本的に前セクションに記されている COM_MULTIPORT の設定に従えば, 拡張カード上の二つのポートで一つの IRQ を使用するように セットアップすることができます. そのような安価な I/O ボードには大抵, 次に示すような, COM ポートを選択する 4x3 のジャンパマトリクスがついています. o o o * Port A | o * o * Port B | o * o o IRQ 2 3 4 5 これは, Port A が IRQ 5 に, Port B が IRQ 3 に結線されていることを示しています. IRQ の並びはボードにより異なるでしょう—例えば, 他のボードは IRQ として 3,4,5,7 が選択できるようになっているかも知れません. 「ああ, IRQ を共有するには IRQ 3 の列にある 3 つの接続点をつなぐようなジャンパ線を手作りして, 両方のポートが IRQ 3 になるように結線すれば良いのか」と 考えるかも知れませんが, それは正しくありません. UART の出力段は トーテムポール 接続(*)されているので, IRQ 3 に複数接続することはできないのです. そのため, もし UART のどれか一つが IRQ 3 を発行したとしても, それが期待するような動作になりません. 拡張ボードやマザーボードの実装に依存することですが, IRQ 3 信号線は常時 H レベルか, L レベルを保っています. 訳注: トーテムポール とは, ディジタル論理回路を構成する TTL ロジック IC の内部構造の一種です. トーテムポール型出力の場合には 出力同士を接続すると短絡電流が流れてしまうため, CPU やメモリで使われている, いわゆるバス接続が使えないという特徴を持っています. IRQ 信号線が常時 H か L レベルに保たれる, というのは, 割り込み信号線が正論理/負論理のどちらになっているかが実装に依存することによります. 以降の解説は, 正論理を仮定して書かれていますのご注意下さい. したがって, 二つの UART の IRQ 出力を分離する必要があります. そのためには, どちらかの UART が IRQ を発行した時にだけ, ボード上の IRQ 信号線が H レベルになり, そうでない時には L レベルになるようにします. 以下の解決法は, Joerg Wunsch j@ida.interface-business.de から提案されたものです: 二つのダイオード(ゲルマニウム, あるいはショットキー型を強く推奨)と 1 キロオームの抵抗器一本で, ワイヤード OR を構成します. 以下に示すのは, 上に示した 4x3 ジャンパの回路図です. Diode +---------->|-------+ / | o * o o | 1 kOhm Port A +----|######|-------+ o * o o | | Port B `-------------------+ ==+== o * o o | Ground \ | +--------->|-------+ IRQ 2 3 4 5 Diode 各ダイオードのカソード側は接地点に, 1 キロオームのプルダウン抵抗器と直列にして接続します. プルダウン抵抗を接続することはとても重要です. これはバス上の IRQ 信号線がフロート状態になるのを防ぎます. さあ, これでカーネルの設定を変更する準備ができました. 上に示すような例の場合, 次のような設定になります. # standard on-board COM1 port device sio0 at isa? port "IO_COM1" tty flags 0x10 # patched-up multi-I/O extension board options COM_MULTIPORT device sio1 at isa? port "IO_COM2" tty flags 0x205 device sio2 at isa? port "IO_COM3" tty flags 0x205 irq 3 sio1 と sio2 の flags 設定は非常に重要です. 詳細は &man.sio.4; をご覧ください. (一般的には, "flags" 属性の 2 は, sio2 の IRQ を使用するということを示します. 下位ニブル(訳注: 16 進数一桁のこと) は間違いなく 5 とするでしょう.) カーネルの verbose モードが ON になっていると, こんな風な出力が得られます. sio0: irq maps: 0x1 0x11 0x1 0x1 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1: irq maps: 0x1 0x9 0x1 0x1 sio1 at 0x2f8-0x2ff flags 0x205 on isa sio1: type 16550A (multiport) sio2: irq maps: 0x1 0x9 0x1 0x1 sio2 at 0x3e8-0x3ef irq 3 flags 0x205 on isa sio2: type 16550A (multiport master) /sys/i386/isa/sio.c は irq maps 配列を使っているために 表示が少々難解なのですが, 基本的なアイデアは 1,3,4 番目の場所に 0x1 があるかどうか調べる, というものです. これはつまり, 対応する IRQ が出力された時にセットされ, その後クリアされるという, ちょうど期待する動作が 行なわれることを意味します. もし, カーネルがこのような表示を出力しない場合, 大部分は結線の誤りによるものでしょう. <devicename>cy</devicename> ドライバのコンフィグ 原作: Alex Nash. 6 June 1996. 訳: &a.jp.yuki;. 6 September 1996. Cyclades 社のマルチポートカードは, 他のマルチポートカードが 使う sio の代わりに cyドライバを使います. コンフィグレーションは非常に簡単で, cy デバイスをあなたの カーネルの コンフィグレーションに足します. (注意. あなたのirqやiomemの設定が違っているかもしれません) device cy0 at isa? tty irq 10 iomem 0xd4000 iosiz 0x2000 vector cyintr 新しいカーネルの 再構成と インストール をします. デバイスノード を次(8ポートと仮定しています.) のように打って作ります: &prompt.root; cd /dev &prompt.root; for i in 0 1 2 3 4 5 6 7;do ./MAKEDEV cuac$i ttyc$i;done もし, 必要なら シリアルデバイス (ttyd) とそっくりにコピーして dialupエントリを作り, ttydの代わりに ttycを使います. 例: ttyc0 "/usr/libexec/getty std.38400" unknown on insecure ttyc1 "/usr/libexec/getty std.38400" unknown on insecure ttyc2 "/usr/libexec/getty std.38400" unknown on insecure … ttyc7 "/usr/libexec/getty std.38400" unknown on insecure 新しいカーネルで立ち上げます. <devicename>si</devicename> ドライバのコンフィグ 原作 &a.nsayer;. 25 March 1998. 訳: &a.jp.yoshiaki;. 29 Apr 1999. マルチポートカードのSpecialix SI/XIO と SX は si ドライバを使います. 1台のマシンで4枚までのホストカードを使うことが できます. 以下のホストカードがサポートされています: ISA SI/XIO host card (2 versions) EISA SI/XIO host card PCI SI/XIO host card ISA SX host card PCI SX host card SX と SI/XIO ホストカードは明らかに違いがあるように見えますが これらの機能は基本的には同じものです. ホストカードはI/O空間を 利用しませんが, 代りに32Kブロックのメモリ空間を使います. ISAカードの工場出荷時の設定は0xd0000-0xd7fff です. これらはIRQを必要とします. PCIカードではもちろん自動設定されます. ホストカードには最大4個の外部モジュールが接続できます. 外部モジュールにはそれぞれ4/8本のシリアルポートが内蔵されています. モジュールは以下の品種があります. SI 4 ポート/ポート モジュール. ポートそれぞれ 最大 57600 bps がサポートされます. - XIO 8 ボートモジュール. ポートそれぞれ最大 + XIO 8 ポートモジュール. ポートそれぞれ最大 115200 bps がサポートされます. XIOモジュールには 7 シリアルポートと1 パラレルポート のタイプもあります. SXDC, 8ポートモジュール. ポートそれぞれ最大921600 bps がサポートされます. XIOと同様, 1つのパラレルポートを持つモデルがあります. ISA ホストカードを設定するには以下の行を カーネルコンフィグレーション ファイルに追加します. 数値は適当なものに変更してください. device si0 at isa? tty iomem 0xd0000 irq 11 有効なIRQ番号は SX ISA ホストカードでは 9, 10, 11, 12, 15 で SI/XIO ISAホストカードでは 11, 12, 15 です. EISAやPCIカードの設定は, 以下の行を使います: device si0 コンフィグレーションエントリを追加した後で, 新しいカーネルの 再構築とインストール を行ないます. 新しいカーネルで再起動した後に, デバイスノード を /dev 以下に 作成する必要があります. MAKEDEVスクリプト で注意深く行なってください. 利用するポートの数をタイプします: &prompt.root; cd /dev &prompt.root; ./MAKEDEV ttyAnn cuaAnn (nn はポートの数に置き換えます. login プロンプトにこれらのポート番号を表示させたい場合 は/etc/ttys に以下の行を追加する必要があります: ttyA01 "/usr/libexec/getty std.9600" vt100 on insecure ターミナルタイプは適当なものに変更してください. 例えばモデムの場合はdialup あるいは unknownが適当でしょう. * パラレルカード * モデム * ネットワークカード * キーボード マウス 寄稿: Joel Sutton jsutton@bbcon.com.au, 2000 年 1 月. FreeBSD は PS/2 ポート, シリアルポート, USB ポートを経由して様々な種類のマウスをサポートしています. mouse デーモンを使うとマウスを X とシステムコンソールの両方で利用することができるため, 多くの人は mouse デーモンを使うことを選んでいます. mouse デーモンに関する詳細は, &man.moused.8; を参照してください. この章の例では, mouse デーモンが使われていることを前提にしています. この節に書かれている各種製品の名前は, 著者が FreeBSD 上で 動作することを確認したものであり, ここに書かれていない他の同様のデバイスも動作する可能性があります. PS/2 マウス システム設定 PS/2 マウスが mouse デーモンで正しく機能するように設定するには, 以下の行を /etc/rc.conf に加える必要があります. moused_enable="YES" moused_type="ps/2" moused_port="/dev/psm0" 利用できることが分かっている機器 Logitech First Mouse - 3 ボタン マイクロソフト社製シリアル-PS/2 互換マウス シリアルマウス システム設定 シリアルマウスが mouse デーモンで正しく機能するよう設定するには, 以下の行を /etc/rc.conf に加える必要があります. この例では, マウスが COM1: に接続されていて, そのマウスが mouse デーモンによって自動的に認識されることを前提としています. moused_enable="YES" moused_type="auto" moused_port="/dev/cuaa0" 特定の種類のシリアルマウスで mouse デーモンを使用する設定に関しては, &man.moused.8; にある詳細な説明をご覧ください. 利用できることが分かっている機器 一般的なマイクロソフトマウス互換品 Logitech First Mouse - 3 ボタン マイクロソフト社製シリアル-PS/2 互換マウス USB システム設定 USB デバイスドライバは比較的最近 FreeBSD に追加されたもので, まだ GENERIC カーネルには含まれていません. 以下の手順は, 典型的なシステムで関連するドライバをいかに組み込むかという一例です. ums デバイスをあなたの カーネルコンフィグレーション の usb セクションに追加します. たとえば, 次のようにします. controller usb0 controller uhci0 device ums0 新しいカーネルを 再構築してインストールします. デバイスノード(device node) を作ります. それには, 以下のように入力します: &prompt.root; cd /dev &prompt.root; sh MAKEDEV ums0 以下の内容を /etc/rc.conf に追加し, mouse デーモンが正しく動作するように設定します. moused_enable="YES" moused_type="auto" moused_port="/dev/ums0" システムを再起動します. &prompt.root; shutdown -r now 利用できることが分かっている機器 Logitech TrackMan - Marble Wheel * その他 ]]> 記憶装置 ESDIハードディスクの使い方 原作および Copyright © 1995, &a.wilko;. 24 September 1995. 訳: &a.jp.ts; 2 September 1996. ESDIとは Enhanced Small Device Interfaceの略語です. この技術は, 馴染み 深い ST506や ST412といったインタフェースに基づくものであり, 世界初の普 及型 5.25インチのウィンチェスタディスクを造ったSeagate Technology社に よって最初に作られました. ESDIの Eは拡張 (Enhanced) を表しており, 実際そのとおりです. まず, イン タフェースの速度は速く, 10 ないし 15Mビット/秒であり, ST412インタフェー スに接続したドライブの 5Mビット/秒よりも高速です. また, 上位レベルのコ マンドがいくつか追加されて, オペレーティングシステムレベルのドライバ作 成者にとって, ESDIインタフェースはある程度インテリジェントなものとなり ました. ただし SCSIほどにインテリジェントではありません. ESDIは ANSIが 標準化をおこなっています. トラックごとのセクタ数を増やすことで, ESDIドライブの記憶容量は引き上げ られました. 通常, トラックあたり 35セクタですが, 今までに筆者がみたド ライブの中で大容量のものは, トラックあたり 54セクタもありました. ESDIは IDEや SCSIといったインタフェースの普及によって消えつつあります が, 無料あるいは在庫処分の 格安なドライブが入手可能であることを 考えると, 少ない (もしくは現状の) 予算で縛られたシステムにとって, ESDIドライブは 理想的です. ESDIのコンセプト 物理的な接続 ESDIインタフェースでは, ドライブごとに2つのケーブルを接続します. 第 1 のケーブルは34ピンのフラットケーブルエッジコネクタで, コントローラとド ライブ間のコマンドおよびステータスの 両信号のやりとりのためのものです. コマンド用ケーブルは, すべての ESDIドライブをデイジーチェーンで結び ますから, すべてのドライブを接続したバスを構成することに なります. 第 2 のケーブルは 20 ピンのフラットケーブル エッジコネクタで, ドライブへの データ入出力に使います. このケーブルは放射状に接続しますから, ドライブ ごとにコントローラへの専用接続を持つことに なるわけです. 筆者の経験によれば, PC向け ESDI コントローラには, コントローラあたり最 大 2 台までのデバイス接続が可能という制限がありました. これは, ドライ ブのアドレス割り当てのために, 単一ビットだけを用意したという WD1003 か ら持ち越された互換 (?) 機能なのだと思われます. デバイスのアドレス指定 1本のコマンドケーブルには最大で 7つのデバイスと 1つのコントローラを接 続することができます. どのドライブをコントローラがアドレスしているのか を個別に認識できるようにするために, ESDIデバイスは, デバイスアドレスを 設定するためのジャンパかスイッチを備えています. PC向けコントローラでは, 最初のドライブにはアドレス0を設定し, 第2番目の ディスクへはアドレス1を設定します. いつも留意すべきことは, ディスクごとに固有のアドレスを必ず設定するということです! つまり, コン トローラあたり最大2台のドライブというような PC向けのものでは, 第1 ドラ イブは第0番ドライブで, 第2ドライブは第1番ドライブだということです. ターミネート処理 (termination) デイジーチェーン接続用コマンドケーブル (34ピンのケーブルであることを覚 えていますか? ) では, 最後のチェーン接続ドライブでターミネートしなけれ ばなりません. このために, ESDIドライブにはターミネート用抵抗ネットワー クが付属しており, ターミネートする必要がないときにはその抵抗をドライブ から外したり, またはジャンパで無効 (disable) にすることができるようになっ ています. したがって, ひとつのドライブ, すなわちコマンドケーブルの最終端に位置す るドライブだけが, そのターミネート用抵抗を有効 (installまたは enable) にすることができます. コントローラは自動的にコマンドケーブルのもう一方 の端のターミネート用抵抗を有効にします. ご注意いただきたいのは, コント ローラは必ずコマンドケーブルのいずれかの 端に位置しなければならず, けっ して途中に位置するようにしては いけない ということです. ESDIディスクの FreeBSDでの使い方 ESDI を初めて動かすようにすることが, どうしてこうも大変なことなのでしょ うか ? ESDIディスクを FreeBSD で動かそうと試みた人たちが激烈なイライラを募らせ たことは知られています. 今までまったく ESDIを知らない場合には, 複数の 要因の組み合わせが悪く働いて, ESDIへの理解を妨げることになるかもしれま せん. このことは, ESDIと FreeBSDの組み合わせは選んではいけないという俗説も生 み出しました. 以下の節において, 落し穴のすべてとその解決策を 述べてみようと思います. ESDI速度の違い すでに簡単に紹介したように, ESDIは2種類の速度を持っています. 旧式のド ライブとコントローラは 10Mビット/秒のデータ転送速度ですが, 新しいもの では 15Mビット/秒が利用できます. 仮に 10Mビット/秒のコントローラへ 15Mビット/秒のドライブを接続したよ うな場合に問題が生じることを予想することは簡単です. したがって必ず, コ ントローラ および ドライブのマニュアルを参照して, それぞれの 転送速度が 一致しているかどうかを調べるようにしてください. トラックについて 主流の ESDIドライブは, トラックあたり34ないし36個のセクタを持ちます. しかし大部分の (古い) コントローラは36個以上のセクタを扱うことができま せん. 新しい大容量のドライブでは, トラックごとにさらに多くの数のセクタを持つ ことができます. たとえば筆者の 670MBのドライブは, トラックあたり 54セ クタも持たせることができます. 筆者のコントローラは 54 セクタ数をサポートしていませんでしたが, トラック あたり 35 セクタという設定で, 問題なく動作しました. しかし, これが意味す るのは大量のディスク容量を失うということです. もう一度, 詳しい情報についてハードウェアのドキュメントを 調べてください. この例のような仕様からはずれた設定をしたときには, うまく動くかもしれま せんが, 動かないこともあります. そのようなときには, 別のより多くの機能 をもつコントローラで試してみるようにしてください. ハードセクタとソフトセクタ 多くの ESDIドライブでは, ハードセクタまたはソフトセクタによる処理を, ジャンパ設定で指定することができます. ハードセクタとは, 新しいセクタの 開始位置において, ESDIドライブにセクタパルス (sector pulse) を発生させ ることです. コントローラはこのパルスを利用して, 書き込みや読み取りのタ イミングを指示します. ハードセクタではセクタのサイズを選ぶことができます (通常はフォーマット 後セクタあたり256, 512, および1024バイト). FreeBSDは512バイトのセクタ サイズを使います. トラックあたりのセクタ数は, 同じように選択に幅があり ますが, フォーマット後のセクタのバイト数はすべて同じです. セクタごとの 未フォーマット のバイト数は, コントローラがどの程度の調整用の バイト数を必要とするかによって異なります. トラックあたりのセクタ数を多 くすれば記憶容量は増えますが, もしドライブから与えられるバイト数よりも 多くのものをコントローラが必要とするのであれば, 問題を生じることがあり ます. ソフトセクタでは, コントローラ自身が読み書きの始まりと終りの位置を決め ます. なお, ESDI (筆者が知り得たものすべて) では, ハードセクタがデフォ ルトのようです. ソフトセクタを試みる必要性は感じたことがありません. 通常, FreeBSDをインストールする以前に, まずセクタ処理の設定を試される ことをおすすめします. というのも, セクタ処理の設定を変えるたびに, 物理 フォーマット (low-level format) をしなければならないからです. 物理フォーマット処理 ESDIドライブは, 使い始める前に, 物理フォーマットをおこなう必要があります. もしトラックあたりのセクタ数を変えたり, ドライブの物理的な設置方法 (水 平や垂直方向) を変えたときには, ふたたびフォーマットする必要があります から, よく検討した後でフォーマットしてください. フォーマット処理の所要 時間を短く予想してはいけません. 大容量のディスクでは数時間を要します. 物理フォーマットが終わったならば, サーフィススキャン (surface scan) を おこない, バッドセクタの検出とフラグの処理をします. ほとんどのディスクには, メーカが作成したバッドブロックリストを 記録した用紙またはステッカーが付 いています. さらに, ほとんどのディスク内にもバッドブロックリストが記録 されています. メーカが作成したリストを利用するようにしてください. この 時点で不良部分をマップし直す方が, FreeBSDのインストール後におこなうよりも, はるかに簡単です. 物理フォーマットプログラムのなかでも, トラックの中にひとつでもバッドセ クタがあれば, 同じトラック内の残りのすべてのセクタを不良とするようなプ ログラムがありますから, そのようなものは利用しないようにしてください. ディスクスペースの浪費だけでなく, より重大な bad144と関連した悲劇の原 因にもなるからです (bad144の節を参照のこと). トランスレーション トランスレーションが, ESDIだけに限定された問題ではないにもかかわらず, 重大な困難になることがあります. トランスレーションにはいくつかの側面が あります. 多くに共通なものは, IBM PC/ATのオリジナルの設計に起因するディ スクジオメトリに関する制限を, うまく回避するような調整を試みるものです (IBM に感謝 ! ). まずはじめに, 1024シリンダに関する (悪) 名高い制限があります. すなわ ち, ブート可能なシステムについて, システム関連ファイルは (オペレーティ ングシステムがどのようなものであっても) , ディスクの先頭部分の 1024シ リンダ内になければいけない, という制限です. シリンダ番号を表すためには 10ビットしか与えられていません. セクタの総数については, 上限は 64 (0か ら 63) です. この1024シリンダの制限を, 16ヘッドの制限 (これも ATの仕様 による) と組み合わせると, かなり限定されたディスク容量しか利用できませ ん. この難点を解消するために, PC 向け ESDIコントローラのメーカは, 自社のコ ントローラボードへ BIOS PROM拡張を施しました. この BIOS拡張の内容は, ブート時のディスクI/Oを (OSによっては すべて のディスクI/Oも) , トランスレーションを用いておこなうというものです. すなわち, 大容量のディ スクを, あたかも 32 ヘッドかつトラックあたり 64 セクタであるようなデバイス として OSへ知らせるのです. この結果, 総シリンダー数は 1024よりも少なく なりますから, 上記の難点などなかったものとして大容量ディスクを使うこと ができるようになります. なお, 注目いただきたいことは, FreeBSDカーネル の起動以降, FreeBSDはこの BIOS拡張機能を使わないということです. 詳しく は後ほどご説明いたします. トランスレーションの第 2 の存在理由は, 多くの旧いシステムBIOSが, トラッ クあたり 17 セクタのドライブだけしか扱えない (ST412 という古い仕様) から, というものです. 比較的新しい BIOSは通常, 自由な値を設定できるドライブ タイプ (多くの場合ドライブタイプ47) を持っています. この文書を読み終えられた後で, どのようにトランスレーションを利用す るにせよ, ぜひご留意いただきたいことがあります. もし複数の OSをひとつ のディスクにインストールするときには, 必ず同じトランスレーションを使わ なければなりません. トランスレーションに関して, 筆者が使用したコントローラは, ひとつのドラ イブを複数のパーティションに論理的に 分けることができる機能を BIOS のオ プションとして持っていました (このような製品はいくつかあると思われる). しかし, ひとつのドライブにはひとつのパーティションに限定しました. なぜ なら, このコントローラはパーティション情報を ディスクへ書き出すからです. つまり, 電源を入れると, コントローラはこの情報を読み取り, OSに対してディ スクから読みとった情報に基づくデバイスとして 知らせるからです. 代替セクタ処理 多くの ESDI コントローラはバッドセクタを 取り替える機能を備えています. ディスクの物理フォーマット処理の途中もしくは終了時に, バッドセクタであ ることを記録して, 代わりのセクタを壊れたセクタの位置へ (論理的に) 置き ます. 通常この置き換え処理は, トラック内の N-1 個のセクタを実際のデータ記録に 使い, 第N番目のセクタだけを代替セクタとすることで実現します. ここでNと いう値はトラック内の物理的セクタの総数です. このアイデアが生まれた背景 は, オペレーティングシステムが壊れたセクタを持たない 「完全」 なディスク を想定している, というものです. しかし FreeBSDではこのアイデアを使うこ とはできません. 理由は, 使用不可 (bad) から 使用可能 への変換をおこなう のが ESDIコントローラ上の BIOSだからなのです. FreeBSDは, 真の 32ビット のオペレーティングシステムであるために, ブート後には BIOSを使いません. 代わりに FreeBSDが使うのは, ハードウェアと直接「対話」するデバイスドラ イバというものです. 結論: 代替セクタ処理やバッドブロックマッピングなど, コントローラ・ メーカがなんと呼ぶかは判りませんが, それらに似た機能を FreeBSDのディス クへは使わないでください. バッドブロックの取り扱い 前節から残された問題があります. すなわち, コントローラによるバッドブロッ ク処理は利用できない状況であるにもかかわらず, FreeBSDのファイルシステ ムが想定しているのはあくまで完全無欠なディスクである, という問題で す. これを解消するために, FreeBSDは bad144 というツールを採用 しています. この bad144 (この名前は DEC社の標準となったバッドブロック 処理に由来している) は, FreeBSDのスライスごとにバッドブロックを調べま す. バッドブロックを見つけ出すと, bad144 は傷ついたブロック番号によるテー ブルを FreeBSDスライスの末尾へ書き込みます. ディスクが動作し始めると, ディスクから読みとられたテーブルを基に, ディ スクアクセスを調べます. この bad144 リストに記録されたブロック番号への 要求が起こると, 代わりのブロック (同じく FreeBSDスライスの末尾に位置す る) を使います. このように, bad144 による置換手続きによって 「完全」 なディ スクを FreeBSD ファイルシステムへ提供しているのです. bad144 の使用により陥るかもしれない落し穴があります. まず, ひとつのス ライスには 126 個以上のバッドセクタを持てません. もしドライブに 126 個以上 のバッドセクタがあったときには, 複数の FreeBSD のスライスに分けて, 各ス ライスのバッドセクタが 126 個以下となるようにする必要があります. くれぐ れも, ひとつのトラック内にたったひとつの欠陥セクタが 見つかっただけで, そのトラック内セクタ すべて を傷ついたものとして記録するよう な物理フォーマットプログラムを使わないようにしてください. 簡単にお解り いただけると思いますが, このような物理フォーマットをおこなえば, 126個の制 限は短時間で達成してしまいます. 次に, もしスライスが root ファイルシステムを含んでいるときには, 1024シ リンダ以内という BIOSの制限を守っていなければなりません. ブート処理の ときですから, bad144 リストは BIOS を使って読み取りますので, このリスト が 1024 シリンダ限界以内に位置していなければ読みとれません. この制限は root ファイルシステム だけ が1024シリンダ限界以内にあれば十分ということではなく, rootシステムを含 んだ スライス 全体が1024シリンダ限界以内におさまっている必要 があります. カーネルのコンフィグレーション ESDIディスクを扱うドライバは, IDEや ST412 MFMディスクなどと同じ wd ドライバです. この wd ドライバは, すべての WD1003 互換インタフェースにも利用できるはずです. 大部分のハードウェアは, ジャンパの設定によって, ふたつの I/Oアドレス範 囲と IRQ 値のうちから, それぞれひとつを選ぶことができます. したがって, wd タイプのふたつのコントローラを ひとつのシステムで使うことができます. もし設定しようとしているハードウェアが 標準以外の割り当てをサポートして いれば, 適切な設定情報をカーネルのコンフィグレーションファイルに 記述す ることで, この非標準割り当てを利用できます. 次にカーネルのコンフィグレー ションファイルの例を示します (このファイルがあるディレクトリは /sys/i386/conf である). # First WD compatible controller controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr disk wd0 at wdc0 drive 0 disk wd1 at wdc0 drive 1 # Second WD compatible controller controller wdc1 at isa? port "IO_WD2" bio irq 15 vector wdintr disk wd2 at wdc1 drive 0 disk wd3 at wdc1 drive 1 ESDIハードウェアの例 Adaptec 2320コントローラ 筆者は, ACB-2320でコントロールされた ESDIディスクへ, FreeBSDをインストー ルすることができました. なお, このディスクには他のオペレーティングシス テムをインストールしていません. インストールするために, まず, NEFMT.EXE (www.adaptec.com から ftp可能) でディスクを物理フォーマットし, かつトラックを代替セ クタとともにフォーマットするかどうかの設問に NOと答えました. また ACB-2320の BIOSは使わないように設定しました. そしてシステム BIOSがブー トできるように, システム BIOSの自由に設定可能 オプションを使いまし た. 実は, NEFMT.EXEを使う以前に, まず ACB-2320 の BIOSに組み込まれているフォー マットプログラムでディスクをフォーマットしてみましたが, 使えないことが 判りました. なぜなら, 代替セクタの処理をおこなわないようにするオプションが 用意されていないからです. 代替セクタ処理をおこなうようにすると, FreeBSDの インストール作業は bad144の実行の段階で失敗しました. もし ACB-232xy をお持ちであれば, そのバージョン番号に注意してください. 文字 x には 0 か 2 が入りまして, ボード上にフロッピーコントローラがあるかど うかを見分けることができます. 文字 yはさらに興味深いもので, ブランクか, A-8か, または Dのいずれかで す. ブランクは, 単純な10Mビット/秒のコントローラであることを表します. A-8は, 15Mビット/秒のコントローラで, かつ 52セクタ/トラックをサポート しているものであることを表します. Dは, 15Mビット/秒のコントローラで, かつ 36セクタ/トラック以上 (52セクタも可能か?) のドライブをサポートし ているものであることを表します. このコントローラのすべてのバージョンはインターリーブ比 1:1に対応してい るはずです. FreeBSDは充分高速なので, ぜひ 1:1と指定してください. Western Digital WD1007コントローラ 筆者は, WD1007でコントロールされた ESDIディスクへ, FreeBSDをインストー ルすることができました. 正確には WD1007-WA2というコントローラでした. これ以外の複数のバージョンも WD1007にあります. 利用できるようにするために, セクタトランスレーションとWD1007の BIOSと を使わないように設定しました. この設定の意味は, BIOSに組み込まれた物理 フォーマットプログラムを使えないようにしたということです. 代わりに, www.wdc.comから WDFMT.EXEを入手して, ディスクをフォーマットし ました. 以後, 順調に動いています. Ultrastor U14Fコントローラ ネットに流れたいくつかの報告によれば, Ultrastorの ESDIボードも FreeBSD で動作するようです. 実際の設定についての詳しい情報はありません. 追加資料 本格的に ESDIのプログラミングを計画している方は, 次の公式規格仕様書を 入手なさることをおすすめします. 最新の ANSI X3T10 委員会の文書は次のものです： Enhanced Small Device Interface (ESDI) [X3.170-1990/X3.170a-1991] [X3T10/792D Rev 11] USENETのニュースグループ comp.periphs は, 詳しい情報を得ることができる注目すべきもので す. World Wide Web (WWW) もまた便利な情報源です. Adaptec社の ESDIコントロー ラについては http://www.adaptec.com/ を参照ください. Western Digital 社のコントローラについては http://www.wdc.com/ を参照ください. 感謝 Andrew Gordon氏より, テスト用の Adaptec 2320コントローラと ESDIディス クを送っていただきました. SCSIとは? 原作:&a.wilko;. July 6, 1996. 訳: &a.jp.yoshiaki;. 4 November 1996. SCSI は Small Computer Systems Interface (小規模コンピュータシステムインタフェース) の頭文字をとったものです. これは ANSI 規格の一つであり, コンピュータ業界において最もよく使われる I/O バスの一つになっています. SCSI はシュガート社 (ミニフロッピーディ スクを世界で最初に販売しました) の開発した SASI (Shugart Associates Standard Interface) バスを元に規格化されました. その後の業界の努力により, 異なるベンダのデバイスが混在して使えるよう, より厳密な規格へと規格化されました. その結果, 認可されたのが ANSI の SCSI-1 規格です. SCSI-1 仕様の規格化が行なわれたのは 1985 年前後です. (訳注: SCSI-1 の最終案決定は 1985 年, ANSI の標準規格としての認可は 1986 年です) この規格は, すでに現在では時代遅れのものになっており, 現在の標準は SCSI-2 (さらに詳しい情報 を参照してください) で, これもまもなく SCSI-3 へ移行していくでしょう. 物理的な相互接続の規格に加えて, SCSIではディスクドライブに不可欠な論理的な規格 (コマンドセット) も定義しています. この規格は標準コマンドセット (CCS; Common Command Set) と呼ばれ, ANSI の SCSI-1 とほぼ同時期に制定されました. SCSI-2 には (改定された) CCS が規格の一部として組み込まれました. コマンドは, デバイスの種類によって変わります. たとえばスキャナにおいて, Write コマンドは意味がありません. SCSI バスは多くの種類があるパラレルバスです. 最も古く, 最も利用されているのが 8 bit 幅, シングルエンド (不平衡) 信号, 50線の信号線のバスです (もしシングルエンドの意味が分からなくても気にすることはありません. この文書は, まさにそのような人たちのために書かれているからです). より新しい設計では 16bit 幅で平衡信号のバスを使います. この場合, 転送速度は 20Mbytes/second まで, ケーブルの長さは 25m まで可能です. SCSI-2では追加のケーブルを使った最大 32bit のバス幅までが定義されています. 最近急速に増えているものに Ultra SCSI (Fast-20 とも呼ばれます) があります. また, SCSI-2には Ultra2 (Fast-40 とも呼ばれます) というものも定義されています. Fast-20 は 1 秒間に 2000 万回の転送 (8bit バスで 20Mbytes/sec), Fast-40 は 1 秒間に 4000 万回の転送 (8bit バスで 40Mbytes/sec) を行ないます. 最近売られているハードディスクのほとんどは, 不平衡信号の Ultra SCSI (8bit または 16bit) です. 訳注: ここでは電気的な用語としては平衡, 不平衡を用いて, バスの名称としては基本的にはシングルエンド, ディファレンシャルとしました. もちろん SCSI バスにはデータ信号だけではなく, 多くのコントロール信号線があります. 複数のデバイスがバスを効率よく共有するための 複雑なプロトコルも規格の一部です. SCSI-2 ではデータは常に独立したパリティ信号を使ってチェックされます. SCSI-2 以前では, パリティチェックはオプションでした. SCSI-3 ではさらに高速なバスタイプが導入され, それと共にケーブルの線数を減らし, より最大バス長を伸ばしたシリアル SCSI が導入されます. SSA や Fiberchannelといった名前を聞いたことはありませんか? シリアルバスは現在では, まだいずれの方式も普及していません (特に一般的な FreeBSD 環境では). このためシリアルバスタイプについては, ここではこれ以上は触れません. 今までの記述から想像されるように, SCSI デバイスはインテリジェントです. これは SCSIの規格 (この文書は 2 インチ以上の厚さがあります) と切り離すことはできません. このため, たとえばハードディスクでは特定のブロックを指す場合は, ヘッド / シリンダ / セクタによって決めるのではなく, 単に必要なブロック番号を指定します. 巧妙なキャッシュ動作や, 不正ブロックの自動置き換えなどの機能は, この「インテリジェントデバイス」のアプローチによって可能になっています. SCSI バスでは任意のデバイスの組で通信することが可能です (訳注: 任意のデバイスがイニシエータになれるという意味です). デバイスの機能がそれを許すかどうかはまた別の問題ですが, 規格では禁止されていません. その場合は信号の衝突を防ぐために, 2 つのデバイスがバスを使う前に調停 (arbitrate) を行なう必要があります. SCSI では, 古い規格のデバイスと新しい規格のデバイスが 同じバスの上で動くように規格を作っています. したがって, 古い SCSI-1の デバイスは SCSI-2 バス上でも普通は動きます. 普通は, と断った理由は, ある古いデバイスが (古い) 規格に対して, 新しいバスでも問題ない程に十分規格に準拠した実装になっているかどうかを 絶対的に保証することはできない, ということです. 一般に, 最近のデバイスはよりうまく動作します. その理由は規格化がより厳密になり, またメーカーがデバイスの製造において, よりきちんと規格に従うようになってきているからです. 一般的に言って, 単一のバス上で動かすデバイスは SCSI-2 あるいはより新しいデバイスであれば うまく動く可能性は高いと言えます. これは新しい 2GBのディスクを手に入れたとしたら 古いデバイスを捨ててしまわなければならないという 意味ではありません. 私のシステムでは SCSI-1以前のディスク, SCSI-2の QICテープユニット, SCSI-1のヘリカルスキャンテープユニット (訳注: VTRのような回転ヘッドを 持ったテープ装置のことです. DATテープドライブもその一つです), 2台の SCSI-1 ディスクが一緒に問題なく動いています. ただし効率の点から古いデバイスと新しい (= 速い) デバイスを分けたいかもしれません. (訳注: 古いデバイスの中には disconnectをサポートしないために一連のコマンド実行中に SCSIバスを占有してしまうデバイスもあります.) SCSI の構成要素 先に述べたように, SCSI デバイスはインテリジェントです. つまりハードウェア細部にからむ知識は SCSI デバイス自身が 持っています. そのためホストシステムは, あるハードディスクがいくつのヘッドを持っているのかとか, 指定したテープデバイスがいくつのトラックを持つか, というようなことを知る必要はありません. もしあなたが知りたいのであれば, 規格で定義されているコマンドを使って, デバイスにハードウェアの詳細について問い合わせることができます. インテリジェントデバイスの利点は明らかです. ホストのデバイスドライバはより一般的に書くことができ, 新しいデバイスを導入する場合でも変更の必要がありません. 接続でおこなうべきこと, してはならないこと ケーブルの接続には鉄則があります. よい部品を使うことです. バスの速度を上げることができ, 多くの災難を防ぐことができます. ですから, 金メッキのコネクタ, シールドケーブル, 固定器具付きの頑丈なコネクタカバーなどを 選ぶのは正しいことです. 2つ目の鉄則は, ケーブルを必要以上に長くしないことです. 私は以前にあるマシンでトラブルの 原因を探すのに 3日間悩んでいましたが, SCSIバスを 1m 短く することで問題を解決したことがあります. もちろん, 元のバスの長さでもSCSIの仕様はきちんと 満たしていたのですが. SCSI バスのタイプ 電気的に互換性のない 2種類のバスのタイプがあります. シングルエンドとディファレンシャルのバスです. これは SCSI デバイスとコントローラは同一のバス上に混在することのできない 2つのグループに大きく分けられるということを意味しています. しかし, 特別なハードウェアを使えばシングルエンドバスを ディファレンシャルバスに (その逆も) 変換することはできます. これらのバスのタイプの違いは次のセクションで説明します. SCSI関連のドキュメントでは 異なるタイプのバスを一種の用語とし て略語で表します. これを次の表に示します. FWD: Fast Wide Differential (高速 ワイド 平衡) FND: Fast Narrow Differential (高速 ナロー 平衡) SE: Single Ended (不平衡) FN: Fast Narrow (高速 ナロー) etc. 少し想像力を働かせればどのような 意味であるかはわかるでしょう. ワイド (Wide) はいくらか曖昧で, 16 または 32 bitのバスを示します. 私の知る限りでは, 32 bit のインタフェースは (まだ) 使われていませんので Wide は通常 16 bitを意味します. 高速 (Fast) はバスのタイミングがいくつかの点で異なり, ナロー (8 bit) バスでは 低速 (slow) SCSIバスの 5 Mbytes/sec に対して 10 Mbytes/sec の能力があります. 前にも述べたように, 20Mbytes/sec や 40Mbytes/sec のバス速度を持つものも現れてきています (Fast-20 == Ultra SCSI で Fast-40 == Ultra2 SCSI です). データ線の上位 (> 8) はデータの転送とデバイスの指定だけに利用されています. コマンドの送出とステータスメッセージ等は下位側の 8 bitのデータ線のみを使います. この規格により ナローデバイスはワイドバス上でも 動作する事ができます. 利用できるバスの幅はデバイス間で調停 (ネゴシエーション) されます. デバイスの IDについてはワイドとナローが混在する時には 気をつけなければなりません. シングルエンドバス (不平衡バス) シングルエンド SCSIバスは 5Vと 0Vの電圧 (つまりTTLレベルです) を信号として使い, それらは共通のグラウンド (GND) レベルを基準 にします. シングルエンド SCSI 8 bitバスは約25本のグラウンド線 を持ち, すべてのデバイスを「直線状」に接続します. 基準ではシングルエンドバスは最大の長さは 6mです. Fast-SCSI デバイスを使う場合には, この最大長さは 3mに短くなります. Fast-SCSIでは 5Mbytes/sec ではなく 10Mbytes/sec の転送速度 が可能になります. Fast-20 (Ultra SCSI) と Fast-40ではそれぞれ1秒間に2000万 (20M) ないしは 4000万 (40M) 回の転送ができます. したがって, Fast-20では 8bitバスで 20Mbytes/sec, 16bitバスで 40Mbytes/secとなりま す. Fast-20ではバスの最大の長さは 1.5m, Fast-40では 0.75mに なります. Fast-20は限界を相当に広げるものなので SCSIバス に雑音が多い場合はその影響を即座に受けます. バス上のいずれかのデバイスが 「高速の」 転送を利用する場合は Fastバスの長さの制限を受けます. 最近の Fast-SCSI デバイスではバスの長さが実際の問題に なりつつあるのが明らかになっています. これがディファレンシャル SCSIバスがSCSI-2の規格に導入された理由です. コネクタのピン配置やコネクタの種類については SCSI-2の規格 (さらに詳しい情報) を参照してください.コネクタ等について 詳細なリストがあります. 非標準のケーブルを使うデバイスに気をつけてください. 例えば Apple (の Macintosh は) 25pin の D-type のコネクタ (シリアルポートやパラレルプリンタに使われているコネクタ -- 訳注: 日本では一般的に D-sub 25pinと言っています) を使っています. 公式なSCSIバスでは50 pin が必要である事からこのコネクタでは 「独創的なピン配置」が必要な事が想像できるでしょう. ここ でおこなわれているようにグラウンド線の数を 減らすことはよい考え ではありません. SCSIの規格通りの 50 pinの接続の方が望まし いです. Fast-20 や 40 でこのようなケーブルを使おうなんて 考えてはいけません. ディファレンシャル (平衡) バス ディファレンシャル SCSIバスは最大長が 25m です. シングルエンド Fast-SCSIバスの 3mとはまったく違います. 平衡信号の背景と なっている考え方は, それぞれのバスの信号はそれぞれ 独立したリターン信号線を持つというものです. つまり, それぞれの信号は (できればより線の) ペアの信号線で 伝えられます. これら2つの信号線の差分の電圧で信号が「真」(assert) で あるか「偽」(de-assert) であるか判定されます. かなりの電圧 がグラウンド電位と信号線ペアの間にかかったとしても影響があ りません (だからといって 10kVの電圧をかけてみたりしないで ください.. ). なぜ平衡信号が よいのかについての説明は このドキュメントの 範囲を越えています. 電気的に平衡信号はノイズマージンの点で 非常に優れたものとして利用されているということを 受け入れて ください. ディファレンシャルバスは普通は外部接続に 利用されています. これは低コストのシングルエンドバスが筐体内の短 い距離のバスでは非常に多く利用されているからです. FreeBSDを使うにおいて, FreeBSD でサポートされている デバイスドライバがあるのであれば ディファレンシャルバスの利用で 問題になることは 何もありません. 例をあげれば, アダプテックの AHA1740はシングルエンドで, AHA1744はディファレンシャルです. 双方のソフトウェアインタフェースはまったく同一です. ターミネータ SCSIにおける用語でのターミネータとはインピーダンスの マッチングを正確におこなうための抵抗ネットワークです. インピーダンス マッチングは反射やリンギングを抑え, バスの信号をきれいにす る重要なものです. たとえば, あまり状態のよくない回線で長距 離の電話をかけた時にあなたは反射をどんなものか 感じるかもしれません. 20Mbytes/sec で信号の伝わる SCSIバスでは信号のエコーはありがたくありません. 訳注: 電気信号のパルスは進行波としての性格を持っています. このため, 一般的には信号線の両端で反射が起きます. 3mのバスの端からパルスを入れた場合, 反対の端からの反射波は 20ns後 - 本当は電線中の信号の伝達は 光速よりも少し遅くなるのでもう少し時間がかかりますが - に返ってきます. 低速のバスの場合タイミング的な余裕があり, 反射を繰り返しているうちに反射波は減衰してしまうのですが 高速のバスの場合は, 反射波の影響が落ち着く前に信号の 読み込みなどを行うために波形の乱れが誤動作の原因に なる場合があります. このためターミネータを使用して反射波の発生をできるだけ おさえます. ターミネータはいろいろな - 洗練されたものもそうでないものも - 実現方法があります. もちろん, 内蔵のものと外部という区別もあります. 多くの SCSIデバイスにはいくつかのソケットがあり, その中には抵抗ネットワーク (集合抵抗) が 入っているものもあるかもしれません (いや, おそらく 間違いなくあるでしょう). ターミネータを デバイスから外す時は大事にしまっておいてください. SCSIの接 続の変更をしようと思った時に必要になるかもしれません. ま た, それらしい抵抗ネットワークが見つからないこともあります. この場合, SCSIデバイスは内蔵ターミネータの有効と無効を切替 えるジャンパがあります. フラットケーブルに取り付ける特別 なターミネータもあります. 他には外部コネクタのような形をし たものやケーブルのないコネクタヘッドだけのものもあります. いろいろと見られるように多くの選択があります. どのような場合に単純な抵抗 (パッシブ) ターミネータから アクティブターミネータへ切替えるかという問題があります. アクティブターミネータはいくらか精巧な回路が信号をより きれいにするために入っています. 一般的に受け入れられている意見としては, 長いバスを使ったり 高速なデバイスを使う場合はアクティブターミネータの 有効性は増加すると言えます. SCSI バスですでに問題が起きて いるならアクティブターミネータを試すことを考えていいで しょう. まず借りることができないか探してみてください. アクティブターミネータは非常に高価だそうですから. ディファレンシャルと シングルエンドバスのターミネータは互換 性がないということを覚えておいてください. これらの2つの種 類を 混在させることはできません. OK, ではあなたは ターミネータをどこに入れればいいでしょうか? これは SCSIで最も多く誤解されているところです. しかし, これ は極めて単純なことです.. ここでのルールは SCSIバスの線 一本一本は必ず両端に 2個のターミネータを入れる ということです. つまり 2個であって1個でも3個でもありません. このルールを受け入れてしたがってください. そうすれば終りの ない苦しみから救われるでしょう. なぜなら間違ったターミネーションは不可解なバグを引き起こす 可能性が非常に高いからです. (ここの 可能性 に注意; 一見動いているように見える ことがあるのがやっかいです.) よく陥りやすい落し穴はマシンの内部 (フラット) ケーブルと外部 ケーブルがコントローラにつながっている場合です. よく見られ るのはコントローラのターミネータを外すのを忘れることです. ターミネータは最後の外部デバイスで必要で, コントローラ には必要ありません! 一般的に, SCSIバスの接続の変更をする場 合はこのようなことに注意をしなければなりません. ターミネータの位置は 信号線ごとに決まることに注意して下さい. ナローとワイドのケーブルを 両方コントローラにつないでいる場 合には, ケーブルの両端とともにコントローラ上ではバスの上位 8ビットをターミネートしないといけません. 私自身は, すべてのデバイスとコントローラのターミネータを外し ています. 2個の外部ターミネータをセントロニクスタイプ (訳注: 日本ではケーブルに対してこういう言い方は あまりしないのでは ないでしょうか) 外部ケーブルと内部フラットケーブルの コネクタの両端に接続しています. こうすることにより接続の変更はかなり簡単になります. 最近のデバイスは, ICターミネータが使われることもあります. コントロールピンにより無効 / 有効を設定できる 特別の IC があります. これは物理的にデバイスから外す必要がありません. 新しいホストアダプタではセットアップツール等を使って ソフトウェア的に設定をおこなう場合があります. また, 中には端子に接続されたケーブルを検出して ターミネータ を必要に応じて自動的に 有効にするものもあります. いずれにしろ, マニュアルを見てく ださい. ターミネータの電源 ここまでの章で議論したターミネータは 正常に動作するためには 電源が必要です. SCSIバス上にはこの目的のために利用される線があります. だから特に気にする必要はないと思いますか? ところがそうではないのです. それぞれのデバイスはデバイス上 にあるターミネータソケットに電源を供給することはできます. けれども外部ターミネータがある場合やSCSIバスにターミネータ の電源を供給するデバイスのスイッチがオフになっているような 場合にはトラブルが起きるかもしれません. イニシエータ (ここではバスの動作を開始-initiate-させる デバイスを指します -- 訳注: 簡単に言えばホスト側のアダプタですがSCSIの 規格によれば, 例えばディスク側がコマンドを発行するような システムがあってもかまわないことになっているので こういう言い方をしています) は ターミネータ電源を供給しなければなりません. すべてのSCSIデバイスはターミネータの電源を供給することが できます (必ずしも供給しなければならないというわけ ではありません). スイッチがオフになっているデバイスが バス上に存在することを 許すために, ターミネータの電源はダイオードを通して供給され なければなりません. これはスイッチを切ったデバイスに電流 が逆流することを防ぐためです. 最悪の事態を避けるために, ターミネータの電源は普通はヒューズが入っています. 当然ヒューズは飛ぶかもしれません. この 場合でもバスが機能停止するとは限りません. 複数のデバイスが ターミネータの電源を供給しているのであれば, ヒューズが一つ 飛んでも全体の機能には影響しません. ただ一つの供給線の ヒューズが飛んだのであれば確かに問題になるでしょう. 外部ターミネータによっては LED でターミネータ電源 が与えられていることを示すものもあります. 最新の設計ではある程度の時間がたつと 「リセット」され 自動復帰するヒューズが使われることもあります. デバイス アドレッシング SCSIバスでは接続された異なるデバイスを区別して指定 できなければなりません. これには SCSIではターゲットIDが使われます. それぞれのデバイ スは特定のターゲットIDを持ちます. デバイスの IDはジャンパや DIPスイッチなどで設定できます. ブート時のメニューからIDを 変更できるようになっているコントローラもあります. (また, IDを 7から変えることができないコントローラもあります.) より詳しい情報はデバイスのマニュアルを見てください. 複数のデバイスを使う場合は IDの重複に気をつけてください. 重複すると普通は混乱状態になります. 同じ IDを共有している デバイスのうちの一つがI/Oリクエストに答えられたりすると 非常にやっかいなことになります. 8 bitバスでは, 最大8台のターゲットまで可能です. 最大8台で ある理由は, バスの8本のデータ線がデバイスの選択に使われる からです. ワイドなバスでは使えるデバイスの数は増えます (通常は16になるわけです). ナロー SCSI デバイスは 8 以上のターゲット ID を持つデバイスとは 通信できないことに注意してください. ですから, コントローラ のターゲットIDを8以上にするのはあまりいい考えとは いえません (CDROMが使えなくなったりします). 同時にバス使用の要求が発生した場合, 最も IDの大きいデバイス が優先されるという調停がおこなわれます. このことは SCSIホストアダプタの IDは通常7番が使われる理由でもあり ます. ただし, ワイドバスでは下位8ビットが上位8ビットより優 先度が高いことに注意してください. つまり, ワイドSCSIのシス テムではターゲットIDの優先度は高い順に [7 6 .. 1 0 15 14 .. 9 8] となります. (どうして下位8ビットの方が優先度が高いかは, 一つ前の段落を読んで考えてみて下さい.) さらにサブユニットとして, 規格では ロジカルユニット, 短縮形で LUNを持つことができます. 一つのターゲットIDが複数の LUNを 持つことができます. 例えば, テープチェンジャを持つテープ ドライブは LUN 0をテープドライブ自身, LUN 1を テープチェンジャ に与えることができます. このようにして, ホストシステムはテープチェンジャの目的の テープユニットの部分を指定することができます. バスの形状 SCSIバスは直線状です. つまり, Y接続, スター接続, 円形, クモの巣状の接続などの直線以外の接続ではありません. 初心者が よくやる間違いとしてはワイドSCSIのコントローラの端子3つと もにケーブルをつないでしまうというものがあります. (外部, 内部ナロー, 内部ワイド.) よほど運がよければこんなトポロジー でもちゃんと動くように見えるかもしれませんが, えてしてこう いうシステムは一番大切な時に使えなくなったりするものです (これをマーフィーの法則といいます). 先に議論したターミネータの問題は直線状以外の場合では より困難になるだろうということに注意してください. また, 内部バス用の ケーブルの端子の数よりデバイスの 数の方が少ない場合には, 必ず両端の端子にはデバイスをつなぐようにしてください. 内側の端子を使ってケーブルの端を余らせておくと, ターミネータの効果が半減します. 電気的特性はそのノイズマージンや全体の信頼性において, 直線状のバスのルールに強く依存しています. 直線状バスであるというルールに したがってください! FreeBSD で SCSIを使う トランスレーション, BIOS, そしてマジック... まず始める前に, 電気的に問題のないバスであるか調べておいてく ださい. SCSIディスクをPCでブートディスクとして使う場合に, PC BIOSに 関する気まぐれについて知っておく必要があります. PC BIOSは ハードディスクへの低レベル物理インタフェースを 利用するように 実現されています. したがって, BIOSに (セットアップツールやBIOSビルトイン セットアップを使って) ディスクの物理パラメータを教えてやる 必要があります. これはヘッドの数, シリンダの数, トラックあたりのセクタなどがあり, プリコンペンセーションや書き込み電流を 減少させるトラック, などのあまりよく知られていないものもあります. SCSIディスクはこれらのことをユーザは 気にする必要がないはず だと考えるかもしれません. しかし, 不思議なことに (これらの項 目の) セットアップはいまだにあるのです. システム BIOSはブート 時にFreeBSDのカーネルを読み込むためにSCSIディスクに /ヘッド/シリンダ/セクタ を指定する方法でアクセスするため, パラメータを知る必要があるのです. AT/EISA/PCIバスなどにあり, ディスクに接続される SCSIホストアダプタや SCSIコントローラは それ自身のオンボードBIOSを持っています. システムの起動時に, SCSI BIOSは システムBIOSのハードディスクの インタフェースルーチンを乗っ取ります. システムBIOSをごまかすために システムセットアップでは普通は `No hard disk' とします. 簡単ですね? 訳注: BIOS で `No hard disk' という設定をおこなうのは SCSI ドライブから直接起動させるためのテクニックです. 現在のマザーボードでは SCSI ドライブから起動させるための オプションを持つ BIOS を使用しているものもあります. また, ブートセレクタを使って IDEドライブのブートブロックから SCSIドライブ上の FreeBSDをブートすることもできます. SCSI BIOS はドライブの トランスレーション と呼ばれる 機能を持ちます. これはPCがブートするために作られたドライブテー ブルをごまかすものです. このトランスレーションは多くは (すべての場合ではありません) トラックあたり64あるいは32個のヘッドを 持つ仮想的なドライブを使います. シリンダの数を変更することで SCSI BIOS は実際のドライブのサイズに適合させます. 総セクタ数 を 32 * 64 / 2 で割った結果がメガバイト単位のドライブのサイズ になります. 2で割っているのは, 通常 512バイトのサイズの セクタを kByte 単位に変換するためです. ではこれですべてうまくいくのでしょうか. いいえ, そういう訳で はありません. ブート可能なハードディスクのシリンダ数は 1024よ り多くすることはできないのです. トランスレーションを使った 場合でもディスクの 1GB以上の領域は見えません. ディスクの容量 がどんどん増加していくにつれこれは問題になってきました. 幸いにして, 単純な解決方法があります. 単に別のトランスレーショ ンを使えばよいのです. 例えば, 32個に代わり, 128個のヘッドを使います. ほとんどの場合, 古いSCSIホストアダプタをアップグレードす るための新しいバージョンの SCSI BIOS が用意されています. 新しいアダプタではジャンパ やセットアップソフトによって SCSI BIOSの使う トランスレーションを選択できる物もあります. ここで非常に重要なことは, ディスク上のすべての オペレーティングシステムが 同一のトランスレーションを使って 正しいパーティションを得ることです. つまり FreeBSDをインストールする時に, ヘッド/シリンダなどについての 質問にあなたのホストアダプタが 使用しているトランスレートされた 値を使わなくてはなりません. トランスレーションに関する失敗でよく見られるものは, ブートしないシステムができたり, 他のパーティションを 上書きしてしまうことです. すべてのシステムが見えるように fdiskを使うべきです. あなたはデバイスについて これとは食い違った話を聞いたことが あるかもしれません. 古い FreeBSDのカーネルはブートする時に SCSI ディスクのジオメトリ情報を報告していました. 私のシステムの一つの例を示しましょう. aha0 targ 0 lun 0: <MICROP 1588-15MB1057404HSP4> sd0: 636MB (1303250 total sec), 1632 cyl, 15 head, 53 sec, bytes/sec 512 最近のカーネルは, 普通はこのような情報を報告しません. たとえば, このようになっています. (bt0:0:0): "SEAGATE ST41651 7574" type 0 fixed SCSI 2 sd0(bt0:0:0): Direct-Access 1350MB (2766300 512 byte sectors) なぜこのように変わったのでしょう? この情報は SCSIディスク自身から得られます. 最近のディスクで はよくゾーンビット記録方式 (zone bit recording) という 技術が使われています. これはドライブの外側のシリンダは 内側よりもスペースが広いのでトラックあたりのセクタ数を 増やすことができるというアイディアです. この結果, 外側のシリンダ上のトラックの容量は内側の シリンダよりも大きくなり, 全体ではより大きな容量となります. この場合, ドライブのジオメトリについての報告は, 最善のものかどうか疑わしく, ほとんどの場合誤解を招くものであ ることがわかるでしょう. ジオメトリを調べる場合, ほとんどの場合は BIOSの用い ている値を与える方がよい結果となり, BIOSがそのディスクに ついてまったく関知しないのであれば (例えばブートディスクで はないなら) 都合のよい仮想のジオメトリを与えればいいでしょう. SCSI サブシステムの設計 FreeBSDでは階層的な SCSIサブシステムを用いています. それぞれ 異なるコントローラカードの デバイスドライバが書かれています. このドライバはコントローラのハードウェアの 詳細を知っています. ドライバは SCSIサブシステムのより上位の階層のコマンドを受け取り, ステータスを報告するインタフェースを持ちます. カードのドライバの最上位には, デバイスのクラスのための いくつかの一般的なドライバがあります. 具体的にいうと, テープドライブのためのドライバ (略号は: st), 磁気ディスク (sd), CDROM (cd) などです. これらのソースコードは /sys/scsiにあります. マニュアルページ (man) のセクション 4 にはより詳しい内容が あるので見てください. 多階層の設計は低レベルとより高位の レベルを分離させることが できます. 新たに他の種類のハードウェアのサポートを加えることを より処理しやすい問題にします. カーネルコンフィグレーション あなたのハードウェア構成にしたがって, カーネルの コンフィグファイルに ホストアダプタについて 1行あるいは数行程度の記述をする 必要があります. これには I/O アドレスや割り込みなどについての内容も 含みます. あなたのアダプタのドライバについてのマニュアルページ にはより多くの情報があるのでよく読んでください. これとは別に /sys/i386/conf/LINT にはカーネルコンフィグファイルについての 概要があります. LINT には一般的なものについては可能なすべての オプションが含まれています. ただし, LINT では実際に動作するカーネルを作ることは できません. 当然のことを言うようで恐縮ですが, カーネルコンフィグファイルは実際のハードウェア構成を 反映すべきです. そのように割り込みやI/Oアドレス等に 合わせてカーネルコンフィグファイルを書か なければなりません. システムのブート時のメッセージは実際に 見つけたハードウェアの設定を表示します. ほとんどの EISA/PCI 用のドライバ (具体的には ahb, ahc, ncr と amdです) はブート時にコントローラから直接パラメータ を読みこみます. これらについては, 何も引数をつ けずにただ controller ahc0 のように書けば大丈夫で す. 例として FreeBSD 2.2.5-Releaseのいくつかのコメント ([]の中) をつけた LINT カーネルコンフィグファイルを示 します. # SCSI host adapters: `aha', `ahb', `aic', `bt', `nca' # # aha: Adaptec 154x # ahb: Adaptec 174x # ahc: Adaptec 274x/284x/294x # aic: Adaptec 152x and sound cards using the Adaptec AIC-6360 (slow!) # amd: AMD 53c974 based SCSI cards (e.g., Tekram DC-390 and 390T) # bt: Most Buslogic controllers # nca: ProAudioSpectrum cards using the NCR 5380 or Trantor T130 # ncr: NCR/Symbios 53c810/815/825/875 etc based SCSI cards # uha: UltraStore 14F and 34F # sea: Seagate ST01/02 8 bit controller (slow!) # wds: Western Digital WD7000 controller (no scatter/gather!). # [ Adaptec AHA274x/284x/294x/394x などのコントローラ] controller ahc0 [ NCR/Symbios 53c875 コントローラ] controller ncr0 [Ultrastor アダプタ] controller uha0 at isa? port "IO_UHA0" bio irq ? drq 5 vector uhaintr # Map SCSI buses to specific SCSI adapters controller scbus0 at ahc0 controller scbus2 at ncr0 controller scbus1 at uha0 # The actual SCSI devices disk sd0 at scbus0 target 0 unit 0 [SCSI ディスク 0 は scbus 0, LUN 0] disk sd1 at scbus0 target 1 [unit を省略すると暗黙で LUN 0] disk sd2 at scbus1 target 3 [uha0 上の SCSIディスク] disk sd3 at scbus2 target 4 [ncr0 上の SCSIディスク] tape st1 at scbus0 target 6 [SCSI テープ は ターゲット (ID)6] device cd0 at scbus? [最初に見つけた CDROM, 固定にしない] 上の例では カーネルは ahc (Adaptec 274x) コントローラをまず探し, その次に NCR/Symbios のボードというように順番に探して 行きます. その下の行の controller の記述ではデバイスの詳細 を記述して, 対応するバスでターゲット ID と LUN が指定された ものと一致する場合だけ 認識するようにカーネルに 伝えています. 固定された (Wired down) デバイスは 最初にユニット番号が 与えられるので, 固定されていないデバイスは同じ種類の 固定されたユニット 番号の最も大きい番号の1つ上の番号から割り当てられます. したがって, ターゲットID 2の SCSIテープを加えると, ターゲットID 6 のテープがユニット番号1に固定されているので, それはst2に設定 されるでしょう. ブート時に見つからなくても固定されたデバ イスにはユニット番号が常に割り当てられます. 固定のデバイスに 割り当てられたユニット番号は, もしそのデバイスのスイッチが ブート時に切られていてもそのデバイスに リザーブされています. これは, 電源を入れて接続した時のユニット番号が与えられます. デバイスのユニット番号は SCSIバスのターゲットID とは 何の関係もない ことに注意してください. 下の例は FreeBSD のバージョン 2.0.5 以前の カーネルコンフィ グファイルです. 最初の例との違いはデバイスの固定 (wired down) がないことです. 固定 によりどのSCSIターゲットをどの デバイスに割り当てるかを記述できるようになりました. 下のコンフィグファイルにより 構築されたカーネルでは最初に見つ けた SCSIディスクが sd0になり, 次に見つけたディスクが sd1に, という具合に割り当てられます. もしディスクの削除や追加をおこなう と, 他の同じタイプのデバイス (この場合はディスク) のすべてが 「移動して」しまうかもしれません. これによりそのたびに /etc/fstab を変更する必要があります. 古いスタイルでも動きますが, 新しいスタイルを使うことが強 く 推奨されています. これにより SCSIバスのハードウェアを どのように変更した場合でもトラブルを避けることができます. ですから, 2.0.5.R以前の FreeBSDからアップグレードした後に古い 信頼できるコンフィグファイルを再利用する時はこの部分を チェックして直してください. [Adaptec 174x用のドライバ] controller ahb0 at isa? bio irq 11 vector ahbintr [Adaptec 154x用のドライバ ] controller aha0 at isa? port "IO_AHA0" bio irq 11 drq 5 vector ahaintr [Seagate ST01/02インタフェースのドライバ] controller sea0 at isa? bio irq 5 iomem 0xc8000 iosiz 0x2000 vector seaintr controller scbus0 device sd0 [4台のSCSI ディスクのサポート, sd0 から sd3] device st0 [2台の SCSI テープのサポート] [CDROMのドライバ] device cd0 #Only need one of these, the code dynamically grows 両方の例で SCSIディスクがサポートされています. ブート中に 「固定」の記述がされているタイプ(例えば sd ディスク) のデバ イスで記述より多くのデバイスが見つかると, システムは単純に最後の 固定 のデバイスの番号より 1つずつ増加させた番号をデバイスに割り当てて行きます. もし 固定 のデバイスがなければユニット番号は 0 から始まります. man 4 scsi によって SCSIサブシステムの最新の情報を チェックしてください. より詳細なホストアダプタドライバの使い 方は, たとえば Adaptec 294xドライバの場合はman 4 ahc にあります. カーネルセットアップでの SCSI チューニング 経験的に SCSIバスリセット (ブート時におきます) 後のINQUIRYコマ ンドに対して応答が遅くなるデバイスがあります. INQUIRYコマンドは ブート時にカーネルがどの種類のデバイス (ディスク, テープ, CDROMなど) がどのターゲットIDに接続されているかを調べるために 発行します. ちなみにこのプロセスをデバイスプロービング (デバイス検出) と言います. 「応答の遅いデバイス」の問題を解決するために, FreeBSDは SCSIバスをリセットした後に SCSIデバイスの検出を おこなうまでのディレイタイムを調整することができます. カーネルコンフィグレーションファイルの下に示すような 行にディレイタイムを設定してください. options SCSI_DELAY=15 #Be pessimistic about Joe SCSI device この行ではディレイタイムは 15秒です. 私のシステムでは, 信頼できる古い CDROMが認識できるように3秒の値を使っています. もし デバイスの認識で問題が起きる時は大きな値 (30秒であるとか) から 始めてください. うまく動いたら, 値を減らしてちょうどよい値 にチューニングしてください. Rogue な SCSI デバイス (訳注: rogue は有名なゲーム, ではなくて 悪党, 群から離れた, 凶暴な, という意味) SCSI の規定は完全で簡潔なものにしようという 努力はされましたが, 複雑な規定となり, 正確に実現するのは簡単なことではありません. いくつかのベンダは他よりもよい仕事をしています. ここで イカレた デバイスが現れることになります. このような デバイスは FreeBSD のカーネルにいくらか標準的 ではない振舞をするものと認識されます. イカレたデバイスは ブート時にカーネルによって報告されます. 次の例は私の2つの カートリッジテープユニットです. Feb 25 21:03:34 yedi /kernel: ahb0 targ 5 lun 0: <TANDBERG TDC 3600 -06:> Feb 25 21:03:34 yedi /kernel: st0: Tandberg tdc3600 is a known rogue Mar 29 21:16:37 yedi /kernel: aha0 targ 5 lun 0: <ARCHIVE VIPER 150 21247-005> Mar 29 21:16:37 yedi /kernel: st1: Archive Viper 150 is a known rogue 例えば, あるターゲットIDから実際には1つのデバイスしかないの にすべての LUNからの応答があるようなデバイスがあるとします. カー ネルはその特定のターゲットIDに8個の LUNがあると誤解してしまう かもしれません. このような混乱の起きる原因については読者へ の課題にしておきます. FreeBSDの SCSIサブシステムは 検出時の INQUIRYの応答を見て 悪い習慣を持つデバイスの認識をしています. INQUIRYの応答には デバイスのファームウェアのバージョン番号が含まれるため, 異なる 動作をするファームウェアのバージョンを 区別することも可能です. 例えば, /sys/scsi/st.c や /sys/scsi/scsiconf.c を 見てください. どのように行っているか, より多くの情報があります. この方法はうまく行きますが, もちろん既知のデバイスがつながっ ている場合だけうまくいくということに 気をつける必要があります. もしあなた以前に Mumbletech SCSI CDROM (訳注: 架空のメーカ のデバイスです) を接続した人がいないとしたら, どんな 「ワザ」 を使ってそれを使うか自分で見つけないと いけないかもしれません. あなたの Mubletech を動かすことができたらその成果を FreeBSDの 次のリリースへ含めるために FreeBSD開発チームへ送ってくださ い. 他の Mumbletechの利用者たちはあなたに感謝するでしょう. 複数の LUNを持つデバイス 単一の SCSI ID上に複数の論理ユニット (LUN) を持つデバイスを使う ような場合もあるかもしれません. 多くの場合では FreeBSDは LUN 0 のみを検出します. このような例としては2台の SCSIではないハード ディスクを SCSIバスにつなぐブリッジボード (例えば古い Sunシステ ムに見られる Emulex MD21) があります. LUN が0ではないデバイスは普通はシステムブート時の検出では 見つかりません. この問題にうまく対処するには /sys/scsi/scsiconf.c に適切なエントリを加えてカーネルを再構築 しなければなりません. 以下のように初期化されている構造体を探します. { T_DIRECT, T_FIXED, "MAXTOR", "XT-4170S", "B5A", "mx1", SC_ONE_LU } LUNが複数あるあなたの Mumbletech BRIDGE2000 はハードディスク として働きます. またファームウェアのリビジョン123などを次のよ うに書き加えます. { T_DIRECT, T_FIXED, "MUMBLETECH", "BRIDGE2000", "123", "sd", SC_MORE_LUS } 訳注: 複数 LUNに対応するためには構造体の最後の要素を SC_MORE_LUSにします. エントリを作る必要がある場合は scsiconf.c にある MBR-7等のエントリを参考にするといいでしょう. カーネルは INQUIRYに一致するデータをブート時にテーブルから 探してこれにしたがってふるまいます. より多くの情報は ソースコードを見てください. タグ コマンド キューイング 最近の SCSI デバイス, 特に磁気ディスクではタグ コマンド キューイング (tagged command queuing: TCQ) がサポートされています. 要約すれば, TCQ は複数の I/O リクエストを同時に受けることを可能 にすることです. デバイスはインテリジェントですから,リクエスト キューにある処理 (ヘッドのポジショニングなど) の最適化を おこなうことができます. RAID (Redundant Array of Independent Disks) のようなSCSIデバイスではTCQ機能はデバイスの持つ並列性の 利点を生かすために不可欠です. 各々の I/O リクエストは単一の tag (タグ コマンド キューイン グの名前の由来) が与えられます. FreeBSDはこの tagによりデバ イスドライバのキューの中のどの I/Oリクエストが完了したかの 識 別をおこないます. TQC のリクエストはデバイスドライバが サポートしていたとしても あるデバイスのファームウェアではインプリメントが 正しくない かもしれません. このような問題に出会うと非常に不可解な問題に つながります. このような場合は TCQ を無効にしてみてください. バスマスタ ホストアダプタ すべてではありませんが多くの SCSIホストアダプタは バスマスタコントローラです. これはホストCPUにデータ転送の 負荷をかけず, ボード自身がI/Oをおこないます. これは FreeBSDのようなマルチタスクのオペレーティングシステム では大きな利点になります. しかし, 何らかの問題の起きることも あります. 例えば Adaptec 1542 コントローラは ホストバス (ここでは ISA または AT バス) を異なった転送速度に設定できます. コントローラが 異なるレートに設定できるのは すべてのマザーボードで 高速な転送が できるわけではないからです. マザーボードに合っていない高速の データ転送速度を用いた時には, ハングアップやデータの損傷等の 問題が起きるかもしれません. これを解決する方法は明らかです. より低いデータ転送速度に設定 してうまく動くか確かめることです. Adaptec 1542 の場合, 可能な限り高速な転送レートを動的に読み取って, 正しい決定をおこなうためのオプションを カーネルコンフィグファイルに 追加することができます. このオプションはデフォルトでは無効に なっています. options "TUNE_1542" #dynamic tune of bus DMA speed あなたの使うホストアダプタについてのマニュアルページを チェックしてください. また最終的な手段としては究極のドキュメントを 使ってください (つまりドライバのソースを読んでくださいというこ とです). 訳注: 2.1.5R の時点ではすべてのドライバに関してマニュアルページ があるわけではありません. また上の例の TUNE_1542のオプション も man aha にはないようです. ソースのコメントだけで も一度見ておいてもいいかもしれません. 問題を突き止める 以下は SCSI で一般的に問題が起きた場合に解決をするためのチェッ クリストの試みです. これは完全な物ではありません. コネクタとケーブルがゆるんでいないかチェックする. ターミネータの場所と数を念には念を入れて チェックする. 少なくとも 1 つのターミネータの電源の供給源があるかチェック する (特に外部ターミネータを使う場合). ターゲットIDが重複していないかチェックする. 使用するすべてのデバイスの電源が ON になっているかチェックする. 必要最小限のデバイスだけの構成を試してみる. 可能であれば, ホストアダプタのスピードを遅くする. 問題をより単純にするために, タグコマンドキューイングを可能 であれば無効にする. (NCRベースのホストアダプタについては man ncrcontrol を見てください) カーネルのコンパイルができるのであれば, SCSIDEBUGオプショ ンをつけて makeして, デバイスをデバッグモードにしてアクセ スしてみてください. もしそれでも起動時にデバイスが検出 されないのであれば, デバイスの設定アドレスが間違っている のかもしれません. また, /sys/scsi/scsidebug.h に あるデバッグレベルを変えてみてください. 検出はされるが 動かないのであれば, &man.scsi.8; コマンドで (SCSIDEBUG をつけてmakeした) カーネルが動いている状態で動的にデバッグ レベルを設定することができます. これは guru (UNIXの達人) で も混乱してしまうほどの非常に大量のデバッグ情報を 出すでしょ う. man 4 scsi にはより正確な情報があります. またman 8 scsi も見てください. さらに詳しい情報 もしあなたがいくらかは本気で SCSIハッキングをする気があるなら たぶん正規の規格を持っていたくなるでしょう. 承認ずみのアメリカ工業規格は ANSI から購入できます. 住所と電話番号は
13th Floor 11 West 42nd Street New York NY 10036 Sales Dept: (212) 642-4900
です. また, ANSIの規格および委員会の規格案 (ドラフト) のほとんどは Global Engineering Documents より買うことができます. 連絡先は
15 Inverness Way East Englewood CO, 80112-5704 Phone: (800) 854-7179 Outside USA and Canada: (303) 792-2181 Fax: (303) 792- 2192
です. X3T10 のドラフトの多くは電子的に利用できる形で SCSI BBS (719-574-0424) と ncrinfo.ncr.com の Anonymous FTP サイトから得ることができます. 最新の X3T10 委員会の文書は: AT Attachment (ATA or IDE) [X3.221-1994] (Approved) ATA Extensions (ATA-2) [X3T10/948D Rev 2i] Enhanced Small Device Interface (ESDI) [X3.170-1990/X3.170a-1991] (Approved) Small Computer System Interface — 2 (SCSI-2) [X3.131-1994] (Approved) SCSI-2 Common Access Method Transport and SCSI Interface Module (CAM) [X3T10/792D Rev 11] 追加情報を得ることのできる出版物は: SCSI: Understanding the Small Computer System Interface, NCR社 編. 出版: Prentice Hall, Englewood Cliffs, NJ, 07632 Phone: (201) 767-5937 ISBN 0-13-796855-8 Basics of SCSI, a SCSI tutorial, Ancot Corporation 編 Ancot の連絡先: Phone: (415) 322-5322 Fax: (415) 322-0455 SCSI Interconnection Guide Book, AMP社の出版物 (発行 4/93, カ タログ 65237) 色々な SCSI コネクタのリスト と ケーブル接続方法のガイド. AMP 社より入手可能. (800) 522-6752 または (717) 564-0100 Fast Track to SCSI, 富士通によるプロダクトガイド, 入手先: Prentice Hall, Englewood Cliffs, NJ, 07632 電話: (201) 767-5937 ISBN 0-13-307000-X The SCSI Bench Reference, The SCSI Encyclopedia, SCSI Tutor, ENDL Publications, 14426 Black Walnut Court, Saratoga CA, 95070 電話: (408) 867-6642 Zadian SCSI Navigator (クイックリファレンス) および Discover the Power of SCSI (最初の本は1時間のビデオとチュートリアルが付属), Zadian Software, Suite 214, 1210 S. Bascom Ave., San Jose, CA 92128, (408) 293-0800 Usenet のニュースグループ comp.periphs.scsi と comp.periphs は特により多くの情報を得るには注目すべき場所です. また定期的に ポストされる SCSI-FAQをここから得ることができます. 多くの主要な SCSIデバイスとホストアダプタの供給元は FTP サイト や BBSを開いています. これらはあなたの持っているデバイスに関す る貴重な情報源となるでしょう. * ディスク/テープ コントローラ * SCSI * IDE * フロッピー ハードディスクドライブ SCSI ハードディスク装置 寄稿: &a.asami; . 17 February 1998. 訳: &a.jp.miyasita;. 20 February 1998. SCSI の章で述べたように, 実際, 現在販売されている SCSI ハードディスク装置はすべて SCSI-2 互換であり, サポートされている SCSI ホストアダプタに 接続すればそれらは正常に動作するでしょう. 人々が直面する問題の多くは, ケーブル接続が間違っていたり (ケーブルが長過ぎる, スター型接続になっている, など), ケーブル終端の処理が不十分だったり, 部品が故障していたりのうちのどれかです. SCSI ハードディスク装置が動作しないときには, まず SCSI の章を参照して下さい. しかし SCSI ハードディスク装置を購入するときに 気を付けておきたいことがふたつあります. 回転速度 現在販売されている SCSI ドライブの回転速度の範囲は 4,500RPM から 10,000RPM であり, その大部分は 5,400RPM か 7,200RPM です. 一般的に 7,200RPM のドライブの方がデータ転送は速いのですが, 5,400RPM の同容量のものと比べてとても熱くなります. 現在のディスク装置の故障の大半は熱によるものです. もし PC のケースの中が非常によく冷却されていなければ, 5,400RPM かそれ以下のドライブにしておいた方がよいでしょう. より高密度で記録するようになっている新しいドライブは 以前のものに比べてより多くのビットを 各回転毎に転送することが できるということに気をつけて下さい. 現在, 5,400RPM の最高級機種では 1, 2 世代前の 7,200RPM の ドライブに匹敵する転送速度が出せます. 仕様一覧からバンド幅の数値を探すには 内部データ (または転送) 速度 という欄を見て下さい. 通常その数値は Mbits/s で書かれているので, それを 8 で割ればそのドライブで出せる速度が Mbytes/s で おおよそ見当をつけることができます. (もしあなたがスピード狂で, あなたの愛する小さなパソコンちゃんに 10,000RPM のドライブを載せたいのならそうしても構いませんが, そのようなドライブはものすごく熱くなります. ドライブへ 直接 風を当てられるようなファンや きちんと換気されているディスク区画を持っていないときには そういうことは考えない方がよいでしょう.) 最新の 10,000RPM のドライブや 7,200RPM のドライブは当然 最新の 5,400RPM のドライブよりも多くのデータを転送することが できますから, 絶対的なバンド幅がアプリケーションにとって 必要ならば, より速いドライブを選ぶしかありません. また, レイテンシを小さくする必要があるときも, より速いドライブが適当です. なぜなら, より速いドライブの方が平均シーク時間が 少ないだけでなく, 回転遅延という尺度において 低回転速度のドライブが高回転速度のものに 勝ることはないからです. (平均回転レイテンシはディスクが 1 回転するために要する時間を半分に したものです. すなわち, 10,000RPM のドライブでは 3 ms, 7,200RPM のドライブでは 4.2 ms, 5,400RPM のドライブでは 5.6 ms となります.) レイテンシはシーク時間と回転遅延との和になります. しかしここで, レイテンシの少ないドライブが欲しいのか, 1 秒あたりのアクセス数を増やす方がよいのかを はっきりさせておかなければいけません. 後者の場合 (例 : ニュースサーバ) では, 大きな速いドライブを 1 つ購入することは最適解とはならないでしょう. 遅いドライブを複数個使ってストライピングされた ディスクアレイを 作る ccd (連結ディスク) ドライバを用いることによって, 全体に必要な費用の点で同様かまたはより 良い結果を得ることができます. ドライブのまわりに適切な空気の 流れを作るようにする必要が あります. 高回転速度のドライブを使おうとしているときには特に 注意してください. 一般的に, ドライブの上下には少なくとも 1/2 インチ (1.25cm) の すき間が必要です. PC のケース内の空気がどんなふうに流れているか 理解しておいてください. 多くのケースには背面から空気を吸い込む電源が付いています. どこから空気が入ってくるかを確かめて, まわりに最大量の 冷たい空気が流れるようにドライブを設置してください. 効果的に冷却するためには, 不要な穴をいくつか塞いだり 新しいファンを追加する必要があるかも知れません. もうひとつ考慮するべき事柄は騒音です. 7,200RPM やそれより速い回転速度のドライブの多くは高い周波数の 音を発生し, この音は多くの人をとても不快にします. それに加えて, 冷却のために追加されたファンによっても, 7,200RPM やそれより速い回転速度のドライブはオフィスや家の環境に そぐわないものになるかもしれません. 形状 現在販売されている大部分の SCSI ドライブは 3.5 インチの 大きさです. それらは高さが 1.6 インチ (ハーフハイト) のものと 1 インチ (ロープロファイル) のものとの 2 種類に分類されます. ハーフハイトのドライブは CDROM ドライブと同じ高さです. しかし前節で述べたすき間についての ルールを忘れないでください. 3.5 インチドライブ用のベイが 3 段用意されているときに, ハーフハイトのドライブ 3 個を (焦がすことなく) そこに設置することはできないでしょう. インタフェース 現在売られている SCSI ハードドライブの多くは Ultra または Ultra-wide SCSI です. Ultra SCSI の最大バンド幅は 20MB/s, Ultra-wide SCSI の場合は 40MB/s です. Ultra と Ultra-wide の間にケーブル最大長の相違はありませんが, 同一バスに接続されるデバイスが増えれば増えるほど 早い時期にバスの整理に関する問題を 抱えることになるでしょう. うまく設計されたディスク区画を持っているのでなければ, 5 個か 6 個以上の Ultra SCSI ドライブを 1 本のバスに 接続することは容易なことではありません. 一方, 多数のドライブを接続する必要があるときに Fast-wide SCSI を利用することは悪くないアイデアでしょう. これは Ultra (narrow) SCSI と同じ最大バンド幅であると同時に 正しく 接続することが電気的にとても容易です. アドバイスとしてはこのようになるでしょうか : ディスクを多数接続したいときには wide SCSI のドライブを 選んで下さい. 通常 wide SCSI の方が少し高価ですが, 将来きっと役に立ちます. (なお, 価格差を補う余裕がないときにはディスクアレイを 作るべきではありません.) wide SCSI ドライブには 68 ピンのものと 80ピン SCA (単コネクタ型) のものとの 2 種類があります. SCA ドライブには 4 ピンの電源コネクタがなく, SCSI ID も 80 ピンコネクタを通じて設定されます. 真面目に大規模な記憶システムを作成するような場合には, SCA ドライブと SCA 筺体 (2 種類の電圧が供給できる電源と少なくとも 1 個のファンが付いたもの) を使ってください. その方が 68 ピンの同様のドライブよりも電気的に優れています. なぜなら, 68 ピンのドライブで作ったディスクアレイに 見られるような SCSI バスの スタブ がディスクキャニスタの内部に 存在しないからです. それらはより簡単に設置することができます (キャニスタの中にドライブをねじで固定すればよいだけで, (SCSI ID やディスクアクセス LED 用の線のような) 細かいケーブルを全部持ち上げるために狭いところへ指を入れて 握らなくてもよいのです). * IDE ハードディスクドライブ テープドライブ 原作: &a.jmb;. 2 July 1996. 訳: &a.jp.yoshiaki;. 13 October 1996. 一般的なテープアクセスコマンド &man.mt.1; はテープドライブへの一般的なアクセス方法を提 供します. rewind, erase, statusなど の共通コマンドがあります. マニュアルページの &man.mt.1; を見 てください. より詳しい解説があります. コントローラインタフェース テープドライブにはいくつかの異なったインタフェースがあり ます. SCSI, IDE, フロッピー, パラレルポートのインタフェース です. 非常に多くの種類のテープドライブがこれらのインタフェー スで使えます. コントローラについての議論はディスク/テープ のコントローラにあります(訳注:現在未完成です). SCSI ドライブ &man.st.4; ドライバは 8mm (Exabyte), 4mm (DAT: Digital Audio Tape), QIC (1/4インチカートリッジ), DLT (デジタルリニアテープ), QIC ミニカートリッジ, 9トラック (大きなリールがハリウッドの コンピュータルームで回っているのを見たことがあるでしょう) をサポートします. &man.st.4; マニュアルページにより詳しい解説があります. 以下のドライブリストは現在 FreeBSDコミュニティのメンバが 使っているものです. これらだけが FreeBSDで動くドライブという わけではありません. これらは単にたまたま私たちのうちの誰かが使っ ているというだけです. 4mm (DAT: Digital Audio Tape ) Archive Python 28454 Archive Python 04687 HP C1533A HP C1534A HP 35450A HP 35470A HP 35480A SDT-5000 Wangtek 6200 8mm (Exabyte) EXB-8200 EXB-8500 EXB-8505 QIC (1/4 インチカートリッジ) Archive Anaconda 2750 Archive Viper 60 Archive Viper 150 Archive Viper 2525 Tandberg TDC 3600 Tandberg TDC 3620 Tandberg TDC 3800 Tandberg TDC 4222 Wangtek 5525ES DLT (Digital Linear Tape) Digital TZ87 Mini-Cartridge Conner CTMS 3200 Exabyte 2501 Autoloaders/Changers Hewlett-Packard HP C1553A Autoloading DDS2 * IDE ドライブ フロッピードライブ Conner 420R * パラレルポートドライブ 詳細な情報 Archive Anaconda 2750 このドライブのブートメッセージの識別子は ARCHIVE ANCDA 2750 28077 -003 type 1 removable SCSI 2 です. これは QIC テープドライブです. QIC-1350テープを利用した場合の標準の容量は 1.35GBです. このドライブは QIC-150 (DC6150), QIC-250 (DC6250), QIC-525 (DC6525) の テープを問題なく読み書きすることができます. &man.dump.8; を使った時のデータ転送レートは 350kB/sです. Amanda における転送レートは 530kB/sと報告されています. このドライブは既に生産中止になっています. このテープドライブの SCSIバスコントローラは他のほとんどの SCSIドライブとピン配置が逆です. Anaconda テープドライブの前後でSCSIケー ブルを1/2ひねることができるくらい SCSI ケーブルが長いことを確認しておく か, 他の SCSIデバイスのピン配置を入れ換えておく必要 があります. そして, このドライブではカーネルコードの変更が 2箇所必要です. そ のままではうまく動かないでしょう. SCSI-2コントローラを持っているなら, ジャンパの 6番をショート してください. そうしないとこのドライブは SCSI-1として働きます. SCSI-1の デバイスとして動作する時, このドライブはテープのfsf (早送り), rewind (巻 戻し),rewoffl (巻戻してオフラインにする) 等を含む操作を行っている間, SCSIバスをロックします. NCR SCSIコントローラを使う場合, /usr/src/sys/pci/ncr.c (以 下を参照してください)にパッチを行って, カーネルを作り直し, 新しいカーネ ルをインストールしてください. *** 4831,4835 **** }; ! if (np->latetime>4) { /* ** Although we tried to wake it up, --- 4831,4836 ---- }; ! if (np->latetime>1200) { /* ** Although we tried to wake it up, 報告者: &a.jmb; Archive Python 28454 このドライブのブートメッセージの識別子は ARCHIVE Python 28454-XXX4ASB type 1 removable SCSI 2 density code 0x8c, 512-byte blocks です. これは DDS-1 テープドライブです. 90m テープを使った場合の標準容量は 2.5GBです. データ転送速度は不明です. このドライブは Sun マイクロシステムが再パッケージして model 595-3067として出しています. 報告者: Bob Bishop rb@gid.co.uk スループットは 1.5 MByte/sec クラスですが, ディスクとテープが同じ SCSI コントローラに接続されている 場合には遅くなってしまいます. 報告者: Robert E. Seastrom rs@seastrom.com Archive Python 04687 このドライブのブートメッセージの識別子はARCHIVE Python 04687-XXX 6580 Removable Sequential Access SCSI-2 deviceです. これは DAT-DDS-2 ドライブです. 120m テープを使った場合の標準容量は 2.5GBです. このドライブはハードウェアデータ圧縮をサポートしています. スイッチ4は MRS (Media Recognition System:メディア認識システム )をコントロールします. MRSテープの透明なテープリーダー部分には しま模様があります. スイッチ 4 をoff にすると MRS が有効に, on にすると MRS が無効になります. パリティはスイッチ 5 でコントロールされます. スイッチ 5 を on にするとパリティが有効になります. 圧縮は スイッチ 6 off で有効です. 圧縮については SCSI MODE SELECT コマンド (see &man.mt.1;) の指定が優先されます. データ転送レートは 800kB/s です. Archive Viper 60 このドライブのブートメッセージ識別子は ARCHIVE VIPER 60 21116 -007 type 1 removable SCSI 1 です. これは QICテープドライブです. 標準の容量は 60MB です. データ転送レートは不明です. このドライブは生産中止になっています. 報告者: Philippe Regnauld regnauld@hsc.fr Archive Viper 150 このドライブのブートメッセージの識別子は ARCHIVE VIPER 150 21531 -004 Archive Viper 150 is a known rogue type 1 removable SCSI 1です. このドライブのファームウェアには多くのリビジョ ンがあります. あなたのドライブではことなった数字が表示されるかもしれま せん(例えば 21247 -005). これは QICテープドライブです. 標準容量は 150/250MBです. 150MB (DC6150) テープと 250MB (DC6250)テープの記録フォーマットがあります. 250MBテープは およそ67% 150MBテープより長いです. このドライブは 120MBのテープを問題 なく読むことができます. 120MBテープに書き込むことはできません. データ転送レートは100kB/sです. このドライブは DC6150 (150MB) と DC6250 (250MB) テープの読み 書きができます. このドライブの奇妙な癖は SCSIテープデバイスドライバはあら かじめ (&man.st.4;) にあらかじめ組み込まれています. FreeBSD 2.2-CURRENTでは, ブロックサイズの設定を設定するためmt blocksize 512としてください. (ファームウェアリビジョンが 21247 -005 である場合の問題です. 他のリビジョンのファームウェアでは異 なる場合があります.) これ以前の FreeBSDバージョンにはこの問題はありません. このドライブは生産中止になっています. 報告者: Pedro A M Vazquez vazquez@IQM.Unicamp.BR &a.msmith; Archive Viper 2525 このドライブのブートメッセージの識別子は ARCHIVE VIPER 2525 25462 -011 type 1 removable SCSI 1です. これは QICテープドライブです. 標準容量は 525MBです. データ転送レートは 90inch/secの場合で 180kB/sです. QIC-525, QIC-150, QIC-120, QIC-24のテープを読むことができま す. QIC-525, QIC-150, QIC-120 に書き込むことができます. ファームウェアのリビジョンが 25462 -011 以前の物はバグが 多く, 正しく機能しません. このドライブは生産中止になっています. Conner 420R このドライブのブートメッセージの識別子は Conner tape です. これはフロッピーコントローラを 使うミニカートリッジテープド ライブです. 標準容量は不明です. データ転送レートは不明です. このドライブは QIC-80テープドライブを使います. 報告者: Mark Hannon mark@seeware.DIALix.oz.au Conner CTMS 3200 このドライブのブートメッセージの識別子は CONNER CTMS 3200 7.00 type 1 removable SCSI 2 です. これはミニカートリッジテープドライブです. 標準容量は不明です. データ転送レートは不明です. このドライブは QIC-3080テープカートリッジを使います. 報告者: Thomas S. Traylor tst@titan.cs.mci.com <ulink url="http://www.digital.com/info/Customer-Update/931206004.txt.html">DEC TZ87</ulink> このドライブのブートメッセージの識別子は DEC TZ87 (C) DEC 9206 type 1 removable SCSI 2 density code 0x19 です. これは DLTテープドライブです. 標準容量は 10GBです. このドライブはハードウェアデータ圧縮の機能があります. データ転送レートは 1.2MB/sです. このドライブは Quantum DLT2000と同一の物です. このドライブ のファームウェアは Exabyteの 8mmドライブ等のよく知られたいくつかのドラ イブのエミュレートをおこなうよう設定ができます. 報告者: &a.wilko; <ulink url="http://www.Exabyte.COM:80/Products/Minicartridge/2501/Rfeatures.html">Exabyte EXB-2501</ulink> このドライブのブートメッセージ識別子は EXABYTE EXB-2501です. これはミニカートリッジテープドライブです. MC3000XLミニカートリッジを使った時の標準容量は 1GBです. データ転送レートは不明です. このドライブは DC2300 (550MB), DC2750 (750MB), MC3000 (750MB), MC3000XL (1GB) ミニカートリッジの読み書きができます. 注意: このドライブは SCSI-2の仕様に適合していません. このドライブは, フォーマット済みのテープ以外を入れた場合, SCSI MODE_SELCTコマンドで完全にロックアップしてしまいます. このドライブを使 う前に, テープブロックサイズを次のように設定します. &prompt.root; mt -f /dev/st0ctl.0 blocksize 1024 ミニカートリッジは最初に使う前に フォーマットしなければなりません. FreeBSD 2.1.0-RELEASE およびそれ以前の場合は &prompt.root; /sbin/scsi -f /dev/rst0.ctl -s 600 -c "4 0 0 0 0 0" (あるいは, FreeBSD 2.1.5/2.2から scsiformatシェルスクリプトを コピーして持ってきた場合と) FreeBSD 2.1.5およびそれ以降の場合は &prompt.root; /sbin/scsiformat -q -w /dev/rst0.ctl とします. 今のところ, FreeBSDではこのドライブはあまりおすすめできません. 報告者: Bob Beaulieu ez@eztravel.com Exabyte EXB-8200 このドライブのブートメッセージの識別子は EXABYTE EXB-8200 252X type 1 removable SCSI 1です. これは8mmテープドライブです. 標準容量は 2.3GBです. データ転送レートは 270kB/sです. このドライブはブート時の SCSIバスへの応答はわりあい遅いです. カスタムカーネルが必要かもしれません (SCSI_DELAYを 10秒に設定しましょう). 訳注: GENERICカーネルの設定では 15秒になっています. このドライブには非常に多くのファームウェアの 構成があります. あるドライブでは特定のベンダのハードウェアに カスタマイズしてあります. ファームウェアは EPROMを置き換えることで変更できます. このドライブは生産中止になっています. 報告者: &a.msmith; Exabyte EXB-8500 このドライブのブートメッセージの識別子は EXABYTE EXB-8500-85Qanx0 0415 type 1 removable SCSI 2 です. これは 8mmテープドライブです. 標準容量は 5GBです. データ転送レートは 300kB/sです. 報告者: Greg Lehey grog@lemis.de <ulink url="http://www.Exabyte.COM:80/Products/8mm/8505XL/Rfeatures.html">Exabyte EXB-8505</ulink> このドライブのブートメッセージ識別子は EXABYTE EXB-85058SQANXR1 05B0 type 1 removable SCSI 2です. これは 圧縮機能を持った 8mmテープドライブで, EXB-5200 と EXB-8500に対する上位互換品です. 標準容量は 5GBです. このドライブは ハードウェアデータ圧縮機能があります. データ転送レートは 300kB/sです. 報告者: Glen Foster gfoster@gfoster.com Hewlett-Packard HP C1533A このドライブのブートメッセージの識別子は HP C1533A 9503 type 1 removable SCSI 2です. これはDDS-2テープドライブです. DDS-2 とはデータ容量を増や すためにハードウェア圧縮と 狭いトラックを採用したものです. 120mテープを使った場合の標準容量は4GBです. このドライブは ハードウェアデータ圧縮機能があります. データ転送レートは510kB/sです. このドライブはヒューレットパッカード社の 6000eU および 6000i テー プドライブ, C1533A DDS-2 DAT ドライブに使われています. このドライブは 8接点のディップスイッチがあります. FreeBSDで の適切な設定は 1 ON; 2 ON; 3 OFF; 4 ON; 5 ON; 6 ON; 7 ON; 8 ON です. スイッチ 1 スイッチ 2 結果 On On 電源投入時に圧縮 ON, ホストによるコントロール可能 On Off 電源投入時に圧縮 ON, ホストによるコントロール不可 Off On 電源投入時に圧縮 OFF, ホストによるコントロール可能 Off Off 電源投入時に圧縮 OFF, ホストによるコントロール不可 スイッチ 3 は MRS (Media Recognition System :メディア認識システ ム) をコントロールします. MRS テープは透明なテープリーダ部分にしま模 様があります. これはテープが DDS (Digital Data Storage) グレードである ことを示します. しま模様のないテープはライトプロテクトされたものとして 扱います. スイッチ3をOFFにすると MRSが有効になります. スイッチ3をONに すると MRSは無効になります. 訳注: 安価な音楽用のDATテープを使うには MRSをOFFにしておきます このドライブの設定についてのより詳しい情報は HP SureStore Tape Products および Hewlett-Packard Disk and Tape Technical Information をご覧ください. 注意: これらのドライブの品質管理は非常に幅がありま す. ある FreeBSDコアチームのメンバは このドライブを2つ返品しました. 報告者: &a.se; Hewlett-Packard HP 1534A このドライブのブートメッセージの識別子は HP HP35470A T503 type 1 removable SCSI 2 Sequential-Access density code 0x13, variable blocksです. これは DDS-1テープドライブです. DDS-1 は最初の DAT テープフォーマットです. 90m テープを使った場合の標準容量は 2GBです. データ転送レートは 183kB/sです. ヒューレットパッカード社の SureStore 2000i テープドライブ, C35470A DDS フォーマット DATドライブ, C1534A DDS フォーマット DATドライブ, HP C1536A DDS フォーマット DATドライブと 同じ機構を使用しています. HP C1534A DDSフォーマット DATドライブはグリーンと黄色(アンバー) の2つの表示ランプがあります. グリーンのランプは動作状 態を示し, ローディング中はゆっくり点滅, ローディングが終了すると点灯, read/write動作中は速く点滅します. 黄色のランプは警告灯で, クリーニング が必要であるかまたはテープが寿命に近くなるとゆっくり点滅, 致命的なエラー の場合は点灯します(工場での修理が必要かもしれません). 報告者:Gary Crutcher gcrutchr@nightflight.com Hewlett-Packard HP C1553A Autoloading DDS2 このドライブのブートメッセージの識別子は未確認です. これはテープチェンジャ付の DDS-2テープドライブです. DDS-2 とはデータ容量を増や すためにハードウェア圧縮と狭いトラックを 採用したものです. 120mテープを使用した場合の標準容量は 24GB です. このドライブはハードウェアデータ圧縮機能があります. データ転送レートは510kB/s (標準) です. このドライブはヒューレットパッカード社の SureStore 12000e テープドライブに使われています. このドライブはリアパネルに2つの選択スイッチがあります. ファンに近いスイッチは SCSI IDです. もうひとつは 7に設定しておきます. 内部に 4個のスイッチがあります. これらは 1 ON; 2 ON; 3 ON; 4 OFF に設定しておきましょう. 現在のカーネルドライバはボリュームの終りで 自動的にテープを 交換しません. ここに示す shellスクリプトでテープを交換できます. #!/bin/sh PATH="/sbin:/usr/sbin:/bin:/usr/bin"; export PATH usage() { echo "Usage: dds_changer [123456ne] raw-device-name echo "1..6 = Select cartridge" echo "next cartridge" echo "eject magazine" exit 2 } if [ $# -ne 2 ] ; then usage fi cdb3=0 cdb4=0 cdb5=0 case $1 in [123456]) cdb3=$1 cdb4=1 ;; n) ;; e) cdb5=0x80 ;; ?) usage ;; esac scsi -f $2 -s 100 -c "1b 0 0 $cdb3 $cdb4 $cdb5" Hewlett-Packard HP 35450A このドライブのブートメッセージの識別子は HP HP35450A -A C620 type 1 removable SCSI 2 Sequential-Access density code 0x13 です. これは DDS-1テープドライブです. DDS-1 は最初の DAT テープフォーマットです. 標準容量は 1.2GBです. データ転送レートは 160kB/sです. 報告者: Mark Thompson mark.a.thompson@pobox.com Hewlett-Packard HP 35470A このドライブのブートメッセージの識別子は HP HP35470A 9 09 type 1 removable SCSI 2です. これは DDS-1テープドライブです. DDS-1は最初の DAT テープフォーマットです. 90mテープを使用した時の標準容量は 2GBです. データ転送レートは 183kB/sです. これはヒューレットパッカード社の SureStore 2000i テープドライブ, C35470A DDSフォーマットDATドライブ, C1534A DDSフォーマットDATドライブ, HP C1536A DDS フォーマットDATドライブと同 じ機構が使われています. 注意: これらのドライブの品質管理には非常に大き な幅があります. ある FreeBSDコアチームのメンバは 5台のドライブを返品し ました. 9ヶ月以上もったものはありません. 報告者: David Dawes dawes@rf900.physics.usyd.edu.au (9 09) Hewlett-Packard HP 35480A このドライブのブートメッセージの識別子は HP HP35480A 1009 type 1 removable SCSI 2 Sequential-Access density code 0x13 です. これは DDS-DCテープドライブです. DDS-DCはハードウェアデータ 圧縮のついたDDS-1です. DDS-1は最初のDATテープフォーマットです. 90mテープを使った場合の標準容量は 2GBです. 120mテープは使用 できません. このドライブはハードウェア圧縮機能があります. 適切なスイッチ設定に関しては, HP C1533A の節を参照してください. データ転送レートは 183kB/sです. このドライブはヒューレットパッカード社の SureStore 5000eU , 5000i テープドラ イブ, C35480A DDS フォーマット DAT ドライブと同じ機構を使っています. このドライブは時々, テープの eject操作 (mt offline) を行っている時にハングアップすることがあります. テープをejectさせたり, ドライブを回復させるにはフロントパネルのボタンを 押してください. 注意: HP 35480-03110 では特有の問題がありました. 少なくとも2回, FreeBSD 2.1.0 で IBM Server 320に 2940W SCSIコントローラ をつけてこのドライブを使っている時にすべての SCSIディスクのパーティショ ンが失われたことがあります. この問題は解析も解決もできていません. <ulink url="http://www.sel.sony.com/SEL/ccpg/storage/tape/t5000.html">Sony SDT-5000</ulink> これらには少なくとも DDS-1のものと DDS-2のものの2つのモデルが あります. DDS-1のものは SDT-5000 3.02です. DDS-2のものは SONY SDT-5000 327M です. DDS-2バージョンには 1MBのキャッシュがあります. この キャッシュによりあらゆる状況で テープのデータの流れを途切れさせません. このドライブのブートメッセージの識別子は SONY SDT-5000 3.02 type 1 removable SCSI 2 Sequential-Access density code 0x13です. 120mテープを使用した場合の標準容量は 4GBです. このドライブ はハードウェアデータ圧縮機能があります. データ転送レートはドライブのモデルによります. SONY SDT-5000 327M でデータ圧縮を行った場合のレートは 630kB/s です. SONY SDT-5000 3.02では 225kB/sです. Kenneth Merry ken@ulc199.residence.gatech.edu の報告によれば このドライブからデータを読むためには, ブロックサイズを 512バイトにしま す (mt blocksize 512). SONY SDT-5000 327M の情報は Charles Henrich henrich@msu.edu による報告です. 報告者: &a.jmz; Tandberg TDC 3600 このドライブのブートメッセージの識別子は TANDBERG TDC 3600 =08: type 1 removable SCSI 2です. このドライブはQIC テープドライブです. 標準容量は150/250MBです. このドライブには奇妙な癖があることが知られていますが, SCSIテープドライバ (&man.st.4;) には問題なく動くコードが含まれてい ます. 問題の修整とSCSI 2へのコンパチビリティを得るためにファームウェ アをある (具体的には不明の) バージョンより上にしてください. データ転送レートは80kB/sです. IBMと Emerald製品のユニットは動かないでしょう. 問題を解決するためにファームウェア EPROMを交換してください. 報告者: &a.msmith; Tandberg TDC 3620 これは Tandberg TDC 3600ドライ ブに非常によく似ています. 報告者: &a.joerg; Tandberg TDC 3800 このドライブのブートメッセージの識別子は TANDBERG TDC 3800 =04Y Removable Sequential Access SCSI-2 device です. これは QIC テープドライブです. 標準容量は 525MB です. 報告者: &a.jhs; Tandberg TDC 4222 このドライブのブートメッセージの識別子は TANDBERG TDC 4222 =07 type 1 removable SCSI 2です. これは QICテープドライブです. 標準容量は2.5GBです. このドライブは 60M (DC600A) 以上のすべての カートリッジを読むことができ, 150MB (DC6150) 以上のすべてのカートリッジを 読み書きできます. ハードウェア圧縮は 2.5GB カートリッジを使用した時の オプションとしてサポートされています. このドライブには奇妙な癖がありますが, FreeBSD の 2.2-CURRENT以降の SCSIテープデバイスドライバ (&man.st.4;) には対応が組み込まれています. それ以前のバージョンの FreeBSDではmtを用いてテープから1ブロッ ク読み, テープを巻戻してからバックアッププログラムを 実行してください. (mt fsr 1; mt rewind; dump ...). データ転送レートは 600kB/s (データ圧縮時のベンダによる公称) で, start/stop モードでも 350kB/s にはなります. 容量の小さいカー トリッジを使った場合にはレートは下がります. 報告者: &a.joerg; Wangtek 5525ES このドライブのブートメッセージの識別子は WANGTEK 5525ES SCSI REV7 3R1 type 1 removable SCSI 1 density code 0x11, 1024-byte blocksです. これは QICテープドライブです. 標準容量は 525MBです. データ転送レートは 180kB/sです. 60, 120, 150, 525MB のテープを読むことができます. 60MB (DC600カートリッジ) には書き込むことはできません. 120および150テー プに確実に上書きするには, 先にテープを消去 (mt erase) します. 120および 150のテープは 525MBのテープより幅の広いトラックを使用してい ます(テープ当たりのトラック数は少なくなります). トラックの幅の外側には上書きされませんので, テープが消去されない限り 両側に古いデータが残ったまま 新しいデータが置かれることになります. このドライブの奇妙な癖は知られていて, SCSI テープドライバ (&man.st.4;) に組み込まれています. 他のファームウェアのリビジョンで動くことが 確認されているも のは M75Dです. 報告者: Marc van Kempen marc@bowtie.nl REV73R1 Andrew Gordon Andrew.Gordon@net-tel.co.uk M75D Wangtek 6200 このドライブのブートメッセージの識別子は WANGTEK 6200-HS 4B18 type 1 removable SCSI 2 Sequential-Access density code 0x13です. これは DDS-1テープドライブです. 90mテープを使用した場合の標準容量は 2GBです. データ転送レートは 150kB/sです. 報告者: Tony Kimball alk@Think.COM * 問題のあるドライブ CDROM ドライブ 原作: &a.obrien;. 23 November 1997. Jordan 氏の選んだ組合せ でふれられているように FreeBSD プロジェクトでは一般的には IDE CDROM よりも SCSI CDROM の方が好まれています. しかし全ての SCSI CDROM ドライブが同じであるというわけではありません. いくつかの SCSI CDROM ドライブの品質は IDE CDROM ドライブよりも 低いものであると感じている人もいます. 東芝は信頼性が高いという評判が ありましたが, 12倍速の XM-5701A は, SCSI メーリングリストでは ( オーディオ CDROM の再生で) 何種類かのオーディオ再生ソフトウェアで ボリュームのコントロールができない, という不満のメールを大量に 見ることがありました. SCSI CDROM のメーカー間の競争のもう一つの局面は, SCSI 規格に対する忠実度です. 多くの SCSI CDROM は ターゲットアドレス(ID)の マルチ LUN に応答します. 既知の規格違反デバイスにはティアックの6倍速ドライブ CD-56S 1.0D があります. * その他 * その他 * PCMCIA diff --git a/ja_JP.eucJP/books/handbook/mail/chapter.sgml b/ja_JP.eucJP/books/handbook/mail/chapter.sgml index 1527da2dca..94beacffee 100644 --- a/ja_JP.eucJP/books/handbook/mail/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/mail/chapter.sgml @@ -1,1537 +1,1537 @@ Bill Lloyd 原作: Jim Mock 改訂: 電子メール 訳: &a.jp.mihoko;. 14 January 1997. この章では email 電子メール 電子メール、email としてのほうが知られているでしょう、 は現代で最も広く利用されているコミュニケーション手段の一つです。 この章では FreeBSD 上でメールサーバを実行するための基本的な導入を説明します。 しかし、この文書は完璧な参考文献ではなく、 実際のところ考慮すべき重要な点の多くが省略されています。 この件について、より網羅したものについては に掲載されている多くの優れた書籍を参照してください。 この章では、以下の分野について説明します。 電子メールの送受信に関係しているソフトウェアの構成要素 FreeBSD における sendmail の基本的な設定ファイルのある場所 スパマーがあなたのメールサーバを踏台として不正に使用することを防ぐ方法 あなたのシステムに sendmail の置き換えとなる代替の MTA をインストールして設定する方法 メールサーバにまつわる共通の問題の解決法 UUCP とともに SMTP を使う方法 ダイアルアップ接続でメールを使う方法 セキュリティを向上するために SMTP 認証を設定する方法 この章を読む前に、以下のことを理解しておく必要があります。 ネットワーク接続の適切な設定方法 () あなたのメールホストに対する DNS 情報の適切な設定方法 () サードパーティ製ソフトウェアのインストール方法 () 電子メールを使う POP IMAP DNS email の交換には 5 つの主要な部分があります。 それらは ユーザープログラム、 サーバーデーモン、 DNS、 POP もしくは IMAP のデーモン、 そしてもちろん メールホストです。 ユーザープログラム いくつか名前を挙げれば、 mutt, pine, elm そして mail といったコマンドラインプログラムや balsa, xfmail のような GUI プログラム、WWW ブラウザーのようにさらに 洗練された ものまであります。 これらのプログラムは、email の処理を server daemons を呼び出したり TCP 経由で渡したり、といった手段でローカルの メールホスト に任せるだけです。 メールホストサーバデーモン メールサーバデーモン sendmail メールサーバデーモン postfix メールサーバデーモン qmail メールサーバデーモン exim 通常、これは sendmail (FreeBSD のデフォルト) や qmail, postfix もしくは exim といった他のメールサーバーデーモンの一つです。 他にもあるのですが、以上のものが広く使われています。 サーバーデーモンは通常 2 つの機能 — やってくるメールを受け取るのと出ていくメールを配送する、 を持っています。メールを読むために POP や IMAP で接続する、 ということはできません。 そのためにはもう一つデーモンが必要なのです。 いくつかの古いバージョンの sendmail には深刻なセキュリティ問題がありますが、 現在のバージョンを使っているおれば特に問題ないことに注意してください。 例のごとく、 どんなソフトウェアを利用する時にも最新の状態にしておくのが大事なのです。 Email と DNS Domain Name System (DNS) とそのデーモンである named は email の配送において大変重要な役割を担ってます。 あなたのサイトからもう一つのサイトへメールを配送するためには、 サーバーデーモンは DNS からそのサイトを探し、 メールの受け取り先のホストを決定します。 メールがあなたに送られた場合にも同じような仕組みになっています。 DNS にはホスト名と IP アドレス、ホスト名とメールホストをマッピングするデータベースがあります。 IP アドレスは A レコードで指定されます。 MX (Mail eXchanger) レコードはあなた宛のメールを受け取るホストを指定します。 あなたのホスト名に対する MX レコードがない場合には、 メールは直接あなたのホストに配送されます。 メールの受け取り email 受け取り メールはメールホストが受け取ります。 このホストは送られてきたメールを集め、 (ユーザーが) 読んだりピックアップしたりするために保存します。 保存されているメールをピックアップするにはメールホストに接続する必要があります。 これは POP や IMAP を用いて行なわれます。 メールホスト上で直接メールを読みたい時は POP や IMAP のサーバーは必要ありません。 POP IMAP POP や IMAP のサーバーを走らせるためには 2 つのことをやらなければいけません。 POP や IMAP のデーモンを ports コレクション からインストールします。 /etc/inetd.conf を修正して POP や IMAP のサーバーが起動されるように設定します。 メールホスト メールホスト メールホストとは責任をもってメールを配送したり、 あなたのホストや、もしかするネットワークも、に宛てたメールを受け取ったりするホストに与えられる名前です。 Christopher Shumway 寄稿: <application>sendmail</application> の設定 sendmail &man.sendmail.8; は FreeBSD のデフォルトの メールトランスファエージェント (MTA) です。 sendmail の仕事はメールユーザエージェント (MUA) からのメールを受け取り、 それを設定ファイルで定義された適当なメーラに届けることです。 sendmail はネットワーク接続を受け入れて、 ローカルのメールボックスにメールを届けたり 別のプログラムにメールを渡したりもできます。 sendmail は次の設定ファイルを使用します。 /etc/mail/access /etc/mail/aliases /etc/mail/local-host-names /etc/mail/mailer.conf /etc/mail/mailertable /etc/mail/sendmail.cf /etc/mail/virtusertable ファイル名 機能 /etc/mail/access sendmail アクセスデータベースファイル /etc/mail/aliases メールボックスエイリアス /etc/mail/local-host-names sendmail が受け付ける配送先ホストのリスト /etc/mail/mailer.conf メーラプログラムの設定 /etc/mail/mailertable メーラ配送表 /etc/mail/sendmail.cf sendmail の主設定ファイル /etc/mail/virtusertable 仮想ユーザおよび仮想ドメイン表 <filename>/etc/mail/access</filename> アクセスデータベースは、 どのホストまたは IP アドレスがローカルメールサーバに接続できるか、 そして接続の種類は何か、ということを定義します。 ホストは , , として指定できます。 または、メーラエラーを指定することで、 単に sendmail の エラー処理ルーチンに渡されます。 として指定されたホスト (これはデフォルトです) は、 メールの最終宛先がローカルマシンである限り、 このホストへメールを送ることを認められます。 として指定されたホストは、 すべてのメール接続を拒絶されます。 ホスト名に対して オプションを指定されたホストは、 このメールサーバを通過して任意の宛先へメールを送ることを認められます。 <application>sendmail</application> アクセスデータベースの設定 cyberspammer.com 550 We don't accept mail from spammers FREE.STEALTH.MAILER@ 550 We don't accept mail from spammers another.source.of.spam REJECT okay.cyberspammer.com OK 128.32 RELAY この例では五つのエントリがあります。 表の左側に当てはまるメール送信者は、表の右側の動作に支配されます。 はじめの二つの例は、エラーコードを sendmail のエラー処理ルーチンに渡します。 メールが表の左側に当てはまると、リモートホストにそのメッセージが表示されます。 次のエントリは another.source.of.spam というインターネット上の特定のホストからのメールを拒絶します。 次のエントリは okay.cyberspammer.com からのメール接続を受け入れます。 このエントリは上にある cyberspammer.com という行よりもさらに厳密です (厳密に一致すればするほど、そうでないものより優先されます)。 最後のエントリは 128.32 から始まる IP アドレスのホストからの電子メールのリレーを認めます。 これらのホストは他のメールサーバに到達できるこのメールサーバを使ってメールを送ることができるでしょう。 このファイルを変更したら、 データベースを更新するために /etc/mail/ ディレクトリで make コマンドを実行する必要があります。 <filename>/etc/mail/aliases</filename> エイリアスデータベースには、 他のユーザ、ファイル、プログラムまたは他のエイリアスに展開される 仮想的なメールボックスの一覧が記載されています。 /etc/mail/aliases において使用できる例をいくつかあげます。 メールエイリアス root: localuser ftp-bugs: joe,eric,paul bit.bucket: /dev/null procmail: "|/usr/local/bin/procmail" ファイル形式はシンプルです。 コロンの左側にあるメールボックス名は、右側のターゲットに展開されます。 はじめの例は単純に root のメールボックスを localuser のメールボックスに展開し、 それからエイリアスデータベースをもう一度調べます。 一致するエントリがなければメッセージはローカルユーザである localuser に配送されます。 次の例はメールリストです。 ftp-bugs のメールボックスへのメールは joe, eric および paul の三つのローカルメールボックスに展開されます。 リモートメールボックスは user@example.com のように指定できることに注意してください。 次の例はメールをファイル、この場合 /dev/null に書き込みます。 最後の例はメールをプログラムに送ります。 この場合メールのメッセージは &unix; パイプを通じて /usr/local/bin/procmail の標準入力に書き込まれます。 このファイルを変更したら、 データベースを更新するために/etc/mail/ ディレクトリで make コマンドを実行する必要があります。 <filename>/etc/mail/local-host-names</filename> これは &man.sendmail.8; がローカルホスト名として認めるホスト名のリストです。 sendmail がメールを受け取るすべてのドメインやホストにこのファイルを置いてください。 たとえば、このメールサーバは example.com というドメインおよび mail.example.com というホストへのメールを受け取るとすると、 local-host-names ファイルの内容は次のようになるでしょう。 example.com mail.example.com このファイルを更新したら、変更を読み込むために &man.sendmail.8; を再起動する必要があります。 <filename>/etc/mail/sendmail.cf</filename> sendmail の主設定ファイルである sendmail.cf は、電子メールアドレスの書き換えから、 リモートメールサーバへ拒絶メッセージを送ることまで sendmail の全般的な動作をすべて制御します。 当然、そのようなさまざまな役割によりこの設定ファイルは大変複雑で、 その詳細についてはこの節の少し範囲外です。好運なことに、 標準的な構成のメールサーバではこのファイルをめったに変更する必要はありません。 sendmail の主設定ファイルは sendmail の機能と動作を決定する &man.m4.1 マクロから構築できます。 詳細については /usr/src/contrib/sendmail/cf/README を参照してください。 このファイルを更新したら、その変更を反映するために sendmail を再起動する必要があります。 <filename>/etc/mail/virtusertable</filename> virtusertable は仮想ドメインおよび仮想メールボックスに対するアドレスを実際のメールボックスと対応づけます。 これらのメールボックスにはローカル、リモート、 /etc/mail/aliases に定義されたエイリアス、 またはファイルを使用できます。 仮想ドメインメール対応表の例 root@example.com root postmaster@example.com postmaster@noc.example.net @example.com joe 上の例では example.com ドメインへの対応づけをしています。 このファイルはファイルの下までファーストマッチ (訳注: 一致するルールが複数ある場合、 一番最初に一致したルールが適用されること) で処理されます。 はじめの行では root@example.com を ローカルの root メールボックスに対応づけています。 次のエントリでは postmaster@example.com を noc.example.net ホスト上の postmaster メールボックスに対応づけています。 最後に、今までのところでは example.com に関して何も一致しない場合、最後のエントリと一致するでしょう。 これは example.com の誰かに送ったすべてのメールが一致します。これは joe のローカルメールボックスに対応づけられています。 Andrew Boothman 原作: Gregory Neil Shapiro Information taken from e-mails written by MTA の変更 email MTA の変更 すでに述べたように、FreeBSD には MTA (Mail Transfer Agent) として、 sendmail がすでにインストールされています。 したがって、デフォルトではこれがメールの送受信を担当しています。 しかしながら、さまざまな理由によって、 システムの MTA を変更しようと考えるシステム管理者もいるかもしれません。 その理由は、単に他の MTA を試してみたいというものから 他のメーラに依存する特定の機能やパッケージが必要だといったものまで、 多岐にわたることでしょう。 幸い、理由がどんなものであれ、FreeBSD では簡単に変更できます。 新しい MTA のインストール さまざまな MTA が利用できます。 FreeBSD Ports Collection から探しはじめるのがよいでしょう。 もちろん、どんな場所からでも、あなたが利用したい MTA が FreeBSD で動作する限りすべて自由に使えます。 新しい MTA をインストールすることからはじめましょう。 新しい MTA をインストールすると、 あなたの要求が実際に実現したかどうか決める機会が与えられます。さらに、 サービスを sendmail から引き継ぐ前に 新しいソフトウェアを設定する機会が与えられます。これを行う場合、 新しいソフトウェアが /usr/bin/sendmail のようなシステムバイナリを上書きしようとしないことを確認してください。 そうしないとあなたが設定する前に新しいメールソフトウェアが本格的に動作しはじめてしまいます。 あなたが選択したソフトウェアを設定する方法についての情報は、 その MTA の文書を参照してください。 <application>sendmail</application> を無効にする sendmail を起動するために使用されていた手続きは、 4.5-RELEASE と 4.6-RELEASE の間で著しく変更されました。 したがって、それを無効にするための手続きは微妙に違います。 2002 年 4 月 4 日より前の FreeBSD 4.5-STABLE (4.5-RELEASE とそれ以前のバージョンが該当) /etc/rc.conf に次の行を加えてください。 sendmail_enable="NO" これは sendmail のメール受信機能を無効にします。 しかし /etc/mail/mailer.conf (下記参照) が変更されていなければ、sendmail はメールの送信にまだ使われるでしょう。 2002 年 4 月 4 日以降の FreeBSD 4.5-STABLE (4.6-RELEASE とそれ以降のバージョンが該当) sendmail を完全に無効にするためには /etc/rc.conf に次の行を加えなくてはいけません。 sendmail_enable="NONE" もしこの方法で sendmail のメール送信機能を無効にしたのなら、 完全に動作する代替メール配送システムと置き換えることが重要です。 さもなければ、&man.periodic.8; などのシステム機能は、 それらの結果を通常想定しているようにメールで配送することができなくなるでしょう。 システムの多くの部分が sendmail 互換のシステムがあることを想定しているかもしれません。 もしそれらを無効にした後に、 アプリケーションがメールを送ろうとするために sendmail のバイナリを使用し続ければ、 メールは使われていない sendmail のキューに入り、そして決して配送されないでしょう。 もし sendmail のメール受信機能だけを無効にしたいのなら /etc/rc.conf に以下の行を追加してください。 sendmail_enable="NO" sendmailの起動オプションに関する詳細は &man.rc.sendmail.8; マニュアルをご覧ください。 起動時に新しい MTA を起動する 起動時に新しい MTA を起動するには二つの選択肢があります。 ここでも、あなたが稼働させている FreeBSD のバージョンに依存します 2002 年 4 月 11 日より前の FreeBSD 4.5-STABLE (4.5-RELEASE とそれ以前のバージョンが該当) /usr/local/etc/rc.d/ ディレクトリに、 ファイル名が .sh でおわり、 root によって実行可能なスクリプトを追加します。 このスクリプトは start および stop パラメータを引数として受け付けるようにします。 起動時にシステムスクリプトは次のコマンドを実行するでしょう。 /usr/local/etc/rc.d/supermailer.sh start これは手動でサーバを起動するためにも使用できます。 システム終了時にはシステムスクリプトは stop オプションを使用して、次のコマンドを実行するでしょう。 /usr/local/etc/rc.d/supermailer.sh stop これはシステムが稼働している間に手動でサーバを停止するためにも使えます。 2002 年 4 月 11 日以降の FreeBSD 4.5-STABLE (4.6-RELEASE とそれ以降のバージョンが該当) より新しいバージョンの FreeBSD では、 上記の方法または次の行を /etc/rc.conf に設定できます。 mta_start_script="filename" filename は、あなたが MTA を立ち上げるために起動時に実行するスクリプト名です。 システムのデフォルトメーラとして <application>sendmail</application> を置き換える sendmail プログラムは &unix; システム上の標準ソフトウェアとして本当にどこでも利用できるので、 これがすでにインストールおよび設定されているとみなしている ソフトウェアもあるかもしれません。 この理由により、代替となる MTA の多くは sendmail コマンドラインインタフェースと 互換性のある実装を提供しています。 これを 差し込む ことによって、 sendmail の置き換えとして代替 MTA を使用することが容易になります。 したがって、あなたが互換メーラを使用しているときには、 /usr/bin/sendmail のような標準 sendmail バイナリを実行しようとするソフトウェアが、 実際にはその代わりにあなたの選択したメーラを実行しているということを 確かめる必要があるでしょう。 好運なことに、FreeBSD はこの仕事をする &man.mailwrapper.8; と呼ばれるシステムを提供しています。 インストールされたまま sendmail が稼働しているときには /etc/mail/mailer.conf には以下のような記述があるでしょう。 sendmail /usr/libexec/sendmail/sendmail send-mail /usr/libexec/sendmail/sendmail mailq /usr/libexec/sendmail/sendmail newaliases /usr/libexec/sendmail/sendmail hoststat /usr/libexec/sendmail/sendmail purgestat /usr/libexec/sendmail/sendmail このことは、これらのうちどの共通コマンド (sendmail 自身のような) が実行されても、 システムは mailer.conf を確認して、 代わりに /usr/libexec/sendmail/sendmail を実行する sendmail という名前の mailwapper のコピーを呼び出すことを意味します。 このようなシステムでは、デフォルトの sendmail が呼び出されたときに、 どのバイナリが実際に実行されるかを変更するのが簡単になります。 したがって、sendmail の代わりに /usr/local/supermailer/bin/sendmail-compat を実行させたいのなら、次のように /etc/mail/mailer.conf を変更してください。 sendmail /usr/local/supermailer/bin/sendmail-compat send-mail /usr/local/supermailer/bin/sendmail-compat mailq /usr/local/supermailer/bin/mailq-compat newaliases /usr/local/supermailer/bin/newaliases-compat hoststat /usr/local/supermailer/bin/hoststat-compat purgestat /usr/local/supermailer/bin/purgestat-compat 完了 あなたのやりたいようにすべてを設定しおえたら、 もはや必要のない sendmail のプロセスを終了して新しいソフトウェアに関するプロセスを起動するか、 単に再起動してください。 再起動することによって、新しい MTA が起動時に正しく立ち上がるように システムが設定されているかどうか確認することもできるでしょう。 トラブルシュート email トラブルシューティング どうして自分のサイトのホストなのに FQDN を使わなければいけないのですか? 恐らく、そのホストは実際には別のドメインにあるのでしょう。 例えば foo.bar.edu ドメインにいて、 bar.edu というドメイン内の mumble というホストにアクセスしたいとします。 この時は単に mumble ではなく mumble.bar.edu と FQDN で参照しなければなりません。 BIND そもそも、BSD BIND のリゾルバー (resolver) ではこのようなことが可能でしたが、 FreeBSD に入っている最新版の BIND では自分のドメイン以外に対する FQDN でない省略形は許されません。 従ってホストを mumble と曖昧に指定した場合は mumble.foo.bar.edu という名前があればそれになり、 そうでなければ root ドメインから検索されます。 これは、 mumble.bar.edu と mumble.edu ということなったドメイン名に対してホスト名のサーチがおこなわれていた以前の振る舞いとは異なったものです。 このような事が悪い例もしくはセキュリティホールとみなされる理由については RFC 1535 を見てください。 /etc/resolv.conf で domain foo.bar.edu と書いてある行を search foo.bar.edu bar.edu と書き換えることで上のようなことができます。 しかし、RFC 1535 にあるように検索順序が 内部 (local) と外部 (public) の管理の境界 をまたがないようにしてください。 sendmail が mail loops back to myself というメッセージを出すのですが。 sendmail FAQ に次のように書いてあります。 Local configuration error というメッセージが出ます。例えば、 553 relay.domain.net config error: mail loops back to myself 554 <user@domain.net>... Local configuration error のような感じですが、どうしたら解決できますか? これは、例えば domain.net のようなドメイン宛てのメールを MX レコードで特定のホスト(ここでは relay.domain.net) に送ろうとしたのに、 そのホストでは domain.net 宛てのメールを受け取れるような設定になっていない場合です。 設定の際に FEATURE(use_cw_file) を指定してある場合には /etc/mail/local-host-names の中に domain.net を追加してください。 もしくは、/etc/mail/sendmail.cf の中に Cw domain.net を追加してください。 sendmail FAQ は にありますので、 メールの設定に おかしなこと があれば常に読んでください。 PPP ダイアルアップ PPP ホストでメールサーバを実行するにはどうしたらいいの? LAN 上にある FreeBSD マシンを、 インターネットに接続したいとします。FreeBSD マシンは、その LAN でのメールゲートウェイになります。FreeBSD マシンは専用線接続ではありません (訳注: ダイアルアップ接続など)。 UUCP これには、少なくとも二つの方法があります。 一つは UUCP を使うことです。 もう一つの方法は、あなたのドメインに対するセカンダリ MX サービスを提供する常時稼働のインターネットサーバを用意することです。 たとえば、あなたの会社のドメインが example.com で、 ISP があなたのドメインに セカンダリ MX サービスを提供するために example.net ドメインを 用意するとしたら次のようにします。 example.com. MX 10 example.com. MX 20 example.net. 最終的なメール受信先としては、 一つのホストだけが定義されるべきです (example.com 上の /etc/mail/sendmail.cf ファイルに、 Cw example.com を追加します)。 送信側の sendmail が、 メールを配送しようとしている時、モデムの接続を介してあなたのところ (example.com) に接続しようとします。大抵の場合、 あなたのマシンがオンラインでないために、 接続はタイムアウトしてしまうでしょう。 sendmail プログラムは自動的に、 たとえばあなたのインターネットプロバイダなどのセカンダリの MX サイト (example.net) にメールを配送するでしょう。 セカンダリ MX サイトは定期的にあなたのホストに接続し、 プライマリ MX ホスト (example.com) にメールを配送しようとするでしょう。 ログインスクリプトとして、 このようなものを使うとよいでしょう。 #!/bin/sh # Put me in /usr/local/bin/pppmyisp ( sleep 60 ; /usr/sbin/sendmail -q ) & /usr/sbin/ppp -direct pppmyisp ユーザごとにログインスクリプトを作りたい場合には、 上記のスクリプトの代わりに、 sendmail -qRexample.com を使用することもできます。 このようにすると、 キューの中の example.com に対するすべてのメールは、すぐに強制的に処理されます。 さらに、次のような改良もできます。 以下は、&a.isp; メーリングリストから抜粋してきたメッセージです。 > 私たちはお客様に対して、セカンダリ MX を提供しています。 > お客様は一日に何回か私たちのサービスに接続し、メールを彼らのプライマリ MX > に受け取ります (彼らのドメインに対するメールが到着した時には、 > 私たちは彼らのサイトを呼び出しません)。 > 私たちの sendmail は、30 分ごとにメールキューに溜っているメールを配送します。 > ちょうどその時に、すべてのメールがプライマリ MX に送られたかどうかを確かめるためには、 > 彼らは 30 分は オンラインでいなければなりません。 > > すべてのメールを今すぐ送るために sendmail を初期化するコマンドはあるでしょうか? > もちろん私たちのマシン上には、ユーザはルート (root) 権限を持っていません。 sendmail.cf の privacy flags セクションに、 Opgoaway,restrictqrun の定義があります。 root 以外のユーザがキューを処理できるようにするには、 restrictqrun を削除してください。また、MX の再調整が必要かもしれません。 あなたがたは、顧客のサイトに対する一番優先度の高い MX なので、 次のように定義します。 # If we are the best MX for a host, try directly instead of generating # local config error. OwTrue このようにすると、リモートサイトからのメールが、 顧客のマシンと接続しようとせず、直接あなたがたのホストマシンに配送されるようになります。 ホストマシンに配送されたメールは、続いて顧客のマシンに送られます。 これはホスト名にのみ有効なので、顧客のメールマシンに、 host.customer.com とは別に、customer.com も定義する必要があります。 DNS 上で、customer.com に対する A レコードを定義してください。 なぜ他のホストにメールを送ろうとすると、いつも Relaying Denied と怒られてしまうの ? FreeBSD がインストールされたデフォルトの状態では、 sendmail は動作しているホストからのメールだけを送るように設定されています。 たとえば POP3 サーバがインストールされているとすると、 ユーザは学校や職場など他のリモートの場所からメールを確認することが できます。しかし、彼らは外部からそのホスト以外へのメールを 送ることはやはりできません。 通常、メールを送ろうとしてから少しすると、 5.7 Relaying Denied というエラーメッセージの書かれたメールが MAILER-DAEMON から送られてくるでしょう。 これを解決する方法はいくつかあります。 一番の正攻法は /etc/mail/relay-domains リレードメインファイルにあなたの ISP のアドレスを書くことです。 これをするのに簡単な方法は次のとおりです。 &prompt.root; echo "your.isp.example.com" > /etc/mail/relay-domains このファイルを作成または編集したら、 sendmail を再起動してください。 もしあなたがサーバ管理者でメールをローカルに送りたくないか、 ポイントを使用して他のマシン (や、さらに他の ISP) の クライアントまたはシステムへ送りたい時は、とても効果があります。 さらに、あなたが一つあるいは二つだけのメールアカウントを 設定している場合でもこれは非常に有用です。 追加すべきアドレスがたくさんある場合には、 単にこのファイルをあなたの好きなテキストエディタで開いて、 そして一行に一つずつドメインを追加してください。 your.isp.example.com other.isp.example.net users-isp.example.org www.example.org これで、リストに掲載されているすべてのホスト (ユーザがあなたのシステムにアカウントを持っていると規定する) からあなたのシステムを通るすべてのメールは送信に成功するでしょう。 これはあなたのシステムから SPAM を送ることを認めることなく、 リモートであなたのシステムからメールを送ることをユーザに 認めるためのとてもよい方法です。 先進的なトピックス これからのセクションでは、 メールの設定やドメイン全体のためのメールの設定といったさらに突込んだ話題について触れます。 基本事項 email 設定 あなたのマシンに FreeBSD を普通にインストールして、 /etc/resolv.conf ファイルを設定するか、 またはネームサーバを走らせれば、 他のホストへ電子メールを送ることができるようになります。 あなたのホスト宛のメールをあなた自身の FreeBSD ホスト上の MTA (たとえば sendmail) に配送するようにしたい場合には、次の二つの方法があります。 自身でネームサーバーを実行し、 自分のドメインを持つ。例えば FreeBSD.org。 あなたのホストへ直接メールが配送されるようにする。 これはメールがあなたのマシンの現在の DNS 名に直接配送されるようにすることにより実現できます。 たとえば example.FreeBSD.org。 SMTP 上のどちらを選ぶ場合でも、自分のホストに直接メールが配送されるようにするには恒久的で 静的 な IP アドレス (ほとんどの PPP ダイアルアップ設定で用いられる動的なアドレスではなく) を持っていなければなりません。 もしファイアウォールの中にいるならば、 SMTP トラフィックが通過してくれないといけません。 もし自分のホストでメールを直接受け取りたいならば、 次の二つのうちのどちらかができていることを確認してください。 MX レコード 自分のドメインでの (一番値の小さい) MX レコードが自分のホストの IP アドレスを差していることを確認する。 自分のドメインの中に自分のホスト用の MX エントリがないことを確認する。 上のどちらかが設定されていれば、 自分のホストでメールを受け取ることができるでしょう。 次のコマンドを実行してみてください。 &prompt.root; hostname example.FreeBSD.org &prompt.root; host example.FreeBSD.org example.FreeBSD.org has address 204.216.27.XX もしあなたのマシンが上記のメッセージだけを出力したならば、 yourlogin@example.FreeBSD.org へのメールは問題なく配送されるでしょう (sendmail が example.FreeBSD.org 上で正しく動作していると仮定します)。 上記のメッセージの代わりに、 &prompt.root; host example.FreeBSD.org example.FreeBSD.org has address 204.216.27.XX example.FreeBSD.org mail is handled (pri=10) by hub.FreeBSD.org というメッセージが出力された場合は、 あなたのホスト (example.FreeBSD.org) に宛てたメールは全て直接配送されずに hub 上の同じユーザー名に配送されます。 上の情報は DNS サーバーが扱います。 メールルーティング情報をもつ DNS レコードは、 Mail eXchange エントリーです。 MX エントリが存在しない場合には、IP アドレスにしたがって、 直接宛先ホストに配送されます。 freefall.FreeBSD.org の現時点での MX エントリは、次のようになっています。 freefall MX 30 mail.crl.net freefall MX 40 agora.rdrop.com freefall MX 10 freefall.FreeBSD.org freefall MX 20 who.cdrom.com freefall は多くの MX エントリを持っています。 一番 MX の値の小さいホストが利用可能な場合は直接メールを受け取ります。 もしなにかの理由でアクセスができない時には、 他のホスト (ときどき バックアップ MX と呼ばれます) が一時的にメールを受け取ります。そして、 より値の小さいホストが利用可能になったときにメールを渡し、 最終的に一番値の小さいホストに渡ります。 使い勝手をよくするためには、代替の MX サイトは、それぞれ 別の経路でインターネットへ接続しているとよいでしょう。 インターネットプロバイダまたは他の関連サイトが、このサービスを 提供することができます。 あなたのドメインに対するメール設定 メールホスト (メールサーバーとしても知られています) をセットアップするためには、 いろいろなワークステーションに宛てた全てのメールを受ける必要があります。 基本的には、あなたのドメイン内 (この場合だと *.FreeBSD.org) のすべてのホスト名宛てのすべてのメールを 受け取って、 そのメールをあなたのメールサーバーに配送し、 ユーザーがマスタメールサーバ上でメールをチェックできるようにします。 DNS 話を簡単にするために、あるユーザーのアカウントはどのマシンでも同じユーザー名にすべきです。 そのためには &man.adduser.8; を使ってください。 使用する予定のメールホストは、 各ワークステーションごとにメール交換が できるように設定されていなければなりません。 これは DNS の設定で次のように行なうことができます。 example.FreeBSD.org A 204.216.27.XX ; ワークステーション MX 10 hub.FreeBSD.org ; メールホスト これは、ワークステーションの A レコードがどこを指していようとも そのワークステーション宛てのメールをメールホストに転送する、というものです。 自前で DNS サーバを運用しているのでなければ、 この作業は自分では行えません。自分で DNS サーバを運用しないとかできないという場合は、 あなたの DNS を提供しているインターネットプロバイダなどに依頼して 作業を行ってもらってください。 もしバーチャル電子メールホストを運用するなら次の情報が役に立つでしょう。 例として、あなたには自分のドメイン、ここでは customer1.org、 を持っている顧客がいるとしましょう。 あなたは customer1.org 宛ての全てのメールを mail.myhost.com というメールホストに集めたいとします。 DNS エントリーは次のようになるでしょう。 customer1.org MX 10 mail.myhost.com customer1.org に対して電子メールを送りたいだけなら、 A レコードは必要ありません。 customer1.org に対して ping を実行しても、 A レコードが存在しない限りうまくいかないことに留意しておいてください。 やらなければいけない最後のことは、 メールホスト上の sendmail に対してどんあドメインやホスト宛のメールを受け取るのか、 を教えることです。いくつかの方法がありますが次のどちらかでいいでしょう。 FEATURE(use_cw_file) を使っているなら、 /etc/mail/local-host-names ファイルにホストを加えます。 もし sendmail のバージョンが 8.10 より前であれば該当ファイルは /etc/sendmail.cw です。 /etc/sendmail.cf もしくは sendmail 8.10 以降なら /etc/mail/sendmail.cf といったファイルに Cwyour.host.com という行を加えます。 UUCP とともに SMTP を使う FreeBSD とともに出荷されている sendmail の設定は、 サイトがインターネットに直接接続しているものとして設計されています。 UUCP 経由でメールを交換したいサイトは、他にも 設定ファイルをインストールしなければいけません。 /etc/mail/sendmail.cf を手動で調整することは先進的なトピックです。 sendmail のバージョン 8 は設定ファイルを &man.m4.1; プリプロセッサから生成します。 これにより、高度に抽象化された設定を行うことができます。 &man.m4.1; による設定ファイルは /usr/src/usr.sbin/sendmail/cf 以下にあります。 もしシステムをすべてのソースとともにインストールしていなければ、 sendmail の設定材料は分割された個別のソース tarball を取得してください。 FreeBSD のソースコードが入った CDROM をマウントしているのなら、 &prompt.root; cd /cdrom/src &prompt.root; cat scontrib.?? | tar xzf - -C /usr/src/contrib/sendmail と展開してください (展開してもたった数百 KB 程度です)。 cf ディレクトリの README ファイルは m4 による設定の基本的な手引として役に立つでしょう。 UUCP 配送に対応するための一番よい方法は mailertable 機能を使用することです。 これは経路を決定するために sendmail が使用できるデータベースを作成します。 まずはじめに .mc ファイルを作成しなければいけません。 /usr/src/usr.sbin/sendmail/cf/cf にいくつか例があります。foo.mc という名前のファイルをあなたが作成したとすると、 有効な sendmail.cf ファイルへ変換するには次のようにするだけです。 &prompt.root; cd /usr/src/usr.sbin/sendmail/cf/cf &prompt.root; make foo.cf &prompt.root; cp foo.cf /etc/mail/sendmail.cf 典型的な .mc ファイルは次のようになるでしょう。 VERSIONID(`Your version number') OSTYPE(bsd4.4) FEATURE(accept_unresolvable_domains) FEATURE(nocanonify) FEATURE(mailertable, `hash -o /etc/mail/mailertable') define(`UUCP_RELAY', your.uucp.relay) define(`UUCP_MAX_SIZE', 200000) define(`confDONT_PROBE_INTERFACES') MAILER(local) MAILER(smtp) MAILER(uucp) Cw your.alias.host.name Cw youruucpnodename.UUCP accept_unresolvable_domains, nocanonify および confDONT_PROBE_INTERFACES 機能を含んでいる行は、 メール配送時にまったく DNS を使用しません。 UUCP_RELAY の記述は UUCP 配送に対応するのに必要です。 そこにインターネットホスト名を単に書くだけで .UUCP pseudo ドメインアドレスを扱うことができるようになります。 大抵の場合、あなたの ISP のメールリレーをそこに入力するでしょう。 次に、 /etc/mail/mailertable が必要になります。 メールを配送するリンクが外界との間に一つだけの場合は、 次のようにファイルを記述するだけで十分でしょう。 # # makemap hash /etc/mail/mailertable.db < /etc/mail/mailertable . uucp-dom:your.uucp.relay 次はさらに複雑な例です。 # # makemap hash /etc/mail/mailertable.db < /etc/mail/mailertable # horus.interface-business.de uucp-dom:horus .interface-business.de uucp-dom:if-bus interface-business.de uucp-dom:if-bus .heep.sax.de smtp8:%1 horus.UUCP uucp-dom:horus if-bus.UUCP uucp-dom:if-bus . uucp-dom: はじめの三行はドメインで宛先を指定されたメールが、 配送路を 近道 するために、 デフォルトルートではなく代わりにいくつかの UUCP 隣接ホストへ送られる特別な場合を扱います。 次の行はメールを SMTP で配送可能なローカルイーサネットドメインへ送ります。 最後に uucp-neighbor !recipient がデフォルトルートを上書きすることを許可するための UUCP 隣接ホストは .UUCP 仮想ドメイン記法で言及されます。 最後の行は常に他のすべてが当てはまるシングルドットです。 これは UUCP 隣接ホストへの UUCP 配送をすることで、 世界に向けたあなたの普遍的メールゲートウェイとして役に立ちます。 uucp-dom: キーワードの後ろにあるノード名はすべて、 uuname コマンドを使用することで確かめられる正しい UUCP 隣接ホストである必要があります。 このファイルは、実際に使用する前に DBM データベース形式に変換する必要があることに注意してください。 これを実行するコマンドラインは mailertable ファイルの先頭にコメントとして書かれています。 mailertable を変更するたびにいつもこのコマンドを実行する必要があります。 最後のアドバイス: もし、 いくつかのメールルーティングがうまく動いているかどうか分からないときは sendmail に オプションをつけることを覚えておいてください。 これは sendmail を アドレステストモード で起動します。 あなたがテストしたいメールルーティングのアドレスを後につけて、 単純に 3,0 と入力してください。 最後の行は、内部で使われたメールエージェント、 このエージェントが呼び出された目的地ホスト、および (もしかしたら変換された) アドレスを表示します。 このモードを終了するには CtrlD を入力します。 &prompt.user; sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > 3,0 foo@example.com canonify input: foo @ example . com ... parse returns: $# uucp-dom $@ your.uucp.relay $: foo < @ example . com . > > ^D ダイアルアップ接続でメールを使う あなたが固定 IP アドレスを持っているのなら、 デフォルトから何も変更する必要はありません。 割りあてあてられたインターネット名をホスト名に設定すれば、 sendmail が残りをやってくれます。 あなたが動的に割り当てられた IP アドレスを持っていて、 インターネットに接続するのにダイアルアップ PPP を使用しているのなら、 おそらく ISP のメールサーバにメールボックスがあるでしょう。 ここでは、あなたの ISP のドメインが example.net, あなたのユーザ名が user, あなたのマシンは bsd.home と呼ばれているものとします。 また、ISP から、メールリレーとして relay.example.net を使用してよいと通知されているとします。 (訳注: ISP 上の) メールボックスからメールを取得するためには、 取得アプリケーションをインストールしないといけません。 fetchmail ユーティリティは、 さまざまなプロトコルの多くに対応しているのでよい選択肢です。 通常、あなたの ISP は POP3 を提供しています。 あなたが user-PPP を使用しているなら、次のエントリを /etc/ppp/ppp.linkup に追加することで、 - インターネット接続が確立したときに自動的ににメールを取得することができます。 + インターネット接続が確立したときに自動的にメールを取得することができます。 MYADDR: !bg su user -c fetchmail あなたがローカルではないアカウントへのメールを配送するために (下記のような) sendmail を使用しているなら、 インターネット接続が確立するとすぐに、 sendmail があなたのメールキューを処理して欲しいとおそらく考えるでしょう。 これを行うには、/etc/ppp/ppp.linkup ファイルの fetchmail コマンドの後に次のコマンドを追加してください。 !bg su user -c "sendmail -q" bsd.home 上に user というアカウントを所有しているとします。 bsd.home 上の user のホームディレクトリに .fetchmailrc ファイルを作成します。 poll example.net protocol pop3 fetchall pass MySecret このファイルはパスワード MySecret を含んでいるので、user を除く他の誰にも読めるようになっていてはいけません。 正しい from: ヘッダでメールを送るためには、 sendmail が user@bsd.home ではなく user@example.net を使用するようにしなくてはいけません。 また、素早くメール送信をするために sendmail にすべてのメールを relay.example.net 経由で送るようにもしたいかもしれません。 次の .mc ファイルで十分でしょう。 VERSIONID(`bsd.home.mc version 1.0') OSTYPE(bsd4.4)dnl FEATURE(nouucp)dnl MAILER(local)dnl MAILER(smtp)dnl Cwlocalhost Cwbsd.home MASQUERADE_AS(`example.net')dnl FEATURE(allmasquerade)dnl FEATURE(masquerade_envelope)dnl FEATURE(nocanonify)dnl FEATURE(nodns)dnl define(`SMART_HOST', `relay.example.net') Dmbsd.home define(`confDOMAIN_NAME',`bsd.home')dnl define(`confDELIVERY_MODE',`deferred')dnl .mc ファイルを sendmail.cf ファイルに変換する方法の詳細については前の節を参照してください。 また、sendmail.cf ファイルを変更した後は、 sendmail を再起動し忘れないでください。 SMTP 認証 メールサーバ上で SMTP 認証を行うと、 多くの利益があります。 SMTP 認証は sendmail にもう一つのセキュリティ層を追加することができます。 さらに、ホストを切りかえるモバイルユーザにとっては、 その都度メールクライアントの設定を変更せずとも 同じメールサーバを利用できるようになります。 ports から security/cyrus-sasl をインストールします。 この port は security/cyrus-sasl にあります。 security/cyrus-sasl にはここで使用する方法に対する多くのコンパイルオプションがあり、 確実に オプションを選択してください。 security/cyrus-sasl をインストールした後に /usr/local/lib/sasl/Sendmail.conf を編集して (もし無ければ作成して) 次の行を追加してください。 pwcheck_method: passwd この方法は sendmail があなたの FreeBSD の passwd データベースに対して認証することを可能にします。 この方法は SMTP 認証に必要となる、 それぞれのユーザに対する一組の新しいユーザ名とパスワードを 作成する際のトラブルを減らし、 ログインパスワードとメールパスワードを同じままにします。 ここで /etc/make.conf 編集し、 次の行を加えます。 SENDMAIL_CFLAGS=-I/usr/local/include/sasl1 -DSASL SENDMAIL_LDFLAGS=-L/usr/local/lib SENDMAIL_LDADD=-lsasl これらの行は sendmail に対して、 コンパイルするときに cyrus-sasl とリンクするための適切な設定オプションを与えるものです。 sendmail を再コンパイルする前に cyrus-sasl がインストールされていることを確かめてください。 次のコマンドを入力して sendmail を再コンパイルしてください。 &prompt.root; cd /usr/src/usr.sbin/sendmail &prompt.root; make cleandir &prompt.root; make obj &prompt.root; make &prompt.root; make install sendmail のコンパイルは /usr/src が大幅に変更されていなくて、 必要な共有ライブラリが利用可能であれば何の問題も起こらないでしょう。 sendmail をコンパイルして再インストールした後は、 /etc/mail/freebsd.mc ファイル (またはあなたが .mc ファイルとして使用しているファイル。 多くの管理者は唯一の名前を用いるために &man.hostname.1; の出力を .mc として使用することを選んでいます) を編集してください。 次の行を加えてください。 dnl set SASL options TRUST_AUTH_MECH(`GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN')dnl define(`confAUTH_MECHANISMS', `GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN')dnl define(`confDEF_AUTH_INFO', `/etc/mail/auth-info')dnl これらのオプションは、ユーザを認証するために sendmail が利用可能な異なる方法を設定します。 もし pwcheck 以外の方法を使用したいのならドキュメントを参照してください。 最後に /etc/mail で &man.make.1; を実行してください。 これにより、新しい .mc ファイルから freebsd.cf という名前 (またはあなたの .mc に使用している名前) の .cf ファイルが作成されます。 それから make install restart コマンドを実行してください。 新しい .cf ファイルが sendmail.cf にコピーされ、 sendmail が適切に再起動されるでしょう。 この手続きについての詳細は /etc/mail/Makefileを参照してください。 すべてがうまくいけば、ログイン情報をメールクライアントに入力し、 テストメッセージを送ることができるでしょう。 より詳細に調べるには sendmail の を 13 に設定し、 すべてのエラーについて /var/log/maillog を見てください。 このサービスがシステムを起動した後にいつでも利用可能となるように、 /etc/rc.conf に次の行を追加しておくとよいでしょう。 sasl_pwcheck_enable="YES" sasl_pwcheck_program="/usr/local/sbin/pwcheck" これにより、システムの起動時に SMTP_AUTH が確実に初期化されるでしょう。 詳細については SMTP 認証 に関する sendmail の文書を参照してください。 diff --git a/ja_JP.eucJP/books/handbook/multimedia/chapter.sgml b/ja_JP.eucJP/books/handbook/multimedia/chapter.sgml index 1b43a7b6f2..7892c699c2 100644 --- a/ja_JP.eucJP/books/handbook/multimedia/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/multimedia/chapter.sgml @@ -1,1976 +1,1976 @@ Ross Lippert 編集: マルチメディア この章では FreeBSD は数多くの種類のサウンドカードに対応しており、 コンピュータで原音に忠実な出力を楽しむことができます。 これには録音機能と、MPEG Layer 3 Audio (MP3) や WAV, Ogg Vorbis などをはじめとした多くの形式の音楽の再生機能が含まれます。 加えて FreeBSD の Ports Collection には、録音した音楽を 編集したり、音響効果を加えたり、接続された MIDI 機器を制御するためのアプリケーションがあります。 意欲的な試みによって、FreeBSD ではビデオファイルおよび DVD の 再生ができるようになりました。さまざまなビデオメディアをエンコード、 変換、再生するアプリケーションの数は、 音声用のアプリケーションほど充実していません。 この文書を執筆している時点では、たとえば audio/sox のようなファイル形式を変換するためのすぐれたアプリケーションは Ports Collection にありません。しかしながら、 この分野のソフトウェアの状況は急速に変わりつつあります。 この章ではサウンドカードを設定するために必要な方法を説明します (ただし、高音質で再生するためには若干の微調整が必要かもしれません)。 ビデオカードのハードウェアに関する問題は、 X11 () のインストールと設定においてすでに扱いましたので、 そちらをご覧ください。 この章を読むと、以下のことがわかります。 サウンドカードを認識させるためにシステムを設定する方法 サンプルアプリケーションを利用して、サウンドカードが うまく動作しているかどうかテストする方法 サウンドの設定に関するトラブルシューティング MP3 およびその他の形式の音声を再生、エンコードする方法 X サーバで どのようにビデオに対応しているか ビデオを再生、エンコードするのに役に立つ ports DVD の .mpg ファイルおよび .avi ファイルを再生する方法 CD および DVD の情報を抽出する方法 TV カードの設定方法 画像スキャナの設定方法 この章を読む前に、以下のことを理解しておく必要があります。 新しいカーネルを設定してインストールする方法 () オーディオ CD を &man.mount.8; でマウントしようとすると、少なくともエラーになります。 最悪の場合、カーネルパニックが発生するでしょう。 これらのメディアは通常の ISO ファイルシステムとは異なり、 特別なエンコードが施されているからです。 Moses Moore 寄稿: Marc Fonvieille &os; 5.X のための再構成: サウンドカードの設定 システムを設定する PCI ISA サウンドカード 設定をはじめる前に、あなたが持っているカードのモデル、 そのカードが使用しているチップ、そして PCI, ISA どちらのカードなのかを確認する必要があります。 FreeBSD は PCI および ISA の両方のカードに幅広く対応しています。 使用しているカードが対応しているかどうかは、 ハードウェアノート の対応オーディオデバイスの一覧を調べてください。 この文書には、カードに対してどのドライバを利用すればよいか についても言及されています。 カーネル 設定 サウンドデバイスを使うために、 適切なデバイスドライバを読み込まなければいけません。 これには二つの方法のどちらかでできるでしょう。 もっとも簡単な方法は &man.kldload.8; を使ってサウンドカードのカーネルモジュールを単に読み込むことです。 次のコマンドで実現できます。 &prompt.root; kldload snd_emu10k1 または /boot/loader.conf ファイルにこのような適切な行を加えて実現することもできます。 snd_emu10k1_load="YES" 以上は Creative &soundblaster; Live! サウンドカードの例です。 他に利用可能な読み込み可能なサウンドモジュールは /boot/defaults/loader.conf に記載されています。 どのドライバを利用すればいいか確かでなければ、 snd_driver モジュールを読み込んでみてください。 &prompt.root; kldload snd_driver snd_driver モジュールは、 一般に使用されるカードに対応したドライバをまとめて一度に読み込む メタドライバです。このドライバを使用すれば、 速やかに正しいドライバを探し出すことができるでしょう。 /boot/loader.conf ファイルを使用して、 すべてのサウンドドライバを読み込むこともできます。 &os; 4.X ですべてのサウンドドライバを読み込むためには、 snd_driver モジュールの代わりに snd モジュールを使用してください。 二つ目の方法は、 サウンドカードのドライバをカーネルへ静的に組み込むことです。 以下の節では、この方法でハードウェアを対応させる方法を説明します。 カーネル再構築の詳細は を参照してください。 サウンドに対応したカスタムカーネルを設定する はじめに、汎用オーディオドライバ &man.sound.4; をカーネルに追加します。 カーネルコンフィグレーションファイルに以下の行を追加してください。 device sound &os; 4.X では、次の行を使用します。 device pcm 次に、サウンドカードに対応したドライバを追加します。 それには、どのドライバがカードに対応しているかを知る必要があります。 使用しているカードに対する正しいドライバを決定するために、 ハードウェアノート の対応オーディオデバイスの一覧を調べてください。 たとえば、Creative &soundblaster; Live! サウンドカードは &man.snd.emu10k1.4; ドライバが対応しています。 このカードを使用するためには、カーネルコンフィグレーションファイルに 以下の行を追加してください。 device "snd_emu10k1" ドライバのマニュアルページを読んで、 追加すべき構文を調べてください。 カーネルコンフィグレーションファイルにおける サウンドドライバの構文に関する情報は、 /usr/src/sys/conf/NOTES (&os; 4.X では /usr/src/sys/i386/conf/LINT) にもあります。 PnP 非対応の ISA カードでは、 カーネルにカードが使用する資源 (IRQ, I/O ポートなど) を明示的に指定する必要があるかもしれません。 この場合は、/boot/device.hints ファイルを使用してください。 システムの起動時に、&man.loader.8; はこのファイルを読み、設定情報をカーネルに渡します。 たとえば、PnP 非対応の古い Creative &soundblaster; 16 (ISA 接続) には &man.snd.sbc.4; ドライバが対応していますが、 カーネルコンフィグレーションファイルに以下の行を追加すると同時に、 device sbc /boot/device.hints ファイルに以下のエントリを追加してください。 hint.sbc.0.at="isa" hint.sbc.0.port="0x220" hint.sbc.0.irq="5" hint.sbc.0.drq="1" hint.sbc.0.flags="0x15" この例では、 I/O ポートに 0x220 を、 IRQ に 5 を使用します。 /boot/device.hints ファイルに用いるべき構文は、 各ドライバのマニュアルページに記載されています。 &os; 4.X では、 この設定をカーネルコンフィグレーションファイルに直接記述します。 ISA カードでは、たとえば以下のような行を追加してください。 device sbc0 at isa? port 0x220 irq 5 drq 1 flags 0x15 初期設定は以上の通りです。 カードを使用する状況によっては、 IRQ やその他の設定を変更する必要があるかもしれません。 詳細は &man.snd.sbc.4; マニュアルページをご覧ください。 &os; 4.X において、 マザーボードに搭載されたサウンドデバイスを利用するシステムでは、 以下の設定が必要になるかもしれません。 options PNPBIOS サウンドカードのテスト カーネルを変更して再起動するか、必要となるモジュールを読み込むと、 システムのメッセージバッファ (&man.dmesg.8;) にサウンドカードが認識されたことが示されます。 たとえば、次のようなメッセージが出力されます。 pcm0: <Intel ICH3 (82801CA)> port 0xdc80-0xdcbf,0xd800-0xd8ff irq 5 at device 31.5 on pci0 pcm0: [GIANT-LOCKED] pcm0: <Cirrus Logic CS4205 AC97 Codec> サウンドカードの状態は、/dev/sndstat ファイルを使用して確認することができます。 &prompt.root; cat /dev/sndstat FreeBSD Audio Driver (newpcm) Installed devices: pcm0: <Intel ICH3 (82801CA)> at io 0xd800, 0xdc80 irq 5 bufsz 16384 kld snd_ich (1p/2r/0v channels duplex default) この出力はシステムによって異なるでしょう。 pcm デバイスがなければ、 今までの手順を振り返ってみてください。 カーネルコンフィグレーションファイルをもう一度見直して、 正しいデバイスを選択しているかどうか確認してください。 トラブルシューティングは を参照してください。 すべてうまくいけば、サウンドカードが機能するでしょう。 CD-ROM または DVD-ROM ドライブがサウンドカードと適切に接続されていれば、 &man.cdcontrol.1; を使ってドライブ内の CD を再生できます。 &prompt.user; cdcontrol -f /dev/acd0 play 1 audio/workman のように、よりよいインタフェースを提供する さまざまなアプリケーションがあります。 MP3 オーディオファイルを聴くために audio/mpg123 のようなアプリケーションをインストールしようと思うかもしれません。 手っ取り早くカードをテストするには、 /dev/dsp デバイスにデータを送ってみてください。 たとえば、以下のようにします。 &prompt.user; cat filename > /dev/dsp ここで filename はどんなファイルでも構いません。 このコマンドラインを実行すると雑音が発生するはずです。 これにより、サウンドカードが実際に動作していることを確認できます。 &os; 4.X のユーザは、 サウンドカードのデバイスノードを使用前に作成する必要があります。 カードが認識されてメッセージバッファに pcm0 が表示されたなら、 root 権限で次を実行しなければなりません。 &prompt.root; cd /dev &prompt.root; sh MAKEDEV snd0 もしカードが pcm1 として認識されたのなら snd0 を snd1 に置き換えて、上と同様に実行してください。 MAKEDEV を実行すると、サウンド関連のアプリケーションが使用する デバイスノード群が作成されます。 サウンドカードのミキサレベルは &man.mixer.8; コマンドで変更することができます。 詳細は &man.mixer.8; マニュアルページをご覧ください。 よくある問題 デバイスノード I/O ポート IRQ DSP エラー 解決方法 unsupported subdevice XX いくつかのデバイスノードが正しく作成されて いません。上記の手順をくり返してください。 sb_dspwr(XX) timed out 使用する I/O ポートが適切に設定されていません。 bad irq XX 使用する IRQ が正しく設定されていません。 サウンドカードの IRQ と設定した IRQ が同じかどうか確かめてください。 xxx: gus pcm not attached, out of memory デバイスを使用するのに 十分なメモリを確保できません。 xxx: can't open /dev/dsp! fstat | grep dsp を使って、他のアプリケーションがデバイスを 使用しているか調べてください。 注目すべきトラブルメーカは esound と KDE のサウンド機能です。 Munish Chopra 寄稿: 複数音源の利用 特定のアプリケーションとのサウンドデバイスの共用に対応していない時、 esound または artsd のように 同時に再生することのできる音源を複数実装していることは、 多くの場合望ましいことです。 FreeBSD では、 仮想サウンドチャネル を使ってこれを実現でき、&man.sysctl.8; で設定できます。 仮想チャネルはカーネル内でサウンドを合成することにより、 サウンドカードの再生チャネルを多重化することができます。 仮想チャネルの数を決めるのに二つの sysctl 変数を設定できます。 root ユーザで以下のようにします。 &prompt.root; sysctl hw.snd.pcm0.vchans=4 &prompt.root; sysctl hw.snd.maxautovchans=4 上記の例では四つの仮想チャネルを設定しています。 これは通常利用する上で十分実用的な数です。 hw.snd.pcm0.vchans は pcm0 が持っている仮想チャネルの数で、 一度デバイスが取り付けられると設定することができます。 hw.snd.maxautovchans は、 &man.kldload.8; を用いて認識された新しいデバイスの仮想チャネル数です。 pcm モジュールはハードウェアドライバとは独立して読み込むことができるので、 後でどんなにデバイスを認識しても hw.snd.maxautovchans は仮想チャネルを格納できます。 &man.devfs.5; を使用していないのなら、 利用するアプリケーションに /dev/dsp0.x を指定しなければならないでしょう。 上記の例のように仮想チャネル数を 4 に設定すると x は 0 から 3 となります。 &man.devfs.5; を使用しているシステムでは、 ユーザが意識しなくてもこれらが自動的に設定されます。 Josef El-Rayes 寄稿: ミキサチャネルの初期値を設定する 各ミキサチャネルの初期値は &man.pcm.4; ドライバのソースにハードコーディングされています。 起動時に記録していたミキサの値を設定する さまざまなアプリケーションやデーモンがありますが、 あまりよい解決方法ではありません。 &os; 5.3 以降では、適切な値を /boot/device.hints ファイルに記述することにより、 ドライバレベルでミキサの初期値を設定することができます。 たとえば、以下のような行を追加します。 hint.pcm.0.vol="100" この例では、&man.pcm.4; が読み込まれたと同時に、 ボリュームチャネルの初期値を 100 に設定します。 Chern Lee 寄稿: MP3 オーディオ MP3 (MPEG Layer 3 Audio) は CD に匹敵する音質でサウンドを再生できます。あなたの FreeBSD ワークステーションにこのプレイヤをインストールしない理由はないでしょう。 MP3 プレイヤ XMMS (X Multimedia System) は とても人気のある &xfree86; ベースの MP3 プレイヤです。 XMMS のグラフィカルインタフェースは Nullsoft の Winamp とほとんど同一なので、Winamp のスキンを使うことができます。 XMMS はネイティブプラグインにも対応しています。 XMMS は multimedia/xmms の port または package からインストールできます。 XMMS のプレイリスト、グラフィックイコライザそしてその他のインタフェースは 直感的です。 Winamp を使いなれている人は 簡単に XMMS を使えるでしょう。 audio/mpg123 はコマンドライン上の代替となる MP3 プレイヤの port です。 mpg123 は次のようにサウンドデバイスと MP3 ファイルを 指定して実行できます。 &prompt.root; mpg123 -a /dev/dsp1.0 Foobar-GreatestHits.mp3 High Performance MPEG 1.0/2.0/2.5 Audio Player for Layer 1, 2 and 3. Version 0.59r (1999/Jun/15). Written and copyrights by Michael Hipp. Uses code from various people. See 'README' for more! THIS SOFTWARE COMES WITH ABSOLUTELY NO WARRANTY! USE AT YOUR OWN RISK! Playing MPEG stream from Foobar-GreatestHits.mp3 ... MPEG 1.0 layer III, 128 kbit/s, 44100 Hz joint-stereo /dev/dsp1.0 は実際の dsp デバイスのエントリに応じて置き換えられるべきでしょう。 CD 音声トラックの抽出 CD 全体または CD トラックを MP3 に変換する前に、CD 上のオーディオデータをハードディスク上に抽出する必要があります。 これには raw CDDA (CD Digital Audio) データを WAV ファイルにコピーします。 sysutils/cdrtools スイートの一部である cdda2wav ツールは CD からオーディオデータを抽出したり、 情報を関係づけるのに使われます。 CD をドライブにいれて次のコマンドを (rootで) 実行して、 CD 全体を (トラックごとに) 個々の WAV ファイルに抽出できます。 &prompt.root; cdda2wav -D 0,1,0 -B cdda2wav は ATAPI (IDE) CDROM ドライブにも対応しています。 IDE ドライブから抽出するには、 SCSI ユニット番号をデバイス名に置き換えて指定します。 たとえば IDE ドライブから七番目のトラックを抽出するには、 次のようにします。 &prompt.root; cdda2wav -D /dev/acd0a -t 7 は SCSI デバイス 0,1,0 を表します。 これは cdrecord -scanbus の出力に一致します。 個々のトラックを抽出するには、 次のように オプションを使用します。 &prompt.root; cdda2wav -D 0,1,0 -t 7 上記の例はオーディオ CDROM の七番目のトラックを抽出します。 範囲を指定して、 たとえば一番目から七番目のトラックまで抽出したい場合、 次のようにします。 &prompt.root; cdda2wav -D 0,1,0 -t 1+7 &man.dd.1; ユーティリティも ATAPI ドライブ上のオーディオトラックを展開するのに使われます。 何ができるか詳しいことは オーディオ CD の複製について を参照してください。 MP3 のエンコード 現在、一般に好まれている MP3 エンコーダは lame です。 lame は Ports Collection の audio/lame に収録されています。 次のコマンドを実行すると、抽出した WAV ファイル audio01.wav を使って audio01.mp3 に変換します。 &prompt.root; lame -h -b 128 \ --tt "曲名" \ --ta "アーティスト名" \ --tl "アルバム名" \ --ty "年" \ --tc "コメント" \ --tg "ジャンル" \ audio01.wav audio01.mp3 128 kbits が標準のビットレートのようです。 多くの人はさらに高音質の 160 kbits または 192 kbits を好むでしょう。 ビットレートが高くなるにつれて作成される MP3 ファイルは多くのディスク領域を消費しますが、より高音質となります。 オプションを指定すると 低速高品質 モードとなります。 ではじまるオプションは ID3 タグを設定します。 このタグにはたいてい曲の情報が含まれており、 MP3 ファイルに格納されます。 lame のマニュアルを参照すれば他のオプションが見つかるでしょう。 MP3 のデコード MP3 からオーディオ CD を作成するには、 MP3 形式を非圧縮 WAV 形式に変換しなければなりません。 XMMS と mpg123 の両方が MP3 から非圧縮ファイル形式への出力に対応しています。 XMMS でディスクへ書き出す方法は次の通りです。 XMMS を起動します。 右クリックで XMMS メニューを表示します。 Options から Preference を選択します。 Output Plugin を Disk Writer Plugin に変更します。 Configure を押します。 非圧縮ファイルを書き出すディレクトリを入力 (または選択) します。 普段通り XMMS へ MP3 ファイルを読み込みます。 音量は 100% で イコライザの設定はオフにします。 Play を押します— XMMS は MP3 を再生しているかのように表示しますが、 音声はきこえません。 実際には MP3 をファイルに出力しています。 再び MP3 を聴けるように Output Plugin を以前のように元に戻すのを忘れないでください。 mpg123 で標準出力へ書き出す方法は次の通りです。 mpg123 -s audio01.mp3 > audio01.pcm を実行します。 XMMS は WAV 形式でファイルに書き出しますが、 mpg123 は MP3 を PCM オーディオデータに変換します。 両形式は cdrecord を使ってオーディオ CD を作成するのに利用することができます。 &man.burncd.8; を使う場合は raw PCM データが必要です。 WAV ファイルを使用する場合、 それぞれのトラックの先頭に小さなノイズが入るのに気づくでしょう。 これは WAV ファイルのヘッダ情報です。 SoX (audio/sox の port または package からインストールできます) を使うと簡単に WAV ファイルのヘッダ情報を削除できます。 &prompt.user; sox -t wav -r 44100 -s -w -c 2 track.wav track.raw FreeBSD での CD 作成の詳しい情報は を参照してください。 Ross Lippert 寄稿: ビデオ再生 ビデオ再生は今まさに成長中の新しいアプリケーション分野です。 辛抱強くしてください。 音声のようにすべてが順調にいくとは限りません。 設定をはじめる前に、あなたが持っているビデオカードのモデル、 そのカードが使用しているチップを確認する必要があります。 &xorg; および &xfree86; はさまざまなビデオカードに対応していますが、 ビデオ再生に申し分のない性能を発揮できるカードはわずかです。 あなたのビデオカードの利用している X サーバが対応している拡張機能のリストを得るには、 X11 を実行中に &man.xdpyinfo.1; コマンドを実行してください。 さまざまなプレイヤやオプションを試すのに、 テストファイルとして小さな MPEG ファイルを用意しておくのはよい考えです。 いくつかの DVD プレイヤは DVD メディアを /dev/dvd として 初期設定しているか、ハードコーディングされているので、 次のように適切なデバイスにシンボリックリンクを張っておくと便利かもしれません。 &prompt.root; ln -sf /dev/acd0c /dev/dvd &prompt.root; ln -sf /dev/racd0c /dev/rdvd &man.devfs.5; を使う FreeBSD 5.X では、 下記のように少し異なったリンクが推奨されます。 &prompt.root; ln -sf /dev/acd0 /dev/dvd &prompt.root; ln -sf /dev/acd0 /dev/rdvd &man.devfs.5; の仕様により、 このように手動で作成されたリンクは再起動すると消えてしまいます。 システムの起動時にこれらのシンボリックリンクを自動的に作成するには、 /etc/devfs.conf に下記の設定を追加します。 link acd0 dvd link acd0 rdvd 加えて、特別な DVD-ROM 機能を必要とする DVD 解読は、 DVD デバイスへの書き込み権限が必要です。 カーネルオプション options CPU_ENABLE_SSE カーネルオプション options USER_LDT ここで議論する ports のいくつかは、 正しく構築するために次のカーネルオプションが使用できることを期待しています。 port を構築する前に、 次のオプションをカーネルコンフィグレーションファイルに追加し、 新しいカーネルを構築して再起動してください。 option CPU_ENABLE_SSE option USER_LDT option USER_LDT は &os; 5.X にはありません。 共有メモリ X11 インタフェースを改善するために、 いくつかの &man.sysctl.8; 変数の値を増やすことが推奨されています。 kern.ipc.shmmax=67108864 kern.ipc.shmall=32768 ビデオ機能の決定 XVideo SDL DGA X11 においてビデオ表示性能を改善する方法はいくつかあると思われます。 ちゃんと動作するかどうかはハードウェアに大きく依存しています。 下記に説明したどの方法でも、 ハードウェアが変わると品質が変わるでしょう。 二つ目に、X11 でのビデオレンダリングは最近多くの注目を集めるトピックです。 そして &xorg; や &xfree86; のバージョンを追うごとに、著しく改良されているかもしれません。 よく知られたビデオインタフェースは次の通りです。 X11: 共有メモリを用いた通常の X11 出力 XVideo: X11 drawable 内でのビデオ再生に対応した X11 インタフェースの拡張機能 SDL: Simple Directmedia Layer DGA: Direct Graphics Access SVGAlib: 低レベルコンソールグラフィックレイヤ XVideo &xorg; と &xfree86; 4.X には XVideo (または Xvideo, Xv, xv) と呼ばれる拡張機能があります。 これは特別なアクセラレーションによって drawable オブジェクト に直接ビデオを表示することができます。 この拡張機能によって、 低速なマシンでも、とてもすぐれた品質の再生が可能となります。 この拡張機能が動作しているかどうかを調べるには、 xvinfo を使います。 &prompt.user; xvinfo 以下のような結果が得られたならば、あなたのカードは XVideo に対応しています。 X-Video Extension version 2.2 screen #0 Adaptor #0: "Savage Streams Engine" number of ports: 1 port base: 43 operations supported: PutImage supported visuals: depth 16, visualID 0x22 depth 16, visualID 0x23 number of attributes: 5 "XV_COLORKEY" (range 0 to 16777215) client settable attribute client gettable attribute (current value is 2110) "XV_BRIGHTNESS" (range -128 to 127) client settable attribute client gettable attribute (current value is 0) "XV_CONTRAST" (range 0 to 255) client settable attribute client gettable attribute (current value is 128) "XV_SATURATION" (range 0 to 255) client settable attribute client gettable attribute (current value is 128) "XV_HUE" (range -180 to 180) client settable attribute client gettable attribute (current value is 0) maximum XvImage size: 1024 x 1024 Number of image formats: 7 id: 0x32595559 (YUY2) guid: 59555932-0000-0010-8000-00aa00389b71 bits per pixel: 16 number of planes: 1 type: YUV (packed) id: 0x32315659 (YV12) guid: 59563132-0000-0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) id: 0x30323449 (I420) guid: 49343230-0000-0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) id: 0x36315652 (RV16) guid: 52563135-0000-0000-0000-000000000000 bits per pixel: 16 number of planes: 1 type: RGB (packed) depth: 0 red, green, blue masks: 0x1f, 0x3e0, 0x7c00 id: 0x35315652 (RV15) guid: 52563136-0000-0000-0000-000000000000 bits per pixel: 16 number of planes: 1 type: RGB (packed) depth: 0 red, green, blue masks: 0x1f, 0x7e0, 0xf800 id: 0x31313259 (Y211) guid: 59323131-0000-0010-8000-00aa00389b71 bits per pixel: 6 number of planes: 3 type: YUV (packed) id: 0x0 guid: 00000000-0000-0000-0000-000000000000 bits per pixel: 0 number of planes: 0 type: RGB (packed) depth: 1 red, green, blue masks: 0x0, 0x0, 0x0 リストにある形式 (YUV2, YUV12 など) が XVideo のすべての実装で存在するとは限りません。 - 対応している形式が少ないために、あるプレーヤでは悪影響が出る + 対応している形式が少ないために、あるプレイヤでは悪影響が出る かもしれないことにも注意してください。 出力が以下のような場合、 X-Video Extension version 2.2 screen #0 no adaptors present あなたのカードはおそらく XVideo に対応していないのでしょう。 あなたのカードが XVideo に対応していないとしても、 このことはあなたのディスプレイでビデオを表示するのに、 計算上の要求を満たすことがより困難になるだけのことです。 しかしながら、あなたのビデオカードおよびプロセッサによっては、 それでも満足のいく性能が得られるかもしれません。 性能を向上させるには をよく読むとよいでしょう。 Simple Directmedia Layer Simple Directmedia Layer (SDL) は µsoft.windows;, BeOS そして &unix; の間で サウンドとグラフィックスを効果的に利用した クロスプラットホームアプリケーションを 開発することを目的としたレイヤです。 SDL レイヤはハードウェアに対する低レベルの抽象的概念を提供し、 時には X11 インタフェースを使用するよりも効果的なことがあります。 SDL は devel/sdl12 からインストールできます。 Direct Graphics Access Direct Graphics Access は、 プログラムが X サーバを介せず 直接フレームバッファを変更することを可能にする &xfree86; の拡張機能です。 共有メモリを使用するために 低レベルのメモリマッピングが実行できることを期待しているので、 この機能を使うプログラムは root 権限で実行されなければなりません。 DGA 機能拡張は &man.dga.1; によってテストとベンチマークができます。 dga 実行中はキーボードを押せばいつでもディスプレイ色が変更されます。 中止するには q を押します。 ビデオを扱う ports および packages ビデオ ports ビデオ packages この節では Ports Collection で利用可能な、 ビデオの再生に使用できるソフトウェアについて論じます。 ビデオ再生は大変活発なソフト開発分野で、 さまざまなアプリケーションの機能は、 ここでの説明から省かざるをえません。 はじめに、FreeBSD で実行できるビデオアプリケーションの多くは、 Linux アプリケーションとして開発されたということを知ることは重要です。 これらのアプリケーションの多くはまだベータ版の品質です。 FreeBSD でこれらのビデオアプリケーションを使用する際に、 以下のような問題が起こるかもしれません。 あるアプリケーションが、 他のアプリケーションの作成したファイルを再生できない。 あるアプリケーションが、 自身の作成したファイルを再生できない。 二つの異なるマシンで構築した同じアプリケーションが、 同じファイルを再生する挙動がそれぞれ異なる。 イメージサイズ変更のように見たところではありふれたフィルタが、 バグの多いサイズ変更ルーチンによってひどい人工物を作成する。 アプリケーションがよくコアダンプする。 文書が port と一緒にインストールされない (文書は web サイトにあったり、その port の work ディレクトリの中に 残っていることがある)。 これらのアプリケーションの多くはさらに Linux 主義 を主張するかもしれません。 すなわち、アプリケーションの作者が仮定した、 Linux ディストリビューションでのみ実装されている ある標準ライブラリの使用方法や Linux カーネルの特定の機能に起因する問題が生じるかもしれません。 必ずしも port 保守担当者がこれらの問題を把握して作業しているとは限らず、 次のような問題が発生する可能性があります。 プロセッサの特性を検知するための /proc/cpuinfo の利用 本当はプログラムを終了させるはずであるのに、 停止させてしまうようなスレッドの誤用 一般的にアプリケーションとともに使用され、まだ FreeBSD の Ports Collection に収録されていないソフトウェアを必要とする これまで、これらのアプリケーションの開発者は、 移植に必要だったその場しのぎの回避方法を最小化し 問題を解決するために port 保守担当者と協力しています。 MPlayer MPlayer は最近開発され、 - 急激に成長つつあるビデオプレイヤです。 + 急激に成長しつつあるビデオプレイヤです。 MPlayer チームの目的は、 Linux や他の Unix 系 OS 上で高速性と柔軟性をもたらすことです。 このプロジェクトは、 チーム創設者が当時利用可能だったビデオプレイヤの ひどい再生能力にうんざりしたのをきっかけとして始まりました。 合理化された設計のために GUI が犠牲にされたと言う人もいます。 しかしながら、コマンドラインオプションおよびキーボード操作に 一度慣れれば非常によく動作します。 MPlayer の作成 MPlayer 作成 MPlayer は multimedia/mplayer にあります。 MPlayer は 構築の際にさまざまなハードウェアのチェックをするため、 あるシステムで作成されたバイナリは、 別のシステムで利用できないかもしれません。 したがって port から構築し、 バイナリパッケージを利用しないことが重要です。 さらに、Makefile や構築のはじめに説明されるように、 make のコマンドラインで多くのオプションを指定することができます。 &prompt.root; cd /usr/ports/multimedia/mplayer &prompt.root; make N - O - T - E Take a careful look into the Makefile in order to learn how to tune mplayer towards you personal preferences! For example, make WITH_GTK1 builds MPlayer with GTK1-GUI support. If you want to use the GUI, you can either install /usr/ports/multimedia/mplayer-skins or download official skin collections from http://www.mplayerhq.hu/homepage/dload.html ほとんどのユーザにとっては port のデフォルトオプションで十分でしょう。 しかしながら、XviD コーデックが必要なら、 WITH_XVID オプションをコマンドラインで指定しなければなりません。 また、デフォルトの DVD デバイスを WITH_DVD_DEVICE オプションで定義することもできます (デフォルトでは /dev/acd0 が使用されます)。 この文書を執筆している時点では、 MPlayer の port は HTML 文書、そして mplayer と mencoder という二つの実行可能なバイナリを構築します。 mencoder はビデオを再エンコーディングするためのツールです。 MPlayer のための HTML 文書は非常に有益です。この章で不足した ビデオハードウェアおよびインタフェースに関する情報があれば、 MPlayer の文書は非常に詳細な補足になります。 &unix; のビデオ対応情報を探しているのなら、時間を割いて MPlayer の文書を読むべきなのは 明らかです。 MPlayer の使用 MPlayer 使用 MPlayer を使用する人はすべて、 各自のホームディレクトリ内に .mplayer サブディレクトリを用意しなければなりません。 この必要となるサブディレクトリを作成するために、 次のコマンドを入力します。 &prompt.user; cd /usr/ports/multimedia/mplayer &prompt.user; make install-user mplayer のコマンドオプションはマニュアルに記載されています。 さらにより詳細な説明について知りたいなら、HTML 文書をご覧ください。 この節では、一般的な使用法についてほんの少し説明します。 さまざまなビデオインタフェースの一つを用いて testfile.avi というファイルを再生するには、 オプションを指定します。 &prompt.user; mplayer -vo xv testfile.avi &prompt.user; mplayer -vo sdl testfile.avi &prompt.user; mplayer -vo x11 testfile.avi &prompt.root; mplayer -vo dga testfile.avi &prompt.root; mplayer -vo 'sdl:dga' testfile.avi ビデオ再生の相対的性能は多くの要因に依存し、 ハードウェアに応じて著しく変わると思われるので、 これらのオプションをすべて試してみる価値はあるでしょう。 DVD を再生するには、 testfile.avi を に置き換えてください。 <N> には再生するタイトル番号を、 DEVICE は DVD-ROM のデバイスノードを指定します。 たとえば、/dev/dvd から 2 番目のタイトルを再生するには以下のようにします。 &prompt.root; mplayer -vo xv dvd://3 -dvd-device /dev/dvd デフォルトの DVD デバイスは、 MPlayer port の構築時に WITH_DVD_DEVICE で定義することができます。 デフォルトでは /dev/acd0 になります。 詳細はこの port の Makefile をご覧ください。 停止、休止、再生などをするにはキーの割り当てを調べてください。 mplayer -h を実行したり、 マニュアルを読めばわかります。 再生に関してさらに重要なオプションがあります。 全画面モードにする オプションと、 性能を向上させる オプションです。 mplayer に指定するコマンドラインが長くなりすぎないように、 .mplayer/config を作成してデフォルトのオプションを設定できます。 vo=xv fs=yes zoom=yes 最後に mplayer は DVD タイトルを .vob ファイルに抽出するのに使用できます。 DVD から 2 番目のタイトルをダンプするには次のようにします。 &prompt.root; mplayer -dumpstream -dumpfile out.vob dvd://2 -dvd-device /dev/dvd 出力された out.vob ファイルは MPEG 形式で、 この節で説明される他のアプリケーションで編集できます。 mencoder mencoder mencoder を使う前に、 HTML 文書を読んでオプションに慣れておくのはよい考えです。 マニュアルもありますが、HTML 文書なしではあまり有用ではありません。 品質向上、低ビットレート、形式変換をする方法が無数にあります。 これらの要素の調節具合で、性能が良かったり悪かったりするなど、 結果に違いが出るかもしれません。 ここにいくつか例を示します。 はじめは単純なファイルのコピーです。 &prompt.user; mencoder input.avi -oac copy -ovc copy -o output.avi コマンドラインオプションを不適切に組合せると、 mplayer でさえ再生できない出力ファイルを作成してしまいます。 したがって、単にファイルを抽出したいときには、 mplayer に オプションをつけます。 input.avi を音声に MPEG3 エンコードを使用して MPEG4 コーデックに変換するには次のようにします (audio/lame が必要です)。 &prompt.user; mencoder input.avi -oac mp3lame -lameopts br=192 \ -ovc lavc -lavcopts vcodec=mpeg4:vhq -o output.avi これは mplayer や xine で再生可能な出力ファイルを作成します。 DVD タイトルを直接再エンコードするためには、 上記のコマンドラインの input.avi を に置き換えて、 root 権限で実行します。 はじめの作業結果に不満をもつと思われるので、 タイトルをファイルにダンプして、ファイルに対して作業することを おすすめします。 xine ビデオプレイヤ xine ビデオプレイヤは オールインワンのビデオソリューションであるだけでなく、 プラグインで拡張できる再利用可能な基本ライブラリと 実行可能なモジュールを提供する広範囲のプロジェクトです。 multimedia/xine の port と package の両方からインストールできます。 xine プレイヤは開発途上であり まだ非常に荒削りですが、通常の利用には十分安定しています。 実用上、xine を使用するには高速なビデオカードとともに高速な CPU があるか、 またはビデオカードが XVideo 拡張に対応していることが必要です。 GUI も利用できますがすこし扱いにくいです。 この文書を執筆している時点では、 xine と一緒に提供されている CSS エンコードされた DVD を再生する入力モジュールはありません。 このモジュールがあるサードパーティの構築物はいくつかありますが、 これらのどれも FreeBSD の Ports Collection には収録されていません。 xine は MPlayer と比べて 利用者にとって多くのことをしてくれますが、 と同時にきめの細かい制御ができません。なお、 xine ビデオプレイヤは、 XVideo インタフェース上で最良の性能を発揮します。 デフォルトでは、xine プレイヤは GUI 付きで起動するでしょう。 その後、メニューを使用して特定のファイルを開くことができます。 &prompt.user; xine GUI なしでファイルを直ちに再生するには、 次のコマンドを実行します。 &prompt.user; xine -g -p mymovie.avi transcode ユーティリティ transcode というソフトウェアは、プレイヤではなく .avi および .mpg ファイルを再エンコードするためのツール一式です。 transcode を使えば、 stdin/stdout インタフェースとともに コマンドラインツールを用いることによって、 ビデオファイルの統合や、壊れたファイルの修復ができます。 MPlayer と同じように、 transcode は非常に実験的なソフトウェアで、 multimedia/transcode port から構築することをおすすめします。 make コマンドに非常に多くのオプションを指定できますが、 とりわけ次のコマンドで構築するのを推奨します。 &prompt.root; make WITH_LIBMPEG2=yes multimedia/avifile をインストールする予定なら、 次のように make コマンドに WITH_AVIFILE オプションを加えてください。 &prompt.root; make WITH_AVIFILE=yes WITH_LIBMPEG2=yes ここに、サイズを変更した出力を作成するビデオ変換のための transcode の使用例を二つあげます。 一つ目は出力を openDIVX AVI ファイルに変換します。 二つ目はよりポータブルな MPEG 形式のファイルに変換します。 &prompt.user; transcode -i input.vob -x vob -V -Z 320x240 \ -y opendivx -N 0x55 -o output.avi &prompt.user; transcode -i input.vob -x vob -V -Z 320x240 \ -y mpeg -N 0x55 -o output.tmp &prompt.user; tcmplex -o output.mpg -i output.tmp.m1v -p output.tmp.mpa -m 1 transcode のマニュアルもありますが、 同時にインストールされる、 さまざまな tc* ユーティリティ (tcmplex など) に関する文書はほとんどありません。 しかしながら、 コマンドラインオプションを使えば いつでもコマンドの短い使用法を調べることができます。 transcode の動作は mencoder と比較すると著しく遅いです。 しかし、幅広いプラットフォームで再生可能なファイルを 作成する可能性はいっそうすぐれています。 たとえば、transcode で作成した MPEG ファイルは、 旧版の &windows.media; Player および Apple の &quicktime; 上でも再生できることが知られています。 さらに進んだ情報 FreeBSD 用のさまざまなビデオソフトウェアは急速に成長しています。 近い将来、ここにあげた問題の多くが解決している可能性は高いでしょう。 それまでの間、FreeBSD の A/V 能力を最大限発揮させたい人々は、 FAQ およびチュートリアルから得た知識を寄せ集めて、 わずかなアプリケーションを使用しなければならないでしょう。 この節は、読者に そのような付加的な情報へのポインタを提供するために存在します。 MPlayer の文書 は技術的に非常に有益です。 おそらく、&unix; ビデオの高水準な専門的知識を得たい人はすべて、 これらの文書を調べるべきです。 MPlayer メーリングリストを購読している人たちは、 文書を面倒がって読まない人には、それが誰であれ反感を持ちます。 そのため、彼らにバグ報告をするときには、マニュアルを読んでください。 xine HOWTO にはすべてのプレイヤに一般的な性能向上についての章が含まれています。 最後に、読者が試みるかもしれない 有望なアプリケーションをいくつかあげます。 Avifile. port が multimedia/avifile にあります。 Ogle. port が multimedia/ogle にあります。 Xtheater. multimedia/dvdauthor. DVD コンテンツをオーサリングするためのオープンソースパッケージです。 Josef El-Rayes 原作: Marc Fonvieille 改訂: TV カードの設定 TV カード はじめに TV カードを使用することで、 TV 放送をコンピュータで見ることができます。 これらの多くは RCA コンポジットまたは S-video 入力端子を備えており、 FM ラジオチューナを装備したカードもあります。 &os; は Brooktree Bt848/849/878/879 または Conexant CN-878/Fusion 878a をビデオキャプチャチップに採用した PCI TV カードに &man.bktr.4; ドライバで対応しています。 対応しているチューナを搭載したボードかどうかを &man.bktr.4; マニュアルページの一覧を参照して確認してください。 ドライバの追加 TV カードを使用するために &man.bktr.4; ドライバを読み込む必要があります。 /boot/loader.conf ファイルに以下の行を追加してください。 bktr_load="YES" あるいは、カーネルにドライバを静的に組み込むこともできます。 この場合、次の行をカーネルコンフィギュレーションファイルに追加します。 device bktr device iicbus device iicbb device smbus カードコンポーネントは I2C バス経由で連結されているため、 &man.bktr.4; ドライバに加えてこれらのデバイスドライバが必要になります。 編集したら新しいカーネルを構築し、インストールします。 システムにドライバを追加したら、計算機を再起動してください。 起動時に TV カードは以下のように認識されるでしょう。 bktr0: <BrookTree 848A> mem 0xd7000000-0xd7000fff irq 10 at device 10.0 on pci0 iicbb0: <I2C bit-banging driver> on bti2c0 iicbus0: <Philips I2C bus> on iicbb0 master-only iicbus1: <Philips I2C bus> on iicbb0 master-only smbus0: <System Management Bus> on bti2c0 bktr0: Pinnacle/Miro TV, Philips SECAM tuner. もちろん、これらのメッセージはハードウェアに応じて異なります。 とはいえ、チューナが正しく検知されているかどうか確認するべきです。 &man.sysctl.8; による MIB の設定や、 カーネルコンフィギュレーションファイルオプションで、 検知されたいくつかのパラメータを変更できます。 たとえば、チューナを Philips SECAM チューナとして検知されるようにするには、 カーネルコンフィギュレーションファイルに以下の行を追加します。 options OVERRIDE_TUNER=6 または、直接 &man.sysctl.8; を使用して変更します。 &prompt.root; sysctl hw.bt848.tuner=6 利用可能なオプションの詳細については &man.bktr.4; マニュアルページおよび /usr/src/sys/conf/NOTES ファイルを参照してください (&os; 4.X を使用しているのなら、 /usr/src/sys/conf/NOTES を /usr/src/sys/i386/conf/LINT に置き換えてください)。 便利なアプリケーション TV カードを使用するためには、以下のアプリケーションの一つをインストールする必要があります。 multimedia/fxtv はウィンドウ内に TV 映像を映します。 画像/音声/ビデオを取り込むこともできます。 multimedia/xawtv も TV アプリケーションです。 fxtv と同様の機能があります。 misc/alevt は文字放送 (ビデオテキスト/テレテキスト) のデコードと表示をします。 audio/xmradio は TV カードに搭載された FM ラジオチューナを使用するためのアプリケーションです。 audio/wmtune はラジオチューナのためのお手軽なデスクトップアプリケーションです。 他にも多くのアプリケーションが &os; Ports Collection に収録されています。 トラブルシューティング TV カードに関する問題が起きたときには、 &man.bktr.4; ドライバが本当にビデオキャプチャチップおよびチューナに 対応しているか、オプションが正しく設定されているかどうかをまず確認してください。 TV カードに関するサポートやさまざまな質問に関しては、 &a.multimedia.name; メーリングリストに参加したり、 過去のアーカイブを検索してみてください。 Marc Fonvieille 寄稿: 画像スキャナ 画像スキャナ はじめに &os; のような近代的なオペレーティングシステムでは 画像スキャナを使用することができます。 スキャナに対するアクセスは SANE (Scanner Access Now Easy) API によって実現されており、 &os; Ports Collection でも提供されています。 SANE はスキャナのハードウェアにアクセスするために &os; デバイスドライバを使用します。 &os; は SCSI 接続および USB 接続のスキャナのどちらにも対応しています。 設定を始める前に、 SANE がスキャナに対応しているか確認してください。 SANE には スキャナについての情報とその状況がまとめられている 対応デバイスの一覧 があります。また、&os; の &man.uscanner.4; マニュアルページにも対応 USB スキャナの一覧が記載されています。 カーネルのコンフィグレーション 前述のように、&os はスキャナのインタフェースとして SCSI と USB の両方に対応しています。 スキャナのインタフェースによって、必要となるドライバが異なります。 USB インタフェース GENERIC カーネルにはデフォルトで USB スキャナに対応するためのデバイスドライバが搭載されています。 カスタムカーネルを使用する際には、 以下の行がカーネルコンフィグレーションファイルにあることを 確認してください。 device usb device uhci device ohci device uscanner マザーボードにどんな USB チップセットが実装されているかによって、 device uhci か device ohci のどちらかが必要となります。ただし、両方を カーネルコンフィグレーションファイルに記載しても害はありません。 使用しているカーネルが GENERIC カーネルではなく、 カーネルを再構築したくなければ、 &man.kldload.8; コマンドを使用して &man.uscanner.4; デバイスドライバモジュールを直接読み込むことができます。 &prompt.root; kldload uscanner このモジュールをシステムを起動するたびに読み込みたければ、 以下の行を /boot/loader.conf ファイルに追加してください。 uscanner_load="YES" 適切なドライバを組み込んだカーネルで再起動するか、 必要となるモジュールを読み込んだ後、 USB スキャナをシステムに接続します。 すると、メッセージバッファ (&man.dmesg.8;) にスキャナが認識されたことが示されます。 たとえば、次のようなメッセージが出力されます。 uscanner0: EPSON EPSON Scanner, rev 1.10/3.02, addr 2 この例では、スキャナが /dev/uscanner0 デバイスノードを使用していることがわかります。 &os; 4.X では、 USB デバイスを調べるために USB デーモン (&man.usbd.8;) が動作していなければなりません。 USB デーモンを有効にするには、/etc/rc.conf ファイルに usbd_enable="YES" という行を追加してシステムを再起動してください。 SCSI インタフェース スキャナに付属しているインタフェースが SCSI であれば、 重要なのはどの SCSI ボードを使用すればよいか把握することです。 使用する SCSI チップセットによって、 カーネルコンフィグレーションファイルを調整する必要があります。 GENERIC カーネルは 一般に使用される SCSI コントローラのほとんどに対応しています。 NOTES ファイル (&os; 4.X では LINT ファイル) を読んで、 適切な行をカーネルコンフィグレーションファイルに追加してください。 また、SCSI アダプタドライバに加えて、 以下の行をカーネルコンフィグレーションファイルに 記述する必要があります。 device scbus device pass カーネルを適切にコンパイルしてシステムを再起動すると、 起動時にデバイスがメッセージバッファに出力されるはずです。 pass2 at aic0 bus 0 target 2 lun 0 pass2: <AGFA SNAPSCAN 600 1.10> Fixed Scanner SCSI-2 device pass2: 3.300MB/s transfers システムを起動する際にスキャナの電源を入れてなければ、 &man.camcontrol.8; コマンドを使用して SCSI バスをスキャンし、 以下のように手動でデバイスを検出させることもできます。 &prompt.root; camcontrol rescan all Re-scan of bus 0 was successful Re-scan of bus 1 was successful Re-scan of bus 2 was successful Re-scan of bus 3 was successful すると、スキャナは SCSI デバイスの一覧に現れるでしょう。 &prompt.root; camcontrol devlist <IBM DDRS-34560 S97B> at scbus0 target 5 lun 0 (pass0,da0) <IBM DDRS-34560 S97B> at scbus0 target 6 lun 0 (pass1,da1) <AGFA SNAPSCAN 600 1.10> at scbus1 target 2 lun 0 (pass3) <PHILIPS CDD3610 CD-R/RW 1.00> at scbus2 target 0 lun 0 (pass2,cd0) SCSI デバイスについての詳細は、&man.scsi.4; および &man.camcontrol.8; のマニュアルページをご覧ください。 SANE の設定 SANE システムは、 二つの部分、すなわちバックエンド (graphics/sane-backends) とフロントエンド (graphics/sane-frontends) に分割されています。 バックエンドはスキャナそのものに対するアクセスを提供します。 SANE の 対応デバイスの一覧 には、どのバックエンドが画像スキャナに対応しているかが記載されています。 デバイスを使用するためには、正しいバックエンドを決定するのは必須です。 また、フロントエンドはグラフィカルなスキャニングインタフェース (xscanimage) を提供します。 はじめに、 graphics/sane-backends の port または package をインストールしましょう。 次に、sane-find-scanner コマンドを使用して、 SANE システムで使用するバックエンドを検出します。 &prompt.root; sane-find-scanner -q found SCSI scanner "AGFA SNAPSCAN 600 1.10" at /dev/pass3 この出力から、 スキャナインタフェースの種類と システムに接続されているスキャナが使用するデバイスノードがわかります。 ベンダ名や製品のモデル名は表示されないかも知れませんが、 重要ではありません。 USB スキャナではファームウェアを読み込む必要がある場合があります。 これはバックエンドのマニュアルページで説明されています。 &man.sane-find-scanner.1; と &man.sane.7; のマニュアルページも読んでください。 スキャナがフロントエンドで認識されるか調べてみましょう。 デフォルトでは、SANE のバックエンドには &man.scanimage.1; と呼ばれるコマンドラインツールが付属します。 このコマンドを使用すると、 デバイスの一覧を表示したり画像を取得することができます。 オプションを使うと、 スキャナデバイスの一覧が出力されます。 &prompt.root; scanimage -L device `snapscan:/dev/pass3' is a AGFA SNAPSCAN 600 flatbed scanner 何も出力が得られなかったり、 スキャナが見つからなかったというメッセージが表示されたら、 &man.scanimage.1; はスキャナを認識できなかったのでしょう。 このような場合は、バックエンドの設定ファイルを編集し、 使用するスキャナデバイスを定義する必要があります。 /usr/local/etc/sane.d/ ディレクトリには、 バックエンドが使用するすべての設定ファイルがあります。 このデバイスの認識による問題は、 特定の USB スキャナで発生するものです。 たとえば、 で使用した USB スキャナを接続したシステムで sane-find-scanner コマンドを実行すると、以下のような情報が得られます。 &prompt.root; sane-find-scanner -q found USB scanner (UNKNOWN vendor and product) at device /dev/uscanner0 スキャナは正しく検出されました。 USB インタフェースを使用し、 /dev/uscanner0 デバイスノードに接続されていることがわかります。 次に、スキャナが正しく認識されているかどうか確認してみましょう。 &prompt.root; scanimage -L No scanners were identified. If you were expecting something different, check that the scanner is plugged in, turned on and detected by the sane-find-scanner tool (if appropriate). Please read the documentation which came with this software (README, FAQ, manpages). スキャナが認識されなかったので、 /usr/local/etc/sane.d/epson.conf ファイルを編集する必要があります。 このスキャナのモデルは &epson.perfection; 1650 なので、 epson バックエンドを使用すればいいことがわかります。 バックエンドの設定ファイルに書かれているコメントを必ず読んでください。 設定ファイルを変更するのは非常に簡単です。 使用しているスキャナには不適切なインタフェースをすべてコメントアウトし (今回の場合は、USB インタフェースを使用するので scsi という語で始まる行をすべてコメントアウトします)、 ファイルの末尾に使用するインタフェースとデバイスノードを追加します。 この例では、以下の行を追加しました。 usb /dev/uscanner0 詳細と使用すべき構文は、 バックエンドのマニュアルページはもちろんのこと、 バックエンドの設定ファイルに書かれているコメントも読んでください。 以上の設定で、スキャナが認識されたかどうかを確認できます。 &prompt.root; scanimage -L device `epson:/dev/uscanner0' is a Epson GT-8200 flatbed scanner USB スキャナが認識されました。 ブランドやモデルが一致しなかったとしても、それほど重要ではありません。 着目すべきは `epson:/dev/uscanner0'という部分で、 バックエンド名とデバイスノードが正しく認識されていることがわかります。 scanimage -L コマンドを実行してスキャナが認識されたことがわかれば、設定は終了です。 デバイスはスキャンする準備ができました。 &man.scanimage.1; コマンドを使用すると コマンドラインから画像を取得することができます。その一方で、 GUI を使用して画像を取得できると一層良いでしょう。 SANE は、簡素ですが役に立つグラフィカルなインタフェース xscanimage (graphics/sane-frontends) を提供しています。 Xsane (graphics/xsane) はもう一つのグラフィカルなスキャニングフロントエンドで、 人気があります。 Xsane - には、さまざまななスキャニングモード (写真、FAX など)、 + には、さまざまなスキャニングモード (写真、FAX など)、 色補正、バッチスキャンなど先進的な機能があります。 これらのアプリケーションの両方とも GIMP のプラグインとして使用することができます。 他のユーザがスキャナにアクセスすることを許可する 前述の操作には、 すべて root 権限が必要となります。 しかしながら、他のユーザがスキャナに アクセスできるようにすることも可能です。 そのためには、スキャナが使用するデバイスノードへの 読み込み権限と書き込み権限をユーザに与えます。 一例として、USB スキャナが、グループ operator が所有する、/dev/uscanner0 デバイスノードを使用しているものとします。 ユーザ joe を グループ operator に加えると、 彼はスキャナを使用できるようになります。 &prompt.root; pw groupmod operator -m joe 詳細は &man.pw.8; のマニュアルページをご覧ください。 また、初期設定では、operator グループに所属するメンバのみが /dev/uscanner0 デバイスノードを読み出すことができます。 このデバイスノードに書き込めるようにするには、 適切な許可属性 (0660 または 0664) を設定する必要があります。 まず、/etc/devfs.rules に次の行を追加してください。 [system=5] add path uscanner0 mode 660 次に、/etc/rc.conf に以下の行を追加して システムを再起動します。 devfs_system_ruleset="system" /etc/devfs.rules で設定した内容についての詳細は、&man.devfs.8; のマニュアルページをご覧ください。 なお、&os; 4.X では、初期設定では、 - operator グループに所属するメンバに + operator グループに所属するメンバが /dev/uscanner0 を読み書きすることができます。 もちろん、ユーザをどんなグループ (特にグループ operator) に追加する時はいつでも、 セキュリティ上の理由から二度は検討を行うべきです。 diff --git a/ja_JP.eucJP/books/handbook/ports/chapter.sgml b/ja_JP.eucJP/books/handbook/ports/chapter.sgml index 26a4d2d578..f3256ec9b1 100644 --- a/ja_JP.eucJP/books/handbook/ports/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/ports/chapter.sgml @@ -1,1556 +1,1556 @@ アプリケーションのインストール - packages と ports この章では ports packages FreeBSD の基本システムには数多くのシステムツールが含まれています。 しかしながら、サードパーティ製のアプリケーションをインストールしないと 実用的にはそれほどたくさんのことはできません。 FreeBSD は、サードパーティ製のソフトウェアをインストールするために Ports Collection と packages という相補的な 2 つの技術を提供しています。 どちらのシステムを用いても、お気に入りのアプリケーションの最新版を ローカルメディアやネットワーク上からインストールできます。 この章を読むと、以下のことがわかります。 packages を用いてサードパーティ製のソフトウェアをバイナリからインストールする方法 Ports Collection を用いてサードパーティ製のソフトウェアをコンパイルする方法 インストールされた packages や ports を削除する方法 ソフトウェアのインストール すでに Unix システムを使ったことのある人ならば、 サードパーティ製ソフトウェアの典型的なインストール手順が 以下のようになることをご存知でしょう。 ソースコード、またはバイナリ形式で 配布されているソフトウェアをダウンロードする。 配布時のフォーマット (一般的には &man.compress.1; または &man.gzip.1; で圧縮された tarball) からソフトウェアを取り出す。 ドキュメントを探しだし (おそらく README ファイル、あるいは doc/ サブディレクト中のファイル)、 ソフトウェアのインストール方法を調べる。 ソース形式でソフトウェアが配布されている場合はコンパイルを行う。 ここでは、Makefile の編集、 または、configure スクリプトの実行、 あるいは他の作業を伴うことがある。 ソフトウェアの動作を確認し、インストールする。 すべてがうまくいったならば、インストール作業は以上です。 もしインストールしているソフトウェアパッケージが、 FreeBSD を意識して移植されたものでなければ、 適切に動くようコードを調べ、編集する必要があるかもしれません。 あなたが望むのであれば、FreeBSD 上へのソフトウェアのインストールに 従来 の方法を使い続けることができます。 しかしながら、FreeBSD は インストール時にかかるたくさんの労力を軽減する 2 つの技術、 すなわち packages と ports を提供しています。 この文書を書いている時点では、 &os.numports; を越えるサードパーティ製アプリケーションがこれらの方法で 利用可能となっています。 FreeBSD package では、いかなるアプリケーションに対しても ダウンロードする必要のあるファイルはただ一つです。 package には、コンパイル済みのアプリケーションの全コマンド、 各種設定ファイルやドキュメントが含まれています。 FreeBSD に用意されている &man.pkg.add.1;, &man.pkg.delete.1;, &man.pkg.info.1; といった package 管理コマンドで、 ダウンロードした package ファイルを扱うことができます。 新しいアプリケーションをインストールするには、 たった一つのコマンドを実行するだけです。 FreeBSD port は、アプリケーションをソースコードからコンパイルする際の 処理を自動化するように設計されたファイルの集まりです。 プログラムをコンパイルする時のことを思い出して下さい。 通常、とてもたくさんの手順 (展開、パッチ作業、コンパイル、インストール) を踏まなくてはなりません。 port を構成するファイルは、 これらすべての作業をあなたの代わりに行うために必要な情報を含んでいます。 いくつかの簡単なコマンドを実行すると、 自動的にアプリケーションのソースコードがダウンロードされ、展開、 パッチ作業、コンパイル、そして、インストール作業が行われます。 さらに ports システムは、pkg_add コマンドや他の package 管理コマンドで扱うことのできる packages を生成できます。 これらのコマンドについては後の節で簡単に紹介します。 packages と ports は依存関係を理解します。 ある特定のライブラリに依存する アプリケーションをインストールするとします。 また、アプリケーションとライブラリは FreeBSD ports や packages によって 入手可能であるとします。 アプリケーションを追加するために pkg_add コマンドまたは ports システムを用いると、 インストールされていないライブラリが検出され、 先に依存するライブラリがインストールされます。 2 つの技術が非常に類似していて、 なぜ FreeBSD がわざわざ両者を採用しているのか不思議に思うでしょう。 packages と ports にはそれぞれ独自の特徴があり、 どちらを使うかはあなたの好みによります。 package の利点 一般的に、あるアプリケーションの package の tarball は、 ソースコードを含む tarball より小さなサイズとなります。 packages はコンパイル作業を必要としません。 このことは、Mozilla, KDE, または GNOME といった大きなアプリケーションで重要となります。 特にシステムが遅い場合にはなおさら重要です。 packages を用いれば、 ソフトウェアのコンパイルに関する知識は必要ありません。 ports の利点 packages は、通常最も多くのシステムで実行できるように、 非常に保守的な設定で構築されています。 port からインストールすることで、 たとえば Pentium III や Athlon プロセッサに特化したコードを生成するような コンパイルオプションを指定できます。 packages のなかには、コンパイル時に プログラムの機能を決めるようなオプションを設定するものがあります。 たとえば、Apache は多種多様な ビルトインオプションを設定できます。 port から構築することで、デフォルトオプションではなく、 自分でオプションを設定することができます。 設定を区別するために、同じアプリケーションに対して 複数の packages が存在することがあります。 たとえば、Ghostscript は X11 サーバーがインストールされているかどうかにより、 ghostscript package と ghostscript-nox11 package が選択可能となっています。 packages でもこのような方法が可能ですが、 アプリケーションのコンパイルオプションが さらに用意されている場合は困難となります。 ライセンス条項で、 バイナリでの配布を禁止しているソフトウェアがあります。 それらはソースコードで配布されなくてはいけません。 バイナリ配布を信用していない人もいます。 ソースコードがあれば、少なくともソースコードを読んで (理論的には) 潜在的な問題点を自分で見つけ出すことができます。 ローカルなパッチがある場合、 それを適用するためにソースコードが必要になります。 ソースコードを手元に置いておきたい人たちもいます。 彼らは、退屈したときに眺めたり、あちこち解析してみたり、 ソースコードを借用したり (もちろん、 ライセンスが許せばの話ですが) するのです。 ports の更新状況を把握するために、 freebsd-ports@freebsd.org メーリングリストを購読するとよいでしょう。 この章では、packages と ports を用いた FreeBSD 上での サードパーティ製ソフトウェアの インストール方法や管理方法について説明します。 アプリケーションの探し方 どんなアプリケーションをインストールするにしても、 まずあなたが何を望んで、 またその名前がなんというのかを理解している必要があります。 FreeBSD 上で利用可能なアプリケーションのリストは常に増えています。 幸運にも、多くの方法で望むものを探すことができます。 FreeBSD ウェブサイトは、 利用可能なすべてのアプリケーションの検索できる最新の一覧を http://www.FreeBSD.org/ports/ で公開しています。 アプリケーションの名前はカテゴリに分類されており、 (名前を知っているならば) 名前で検索できます。 また、カテゴリ中の利用可能な すべてのアプリケーションを表示させることもできます。 FreshPorts Dan Langille は http://www.FreshPorts.org/ で FreshPorts を公開しています。 FreshPorts は ports ツリー中のアプリケーションの変更を追跡します。 一つまたはそれ以上の ports を 監視 することができ、 変更があるとメールで更新情報を送ってくれます。 FreshMeat ご希望のアプリケーションの名前がわからなければ、 FreshMeat (http://www.freshmeat.net/)、 または、AppWatch (http://www.appwatch.com/) のようなサイトでアプリケーションを探して下さい。 その後、そのアプリケーションが ports で利用可能かどうかを FreeBSD サイトで調べて下さい。 Chern Lee 寄稿: packages システムの利用 package のインストール packages インストール pkg_add &man.pkg.add.1; は、ローカルファイルやネットワーク上のサーバから FreeBSD ソフトウェア package を インストールするためのユーティリティです。 package をダウンロードしてローカルからインストールする &prompt.root; ftp -a ftp2.freebsd.org Connected to ftp2.freebsd.org. 220 ftp2.freebsd.org FTP server (Version 6.00LS) ready. 331 Guest login ok, send your email address as password. 230- 230- This machine is in Vienna, VA, USA, hosted by Verio. 230- Questions? E-mail freebsd@vienna.verio.net. 230- 230- 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp> cd /pub/FreeBSD/ports/packages/sysutils/ 250 CWD command successful. ftp> get lsof-4.56.4.tgz local: lsof-4.56.4.tgz remote: lsof-4.56.4.tgz 200 PORT command successful. 150 Opening BINARY mode data connection for 'lsof-4.56.4.tgz' (92375 bytes). 100% |**************************************************| 92375 00:00 ETA 226 Transfer complete. 92375 bytes received in 5.60 seconds (16.11 KB/s) ftp> exit &prompt.root; pkg_add lsof-4.56.4.tgz (FreeBSD CD-ROM セットのような) ローカルな packages がない場合は、 &man.pkg.add.1; に -r オプションをつける方が楽でしょう。 このユーティリティは、このオプションを指定して実行すると 自動的に適切なオブジェクトの形式とリリースを判断し、 package を FTP サイトからダウンロードしてインストールします。 pkg_add &prompt.root; pkg_add -r lsof-4.56.4 上の例では適当な package がダウンロードされた後、インストールされます。 ユーザーはこれ以外に作業をする必要はありません。 package は .tgz という拡張子を持つファイルとして配布されており、 ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/packages/ や FreeBSD CD-ROM にあります。 FreeBSD 4-CD セット (または PowerPak など) の CD はすべて、 /packages ディレクトリに packages が あります。packages のレイアウトは、 /usr/ports ツリーのものと同様です。 カテゴリごとにディレクトリがあり、 All ディレクトリにはすべての package があります。 package システムのディレクトリ構造は ports のそれと同一です。 両者が組み合わさって package/port システムが構成されます。 package の削除 pkg_delete packages 削除 インストールされている package を削除するには、 &man.pkg.delete.1; ユーティリティを使ってください。 &prompt.root pkg_delete xchat-1.7.1 packages の管理 packages 管理 &man.pkg.info.1; は、インストールされている packages の一覧と説明を表示するユーティリティです。 pkg_info &prompt.root pkg_info cvsup-16.1 A general network file distribution system optimized for CV docbook-1.2 Meta-port for the different versions of the DocBook DTD ... &man.pkg.version.1; は、インストールされている packages のバージョンを要約して表示するユーティリティです。 package のバージョンを、現在の ports ツリーのバージョンと 比較します。 &prompt.root pkg_version cvsup = docbook = ... 2 列目の記号は、インストールされているバージョンの ローカル ports ツリーのバージョンに対する 新旧を表します。 記号 意味 = インストールされている package のバージョンは、 ローカル ports ツリーのものと一致しています。 < インストールされているバージョンは、 ローカル ports ツリーのものより古いです。 >インストールされているバージョンは、 ローカル ports ツリーのものより新しいです (おそらくローカル ports ツリーは古くなっています)。 ?インストールされた package を ports インデックスの中に見つけることができません。 *複数のバージョンの package が存在します。 その他 package に関するすべての情報は /var/db/pkg ディレクトリ以下に置かれています。 このディレクトリの下にあるファイルの中に、 インストールされたファイルの一覧やインストールされた各 package についての説明が含まれています。 Ports Collection の利用 このセクションでは、Ports Collection を利用してシステムにプログラムをインストールしたり、 システムから削除したりする基本的な手順について説明します。 Ports Collection の準備 ports をインストールするためには、まず Ports Collection を用意しなくてはなりません。 Ports Collection とは、通常 /usr/ports 以下に置かれる Makefile, 修正パッチ、 説明文などの一連のファイルのことです。 FreeBSD のシステムインストール時に、 sysinstall が Ports Collection をインストールするかどうかを尋ねてきたはずです。 No を選んだ場合、以下の作業をおこない Ports Collection をインストールしてください。 sysinstall を利用する方法 ここでは、再び sysinstall を利用して Ports Collection を手動でインストールする方法について説明します。 root ユーザ権限で、以下のように /stand/sysinstall を実行してください。 &prompt.root; /stand/sysinstall スクロールダウンして Configure を選び、 Enter を押してください。 スクロールダウンして Distributions を選び、 Enter を押してください。 スクロールダウンして ports を選び、 スペースキーを押してください。 Exit までスクロールアップして、Enter を押してください。 CDROM や FTP といったインストールメディアを選択してください。 メニューに従って sysinstall を終了してください。 Ports Collection をインストールしたり、最新の状態にしておくためのもう一つの方法は CVSup を利用する方法です。 ports 用の CVSup ファイル /usr/share/examples/cvsup/ports-supfile をご覧ください。 CVSup を使うための情報や、 このファイルに関する説明は CVSup を使う () にあります。 CVSup を利用する方法 ここでは、CVSup を利用して Ports Collection をインストールする方法について簡単に説明します。 あなたの ports ツリーを最新の状態にしておきたい、または CVSup についてもっと知りたいのであれば、 先ほど紹介したセクションをご覧ください。 まず net/cvsup port をインストールしてください。 インストールについての詳細は、CVSup のインストール () を参照してください。 root ユーザ権限で、 /usr/share/examples/cvsup/ports-supfile を /root や、あなたのホームディレクトリなどへコピーしてください。 次に ports-supfile を編集します。 CHANGE_THIS.FreeBSD.org を最寄りの CVSup サーバに変更してください。 ミラーサイトの完全なリストは CVSup サイト () にあります。 cvsup -g -L 2 <path_to_supfile> を実行してください。 &prompt.root; cvsup -g -L 2 /root/ports-supfile この手順を時間をおいて繰り返し実行すると、 最新の変更点がダウンロードされて、あなたの手元の Ports Collection に加えられます。 ports のインストール ports インストール 一番最初に知らなければならないのは、 Ports Collection は スケルトン と呼ばれるもので構成されているという事実です。 port スケルトンは簡単に言うと、アプリケーションを FreeBSD 上でコンパイルしインストールするために必要となる最小限のファイルのセットのことです。 それぞれの port スケルトンには、次のファイルが含まれています。 Makefile。 Makefile にはアプリケーションのコンパイル方法やシステムのどこにインストールするかを指定する、 さまざまな命令文が含まれています。 distinfo ファイル。 このファイルには、その port を構築するために ダウンロードする必要があるファイルのファイル名と、 それらのファイルがダウンロードによって壊れていないか チェックするためのチェックサム情報が含まれています。 files ディレクトリ。 このディレクトリには FreeBSD システム上でプログラムをコンパイルし、 インストールするための修正パッチが含まれています。 修正パッチ (patch) とは基本的に、 個々のファイルに対する変更点を表した小さなファイル群のことです。 ファイルはプレインテキスト形式で、 10 行目を削除 や 26 行目を ... に変更 などと書かれています。 修正パッチは、diff (差分) とも呼ばれます。 これは、修正パッチが diff プログラムで作成されるからです。 このディレクトリには、その port の構築に必要な その他のファイルが入る場合もあります。 pkg-comment ファイル。 これにはプログラムの一行説明文が含まれています。 pkg-descr ファイル。 これにはプログラムの、複数行にわたる詳しい説明文が含まれます。 pkg-plist ファイル。 これは、その port によってインストールされる全ファイルのリストです。 これにはプログラムを削除する際に、 どのファイルを削除すれば良いのかを ports システムに伝える役割もあります。 さて、Ports Collection が何を目的として使われるものなのか、 それを理解するための基礎的な知識はこれで十分です。 最初の port をインストールする準備ができました。 port のインストールには二つの方法があります。 実際の作業に入る前に、 インストールする port を選ぶ必要があります。 選ぶ方法はいくつかありますが、最も簡単なのは FreeBSD ウェブサイトの ports リスト を利用することでしょう。 そこにリストされている ports や、 サイトの検索機能を使って閲覧することができます。 各々の port には説明文が含まれていますので、 インストールを決める前にその port に関する説明を読むこともできます。 もう一つの方法は、whereis コマンドを使うことです。 whereis コマンドを使うには、 プロンプトから単に whereis <インストールしたいプログラム名> と入力します。 もし、あなたのシステム上でプログラムが見つかれば、 それがどこにあるのかが次のように表示されます。 &prompt.root; whereis lsof lsof: /usr/ports/sysutils/lsof この表示は、lsof (システムユーティリティの一つ) が /usr/ports/sysutils/lsof というディレクトリに見つかったことを示しています。 また、Ports Collection の持つ検索機能を利用して port を検索する方法もあります。 この検索機能を利用するには、カレントディレクトリが /usr/ports である必要があります。 そのディレクトリに移動したら、 make search key=プログラム名 と入力してください。 プログラム名 の部分には検索したいプログラム名を入れます。 たとえば、lsof を探したい場合には次のようにします。 &prompt.root; cd /usr/ports &prompt.root; make search key=lsof Port: lsof-4.56.4 Path: /usr/ports/sysutils/lsof Info: Lists information about open files (similar to fstat(1)) Maint: obrien@FreeBSD.org Index: sysutils B-deps: R-deps: 出力のうち特に注意して見なければならないのは Path という行です。 この行は xchat がどこにあるかを示しています。 出力される他の情報は port をインストールする際には直接必要となるものではありませんので、 ここでは触れないでおきます。 ports をインストールするには、 root ユーザにならなければなりません。 インストールしたい port が見つかったら、 実際のインストールに移ることができます。 CD-ROM からの ports のインストール ports CD-ROM からのインストール タイトルから想像できると思いますが、 このセクションで説明する内容は、FreeBSD の CDROM セットを持っていることを前提としています。 もし CDROM セットを持っていなければ、 FreeBSD Mall で注文することができます。 FreeBSD CDROM がドライブに挿入されていて、 /cdrom (マウントポイントは必ず /cdrom でないといけません) にマウントされていれば、port をインストールすることができます。 まず、インストールしたい port のあるディレクトリに移動してください。 &prompt.root; cd /usr/ports/sysutils/lsof lsof ディレクトリに移動すると、 port スケルトンがあるのが確認できると思います。 次に行なうのは、port のコンパイル (構築、ビルド (build) とも呼ばれます) です。 これは、プロンプトから単に make と入力するだけで行なえます。 そうすると、次のような出力が現われるはずです。 &prompt.root; make >> lsof_4.57D.freebsd.tar.gz doesn't seem to exist in /usr/ports/distfiles/. >> Attempting to fetch from file:/cdrom/ports/distfiles/. ===> Extracting for lsof-4.57 ... [extraction output snipped] ... >> Checksum OK for lsof_4.57D.freebsd.tar.gz. ===> Patching for lsof-4.57 ===> Applying FreeBSD patches for lsof-4.57 ===> Configuring for lsof-4.57 ... [configure output snipped] ... ===> Building for lsof-4.57 ... [compilation snipped] ... &prompt.root; コンパイルが終了してプロンプトに戻ることを確認してください。 次に port のインストールを行ないます。 port をインストールするのに必要なのは、 make コマンドに一つの単語、 install を指定することだけです。 &prompt.root; make install ===> Installing for lsof-4.57 ... [install routines snipped] ... ===> Generating temporary packing list ===> Compressing manual pages for lsof-4.57 ===> Registering installation for lsof-4.57 ===> SECURITY NOTE: This port has installed the following binaries which execute with increased privileges. &prompt.root; プロンプトに戻ったら、 インストールしたプログラムは実行できるようになっています。 lsof は高い権限で動作するプログラムなので、 セキュリティに関する警告が表示されます。 ports のコンパイルや インストール中に表示されるこれらの警告に注意してください。 make、make install と二つに分けられた手順の代わりに、 最初から make install と実行することで、 手順の二番目の操作を省くことができます。 port には CDROM への収録を許可しないライセンス条項を持つものがあることに 注意してください。 これにはダウンロード前に登録を必要としたり、 再配布が禁止されているなどという理由があります。 CDROM に含まれていない port をインストールしたい場合には、 ネットワークに接続する必要があります (次のセクションをご覧ください)。 インターネット経由での ports のインストール 前セクションと同じように、このセクションでは、 インターネットへの接続が可能であることを前提としています。 もしインターネット接続が不可能な場合は、 CDROM からのインストールが必要になるでしょう。 インターネット経由で port をインストールする方法は、 CDROM からインストールする場合と完全に同じです。 唯一異なる部分はプログラムのソースコードを CDROM からではなく、 インターネット経由でダウンロードするということです。 次のように、必要な手順は同じです。 &prompt.root; make install >> lsof_4.57D.freebsd.tar.gz doesn't seem to exist in /usr/ports/distfiles/. >> Attempting to fetch from ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/. Receiving lsof_4.57D.freebsd.tar.gz (439860 bytes): 100% 439860 bytes transferred in 18.0 seconds (23.90 kBps) ===> Extracting for lsof-4.57 ... [extraction output snipped] ... >> Checksum OK for lsof_4.57D.freebsd.tar.gz. ===> Patching for lsof-4.57 ===> Applying FreeBSD patches for lsof-4.57 ===> Configuring for lsof-4.57 ... [configure output snipped] ... ===> Building for lsof-4.57 ... [compilation snipped] ... ===> Installing for lsof-4.57 ... [install routines snipped] ... ===> Generating temporary packing list ===> Compressing manual pages for lsof-4.57 ===> Registering installation for lsof-4.57 ===> SECURITY NOTE: This port has installed the following binaries which execute with increased privileges. &prompt.root; ご覧のとおり、 出力の違いはシステムがどこから port を入手したか示す行だけです。 以上が、システムに ports をインストールするために必要な操作です。 次のセクションでは、システムにインストールされている port を削除する方法について学びます。 インストールされた ports の削除 ports 削除 ports のインストール方法について知ればおそらく、 インストールの後になって、それが間違っていたことに気付いた時などに備えて それらを削除する方法はどうすれば良いのか疑問に感じることでしょう。 ここでは、その削除の方法について扱います。 さて、前の例 (例のまま何も変更していない人は lsof) を削除してみましょう。ports のインストールと同じように、 まず最初にやらなければならないのは port のディレクトリに移動することです。 port のディレクトリは /usr/ports/sysutils/lsof でしたね。 ディレクトリを移動したら、lsof を削除するのに必要な準備は終わりです。 削除するには、make deinstall コマンド を実行します。 &prompt.root; cd /usr/ports/sysutils/lsof &prompt.root; make deinstall ===> Deinstalling for lsof-4.57 極めて簡単な作業です。 これでうまく lsof をシステムから削除することができました。 もう一度再インストールしたい場合には、 /usr/ports/sysutils/lsof ディレクトリから make reinstall を実行することで行なうことができます。 トラブルシューティング このセクションでは、Ports Collection について良く質問される質問と、 いくつかの基本的なトラブルシューティングテクニック、 そして port がうまく動かない場合にできることについて扱います。 質問と回答集 私はモデムについての議論を しているのかと思っていました??! なるほど。 あなたはきっと、 コンピュータの背面についているシリアルポートのことだと思ってしまったのでしょう。 あるバージョンの Unix から、 別のバージョンの Unix へとプログラムを移植することを porting というのですが、 ここでわたしたちは porting の結果という意味で port を使っています。 パッチ (patch) とは何ですか? パッチとは、 あるバージョンから他のバージョンへどのように変更するかを 示す、(通常は) 小さなファイルです。 23 行目を削除、 468 行目の後にこれらの 2 行を追加、 または 197 行目をこのように変更 というような内容を含んでいます。 これは、diff という名前のプログラムで生成されます。 tarball tarball とは一体何ですか? .tar または .tar.gz という拡張子を持つファイルです (.tar.Z のようなバリエーションもありますし、 DOS のファイルシステム用に .tgz と短縮される場合もあります)。 これは基本的にファイルを一つにまとめた (.tar) ディレクトリツリーです。 圧縮されている (.gz) 場合もあります。 元々 Tape ARchives (訳注: テープアーカイブ) (このため tar という名前なのです) で使われていたものなのですが、 インターネット上でプログラムのソースコードを配布するために 広く使われている方法です。 これらのファイルの中身を見たり、 展開したりすることもできます。FreeBSD の基本システムに付属する Unix 標準の tar コマンドを使ってみると次のようになります。 &prompt.user; tar tvzf foobar.tar.gz &prompt.user; tar xzvf foobar.tar.gz &prompt.user; tar tvf foobar.tar &prompt.user; tar xvf foobar.tar チェックサム チェックサムとは何ですか? これは、 チェックしたいファイル中のすべてのデータを加えて生成した 数値です。何か文字が書き換わっていたら、 チェックサムが一致しなくなります。そのため、 単純な比較だけで違いを見つけることができるのです。 今まで「CD-ROM からの ports のコンパイル」にあるようにして ports をインストールできていたのですが、 kermit のインストールをしようとするとうまくいきません。 &prompt.root; 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 が見つからないのでしょうか? 不良品の CDROM を買ってしまったのでしょうか? CD-ROM からの ports のコンパイル のセクションで説明されているとおり、 ports の一部にライセンス上の制限から CDROM には収録できない種類のものが存在します。 kermit はその一例です。 kermit のライセンス条件は tarball を CDROM に収録することを禁じているため、 申し訳ありませんが手動で tarball を取得してください。 質問にあるようなエラーメッセージが表示されるのは、 あなたがそのときにインターネットへ接続していなかったことによります。 一度 MASTER_SITES のいずれかから (Makefile の中に書いてあります) ダウンロードしておけば、プロセスを再開することができます。 kermit の tarball を入手しましたが、 /usr/ports/distfiles に ファイルを置こうとすると、 書き込み権がないというエラーがでます。 ports は /usr/ports/distfiles から tarball を探します。しかし、これは読み出し専用の CDROM へのシンボリックリンクなので、 ここにファイルを置くことはできません。 次のようにすれば他の場所を探すよう ports に指示することができます。 &prompt.root; make DISTDIR=/where/you/put/it install ports は、すべてを /usr/ports に置いたときだけ動作するのでしょうか? システムの管理者によると、私の個人的なファイルは /u/people/guests/wurzburger に入れなければならないのですが、 これではうまくいかないように思います。 PORTSDIR 変数と PREFIX 変数を変更することで、 違うディレクトリを 使用することができます。 たとえば、 &prompt.root; make PORTSDIR=/u/people/guests/wurzburger/ports install とすると、ports は /u/people/guests/wurzburger/ports でコンパイルされ、すべて /usr/local 以下にインストールされます。 &prompt.root; make PREFIX=/u/people/guests/wurzburger/local install この場合、コンパイルは /usr/ports でおこない、 /u/people/guests/wurzburger/local にインストールします。 もちろん、 &prompt.root; make PORTSDIR=../ports PREFIX=../local install とすれば両者を組み合わせることが可能です (省略せずに記述したらこのページに収めるには長すぎるのですが、 考え方は理解していただけたと思います)。 imake (X Window System に含まれる) &man.imake.1; を使用する ports の場合は PREFIX が機能せず、 /usr/X11R6 の下へインストールしようとします。 また、Perl 関連の ports も同様に PREFIX を無視して Perl ツリーにインストールします。 これらの ports で PREFIX がきちんと参照されるように変更するのは、ほとんど不可能です。 もし ports をインストールするたびにこれらを毎回タイプするのが気に入らないのであれば、 これらを環境変数にセットしてしまうという手があります。 どのようにすれば良いかについては、 あなたの使っているシェルのマニュアルページを参照してください。 わたしは FreeBSD の CDROM を持っていませんが、 すべての tarball を システムに置いておきたいのです。 そうすれば ports をインストール するたびに毎回ダウンロードが終わるのを待たなくてすむでしょう。 これを一度におこなう簡単な方法はありませんか? Ports Collection 全体の tarball を持ってくるには、 次のようにします。 &prompt.root; cd /usr/ports &prompt.root; make fetch ports の下の一つのディレクトリの tarball を持ってくるには、次のようにします。 &prompt.root; cd /usr/ports/directory &prompt.root; make fetch ports を一つだけ持ってくる方法は、 もうお分かりでしょう。 近くにある FreeBSD のミラーサイトから tarball を持ってくる方がおそらく速いはずです。 MASTER_SITES に書かれているサイト以外から持ってくるように ports に指示する方法はありませんか? もちろんあります。たとえば ftp.FreeBSD.org が MASTER_SITES に書かれている サイトより近いとしたら、以下のようにしてください。 &prompt.root; cd /usr/ports/directory &prompt.root; make MASTER_SITE_OVERRIDE=ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/ fetch make がダウンロードしようとする前に、 どんなファイルが必要とするか知りたいのですが。 make fetch-list とすると、ports に必要なファイルの一覧を表示できます。 ports のコンパイルを途中で止める方法はありますか? 私はインストールをする前に いろいろとソースコードを解析したいのですが、毎回 control-C を打たなければならないのが少し面倒です。 make extract を実行すると、 ファイル転送とソースコードの展開まで行なったところで停止します。 自分で ports を作ろうとしています。 わたしの作ったパッチが正しく処理できることを確認できるように、 コンパイルを止めたいのです。 パッチのための make extract のようなものはありませんか? あります。make patch があなたの望むものです。 おそらく PATCH_DEBUG オプションも同様に役に立つことでしょう。 あなたの努力に感謝いたします!! あるコンパイルオプションはバグの原因になるという話を聞きました。 本当なのでしょうか? どうやったら正しい設定で ports をコンパイルできますか? 本当です。 gcc の バージョン 2.6.3 (FreeBSDの 2.1.0 と 2.1.5 に付属している バージョン) では、 オプションを オプションなしで 使うと、バグのあるコードを出力します (ほとんどの ports は オプションを使いません)。 - コンバイルオプションは次のように定義すべきです。 + コンパイルオプションは次のように定義すべきです。 &prompt.root; make CFLAGS='-O2 -fno-strength-reduce' install これを /etc/make.conf に書いておくこともできますが、 残念なことにすべての ports がこの指定を尊重してくれるわけではありません。 もっとも確実なのは make configure を実行し、ソースディレクトリの Makefile を見て、手で修正することですが、 ソースが多くのサブディレクトリに分かれていて、 各々に Makefile がある場合は大変な仕事になります。 FreeBSD の標準コンパイルオプションは非常に保守的ですので、 変更していなければ問題となることはないでしょう。 ports がたくさんありすぎて、 わたしの欲しいものがなかなか見つけられません。 どんな ports が使えるのか、リストはどこかにありませんか? /usr/ports の中にある INDEX ファイルを見てみましょう。 また、あるキーワードで ports コレクションを検索することも可能です。 たとえば以下のようにすれば、プログラミング言語 LISP に関連した ports を探すことができます。 &prompt.user; cd /usr/ports &prompt.user; make search key=lisp foo ports をインストールしたいのですが、それのコンパイルは すぐに停止して、bar ports のコンパイルが始まってしまいます。一体どうして? foo ports が、 bar ports の提供する何らかの機能を必要としているからです。 たとえば foo が画像を扱うもので bar がその画像処理に必要なライブラリを持っている場合などです。 もしくは bar が foo をコンパイルするのに必要なツールなのかもしれません。 ports から grizzle プログラムをインストールしましたが、まったく ディスクスペースの浪費です。削除したいのですが、 すべてのファイルがどこへインストールされたのかわかりません。 何か手がかりはありませんか? 大丈夫、次のように入力してください。 &prompt.root; pkg_delete grizzle-6.5 もしくは、次のよう入力します。 &prompt.root; cd /usr/ports/somewhere/grizzle &prompt.root; make deinstall ちょっと待ってください。 削除しようとするコマンドのバージョン番号を 知っていなくてはならないのでしょうか? あなたは、わたしがバージョン番号を 覚えていると本気で思っているのですか? そんなことはありません。 バージョン番号は次のようにすればわかります。 &prompt.root; pkg_info -I 'grizzle*' Information for grizzle-6.5: grizzle-6.5 - the combined piano tutorial, LOGO interpreter and shoot 'em up arcade game. バージョン番号は、pkg_info または ls /var/db/pkg と入力してもわかります。 ディスク容量のことなのですが、ports のディレクトリは非常に膨大な容量を使うように見えます。 残しておいた方がよいのでしょうか? それとも削除してしまって構わないのでしょうか? はい。インストールが首尾よく終わり、 もうソースコードが必要でないと思うなら、 それらを残しておく理由はないでしょう。 一番確実な方法は、次のとおりです。 &prompt.root; cd /usr/ports &prompt.root; make clean これはすべての ports のサブディレクトリを調べ、 各 ports のスケルトン以外の削除をおこないます。 各サブディレクトリの Makefile を再帰的に読み込まなくても削除をおこなえます。 たとえば、次のようにすると work サブディレクトリを直接削除できます。 &prompt.root; find /usr/ports -depth -name work -exec rm -rf {} \; これを試してみたのですが、tarball や ports で使われたファイルが distfiles ディレクトリに残っています。 これも削除してしまっても大丈夫ですか? はい。それを使った作業が終わったのであれば、 削除してしまっても大丈夫です。 手動でファイルを操作するか、 もしくは make distclean を使えば削除することができます。 わたしはとてもとてもたくさんのプログラムを楽しみたいのです。 一度にすべての ports をインストールする方法はありませんか? 次のようにしてください。 &prompt.root; cd /usr/ports &prompt.root; make install ports の中には、 同じ名前でインストールを行なうものがあるということに注意してください。 二つのグラフィック ports をインストールして、 それらが両方とも /usr/local/bin/plot をインストールする場合などは明らかに問題となるでしょう。 やってみました。 時間がとてもかかるだろうと思ったので、 そのまま実行を続けさせて、わたしは寝ました。 翌朝コンピュータを見てみると、 三つ半の ports しか処理が終わっていませんでした。 何か悪かったのでしょうか? ports の中には、 わたしたちの決められないこと (たとえば、あなたが A4 の 用紙に印刷したいのか、US レターサイズの用紙に印刷したいのかなど) について質問してくるものがあるからです。 それらの質問には手動で答える必要があります。 一日中モニタの前に座って過ごしたりしたくないのですが、 何か良いアイディアはありませんか? では、あなたが寝に / 仕事に / 公園にいく前に以下を実行してください。 &prompt.root; cd /usr/ports &prompt.root; make -DBATCH install これでユーザの入力を要求しないすべての ports をインストールします。 そして戻ってきてから次のように実行してください。 &prompt.root; cd /usr/ports &prompt.root; make -DINTERACTIVE install そして残りの作業を実行してください。 わたしたちは Ports Collection にある frobble を使っています。 ですが、わたしたちの必要に応じて ports を変更したところがあるのです。 自分で package を作って、 それをわたしたちのサイトのまわりに簡単に配布できるような方法がありますか? もちろんあります。 変更点をパッチにする方法は知っていますよね? &prompt.root; cd /usr/ports/somewhere/frobble &prompt.root; make extract &prompt.root; cd work/frobble-2.8 [あなたのパッチをあててください] &prompt.root; cd ../.. &prompt.root; make package この ports の技術は本当に賢いですね。 わたしはこれがどのようにして動いているのか知りたいのですが、 その秘密とは何ですか? 秘密なんて一切ありません。 /usr/ports/Mk/ ディレクトリにある bsd.port.mk と bsd.port.subdir.mk ファイルを見てください。 (複雑なシェルスクリプトを嫌う読者は、 このディレクトリにあるファイルを見ない方が良いでしょう。) たすけて! port がうまく動かない! port がうまく動作しない状況に遭遇したら、 あなたにできることは次のようなことしかありません。 自分で直しましょう! "Ports" システムに関する詳細な情報は port 作成者のためのハンドブック にあります。 このセクションを読むと、壊れてしまった port を直したり、 自分で作った port を提出したりできるようになります! 苦情を言いましょう — ただし電子メールで! まず port の保守担当者に電子メールを送ってください。 make maintainer と入力するか、 Makefile を直接読み、 保守担当者の電子メールアドレスを調べます。 メールを送る際には、port 名とバージョン番号 (Makefile の $FreeBSD: 行)、 そしてエラーが出力されるまでの出力ログを忘れずに添付してください。 保守担当者から返信がなければ、send-pr を使ってバグレポートを提出しても構いません。 近くの FTP サイトから package を入手しましょう。 マスタ package コレクションは、 ftp.FreeBSD.org の package のディレクトリにありますが、 まずはあなたの地域のミラーサイトを最初に調べてください。 ソースからコンパイルすることを試みるより確実ですし、 時間もかかりません。 package をシステムにインストールするには、&man.pkg.add.1; を使います。 diff --git a/ja_JP.eucJP/books/handbook/ppp-and-slip/chapter.sgml b/ja_JP.eucJP/books/handbook/ppp-and-slip/chapter.sgml index 01c96d570c..476c8329e6 100644 --- a/ja_JP.eucJP/books/handbook/ppp-and-slip/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/ppp-and-slip/chapter.sgml @@ -1,2794 +1,2794 @@ PPP と SLIP 改訂: &a.jim;, 2000 年 3 月 1 日. この章では もしあなたがモデムを使ってインターネットに接続したり, 他の人々に FreeBSD によるインターネットへのダイヤルアップ接続を 提供しようとしているのでしたら, PPP または SLIP 接続を選択することができます. この節では 3 種類の PPP について説明しています. それは ユーザ, カーネル, そして PPPoE (PPP オーバイーサネット) です. また SLIP のクライアントとサーバの設定についても記述しています. 最初に説明するのは, ユーザ PPP です. ユーザ PPP は FreeBSD に 2.0.5-RELEASE の時に, 既に存在していたカーネル実装の PPP に加えて導入されました. ユーザ PPP とカーネル PPP の主な違いは何かと疑問に思われるかも 知れませんが, その答えは簡単です. ユーザ PPP はデーモンとしては実行されず 必要に応じて実行されるのです. PPP インタフェイスを組み込んだカーネルは 必要ではなく, ユーザプロセスとして実行されカーネルとのデータの やり取りにはトンネルデバイスドライバ (tun) を 使用します. この節ではこれ以降ユーザ PPP のことは, pppd のような他の PPP ソフトウエアと特に区別する必要がある場合を除いて, 単に ppp と記述します. またこの節に記述されているコマンドは すべて root で実行されなければなりません. ユーザ ppp の利用 原作: &a.brian;, 協力: &a.nik;, Dirk-Willem van Gulik Dirk.vanGulik@jrc.it, Peter Childs pjchilds@imforei.apana.org.au. ユーザ PPP 前提条件 以下の情報を手に入れておく必要があるでしょう: PPP で接続するインターネットサービスプロバイダ (ISP) のアカウント. さらに, 接続済みのモデム (またはその他のデバイス) があり, プロバイダとの接続が可能なように正しく設定されている. プロバイダの電話番号. ログイン名とパスワード. これは通常の unix 形式のログイン名と パスワードの組という場合もありますし, PPP PAP または CHAP の ログイン名とパスワードの組という場合もあります. 一つ以上のネームサーバの IP アドレス. 通常, プロバイダから IP アドレスを二つ指示されている はずです. 一つすら提供されていないならば, ppp.conf ファイル中で enable dns コマンドを使って ppp にネームサーバを設定するよう 指示できます. プロバイダからは以下の情報が提供されているはずですが, どうしても必要というわけではありません: プロバイダのゲートウェイの IP アドレス. ゲートウェイとは, あなたがそこに接続をおこなって, デフォルトルート として設定することになるマシンです. プロバイダがこのアドレスを明示していなくても, 最初は 適当に設定しておいて, 接続時にプロバイダの PPP サーバから 正しいアドレスを教えてもらうことができます. このアドレスは, ppp から HISADDRとして参照されます. プロバイダのネットマスク設定. プロバイダが明示していないとしても, ネットマスクとして 255.255.255.0 を使用しておけば問題ありません. もしプロバイダから固定の IP アドレスとホスト名の割り当てを 受けていれば, その情報を指定しておくこともできます. 割り当てを受けていなければ, 接続先から適切な IP アドレスを指定してもらいます. もし, 必要な情報が不足していれば, プロバイダに連絡を取って 確認しておいてください. ppp 対応カーネルの構築 説明でも述べているように, ppp はカーネルの tun デバイスを使います. 使っているカーネルがどれであっても, tun デバイスを設定しなければなりません. FreeBSDに付属しているデフォルトの GENERIC カーネルに合うように tun デバイスは前もって設定されています. しかしながら, 自分で修正したカーネルをインストールするのであれば, pppが正しく動くよう, カーネルが設定されているか確認しなくてはいけません. これを確認するには, カーネルコンパイルディレクトリ (/sys/i386/conf または /sys/pc98/conf) に移動して, カーネルコンフィグレーションファイルを調べます. 以下の行がどこかに含まれている必要があります. pseudo-device tun 1 この行がカーネルコンフィグレーションファイルに 含まれていない場合, この行を追加して カーネルの再コンパイルとインストールをおこなう必要があります. 元々の GENERIC カーネルは 標準でこれを含んでいますので, カスタムカーネルをインストールしているのではなかったり, /sys ディレクトリが存在しないのであれば, 何も変更する必要はありません. カーネルコンフィグレーションの詳細については, FreeBSD カーネルのコンフィグレーション を参照してください. 以下のコマンドを実行することで, 現在のカーネルにトンネルデバイスが いくつ組み込まれているかを調べることができます: &prompt.root; ifconfig -a tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500 inet 200.10.100.1 --> 203.10.100.24 netmask 0xffffffff tun1: flags=8050<POINTOPOINT,RUNNING,MULTICAST> mtu 576 tun2: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500 inet 203.10.100.1 --> 203.10.100.20 netmask 0xffffffff tun3: flags=8010<POINTOPOINT,MULTICAST> mtu 1500 FreeBSD 4.0やより最近のリリースでは, すでに使われている tun デバイスしか見つけることが できないでしょう. これは, 全く tun デバイスを見つけることが できないかもしれないということです. しかし, もしこうなって しまっても, 心配することはありません. そのデバイスは ppp が使おうとする時に動的に作られるはず だからです. この例ではトンネルデバイスが四つ存在し, そのうち二つに 設定がおこなわれ, 使用中であることがわかります. 上の例で RUNNING フラグがオンになっている ものがありますが, これは そのインタフェースが何かに使用されていることを示している だけであるということに注意してください. つまり, RUNNING になっていない インタフェースがあったとしても, それはエラーではありません. トンネルデバイスがカーネルに組み込まれておらず, 何らかの理由で カーネルの再構築ができない場合でも, 方法がないわけではありません. 動的にデバイスをロードすることができるはずです. 詳細については &man.modload.8; や &man.lkm.4; など, 適切なマニュアルを参照してください. tun デバイスの確認 ほとんどのユーザは tun デバイス (/dev/tun0) が一つあれば充分でしょう. より多くのデバイスを使う場合 (すなわち, カーネルコンフィグレーション ファイルで pseudo-device tun の行に 1 以外の数値を指定している場合), 以下で tun0 と書かれている部分をすべて, あなたが使うデバイスの番号に あわせて読みかえてください. tun0 デバイスが正しく作成されていることを確認する最も簡単な方法は, それを作り直すことです. そのためには, 以下のコマンドを実行します: &prompt.root; cd /dev &prompt.root; ./MAKEDEV tun0 カーネルに 16 個のトンネルデバイスを組み込んだのであれば, tun0 だけでなく他の tun デバイスも作成しておく必要があるでしょう: &prompt.root; cd /dev &prompt.root; ./MAKEDEV tun15 また, カーネルが正しく設定されているかどうかを調べるために 以下のコマンドを実行して, このような出力が得られることを確認します: &prompt.root; ifconfig tun0 tun0: flags=8050<POINTOPOINT,RUNNING,MULTICAST> mtu 1500 まだ RUNNING フラグがセットされていない場合もあります. その時は以下のような出力が得られるでしょう: &prompt.root; ifconfig tun0 tun0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500 前述したように, FreeBSD 4.0 以降のリリースでは tun デバイスは要求に応じて 作られるので, もしそのデバイスがまだ使われていなければ, 見つけられないかもしれないということを思い出してください. 名前の解決に関する設定 リゾルバ (resolver) はシステムの一部分で, IP アドレスとホスト名との 変換をおこないます. IP アドレスとホスト名を対応させるためのマップを, 二つの場所のうちの一つから探すように設定できます. 一つめは /etc/hosts (man 5 hosts) と呼ばれるファイルです. 二つめはインターネット ドメインネームサービス (DNS) と呼ばれる 分散データベースですが, これに関する議論は このドキュメントで扱う範囲を 越えていますので, これについての説明はおこないません. リゾルバは名前のマッピングを おこなうシステムコールの集合体です. ただし どこからマッピング情報を見つけるのかは, 最初に指示しておく必要があります. これは まず /etc/host.conf ファイルを編集することでおこないます. 混乱の元になりますので, このファイルを /etc/hosts.conf と 呼んだりしてはいけません (余分な s がついていますね). <filename>/etc/host.conf</filename> ファイルの編集 このファイルには 以下の 2 行が (この順番で) 書かれているはずです: hosts bind これは, 最初に /etc/hosts ファイルを調べ, そこで目的の名前が 見つけられなかった場合に DNS を引きにいくようリゾルバに指示します. /etc/hosts(5) ファイルの編集 このファイルはローカルネットワーク上に存在するマシンの IP アドレスと ホスト名を含んでいるはずです. 最低でも ppp を動作させるマシンのエントリが 含まれている必要があります. そのマシンのホスト名が foo.bar.com で, IP アドレスが 10.0.0.1 であると仮定すると, /etc/hosts は 以下の行を含んでいなければいけません: 127.0.0.1 localhost.bar.com localhost 127.0.0.1 localhost.bar.com. 10.0.0.1 foo.bar.com foo 10.0.0.1 foo.bar.com. 一つめの行は localhost を現在のマシンの別名として定義しています. マシン固有の IP アドレスが何であっても, この行の IP アドレスは 常に 127.0.0.1 でなければいけません. 二つめの行はホスト名 foo.bar.com (と, その省略形 foo) を IP アドレス 10.0.0.1 にマップします. もしプロバイダから固定の IP アドレスとホスト名を割り当てられて いるのであれば, それを 10.0.0.1 エントリのかわりに使ってください. <filename>/etc/resolv.conf</filename> ファイルの編集 /etc/resolv.conf はリゾルバの振舞いを指定します. もし自前の DNS サーバを走らせているのなら, このファイルは空のままに しておくこともできます. 通常は, 以下のように書いておく必要があるでしょう: domain bar.com nameserver x.x.x.x nameserver y.y.y.y x.x.x.x と y.y.y.y はプロバイダから指示されたアドレスで, 接続するプロバイダが提供しているネームサーバを すべて書いてください. domain に指定するのは このマシンのデフォルトのドメイン名で, おそらく 書かなくても問題は無いでしょう. このファイルの各エントリの詳細については, resolv.conf のマニュアルページを参照してください. バージョン 2 以降の ppp を使用している場合には, enable dns コマンドを使用してネームサーバのアドレスを プロバイダに問い合わせるように指示することができます. 上の指定とは異なるアドレスをプロバイダが指定してきた場合 (または /etc/resolv.conf でネームサーバが指定されていない場合), ppp はプロバイダが指定したアドレスで resolv.conf を書きかえます. <command>ppp</command> の設定 ユーザ ppp と pppd (カーネルレベルの PPP 実装) は どちらも /usr/share/examples/ppp ディレクトリに置かれた設定ファイルを使います. ここには設定ファイルのサンプルが用意されていて, ユーザ ppp の設定を おこなう際に大変参考になりますので, 削除したりしないでください. ppp の設定をするためには, 必要に応じていくつかのファイルを編集する必要が あります. 書き込む内容は, プロバイダが静的に IP アドレスを割り当てる (つまり, 固定の IP アドレスを一つ与えられて, 常にそれを使う) か, または動的に IP アドレスを割り当てる (つまり, PPP セッションごとに IP アドレスが変化する可能性がある) かということに ある程度依存します. 静的 IP アドレスによる PPP 接続 まず /etc/ppp/ppp.conf という設定ファイルを作成する必要があります. これは以下の例とほとんど同じようなものになるでしょう. : で終る行は 1 カラム目から始め, その他の行はスペースまたはタブで以下の例のように 段をつける (インデントする) 必要があります. 1 default: 2 set device /dev/cuaa0 3 set speed 115200 4 set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" ATE1Q0 OK-AT-OK \\dATDT\\TTIMEOUT 40 CONNECT" 5 provider: 6 set phone "(123) 456 7890" 7 set login "TIMEOUT 10 \"\" \"\" gin:--gin: foo word: bar col: ppp" 8 set timeout 300 9 set ifaddr x.x.x.x y.y.y.y 255.255.255.0 0.0.0.0 10 add default HISADDR 11 enable dns ファイルでは行番号を取り除いておいてください. これは解説の際に参照する行を示すためにつけたものです. Line 1: デフォルトエントリを指定します. このエントリ中のコマンドは ppp が起動された際に自動的に実行されます. Line 2: モデムが接続されているデバイスを指定します. COM1: は /dev/cuaa0 に, COM2: は /dev/cuaa1 になります. Line 3: 通信速度 (DTE 速度) を指定します. もし 115200 が使えない (最近のモデムなら大抵使えるはずですが) 場合には, かわりに 38400 を指定してみてください. Line 4: ダイアルスクリプトを指定します. ユーザ PPP は &man.chat.8; 言語に似た, 受信待ち文字列と 送信文字列の対からなるスクリプトを使用します. この言語の機能に関しては, マニュアルページを参照してください. Line 5: 接続するプロバイダの名前 provider を エントリ名として指定します. Line 6: このプロバイダの電話番号を指定します. 複数の電話番号を : や | で区切って指定することができます. これら区切り文字の違いについては, &man.ppp.8 に 詳しく書かれています. 要約すると, 毎回違う番号に かけたいのであれば : を使います. 常に まず先頭の番号にかけてみて, つながらない時にだけ 2 番目以降の番号に かけたいのであれば | を使います. 例に示されているように, 常に電話番号全体を引用符で くくって (クォートして) おきます. Line 7: ダイアルスクリプトと同様に, ログインスクリプトも chat 言語風の記述をおこないます. この例は, 以下のようなログインセッションを使用する プロバイダのためのものです: J. Random Provider login: foo password: bar protocol: ppp このスクリプトは必要に応じて 書きかえなければならないでしょう. 初めてスクリプトを書く時には, 予想した通りに 処理が進んだかどうかを確認するため, chat ログを とるようにしておいた方が良いでしょう. PAP や CHAP を使用する場合には, ここでログインすることは ありませんから, ログイン文字列は空白のままにしておくべきです. 詳細については PAP および CHAP による認証を参照してください. Line 8: デフォルトの接続タイムアウト時間を (秒数で) 指定します. この例では, 300 秒間 通信がおこなわれなければ 自動的に接続を切るように指定しています. タイムアウトさせたくない場合には, この値を 0 に設定します. Line 9: インタフェースのアドレスを指定します. 文字列 x.x.x.x は プロバイダに割り当てられた IP アドレスで置きかえてください. 文字列 y.y.y.y はプロバイダから指示されたゲートウェイ (接続先となるマシン) の IP アドレスで置きかえてください. プロバイダがゲートウェイのアドレスを 指示していない場合は, 10.0.0.2/0 を使用しておいてください. もし 仮の アドレスを使用する必要がある場合には, 動的 IP アドレスによる PPP 接続に関する指示に従って, /etc/ppp/ppp.linkup にエントリを作成していることを 確認してください. この行が省略されている場合, ppp を モードで動作させることはできません. Line 10: プロバイダのゲートウェイへの経路を デフォルトルートとして 追加します. 特殊文字列 HISADDR は, 9 行目で指定された ゲートウェイのアドレスで置きかえられます. HISADDR は 9 行目までは初期化されていませんので, その行よりも後でしか使えないことに 注意してください. Line 11: ネームサーバのアドレスが正しいか どうかを確認するため, プロバイダに問い合わせをおこなうよう ppp に指示します. プロバイダがこの機能をサポートしていれば, ppp は /etc/resolv.conf のネームサーバエントリを 正しいアドレスに更新することができます. 静的な IP アドレスを持っていて, 接続が完了する前にルーティングテーブルの エントリが正しく設定されているのであれば, ppp.linkup に エントリを追加する必要はありません. しかし, この場合でもエントリを追加して, 接続が完了した時点で プログラムを呼び出したいことがあるかもしれません. これについては後ほど sendmail を例として説明します. これらの設定ファイルのサンプルが /usr/share/examples/ppp ディレクトリに 置かれています. 動的 IP アドレスによる PPP 接続 プロバイダが静的な IP アドレスの割り当てをおこなっていない場合, ppp が相手側のホスト (ゲートウェイ) と交渉して, こちら側と相手側のアドレスを 決めるように設定することができます. これは, 起動時には仮のアドレスを使っておいて, 接続後に IP コンフィグレーション プロトコル (IPCP) を使用して ppp が IP アドレスを正しく設定できるようにすることで実現されます. 静的 IP アドレスによる PPP 接続に 以下の変更を加える以外は, ppp.conf の設定は同じです: 9 set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 繰り返しますが, 行番号は取り除いておいてください. これは解説の際に参照する行を示すためにつけたものです. なお, 少なくともスペース 1 個分の段づけ (インデント) が必要です. Line 9: / 文字の後ろの数字は, アドレス交渉の際に固定しておきたい ビットの数です. 場合によっては, もっと適切な IP アドレスを 指定しておきたいこともあるかもしれませんが, ほとんどの場合には 上の例の通りで問題ありません. 最後の引数 (0.0.0.0) は, アドレスの交渉の際に 10.0.0.1 ではなく 0.0.0.0 を使用するよう ppp に指示するためのものです. set ifaddr コマンドの最初の引数として 0.0.0.0 を指定してはいけません. さもないと, モードで動作させる際に 初期経路を設定することができなくなります. バージョン 1.X の ppp を使用する場合, /etc/ppp/ppp.linkup にもエントリを作成しておく必要があります. ppp.linkup は接続が確立された後に使用されます. この時点では, ppp は実際にどの IP アドレスを使うべきなのか わかっているはずです. 以下のエントリは存在する仮の経路を削除し, 正しい経路を作成します: 1 provider: 2 delete ALL 3 add default HISADDR Line 1: 接続を確立する際に, ppp は以下のルールに従って ppp.linkup のエントリを検索します: まず ppp.conf で使用されたのと同じラベルを探します. もし見つからなければ, ゲートウェイの IP アドレスのエントリを 探します. このエントリは 4 オクテットの IP アドレス形式の ラベルです. それでも まだエントリが見つからなければ, MYADDR エントリを探します. Line 2: この行は, 使用する tun インタフェースに関する既存の経路を (ダイレクトルートのエントリを除き) すべて削除するよう ppp に指示します. Line 3: この行は HISADDR への経路をデフォルトルートとして 追加するように ppp に指示します. HISADDR は IPCP で 決定されたゲートウェイの IP アドレスで置きかえられます. 詳細なサンプルについては, /usr/share/examples/ppp/ppp.conf.sample ファイル中のpmdemand エントリと /usr/share/examples/ppp/ppp.linkup.sample を参照してください. バージョン 2 の ppp から sticky routes が導入されました. MYADDR や HISADDR を含む add コマンドと delete コマンドを記憶して, MYADDR や HISADDR の アドレスが変化した際には経路の再設定をおこないます. したがって, これらのコマンドを ppp.linkup に 繰り返し記述する必要は無くなりました. かかってきた電話を <command>ppp</command> で受けるには かかってきた電話を ppp が受けるように設定する際に, そのマシンが LAN に接続されているのであれば, パケットを LAN に転送するかどうかを決定する必要があります. 転送をおこなう場合には, その LAN のサブネットから IP アドレスを ppp クライアントに割り当て, 以下のコマンドを指定するのが良いでしょう. gateway_enable=YES どの getty を使いますか? getty でダイアルアップサービスをおこなう場合の優れた解説が FreeBSD でダイアルアップサービスをおこなうための設定 にあります. getty に代わるものとしては, mgetty があります. これは getty をより柔軟にしたもので, ダイアルアップ回線での使用を意図して 設計されています. mgetty を使う場合の利点は, mgetty が積極的にモデムと通信する ということです. つまり, もし /etc/ttys でポートを閉じている場合, モデムは電話をとらなくなります. 最近のバージョンの mgetty (0.99beta 以降) では, PPP ストリームの 自動検出もサポートされています. これにより, クライアント側で スクリプトを準備しなくてもサーバに アクセスすることができます. mgetty に関する, より詳細な情報については Mgetty と AutoPPP を参照してください. ppp の実行許可 ppp は通常, ID 0 のユーザ (root) として動作しなければいけませんが, 以下で説明するように, ppp を通常のユーザとしてサーバモードで実行させたい 場合には, そのユーザを /etc/group の network グループに 追加して, ppp を実行する許可を与えておかなければいけません. また, そのユーザが設定ファイル内の目的のエントリに アクセスできるように, 以下のように allow コマンドで許可を与えておく必要があります: allow users fred mary このコマンドがデフォルトエントリに 書かれている場合には, 指定されたユーザは すべてのエントリをアクセスできるようになります. 動的 IP ユーザのための ppp シェルの設定 /etc/ppp/ppp-shell という名前で, 以下のような内容のファイルを 作成します: #!/bin/sh IDENT=`echo $0 | sed -e 's/^.*-\(.*\)$/\1/'` CALLEDAS="$IDENT" TTY=`tty` if [ x$IDENT = xdialup ]; then IDENT=`basename $TTY` fi echo "PPP for $CALLEDAS on $TTY" echo "Starting PPP for $IDENT" exec /usr/sbin/ppp -direct $IDENT このスクリプトには実行可能属性をつけておきます. 次に, 以下のコマンドを実行し, ppp-dialup という名前で このスクリプトへのリンクを作成します: &prompt.root; ln -s ppp-shell /etc/ppp/ppp-dialup すべてのダイアルアップ ppp ユーザのログインシェルとして このスクリプトを使用します. 以下は pchilds というユーザ名の ダイアルアップユーザを /etc/password へ登録した場合の例です. (パスワードファイルを直接エディタで編集したりせず, vipw を使ってください) pchilds:*:1011:300:Peter Childs PPP:/home/ppp:/etc/ppp/ppp-dialup 任意のユーザが読むことのできる, /home/ppp ディレクトリを 作成します. /etc/motd が表示されないようにするため, このディレクトリには以下のように大きさが 0 バイトのファイルを 作成しておきます. -r--r--r-- 1 root wheel 0 May 27 02:23 .hushlogin -r--r--r-- 1 root wheel 0 May 27 02:22 .rhosts 静的 IP ユーザのための PPP シェルの設定 上記と同じように ppp-shell ファイルを作成し, 静的な IP アドレスを割り当てるアカウントそれぞれについて ppp-shell へのシンボリックリンクを作成します. 例えば, クラス C ネットワークの経路制御を必要とする, 三人のダイアルアップユーザ fred, sam, mary がいるとすると, 以下のコマンドを実行することになります: &prompt.root; ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-fred &prompt.root; ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-sam &prompt.root; ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-mary これらのユーザのダイアルアップアカウントでは, 上で作成した それぞれのシンボリックリンクを ログインシェルとして設定しておきます. (つまり, ユーザ mary のログインシェルは /etc/ppp/ppp-mary に なります). 動的 IP ユーザのための ppp.conf の設定 /etc/ppp/ppp.conf ファイルは, 大体以下のような内容になるでしょう: default: set debug phase lcp chat set timeout 0 ttyd0: set ifaddr 203.14.100.1 203.14.100.20 255.255.255.255 enable proxy ttyd1: set ifaddr 203.14.100.1 203.14.100.21 255.255.255.255 enable proxy 上の例のように段をつける (インデントする) 必要があることに注意してください. default: エントリはセッションごとにロードされます. /etc/ttys で有効にしてある各ダイアルアップ回線ごとに一つ, 上記の ttyd0: のようなエントリを作成します. 各行の相手側アドレスとして, それぞれ別の IP アドレスを 動的 IP ユーザのための IP アドレスのプールから割り当てておく必要があります. 静的 IP ユーザのための <filename>ppp.conf</filename> の設定 上のサンプルの /usr/share/examples/ppp/ppp.conf の内容に加えて, 静的に IP を割り当てられたダイアルアップユーザ それぞれのためのエントリを追加する必要があります. ここでも fred, sam, mary の例を使うことにしましょう. fred: set ifaddr 203.14.100.1 203.14.101.1 255.255.255.255 sam: set ifaddr 203.14.100.1 203.14.102.1 255.255.255.255 mary: set ifaddr 203.14.100.1 203.14.103.1 255.255.255.255 必要であれば, それぞれの静的 IP ユーザに対する経路制御情報も /etc/ppp/ppp.linkup ファイルに書いておくべきでしょう. 以下の例ではクライアントの PPP リンクを経由する, クラス C の 203.14.101.0 ネットワークへの経路を追加しています. fred: add 203.14.101.0 netmask 255.255.255.0 HISADDR sam: add 203.14.102.0 netmask 255.255.255.0 HISADDR mary: add 203.14.103.0 netmask 255.255.255.0 HISADDR <command>mgetty</command>, AutoPPP, マイクロソフト拡張の詳細 <command>mgetty</command> と AutoPPP AUTO_PPP オプションつきでコンパイルした mgetty を使えば, mgetty が PPP 接続の LCP フェーズを検出して, 自動的に PPP シェルを起動するように 設定することができます. しかし この場合, デフォルトの login/password シーケンスは発生しないので, ユーザの認証は PAP または CHAP を使っておこなう必要があります. このセクションでは, ユーザ (あなた) が問題なく AUTO_PPP オプションつきの mgetty (v0.99beta またはそれ以降) の設定, コンパイル, インストールができているものと仮定しています. /usr/local/etc/mgetty+sendfax/login.config ファイルが 以下の行を含んでいることを確認してください: /AutoPPP/ - - /etc/ppp/ppp-pap-dialup これにより, PPP 接続を検出したら mgetty が ppp-pap-dialup スクリプトを実行するようになります. /etc/ppp/ppp-pap-dialup という名前で, 以下のような内容のファイルを 作成します (このファイルには実行可能属性を つけておく必要があります): #!/bin/sh exec /usr/sbin/ppp -direct pap さらに, かかってきた電話すべてを自分で扱うエントリを /etc/ppp/ppp.conf に作成します. pap: enable pap set ifaddr 203.14.100.1 203.14.100.20-203.14.100.40 enable proxy この方法でログインする それぞれのユーザは, PAP によるユーザ認証を おこなうために /etc/ppp/ppp.secret ファイルにユーザ名とパスワードを 書いておくか, または /etc/password ファイルを使うように, enable passwdauth ユーザに静的な IP アドレスを割り当てる場合には, そのアドレスを /etc/ppp/ppp.secret の第三引数として指定することができます. サンプルについては, /usr/share/examples/ppp/ppp.secret.sample を参照してください. マイクロソフト拡張 クライアントからの要求に応じて, ppp が DNS や NetBIOS ネームサーバの アドレスを通知するように 設定をおこなうこともできます. バージョン 1.X の ppp で これらの拡張機能を有効にするには, 以下の行を /etc/ppp/ppp.conf の適切なセクションに追加する必要があるでしょう. enable msext set ns 203.14.100.1 203.14.100.2 set nbns 203.14.100.5 バージョン 2 以降の ppp では, 以下のようになります: accept dns set dns 203.14.100.1 203.14.100.2 set nbns 203.14.100.5 これにより, クライアントはプライマリと セカンダリのネームサーバアドレス および NetBIOS ネームサーバホストを知ることができます. バージョン 2 以降の ppp では, set dns の行を省略した場合には /etc/resolv.conf に書かれているネームサーバのアドレスを使用します. PAP および CHAP による認証 いくつかのプロバイダでは, PAP または CHAP のいずれかの認証メカニズムを 使用して接続時の認証をおこなうように システムを設定しています. この場合, プロバイダは接続の際に login: プロンプトを送信せず, 最初から PPP で通信を始めようとするでしょう. PAP ではパスワードがそのまま送られてしまうため, CHAP に比べると安全性が 低くなりますが, このパスワードはシリアル回線のみを通して送られます. そのため, クラッカーが 盗み聞き する余地は多くないので, 通常ここの セキュリティは問題にはなりません. 静的 IP アドレスによる PPP 接続または 動的 IP アドレスによる PPP 接続の セクションに戻って, 以下の変更をおこないます: 7 set login … 12 set authname MyUserName 13 set authkey MyPassword これまでと同様に, 行番号は取り除いておいてください. これは解説の際に参照する行を示すためにつけたものです. なお, 少なくともスペース 1 個分の段づけ (インデント) が必要です. Line 7: PAP または CHAP を使用する場合, 通常 プロバイダはサーバへの ログインを必要としません. そのため, set login 文字列を 無効にしておかなければいけません. Line 12: この行は PAP/CHAP ユーザ名を指定します. MyUserName に 正しい値を入れておく必要があります. Line 13: この行は PAP/CHAP パスワードを指定します. MyPassword に 正しい値を入れておく必要があります. PAP と CHAP はデフォルトで両方とも 受け付けられるようになって いますが, PAP や CHAP を使用するという 意思を明示するために, 15 accept PAP または 15 accept CHAP という行を追加しておくのも良いでしょう. 動作中の ppp の設定変更 適切な診断ポートが設定されている場合には, バックグラウンドで動作中の ppp プログラムと通信することができます. この設定をおこなうためには, 以下の行を設定ファイルに追加しておきます: set server /var/run/ppp-tun%d DiagnosticPassword 0177 これにより, ppp は指定された unix ドメインの ソケットをモニタして, クライアントから正しいパスワードを受け取った後に アクセスを許可します. このソケット名に含まれる %d は, この ppp が使用している tun デバイスの デバイス番号で置きかえられます. 一旦ソケットの設定が終了したら, スクリプト中で &man.pppctl.8; を 使用して, 動作中の ppp を操作することができるでしょう. システムの最終設定 これで ppp の設定は終りました. しかし ppp を動かす前に, まだ少し必要なことがあります. それらの設定は, すべて /etc/rc.conf ファイルを 編集することでおこないます. (このファイルは以前には /etc/sysconfig と呼ばれていました) このファイルを上から順に設定していきます. まずは hostname= の行が設定されていることを確認します. 例えば以下のように: hostname="foo.bar.com" もしプロバイダが静的な IP アドレスとホスト名を割り当てているのなら, ホスト名としてそれを使うのが おそらくベストでしょう. 次に network_interfaces 変数を調べます. 必要に応じて (on demand) プロバイダにダイアルするようにシステムを設定したい場合には, tun0 デバイスがこのリストに追加されていることを確認しておきます. それ以外の場合には, tun0 デバイスをリストから削除しておきます. network_interfaces="lo0 tun0" ifconfig_tun0= ifconfig_tun0 変数が空で, /etc/start_if.tun0 という名前の ファイルが作成されていなければなりません. このファイルの内容は以下のようになります. ppp -auto mysystem このスクリプトはネットワークの設定時に実行され, ppp デーモンを自動モードで立ち上げます. このマシンがもし LAN のゲートウェイであれば, スイッチも使用したいと思うかもしれません. 詳細に関しては, マニュアルページを参照してください. 以下のようにルータプログラムを NO に設定します. router_enable="NO" routed は, ppp が作成したデフォルトのルーティングテーブル エントリを削除してしまう場合がありますので, (初期設定では起動されるようになっている) routed デーモンが 起動されないようにしておくことが重要です. sendmail_flags 行が オプションを含まないように 設定しておいた方がよいでしょう. さもないと, sendmail が アドレスを調べようとして発信をおこなってしまう場合があります. 以下のような設定で良いでしょう: sendmail_flags="-bd" この結果, PPP リンクを立ち上げた時には いつでも以下のコマンドを実行して, キューにたまっているメールを sendmail に送信させる作業が必要になるでしょう. &prompt.root; /usr/sbin/sendmail -q ppp.linkup 中で !bg コマンドを使用することで, これを自動的に おこなうこともできます: 1 provider: 2 delete ALL 3 add 0 0 HISADDR 4 !bg sendmail -bd -q30m こうするのが嫌であれば, SMTP トラフィックをブロックするように dfilter を設定しておくこともできます. 詳細についてはサンプルファイルを参照してください. 後はマシンをリブートするだけです. リブートが終ったら, &prompt.root; ppp コマンドを実行し, 続いて PPP セッションを開始させるために dial provider と入力することもできますし, (start_if.tun0 スクリプトを作成していない場合に), 外部へのトラフィックが発生した時に, ppp が自動的に セッションを確立してくれるようにしたいのであれば, 以下のコマンドを実行することもできます. &prompt.root; ppp -auto provider まとめ 要約すると, 初めて ppp を設定する際には, 以下のステップが不可欠です: クライアント側: カーネルに tun デバイスが組み込まれていることを確認. /dev ディレクトリに tunX デバイスファイルが 存在することを確認. /etc/ppp/ppp.conf にエントリを作成. ほとんどのプロバイダでは, pmdemand の例で充分でしょう. 動的 IP アドレスを使用するなら, /etc/ppp/ppp.linkup に エントリを作成. /etc/rc.conf (または sysconfig) ファイルを更新. 必要に応じてダイヤル (demand dialing) したいのであれば, start_if.tun0 スクリプトを作成. サーバ側: カーネルに tun デバイスが組み込まれていることを確認. /dev ディレクトリに tunX デバイスファイルが 存在することを確認. (&man.vipw.8; コマンドを使って) /etc/passwd にエントリを作成. このユーザのホームディレクトリに ppp -direct direct-server か何かを実行するプロファイルを作成. /etc/ppp/ppp.conf にエントリを作成. direct-server の例で充分でしょう. /etc/ppp/ppp.linkup にエントリを作成. /etc/rc.confファイルを更新. カーネル PPP の利用 原作: Gennady B. Sorokopud gena@NetVision.net.il, Robert Huff rhuff@cybercom.net. 訳: &a.jp.graphite;. 1996 年 9 月 6 日. カーネル PPP の設定 PPP の設定を始める前に, pppd が /usr/sbin にあり, また /etc/ppp という ディレクトリが存在することを確認してください. pppd はふたつのモードで動作します. クライアント モード. シリアル接続やモデムを利用して, そのマシンを 外部のネットワークに PPP 接続したい場合に用います. サーバ モード. そのマシンがネットワーク上にあるときに, PPP を使って ほかのコンピュータを接続する際に用います. どちらの場合でも, オプションファイルを設定する必要があります (/etc/ppp/options または, そのマシン上で PPP を使用する人が 複数いる場合には ~/.ppprc). また, ダイヤルとリモートホストへの接続をおこなうために, シリアル接続やモデムを 操作する, なんらかのソフトウェアが必要です (kermit が適しているでしょう). PPP クライアントとしての動作 わたしは, CISCO ターミナルサーバの PPP 回線に接続するために, 下記のような /etc/ppp/options を使用しています. crtscts # enable hardware flow control modem # modem control line noipdefault # remote PPP server must supply your IP address. # if the remote host doesn't send your IP during IPCP # negotiation , remove this option passive # wait for LCP packets domain ppp.foo.com # put your domain name here :<remote_ip> # put the IP of remote PPP host here # it will be used to route packets via PPP link # if you didn't specified the noipdefault option # change this line to <local_ip>:<remote_ip> defaultroute # put this if you want that PPP server will be your # default router 接続方法: kermit (またはその他のモデム操作プログラム) を使ってリモートホストに ダイヤルし, 接続してください. そして, あなたのユーザ名とパスワード (必要 であれば, その他にもリモートホストで PPP を有効にするための操作) を入力 します. kermit を抜けてください. (回線を切断せずに) 下記のように入力します: &prompt.root; /usr/src/usr.sbin/pppd.new/pppd /dev/tty01 19200 (通信速度とデバイス名には, あなたの環境に適したものを入れてください) これでこのコンピュータは PPP で接続されました. もし, なんらかの理由で 接続に失敗したならば, /etc/ppp/options ファイルに オプションを追加して, 問題点を突き止めるために, コンソールに表示される メッセージを調べてください. 下記の /etc/ppp/pppup スクリプトは, 上記の作業を すべて自動的におこないます: #!/bin/sh ps ax |grep pppd |grep -v grep pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing pppd, PID=' ${pid} kill ${pid} fi ps ax |grep kermit |grep -v grep pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing kermit, PID=' ${pid} kill -9 ${pid} fi ifconfig ppp0 down ifconfig ppp0 delete kermit -y /etc/ppp/kermit.dial pppd /dev/tty01 19200 /etc/ppp/kermit.dial は kermit 用のスクリプトで, ダイヤルして, リモートホストでの認証に必要なすべての処理をおこないます. (そのようなスクリプトの例は この文書の終わりに添付してあります) PPP 接続を切断するには, 下記のような /etc/ppp/pppdown スクリプトを 使用します: #!/bin/sh pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'` if [ X${pid} != "X" ] ; then echo 'killing pppd, PID=' ${pid} kill -TERM ${pid} fi ps ax |grep kermit |grep -v grep pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing kermit, PID=' ${pid} kill -9 ${pid} fi /sbin/ifconfig ppp0 down /sbin/ifconfig ppp0 delete kermit -y /etc/ppp/kermit.hup /etc/ppp/ppptest PPP が動作中かどうかを調べます (/usr/etc/ppp/ppptest): #!/bin/sh pid=`ps ax| grep pppd |grep -v grep|awk '{print $1;}'` if [ X${pid} != "X" ] ; then echo 'pppd running: PID=' ${pid-NONE} else echo 'No pppd running.' fi set -x netstat -n -I ppp0 ifconfig ppp0 モデム回線を切断します (/etc/ppp/kermit.hup): set line /dev/tty01 ; put your modem device here set speed 19200 set file type binary set file names literal set win 8 set rec pack 1024 set send pack 1024 set block 3 set term bytesize 8 set command bytesize 8 set flow none pau 1 out +++ inp 5 OK out ATH0\13 echo \13 exit 次は kermit の代わりに chat を使う方法です. 原作: Robert Huff rhuff@cybercom.net. pppd 接続を確立するためには, 次の二つのファイルの設定だけで十分です. /etc/ppp/options: /dev/cuaa1 115200 crtscts # enable hardware flow control modem # modem control line connect "/usr/bin/chat -f /etc/ppp/login.chat.script" noipdefault # remote PPP serve must supply your IP address. # if the remote host doesn't send your IP during # IPCP negotiation, remove this option passive # wait for LCP packets domain <your.domain> # put your domain name here : # put the IP of remote PPP host here # it will be used to route packets via PPP link # if you didn't specified the noipdefault option # change this line to <local_ip>:<remote_ip> defaultroute # put this if you want that PPP server will be # your default router /etc/ppp/login.chat.script: (実際には一行になります.) ABORT BUSY ABORT 'NO CARRIER' "" AT OK ATDT<phone.number> CONNECT "" TIMEOUT 10 ogin:-\\r-ogin: <login-id> TIMEOUT 5 sword: <password> 正しくインストールし編集した後は, 必要な事はこれだけです &prompt.root; pppd このサンプルは主に Trev Roydhouse <Trev.Roydhouse@f401.n711.z3.fidonet.org> から寄せられた情報に基づいており, 承諾を得て使用しています. PPP サーバとしての動作 /etc/ppp/options: crtscts # Hardware flow control netmask 255.255.255.0 # netmask ( not required ) 192.114.208.20:192.114.208.165 # ip's of local and remote hosts # local ip must be different from one # you assigned to the ethernet ( or other ) # interface on your machine. # remote IP is ip address that will be # assigned to the remote machine domain ppp.foo.com # your domain passive # wait for LCP modem # modem line 下記のような /etc/ppp/pppserv スクリプトで, そのマシンを PPP サーバにすることができます. #!/bin/sh ps ax |grep pppd |grep -v grep pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing pppd, PID=' ${pid} kill ${pid} fi ps ax |grep kermit |grep -v grep pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing kermit, PID=' ${pid} kill -9 ${pid} fi # reset ppp interface ifconfig ppp0 down ifconfig ppp0 delete # enable autoanswer mode kermit -y /etc/ppp/kermit.ans # run ppp pppd /dev/tty01 19200 PPP サーバを終了するには, この /etc/ppp/pppservdown スクリプト を使用します: #!/bin/sh ps ax |grep pppd |grep -v grep pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing pppd, PID=' ${pid} kill ${pid} fi ps ax |grep kermit |grep -v grep pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing kermit, PID=' ${pid} kill -9 ${pid} fi ifconfig ppp0 down ifconfig ppp0 delete kermit -y /etc/ppp/kermit.noans 下記の kermit スクリプトは, モデムの自動応答機能を有効, または無効にします (/etc/ppp/kermit.ans): set line /dev/tty01 set speed 19200 set file type binary set file names literal set win 8 set rec pack 1024 set send pack 1024 set block 3 set term bytesize 8 set command bytesize 8 set flow none pau 1 out +++ inp 5 OK out ATH0\13 inp 5 OK echo \13 out ATS0=1\13 ; change this to out ATS0=0\13 if you want to disable ; autoanswer mod inp 5 OK echo \13 exit この /etc/ppp/kermit.dial スクリプトは, リモートホストに ダイヤルし, 認証手続きをするのに使用します. あなたは必要に応じて, これを 変更しないといけないでしょう. あなたのユーザ名とパスワードをこの スクリプトに書かなければいけませんし, モデムやリモートホストからの 応答によっては, 入力待ちの文を変更する必要もあります. ; ; put the com line attached to the modem here: ; set line /dev/tty01 ; ; put the modem speed here: ; set speed 19200 set file type binary ; full 8 bit file xfer set file names literal set win 8 set rec pack 1024 set send pack 1024 set block 3 set term bytesize 8 set command bytesize 8 set flow none set modem hayes set dial hangup off set carrier auto ; Then SET CARRIER if necessary, set dial display on ; Then SET DIAL if necessary, set input echo on set input timeout proceed set input case ignore def \%x 0 ; login prompt counter goto slhup :slcmd ; put the modem in command mode echo Put the modem in command mode. clear ; Clear unread characters from input buffer pause 1 output +++ ; hayes escape sequence input 1 OK\13\10 ; wait for OK if success goto slhup output \13 pause 1 output at\13 input 1 OK\13\10 if fail goto slcmd ; if modem doesn't answer OK, try again :slhup ; hang up the phone clear ; Clear unread characters from input buffer pause 1 echo Hanging up the phone. output ath0\13 ; hayes command for on hook input 2 OK\13\10 if fail goto slcmd ; if no OK answer, put modem in command mode :sldial ; dial the number pause 1 echo Dialing. output atdt9,550311\13\10 ; put phone number here assign \%x 0 ; zero the time counter :look clear ; Clear unread characters from input buffer increment \%x ; Count the seconds input 1 {CONNECT } if success goto sllogin reinput 1 {NO CARRIER\13\10} if success goto sldial reinput 1 {NO DIALTONE\13\10} if success goto slnodial reinput 1 {\255} if success goto slhup reinput 1 {\127} if success goto slhup if < \%x 60 goto look else goto slhup :sllogin ; login assign \%x 0 ; zero the time counter pause 1 echo Looking for login prompt. :slloop increment \%x ; Count the seconds clear ; Clear unread characters from input buffer output \13 ; ; put your expected login prompt here: ; input 1 {Username: } if success goto sluid reinput 1 {\255} if success goto slhup reinput 1 {\127} if success goto slhup if < \%x 10 goto slloop ; try 10 times to get a login prompt else goto slhup ; hang up and start again if 10 failures :sluid ; ; put your userid here: ; output ppp-login\13 input 1 {Password: } ; ; put your password here: ; output ppp-password\13 input 1 {Entering SLIP mode.} echo quit :slnodial echo \7No dialtone. Check the telephone line!\7 exit 1 ; local variables: ; mode: csh ; comment-start: "; " ; comment-start-skip: "; " ; end: PPP オーバイーサネット (PPPoE) の利用 原作: &a.jim; ( node.to より) 10 Jan 2000. 以下の解説は, PPPoE として知られる, PPP オーバイーサネットの設定法です. 必要なもの あなたのシステムで PPPoE を適切に機能させるためには, 以下のものが必要です. FreeBSD 3.4やそれより新しいバージョンのカーネルソース FreeBSD 3.4やそれより新しいバージョンのppp カーネルコンフィギュレーション 以下に示すオプションをカーネルコンフィギュレーションファイルに 追加して, その後 新しいカーネルを コンパイルする必要があります. options NETGRAPH 以下は任意 options NETGRAPH_PPPOE options NETGRAPH_SOCKET この機能は実行時には有効ではありませんが, 要求に応じて ppp は関係のあるモジュールを 読み込みます. <filename>ppp.conf</filename> の設定 これは動作している ppp.conf の 例です: default: # or name_of_service_provider set device PPPoE:xl1 # replace xl1 with your ethernet device set mru 1492 set mtu 1492 set authname YOURLOGINNAME set authkey YOURPASSWORD set log Phase tun command # you can add more detailed logging if you wish set dial set login set ifaddr 10.0.0.1/0 10.0.0.2/0 add default HISADDR nat enable yes # if you want to enable nat for your local net papchap: set authname YOURLOGINNAME set authkey YOURPASSWORD オプションを付けてPPPoE を起動する際には注意するべきです. <application>PPP</application> の起動 以下を root 権限において実行することで, - 起動させることができます.: + 起動させることができます: &prompt.root; ppp -ddial name_of_service_provider システム起動時に <application>PPP</application> を立ち上げる /etc/rc.conf ファイルに以下の行を追加 してください: ppp_enable="YES" ppp_mode="ddial" ppp_nat="YES" ppp_profile="default" # or your provider SLIP の利用 原作: &a.asami;,&a.ghelmer;, 協力: &a.wilko;, &a.piero;. 訳: &a.hanai; 1996 年 8 月 8 日. SLIPクライアントのセットアップ ここには FreeBSD マシンを静的アドレスのネットワークにつなげる場合の SLIPのセットアップの一つの方法を書いてあります. ホスト名を動的に割り当てる(つまり, ダイヤルアップするたびにアドレスが かわる)ためには, おそらくもっと凝ったことが必要です. まず, モデムがどのシリアルポートにつながっているか決めましょう. 私は /dev/cuaa1 から /dev/modemへというシンボリックリンクを張り, コンフィグレーションではその名前だけを使っています. /etc や.kermrc など, システム全体に散らばっているファイルを修正する 必要がでるとまったく煩わしいのです! ここで, /dev/cuaa0は COM1であり, cuaa1はCOM2です. カーネルのコンフィグレーションファイルに pseudo-device sl 1 という記述があるのを確認してください. これは GENERIC カーネルに含まれている ので削除していない限り大丈夫でしょう. 最初の設定 /etc/hosts ファイルにあなたのマシンのゲートウェイとネームサーバ を加えてください. 私のは以下のようになっています. 127.0.0.1 localhost loghost 136.152.64.181 silvia.HIP.Berkeley.EDU silvia.HIP silvia 136.152.64.1 inr-3.Berkeley.EDU inr-3 slip-gateway 128.32.136.9 ns1.Berkeley.edu ns1 128.32.136.12 ns2.Berkeley.edu ns2 /etc/host.conf ファイル中で が よりも前にあること を確認してください. さもないとヘンなことが起こるかもしれません. /etc/rc.conf ファイルを編集してください. なお, お使いの FreeBSD が 2.2.2 よりも前のバージョンのものの場合は, /etc/sysconfig を編集してください. 行 hostname=myname.my.domain を編集してホスト名をセットしてください. 完全なInternetホスト名を与えるべきです. 行 network_interfaces="lo0" を network_interfaces="lo0 sl0" へ変更することにより ネットワークインタフェースのリストに sl0 を加えてください. 行 ifconfig_sl0="inet ${hostname} slip-gateway netmask 0xffffff00 up" を加えて sl0 のスタートアップフラグをセットしてください. 行 defaultrouter=NO を defaultrouter=slip-gateway へ変更してデフォルトのルータを 指定してください. 次の domain HIP.Berkeley.EDU nameserver 128.32.136.9 nameserver 128.32.136.12 という内容を含むファイル /etc/resolv.conf を作ってください. 見ればわかるように, これらはネームサーバホストを設定しています. もちろん, 実際のドメイン名やアドレスは あなたの環境に依存します. root と toor (及びパスワードを持っていない他のアカウントすべて) のパスワード を設定してください. passwdコマンドを使いましょう. /etc/passwd や /etc/master.passwd といったファイルを編集してはいけません! マシンを再起動して正しいホスト名で 立ち上がることを確認してください. SLIP接続をおこなう モデムを起動, つながったらプロンプトで slipとタイプし, マシン名と パスワードを入力してください. 入力する必要があるものは環境に よって異なります. 私は次のようなスクリプトでkermitを使っています. # kermit setup set modem hayes set line /dev/modem set speed 115200 set parity none set flow rts/cts set terminal bytesize 8 set file type binary # The next macro will dial up and login define slip dial 643-9600, input 10 =>, if failure stop, - output slip\x0d, input 10 Username:, if failure stop, - output silvia\x0d, input 10 Password:, if failure stop, - output ***\x0d, echo \x0aCONNECTED\x0a (もちろん, ホスト名とパスワードは変える必要があります). 接続するためには kermit のプロンプトで slipとタイプするだけです. ファイルシステムのどんなところにもプレインテキスト にパスワードを書いておくのは一般的にはよくありません. 覚悟の上で やってください. 私は単に不精なだけです. ここでkermitから抜け出し (zでkermitをサスペンドできます), root で &prompt.root; slattach -h -c -s 115200 /dev/modem と入力しましょう. もしルータの向う側のホストへ ping できるなら接続成功です! もしうまく いかなければslattachへの引数として の代わりにとやってみてください. 接続の切り方 slattachを殺すためにrootで &prompt.root; kill -INT `cat /var/run/slattach.modem.pid` とタイプしてください. そして kermit に戻り (もしkermitをサスペンドしていたなら fg), kermitから抜けてください (q). slattachのマニュアルページにはインタフェースを落すために ifconfig sl0 downをしなければいけないと書いていますが, 私には差がないように見えます. (ifconfig sl0とやっても同じ結果が得られる.) 時にはモデムがキャリアを落すのを 拒絶するかもしれません(私のは よくそうなります). その時は単にkermitをスタートしてまた終了 してください. 普通は2回目で落ちます. トラブルシューティング もし動かなければ自由に私に質問してください. 今までいろんな人がつまずいた のは次のようなことです. slattach で や を使わなかった(私はなぜこれが致命的になり得るのか わかりませんが, このフラグを付けることで少なくとも一人の 問題は解決しました.) の代わりに を使った(いくつかのフォントでは見分けるのは難しい かもしれません). インタフェースの状態を見るために ifconfig sl0 をやってみてください. 私は, &prompt.root; ifconfig sl0 sl0: flags=10<POINTOPOINT> inet 136.152.64.181 --> 136.152.64.1 netmask ffffff00 となります. また, pingが no route to host というメッセージを返す時には netstat -rでルーティングテーブルを確認しましょう. 私のは, &prompt.root; netstat -r Routing tables Destination Gateway Flags Refs Use IfaceMTU Rtt Netmasks: (root node) (root node) Route Tree for Protocol Family inet: (root node) => default inr-3.Berkeley.EDU UG 8 224515 sl0 - - localhost.Berkel localhost.Berkeley UH 5 42127 lo0 - 0.438 inr-3.Berkeley.E silvia.HIP.Berkele UH 1 0 sl0 - - silvia.HIP.Berke localhost.Berkeley UGH 34 47641234 lo0 - 0.438 (root node) となります. (これはたくさんのファイルを転送した後でのもので, あなたの見る数字はもっと小さいかも しれません). SLIPサーバのセットアップ方法 訳: &a.jp.ts;. 1996 年 9 月 6 日. この文書の目的は, SLIPサーバ機能を FreeBSDシステムのもとで設定するため の助言を提供することです. SLIPサーバ機能を設定するということは, リモー トの SLIPクライアントがログインできるようにするために, 自動的に接続処 理をおこなうようにすることです. この文書は著者の経験に基づいておりますが, 実際のシステム構成や要望は異なりますから, すべての疑問にこの文書が答え ることはできません. なお, ここでの助言を試みた結果, あなたのシステムへ の悪影響やデータの損失が生じたとしても, 著者が責任を持つことはできませ んのでご了解をお願いします. 前提 この文書の内容はテクニカルなものなので, 前提知識が必要です. すなわち, TCP/IPネットワークプロトコルについての知識, 特に, ネットワークとノード のアドレス指定をはじめ, ネットワークアドレスマスク, サブネット化, ルー ティング, および RIPなどのルーティングプロトコルなどに関する知識を前提 としています. ダイヤルアップサーバで SLIP機能を設定するためには, これ らの概念についての知識が必要ですから, もし不案内であると思われる方は, O'Reilly & Associates, Inc.から出版されている Craig Hunt氏の TCP/IP Network Administration (ISBN 0-937175-82-X)か, または Douglas Comer氏の TCP/IPプロトコルに関する一連の書籍をお読みください. 前提知識に加え, さらに, モデムの設定が完了しており, そのモデムを経由し てログインできるように, システムファイル群が適切に記述できているものと 仮定しています. もしモデムの準備ができていないときには, あらかじめダイヤ ルアップ機能の設定についてのチュートリアルをお読みください. Webブラ ウザが使えるのであれば http://www.FreeBSD.org/ におけるチュー トリアルの一覧を調べてください. あるいは, この文書を見つけた場所を調べ て, dialup.txt やそれに類似した名前の文書をお読みください. 関連す るマニュアルページとしては, シリアルポート向けデバイスドライバについて の &man.sio.4; をはじめ, モデムからのログインを 受理できるようにシステ ムを設定するための &man.ttys.5;, &man.gettytab.5;, &man.getty.8;, &man.init.8; など, さらには, シリアルポート関連パラメータ ( たと えば直接接続シリアルインタフェースの clocal ) についての &man.stty.1; なども助けになるかもしれません. 概要 一般的な設定内容で FreeBSDを SLIPサーバとして利用すると, その動作は次 のようになります. まず, SLIPユーザが FreeBSD による SLIPサーバへ電話し て, SLIP専用IDでログインします. なお, このIDを持ったユーザはシェルとし て /usr/sbin/sliplogin を使います. この sliplogin は, ファイル /etc/sliphome/slip.hosts の中から, ログインIDと一致する 記述行を探します. もし一致する行があれば, ログインしたシリアル回線を, 利用可能な SLIPインタフェースへ接続し, その後にシェルスクリプト /etc/sliphome/slip.login で SLIPインタフェースを設定します. SLIPサーバへのログイン例 仮に SLIPユーザIDが Shelmerg とします. すると, /etc/master.passwd における Shelmerg のエントリは次のよ うなものになります (実際には一つの行に続いている) . Shelmerg:password:1964:89::0:0:Guy Helmer - SLIP:/usr/users/Shelmerg:/usr/sbin/sliplogin Shelmerg がログインすると, sliplogin は, ファイル /etc/sliphome/slip.hosts からユーザIDと一致する行を探しま す. いま仮に, /etc/sliphome/slip.hosts に次のような記述がなされていたとします. Shelmerg dc-slip sl-helmer 0xfffffc00 autocomp sliplogin が上記のエントリを見つけると, Shelmerg が使用して いるシリアル回線を, 利用可能な SLIPインタフェースのなかの最初のものへ 接続し, 次の内容の /etc/sliphome/slip.login を実行します. /etc/sliphome/slip.login 0 19200 Shelmerg dc-slip sl-helmer 0xfffffc00 autocomp もし上記の手順が正常に処理されると, /etc/sliphome/slip.login は, sliplogin が割り当てた SLIPインタフェース (この例では slip.login で与えられたパラメータのうちで最初の値である SLIP インタフェース0である) に対して ifconfig を実行し, ローカル IPアドレス (dc-slip)をはじめ, リモート IPアドレス (sl-helmer), SLIPインタフェースへのネットワークマスク (0xfffffc00), およびその他のフラグ (autocomp)を設定 します. 逆に, さきほどの手順が正常に終了しなかった場合, 通常は sliplogin は十分な情報を syslog の daemon 機能経由で /var/log/messages へ記録します ( &man.syslogd.8; や &man.syslog.conf.5; のマニュアルページを参照のうえ, さらに /etc/syslog.conf を調べて syslogd がどのファイルへ記 録するかを確認のこと) . 例はこのくらいにして, さっそくシステムのセットアップを始めてみましょう. カーネルのコンフィグレーション FreeBSD のデフォルトのカーネルには, 通常, 二つの SLIPインタフェースが 準備されています (sl0 と sl1) . これらのインタフェー スが使用中のカーネルに準備されているかどうかを調べるには, netstat -i を実行してください. netstat -i の出力例 Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll ed0 1500 <Link>0.0.c0.2c.5f.4a 291311 0 174209 0 133 ed0 1500 138.247.224 ivory 291311 0 174209 0 133 lo0 65535 <Link> 79 0 79 0 0 lo0 65535 loop localhost 79 0 79 0 0 sl0* 296 <Link> 0 0 0 0 0 sl1* 296 <Link> 0 0 0 0 0 netstat -i の出力に sl0 と sl1 のインタフェー スが含まれているということから, カーネルには二つの SLIPインタフェー スが組み込まれているということを示しています. (sl0 と sl1 に付いたアスタリスクは, netstat -i の実行時点で はインタフェースが ダウン していることを表しています. ) なお, パケットのフォワード機能は FreeBSD のデフォルトのカーネルでは設定 されていません (すなわちルータとしては動作しない) . もしインターネット 接続ホストについての RFC要件 ( RFC 1009 [Requirements for Internet Gateways] と 1122 [Requirements for Internet Hosts — Communication Layers], おそらく 1127 [A Perspective on the Host Requirements RFCs] も ) に準拠して, FreeBSDによる SLIPサー バをルータとして動作させたいときには, /etc/rc.conf (バージョ ン 2.2.2 より前の FreeBSD では /etc/sysconfig) ファイル の gateway_enable 変数を としてください. もし古いシステ ムで /etc/sysconfig ファイルすらないときには, 次のコマン ドを /etc/rc.local へ追加してください. sysctl -w net.inet.ip.forwarding = 1 この新しい設定を有効とするには, リブートする必要があります. デフォルトのカーネルコンフィグレーションファイル (/sys/i386/conf/GENERIC) の最後の部分に, 次のような行がありま す. pseudo-device sl 2 この行によって, 使用可能な SLIPデバイスの総数が決まります. すなわち, 行 末の数値が, 同時に動作可能な SLIP接続の最大数となります. カーネルの再構築については, FreeBSDカー ネルのコンフィグレーション を参照ください. Sliploginのコンフィグレーション すでにご説明したように, /usr/sbin/sliplogin のコンフィグレー ションのために, 3種類のファイルが/etc/sliphome ディレクトリに あります (sliplogin についての実際のマニュアルページとしては &man.sliplogin.8; を参照のこと) . ファイル slip.hosts は SLIPユーザおよびその IPアドレスを決めます. 通常, ファイル slip.login は, SLIPインタフェースを設定することだけに使 用します. slip.logout はオプションのファイルで, slip.login で設定した内容を, シリアル接続が終了した時点で解除 するときに使用します. <filename>slip.hosts</filename> のコンフィグレーション /etc/sliphome/slip.hosts には, 少なくとも 4 つの項目をホワイ トスペース (スペースやタブ) で区切って指定します. SLIPユーザのログインID SLIPリンクのローカル (SLIPサーバ側) アドレス SLIPリンクのリモートアドレス ネットワークマスク ホスト名をローカルおよびリモートのアドレスとして 記述できます (IPアドレ スの決定は, /etc/host.conf の指定内容に応じて, /etc/hosts か DNSのいずれかによって決定される) . また, ネット ワークマスクも /etc/networks ファイルに記述された名前を参照す ることで, 指定することもできると思います. これまでの例としてあげたシス テムでの /etc/sliphome/slip.hosts は次のようになります. # # login local-addr remote-addr mask opt1 opt2 # (normal,compress,noicmp) # Shelmerg dc-slip sl-helmerg 0xfffffc00 autocomp それぞれの行の最後には, 次に示すオプションを一つ以上指定できます. — ヘッダを圧縮しない — ヘッダを圧縮する — リモートの設定に応じて, ヘッダを圧縮する — ICMPパケットを禁止する ( ping パケットは送出されず, バンド幅を占有しない) なお, FreeBSDバージョン2の初期リリースの sliplogin は, 旧 FreeBSD 1.xでは有効であった上記のオプションを無視していましたので, , , , そして などのオプションは FreeBSD 2.2でサポートされるまでは効果がありませんでした (た だしこれらのフラグを使うためには slip.login スクリプトへ記述する 必要がある) . SLIPリンクでのローカルとリモート向けのアドレスの 選び方は, TCP/IPサブネッ トを専用に割り当てるか, または プロキシ ARP を SLIPサーバへ用いるかによって違います ( プロキシ ARP という用語のここでの使い方は本来のものではないが, 説明のためにこの用語を使う) . もし, どちらの方式を選ぶべきか判らなかったり, IPアドレスの割り当て方が不明のときには, 上述の 前提 の節で紹介した TCP/IP関連書籍を参考になさるか, またはあなたの IPネットワークを管理している方に相談なさると よいでしょう. 独立したサブネットを SLIPクライアントへ適用するときには, すでに割り当てられている IPネットワーク番号の範囲からサブネット番号を割り当て, 同 時にそのサブネットの範囲内で有効な IPアドレスを SLIPクライアントの IP 番号として割り当てる必要があります. さらに, この SLIPサブネットから SLIPサーバを経由して最も近い IPルータへの経路を静的に設定するか, または gated を FreeBSDによる SLIPサーバへインストールして, 適当 なルーティングプロトコルを使って, SLIPサーバ経由のサブネットへの経路情 報をルータ群へ通知できるように設定するか, のいずれかをおこなう必要があります. プロキシ ARP 方式を採用するときには, SLIPクライアント向けの IPアドレス として, SLIPサーバのサブネットの範囲から 選んで割り当てるとともに, &man.arp.8; コマンドを使うために /etc/sliphome/slip.login と/etc/sliphome/slip.logout のスクリプトを修正して, SLIPサー バにおける ARPテーブル内のプロキシ ARPエントリへ 反映させる必要がありま す. <filename>slip.login</filename> のコンフィグレーション ファイル /etc/sliphome/slip.login の一般的な内容は次にようになります. #!/bin/sh - # # @(#)slip.login 5.1 (Berkeley) 7/1/90 # # generic login file for a slip line. sliplogin invokes this with # the parameters: # 1 2 3 4 5 6 7-n # slipunit ttyspeed loginname local-addr remote-addr mask opt-args # /sbin/ifconfig sl$1 inet $4 $5 netmask $6 この slip.login ファイルの役目は単に, SLIPインタフェースにつ いてのローカルとリモートのアドレス, およびそのネットワークマスクを ifconfig コマンドで設定することです. もし プロキシ ARP 方式を採用する (SLIPクライアントへ独立したサブネットを使わない) ときには, ファイル /etc/sliphome/slip.login は次のような内容になります. #!/bin/sh - # # @(#)slip.login 5.1 (Berkeley) 7/1/90 # # generic login file for a slip line. sliplogin invokes this with # the parameters: # 1 2 3 4 5 6 7-n # slipunit ttyspeed loginname local-addr remote-addr mask opt-args # /sbin/ifconfig sl$1 inet $4 $5 netmask $6 # Answer ARP requests for the SLIP client with our Ethernet addr /usr/sbin/arp -s $5 00:11:22:33:44:55 pub この slip.login で追加された行 arp -s $5 00:11:22:33:44:55 pub は, SLIPサーバにおける ARPテーブルへ新たなエントリを作ります. SLIPサーバ は, この ARPエントリが作られると, SLIPクライアントの IPアドレスと話し たい他の IPノードが要求してきたときにはいつも, SLIPサーバ の Ethernet MACアドレスを返すようになります. 上記の例を実際に流用なさるときには, 例にある Ethernet MACアドレス (00:11:22:33:44:55) を, あなたのシステムの実際のEthernetカー ドの MACアドレスと置き換えなければ プロキシ ARP はうまく動作しません! SLIPサーバの Ethernet MACアドレスを調べるには netstat -i コマ ンドを利用してください. 実行結果の第2行は次のようなものになるはずです. ed0 1500 <Link>0.2.c1.28.5f.4a 191923 0 129457 0 116 この例での Ethernet MACアドレスは 00:02:c1:28:5f:4a であると 読みます. なお &man.arp.8; における MAC アドレスの指定に際しては, コマンド netstat -i が付けた Ethernet MACアドレスのピリオド記 号をコロン記号と置き換え, かつ単一桁の 16 進数にはゼロを先頭に加える必 要があります. この指定についての正確な情報は &man.arp.8; を参照く ださい. /etc/sliphome/slip.login と /etc/sliphome/slip.logout を作成したならば, ファイル属性の 実行 ビット (すなわち chmod 755 /etc/sliphome/slip.login /etc/sliphome/slip.logout) を 設定しなければなりません. さもなければ sliplogin が うまく実行されません. <filename>slip.logout</filename> のコンフィグレーション ファイル /etc/sliphome/slip.logout は必ずしも必要なものではあ りません (ただし プロキシ ARP を利用する場合を除く) . もしこのファイルを 作成するときには, 次に示す標準的な slip.logout スクリプト例を 参考にしてください. #!/bin/sh - # # slip.logout # # logout file for a slip line. sliplogin invokes this with # the parameters: # 1 2 3 4 5 6 7-n # slipunit ttyspeed loginname local-addr remote-addr mask opt-args # /sbin/ifconfig sl$1 down プロキシ ARP を利用する場合, この /etc/sliphome/slip.logout を 使って, 特定の SLIPクライアント向けの ARPエントリを削除したくなるようなときがあります. #!/bin/sh - # # @(#)slip.logout # # logout file for a slip line. sliplogin invokes this with # the parameters: # 1 2 3 4 5 6 7-n # slipunit ttyspeed loginname local-addr remote-addr mask opt-args # /sbin/ifconfig sl$1 down # Quit answering ARP requests for the SLIP client /usr/sbin/arp -d $5 コマンド arp -d $5 は, SLIPクライアントがログインした 際に, プロキシ ARP を使った slip.login によって追加され た ARPエントリを削除します. これによって, 繰り返して利用することができるわけです. 必ず, /etc/sliphome/slip.logout を作成した後に, 実行ビットを設定し てください ( chmod 755 /etc/sliphome/slip.logout ) . ルーティングについての考慮点 プロキシ ARP 方式を利用せずに SLIPクライアントとその他のネットワーク (Internetも含む) の構成要素との間でパケットをルーティングするときには, SLIPサーバ経由で SLIPクライアントが属するサブネットまでの経路を, 最も 近いデフォルトのルータ群へ静的な経路情報として 追加しなければならないか, または gated を FreeBSDによる SLIPサーバへインストールして, SLIP サブネットについての経路情報を, 適当なルーティングプロトコルでルー タ群へ通知できるように設定するか, のどちらかをおこなわなければなりません. 静的な経路 静的な経路を最も近いデフォルトの ルータ群へ追加することが困難なことがあ ります (経路情報を追加できる権限がなければそもそも不可能となる). もし あなたの組織に複数のルータで構成された ネットワークがあるならば, ある種 のルータ (たとえば Ciscoや Proteonなど) は, 静的な経路を SLIPサブネッ トへ使うようにルータを設定しなければならないだけでなく, その静的経路を 他のどのルータへ知らせるのかもあらかじめ 指定しておく必要がありますから, 静的経路に基づくルーティングを軌道に乗せるには それなりの専門的技術やト ラブルシューティングやコツが必要だと思います. <command>gated</command>の稼働 静的経路についての頭痛への代替手段は, gated を FreeBSDによる SLIPサー バへインストールして, 適切なルーティングプロトコル (RIP/OSPF/BGP/EGP) を使って SLIPサブネットについての経路情報を他のルータへ知らせるように 設定することです. ports コレクションから gated を用いることもできますし, the GateD 匿名 FTP サイト から探して自分自身で構築することもで きます. この文章を執筆時点の最新バージョンは gated-R3_5Alpha_8.tar.Z であり, このファイル だけで FreeBSDで 動作させることができます. gated についてのすべての情報と文書 は Merit GateD コンソーシアム からはじまる Web 上で入手でき ます. gated のコンパイルとインストールを行ったならば, 独自の 設定のために /etc/gated.conf ファイルを記述してください. 次の 例は, 筆者が FreeBSDによる SLIP サーバで使っている内容と類似のものです. # # gated configuration file for dc.dsu.edu; for gated version 3.5alpha5 # Only broadcast RIP information for xxx.xxx.yy out the ed Ethernet interface # # # tracing options # traceoptions "/var/tmp/gated.output" replace size 100k files 2 general ; rip yes { interface sl noripout noripin ; interface ed ripin ripout version 1 ; traceoptions route ; } ; # # Turn on a bunch of tracing info for the interface to the kernel: kernel { traceoptions remnants request routes info interface ; } ; # # Propagate the route to xxx.xxx.yy out the Ethernet interface via RIP # export proto rip interface ed { proto direct { xxx.xxx.yy mask 255.255.252.0 metric 1; # SLIP connections } ; } ; # # Accept routes from RIP via ed Ethernet interfaces import proto rip interface ed { all ; } ; この gated.conf ファイルの例では, SLIPのサブネット xxx.xxx.yy についての経路情報を RIPを使って Ethernetへブロー ドキャストしています. もし ed ドライバ以外の Ethernetドライバを使うのであれば, ed インタフェースの記述を適切なものに置き換えてくだ さい. またこの例では, gatedの動作をデバッグするために, /var/tmp/gated.output へトレース情報を出力するように指示して います. gated が希望通りに動作したならば, このトレースオプショ ンを止めることができます. なお, 例における xxx.xxx.yy を, あ なた自身の SLIPサブネットのネットワークアドレスに換えてください (また proto direct 部分のネットワークマスクも換えることを忘れないこ と) . gated のコンパイルとインストールが終了し, コンフィグレーショ ンファイルの作成も完了したら, FreeBSDシステムではデフォルトの routedに代わって gated を起動してください. そのため には, /etc/netstart の routed/gated 起動パラメータを 適切な値に設定してください. gated のコマンドラインパラメータにつ いての情報は, gated のマニュアルページを参照してください. diff --git a/ja_JP.eucJP/books/handbook/security/chapter.sgml b/ja_JP.eucJP/books/handbook/security/chapter.sgml index 29a8e9ead5..389c03c5d5 100644 --- a/ja_JP.eucJP/books/handbook/security/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/security/chapter.sgml @@ -1,3204 +1,3204 @@ セキュリティ この章の多くの部分は&a.dillon;によって書かれた &man.security.7; マニュアルページからの引用です. 訳: &a.jp.hino;, (jpman プロジェクトの成果を利用させ ていただきました). この章では この章では, 基本的なシステムセキュリティの考え方, 覚えておくべき一般的なルールを紹介し, そして S/Key, OpenSSL, Kerberos などの高度な話題について簡単に説明します. はじめに セキュリティとは, システム管理者をいつも悩ませる仕事の一つです. すべての BSD UNIX マルチユーザシステムは, 従来からいくつかのセキュリティ機構を備えていますが, ユーザを疑心暗鬼に陥らせないように追加のセキュリティ機構を構築し 保守する仕事はおそらく, システム管理者としてもっとも大きな責務の一つでしょう. マシンの安全性に反映されるのは, 管理者が作業したことだけです. またセキュリティ問題は, 快適な環境に必要なものと競合します. 一般に UNIX システムは膨大な数のプロセスを同時に動作させることができ, そのプロセスの大部分は, サーバ – 外部から接続し, 通信するものとして動作します. かつてのミニコンとメインフレームがデスクトップにとってかわり, さらにコンピュータが相互に接続されたネットワークを形成するようになった今日, セキュリティは非常に大きな関心事になってきています. セキュリティを実装するには, タマネギのように階層化する手法 (a layered onion approach) が最適です. どうすれば良いのか簡単に説明すると, 便利な機能と同じ数だけセキュリティの階層を作り, システムへの侵入を注意深く監視するのです. あなたはセキュリティを過度に厳重にしたり, 侵入の監視に時間をとられたいとは思わないでしょう. この侵入の発見という部分は, あらゆるセキュリティ機構において最も重要な部分の一つなのです. たとえば, システムの各バイナリに schg フラグ を設定するのは, 大して意味がありません. フラグを設定すると一時的にバイナリが保護され, 侵入してきたクラッカーによってシステムに加えられる変更のうち, 容易に検出可能な変更は行なえなくなります. しかしその結果として, セキュリティ機構がその侵入者を検出することも まったくできなくなってしまうでしょう. また, システムセキュリティには, さまざまな形での攻撃に対処することとも関係しています. この攻撃には root 権限を奪おうとするものだけでなく, クラッシュやシステムの不安定状態を引き起こそうとするものを含まれます. このセキュリティ問題は, いくつかに分類することが可能です. サービス妨害攻撃 (denial of service attack) ユーザアカウントの不正利用 (user account compromise) アクセス可能なサーバを使った root 権限の不正利用 ユーザアカウントを経由した root 権限の不正使用 バックドアの設置 サービス妨害攻撃 (DoS 攻撃) とは, マシンから必要な資源を奪う行為です. 通常, サービス妨害攻撃はそのマシンで実行されるサーバや ネットワークスタックを過負荷状態にしてマシンをクラッシュさせたり, マシンを使えなくしたりするような力任せの方法です. サービス妨害攻撃の中には, ネットワークスタックのバグを利用して, パケット一つでマシンをクラッシュさせようとするものもあります. 後者には, カーネルにバグ修正を施すことによってのみ対応することができます. サーバプロセスに対する攻撃は, オプションを適切に指定することによって, 攻撃されている状況でサーバプロセスの負荷上昇に限界を設定することで 対応できる場合が多いです. これらに比べると, ネットワークへの力任せの攻撃への対応はずっと難しくなります. たとえば, 偽造パケットによる攻撃 (spoof-packet attack) は, インターネットからシステムを切り離す以外の方法で 防ぐことはほとんど不可能です. この攻撃によって, マシンを落としてしまうことはできないかもしれませんが, 接続しているインターネット回線を混雑させていっぱいにしてしまうことはできます. ユーザアカウントの不正利用は, サービス妨害攻撃 よりもずっとよくある問題です. このご時勢でも, 自分たちのマシンで 標準の telnetd, rlogind, rshd, ftpd サーバを実行させているシステ ム管理者は多いのです. これらのサーバは, デフォルトでは, 暗号化さ れたコネクション上で動作していません. その結果, 抱えているユーザ 数が標準くらいであれば, リモートログイン (そのシステムにログイン するには最も普通で便利な方法です) しているユーザのうち一人以上は, パスワードを覗き見られてしまうでしょう. システム管理者が注意深い 人ならば, たとえログインが成功していたとしても, リモートアクセス ログを解析して, 疑わしい送信元アドレスを探すものです. ひとたび攻撃者がユーザアカウントへのアクセス権を入手すると, 攻撃者が root の権限を破る可能性があることを仮定するべきです. し かし, セキュリティを十分維持し, 手入れの行き届いたシステムにおい ては, あるユーザアカウントへのアクセスが可能となっても, 攻撃者に 必ずしも root へのアクセス権を与えるとは限りません. こ の違いは重要です. というのは, 一般的に root へのアクセス権がなければ, 攻撃者は自分の侵入の痕跡を隠蔽することができませんし, そ のユーザのファイルを引っかき回したり, マシンをクラッシュさせたり できるのがせいぜいです. ユーザアカウントの不正利用は めずらしいことではありません. それは一般ユーザに, システム管 理者ほど注意を払わない傾向があるからです. システム管理者は「あるマシン上で root の権限を破る方法は, 潜 在的に何通りもあるのだ」ということを心しておかねばなりません. 攻撃 者が root のパスワードを知ってしまうかもしれませんし, 攻撃者が root の権限で実行されるサーバのバグを見つけ, ネットワークからそ のサーバへ接続して root の権限を破ることができるかもしれません. ひとたびユーザアカウントを破ると, ユーザアカウントから root の権 限を破ることを可能にするような suid-root プログラムに存在するバグを 攻撃者は知っているかもしれません. あるマシン上で攻撃者 が root の権限を破る方法を知ったとすると, 攻撃者は, 裏口を作る必 要はありません. これまでに発見され, ふさがれた root の 穴の多くには, クラッカーが侵入した跡を消そうとしてたくさん仕事し た結果が含まれています. そのためにこそ, 多くのクラッカーは裏口を 作るのです. 攻撃者は裏口を使ってシステムへの root アクセスを再び 簡単に得ることができます. しかしこの裏口は, クラッカーの検出をす るのに便利なものでもあります. クラッカーに裏口を作らせないように するということは, セキュリティにとっては実際には良くないことかも しれません. なぜなら, そうすることで, クラッカーが最初に侵入して くるために発見したセキュリティホールがふさがるわけではないからで す. セキュリティを改善する方法は, 常に, タマネギの皮 のように階層化する手法 (a multi-layered onion peel approach) で実装されるべきです. これら は次のように分類できます. root とスタッフのアカウントの安全性を高める. root の安全性を高める – root 権限で動作するサーバ と suid/sgid バイナリ. ユーザアカウントの安全性を高める. パスワードファイルの安全性を高める. カーネルのコア, raw デバイス, ファイルシステムの安全性を 高める. システムに対して行なわれた, 不適切な変更をすばやく検出す る. 必要と思われる以上の対応をとる (paranoia). 本章の次の節では, 上記の各項目についてより深く掘り下げていき ます. FreeBSDの安全性を高める 以下の節では, 本章の前節 でとりあげた FreeBSD システムの安全性を高める方法について 述べます. root アカウントとスタッフアカウントの安全性を高める root のアカウントの安全性を確保しないうちからスタッフのア カウントの安全性をうんぬんしてもしかたがありません. ほとんどの システムでは, root アカウントに割り当てたパスワードが 1 つあり ます. まず最初にすべきことは, このパスワードはいつで も不正利用の危険に晒されていると仮定することです. これは root のパスワードを消すべきだと言っているのではありません. root のパスワードは, マシンにコンソールからアクセスするのには, ほとんどいつでも必要なものです. ここで言いたいのは, コンソール 以外からは, そして可能なら &man.su.1; コマンドを実行する場合も root のパスワードを使えないようにするべきである, ということで す. たとえば, あなたが使っている pty が, /etc/ttys ファイルで unsecure と指定 されているか確認してください. そうすると, telnet や rlogin 経由では root で直接ログインできないようになります. sshd のような, 別のログインサービス を使っている場合でも同様に, 直接 root へログインすることを許し ていないかどうか確認してください. すべてのアクセス手段 – たとえば ftp のようなサービスが, 良くクラックの対象となることを 考えましょう. root への直接ログインは, シス テムコンソール経由でのみ可能であるべきなのです. また当然, システム管理者として自分が root になれるようにしておく必要が ありますから, そのための穴をいくつか開けておきます. し かし, それらの穴を動作させるには, さらに追加のパスワード認証が 必要であるようにしておくことが重要です. root でアクセス可能と する方法の一つとして, 適切なスタッフアカウントを (/etc/group 中の) wheel グループに加えることがありま す. wheel グループに入っているスタッフメン バは su を使って root になることが許されま す. パスワードエントリにおいて, スタッフメンバを wheel グループに置くことによって直接 wheel 権限を与えてはいけません. スタッフメンバのアカウントは staff グループに所属させるべきで, そして /etc/group ファイルを通して wheel グループに加えるべきです. 実際に root アクセスの必要なスタッフメンバのみ wheel グ ループに置くようにすべきです. 他の認証方法の場合, たとえば kerberos を使用する場合には, root アカウントの .k5login ファイルを使って, 誰も wheel グループに置く必要なく &man.ksu.1; を 使って root になることを許すようにすることもできます. このやり 方はよりよい解決策なのかもしれません. なぜなら, wheel のメカニズムでは, 侵入者がパスワード ファイルを手に入れ, スタッフアカウントのいずれか 1 つを破るこ とができると, root を破ることがまだできてしまうからです. wheel のメカニズムを用いる方が, 何もしない よりは良いのですが, 必ずしも最も安全な選択肢とは限りません. root アカウントの安全性を高める間接的な方法として, 別のロ グインアクセスの方法を用いてスタッフのアカウントの安全性を高め, その上でそのスタッフのアカウントの暗号化パスワードを * にしておく方法があります. この方法だと, 侵入者がパスワードファイルを盗むことができた場合でも, スタッフ アカウントを破ることはできなくなります (また, たとえ root が暗 号化パスワードをパスワードファイルに付けていたとしても, 間接的 に root アカウントを破ることはできません). スタッフメン バがスタッフアカウントでログインする際には, &man.kerberos.1; や &man.ssh.1; のような, 公開鍵 / 秘密鍵の鍵の組を使う安全性の 高いログイン機構を使います. kerberos のようなログイン機構を使う 場合は一般に, kerberos サーバを実行するマシンと自分のデスクトッ プワークステーションとの安全性を確保しなければなりません. また ssh で公開鍵 / 秘密鍵の組を使う場合, 一般に, ログイン元マシン (通常は自分のワー クステーション) の安全性を確保しなければなりません. ここで, - <&man.ssh-keygen.1; で公開鍵 / 秘密鍵の組を生成する際, 鍵の組 + &man.ssh-keygen.1; で公開鍵 / 秘密鍵の組を生成する際, 鍵の組 をパスワードで防御することにより, 鍵の組への防御層を追加するこ ともできます. スタッフアカウントのパスワードを * でつぶすことができると, 管理者自身が設定 した安全性の高い方法でしかスタッフメンバがログインできないこと も保証できます. こうして, 多くの侵入者が使う重大なセキュリティ の穴, すなわち, 安全性の低い無関係なマシンからネットワークを覗 き見る方法, を塞ぐようなセッションを提供する, 安全性の高い暗号 化されたコネクションを使うことを, スタッフメンバ全員に強制する ことができるのです. より間接的なセキュリティの仕組みでは, 制限の強いサーバから 制限の弱いサーバへログインすることを前提としています. たとえば, メインマシンで, 様々な種類のサーバを実行させている場合, ワーク ステーションではそれらのサーバを実行させてはなりません. ワーク ステーションを十分に安全にしておくためには, 実行するサーバの数 を, 一つもサーバが実行されていないというくらいにまでできる限り 減らすべきです. また, パスワードで保護されたスクリーンセーバを 走らせておくべきです. ワークステーションへの物理的アクセスが与 えられたとすると, もちろん言うまでもなく, 攻撃者は管理者が設定 したいかなる種類のセキュリティをもうち破ることができるのです. このことは, 管理者として必ず考えておかねばならない問題ですが, システム破りの大多数は, ネットワーク経由でリモートから, ワーク ステーションやサーバへの物理的アクセス手段を持たない人々によっ て行われるという事実もまた, 念頭に置いておく必要があります. kerberos のような方法を使うことで, スタッフアカウントのパ スワードの変更もしくは停止を一箇所で行なうことと, スタッフメン バがアカウントを持つすべてのマシンに即時にその効果を及ぼすこと が可能となります. スタッフメンバのアカウントが危険に晒されたと きに, すべてのマシンでスタッフメンバのパスワードを即座に変更す る能力を過小評価してはいけません. パスワードが分散されている状 況では, N 台のマシンでパスワードを変更すると, てんやわんやの事 態を招く可能性があります. kerberos を使用すると, パスワードの 再発行に制限 (re-passwording restriction) を課することもできま す. この機能を使うことにより, ある kerberos チケットをしばらく 経つとタイムアウトにすることができるだけでなく, 一定期間 ( 例 えば, 1 ヶ月に 1 回) 経つと, ユーザに新しいパスワードを選ぶよ うに要求することもできます. root 権限で実行されているサーバと SUID/SGID バイナリの安全性を高める 用心深いシステム管理者は, 自分に必要なサーバプロセスだけを 過不足なく実行させるものです. サードパーティ製のサーバは, よくバグを持っ ていがちだということに注意して下さい. たとえば, 古いバージョンの imapd や popper を実行させておくのは, 全世界に万能の root の切 符を与えているようなものです. 自分で注意深くチェックしていない サーバは, 決して実行してはいけません. root で実行させる必要の あるサーバはほとんどありません. たとえば, ntalk, comsat, finger デーモンを, 専用ユーザの 砂場 (sandbox) で実行させることができます. 管理者が膨大な数の問題に直面していないのなら, この「砂場」は完 璧ではありませんが, セキュリティに関するタマネギ的アプローチは ここでも成り立ちます. 砂場で実行されているサーバプロセスを経由 して侵入を果たすことができたとしても, 攻撃者はさらに砂場から外 に脱出しなければなりません. 攻撃者が通過せねばならない層の数が 増えれば増えるほど, それだけ攻撃者が侵入に成功する確率が減りま す. root の抜け穴は歴史的に, 基本システムサーバも含め, root 権 限で実行されるほとんどすべてのサーバプロセスで発見されています. ユーザが sshd 経由でのみログインし, telnetd, rshd, rlogind 経由でログインすることが決 してないマシンを稼働させているのであれば, それらのサービスを停 止させて下さい! FreeBSD では, 今では ntalkd, comsat, finger は砂場で実行させることがデフォ ルトになっています. 次に砂場で実行させるべきプログラムの候補と して, &man.named.8; があります. /etc/defaults/rc.conf ファイルには, named を砂場で実行するために必要な 引数がコメントアウトされた形式で含まれています. 新しいシステム をインストールしているか, それとも既存のシステムをアップグレー ドして使っているかに依存しますが, 砂場として使用する特別のユー ザアカウントがインストールされていないかもしれません. 用心深い システム管理者であれば, できるだけいつでも研究を怠らず, サーバ に砂場を仕込むものでしょう. 通常, 砂場で実行しないサーバが他にいくつかあります. sendmail, popper, imapd, ftpd などです. これらのうちいくつか のサーバには代わりとなるものがありますが, 代わりのものをインス トールするには, あなたが思うより多くの仕事が必要になるかもしれ ません (便利さという要素がまたも勝利を収めるわけです). これら - のサーバは, root 権限で実行せねばならいかもしれません. また, + のサーバは, root 権限で実行せねばならないかもしれません. また, これらのサーバ経由で生じる侵入を検出するためには, 他の仕組みに 頼らなくてはならないかもしれません. システムの root 権限の潜在的な穴で他に大きなものとして, シ ステムにインストールされた suid-root/sgid バイナリがあります. これらのバイナリは, rlogin のように, /bin, /sbin, /usr/bin, /usr/sbin に存在するものがほとんどです. 100% 安全なものは存在しないとは いえ, システムデフォルトの siud/sgid バイナリは比較的安全とい えます. それでもなお, root の穴がこれらのバイナリにときおり発 見されています. 1998 年に Xlib で見つかった root の穴は, xterm (普通, suid 設定 されています)を脆弱にしてしまいました. 安全である方がよいので, 用心深いシステム管理者は残念に思いながらも, スタッフのみが実行 する必要がある suid バイナリは, スタッフのみがアクセス可能な特 別なグループに含めるように制限を加え, 誰も使わない suid バイナ リは (chmod 000 を実行して) 片付けてしまう でしょう. ディスプレイを持たないサーバは, 一般的に xterm のバイナリを必要としません. sgid バイナリもほとんど同様の危険な存在になり得ます. 侵入者が kmem に sgid されたバイナリを破ることができた場合, その侵入者 は /dev/kmem を読み出すことができるように なるでしょう. つまり, 暗号化されたパスワードファイルを読み出す ことができるようになるので, パスワードを持つどのアカウントをも, 潜在的な危険に晒すことになります. 他にも, kmem グループを破った侵入者が pty を通して 送られたキーストロークを監視できるという危険があります. キース トロークには, 安全な方法でログインするユーザが使っている pty も含まれます. tty グループを破った侵入者は, ほぼ任意のユーザの tty へ書き込みができます. ユーザが端末プログラムやキーボードを シミュレーションする機能を持ったエミュレータを使っている場合, 侵入者は潜在的に, 結局そのユーザとして実行されるコマンドをユー ザの端末にエコーさせるデータストリームを生成できる可能性があり ます. ユーザアカウントの安全性を高める ユーザアカウントは, 普通, 安全性を高めることが最も困難です. スタッフに対しては, とても厳格なアクセス制限を強制しパスワード を * で外すことができるでしょうが, 管理者が 持ちうる一般ユーザすべてのアカウントに対して同じことはできない かもしれません. 管理者が十分に統率をとることができるなら, 管理 者は勝利し, ユーザのアカウントの安全を適切に確保できるかもしれ ません. それができないならば, よりいっそう気を配って一般ユーザ のアカウントを監視するよりほかありません. 一般ユーザアカウント に対し ssh や kerberos を利用するこ とには, システム管理がさらに増えたりテクニカルサポートが必要に なるなどの問題があります. それでも, 暗号化パスワードファイルと 比較するとはるかに良い解です. パスワードファイルの安全性を高める できるだけ多くのパスワードを * で外し, それらのアカウントのアクセスには ssh や kerberos を使うようにするこ とが, 唯一の確実な方法です. 暗号化パスワードファイル (/etc/spwd.db) は root でのみ読み出し可能 だといっても, 侵入者が root の書き込み権限は得られなくとも, 読 み出しアクセス権限を得ることは可能かもしれません. セキュリティスクリプトで常にパスワードファイルの変更をチェッ クし, 報告するようにすべきです (ファイルの完全性のチェック 参照). カーネルのコア, raw デバイス, ファイルシステムの安全性を 高める root の権限を破ると, 攻撃者は何でもできますが, 特に重宝さ れる特定の事柄もいくつかあります. たとえば, 最近のカーネルは, 組 み込みのパケット覗き見デバイス (packet sniffing device) ドライ バを備えているものがほとんどです. FreeBSD では bpf デバイスと呼ばれています. 侵入者 は普通, 侵入済みのマシンでパケット覗き見プログラムを実行させよ うと試みます. 侵入者にわざわざそういう機能を提供する必要はない ので, ほとんどのシステムで bpf デバイスを組み込むべきではあり ません. bpf デバイスを外しても, /dev/mem と /dev/kmem という悩みの種がまだ残っていま す. この問題に関しては, 侵入者は raw ディスクデバイスに書き込 むこともできます. また, モジュールローダ, &man.kldload.8; とい う, 別のカーネル機能があります. やる気まんまんの侵入者は, KLD モジュールを使って自分独自の bpf もしくはその他覗き見デバイス を動作中のカーネルにインストールすることができます. この問題を 避けるため, システム管理者はカーネルをより高い安全レベル ( securelevel) , 少なくとも安全レベル 1 で実行させる必要がありま す. sysctl を使って kern.securelevel 変数に安全レベルを設定する ことができます. ひとたび安全レベルに 1 を設定すると, raw デバ イスに対する書き込みアクセスは拒否され, たとえば schg のような特別な chflags フラグの機能が 強制されます. システム起動に関わる重要なバイナリやディレクトリ, スクリプトファイルなど, 安全レベルが設定されるまでの間に実行さ れるすべてのものに対しても schg フラグを on にしておくことも確実に実行してください. この設定をやり過ぎても 構いませんが, より高い安全レベルで動作している場合, システムの アップグレードがはるかに困難になります. システムをより高い安全 レベルで実行させるようにするが, すべてのシステムファイルとディ レクトリに schg フラグを設定しないという妥 協をする方法もあります. もう一つの可能性としては, 単純に / および /usr を読み 込み専用でマウントすることです. ここで特筆すべきことは, システ ムを守ろうとして厳しくしすぎると, 侵入を検出するという非常に重 要なことができなくなってしまうということです. ファイルの完全性のチェック: バイナリ, 設定ファイルなど ことこの問題に至ると, システム管理者にできることは, 便利さ という要素がその醜い頭を上げない程度に, コアシステムの設定と制 御ファイルを防御することだけです. たとえば, / および /usr にある 大部分のファイルに schg ビットを設定するた めに chflags を使用するのは, おそらく逆効果 でしょう. なぜなら, そうすることでファイルは保護できますが, 侵 入を検出する窓を閉ざしてしまうことにもなるからです. セキュリティ のタマネギの最後の層はおそらく最も重要なもの – 検出で す. セキュリティの残りのものは, 突然の侵入を検出できなければ, まったく有用ではありません (あるいは, もっと悪ければ, 安全性に 対する間違った感覚を植え付けてしまいます). タマネギの仕事の半 分は, もう半分の検出側が攻撃者を攻撃の最中に捕えるようにするた めに, 攻撃者を食い止めるのではなく侵入を遅らせることなのです. 侵入を検出する最も良い方法は, 変更されていたり, 消えていた り, 入れた覚えがないのに入っているファイルを探すことです. 変更 されたファイルを探すのに最も良い方法は, もう一つの (しばしば中 央に集められた), アクセスが制限されたシステムから行なうもので す. さらに安全でアクセス制限されたシステム上でセキュリティ用ス クリプトを書けば, スクリプトは潜在的なクラッカー達からはほぼ見 えなくなります. これは重要なことです. この有効性を最大限に活用 するためには, 一般的に, アクセスの制限されたマシンから実際に使っ ている他のマシンへのかなりのアクセスを許す必要があります. 普 通は, 他のマシンからアクセス制限されたマシンへ読み込み専用の NFS エクスポートをしたり, アクセス制限されたマシンから他のマシ ンへ ssh を行なうために, ssh 鍵のペアを作ったりすることで行 います. ネットワークのトラフィックを別にして, NFS は最も可視性 のない方法です – 各クライアント上のファイルシステムを, 事実上検出されずに監視できるようになります. アクセス制限された サーバがスイッチを通してクライアントに接続されている場合, たい てい NFS がより良い選択肢です. アクセス制限されたサーバがハブ を通したり, いくつかのルーティング層を通したりしてクライアント に接続する場合, NFS はあまりにも危険な方法かもしれず (ネットワー クの面で) , ssh の方が認証の道筋は 跡となって残りますが, それでもより良い方法かもしれません. アクセス制限されたマシンに, 監視しようとするクライアントシ ステムへの少なくとも読み込みのアクセス権を与えたら, 次に実際に 監視するためのスクリプトを書かなくてはいけません. NFS マウント をすれば, &man.find.1; や &man.md5.1; などの単純なシステムユー ティリティでスクリプトを書くことができます. 少なくとも 1 日 1 回, クライアントのファイルを直接 md5 にかけ, さらにもっと頻繁 に /etc および /usr/local/etc にあるようなコントロール用 ファイルを試験するのが一番です. アクセス制限されたマシンが正し いと知っている, 基となる md5 情報と比べて違いが見つかった場合, システム管理者に調べて欲しいと悲鳴を上げるようにすべきです. 優 れたセキュリティ用スクリプトは, / および /usr などのシステムパーティション上で不適 当に suid されたバイナリや, 新たに作成されたファイルや削除され たファイルもチェックするでしょう. NFS ではなく, ssh を使用する場 合は, セキュリティ用スクリプトを書くのはずっと難しいことで す. スクリプトを動かすためには, クライアントに対してスクリプト を scp しなくてはいけませんし, それは目に見 えてしまいます. そして, 安全のためには, スクリプトが使うバイナ リ (find など) を scp する必要もあります. クライアントの ssh デーモンはすでに 攻撃されてしまっているかもしれません. 結局のところ, 安全でない リンク上の場合は ssh は必要かもしれ ませんが, ssh を扱うのはとても大変 なことです. 優れたセキュリティ用スクリプトは, ユーザやスタッフメンバの アクセス設定ファイルの変更もチェックするものです. .rhosts, .shosts, .ssh/authorized_keys など … MD5 チェックの範囲外になってしまうであろう ファイル群です. ユーザ用のディスク容量が非常に大きい場合は, パーティション 上の各ファイルを見て回るのに大変な時間がかかるかもしれません. この場合は, マウントフラグを設定して, このパーティションに suid されたバイナリやデバイスを置けないようにするのが良い考え です.nodev および nosuid オプション (&man.mount.8; 参照) が知るべきものでしょう. とにかく少なくとも週に 1 度はファイルシステムをスキャンするべきです. なぜなら, この層の目的は, 侵入が成功したかどうかに関わらず, 侵 入があったことの検出をすることだからです. プロセスアカウンティング (&man.accton.8; 参照) は, マシンへの侵入を検出するためのメカニズムとして推奨できる, 比較的オーバヘッドの少ないオペレーティングシステムの機能です. 侵入を受けた後でも当該ファイルが無傷である場合に, 侵入者が 実際にどのようにしてシステムに侵入したかを追跡するのに特に役立ちます. 最後に, セキュリティスクリプトはログファイルを処理するよう にし, ログファイル自体もできるだけ安全性の高い方法で生成するよ うにすべきです – リモート syslog は極めて有益になり得ま す. 侵入者は自分の侵入の痕跡を覆い隠そうとしますし, また, ログ ファイルはシステム管理者が最初の侵入の時刻と方法を追跡してゆく ために極めて重要です. ログファイルを永久に残しておくための 1 つの方法は, システムコンソールをシリアルポートにつないで走らせ, コンソールを監視している安全なマシンを通して絶えず情報を集める ことです. 偏執狂的方法 多少偏執狂的になっても決して悪いことにはなりません. 原則的 に, システム管理者は, 便利さに影響を与えない範囲でいくつでもセ キュリティ機能を追加することができます. また, いくらか考慮した 結果, 便利さに影響を与えるセキュリティ機能を追加することもでき ます. もっと重要なことには, セキュリティ管理者とは少し喧嘩にな るはずなのですが – もしあなたが, 本文書に書かれている勧 告をそのまま使用した場合は, 予想されるクラッカーはやはり本文書 を読んでいるわけですから, あなたの防御策を教えてしまうことにな ります. サービス妨害攻撃 このセクションではサービス妨害攻撃 (DOS 攻撃) を扱います. サービス妨害攻撃は, 普通は, パケット攻撃です. ネットワークを飽 和させる最先端の偽造パケット (spoofed packet) 攻撃に対してシス テム管理者が打てる手はそれほど多くありませんが, 一般的に, その 種の攻撃によってサーバがダウンしないことを確実にすることで, 被 害をある限度に食い止めることはできます. サーバの fork の制限. 踏み台攻撃の制限 (ICMP 応答攻撃, ping broadcast など). カーネルの経路情報のキャッシュ. よくあるサービス妨害攻撃は, fork するサーバプロセスに対す るものです. これは, サーバにプロセス, ファイル記述子, メモリを マシンが死ぬまで食い尽くさせようとするものです. inetd (&man.inetd.8; 参照) には, この種の攻撃を制限するオプションが いくつかあります. マシンがダウンすることを防止することは可能で すが, この種の攻撃によりサービスが中断することを防止することは 一般的に言ってできないことに注意する必要があります. inetd のマ ニュアルページを注意深く読んで下さい. 特に, , , オプションに注意して下さい. IP 偽造攻撃 (spoofed-IP attack) は inetd の オプションの裏をかけるので, 一般 にオプションを組み合わせて使用するべきであることに注意して下さ い. スタンドアロンサーバの中には, 自分自身で fork を制限するパ ラメータを持っているものがあります. Sendmail には, オプションがあります. シ ステム負荷の値変化には遅れがあるので, sendmail の負荷限界指定 オプションを使うよりも, このオプションを使う方がまともに動作す る可能性ははるかに高いです. sendmail の実行を開始する際に, MaxDaemonChildren パラメータを設定するべき です. その値は, 通常見込まれる負荷を扱える程度に十分高いが, そ れだけの数の sendmail を操作しよう とするとマシンが卒倒してしまうほどには高くないような値に設定す るべきです. sendmail をキュー処理モード () で実行することや, sendmail デーモン (sendmail -bd) をキュー処 理用プロセス (sendmail -q15m) と別に実行す ることも, 用心深いことと言えます. それでもなおリアルタイムでの 配送を望むのであれば, のようにすることで, キュー処理をはるかに短い時間間隔で行うことができます. いずれに しても, MaxDaemonChildren オプションに合理 的な値を確実に指定して, sendmail がなだれをうって失敗すること がないようにして下さい. syslogd は直接攻撃される可能性 があるので, 可能ならばいつでも オプション を用いることを強く推奨します. これができないなら, オプションを使って下さい. tcpwrapper の逆 identd などの接 続返し (connect-back) を行うサービスについては十分注意を払うよ うにするべきです. これらは直接攻撃を受ける可能性があります. こ ういう事情があるので, tcpwrapper の 逆 ident 機能を使おうとは思わないのが一般的です. 境界ルータのところでファイアウォールを設けて, 外部からのア クセスに対して内部サービスを防御するという考えは実によいもので す. この考えは, LAN の外部からの飽和攻撃を防ぐことにあり, 内部 サービスをネットワークベースの root 権限への攻撃から防御するこ とにはあまり考慮を払っていません. ファイアウォールは常に排他的 に設定して下さい. つまり, ポート A, B, C, D と M から Z まで以外 のすべてにファイアウォールを設ける というふうにです. このようにすることで, named (ゾーンのプライマリである場合), ntalkd, sendmail などのインターネットからア クセスできるサービスとして特に指定するもの以外の, 小さい番号の ポートすべてをファイアウォールで防御することができます. ファイ アウォールをこの他のやり方 – つまり包含的もしくは受容的 なファイアウォールとして設定しようとする場合, close することを忘れてしまうサービスがいくつか 出てきたり, 新しい内部サービスを追加したのにファイアウォールの 更新を忘れたりする可能性がよく出てきます. ファイアウォール上の 大きい番号のポートを開けておくことにより, 小さい番号のポートを 危険に晒すことなく受容的な動作を許すことができます. FreeBSD で は, net.inet.ip.portrange への sysctl (sysctl -a | fgrep portrange) をいろいろ使用することで, 動的バインドに使用される ポート番号の範囲を制御できることを記憶にとどめておいてください. これによりファイアウォールの設定を簡略化することもできます. たとえば, 通常の first/last 範囲として 4000 から 5000 を, 高位ポートの範囲として, 49152 から 65535 を指定し, (いくつかのインターネットアクセス可能 なポートをブロックから除外するのはもちろんですが) 4000 より下 のすべてをブロックするという設定が考えられるでしょう. また別のよくあるサービス妨害攻撃として, 踏み台攻撃 (springboard attack) と呼ばれるものがあります – これは, あるサーバを攻撃し, そこ結果として生成される応答が自分自身, ロー カルネットワーク, そして他のマシンを過負荷に追い込むようにする 攻撃です. この種の攻撃の中で最もありふれたものに, ICMP ping broadcast 攻撃があります. 攻撃 者は, 実際に攻撃したいマシンのアドレスを送信元アドレスに設定し た ping パケットを偽造して, 対象の LAN のブロードキャストアド レスに向けてパケットを送信します. 境界にあるルータがブロードキャ ストアドレスに対する ping パケットを握り潰すように設定されてい ない場合, LAN は, 詐称された送信元アドレスに向けて応答パケット を生成するはめになり, 犠牲となるマシンが飽和するところまで行っ てしまいます. 攻撃者が同じトリックを異なるネットワーク上のいく つものブロードキャストアドレスに対して同時に使用した場合, とく にひどいことになります. これまでに, 120 メガビット以上のブロー ドキャスト攻撃が観測されています. 2 番目の踏み台攻撃は, ICMP エラー報告の仕掛けを狙うものです. 攻撃者は ICMP エラー応答を生 成するパケットを生成し, サーバの受信ネットワークを飽和させ, そ の結果としてサーバが送信ネットワークを ICMP 応答で飽和させてし まうようにすることができます. mbuf を消費し尽くさせることによ り, この種の攻撃でサーバをクラッシュさせることも可能です. サー バが生成した ICMP 応答を十分速く送信できない場合, とくにひどい ことになります. FreeBSD カーネルには, この種の攻撃の効果を抑制 する ICMP_BANDLIM と呼ばれる新しいカーネルコンパイルオプション があります. 踏み台攻撃の 3 つめの主要なクラスに属する攻撃は, udp echo サービスのような, 特定の inetd 内部サービスに関連する ものです. 攻撃者は, 単に送信元アドレスがサーバ A の echo ポー トであり, 送信先アドレスがサーバ B の echo ポートであるように UDP パケットを偽造します. ここでサーバ A, B はともにあなたの LAN に接続されています. この 2 つのサーバは, この一つのパケッ トを両者の間で互いに相手に対して打ち返しあいます. このようにし てパケットをほんのいくつか注入するだけで, 攻撃者は両方のサーバ と LAN を過負荷状態にすることができます. 同様の問題が内部 chargen ポートにも存在します. 有能なシステム管理者はこの手の inetd 内部テストサービスのすべてを無効にしておくものです. 偽造パケット攻撃は, カーネルの経路情報キャッシュに過負荷を 生じさせるために用いられることもあります. net.inet.ip.rtexpire, rtminexpire, rtmaxcache の sysctl パラメータを参照して下さい. でた らめな送信元 IP アドレスを用いた偽造パケット攻撃により, カーネ ルは, 一時的なキャッシュ経路を経路情報テーブルに生成します. こ れは netstat -rna | fgrep W3 で見ることがで きます. これらの経路は, 普通は 1600 秒程度でタイムアウトになり ます. カーネルがキャッシュ経路テーブルが大きくなり過ぎたことを 検知すると, カーネルは動的に rtexpire を減らしますが, rtminexpire より小さくなるようには決して減らしません. ここに問 題が 2 つあります: 負荷の軽いサーバが突然攻撃された場合, カーネルが十分素 早く反応できないこと. カーネルが持続的攻撃に耐えられるほど十分 rtminexpire が低く設定されていないこと. 自分のサーバが T3 もしくはそれより高速の回線でインターネッ トに接続されている場合, &man.sysctl.8; を用いて rtexpire と rtminexpire とを手動で上書きしておくことが思慮深いことといえます. どちらか 一方でも 0 には決してしないで下さい (自分のマシンをクラッシュ させたくないのであれば :-). 両パラメータを 2 秒 に設定すれば, 攻撃から経路情報テーブルを守るには十分でしょう. Kerberos および SSH を用いたアクセスの問題 もしあなたが, kerberos および ssh を使用したいのだとしたら, 両者 に関して言っておく必要のある問題がいくつかあります. kerberos V は大変優れた認証プロトコルですが, kerberos 化された telnet や rlogin は, バイナリストリームを扱う のに不向きになってしまうようなバグがあります. さらに, デフォル トでは, kerberos は オプションを使わない限 りセッションを暗号化してくれません. ssh では, デフォルトですべてを暗号 化してくれます. ssh はあらゆる場面でとても良く 働いてくれます. ただし, デフォルトで暗号鍵を転送してしまうこと を除けばです. これはつまり, 暗号鍵を持った安全なワークステーショ ンがあって, この暗号鍵で残りのシステムとアクセスできるようになっ ている場合に, 安全でないマシンへ ssh を行なう時に暗号鍵が見えてしま うということです. 実際の鍵そのものが見えてしまうわけではありま せんが, ssh は, あなたが login して いる間, 転送用ポートを作ります. クラッカーが安全でないマシンの root を破ると, クラッカーは, このポートを使って暗号鍵を取得し, この暗号鍵でロックの外れる他のマシンへのアクセスを得ます. スタッフのログインには, kerberos を組み合せた ssh を使用することを勧めます. ssh は, kerberos サポート機能と一緒 にコンパイルできます. こうすると, 見えてしまうかもしれない ssh 鍵をあまりあてにしないで良いよ うになります. また, それと同時に, kerberos 経由でパスワードを 保護することもできます. ssh 鍵は, 安全なマシンからの自動化されたタスク (kerberos はこの用途には 不向きです) のみに使用するべきです. また, ssh の設定で鍵転送をしないようにす るか, あるいは, ssh が authorized_keys ファイル中に書くことを許 している from=IP/DOMAIN オプションを使用し て, 特定のマシンからログインしてきたときのみ鍵が有効であるよう にすることも勧めます. DES, MD5, と Crypt 改訂: &a.unfurl;, 21 March　 2000. 訳: &a.hanai;, 12 September 1996. 訳改訂: &a.jp.hino;, 12 March 2001. UNIX システムにおけるすべてのユーザは, そのアカウントに対応し た一つのパスワードを持っています. それらのパスワードはユーザ本人 と本当のオペレーティングシステムのみが知っているべきであるという ことは明らかでしょう. それらのパスワードを秘密に保っておくために, パスワードは一方向ハッシュとして知られる方式で暗 号化されます. 一方向ハッシュとは, 簡単に暗号化はできるが解読は難 しいという方法です. 言葉を換えると, 先ほど明らかであると書いたの は実は正しくないのです: オペレーティングシステム自身は 本当はパスワードを知らないのです. その代わりに 暗号化された形でのみパスワードを知っていま す.素のテキストとしてパスワードを得る唯一の方法は, 可能な限りのパスワード空間を検索するという力任せの方法です. 不幸なことに, UNIX が生まれようとしているときにパスワードを 安全な形で暗号化できる方式は DES(Data Encryption Standard) に基 づいたものだけでした. このことは米国に住んでいるユーザにとって は大して問題ではありませんでしたが, DES のソースコードを米国外に 輸出することはできないという問題がありました. そのために, FreeBSD は, 米国の法律を守ることと, 未だに DES を使っている他の UNIX 一族との互換性を保つこととを両立する方法を探し出す必要があ りました. その解決方法は, 米国のユーザは DES のライブラリをインストー ルして DES を使用できるが, 米国外のユーザは国外に輸出可能な他の ひとつの暗号化方式を使用することができる, というように暗号化ライ ブラリを分割することでした. これが FreeBSD がデフォルトの暗号化 方式として MD5 を使うようになったいきさつです. MD5 は DES よりも より安全であると考えられているため, DES をインストールする一番の 理由は互換性を保つためといえます. 暗号化機構を理解する FreeBSD がどの暗号化方式を使うようにセットアップされている かを判断するのは簡単です. /etc/master.passwd ファイルの中の暗号化さ れたパスワードを調べてみるのが一つの方法です. MD5 ハッシュで暗 号化されたパスワードは, DES ハッシュで暗号化されたパスワードよ りも長いですし, その上 $1$ と いう文字で始まるという特徴も持っています. DES のパスワードはこ れといって識別可能な特徴は持っていませんが, MD5 のパスワードよ りは短く, そして $ という文字を含ま ない 64 文字のアルファベットを使って表現されているので, 比較的 短い文字列でドル記号で始まっていないものはおそらく DES のパス ワードでしょう. 同様の方法で, ライブラリはパスワードを識別します. 結果とし て, DES のライブラリは MD5 パスワードを識別でき, そして MD5 を 使って MD5 で暗号化されたパスワードをチェックし, その他のパス ワードには DES を使ってチェックします. DES のライブラリは MD5 も含んでいるのでこのようなことが可能なのです. 残念なことに, 反 対は真ではありません. MD5 のライブラリは DES で暗号化されたパ スワードを認証することができません. あなたのシステムでプログラムがどちらのライブラリを使ってい るかを調べるのは非常に簡単です. crypt を使うプログラムは libcrypt をリンクしています. そしてそれぞれのライブラリに対す る適切な実装へのシンボリックリンクとなってい ます. たとえば, DES 版を使っているようなシステムにおいては次のようになっています: &prompt.user; ls -l /usr/lib/libcrypt* lrwxr-xr-x 1 root wheel 13 Mar 19 06:56 libcrypt.a -> libdescrypt.a lrwxr-xr-x 1 root wheel 18 Mar 19 06:56 libcrypt.so.2.0 -> libdescrypt.so.2.0 lrwxr-xr-x 1 root wheel 15 Mar 19 06:56 libcrypt_p.a -> libdescrypt_p.a MD5 に基づいたライブラリを使っているシステムにおいては, 同 じようなリンクが 見られるでしょうが, そのターゲットは libdescrypt ではなく libscrypt になっているでしょう. もし DES 機能を持った crypt ライブラリ libdescrypt をインストールしたのなら (つ まり "crypt" ディストリビューションをインストールした場合), 新 規パスワードがどちらのパスワード形式になるかは, /etc/login.conf の中の passwd_format ログインケーパビリティによって制 御されます. その値としては, des または md5 を設定することができます. ログインケーパビ リティに関するより詳細な情報は, &man.login.conf.5; マニュアルページ をご覧ください. S/Key S/Key は一方向ハッシュ関数を基にしたワンタイムパスワード方式 です. FreeBSD では, 互換性のために MD4 ハッシュを用いていますが 他のシステムでは MD5 や DES-MAC を用いてます. S/Key は, バージョ ン1.1.5 以降のすべての FreeBSD に含まれていますし, FreeBSD 以外 の数多くのシステムの上でも利用されています. S/Key ば Bell Communications Research, Inc. の登録商標です. 以下の説明では, 三種類の異なる「パスワード」が使われます. まず一つ目は, あなたが普段使っている普通の UNIX スタイルの, もし くは Kerberos でのパスワードです. ここではこれを UNIX パ スワードと呼ぶことにし ます. 二つ目は, S/Key の key プログラムによって生成され, keyinit プログラムとログインプロンプトが受け 付けるパスワードです. ここではこれをワンタイムパスワード と呼ぶことにします. 三つ目のパスワードは, key (と場合により keyinit) プログラムに対してユーザが入力する秘密のパスワードで, ワンタイム パスワードを生成するのに使われます. ここではこれを秘密の パスフレーズもしくは単に “パスフレーズ” と呼 ぶことにします. (訳注: ユーザが頭の中だけにしまっておくべきもの が, この秘密のパスフレーズです. なお, 原文ではこれをパスワードと 表記していますが, 混乱を避けるために訳文ではすべて 秘密の パスフレーズに統一しています.) 秘密のパスフレーズは, UNIX パスワードと何の関連性もありませ ん: 両者を同一に設定することは可能ですが, お奨めしません. UNIX パスワードは長さが 8 文字に制限されています (訳注: FreeBSD で DES を導入していない場合はもっと長いパスワードも認識されます). これに対し, S/Key では秘密のパスフレーズを好きなだけ長くすること ができます (訳注: 実装上, key コマンドなどの バッファ長で制限されてしまう可能性があります. 200 文字程度に押 えておいた方がよいでしょう :-). 6 語から 7 語からなるパスフレー ズがふつうです. ほとんどの部分で, S/Key システムは UNIX のパスワー ドシステムと完全に独立して動作するようになっています. パスフレーズに加え, S/Key システムにとって重要な二種類のデー タがあります. 一つはシード (seed: 種)または キー (key: 鍵)と呼ばれるもので, 二つの文字と五つ の数字で構成されます. もう一つはシーケンス番号 (iteration count) で, 1 から 100 までの整数です. S/Key はここまで に述べたデータを利用してワンタイムパスワードを生成します. その方 法は, まずシードと秘密のパスフレーズを連結し, それに対してシーケ ンス番号の回数だけ MD4 ハッシュを繰り返し計算します. そしてその 結果を 六つの短い英単語に変換します. login プ ログラムと su プログラムは, 前回最後に受け付 けられたワンタイムパスワードを記録しています. そして, その前回 のワンタイムパスワードと, ユーザが入力したワンタイムパスワードを 一回ハッシュ関数にかけた結果とが一致した場合に, このユーザは認証 されます. 一方向ハッシュ関数を使っているので, もし正しく認証され たワンタイムパスワードが一回盗聴されたとしても, 次回以降に使われ る複数のワンタイムパスワードを生成することは不可能です. シーケ ンス番号はログインが成功するたびに一つずつ減らされて, ユーザとロ グインプログラムの間で同期が取られます. シーケンス番号が 1 まで 減ったら, S/Key を再度初期化する必要があります. 次に, S/Key 関連の四つのプログラムについて説明します. key プログラムは, シーケンス番号一つと, シー ド一つと, 秘密のパスフレーズ一つとを受け付けて, ワンタイムパスワー ドを一つ生成します. keyinit プログラムは, S/Key を初期化するのに使用され, また秘密のパスフレーズやシーケン ス番号やシードを変更するためにも使用されます. このプログラムを実 行するには, 秘密のパスフレーズか, または, シーケンス番号とシード とワンタイムパスワードの一組かの, どちらかが必要になります. keyinfo プログラムは, /etc/skeykeys というファイルを調べて, この プログラムを起動したユーザの現在のシーケンス番号とシードを表示し ます. 最後に, login と su プログラムについてですが, これらは S/Key のワンタイムパスワード を, (訳注:システムが) ユーザを認証するものとして受理するのに必要 な処理をおこないます. login プログラムは, 指 定された特定のアドレスからの接続に対して, UNIX パスワードの使用 を認めなくする機能, 逆に言えば S/Key の利用を強制する機能も持っ ています. この文書では, 四種類の異なる操作について説明します. 一つ目は, keyinit プログラムを信頼できる通信 路上で利用する場合で, 一番始めに S/Key を設定する操作や, 使い始 めたあとで秘密のパスフレーズやシードを変更する操作です. 二つ目は, keyinit プログラムを信頼できない通信路上で利 用する場合で, 操作の目的は一つ目と同じです. この場合には key プログラムを併用する必要があります. 三つ 目は, key プログラムを使い, 信頼できない通信 路を通じてログインする操作です. 四番目は, key プログラムを使って, 複数のワンタイムパスワードを一気に生成する操 作です. ここで生成した複数のワンタイムパスワードは, メモしたり 印刷したりして携帯し, 信頼できる通信路が一切ないところで利用する ことができます. (訳注: ワンタイムパスワードを記録した紙をなくさ ないこと! 電話番号やIPアドレス, ユーザ名を一緒にメモしていたら 最悪です!!) 信頼できる通信路での初期化 信頼できる通信路 (たとえばあるマシンのコンソール画面や, ssh を使っている時など) を利用しているときに, S/Key を初めて初期化 すること, S/Key の秘密のパスフレーズを変更すること, またはシー ドを変更すること, をおこなうことができます. そのためには, まず あなた自身がログインし, keyinit コマンドを 以下のようにパラメータなしで実行します: &prompt.user; keyinit Adding unfurl: Reminder - Only use this method if you are directly connected. If you are using telnet or rlogin exit with no password and use keyinit -s. ) `keyinit' コマンドが出力する注意です. 訳すと, ) 注意 - この動作モードはマシンに直接入力しているときのみ利用 ) すること. もし今 telnet や rlogin を使っているなら, 秘密のパ ) スフレーズを入力せずにこのままコマンドを終了し, かわりに ) keyinit -s を実行すること. Enter secret password: Again secret password: ID unfurl s/key is 99 to17757 DEFY CLUB PRO NASH LACE SOFT Enter secret password: というプロンプトに 対してあなたが考えた秘密のパスフレーズを入力します. このパスフ レーズはログインするときに使うものではなく, ログインするときに 使うワンタイムパスワードを生成するために使うものであることを覚 えておいてください. ID から始まる行は, S/Key に おける一回分のパラメータであり, あなたのログイン名とシーケンス番 号とシードです. (訳注: `keyinit' コマンドは 次回にログインするときに使えるパラメータを参考のためにここで表示 します.) S/Key を使ってログインするときには, システム側が自動 的にこれらのパラメータを表示してくれますから, これらのパラメータを 覚えておく必要はありません. 最後の行が, 今述べたパラメータと入力 された秘密のパスフレーズから計算されたワンタイムパスワードです. この例を実行した後, 次にログインするときに打ち込むべきワンタイ ムパスワードがこれです. 信頼できない通信路での初期化 信頼できない通信路を使って S/Key を初期化, または秘密のパ スフレーズを変更するためには, 信頼できる通信路として, その信頼 できない通信路とは別のものを用意する必要があります. その信頼で きる通信路は key プログラムを実行するために 必要となるもので, たとえばそれは, あなたが信頼できる Macintosh のデスクアクセサリや信頼できるマシンのシェルプロンプトだったり するでしょう. (訳注: ここでの通信路とはマシンそのものになりま す. 信頼できるマシンとは, 信頼できる人がしっかり管理しているマ シンということです.) 他に準備しておくものとして, シーケンス番 号 (100 は適切な値といえるでしょう) と, 場合によっては自分で考 えた, またはランダムに生成されたシードがあります. (あなたが S/Key を初期化しようとしているマシンへの) 信頼できない通信路を 使うときには, keyinit -s コマンドを以下のよ うに使用します: &prompt.user; keyinit -s Updating unfurl: Old key: to17758 Reminder you need the 6 English words from the key command. ) `keyinit' コマンドが出力する注意です. 訳すと, ) 注意 - skey コマンドの出力する 6 英単語が必要になります. Enter sequence count from 1 to 9999: 100 Enter new key [default to17759]: s/key 100 to 17759 s/key access password: デフォルトのシード (keyinit プログラム は困ったことにこれを key と読んでいるのです が, 混乱しないよう注意してください) で構わなければ, リターンキー を押してください. 次に, アクセスパスワードを入れる前に, あらか じめ用意しておいた信頼できる通信路(信頼できるマシンや信頼でき る S/Key デスクアクセサリなど) へ移って, 先ほどと同じパラメータ を入力します: &prompt.user; key 100 to17759 Reminder - Do not use this program while logged in via telnet or rlogin. Enter secret password: <秘密のパスフレーズ> CURE MIKE BANE HIM RACY GORE ここで信頼できない通信路の方に戻って, key コマンドが出力したワンタイムパスワード をコピーして keyinit プログラムに入力します. s/key access password:CURE MIKE BANE HIM RACY GORE ID unfurl s/key is 100 to17759 CURE MIKE BANE HIM RACY GORE 後は, 前章で説明したことと同様です. ワンタイムパスワードを一つ生成する S/Key の初期化ができたら, ログインするときには以下のような プロンプトが出てくるでしょう: &prompt.user; telnet example.com Trying 10.0.0.1... Connected to example.com Escape character is '^]'. FreeBSD/i386 (example.com) (ttypa) login: <ユーザ名> s/key 97 fw13894 Password: ここでは表示していませんが, 便利な機能がログインプログラム に備わっています: パスワードプロンプトに対して, 何も入力せずに リターンを押すとエコーモードに切り替わります. つまりタイプし た文字がそのまま見えるようになるのです. これはS/Key のワンタイ ムパスワードを紙に印刷していた場合など, ワンタイムパスワードを 手で入力しなければならない場合に特に役立つ機能です. また, この ログインしようとしてるマシンが, 接続元のマシンから UNIX パスワードを使ってログインすることができないように設定さ れている場合には, ログインプロンプトには S/Key のワンタイムパ スワードのみが受け付けられることを示す (s/key required) という注釈が表示されます. 次に, このログインプロンプトに対して入力するためのワンタイ ムパスワードを生成しましょう. そのために, key プログラムを使える信頼できるマシンを用 意します. (key プログラムには DOS や Windows の上で動くもの, MacOS の上で動くものなどもあります.) key プログラムを使うときには, シーケンス番 号とシードを指定します. ログインしようとしているマシンのログ インプロンプトの右側をカットアンドペーストすると楽でしょう. 信頼できるシステムで: &prompt.user; key 97 fw13894 Reminder - Do not use this program while logged in via telnet or rlogin. Enter secret password: WELD LIP ACTS ENDS ME HAAG ここでワンタイムパスワードが得られました. ログインを続けま しょう: login: <username> s/key 97 fw13894 Password: <return to enable echo> s/key 97 fw13894 Password [echo on]: WELD LIP ACTS ENDS ME HAAG Last login: Tue Mar 21 11:56:41 from 10.0.0.2 ... 以上の手順は, 信頼できるマシンが利用できる場合の みに使えるもっとも簡単な方法です. Java による S/Key の key applet もあり, The Java OTP Calculator からダウンロードして Java をサポートするブ ラウザ上でローカルに実行することができます. 複数のワンタイムパスワードを生成する 都合によっては, 信頼できるマシンや信頼できる通信路が一切確 保できないようなところで S/Key を使う必要があるでしょう. この ような場合には, key コマンドを使って複数の ワンタイムパスワードをあらかじめ一気に生成し, 紙に印刷して携帯 していくことができます. たとえば: &prompt.user; key -n 5 30 zz99999 Reminder - Do not use this program while logged in via telnet or rlogin. Enter secret password: <秘密のパスフレーズ> 26: SODA RUDE LEA LIND BUDD SILT 27: JILT SPY DUTY GLOW COWL ROT 28: THEM OW COLA RUNT BONG SCOT 29: COT MASH BARR BRIM NAN FLAG 30: CAN KNEE CAST NAME FOLK BILK という引数によって 5 個のワンタイム パスワードを順に生成します. ここで は, 最 後のシーケンス番号となるべき数字です. 出力は普通に使う順番とは 逆に出力されていることに注意してください (訳注: 一番最初に使うワンタイムパスワードは一番最後に出力され たものです). この結果をカットアンドペーストして lpr コマンドを使って印刷すると よいでしょう. もしあなたがセキュリティに偏執するなら, この結果を紙と鉛筆を使っ て手で書き移した方がよいかもしれません. ここで, 出力の各行はシー ケンス番号とそれに対応する一回分のワンタイムパスワードです. 消費済みの ワンタイムパスワードの行をペンで消していくと便利で しょう. UNIX パスワードの利用を制限する 設定ファイル /etc/skey.access を使っ て UNIX パスワードの利用を制限することができます. この場合の判 断基準として, ログインを受け付ける際のホスト名, ユーザ名, 端末 のポート, IP アドレスなどが利用できます. この設定ファイルの詳 細に関してはマニュアル &man.skey.access.5; をご覧ください. マ ニュアルにはこの機能に関わるセキュリティについて, いくつかの警 告が記述してあります. この機能を使ってセキュリティを高めようと するのならば絶対にこのマニュアルを読んでください. もし /etc/skey.access ファイルが存在 しないならば (FreeBSD のデフォルト状態ではそうです), すべての ユーザが UNIX パスワードを利用することができます. 逆に, もし ファイルが存在するならば, skey.access ファ イルに明示的に記述されていない限り, すべてのユーザは S/Key の 利用を要求されます. どちらの場合においても, そのマシンのコンソー ルからはいつでも UNIX パスワードを使ってログインすることが可能 です. 以下によく使われるであろう三種類の設定を含む設定ファイルの 例を示します: permit internet 192.168.0.0 255.255.0.0 permit user fnord permit port ttyd0 はじめの行 (permit internet) で, telnet などで接続するときの IP のソースアドレス (注意: これは偽造され るおそれがあります) が特定の値とマスクに一致している場合に, UNIX パスワードの利用を許可することを指定しています. この設定 自体はセキュリティを高めるための機能ではありません. そうでは なく, ログインの権利を持つ許可されたユーザに対して, 現在そのユー ザが使っているネットワークが信頼できないと考えられるので S/Key を使うべきである, ということを気づかせるための機能であると考え てください. 二行目 (permit user) によって, ある特定 のユーザ, この場合は fnord, に対して, いつ でも UNIX パスワードの利用を許可するように指定しています. 一般 的にはこの設定をおこなうべきではありません. key プログラムがどうしても使えない環境にい る人や, ダム端末しかない環境にいる人, または何度教えても聞く耳 を持たないような人をサポートする必要がある場合にのみ設定をおこ なってください. 三行目 (permit port) によって, ある特定 の端末ポートからログインしようとするすべてのユーザに対して UNIX パスワードの利用を許可するように指定しています. この設定 はダイヤルアップ回線に対する設定として利用できるでしょう. Kerberos 原作: &a.markm; (Mark Dapoz md@bsc.no からの寄稿に基づいています). 訳: &a.jp.arimura;. Kerberosは, サーバのサービスによってユーザが安全に認証を受けられる ようにするための, ネットワークの付加システム及びプロトコルです. リモートログイン, リモートコピー, システム間での安全なファイルのコピ ーやその他のリスクの高い仕事がかなり安全に, そしてこれまでより制御 できるようになります. 以下の文章は, FreeBSD用として配布されているKerberosをセットアップ する際のガイドとして読むことができます. しかし, 完全な説明が必要な場合には, マニュアルページを読んだ方がよい でしょう. FreeBSDのKerberosは, オリジナルの4.4BSD-Liteの配布に含まれているものではなく, FreeBSD 1.1.5.1のときに移植されたeBonesです. これはアメリカ/カナダの外で作成されており, そのため, アメリカか らの暗号技術の輸出制限があった時代でも, これら以外の国の人々が手に入れられるものでした. 初期データベースの作成 この作業はKerberosサーバだけでおこないます. まず, 古いKerberosの データベースが存在しないことを確認してください. ディレクトリ/etc/kerberosIVに移って, 次のファイルだけが 存在することをチェックします: &prompt.root; cd /etc/kerberosIV &prompt.root; ls README krb.conf krb.realms もし他のファイル (principal.* や master_key) が 存在する場合には, kdb_destroyというコマンドで古い Kerberosデータベースを消してください. Kerberosが走っていなければ, 単に余計なファイルを消せばよいです. まず, krb.conf と krb.realmsを編集してKerberosの 管理領域 (realm) を定義してください. ここでは管理領域がGRONDAR.ZA で, サーバ名がgrunt.grondar.zaであるとします. krb.conf というファイルを次のように編集してください: &prompt.root; cat krb.conf GRONDAR.ZA GRONDAR.ZA grunt.grondar.za admin server CS.BERKELEY.EDU okeeffe.berkeley.edu ATHENA.MIT.EDU kerberos.mit.edu ATHENA.MIT.EDU kerberos-1.mit.edu ATHENA.MIT.EDU kerberos-2.mit.edu ATHENA.MIT.EDU kerberos-3.mit.edu LCS.MIT.EDU kerberos.lcs.mit.edu TELECOM.MIT.EDU bitsy.mit.edu ARC.NASA.GOV trident.arc.nasa.gov この例にあるような他の管理領域は, 実際には必要ありません. この例は複数の管理領域を認識する方法を示したものですので, これらの行は含めなくても結構です. 1行目はこのシステムが動いている管理領域の名前です. 他の行は管理領域とホスト名のエントリです. 行の1つめの単語が管理領域で, 2つめがその管理領域の中で 鍵配布センター(Key Distribution Center) として働くホスト名です. ホスト名の次に admin server と書いてある場合には, そのホストが ``管理データベースサーバ''(Administrative Database Server) も提供 することを意味します. これらの単語について詳しく知りたい場合にはKerberosのマニュアル ページをご覧ください. ここで, GRONDAR.ZAという管理領域にgrunt.grondar.za およびその他の.grondar.za ドメインのすべてのホストを追加し なければなりません. krb.realmsは次のようになります: &prompt.root; cat krb.realms grunt.grondar.za GRONDAR.ZA .grondar.za GRONDAR.ZA .berkeley.edu CS.BERKELEY.EDU .MIT.EDU ATHENA.MIT.EDU .mit.edu ATHENA.MIT.EDU もう一度注意しますが, 他の管理領域を書く必要はありません. これらは複数の管理領域を認識できるようにマシンを設定する方法を 示した例ですので, これらの行は消して構いません. 1行目は名前をつけた管理領域に 特定の システムを含めるための ものです. 残りの行は名前をつけた管理領域にサブドメインのデフォルトの システムを含めるためのものです. これでデータベースを作成する準備ができました. この操作はKerberos サーバ (鍵配布センター) を起動するだけです. kdb_initコ マンドを次のように実行してください: &prompt.root; kdb_init Realm name [default ATHENA.MIT.EDU ]: GRONDAR.ZA You will be prompted for the database Master Password. It is important that you NOT FORGET this password. Enter Kerberos master key: ここで鍵を保存して, ローカルのマシンにあるサーバが取り出せるように します. それにはkstashコマンドを使用します. &prompt.root; kstash Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! これで暗号化されたマスタパスワードが /etc/kerberosIV/master_key に保存されました. すべてが動くようにするための設定 Kerberosを導入する それぞれの システムのデータベースに, 2つ のprincipal (主体名) を追加する必要があります. その名前は kpasswdとrcmdです. これら2つのprincipalは, 個々 のシステムにおいて, システム名と同じ名前のインスタンスと組にして作成 されます. これらの kpasswd と rcmd というデーモンによって, 他の システムからKerberosのパスワードを変更したり, rcpや rlogin, rshといったコマンドを実行したりできるよ うになります. それでは実際にこれらのエントリを追加しましょう: &prompt.root; kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: passwd Instance: grunt <Not found>, Create [y] ? y Principal: passwd, Instance: grunt, kdc_key_ver: 1 New Password: <---- ここは「RANDOM」と入力してください Verifying password New Password: <---- ここは「RANDOM」と入力してください Random password [y] ? y Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: rcmd Instance: grunt <Not found>, Create [y] ? Principal: rcmd, Instance: grunt, kdc_key_ver: 1 New Password: <---- ここは「RANDOM」と入力してください Verifying password New Password: <---- ここは「RANDOM」と入力してください Random password [y] ? Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: <---- 何も入力しないと終了します サーバファイルの作成 次に, 各マシンにおけるサービスを定義している, すべてのインスタンス を展開します. これにはext_srvtabというコマンドを使用しま す. このコマンドで作成されるファイルは, Kerberosの各クライアン トの/etc/kerberosIVディレクトリに 安全な方法でコピーまたは 移動する必要があります. このファイルはそれぞれのサーバとクラ イアントに存在しなければならず, またKerberosの運用において重要なも のです. &prompt.root; ext_srvtab grunt Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Generating 'grunt-new-srvtab'.... このコマンドは一時的なファイルを作成するだけです. ファイル名をすべ てのサーバが読めるような srvtab という名前に変更しな ければなりません. mvコマンドを用いてシステムの場所に移動 してください. &prompt.root; mv grunt-new-srvtab srvtab そのファイルがクライアントに配るためのもので, ネットワークが安全で はないと思われる場合には, client-new-srvtab を移動 可能なメディアにコピーして物理的に安全な方法で運んでください. クラ イアントの/etc/kerberosIVディレクトリで, 名前を srvtabに変更し, modeを600にするのを忘れないでください: &prompt.root; mv grumble-new-srvtab srvtab &prompt.root; chmod 600 srvtab データベースへのユーザの追加 ここで, ユーザのエントリをデータベースに追加する必要があります. 始めに, ユーザjaneのエントリを作成してみましょう. kdb_edit を用いて次のように作成してください: &prompt.root; kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: jane Instance: <Not found>, Create [y] ? y Principal: jane, Instance: , kdc_key_ver: 1 New Password: <---- 安全なパスワードを入れてください Verifying password New Password: <---- もう一度パスワードを入れてください Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: <---- 何も入力しないと終了します すべてのテスト まず始めにKerberosデーモンを起動する必要があります. /etc/rc.conf ファイルを正しく編集してあれば, マシンを再 起動することでに自動的にデーモンが起動します. これはKerberosサー バでのみ必要です. Kerberosクライアントは/etc/kerberosIVか ら必要なものを自動的に入手します. &prompt.root; kerberos & Kerberos server starting Sleep forever on error Log file is /var/log/kerberos.log Current Kerberos master key version is 1. Master key entered. BEWARE! Current Kerberos master key version is 1 Local realm: GRONDAR.ZA &prompt.root; kadmind -n & KADM Server KADM0.0A initializing Please do not use 'kill -9' to kill this job, use a regular kill instead Current Kerberos master key version is 1. Master key entered. BEWARE! さあ, これで上で作成した jane というIDのチケットを kinitコマンドで得ることができます: &prompt.user; kinit jane MIT Project Athena (grunt.grondar.za) Kerberos Initialization for "jane" Password: klist コマンドを用いてトークンを見て, きちんとチケットを持って いるかどうか確認してください: &prompt.user; klist Ticket file: /tmp/tkt245 Principal: jane@GRONDAR.ZA Issued Expires Principal Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.GRONDAR.ZA@GRONDAR.ZA passwd コマンドを用いてパスワードを変更して, kpasswdデーモ ンがKerberos データベースに対して認証されるかどうかチェックして ください: &prompt.user; passwd realm GRONDAR.ZA Old password for jane: New Password for jane: Verifying password New Password for jane: Password changed. <command>su</command>特権の追加 root権限が必要なユーザは誰でも, suコマンドのパス ワードをユーザ毎に別のもの として持つことができます. rootにsu できる権利を与えられたidを追加します. これは, principalに付いているroot というインスタンスに よって制御されています. kdb_editを用いて jane.rootというエントリを Kerberosデータベースに作成します: &prompt.root; kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: jane Instance: root <Not found>, Create [y] ? y Principal: jane, Instance: root, kdc_key_ver: 1 New Password: <---- 安全なパスワードを入れます Verifying password New Password: <---- もう一回パスワードを入れます Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? 12 <--- ここは短くしてください Attributes [ 0 ] ? Edit O.K. Principal name: <---- 何も入力しないと終了します 実際にトークンをもらって, ちゃんと働いているかどうか確認しましょう: &prompt.root; kinit jane.root MIT Project Athena (grunt.grondar.za) Kerberos Initialization for "jane.root" Password: ここでrootユーザの .klogin ファイルにユーザを追加する必要が あります. &prompt.root; cat /root/.klogin jane.root@GRONDAR.ZA suしてみましょう: &prompt.user; su Password: どのトークンを持っているか見てみましょう: &prompt.root; klist Ticket file: /tmp/tkt_root_245 Principal: jane.root@GRONDAR.ZA Issued Expires Principal May 2 20:43:12 May 3 04:43:12 krbtgt.GRONDAR.ZA@GRONDAR.ZA 他のコマンドの使用 ここまでの例では, jane という principal を root とい うインスタンス付きで作成しました. これはユーザと同じ名前をprincipalと しており, Kerberosのデフォルトの値です; <username>.root という形式の <principal>.<instance>で, 必要なエント リがrootのホームディレクトリの .kloginファイルに あれば, <username>がrootに suすることができま す. &prompt.root; cat /root/.klogin jane.root@GRONDAR.ZA 同様に, ユーザのホームディレクトリの .kloginファイルに次の ような行がある場合には: &prompt.user; cat ~/.klogin jane@GRONDAR.ZA jack@GRONDAR.ZA jane または jack という名前で (前述のkinit によって) 認証されている GRONDAR.ZA という管理領域のユーザ なら誰でもrlogin や rsh, rcp等によってこ のシステム (grunt) のjaneのアカウントまたはファ イルにアクセスできます. たとえば, Janeが他のシステムにKerberos を用いてloginします: &prompt.user; kinit MIT Project Athena (grunt.grondar.za) Password: &prompt.user; rlogin grunt Last login: Mon May 1 21:14:47 from grumble Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995 次の例では, Jackが同じマシンの Jane のアカウントにloginします. Janeは .klogin ファイルを前述のように設定しており, Kerberosではjackというprincipal をインスタンスなしで設定してあ ります. &prompt.user; kinit &prompt.user; rlogin grunt -l jane MIT Project Athena (grunt.grondar.za) Password: Last login: Mon May 1 21:16:55 from grumble Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995 ファイアウォール 原作: &a.gpalmer;, Alex Nash;. 訳: &a.jp.saeki;. 11 November 1996. ファイアウォールは, インターネットに参加している人はもちろんのこと, プライベートネットワークのセキュリティ向上のための アプリケーションを 探している人にとっても, ますます興味深くなりつつある分野です. このセクションではファイアウォールとは何か, ファイアウォールの使用法, そしてファイアウォールを構築するために FreeBSD のカーネルで 提供されているファシリティ (機能) の使用法について説明したいと思います. 社内のネットワークと 巨大かつ信頼のおけない インターネットとの間にファイアウォールを構築することで セキュリティ上のすべての問題が解決できると考える人がいます. ファイアウォールはセキュリティ上の問題を 解決する助けになる場合もありますが, 充分な設定がなされていないファイアウォールは, まったくファイアウォールを 持たない場合よりもセキュリティ上の危険を増大させてしまいます. ファイアウォールにできることは, あなたのシステムにもう一つのセキュリティ層を 追加することだけで, 本気でアタックをしかけてくるクラッカーが内部ネットワークに 侵入するのを妨げることはできません. ファイアウォールを侵入不可能と過信して 内部のセキュリティをおろそかにすることは, 単にクラッカーの仕事を少し簡単にするだけでしか ありません. ファイアウォールとは何か ? 現在インターネットで普通に使用されている ファイアウォールには 二つの異なるタイプがあります. 一つは, 厳密には パケットフィルタリングルータ と 呼ばれるタイプのものです. これはマルチホームのホストマシン (複数の ネットワークに接続されているマシン) のカーネルが, ある規則にしたがって パケットを転送したりブロックしたりするものです. もう一つは, proxy (代理) サーバ として知られているタイプのものです. これは, おそらくはマルチホームのホストマシン上で, カーネルによるパケット転送を 禁止して, デーモンにより認証の提供とパケットの転送とを おこなうものです. 二つのタイプのファイアウォールを組み合わせて使用して, 特定のマシン ( 要塞ホスト と呼ばれる) だけが パケットフィルタリングルータを通して内部ネットワークへ パケットを送ることができるよう設定している サイトがしばしば存在します. proxy (代理) サービスは通常の認証機構よりもセキュリティを 強化してある 要塞ホストで動作させます. FreeBSD は (IPFW として知られる) カーネルパケットフィルタ込みで 提供されています. このセクションの後の方では, このフィルタについての 説明を集中しておこないます. サードパーティから提供されるソフトウェアを使用することにより, Proxy サーバを FreeBSD 上に構築することができます. しかし, 現在入手可能な proxy サーバは たいへんバラエティに富んでいるので, このドキュメントでそれらすべてを カバーすることは不可能です. パケットフィルタリングルータ ルータとは, 二つまたはそれ以上のネットワークの間で パケットの転送をおこなう マシンのことです. パケットフィルタリングルータは, そのカーネルの内部に, 一つ一つのパケットをルールリストと比較して 転送するかしないかを決める 特別なコードを持っています. 最近の IP ルーティングソフトウェアのほとんどは, 内部に パケットのフィルタリングをおこなうためのコードを持っていて, デフォルトでは すべてのパケットを転送するようになっています. このフィルタを有効にするためには, パケットの通過を許すべきかどうかを決める ルールを自分で定義する必要があります. パケットを通すべきか通すべきでないかを決めるために, パケットヘッダの内容にマッチするものが ルールリストから探されます. マッチするルールが見つかると, ルールアクションが実行されます. ルールアクションには, パケットを捨てる, パケットを転送する, またはパケットの発信元に ICMP メッセージを送り返すというものがあります. ルールの検索は先頭から順番におこなわれ, 通常は最初にマッチしたものだけが 適用されます. そのため, このルールリストはルールチェーン と呼ばれることもあります. パケットマッチングの基準は使用するソフトウェアに よって異なりますが, 通常はパケットの発信元 IP アドレス, 宛先 IP アドレス, 発信元ポート番号, 宛先ポート番号 (ポート番号はポートをサポートするプロトコルの場合のみ), パケットタイプ (UDP, TCP, ICMP など) に基づくルールを指定することができます. Proxy サーバ Proxy サーバとは通常のシステムデーモン (telnetd, ftpd など) を 特別なサーバで置き換えたマシンのことです. これらのサーバは, 通常は中継をおこなって特定方向への接続だけを許すため, proxy サーバ と呼ばれます. (たとえば) proxy telnet サーバをファイアウォールホストで走らせておきます. 外部からユーザがファイアウォールに対して telnet を実行すると, proxy telnet サーバが応答して, 何らかの認証機構を実行します. これを通過した後で, 内部ネットワークへのアクセスがおこなえるように なるのです. (内部ネットワークからの信号は proxy サーバがかわりに受け取り, 外へ向けて送り出します.) Proxy サーバは通常, 普通のサーバより堅固に構築されていて, しばしば 使い捨てパスワードシステムなどを含む, 多様な認証機構を持っています. 使い捨てパスワードシステムとは, どういうものなのでしょうか. 仮に誰かが何らかの方法で, あなたが使用したパスワードを手に入れたとします. しかし, 一度使用したことで, そのパスワードは既に無効になっているのです. ですから, そのパスワードをもう一度使用したとしても, あなたのシステムへ アクセスすることはできないというわけです. これらのサーバは中継をおこなうだけで, 実際のところサーバホスト自身への アクセスをユーザに許してはいません. そのため, 何者かがセキュリティシステムに 侵入用の裏口を取り付けることは, より困難になっています. proxy サーバはアクセス制限の方法をいくつも持っていて, 特定のホスト だけがサーバへのアクセス権を得ることができるように なっていることがあり ます. そして目的のマシンと通信できるユーザを制限するように 設定することもできます. もう一度言いますが, どんなファシリティ (機能) が使えるかは, どんな proxy サービスをおこなうソフトウェアを選ぶかに大きく 依存します. IPFW で何ができるか FreeBSD とともに配布されている IPFW は, カーネル内部にあって パケットのフィルタリングとアカウンティングを おこなうシステムであり, ユーザ側のコントロールユーティリティである &man.ipfw.8; を 含んでいます. ルーティングの決定をおこなう際に, これらは互いに協力して, カーネルで使用されるルールを定義したり, 現在使用されているルールを 問い合わせたりすることができます. IPFW は互いに関連する二つの部分からなっています. ファイアウォールセクションは パケットフィルタリングをおこないます. また, IP アカウンティングセクションはファイアウォールセクションのものと 似たルールに基づいてルータの使用を追跡します. これにより, (たとえば) 特定のマシンからルータへのトラフィックがどのくらい 発生しているか調べたり, どれだけの WWW (World Wide Web) トラフィックが フォワードされているかを知ることができます. IPFW は, ルータではないマシンにおいても入出力コネクションの パケットフィルタリングのために 使用することができるように設計されています. これは一般的な IPFW の使用法とは異なる特別な使い方ですが, こういった状況でも同じコマンドと テクニックが使用されます. FreeBSD で IPFW を有効にする IPFW システムの中心となる部分はカーネル内部にあります. そのため, どのファシリティ (機能) を必要とするかによって, 一つまたは それ以上のオプションをカーネルコンフィグレーション ファイルに追加し, カーネルを再コンパイルする必要があるでしょう. カーネルの再コンパイル方法の詳細については, カーネルコンフィグレーション を参照してください. 現在, IPFW に関係するカーネルコンフィグレーションオプションは 三つあります: options IPFIREWALL パケットフィルタリングのためのコードを カーネルに組み込みます. options IPFIREWALL_VERBOSE &man.syslogd.8; を通じて パケットのログを取るためのコードを有効にします. フィルタルールでパケットのログを取るように指定しても, このオプションが指定されていなければ, ログを取ることはできません. options IPFIREWALL_VERBOSE_LIMIT=10 &man.syslogd.8; を通じて ログを取るパケットの数をエントリ毎に制限します. 敵対的な環境においてファイアウォールの 動作のログを取りたいけれど, syslog の洪水によるサービス拒絶攻撃に対し 無防備でありたくないという場合に, このオプションを使用したいと思うことが あるかもしれません. チェーンエントリのログが指定された制限数に達すると, そのエントリに関するログ取りは停止されます. ログ取りを再開するには, &man.ipfw.8; ユーティリティを使用して 関連するカウンタをリセットする必要があります: &prompt.root; ipfw zero 4500 4500 とは, ログ取りを続行したいチェーンエントリの番号です. 以前のバージョンの FreeBSD は IPFIREWALL_ACCT というオプションを 持っていました. しかし, ファイアウォールコードがアカウンティングファシリティ (機能) を 自動的に含むようになったため, 現在では使用されることはなくなっています. IPFW の設定 IPFW ソフトウェアの設定は &man.ipfw.8; ユーティリティを 通じておこないます. このコマンドの構文は非常に 複雑に見えますが, 一旦その構造を理解すれば比較的単純です. このユーティリティでは今のところ四つの異なる コマンドカテゴリが 使用されています: それは追加 / 削除, 表示, フラッシュ, およびクリアです. 追加 / 削除はパケットの受け入れ, 拒絶, ログ取りをどのようにおこなうか というルールを構築するのに使用します. 表示はルールリスト (またはチェーン) と (アカウンティング用) パケットカウンタの 内容を調べるのに使用します. フラッシュはチェーンからすべてのエントリを 取り除くのに使用します. クリアは一つまたはそれ以上のアカウンティングエントリを ゼロにするのに 使用します. IPFW ルールの変更 この形式での使用法は: ipfw -N コマンド index アクション log プロトコル アドレス オプション この形式で使用する際に有効なフラグは一つだけです: -N アドレスやサービス名を 文字列に変換して表示します. コマンド は一意である限り短縮可能です. 有効な コマンド は: add ファイアウォール / アカウンティングルールリストに エントリを追加します. delete ファイアウォール / アカウンティングルールリストから エントリを削除します. 以前のバージョンの IPFW では, ファイアウォールエントリと パケットアカウンティングエントリが別々に利用されていました. 現在のバージョンでは, それぞれのファイアウォールエントリ毎に パケットアカウンティングエントリが備えられています. index が指定されていると, エントリはチェーン中の index で示される位置に置かれます. index が指定されて いなければ, エントリは (65535 番のデフォルトルールである パケット拒絶を別にして) 最後のチェーンエントリの index に 100 を足した 位置 (チェーンの最後) に置かれます. カーネルが IPFIREWALL_VERBOSE つきでコンパイルされている場合, log オプションはマッチしたルールを システムコンソールに出力させます. 有効な アクション は: reject パケットを捨てます, ICMP ホスト / ポート到達不能パケットを (適切な方を) 発信元へ送ります. allow 通常通りパケットを通過させます. (別名: pass および accept) deny パケットを捨てます. 発信元は ICMP メッセージによる 通知を受けません (そのためパケットが 宛先に到達しなかったように見えます). count このルールはパケットカウンタを更新するだけで, パケットを 通過させたり拒絶したりしません. 検索は次のチェーンエントリから続けられます. それぞれの アクション は一意な先頭部分だけでも認識されます. 指定可能な プロトコル は以下の通り: all 任意の IP パケットにマッチします. icmp ICMP パケットにマッチします. tcp TCP パケットにマッチします. udp UDP パケットにマッチします. アドレス の指定は: from address/mask port to address/mask port via interface port はポートをサポートする プロトコル (UDP と TCP) の 場合にだけ指定可能です. は必須ではなく, 特定のインタフェースを通ってきたパケット だけにマッチするように, IP アドレスまたはローカル IP インタフェースの ドメイン名, またはインタフェース名 (たとえば ed0) を 指定することができます. インタフェースユニット番号はオプションで, ワイルドカードで指定することが できます. たとえば, ppp* はすべてのカーネル PPP インタフェースに マッチします. address/mask の指定は: address または address/mask-bits または address:mask-pattern IP アドレスのかわりに有効なホスト名を指定することも可能です. はアドレスマスクで上位何ビットを１にするべきかを 示す十進数値です. たとえば次の指定, 192.216.222.1/24 はクラス C のサブネット (この場合 192.216.222) の任意のアドレスにマッチする マスクを作成します. は与えられたアドレスと 論理 AND される IP アドレスです. キーワード any は任意の IP アドレスを指定するために 使用することができます. ブロックするポート番号は以下のように指定します: port, port, port… のように単独のポートまたはポートのリストを指定します. または port- port のようにポートの範囲を指定します. 単独のポートとポートのリストを 組み合わせて指定することも可能ですが, その場合は常に範囲の方を 最初に指定しなければなりません. 使用可能な オプション は: frag データグラムの最初の フラグメントでなければマッチします. in 入力途中のパケットであればマッチします. out 出力途中のパケットであればマッチします. ipoptions spec IP ヘッダが spec に指定された カンマで区切られた オプションのリストを含んでいればマッチします. サポートされている IP オプションのリストは: ssrr (ストリクトソースルート), lsrr (ルーズソースルート), rr (レコードパケットルート), そして ts (タイムスタンプ) です. 特定のオプションを含まないことを指定するには ! を先頭につけます. established パケットが既に確立されている TCP コネクションの一部であれば (つまり RST または ACK ビットがセットされていれば) マッチします. established ルールをチェーンの最初の方に置くことで, ファイアウォールのパフォーマンスを向上させることが できます. setup パケットが TCP コネクションを確立しようとするものであれば (SYN ビットがセットされ ACK ビットはセットされていなければ) マッチします. tcpflags flags TCP ヘッダが flags に指定された カンマで区切られたフラグの リストを含んでいればマッチします. サポートされているフラグは, fin, syn, rst, psh, ack と urg です. 特定のフラグを含まないことを指定するには ! を先頭につけます. icmptypes types ICMP タイプが types リストに 存在していればマッチします. リストはタイプの範囲または個々のタイプを カンマで区切った任意の組合せで指定できます. 一般的に使用されている ICMP タイプは: 0 エコーリプライ (ping リプライ), 3 相手先到達不可能, 5 リダイレクト, 8 エコーリクエスト (ping リクエスト), そして 11 時間超過 (&man.traceroute.8; で使用されているように, TTL 満了を示すのに使用されます) です. IPFW ルールリストの表示 この形式での使用法は: ipfw -a -t -N l この形式で使用する際に有効なフラグは三つあります: -a リスト表示の際にカウンタの値も表示します. このオプションは アカウンティングカウンタの 内容を見る唯一の手段です. -t 各チェーンエントリが最後に マッチした時刻を表示します. この時刻表示は &man.ipfw.8; ユーティリティで使用される入力形式と 互換性がありません. -N (可能であれば) アドレスやサービス名を文字列に変換して表示します. IPFW ルールのフラッシュ チェーンをフラッシュするには: ipfw flush カーネルに固定されているデフォルトルール (インデックス 65535 番) 以外の, ファイアウォールチェーンの中のすべてのエントリを削除します. デフォルトではすべてのパケットが拒絶されるので, 一旦これを実行すると, パケットを許可するエントリがチェーンに追加されるまで, あなたのシステムがネットワークから切り放されてしまいます. そのため, ルールのフラッシュをおこなうときは注意が必要です. IPFW パケットカウンタのクリア 一つまたはそれ以上のパケットカウンタをクリアするためには: ipfw zero index index が指定されていなければ, すべてのパケットカウンタが クリアされます. index が指定されていれば, 特定のチェーンエントリだけが クリアされます. ipfw に対するコマンドの例 このコマンドは, ホスト evil.crackers.org から ホスト nice.people.org の telnet ポートへの すべてのパケットを拒絶します: &prompt.root; ipfw add deny tcp from evil.crackers.org to nice.people.org 23 次の例は, ネットワーク crackers.org (クラス C) 全体から マシン nice.people.org (の任意のポート) への 任意の TCP トラフィックを拒絶し, ログを取ります. &prompt.root; ipfw add deny log tcp from evil.crackers.org/24 to nice.people.org あなたの内部ネットワーク (クラス C のサブネット) に対する X セッションを 張れないようにする場合, 以下のコマンドで必要なフィルタリングがおこなえます: &prompt.root; ipfw add deny tcp from any to my.org/28 6000 setup アカウンティングレコードを見るには: &prompt.root; ipfw -a list または短縮形式で &prompt.root; ipfw -a l 最後にチェーンエントリがマッチした 時刻を見ることもできます. &prompt.root; ipfw -at l パケットフィルタリングファイアウォールの構築 以下の提案は, ただの提案にすぎません: 必要な処理はそれぞれのファイアウォールで異なるため, あなた独自の要求にあったファイアウォールを構築する方法を ここで述べることはできないのです. 最初にファイアウォールをセットアップするとき, コントロールされた環境でファイアウォールホストの 設定がおこなえるような テストベンチセットアップが用意できない場合には, カーネルのログ取りを 有効にしてログ取り版のコマンドを使用することを 強くおすすめします. そうすることで, 大した混乱や中断なしに問題となる範囲の特定と処置を 素早くおこなうことができます. 初期セットアップフェーズが完了してからであっても, アタックの可能性のあるアクセスをトレースしたり, 要求の変化に応じてファイアウォールルールを 変更したりできるので, `deny' に対するログ取りをおこなうことをおすすめします. accept コマンドのログ取りをおこなっていると, ファイアウォールをパケットが一つ通過する毎に 1 行のログが生成されるため 大量の ログデータが発生します. そのため, 大規模な ftp/http 転送などをおこなうと, システムが非常に 遅くなってしまいます. また, パケットが通過するまでにカーネルにより 多くの仕事を要求するため, パケットのレイテンシ (latency) を増加させてしまいます. syslogd もログをディスクに記録するなど, より多くの CPU タイムを 使用し始め, 実に容易に /var/log が置かれているパーティションを パンクさせてしまう可能性があります. ファイアウォールは, /etc/rc.conf.local か, もしくは /etc/rc.conf によって有効化されるべきです. 関連マニュアルページには, どのドアノブ(訳注: ポートや IP アドレスなど, ネットワークからの入口を示すもののこと)に手をつければ良いのかに ついての説明と, ファイアウォール設定の既定値のリストがあります. もし, 設定の既定値を使わない場合には, ipfw list とすることで, 現在のルールセットを rc.conf から読み込める形で ファイルに出力することができます. また, /etc/rc.conf.local や /etc/rc.conf によってファイアウォールを 有効化しない場合には, ファイアウォールの有効化がすべての IP インタフェイス設定より先に行なわれるように確認することが重要です. 次の問題は, ファイアウォールが実際には何を する べきかです ! これは外部からそのネットワークへのどんなアクセスを許したいか, また内部から外界へのアクセスを どのくらい許したいかに大きく依存します. いくつか一般的なルールを挙げると: 1024 番以下のポートへのすべての TCP 入力アクセスをブロックします. ここは finger, SMTP (mail) そして telnet など, 最もセキュリティに敏感な サービスが存在する場所だからです. すべての 入力 UDP トラフィックをブロックします. これは UDP を使用しているサービスで有用なものは極めて少ないうえ, 有用なトラフィック (たとえば Sun の RPC と NFS プロトコル) は, 通常セキュリティに対する脅威となるためです. UDP はコネクションレスプロトコルであるため, 入力 UDP トラフィックを拒絶することは すなわち出力 UDP トラフィックに対する返答をも ブロックすることになるので, このことはそれなりの不利益をもたらします. たとえば外部の archie (prospero) サーバを使用している (内部の) ユーザに とって問題となる可能性があります. もし archie へのアクセスを許したければ, 191 番と 1525 番のポートから 任意の UDP ポートへ来るパケットがファイアウォールを通過することを 許可しなければなりません. 123 番のポートから来るパケットは ntp パケットで, これも通過の許可を考慮する必要がある もう一つのサービスです. 外部から 6000 番のポートへのトラフィックをブロックします. 6000 番のポートは X11 サーバへのアクセスに使用されるポートで, セキュリティに対する脅威となりえます. (特に自分のワークステーションで xhost + をおこなう癖を持っている人がいればなおさらです). X11 は実際に 6000 番以降のポートを使用する可能性があるため, 通過許可に 上限を定めると, そのマシンで走らせることのできる X ディスプレイの 個数が制限されます. RFC 1700 (Assigned Numbers) で定義されているように, 上限は 6063 です. 内部のサーバ (たとえば SQL サーバなど) がどのポートを使用するかを チェックします. それらのポートは通常, 上で指定した 1-1024 番の範囲から外れていますので, これらも同様にブロックしておくことは おそらく良い考えです. これとは別のファイアウォール設定に 関するチェックリストが CERT から 入手可能です. http://www.cert.org/tech_tips/packet_filtering.html 前にも述べたように, これはただの ガイドライン にすぎません. ファイアウォールでどのようなフィルタルールを使用するかは, あなた自身が 決めなければなりません. これまでのアドバイスにしたがったにも関わらず, 誰かがあなたのネットワークに 侵入してきたとしても, わたしたちは「いかなる」責任もとることはできません. OpenSSL FreeBSD 4.0 では, OpenSSL ツールキットが基本構成の一部に 含まれています. OpenSSL は, Secure Sockets Layer v2/v3 (SSLv2/SSLv3) や Transport Layer Security v1 (TLSv1) ネットワークセキュリティプロトコルと同様の 多目的な暗号化ライブラリを提供します. しかしながら, OpenSSL に含まれるアルゴリズムのひとつ (特に IDEA) は, 合衆国内, その他の地域において, 特許により保護されています. そのため, 無制約な利用は許されません. IDEA は FreeBSD の OpenSSL 配布に含まれていますが, デフォルトではコンパ イルされません. もし IDEA を使いたいなら, そしてあなたがそのライ センス条項に合致するなら, /etc/make.conf の中の MAKE_IDEA スイッ チを有効にして, 'make world' でソースをリビルドしてください. 現在は RSA アルゴリズムはアメリカとその他の国で自由に利用で きます. 以前は特許により保護されていました. ソースコードのインストール OpenSSL は src-crypto と src-secure cvsup コレクションの一部です. FreeBSD のソースコードの取得と更新の詳細は, FreeBSD の入手の項を参照して下さい. IPsec 原作: &a.shin;, 5 March 2000. 訳: &a.jp.hino;, 14 March 2001. IPsec 機構は, IP 層とソケット層の両方に対して安全な通 信を提供します. 実装の詳細に関しては The Developers' Handbook を参照してください. 現在の IPsec の実装は, トランスポートモードとトンネルモード の両方をサポートしています. しかし, トンネルモードにはいくつかの 制限事項があります. http://www.kame.net/newsletter/ にはより総合的な例が載っています. ここで述べる機能を利用するには, 以下のオプションをカーネルコ ンパイル時に指定する必要があることにご注意ください. options IPSEC #IP security options IPSEC_ESP #IP security (crypto; define w/IPSEC) IPv4 におけるトランスポートモードの例 ホスト A (10.2.3.4) とホスト B (10.6.7.8) との間に安全なチャ ネルを配置するために, セキュリティアソシエーションを設定しましょ う. ここでは, 少し込み入った例を示します. ホスト A からホストB へは old AH のみを使います. ホスト B からホスト A へは new AH と new ESP を組み合わせます. ここで "AH"/"new AH"/"ESP"/"new ESP" に対応するアルゴリズ ムを決めないといけません. アルゴリズムの名前を知るには, &man.setkey.8; マニュアルページをご覧ください. ここでは, AH に MD5 を, new AH には new-HMAC-SHA1 を, new ESP には 8 バイト IV の new-DES-expIV を選びました. 鍵長はそれぞれのアルゴリズムに大きく依存します. たとえば, MD5 では鍵長は 16 バイトでなければなりませんし, new-HMAC-SHA1 では 20 バイトでなければなりませんし, new-DES-expIV では 8 バ イトでなければなりません. ここではそれぞれ "MYSECRETMYSECRET", "KAMEKAMEKAMEKAMEKAME", "PASSWORD", とします. 次に, それぞれのプロトコルに対して SPI (セキュリティパラメー タインデックス: Security Parameter Index) を割り当てます. 三種 類のセキュリティヘッダ (ホスト A からホスト B に一つ, ホスト B から ホスト A に二つ) を生成するので, この安全なチャネルには三 つの SPI が必要になることに注意してください. さらに, SPI は 256 以上である必要があることにも注意してください. ここではそれ ぞれ 1000, 2000, 3000 を割り当てます. (1) ホスト A ------> ホスト B (1)PROTO=AH ALG=MD5(RFC1826) KEY=MYSECRETMYSECRET SPI=1000 (2.1) ホスト A <------ ホスト B <------ (2.2) (2.1) PROTO=AH ALG=new-HMAC-SHA1(new AH) KEY=KAMEKAMEKAMEKAMEKAME SPI=2000 (2.2) PROTO=ESP ALG=new-DES-expIV(new ESP) IV length = 8 KEY=PASSWORD SPI=3000 次に, セキュリティアソシエーションを設定しましょう. ホスト A とホスト B の両方で, &man.setkey.8; を実行します: &prompt.root; setkey -c add 10.2.3.4 10.6.7.8 ah-old 1000 -m transport -A keyed-md5 "MYSECRETMYSECRET" ; add 10.6.7.8 10.2.3.4 ah 2000 -m transport -A hmac-sha1 "KAMEKAMEKAMEKAMEKAME" ; add 10.6.7.8 10.2.3.4 esp 3000 -m transport -E des-cbc "PASSWORD" ; ^D 実際には, セキュリティポリシのエントリが定義されるまでは IPsec による通信は行われません. この例の場合, 両方のホストを設 定する必要があります. A で: &prompt.root; setkey -c spdadd 10.2.3.4 10.6.7.8 any -P out ipsec ah/transport/10.2.3.4-10.6.7.8/require ; ^D B で: &prompt.root; setkey -c spdadd 10.6.7.8 10.2.3.4 any -P out ipsec esp/transport/10.6.7.8-10.2.3.4/require ; spdadd 10.6.7.8 10.2.3.4 any -P out ipsec ah/transport/10.6.7.8-10.2.3.4/require ; ^D ホスト A -------------------------------------> ホスト B 10.2.3.4 10.6.7.8 | | ========== old AH keyed-md5 ==========> <========= new AH hmac-sha1 =========== <========= new ESP des-cbc ============ IPv6 におけるトランスポートモードの例 IPv6 を使ったもう一つの例. ホスト-A とホスト-B 間の TCP ポート番号 110 番の通信には, ESP トランスポートモードが推奨されます. ============ ESP ============ | | ホスト-A ホスト-B fec0::10 -------------------- fec0::11 暗号化アルゴリズムは blowfish-cbc で, その鍵は "kamekame", 認証アルゴリズムは hmac-sha1 で, その鍵は "this is the test key" とします. ホスト-A の設定: &prompt.root; setkey -c <<EOF spdadd fec0::10[any] fec0::11[110] tcp -P out ipsec esp/transport/fec0::10-fec0::11/use ; spdadd fec0::11[110] fec0::10[any] tcp -P in ipsec esp/transport/fec0::11-fec0::10/use ; add fec0::10 fec0::11 esp 0x10001 -m transport -E blowfish-cbc "kamekame" -A hmac-sha1 "this is the test key" ; add fec0::11 fec0::10 esp 0x10002 -m transport -E blowfish-cbc "kamekame" -A hmac-sha1 "this is the test key" ; EOF そしてホスト-B の設定: &prompt.root; setkey -c <<EOF spdadd fec0::11[110] fec0::10[any] tcp -P out ipsec esp/transport/fec0::11-fec0::10/use ; spdadd fec0::10[any] fec0::11[110] tcp -P in ipsec esp/transport/fec0::10-fec0::11/use ; add fec0::10 fec0::11 esp 0x10001 -m transport -E blowfish-cbc "kamekame" -A hmac-sha1 "this is the test key" ; add fec0::11 fec0::10 esp 0x10002 -m transport -E blowfish-cbc "kamekame" -A hmac-sha1 "this is the test key" ; EOF SP の方向に注意してください. IPv4 におけるトンネルモードの例 二台のセキュリティゲートウェイ間のトンネルモード セキュリティプロトコルは old AH トンネルモード, すなわち RFC1826 で指定されるものです. 認証アルゴリズムは "this is the test" を鍵とする keyed-md5 です. ======= AH ======= | | ネットワーク-A ゲートウェイ-A ゲートウェイ-B ネットワーク-B 10.0.1.0/24 ---- 172.16.0.1 ----- 172.16.0.2 ---- 10.0.2.0/24 ゲートウェイ-A における設定: &prompt.root; setkey -c <<EOF spdadd 10.0.1.0/24 10.0.2.0/24 any -P out ipsec ah/tunnel/172.16.0.1-172.16.0.2/require ; spdadd 10.0.2.0/24 10.0.1.0/24 any -P in ipsec ah/tunnel/172.16.0.2-172.16.0.1/require ; add 172.16.0.1 172.16.0.2 ah-old 0x10003 -m any -A keyed-md5 "this is the test" ; add 172.16.0.2 172.16.0.1 ah-old 0x10004 -m any -A keyed-md5 "this is the test" ; EOF 上記の例のように, もしポート番号フィールドを書かないと, "[any]" と同じ意味になります. `-m' は使用される SA のモードを 指定します. "-m any" はセキュリティプロトコルのモードのワイル ドカードを意味します. この SA をトンネルモードとトランスポート モードの両方で使用できます. そしてゲートウェイ-B では: &prompt.root; setkey -c <<EOF spdadd 10.0.2.0/24 10.0.1.0/24 any -P out ipsec ah/tunnel/172.16.0.2-172.16.0.1/require ; spdadd 10.0.1.0/24 10.0.2.0/24 any -P in ipsec ah/tunnel/172.16.0.1-172.16.0.2/require ; add 172.16.0.1 172.16.0.2 ah-old 0x10003 -m any -A keyed-md5 "this is the test" ; add 172.16.0.2 172.16.0.1 ah-old 0x10004 -m any -A keyed-md5 "this is the test" ; EOF 二台のセキュリティゲートウェイ間の SA の束を作ります ゲートウェイ-A とゲートウェイ-B の間では, AH トランスポー トモードと ESP トンネルモードが要求されます. この例では, ESP ト ンネルモードが先に適用され, 次に AH トランスポートモードが適用さ れます. ========== AH ========= | ======= ESP ===== | | | | | ネットワーク-A ゲートウェイ-A ゲートウェイ-B ネットワーク-B fec0:0:0:1::/64 --- fec0:0:0:1::1 ---- fec0:0:0:2::1 --- fec0:0:0:2::/64 IPv6 におけるトンネルモードの例 暗号化アルゴリズムは 3des-cbc, ESP の認証アルゴリズムは hmac-sha1 とします. AH の認証アルゴリズムは hmac-md5 とします. ゲートウェイ-A での設定は: &prompt.root; setkey -c <<EOF spdadd fec0:0:0:1::/64 fec0:0:0:2::/64 any -P out ipsec esp/tunnel/fec0:0:0:1::1-fec0:0:0:2::1/require ah/transport/fec0:0:0:1::1-fec0:0:0:2::1/require ; spdadd fec0:0:0:2::/64 fec0:0:0:1::/64 any -P in ipsec esp/tunnel/fec0:0:0:2::1-fec0:0:0:1::1/require ah/transport/fec0:0:0:2::1-fec0:0:0:1::1/require ; add fec0:0:0:1::1 fec0:0:0:2::1 esp 0x10001 -m tunnel -E 3des-cbc "kamekame12341234kame1234" -A hmac-sha1 "this is the test key" ; add fec0:0:0:1::1 fec0:0:0:2::1 ah 0x10001 -m transport -A hmac-md5 "this is the test" ; add fec0:0:0:2::1 fec0:0:0:1::1 esp 0x10001 -m tunnel -E 3des-cbc "kamekame12341234kame1234" -A hmac-sha1 "this is the test key" ; add fec0:0:0:2::1 fec0:0:0:1::1 ah 0x10001 -m transport -A hmac-md5 "this is the test" ; EOF 異なる通信端での SA を作る ホスト-A とゲートウェイ-A の間では ESP トンネルモードが要 求されています. 暗号化アルゴリズムは cast128-cbc で, ESP の認 証アルゴリズムは hmac-sha1 です. ホスト-A とホスト-B との間で は ESP トランスポートモードが推奨されています. 暗号化アルゴリ ズムは rc5-cbc で, ESP の認証アルゴリズムは hmac-md5 です. ================== ESP ================= | ======= ESP ======= | | | | | ホスト-A ゲートウェイ-A ホスト-B fec0:0:0:1::1 ---- fec0:0:0:2::1 ---- fec0:0:0:2::2 ホスト-A での設定: &prompt.root; setkey -c <<EOF spdadd fec0:0:0:1::1[any] fec0:0:0:2::2[80] tcp -P out ipsec esp/transport/fec0:0:0:1::1-fec0:0:0:2::2/use esp/tunnel/fec0:0:0:1::1-fec0:0:0:2::1/require ; spdadd fec0:0:0:2::1[80] fec0:0:0:1::1[any] tcp -P in ipsec esp/transport/fec0:0:0:2::2-fec0:0:0:l::1/use esp/tunnel/fec0:0:0:2::1-fec0:0:0:1::1/require ; add fec0:0:0:1::1 fec0:0:0:2::2 esp 0x10001 -m transport -E cast128-cbc "12341234" -A hmac-sha1 "this is the test key" ; add fec0:0:0:1::1 fec0:0:0:2::1 esp 0x10002 -E rc5-cbc "kamekame" -A hmac-md5 "this is the test" ; add fec0:0:0:2::2 fec0:0:0:1::1 esp 0x10003 -m transport -E cast128-cbc "12341234" -A hmac-sha1 "this is the test key" ; add fec0:0:0:2::1 fec0:0:0:1::1 esp 0x10004 -E rc5-cbc "kamekame" -A hmac-md5 "this is the test" ; EOF OpenSSH 原作: &a.chern;, 2001 年 4 月 21 日. セキュアシェル (secure shell) はリモートマシンへのセキュアなアクセスに使われる ネットワーク接続ツールのセットです. それは rlogin, rsh, rcp, telnet を直接置き換えて使うことができます. また, 他のあらゆる TCP/IP 接続を ssh 経由でセキュアにトンネル/フォワードすることもできます. ssh はすべてのトラフィックを暗号化し, 盗聴や接続の乗っ取り等のネットワークレベルの攻撃を事実上無効化します. OpenSSH は OpenBSD プロジェクトによって維持管理されており, SSH v1.2.12 に最新のすべてのバグ修正と更新を適用したものをベースにしています. OpenSSH クライアントは SSH プロトコル 1 と 2 の両方に互換性があります. OpenSSH は FreeBSD 4.0 以降ベースシステムに取り込まれています. OpenSSH を使うことの利点 &man.telnet.1; や &man.rlogin.1; を使う場合, 一般にデータはネットワークを平文で流れます. ネットワークをクライアントとサーバの間のどこかで盗聴することで あなたのユーザ/パスワード情報やセション中を流れるデータを盗むことが可能です. OpenSSH はこれらを予防する為にさまざまな認証と暗号化の方法を提供します. sshd を有効にする rc.conf ファイルに 以下の行を追加してください. sshd_enable="YES" 次に起動したときから ssh デーモンが起動します. もしくは単に sshd デーモンを実行しても構いません. SSH クライアント &man.ssh.1; ユーティリティは &man.rlogin.1; と同様に働きます. &prompt.root ssh user@foobardomain.com Host key not found from the list of known hosts. Are you sure you want to continue connecting (yes/no)? yes Host 'foobardomain.com' added to the list of known hosts. user@foobardomain.com's password: ******* ログインは rlogin や telnet でセションを張った時と同様に続きます. SSH はクライアントが接続した時, サーバの信頼性の検証のために鍵指紋システム (key fingerprint system) を利用します. 初めての接続の際にのみ, ユーザは 'yes' と入力することを要求されます. これ以降の login では保存されていた鍵指紋を照合することで検証されます. SSH クライアントは保存されていた鍵指紋が login しようとした際に送られてきたものと異なっていた場合には警告を表示します. 指紋は ~/.ssh/known_hosts に保存されます. Secure copy scp コマンドが rcp と異なるのは, セキュアになっているという点だけです. つまりローカルのファイルをリモートマシンへ, あるいはリモートマシンのファイルをローカルにコピーします. &prompt.root scp user@foobardomain.com:/COPYRIGHT COPYRIGHT user@foobardomain.com's password: COPYRIGHT 100% |*****************************| 4735 00:00 &prompt.root 前回の例でこのホストの指紋がすでに保存されていれば この scp を使う時に検証が行なわれます. 設定 システム全体の設定ファイルは, OpenSSH デーモン, クライアントの両方とも /etc/ssh ディレクトリにあります. ssh_config はクライアントの動作設定, sshd_config はデーモンの動作設定を行ないます. ssh-keygen パスワードの代わりに &man.ssh-keygen.1; を使って ユーザの認証用の RSA 暗号鍵を作ることができます. &prompt.user ssh-keygen Initializing random number generator... Generating p: .++ (distance 66) Generating q: ..............................++ (distance 498) Computing the keys... Key generation complete. Enter file in which to save the key (/home/user/.ssh/identity): Enter passphrase: Enter the same passphrase again: Your identification has been saved in /home/user/.ssh/identity. ... &man.ssh-keygen.1; は認証に使う為の公開鍵と秘密鍵のペアを作ります. 秘密鍵は ~/.ssh/identity に保存され, 公開鍵は ~/.ssh/identity.pub に保存されます. 公開鍵はリモートマシンの ~/.ssh/authorized_keys にも置かなければなりません. これでパスワードの代わり RSA 認証を使って リモートマシンに接続できるようになったはずです. &man.ssh-keygen.1; でパスフレーズを使っている場合は, ユーザは秘密鍵を使うために毎回パスフレーズの入力を行なう必要があります. &man.ssh-agent.1; と &man.ssh-add.1; は 多重にパスワード化された秘密鍵の管理に使われます. SSH トンネリング OpenSSH は暗号化されたセションの中に他のプロトコルを カプセル化することでトンネルを作ることができます. 以下のコマンドは &man.ssh.1; で telnet 用のトンネルを作成します. &prompt.user; ssh -2 -N -f -L 5023:localhost:23 user@foo.bar.com &prompt.user; -2 は &man.ssh.1; にプロトコル 2 を使うことを指示します. (古い ssh サーバを使っているときには指定しないでください) -N はトンネルだけでコマンドはないことを示します. 省略されると &man.ssh.1; は通常のセッションを開始します. -f は &man.ssh.1; にバックグラウンド実行を強制します. -L はローカルトンネルとして localport:localhost:remoteport 形式を指示します. foo.bar.com はリモート/ターゲットの SSH サーバです. SSH のトンネルは指定されたローカルホストとポートを listen する ソケットを作ることで実現されています. SSH はローカルのホスト/ポートへのすべての接続を SSH 接続経由でリモートマシンの指定されたリモートポートへ 転送 (フォワード) します. たとえば, ローカルホストのポート 5023 がリモートマシンの 23 に転送されるようになっているとします. 23 は telnet なのでこれは SSH トンネルを通るセキュアな telnet セッションを作ります. このようにして smtp や pop3, ftp 等のセキュアではない TCP プロトコルをカプセル化することができます. 典型的な SSH トンネル &prompt.user; ssh -2 -N -f -L 5025:localhost:25 user@mailserver.foobar.com user@mailserver.foobar.com's password: ***** &prompt.user; telnet localhost 5025 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 mailserver.foobar.com ESMTP &man.ssh-keygen.1; と別のユーザアカウントを組み合わせて使うことで より透過的で悩まずに済むような SSH のトンネル環境を作ることができます. パスワードを入力するところで暗号鍵を使い, トンネルは別のユーザ権限で実行することが可能です. さらに知りたい人へ OpenSSH &man.ssh.1; &man.scp.1; &man.ssh-keygen.1; &man.ssh-agent.1; &man.ssh-add.1; &man.sshd.8; &man.sftp-server.8; diff --git a/ja_JP.eucJP/books/handbook/serialcomms/chapter.sgml b/ja_JP.eucJP/books/handbook/serialcomms/chapter.sgml index 97c79ea3f8..d4eaddae56 100644 --- a/ja_JP.eucJP/books/handbook/serialcomms/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/serialcomms/chapter.sgml @@ -1,3159 +1,3159 @@ シリアル通信 この章では シリアル通信 Unix は現在に至るまで、常にシリアル通信機能をサポートしていました。 実際、本当に初期の Unix マシンは、ユーザとの入出力にシリアル通信を使っていました。 10 文字毎秒のシリアルプリンタ、 キーボードから構成された 端末(terminal) が広く使われていた当時とは、 何もかもがすっかり変わっています。この章では、FreeBSD でシリアル通信を行なういくつかの方法について説明しています。 シリアル接続の基礎 Assembled from FAQ. このセクションには、 シリアルポートについての一般的な情報が書かれていま す。 あなたが求めている情報が、もしここで見つからなかった場合には、 ハン ドブックの端末とダイアルアップのセクションを見てください。 ttyd cuaa ttydX (または cuaaX) デバイスは、アプリケーション上 でシリアルポートをオープンする時に使用する、 標準的なデバイスです。プロセスがデバイスをオープンする際、端末 I/O 設定の デフォルトセットが使用されます。これらの設定内容は、 次のコマンドで確認することができます。 &prompt.root; stty -a -f /dev/ttyd1 このデバイスの設定を変更した場合、その設定はデバイスが クローズされるまで有効です。デバイスが再びオープンされる時、 デフォルトの設定値に戻ります。 デフォルトの設定を変更するためには、 初期状態 を設定した いデバイスをオープンして調節することができます。例えば、ttyd5 というデバイスに対して、デフォルトで CLOCAL モードを ON にして、8 bits の設定をおこない、 XON/XOFF フロー制御を行うように設定したい場合は、次のようにします。 &prompt.root; stty -f /dev/ttyid5 clocal cs8 ixon ixoff rc ファイル rc.serial このコマンドを記述するのに適しているファイルは、 /etc/rc.serial です。 アプリケーションがttyd5 をオープンするときに、 デフォルトでこの設定をおこなうようになります。これらの設定は、 好きなように変更することができます。 また、固定状態 のデバイスに調節を行うことで、 ある一定の設定が アプリケーションに変更されることを防ぐこともできます。例えば、 ttyd5 のスピードを 57600 bps に固定したい場合には、次のようにします。 &prompt.root; stty -f /dev/ttyld5 57600 これで、ttyd5 をオープンして、 シリアルポートの転送スピードを 変更しようとするアプリケーションは 57600 bps に固定されるでしょう。 MAKEDEV 本来、デバイスの初期状態を変更したり設定を固定するのは、 root だけが行うべきです。 MAKEDEV スクリプトがデバイスエントリを作成する時は、 これをおこないません。 シリアル端末 端末 原作: Sean Kelly kelly@ad1440.net 28 July 1996 訳: &a.max; シリアル端末を利用することで、 コンピュータのコンソールのそばにいないと きや、 手近にネットワーク接続されているコンピュータがないときでも、 FreeBSD の機能を便利に、かつ安価に利用することができます。 ここでは、FreeBSD にシリアル端末を接続する方法を解説します。 端末の種類と利用方法 もともと Unix システムにはコンソールがありませんでした。 ユー ザはコンピュータのシリアル ポートに接続された端末からログインして プログラムを利用していました。 ちょうどモデムと通信ソフトを使ってリモート のコンピュータにログインし、テキスト ベースのプログラムを利用するのと よく似ています。 最近の PC は、 高品質の画像を表示できるコンソールを搭載していま すが、 ほとんどすべての Unix 系 OS には未だにシリアル ポートを使ってログ インするための機能があり、FreeBSD でもこの機能がサポートされています。 現在使用されていないシリアル ポートに端末を接続することでシステムに ログインし、 通常はコンソールや Xウィンドウ システムの xterm のウィ ンドウ上で起動しているテキスト ベースのプログラムであれば何 でも利用することができます。 職場での利用ということで考えるならば、FreeBSD が動作しているコンピュー タに接続された何台ものシリアル端末を 各社員の机に配置するというようなこ とが可能です。また、 家庭での利用方法としては、余っている古い IBM PC や Macintosh を FreeBSD が動いているパワフルなコンピュータの端末として利 用することができます。普通ならシングルユーザのコンピュータを、 パワフ ルなマルチユーザのシステムに変えることができるのです。 FreeBSD では、以下に挙げる3種類の端末が利用できます。 ダム (dumb) 端末 PCを利用した端末 X 端末 以下は、それぞれについての解説です。 ダム端末 ダム端末は、シリアルライン経由でのコンピュータとの接続専 用のハードウェアです。ダム端末は、 テキストの送受信および表示ができる 程度の計算能力しかもっていないので、dumb (間抜け) というように呼ば れています。 この端末上でプログラムを実行することはできません。テキスト エディタ、コンパイラ、E-mail、 ゲームなどなどのプログラムを実行するのは、 ダム端末を接続しているコンピュータの方です。 Digital Equipment社の VT-100 や、Wyse社の WY-75 を初めとして、多くのメーカが何百種類もの ダム端末を作っています。ほとんどどんな種 類のダム端末でも FreeBSD に接続して使用できます。さらに、高性能の端 末の中には画像を取り扱えるものもありますが、 限られた数のソフトウェア パッケージしかこういった機能には対応していません。 ダム端末は、X ウィンドウ システムで提供されるようなグラ フィックアプリケーションを必要としない 職場で広く用いられています。 PC を端末として利用する ダム端末 がテキストの表示およ び送受信の機能をそなえただけのものならば、言うまでもなく、 どんなPC もダム端末になり得ます。 必要なものは適切なケーブルと、そのPCの上 で動作する端末エミュレーション を行うソフトウェアのみです。 このような環境は、家庭においてよく利用されます。 たとえば、あなたの同居 人が FreeBSD のコンソールを専有している時などに、あまりパワーのないコ ンピュータを FreeBSD システムにシリアル端末として接続し、 その端末上で テキストだけを用いる作業をおこなうことができます。 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 connects to 3 RxD RxD 3 connects to 2 TxD DTR 20 connects to 6 DSR DSR 6 connects to 20 DTR SG 7 connects to 7 SG DCD 8 connects to 4 RTS RTS 4 5 CTS CTS 5 connects to 8 DCD DCD と RST では、コネクタ内部でピン4を5に接続し、 そして逆側のコネクタのピン8と接続します。 スタンダード RS-232C ケーブル 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/ttydx ( x は 0から始まるポート番号) となっています。一般に端末の接続には 着信用ポートを用います。着信用のポートでは、 シリアルラインのデータ キャリア検出 (DCD) 信号がオンになっている必要があります。 発信用のポートの名前は、 /dev/cuaax となっています。 発信用のポートは普通モデムの接続に用い、端末の接続には 利用しません。ただ、 ケーブルまたは端末がキャリア検出信号を使えない タイプのものの場合は、 発信用のポートを使うとよいでしょう。 詳しくは、&man.sio.4; のマニュアルをご覧ください。 たとえば、端末を一つ目のシリアルポート (DOS でいうところの COM1) に接 続したとすると、/dev/ttyd0 がこの端末を指すことになります。また、 二つ目のシリアルポート (COM2) ならば /dev/ttyd1 となり、 以下この形式のデバイスエントリを使います。 各シリアルポート、 特にマルチポートのシリアルカードを利用する ために、kernel の設定をおこなう必要がある場合がありますので、注意してくだ さい。詳しくは、FreeBSD カーネルのコンフィグレーション をご覧ください。 設定 ここでは、端末からのログインを可能にするために必要な FreeBSD 側の設定について解説します。 既に端末を接続するポートが利用できるように kernel の設定をおこない、端末が接続されているものと考えて、解説を進め ます。 簡単に言えば、プロセス管理や初期化をおこなっている init プロセス に対して、 ログイン名を読み込み login プログラムを起動している getty を実行するように指示します。 これをおこなうには、/etc/ttys の内容を編集する必要があります。まず、su コマンドで root になって、/etc/ttys に以下の 変更を加えてください。 端末を接続するポートの /dev のエントリが含ま れている行がまだ存在しなければ、これを /etc/ttys に追加してく ださい。 /usr/libexec/getty が対象となるポートに対して 実行されるように指定してください。また、 /etc/gettytab ファイ ル内の適切な getty タイプのエントリを指定してください。 デフォルトのターミナルタイプを指定してください。 対象となるポートを on に設定してください。 そのポートが secure であるかどうかを指定してください。 init に /etc/ttys を読み込みなおさせてく ださい。 また、必要に応じて /etc/gettytab を変更し、上の 2で使用する getty のエントリを追加してください。 このドキュメントではこの方 法については特に解説しませんので、&man.gettytab.5; および &man.getty.8; のマニュアルをご覧ください。 以下では、上のステップについて詳しく解説します。 実例を用いて、何をす べきかを解説していきます。Wyse-50 と、 古い IBM の 286 マシン上で通信 ソフト Procomm を使って VT-100 エミュレーションをおこなっているものを端 末の例として紹介します。また、Wyse は 2番目のポートに、 286マシンは 6 番目のポート (マルチポートのシリアルカード上のポート) に接続します。 /etc/ttys について、 より詳しくは、&man.ttys.5; のマニュアルをご覧 ください。 <filename>/etc/ttys</filename> へのエントリの追加 既にエントリがある場合を除いて、まず初めに /etc/ttys にエントリを追加しなければいけません。 /etc/ttys には、 FreeBSDシステム上のログインを許可するすべての ポートを記述します。たとえば、一つ目の仮想コンソール ttyv0 のエン トリもこのファイルにあります。このエントリのおかげで、 コンソールからの ログインが可能になっています。 このファイルには、他の仮想コンソール、シ リアルポートおよび仮想端末のエントリも含まれています。 端末を接続する 場合は、そのポートの /dev のエントリを、 /dev の部分 を省略して記述します。 FreeBSD のインストール当初の状態では、 ttyd0 から ttyd3 までの、初めの四つのシリアルポートのエントリが /etc/ttys に記述され ています。 これらのポートのいずれかに端末を接続する場合は、新たなエント リを追加する必要はありません。 ここで紹介している例では、 既にファイルにエントリが存在する 2番目のシリ アルポート、 ttyd1 に Wyse-50 を接続しています。 一方、6番目のシ リアルポートに接続する 286マシン用のエントリは、新たに追加してやらな ければなりません。以下に、エントリを追加した後の /etc/ttys か ら抜粋して示します。 ttyd1 "/usr/libexec/getty std.9600" unknown off secure ttyd5 <replaceable>getty</replaceable> タイプの指定 次に、 端末からのログインを処理するプログラムの指定をおこな います。 FreeBSDでは、標準的には /usr/libexec/getty をこの目的 で利用しています。login: プロンプトを送り出しているのは、このプロ グラムです。 getty プログラムは、 コマンドラインパラメータとして、 getty タイプをとります。ただし、 このパラメータは必須ではあ りません。 getty タイプは、 ボーレートやパリティといった、接続され た端末の特徴を表すものです。getty プログラムは、与えられた getty タイプに対応したこれらの特徴を /etc/gettytab から 読み込みます。 ファイル /etc/gettytab には、 新旧の端末に関する多数のエントリ が記述されています。 ほとんどの場合、std という文字列で始まる名前 のエントリを使えば、 接続された端末に対してログインセッションを提供す ることができます。これらのエントリを利用した場合、 パリティは無視されま す。110 bps から 115200 bps までのボーレートに対応した std のエン トリがあります。当然、 新たなエントリを追加することも可能です。 &man.gettytab.5; のマニュアルに、 さらに詳しく解説されています。 /etc/ttys の getty タイプの設定をする際は、 端末側の通信 パラメータの設定が、getty タイプのものと一致していることを確認し てください。 紹介している実例では、Wyse50 はパリティなし 38400 bps で接続していま す。また、286 マシンの方は、パリティなし 19200 bps の接続です。以下は、 この段階でのこの二つの端末に関する /etc/ttys の設定です。 ttyd1 "/usr/libexec/getty std.38400" unknown off secure ttyd5 "/usr/libexec/getty std.19200" ここで、実行するプログラムを指定している 2番目のフィールドが、ダブルクォー テーションに囲まれていることに注意してください。 こうしないと、getty のタイプの指定が、 つぎのフィールドとして判断されてしまう可 能性があるので、 十分注意することが必要です。 デフォルトのターミナルタイプの指定 /etc/ttys の 3番目のフィールドには、 そのポートのター ミナルタイプのデフォルトを指定します。 ダイアルアップ用のポートの場合 は、 ユーザがどのタイプの端末あるいは 通信ソフトを利用してダイアルアップ してくるかは分からないので、unknown や dialup を記述するの が一般的です。一方、 直結された端末の場合、ターミナルタイプが変わるこ とはありませんから、 このフィールドには実際のターミナルタイプを記述し ます。 一般に、ユーザは .login や .profile などのファイル内で tset コマンドを使って、 ターミナルタイプをチェックし、必要ならば ターミナルタイプの入力を求めるプロンプトを 表示するようにします。この とき、 /etc/ttys の中でターミナルタイプが指定されていれば、 このプロンプトを表示せずに先に進むことが可能です。 termcap FreeBSD 上で、どのターミナルタイプを利用できるかは、 /usr/share/misc/termcap をご覧ください。 このファイルには、お よそ 600 のターミナルタイプが定義されています。 必要ならば、新たなエン トリを追加することも可能です。詳しくは &man.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 を指定すると、 init プロセスが2番目のフィールドに書かれ たプログラム、getty を実行し、 ログインのためのプロンプトを送り出 すようになります。 このフィールドに off を記述すると、 getty は起動されず、 よってこのポートからのログインもできなくなります。 ということで、当然このフィールドには on を指定します。以下が /etc/ttys です。それぞれのポートを on にしました。 ttyd1 "/usr/libexec/getty std.38400" wy50 on secure ttyd5 "/usr/libexec/getty std.19200" vt100 on ``secure'' なポートの指定 とうとう最後のフィールドの設定です。 (実際にはここでは触れ ませんが、 オプショナルなwindow の設定のフィールドも存在するので、 ほぼ最後のフィールドといった方が正確かもしれません) 最後のフィールド では、 そのポートが安全かどうかを指定します。 ここで、安全 なポートとはどういうポートのことでしょう? これは、root のアカウント (または、ユーザ ID が 0 のアカウント) がロ グインしてもよいポートということです。 安全でないポートでは、root のロ グインは許可されません。 では、どのように安全なポートとそうでない ポートを使えばよいでしょう? ポートを安全ではないとすることで、 そのポートに接続された端末からは、root のログインを禁止することができます。FreeBSDシステムの root のパス ワードを知っている人は、 まず一般ユーザとしてログインしなければなりませ ん。 スーパユーザの特権を得るためには、そのうえで su コマンドを 利用しなければいけません。 これによって、root アカウントが不正に利用された場合に、 その経過を調査 する上で二つの記録を利用できるようになります。 login と su コマンドは、共にシステムのログに記録を残します (また、 ログイン は wtmp にも記録を残します。 )。 ポートを安全なものとして指定すると、その端末からの root のログインが可 能になります。root のパスワードを知っている人は、単に root としてログ インできます。この場合は、当然ログインの記録や su コマンドのログ は残りません。 では、どちらを使うべきでしょうか? 単純に insecure を使うのがよいでしょう。 公共の場所にある訳ではな い端末や、 鍵のかかったドアの内側にある端末にも insecure を指 定する方がよいでしょう。 スーパユーザの特権が必要な場合でも、ログイ ンして su を実行するのは、 ごく簡単なことなんですから。 以下に、ようやく完成した /etc/ttys のエントリに端末の場所を表 すコメントを追加したものを示します。 ttyd1 "/usr/libexec/getty std.38400" wy50 on insecure # Kitchen ttyd5 "/usr/libexec/getty std.19200" vt100 on insecure # Guest bathroom <command>init</command> にファイル <filename>/etc/ttys</filename> の再読み 込みをさせる FreeBSD をブートすると、最初に起動されるプロセス、 initが /etc/ttys を読み込んで、記述されているプログラムを利用可能な ポートに対して実行し、 ログインプロンプトを送り出させます。 /etc/ttys の編集が終わった後、 init に変更を認識させるた めに、わざわざ FreeBSD をブートしなおしたくはないでしょう。このような 場合のために、init は、 SIGHUP (hangup) シグナルを受信すると、 /etc/ttys を読み込みなおすようになっています。 /etc/ttys の変更を保存したら、 以下のようなコマンドを実行して、init に対して SIGHUP を送信します。 &prompt.root; kill -HUP 1 (init プロセスのプロセス ID は 常に 1です) すべての設定が正しくおこなわれ、 すべてのケーブルがただしく接続されてい て、 かつ端末の電源が入っていれば、 端末にはログインプロンプトが表示され ているはずです。これで、 これらの端末からの最初のログインの準備が完了で す! トラブルシューティング 細心の注意を払って設定をおこなっても、 ときには端末の接続がう まくいかない場合があるでしょう。以下に、 よく見られる問題とその解決方法 を示します。 ログインプロンプトが表示されない 端末の電源が接続され、 スイッチが入っていることを確認してください。もし、PC を端末として利用している場合は、 通信ソフトが適切なシリアルポー トを利用する設定になっているかどうか確かめてください。 ケーブルがしっかりと端末と FreeBSDが動作しているコンピュータの両方に接続され ていることを確認してください。また、 正しい種類のケーブルを利用している か確かめてください。 端末と FreeBSD の間の通信速度とパリティの設定が一致していることを確認 してください。 出力をモニタに表示するタイプの端末の場合は、モニタ のコントラストと明るさの設定を確認してください。また、 出力が印刷 されるタイプの端末の場合は、 紙とインクが十分にあるかどうかを確かめてく ださい。 getty が動いていて、 端末を認識していることを確認してください。以 下のコマンドで動作中の getty プロセスのリストを得ることができます。 &prompt.root; ps -axww|grep getty その端末に対する getty の情報が表示されるはずです。たとえば、以下 の表示例は、getty は 2番目のシリアルポート (ttyd1) に対し て /etc/gettytab 中の std.38400 のエントリを使って動作し ているということを示しています。 22189 d1 Is+ 0:00.03 /usr/libexec/getty std.38400 ttyd1 もし、getty プロセスが一つも動いていないようであれば、 /etc/ttys の中で、 そのポートを利用可能にする設定をしたかどう か確かめてください。また、kill -HUP 1 を確実に実行してください。 ログインプロンプトの代わりにゴミが表示される 端末と FreeBSD の間の通信速度およびパリティの設定が一致していることを確 かめてください。また、getty プロセスの情報を調べて、適切な getty のタイプが使用されていることを確認してください。間違った getty タイプが使用されている場合は、 /etc/ttys を修正し てから、 kill -HUP 1 を実行してください。 文字が重複して表示される、 入力したパスワードが表示される 端末または通信ソフトの設定で、半二重 (half duplex) あるいは ローカ ルエコー となっているところを、全二重 (full duplex) に変更してください。 ダイアルインサービス ダイアルインサービス 原作: &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 のシリアル ディバイス ドライバ (sio) は、 バージョンを追う毎に改善されてき ていますので、 より新しいバージョンの FreeBSD を使用することで、よりよ い、 より効率の高いドライバを利用することができるはずです。 用語解説 以下、簡単にいくつかの用語について解説しておきます。 bps bits-per-second Bits per Second　の略で、 データの転送速度を表す単位。 DTE DTE Data Terminal Equipment の略。 たとえばコンピュータ本体のこと。 DCE DCE Data Communications Equipment の略で、 具体的にはモデムのこと。 RS-232 RS-232 ケーブル EIA (米電気産業協会) のハードウェア間シリアル通信の標準規 格。 これらの用語やデータ通信一般に関して、 より詳しい情報が必要な場合は、The RS-232 Bible という本 (誰か ISBN 分かる方いませんか?) が参考 になると思います。 通信においてのデータ転送速度に関して、 このドキュメントでは ボーレー ト (baud rate) ではなく、bps (bits per second) をその単位として 使うことにします。これは、 ボーというのは一定時間に生じる電気的状態の変 化の数を表す単位にすぎず、bps という単位の方が実体に即しているか らです (少なくとも、 こういう表現をしておけば、意地の悪い人に怒られる こともないのではないかと思います)。 外づけモデムと内蔵モデムについて ダイアルアップのサービスに関していえば、 外づけのモデムの方が適している ようです。これは、 多くの外づけのモデムは設定を不揮発ラムに書き込んで半 永久的に保存することができますし、また RS-232 に関する重要な情報を知る ための点滅するライトによるインディケータが 搭載されているからです。点滅 するライトは、 システムを見に来た訪問者に強い印象を与えるという効果だけ でなく、モデムが適切に動作しているかどうかを知るためにも 有効です。 一方、たいていの内蔵型のモデムには 不揮発性ラムが搭載されていないため、ディップ スイッチの変更以外に設定を保存する方法がありません。また、も しインディケータがついていても、おそらくコンピュータのケース カバーが 外されていなければその状態を確認するのは 難しいでしょう。 モデムとケーブル 以下のことに関して、予め知っておく必要があります。 コンピュータとモデムの間での通信が 行えるようにするための接続方 法。 (内蔵型の場合は接続の必要はありません) お使いのモデムのコマンドについての知識、 あるいはコマンドの解説 の在処 (通信ソフトを使っての) モデムの不揮発ラムに保存可能な設定の変更 方法 1番目のモデムの接続はたいてい簡単に行えるはずです。 ほとんどのストレー ト シリアル ケーブルが使えるでしょう。 使用すべきケーブルは、両端に適 切なコネクタ (DB-25 または DB-9 の雄または雌) のついた、DCE-DTE 間接 続用のもので、 以下の信号線が接続されていなければなりません。 モデムコマンド Transmitted Data (SD) Received Data (RD) Request to Send (RTS) Clear to Send (CTS) Data Set Ready (DSR) Data Terminal Ready (DTR) Carrier Detect (CD) Signal Ground (SG) FreeBSD で 2400bps 以上の転送速度を利用する場合には、 フロー制御のため に RTS 信号と CTS 信号が必要です。また、 接続の確立と回線の切 断を検出するために CD 信号を利用します。さらに、 DTR 信号を使っ て回線切断後のモデムのリセットを行います。ケーブルの中には、 総ての必要 な信号線が接続されていないものもありますので、 たとえば、回線切断後でも ログイン セッションが残ってしまうといった問題が発生した場合などには、 ケーブルに問題がある可能性もあります。 次に、お使いのモデムにもよりますが、 もしモデムのコマンドをよく覚えてい ない場合は、 モデムのマニュアルをすぐに参照できるようにしておいてくださ い。このドキュメントでは例として USR Sportstar の 14,400 bps の外づけ型 モデムのコマンドを示しておきます。 他の種類のモデムをお使いの場合も、参 考になるかもしれません。 最後に、FreeBSDで快適にモデムを使うためにも、 モデムの設定方法を知って おく必要があります。FreeBSD も他の Unix 系 OS と同様、回線の接続およ び切断の検出や回線の切断および回線切断後の モデムの初期化にハードウェア シグナルを利用します。FreeBSD は、モデムに対するコマンドの送信やモデ ムの状態の監視を行いません。パソコンで運用されている BBS への接続に慣 れている方にとっては、 ちょっとめんどうかもしれませんね。 シリアル インタフェースについて 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 は以下の手順でモデムからのログインを受付ます。 init から起 動された getty のプロセスが、割り当てられたシリアル ポート (この 例では /dev/ttyd0) がオープンされるのを辛抱強く待ちます。ps ax コマンドを実行すると、 以下のような出力が得られるはずです。 4850 ?? I 0:00.09 /usr/libexec/getty V19200 ttyd0 ユーザがモデムに電話をかけ、モデム同士が接続されると、 モデムの CD が検出されます。その結果、 kernel がキャリア信号を検出して、getty によるポートのオープンの処理が終了します。 getty は、login: プロンプトを指定されている初期回線速度で送信します。 getty は、 正常に文字列を受信できるかどうか監視し、通常の設定では、 - もし以上な文字列を検出した場合 (理由としては、 + もし異常な文字列を検出した場合 (理由としては、 getty の速度とモデ ムの接続速度が異なっているような場合が考えられます)、 正常に文字列が 受信できるまで、getty は速度を変え続けます。 /usr/bin/login getty が正しい速度を検出すれば、 ユーザに対して login: プロン プトが表示されるはずです。ユーザがログイン名を入力すると、 getty は /usr/bin/login を起動して、 パスワードの入力を要求し、その 後ユーザのシェルを起動します。 それでは、続いて設定についての解説です。 kernel の設定 通常、FreeBSD の kernel は、MS-DOS の世界で COM1:、COM2: 、COM3: および COM4: と呼ばれる四つのシリアル ポートを 探す ように設定されています。また、FreeBSD では、現在のところ Boca の 1008 や 2016 のような、単純なマルチポートのシリアル インタフェースもサポー トしています (マルチポートのシリアル ボードに関しての kernel の設定 については、&man.sio.4; のマニュアルを参照してください)。 デフォルト の kernel は、COM ポートだけを探します。 搭載されているシリアル ポートのいずれかを、kernel が認識しているかどう か確認したい場合は、kernel 起動時のメッセージを注意深く見ているか、あ るいは /sbin/dmesg コマンドを使って、 ブート時の出力メッセージ を確認してください。特に、 sio で始まるメッセージをよく見てくださ い。 参考までに、以下のコマンドで sio という文字列を含むメッセージ だけを表示することができます。 &prompt.root; /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 に cd して作成してくださ い。初めてコンフィギュレーション ファイルを作る場合は、まず GENERICAH (FreeBSD 1.x で BusTek の SCSI コントローラを使っている場合は GENERICBT) というファイルを、 YOURSYS にコピーしてください。ここ で、 YOURSYS はあなたのシステム名で、 大文字である必要があります。このファイルを編集して、 ディバイスに関する記述を変更します。 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 のようなマルチポートの シリアル ボードをお持ちの場合は、&man.sio.4; のマニュアルを見て、マ ルチポートのボードのためのコンフィギュレーション ファイルの記述のし方 に関して確認してください。ディバイスのフラグの 指定方法がバージョンによっ て異なりますので、別のバージョンの FreeBSD で利用していたコンフィギュ レーション ファイルを流用する場合には 十分注意してください。 なお、port "IO_COM1"、 IO_COM2、IO_COM3 および IO_COM4 は、 それぞれのポートの一般的なアドレスである 0x3f8、0x2f8、 0x3e8 および 0x2e8 を表します。また、割り込 み番号 4、3、5 と 9 は、それぞれ COM1: から COM4: のポー トで一般的に使用される IRQ です。また、ISA バスのコンピュータの場合、 一般的なシリアルポートは複数のポートで一つの IRQ を共有することが できませんので注意が必要です (マルチポートのシリアル ボードの 場合は、複数の 16550A ベースのポートで一つまたは二つの IRQ を共有する ための機構を備えています)。 コンフィギュレーション ファイルの編集が終わったら、 Building Berkeley Kernels with Config (config コマンドによる BSD kernel の構築) および &man.config.8; のマニュアルにしたがって、 config コマンド を使って kernel 構築のためのディレクトリを作成した後、kernel の構築、 インストールおよびテストを行ってください。 ディバイス スペシャル ファイル kernel に組み込まれているほとんどのディバイスは、 /dev ディレ クトリにある、 ディバイス スペシャル ファイル を介してアクセスされ ます。 sio ディバイスの場合は、着信用の /dev/ttyd? およ び、発信用の /dev/cuaa? が利用されます。さらに、FreeBSD の 1.1.5 以降では、 初期化ディバイス (/dev/ttyi? と /dev/cuai0?) およびロッキング ディバイス (/dev/ttyld? と /dev/cual0?) も合わせて利用されます。初期化ディバイスは、通信 ポートがオープンされる度に、 そのポートの初期設定を行うために使われます。たとえば、 CTS/RTS によるフロー制御を行うモデムが接続されてい る場合の crtscts などのパラメータの初期化が行われます。ロッキング ディバイスは、ポートの設定をロックし、 他のユーザやプログラムにこれらを 変更されることのないようにするために利用されます。 通信ポートの設定、初 期化とロックおよび設定の変更に関しては、 それぞれ &man.termios.4;、&man.sio.4; と &man.stty.1; のマニュアルをご覧ください。 ディバイス スペシャル ファイルの作成 ディバイス スペシャル ファイルの管理は、ディレクトリ /dev にあるシェル スクリプト MAKEDEV によって行います (FreeBSD 1.1.5 の &man.MAKEDEV.8; のマニュアルの COM ポートに関する記述は、 かなりいい加減なので無視してください)。 MAKEDEV を使って、 COM1: (ポート 0) をダイアルアップのポートとして利用するためのディ バイス スペシャル ファイルを作るには、 /dev に cd して から、MAKEDEV ttyd0 と実行してください。 同様に、MAKEDEV ttyd1 とすることで、COM2: (ポート 1) 用のディバイス スペシャル ファイル を作成することができます。 MAKEDEV は、 /dev/ttyd? のディバイス ファイルだけでなく、 /dev/cuaa? (および FreeBSD 1.1.5 以降では総ての初期化ディバイ スとロッキング ディバイスのスペシャル ファイル) も作成します。さらに、もしシリアル端末用のスペシャル ファイル /dev/tty0? が存在すれ ば、それらの削除も行います。 ディバイス スペシャル ファイルの作成後、 これらのファイルのパーミション が適切に設定されていて、 これらのディバイスを利用してもよいユーザのみが 読み書きできるようになっていることを確認してください (特に /dev/cua* のパーミションには注意を払ってください)。この確認 を怠ると、 一般のユーザがあなたのモデムを使うことができるようなことにな りかねません。デフォルトの /dev/cua* のパーミションは、以下の ようになっていて、 たいていの場合適切なものだと思います。 crw-rw---- 1 uucp dialer 28, 129 Feb 15 14:38 /dev/cuaa1 crw-rw---- 1 uucp dialer 28, 161 Feb 15 14:38 /dev/cuaia1 crw-rw---- 1 uucp dialer 28, 193 Feb 15 14:38 /dev/cuala1 上の設定では、ユーザ uucp と、 グループ dialer に属するユーザ が発信用のディバイスを利用できます。 設定ファイル FreeBSD のシステムへのダイアル アップによるアクセスを実現するために編 集が必要と思われる設定ファイルが、/etc ディレクトリに三つあ ります。まず、 /etc/gettytab には、 /usr/libexec/getty デーモンの設定を記述します。つぎに、 /etc/ttys に保存されている情報から、 /sbin/init はど の tty ディバイスに対して getty のプロセスを実行するべきか判 断します。最後に、お使いの FreeBSD が 1.1.5.1 以降のものならば /etc/rc.serial スクリプトに、 それ以前のものならば /etc/rc.local スクリプトにシリアル ポートの初期化のためのコマ ンドを記述することができます。 Unix にダイアル アップ モデムを接続する方法には、 二つの考え方がありま す。一つの方法は、ダイアル インしてくるユーザの接続速度に関係なく、常 にモデムとローカルのコンピュータの RS-232 インタフェースの接続速度を一 定に保つように設定する方法です。 この設定の長所は、ユーザがダイアル イ ンして接続されると、 即座にシステムからのログイン プロンプトが送信され るということです。短所は、 システムが実際のモデム間の速度を知ることがで きないために、 Emacs のようなフル スクリーンのプログラムが、端末との接 続速度が遅い場合でも、 そのような場合に効果的な方法で画面出力を行わない 点です。 もう一つは、モデムの RS-232 インタフェースとコンピュータの接続速度を、 モデム間の接続速度に応じて変化させるような設定です。たとえば、 モデム間 の接続が V.32bis (14.4 Kbps) ならば、 モデムとコンピュータの間の接続を 19.2 Kbps とし、 モデム間の接続が 2400 bps の時には、モデムとコンピュー タ間も 2400 bps で接続するような設定をします。この場合、 getty は、モデムが返すリザルト コードからモデムとコンピュータの接続速度を認識す ることができませんので、getty は、 まず初期速度で login: とい う文字列を送信して、それに対する応答の文字列を監視します。 ここで、ユー ザ側の端末に無意味な文字列が表示された場合、 ユーザは意味のある文字列を 受信するまで <Enter> キーを繰り返し押さなければならない ということを知っていると仮定しています。 もし接続速度が間違っている場合、getty は、 ユーザから送られた文字を無意味な文字列として扱い、次の 速度を試します。そして、ここで再度 login: プロンプトを送信します。 この一連の動作が異常な回数繰り返されることも考えられますが、 普通は1度 か2度のキー入力があれば、 ユーザはまともなプロンプトを受信できます。こ のログインの動作が前者の固定速度による方法に 比べて美しくないのは明らか ですが、この方法では、 低速度で接続しているユーザに対するフル スクリー ンのプログラムからのレスポンスが改善されます。 このドキュメントでは、両方の設定方法について解説しますが、 どちらかとい うとモデム間の速度に応じて RS-232 インタフェースの速度が変化するような 設定の方に偏った説明になってしまうと思います。 <filename>/etc/gettytab</filename> /etc/gettytab /etc/gettytab は、&man.getty.8; の設定ファイルで、&man.termcap.5; と同様の形式で記述されます。ファイルのフォーマットや定 義できる機能についての詳細については、&man.gettytab.5; のマニュアルを ご覧ください。 固定速度の設定 モデムとコンピュータ間の通信速度を固定して使う場合、 おそらく /etc/gettytab に特に変更を加える必要はないはずです。 可変速度の設定 getty が利用するモデムとコンピュータの接続速度に関する情報を /etc/gettytab に記述する必要があります。もし、2400 bps のモ デムをお使いになるのであれば、既存の D2400 のエントリがそのまま利 用できるでしょう。このエントリは FreeBSD の 1.1.5.1 の gettytab には既に含まれていますので、 あなたの FreeBSD のバージョンでこのエント リが存在しているのであれば、 新たに追加する必要はありません。 # # 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 では、:np: パラメータをファイルの 先頭の std.xxx のエントリに追加することで、パリティなし、 8ビットの接続が行われますが、 このパラメータを追加しなければ接続は偶数 パリティ、 7ビットになります。 上記の例では、まず 19.2 Kbps (V.32bis) によるモデムとコンピュータ間の 接続を試み、続いて 9600 bps (V.32)、2400 bps、1200 bps、300 bpsと順に 試み、再び 19.2 Kbps による接続を試みるという循環に入ります。この接続 速度の循環は、nx=(next table) の機能で実現されています。ま た、 各行はそれぞれ tc=(table continuation) の機能を使って、 その他の接続速度に依存した 標準的な 設定を取り込んでいます。 もし、お使いのモデムが 28.8 Kbps であったり、14.4 Kbps の圧縮転送の機 能を有効に利用したい場合は、19.2 Kbps よりも速い速度を利用するように 設定する必要があります。 以下に 57.6 Kbps から接続を試みる gettytab の設定例を示しておきます。 # # 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 に対する負荷が高い場合 で、16550A 系のシリアル ポートをお使いでない場合、57.6 Kbps の接続に おいて、sio の silo エラーが発生するかもしれません。 <filename>/etc/ttys</filename> /etc/ttys /etc/ttys には、 init が監視すべき tty のリストを記 述します。さらに、/etc/ttys は、 login に対してセキュリ ティに関する情報を提供します。(ユーザ root は、secure とマー クされている tty のみからログインできます)。詳しくは &man.ttys.5; のマニュアルをご覧ください。 /etc/ttys の既存の行を変更するか、 あるいは新しい行を追加して、init が自動的に新しいダイアル アップ サービス用のポートに対して getty プロセスを起動するようにしてください。書式は、固定速度の設 定か可変速度の設定かに関わらず、以下のとおりです。 ttyd0 "/usr/libexec/getty xxx" dialup on 1番目の項目は、このエントリで対象とするディバイス スペシャル ファイル です。上の例では ttyd0 として、 /dev/ttyd0 を getty に監視させることを表しています。2番目の項目 "/usr/libexec/getty xxx" (xxx は初期段階で使われる gettytab のエントリ に置き換えてください) が、init がこのディバイスに対して起動する プロセスです。3番目の dialup は、デフォルトのターミナル タイプで す。4番目の on は、 この行が有効であることを init に対して示 しています。5番目の項目に secure を指定することもできますが、これ は、 たとえばシステムのコンソールのように、 物理的に安全な端末に対しての み指定するようにしてください。 デフォルトのターミナル タイプ (上記の例では dialup) は、ローカル のユーザの好みによって異なってきます。ユーザがログイン スクリプトをカ スタマイズして、ターミナル タイプが dialup の時には自動的に他のター ミナル タイプを設定できるように、ダイアル アップのポートのデフォルトの ターミナル タイプには dialup が伝統的に用いられています。 しかし、筆者のサイトでは、ほとんどのユーザが VT102 エミュレイションを使ってい るので、ダイアル アップのポートのデフォルト ターミナル タイプとして vt102 を指定しています。 /etc/ttys の修正がすんだら、 以下のようなコマンドを使って init プロセスに HUP シグナルを送り、/etc/ttys を 読み込み直させてください。 &prompt.root; kill -HUP 1 ただ、もし初めてシステムを設定しているのであれば、 モデムが適切に設定さ れて接続されるまでは、init に対してシグナルを送らない方がいいか もしれません。 固定速度の設定 速度を固定する設定では、/etc/ttys の中で、getty に対し て固定速度のエントリを指定する必要があります。たとえば、 以下の例はポー トのスピードが 19.2 Kbps に固定されたモデムのための ttys のエント リです。 ttyd0 "/usr/libexec/getty std.19200" dialup on 別の速度でモデムのポートのスピードを固定したい場合は、 /etc/gettytab から適切なエントリを選んで、上の例の std.19200 の部分を std.speed として、適切な速度のも のに置き換えてください。 可変速度の設定 可変速度の設定では、ttys のエントリが、/etc/gettytab の中の適切な 自動速度調整 の初期設定のエントリを参照していなければな りません。 たとえば、もし前述の 19.2 Kbps から接続を試みる可変速度の設 定例 (V19200 の gettytab エントリ)をそのまま ttys に追 加したのであれば、 ttys エントリは以下のようになります。 ttyd0 "/usr/libexec/getty V19200" dialup on <filename>/etc/rc.serial</filename> または <filename>/etc/rc.local</filename> rc ファイル rc.local rc ファイル rc.serial V.32、V.32bis または V.34 モデムのような高速モデムを利用する場合、ハー ドウェア (RTS/CTS) フロー制御を行う必要があります。FreeBSD kernel のモデム ポートにハードウェア フロー制御のフラグを設定するため の stty コマンドを、FreeBSD 1.1.5.1 以降では /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 この例では、termio のフラグ crtscts をシリアル ポート #1 (COM2:) のダイアル インおよびダイアル アウトの初期化ディバイスに 設定しています。 古い FreeBSD 1.1 では、以下のエントリが 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 には初期化のためのディバイス スペシャル ファイルがないので、ディバイス ファイルそのものにフラグを設定して、その後はフラグをクリア してしまうような極悪人が現れないことを願うしかありません。 モデムの設定 もし、あなたのモデムがパラメータを不揮発ラムに 保存できるタイプならば、MS-DOS 上の Telix や FreeBSD 上の tip などのような通信プログラム を使って、 パラメータを設定してください。getty が利用する初期速度でモデムに接続して、以下の条件を満たすよ うに不揮発ラムの設定を変更してください。 接続時に CD 信号がオンになる 接続時に DTR がオンになり、 DTR オフで回線を切断しモ デムをリセットする。 送信時フロー制御には CTS を利用。 XON/XOFF によるフロー制御を行わない。 受信時のフロー制御は RTS を使用。 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) リザルト コードを返さないように設定しておかないと、 getty が誤っ て login: プロンプトをコマンド モードのモデムに送信してしまった場 合に、 モデムがこの入力をエコーしたり、この入力に対するリザルト コード を返してしまったりすることになります。この結果として、 モデムと getty の間で延々と無意味なやりとりが続いたというケースを聞いたこ とがあります。 固定速度の設定 固定速度の設定では、 モデムとコンピュータ間の通信速度をモデムとモデム間 の接続速度に関係なく、常に一定に保つように、 モデムを設定する必要があり ます。USRobotics Sportster の 14,400 bps 外づけモデムの場合、以下のコ マンドで、 モデムとコンピュータ間の速度が、コマンド送信時の速度に固定さ れます。 ATZ AT&B1&W 可変速度の設定 可変速度の設定では、シリアル ポートの速度が、 着信速度に応じて変化する ように設定しなければいけません。 USRobotics Sporster の 14,400 bps 外 づけモデムの場合、 以下のコマンドで、エラー訂正機能を利用した通信の場合 は、 コマンドを送信した時の通信速度にシリアル ポートの速度を固定し、エ ラー訂正機能を利用しない接続では、 シリアル ポートの速度が変化するよう に設定されます。 ATZ AT&B2&W モデムの設定の確認 ほとんどの高速モデムには、 現在の設定をある程度人間にも理解できる形式に して表示させるコマンドがあります。USRobotics Sporster の 14,400 bps 外づけモデムの場合は、ATI5 コマンドで、現在の不揮発ラムの設定を 表示することができます。 さらに、ディップ スイッチの設定も含めた現在の 設定を確認するためには、ATZ コマンドを送信してから、ATI4 コマンドを送信してください。 他のメーカーのモデムをお使いの場合は、 モデムのマニュアルで設定値の確認 方法を確認してください。 トラブルシューティング 以下の手順でダイアル アップ モデムの動作を確認することができます。 FreeBSD システムの動作確認 モデムを FreeBSD システムに接続し、 システムをブートします。あなたのモ デムにモデムの状態を確認するためのインジケータがあれば、 DTR のイ ンジケータの状態に注目してください。もし、 システムのコンソールに login: プロンプトが表示された時に、DTR のインジケータが点灯 すれば、FreeBSD が適切なポートに対して getty を起動し、モデムへ の着信を待っている状態であることを意味しています。 もし DTR のインジケータが点灯しない場合は、システムのコンソールか ら FreeBSD にログインして、ps ax を実行し、 FreeBSD が 適切なポー トに対してgetty プロセスを起動しようとしているのかどうか確認して ください。 プロセスに関する情報の中に、以下のような行が表示されるはずで す。 114 ?? I 0:00.10 /usr/libexec/getty V19200 ttyd0 115 ?? I 0:00.10 /usr/libexec/getty V19200 ttyd1 モデムにまだ着信がない状態の時に、 以下のように上とは異なる出力があった 場合、getty は既にモデム ポートのオープンを終了したということに なります。 114 d0 I 0:00.10 /usr/libexec/getty V19200 ttyd0 getty は、CD (carrier detect) 信号がオンの状態になるまで、 ポートのオープンを完了することはできませんので、 この場合は接続に問題が あるか、あるいはモデムの設定に問題があることが考えられます。 もし、適切なポートをオープンしようとしている getty が見あたらない 場合は、再度 /etc/ttys の内容を確認し、 書式などに誤りがないか 調べてみてください。また、ログ ファイル /var/log/messages に init および getty から何か出力がないかどうかも確認してみてく ださい。 もし何かメッセージが記録されていたら、再度 /etc/ttys、 /etc/gettytab の二つの設定ファイルと、 ディバイス スペシャル ファイル /dev/ttyd? を確認し、 記述に誤りがないか、足りないエ ントリがないか、 足りないディバイス スペシャルファイルがないかといった 点について調べてみてください。 モデムで接続してみる 実際にモデムを使って別のコンピュータから 接続してみてください。この時、8ビット、パリティなし、 1ストップ ビットで接続するようにしてください。 接続後すぐにプロンプトが返ってこない場合や、 無意味な文字列が表示される 場合は、1秒に1回くらいの割合で <Enter> キーを押してみて ください。 しばらくたって、なおも login: プロンプトが現れない場合 は、BREAK 信号を送信してみてください。この時、端末側で使って いるモデムが高速モデムならば、 このモデムのインタフェースの接続速度を固 定してから、 再度ダイアル インしてみてください。(たとえば、USRobotics Sportster の場合は、AT&B1) それでもまだ login: プロンプトが表示されない場合は、 /etc/gettytab の以下の点について再度確認してみてください。 /etc/ttys の対応する行の 2番目の項目で、/etc/gettytab の中で定義されているエントリが指定されているか 各 nx= で /etc/gettytab の中で定義されているもの が指定されているか 各 tc= で /etc/gettytab の中で定義されているもの が指定されているか もしダイアル インしても、FreeBSD システム側のモデムが応答しない場合は、FreeBSD 側のモデムが DTR がオンになった時に電話にでるように設定さ れているかを確認してください。 もしモデムの設定に問題がなさそうならば、 モデムのインジケータ (がもしあれば) で、 DTR がオンになっているか を確認してください。 この確認のステップを数回繰り返しても うまくいかない場合は、一度休憩して、 しばらくたってから挑戦してみましょう。それでもだめなら、 おそらく &a.questions; にあなたのモデムについての情報と問題を書いたメールを送れ ば、 メーリング リストのメンバーが問題の解決を助けるべく努力してくれる でしょう。 謝辞 以下の方々から、 多くのコメントやアドバイスをいただきました。ここに謝意 を表します。 Sean Kelly <kelly@fsl.noaa.gov> 多くのすばらしい助言をいた だきました ダイアルアウトサービス ダイアルアウトサービス 原作: FAQ からの情報 訳: &a.jp.tmaruya;. 31 December 1996. 以下はモデムを利用して他のコンピュータと 接続する方法を説明しています。 これはリモートホストとターミナル接続を確立するための 適切な方法です。 これは BBS に接続するときによく使います。 この種の接続は PPP 接続に問題がある場合、Internet 上にあるファイルを 転送するのに非常に役に立ちます。FTP で何らかのファイルを転送したいのに PPP 接続を確立できない場合は、ファイルを FTP 転送するためにターミナルセッション を利用します。そして ZMODEM を利用してファイルを転送します。 <command>tip</command> や <command>cu</command> が実行できないはなぜ? あなたのシステムで tip や cu というプログラムは uucp や dialer というグループに所属しているユーザのみが 実行できるようになっているのでしょう。リモートホストやモデムを 利用できる dialer のグループにあなたのアカウントを 加えましょう。 もしくは下記のコマンドを使うことによって、そのシステムで tip や cu を誰でも使えるようになります: &prompt.root; chmod 4511 /usr/bin/tip このコマンドは cu に対しておこなう必要はありません、それは cu は tip に対するハードリンクだからです。 私の Hayes モデムはサポートされていません、 どうしよう? 実際、tip の マニュアルページは古くなっています。既に Hayes ダイアラが組み込まれています。/etc/remote ファイル中で at=hayes を使ってください。 Hayes ドライバは、最近のモデムの新しい機能である BUSY、NO DIALTONE、 CONNECT 115200などのメッセージを 認識できるほど賢くはなく、単に混乱を起こすだけです。 tipを使う場合には、 (ATX0&W とするなどして) これらの メッセージを表示させないようにしなくてはいけません。 また、tip のダイアルのタイムアウトは 60秒です。モデムの タイムアウト設定はそれより短くすべきであり、 そうしないと tip は通信に問題があると判断するでしょう。 ATS7=45&W を実行してください。 実際、デフォルトの tip は Hayes の完全なサポートを しているわけではありません。解決方法は /usr/src/usr.bin/tip/tip の下の tipconf.h を変更することです。 もちろんこれにはソース配布ファイルが必要です。 #define HAYES 0 と記述されている行を #define HAYES 1 と変更し、そして make、make install を実行します。これでうまく動作するでしょう。 これらの AT コマンドを入力するには? /etc/remote /etc/remote ファイルの中で direct エントリを作ります。たとえばモデムが 1番目のシリアルポートである /dev/cuaa0 に接続されている場合、次のようにします: cuaa0:dv=/dev/cuaa0:br#19200:pa=none モデムがサポートする最大の bps レートを br フィールドに使います。そして tip cuaa0 を実行すると、モデムが利用できるようになります。 /dev/cuaa0 がシステムに存在しない場合は、次のようにします: &prompt.root; cd /dev &prompt.root; ./MAKEDEV cuaa0 または root になって以下のように cu コマンドを実行します: &prompt.root; cu -lline -sspeed line にはシリアルポートを指定します (例えば /dev/cuaa0)。そして speed には接続する速度を指定します (例えば 57600)。その後 AT コマンドを実行したら、~. と入力すれば終了します。 pn 機能の <literal>@</literal> 記号が使えません! 電話番号 (pn) 機能の中での @ 記号は、 tip に /etc/phone にある電話番号を参照するように伝えます。しかし @ の文字は /etc/remote のような 設定ファイルの中では特殊文字となります。 バックスラッシュを使ってエスケープをおこないます: pn=\@ コマンドラインから電話番号を指定するには? generic エントリと呼ばれるものを /etc/remote に追加します。 例えば次のようにします: tip115200|Dial any phone number at 115200 bps:\ :dv=/dev/cuaa0:br#115200:at=hayes:pa=none:du: tip57600|Dial any phone number at 57600bps:\ :dv=/dev/cuaa0:br#57600:at=hayes:pa=none:du: そして &prompt.root; tip -115200 5551234 のように利用できます。 tip より cu を使いたい場合、 cu の generic エントリを使います: cu115200|Use cu to dial any number at 115200bps:\ :dv=/dev/cuaa1:br#57600:at=hayes:pa=none:du: そして &prompt.root; cu 5551234 -s 115200 と実行します。 毎回 bps レートを入力しなければいけませんか? tip1200 や cu1200 用のエントリを記述し、適切な通信速度を br フィールドに設定します。tip は 1200 bps が正しいデフォルト値であるとみなすので、 tip1200 エントリを参照します。もちろん 1200 bps を使わなければならないわけではありません。 ターミナルサーバを経由して 複数のホストへアクセスしたいんです。 毎回接続されるのを待って CONNECT <host> と入力する かわりに、tip の cm 機能を使います。 例えば、/etc/remote に次のようなエントリを追加します: pain|pain.deep13.com|Forrester's machine:\ :cm=CONNECT pain\n:tc=deep13: muffin|muffin.deep13.com|Frank's machine:\ :cm=CONNECT muffin\n:tc=deep13: deep13:Gizmonics Institute terminal server:\ :dv=/dev/cuaa2:br#38400:at=hayes:du:pa=none:pn=5551234: これで、tip pain や tip muffin と実行すると pain や muffin のホストに接続することができ、 tip deep13 を実行するとターミナルサーバに接続します。 tip を使ってそれぞれのサイトの 複数の回線に接続できますか? これは大学に電話回線がいくつかあって 数千人の学生が接続しようとする 場合によくある問題です。 あなたの大学のエントリを /etc/remote ファイルに作成して、pn のフィールドには @ を使います: big-university:\ :pn=\@:tc=dialout dialout:\ :dv=/dev/cuaa3:br#9600:at=courier:du:pa=none: そして /etc/phone ファイルに大学の電話番号の一覧を書きます: big-university 5551111 big-university 5551112 big-university 5551113 big-university 5551114 tip は一連の電話番号を試みて、 最終的に接続できなければあきらめます。 リトライを続けさせたい場合は、tip を while ループに入れて 実行します。 CTRL+P を 1回送るために 2度押す必要があるのはなぜ? CTRL+P は通常 force (強制) 文字であり、 tip に次の文字が リテラルデータであることを伝えます。force 文字は 変数の設定 を意味する ~s エスケープによって他の文字にすることができます。 ~sforce=single-char と入力して改行します。single-char は、任意の 1バイト文字です。 single-char を省略すると NUL 文字になり、これは CTRL+2 や CTRL+SPACE を押しても入力できます。また、 single-char に SHIFT+CTRL+6 を割り当てる方法を使っているターミナルサーバもあります。 $HOME/.tiprc に次のように定義することで、任意の文字を force 文字として利用できます: force=<single-char> 打ち込んだ文字が突然すべて大文字になりました?? CTRL+A を押してしまい、caps-lock キーが壊れている場合のために設計された tip の raise character モードに入ったのでしょう。 既に述べたように ~s を使って、 raisechar をより適切な値に 変更してください。もしこれら両方の機能を使用しないのであれば、 force 文字と同じ設定にすることもできます。 以下は CTRL+2 や CTRL+A などを頻繁に使う必要のある Emacs ユーザにうってつけの .tiprc ファイルのサンプルです: force=^^ raisechar=^^ ^^ は SHIFT+CTRL+6 です。 <command>tip</command> でファイルを転送するには? もし他の Unix のシステムと接続しているなら、 ~p(put) や ~t(take) でファイルの送受信ができます。これらのコマンドは 相手のシステムの上で cat や echo を実行することで 送受信をします。 書式は以下のようになります: ~p ローカルのファイル名 リモートのファイル名 ~t リモートのファイル名 ローカルのファイル名 この方法ではエラーチェックをおこないませんので、zmodem などの他のプロトコルを使った方がよいでしょう。 <command>tip</command> から zmodem を実行するには? ファイルを受信するには、 リモート側で送信プログラムを起動します。そして ~C rz と入力すると、ローカル側へのファイルの受信が 始まります。 ファイルを送信するには、 リモート側で受信プログラムを起動します。そして ~C sz files と入力すると、 リモート側への ファイルの送信が始まります。 シリアルコンソールの設定 シリアルコンソール 原作: &a.yokota;、&a.wpaul; この文書はほとんどが &a.wpaul; 氏の /sys/i386/boot/biosboot/README.serial に基づいています。 導入 FreeBSD/i386 オペレーティングシステムは、コンソールとして シリアルポート上のダム端末しか持たないシステムでも起動できます。 この様な構成はきっと次のような二種類の人達に便利でしょう。それは、 キーボードやモニタのないマシンに FreeBSD をインストールしたいシステム管理者と、 カーネルやデバイスドライバをデバッグしたい開発者です。 バージョン 3.1 から、FreeBSD/i386 は 3 ステージ構成のブートストラップ を用いるようになりました。最初の 2 つのステージは、 ブートディスクにある FreeBSD スライスの最初に格納されている、 ブートブロックのコードが行います。 それからブートブロックは、第 3 ステージのコードとしてブートローダ (/boot/loader) を読み込み、実行します。 (ブートプロセスの詳細については &man.boot.8; と &man.loader.8; をご覧下さい。) シリアルコンソールを設定するためには、ブートブロックコード、 ブートローダコード、カーネルを設定する必要があります。 FreeBSD バージョン 3.0 では、ブートローダはないので ブートストラップは 2 ステージです。つまり、ブートブロックが直接 カーネルをメモリに読み込みます。もしあなたが FreeBSD 3.0 を使って いるなら、このセクションでブートローダについて述べている部分は無視してください。 それでもシリアルポートをコンソールとして使うのに支障はありません。 FreeBSD バージョン 2.X と 3.X のシリアルポートドライバ &man.sio.4 は全く違いますので、設定も異なった方法で行う必要があります。 この章ではバージョン 2.X システム用の設定については扱っていません。 もしあなたが古いバージョンの FreeBSD を使っているなら、かわりに /sys/i386/boot/biosboot/README.serial を調べてみてください。 シリアルコンソールを設定するための 6 ステップ シリアルケーブルを用意してください。 ヌルモデムケーブル ヌルモデムケーブル、 もしくは標準シリアルケーブルとヌルモデムアダプタが必要となります。 シリアルケーブルについては をご覧下さい。 キーボードをはずして下さい。 たいていの PC システムは Power-On Self-Test (POST) の間にキーボードを検出し、もし見つからなければエラーと なります。また、キーボードがないことを大きな音で知らせ、 キーボードが接続されるまでは起動を中断するようなマシンもあります。 コンピュータがエラーを表示していても、 とにかく起動するなら特別な対応は必要ありません (Phoenix BIOS を搭載しているマシンには、 Keyboard failed と表示されても、正常に起動するものがあります)。 あなたのコンピュータがキーボードを接続していない状態で 起動しないようなら、(もし可能ならば) エラーを無視するように BIOS を設定する必要があります。設定方法の詳細については、 マザーボードのマニュアルを調べてください。 BIOS の設定でキーボードを Not installed にするということは、キーボードを使えないということを 意味しているわけではありません。これは、BIOS がキーボードがなくても文句を言わないように、電源投入時には キーボードを探すな、と指示するだけです。このフラグを Not installed にしていてもキーボードを 接続したままにできますし、ちゃんと動作します。 あなたのシステムが PS/2 マウスを使っているなら、 おそらくマウスもキーボード同様にはずす必要があるでしょう。 というのは、PS/2 マウスは部分的にキーボードとハードウェアを 共有しており、マウスを接続したままにしていると、 キーボードも存在する、と誤って検出してしまう可能性があるからです。 AMI BIOS を持つ Gateway 2000 Pentium 90MHz システム はこれに該当すると言われています。 一般的にこれは問題ではありません。なぜなら、どっちにしても マウスはキーボードなしではたいして役に立たないからです。 COM1: (sio0) にダム端末を接続してください。 ダム端末がなければ、かわりに古い PC/XT でモデム - プログラムを走らせて使ったり、シリアルボートに他の Unix + プログラムを走らせて使ったり、シリアルポートに他の Unix マシンを繋いだりできます。もしも COM1: (sio0) がなければ、作成してください。 今のところ、COM1: 以外のポートを 選択するためにはブートブロックの再コンパイルが必要です。 すでに COM1: を他の装置に 使っていた場合は、一時的にその装置をはずして いったん FreeBSD がうまく動作してから、 新しいブートブロックとカーネルをインストールしてください。 (上記はとにかくファイル/演算/端末サーバの COM1: が利用可能であると仮定して います。あなたが本当に何かのために COM1: が必要 (で、なおかつその何かを COM2: (sio1) に付け替えることができない) ならば、多分、そもそも 悩んでる場合ではありません。) カーネルコンフィグファイルの COM1: (sio0) に適切なフラグを 設定していることを確認してください。 関連するフラグ: 0x10 このポートのコンソールサポートを有効にします。 このフラグが設定されない場合、他のフラグは無視されます。 現在のところ、一つのポートしかコンソールサポートを有効に できません。(config ファイルに書かれた順番で) 最初にこのフラグを 指定されたポートが選択されます。 なお、このオプションを指定するだけでシリアルポートが コンソールとして使えるわけではありません。 このフラグと一緒に、以下のフラグも指定するかもしくは オプションも使ってください。 0x20 後述される オプション を無視して、(他に優先度の高いコンソールがない限り) このポートをコンソールとして指定します。 このフラグは FreeBSD バージョン 2.X の COMCONSOLE オプションに対応するものです。 フラグ 0x20 は必ず フラグ と一緒に指定されなければなりません。 0x40 (0x10 と組み合わせることで) このポートを予約し、通常のアクセスができない ようにします。 このフラグは、シリアルコンソールとして使いたいポートに 指定すべきではありません。 唯一の使い道は、ユニットがカーネルのリモートデバッグ用 であることを指定することです。 リモートデバッグの詳細については The Developer's Handbook を参照してください。 FreeBSD 4.0-CURRENT 以降では、 フラグ 0x40 の意味が若干異なり、 シリアルポートにリモートデバッグを指定するためには、 別のフラグを使います。 例: device sio0 at isa? port "IO_COM1" tty flags 0x10 irq 4 詳細については &man.sio.4; を参照して下さい。 もしこれらのフラグがセットされていなければ、(別のコンソールで) UserConfig を実行するか、 カーネルを再コンパイルする必要があります。 ブートドライブの a パーティションの ルートディレクトリに boot.config を作成してください。 このファイルは、ブートブロックコードに対してどのように システムを起動したいかを教えます。 シリアルコンソールを活かすためには、以下のオプションを幾つか - dash; 複数の場合も一行で、設定する必要があります: + — 複数の場合も一行で、設定する必要があります: 内蔵コンソールとシリアルコンソールの切替えを行います。 これを使用してコンソールデバイスを変更できます。 例えば、内蔵 (ビデオ) コンソールからブートした場合、 カーネルとブートローダがコンソールデバイスとして シリアルポートを使用するようにするため、 を使って指示できます。 反対に、シリアルポートからブートした場合、 ブートローダとカーネルがコンソールとして代わりに ビデオディスプレイを使用するようにするため、 を使用できます。 シングルとデュアルのコンソール設定を切り替えます。 シングル設定では、上記の オプションの状態によって、コンソールは内蔵コンソール (ビデオディスプレイ)かシリアルポートのいずれかになります。 デュアルコンソール設定では、ビデオディスプレイと シリアルポートの両方が、 オプションの状態によらず、同時にコンソールになります。 しかし、デュアルコンソール設定は、ブートブロックが 実行されている間でしか効果を持ちません。 一旦ブートローダに制御が移ると、 オプションによって指定されたコンソールが 唯一のコンソールになります。 ブートブロックがキーボードを検出するようにします。 キーボードが発見できなかった場合には、 と オプションが自動的にセットされます。 現バージョンのブートブロックでは容量の制限により、 オプションは拡張キーボードしか 検出できません。キーが 101 個より少ない (そして F11 と F12 がない) キーボードは検出されない可能性があります。 この制限から、いくつかのラップトップコンピュータの キーボードは正しく検出されないでしょう。 残念ながら、この問題の回避策はありません。 オプションを使ってコンソールを 自動的に選ぶか、 オプションを使って シリアルコンソールを有効にしてください。 さらに &man.boot.8; で説明されている他のオプションも使う ことができます。 以外のオプションはブートローダ (/boot/loader) に渡されます。 ブートローダは、 オプションだけの状態を 調べることで内蔵ビデオとシリアルポートのどちらがコンソールに なるのか決めます。 つまり、/boot.config の中で オプションを指定して オプションを指定しなかった場合、 ブートブロック実行中でのみシリアルポートをコンソールとして 使うことができます。ブートローダは内蔵ビデオディスプレイを コンソールとして使います。 マシンを起動する。 FreeBSD を起動したとき、ブートブロックは /boot.config の内容をコンソールに表示 します。例えば、 /boot.config: -P Keyboard: no 行の二番目は、 /boot.config にオプション が指定してあるときだけ表示され、 キーボードが存在するかどうかを表します。 これらのメッセージは、シリアルか内蔵のいずれか、 あるいはその両方のコンソールに表示されます。 どちらに表示されるかは、 /boot.config の設定によって変わります。 オプション指定 メッセージの表示される場所 なし 内蔵 シリアル シリアルと内蔵の両方 シリアルと内蔵の両方 、キーボードが存在する場合 内蔵 、キーボードが存在しない場合 シリアル このメッセージが表示された後、 ブートブロックがブートローダのロードを再開し、 他の全てのメッセージがコンソールに表示されるまで、 若干時間がかかります。通常の環境では、ブートブロックに 割り込みをかける必要はありませんが、 ちゃんとセットアップされているかどうか確かめるために、 割り込みをかけることができるようになっています。 ブートプロセスに割り込みをかけるには、 コンソールの(Enter/Return キー以外の)キーをたたいて下さい。 ブートブロックはその時、操作を指定するためのプロンプトを表示します。 こんな風に表示されるでしょう。 >> FreeBSD/i386 BOOT Default: 0:wd(0,a)/boot/loader boot: 上に示したメッセージが、シリアルか内蔵、 あるいはその両方といった、/boot.config で指定したとおりのコンソールに表示されることを確認して下さい。 メッセージが正しいコンソールに表示されたら、Enter/Return キーを押してブートプロセスを継続してください。 もし、シリアルコンソールを利用するように設定しているのに シリアル端末にプロンプトが出てこない場合は、 設定のどこかに間違いがあります。 ブートブロック(とブートローダ、カーネル)に対して シリアルポートをコンソールに使うことを伝えるため、 割り込みをかけた時に を入力し、 (可能ならば) Enter/Return キーを押して下さい。そして、 一度システムを起動させてから、どこが悪いのかをチェックして下さい。 ブートローダがロードされ、ブートプロセスの第三ステージに いる時には、まだ内蔵コンソールとシリアルコンソールを切り替えることができます。 それにはブートローダの環境変数を適切に設定すれは良いのですが、 詳細については を参照してください。 まとめ このセクションで扱ったさまざまな設定と、 最終的に選択されるコンソールに関するまとめです。 Case 1: sio0 の flags に 0x10 をセットした場合 device sio0 at isa? port "IO_COM1" tty flags 0x10 irq 4 /boot.config 内のオプション ブートブロック実行中のコンソール ブートローダ実行中のコンソール カーネルのコンソール なし 内蔵 内蔵 内蔵 シリアル シリアル シリアル 内蔵、シリアルの両方 内蔵 内蔵 内蔵、シリアルの両方 シリアル シリアル 、キーボードが存在する場合 内蔵 内蔵 内蔵 、キーボードが存在しない場合 内蔵、シリアルの両方 シリアル シリアル Case 2: sio0 の flags に 0x30 をセットした場合 device sio0 at isa? port "IO_COM1" tty flags 0x30 irq 4 /boot.config 内のオプション ブートブロック実行中のコンソール ブートローダ実行中のコンソール カーネルのコンソール なし 内蔵 内蔵 シリアル シリアル シリアル シリアル 内蔵、シリアルの両方 内蔵 シリアル 内蔵、シリアルの両方 シリアル シリアル - 、キーボートが存在する場合 + 、キーボードが存在する場合 内蔵 内蔵 シリアル 、キーボードが存在しない場合 内蔵、シリアルの両方 シリアル シリアル シリアルコンソールを利用する上で役に立つ情報 シリアルポートの通信速度をもっと速いものに設定するには デフォルトのシリアルポート通信速度は、9600 ボー、 8 ビット、パリティなし、ストップビット 1 です。 通信速度を変更したい場合には、少なくとも ブートブロックの再コンパイルが必要になります。 /etc/make.conf に次のような行を追加して、 新しくブートブロックをコンパイルして下さい。 BOOT_COMCONSOLE_SPEED=19200 もし、シリアルコンソールがブート時の オプション以外の方法で設定されていたり、 カーネルが利用するシリアルコンソールが ブートブロック実行中のものと異なる場合には、 カーネルコンフィグレーションファイルに次のオプションを追加して、 新しくカーネルをコンパイルしなければなりません。 options CONSPEED=19200 <devicename>sio0</devicename> 以外のシリアルポートを コンソールとして使うには sio0 以外のポートをコンソールとして使うには、再コンパイルが必要です。 それがどんな理由であれ、他のポートを使用する場合には ブートブロック、ブートローダ、カーネルを 次のようにして再コンパイルして下さい。 カーネルソースを取得する。 /etc/make.conf を編集し、 BOOT_COMCONSOLE_PORT に 使用したいポートのアドレス(0x3F8、0x2F8、0x3E8 or 0x2E8)を 設定してください。使用可能なのは sio0 から sio3 (COM1: から COM4:) までで、 マルチポートシリアルカードは使えません。 また、ここで割り込みの設定をする必要はありません。 設定を変更するために新たなカーネルコンフィグレーションファイルを作成し、 使いたいシリアルポートのフラグを適切に設定します。 例えば、sio1 (COM2:) をコンソールにしたければ、 device sio1 at isa? port "IO_COM2" tty flags 0x10 irq 3 または、 device sio1 at isa? port "IO_COM2" tty flags 0x30 irq 3 とします。その際、 他のシリアルポートにコンソールフラグをつけてはいけません。 ブートブロックを再コンパイルし、インストールする。 &prompt.root; cd /sys/boot/i386/boot2 &prompt.root; make &prompt.root; make install ブートローダを再コンパイルし、インストールする。 &prompt.root; cd /sys/boot/i386/loader &prompt.root; make &prompt.root; make install カーネルを再構築し、インストールする。 &man.disklabel.8; を使ってブートブロックをブートディスクに書き込み、 新しいカーネルから起動する。 シリアルポートから DDB デバッガを起動するには シリアルコンソールからカーネルデバッガを起動したい(これは リモートで診断する際に便利ですが、もしおかしな BREAK 信号がシリアルポートに送られるような場合には危険です!) 場合には、次のオプションを使ってカーネルをコンパイルして下さい。 options BREAK_TO_DEBUGGER options DDB シリアルコンソールにログインプロンプトを表示させるには シリアルコンソールからブートメッセージを確認したり、 シリアルコンソールを経由してカーネルデバッグセッションに入ることが できるので、これは必要がないかもしれませんが、 login プロンプトをシリアルポートに 出力するように設定することもできます。 これには、次のようにします。 エディタで /etc/ttys というファイルを開き、 次に示す行に移動して下さい。 ttyd0 "/usr/libexec/getty std.9600" unknown off secure ttyd1 "/usr/libexec/getty std.9600" unknown off secure ttyd2 "/usr/libexec/getty std.9600" unknown off secure ttyd3 "/usr/libexec/getty std.9600" unknown off secure ttyd0 から ttyd3 は、 COM1 から COM4 に対応しています。 設定したいポートの off を on に変更して下さい。 また、もしシリアルポートの通信速度を変更しているなら、 std.9600 が実際の通信速度になるように、 例えば std.19200 のように変更して下さい。 さらに、実際のシリアル端末に合わせて、 端末タイプを unknown から変更することも可能です。 ファイルの編集が終了したら、 変更を有効化するために kill -HUP 1 を実行しなければなりません。 ブートローダからコンソールを変更するには 前セクションは、ブートブロックの設定を変更することでシリアルコンソールを セットアップする方法について解説していました。 このセクションでは、ブートローダへのコマンド入力と環境変数設定で コンソールの指定を行なう方法を紹介します。 ブートローダがブートブロックの後、 ブートプロセスの第三ステージとして呼び出されたとき、 ブートローダの設定には、ブートブロックの設定がそのまま使われます。 シリアルコンソールをセットアップする ブートローダとカーネルに対して シリアルコンソールを使用するように設定するには、 単に /boot/loader.rc のファイルに、次のような一行を書くだけで実現できます。 set console=comconsole これは、前セクションで扱ったブートブロックの設定に 全く関係なく機能します。 上に示した行は、 /boot/loader.rc の最初の行に書き込まなくてはいけません。 これはできるだけ早く、ブートメッセージをシリアルコンソールに 出力させるために必要なことです。 同様にして、次のように内蔵コンソールを指定することもできます。 set console=vidconsole もし、ブートローダの環境変数 console が設定されていない場合、 ブートローダ、そしてその次に起動するカーネルは ブートブロックで指定された オプションに 示されたコンソールを使用します。 3.2 以降のバージョンにおいては /boot/loader.rc ではなく、 /boot/loader.conf.local や /boot/loader.conf にコンソール指定を書き込みます。 その場合、 /boot/loader.rc は次のようになっていなければなりません。 include /boot/loader.4th start それから、/boot/loader.conf.local を作成して、次の行をそこに追加して下さい。 console=comconsole か、もしくは console=vidconsole です。詳細については、&man.loader.conf.5; を参照して下さい。 その際、ブートローダはオプション指定なし (ブートブロックに オプションが指定されたのと等価)になり、 キーボードの存在を調べて 内蔵コンソールとシリアルコンソールを自動的に選択する機能は働きません。 <devicename>sio0</devicename> 以外のシリアルポートを コンソールとして使うには sio0 以外のシリアルポートを コンソールとして使うには、ブートローダを再コンパイルする必要があります。 それには、 に書かれている説明にしたがって下さい。 注意 シリアルコンソールというアイデアは、 グラフィック出力用のハードウェアやキーボードが接続されていない 専用サーバのセットアップを可能にするためのものです。 (ほとんど?)全てのシステムはキーボードなしで起動できますが、 不幸にも、グラフィックアダプタなしでは起動できないシステムはたくさんあります。 AMI BIOS を採用しているマシンでは、CMOS 設定の `graphics adapter' を `Not Installed' にするだけで、 グラフィックアダプタがなくとも起動できるように設定することができます。 しかしながら、多くのマシンはこのようなオプションを持っていませんし、 ディスプレイハードウェアがシステムに存在しないと起動しないように なっています。そのようなマシンでは、 モニタを接続する必要がなかったとしても、 適当なグラフィックカード(モノクロのジャンク品でも構いません)を 挿入したままにしておく必要があるでしょう。 また、AMI BIOS をインストールする、という手もあります。 diff --git a/ja_JP.eucJP/books/handbook/users/chapter.sgml b/ja_JP.eucJP/books/handbook/users/chapter.sgml index 86ee208869..f74116b777 100644 --- a/ja_JP.eucJP/books/handbook/users/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/users/chapter.sgml @@ -1,508 +1,508 @@ ユーザと基本的なアカウントの管理 この章では 寄稿: &a.nbm;、2000 年 2 月 システムへアクセスするには、かならずユーザアカウントが使われます。 また、プロセスもすべてユーザによって実行されますので、 ユーザとアカウントの管理は FreeBSD システムにおいて欠かすことのできない重要なものです。 アカウントには大きく分けて三種類のものがあります。それは、 スーパーユーザ (Superuser)、 システムユーザ (system users)、 そしてユーザアカウント (user accounts) です。 スーパーユーザのアカウントは通常 root と呼ばれ、 無制限の特権を持つためにシステムの管理に用いられます。 また、システムユーザはサービスの運用に用いられ、 最後のユーザアカウントは、 実際にログインしてメールを読むといった作業を行なう利用者のためのものです。 スーパーユーザアカウント スーパーユーザアカウントは通常 root と呼ばれ、初期時から設定済みです。 このアカウントはシステム管理を行なうためのもので、 メールのやりとり、システムの調査、 プログラミングといった日常的な作業を行なうために使われるべきものではありません。 その理由は、スーパーユーザが通常のユーザアカウントと異なり、 操作にまったく制限を受けないことによります。 そのためスーパーユーザアカウントで操作を間違えると、 システムに重大な影響を与えてしまう恐れがあるのです。 ユーザアカウントでは、仮に操作を間違えてもシステムを壊してしまうようなことは できないようになっています。したがって特権を必要としていないのであれば、 できるだけいつもユーザアカウントを利用する方が望ましいと言えるでしょう。 また、スーパーユーザで実行するコマンドはいつでも、 二回、三回と何度もコマンドをチェックしてください。 なぜならスペースが多かったり、文字が欠けていたりするだけで、 取り返しのつかないデータの破壊につながる可能性があるからです。 スーパーユーザになると得られる特権は、 言い換えてみれば通常のユーザアカウントの保護を受けることができない、 ということも意味しています。 ですから、この章を読んでからあなたが最初にすべきなのは、 もし用意していないなら、日常的に利用するための あなた自身のユーザアカウントを作成することです。 これはマルチユーザモード、シングルユーザモードを問わず、 同様にあてはまります。 この章のうしろの方では、アカウントの追加と通常のユーザから スーパーユーザへと移行する手順について扱います。 システムアカウント システムユーザとは、DNS、メール、 ウェブサーバといった各種サービスを運用するために使われます。 この目的は、セキュリティを確保するためです。 もしサービスがスーパーユーザで実行されていると、 それらのサービスは (本来意図しないような) どんな動作でも可能となり、適切な制限を適用することができません。 システムユーザの具体例として、 daemon、 operator、 bind (DNS; Domain Name Service 用) および news といったものがあります。 またシステム管理者はよく、 インストールしたウェブサーバを運用するために httpd というユーザを作成しています。 nobody ユーザは通常の特権を持たないシステムユーザですが、 nobody を利用するサービスが増えれば増えるほど、その特権も大きくなります。 ユーザアカウント ユーザアカウントは、 主に現実のユーザがシステムにアクセスする手段として用いられるものです。 このアカウントは利用するユーザとシステム環境を分離します。 そのため、システムや他のユーザに危害をおよぼす危険性をなくし、また、 他に影響を与えることなくユーザ自身の環境をカスタマイズすることを可能にしています。 システムにアクセスするすべてのユーザは、 それぞれに一人一つのユーザアカウントを持つべきです。 こうすることで誰が何を行なっているかがわかりますし、 他の人の設定を壊してしまったり、 他人にメールを読まれてしまうようなことを避けることができます。 それぞれのユーザは快適にシステムを利用するため、 シェル、エディタ、キー設定、言語など、 各自の環境をセットアップすることができます。 アカウント情報の変更 強力で柔軟性に富むアカウント情報の変更手段として、 pw があります。 しかし、新しいアカウントをつくる場合は adduser を、 アカウントを削除する場合は rmuser を使うことが推奨されています。 chpass を使うことで、 システム管理者、通常のユーザはパスワード、シェル、 その他の個人情報を変更することができます。 また、特にパスワードを変更する場合には、 通常 passwd の方が良く使われます。 adduser adduser は、 新しいユーザを登録するためのシンプルなプログラムです。 このプログラムは passwd と group に新しいユーザのエントリを作成するのと同時に、 ホームディレクトリを作成して /usr/share/skel からデフォルトで使用されるドットファイル (訳注: ホームディレクトリに存在する . から始まるファイルのことで、各種設定に用いられます) をコピーします。 また、新しく作成されたユーザに対して、 ウェルカムメッセージをメールで送信することも可能です。 初期設定ファイルを作成するには、 - adduser -s -config_create。 + adduser -s -config_create とします オプション をつけると、 デフォルトで詳細を表示しないように adduser を設定します。 この後に詳細を表示させるようにしたい場合は、 オプション を指定してください。 。 そして次に adduser のデフォルト設定を行ない、 最初のユーザアカウントを作成します。 システムを日常利用する際に root を用いるのは最悪です。 adduser の設定の変更 &prompt.root; adduser -v Use option ``-silent'' if you don't want to see all warnings and questions. Check /etc/shells Check /etc/master.passwd Check /etc/group Enter your default shell: csh date no sh tcsh [sh]: tcsh Your default shell is: tcsh -> /usr/local/bin/tcsh Enter your default HOME partition: [/home]: Copy dotfiles from: /usr/share/skel no [/usr/share/skel]: Send message from file: /etc/adduser.message no [/etc/adduser.message]: no Do not send message Use passwords (y/n) [y]: y Write your changes to /etc/adduser.conf? (y/n) [n]: y Ok, let's go. Don't worry about mistakes. I will give you the chance later to correct any input. Enter username [a-z0-9_-]: jru Enter full name []: J. Random User Enter shell csh date no sh tcsh [tcsh]: Enter home directory (full path) [/home/jru]: Uid [1001]: Enter login class: default []: Login group jru [jru]: Login group is ``jru''. Invite jru into other groups: guest no [no]: wheel Enter password []: Enter password again []: Name: jru Password: **** Fullname: J. Random User Uid: 1007 Gid: 1007 (jru) Class: Groups: jru wheel HOME: /home/jru Shell: /usr/local/bin/tcsh OK? (y/n) [y]: y Added user ``jru'' Copy files from /usr/share/skel to /home/jru Add another user? (y/n) [y]: n Goodbye! &prompt.root; 簡単に上の操作を説明します。 まずデフォルトシェルを tcsh (packages にある追加のシェルです) に変更し、 新しいユーザにウェルカムメッセージのメールを送付しないようにしました。 そしてその設定を保存し、wheel グループ (後に、 これが重要な意味を持っていることがわかるでしょう) に所属する jru というアカウントを作成しています。 入力したパスワードは画面に表示されません。 アスタリスク記号も表示されませんので、 パスワードを二回とも間違えて入力してしまわないように注意してください。:-) これ以降はオプション引数をつけず単に adduser を起動します。 デフォルト設定を変更する必要はありません。 もし、adduser がデフォルト設定を変更するかどうか尋ねてきたら、 adduser を終了し、 オプションを使うようにしてください。 rmuser rmuser は、 システムからユーザを削除します。 これにはユーザデータベースからの削除だけでなく、 その他、そのユーザに依存する情報すべてが含まれます。 rmuser は次の手順を実行します。 指定されたユーザの &man.crontab.1; エントリを削除 (存在する場合)。 指定されたユーザの &man.at.1; ジョブをすべて削除。 指定されたユーザが所有するすべてのプロセスを強制終了。 ローカルパスワードファイルから、 指定されたユーザのエントリを削除。 指定されたユーザのホームディレクトリを削除 (ディレクトリの所有者が指定されたユーザのものだった場合)。 /var/mail から、指定されたユーザの到着メールファイルを削除。 /tmp のような一時ファイル保存領域から、 指定されたユーザの所有するファイルを削除。 そして最後に、 /etc/group にある すべてのグループから、指定されたユーザを削除します。 指定されたユーザと同じ名前のグループで、 そのユーザが削除されると空のグループとなる場合は、 そのグループ自体が削除されます。 これは &man.adduser.8; によってユーザごとに作成される、 ユニークなグループに対応するものです。 スーパユーザアカウントの削除に rmuser を利用することはできません。 スーパユーザアカウントの削除はほとんどすべての場合、 大規模なシステムの破壊を意味するからです。 デフォルトでは、 どういう操作を行なっているか確認できる対話モードが使われます。 rmuser による対話的なアカウントの削除 &prompt.root; rmuser jru Matching password entry: jru:*:1000:1000::0:0:J. Random User:/home/jru:/usr/local/bin/tcsh Is this the entry you wish to remove? y Remove user's home directory (/home/jru)? y Updating password file, updating databases, done. Updating group file: trusted (removing group jru -- personal group is empty) done. Removing user's incoming mail file /var/mail/jru: done. Removing files belonging to jru from /tmp: done. Removing files belonging to jru from /var/tmp: done. Removing files belonging to jru from /var/tmp/vi.recover: done. &prompt.root; pw pw は、 ユーザやグループの作成、削除、 変更および表示を行なうことができ、 システムユーザファイルやシステムグループファイルの編集機能を持った コマンドラインのユーティリティです。 これはシェルスクリプトからの利用や、 直接コマンドを実行する際に便利に使えるように設計されたものです。 詳細はすべて &man.pw.8; に書かれています。 chpass chpass は、 パスワード、シェル、その他の個人情報といった、 ユーザデータベース情報を変更します。 システム管理者に限りスーパユーザ権限で chpass を用い、 他のユーザの情報やパスワードを変更することが可能です。 ユーザ名の他にオプションを指定しないと、 chpass はユーザ情報を編集するエディタを表示します。 そのエディタを終了すると、 chpass はユーザデータベース情報の変更を試みます。 スーパユーザによる対話的な chpass #Changing user database information for jru. Login: jru Password: * Uid [#]: 1000 Gid [# or name]: 1000 Change [month day year]: Expire [month day year]: Class: Home directory: /home/jru Shell: /usr/local/bin/tcsh Full Name: J. Random User Office Location: Office Phone: Home Phone: Other information: 通常のユーザは、この情報の限られた部分のみ変更が可能です。 また、変更できるのはそのユーザ自身の情報のみです。 通常のユーザによる対話的な chpass #Changing user database information for jru. Shell: /usr/local/bin/tcsh Full Name: J. Random User Office Location: Office Phone: Home Phone: Other information: chfn、 chsh はいずれも、 単に chpass へのハードリンクになっています。 また、ypchpass、 ypchfn および ypchsh も同様です。 NIS のサポートは自動的に行なわれますので、 コマンドの先頭に yp をつける必要はありません。 passwd passwd は、 ユーザが自分のパスワードを変更する通常の方法です。 スーパユーザ権限では、 他のユーザのパスワードを変更するのに使われます。 ユーザはパスワードを変更する前に、 もともと設定されていたパスワードを入力しなければなりません。 これはユーザがコンソールを離れた際に、 不審な人物によってパスワードが変更されることを防ぐためです。 passwd &prompt.user; passwd Changing local password for jru. Old password: New password: Retype new password: passwd: updating the database... passwd: done &prompt.root; passwd jru Changing local password for jru. New password: Retype new password: passwd: updating the database... passwd: done yppasswd は、 単に passwd へのハードリンクになっています。 NIS のサポートは自動的に行なわれますので、 コマンドの先頭に yp をつける必要はありません。 ユーザへの制限と設定 quota がシステムで有効化されていると、 システム管理者はディスク使用の上限を設定し、 ユーザは自身のディスク使用量をチェックできるようになります。 quota については、quota の章に書かれています。 地域化 (localization) とは、 それぞれ異なる言語、キャラクタセット、 日付や時間の標準などに適応させるための環境設定を、 システム管理者やユーザが行なうことを指します。 地域化については、 地域化の章に書かれています。 diff --git a/ja_JP.eucJP/books/handbook/x11/chapter.sgml b/ja_JP.eucJP/books/handbook/x11/chapter.sgml index 22b9c74ca7..be64ac4e89 100644 --- a/ja_JP.eucJP/books/handbook/x11/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/x11/chapter.sgml @@ -1,1113 +1,1113 @@ X Window System この章では FreeBSD では、ユーザに強力なグラフィカルインタフェイスを提供するためにXFree86を採用しています。 XFree86 は X Window System のオープンソースな実装です。この章では FreeBSD における XFree86 のインストールと設定について解説します。XFree86 についての情報や、それがサポートするビデオハードウェアについては XFree86 の Web サイトをご覧ください。 この章を読めば以下のことがわかります。 X Window System の様々なコンポーネントと、それらが互いにどのように連携しているか。 XFree86 のインストールと設定について 様々なウィンドウマネージャのインストール方法 XFree86 での TrueType フォントの使い方 GUI ログイン (XDM) のセットアップ方法 この章を読み始める前に以下のことに注意してください。 サードパーティ製ソフトウェアのインストール方法について知っていること ()。 X を理解する 初めて X を使う場合、Microsoft Windows や Mac OS といった他の GUI 環境に慣れている人は多少ショックを受けるでしょう。 様々な X のコンポーネントについての詳細の全てや、それらがどのようにやり取りするかについては理解する必要はありませんが、基本的なことをいくつか知っていると X を使う際に強力な武器になるでしょう。 なぜ X? X は、UNIX 用に書かれた最初のウィンドウシステムではありませんが、最もポピュラーなものです。X のオリジナルの開発チームは X を書く前に別のウィンドウシステムを開発していました。そのシステムの名前は W (Windowの W) です。X は単にローマ字でその次の文字だというだけなのです。 X は X、X Window System、X11、もしくはその他の用語で呼ぶことができます。X11 を X Windows と呼ぶと気を悪くする人もいます。詳しくは &man.X.1; をご覧ください。 X のクライアント/サーバモデル X は最初からネットワークを意識してデザインされており、クライアント - サーバモデルを採用しています。 X では、X サーバはキーボードやモニター、マウスが接続されたコンピュータ上で動きます。このサーバはディスプレイの表示を管理したり、キーボード、マウスなどからの入力を処理したりします。各 X アプリケーション (XTerm や Netscape など) は クライアントになります。クライアントはこの座標にウィンドウを描いてくださいといったメッセージをサーバへ送り、サーバはユーザが OK ボタンを押しましたといったようなメッセージを送り返します。 家庭や小さなオフィスのような環境で、1 台しかコンピューターがないという場合には、X サーバと X クライアントは同じコンピューター上で動くことになるでしょう。しかし、X サーバを非力なデスクトップコンピューターで動かし、X アプリケーション (クライアント) は例えばオフィス全体を捌くような高機能で高価なマシンで動かすことも可能なのです。この場合、X のクライアントとサーバの通信はネットワーク越しに行なわれます。 これは、ある人々を混乱させることがあります。X での用語は彼らが想定するものとは正反対だからです。彼らはX サーバは地下にある大きなパワフルなマシンであり、X クライアントが自分たちのデスク上にあると想像するのです。 Xサーバとはモニターとキーボードがついているマシンのことであり、Xクライアントとはウィンドウを表示するプログラムだということを思い出してください。 X のプロトコルには、クライアントとサーバのマシンが同じ OS で動いていなければならないといったことを強制するものはなにもありませんし、同じ機種で動いている必要もありません。X サーバを Microsoft Windows や Apple の Mac OS で動かすことも可能ですし、そのようなソフトウェアもフリーのものから商用のまでいろいろとあります。 FreeBSD に付いてくる X サーバは XFree86 と呼ばれるもので、FreeBSD のライセンスに似たライセンスに従ってフリーで配布されています。FreeBSD 用の商用 X サーバも入手可能です。 X ウィンドウマネージャ X のデザイン哲学は UNIX のそれに非常によく似ており、ツールであってポリシーではないのです。 つまり、X はあるタスクがどのように達成されるべきかを示すものではありません。その代わり、ユーザにはツールが与えられ、それらをどうするかはユーザに委ねられているのです。 この哲学は、X ではスクリーン上でウィンドウがどのように見えるべきか、マウスでそれらをどうやって動かすか、ウィンドウ間を移動するのにどういうキーストロークを使うべきか (例えば Microsoft Windows における Alt Tab )、各ウィンドウのタイトルバーはどのように見えるべきか、それらはクローズボタンを持つべきかどうか、といったことを示すものではないというところまで拡大して解釈できます。 - その代わりに、X ではそういったことをウィンドウマネージャと呼ばれるアプリケーションに任せるのです。X 用のウィンドウマネージャは以下のようにたくさんあります。AfterStep、Blackbox、ctwm、Enlightenment、fvwm、Sawfish、twm、Window Maker、などなど。これらのウィンドウマネージャはそれぞれ異なるルックアンドフィールを持っていますし、いくつかはバーチャルデスクトップをサポートしていますし、いくつかはデスクトップのマネージメントにキーストロークをカスタマイズできたり、スタートボタンやそれに類するもの持っているものもありますし、テーマをサポートをしており新しいテーマを適用することによってルックアンドフィールを完全に変えることができるものもあります。これらのウィンドウマネージャやさらに多くのものはportsコレクションの x11-wm というカテゴリーからインストールすることが可能です。 + その代わりに、X ではそういったことをウィンドウマネージャと呼ばれるアプリケーションに任せるのです。X 用のウィンドウマネージャは以下のようにたくさんあります。AfterStep、Blackbox、ctwm、Enlightenment、fvwm、Sawfish、twm、Window Maker、などなど。これらのウィンドウマネージャはそれぞれ異なるルックアンドフィールを持っていますし、いくつかはバーチャルデスクトップをサポートしていますし、いくつかはデスクトップのマネージメントにキーストロークをカスタマイズできたり、スタートボタンやそれに類するものを持っているものもありますし、テーマのサポートをしており新しいテーマを適用することによってルックアンドフィールを完全に変えることができるものもあります。これらのウィンドウマネージャやさらに多くのものはportsコレクションの x11-wm というカテゴリーからインストールすることが可能です。 加えて、KDE や GNOME といったデスクトップ環境はともにそれぞれのデスクトップに統合された独自のウィンドウマネージャを持っています。 それぞれのウィンドウマネージャはまた異なる設定機構を備えており、手で設定ファイルを編集しなければならないものや、設定作業のほとんどを GUI ツールですることができるものもあります。少なくとも 1 つ (sawfish) は Lisp 言語の変種で書かれた設定ファイルを持っています。 フォーカスポリシー ウィンドウマネージャのもう一つの機能はマウスのフォーカスポリシーに関するものです。 全てのウィンドウシステムは、ウィンドウを選択しキーストロークを受け付けるようにするための方法が必要です。 そして、どのウィンドウがアクティブなのかを示す必要もあります。 よく知られているフォーカスポリシーは click-to-focus と呼ばれるもので、このモデルは Microsoft Windows で利用されており、あるウィンドウ内でマウスをクリックすればそのウィンドウがアクティブになる、というものです。 X は特定のフォーカスポリシーを採用していません。代わりにウィンドウマネージャがそれをコントロールします。それぞれのウィンドウマネージャが、それぞれのフォーカスポリシーをサポートしています。全てのものは click-to-focus をサポートしていますし、多くのものは他の方法もサポートしています。 最もポピュラーなフォーカスポリシーは次のものでしょう focus-follows-mouse マウスポインターの下にいるウィンドウがフォーカスされるというものです。ウィンドウは最前面にある必要はありません。フォーカスを変えるには他のウィンドウにマウスポインターを動かすだけです。クリックする必要はありません。 sloppy-focus これは focus-follows-mouse を少し拡張したものです。focus-follows-mouse では、マウスがルートウィンドウ (背景) に移動した時には、フォーカスされているウィンドウがなくなり、キーストロークは単に破棄されます。sloppy-focus であればポインターが別のウィンドウに移った時のみフォーカスが変わり、現在のウィンドウから出ただけでは変わりません。 click-to-focus アクティブなウィンドウはマウスクリックにより選択されます。 ウィンドウは持ち上げられ、他の全てのウィンドウの前にきます。 ポインターが別のウィンドウに動いた時でも、全てのキーストロークがこのウィンドウに届きます。 多くのウィンドウマネージャはこういったものに加え、他のポリシーもサポートしています。ウィンドウマネージャ自身のドキュメントもよく読んでください。 ウィジェット X のツールを提供してもポリシーは提供しないというアプローチは、各アプリケーションでスクリーンに現われるウィジェットにも適用されます。 ウィジェットはクリック可能であったり、他の方法で操作可能な全てのユーザインタフェイス用アイテムを指す用語です。ボタンやチェックボックス、ラジオボタン、アイコン、リスト、などがそうです。Microsoft Windows はこれらをコントロールと呼んでいます。 Microsoft Windows や Apple の Mac OS はともに非常に厳密なポリシーをウィジェットに課しています。アプリケーション開発者は共通のルックアンドフィールに確実に従うことを想定されているわけです。X では、グラフィカルなスタイルやウィジェットのセットが特定のものに合わせたりすることに対してそれほど意識していませんでした。 すなわち、X アプリケーションに共通のルックアンドフィールを期待してはいけません。いくつかのポピュラーなウィジェットセットやその亜種があります。MIT のオリジナルの Athena ウィジェットや Motif (Microsoft Windows をモデルにした、斜めになったエッジやグレイの陰影のウィジェットセットを持っている)、OpenLook などです。 比較的新しい X アプリケーションのほとんどが、KDE で使われている Qt や GNOME プロジェクトで使われている GTK のようにモダンな見た目を持ったウィジェットセットを使っています。この点で言えば、UNIX のルックアンドフィールは収斂されてきており、初心者がより簡単に使えるようになってきています。 XFree86 のインストール XFree86 をインストールする前にどのバージョンを動かすかを決めてください。XFree86 3.x は XFree86 におけるメンテナンスブランチです。これは非常に安定しており、非常にたくさんの数のグラフィックカードをサポートしているのですが、もう新しい機能は追加されません。XFree86 4.X はシステムを完全に見直して設計したものであり、フォント自体のもっと良いサポートやアンチエイリアスなどといった多くの新しい機能も追加されています。残念ながら、この新しいアーキテクチャーではビデオドライバーの書き直しが必要なため、3.X でサポートされていたいくつかの古いカードはまだサポートされていません。 FreeBSD のセットアッププログラムを使えば、OS のインストール時に XFree86 3.3.6 をインストールして設定することができます (に書かれています)。XFree86 4.x を使いたい場合、まずベースとなる FreeBSD をインストールしてから XFree86 のインストールを行うことになります。例えば、XFree86 4.X を ports コレクションからビルドしてインストールする場合には次のようにします。 &prompt.root; cd /usr/ports/x11/XFree86-4 &prompt.root; make all install clean 他には pkg_add ツールを用いたり、XFree86 の Webサイトで直接提供されているものを利用して XFree86 4.X のバイナリパッケージをインストールするという方法もあります。 この章の残りでは、XFree86 をどのように設定すればいいか、また productive なデスクトップ環境をどのように設定するかについて解説します。 Christopher Shumway 寄稿: XFree86 の設定 XFree86 4.X XFree86 はじめに XFree86 4.Xの設定を始める前に, 次の情報が必要となります。 モニターの仕様 ビデオアダプタのチップセット ビデオアダプタのメモリー 水平走査周波数 垂直同期周波数 モニターの仕様は、XFree86 がどの解像度とリフレッシュレートで動くかを決定するために用いられます。 こういった仕様は、通常はモニターに付いてくるドキュメントや製造元のWebサイトから取得することができます。必要なものは二つの数字の範囲、一つは水平走査周波数でもう一つは垂直同期周波数、です。 ビデオアダプタのチップセットは XFree86 がグラフィックハードウェアとやり取りするためにどのドライバーモジュールを使うかを定義します。ほとんどのチップセットが自動認識されますが、正常に認識されない時のために知っておくとよいでしょう。 ビデオメモリーは、グラフィックアダプタがどの解像度とどの色数で動くことができるかを決めます。 これは、ユーザが自分のシステムにおける制限を理解するために知っておくことが重要です。 XFree86 4.Xの設定 XFree86 4.X の設定は複数のステップの処理に分けられます。 まずは XFree86 に オプションを付けて初期設定ファイルを作りましょう。スーパーユーザになって次のようにしてください。 &prompt.root; XFree86 -configure これにより、現在のワーキングディレクトリに XF86Config.new という XFree86 の設定ファイルのスケルトンが生成されます。 XFree86 プログラムはシステム上のグラフィックハードウェアを検出し, そのハードウェア用の適切なドライバーを読み込む設定ファイルを作ります。 次のステップは、作成した設定ファイルで XFree86 が動くことを確認することです。 そのためには以下のようにします。 &prompt.root; XFree86 -xf86config XF86Config.new 黒とグレーのグリッドと X のマウスポインターが現われればその設定は成功です。 テストから抜け出すためには単に次のキーを同時に押します。 Ctrl Alt Backspace XFree86 4 のチューニング 次は XF86Config.new を好みに合うように調整します。 &man.emacs.1; や &man.ee.1; のようなテキストエディターでファイルを開いてください。 まずモニターの周波数を加えます。これらは水平と垂直の同期周波数と表現されるのが普通です。 これらの値は XF86Config.new の "Monitor" のセクションに次のように加えます。 Section "Monitor" Identifier "Monitor0" VendorName "Monitor Vendor" ModelName "Monitor Model" HorizSync 30-107 VertRefresh 48-120 EndSection HorizSync と VertRefresh というキーワードが設定ファイル中にない場合があります。その場合には, Horizsync キーワードの後には水平走査周波数の, VertRefresh キーワードの後には垂直同期周波数の正しい値を加えてください。 上の例では対象となるモニターの周波数が書かれています。 X はモニターが対応していれば DPMS (Energy Star) 機能を使うことができます。 'xset' プログラムでタイムアウトをコントロールしたり、強制的にスタンバイ、サスペンドや電源オフにすることができます。 モニターの DPMS 機能を有効にしたい場合は、"Monitor" のセクションに次の行を加えてください。 Option "DPMS" XF86Config XF86Config.new はエディターで開いたままにしておき, デフォルトの解像度と色数を好みで選びましょう。 Screen セクションに以下のように書きます。 Section "Screen" Identifier "Screen0" Device "Card0" Monitor "Monitor0" DefaultDepth 24 SubSection "Display" Depth 24 Modes "1024x768" EndSubSection EndSection DefaultDepth というキーワードはデフォルトで動く色数について記述するためのものです。 &man.XFree86.1; のコマンドラインスイッチ -bpp が使用された場合はこちらが優先されます。 Modes というキーワードは与えられた色数におけるデフォルトの解像度を記述しておくためのものです。 上の例ではデフォルトの色数はピクセルあたり24ビットであり、この色数での解像度は1024ピクセル×768ピクセルです。 - 1024x768の解像度で動かすためには DefaultDepth というキーワードに 24 という値を与えて書き加えおき, + 1024x768の解像度で動かすためには DefaultDepth というキーワードに 24 という値を与えて書き加えておき, "Display" サブセクションに求める Depth と Modes のキーワードを書いておきます。 ターゲットのシステムのフラフィックハードウェアによって定義されているように、VESAスタンダードモードのみがサポートされていることに注意してください。 最後に、設定ファイルを保存し、上の例にあるようにテストしてみてください。全てうまくいったなら、&man.XFree86.1; が見つけることができる共通の場所に設定ファイルを置きます。 これは、通常は /etc/X11/XF86Config や /usr/X11R6/etc/X11/XF86Config です。 &prompt.root; cp XF86Config.new /etc/X11/XF86Config 設定ファイルを共通の場所に置いたら、設定は完了です。 &man.startx.1; で XFree86 4.X を起動するために x11/wrapper ポートをインストールします。 また、XFree86 4.X を &man.xdm.1; で立ち上げることも可能です。 高度な設定 Intel i810 グラフィックチップセットの設定 Intel i810 graphic chipset Intel i810 統合チップセットを設定には、XFree86にカードを制御させるためにAGP プログラミングインタフェイスである agpgart が必要になります。 agpgart を利用するには、&man.kldload.8; を使って agp.ko というカーネルローダブルモジュールをカーネルにロードしておく必要があります。 これは、/boot/loader.conf に次のように書いておけば &man.loader.8; がブート時に自動的にやってくれます。 agp_load="YES" 次に、プログラミングインタフェイス用にデバイスノードを作る必要があります。 AGP のデバイスノードを作るには、/dev で &man.MAKEDEV.8; を次のように起動します。 &prompt.root; cd /dev &prompt.root; sh MAKEDEV agpgart これで他のグラフィックカードと同様に設定を行うことができるようになります。 もし XFree86 4.1.0 (もしくはそれ以降) を使っており, fbPictureInit といったようなシンボルが見つからないというメッセージが現われるなら, XFree86 設定ファイルで Driver "i810" の後に次のような行を入れてみてください。 Option "NoDDC" Murray Stokely 寄稿: XFree86 でのフォントの使用 Type1 フォント XFree86 に付いてくるデフォルトのフォントは通常のデスクトップパブリッシングアプリケーションにとっては理想的とは言えない程度のものです。 文字を大きくするとジャギーになりプロフェッショナルとは言えないようなものになりますし, Netscape での小さなフォントは頭が悪そうに見えます。 しかし、世の中には質の高い Type1 (PostScript) フォントがいくつかあり, XFree86 ではバージョン 3.X でも 4.X でもそれらを簡単に利用することができます。 例えば、URW フォントコレクション (x11-fonts/urwfonts) には高品質の Type1 フォント (Times Roman、Helvetica、Palatino など) が含まれています。 freefont コレクション (x11-fonts/freefont) にはもっとたくさんのフォントが含まれていますが, それらは Gimp のようなグラフィックソフトウェアで使用するためのものであり, スクリーンフォントとしては十分ではありません。さらに、XFree86 は簡単に TrueType フォントを使うように設定することも可能です。 後に出てくる TrueType フォントのセクション を参照してください。 上記の Type1 フォントコレクションを ports から入れる場合には次のコマンドを実行してください。 &prompt.root; cd /usr/ports/x11-fonts/urwfonts &prompt.root; make install clean freefont や他のコレクションでも同じようにします。 X サーバにこれらのフォントがあることを教えるには (XFree86 バージョン 3 の場合は /etc/, バージョン 4 では /etc/X11/ にある) XF86Config の適切な場所に次のような行を加えます。 FontPath "/usr/X11R6/lib/X11/fonts/URW/" 別の方法としては、X のセッション中に次のようなコマンドラインを実行します。 &prompt.user; xset fp+ /usr/X11R6/lib/X11/fonts/URW &prompt.user; xset fp rehash これは動くのですが、X のセッションが終了すると消えてしまいます。 消えないようにするには X の起動時に読み込まれるファイル (通常の startx セッションの場合は ~/.xinitrc, XDM のようなグラフィカルなログインマネージャを通してログインする時は ~/.xsession) に加えておきます。 三番目の方法は新しい XftConfig ファイルを使うことです。 これに関しては アンチエイリアスのセクションを参照してください。 TrueType フォント XFree86 4.X には TrueType フォントのレンダリング機能が組み込まれています。 この機能を実現するために二つの異なるモジュールがあります。 ここでは、"freetype" のほうがより他のフォントレンダリングバックエンドと似ているため, このモジュールを使うことにします。 freetype モジュールを使うためには /etc/X11/XF86Config ファイルに以下の行を追加するだけです。 Load "freetype" XFree86 3.3.X の場合, TrueType フォントサーバが別に必要となります。 Xfstt がよく使われるものです。 - Xfstt とインストールするのは簡単で, + Xfstt をインストールするのは簡単で, x11-servers/Xfstt ポートを利用してください。 さて、まずは TrueType フォント用のディレクトリ (例えば /usr/X11R6/lib/X11/fonts/TrueType) を作り、そこに TrueType フォントを全て放り込みましょう。 Macintosh の TrueType フォントは、そのままでは使うことができませんので注意してください。 XFree86 で使うには Unix/DOS/Windows 用のフォーマットでなければなりません。 ファイルを置いたら ttmkfdir を使って fonts.dir ファイルを作ってください。 このファイルにより、X は新しいファイルがイントールされたことを理解します。 ttmkfdir は FreeBSD Ports コレクション, x11-fonts/ttmkfdir、からインストールできます。 &prompt.root; cd /usr/X11R6/lib/X11/fonts/TrueType &prompt.root; ttmkfdir > fonts.dir 次に TrueType フォントのディレクトリをフォントパスに追加します。 上の Type1 フォントの場合と同じように, &prompt.user; xset fp+ /usr/X11R6/lib/X11/fonts/TrueType &prompt.user; xset fp rehash とするか、もしくは XF86Config ファイルに 行を追加するのです。 これで終わりです。Netscapeや Gimp、StarOffice といった全ての X アプリケーションから TrueType フォントを使うことができます。 (高解像度なディスプレイで見る Web ページ上のテキストみたいな) とても小さなフォントや (StarOffice にあるような) 非常に大きなフォントもかなり綺麗に見えるようになることでしょう。 フォントのアンチエイリアス XFree86 では 4.0.2 以降でフォントのアンチエイリアスをサポートしています。 今のところ、ほとんど全てのソフトがこの新しい機能を使うメリットを亨受するようにはなっていません。 しかし、Qt (KDE デスクトップ用のツールキット) はサポートしていますので, XFree86 4.0.2 以降と Qt 2.3 以降及び KDE を使う場合には全ての KDE/Qt アプリケーションでアンチエイリアスなフォントを使うことができます。 アンチエイリアスを使うように設定するには, /usr/X11R6/lib/X11/XftConfig ファイルを作ります (既にある場合には編集してください)。 このファイルを使えばいくつかの先進的な機能を使うことができるのですが, このセクションでは最も簡単なところだけを解説します。 まず、X サーバに対してアンチエイリアスをかけるべきフォントを指定します。 それぞれのフォントディレクトリに対して次のような行を加えます。 dir "/usr/X11R6/lib/X11/Type1" アンチエイリアスをかけたい他のフォントのディレクトリ (URW や truetype など) についても同じようにします。 アンチエイリアスはスケーラブルなフォント (基本的には Type1 と TrueType) にのみ有効ですので、ビットマップフォントのディレクトリは加えないようにしてください。 ここに含めたディレクトリは XF86Config ではコメントアウトします。 アンチエイリアスをかけることによって境界が少しぼやけ, そのためにとても小さなテキストはさらに読みやすくなり, 大きなフォントではギザギザが消えるのです。 しかし、普通のテキストにかけた場合には目が疲れることになります。 9から13ポイントのサイズのフォントについて、アンチエイリアスをかけないようにするには次の行を加えます。 match any size > 8 any size < 14 edit antialias = false; いくつかの等幅フォントは, アンチエイリアスをかけるとスペーシングがうまくいかなくなる場合があります。 特に KDE でその傾向があるようです。 解決策の一つとして、そういったフォントのスペーシングを100に設定する方法があります。 そうするためには次の行を加えてください。 match any family == "fixed" edit family =+ "mono"; match any family == "console" edit family =+ "mono"; (これによりfixedというフォントに他の "mono" という名前のエイリアスを付けます) そして次の行も加えてください。 match any family == "mono" edit spacing = 100; 等幅フォントが必要な時にはつねに Lucidux を使うように (このフォントは実際見目もよく、スペーシングの問題もありません) するためには最後の行を次のように変更します (最後の行は異なるものに同じファミリー名を付けています)。 match any family == "mono" edit family += "LuciduxMono"; match any family == "Lucidux Mono" edit family += "LuciduxMono"; match any family == "LuciduxMono" edit family =+ "Lucidux Mono"; 最後に、このファイルを自分の .xftconfig として保存し、次のコマンドを追加します。 includeif "~/.xftconfig" 最後に一つ。LCD スクリーンではサブピクセルサンプリングが必要な場合があります。 これは、基本的には (水平方向に分かれている) 赤、緑, 青の各コンポーネントを別々に扱うことによって水平方向の解像度を良くするというもので, そうすることによって劇的な結果が得られます。 これを有効にするには XftConfig ファイルに次の行を加えます (ディスプレイの種類にもよりますが最後は ``rgb'' ではなく ``bgr''や ``vrgb''、``vbgr'' の場合もあるので、試してみて最も良いものを使ってください)。 match edit rgba=rgb; アンチエイリアスは、次に X サーバを立ち上げた時から有効になります。 しかし、上でも述べたようにその恩恵を受けるにはプログラム側での対処も必要です。 今のところ Qt は対応しているため、KDE 環境全体でアンチエイリアスのかかったフォントを用いることができます (KDE についての詳しいことは をご覧ください)。 gtk+ を同じようにするパッチもありますので、そのパッチを当てた gtk+ を使ってコンパイルし直せば GNOME 環境や Mozilla もまたアンチエイリアスなフォントを使うことができます。 実際には x11/gdkxft という port があり, リコンパイルしなくてもアンチエイリアスなフォントを使うことができます。 詳しくは をご覧ください。 アンチエイリアスは、FreeBSD や XFree86 ではまだ新しい機能ですが、その設定はもっと簡単になるでしょうし, すぐにもっとたくさんのアプリケーションがサポートするようになるでしょう。 Seth Kingsley 寄稿: X ディスプレイマネージャ 概要 X ディスプレイマネージャ (XDM) は X Window System のオプショナルな一部分であり、ログインセッションの管理に用います。 最低限の機能を実装した X 端末やデスクトップ, 大規模なネットワークディレプレイサーバといった場面ではこれが有用です。 X Window System はネットワークとプロトコルから独立しているため, ネットワークで繋がれた X のクライアントとサーバを動かすための設定はかなり幅が広くなります。 XDM はどのディスプレイサーバに接続するかを選択でき、ログイン名とパスワードの組み合わせなど認証情報を入力できるグラフィカルなインタフェイスを提供しています。 XDM がユーザに &man.getty.8; (詳しくはをご覧ください) と同じ機能を提供することを考えてみてください。 つまり、ディスプレイ上でシステムへのログインができ、ユーザの代わりにセッションマネージャ (通常は X のウィンドウマネージャ) を起動することができるのです。 それからXDMは、ユーザが作業を終えてディスプレイからログアウトする合図を送ってきてプログラムが終了するのを待ちます。 この時点で、XDM は次にログインするユーザのためにログイン画面や chooser 画面を表示することができるのです。 XDM の使用 XDM のデーモンプログラムは /usr/X11R6/bin/xdm にあります。 このプログラムは root になればいつでも起動することができ, ローカルマシン上のディスプレイの管理を始めます。 マシンをブートする際、いつも XDM を起動したい場合には、/etc/ttys にそのためのエントリを加えておくのが簡単です。 このファイルのフォーマットや使用方法についての詳細は を参照してください。デフォルトの /etc/ttys ファイルには仮想端末上で XDM のデーモンプログラムを起動するための行: ttyv8 "/usr/X11R6/bin/xdm -nodaemon" xterm off secure があります。このエントリーはデフォルトでは無効になっており, 有効にするには 5 番目のカラムを off から on にし、 の指示に従って &man.init.8; を再起動します。最初のカラムはこのプログラムが管理する端末の名前で, この場合 ttyv8 になります。 つまり、XDM は 9 番目仮想端末で起動されるということです。 XDM の設定 XDM の設定用ディレクトリは /usr/X11R6/lib/X11/xdm です。 このディレクトリには XDM の振る舞いや見た目を変更するために用いられるいくつかのファイルがあります。 だいたいは以下のような感じです。 ファイル 説明 Xaccess クライアント認証のルールセット Xresources デフォルトの X リソース Xservers 管理すべきリモートやローカルのディスプレイのリスト Xsession デフォルトのログイン時のセッションスクリプト Xsetup_* ログインインタフェイスの前にアプリケーションを起動するためのスクリプト xdm-config このマシンで動いている全てのディスプレイのグローバルな設定 xdm-errors サーバプログラムによって生成されるエラー xdm-pid 現在動いている XDM のプロセス ID このディレクトリにはまた、XDM の動作中にデスクトップをセットアップするために用いられるスクリプトやプログラムがいくつかあります。 それぞれのファイルの目的を簡単に解説しましょう。 正確な文法や使い方は &man.xdm.1; に記述されています。 デフォルトの設定では,単純な四角のログインウィンドウがあり, そこにはマシンのホスト名が大きなフォントで表示され、Login: と Password: のプロンプトがその下に表示されています。 XDM スクリーンのルックアンドフィールを変えるにはここから始めるのがいいでしょう。 Xaccess XDM がコントロールするディスプレイに接続するためのプロトコルは X Display Manager Connection Protocol (XDMCP) と呼ばれます。 このファイルにはリモートのマシンからの XDMCP 接続をコントロールするためのルールセットが書かれます。 デフォルトでは、どんなクライアントからの接続も許可するようになっていますが, xdm-config を変更してリモートからのコネクションを待ち受けるようにしない限り問題ではありません。 Xresources これはディスプレイの chooser とログインスクリーン用の application-defaults ファイルです。 このファイルでログインプログラムの見た目を変更することができます。 フォーマットは XFree86 のドキュメントで記述されている app-defaults ファイルのものと同じです。 Xservers これは、chooser が選択肢として提供するリモートのディスプレイの一覧です。 Xsession XDM でログインした後に実行されるデフォルトのセッションスクリプトです。 通常、各ユーザは ~/.xsessionrc というカスタマイズしたセッションスクリプトを持っており、こちらが優先されます。 Xsetup_* これらは chooser やログインインタフェイスが表示される前に自動的に実行されます。 それぞれのディスプレイには, Xsetup_ に続けてローカルのディスプレイ番号を付けたもの (例えばXsetup_0) を名前とするスクリプトがあります。 典型的な使い方は xconsole のようなバックグラウンドで動かすプログラムを一つか二つ起動することです。 xdm-config app-defaultsの書式で書かれた、このインストレーションで管理されるすべてのディスプレイに適用される設定を保持しています。 xdm-errors このファイルには XDM が起動しようとしている X サーバからの出力が書き出されます。 XDM が起動しようとしているディスプレイがなんらかの理由でハングした場合, このファイルのエラーメッセージを見てください。 そういったメッセージは各ユーザの ~/.xsession-errors にもセッション毎に書き出されます。 ネットワークディスプレイサーバの起動 あるディスプレイサーバに他のクライアントが接続することができるようにするために, アクセスコントロールのルールを編集し、コネクションリスナーを有効にします。 デフォルトでは保守的な設定になっています。 XDM がそういったコネクションを待ち受けるようにするためには xdm-config にある次の行をコメントアウトします。 ! SECURITY: do not listen for XDMCP or Chooser requests ! Comment out this line if you want to manage X terminals with xdm DisplayManager.requestPort: 0 そして、XDM を再起動します。 app-defaults ファイルにおけるコメントは ! であっていつものような # ではないことに注意してください。 アクセス制限はもっと厳しくしたいかもしれません。 Xaccess にある例を参考にしたり、オンラインマニュアル &man.xdm.1; を参照したりしてください。 XDM の代わりになるもの デフォルトの XDM に代わるものがいくつかあります。 一つは KDM (KDE に付属しています) はその一つであり、この章の後ろで解説します。 KDM はログイン時にウィンドウマネージャを選ぶことができるのに加え, 見た目もかなり綺麗にしてくれます。 Valentino Vaschetto 寄稿: デスクトップ環境 このセクションでは、FreeBSD 上の X で利用可能ないくつかのデスクトップ環境について解説します。 デスクトップ環境とは、単なるウィンドウマネージャから KDE や GNOME といったような完全なデスクトップアプリケーションスイートまでカバーします。 GNOME GNOME について GNOME はユーザフレンドリーなデスクトップ環境で, ユーザはコンピューターを簡単に使ったり設定したりできるようになります。 GNOME にはパネル (アプリケーションを起動したり状態を表示したりするもの) 、デスクトップ (データやアプリケーションが置かれる場所), 標準的なデスクトップツールやアプリケーションのセット, そしてアプリケーションが互いにうまくやり取りできるような仕組みが含まれています。 他の OS や環境に慣れている人でも GNOME の提供するグラフィック環境であれば心地よく感じるでしょう。 GNOME のインストール GNOME をインストールする最も簡単な方法は, 第 2 章で解説した FreeBSD のインストールメニューのデスクトップ環境の設定を通して行うことです。 また、package や ports を利用しても簡単にインストールできます。 GNOME packageをネットワークからインストールするには, 以下のようにするだけです。 &prompt.root; pkg_add -r gnome GNOME をソースから構築する場合, 次のように ports ツリーを使いましょう。 &prompt.root; cd /usr/ports/x11/gnome &prompt.root; make install clean GNOMEがインストールできたら、デフォルトのウィンドウマネージャの代わりに GNOME を起動するように X サーバに教えます。 自分の .xinitrc が既にある場合には、ウィンドウマネージャを起動するところの行を /usr/X11R6/bin/gnome-session を起動するように変更するだけです。 特にこのファイルを用意していない場合には次のようにすれば十分でしょう。 &prompt.user; echo "/usr/X11R6/bin/gnome-session" > ~/.xinitrc 次に、startx とタイプすれば GNOME デスクトップ環境が起動します。 もし XDM のようなディスプレイマネージャを使っているなら, この方法ではうまくいきません。その代わり、実行可能な .xsession というファイルを作成し, 同じコマンドを起動するようにします。 そのためには、このファイルを編集してウィンドウマネージャを /usr/X11R6/bin/gnome-session で置き換えます。 &prompt.user; echo "#!/bin/sh" > ~/.xsession &prompt.user; echo "/usr/X11R6/bin/gnome-session" >> ~/.xsession &prompt.user; chmod +x ~/.xsession もう一つの方法は、ログイン時にウィンドウマネージャを選択できるようにディスプレイマネージャを設定することです。 KDE2 の詳細についてのセクションで KDE のディスプレイマネージャである kdm を使ってどのようにすればいいのかを解説しています。 GNOME でアンチエイリアスなフォントの使用 XFree86 デスクトップでは、フォントのアンチエイリアスは KDE 環境ではじめて登場し標準のインストールでサポートされていますが, GNOME 環境のような gtk アプリケーションでも可能です。 最も素直なやり方は恐らく x11/gdkxft port にある libgdkxftライブラリ を使うことです。 この port をインストールしたら /usr/X11R6/share/doc/gdkxft/README を注意深く読んでください。 あとは gtk アプリケーションにフォントのレンダリング関数を標準の libgdk.so よりも前に libgdkxft.so から探すようにさせるだけです。 これは、環境変数が正しい位置を指すようにするだけでできます。 Bourne シェル (/bin/sh) 系のシェルの場合, - (The Gimp を起動するなら) 次のようにタイプします。 + (Gimp を起動するなら) 次のようにタイプします。 &prompt.user; LD_PRELOAD=/usr/X11R6/lib/libgdkxft.so gimp csh 系のシェルであれば次のようにしてください。 &prompt.user; setenv LD_PRELOAD /usr/X11R6/lib/libgdkxft.so &prompt.user; gimp もしくは, LD_PRELOAD=/usr/X11R6/lib/libgdkxft.so export LD_PRELOAD というコマンドを、X をどのように立ち上げるかに依って .xinitrc や .xsession, もしくは /usr/X11R6/lib/X11/xdm/Xsession に書いておきます。 ただし、こうすると GTK の Linux バイナリを起動する時にトラブるかもしれません。 KDE2 KDE2 について KDE は最近の簡単に使えるデスクトップ環境です。 KDE によりユーザは以下のようなメリットを亨受します。 美しい現代風のデスクトップ ネットワーク透過なデスクトップ KDE デスクトップやそのアプリケーションを使う際の便利で統一されたヘルプにアクセスできるような統合されたヘルプシステム 全ての KDE アプリケーションで統一されたルックアンドフィール 標準化されたメニュー、ツールバー、キーバインディング、カラースキームなど 国際化: KDE は 40を越える言語で利用可能 集中したダイアログベースのデスクトップ設定 膨大な数の KDE アプリケーション KDE はその KParts テクノロジーをベースにしたオフィススイートを持っており, それにはスプレッドシート、プレゼンテーションアプリケーション、オーガナイザー, ニュースクライアントなどが含まれています。 KDE にはまた Konqueror と呼ばれる Web ブラウザーも付属しており、これは Unix システム上の他の Web ブラウザーの強力な競争相手です。 KDE の詳細については KDE の Webサイトをご覧ください。 KDE2 のインストール GNOME や他のデスクトップ環境と全く同じように, KDE をインストールする最も簡単な方法は第 2 章にある FreeBSD のインストールメニューでのデスクトップ設定を利用することです。 またまた同じことですが、package や ports コレクションからインストールするのも簡単です。 ネットワーク越しに KDE2 package をインストールするには次のようにします。 &prompt.root; pkg_add -r kde2 ソースから KDE を構築するには次のように ports ツリーを使いましょう &prompt.root; cd /usr/ports/x11/kde2 &prompt.root; make install clean KDE2 がインストールできたら X サーバに、デフォルトのウィンドウマネージャの代わりにこのアプリケーションを立ち上げるように教えます。 .xinitrc ファイルを次のように編集しましょう。 &prompt.user; echo "/usr/X11R6/bin/startkde" > ~/.xinitrc さぁ、これで startx でいつ X Window System を立ち上げても KDE2 がデスクトップになります。 xdm のようなディスプレイマネージャを使っている場合, 設定は少し異なります。 代わりに .xsession ファイルを編集しましょう。 kdm 用の説明はこの章の後のほうにあります。 KDE2 の詳細について さぁ、KDE2 のインストールができました。 ほとんどのことはヘルプページを見たりいろんなメニューをつつけばわかるでしょう。 Windows や Mac のユーザにも簡単なはずです。 KDE2 の最も良いリファレンスはオンラインドキュメントです。 KDE には独自の Web ブラウザー Konqueror が付属してますし、膨大な数の便利なアプリケーションや詳しいドキュメントもあります。 このセクションの残りではなんとなく使っているだけでは理解し難い技術的なところを解説します。 KDE ディスプレイマネージャ マルチユーザシステムの管理者であれば、ユーザを迎えるにあたってグラフィカルなログインスクリーンが欲しいと思うかもしれません。 xdm は上で述べたようにその目的で使うことができます。 しかしながら、KDE にはその代わりになる KDM が付いており、より魅力的な見た目で、ログイン時のオプションもたくさんあります。 特に、(メニューを使って) ログイン後にどのデスクトップ環境か (KDE2 や GNOME など) を簡単に選ぶこともできます。 まず最初に root で KDE2 のコントロールパネル kcontrol を起動しましょう。 一般には X 環境全体を root で動かすのは安全ではありませんので, ウィンドウマネージャは普通のユーザで起動しておいて (xterm や KDE の konsole のような) ターミナルウィンドウを開き、su コマンドで root になり (そのユーザは wheel グループに入ってなければなりません) kcontrol とタイプします。 左側にあるシステム と書かれたアイコンをクリックし, ログインマネージャ をクリックします。 右側には様々な設定オプションがあり、これらについては KDE のマニュアルに細かく解説されています。右側にある セッション をクリックしてください。 新規追加 をクリックして様々なウィンドウマネージャやデスクトップ環境を加えます。 これらはただのラベルですので startkde や gnome-session ではなく KDE や GNOME とできます。 failsafe というラベルも入れてください。 他のメニューでも遊んでみてください。それらはだいたい見た目に関するもので, 見ればわかります。終わったら下のほうにある 適用 ボタンをクリックしてコントロールセンターを終了します。 (KDE や GNOME といった) ラベルが何かを kdm が確実に理解してくれるように, xdm で使われているファイルを編集します。 KDE 2.2 では、これは変更され kdm は独自の設定ファイルを持ちます。 詳しくは KDE 2.2 のドキュメントを参照してください。 ターミナルウィンドウで root で /usr/X11R6/lib/X11/xdm/Xsession ファイルを編集します。 中ほどに次のような行があるはずです。 case $# in 1) case $1 in failsafe) exec xterm -geometry 80x24-0-0 ;; esac esac このセクションにもう少し行を追加する必要があります。 KDE2 や GNOME というラベルが付いてると仮定すると, 以下の行を追加してください。 case $# in 1) case $1 in kde) exec /usr/local/bin/startkde ;; GNOME) exec /usr/X11R6/bin/gnome-session ;; failsafe) exec xterm -geometry 80x24-0-0 ;; esac esac KDE を尊重してログイン時のデスクトップのバックグラウンドを変える場合には /usr/X11R6/lib/X11/xdm/Xsetup_0 に次の行を加えます。 /usr/local/bin/kdmdesktop 最後に、次のブート時で立ち上がるように /etc/ttys に kdm を書きます。 上の xdm のセクションの解説で /usr/X11R6/bin/xdm となっている部分を /usr/local/bin/kdm とすればいいだけです。 アンチエイリアスフォント 4.0.2 以降、XFree86 ではその "RENDER" 拡張によってアンチエイリアスがサポートされています。 (KDE で利用されているツールキットである) Qt では 2.3 以降でこの拡張がサポートされています。 その設定は X11 フォントでのアンチエイリアスに関して で解説されています。従って最新のソフトウェアであれば KDE2 デスクトップ上でアンチエイリアスを利用することが可能なのです。 KDE2 のメニューから 設定 -> ルックアンドフィール -> フォント と辿り, フォントとアイコンをアンチエイリアス表示 をクリックしてください。 KDE の一部になっていない Qt アプリケーションの場合, QT_XFT という環境変数をプログラムを起動する前に設定する必要があります。 XFCE XFCE について XFCE は GNOME で使われている GTK ツールキットをベースにしたデスクトップ環境ですが、非常に軽く, 使用や設定が簡単なのにも関わらずシンプルで効率的なデスクトップです。 見ためとしては商用 Unix システムが採用している CDE にかなり似ています。XFCE の機能のいくつかを下に挙げておきます。 シンプルで使いやすいデスクトップ マウスのドラッグアンドドロップなどで全ての設定が可能 CDE に似たメインパネルとメニューやアプレット、ランチャー 統合されたウィンドウマネージャ、ファイルマネージャ、サウンドマネージャと GNOME 準拠のモジュールなど (GTK なので) テーマをサポート 速くて軽くて効率的: 古いマシンや遅いマシン、メモリーの限られたマシン向き XFCE に関する詳しい情報は XFCE の Web サイトから得られます。 XFCE のインストール (この文章を書いている時点で) xfce のバイナリーパッケージがあります。インストールするにはただ次のようにタイプするだけです &prompt.root; pkg_add -r xfce また、ports コレクションを利用してソースから作ることも可能です &prompt.root; cd /usr/ports/x11-wm/xfce &prompt.root; make install clean 次に X が起動した時に XFCE が起動されるように設定します。 次のようにしてください。 &prompt.user; echo "/usr/X11R6/bin/startxfce" > ~/.xinitrc 次に X が起動する時 XFCE のデスクトップが立ち上がります。 上と同様に、xdm のようなディスプレイマネージャを使っている場合には GNOME のセクションに書いてあるのと同じように .xsession ファイルを作り、/usr/X11R6/bin/startxfce を起動するようにします。 もしくは、kdm のセクションにあるようにディスプレイマネージャから XFCE を選ぶことができるように設定します。