diff --git a/ja_JP.eucJP/books/design-44bsd/book.sgml b/ja_JP.eucJP/books/design-44bsd/book.sgml index 988fa817e7..7973565be2 100644 --- a/ja_JP.eucJP/books/design-44bsd/book.sgml +++ b/ja_JP.eucJP/books/design-44bsd/book.sgml @@ -1,2631 +1,2631 @@ %man; ]> 4.4BSD オペレーティングシステムの設計と実装 Marshall Kirk McKusick Keith Bostic Michael J. Karels John S. Quarterman 1996 Addison-Wesley Longman, Inc この文書は出版元の許可の下に The Design and Implementation of the 4.4BSD Operating System の第二章を抜粋したものです。 この抜粋の複製や再配布を出版元の明示的な許可なく行なうことは禁止されています。 この章で紹介されている各概念については 本の残りの部分に非常に詳細に書かれており、 BSD UNIX に興味を持つ読者にとって優れた参考文献の一つとなっています。 この本に関する詳細は出版元から提供されています。 そこで登録することで 関連書籍 のニュースを受け取ることも可能です。 また、Kirk McKusick 氏より BSD courses に関する情報も提供されています。 この文書の日本語化は FreeBSD 日本語ドキュメンテーションプロジェクトによって行なわれました。 日本語化の詳細はを参照してください。 The second chapter of the book, The Design and Implementation of the 4.4BSD Operating System is excerpted here with the permission of the publisher. No part of it may be further reproduced or distributed without the publisher's express written permission. The rest of the book explores the concepts introduced in this chapter in incredible detail and is an excellent reference for anyone with an interest in BSD UNIX. More information about this book is available from the publisher, with whom you can also sign up to receive news of related titles. Information about BSD courses is available from Kirk McKusick. 4.4BSD の設計の概要 4.4BSD の機能とカーネル 4.4BSD カーネルは 4 つの基本機能を提供します。 それはプロセス、ファイルシステム、コミュニケーション、そしてシステムの起動です。 この節ではその 4 つの基本サービスのそれぞれについて この本で書かれていることを紹介します。 プロセスはアドレス空間上でのコントロールの流れを構成します。 生成や終了やその他のプロセスをコントロールするための仕組みは 4 章に述べます。システムは各プロセスの個別の仮想アドレス空間を 多重化します。このメモリ管理については 5 章で議論します。 ファイルシステムとデバイスへのユーザインタフェースは似ているため、 6 章ではそれらに共通する特徴について議論します。 7 章で説明するファイルシステムは、 ディレクトリが木構造になった階層で組織された名前付きのファイルと、 それらを扱うための操作からなります。 ファイルはディスクのような物理的なメディア上に存在します。 4.4BSD はディスク上のデータ配置法をいくつかサポートしており、 それは 8 章の中で述べます。 遠隔マシン上のファイルへのアクセスについては 9 章、 システムにアクセスするために使われている端末とその動作については 10 章で扱います。 UNIX で古くから提供されている通信機構には、 関連するプロセス間における単純で信頼性の高いバイトストリーム (11.1 節パイプを参照)および、 例外イベントの通知 (4.7 節シグナルを参照)があります。 また、4.4BSD は汎用のプロセス間通信機構も備えています。 11 章に述べるこの通信機構は、 ファイルシステムのものとは異なるアクセス機構を使用していますが、 一度接続が確立されれば、 プロセスからはパイプと同じようにアクセスすることができます。 12 章では汎用のネットワーク通信フレームワークについて扱っています。 これは通常、IPC 機構の下位レイヤとして使われているものです。 13 章では、ある特定のネットワークの実装について詳細に述べます。 いかなる実際のオペレーティングシステムにも、 どのように起動するかというような運用上の話題があります。 14 章では起動時や運用上の話題について述べます。 2.3 節から 2.14 節は 3 章から 14 章の内容を紹介するものです。 わたしたちは用語を定義し、基本的なシステムコールについて扱い、 開発の歴史について解説していきます。 そして最後に、中心となっている数多くの設計が、 どうやって選ばれたのかという理由を示します。 カーネル カーネル はプロテクトモードで動作し、 すべてのユーザプログラムが基本的なハードウェア (たとえば CPU、ディスク、端末、ネットワーク接続機器) および ソフトウェアを構成するもの (たとえばファイルシステム、 ネットワークプロトコル) へのアクセスを解決します。 カーネルは基礎的なシステムの機能を提供します。 それはプロセスを生成して管理を行い、ファイルシステムへのアクセス機能や コミュニケーション機能を提供します。 システムコール と呼ばれるこれらの機能は ライブラリのサブルーチンとしてユーザプロセスに現れます。 これらのシステムコールはプロセスがこれらの機能に対して持っている 唯一のインタフェースです。 システムコール機構の詳細は、 システムコールを実行することで実現されているもの以外の、 いくつかのカーネル内機構を説明した 3 章で扱います。 従来のオペレーティングシステムの用語における カーネル とは、 オペレーティングシステムにサービスを追加する実装を行うために必要な 最小限の仕組みだけを提供する、 ソフトウェアの小さな核となる部分のことです。 同時代のオペレーティングシステムの研究、たとえば Chorus , Mach , Tunis , V Kernel では、 このカーネルという機能による区分が、さらに論理的に複数に分けられています。 ファイルシステムやネットワークプロトコルといったサービスは、 その核もしくはカーネルに対するクライアントアプリケーションプロセスとして 実装されています。 4.4BSD カーネルは複数のプロセスには分割されていません。 この基本設計の決定は UNIX の最初のバージョンで行われました。 Ken Thompson によって行われた初めの 2 つの実装では メモリマッピングがなく、 ユーザおよびカーネル空間はハードウェアによる分離が行なわれていませんでした 。 メッセージ伝達システムは、 実際に実装されたカーネルとユーザプロセスのモデルと 同じくらい容易に実装することが可能でした。 単純化と性能のためにモノリシックカーネルが選ばれました。 また、初期のカーネルは非常に小さいものでしたが、 ネットワークのような機能が追加されることで 次第に大きくなっていきました。 現在のオペレーティングシステムの研究の最先端では そのようなサービスをユーザ空間に置くことで カーネルの大きさを減らそうとする傾向にあります。 ユーザは通常、 シェルと呼ばれる コマンド言語インタプリタや、 追加されたユーザアプリケーションプログラムを通してシステムと対話します。 そのようなプログラムやシェルは、プロセスを使って実装されています。 それらのプログラムの詳細についてはこの本の範囲を超えますので、 ここではカーネルについてのみ、考えることにします。 2.3 節、2.4 節では 4.4BSD カーネルによって提供されるサービスや最近の設計の概要について扱います。 そして後の章では、 4.4BSD に現れるそれらのサービスの設計と実装の詳細を説明します。 カーネルの構成 この節では、2 つの側面から 4.4BSD カーネルの構成を見ていきます。 ソフトウェアの静的側面、つまりカーネルを構築するためのモジュール によって提供された機能性による分類 その動的な機能、つまりユーザに提供されるサービスによる分類 カーネルの大部分は、システムコールを通してアプリケーションが アクセスするためのシステムサービスを実装しています。 4.4BSD では、このソフトウェアは次のような構成になっています。 基礎的なカーネル機能: タイマーおよびシステム時計の取り扱い、 記述子管理、そしてプロセス管理 メモリ管理のサポート: ページングとスワッピング 汎用のシステムインタフェース: I/O、コントロール、 記述子よって実現される多重化操作 ファイルシステム: ファイル、ディレクトリ、パス名の解釈、ファイルロック、 I/O バッファ管理 端末の取り扱いのサポート: 端末のインタフェースドライバと ラインディシプリン プロセス間通信機能: ソケット ネットワーク通信への対応: 経路制御等の通信プロトコル、一般的なネットワーク機能 4.4BSD カーネルにおける機種非依存なソフトウェア 分類 コード行数 カーネル内での割合 機種非依存部分の総計 162,617 80.4 ヘッダ 9,393 4.6 初期化部分 1,107 0.6 カーネルの機能 8,793 4.4 汎用のインタフェース 4,782 2.4 プロセス間通信 4,540 2.2 端末の取り扱い 3,911 1.9 仮想メモリ 11,813 5.8 vnode 管理 7,954 3.9 ファイルシステムネーミング 6,550 3.2 FFS 4,365 2.2 ログ構造化ファイルシステム 4,337 2.1 メモリベースのファイルシステム 645 0.3 cd9660 ファイルシステム 4,177 2.1 その他のファイルシステム (10) 12,695 6.3 ネットワークファイルシステム 17,199 8.5 ネットワーク通信 8,630 4.3 インターネットプロトコル 11,984 5.9 ISO プロトコル 23,924 11.8 X.25 プロトコル 10,626 5.3 XNS プロトコル 5,192 2.6
これらのカテゴリのソフトウェアのほとんどは機種非依存であり、しかも 異なるハードウェアアーキテクチャに移植できるものです。 カーネルの機種依存部分は本流のコードから分離されています。 特に、機種依存しているコードのどれを取っても、 特定のアーキテクチャのためのコードを含んでいません。 機種に依存する機能が必要なときには、機種に依存しないコードは 機種依存のコード内にあるアーキテクチャ依存の関数を呼び出します。 機種依存であるソフトウェアは次のものを含んでいます。 低レベルなシステム起動のための動作 トラップおよびフォールトの扱い プロセスの動作状態に関する低レベルな操作 ハードウェアデバイスの設定と初期化 I/O デバイスのランタイムサポート 4.4BSD カーネル内にある HP300 用の機種依存部分 分類 コード行数 カーネル内での割合 機種依存部分の総計 39,634 19.6 機種依存部分のヘッダ 1,562 0.8 デバイスドライバのヘッダ 3,495 1.7 デバイスドライバのソースコード 17,506 8.7 仮想メモリ 3,087 1.5 他の機種依存部分 6,287 3.1 アセンブリ言語で書かれたルーチン 3,014 1.5 HP/UX 互換機能 4,683 2.3
は HP300 用 4.4BSD カーネルを構成するソフトウェアのうち、 機種非依存の部分をまとめたものです。 2 列目の数値は C 言語のソースコード、ヘッダファイル、そして アセンブリ言語のものを表しており、 アセンブリ言語のものは 2% 以下しかありません。 また、 の統計が示しているように、 機種依存のソフトウェアは、HP/UX やデバイスサポートを除いて、 カーネルのうちわずかに 6.9% しかありません。 カーネルのごく小さな部分だけがシステムの初期化に専念します。 このコードはシステムが 起動する ときに用いられ、 カーネルがハードウェアやソフトウェアの環境構築をするための基本部分と なります (14 章参照)。 (制限された物理メモリを持つものには特に) オペレーティングシステムの中には これらの機能が実行された後にそのソフトウェアを廃棄してしまうか、 上から覆ってしまう ものもあります。 4.4BSD カーネルは、起動するために要したコードのためのメモリを再利用しません。 それは通常の機種ではカーネルのリソースのうち 0.5% に過ぎないからです。 そして、起動のためのコードはカーネルの中の一部分に固まってはいません。 それは全体にわたって散在しており、初期化されたときに論理的に関連していた 場所に存在します。 カーネル サービス カーネルレベルコードとユーザレベルコードの間の境界は、 基盤となるハードウェアで提供されるハードウェアレベルの保護機能によって 分離されています。 カーネルは、ユーザプロセスにとってアクセスしにくい切り離された アドレス空間で作動します。特権のある操作 -- たとえば I/O の開始や中央処理装置 (CPU) の停止 -- は、カーネルだけが利用可能です。 アプリケーションはシステムコールを用いてカーネルに サービスを要求します。システムコールは二次記憶装置にデータを 書き込むような複雑な作業や、現在の日時を返すような単純な作業を カーネルに実行させるために使用されます。 アプリケーションからは、 すべてのシステムコールが同期的に実行するように見えます。 つまりアプリケーションは、カーネルがシステムコールに関連した 動作をしているときには停止しています。 カーネルはシステムコール操作の一部を、 システムコールが戻った後に完了することもあります。 たとえば wirte システムコールは、 プロセスが待っている間に書き込むデータをユーザプロセスからカーネルバッファにコピーしますが、 通常、そのカーネルバッファがディスクに書き込まれる前にシステムコールから戻ります。 通常、システムコールは CPU の実行モードおよび現在のアドレス空間マッピングを変更する ハードウェアトラップとして実装されています。 ユーザによって与えられたシステムコール中のパラメータは、 使用される前にカーネルによって検証されます。 そのようなチェックはシステムの完全性を保証します。 カーネルへ渡されたパラメータはすべてカーネルのアドレス空間にコピーされます。 これは、システムコールの副作用により検証されたパラメータが 変更されないことを保証するためです。 システムコールの戻り値は、カーネルによってハードウェアレジスタ中に返されるか、 あるいはユーザが指定したメモリアドレスにコピーされる値で返されます。 カーネルへ渡されたパラメータのように 結果を戻すためにアプリケーションによって指定されたアドレスは、 それらが確実にアプリケーションのアドレス空間の一部である、 ということが検証されなければなりません。 システムコールを処理する間にカーネルがエラーに遭遇した場合、カーネルは ユーザにエラーコードを返します。 C プログラミング言語においては、このエラーコードが大域変数 errnoに格納されます。また、システムコールを 実行した関数は -1 の値を返します。 ユーザアプリケーションとカーネルは、互いに独立して動作します。 4.4BSD は I/O コントロールブロックや、 オペレーティングシステムに関連するその他のデータ構造体を アプリケーションのアドレス空間に格納しません。 ユーザレベルのアプリケーションはそれぞれ、 実行のための独立したアドレス空間を提供されます。 カーネルは、たとえば別のプロセスが走っている間そのプロセスを停止させ、 関係するプロセスに見えないようにするというような、 状態変更のほとんどを実現しています。 プロセス管理 4.4BSD はマルチタスク環境をサポートしています。 実行されたそれぞれのタスクまたはスレッドは プロセスと呼ばれています。 4.4BSD のプロセスのコンテキストは、 アドレス空間の内容とランタイム環境を含むユーザレベルの状態と、 スケジューリングのパラメータやリソース制御、識別情報を含む カーネルレベルの状態から構成されています。 コンテキストにはカーネルがプロセスにサービスを 提供する際に使用するすべてが含まれています。 ユーザはプロセスを生成し、その実行を制御し、 プロセスの実行状態が変化したときに通知を受け取ることができます。 すべてのプロセスにはプロセス ID (PID) と呼ばれる一意の値が割り当てられます。 この値はカーネルがユーザに実行状態の変化を報告するときにプロセスの身元を確認したり、 ユーザがシステムコールを実行するために参照する際に使用されます。 カーネルは他のプロセスのコンテキストを複製してプロセスを生成します。 新しく生成されたプロセスを 元の親プロセスの 子プロセスと呼びます。 プロセス生成時に複製されたコンテキストは、ユーザレベルのプロセスの実行状態と カーネルが管理しているプロセスのシステム状態の両方を含んでいます。 カーネルの状態に関する重要な構成要素については、4 章で解説しています。
プロセスのライフサイクル +--------------+ wait +--------------+ | 親プロセス |------------------------------->| 親プロセス |---> +--------------+ +--------------+ | ^ | fork | V | +--------------+ execve +--------------+ wait +----------------+ | 子プロセス |------->| 子プロセス |------->| ゾンビプロセス | +--------------+ +--------------+ +----------------+ プロセス管理システムコール
ではプロセスのライフサイクルを示しています。 プロセスは fork システムコールを用いて、 元のプロセスのコピーとして新しいプロセスを生成することができます。 fork は呼び出されると 二度戻ります。一方は親プロセスに子プロセスのプロセス ID を返し、 もう一方は子プロセスに 0 を返します。 プロセスの親子関係はシステム上のプロセスの組に階層構造をもたらします。 新しく生成されたプロセスはファイル記述子やシグナルハンドラの状態、 メモリレイアウトのような親が持っているリソースすべてを共有します。 親のコピーとして生成された新しいプロセスであっても、 別のプログラムをロードし実行することでより便利で特有の動作をすることもできます。 プロセスは execve システムコールを用いることで、 別のプログラムのメモリイメージで自分自身を上書きして、 新しい引数の組をその新しく作成したイメージに引き渡すことができます。 引数の一つは、システムで認識されるフォーマット (バイナリ実行ファイルや指定されたインタプリタプログラムの起動を促すファイル) をしたファイルの名前です。 プロセスは exit システムコールを実行することで、 親プロセスに 8 ビットの exit ステータスを送信して終了することができます。 もしプロセスが 1 バイト以上の情報を親プロセスに伝えたい場合には、 パイプやソケット、または仲介ファイルを用いて プロセス間通信チャネルをセットアップする必要があります。 プロセス間通信については 11 章で大きく取り上げています。 プロセスは、wait システムコールを用いて 子プロセスのいずれかが終了するまで実行を中断することができ、 wait システムコールは終了した子プロセスの PID と終了ステータスを返します。 親プロセスは、子プロセスが終了または異常終了したときのシグナルによる通知のされ方を調整できます。 wait4 システムコールを使用することで、 親プロセスは子プロセスの終了を引き起こしたイベントについての情報と、 子プロセスが生存期間の間に消費したリソースについての情報を取得することができます。 もし親プロセスが先に終了したためにリソースがオーファンド (親のない状態) になってしまった場合、カーネルは init という特別なプロセスにその子プロセスの 終了ステータスが渡されるよう調整します。これについては 3.1 節および 14.6 節を参照してください。 5 章では、カーネルがどのようにしてプロセスを生成し 消滅させるかについての詳細を述べています。 プロセスはプロセス優先度というパラメータに従って 実行をスケジュールされます。 この優先度はカーネルベースのスケジューリングアルゴリズムによって管理されています。 スケジューリングの優先度全体に重みづけする特別なパラメータ (nice) によって、ユーザはプロセスの実行優先度に影響を与えることができますが、 カーネルのスケジューリングポリシに従って、基本となる CPU リソースを共有する必要があります。 シグナル システムはプロセスに送ることができる シグナルのセットを定義しています。 4.4BSD におけるシグナルはハードウェア割り込みをモデルとしています。 プロセスはユーザレベルのサブルーチンをシグナルが送られるべき ハンドラとして指定できます。 シグナルが発生して、それがハンドラによって捕捉されている間は さらなるシグナルの発生はブロックされます。 シグナルを捕捉することで、現在のプロセスのコンテキストを保存し、 ハンドラを実行するための新たなコンテキストを構築することになります。 シグナルがハンドラに伝わると、そのハンドラはプロセスをアボートさせたり、 (おそらく大域変数に値を設定した後で) 実行中のプロセスに戻ることもできます。 ハンドラから戻ると、そのシグナルはブロックされなくなり、 発生する (そして捕捉される) ことが再び可能になります。 また、プロセスはシグナルを無視することや、 カーネルで定義されているデフォルトの動作を行なうように指定することができます。 ある種のシグナルのデフォルトでの動作はプロセスを終了させることです。 このような場合の終了は、事後のデバッグに使用できるようにその時のプロセスのメモリイメージを含んだ コアファイルの生成を伴います。 いくつかのシグナルは捕捉することも無視することもできません。 そのシグナルは、暴走したプロセスを停止させる SIGKILL や、 ジョブコントロールシグナルである SIGSTOP です。 プロセスはシグナルを特別なスタックに伝達させることも選択できます。 これにより、洗練されたソフトウェアスタック操作が可能です。 たとえば、コルーチンをサポートしている言語では それぞれのコルーチンにスタックを提供する必要があります。 その言語の実行システムは、4.4BSD で提供される単一のスタックを分割することで、 これらのスタックを割り当てることができます。 もしカーネルが独立したシグナルスタックをサポートしていない場合、 それぞれのコルーチンに割り当てられた領域を シグナルの捕捉に必要な分だけ拡張しなければなりません。 すべてのシグナルは、同じ優先度を持っています。 もし複数のシグナルが同時に未処理となっている場合は、 シグナルの届く順序は実装に依存します。 シグナルハンドラは、そのシグナルがブロックされるようにして実行しますが、 他のシグナルは依然発生可能です。 このメカニズムにより、プロセスは コードのクリティカルな部分を特定のシグナルの発生に対して保護することができるのです。 シグナルの設計と実装の詳細は、4.7 節で解説しています。 プロセスグループとセッション 複数のプロセスを組織してプロセスグループが作られます。 プロセスグループは端末へのアクセスの制御や 関係プロセスの集合にシグナルを送る手段を提供するのに使用されます。 プロセスは親プロセスからプロセスグループを引き継ぎます。 プロセスが自分自身または自分の子孫のプロセスグループを変更できるようにする メカニズムをカーネルは提供しています。 新しいプロセスグループを作成することは簡単です。 新しいプロセスグループの値はたいてい 作成したプロセスのプロセス ID となります。 プロセスグループにおけるプロセスの集合は、ジョブと呼ばれることがあり、 シェルのような高レベルのシステムソフトウェアで操作されます。 シェルによって生成されるよくある類のジョブは、いくつかのプロセスをパイプでつないだ パイプラインで、最初のプロセスの出力が 2 番目の入力となり、 2 番目の出力が 3 番目の入力となり、4 番目も同様に… というものです。 シェルはパイプラインの各段階においてプロセスを fork して、 これらすべてのプロセスを別個のプロセスグループにおくことで このようなジョブを生成します。 ユーザプロセスは、単独のプロセスに送る場合と同様に プロセスグループのそれぞれのプロセスにまとめてシグナルを送ることができます。 指定されたプロセスグループに属するプロセスが そのプロセスグループに影響するソフトウェア割り込みを受け取ると、 それによってプロセスグループは実行を中断や再開をしたり、 割り込みを受けたり、終了させられたりします。 端末にはプロセスグループ ID が割り当てられています。 この ID は、端末に関連づけられたプロセスグループの ID が通常セットされます。 ジョブコントロール機能を持つシェルは、同じ端末に関連づけされた プロセスグループを多数作成することができます。 その端末は、これらのプロセスグループに属するプロセスの制御端末となります。 プロセスは、端末のプロセスグループ ID とそのプロセスのプロセスグループ ID が一致したときのみ、 制御端末を記述子から読むことができます。 もしプロセスグループ ID が一致していなければ、 プロセスがその端末から読み込もうとする際にブロックされます。 端末のプロセスグループ ID を変更することで、 シェルはいくつかの異なるジョブの間で端末を調停することができます。 この調停はジョブコントロールと呼ばれ、 プロセスグループとともに 4.8 節で解説しています。 関連するプロセスの集合をプロセスグループとしてまとめることができるのと同じように、 プロセスグループの集合をセッションとしてまとめることができます。 セッションのおもな用途は、デーモンプロセスとその子プロセスに対して隔離した環境を作り出したり、 ユーザのログインシェルとそのシェルが作り出すジョブをひとまとめにすることです。 メモリ管理 それぞれのプロセスはプロセスごとのプライベートアドレス空間を持っています。 アドレス空間は、最初に論理的な3つのセグメントに分割されます: テキスト、 データ、および スタックです。 テキストセグメントは読み出し専用で、プログラムの命令を含んでいます。 データ及びスタックセグメントは読み取り書き込みともに可能です。 データセグメントには 初期化されているデータと初期化されていないデータがあるのに対し、 スタックセグメントはランタイムスタックを保持します。 ほとんどのマシンでは、プロセスが実行するとともに、 カーネルによってスタックセグメントは自動的に拡張されます。 プロセスはシステムコールによりデータセグメントを拡張する事が可能ですが、 セグメントの内容がファイルシステムからのデータである場合、あるいは デバッグ時に限りプロセスはそのテキストセグメントのサイズを変更することができます 子プロセスのセグメントの初期の内容は親プロセスのセグメントのコピーです。 プロセスアドレス空間の全内容はプロセスが実行するのには必要がありません。 プロセスがメインメモリにおいて保持されていないアドレス空間の一部を参照する場合、 システムはメインメモリーからメモリの中の必要な情報を ページ につけます。 システムリソースが不足する場合、システムは利用可能な資源を維持するために2レベルのアプローチをします。 適度の量のメモリが利用可能な場合でこれらの資源が最近使用されていない場合、 システムはプロセスからメモリリソースを解放します。 メモリー不足が深刻だった場合、システムはプロセスの全情況を２次キャッシュの スワップ に頼ります。 ページング と スワップ の交換はシステムによって行われた、プロセスに有効です。 プロセスは実行援助として予期された将来のメモリ利用についてシステムに助言するかもしれません。 BSDメモリ管理設計の決定 疎の広いアドレス空間のサポート、 メモリマップファイル、共有メモリは、 4.2BSD に要求されたものの一つでした。 独立したプロセス群がプロセスのアドレス空間をファイルにマッピングし、 それの共有を可能にする mmap と呼ばれるインタフェースが規定されました。 複数のプロセスが同じファイルにプロセスのアドレス空間をマッピングした場合、 一つのプロセスがファイルにマッピングされたアドレス空間の一部分に対して 加えた変更は、通常のファイルがそうであるのと同様、 同じ部分をマッピングしている他のプロセスにも反映されます。 しかし結局、4.2BSDは mmap インタフェースを含まない形でリリースされました。 これはネットワークのような他の機能を実現する方が重要で、 時間的な余裕がなかったからです。 mmap インタフェースの開発は、4.3BSD の作業の間も続けられました。 40 社を超える会社と研究グループが、 Berkeley Software Architecture Manual に記載されたアーキテクチャの改訂版を策定する議論に参加し、 いくつかの企業はその改訂版のインタフェースを実装しました 。 しかし、またもや時間的な問題により 4.3BSD への mmap インタフェースの実装は見送られました。 もちろん既存の 4.3BSD 仮想記憶システムにそのインタフェースを組み込むことは 可能だったのですが、4.3BSD の仮想記憶システムの実装は 10 年近く前のものであったため、開発者たちはそれを組み込まないことに決定したのです。 4.3BSD の仮想記憶システムはローカルに接続されたディスク装置は高速・大容量・安価で、 コンピュータのメモリは小容量・高価であるという仮定に基づいて設計されており、 そのため、その設計はメモリ利用量を節約できる代わりに 余分なディスクアクセスを生成してしまうものでした。 また、この実装は VAX のメモリ管理ハードウェアに強く依存するもので、 他のコンピュータアーキテクチャへの移植が困難でした。 最後にもう一つ付け加えるなら、この仮想記憶システムは 現在普及がすすみ重要になってきている密結合マルチプロセッサに 対応するように設計されていなかったのです。 古い仮想記憶システムの実装を改良しようという試みは、 ますます失敗が運命づけられたように思われました。 その一方で、完全に新しい設計は大容量メモリを利用し、 ディスクへのデータ転送を低減し、 マルチプロセッサで動作することができる能力を持っていました。 その結果、仮想記憶システムは 4.4BSD で完全に置き換えられることになったのです。 4.4BSD 仮想記憶システムは Mach 2.0 VM システム をベースに、Mach 2.5 と Mach 2.0 の改良を採り入れたものです。 この実装は、 メモリ共有の効率が良く機種依存部分と機種非依存部分がきれいに分離されていて、 (現在は使われていませんが) マルチプロセッサに対応しているという特徴を持っています。 各プロセスは自分のアドレス空間のあらゆる部分をファイルにマッピングすることができ、 互いに同一のファイルにアドレス空間をマッピングすることで、 プロセス間でアドレス空間の一部を共有することが可能になりました。 一つのプロセスが加えた変更は他のプロセスのアドレス空間にも反映され、 マッピングされたファイル自身にも書き込まれます。 また、プロセスはファイルをプライベートマッピングすることも可能です。 プライベートマッピングとは、プロセスが加えた変更が、 そのファイルをマッピングしている他のプロセスから見えないようにしたり、 ファイル自身に書き戻されないようにするものです。 仮想記憶システムの抱えるもう一つの問題は、 システムコールが発行された時にカーネルに情報を渡す方法です。 4.4BSD では、常にプロセスのアドレス空間からカーネル内のバッファに データをコピーしていました。 大容量のデータを転送する読み書き操作が発生することを考えると、 このコピーの実行には時間がかかる可能性があります。 コピーを実現するもう一つの方法として、 プロセスのメモリをカーネル内に再マッピングする方法があります。 しかし 4.4BSD カーネルは、 以下の理由から常にデータをコピーします。 ほとんどの場合ユーザデータはページ境界にアラインされていませんし、 ハードウェアページ長の倍数でもありません。 そのページをプロセスが破棄してしまうと、 カーネルがページを参照できなくなってしまいます。 プログラムの中には、カーネル内のバッファに 書かれたデータが残っていることを想定しているものがあります。 (現在の 4.4BSD セマンティクスで可能なように) プロセスがページのコピーを持てる場合、 そのページは必ずコピーオンライト(copy-on-write) になっています。 コピーオンライトのページとは、 読み込み専用に設定することで書き込みに対する保護機能を有効化したページのことです。 プロセスがそのページを変更しようとするとカーネルは書き込み例外を検出します。 その際カーネルは、プロセスが変更できるようにそのページのコピーを作成します。 残念ながら、プロセスは通常すぐに出力バッファに新しいデータを書こうとするため、 結局データのコピーが発生してしまいます。 ページが新しい仮想メモリアドレスに再マッピングされる際、 ほとんどのメモリ管理ハードウェアでは、 ハードウェアアドレス変換キャッシュの一部を破棄する必要があります。 多くの場合、このキャッシュの破棄は時間がかかるため、 4 から 8 キロバイトより小さいデータブロックに対しては、 コピーするよりも再マッピングする方が実質的に遅い、 という結果となります。 メモリマッピングの最も大きな目的は、 巨大なファイルへのアクセスと、 プロセス間の大容量のデータ転送という要求に応えることです。 mmap インタフェースは、 両方の要求をコピーを行なうことなく実現する一つの方法を提供します。 カーネル内部のメモリ管理 カーネルは一つのシステムコールの間だけ必要とされるメモリの割り当てを頻繁に行ないます。 ユーザプロセスではおそらく、 そのような短期間使われるメモリはランタイムスタックに割り当てられるでしょう。 カーネルのランタイムスタックには上限があるため、 小さめのメモリブロックだとしてもスタックにメモリを割り当てることはできません。 そのため、 そのようなメモリはもっと動的な機能を用いて割り当てる必要があります。 たとえば、システムがパス名の解釈を行なう場合、 パス名を保持するために 1 キロバイトのバッファを割り当てる必要があります。 しかしメモリブロックは一つのシステムコールよりも 長く持続していなければならないため、 スタックに空きがあったとしても、そこに割り当てることはできないでしょう。 こういう例の一つに、ネットワークが接続されている間維持している必要がある プロトコル制御ブロックがあります。 カーネル内の動的なメモリ割り当てに対する需要は、 サービスが追加されるにつれて増加しています。 汎用のメモリアロケータがあれば、 カーネル内部のコードを書く際の複雑さを低減することができます。 そのため 4.4BSD カーネルでは、システムのあらゆる場面で利用可能な 単一のメモリアロケータを備えています。 これは、 アプリケーションプログラム用のメモリ割り付けを実現するために C ライブラリルーチンに含まれている malloc と free と類似したインタフェースを持っています 。 この割り付けルーチンは C ライブラリインタフェースと同様、 引数として必要なメモリサイズを指定します。 割り当てるメモリサイズの上限はありませんが、 割り当てられるのは物理メモリであり、ページではありません。 メモリ解放ルーチンは解放するメモリへのポインタを引数にとります。 その際、解放するメモリサイズを指定する必要はありません。 I/O システム 基本的な UNIX の I/O システムモデルは、ランダムアクセスおよび シーケンシャルアクセスの可能なバイト列です。 通常の UNIX ユーザープロセスには、 アクセスメソッド や コントロールブロック は存在しません。 I/O にさまざまなレベルの構造を期待するプログラムは各種ありますが、 カーネルは I/O に構造を課しません。 たとえば、テキストファイルは改行文字 (ASCII LF 文字) で区切られた ASCII 文字の行の集まりですが、 カーネルはそのような構造を関知しません。 ほとんどのプログラムにとって、 このモデルはデータバイトのストリームもしくは I/O ストリーム にすぎません。 このような単一のデータ構造が、UNIX のツールベースのアプローチ (tool-based approach) を可能にしているのです。 あるプログラムの出力ストリームは、他のほとんどのプログラムの入力 ストリームとしてそのまま与える事ができます (このような伝統的な UNIX の I/O ストリームを、Eigth Edition のストリーム I/O システムや、 System V Release 3 の STREAMS と混同すべきではありませんが, - どちらののストリームも伝統的な I/O + どちらのストリームも伝統的な I/O ストリームと同じようにアクセスすることが可能です)。 記述子と I/O UNIX のプロセスは、I/O ストリームを参照するのに 記述子(descriptor)を使用します。 記述子は open または socket システムコールにより取得される符号無しの小さな整数です。 openシステムコールは、 引数にファイル名および許可モードをとり、 それぞれ開くファイルおよび、モード (読み込み、書き込みまたは読み書き) を指定します。 open システムコールは、新しい空のファイルの作成にも使用できます。 readおよび writeシステムコールを記述子に対して使用し、 データの転送を行います。 closeシステムコールは、任意の記述子を開放します。 記述子は、カーネルでサポートされるオブジェクトを表します。 4.4BSD では、ファイル、パイプ、ソケットの 3 つのオブジェクトを 表すことができます。 ファイルは、少なくとも 1 個の名前を持つバイト列です。 ファイルは、すべての名前を明示的に削除し、 その記述子を持つすべてのプロセスが消滅するまで存在します。 プロセスは、open システムコールにより、 指定されたファイル名を持つファイルのファイル記述子を取得します。 I/O デバイスはファイルとしてアクセスされます。 パイプとは、 ファイルと同じくバイト列ですが I/O ストリームとしてのみ使われ、単一方向にのみ使われます。 パイプには名前がないので、open システムコールでは開くことができません。 パイプを開くには、pipe システムコールを使用します。 pipeシステムコールは 2 つの記述子を返します。 ひとつの記述子に入力されたデータは、 もう一方の記述子にそのまま順序を変えずに出力されます。 名前付きパイプ (FIFO) も使用できます。 名前があるのでファイルシステム上に配置され、 open システムコールでアクセスできる以外は、 パイプと同一の機能を持ちます。 FIFO を使用してプロセス間通信を行いたい場合は、 片方のプロセスが FIFO を書き込み用に開き、 もう片方では読み込み用に開きます。 ソケットは、 プロセス間通信のために使用されるオブジェクトで、 ソケットを参照する記述子を持つプロセスが存在する間のみ存在します。 ソケットは socket システムコールで作成します。 socket システムコールは、 作成したソケットの記述子を返します。 さまざまな通信方法を実現するために、 各種のソケットがあります。 たとえば、信頼性の高いデータ転送を目的としたソケット、 メッセージの順番を保持するソケット、 メッセージの境界を保護するソケットなどがあります。 4.2BSD でソケットが導入されるまで、 パイプはファイルシステムを用いて実装されていました。 4.2BSD 以降では、ソケットを使用して実装されています。 カーネルはそれぞれのプロセスの記述子テーブルを保持しており、 記述子の外部表現を内部表現に変換するために用いられます (記述子そのものはこのテーブルへのインデックス値にすぎません)。 記述子テーブルは、親プロセスから子プロセスに継承されます。 そのため、記述子の参照先も同じく継承されます。 記述子を得るためには、オブジェクトを開いたり、 作成したりする以外に、 このような親プロセスからの継承による方法があります。 また IPC ソケットを使用すれば、 同一マシン上で動作している無関係なプロセス間で、 記述子のやりとりが可能です。 すべての有効な記述子は、 オブジェクトの先頭からの位置を ファイルオフセット としてバイト単位で保持しています。 読み込みおよび書き込み動作は、 このオフセット位置から行われ、 データが転送される毎にオフセットの位置は更新されます。 ランダムアクセスを許可しているオブジェクトの場合、 ファイルオフセットは、lseek システムコールを利用して移動することもできます。 通常のファイルやある種のデバイスはランダムアクセス可能です。 パイプ、ソケットはランダムアクセスできません。 プロセスが終了すると、 カーネルはそのプロセスに使用されていたすべての識別子を回収します。 プロセスがオブジェクトへの参照を保持したまま終了した場合は、 オブジェクトマネージャに通知し、ファイルの削除、 ソケットの開放などの必要なクリーンアップを行わせます。 記述子の管理 ほとんどの場合、プロセスが起動されると、 3 つの記述子がすでに開かれています。 それらの記述子は、0、1、2 で、それぞれ一般的には、 標準入力、 標準出力、 標準エラー出力 として知られています。 通常これらの識別子は、 ログインプロセスによりユーザの端末に割り当てられています (14.6 節参照)。すなわち、キーボードからの入力を標準入力として受け取り、 標準出力への出力は端末の画面に表示されます。 標準エラー出力もエラー出力用に書き込み用に開かれていますが、 通常の出力には標準出力が利用されます。 これらの記述子を (他の記述子も) 端末以外のオブジェクトに割り当てることも可能です。 このような割り当てを、 I/O リダイレクトと呼びます。 すべての標準シェルでは、ユーザが I/O リダイレクトを行うことができます。 記述子 1 (標準出力) を閉じ、 指定したファイルを記述子 1 として開くことで、 シェルは出力をファイルに送ることができます。 同様に、記述子 0 を閉じ、 指定したファイルを開くことで、 ファイルから標準入力を受け取るようにできます。 パイプは、プログラムの変更をまったく行わず (再リンクも必要ありません)、あるプログラムの出力を 他のプログラムに入力することを可能にします。 出力側のプログラムの記述子 1 (標準出力) は、端末出力の代わりにパイプの入力記述子に割り当てられます。 同様に入力側のプログラムの記述子 0 (標準入力) は、 端末からのキーボード入力ではなくパイプの出力記述子に割り当てられます。 open、 pipe、 socket システムコールは、新しい記述子を生成し、 使用できる最も小さい番号を割り当てます。 パイプを動作させるためには、そのように生成された記述子を 0 や 1 にマップする仕組みが必要になります。 dup システムコールは、 同一のファイルテーブルエントリを指す記述子のコピーを作成します。 新しい記述子も同じく使用可能な最小の番号が使われるため、 dupシステムコールを使用して、 必要なマップを行えます。 ただ、記述子 1 が必要な場合でも、記述子 0 が既に閉じられていると、 記述子 0 が割り当てられてしまいますので注意が必要です。 この問題を避けるため、 dup2 システムコールがあります。 dup に引数が 1 つ追加され、 割り当てたい記述子の番号を指定することができます (もし、指定された番号の記述子が使用中の場合、 dup2 は、まずその記述子を閉じたのち、 再割り当てします)。 デバイス ハードウェアデバイスはファイル名を持ち、通常のファイルと 同一のシステムコールでアクセスできます。カーネルは、 デバイス特殊ファイル や 特殊ファイルを区別し、 参照しているデバイスを特定できますが、 ほとんどのプロセスにとって、このような区別は必要ありません。 端末、プリンタ、テープデバイスは、4.4BSD のディスクファイルと同様、 バイト列としてアクセスされます。そのため、デバイス依存部分や特殊部分は、 可能な限りカーネルに隠蔽され、さらにカーネル内でも、 それらの大部分がデバイスドライバ内に分離されています。 ハードウェアデバイスは、 構造を持つデバイスと 構造を持たないデバイスに分けられます。 それぞれ、 ブロックデバイス、 キャラクタデバイスと呼ばれます。 それらのデバイスファイルへのアクセスは、カーネル内の デバイスドライバ と呼ばれるソフトウェアモジュールによって処理されます。 ほとんどのネットワーク通信ハードウェアデバイスは、 ファイルシステム上に特殊ファイルを持たず、 プロセス間通信機能のよってのみアクセスできます。 それは、raw-socketの方が特殊ファイルより、 より自然なインタフェースを提供できるためです。 典型的なブロックデバイス (構造を持つデバイス) としては、 ディスク、磁気テープがあげられますが、 ほとんどのランダムアクセスデバイスがそれに該当します。 カーネルは、読み込み-変更-書き込みに対してバッファリングを提供し、 通常ファイルと同様の、 完全なバイトアドレス指定のランダムアクセスを提供します。 ファイルシステムは、ブロックデバイス上に構築されます。 構造を持たないデバイスは、 ブロック構造をサポートしないデバイスで、通信線、ラスタプロッタ、 バッファのない磁気ディスクやテープなどです。 構造を持たないデバイスは通常、 大容量のブロック I/O 転送をサポートします。 構造を持たないファイルはキャラクタデバイスと呼ばれます。 これは最初の実装されたこの種類のデバイスが、 端末デバイスドライバだったからです。 このようなデバイスに対するカーネルのインタフェースは、 他のブロック構造を持たないデバイスに対しても有用であることが証明されました。 デバイス特殊ファイルは、 mknodシステムコールによる作成されます。 ioctlシステムコールは、 特殊ファイルに対応するデバイスのパラメータを操作するのに使われます。 このシステムコールは、他のシステムコールに新たな機能を追加せずに、 デバイスの特殊な機能を操作することを可能にします。 たとえば、ioctlを使用して、 終了マークをテープデバイスに書き込むことができます。 write に変更を加えたり、 特殊なバージョンを用意する必要はありません。 ソケット IPC 4.2BSD カーネルはソケットを利用して、パイプより柔軟な IPC 機能を導入しました。ソケットは、ファイルやパイプと同様、 記述子により参照される、通信の末端点です。 2 つのプロセスがそれぞれ、ソケットを作成して接続することにより、 信頼性の高いバイトストリームを作成できます。 接続されれば、それぞれのプロセスは、パイプと同じように、 読み込み書き込みをソケットに対して行えます。 ソケットの透明性により、カーネルはプロセスの出力を、 別のマシン上のプロセスの入力に送ることも可能です。 パイプとソケットの大きな違いは、 パイプは共通の親プロセスが設定する必要があるのに対して、 ソケットはまったく無関係の (異なるマシン上で動作する) プロセス間でも使用できる点です。 System V は、FIFO もしくは名前付きパイプと呼ばれる ローカルプロセス間通信の仕組みを備えています。 FIFO はファイルシステム上のオブジェクトとして現われ、 パイプと同様な方法でオープンし、データを送ることができます。 そのため、FIFO は共通の親プロセスによって設定される必要はなく、 プロセス同士が起動し動作開始してから接続することが可能です。 しかしソケットとは異なり、 異なるマシン上で動作するプロセスに対しては使用できません。 4.4BSD で、FIFO が実装されているのは、 POSIX.1 標準に準拠するためのみです。 FIFO の機能は、ソケットの機能の一部になっています。 ソケット機構を実現するには、 伝統的な UNIX の I/O システムコールに名前付けや接続機能を追加する必要がありました。 開発者は、既存のインタフェースへの拡張は既存のシステムコールが変更なしに使用できる範囲にとどめ、 追加機能を扱う新しいインタフェースを設計しました。 バイトストリーム型の接続の読み込み書き込みを行う readと write システムコールに加え、 ネットワークダイアグラムのような宛名付きメッセージを読み込むため、 新たに 6 つのシステムコールが追加されました。 メッセージ書き込み用の send、 sendto、 sendmsg システムコールと、 メッセージの読み込み用の recv、 recvfrom、 recvmsg システムコールです。 考え直して見ると、 それぞれの読み書き用のシステムコールのうち最初の 2 - つは次ののシステムコールの特殊な場合であるので、 + つは次のシステムコールの特殊な場合であるので、 recvfrom と sendto システムコールは、それぞれ recvmsg と sendmsg のライブラリインタフェースとし て追加すべだったかも知れません。 Scatter/Gather I/O 既存の read および write システムコールに加え、 4.2BSD で scatter/gather I/O 機能が導入されました。 scatter 入力は readv システムコールによって行われ、 複数の異なるバッファに対して単一の読み込みを実行できます。 逆に writev システムコールは、複数の異なるバッファに対してアトミックな書き込みを実行できます。 read や write によって行われるように、 単一のバッファと長さをパラメータとして渡す代わりに、 バッファと長さの配列へのポインタとそのサイズを渡します。 この機能により、 プロセスアドレス空間の異なる場所にあるバッファに対してアトミックな単一の書き込みを行え、 隣接するバッファにコピーする必要もありません。 テープデバイスのように、それぞれの要求に対し、 テープブロックを出力をする必要があるようなレコードベースのデバイスを抽象化した場合、 アトミックな書き込みが必要になります。 また、単一の読み込みリクエストで複数のバッファに読み込めるのは非常に便利です (たとえばレコードヘッダとデータをそれぞれ別のバッファに読み込む場合など)。 もちろん単一の大きなバッファにデータを読み込み、 読み込んだデータを必要な場所に移動することで scatter 動作をシミュレートすることは可能です。 ただし、このようなメモリ間のコピーのコストは、 アプリケーションの動作に必要な時間を 2 倍以上にしてしまうことも良くあります。 send と recv がそれぞれ、 sendto と recvfrom のライブラリインタフェースとして実装可能であったのと同じく、 read と write をそれぞれ、 readv と writev のライブラリインタフェースとして実装も可能であったでしょう。 しかし、 read と write はより頻繁に使われるため、 シミュレートするための追加コストを考えると ライブラリインタフェースとしての実装は割に合わなかったでしょう。 複数のファイルシステムのサポート ネットワークコンピューティングの発達により、 ローカルおよびリモートファイルシステムへの対応が望まれるようになりました。 複数のファイルシステムのサポートを簡単にするために、 開発者は vnode インタフェースをカーネルに追加しました。 vnode インタフェースから提供される操作は、 以前にローカルファイルシステムでサポートされていたファイルシステム操作とほぼ同じですが、 幅広いファイルシステムにより使用ができるようになっています。 ローカルのディスクファイルシステム 各種リモートファイルシステムプロトコルによりインポートされたファイル 読み込み専用 CD-ROM ファイルシステム 特殊機能を提供するファイルシステム。 たとえば /proc ファイルシステムなど 4.4BSD 由来の OS の中には FreeBSD のように、 mount でファイルシステムが初めて参照された時にファイルシステムを動的に読み込むことが できるものもあります。 vnode インタフェースについては 6.5 節、 補助サポートルーチンについては 6.6 節、 特殊機能ファイルシステムについては 6.7 節に記載されています。 ファイルシステム 通常ファイルとは一次元のバイト列であり、 任意の場所から読み込み・書き込みが可能です。 カーネルは、ファイルのレコード境界を認識しませんが、 多くのプログラムは 改行 (LF) 文字を行の終りと認識します。 またこれとは異なるファイル構造を利用するアプリケーションもあります。 ファイル自身には、ファイルに関するシステム情報はまったく含まれません。 各ファイルのファイル所有者、許可属性、 使用状況などのいくつかの情報はファイルではなくファイルシステムが保持しています。 ファイル名は最大 255 文字までの文字列です。 ファイル名はディレクトリ と呼ばれる型のファイルに保管されます。 ディレクトリに含まれるファイルの情報はディレクトリエントリと呼ばれ、 ファイル名以外にファイルそのものへのポインタも含みます。 ディレクトリエントリには通常のファイル以外に、 他のディレクトリを参照するエントリが含まれます。 このようにしてディレクトリとファイルによる階層が形作られ、 その階層構造をファイルシステムと呼びます。
小規模なファイルシステム +-------+ | | +-------+ / \ usr / \ vmunix |/ \| +-------+ +-------+ | | | | +-------+ +-------+ / | \ staff / | \ bin |/ | tmp \| +-------+ V +-------+ | | +-------+ | | +-------+ | | +-------+ / | \ +-------+ / | \ mckusick / | \| |/ | \ ls |/ | karels | vi \| +-------+ V V +-------+ | | +-------+ +-------+ | | +-------+ | | | | +-------+ +-------+ +-------+ 小規模なファイルシステムツリー
は小規模なファイルシステムの一例です。 ディレクトリはサブディレクトリを含むことができ、 入れ子の深さには特に制限はありません。 ファイルシステムの一貫性を保つため、 カーネルはプロセスが直接ディレクトリへ書き込むことを禁止しています。 ファイルシステムには、通常ファイル、ディレクトリ以外に、 デバイスファイルやソケットなどの他のオブジェクトへの参照も含まれます。 ファイルシステムは、 ルートディレクトリ を始点とする木構造を持っています。 ルートディレクトリは、 スラッシュ と呼ばれる場合もあり、斜線文字(/)で表されます。 ルートディレクトリにはファイルが含まれます。 図 2.2 の例では、 usr ディレクトリが含まれ、その usr ディレクトリには、 bin ディレクトリが含まれます。 bin ディレクトリには、通常 ls や vi をはじめとする、プログラムの実行可能コードが含まれます。 プロセスは、ファイルの指定をパス名によって行います。 パス名は、0 個以上のファイル名を斜線文字(/)で区切った文字列です。 カーネルはパス名を解釈するため、それぞれのプロセスに 2 つのパス名を関連付けます。 プロセスのルートディレクトリは、 プロセスがアクセスできるファイルシステム上で最も上位の点です。 通常、このルートディレクトリは、 ファイルシステム全体のルートディレクトリに設定されます。 斜線文字 (/) ではじまるパス名は絶対パス名と呼ばれ、 カーネルは、そのパス名がプロセスのルートディレクトリから 開始するものと解釈します。 斜線文字 (/) ではじまらないパス名は相対パス名と呼ばれ、 プロセスのカレント作業ディレクトリを基準とした相対的なパスとして解釈されます (このディレクトリは、短縮して カレントディレクトリ または、 作業ディレクトリ とも呼ばれます)。 カレントディレクトリそのものは、 ドット とも呼ばれ、1 つのピリオド (.) で表されます。 ファイル名 ドットドット (..) は、 ディレクトリの親ディレクトリを表します。 ルートディレクトリの親ディレクトリはルートディレクトリ自身です。 chroot システムコールにより、プロセスのルートディレクトリを、 chdir システムコールにより、カレントディレクトリを変更できます。 chdir はいつでも行えますが、 chroot の実行は、管理者特権を持つプロセスに限られます。 chroot は通常、システムに対するアクセス制限を課すために用いられます。 図 2.2 のファイルシステムにおいて、プロセスのルートディレクトリ がファイルシステムのルートディレクトリで、カレントディレクトリが /usr であったとします.このとき、 vi を参照するには、絶対パスを用いて、 /usr/bin/vi とも書けますし、カレントディレクトリからの相対パスを用いて、 bin/vi とも書けます。 システムのユーティリティやデータベースは、 よく知られたある決まったディレクトリに保存されます。 ファイルシステムの階層構造としてよく知られたものに、 各々のユーザのホームディレクトリがあります。 たとえば、図 2.2 の /usr/staff/mckusick や /usr/staff/karels などです。 ユーザがログインすると、 シェルのカレントディレクトリはホームディレクトリに設定されます。 ユーザはホームディレクトリ内で通常ファイルの作成と同様にディレクトリも作成できるため、 複雑な階層構造を構築することも可能です。 ユーザからはファイルシステムが 1 つに見えますが、 システムは 1 つの仮想ファイルシステムが、 実際には異なるデバイス上の複数の物理ファイルシステムから構成されていること認識しています。 物理ファイルシステムは、異なったデバイスにまたがることはできません。 ほとんどの場合、物理ディスクデバイスは複数の論理デバイスに分割されるため、 1 つの物理デバイス上に複数のファイルシステムを構成することもできます。 すべての絶対パス名を解決できるファイルシステムを ルートファイルシステムと呼び、 常に利用可能な状態になっています。 他のファイルシステムは、マウントすることができます。 マウントとは、ルートファイルシステムのディレクトリ構造の一部として統合する操作です。 ファイルシステムにマウントされたディレクトリの参照は、 そのマウントされたファイルシステムのルートディレクトリの参照へと カーネルによって透過的に変換されます。 link システムコールは、既存のファイル名に、別名を与えます。 リンクが成功すると、 ファイルはどちらのファイル名からでもアクセスできるようになります。 ファイル名は unlink システムコールにより削除できます。 ファイルを参照していた最後の名前が削除されると (さらにファイルを開いていた最後のプロセスがファイルを閉じると) ファイルそのものも削除されます。 ファイルはディレクトリ内で階層構造を持って保持されます。 ディレクトリそのものも一種のファイルですが、 ディレクトリは一般のファイルと異なり、 システムのよって決められた構造を持っています。 ディレクトリは一般のファイルと同じくプロセスから読み込むことが可能ですが、 ディレクトリに変更を加えられるのはカーネルだけです。 ディレクトリは mkdir システムコールで作成し、 rmdir システムコールで削除します。 4.2BSD 以前のシステムにおける mkdir と rmdir システムコールは、一連の link、unlink システムコールの実行として実装されていました。 明示的にディレクトリの作成、 削除を行うシステムコールを新たに追加した理由は、3 つあります。 アトミックな動作を可能にするため。 link システムコールによる実装の場合と異なり、 システムがクラッシュした場合に ディレクトリの構造が中途半端なままになることがありません。 ネットワークファイルシステムを使用している場合には シリアライズ (操作順序の保証) を行うため、ファイルおよびディレクトリの作成、 削除はアトミックに行われる必要があります。 UNIX 以外のファイルシステム (他のパーティション上の MS-DOS ファイルシステムなど) をサポートする場合、 そのファイルシステムが link システムコールをサポートしない可能性があります。 たとえそれがディレクトリをサポートするファイルシステムであっても、 UNIX ファイルシステムとは異なり、ディレクトリをリンクとして作成、 削除しないものもあります。 そのためそのようなファイルシステムでは、 ディレクトリの作成、削除は、 明示的に要求されない限り行われません。 chown システムコールはファイルの所有者とグループを設定します。 chmod システムコールは、ファイルの保護モードを変更します。 これらのファイルの属性は、 stat システムコールをファイル名に対し実行することで読み出すことができます。 fchown、 fchmod、 fstat システムコールは、同様な動作をファイル名ではなくファイル記述子に対して行います。 rename システムコールは、ファイルに新しい名前をつけて古い名前を削除します。 ディレクトリ作成・削除操作と同じように、 rename システムコールはローカルファイルシステムの名前変更動作をアトミックにするため 4.2BSD で追加されました。 後に。この動作はネットワーク上の非 UNIX ファイルシステムに対して名前変更操作を行う場合に有効であることがわかりました。 truncateは、 4.2BSD で追加されたファイルを任意の長さに切り詰めるシステムコールです。 このシステムコール追加の主な目的は ランダムアクセスファイルの最後をプログラムが最後にアクセスした場所に設定する、 という動作を持つ Fortran ランタイムライブラリのサポートでした。 truncate システムコールを使用しない場合、 ファイルの長さを縮める唯一の方法は必要な部分をコピーしたファイルを作成し、 元のファイルを削除した後にコピーしたファイルをリネームする方法です。 このアルゴリズムは遅いだけでなく、 空き容量の少ないファイルシステムでは失敗する可能性があります。 ファイルシステムにファイルを縮める機能が追加されると、 それはカーネルが大きな空のディレクトリを小さくする用途に使用するようになりました。 空のディレクトリを縮小すると、 ファイルの作成、 削除時にカーネルがファイルを検索する時間を短縮できるという利点があります。 新規に作成されたファイルには、 作成したプロセスのユーザ識別子と作成が行われたディレクトリにグループ識別子を与えられます。 ファイルの保護用に 3 レベルのアクセス制御機構が用意されています。 この 3 レベルのファイルアクセス許可は ファイルを所有しているユーザ ファイルを所有しているグループ 他のすべて に対して設定することができます。 それぞれのアクセスレベルは、さらに 読み取り許可、書き込み許可、実行許可に分けられています。 ファイルは作成時に長さが 0 であり、 書き込みされるにつれて長くなっていきます。 システムはファイルが開かれると、 対応する記述子の現在位置を指定するポインタを保持します。 このポインタはファイル内をランダムアクセスするように動かすことが可能です。 fork や dup システムコールによりファイル記述子を共有するプロセス間では、 この現在位置ポインタは共有されます。 別々の open システムコールによって 作成されたファイル記述子は、独立した現在位置ポインタを持ちます。 ファイルは穴を持つことがあります。 穴とはファイルの一次元構造の中で、 データが一度も書き込まれたことのない空の部分です。 ファイルの最後尾より後にポインタを動かし書き込みを行うことで、 ファイルに穴をつくることができます。 読み込まれた場合、穴は 0 の値をもつバイトとして扱われます。 初期の UNIX システムではファイル名に 14 文字以内という制限があり、 よく問題となっていました。 たとえば、ユーザは当然ながら長く説明的なファイル名を付けたいと望みますし、 basename.extension という慣用的なファイル命名規則を考えると、 extension (C のソースファイルの .c、 中間バイナリオブジェクトファイルの .o というように、ファイルの種類を示す部分) に 1 から 3 文字必要ですから、 basename に付けられる文字数は 10 から 12 しか残っていません。 ソースコード制御システムやエディタは通常、 独自の目的のためにさらに 2 文字をファイル名の前後に付加しますので、 実際に使えるのは、8 から 10 文字になります。 basename として英語を一単語 (たとえば multiplexer) 使うだけで、 簡単に 10 から 12 文字になってしまうでしょう。 このような制限を守るのは不可能ではありませんが、 危険な場合もあります。 他の UNIX システムでは、 より長いファイル名を受け付けるものの実際にファイルを作成する時点でファイル名を 切り詰めるものがあるからです。 C のソースコードファイル multiplexer.c (すでに 13 文字です) のソースコード制御ファイルは、 頭に s. が付加されて s.multiplexer となります。 このファイルは、C ソースの文書の troff ソースファイル multiplexer.ms のソースコード制御ファイルと区別がつきません。 ソースコード制御システムはこの問題に対して警告を出さないため、 これらの 2 つのファイル内容の取り違えは容易に発生します。 注意深くコーディングすればこのような問題は避けられますが、 4.2BSD でロングファイルネームが導入されたことで この問題は実質的になくなりました。 ファイル記録機構 ローカルファイルシステムに対する操作には二種類あります。 まず、ローカルファイルシステムすべてに共通して 階層化されたファイルのネーミング、ロック、割り当て、 属性管理、保護といった、データの記録方法とは独立した機能です。 4.4BSD はこれらの機能を提供する単一の実装を備えています。 もう一つは記録媒体上におけるデータ構成と管理です。 ファイル内容を記録媒体上に配置するのはファイル記録機構の役割であり、 4.4BSD は 3 種類の異なるファイル配置法に対応しています。 伝統的な Berkeley Fast Filesystem Sprite という OS の設計に由来する ログ構造化ファイルシステム メモリベースのファイルシステム これらのファイル記録機構の構成はまったく異なるものですが、 それを使用するプロセスからは違いを意識することはありません。 Fast Filesystem は、データをシリンダグループという単位で構成します。 ファイルシステム階層の配置から考えて同時にアクセスされやすいと考えられるファイルは、 同じシリンダグループに記録され、同時にアクセスされる可能性の低いファイルは 異なるシリンダグループに記録されます。 この記録機構では以上のように、複数のファイルが同時に書き込まれたとしても、 記録される場所はディスクのまったく違う場所になる可能性があるのです。 ログ構造化ファイルシステムは、データをログという形で構成します。 ある時点で記録されたデータはすべて一つに集められ、 同じディスクの場所に書き込まれます。 データが上書きされることは絶対にありません。 ファイルの更新は、ファイルを上書きする代わりに 新しいファイルを書き込んでそのファイルを置き換えることによって行なわれます。 ファイルシステムに空き容量がなくなり新たに空き容量が必要になった場合は ゴミ集め (garbage-collection) プロセスが実行され、 古いファイルが再利用されます。 メモリベースのファイルシステムは、 データを仮想メモリに記録するように設計されたものです。 これは /tmp のように高速アクセスが必要で、 永続的でないファイルシステムに使われます。 メモリベースファイルシステムの目標は、 仮想メモリ資源の利用量を可能な限り最小限に保つことにあります。 ネットワークファイルシステム 当初、ネットワーク通信はデータをあるマシンから 他のマシンへ転送するために用いられていましたが、 のちにそれは、ユーザが離れたマシンへログイン可能な形に発展しました。 次に期待されたのはユーザがデータを取り行くのではなく、 ユーザの元にデータがやってくるようにすることでした。 そのために生まれたのがネットワークファイルシステムです。 ローカルで作業しているユーザはキー入力時にネットワークの遅れを感じず、 より応答性の良い環境を手に入れたのです。 ファイルシステムをローカルマシンに持ってくることは 初期のサーバ-クライアント型アプリケーションの中で主要なもののひとつでした。 サーバ は 1 つもしくはそれ以上のファイルシステムを エクスポートするリモートのマシンです。 クライアント はそのファイルシステムをインポートするローカルのマシンです。 ローカルのクライアントから見ると、 リモートでマウントされたファイルシステムは ローカルにマウントされた他のファイルシステムのように ファイルツリーの名前空間に現れます。 ローカルのクライアントは リモートのファイルシステム上にディレクトリを変えたり、 ローカルのファイルシステム上でするのとまったく同じように リモートのファイルシステムで読み書きをしたり、 バイナリを実行したりできます。 ローカルのクライアントが リモートのファイルシステム上で操作すると、 その操作要求がひとまとめにされてサーバに送られます。 サーバは要求された操作を行い、 クライアントから要求された情報、もしくは、 なぜその要求が拒絶されたかを示すエラーを返します。 適切な性能を得るには、 クライアントは頻繁にアクセスされたデータをキャッシュしなければなりません。 リモートファイルシステムの複雑さは、 サーバと多くのクライアントの間のキャッシュの一貫性を維持することにあります。 長期にわたって数多くのリモートファイルシステムプロトコルが開発されてきましたが、 UNIX システムにおいて最も普及しているものは、 そのプロトコルと実装の大部分が Sun Microsystems によって行なわれた ネットワークファイルシステム (NFS) です。 実装はプロトコル規格から独立して行われましたが、 4.4BSD カーネルは NFS プロトコルをサポートしています 。 NFS プロトコルについては 9 章で説明しています。 端末 端末は、標準的なシステム I/O 操作はもちろんのこと、 入力文字の編集や出力のディレイの制御をするための端末固有の操作をひととおり サポートしています。 一番低いレベルにあるのは、ハードウェア端末ポートを制御する端末デバイスドライバです。 端末入力は、たとえばボーレートのような基礎的な通信特性や、 パリティ検査のようなソフトウェアで制御可能なパラメータ類に 従って扱われます。 端末デバイスドライバの上の層には、 文字処理をどの程度行なうかを定義している ラインディシプリン (line discipline; 回線端末制御) と呼ばれるものがあります。 対話的なログインをするためにポートが 用いられるときにはデフォルトのラインディシプリンが選択され、 そのラインディシプリンはカノニカルモードで動作します。 これは、入力が標準的な行指向編集機能を提供するように処理され、 入力自体を行単位の処理で表現するモードです。 スクリーンエディタや、他のコンピュータと通信をするプログラム (訳注: telnet など) は、普通非カノニカルモード (raw モードやキャラクタごとのモード (character-at-a-time mode) などとも呼ばれます) で動作します。 これらのモードでは、入力はそのまますぐに読み込み側の プロセスへと渡されます。 すべての特殊文字入力の処理は無効化されていて、 削除やその他の行編集処理は行なわれず、 すべての文字はその端末から読み込もうとしているプロセスへと渡されます。 端末は、この二つの両極端のモードの中間の多くの組み合わせで 設定することが可能です。 たとえば、あるスクリーンエディタがユーザからの割り込みを非同期的に 受け入れたい場合に、シグナルを生成する文字や出力の流量制御を許可したまま、 それ以外を非カノニカルモードで動かして、これらの文字以外の文字を まったく解釈しないまま渡す、ということが可能です。 出力では、端末処理は次のような単純な整形サービスを提供しています。 ラインフィードをキャリッジリターンとラインフィードの並びへと変換 特定の標準的な制御文字の後にディレイを挿入 タブ文字の展開 エコーされた非表示アスキー文字を ``^C'' (すなわち、アスキーのキャレット文字 の後に、そのキャラクタの値をアスキーの ``@'' 文字からのオフセットとした アスキー文字) という二文字の並びとして表示 これらの整形機能は、コントロールリクエストを使ってそれぞれ独立に 無効化することが可能です。 プロセス間通信 (IPC) 4.4BSD のプロセス間通信 (IPC) は、コミュニケーション ドメイン内で働くようになっています。現在サポートされて いるドメインには、同じマシン上で実行している複数のプロセス間 での通信用のローカルドメイン、 TCP/IP プロトコルスイート用の (おそらく the Internet 内) インターネットドメイン、 ISO/OSI プロトコルファミリでの通信を行なうことが必要なサイト間通信用の ISO/OSI プロトコルファミリ、 XEROX Network Systems (XNS) を使用したプロセス間通信用の XNS ドメインが含まれています。 ドメイン内では、ソケットとして知られ ている通信終端間で通信が行なわれます。 2.6 節で説明しているように、 soket システムコールはソケットを生成し、その記述子を返します。 他の IPC システムコールについては 11 章で解説します。 各ソケットは、通信セマンティクスを定義した型を持ちます。 このセマンティクスには信頼性、順序、メッセージの重複防止が 含まれています。 各ソケットは、通信プロトコル と関連しています。 ここでのプロトコルは、通信相手のソケットの型に従って そのソケットで要求されているセマンティクスを提供します。 アプリケーションは、ソケットを生成する際に特定のプロトコルを 要求することができますし、また、そのシステムは、将来生成される ソケットの型にふさわしいプロトコルを選択するようにすることも 可能です。 ソケットは、そのソケットと関連づけされた (バインドされた) アドレスを持つことができます。 ソケットアドレスの形式と意味は、そのソケットが生成された コミュニケーションドメインに依存します。 ローカルドメインにおいてソケットに名前をバインドすると、 そのファイルシステムにおいてファイルが生成されます。 ソケットを通じて送受信される通常のデータは型づけされていません。 データ表現については、プロセス間通信機能の最上位に位置するライブラリに責任があります。 通常データの配送に加えて、コミュニケーションドメインは access rights という特別な型のデータの 送受信をサポートすることができます。 たとえばローカルドメインはプロセス間で記述子を渡すために、 この機能を使用します。 4.2BSD より前の UNIX におけるネットワーク機能の実装は、 大抵キャラクタデバイスインタフェースをオーバロードさせることで 動作していました。 ソケットインタフェースの目的の一つは、単純なプログラムが ストリーム型の通信を変更せずに動作するようにすることです。 そのようなプログラムは、read と write のシステムコールが変更されなければ 動作します。 当然、元のインタフェースがそのまま残されれば、 ストリーム型のソケット上で動作し続けるようになります。 send の各呼び出しで指定しなければならない 送信先アドレスを持つデータグラムを送信するような、 より複雑なソケット用に新しいインタフェースが追加されました。 もう一つの利点は、この新しいインタフェースは移植性が 非常に良いということです。 バークレーから入手できたテストリリースのすぐ後で、 ソケットインタフェースは UNIX ベンダによって System III に移植されました (しかし、AT&T は System V Release 4 のリリースまでソケットインタフェースをサポートせず、 その代わりに Eighth Edition のストリーム機構を使用する ことを決めました)。 ソケットインタフェースはまた、Excelan 社や Interlan 社のような ベンダによって多くのイーサネットカードで動作するように移植され、 マシンが小さすぎてメインプロセッサ中でネットワーク通信を動作 させることができない PC 市場に売り出されました。 ごく最近では、Microsoft 社の Windows 用の Winsock ネットワークインタフェースの基盤として ソケットインタフェースが使われています。 ネットワーク通信 ソケット IPC 機構が対応している ネットワークドメインのいくつかは、 ネットワークプロトコルへのアクセスを提供しています。 これらのプロトコルは理論上、 カーネルのソケットソフトウェアよりも下の層にある 別のソフトウェアとして実装されています。 カーネルは、バッファ管理、メッセージ配送、 各プロトコルへの汎用インタフェースを提供し、 また、さまざまなネットワークプロトコルを使用するための ネットワークインタフェースドライバへのインタフェースなど、 多くの付随サービスを提供します。 4.2BSD が実装された時点ではさまざまなネットワークプロトコルが 使用され、また開発中の段階にありました。 それらはそれぞれ固有の強みと弱みを持っており、 明らかに優れたプロトコルやプロトコルスイートというものは存在しませんでした。 4.2BSD は複数のプロトコルに対応することで、 バークレー校の環境で利用可能だったさまざまなマシン間での 資源の共有や、相互運用の提供を可能にしていました。 またこの複数プロトコルへの対応は、 将来的な変更に備えて設計されていました。 今日利用されている 10-100Mbps のイーサネット用のプロトコルは、 将来の 1-10Gbps 光ファイバネットワークに対して、 おそらく十分なものではないでしょう。 そのため、ネットワーク通信レイヤは複数のプロトコルに対応できるように 設計されています。 新しいプロトコルがカーネルに追加されても、 既存のプロトコルがその影響を受けることはまったくありません。 新しいアプリケーションは新しいネットワークプロトコルで動作し、 一方で既存のアプリケーションもまた、 それと同じ物理ネットワーク上で今までどおりのプロトコルを 利用し続けることが可能です。 ネットワーク実装 4.2BSD で実装された最初のプロトコルスイートは DARPA の Transmission Control Protocol/Internet Protocol (TCP/IP) でした。 CSRG は、ソケット IPC フレームワークに組み込む最初のネットワークとして TCP/IP を選択しました。その理由は、4.1BSD ベースの実装が DARPA がスポンサーとなっていた Bolt、Beranek、Newman (BBN) におけるプロジェクトからパブリックに入手可能だったからです。 それは大きな選択でした。 このプロトコルスイートが非常に広く利用されたのは、 主に 4.2BSD でのこの実装が理由となっています。 TCP/IP の実装に対するその後の性能と能力の改善も広く採用されました。 TCP/IP の実装については、13 章で詳細に解説しています。 4.3BSD のリリースでは、メリーランド大学とコーネル大学で部分的に 開発された Xerox Network Systems (XNS) プロトコルスイートが追加されました。 このプロトコルスイートは、TCP/IP を使用して通信できない孤立したマシンと 通信するのに必要でした。 4.4BSD のリリースでは、近頃米国内外で増加している ISO プロトコルスイートが追加されました。 ISO プロトコル群のために多少異なるセマンティクスを定義したので、 これらのセマンティクスに適合させるため ソケットインタフェースにいくつかの小さな変更が必要となりました。 その変更は、 他の既存プロトコルのクライアントには分からないようになされています。 ISO プロトコル群用に 4.3BSD カーネルで提供された 2 レベルルーティングテーブルに対する大規模な追加も必要でした。 4.4BSD で大きく拡張されたルーティング機能は、 可変長アドレスと ネットワークマスクを持つ任意のレベルのルーティングが含まれています。 システム運用 ブートストラップ機構はシステムを起動するために利用されます。 まず最初に、4.4BSD カーネルは CPU のメインメモリに読み込まれます。 カーネルが読み込まれると、 特定の状態へハードウェアを設定する初期化フェーズに移行します。 次に、カーネルは自動設定 (autoconfiguration) を行ないます。 これは CPU に接続された周辺機器の検出と設定を行なう過程です。 システムは最初、ディスクチェック、アカウント処理、 quota チェックを行なうスタートアップスクリプトを シングルユーザモードで実行します。 スタートアップスクリプトは最後に一般的に利用されるシステムサービス群を起動し、 システムを完全なマルチユーザモードに移行させます。 マルチユーザモードでは、プロセスが ユーザがアクセスできるように設定された端末回線や ネットワークポート上でのログイン要求を待ちます。 ログイン要求が検出されるとログインプロセスが生成され、 ユーザの確認処理が行われます。 そしてユーザの確認処理が成功すると、 そのユーザに対して、 他のプロセスを実行できるようにするためのログインシェルが生成されます。 参考文献 Accetta et al, 1986 Mach: A New Kernel Foundation for UNIX Development" M. Accetta R. Baron W. Bolosky D. Golub R. Rashid A. Tevanian M. Young 93-113 USENIX Association Conference Proceedings USENIX Association June 1986 Cheriton, 1988 The V Distributed System D. R. Cheriton 314-333 Comm ACM, 31, 3 March 1988 Ewens et al, 1985 Tunis: A Distributed Multiprocessor Operating System P. Ewens D. R. Blythe M. Funkenhauser R. C. Holt 247-254 USENIX Assocation Conference Proceedings USENIX Association June 1985 Gingell et al, 1987 Virtual Memory Architecture in SunOS R. Gingell J. Moran W. Shannon 81-94 USENIX Association Conference Proceedings USENIX Association June 1987 Kernighan & Pike, 1984 The UNIX Programming Environment B. W. Kernighan R. Pike Prentice-Hall
Englewood Cliffs NJ
1984 Macklem, 1994 The 4.4BSD NFS Implementation R. Macklem 6:1-14 4.4BSD System Manager's Manual O'Reilly & Associates, Inc.
Sebastopol CA
1994 McKusick & Karels, 1988 Design of a General Purpose Memory Allocator for the 4.3BSD UNIX Kernel M. K. McKusick M. J. Karels 295-304 USENIX Assocation Conference Proceedings USENIX Assocation June 1998 McKusick et al, 1994 Berkeley Software Architecture Manual, 4.4BSD Edition M. K. McKusick M. J. Karels S. J. Leffler W. N. Joy R. S. Faber 5:1-42 4.4BSD Programmer's Supplementary Documents O'Reilly & Associates, Inc.
Sebastopol CA
1994 Ritchie, 1988 Early Kernel Design private communication D. M. Ritchie March 1988 Rosenblum & Ousterhout, 1992 The Design and Implementation of a Log-Structured File System M. Rosenblum K. Ousterhout 26-52 ACM Transactions on Computer Systems, 10, 1 Association for Computing Machinery February 1992 Rozier et al, 1988 Chorus Distributed Operating Systems M. Rozier V. Abrossimov F. Armand I. Boule M. Gien M. Guillemont F. Herrmann C. Kaiser S. Langlois P. Leonard W. Neuhauser 305-370 USENIX Computing Systems, 1, 4 Fall 1988 Tevanian, 1987 Architecture-Independent Virtual Memory Management for Parallel and Distributed Environments: The Mach Approach Technical Report CMU-CS-88-106, A. Tevanian Department of Computer Science, Carnegie-Mellon University
Pittsburgh PA
December 1987 日本語化について The Design and Implementation of 4.4BSD Operating System Chapter 2 の日本語化は、原著の出版元である Addison-Weslay、 翻訳出版権を保有する Pearson Education Japan の協力を得て、 FreeBSD 日本語ドキュメンテーションプロジェクト (FreeBSD doc-jp) によって行なわれました。 日本語版について何かお気付きの点がありましたら 日本語ドキュメンテーションプロジェクト doc-jp@jp.FreeBSD.org までご連絡ください。 この日本語版の著作権は、原著者、原著の出版元である Addison-Weslay および日本語版の翻訳出版権を保有する Pearson Education Japan に帰属します。そのため、 この文書をこれらの著作権保有者の明示的な許可なく複製、 再配布することは禁止されています。 2001 年 5 月 5 日にスタートした日本語化作業には、 さまざまな方々が翻訳に参加されました。 FreeBSD doc-jp では、FreeBSD 関連文書の日本語版を作成する作業を精力的に続けています。 この作業に協力したいと思われる方は、 ぜひFreeBSD 日本語ドキュメンテーションプロジェクトのページをご覧の上 doc-jp へご参加ください。 翻訳者 杉村 貴士 sugimura@jp.FreeBSD.org (2.1, 2.2 節) IKENO Naoki nao@mc.kcom.ne.jp (2.3 節) 田畑 喜晃 ytabata@tkf.att.ne.jp (2.4 節) Atsuto atsuto@guitar.interq.or.jp (2.5 節) はらだきろう kiroh@jp.FreeBSD.org (2.6, 2.7 節) 高田 知樹 tomoki@leergirls.org (2.8 節) 倉品 英行 rushani@bl.mmtr.or.jp (2.9 節) 塩崎 拓也 tshiozak@FreeBSD.org (2.10 節) こが よういちろう y-koga@jp.FreeBSD.org (2.11, 2.13 節) 森 直之 mori@jp.FreeBSD.org (2.12 節) 坂井 順行 sakai@lac.co.jp (2.14 節) 内川 喜章 yoshiaki@kt.rim.or.jp (査読) 日野 浩志 hino@ccm.cl.nec.co.jp (査読) 山口 雅信 yamagu-m@titan.ocn.ne.jp (翻訳提供) diff --git a/ja_JP.eucJP/books/faq/book.sgml b/ja_JP.eucJP/books/faq/book.sgml index 43c5a61d39..e5b51420f0 100644 --- a/ja_JP.eucJP/books/faq/book.sgml +++ b/ja_JP.eucJP/books/faq/book.sgml @@ -1,14952 +1,14952 @@ %man; %freebsd; %ja-authors; %authors; %teams; %bookinfo; %mailing-lists; %newsgroups; ]> FreeBSD 2.X、3.X、4.X についての FAQ (よくある質問とその答え) FreeBSD ドキュメンテーションプロジェクト $FreeBSD$ 1995 1996 1997 1998 1999 2000 2001 FreeBSD ドキュメンテーションプロジェクト &bookinfo.legalnotice; この文書は FreeBSD システム・バージョン 2.X、3.X、4.X についての FAQ です。 特に断わりがない限り、どの項目も FreeBSD 2.0.5 以降のものを想定しています。 <XXX> のついている項目はまだ作業中のものです。 この FreeBSD ドキュメンテーションプロジェクトに協力したいと思われる方は、 &a.doc; まで (英語で) 電子メールを送ってください。 この文書の最新バージョンは、いつでも 日本国内版 FreeBSD World Wide Web サーバや FreeBSD World Wide Web サーバで 見ることができます。 また、ひとつの巨大な HTML ファイルとして HTTP でダウンロードすることもできます。 プレーンテキスト、PostScript、PDF、およびその他の形式のものは FreeBSD FTP サーバに置かれています。 また、FAQ の検索も可能です。 2000 年 3 月現在、HTML 版以外の日本語 FAQ は用意されていません。 日本語版の作成は FreeBSD 日本語ドキュメンテーションプロジェクトが オリジナルの英語版をもとにして行なっています。 FreeBSD FAQ 日本語訳および、 FreeBSD FAQ 日本語版のみに関連することは、 &a.jp.doc-jp; において日本語で議論されています。 必要に応じて日本語ドキュメンテーションプロジェクトから、 FreeBSD Documentation Project に対してフィードバックを行ないますので、 英語が得意でない方は &a.jp.doc-jp; まで日本語でコメントをお寄せください。 また、この FreeBSD FAQ とは別に、日本の FreeBSD ユーザ有志によって メーリングリスト &a.jp.users-jp; やニュースグループ fj.os.bsd.freebsd などへの投稿をもとに作成された QandA が公開されています。 特に日本語環境など日本固有の話題が充実していますので、 こちらも合わせてご覧ください。 まえがき 訳: &a.kuriyama;、 &a.hanai;、 &a.jp.nakai;、 &a.motoyuki;、 &a.jp.sugimura;、 1997 年 11 月 5 日 FreeBSD 2.X-4.X FAQ へようこそ! Usenet の FAQ がそうであるように、 この文書も FreeBSD オペレーティングシステムに関して 頻繁に尋ねられる質問を網羅することを目的としています (もちろんそれに対する答えも!)。 FAQ は本来バンド幅を減らし、 同じ質問が何度も繰り返されるのを避けるために作られたものですが、 最近は有用な情報源と見なされるようになってきました。 この FAQ をできる限り有用なものにしようと、 あらゆる努力がはらわれています。 もし何かしらの改善案が浮かんだら、ぜひ &a.faq; までメールを送ってください。 FreeBSD って何? FreeBSD とは一言で言えば、カリフォルニア大学バークレイ校から リリースされた 4.4BSD-Lite と 4.4BSD-Lite2 による 強化の一部に由来する、 i386 および Alpha/AXP 系のプラットフォーム向けの UN*X ライクなオペレーティングシステムです。 間接的には同じバークレイ校の Net/2 を William Jolitz が i386 系に移植した 386BSD も基にしていますが、 386BSD のコードはほとんど残っていません。 FreeBSD についての詳細と、何ができるかについては FreeBSD のホームページ を参照してください。 FreeBSD は企業やインターネットサービスプロバイダ、研究者、 コンピュータ専門家、学生、家庭のユーザなどにより、業務や教育、 娯楽に用いられています。これらに関しては FreeBSD ギャラリーをご覧ください。 FreeBSD に関するより詳しい情報は FreeBSD ハンドブックを参照してください。 FreeBSD が目指しているもの FreeBSD プロジェクトの目的は、 いかなる用途にも使用でき、 何ら制限のないソフトウェアを供給することです。 私たちの多くは、 コード (そしてプロジェクト) に対してかなりの投資をしてきており、 これからも多少の代償はあっても投資を続けて行くつもりです。 ただ、他の人達にも同じような負担をするように主張しているわけではありません。 FreeBSD に興味を持っている一人残らずすべての人々に、 目的を限定しないでコードを提供すること。 これが、 私たちの最初のそして最大の「任務」であると信じています。 そうすれば、コードは可能な限り広く使われ、 最大の恩恵をもたらすことができるでしょう。 これが、私たちが熱烈に支持しているフリーソフトウェアの最も基本的な目的であると、 私は信じています。 私たちのソースツリーに含まれるソースのうち、GNU 一般公有使用許諾 (GPL) または GNU ライブラリ 一般公有使用許諾 (GLPL) に従っているものについては、 多少制限が科されています。ただし、 ソースコードへのアクセスの保証という、 一般の制限とはいわば逆の制限です。 ただし GPL ソフトウェアを商用で利用する場合、 さらに複雑になるのは避けられません。 そのため、それらのソフトウェアを、より制限の少ない BSD 著作権に従ったソフトウェアで置き換える努力を、 可能な限り日々続けています。 訳注 GPL では、「ソースコードを実際に受け取るか、 あるいは希望しさえすればそれを入手することが可能であること」を求めています。 どうして FreeBSD と呼ばれているのですか? 無料 (free) で使うことができる (商利用も含む)。 オペレーティングシステムの完全なソースコードが自由 (freely) に手に入り、 商利用・非商利用にかかわらず、最低限の制限で他の仕事への利用、配布、導入が可能。 改良やバグフィックスがある場合、 誰でも (free) そのコードを提出でき、 ソースツリーに加えることができます (いくつかの簡単な条件には従ってもらいます)。 母国語が英語でない読者のために、ここでは free という単語が二つの意味で用いられていることを指摘しておくと分かりやすいかも知れません。 ひとつは「無料である」ということ、 もうひとつは「自分のやりたいようにできる」ということです。 FreeBSD のコードでできないいくつかのこと (自分が書いたものだと偽るなど) を除けば、 あなたは自分のやりたいことをやることが可能なのです。 FreeBSD の最新バージョンは? 4.3 が最新の STABLE バージョンで、 2001 年 4 月にリリースされました。 また、これは最新の RELEASE バージョンでもあります。 簡単に言ってしまうと、-STABLE は最新の -CURRENT のスナップショットのすばらしい新機能の数々よりも、 安定性と変更回数の少なさを好む ISP や、 他の企業のユーザをターゲットにしています。 リリースはこの二種類のブランチで行なわれますが、 (-STABLE と比較すると多少) 不安定な動作があるということを許容できるなら、 必要となるのは -CURRENT の方だけでしょう。 各リリースは 数カ月毎にしか行なわれません。 多くの人々が FreeBSD のソースをそのリリースよりも 最新の状態に維持している (FreeBSD-current と FreeBSD-stable に関する質問も参照してください) のですが、 ソースというのは常に改変され続けているため、 そうすることは一種の慣例になっています。 FreeBSD-CURRENTって何? FreeBSD-CURRENT はオペレーティングシステムの開発バージョンで、 やがて 5.0-RELEASE となります。よってこれは、そこに携わっている開発者や、 どんな障害をも乗り越えていけるタフな愛好家たちにとってのみ興味の対象となるものです。 -CURRENT の使用に際しての詳細は FreeBSD ハンドブック の 関連するセクション を参照してください。 オペレーティングシステムに馴染みがない場合や、 それが一時的に発生している問題なのか、 それとも本質的な問題かを見極める能力がない場合は、 FreeBSD-CURRENT を使うべきではありません。 このブランチは時々急激に拡張されたり、 システムが構築できない状態になることもちょっちゅうあります。 FreeBSD-CURRENT を使う人は問題を分析し、 「小さな欠陥」ではなく、 明らかに間違いであると思われるものだけを報告できるものと想定されています。 「make world したら group 関係でエラーがでました」のような質問は、 -CURRENT メーリングリストでは軽蔑の眼差しであしらわれることもあります。 毎日、その時点の -CURRENT と -STABLE のコードを元に snapshot が作成されています。 現在は、その snapshot の配布も利用可能です。 それぞれの snapshot には以下のような目的があります。 インストールプログラムの最新版のテスト。 試してみたいけれど、 基礎的な所から毎日変わるようなものを追いかける時間もバンド幅も無い、 という人にも -CURRENT や -STABLE を使えるようにする。 また、そのような人たちのシステム移行のための手っ取り早い方法を提供する。 あとでとんでもないことをしてしまった時のために、 問題となるコードの特定の参照基準点を保存しておく。 (通常は CVS がこういうハプニングのような恐ろしい事態を防止して いるんですけどね :) テストが必要な新しい機能を、 できる限り多くの隠れテスターに試してもらう。 どんな目的であれ、-CURRENT snapshot が 製品レベルの品質 であるとの考えに基づく要求は行わないでください。 安定性やテスト十分性にこだわる人は、 完全なリリース、あるいは -STABLE snapshot から離れてはいけません。 スナップショットリリースは、5.0-CURRENT が ftp://current.FreeBSD.org/pub/FreeBSD/ から、4-STABLE が releng4.FreeBSD.org から直接入手可能です。 また、3-STABLE スナップショットは、 この文章の執筆時点 (2000 年 5 月) で作成されていません。 スナップショットリリースは、 現在、開発や保守作業が行なわれているすべてのブランチにおいて、 平均して一日一回作成されます。 FreeBSD-STABLE のコンセプトは何ですか? FreeBSD 2.0.5 がリリースされた後、私たちは FreeBSD の開発を 2 系統に分割することにしました。 一つは -STABLE というブランチで、バグの修正はしっかりテストされ、 機能の強化は少しずつしか行われません (急な変更や実験的機能を望まない、 インターネットサービスプロバイダや営利企業向け)。 もう一方のブランチは -CURRENT で、2.0 がリリースされて以来 5.0-RELEASE (そしてその後も) へ向けて脈々と続いているものです。 ASCII で描いた簡単な図がわかりやすいかは自信がありませんが、 こんな感じになります。 2.0 | | | [2.1-STABLE] *BRANCH* 2.0.5 -> 2.1 -> 2.1.5 -> 2.1.6 -> 2.1.7.1 [2.1-STABLE 終了] | (1997/03) | | | [2.2-STABLE] *BRANCH* 2.2.1 -> 2.2.2-RELEASE -> 2.2.5 -> 2.2.6 -> 2.2.7 -> 2.2.8 [終了] | (1997/03) (1997/10) (1998/04) (1998/07) (1998/12) | | 3.0-SNAPs (1997 年第一四半期開始) | | 3.0-RELEASE (1998/10) | | [3.0-STABLE] *BRANCH* 3.1-RELEASE (1999/02) -> 3.2 -> 3.3 -> 3.4 -> 3.5 -> 3.5.1 | (1999/05) (1999/09) (1999/12) (2000/06) (2000/07) | [4.0-STABLE] *BRANCH* 4.0 (2000/03) ->4.1 -> 4.1.1 -> 4.2 -> 4.3 -> ... 将来の 4.x リリース ... | | (2000/07) (2000/09) (2000/11) | \|/ + [5.0-CURRENT として継続中] -CURRENT ブランチは 5.0 とその先へ向けてゆっくりと進化を続けています。 従来あった 2.2-STABLE ブランチは 2.2.8 のリリースをもって終了しました。 3-STABLE がそれに代わり、2000 年 7 月に 3.5.1-RELEASE (最後の 3.X リリース) がリリースされました。 2000 年 3 月 (3.5 の公開前になりますが) には、 3-STABLE ブランチはほぼ、4-STABLE ブランチによって置き換えられました。 4.3-RELEASE は 2001 年 4 月にリリースされました。 4-STABLE は現在 -STABLE ブランチで活発に開発が続けられていますが、 3-STABLE へのバグの修正 (ほとんどがセキュリティ関連のもの) もまだ行なわれています。 3.X ブランチは 2000 年の夏には公式に開発が終了する予定です。 現在の current branch は 5.0-CURRENT であり、 最初の 5.0 系列のリリース予定はまだ決定していません。 FreeBSD のリリースはいつ作られるのですか? FreeBSD コアチームは原則的に、 新しい機能やバグフィックスが充分集まり、 リリースの安定性を損なうことが無いよう、 さまざまな変更が十分に安定しているという条件を満たしている場合にのみ、 新しいバージョンの FreeBSD をリリースします。 たとえこの用心深さが新しい機能が使えるようになることを 待ち望んでいるユーザを欲求不満にさせるとしても、 多くのユーザはこのことを FreeBSD の最も良い所の一つだと考えています。 リリースの作成は、平均的に言っておよそ 4 ヶ月ごとに行なわれます。 もう少し刺激が欲しい (あるいは待ち遠しい) 方々向けには、 毎日バイナリスナップショットが作成されています。 上記を参照してください。 FreeBSD は PC 用だけしかないの? FreeBSD 3.x 以降は x86 アーキテクチャと同様、 DEC Alpha でも動作します。 また、SPARC、PowerPC、IA64 への移植という興味深い話もあります。 異なるアーキテクチャのマシンを 持っていて、ゆっくり待てないという場合には次の URL を 参照してください。 NetBSD または OpenBSD。 FreeBSD の責任者はいったい誰? プロジェクトの全体的な方向性や、 誰にソースツリーにコードの書き込み権限を与えるか、 などといった FreeBSD プロジェクトに関する重要な意思決定は、 9 名からなるコアチーム (core team) によってなされます。 ソースツリーを直接変更できる人はもっと多く、 200 名以上のソースツリー管理者 (committer) がいます。 しかし、メーリングリストで先行して議論される、 通常の変更ではないものの議論への参加には、一切制限はありません。 どこから FreeBSD を入手できますか? FreeBSD のすべての主要なリリースは anonymous FTP 経由で FreeBSD FTP サイト から入手できます。 現在の 3.X-STABLE リリース、3.5.1-RELEASE は 3.5.1-RELEASE のディレクトリにあります。 現在の 4-STABLE リリース、4.3-RELEASE は 4.3-RELEASE のディレクトリにあります。 4.X Snapshot は、ほぼ一日に一回作成されています。 5.0 Snapshot リリースは -CURRENT ブランチ用に一日に一回作成されており、 これらは純粋に最先端の開発者およびテスターのために提供されています。 また、FreeBSD は CD-ROM でも入手でき、次のところで注文できます。
BSDi 4041 Pike Lane, Suite F Concord, CA 94520 USA Orders: +1 800 786-9907 Questions: +1 925 674-0783 FAX: +1 925 674-0821 email: BSDi Orders address WWW: BSDi Home pageOrders: +1 800 786-9907
オーストラリアでは、次のところに問い合わせてください。
Advanced Multimedia Distributors Factory 1/1 Ovata Drive Tullamarine, Melbourne Victoria Australia Voice: +61 3 9338 6777 CDROM Support BBS 17 Irvine St Peppermint Grove, WA 6011 Voice: +61 9 385-3793 Fax: +61 9 385-2360
イギリスの場合は次のところです。
The Public Domain & Shareware Library Winscombe House, Beacon Rd Crowborough Sussex. TN6 1UL Voice: +44 1892 663-298 Fax: +44 1892 667-473
 FreeBSD のメーリングリストについて知りたいのですが? 完全な情報が FreeBSD ハンドブックのメーリングリストの節 にあります。 FreeBSD の西暦 2000 年問題に関する情報はどこにありますか? 完全な情報が FreeBSD Y2K のページ にあります。 FreeBSD のニュースグループは何がありますか? 完全な情報が FreeBSD ハンドブックのニュースグループの節にあります。 FreeBSD の IRC (Internet Relay Chat) について何か情報はありますか? あります。 以下のように、ほとんどの有名な IRC ネットワークには FreeBSD のチャットチャンネルがあります。 EFNet の Channel #FreeBSD は FreeBSD 関係のフォーラムですが、 そこで技術的サポートを期待してはいけません。 そこにいる人たちはあなたをマニュアルページを読むとか、 研究をするとかといった苦労から遠ざけようとします。 まず第一に、これはチャットチャンネルであり、 そこにあるトピックスは恋人募集、スポーツ、 核兵器といったようなものであり、 FreeBSD も同列に扱われています。 一応注意しましたからね! これは irc.chat.org のサーバー上にあります。 EFNet の Channel #FreeBSDhelp は FreeBSD ユーザのヘルプ専用チャネルです。 参加者は #FreeBSD チャネルよりも親切に質問に答えてくれます。 DALNET の Channel #FreeBSD はアメリカでは irc.dal.net、 ヨーロッパでは irc.eu.dal.net にあります。 UNDERNET の Channel #FreeBSD はアメリカでは us.undernet.org、 ヨーロッパでは eu.undernet.org にあります。 ここはヘルプチャンネルです。 ドキュメントを読める準備をしてから利用してください。 HybNet の Channel #FreeBSD。 このチャンネルはへルプチャンネルです。 サーバーのリストは HybNet のウェブサイト にあります。 それぞれのチャンネルは別個のもので、 互いに接続されていません。 チャットのスタイルも違っていますので、 自分のチャットのスタイルにあったものを見つけるために一つ一つ試すのもいいでしょう。 あらゆる種類の IRC トラフィックのため、失礼なことをいう若者たち (年輩の方は少数です) のために機嫌を損ねたり、 手に負えなくなっても気にしてはいけません。 FreeBSD の本 &a.doc; にコンタクトしてみてください (さらに参加すればもっとよいでしょう)。 このメーリングリストは FreeBSD 関連の文書に関する議論のためのものです。 FreeBSD に関する質問に対しては、 &a.questions; というメーリングリストがあります。 FreeBSD ハンドブックもあります。 これは現在作業中で、 不完全だったり最新情報でないものが含まれていることに注意してください。 FreeBSD のガイド本の決定版は、 Greg Lehey 氏による The Complete FreeBSD です。 これは BSDi (以前の Walnut Creek CDROM) Books から出版されています。 現在は第三版になっていて、 インストール、システム管理ガイド、プログラム設定のヘルプ、 マニュアルページまでの内容が 773 ページにわたって書かれています。 この本は (そして現在の FreeBSD リリースは) BSDi、 CheapBytes、 または最寄りの書店で注文することができます。 ISBN コードは 1-57176-246-9 です (これ以外のコードの場合もあるかもしれません)。 また、FreeBSD は Berkeley 4.4BSD-Lite ベースなので、多くの 4.4BSD のマニュアルが FreeBSD にも応用できます。 O'Reilly and Associates が以下のマニュアルを出版しています。 4.4BSD System Manager's Manual By Computer Systems Research Group, UC Berkeley 1st Edition June 1994, 804 pages ISBN: 1-56592-080-5 4.4BSD User's Reference Manual By Computer Systems Research Group, UC Berkeley 1st Edition June 1994, 905 pages ISBN: 1-56592-075-9 4.4BSD User's Supplementary Documents By Computer Systems Research Group, UC Berkeley 1st Edition July 1994, 712 pages ISBN: 1-56592-076-7 4.4BSD Programmer's Reference Manual By Computer Systems Research Group, UC Berkeley 1st Edition June 1994, 886 pages ISBN: 1-56592-078-3 4.4BSD Programmer's Supplementary Documents By Computer Systems Research Group, UC Berkeley 1st Edition July 1994, 596 pages ISBN: 1-56592-079-1 これらの詳細な説明が WWW 経由で 4.4BSD books description から読むことができます。 販売数が少ないためこれらのマニュアルは入手しにくいかもしれません。 4.4BSD のカーネル構成についてより徹底的に知りたいのなら、 これなら間違いないでしょう。 McKusick, Marshall Kirk, Keith Bostic, Michael J Karels, and John Quarterman. The Design and Implementation of the 4.4BSD Operating System. Reading, Mass. : Addison-Wesley, 1996. ISBN: 0-201-54979-4 システム管理について参考になる本は次のものです。 Evi Nemeth, Garth Snyder, Scott Seebass & Trent R. Hein, ``Unix System Administration Handbook'', Prentice-Hall, 2000 ISBN: 0-13-0206016 初版のものではなく、紫色のカバーの第三版であるか 確認してください。 この本は TCP/IP だけでなく DNS、NFS、SLIP/PPP、sendmail、 INN/NNTP、印刷などの基礎を扱っています。 高価ですが、買う価値はあります。 第三版では、Solaris, HP/UX, FreeBSD および Linux を取り扱っています。 障害報告 (PR; Problem Report) データベースにアクセスする方法は? ユーザからの変更要求がまとめられている Problem Report データベースは、 障害報告の web ベースのインタフェースを通して、 提出と問い合わせを行なうことができます。 また、send-pr(1) コマンドを使用して、 電子メール経由で障害報告や変更要求を提出することもできます。 プレインテキスト (ASCII) 版 や PostScript 版の FreeBSD 文書はないのでしょうか? はい、もちろんあります。 数多くの異なるフォーマット、圧縮形式の文書が FreeBSD FTP サイトの /pub/FreeBSD/doc/ というディレクトリから入手可能です。 文書は、次のようなさまざまな観点から分類されています。 faq や handbook といった文書名による分類。 文書の言語とエンコーディングによる分類。これは FreeBSD システムの /usr/share/locale にある locale 名に基づいています。 現在利用可能な言語、エンコーディングは以下のとおりです。 名前 意味 en_US.ISO8859-1 英語 (米国) de_DE.ISO_8859-1 ドイツ語 es_ES.ISO8859-1 スペイン語 fr_FR.ISO8859-1 フランス語 ja_JP.eucJP 日本語 (EUC エンコーディング) ru_RU.KOI8-R ロシア語 (KOI8-R エンコーディング) zh_TW.Big5 中国語 (Big5 エンコーディング) 言語によっては準備されていない文書も存在します。 文書の形式による分類。 文書は数多くの異なる出力形式を用意し、 可能な限り柔軟な対応ができるようにしています。 現在、利用可能な文書形式は以下のとおりです。 文書形式 意味 html-split サイズの小さい、 リンクされた複数の HTML ファイル html 文書全体を含んだ、単一の大きなファイル pdb iSilo で利用可能な Palm Pilot データベース形式 pdf Adobe 社の PDF (Portable Document Format) 形式 ps Postscript 形式 rtf Microsoft 社のリッチテキスト形式 この形式を Word で読み込んだ場合、 ページ番号は自動的に更新されません。 ページ番号を更新するには文書を読み込んでから CTRL+A、 CTRL+END、 F9 を押してください。 txt プレインテキスト形式 圧縮と package 形式による分類。 現在利用されているのは次の 3 種類です。 html-split 形式の場合、 ファイルはまず、&man.tar.1; を使ってまとめられ、 まとめられた .tar ファイルは次に解説する方式で圧縮されます。 その他の形式の場合、ファイルは book.format (たとえば book.pdb、 book.html など) という単一のファイルです。 上にあげたファイルは 3 種類の方式のいずれかで圧縮されます。 方式 説明 zip Zip 形式。 FreeBSD で圧縮を元に戻すには、まず archivers/unzip の port をインストールする必要があります。 gz GNU Zip 形式。圧縮を元に戻すには、 FreeBSD に含まれる &man.gunzip.1; を使います。 bz2 BZip2 形式。 他の形式に比べて普及していませんが、 一般的にファイルサイズが小さくなります。 圧縮を元に戻すには、 archivers/bzip2 port をインストールしてください。 Postscript 版のハンドブックが BZip2 形式で圧縮されている場合、ファイル名は handbook/ ディレクトリの中の book.sgml.bz2 になります。 さまざまな形式に整形された文書は、以下に述べるように FreeBSD の package としても提供されています。 ダウンロードする文書と圧縮形式を選択したら、 文書を FreeBSD package としてダウンロードするかどうか決めなければなりません。 package としてダウンロードしてインストールする場合には、 文書を &man.pkg.add.1; や &man.pkg.delete.1; といった、普通の FreeBSD package 管理システムを用いた管理が可能であるという利点があります。 文書の package をダウンロードしてインストールすることに決めたら、 まずはダウンロードするファイル名を知る必要があります。 文書の package は、packages というディレクトリに置かれています。 そしてそれぞれの package ファイルは、 文書名.言語.エンコーディング.形式.tgz というような名前になっています。 たとえば、FAQ の英語版で PDF 形式のものは、 faq.en_US.ISO8859-1.pdf.tgz というファイル名です。 ファイル名がわかったら、 次のようなコマンドで英語版の PDF 形式 FAQ の package をインストールすることができます。 &prompt.root; pkg_add ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/packages/faq.en_US.ISO8859-1.pdf.tgz インストールの終了後は &man.pkg.info.1; を使い、 ファイルがどこにインストールされたかを調べることができます。 &prompt.root; pkg_info -f faq.en_US.ISO8859-1.pdf Information for faq.en_US.ISO8859-1.pdf: Packing list: Package name: faq.en_US.ISO8859-1.pdf CWD to /usr/share/doc/en_US.ISO8859-1/books/faq File: book.pdf CWD to . File: +COMMENT (ignored) File: +DESC (ignored) ご覧になるとわかるとおり、book.pdf は /usr/share/doc/en_US.ISO8859-1/books/faq にインストールされます。 package を利用しない場合は、 自分で圧縮されたファイルをダウンロードして元に戻し、 適切な場所にそれをコピーする必要があります。 たとえば、分割された HTML 版の FAQ で、 &man.gzip.1; で圧縮されているものは en_US.ISO8859-1/books/faq/book.html-split.tar.gz というファイルです。 これをダウンロードして圧縮を元に戻すには、次のようにする必要があるでしょう。 &prompt.root; fetch ftp://ftp.freebsd.org/pub/FreeBSD/doc/en_US.ISO8859-1/books/faq/book.html-split.tar.gz &prompt.root; gzip -d book.html-split.tar.gz &prompt.root; tar xvf book.html-split.tar こうすると、複数の .html ファイルが作成されます。 中心となっているのは index.html という名前のファイルで、 目次や前書き、文書の他の部分へのリンクが含まれています。 これらのファイルは、必要に応じて他の場所にコピーしても構いません。 FreeBSD のウェブサイトのミラーサイトになりたいです! 承知しました! ウェブページをミラーするにはいくつかの手段があります。 CVSup を使います。 CVSup を使って CVSup サーバに接続することで、 整形されたファイルを取ってくることができます。 ウェブページを取得する場合は、 /usr/share/examples/cvsup/www-supfile にある supfile の例を参考にしてください。 FTP を使ってミラーリングします。 あなたの好きな FTP ミラーリングツールを使って、 FTP サーバに置いてある web サイトのコピーをダウンロードすることができます。 タウンロードは単純に ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-CURRENT/www から始めてください。 この文書を他の言語に翻訳したいのですが? 報酬は支払えませんが、 文書の翻訳を提出してくださる方には、 フリーの CD、T シャツの手配や、 ハンドブックにある貢献者一覧への登録を行ないたいと思います。 翻訳作業をはじめる前に、 &a.doc; へ連絡するようにお願いします。 翻訳作業を手伝うという人が現われるかも知れませんし。 既に翻訳チームがあって、あなたの参加を歓迎してくれるかも知れません。 その他の情報 以下のニュースグループには FreeBSD ユーザに直接関係のある議論が行われてます。 comp.unix.bsd.freebsd.announce (moderated) comp.unix.bsd.freebsd.misc comp.unix.bsd.misc Web 上のリソース: FreeBSD のホームページ ラップトップ PC を持っている方は、 迷うことなく日本の細川 達己氏の Mobile Computing のページ を見ましょう。 SMP (Symmetric MultiProcessing) に関する情報は、 SMP サポートページをご覧ください。 FreeBSD のマルチメディアアプリケーションに関する情報は、 マルチメディアのページをご覧ください。 特に Bt848 ビデオキャプチャチップに興味のある方は、 リンクをたどってみてください。 FreeBSD ハンドブックには、 実に完成された参考図書の一覧があり、 買うべき本をさがしている方は読む価値があります。 インストール 訳: &a.iwasaki;、 &a.jp.mrt;、 1997 年 11 月 8 日 FreeBSD を入手するには、どのファイルをダウンロードすれば良いのでしょうか? FreeBSD 3.1-RELEASE 以前では、 インストールの際に必要なのは floppies/boot.flp と名前のついた 一つのフロッピーディスクイメージだけでした。 しかし FreeBSD 3.1-RELEASE 以降、 幅広い種類のハードウェアサポートが基本システムに追加され、 そのサポートが必要とする容量を補うため、 3.X と 4.X の系列では新たに、 floppies/kernel.flp および floppies/mfsroot.flp という、二つのフロッピーディスクイメージを使うようになりました。 これらのイメージをフロッピーディスクに書き込むには、 fdimage や &man.dd.1; といったツールが必要となります。 (DOS ファイルシステムからのインストールなどで) あなた自身が手動で配布ファイルをダウンロードする場合には、 以下の配布ファイルをダウンロードすることをおすすめします。 bin/ manpages/ compat*/ doc/ src/ssys.* この手順の完全な説明と、一般的なインストール時の問題については FreeBSD ハンドブックのインストールの節 を参照してください。 ブートフロッピーイメージが一枚のフロッピーディスクに納まらないみたい! 3.5 インチ (1.44MB) のフロッピーディスクには、 1474560 バイトのデータを格納できます。 ブートイメージはちょうど 1474560 バイトの大きさです。 ブートフロッピーディスクを準備する際のよくある間違いには、 以下のものがあります。 FTP によってフロッピーイメージをダウンロードする際に、 バイナリ (binary) モードにしていなかった。 FTP クライアントの中には、 転送モードのデフォルトをアスキー (ascii) モードにして、 クライアント側システムの慣習にあうよう、 すべての行末の文字を変更するものがあります。 この場合は常に、ブートイメージが壊れたものになります。 ダウンロードしたブートイメージのサイズをチェックしてください。 サーバ上のものと正確に一致しなければ、 ダウンロードの処理を疑いましょう。 これを回避するには、 サーバに接続してイメージのダウンロードを開始する前に FTP のコマンドプロンプトで binary とタイプします。 ブートイメージを DOS の copy コマンド (または GUI の同等のツール) でフロッピーディスクへ転送した。 copy のようなプログラムは、 直接起動するように作成されたブートイメージをうまく処理できません。 イメージにはフロッピーディスクの完全な中身がトラック単位で格納されており、 フロッピーディスク上に通常のファイルとして 格納されるように想定されているわけではありません。 FreeBSD のインストールに記述されているように、 低レベルのツール (たとえば fdimage や rawrite) を使用して そのままの (raw) の状態でフロッピーディスクに 転送する必要があります。 FreeBSD のインストールについての説明書はどこにありますか? インストールの説明書はFreeBSD ハンドブックのインストールの章にあります。 FreeBSD を動作させるには何が必要ですか? 386 以上の PC、5MB 以上の RAM、 そして最低 60MB のハードディスク容量が必要となります。 ローエンドの MDA カードでも動作しますが、 X11R6 を使うには VGA かそれ以上のビデオカードが必要となります。 もご覧ください。 4MB しかメモリがないのですが、インストールできますか? 4MB のシステムにインストールできた最後の FreeBSD は FreeBSD 2.1.7 でした。2.2 を含むより新しいバージョンの FreeBSD は新規のインストールに最低 5MB は必要になります。 ただし、インストールプログラムが 4MB では動作しないだけで、 3.0 を含む FreeBSD のすべてのバージョンは 4MB の RAM で動作可能です。 インストールする時だけさらに 4MB 追加しておき、 システムがセットアップされて動作するようになった後、 また 4MB を取り出して元に戻すこともできます。 あるいは 4MB より多くメモリを搭載したシステムにディスクを持っていき、 そのマシンでインストールした後にディスクを戻すこともできます。 また、FreeBSD 2.1.7 であっても、4MB ではインストールできない場合があります。 正確には、640KB のベースメモリ + 3MB の拡張メモリでは、 インストールはできません。もしマシンのマザーボードが 640KB から 1MB の領域で「失われた」メモリを再マップできる場合は、 FreeBSD 2.1.7 をインストールできるかもしれません。 BIOS のセットアップ画面で、remap のオプションを探して有効 (enable) にしてみてください。 また、ROM shadowing を無効 (disable) にする必要もあります。 簡単なやり方としては、インストールする時だけあと 4MB 追加しておく方法があります。 必要なオプションだけを選択してカスタムカーネルを構築し、 また 4MB を取り出してもとに戻せばいいのです。 また、2.0.5 をインストールして、 それから 2.1.7 のインストーラの upgrade オプションでシステムを 2.1.7 へアップグレード するというやり方もあります。 インストールしたあとでカスタムカーネルの構築をした場合には、 4MB でも動作します。 2MB で起動に成功した人もいます (でもそのシステムは、 ほとんど使いものになりませんでした :-))。 自分用のインストールフロッピーを作るには? 現在はカスタムインストールフロッピーディスク「だけ」を作る方法はありません。 カスタムインストールフロッピーディスクイメージを含む、 release 環境全体を新たに作る必要があります。 カスタムの release 環境をつくるには、 ここの指示にしたがってください。 自分の PC に複数のオペレーティングシステムを入れるには? multi-OS のページをご覧ください。 同じマシンで Windows 95/98 と共存できますか? まず Windows 95/98 をインストールしてから、そのあとで FreeBSD をインストールしてください。FreeBSD のブートマネージャが Win95 と FreeBSD のブート管理をしてくれるようになります。 Windows 95/98 を後にインストールした場合はひどいことに、 問い合わせることもなくブートマネージャを上書きしてしまいます。 そうなってしまった場合は次の節をご覧ください。 Windows 95/98 がブートマネージャを潰しちゃった! どうやって戻すの? ブートマネージャの再インストールの方法として、 FreeBSD では以下に示す三通りの方法が用意されています。 DOS を起動し、FreeBSD の配布物の中にある tools/ ディレクトリへ移動し、 bootinst.exe を探してください。 そして次のように実行します。 ...\TOOLS> bootinst.exe boot.bin こうすることで、 ブートマネージャが再インストールされます。 FreeBSD のブートフロッピーディスクから起動し、 「カスタム」インストールメニューを選択し、 続いて「パーティション」を選択します。 ブートマネージャがインストールされていたドライブ (多分最初のもの) を選択し、 パーティションエディタにたどり着いたら、 (何も変更せず) そのまま (W)rite を指定します。 確認のメッセージが出ますので「はい(Y)」と答え、 ブートマネージャ選択の画面で確実に Boot Manager を選択します。 これでブートマネージャがディスクに再び書き込まれます。 インストールメニューから抜けて再起動すると、 ハードディスクは元通りになります。 FreeBSD 起動フロッピー (もしくは CD-ROM) から起動し、 Fixit メニューを選択します。 Fixit フロッピーか CD-ROM #2 (live - ファイルシステムオプション) の好きな方をを選択して + ファイルシステムオプション) の好きな方を選択して fixit シェルに入ります。 そして、次のコマンドを実行してください。 Fixit# fdisk -B -b /boot/boot0 起動デバイス 起動デバイス の部分は、たとえば ad0 (一番目の IDE ディスク)、 ad4 (セカンダリ IDE コントローラの一番目の IDE ディスク)、 da0 (一番目の SCSI ディスク) などといった、実際の起動デバイスを表しています。 IBM Thinkpad の A、T、X シリーズのいずれかを持っています。 FreeBSD をインストールしたら起動しなくなってしまいました。 どうすればいいですか? これらのマシンに使われている初期のリビジョンの IBM BIOS にはバグがあり、FreeBSD のパーティションをディスクサスペンド用の FAT 領域だと誤認します。 そのため、BIOS が FreeBSD のパーティションを 検出したところでシステムがハング (停止) してしまいます。 IBM これは Keith Frechette kfrechet@us.ibm.com からのメールによります。 によれば、以下のモデル/BIOS リリース番号には修正が含まれています。 モデル BIOS リビジョン番号 T20 IYET49WW 以降 T21 KZET22WW 以降 A20p IVET62WW 以降 A20m IWET54WW 以降 A21p KYET27WW 以降 A21m KXET24WW 以降 A21e KUET30WW それより新しいリビジョンの BIOS にまたバグが入り込んだか もしれないという報告がありました。Jacques Vidrine は mobile@freebsd.org メーリングリストにあてた メッセージ で、これ以降の IBM の laptop で FreeBSD が正常に起動しない 場合におそらくうまく行く、BIOS をアップグレードまたは ダウングレードできる手順を説明しています。 もし問題のある BIOS を使っていてアップグレードが選べない場合、 FreeBSD をインストールしてから FreeBSD が使っているパーティション ID を変更し、 変更されたパーティション ID を正しく扱うことのできる 新しい起動ブロックをインストールすることで解決することができます。 それにはまず、 セルフテスト画面を通過する状態にまでマシンを回復させる必要があります。 そのためには、マシンがプライマリディスクから FreeBSD パーティションを見つけないようにして起動しなければなりません。 たとえば、一度ハードディスクを外してしまって、そのディスクを古い ThinkPad (ThinkPad 600 など) やデスクトップ PC に適切な変換ケーブルで接続します。 その後 FreeBSD のパーティションを削除し、 ハードディスクを元の ThinkPad に戻します。 こうすることで ThinkPad は起動可能な状態に戻るはずです。 マシンがちゃんと動くようになったら、 以下の復旧手順に従って FreeBSD をインストールすることができます。 http://people.freebsd.org/~bmah/ThinkPad/ から boot1 と boot2 をダウンロードします。 これらのファイルは、 あとで必要になった時、取り出せる場所に置いておきます。 ThinkPad に普通に FreeBSD をインストールします。 ただし、Dangerously Dedicated モードを使ってはいけません。 また、インストールが終わっても再起動してはいけません。 緊急ホログラフィックシェル (Emergency Holographic Shell) (ALTF4) に切り替えるか、fixit シェルを起動します。 &man.fdisk.8; を使って FreeBSD のパーティション ID を 165 から 166 に 変更します (これは OpenBSD で使われているものです)。 boot1 と boot2 のファイルをローカルファイルシステムに持って来ます。 &man.disklabel.8; を使って boot1 と boot2 を FreeBSD のスライスに書き込みます。 &prompt.root; disklabel -B -b boot1 -s boot2 ad0sn n は、 あなたが FreeBSD をインストールしたスライスの番号です。 再起動します。起動プロンプトは OpenBSD と示しますが、実際には、それで FreeBSD が起動します。 この方法で FreeBSD と OpenBSD をデュアルブートする方法は、読者への練習問題としましょう。 不良ブロックのあるディスクにインストールできますか? FreeBSD 3.0 以前のシステムでは、 不良ブロックを自動的に再マッピングする bad144 というユーティリティが含まれていましたが、 現在の IDE ドライブはドライブ自身がこの機能を備えているため、 bad144 は FreeBSD ソースツリーから削除されました。 FreeBSD 3.0 かそれ以降をインストールしたいと思っているなら、 比較的新しいディスクドライブを購入することを強くおすすめします。 新しいドライブを購入する気がなければ、FreeBSD 2.x を利用するべきです。 現在の IDE ドライブで不良ブロックによるエラーが発生した場合、 まもなくドライブが故障する可能性があります (それはそのドライブ内蔵の再マッピング機能では 不良ブロックが修正できなくなったということであり、 ディスクがひどく壊れていることを意味します)。 新しいハードディスクドライブに交換しましょう。 不良ブロックのある SCSI ドライブの場合は、 この回答を参照してください。 インストーラから起動したら変なことになりました! インストーラから起動しようとしたときに、マシンが固まってし まうとか自然と再起動してしまうといった現象であれば、 次の三つの項目を確認してください。 新品の、フォーマットしたての、 エラーのないフロッピーディスクを使っていますか? (三年間もベッドの下に放置されていた雑誌の付録みたいなやつではなくて、 買ってきたばかりの新品を使ってください) フロッピーイメージをバイナリモードでダウンロードしましたか? (困った顔をしないでください。私たちの中で一番優秀な人でさえ、 少なくとも一回はバイナリファイルを ASCII モードで思いがけずダウンロードしたことがあるのです!) Windows95 あるいは Windows98 を使用しているなら、 ありのままの本物の DOS で fdimage か rawrite を実行しましたか? これらの OS はディスク作成プログラムのような、 ハードウェアに直接書き込みを行なうプログラムに干渉する可能性があります。 GUI の中の DOS シェル内部で動作している場合でも、 この問題は発生します。 また、Netscape でブートイメージをダウンロードする場合も問題があることが報告されていますので、 できれば別の FTP クライアントを使うのがよいでしょう。 APAPI CD-ROM から起動したのですが、 インストールプログラムは CD-ROM が見つかりませんと言ってきます。 CD-ROM はどこに行ってしまったのでしょうか? この問題は通常、CD-ROM ドライブの設定ミスによって発生します。 大部分の PC の CD-ROM ドライブは、 セカンダリ側の IDE コントローラのスレーブデバイスとして接続され、 マスタデバイスがない状態で出荷されています。 この接続方法は ATAPI 規格違反なので、 Windows は規格どおりに動いたり、動かなかったりしますが、 BIOS は起動時に規格違反を無視します。 そのため BIOS は起動時に CD-ROM を見つけられますが、 FreeBSD は CD-ROM を見つけられず、 インストールを完了できないのです。 CD-ROM が 接続されている IDE コントローラのマスタデバイスとなるように設定するか、 もしくはマスタ、 スレーブの両方にデバイスが接続されているようにシステムを再構成してください。 あれれ? テープからインストールできません! FreeBSD 2.1.7R をテープからインストールする場合、 tar ブロックサイズを 10 (5120 バイト) にしたテープを作る必要があります。 デフォルト の tar ブロックサイズは 20 (10240 バイト) で、 このデフォルトサイズで作られたテープでは FreeBSD 2.1.7R をインストールすることはできません。 もしこうしたテープを使うと、 レコードサイズが大きすぎるというエラーが起きることになります。 PLIP 経由で二つ FreeBSD box を接続したいのですが Laplink パラレルケーブルを用意して、 両方の PC のカーネルに lpt ドライバが組み込まれていることを確認してください。 &prompt.user; dmesg | grep lp lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface パラレルインタフェースに Laplink パラレルケーブルを接続します。 root になって、両方で lp0 のネットワークインタフェースパラメータを設定します。 たとえば、ホスト max と moritz を接続したい場合、 max <-----> moritz IP Address 10.0.0.1 10.0.0.2 max 側で次のようにして、 &prompt.root; ifconfig lp0 10.0.0.1 10.0.0.2 moritz 側で同様に次のようにします。 &prompt.root; ifconfig lp0 10.0.0.2 10.0.0.1 以上です! &man.lp.4; と &man.lpt.4; のマニュアルページも参照してください。 また、 /etc/hosts にホストの追加もしましょう。 127.0.0.1 localhost.my.domain localhost 10.0.0.1 max.my.domain max 10.0.0.2 moritz.my.domain moritz 動作確認は次のようにします。 max 側: &prompt.user; ifconfig lp0 lp0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 10.0.0.1 --> 10.0.0.2 netmask 0xff000000 &prompt.user; netstat -r Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire moritz max UH 4 127592 lp0 &prompt.user; ping -c 4 moritz PING moritz (10.0.0.2): 56 data bytes 64 bytes from 10.0.0.2: icmp_seq=0 ttl=255 time=2.774 ms 64 bytes from 10.0.0.2: icmp_seq=1 ttl=255 time=2.530 ms 64 bytes from 10.0.0.2: icmp_seq=2 ttl=255 time=2.556 ms 64 bytes from 10.0.0.2: icmp_seq=3 ttl=255 time=2.714 ms --- moritz ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 2.530/2.643/2.774/0.103 ms ラップトップ PC に PLIP 経由でインストールできますか? 次のようにして、二つのコンピュータを Laplink パラレルケーブルで接続してください。 ネットワーク接続用のパラレルケーブルの結線 A-name A 側 B 側 説明 ポート / ビット DATA0 -ERROR 2 15 15 2 Data 0/0x01 1/0x08 DATA1 +SLCT 3 13 13 3 Data 0/0x02 1/0x10 DATA2 +PE 4 12 12 4 Data 0/0x04 1/0x20 DATA3 -ACK 5 10 10 5 Strobe 0/0x08 1/0x40 DATA4 BUSY 6 11 11 6 Data 0/0x10 1/0x80 GND 18-25 18-25 GND -
また、 Mobile Computing についてのページもご覧ください。 ハードディスクドライブには、 どのジオメトリを使うべきでしょうか? ここでディスクの「ジオメトリ」とは、ディスクのシリンダ、ヘッダ、 トラック当りのセクタの数を意味しています - 便宜上、 C/H/S とすることにします。これはディスクのどの領域で読み書きを 行なうかを PC の BIOS が決定する手段となります。 これについてはある理由のために、誤解されている点が多いようです。 まず最初に、FreeBSD はディスクブロックで動作しているため、 SCSI ドライブの物理的なジオメトリという言い方は、 まったく見当違いのものです。事実、 セクタの密度はディスクによってまちまちであるため、 物理的なジオメトリというものは存在しません。 製造者が「本当の」物理的なジオメトリと公表しているものは通常、 彼らが検査して得た最小の使用不可容量の結果のジオメトリのことです。 IDE の場合、FreeBSD は C/H/S で動作しますが、 最近のドライブはすべて、これを内部で参照するブロックに変換しています。 問題はとなるのは論理的なジオメトリです。 これは BIOS がそのディスクのジオメトリについて調べた際に取得されるものであり、 その後のディスクへのアクセスに使用します。 FreeBSD は起動時に BIOS を使用するため、 これを正しく取得することは非常に重要なことなのです。 実際に、ディスク上に複数のオペレーティングシステムがある場合は、 ジオメトリはどこからでも同じように解釈される必要があります。 そうしないと、起動時に深刻な問題が発生します。 SCSI ディスクでは、 使用するジオメトリはコントローラの拡張 BIOS トランスレーション (>1GB の DOS ディスクドライブのサポート とも呼ばれます) が有効になっているかどうかによります。 無効になっている場合、N シリンダ、64 ヘッド、 32 セクタ/トラックを使用しますが、 ここで `N' は MB 単位のディスク容量です。 たとえば、2GB ディスクは見かけ上 2048 シリンダ、64 ヘッド、 32 セクタ/トラックとなります。 それが「有効」になっており (MS-DOS ではこの方法で、ある制限を回避する場合もあります)、 ディスク容量が 1GB を越える場合は、M シリンダ、 63 セクタ/トラック (64 「ではなく」)、 255 ヘッドを使用します。 `M' は MB 単位のディスク容量を 7.844238(!) で割った値となります。 ということで、2GB ディスクの例では、 261 シリンダ、63 セクタ/トラック、255 ヘッドとなります。 (訳注: 以上は Adaptec 社と NCR 社製の SCSI アダプタの場合です。 SCSI アダプタによって変換の数値が変わってくるのでマニュアルを 参照してください)。 これについてよく分からない場合や FreeBSD がインストール中に正しくジオメトリを取得できない場合、 これを回避するもっとも簡単な方法は、 ディスクに小さな DOS パーティションを作ることです。 そうすると正しいジオメトリが取得されるはずです (そして、 残しておきたくないとか、 ネットワークカードのプログラミング用に使いたい場合などには、 いつでもパーティションエディタで DOS パーティションを削除することができます)。 もう一つの方法として、FreeBSD - と一緒にに配布されているフリーで使えるユーティリティに + と一緒に配布されているフリーで使えるユーティリティに pfdisk.exe (FreeBSD CD-ROM の tools ディレクトリや、他のさまざまな FTP サイトにあります)と呼ばれるものがあり、 ディスク上の他のオペレーティングシステムが使用している ジオメトリを調べるのに役立ちます。 このジオメトリ情報は、 パーティションエディタに入力することができます。 ディスクの分割の仕方で何か制限はありますか? はい。 BIOS がカーネルを起動できるようにルートパーティションが 1024 シリンダ以内にあることを確認する必要があります (これは FreeBSD ではなく PC の BIOS の制限です)。 SCSI ドライブでは、通常はルートパーティションが最初の 1024MB に収まっていることが前提となります (または拡張 BIOS トランスレーションが有効になっている場合は最初の 4096MB - 他の質問をご覧ください)。IDE でそれに相当する値は 504MB となります (訳注: E-IDE 対応の BIOS 搭載マシンの場合は IDE の 504MB という制限はありません)。 大容量ディスクを持っていますが、ディスクマネージャは使えますか? FreeBSD は Ontrack Disk Manager を認識し、これを考慮にいれます。 他のディスクマネージャはサポートしません。 ディスク全体を FreeBSD で使いたい場合、 ディスクマネージャは必要ありません。 BIOS が扱える容量 (通常 504MB) いっぱいでディスクの設定を行なうと、 FreeBSD は実際の容量を算出するはずです。 MFM コントローラ付きの古いディスクを使っている場合は、 FreeBSD に使用するシリンダ数を詳細に指定する必要があります。 FreeBSD と他のオペレーティングシステムが入っているディスクを使用したい場合は、 ディスクマネージャなしでもできるでしょう。 FreeBSD の起動パーティションと他のオペレーティングシステム用のスライスが、 最初の 1024 シリンダ内に収まっている事を確認するだけです。 気になる方は、起動パーティションを 20 メガバイトぐらいにして大きめにするととよいでしょう。 FreeBSD の起動時に Missing Operating System と表示されます これは FreeBSD や DOS、 そのほかの OS がディスク領域ジオメトリ のとらえ方で衝突しあっていることから起こる典型的な例です。 こうなったら FreeBSD をインストールし直す以外にはありませんが、 他のところで説明した手順にしたがってやれば、 ほぼ間違いなくうまくいくはずです。 ブートマネージャの F? プロンプトが表示されません。 これはすでに前に質問されている問題のもう一つの症状です。 BIOS のジオメトリと FreeBSD のジオメトリ設定が一致していないのです! コントローラや BIOS がシリンダの変換 (>1GB ドライブの サポートとも呼ばれます) をサポートしていたら、 その設定を無効化して FreeBSD をインストールし直してみてください。 ソースを全部インストールする必要はありますか? 一般的には「いいえ」です。 しかし最低でも、base ソースキット (これにはこの FAQ で述べられているファイルのいくつかが含まれています) と、 sys (kernel) ソースキット (これにはカーネルのソースが含まれています) をインストールする事を強くおすすめします。 通常、何かの実行にソースが必要になる事はありません。 しかし、カーネルをコンフィグレーションするためのプログラム &man.config.8; を実行する時は例外です。 カーネルのソースをインストールしなくてもよい例として、 どこか別の場所からカーネルのソースを読み込み専用で NFS マウントすることができます。また、 そこから新しいバイナリを作成できるようにもなっています (カーネルソースの制限があるので、直接 /usr/src をマウントする事はおすすめできません。 それよりもどこか別のディレクトリにマウントして、 ソースツリーの複製ができるように適切にシンボリックリンクを張ってください)。 ソースをネットワーク上に持ち、 そこからシステムをビルドするようにしておけば、 FreeBSD の将来のリリースへのアップグレードがずっと簡単になります。 実際にソースのサブセットを選択するには、 システムインストールツールの「配布ファイル」メニューにある、 「カスタム」メニューを使用します。 カーネルは必ず作り直さなくちゃならないんですか? カーネルを新しく作り直すのは元々、 FreeBSD のインストール時に必須の作業でした。 でも最近のリリースでは、 とてもユーザフレンドリなカーネル設定ツールの恩恵を受けています。 FreeBSD の起動プロンプト (boot:) で とタイプすればビジュアルな設定画面になり、 ほとんどの一般的な ISA カードについてのカーネルの設定をすることができるのです。 今でも、 必要なデバイスドライバだけを組み込んだカーネルを作ることはよい事とされています。 ほんのちょっとだけメモリを節約できますからね。 でもほとんどのシステムでは、 もはやどうしてもやらなくちゃならないことではないのです。 DES と MD5、どちらのパスワードを使うべきなのでしょうか? また、ユーザがどちらを使うことになるか指定する方法はありますか? FreeBSD の標準のパスワードフォーマットは MD5 を使ったものです。 これは DES アルゴリズムに基づいた手法を用いる UNIX の伝統的なパスワードフォーマットより安全 (secure) だと 信じられているものです。 DES パスワードは あなたが FreeBSD のパスワードファイルを、 安全性に劣るパスワードフォーマットを利用している古い OS と共有しなければならなくなったときのために 利用可能になっています (これは利用するためには、 sysinstall から crypto 配布物のインストール 選ぶか、ソースから build しているなら、 crypto のソースがインストールされている必要があります)。 新しいパスワードにどちらのパスワードフォーマットを使うかは /etc/login.conf の中の passwd_format という login ケーパビリティで制御されます。このケーパビリティは des (利用できるなら) か md5 のどちらかの値を取ります。 login ケーパビリティの詳細については login.conf(5) を 参照してください。 ブートフロッピーで起動すると、 Probing Devices... の画面でハングアップします。 IDE Zip か Jaz ドライブが接続されていたら、 それを取り外してもう一度試してみましょう。 ブートフロッピーはこの種のドライブを誤認してしまうのです。 システムがインストールされた後は、そのドライブを再度接続することができます。 うまくいけばこの問題は将来のリリースで解決されるでしょう。 インストール終了後にシステムを再起動すると、 panic: cant mount root のエラーとなります。 このエラーはディスクデバイスについて、 起動ブロックとカーネルの認識が混乱しているために起こります。 このエラーは通常、 2 台の IDE ディスクがそれぞれ別の IDE コントローラのマスターに一つずつ接続されているシステムにおいて、 FreeBSD がセカンダリ IDE コントローラに接続されたディスクにインストールされている場合に発生します。 起動ブロックは FreeBSD が wd1 (2 台目の BIOS ディスク) にインストール されていると認識するのに対し、 カーネルはセカンダリ IDE の 1 台目のハードディスクである wd2 にインストールされていると認識するのです。 デバイス検出後で、 カーネルは起動ブロックが起動ディスクだと認識したディスクである wd1 をマウントしようとします。 しかし、実際には起動ディスクは wd2 なので失敗してしまうのです。 この問題を解決するには、以下のどれか一つを行ってください。 FreeBSD 3.3 以降を利用している場合には、 システムを再起動して、Booting kernel in 10 seconds; hit [Enter] to interrupt が表示されている間に Enter キーを押します。 すると、ブートローダに移行します。 そうしたら、set root_disk_unit="disk_number" と入力します。 FreeBSD が最初の IDE コントローラのマスターに接続されたドライブにインストールされていれば、 disk_number は 0 です。 また、 最初の IDE コントローラのスレーブなら 1、 二番目の IDE コントローラのマスターなら 2、 二番目の IDE コントローラのスレーブなら 3 になります。 その後、boot と入力します。 システムはきちんと再起動するはずです。 この変更を恒久的なものにする (つまり、 再起動や電源を入れる度にこの操作する必要がないようにする) には、 /boot/loader.conf.local に root_disk_unit="disk_number" という行を追加してください。 FreeBSD 3.2 以前を利用している場合は、 Boot: プロンプトで 1:wd(2,a)kernel と入力してエンターキーを押します。 システムが起動したら、 echo "1:wd(2,a)kernel" > /boot.config というコマンドを実行してこれをデフォルトのブート文字列とします。 FreeBSD のディスクをプライマリ IDE コントローラに接続して、 ハードディスクが連続したドライブ番号で認識されるようにします。 カーネルのコンフィグレーションファイルで wd の行を以下のように変更し、 カーネルの再構築を行って、 新しいカーネルをインストールします。 controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr disk wd0 at wdc0 drive 0 # disk wd1 at wdc0 drive 1 # この行をコメントアウト controller wdc1 at isa? port "IO_WD2" bio irq 15 vector wdintr disk wd1 at wdc1 drive 0 # wd2 から wd1 へ変更 disk wd2 at wdc1 drive 1 # wd3 から wd2 へ変更 ディスクの接続を変更して元の設定に戻したい場合は、ディスクを お望みの設定の通りの接続に戻してから再起動します。 システムは正常に起動するはずです。 メモリの大きさの制限は? 認識できるメモリの上限は、4GB です。 この構成は試験済みで、 詳細は wcarchive's configuration をご覧ください。 このようにたくさんのメモリをマシンに導入しようという場合には、 注意が必要です。ECC 機能をサポートし、なおかつ 容量性負荷 (訳注: 多くのメモリ素子は容量性負荷として働きますが、 メモリバス上に容量性負荷が増えると信号の伝達が遅れ、誤動作の原因となります) を 低減させるため、18 チップ構成のメモリモジュールより 9 チップ構成のメモリモジュールを選択することが、おそらく望ましいでしょう。 ffs ファイルシステムの大きさの制限は? ffs ファイルシステムの場合、 論理的な最大の上限は 8 TB (2G ブロック)、 デフォルトのブロックサイズを 8K とすると 16 TBとなります。 実際問題として、1 TB のソフトウェアの限界がありますが、 修正すれば 4 TB のファイルシステムが可能です (実際に存在します)。 一つの ffs のファイルの最大のサイズは、ブロックサイズが 4K の場合で 約 1G ブロック (4 TB)です。 最大ファイルサイズ fs ブロックサイズ 2.2.7-stable 3.0-current 動作確認済みのサイズ 動作するはずのサイズ 4K 4T-1 4T-1 4T-1 4+t 8K 32+G 8T-1 32+G 32T-1 16K 128+G 16T-1 128+G 32T-1 32K 512+G 32T-1 512+G 64T-1 64K 2048+G 64T-1 2048+G 128T-1
fs ブロックサイズが 4K の場合は三重間接ブロックが使用され、 いずれの場合でも三重間接ブロックを使用して表現できる最大の fs ブロック番号 (およそ 1K^3 + 1K^2 + 1K) に制限されるはずなのですが、 実際は fs ブロック番号の (間違った) 上限 1G-1 で制限されます。 fs ブロック番号の制限は 2G-1 となるはずです。2G-1 付近に fs ブロック番号のバグが多少ありますが、fs ブロックサイズが 4K の場合は、ここまでのブロック番号には到達しません。 ブロックサイズが 8K 以上の場合、いずれの場合も fs ブロック番号の上限 2G-1 で制限されるはずですが、 実際は fs ブロック番号の上限 1G-1 で制限されます。 例外的に -STABLE では三重間接ブロックまでは到達しないため、 制限は二重間接ブロックで表現できる最大の fs ブロック番号 (およそ (blocksize/4)^2 + (blocksize/4)) となります。 -CURRENT ではこの制限を超えると問題を引き起こすかもしれません。 正しい制限値である 2G-1 ブロックを使用すると明らかに問題が出ます。 フロッピーに 1 TB のファイルを格納するには? 寄稿: Bruce Evans、1998 年 9 月 わたしのところでは、 フロッピーにいくつかの実際のファイルを保存しています :-)。 最大のファイルサイズは最大のディスクサイズとはあまり関係はありません。 最大のディスクサイズは 1 TB です。 ファイルサイズがディスクサイズより大きくなりうるというのは仕様です。 以下の例は、32K のディスク容量 (3 つの間接ブロックと 1 つのデータブロック) を使って、 小さなルートパーティションに 8T-1 の大きさのファイルを作成します。 ここでの dd コマンドは大きなファイルが扱えるものが必要です。 &prompt.user; cat foo df . dd if=/dev/zero of=z bs=1 seek=`echo 2^43 - 2 | bc` count=1 ls -l z du z df . &prompt.user; sh foo Filesystem 1024-blocks Used Avail Capacity Mounted on /dev/da0a 64479 27702 31619 47% / 1+0 records in 1+0 records out 1 bytes transferred in 0.000187 secs (5346 bytes/sec) -rw-r--r-- 1 bde bin 8796093022207 Sep 7 16:04 z 32 z Filesystem 1024-blocks Used Avail Capacity Mounted on /dev/da0a 64479 27734 31587 47% / 新しいカーネルをコンパイルしたら、起動時に archsw.readin.failed というエラーメッセージが表示されるようになってしまいました。 ローダがスタートする前の | が表示されているときに何かキーを押すことで、 起動のセカンドステージから直接、起動するカーネルを指定して起動することができます。 特に、カーネルのソースを更新し、make world しないで新しいカーネルだけインストールした場合にこの症状が現われます。 こういう操作は動作が保証されません。きちんと make world してください。 3.X から 4.X にアップグレードするにはどうしたら良いのですか? アップグレードには、 バイナリスナップショットを使うことを強くおすすめします。 4-STABLE スナップショットは releng4.FreeBSD.org から入手可能です。 ソースを使ってアップグレードする場合は、詳細について FreeBSD ハンドブックを参照するようにしてください。 ソースを使ったアップグレードは、 慣れていないユーザにはまったくおすすめできません。 3.X -> 4.X の場合は特にそうです。 ソースを使ったアップグレードを試す前に、 手順を注意深く読むように心がけてください。 セキュリティプロファイル (security profiles) とは何ですか? セキュリティプロファイルとは、特定の プログラムやその他の設定を有効にしたり無効にすることで、求める 比率で安全と便利さを実現しようとする構成の選択肢の集まりの ことです。セキュリティプロファイルが厳しいほど、デフォルトで 有効になるプログラムが減ります。これは、動かさなければならない もの以外は、何も動かしてはいけないというセキュリティの 基本的原則の一つです。 セキュリティプロファイルは、単にデフォルトの設定である ということに気をつけてください。FreeBSD をインストールした あとに /etc/rc.conf に適切な行を編集したり 追加すれば、どのプログラムでも有効にしたり無効にしたりできます。 後者について詳しいことは &man.rc.conf.5; のマニュアルを ご覧ください。 以下に、各セキュリティプロファイルが何を行うかを説明した 表を掲載します。列はセキュリティプロファイルの選択肢で、行は 有効または無効になるプログラムや機能です。 指定できるセキュリティプロファイル Extreme High Moderate Low &man.inetd.8; NO NO YES YES &man.sendmail.8; NO YES YES YES &man.sshd.8; NO YES YES YES &man.portmap.8; NO NO おそらく インストール時に、すでにマシンを NFS クライアントまたはサーバとして設定していると、 ポートマッパが有効になります。 YES NFS server NO NO YES YES &man.securelevel.8; YES (2) securelevel を設定するセキュリティプロファイル (Extreme または High) を選択する場合、その影響を 承知していなければなりません。&man.init.8; のマニュアルを 読み、セキュリティレベルの意味について特に注意を 払ってください。そうしないと、後で深刻な問題が 起きるかもしれません。 YES (1) NO NO
セキュリティプロファイルは魔法の薬ではありません。 High に設定したら、適当な メーリングリストを読んだり、良質なパスワードや パスフレーズを用いたり、セキュリティについてのよい習慣を 守ったりしなくていいわけではありません。求めるセキュリティと 便利さの比率を手軽に設定してくれるだけです。 セキュリティプロファイルの機構は、FreeBSD を最初に インストールする時に使うことを想定しています。すでに FreeBSD がインストールされているなら、単に求める機能を 有効にしたり無効にしたりする方が、おそらく効率が よいでしょう。もし、本当にセキュリティプロファイルを 使いたいのであれば、&man.sysinstall.8; を再実行すれば 設定できます。 ハードウェアコンパチビリティ 訳: にしか nishika@cheerful.com、 1997 年 11 月 12 日 FreeBSD は、 どんなハードディスクドライブをサポートしているのですか? FreeBSD は、EIDE と SCSI ハードディスクドライブをサポートしています (互換コントローラも含みます。 次の節参照)。 また独自の Western Digital インタフェースを使用しているすべてのドライブ (MFM、 RLL、ESDI、もちろん IDE) もサポートしています。 独自仕様のインタフェースを使用する ESDI コントローラでは動作しないものがあり、 WD1002/3/6/7 とその互換インタフェースと衝突します。 どの SCSI コントローラをサポートしているのですか? FreeBSD ハンドブックに記されている完全なリストを参照してください。 どんな CD-ROM ドライブをサポートしているのですか? サポートされている SCSI コントローラに接続できる SCSI ドライブは、すべてサポートされています。 また、以下の専用 CD-ROM インタフェースもサポートしています。 ミツミ LU002 (8bit)、LU005 (16bit) および FX001D (16bit 2倍速)。 ソニー CDU 31/33A Sound Blaster 非 SCSI タイプの CD-ROM 松下/Panasonic CD-ROM ATAPI 互換の IDE CD-ROM SCSI でないカードはすべて、SCSI ドライブよりも極めて動作速度が 遅いことが知られており、ATAPI CD-ROM には動作しないものもあるようです。 BSDi の FreeBSD 2.2 CD-ROM からは CD からの直接起動が サポートされています。 FreeBSD は、どの CD-RW ドライブに対応していますか? FreeBSD は ATAPI 互換の IDE CD-R または CD-RW ドライブで あれば対応しています。FreeBSD バージョン 4.0 以降については、 &man.burncd.8; のマニュアルをご覧ください。それ以前の バージョンの FreeBSD では、 /usr/share/examples/atapi にある例を ご覧ください。 また、FreeBSD は SCSI の CD-R または CD-RW ドライブにも 対応しています。ports または packages から cdrecord コマンドをインストールして、 カーネルに pass デバイスが組み込まれて いることを確認してください。 ZIP ドライブをサポートしていますか? もちろん、 FreeBSD は SCSI ZIP ドライブ (外付け) をサポートしています。 ZIP ドライブは SCSI ID を 5 か 6 に設定した状態でなら使用できますが、 もし SCSI ホストアダプタの BIOS がサポートしてさえいれば ZIP ドライブから起動させることもできます。 どのホストアダプタが SCSI ID を 0 や 1 以外に設定したデバイスから 起動できるのかはわかりません。そうしたい場合は、アダプタの ドキュメントを参照しなければなりません。 ATAPI (IDE) ZIP ドライブは、FreeBSD 2.2.6 以降のバージョンでサポートされています。 バージョン 3.0 以降の FreeBSD では、 パラレルポート接続の ZIP ドライブをサポートしています。 最近のバージョンの FreeBSD をお使いでしたら、 カーネルコンフィグレーションファイルに scbus0、 da0、 ppbus0、 vp0 の各ドライバが記述されていることを確認してください。 (GENERIC カーネルには vp0 を除くすべてのドライバが含まれています)。 これらすべてのドライバがあれば、 パラレルポートのドライブは /dev/da0s4 となります。 ディスクは mount /dev/da0s4 /mnt とするか mount_msdos /dev/da0s4 /mnt (DOS ディスクの場合) とすることでマウントできます。 それからリムーバブルドライブに関する注意および、 「フォーマット」に関する注意についても 確認しておいてください。 では、JAZ や EZ、 それからその他のリムーバブルドライブはサポートしていますか? FreeBSD では、IDE バージョンの EZ ドライブを除くすべての SCSI デバイスは、 SCSI のディスクと同等に扱われます。 また IDE EZ は IDE ドライブと同等となります。 システム稼働中のメディア交換について FreeBSD がどれほどうまく動くか定かではありません。 もちろんメディアを入れ替える前にそのドライブのマウントを解除しなければいけないでしょうし、 FreeBSD がそれらを認識するには、 起動時に外部ユニットにも電源が投入されていることを確認しなければいけないでしょう。 「フォーマット」に関する注意も参照のこと。 どのマルチポートシリアルカードをサポートしていますか? 一覧は その他のデバイスの節にあります。 無名のカードにもうまく動くものがあり、 特に AST 互換といわれているものに多く見られます。 カード設定の詳細な情報は、&man.sio.4; のマニュアルページを参照してください。 USB キーボードを持っているのですが、FreeBSD で使えますか? USB デバイスは FreeBSD 3.1 からサポートされましたが、 実装は FreeBSD 3.2 であってもまだ完全ではないため、 必ずしも安定して動作するとは限りません。 もし、それでも USB キーボードを使ってみたいという人は、 以下の手順を試してみてください。 FreeBSD 3.2 か、それ以降を使います。 カーネルコンフィグレーションファイルに以下の行を追加し、 カーネルを再構築します。 device uhci device ohci device usb device ukbd options KBD_INSTALL_CDEV FreeBSD 4.0 より前のバージョンでは、 代わりに次のようにします。 controller uhci0 controller ohci0 controller usb0 controller ukbd0 options KBD_INSTALL_CDEV /dev ディレクトリに移動し、 次のようにしてデバイスノードを作成します。 &prompt.root; cd /dev &prompt.root; ./MAKEDEV kbd0 kbd1 /etc/rc.conf を編集し、 以下の行を追加します。 usbd_enable="YES" usbd_flags="" システムを再起動させた後、 AT、USB 両方のキーボードが接続されていれば、 AT キーボードは /dev/kbd0 に、 USB キーボードは /dev/kbd1になります。 一方、USB キーボードだけが接続されているなら、 /dev/ukbd0 となります。 USB キーボードをコンソールで利用するには、 それをコンソールドライバに対して明示的に指定する必要があります。 システムの初期化の際に、次に示すようなコマンドを実行してください。 &prompt.root; kbdcontrol -k /dev/kbd1 < /dev/ttyv0 > /dev/null ただし、USB キーボードしか接続されていない場合、それは /dev/kbd0 としてアクセスされますので、 コマンドは次のようにしなければなりません。ご注意ください。 &prompt.root; kbdcontrol -k /dev/kbd0 < /dev/ttyv0 > /dev/null 上のコマンドは、/etc/rc.i386 に追加すると良いでしょう。 この設定を一度行なっていれば、 X 環境でも特に他の設定なしに USB キーボードが利用できます。 USB キーボードの活線挿抜 (ホットプラグ機能) は、 まだおそらくきちんと動作しないと思われます。 トラブルを避けるためにも、キーボードはシステムを起動させる前に接続しておき、 シャットダウンするまではずさないようにした方が良いでしょう。 詳細については、&man.ukbd.4; のマニュアルページを参照してください。 珍しいバスマウスを持っているのですが、どのように設定すればいいのですか? FreeBSD は Microsoft、Logitech、 ATI 等のメーカーから出ているバスマウスと InPort バスマウスをサポートしています。FreeBSD 2.X の場合、 バスマウスのデバイスドライバは GENERIC カーネルに標準で含まれますが、 FreeBSD 3.X 以降では標準で含まれていません。もしバスマウスのデバイス ドライバを含むカーネルを自分で構築する場合には、 カーネルコンフィグレーションファイルに以下の行が含まれていることを確認してください。 それは FreeBSD 3.0 を含む、それ以前のリリースの場合は次のとおり、 device mse0 at isa? port 0x23c tty irq5 vector mseintr FreeBSD 3.X では、次のとおりです。 device mse0 at isa? port 0x23c tty irq5 そして FreeBSD 4.X とそれ以降では、次のようになります。 device mse0 at isa? port 0x23c irq5 通常バスマウスには専用のインタフェースカードが附属しています。 インタフェースカードによってはポートアドレスや割り込み番号を上記の 設定以外に変更できるかもしれません。詳しくはバスマウスのマニュアルと &man.mse.4; のマニュアルページを参照してください。 PS/2 マウス (「マウスポートマウス」、「キーボードマウス」) を 使うにはどのように設定すればいいのですか? あなたが 2.2.5 以降のバージョン FreeBSD を使っているのなら、 必要なドライバ psm はカーネルに含まれていて有効になっています。 カーネルは起動時に PS/2 マウスを検出するでしょう。 あなたの使っている FreeBSD が比較的新しいけれど前のバージョン (2.1.x 以降) のものなら、 インストールの時に、単にカーネルのコンフィグレーションのメニュー上で PS/2 マウスを有効化するだけです、あるいは後で boot: プロンプト上で を指定することでもメニューは現れます。 デフォルトでは無効に設定されていますので、 明示的に有効化してあげないといけません。 あなたの使っている FreeBSD が比較的古いものなら、 カーネルコンフィグレーションファイルに以下の行を加えて カーネルを再コンパイルする必要があります。 それは FreeBSD 3.0 を含む、それ以前のリリースでは次のとおり、 device psm0 at isa? port "IO_KBD" conflicts tty irq 12 vector psmintr FreeBSD 3.1 を含む、それ以降のリリースでは次のとおり、 device psm0 at isa? tty irq 12 FreeBSD 4.0 とそれ以降のリリースでは次のとおりです。 device psm0 at atkbdc? irq 12 カーネルの再構築についてよく知らないのであれば、 カーネルのコンフィグレーションを参照してください。 起動時にカーネルが psm0 を検出したら、 psm0 のエントリが /dev の中にあることを確認してください。それには、以下のようにします。 &prompt.root; cd /dev; sh MAKEDEV psm0 これは root でログインしているときに行なってください。 X Window System 以外の環境でマウスを使うことは可能ですか? もしデフォルトのコンソールドライバである syscons を使っているのであれば、 テキストコンソール上でマウスを使って、 テキストのカットアンドペーストができます。 マウスデーモンである moused を起動し、 仮想コンソールでマウスポインタを有効にしてください。 &prompt.root; moused -p /dev/xxxx -t yyyy &prompt.root; vidcontrol -m on ここで xxxx はマウスのデバイス名、 yyyy はマウスのプロトコルタイプです。 サポートされているプロトコルタイプについては &man.moused.8; のマニュアルページを参照してください。 システムを起動する時に自動的に moused を起動したい場合には、次のようにします。 FreeBSD 2.2.1 では以下の変数を /etc/sysconfig で設定してください。 mousedtype="yyyy" mousedport="xxxx" mousedflags="" FreeBSD 2.2.2 以降のバージョンでは /etc/rc.conf で以下のように設定します。 moused_type="yyyy" moused_port="xxxx" moused_flags="" FreeBSD 3.1 とそれ以降で PS/2 マウスを利用する場合は、 moused_enable="YES" を /etc/rc.conf に書き加えるだけです。 また、起動時にすべての仮想端末で、 標準のコンソールに加えマウスデーモンも使えるようにしたい、 という場合には、以下の行を /etc/rc.conf に加えます。 allscreens_flags="-m on" FreeBSD 2.2.6 以降の場合で 比較的新しいシリアルマウスを使っているならば、 マウスデーモンはマウスのプロトコルタイプを自動判別できます。 自動判別を試みるには、プロトコルタイプとして auto を指定します。 マウスデーモンを実行中は、マウスデーモンと他のプログラム (たとえば X Window System) の間でマウスへのアクセスを調整しなければなりません。 この問題については X とマウスをご覧ください。 マウスを使って、 テキストコンソールでカットアンドペーストするにはどうしたらよいのですか? マウスデーモンを起動 (前の質問に対する答えを参照してください) したあと、 ボタン 1 (左ボタン) を押しながらマウスを動かして範囲を指定します。 ボタン 2 (中ボタン) またはボタン 3 (右ボタン) をクリックするとテキスト カーソルの位置に選択した範囲のテキストがペーストされます。 FreeBSD 2.2.6 以降では、ボタン 2 をクリックするとペーストされ、ボタン 3 をクリックした場合に既存の選択範囲が現在のマウスポインタの位置まで 「延長または短縮」されます。もしマウスに中ボタンがないなら、 moused のオプションを使って中ボタンのエミュレーションをするか、 他のボタンを中ボタンとして使う事ができます。 詳しくは &man.moused.8; のマニュアルページを参照してください。 USB マウスを持っているのですが、FreeBSD で使えますか? USB デバイスは FreeBSD 3.1 からサポートされましたが、 実装は FreeBSD 3.2 であってもまだ完全ではないため、 必ずしも安定して動作するとは限りません。 もし、それでも USB マウスを使ってみたいという人は、 以下の手順を試してみてください。 FreeBSD 3.2 か、それ以降を使います。 カーネルコンフィグレーションファイルに以下の行を追加し、 カーネルを再構築します。 device uhci device ohci device usb device ums FreeBSD 4.0 より前のバージョンでは、 代わりに次のようにします。 controller uhci0 controller ohci0 controller usb0 device ums0 /dev ディレクトリに移動し、 次のようにしてデバイスノードを作成します。 &prompt.root; cd /dev &prompt.root; ./MAKEDEV ums0 /etc/rc.conf を編集し、 以下の行を追加します。 moused_enable="YES" moused_type="auto" moused_port="/dev/ums0" moused_flags="" usbd_enable="YES" usbd_flags="" moused の設定の詳細については、 前項も参照してください。 X のセッションで USB マウスを使うには、 XF86Config を編集する必要があります。 XFree86 3.3.2、もしくはそれ以降を利用している場合は、 Pointer セクションが次のようになっていることを確認してください。 Device "/dev/sysmouse" Protocol "Auto" それより前のバージョンの XFree86 を利用している場合は、 Pointer セクションが次のようになっていることを確認してください。 Device "/dev/sysmouse" Protocol "SysMouse" X 環境でのマウスの利用については、 他の項も参照してください。 USB マウスの活線挿抜 (ホットプラグ機能) は、 まだおそらくきちんと動作しないと思われます。 トラブルを避けるためにも、マウスはシステムを起動させる前に接続しておき、 シャットダウンするまではずさないようにした方が良いでしょう。 わたしのマウスにはホイール機能や便利なボタンがついているのですが、 これは FreeBSD でも使えるのですか? 答えは残念ながら「場合によります」です。 こうしたマウスの付加的な機能は大抵の場合、特殊なドライバを必要とします。 マウスのデバイスドライバやユーザのプログラムが そのマウスに対する固有のサポートをしていない場合には、 標準的な 2 ボタン/3 ボタンマウスのように振舞います。 X ウィンドウシステムの環境でのホイールの使い方については、 X とホイールの項をご覧ください。 わたしのマウスはきちんと動いてくれないようです。 マウスカーソルが画面中をとびまわります。 このマウスにはホイールがついていて、 接続は PS/2 ポートです。 FreeBSD 3.2 およびそれ以前の PS/2 マウスドライバ psm には、 Logitech モデル M-S48 とその OEM のホイールマウスで不具合が発生します。 以下のパッチを /sys/i386/isa/psm.c に適用して、カーネルを再構築してください。 Index: psm.c =================================================================== RCS file: /src/CVS/src/sys/i386/isa/Attic/psm.c,v retrieving revision 1.60.2.1 retrieving revision 1.60.2.2 diff -u -r1.60.2.1 -r1.60.2.2 --- psm.c 1999/06/03 12:41:13 1.60.2.1 +++ psm.c 1999/07/12 13:40:52 1.60.2.2 @@ -959,14 +959,28 @@ sc->mode.packetsize = vendortype[i].packetsize; /* set mouse parameters */ +#if 0 + /* + * A version of Logitech FirstMouse+ won't report wheel movement, + * if SET_DEFAULTS is sent... Don't use this command. + * This fix was found by Takashi Nishida. + */ i = send_aux_command(sc->kbdc, PSMC_SET_DEFAULTS); if (verbose >= 2) printf("psm%d: SET_DEFAULTS return code:%04x\n", unit, i); +#endif if (sc->config & PSM_CONFIG_RESOLUTION) { sc->mode.resolution = set_mouse_resolution(sc->kbdc, - (sc->config & PSM_CONFIG_RESOLUTION) - 1); + (sc->config & PSM_CONFIG_RESOLUTION) - 1); + } else if (sc->mode.resolution >= 0) { + sc->mode.resolution + = set_mouse_resolution(sc->kbdc, sc->dflt_mode.resolution); + } + if (sc->mode.rate > 0) { + sc->mode.rate = set_mouse_sampling_rate(sc->kbdc, sc->dflt_mode.rate); } + set_mouse_scaling(sc->kbdc, 1); /* request a data packet and extract sync. bits */ if (get_mouse_status(sc->kbdc, stat, 1, 3) < 3) { FreeBSD 3.2 より新しいリリースではきちんと動作するはずです。 ラップトップ PC のマウス/トラックボール/タッチパッドは使えますか? 前の質問に対する答えと、 モバイルコンピューティングのページをご覧ください。 どんなテープドライブをサポートしていますか? FreeBSD は SCSI と QIC-36 (QIC-02 インタフェース付き) をサポートしています。 これらには 8-mm (Exabyte と呼ばれています) や DAT ドライブも含まれています。 初期の 8-mm ドライブの中には SCSI-2 とまったく互換性を持たないものがあります。 これらは FreeBSD 上では動作しません。 どんなテープチェンジャーをサポートしていますか? FreeBSD 2.2 は &man.ch.4; デバイスと &man.chio.1; コマンドを使用した SCSI チェンジャーをサポートしています。 実際のチェンジャーの制御方法の詳細は、&man.chio.1; のマニュアルページを参照してください。 使用している製品が AMANDA のようにチェンジャーに対応済みのものでない場合は、 次のことについて留意してください。 それらの製品は任意のポイント間のテープの移動を制御するだけなので、 テープがどのスロットに入っているか、現在ドライブにあるテープが どのスロットに戻るべきかを把握しておく必要があります。 どんなサウンドカードをサポートしていますか? FreeBSD は SoundBlaster、SoundBlaster Pro、SoundBlaster 16、 Pro Audio Spectrum 16、AdLib それから Gravis UltraSound サウンドカードを サポートしています。MPU-401 やその互換カードも機能に制限はあるものの サポートされています。マイクロソフトサウンドシステムのスペックに準拠 したカードも、pcm ドライバでサポートされています。 これらはサウンドについてのみの話です! これらのドライバは CD-ROM、SCSI、カード上にあるジョイスティックをサポートしていません (SoundBlaster は例外です)。SoundBlaster SCSI インタフェースと非 SCSI CD-ROM はサポートしていますが、そのデバイスからは起動できません。 pcm ドライバで es1370 から音が出ないのはどうにかなりませんか? マシンを起動するごとに以下のコマンドを実行してください。 &prompt.root; mixer pcm 100 vol 100 cd 100 どんなネットワークカードをサポートしていますか? より完全な一覧についてはイーサネットカードの節を参照してください。 数値演算コプロセッサを持っていませんが、何かまずいでしょうか? これらは 386/486SX/486SLC を持っている場合に影響します - ほかのマシンでは CPU に内蔵されています。 一般にこれらは問題とはなりません。 しかし、数値演算エミュレーションコードのパフォーマンスか、 正確さのいずれかを選択する状況があります (詳しくは FP エミュレーション についての節をご覧ください)。 とくに、X 上で弧を描く際にとても遅くなることでしょう。 数値演算コプロセッサを購入されることを強くおすすめします。 とても役立つことでしょう。 他の数値演算コプロセッサよりも優れたコプロセッサもあります。 これは言いにくいことなのですが、Intel を買うために躍起になる人もいないでしょう。 それが FreeBSD 上で動くという確信がないのなら、クローンにご用心を。 FreeBSD がサポートするデバイスは他にもあるんでしょうか? FreeBSD ハンドブックに記されている、 サポートされている他のデバイスの一覧を参照してください。 パワーマネージメント機能付きのラップトップ PC を持っているのですが…。 FreeBSD は一部のマシンの APM をサポートしています。 LINT カーネルコンフィグファイル の APM の部分をご覧ください。 さらに詳しいことは &man.apm.4; に載っています。 Micron システムが起動時に固まってしまいます。 特定の Micron 製のマザーボードの中には、PCI BIOS が規格通りに 実装されていないために FreeBSD の起動に失敗するものがあります。 その BIOS は、PCI デバイスをあるアドレスで設定したと報告するにも 関わらず、実際にはそうしていないのです。 この問題を回避するには、BIOS の Plug and Play Operating System を無効に設定してください。また、より詳しい情報は http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html#micron を参照してください。 新しい Adaptec コントローラを持っているのですが、 FreeBSD が検出できないようです。 新しい AIC789x シリーズの Adaptec チップは、3.0 でデビューした CAM SCSI フレームワークでサポートされています。 2.2-STABLE のパッチは ftp://ftp.FreeBSD.org/pub/FreeBSD/development/cam/ にあります。 CAM システムが入っている高機能ブートフロッピーは http://people.FreeBSD.org/~abial/cam-boot/ にあります。 どちらの場合にしても、作業を始める前に README をお読みください。 内蔵の Plug & Play モデムを持っているのですが、FreeBSD が検出できないようです。 モデムの PnP ID を シリアルドライバの PnP ID リストに追加する必要があるでしょう。 Plug & Play サポートを有効にするには、 controller pnp0 をコンフィグレーション ファイルに付け加え、 新しいカーネルをコンパイルしてシステムを再起動してください。 カーネルは、検出したすべてのデバイスの PnP ID を表示します。 モデムの欄にある PnP ID を /sys/i386/isa/sio.c の 2777 行目くらいにあるテーブルに書き入れてください。 テーブルを見つけるには、構造体 siopnp_ids[] の文字列 SUP1310 を探します。 カーネルを作り直したらインストールし、システムを再起動してください。 そうすれば、モデムが検出されるはずです。 起動時のコンフィグレーションの際に、pnp コマンドを使用して PnP の設定をマニュアルで行なわなければならないかもしれません。 その場合、モデムを検出させるためのコマンドは pnp 1 0 enable os irq0 3 drq0 0 port0 0x2f8 のようになります。 シリアルコンソールで boot: プロンプトを表示するにはどうすればいい? options COMCONSOLE を指定してカーネルを構築してください。 そして /boot.config を作成して とだけ書き入れてください。 その後、キーボードをシステムから抜きます。 /usr/src/sys/i386/boot/biosboot/README.serial に、 これに関する情報が書かれています。 なぜ Micron コンピュータで 3Com PCI ネットワークカードが動かないのでしょう? 特定の Micron 製のマザーボードの中には、PCI BIOS が規格通りに 実装されていないために FreeBSD の起動に失敗するものがあります。 その BIOS は、PCI デバイスをあるアドレスで設定したと報告するにも 関わらず、実際にはそうしていないのです。 この問題を回避するには、BIOS の Plug and Play Operating System を無効に設定してください。また、より詳しい情報は http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html#micron を参照してください。 対称型マルチプロセシング (SMP) をサポートしていますか? SMP は、3.0-STABLE とそれ以降のリリースでのみサポートされています。 GENERIC カーネルでは SMP は有効化されていませんので、 SMP を有効化するにはカーネルを再構築する必要があります。 /sys/i386/conf/LINT を見て、 カーネルコンフィグファイルにどのオプションを追加すれば良いのか確かめてください。 ASUS K7V マザーボードのシステムでブートフロッピーを使うと、 システムがハングアップします。 対応策はありませんか? BIOS セットアップで起動時のウィルス保護機能を無効化してください。 トラブルシューティング 訳: &a.jp.yoshiaki;、 1997 年 11 月 10 日 ハードディスクに不良ブロックがあります! SCSI ディスクの場合は自動的に再マップする機能があるはずです。 しかし、理解し難い理由から多くのドライブがこの機能が無効化 されて出荷されています…。 これを有効化するには、 最初のデバイスのモードページを変更する必要があります。 これは次のコマンドを実行することで、FreeBSD 上で行なうことができます (root 権限で行ないます)。 &prompt.root; scsi -f /dev/rsd0c -m 1 -e -P 3 そして、AWRE と ARRE の値を 0 から 1 へ変更します AWRE (Auto Write Reallocation Enbld): 1 ARRE (Auto Read Reallocation Enbld): 1 以下は、Ted Mittelstaedt 氏から寄せられたものです。 IDE ドライブの場合は通常、不良ブロックは潜在的な障害の兆候です。 最近の IDE ドライブは、内部の不良ブロック再マッピング機能を有効にした状態で 出荷されています。また、今日の IDE ハードディスクメーカは、 出荷以降に不良ブロックが発生することに関して保証を提供していて、 不良ブロックのあるディスクドライブを交換するサービスを行なっています。 もし、不良ブロックのある IDE ディスクドライブを復旧しようと思うなら、 IDE ドライブメーカが提供する IDE 診断プログラムをダウンロードして、 そのドライブに使ってみてください。この種のプログラムは大抵、 ドライブの制御部分に対して不良ブロックを再走査し、 不良ブロックを使用不能にするようにセットすることができます。 ESDI、RLL および MFM ドライブの場合、 不良ブロックはドライブの正常な部分であり、 一般的に言って障害を表すものではありません。 PC では、ディスクドライブコントローラカードと BIOS が不良ブロックの使用不能化の作業を行ないます。 DOS など、ディスクアクセスに BIOS を経由する OS にとっては有効に働きますが、FreeBSD のディスクドライバは BIOS を利用しません。そのため、 代替として bad144 という機構が存在します。 bad144 は、wd ドライバでだけ (つまり FreeBSD 4.0 ではサポートされていない)動作し、SCSI ドライバに利用することは できません。bad144 は、 検出された不良セクタをスペシャルファイルに記録するという機能を持っています。 bad144 を利用する上で、注意しなければならない点が一つあります。 それは、不良ブロックスペシャルファイルは、 ディスクの最終トラックに置かれるということです。 このファイルには、ディスクの先頭の付近、 /kernel ファイルが位置しているであろう部分で発生した不良セクタが記録されています。 したがって、このファイルは BIOS コールを使ってカーネルファイルを読み込む起動プログラムが、 アクセス可能でなければなりません。 これはつまり、bad144 を利用するディスクは 1024 シリンダ、16 ヘッド、63 セクタを超えてはならないということを意味し、 bad144 を利用したディスクが実質 500MB を超えられないことになります。 bad144 を使うには、FreeBSD のインストール時に表示される fdisk 画面で Bad Block 走査を ON に設定するだけです。 これは、FreeBSD 2.2.7 以降で機能します。 ディスクは、1024 シリンダ以内でなければなりません。 ディスクドライブは事前に少なくとも 4 時間、 ディスクが温度によって膨張し、 トラックに曲がりが出るまで回転させることをお薦めします (訳注: 温度変化に対する膨張によって、 ディスクが微小変形することにより発生する不良セクタを確実に検出するためです)。 大容量の ESDI ドライブのように 1024 シリンダを超えるディスクの場合、 DOS 上でそのディスクが利用できるよう、 ESDI コントローラは特殊な変換モードを利用します。 fdisk の set geometry コマンドを使って 変換された (translated) ジオメトリに切替えると、wd ドライバはこの変換モードを解釈できます。 その際、FreeBSD パーティションを作成するのに dangerously dedicated モードを利用してはいけません。 このモードは、そのようなジオメトリを無視するからです。 たとえ fdisk がオーバーライドされたジオメトリ情報を使ったとしても、 依然としてディスクの真の大きさを保持しているため、大きすぎる FreeBSD パーティションを作成しようとしてしまうでしょう。 ディスクジオメトリ情報が変換されたジオメトリ情報にかわっている場合は、 手動でブロック数を入力し、 パーティションを作成する必要があります。 大容量の ESDI ディスクを ESDI コントローラでセットアップするには、 ちょっとしたトリックを使います。まず、DOS のディスクで起動して そのディスクを DOS パーティションとしてフォーマットします。 そして FreeBSD を起動し、インストーラの fdisk 画面で DOS パーティションのブロックサイズとブロック数を読みとり、メモしておきます。 ジオメトリ情報を DOS が利用しているものと同一に再設定し、 DOS パーティションを削除して cooperative FreeBSD パーティションを 先程記録したブロックサイズを使って作成してください。 そのパーティションを起動可能パーティションに設定し、不良ブロック走査を 有効にします。 実際のインストールでは、ファイルシステムが作成される前に bad144 が最初に実行されます (Alt-F2 を押すことで状況を確認できます)。 不良セクタファイルを作成中に何らかの障害が発生したなら、 システムを再起動して、もう一度最初からやり直しになります。 おそらくディスクジオメトリ情報の設定を大きくしすぎているのでしょう (やり直しは、DOS によるフォーマットとパーティション確保を含みます)。 もし、不良ブロックの再マッピングを有効にしていて不良ブロックが見付かったら、 ドライブの交換を考えてください。不良ブロックは、時間とともに悪化するからです。 Bustek 742a EISA SCSI が認識されません。 この情報は 742a のためのものですが、他の Buslogic カードについても 同様のことが言えます。(Bustek = Buslogic) 742a カードには大きくわけて 2 つの「バージョン」が存在します。 ハードウェアリビジョンの A-G と H 以降です。リビジョンの 文字はカードの隅にあるアセンブリ番号の後ろにあります。 742a は二つの ROM チップを持っており、一つは BIOS チップで もう一つはファームウェアチップです。FreeBSD はあなたの 持っているものがどの BIOS バージョンかは問題ありませんが、 ファームウェアバージョンについては問題となります。 Buslogic の技術サポート部門に連絡すれば、アップグレード版の ROM を送ってくれることでしょう。BIOS チップと ファームウェアチップはペアで出荷されます。 アダプタカードのハードウェアリビジョンにあわせた 最も新しいファームウェア ROM を使用しなければなりません。 リビジョン A-G のカードには、2.41/2.21 までの BIOS/ファームウェアのセットを使用することができます。 リビジョン H 以降のカードには、最新のものである 4.70/3.37 の BIOS/ファームウェアのセットを 使用することができます。これらのファームウェアの違いは、 ファームウェア 3.37 が 「ラウンドロビン方式」 をサポートしているところからきています。 Buslogic のカードには、製造番号も刻印されています。古い ハードウェアリビジョンのカードを持っている場合は、Buslogic の RMA 部門に問い合わせて製造番号を伝えると、新しいハードウェアリビジョンの カードに交換することもできます。もしカードが十分新しければ、彼らは 交換に応じてくれるでしょう。 FreeBSD 2.1 は ファームウェアリビジョン 2.21 以降のものをサポートしています。 これよりも古いファームウェアリビジョンのものは、 Buslogic カードとして正常に認識されません。 しかし、Adaptec 1540 として認識されるかもしれません。 初期の Buslogic のファームウェアは AHA1540 「互換」モードを 持っています。しかし、EISA カードにとってこれは よいことではありません。 古いハードウェアリビジョンのカードを持っていてファームウェア 2.21 を入手するのであれば、ジャンパ W1 の位置をデフォルトの A-B から B-C に合わせる必要があるでしょう。 HP Netserver 上のオンボード SCSI コントローラが認識されません。 基本的にこれは既知の問題です。HP Netserver マシンの EISA オンボード SCSI コントローラは EISA のスロット番号 11 を占有しますが、「本当の」EISA スロットはすべてそれよりも前のアドレスに配置されているのです。 残念ながら、 10 番以上の EISA スロットは PCI に割り当てられたアドレス空間と衝突し、FreeBSD の自動コンフィグレーションは、 現状ではうまくこの状況を処理できていないのです。 ですから現時点での最良の方法は、カーネルオプションの EISA_SLOTS を 12 に変え、 アドレス空間の衝突がないかの ようなふりをさせることです :) カーネルの再構築に記述されているようにしてカーネルを再構築してください。 もちろん、これはこのようなマシンにインストールする際に 「卵が先か、 鶏が先か」といった問題を生み出すことになります。 この問題を回避するために、 ユーザコンフィグ (UserConfig) の中には特別な仕組みが組み込まれています。 このとき visual インタフェースは使用せず、 コマンドラインインタフェースを使用してください。単純に eisa 12 quit とプロンプト上から打ち込み、 後は普通にインストールを行なってください。 とにかくカスタムカーネルのコンパイルとインストールを行なうことを おすすめします。 うまくいけば、将来のバージョンではこの問題が解決していることでしょう。 HP Netserver では危険覚悟の専用ディスクは使用できません。 詳細については この注意事項をご覧ください。 この CMD640 IDE コントローラはどこかおかしいようです。 それは壊れているのです。両方のチャンネルを同時に制御できないのです。 現在、このチップを使っているシステムを自動的に検出して、 うまく動かすためのしくみが使えるようになっています。 くわしくは wd(4) のマニュアルページを参照してください。 CMD640 IDE コントローラを使っているシステムで FreeBSD 2.2.1 あるいは 2.2.2 を使い、 かつセカンダリのチャネルを使いたいのであれば、 options "CMD640" を有効にしてカーネルを作り直してください。 FreeBSD 2.2.5 以降では、デフォルトでそうなっています。 ed1: timeout のようなメッセージがいつも出ます。 たぶん IRQ の衝突が原因でしょう (二つのボードが同じ IRQ を使用しているなど)。FreeBSD 2.0.5R 以前はこれに関して寛大で、 IRQ の衝突があってもネットワークドライバは機能していました。 しかし 2.0.5R 以降はもはや、IRQ の衝突に寛大ではありません。 オプションをつけて起動し、 ed0/de0/... のエントリをボードの設定に合わせてください。 ネットワークカードの BNC コネクタ (訳注: 10BASE-2 タイプのインタフェース) を使っている場合、 デバイスのタイムアウトはターミネーションの不良によっても起きます。 これをチェックするにはケーブルを外してターミネータを直接 NIC に接続します。そしてエラーメッセージが消えるかどうか 確認します。 NE2000 コンパチブルカードのなかには、 UTP ポートのリンクがなかったりケーブルが接続されていない場合に このエラーを出すものがあります。 CDROM をマウントしようとすると Incorrect super block と言われます。 &man.mount.8; にマウントしたいデバイスのタイプを指定する必要があります。 デフォルトでは &man.mount.8; はファイルシステムを ufs とみなします。CDROM のファイルシステムを マウントしたいのであれば と &man.mount.8; にオプションをつけて明示する必要があります。 これはもちろん CDROM が ISO 9660 ファイルシステムである場合です。ほとんどの CDROM はこの形式です。1.1R の FreeBSD では (訳注: 2.1.5R、 2.2R でも同様です) 自動的に Rock Ridge 拡張 (長いファイル名への対応) をうまく解釈します。 CDROM のデバイス /dev/cd0c を /mnt にマウントしたい場合の例では、次のようにします。 &prompt.root; mount -t cd9660 /dev/cd0c /mnt デバイスの名前はインタフェースによっては別の名前になっている かもしれないので注意してください (/dev/cd0c はこの場合の例です)。 オプション によって mount_cd9660 コマンドが実行されることに注意してください。 このため例は次のようにすることもできます。 &prompt.root; mount_cd9660 /dev/cd0c /mnt CDROM をマウントしようとすると Device not configured と言われます。 これは 一般的に CDROM ドライブの中に CDROM が入っていないか、 ドライブがバス上に見えないことを意味します。ドライブに CDROM を入れるか、IDE (ATAPI) であれば master/slave の状態をチェックしてください。 また、CDROM ドライブに CDROM を入れてから認識するまでには数秒かかりますので、 少し待ってみてください。 SCSI CDROM ではバスリセットへの応答時間が遅いために、 失敗することがあるかもしれません。 SCSI CDROM を持っている場合は、 カーネルコンフィグレーションファイルに以下の行を加えて 再コンパイルして試してみてください。 訳注 現在の GENERIC カーネルでは上の設定はデフォルトになっています。 問題のある場合は SCSI_DELAY の数値を増やしてみてください。 options "SCSI_DELAY=15" CDROM をマウントすると、ファイル名中の英数字以外の 文字が、? と表示されてしまいます。 もっともありそうなのは、その CDROM が Joliet 拡張を利用してファイルおよび ディレクトリに関する情報を保存しているということです。この拡張は、 すべてのファイル名を Unicode の 2 バイト文字で保存するように 規定しています。現在、FreeBSD カーネルに汎用的な Unicode インタフェースを導入する作業が行われていますが、 まだ完了していません。したがって、CD9660 ドライバはファイル名の文字を解読できません。 一時的な解決策として、FreeBSD 4.3R 以降では、CD9660 ドライバに特別な仕掛けを施して、ユーザーがその場で適切な 変換表を読み込めるようにしました。一般的なエンコーディングに 対応したいくつかのモジュールが sysutils/cd9660_unicode port で提供されています。 訳注 この記述は古くなっています。 英語版の記述をご覧ください。 私のプリンタはとてつもなく遅いのです。 どうしたらよいのでしょう? パラレルインタフェースで、問題はとんでもなく遅いだけであるなら、 プリンタボートを polled モードに設定してみてください。 &prompt.root; lptcontrol -p HP の新しいプリンタには、 割り込みモードで使えないものがあるようです (完全にわかったわけではありませんが)。 タイミングの問題のように思われます。 わたしのプログラムは時々 Signal 11 のエラーで止まってしまいます。 Signal 11 エラーはオペレーティングシステムが 許可を与えていないメモリにアクセスしようとしたときに発生します。 このようなことがランダムな間隔で起っているようなら、 注意深く調査していった方が良いです。 この手の問題はたいていの場合、以下のどちらかです。 その問題が特定の、 あなたが自分で開発したアプリケーションでのみ起っているなら、 あなたのコードにバグがあるのでしょう。 それが FreeBSD のベースシステムの一部と関連する問題なら、 コードにバグがあるということになります。 しかしほとんどの場合、 普通の FAQ の読者がそのようなコードを使うようになるずっと前に、 そういった問題は発見され、修正されているはずです (それが -current の役目なのですから)。 それが FreeBSD のバグでは「ない」という決定的なケースとして、 その問題の発生がプログラムをコンパイルしているときであり、 コンパイル毎に毎回、コンパイラの挙動が変るというものがあります。 たとえば、あなたが make buildworld を実行していて、 コンパイラが ls.c から ls.o をコンパイルしようとしたときに コンパイルに失敗したとします。もう一度 make buildworld を実行したときに、まったく同じ場所でコンパイルが失敗したのなら、 それは build が壊れている (訳注: つまりソースにバグがある) と言うことです -- ソースを更新してやりなおしてみてください。 もしコンパイルが別の場所でしくじっていたら、 それはハードウェアの問題です。 あなたのやるべき事は: 前者の場合は、 そのプログラムの間違ったアドレスへアクセスしようとしている部分を、 gdb 等のデバッガで見つけて修正します。 後者の場合は、 ハードウェアに問題がないことを確かめる必要があります。 その一般的な原因として : ハードディスクが熱を持ちすぎているかも知れません: ケースのファンがちゃんと動いていてディスクを冷やしているか 確かめてください (たぶん、他の部品も過熱しています)。 CPU がオーバーヒートしています: CPU をオーバークロックしていませんか? さもなければ CPU ファンが死んでいるのかもしれません。 いずれにせよ、少なくとも問題解決の間では ハードウェアが動くべく指定された条件で動かしてください。 クロックはデフォルトの設定に戻してください。 もしあなたがクロックアップをしているのなら、 遅いシステムでも、システムが焼き付いて 買い換えなければならなくなるよりずっとマシだということを 覚えておいた方が良いでしょう。 大きいコミュニティでは特に、 あなたがそれが安全だと思っているかどうかは関係なく、 オーバークロックしたシステムに発生した問題には同情的ではありません。 怪しいメモリ: もし複数の SIMM や DIMM を使っているならそれを全部抜いてから 各 SIMM や DIMM を別個に組み込んだシステムを立ち上げてることで どの DIMM/SIMM が怪しいのか、それとも組合わせが悪いのか と問題の幅が狭まります。 楽観的すぎるマザーボードの設定: ほとんどの場合に標準設定で十分なタイミングを、 BIOS の設定やマザーボード上のジャンパピンを変えることで、 さまざまに変更することができます。しかし時には RAM の アクセスウェイトを低くしすぎたり RAM Speed: Turbo や その手の BIOS の設定でおかしな挙動が起こることがあります。 BIOS を標準の設定に戻すというのはいいアイディアですが、 その前にあなたの設定を書き留めておいた方がいいでしょう。 マザーボードへの電源が安定していない。 もし使っていない I/O ボードやハードディスク、 CDROM 等があるなら、一旦それらから電源ケーブルを抜き、 電源が小さな負荷ならなんとか動作するか確認しましょう。 あるいは別の電源を試してみましょう。 その時はなるべく、少し容量の大きいもので試しましょう (たとえば、今の電源容量が 250W だったら 300W のものを試します)。 SIG11 FAQ (下に示します) にはこれらの問題のすべてが 詳しく説明されています。Linux の視点に基づくものですが、 これも読んでおいた方がいいでしょう。そこではまた、 メモリのテストを行うソフトウェアや、 ハードウェアがなぜ問題のあるメモリを見逃してしまうかについても 議論されています。 最後に、これらがどれも助けにならなかったら、 FreeBSD のバグを発見した可能性があります。 以下の説明を読んで障害報告を送ってください。 詳細な FAQ は、 the SIG11 problem FAQ にあります。 起動の時に画面が真っ暗になって同期も取れません。 これは ATI Mach 64 ビデオカードの既知の問題です。 この問題はカードがアドレス 2e8 を使い、 4 番目のシリアルポートもここを使うということにあります。 &man.sio.4; ドライバのバグ (仕様?) のため、 4 番目のシリアルポートがなくても、 通常このアドレスを使う sio3 (4 番目のポートにあたります) を無効にしても、ドライバはこのアドレスをさわります。 バグが修正されるまでは、次のようにして対処してください。 起動プロンプトが出たら と入力します (これによりカーネルはコンフィグレーションモードに入ります)。 sio0、 sio1、 sio2、 sio3 (これらすべて) を無効にします。 これによって &man.sio.4; ドライバは動作しなくなりますが、問題はありません。 exit と入力して起動を続行します。 もしシリアルポートを有効にしたいのであれば以下の変更を行なって 新しいカーネルを作る必要があります。 /usr/src/sys/i386/isa/sio.c の中で 1 ヵ所ある 0x2e8 という文字列を探し、 この文字列とその手前にあるコンマを削除します (後ろのコンマは残します)。 後は通常の手続きにしたがって新しいカーネルを作ります。 この対処を行なった後でもまだ X ウィンドウシステムはうまく動かないかもしれません。 その場合は、 使用している XFree86 がすくなくとも XFree86 3.3.3 以降であることを確かめてください。 それ以降のバージョンでは、 Mach64 カードやそれらのカードのためにつくられた X サーバ の組込みをサポートします。 128MB の RAM があるのですが、64MB しか認識しません。 FreeBSD がメモリのサイズを BIOS から取得する方法の制限により、 KB 単位で 16 ビット分までしか検出できません (すなわち最大 65535KB=64MB です。これより少ない場合もあります。 ある BIOS の場合はメモリサイズが 16MB に制限されます)。 64MB 以上のメモリを積んでいる場合、 FreeBSD はそれを検出しようとします。 しかしその試みは失敗するかもしれません。 この問題を回避するには、 以下に示すカーネルオプションを使用する必要があります。 完全なメモリ情報を BIOS から取得する方法もありますが、 起動ブロックに空きが無いため実装できません。 起動ブロックの問題が解決されれば、 いつか拡張 BIOS 機能を使用して完全なメモリ情報を取得できるようになるでしょう。 とりあえず現在は、カーネルオプションを使ってください。 options "MAXMEM=n" n には、 キロバイト単位でメモリの量を指定します。128MB の場合は、131072 となります。 FreeBSD 2.0 が kmem_map too small! と言ってパニックします。 メッセージは、mb_map too small! の場合もあります。 このパニックは、ネットワークバッファ (特に mbuf クラスタ) の仮想メモリが無くなったことを示します。 以下のオプションをカーネルコンフィグファイルに追加して mbuf クラスタに使用できる仮想メモリの量を増やしてください。 options "NMBCLUSTERS=n" n には、 同時に使用したい TCP コネクションの数に応じて 512 から 4096 までの数値を指定できます。 とりあえず 2048 を試してみるのをおすすめします。 これでパニックは完全の予防できるはずです。 mbuf クラスタの割り当て、使用状況については、 netstat -m で知ることができます (&man.netstat.1; をご覧ください)。 NMBCLUSTERS のデフォルト値は 512 + MAXUSERS * 16 です。 新しいカーネルで再起動すると CMAP busy panic となってパニックを起こしてしまいます。 ファイル /var/db/kvm_*.db において範囲外のデータを検出するためのロジックは失敗することがあり、 こうした矛盾のあるファイルを使用することでパニックを引き起こすことがあります。 これが起こったなら、シングルユーザで再起動した後に、 以下のコマンドを実行してください。 &prompt.root; rm /var/db/kvm_*.db ahc0: brkadrint, Illegal Host Access at seqaddr 0x0 というエラーが出ます これは Ultrastor SCSI Host Adapter と衝突しています。 起動時に kernel configuration メニューに入り、 問題を起こしている uha0 を disable にしましょう。 sendmail が mail loops back to myself というメッセージを出すのですが。 この事は、sendmail FAQ に次のように書いてあります。 * "Local configuration error" というメッセージが出ます。たとえば: 553 relay.domain.net config error: mail loops back to myself 554 <user@domain.net>... Local configuration error のような物ですが、どのようにしたらこの問題を解決できますか? これは、たとえば domain.net のようなドメイン宛てのメールを MX record で 特定のホスト (ここでは relay.domain.net) に送ろうとしたのに、 そのホストでは domain.net 宛てのメールを受け取れるような設定に なっていない場合です。設定の際に FEATURE(use_cw_file) を 指定してある場合には /etc/sendmail.cw の中に domain.net を 追加してください。もしくは、/etc/sendmail.cf の中に "Cw domain.net" を追加してください。 もはや現在の sendmail FAQ は sendmail release とは一緒には保守されていません。 しかし次のネットニュースに定期的に投稿されてます。 comp.mail.sendmail、 comp.mail.misc、 comp.mail.smail、 comp.answers、 news.answers。 また、メール経由でコピーを入手する場合は mail-server@rtfm.mit.edu 宛まで本文に send usenet/news.answers/mail/sendmail-faq と書いて送ります。 リモートマシン上のフルスクリーンアプリケーションがうまく動かない リモートマシンのターミナルタイプが FreeBSD のコンソールで必要とされている cons25 以外のものです。 この問題を解決しうる方法はいろいろあります: リモートマシンにログインした後、 そのリモートマシンが ansi か sco のターミナルタイプを知っているなら、 shell 変数の TERM にそれらのいずれかを設定します。 FreeBSD のコンソール側で screen のような VT100 エミュレータを使用します。 screen は一つのターミナルの中で複数のセッションを並列動作させることができますし、 本来の機能も優れています。 各々の screen のウィンドウは VT100 ターミナルのように振る舞うので、 リモート側で設定されるべき TERM 変数は vt100 となります。 リモートマシンのターミナルデータベースに cons25 のエントリをインストールします。 このインストール方法はリモートマシンのオペレーティングシステムに依存します。 リモートのシステムのシステム管理マニュアルが役に立つことでしょう。 FreeBSD 側で X サーバを起動して、 リモートマシンに xterm や rxvt のような X ベースのターミナルエミュレータを使ってログインします。 (訳注: 日本語が必要な場合は kterm 等を 利用します) リモートホストの TERM 変数は xterm もしくは vt100 (訳注: もしくは kterm) に設定します。 私のマシンで calcru: negative time... と表示されるのですが これは、割り込みに関連するさまざまな不具合によって発生します。 あるいは、あるデバイスが元々持っているバグが表面化したのかも知れません。 この症状を再現させる一つの方法として、パラレルポート上で、 TCP/IP を 大きな MTU で走らせるというものがあります。 グラフィックアクセラレータがこの症状を起こすことがありますが、 その場合はまず、カードの割り込み設定を確認してください。 この問題の副作用として、 プロセスが SIGXCPU exceeded cpu time limit というメッセージとともに終了してしまう、というものがあります。 1998 年 11 月 29 日に公開された FreeBSD 3.0 以降で この問題が解決しないなら、次の sysctl 変数をセットしてください。 &prompt.root; sysctl -w kern.timecounter.method=1 これは、パフォーマンスへ強い影響を与えますが、 問題の発生に比べればおそらく気にならない程度でしょう。 もし、これでもまだ問題が残るようなら、 カーネルオプションの NTIMECOUNTER を大きな値に増やしてください。 NTIMECOUNTER=20 にまで増やしても解決しない場合は、 計時処理の信頼性が保てない程の割り込みが、 そのマシン上で起こっていることを意味します。 pcm0 not found という表示を見たり カーネルコンフィグレーションファイルには device pcm0 と 書いてあるのにサウンドカードが pcm1 として 発見されたりします。 これは FreeBSD 3.x で PCI のサウンドカードを使っているときに 発生します。pcm0 デバイスは ISA のカード専用に予約されているものです。このため、 あなたが PCI カードを持っているときはこのエラーが表示され、 カードは pcm1 として検出されます。 この警告を、単にカーネルコンフィグファイルの当該行を device pcm1 に変更することで 抑制することはできません。その時は pcm1 が ISA カードのために予約され、PCI のカードは pcm2 として (pcm1 not found の警告とともに) 検出されます。 PCI のサウンドカードを持っているのならば、以下のようにして snd0 デバイスのかわりに snd1 を作る必要があります。 &prompt.root; cd /dev &prompt.root; ./MAKEDEV snd1 この状況は FreeBSD 4.x では生じません。多くの努力の結果より PnP 中心に作り替えられ、 現在、pcm0 デバイスは ISA カード専用に予約されたものではなくなりました。 プラグアンドプレイのカードが認識されなくなりました (または、unknown と認識されるようになりました)。 現在の FreeBSD 4.x はより PnP 中心に なっています。その副作用の影響で、FreeBSD 3.x で動いていた PnP デバイス (たとえばサウンドカードや内蔵モデム) の中には、 動かなくなってしまったものもあります。 この挙動の原因は Peter Wemm が freebsd-questions メーリングリストに書いた、以下の 「FreeBSD 4.x にアップグレードしたところ内蔵モデムが 見つからなくなった」というメールで解説されています。 (わかりやすくするために [] 内に コメントを加えました)。
PnP BIOS はあらかじめ、[モデムを] ポート空間に存在しているかのように設定します。 そのため [3.x では] 従来の手法に基づく ISA デバイスの検索により、モデムの存在を「発見」できます。 4.0 の ISA コードは、より PnP 中心になっています。 [3.x では] ISA デバイスの検索が「はぐれた」デバイスを発見して、 次に PNP デバイス ID のマッチが行なわれることでリソースの競合が発生し、 デバイスの検索に失敗する可能性があります。 したがって、4.0 の ISA コードでは 二重に検索しないよう、プログラマブルなカードを 最初に無効にしています。 これは、対応している PnP ハードウェアの PnP ID が、 予めわかっている必要がある、ということを意味します。 ユーザがこの挙動にもっと手を入れられるようにすることが TODO リスト中にあげられています。
3.0 で動作していたデバイスを 4.0 でも動作するようにするには、 それの PnP ID を調べ、ISA デバイスの検索が PnP デバイスの識別に使っているリストにそれを追加する必要があります。 デバイスの検索に使われる &man.pnpinfo.8; を用いて、 PnP ID を得ることができます。 たとえば、内蔵モデムに関する &man.pnpinfo.8; の出力は、 以下のようになります。 &prompt.root; pnpinfo Checking for Plug-n-Play devices... Card assigned CSN #1 Vendor ID PMC2430 (0x3024a341), Serial Number 0xffffffff PnP Version 1.0, Vendor Version 0 Device Description: Pace 56 Voice Internal Plug & Play Modem Logical Device ID: PMC2430 0x3024a341 #0 Device supports I/O Range Check TAG Start DF I/O Range 0x3f8 .. 0x3f8, alignment 0x8, len 0x8 [16-bit addr] IRQ: 4 - only one type (true/edge) [more TAG lines elided] TAG End DF End Tag Successfully got 31 resources, 1 logical fdevs -- card select # 0x0001 CSN PMC2430 (0x3024a341), Serial Number 0xffffffff Logical device #0 IO: 0x03e8 0x03e8 0x03e8 0x03e8 0x03e8 0x03e8 0x03e8 0x03e8 IRQ 5 0 DMA 4 0 IO range check 0x00 activate 0x01 必要な情報は、出力の冒頭にある Vendor ID 行にあります。 かっこの中の 16 進数 (例の中では 0x3024a341) が PnP ID で、 直前の文字列 (PMC2430) はユニークな ASCII ID です。 この情報はファイル /usr/src/sys/isa/sio.c に 追加する必要があります。 まず失敗したときに備えて sio.c の バックアップを取るべきです。障害報告を送るために修正パッチを 作る時にも必要になるでしょう (send-pr しようとしていますよね?)。 sio.c を編集して以下の行を探してください。 static struct isa_pnp_id sio_ids[] = { そしてあなたのデバイスのエントリを追加する正しい場所を探します。 エントリは以下のような形をしていて、&man.pnpinfo.8; の 出力にある デバイスの説明の全部 (もし収まれば) か一部とともに行の右の方のコメント領域に書かれている ASCII ベンダ ID でソートされています。 {0x0f804f3f, NULL}, /* OZO800f - Zoom 2812 (56k Modem) */ {0x39804f3f, NULL}, /* OZO8039 - Zoom 56k flex */ {0x3024a341, NULL}, /* PMC2430 - Pace 56 Voice Internal Modem */ {0x1000eb49, NULL}, /* ROK0010 - Rockwell ? */ {0x5002734a, NULL}, /* RSS0250 - 5614Jx3(G) Internal Modem */ あなたのデバイスの16進数のベンダ ID を正しい場所に 追加し、ファイルをセーブしてカーネルを作り直して再起動します。 あなたのデバイスは FreeBSD 3.x の時と同じように sio として見つかるようになっているはずです。 top や systat の 実行中に nlist failed という エラーがでます。 このエラーは、 実行しようとしたアプリケーションが あるカーネルシンボルを検索した結果、 何らかの理由でその検索に失敗した、ということを意味しています。 これは、以下に示すいずれかの理由によるものです。 カーネルとユーザランドが同期していない (つまり カーネルは新しいものを構築したが、 installworld は行なっていない。 あるいはその逆) ので、 シンボルテーブルがユーザアプリケーションの考えているものと異なっている。 もしこのケースなら、一連のアップグレード手順に従ってアップグレードを行なってください (正しいやり方は /usr/src/UPDATING に書いてあります)。 カーネルをロードするのに /boot/loader を使わず、 直接 boot2 (&man.boot.8; 参照) からロードしている。 もちろん /boot/loader を使わなくとも問題はないのですが、 /boot/loader は一般的に、 ユーザアプリケーションからカーネルシンボルを アクセスできるようにするための機能を持っています。 &man.ssh.1; や &man.telnet.1; でコンピュータに接続する のに、どうしてこんなに時間がかかるのですか? 症状: TCP コネクションが確立してから、 クライアントソフトウェアがパスワードを尋ねてくるまで (&man.telnet.1; の場合は、ログインプロンプトが表示されるまで) に長い時間がかかる、というもの。 問題: おそらく、サーバソフトウェアがクライアントの IP アドレスからホスト名を解決しようとして、遅れが生じている のでしょう。FreeBSD に付属する SSH や Telnet を含む多くの サーバソフトウェアは、この名前解決をおこないます。これは、 管理者が後日参照するログファイルに、その他の情報と一緒に ホスト名を記録できるようにするのが目的です。 対処法: もし、あなたのコンピュータ (クライアント) からどのサーバに接続する場合にも問題が起こるのであれば、 クライアントに問題があります。そして、誰かがあなたの コンピュータ (サーバ) に接続するときだけ問題が起こるのであれば、 そのサーバの問題です。 問題がクライアントにある場合、唯一の対処法は サーバがそのクライアントの名前を解決できるように DNS を修正することです。 症状がローカルネットワークで発生しているなら、サーバの設定に 原因がありますので、このまま続きを読みましょう。 そうではなく、グローバルなインターネット環境で発生しているなら、 ISP に連絡して問題の修正をお願いしなければならない可能性が高いでしょう。 問題がサーバにあって、症状がローカルネットワークで 発生しているなら、ローカルのアドレス範囲にあるアドレスを、 それに対応するホスト名に解決する問合せを処理できるように、 サーバを設定する必要があります。 詳しくは、&man.hosts.5; および &man.named.8; のマニュアルをご覧ください。グローバルなインターネット環境の場合は、 サーバのリゾルバが正しく動作していないのが原因かもしれません。 確認するには、他のホスト (たとえば www.yahoo.com) を引いてみてください。 うまくいかなければ、あなたのコンピュータの問題です。 file: table is full という メッセージが繰り返し dmesg にあらわれます。 このエラーは、システムのファイル記述子を使い果たして しまった時に発生します。メモリ中のファイルテーブルが一杯に なっているのです。 解決法: 手動で sysctl 変数 kern.maxfiles の限界値を調整します。 &prompt.root; sysctl -w kern.maxfiles=n n は、システム要件に合わせてください。 オープンされたファイル、ソケットまたは fifo のそれぞれが ファイル記述子を消費します。規模の大きなサーバは、 同時に実行されるサービスに応じて、いともたやすく何万もの ファイル記述子を要求します。 カーネルに設定されたデフォルトのファイル記述子の 数を決定するのは、次の maxusers 32 カーネル設定ファイルの maxusers 行 です。kern.maxfiles はこの値に比例して 増加します。 現在設定されている kern.maxfiles の 値は、次のコマンドで調べることができます。 &prompt.root; sysctl kern.maxfiles kern.maxfiles: 1064 laptop の時間が狂って、大きく進んだり遅れたりします。 laptop には二つ以上の時計が内蔵されていますが、FreeBSD が間違った方を選択して使用しています。 &man.dmesg.8; を実行して Timecounter を含む行を確認してください。 最後に出力された行が FreeBSD が選択したもので、まず間違い なく TSC でしょう。 &prompt.root; dmesg | grep Timecounter Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 595573479 Hz &man.sysctl.3; 変数 kern.timecounter.hardware を確認すれば 裏付けがとれます。 &prompt.root; sysctl kern.timecounter.hardware kern.timecounter.hardware: TSC バッテリ駆動している時に、BIOS が CPU の速度を変えるために TSC クロックを変更したり、電力節約モードに入ることがあります。 しかし、FreeBSD はそういった調整を関知しないので、 時間が早まったり遅れたりするようです。 上記の例では、i8254 クロックも利用できます。 &man.sysctl.3; 変数 kern.timecounter.hardware にその名称を書き込んで選択できます。 &prompt.root; sysctl -w kern.timecounter.hardware=i8254 kern.timecounter.hardware: TSC -> i8254 これで、laptop はより正確な時間を刻むでしょう。 この変更を起動時に自動で行うには、次の行を /etc/sysctl.conf に追加してください。 kern.timecounter.hardware=i8254 商用アプリケーション 訳: 山下 淳 junkun@esys.tsukuba.ac.jp、 1997 年 11 月 10 日 この章はまだまだ情報が足りません。 情報を追加してくれるような企業を待ち望んでいます。 FreeBSD グループはここに載っている企業からの金銭的な支援を期待してはいませんので、 奉仕作業の一つとして掲載しています (そして FreeBSD が係わる宣伝は、長い目で見ると FreeBSD に対してよい方向へ働くと思っています)。 私たちは商用ソフトウェアベンダに、 ここで製品を宣伝してもらうことを望んでいます。詳しくは、 商用ソフトウェアベンダ覧のページをご覧ください。 FreeBSD 用のオフィススイートはどこで入手できますか? BSDi は FreeBSD ネイティブ版の VistaSource ApplixWare 5 を提供しています。 ApplixWare は、豪華で機能満載の FreeBSD 向けの 商用オフィススイートで、ワードプロセッサ、表計算、 プレゼンテーションソフトウェア、ベクタ描画ソフトウェア、 その他のアプリケーションを揃えています。 FreeBSD 版の ApplixWare の購入は こちらからどうぞ。 Linux 版の StarOffice は FreeBSD で完璧に動作します。Linux 版の StarOffice をインストールするもっとも簡単な方法は、FreeBSD Ports コレクションを利用することです。 また、オープンソースの OpenOffice も将来のバージョンで動作するでしょう。 FreeBSD 用の Motif はどうやったら手に入りますか FreeBSD 用の廉価版 ELF Motif 2.1.20 (i386 版、Alpha 版) に関する情報はApps2go から 手に入れることができます。 この製品には、「開発者版 (development edition)」 と、 より安価な「ランタイム版 (runtime edition)」 の二つの版があります。これらの製品は以下の物が含まれています。 OSF/Motif manager、xmbind、panner、wsm。 uil、mrm、xm、xmcxx、インクルードファイルや Imake ファイルといった開発者向けキット FreeBSD 3.0 以降で利用できる ELF 版スタティックライブラリ、 およびダイナミックライブラリ デモンストレーションプログラム 注文する際には FreeBSD 用の Motif であることをきちんと 確認してください (あなたの欲しいアーキテクチャを指定するのも 忘れないでください!)。NetBSD や OpenBSD 用の Motif もまた、 Apps2goから販売されています。現在、FTP による ダウンロードのみ利用可能です。 より詳しい情報は Apps2go WWW page 問い合わせは Sales または Support 電子メールアドレス。 もしくは phone (817) 431 8775 or +1 817 431-8775 他の FreeBSD 用 Motif 2.1 (ELF 版、a.out 版) に関する情報は Metro Link から手に入れることができます。 この製品は以下の物が含まれています。 OSF/Motif manager、xmbind、panner、wsm。 uil、mrm、xm、xmcxx、インクルードファイルや Imake ファイルといった開発者向けキット スタティックライブラリ、およびダイナミックライブラリ。 (FreeBSD 3.0 以降で利用できる ELF 版か、 FreeBSD 2.2.8 以前で利用できる a.out 版を指定してください) デモンストレーションプログラム 整形済みのマニュアルページ 注文する際には FreeBSD 用の Motif であることをきちんと 確認してください。Linux 用の Motif も Metro Link から販売されています。現在、CDROM および FTP によるダウンロードが利用可能です。 FreeBSD 用の a.out 版 Motif 2.0 に関する情報は Xi Graphics から 手に入れることができます。 この製品には以下の物が含まれています。 OSF/Motif manager、xmbind、panner、wsm。 uil、mrm、xm、xmcxx、インクルードファイルや Imake ファイルといった開発者向けキット FreeBSD 2.2.8 以前のバージョンで利用できるスタティックライブラリ、 およびダイナミックライブラリ デモンストレーションプログラム 整形済みのマニュアルページ 注文する際には FreeBSD 用の Motif であることをきちんと 確認してください。BSDI や Linux 用の Motif もまた、Xi Graphics から販売されています。現在フロッピーディスク 4枚組ですが、 将来的には CDE のように統合された CD に変わるでしょう。 FreeBSD 用の CDE はどうやったら手に入りますか 以前 Xi Graphics より FreeBSD 用の CDE が 販売されていましたが、現在は既に販売が終了しています。 KDE 多くの点で CDE と類似しているオープンソースの X11 デスクトップ環境です。 xfce の ルック & フィール (訳注: 外観や操作方法のこと) も気に入るかも知れません。 KDE、xfce は、いずれも FreeBSD Ports Collection に含まれています。 高機能な商用 X サーバってあるんですか? はい、Xi Graphics と Metro Link から、FreeBSD ほか Intel ベースのシステムで動作する Accelerated-X という製品が販売されています。 Metro Link は、FreeBSD のパッケージ操作ツールを利用することで 容易に設定が行なえるほか、数多くのビデオボードをサポートした 高機能な X サーバを提供しています。配布はバイナリ形式のみで、 FTP が利用可能です。もちろん、とても安価 ($39) に手に入れることができます。 また、Metro Link は ELF 版、a.out 版の FreeBSD 用 Motif も販売しています (前を参照)。 より詳しい情報は Metro Link WWW page 問い合わせは Sales または Support 電子メールアドレス もしくは phone (954) 938-0283 or +1 954 938-0283 Xi Graphics が提供している高性能な X サーバは楽に設定を行なえるほか、 数多くのビデオボード をサポートしています。サーバはバイナリのみが含まれます。 FreeBSD 用と Linux 用の統合されたフロッピーディスクに入っています。 Xi Graphics は Laptop サポートに特化した高性能 X サーバも提供しています。 バージョン 5.0 の「互換デモ」が無料で入手できます。 また Xi Graphics は FreeBSD 用の Motif と CDE も販売しています (前を参照)。 より詳しい情報は Xi Graphics WWW page 問い合せは Sales または Support もしくは phone (800) 946 7433 or +1 303 298-7478. FreeBSD 用のデータベースシステムはありますか? もちろんです。FreeBSD のウェブサイトにある 商用ベンダー というセクションをご覧ください。 また、FreeBSD Ports Collection のデータベースのセクションも参考になるでしょう。 Oracle を FreeBSD 上で動かすことはできますか? はい。Linux 版 Oracle を FreeBSD でセットアップするための方法は、 次に示すページに詳しく書かれています。 http://www.scc.nl/~marcel/howto-oracle.html http://www.lf.net/lf/pi/oracle/install-linux-oracle-on-freebsd ユーザアプリケーション 訳: 山下 淳 junkun@esys.tsukuba.ac.jp、 &a.jp.shou;、 1997 年 11 月 8 日 そういうユーザアプリケーションはどこにあるの? FreeBSDに移植されたソフトウェアパッケージについては、 FreeBSD Ports Collection のページをご覧ください。 このリストには現在 3400 を越える項目があり、 しかも毎日更新されています。このページをこまめに訪れるか、 freebsd-announce メーリングリストを購読すると、 新しく入った ports を定期的にチェックすることができます。 大部分の ports は 2.2 と 3.x および 4.x ブランチで利用できるはずです。 多くは 2.1.x 系のシステムでも同様に動作するでしょう。 FreeBSD のリリースが出る度に、そのリリースの時点での ports ツリーの スナップショットが撮られ、ports/ ディレクトリに 納められることになっています。 また、package という考えも採用されています。これは基本的には gzip で圧縮されたバイナリディストリビューションに、 インストール時に環境に合わせた作業が必要になった場合、 行う機能を多少付け加えたものです。 package を使えば、どのようなファイルが配布物として含まれているか、 と言った細かい事柄にいちいち煩わされることなく、 簡単にインストールやアンインストールを繰り返すことができます。 インストールしたい package があるなら、 /stand/sysinstallの、 「インストール後の FreeBSD の設定を行う」の下にある package のインストールメニューを使うか、 package のファイル名を指定して pkg_add(1) を使用してください。 package のファイル名には、 通常末尾に .tgz がついています。 CDROM をご使用の方は、CD の packages/All ディレクトリからそれらのファイルを利用することができます。 また、以下の場所から、 FreeBSD の各種バージョンにあわせた package をダウンロードする こともできます。 2.2.8-RELEASE/2.2.8-STABLE 用 ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-2.2.8/ 3.X-RELEASE/3.X-STABLE 用 ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/ 4.X-RELEASE/4-STABLE 用 ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/ 5.X-CURRENT 用 ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current お近くのミラーサイトもご利用ください。 新しい ports が続々と追加されている状態なので、すべての ports に 対応する package が存在するわけではないことを覚えておいてください。 定期的に ftp.FreeBSD.org マスターサイトを訪れて、どのような package が利用できるのかチェックするのも良いでしょう。 なぜ /bin/sh はこんなに低機能なのですか? どうして bash や他のシェルを採用しないのでしょう? それは、POSIX がそのようなシェルがあることを規定しているからです。 もっと込み入った回答: 多くのユーザは、多くのシステムで同じように動作できるシェルスクリプトを書く必要があります。 これが、POSIX でシェルやユーティリティコマンドが細く規定されている理由です。 ほとんどすべてのスクリプトは Bourne shell で書かれているのですが、 それは、数多くの重要なプログラミングインタフェイス (&man.make.1;、 &man.system.3;、&man.popen.3;、や Perl や Tcl 等の類似の 高水準スクリプト言語) が、コマンドの解釈に Bourne shell を使うからです。 このように Bourne shell が極めて頻繁にかつ広範囲で使われているため、 素早く起動できて確実に動作し、メモリを少ししか消費しないということが 重要になります。 既存の実装は、 私たちに可能な限りこれらの多くの要求を同時に満足することができる最良のものです。 /bin/sh を小さいままに保つため、 私たちは他のシェルが持つ様々な便利な機能を提供していません。 Ports コレクションが bash や scsh、tcsh、zsh などの 多機能なシェルを含んでいるからです (これらのシェルすべての メモリ使用状況は、ps -u の VSZ や RSS の行で、あなた自身が確認することができます)。 libc.so.3.0 はどこにありますか? FreeBSD 2.1.x のシステムで 2.2 以降用の package を動かそうとしていますね? 前のセクションを読んで、システムに合った正しい port/package を入手してください。 Error: can't find libc.so.4.0 というメッセージが表示されるのですが。 何かの手違いで、4.X と 5.X のシステム用 package をダウンロードし、 FreeBSD 2.X、もしくは 3.X のシステムにインストールしてしまったのでしょう。 対応する正しいバージョンの package をダウンロードしてください。 386/486SX のマシンで ghostscript を動かすとエラーがでます。 あなたのマシンには数値演算プロセッサが塔載されていませんね? カーネルにコプロセッサの代わりとなる数値演算エミュレータを追加する必要があります。 以下のオプションをカーネルのコンフィグレーションファイルに追加して、 カーネルを再構築してください。 options GPL_MATH_EMULATE このオプションを追加する場合、 MATH_EMULATE の行を削除してください。 SCO/iBCS2 のアプリケーションを実行すると、 socksys で落ちてしまいます。 (FreeBSD 3.0 とそれ以前のみ) まず最初に /etc/sysconfig (または /etc/rc.conf, &man.rc.conf.5; 参照) の最後のセクションを編集し、 以下の変数を YES に直します。 # Set to YES if you want ibcs2 (SCO) emulation loaded at startup ibcs2=NO これでシステムの起動時に ibcs2 カーネルモジュールが読み込まるようになります。 次に /compat/ibcs2/dev/ を以下のように編集します。 lrwxr-xr-x 1 root wheel 9 Oct 15 22:20 X0R@ -> /dev/null lrwxr-xr-x 1 root wheel 7 Oct 15 22:20 nfsd@ -> socksys -rw-rw-r-- 1 root wheel 0 Oct 28 12:02 null lrwxr-xr-x 1 root wheel 9 Oct 15 22:20 socksys@ -> /dev/null crw-rw-rw- 1 root wheel 41, 1 Oct 15 22:14 spx open や close の処理は、 socksys から /dev/null (&man.null.4; 参照) へシンボリックリンクを張ることで代用します。 残りの処理は、-CURRENT に入っているコードが担当しています。 これは以前のものより ずっとスッキリした方法です。 INN (インターネットニュース) の設定方法は? inn の package や port をインストールしたあとに Dave Barr's INN Page を見てみましょう。初心者向けの INN FAQ があります。 どのバージョンの Microsoft FrontPage を手に入れる必要がありますか? ルーク、ports を使うのだ! パッチ処理済みの Apache が ports ツリーから入手できます。 FreeBSD は Java をサポートしていますか? はい。 http://www.FreeBSD.org/java/ をご覧ください。 日本語訳 もあります。 3.x-STABLE を載せているマシンで port がコンパイルできないことがあります。それはどうしてですか? もし、その時点の -CURRENT か -STABLE に比べてずっと古いバージョンの FreeBSD を利用しているなら、 http://www.FreeBSD.org/ports/ にある ports アップグレードキットが必要です。 最新の FreeBSD を利用しているのに発生する場合はおそらく、 -CURRENT では正常なのに -STABLE ではうまく動かなくなるような変更がその port に対して行なわれ、受理されてしまっているのでしょう。 ports コレクションは -CURRENT と -STABLE、 両方のブランチで動かなければならないものですので、 もしそれを発見したら send-pr(1) コマンドを使ってバグレポートの提出をお願いします。 ld.so はどこにありますか? 3.1-R 以降などの Elf 化されたマシンで Netscape Navigator などの aout 形式のアプリケーションを動かすときには、 /usr/libexec/ld.so と aout ライブラリのファイルが必要です。 それらは配布物の compat22 に納められています。 /stand/sysinstall や compat22 サブディレクトリ内の install.sh を使って compat22 をインストールしてください。 合わせて 3.1-R と 3.2-R の ERRATA もお読みください。 ソースコードを更新しました。さて、インストール済みの ports を更新するにはどうすればよいでしょうか? 残念ながら、インストール済みの ports を更新する簡単な 方法はありません。pkg_version コマンドを 用いて ports ツリー中の新しいバージョンに更新する スクリプトを次のように生成することができます。 &prompt.root; pkg_version > /tmp/myscript 出力されたスクリプトを使う前に、手で 編集しなければなりません。現在のバージョンの pkg_version では、スクリプトの先頭に exit を挿入して強制しています。 スクリプトの出力には、更新された packages に依存する packages が記載されているので、保存しておきましょう。これらも やはり更新する必要があるかもしれません。通常、更新が 必要となるのは、共有ライブラリのバージョンが変化し、 そのライブラリを利用している ports が新しいライブラリを用いるために 再構築する必要がある場合です。 システムが常時稼動しているならば、 /etc/periodic.conf に weekly_status_pkg_enable="YES" を 設定して、&man.periodic.8 システムによって毎週更新が必要な ports の一覧を生成できます。 カーネルコンフィグレーション 訳: &a.jp.kiroh;、 1997 年 11 月 10 日 カーネルをカスタマイズしたいんですが、難しいですか? 全然難しくありません。 カーネルの再構築を調べてください。 うまく動作するカーネルができたら、 日付入りのカーネルのスナップショットを kernel.YYMMDD のように作成することをおすすめします。 こうしておけば、次にカーネルの構築をやってうまくいかなくなってしまっても、 kernel.GENERIC にわざわざ戻る必要がなくなります。 これは、GENERIC カーネルでサポートされないデバイスから起動している場合は、 特に重要です。 _hw_float が無いので、カーネルのコンパイルがうまくいきません。 推測ですけど、数値演算コプロセッサを持ってないからと思って、 npx0 (&man.npx.4; 参照) をカーネルコンフィグファイルから削除しちゃったんじゃないですか? npx0 は必須です。 コプロセッサがなくても、npx0 デバイスは削除してはいけません。 わたしのカーネルはどうしてこんなに大きい (10MB 以上) のでしょうか? これはデバッグモードでカーネルを構築していることが原因です。 デバッグモードで構築されたカーネルは、 デバッグに用いられる膨大なシンボル情報を含んでいるため、 カーネルのサイズが非常に大きくなります。 ただし FreeBSD 3.0 とそれ以降のシステムの場合は カーネルのサイズは小さくなりますし、 デバッグカーネルを実行する時のパフォーマンスの低下もありません。 また、そのカーネルはシステムがパニックした場合に有用です。 しかし、容量の小さなディスクでシステムを運用していたり、 単にデバッグカーネルを実行したくない場合は、 以下の両方が当てはまっているかどうか確認してください。 カーネルコンフィグファイルに以下の行が書かれていないこと。 makeoptions DEBUG=-g config を実行する際、 オプションを付けていないこと。 上に書かれた指定は両方ともカーネルをデバッグモードで構築するためのものです。 上の手順を従っている限り、カーネルを普通に構築してサイズの小さなカーネルを得ることができます。 その場合のカーネルサイズは、およそ 1.5MB から 2MB 程度になります。 マルチポートシリアルのコードで割り込みが衝突しています。 Q. マルチポートシリアルを サポートするコードを含んだカーネルをコンパイルしようとすると、 最初のポートだけ検出され、 残りのポートは割り込みの競合のためスキップされたと言われます。 どうやったらいいでしょうか? A. ここでの問題は、FreeBSD にはハードウェアまたはソフトウェアの競合により、 カーネルがクラッシュするのを防ぐコードが含まれているという点です。 解決するには、最初のポートにだけ IRQ の設定を書き、 残りは IRQ の設定を削除します。 以下に例を示します。 # Multiport high-speed serial line - 16550 UARTS # device sio2 at isa? port 0x2a0 tty irq 5 flags 0x501 vector siointr device sio3 at isa? port 0x2a8 tty flags 0x501 vector siointr device sio4 at isa? port 0x2b0 tty flags 0x501 vector siointr device sio5 at isa? port 0x2b8 tty flags 0x501 vector siointr カーネルを構築にいつも失敗します。 GENERIC カーネルも構築できません。 さまざまな理由が考えられます。以下、順に列記します。 あなたは新しい make buildkernel や make installkernel ターゲットを使わず、 現在走っているシステムを構築した時と異なるソースツリーを 構築しようとしている (たとえば、4.0-RELEASE のシステム上で 4.3-RELEASE を構築しようとしている) のではないでしょうか? もしシステムをアップグレードしようとしているのなら、 /usr/src/UPDATING ファイルを 共通項目 (COMMON ITEMS) 節に注意しながら最後までお読みください。 あなたは新しい make buildkernel や make installkernel ターゲットを 使っているのにも関わらず、 make buildworld を行なっていないのではないでしょうか? make buildkernel ターゲットは、 make buildworld ターゲットによって作られるファイルに依存しています そのため、make buildkernel が正常に終了するためには make buildworld ターゲットが正常に完了している必要があります。 構築しようとしているのが FreeBSD-STABLE だったとしても、あなたが入手したソースツリーが何らかの理由で 書き換わったり、壊れてしまっているのかも知れません。 FreeBSD-STABLE はほとんどの場合、きちんと構築できるようになっていますが、 確実に構築可能であることが保証されているのは リリース版だけです。一度ソースツリーを再取得して、 問題が解決しないかどうか試してみてください。 また、あるサーバから取得した時に問題が発生したら、 別のサーバを試すのも効果があるかも知れません。 システム管理 訳: にしか nishika@cheerful.com、 1997 年 11 月 12 日 システムスタートアップファイルはどこにあるのですか? FreeBSD 2.0.5R から 2.2.1R までは、 プライマリコンフィグレーションファイルは /etc/sysconfig にあります。 オプションはすべてこのファイルで設定され、他の /etc/rc (&man.rc.8; 参照) および /etc/netstart といった ファイルはこれを読み込むだけです。 ファイル /etc/sysconfig を見て、システムに適合するように変更してください。 このファイルには、 それぞれの場所に何を書けばいいのかを表すコメントがたくさん書かれています。 FreeBSD 2.2.2 から 3.0 までのシステムでは、 /etc/sysconfig は、 より分りやすい名前の &man.rc.conf.5; に改名され、それに従って書式もいくぶん改められています。 /etc/netstart も /etc/rc.network に改名され、 全部のファイルを cp /usr/src/etc/rc* /etc で一度にコピーすることが出来るようになります。 FreeBSD 3.1 とそれ以降では、 /etc/rc.conf が /etc/defaults/rc.conf に移動しました。 このファイルを編集してはいけません! 代わりに、 /etc/defaults/rc.conf の中で変えたいエントリの行を /etc/rc.conf にコピーし、 そこで変更するようにしてください。 たとえば named を起動したいとしましょう。 FreeBSD 3.1 かそれ以降のシステムで FreeBSD 付属の DNS サーバを起動するには、次のようにするだけです。 &prompt.root; echo named_enable="YES" >> /etc/rc.conf FreeBSD 3.1 かそれ以降でローカルサービスを起動するためには、 /usr/local/etc/rc.d ディレクトリにシェルスクリプトを置きます。 シェルスクリプトは起動可能に設定し、ファイル名が .sh で終わっていなければなりません。 FreeBSD 3.0 とそれ以前のリリースでは、 /etc/rc.local を編集する必要があります。 ファイル /etc/rc.serial はシリアルポートの初期化 (たとえばポートの設定を固定したり等々) のためにあります。 ファイル /etc/rc.i386 は iBCS2 エミュレーションのような Intel アーキテクチャ固有の設定や、 PC システムコンソール設定のためにあります。 簡単にユーザを追加するにはどうすればいいのですか? &man.adduser.8; コマンドを使用してください。 また、&man.pw.8; コマンドを用いることで、さらに細かい操作が可能です。 ユーザを削除するには &man.rmuser.8; コマンドを使用してください。 繰り返しになりますが、pw でも構いません。 FreeBSD システムに新しいハードディスクを追加するには? www.FreeBSD.org に書かれているディスクフォーマットチュートリアルを参照してください。 新しいリムーバブルドライブを持っていますが、どうやって使うの? そのリムーバブルドライブが ZIP であれ EZ drive であれ (あるいはもしそういう風に使いたいのなら、フロッピーであれ)、 またハードディスクであれ、一旦システムにインストールされて認識され、 カートリッジ、フロッピー等々が挿入されていれば、 ことはどのデバイスでも全く同じように進みます。 (このセクションはMark Mayo's ZIP FAQ に基づいています) ZIP ドライブやフロッピーで、すでに DOS のファイルシステムで フォーマットしてある場合、次のコマンドを使うことができます。 これはフロッピーの場合です。 &prompt.root; mount -t msdos /dev/fd0c /floppy 出荷時の設定の ZIP ディスクではこうです。 &prompt.root; mount -t msdos /dev/da2s4 /zip その他のディスクに関しては、&man.fdisk.8; や /stand/sysinstall を使って、 どのようにレイアウトされているか確かめてください。 以降は ZIP ドライブが 3 番目の SCSI ディスクで、 da2 と認識されている場合の例です。 他人と共有しなければならないフロッピーやリムーバブルディスク でなければ、BSD ファイルシステムを載せてしまうのが良い考えでしょう。 ロングファイル名もサポートされ、パフォーマンスは少なくとも 2 倍は向上しますし、おまけにずっと安定しています。 まず最初に、DOS レベルでのパーティション / ファイルシステムを無効にしておく必要があります。使用するのは fdisk でも /stand/sysinstall でも結構です。 複数のオペレーティングシステムを入れることを考慮する 必要がないような容量の小さなドライブの場合は、 次のように FAT パーティションテーブル (スライス) 全体を飛ばして、BSD のパーティション設定を行うだけで良いでしょう。 &prompt.root; dd if=/dev/zero of=/dev/rda2 count=2 &prompt.root; disklabel -Brw da2 auto 複数の BSD パーティションをつくる場合、 disklabel か /stand/sysinstall を使います。 固定ディスク上にスワップ領域を加える場合、 そういうことをしたいと思うのはもっともですが、 ZIP のようなリムーバブルドライブの上ではそういう考えは不適切 でしょう。 最後に、新しいファイルシステムをつくります。ディスク全体を使用する ZIP ドライブの場合は、以下のようにします。 &prompt.root; newfs /dev/rda2c 次にマウントします。 &prompt.root; mount /dev/da2c /zip また、次のような行を /etc/fstab (&man.fstab.5; 参照) に入れておくのも良い考えでしょう。 mount /zip と入力するだけでマウントできるようになります。 /dev/da2c /zip ffs rw,noauto 0 0 自分の crontab ファイルを編集した後 root: not found のようなメッセージが延々と表示されるのですが、 これはなぜですか? これは通常、システム crontab (/etc/crontab) を編集し、&man.crontab.1; を使ってインストールした場合に起こります。 &prompt.root; crontab /etc/crontab この方法は正しくありません。 システム crontab のフォーマットは &man.crontab.1; が更新する各ユーザの crontab とは異なります (フォーマットの相違点の詳細は &man.crontab.5; で説明されています)。 もしこのような操作をしてしまったなら、 あらたな crontab は誤ったフォーマットの /etc/crontab のコピーになってしまっているからです。 以下のコマンドで削除してください。 &prompt.root; crontab -r 今度 /etc/crontab を編集する時は、 その変更を &man.cron.8; に伝えるような操作をしてはいけません。 &man.cron.8; は、自動的にその変更を認識するからです。 もしあなたが何かを一日一回、あるいは一週間や一ヶ月に一回だけ 実行させたいなら、シェルスクリプトを /usr/local/etc/periodic に追加し、 &man.periodic.8; コマンドにシステムの cron スケジュールから 他の定期的なシステムのタスクとともに 実行させたほうが良いかもしれません。 このエラーの実際の原因は、システム crontab には どのユーザ権限でコマンドを実行するかを指定する余分なフィールドがあることによるものです。 FreeBSD に添付されている標準のシステム crontab には、 すべてのエントリに root が書かれています。 この crontab が root ユーザの crontab (システム crontab とは 異なります) として使われた場合、&man.cron.8; は root を実行するコマンドの最初の単語だと認識しますが、 そのようなコマンドは存在しないのです。 &man.su.1; コマンドを実行して root になろうとすると、 su が you are not in the correct group to su root と警告します。 これは、セキュリティ上の機能です。su コマンドを実行して root (またはスーパーユーザ権限を持つ 他のアカウント) になるには、wheel グループに所属していなければなりません。この機能がないと、 システムにアカウントがあって root の パスワードを見つけさえすれば、誰でもスーパーユーザ権限で システムにアクセスできてしまいます。この機能がある場合は、 必ずしもそうはなりません。wheel グループに 所属していなければ、&man.su.1; がパスワードの入力すら 拒否するからです。 誰かが root に su できるように するには、その人を wheel グループに追加してください。 rc.conf やその他の スタートアップファイルを書き間違えてしまいました。 しかもそのためファイルシステムがリードオンリーになってしまっていて 編集ができません。どうすればいいですか? シェルのパス名を入力するプロンプトが表示されたときに、 単に ENTER を押し、mount / を 実行してそルートファイルシステムを再マウントさせます。 また、お気に入りのエディタがあるファイルシステムを マウントするために mount -a -t ufs を する必要があるかも知れません。あなたのお気に入りのエディタが ネットワークファイルシステム上にある場合は、 ネットワークファイルシステムをマウントする前にネットワークを 手動で設定するか、&man.ed.1; のようなローカルファイルシステムにある エディタを使うかしなければなりません。 &man.vi.1; や &man.emacs.1; の様なフルスクリーンエディタを 使うつもりなら export TERM=cons25 と やってエディタが &man.termcap.5; データベースから正しい データを読み取れるようにしなければなりません。 これを行ったあとはいつもと同様、 /etc/rc.conf を編集して間違いを訂正することができるようになります。 カーネル起動メッセージの直後に表示されたエラーメッセージには、 問題の起こったファイル内での行番号を表示されているはずです。 どのようにしたら DOS の拡張パーティションをマウントできますか? DOS 拡張パーティションは、 すべての基本パーティションの後に認識されます。 たとえば、2台目の SCSIドライブの拡張パーティションに E パーティションがあるとしますと、 これは /dev に「スライス 5 」のスペシャルファイルを作る必要があり、 /dev/da1s5 としてマウントされます。 &prompt.root; cd /dev &prompt.root; ./MAKEDEV da1s5 &prompt.root; mount -t msdos /dev/da1s5 /dos/e 他のシステムのファイルシステムを FreeBSD でマウントすることはできますか? Digital UNIX: UFS CDROM は直接 FreeBSD でマウントすることができます。 Digital UNIX やそれ以外のシステムのサポートする UFS のディスクパーティションをマウントすることはもっと複雑なことで、 オペレーティングシステムのディスクパーティションの詳細に依存します。 Linux: 2.2 以降は ext2fs パーティションをサポートします。 マニュアルの &man.mount.ext2fs.8; を見てください。より多くの情報があります。 NT: FreeBSD 用の読みだしのみ可能な NTFS ドライバがあります。 詳しくは、Mark Ovens 氏によって書かれたチュートリアル http://ukug.uk.freebsd.org/~mark/ntfs_install.html をご覧ください。 この問題について他の情報があれば、他の人から感謝されるでしょう。 どのようにしたら FreeBSD を NT ローダーから起動させることができますか? この手順は 2.2.x と (起動が 3 つのステージに分かれている) 3.x のシステムとで多少異なります。 FreeBSD のネイティブルートパーティションの最初のセクタをファイルにして DOS/NT パーティション上に置くという画期的なアイディアがあります。 ファイル名を c:\bootsect.bsd (c:\bootsect.dos からの発想です) としたとします。 c:\boot.iniファイルを次のように編集します。 [boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS [operating systems] multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows NT" C:\BOOTSECT.BSD="FreeBSD" C:\="DOS" この手順は、利用しているシステムが 2.2.x であり、DOS、NT、FreeBSD あるいはその他のオペレーティングシステムがすべて、 同じディスクのそれぞれの fdisk パーティションにインストールされていることを想定しています。 この例は、DOS と NT を最初の fdisk パーティションにおき、 FreeBSD は 2 番目においたシステムで確認しています。 また、FreeBSD は MBR を使わずに、 ネイティブパーティションから起動するように設定してあります (訳注: FreeBSD のインストールで、ブートマネジャを使わずに標準 MBR を使う場合に相当します)。 (もし NTFS に変換してしまっているなら)DOS フォーマットのフロッピーディスクか FAT パーティションを /mnt に DOS マウントします。 &prompt.root; dd if=/dev/rda0a of=/mnt/bootsect.bsd bs=512 count=1 再起動してして DOS か NT に切替えます。NTFS ユーザは bootsect.bsd や bootsect.lnx をフロッピーディスクから C:\ へコピーします。 boot.ini のファイル属性 (パーミッション) の変更を以下のように行ないます。 > attrib -s -r c:\boot.ini 上の例の boot.ini で示したような正しいエントリを加え、 ファイル属性を元に戻します。 > attrib +s +r c:\boot.ini FreeBSD が MBR から起動するようになっている場合、 それぞれのネイティブパーティションから起動するように設定した後で、 DOS から fdisk コマンドを実行して元に戻してください。 FreeBSD 3.X における手順は、これよりいくぶん簡単です。 FreeBSD が NT 起動パーティションとして同じディスクにインストールされている場合には、 /boot/boot1 を単純に C:\BOOTSECT.BSD へコピーします。 もし FreeBSD が異なったディスクにインストールされている場合には、 /boot/boot1 では動作しませんので、 /boot/boot0 が必要です。 ここで /boot/boot1 の代わりに /boot/boot0 をコピーするようなことをしてはいけません! そうすると、パーティションテーブルを上書きしてしまい、 コンピュータが起動できなくなってしまいます。 /boot/boot0 をインストールするには、 sysinstall のブートマネージャを利用するかどうか尋ねられる画面で FreeBSD ブートマネージャを選択する必要があります。 /boot/boot0 のパーティションテーブル部分は NULL 文字で埋められているのですが、 sysinstall は /boot/boot0 を MBR にコピーする前にパーティションテーブルをきちんとコピーしてくれるからです。 FreeBSD ブートマネージャは最後に起動した OS を記録するために パーティションテーブルの最後に起動した OS のエントリにあるアクティブフラグをセットし、512 バイト全体を MBR に書き戻します。 これは /boot/boot0 を C:\BOOTSECT.BSD にコピーし、 エントリの一つにアクティブフラグをセットして空のパーティションテーブルを MBR に書き込むことと同じです。 FreeBSD と Linux を LILO から起動するには? FreeBSD と Linux が同じディスクにインストールされている場合、 単に Linux 以外の OS を起動するための LILO のインストール手順に 従えばいいだけです。非常に簡単にではありますが、記してみましょう。 Linux を起動し、/etc/lilo.conf に以下の行を加えて ください。 other=/dev/hda2 table=/dev/hda label=FreeBSD (上記の手順は FreeBSD のスライスが Linux から /dev/hda2 という名前で見えていると仮定しています。 あなたの設定にあわせてください) その後、lilo を root で実行すれば完了です。 FreeBSD が別のディスクにインストールされているのなら、 LILO のエントリに loader=/boot/chain.b を追加してください。たとえば、このようになります。 other=/dev/dab4 table=/dev/dab loader=/boot/chain.b label=FreeBSD 場合によっては、二つ目のディスクを正しく起動するために FreeBSD ブートローダに BIOS ドライブ番号を指定する必要があるかもしれません。 たとえば、FreeBSD SCSI ディスクが BIOS によって BIOS ディスク 1 として認識されるのなら、 FreeBSD のブートローダのプロンプトで、次のように指定する必要があります。 Boot: 1:da(0,a)/kernel FreeBSD 2.2.5 やそれ以降の版では、&man.boot.8; を設定すれば 起動時に上記のことが自動的に行えます。 Linux+FreeBSD mini-HOWTO が FreeBSD と Linux とを相互に使えるようにするためのよい参考資料になるでしょう。 FreeBSD と Linux を BootEasy から起動するには? LILO をマスターブートレコード (MBR) ではなく Linux の起動パーティションにインストールしてください。 これで BootEasy から LILO を起動できるようになります。 Windows95 と Linux を使用している場合は、 いずれにせよ後者の方がおすすめです。 Windows95 を再インストールする必要にかられたとき、 Linux を起動可能に戻す手続きが簡単ですむからです (Windows95 は偏屈なオペレーティングシステムで、 マスターブートレコード (MBR) から他のオペレーティングシステムを追い払ってしまうのです)。 「危険覚悟の専用 (dangerously dedicated) ディスク」は健康に悪いの? インストール作業中、 ハードディスクのパーティションを切る際に 2 つの方法を選ぶことができます。 デフォルトの方法では、fdisk のテーブルエントリ (FreeBSD ではスライスと呼ばれる) を使って、 自身のパーティションを使用する FreeBSD のスライスを、 同じマシンの他のオペレーティングシステムと互換性のある形にします。 それに付随して、ブートセレクタをインストールすれば、 ディスク上の使用可能なオペレーティングシステムを切り替えることができます。 もう一つの方法はディスクすべてを FreeBSD で使うというもので、 この場合ほかのオペレーティングシステムとの互換性を考慮しないことになります。 では、なぜこれが 「危険覚悟の」と言われるのでしょう? このモードのディスクが、通常の PC のユーティリティが有効な fdisk テーブルと見なす情報を持っていないからです。 ユーティリティの出来如何によりますが、 そのようなディスクを発見したとき、 警告を出すものもあります。また、もっと悪い場合、 確認も通告もなしに BSD のブートストラップにダメージを与えるものもあるでしょう。 さらには、「危険覚悟の」ディスクレイアウトは多数の BIOS、 AWARD (たとえば HP Netserver や Micronics システム、 他多数で使用されていた) や Symbios/NCR (人気のあるSCSI コントローラ 53C8xx 用) などを混乱させることが分かっています。 これは完全なリストではありません。 他にもまだまだあります。この混乱の兆候は、 起動時にシステムがロックするというだけでなく、 FreeBSD のブートストラップが自分自身を見つけられないために表示する read error というメッセージなどにも現れることでしょう。 そもそもいったいなぜこのモードがあるのでしょうか? これはわずかに数キロバイトのディスク容量を節約するのみであり、 新規インストールで実際に問題を生ずるのです。 「危険覚悟の」モードの起源は新しい FreeBSD インストーラでの、 BIOS から見えるディスクの 「ジオメトリ」の値とディスク自身との整合性という、 もっとも一般的な問題のひとつを回避したいという要求が背景にあります。 「ジオメトリ」は時代遅れの概念ですが、 未だに PC BIOS とディスクへの相互作用の中核をなしています。 FreeBSD のインストーラがスライスを作る時、 ディスク上のスライスを BIOS が見つけられるように、 スライス位置をディスク上に記録します。それが誤っていれば、 起動できなくなってしまうでしょう。 「危険覚悟の」モードはこれを、 問題を単純にすることで回避しようとします。 状況によってはこれでうまくいきます。 しかし次善の策として使われているに過ぎません。 この問題を解決するもっと良い方法はいくらでもあるのです。 では、 インストール時に「危険覚悟の専用」モードが必要になる 状況を回避するにはどうすればよいのでしょうか? まず BIOS が報告するディスクのジオメトリの値を覚えておくことからはじめましょう。 boot: プロンプトで を指定するか、ローダで boot -v と指定して、 起動時にカーネルにこの値を表示させることができます。 インストーラが起動する直前に、 カーネルがジオメトリ値のリストを表示するでしょう。 パニックを起こさないでください。 インストーラが起動するのを待ち、 逆スクロールでさかのぼって値を確認してください。 普通は BIOS ディスクユニット番号は、 FreeBSD がディスクを検出する順序と同様であり、 最初に IDE、次に SCSI となります。 ディスクをスライシングする際に、 FDISK の画面で表示されるディスクのジオメトリが正しいこと (BIOS の返す値と一致しているか) を確認してください。 万一異なっていたら g を押して修正してください。 ディスクにまったくなにもない場合や、 他のシステムから持ってきたディスクの場合は これを行なう必要があるかもしれません。 これはそのディスクから起動させようとしている場合にのみ、 問題になることに注意してください。 FreeBSD はそのディスクをうまい具合いに他のディスクと区別してくれます。 ディスクのジオメトリについて BIOS と FreeBSD 間で一致させることができたら、この問題はほぼ解決したと思ってよいでしょう。 そしてもはや「危険覚悟の専用」モードは必要ありません。 しかし、まだ起動時に恐怖の read error メッセージが出るようであれば、 お祈りを捧げて新しいディスクを買いましょう。 もう失うものは何もありません。 「危険覚悟の専用ディスク」を通常の PC での使用法に戻すには、 原則として 2 つ方法があります。1 つは十分な NULL バイトを MBR に書き込んで、 きたるべきインストーラにディスクはまっさらだと思い込ませる方法です。 たとえば、こんな感じです。 &prompt.root; dd if=/dev/zero of=/dev/rda0 count=15 また、マニュアルには書かれていない DOS の「機能」 > fdisk /mbr は、BSD ブートストラップを追い払ってくれる上に、 新しいマスターブートレコードをインストールしてくれます。 どのようにしたらスワップ領域を増やせますか? スワップパーティションのサイズを増やすのが最良の方法ですが、 別のディスクを追加しなくて済むという利点のある方法があります。 経験から得た一般的な方法はメインメモリの 2倍程度のスワップ領域を とるというものです。しかしごく小さなメインメモリしかない場合は、 それ以上のスワップを構成したいと思うでしょう。また、将来のメモリの アップグレードに備え、後でスワップの構成を変更する必要がないように 十分なスワップを構成しておくことは良い考えです。 スワップを別のディスク上に追加することは、単純に同じディスク上 にスワップを追加する場合よりも高速に動作するようになります。 例に挙げれば、あるディスク上のソースをコンパイルしているとして、 スワップが別のディスク上に作られていれば、これらが同じディスク上 にある場合よりも断然速いです。SCSI ディスクの場合は特にそうだと言えます。 ディスクが複数ある場合、スワップパーティションを各ディスクに 作るように構成すると、使用中のディスク上にスワップを置いたとしても、 通常の場合は有益です。一般的に、システムにある高速なディスクには スワップを作るようにすべきでしょう。 FreeBSD はデフォルトでインターリーブなスワップデバイスを 4つまで サポートします。複数のスワップパーティションを構成する際に、 普通はそれらを大体同じくらいの大きさにして作りたいところですが、 カーネルのコアダンプを取るのに都合が良いようにメインの スワップパーティションを大きめにとる人もいます。 メインのスワップパーティションはカーネルのコアがとれるように 最低でも実メモリと同じ大きさにすべきでしょう。 IDE ドライブは同時に同じチャネル上の複数のドライブには アクセスできません (FreeBSD は mode 4 をサポートしていないので、 すべての IDE ディスク I/O は programmed です)。 IDE の場合であってもやはり、スワップを別のハードディスク上に 作成することをおすすめします。 ドライブは実に安いものです、心配するだけ無駄です。 NFS 越しにスワッピングさせる方法は、 スワップ用のローカルディスクが無い場合にのみ推奨されます。 NFS 越しのスワッピングは遅く、FreeBSD 4.x より前のリリースでは 効率が悪いのですが、4.0 以降ではそれなりに高速になります。 そうはいっても、利用できるネットワークの太さに制限されますし、 NFS サーバに余計な負荷がかかります。 これは 64MBの vn-swap を作る例です (ここでは /usr/swap0 としますが、もちろん好きな名前を使うことができます)。 カーネルが次の行を含むコンフィグファイルから構成されているかを 確認します。GENERIC カーネルには、この行が含まれています。 pseudo-device vn 1 #Vnode driver (turns a file into a device) vn デバイスを作ります &prompt.root; cd /dev &prompt.root; sh ./MAKEDEV vn0 スワップファイルを作ります (/usr/swap0) &prompt.root; dd if=/dev/zero of=/usr/swap0 bs=1024k count=64 スワップファイルに適切なパーミッションを設定します &prompt.root; chmod 0600 /usr/swap0 /etc/rc.conf でスワップファイルを有効化させます swapfile="/usr/swap0" # Set to name of swapfile if aux swapfile desired. マシンを再起動します スワップファイルをすぐに有効化させたいのなら以下のようにタイプします。 &prompt.root; vnconfig -e /dev/vn0b /usr/swap0 swap プリンタのセットアップで問題があります ハンドブックのプリンタの部分を参照してください。 探している問題のほとんどが書かれているはずです。 FreeBSD ハンドブックの「プリンタの利用」をご覧ください。 プリンタによっては、印刷するのにホスト側にドライバが 必要です。これら WinPrinters と呼ばれるものは、 素の FreeBSD では使えません。DOS や Windows NT 4.0 で動作しない なら、そのプリンタはおそらく WinPrinter でしょう。 ただし、唯一の希望が残されています。 ports/print/pnm2ppa の port が 対応しているかどうか確認してみてください。 パッケージの説明にはこう書いてあります。
このソフトウェアは PPA (printer performance architecture) プロトコルの出力を行います。このプロトコル は HP の "Windows 専用" プリンタの一部に使われています。 そのなかには、HP Deskjet 820C シリーズ、HP DeskJet 720 シリーズ、および HP DeskJet 1000 シリーズがあります。(略) WWW: http://pnm2ppa.sourceforge.net/
私のシステムのキーボードマッピングは間違っています。 kbdcontrol プログラムは、 キーボードマップファイルを読み込むためのオプションを備えています。 /usr/share/syscons/keymaps の下にたくさんのマップファイルがあります。 システムに関連のあるものを一つ選んで、ロードしてください。 &prompt.root; kbdcontrol -l uk.iso /usr/share/syscons/keymaps と拡張子 .kbd は、どちらも &man.kbdcontrol.1; によって使用されます。 これは /etc/sysconfig (または &man.rc.conf.5;) 中で設定することができます。 このファイル中にあるそれぞれのコメントを参照してください。 FreeBSD 2.0.5R やそれ以降の版では、 テキストフォントやキーボードマッピングに関係のあるものはすべて、 /usr/share/examples/syscons の中におさめられています。 現在以下のマッピングがサポートされています。 Belgian ISO-8859-1 Brazilian 275 keyboard Codepage 850 Brazilian 275 keyboard ISO-8859-1 Danish Codepage 865 Danish ISO-8859-1 French ISO-8859-1 German Codepage 850 German ISO-8859-1 Italian ISO-8859-1 Japanese 106 Japanese 106x Latin American Norwegian ISO-8859-1 Polish ISO-8859-2 (programmer's) Russian Codepage 866 (alternative) Russian koi8-r (shift) Russian koi8-r Spanish ISO-8859-1 Swedish Codepage 850 Swedish ISO-8859-1 Swiss-German ISO-8859-1 United Kingdom Codepage 850 United Kingdom ISO-8859-1 United States of America ISO-8859-1 United States of America dvorak United States of America dvorakx 起動時に、unknown: <PNP0303> can't assign resources というメッセージが表示されるのですが? 以下は、freebsd-current メーリングリストへの投稿からの 抜粋です。
&a.wollman;, 2001 年 4 月 24 日 can't assign resources というメッセージは、 そのデバイスがレガシー ISA デバイスで、PnP を意識していない ドライバがカーネルに組み込まれていることを示します。 これには、キーボードコントローラ、プログラム可能な 割り込み制御 IC やその他さまざまな標準的なデバイスが あります。リソースが割り当てられないのは、既にそのアドレスを 使っているドライバがあるからです。
ユーザディスククォータが正常に動作していないようです。 / にはディスククォータを設定しないでください。 クォータファイルが置かれるファイルシステム上に クォータファイルを置くようにしてください。 Filesystem Quota file /usr /usr/admin/quotas /home /home/admin/quotas … … わたしの ccd は、 何が適合していない (Inappropriate) のでしょう? 次のような症状が現れます。 &prompt.root; ccdconfig -C ccdconfig: ioctl (CCDIOCSET): /dev/ccd0c: Inappropriate file type or format 通常この現象はタイプを「未使用 (unused)」のまま放っておかれた c パーティションをつなげようとした場合に現れます。ccd ドライバは FS_BSDFFS タイプをベースとするパーティションを要求します。 つなげようとしているディスクのディスクラベルを編集して、 パーティションのタイプを 4.2BSD に変更してください。 どうしてわたしの ccd のディスクラベルを変更することができないのでしょう? 次のような症状が現れます。 &prompt.root; disklabel ccd0 (it prints something sensible here, so let's try to edit it) &prompt.root; disklabel -e ccd0 (edit, save, quit) disklabel: ioctl DIOCWDINFO: No disk label on disk; use "disklabel -r" to install initial label これは ccd から返されるディスクラベルが、 実はディスク上にはないまったくの偽の情報だからです。 これを明示的に書き直すことで問題を解消できます、 それには、つぎのようにします。 &prompt.root; disklabel ccd0 > /tmp/disklabel.tmp &prompt.root; disklabel -Rr ccd0 /tmp/disklabel.tmp &prompt.root; disklabel -e ccd0 (this will work now) FreeBSD は System V の IPC プリミティブをサポートしますか? はい。 FreeBSD は System-V スタイルの IPC をサポートします。 共有メモリ、メッセージ、セマフォが含まれます。 以下の行をカーネルコンフィグファイルに加えると、 サポートが有効になります。 options SYSVSHM # enable shared memory options SYSVSEM # enable for semaphores options SYSVMSG # enable for messaging FreeBSD 3.2 とそれ以降では、 これらのオプションがあらかじめ GENERIC カーネルに含まれていますので、 あなたのシステムにはすでに組み込まれています。 カーネルを再構築してインストールしてください。 UUCP でメールを配送するには sendmail をどう使えばよいのですか? FreeBSD に付属している sendmail は、 インターネットに直接つながっているサイトにあわせて設定してあります。 UUCP 経由で mail を交換したい場合には sendmail の設定ファイルを改めてインストールしなければなりません。 /etc/sendmail.cf を自分の手で改造するのは純粋主義者のやるような事です。 sendmail の version 8 は &man.m4.1; のようなプリプロセッサを通して設定ファイルを生成する新しいアプローチを取っており、 より抽象化されたレベルの設定ファイルを編集します。 /usr/src/usr.sbin/sendmail/cf ディレクトリの中にある設定ファイルを使用してください。 もしすべてのソースをインストールしていない場合には sendmail の設定ツールは、別の tar ファイルにまとめてあります。CD-ROM が mount されている場合には、次のようにしてください。 &prompt.root; cd /cdrom/src &prompt.root; cat scontrib.?? | tar xzf - -C /usr/src contrib/sendmail これはたった数 100Kbyte ですから心配ないでしょう。 cf ディレクトリにある README に、m4 での設定の基本的な説明があります。 UUCP での配送のためには、mailertable を使用すれば よいでしょう。これによって、sendmail が配送方式を決定するデータベースを 作成することができます。 まずはじめに、 .mc ファイルを作成しなければなりません。 /usr/src/usr.sbin/sendmail/cf/cf というディレクトリが、 これらのファイルを作成する場所です。既にいくつか例があると思います。 これから作成するファイルの名前を foo.mc とすると、 sendmail.cf を求めているような形式に変換するには、 次のようにしてください。 &prompt.root; cd /usr/src/usr.sbin/sendmail/cf/cf &prompt.root; make foo.cf &prompt.root; cp foo.cf /etc/sendmail.cf 標準的な .mc ファイルは次のようになります。 include(`../m4/cf.m4') VERSIONID(`Your version number') OSTYPE(bsd4.4) FEATURE(nodns) FEATURE(nocanonify) FEATURE(mailertable) define(`UUCP_RELAY', your.uucp.relay) define(`UUCP_MAX_SIZE', 200000) MAILER(local) MAILER(smtp) MAILER(uucp) Cw your.alias.host.name Cw youruucpnodename.UUCP nodns と nocanonify という指定をすることで、 mail の配送に DNS を使用しなくなります。 UUCP_RELAY という 行に関しては、 ある理由から必要ですがそれは聞かないでください。 .UUCP で終わる仮想ドメインを処理することのできるインターネット上での ホスト名をここに書いてください。通常は、ISP の mail リレーホストを 書くことになると思います。 これが終了したら、次に /etc/mailertable というファイルが必要です。標準的な例は次のとおりです。 # # makemap hash /etc/mailertable.db < /etc/mailertable # horus.interface-business.de uucp-dom:horus .interface-business.de uucp-dom:if-bus interface-business.de uucp-dom:if-bus .heep.sax.de smtp8:%1 horus.UUCP uucp-dom:horus if-bus.UUCP uucp-dom:if-bus . uucp-dom: 見れば分かるように、これは実在する設定のファイルです。はじめの 3 行はドメイン名で指定されたメールが default の経路で配送されずに、 「近道」するために UUCP で隣りのサイトに送るための特別な状況を 処理するものです。 次の行は Ethernet でつながっているローカルのドメインに対しては SMTP で送るための設定です。 最後に、UUCP での隣りのサイトが .UUCP で終わる仮想ドメインの書式で 指定されており、default の rule を uucp-neighbour! recipient で上書きするためのものです。一番最後の行はいつもドットを一つ書きます。 これは、ここまでの行でマッチしなかったすべてのホストにマッチし、 このサイトから世界に向けて出ていくための mail gateway に UUCP で配送するためのものです。 uucp-dom: に続けて書かれているノード名は、 uuname コマンドで指定することによって UUCP で直接配送される正しいノード名でなければなりません。 最後に、このファイルは使用する前に DBM データベースのファイルに 変換する必要があります。これを行なうコマンドラインは mailertable の最初のコメントに書いてあります。mailertable を変更した時には、 必ずこのコマンドを実行してください。 最後のヒントです: もし特定のメール配送がうまく作動するかどうか 確かめたい場合には、sendmail の オプションを 使用してください。このオプションによって sendmail は アドレステストモードで起動します。 0 の後に配送したいアドレスを書いてください。最後の行に、実際に使用される mail agent、この mail agent で送られる送信先のホスト、そして (多分変換されている) アドレスが表示されます。このモードを抜けるには Control-D を押してください。 &prompt.user; sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > 0 foo@interface-business.de rewrite: ruleset 0 input: foo @ interface-business . de ... rewrite: ruleset 0 returns: $# uucp-dom $@ if-bus $: foo \ < @ interface-business . de > > ^D ダイアルアップでインターネットに接続する環境でメールをセットアップするにはどうやるの? 静的に IP アドレスが割り当てられる場合は、 デフォルトの状態を変更する必要はありません。 割り当てられた名前をホストネームと するだけで、sendmail が後のことを引き受けてくれます。 ダイアルアップ ppp をインターネット接続に使用し、動的に IP アドレスが割り当てられる場合は、 インターネットサービスプロバイダ (ISP) のメールサーバにメールボックスがあるはずです。 ISP のドメインが myISP.com で、あなたのユーザ名が user だと仮定します。 また、あなたが自分のマシンを bsd.home と呼んでおり、ISP が relay.myISP.com をメールリレーとして使用できると言っているとしましょう。 メールボックスからメールを取ってくるためには、 回収 (retrieval) エージェントをインストールする必要があります。 Fetchmail は多種多様なプロトコルをサポートしているのでお勧めです。 ISP が使用しているのは、大抵 POP3 プロトコルです。 ユーザ ppp を使用している場合、 /etc/ppp/ppp.linkup に以下のように記述すると、 インターネットと接続が完了した時点で自動的にメールを取得するようになります。 MYADDR: !bg su user -c fetchmail ローカルでないアカウントにメールを配送するのに sendmail を使用している場合 (後述)、 上に示したエントリの後に !bg su user -c "sendmail -q" を記述します。これはネットワーク接続が確立したらすぐに sendmail に溜っている mailqueue を強制的に処理させるようにします。 この例では、user が bsd.home にアカウントを持ち、 bsd.home 上の user のホームディレクトリに、以下のような .fetchmailrc ファイルがつくられていることを想定しています。 poll myISP.com protocol pop3 fetchall pass MySecret; 言うまでもなく、このファイルは user 以外のユーザが読むことが出来ないようにしなくてはなりません。 内容にパスワード MySecret が含まれているからです。 正しい from: ヘッダをつけてメールを送るためには、 sendmail に user@bsd.home ではなく user@myISP.com を使用するよう教える必要があります。 メールをより早く転送するために、すべてのメールを relay.myISP.com へ送るように sendmail に 指示しておくのも良いでしょう。 上の要件を満たすには、以下のような .mc ファイルが適しています。 VERSIONID(`bsd.home.mc version 1.0') OSTYPE(bsd4.4)dnl FEATURE(nouucp)dnl MAILER(local)dnl MAILER(smtp)dnl Cwlocalhost Cwbsd.home MASQUERADE_AS(`myISP.com')dnl FEATURE(allmasquerade)dnl FEATURE(masquerade_envelope)dnl FEATURE(nocanonify)dnl FEATURE(nodns)dnl define(`SMART_HOST', `relay.myISP.com') Dmbsd.home define(`confDOMAIN_NAME',`bsd.home')dnl define(`confDELIVERY_MODE', `deferred')dnl .mc ファイルから sendmail.cf への変換方法については、 前のセクションを参照してください. sendmail.cf を更新した後に sendmail をリスタートするのもお忘れなく。 この UID が 0 の toor という アカウントとは何ですか? 危険にさらされているのでしょうか? 心配無用です。toor は 代替の スーパーユーザーアカウントです (toor は root を逆に綴ったものです)。 以前は、&man.bash.1; シェルがインストールされた時に 作成されていましたが、現在は標準で作成されています。 このユーザーが作成されるのは、 スーパーユーザが非標準のシェルを使う場合を想定しており、 root の標準のシェルを変更しなくてもよくなっています。 基本配布に含まれていないシェル (たとえば ports や packages からインストールされるシェル) は、デフォルトでは別のファイルシステムに存在する 可能性のある /usr/local/bin に インストールされることが多いので、これは重要です。 root のシェルが /usr/local/bin にあり、 /usr (または、/usr/local/bin があるいずれかのファイルシステム) が何らかの理由でマウントされていないとすると、 root は問題を解決するために ログインすることができません (シングルユーザーモードで再起動すれば、 シェルのパスの入力を促されるのですが)。 toor を日々の root の仕事を 非標準のシェルで行うために使い、root は シングルユーザーモードや緊急時のために、標準のシェルのままに している人がいます。何もしなければ、パスワードを無効にしてあるので toor ではログインできません。 使いたいなら、root でログインして toor の パスワードを設定しましょう。 しまった! root のパスワードを忘れてしまった! 慌てないでください! 単にシステムを再起動し、 シングルユーザモードに移るために Boot: と表示されるプロンプトで boot -s と入力してください (FreeBSD の 3.2 より前のリリースでは -sとなります)。 どのシェルを使うのかという質問には、ENTER キーを押してください。&prompt.root; に移ることができるでしょう。 mount -u / と入力して ルートファイルシステムの読み書きを再マウントし、 mount -a と入力して、 すべてのファイルシステムをマウントし直した後、 passwd root と入力して root のパスワードを設定し直してください。 その後、exit と入力すれば、起動が続けられます。 Control-Alt-Delete でシステムが再起動しないようにするにはどうすればいい? FreeBSD 2.2.7-RELEASE 以降で syscons (デフォルトのコンソールドライバ) を使用している場合には、次の行をカーネルコンフィグレーションファイルに追加して カーネルを再構築し、インストールしてください。 options SC_DISABLE_REBOOT FreeBSD 2.2.5-RELEASE 以降で PCVT コンソールドライバを使用している 場合には、同様に次の行をカーネルコンフィグレーションファイルに追加して カーネルを再構築し、インストールしてください。 options PCVT_CTRL_ALT_DEL 上にあげたものよりも古い FreeBSD の場合、 現在コンソールが使用しているキーマップを編集し、 キーワード boot を nop に書き換えてください。 /usr/share/syscons/keymaps/us.iso.kbd にあります。 その変更を反映させようとして、 このキーマップのロードを明示的に行なうために、 /etc/rc.conf を実行すべきかもしれません。 もちろん他の国のキーマップを使っているのであれば、 代わりにそのキーマップファイルを編集してください。 DOS のテキストファイルを UNIX のテキストファイルに整形するにはどうすればいい? 単に次の perl コマンドを実行してください。 &prompt.user; perl -i.bak -npe 's/\r\n/\n/g' file ... file の部分には処理するファイルを指定してください。 整形後のファイルは元のファイル名で作成され、 整形前のファイルはバックアップとして元の ファイル名の末尾に拡張子 .bak のつけられた名前で作成されます。 あるいは &man.tr.1; コマンドを使うこともできます。 &prompt.user; tr -d '\r' < dos-text-file > unix-file dos-text-file は DOS 形式のテストファイル、 unix-file には変換された出力が格納されます。 perl を使うよりほんのちょっぴり速くなります。 名前で指定してプロセスにシグナルを送るにはどうすればいい? &man.killall.1; を使ってください。 su が not in root's ACL と言って私を悩ませるのはなぜ? Kerberos の認証システムからくるエラーです。 この問題は致命的なものではなく、 うっとおしいといったものです。 su に オプションをつけて起動するか、 次の質問で説明されている方法で Kerberos をアンインストールしてください。 Kerberos をアンインストールするにはどうすればいいの? システムから Kerberos を削除するには、 あなたの動かしているリリースの bin ディストリビューションを再インストールしてください。 もし CDROM を持っているのなら、 その CDROM をマウント (マウントポイントは /cdrom と仮定) して、 次のように入力してください。 &prompt.root; cd /cdrom/bin &prompt.root; ./install.sh 疑似ターミナルを追加するには? telnet、ssh、X、screen をたくさん利用されている場合、 疑似ターミナルが足りなくなっている可能性があります。 これを増やすには次のようにします。 次の行をカーネルコンフィグレーションファイルに追加して pseudo-device pty 256 新たにカーネルを作りインストールします。 次のコマンドを実行して &prompt.root; cd /dev &prompt.root; ./MAKEDEV pty{1,2,3,4,5,6,7} 新たなターミナル用の 256 個のデバイスノードを作ります。 /etc/ttys を編集し 256 個のターミナルごとの定義を追加します。 既存のエントリーの形式にあわせる必要があるでしょう。 たとえばこんな感じです。 ttyqc none network 正規表現を使った指定は tty[pqrsPQRS][0-9a-v] となります。 新しいカーネルでシステムを再起動すると完了です。 snd0 デバイスを作成することができません! snd というデバイスは存在しません。 この名前は、FreeBSD サウンドドライバによって作成されるさまざまなデバイス、 mixer や sequencer、 dsp などを総称したものです。 これらのデバイスを作成するには、次のようにする必要があります。 &prompt.root; cd /dev &prompt.root; sh MAKEDEV snd0 再起動せずにもう一度 /etc/rc.conf を読み込んで /etc/rc を開始させるには? シングルユーザモードに移行して、 マルチユーザモードに戻ってください。 コンソールで次のように実行します。 &prompt.root; shutdown now(注: や は付けません) &prompt.root; return &prompt.root; exit 砂場 (sandbox) とは何ですか? 砂場 (Sandbox) とはセキュリティ用語の一つで、 次の二つの意味があります。 一つ目は、「仮想的な『防壁』で囲まれているプロセス」です。 その『防壁』は、そのプロセスに侵入した第三者が、 さらにシステムの広い範囲に影響を与えることを防ぐように設計されます。 このプロセスの振舞いは、『防壁』の中だけに制限される、と表現できます。 つまり、このプロセスにおいて、『防壁』を越えるようなコードの実行は できないという意味です。そのため、コードの実行におけるセキュリティは 確かなものであると保証でき、実行の詳細な追跡を行なう必要はなくなります。 その『防壁』とは、たとえばユーザ ID がそれにあたるでしょう。 この定義は、security(7) や named(8) のマニュアルページで用いられています。 ntalk サービス (/etc/inetd.conf 参照のこと) を例にとってみます。 このサービスはかつて、実行時の ユーザ ID として root を用いていましたが、現在では tty というユーザ ID で動作します。 ユーザ tty は、 ntalk を経由してシステムの侵入に成功した第三者が そのユーザ ID 以上の権限を得ることを、 より一層困難にするために設計された砂場 (sandbox) なのです。 二つ目は「シミュレートされたマシンの内側で実行されるプロセス」のことで、 こちらはより中核的です。 普通に考えれば、あるプロセスに侵入することができる第三者は、 マシンのより広い範囲にも侵入できると信じるものなのですが、 この種のプロセスの場合、それは実際にはシミュレートされたマシンに 侵入しただけなので、現実のデータを変更することは何一つできません。 これを実現するための最も広く用いられている方法は、 シミュレートされた環境をサブディレクトリに構築し、 そのディレクトリに chroot して、そのディレクトリで プロセスを実行すること (つまり、そのプロセスにとって / は システムの実際のルートディレクトリ / ではなく、 chroot されたサブディレクトリを指す) です。 広く用いられているもう一つの方法があります。 それは、既に存在しているファイルシステムを 読み込み専用 (read-only) でマウントし、その上に、あるプロセスに対して そのファイルシステムが書き込み可能であるように見せるような、 もう一つのファイルシステムの層を用意するものです。すると、 そのプロセスはファイルを書き込むことができると認識し、 実際に書き込むことができるのもその特定のプロセスだけ - システムにある他のプロセスは書き込めないのに対して - であるという状況を実現することができます。 この種の砂場 (sandbox) は、 その非常に透過的な性質を使って、ユーザ (もしくは侵入者) が その事実に気付かないように実現されます。 UNIX は、内部的に二つの砂場 (sandbox) を実装しています。 一つはプロセスレベルのもの、もう一つはユーザ ID レベルのものです。 UNIX プロセスはすべて、他の UNIX プロセスから完全に隔離されています。 どのプロセスも、他のプロセスのアドレス空間を変更することはできません。 これは、あるプロセスが他のプロセスのアドレス空間を上書きできるような、 クラッシュにつながる行為が容易に実現できる Windows とは全く異なるものです。 UNIX プロセスは、特定のユーザ ID が所有します。 もし、実行者のユーザ ID が root ユーザのものでなければ、 ユーザ ID は、他のユーザが所有するプロセスから そのプロセスを守る機能を果たすわけです。 また、そのユーザ ID は、ディスク上にあるデータを 保護するのにも使われています。 セキュアレベル (securelevel) って何ですか? セキュアレベルとはカーネルに実装されているセキュリティ機構の一つです。 簡単に言うと、カーネルはセキュアレベルが正の値の時に、 ある特定の操作を制限します。この制限は、たとえスーパユーザ (root のこと) であっても例外ではありません。 この文を書いている時点では、 セキュアレベル機構を使って以下のような操作を制限することができます。 schg (system immutable flag) のようなファイルフラグの変更 /dev/mem および /dev/kmem 経由でのカーネルメモリへの書き込み カーネルモジュールのロード &man.ipfirewall.4; ルールの変更 稼働中のシステムでセキュアレベルの状態をチェックするには、 次のコマンドを実行します。 &prompt.root; sysctl kern.securelevel 出力には、&man.sysctl.8; 変数 (今の場合は kern.securelevel) と数字が現れます。 数字が現在のセキュアレベルの値です。 これがもし正の値なら、 何らかのセキュアレベルによる制限が有効になっています。 システム稼働中にセキュアレベルを下げることはできません。 これは、それを可能にするとセキュアレベルの意味がなくなってしまうからです。 セキュアレベルが正の値でないことを要求する操作 (たとえば installworld や日付の変更など) を行なう必要がある場合は、/etc/rc.conf にあるセキュアレベルの設定 (kern_securelevel と kern_securelevel_enable という変数) を変更して再起動する必要があります。 セキュアレベルに関する詳しい情報や、 各レベルで実現される機能に関しては &man.init.8; のマニュアルページを参照してください。 セキュアレベルは万能というわけではなく、 弱点も数多く存在します。また、場合によっては、 セキュリティを低下させてしまうこともあります。 最も大きな問題の一つに、 セキュアレベルの機能を有効にするには、 起動処理でセキュアレベルが設定されるまでに使われるすべてのファイルを 保護する必要があるということがあります。 もし攻撃者が、システムがセキュアレベルを設定する前にコードを実行することができるとしたら、 セキュアレベルによる保護は無意味になってしまいます (起動時には低いセキュアレベルでしか実行できない処理を行なう必要があるため、 セキュアレベルの設定は、起動処理の最後の方で行なわれます)。 起動処理で使われるすべてのファイルを保護することは技術的に不可能です。 もしそうできたとしても、システムの保守はまさに悪夢となるでしょう。 設定ファイル一つ書き換えるのにも、 シングルユーザモードに切替えなければならなくなるのですから。 以上で説明した内容やその他の点については、 メーリングリストでも良く話題にのぼります。 議論のようすをこのページから検索してみてください。 セキュアレベルは、 いずれより粒度の細かい機構にとって代わるだろうと考えている人々もいますが、 その点についてはまだ不透明なままです。 どうか注意するようにしてください。 フロッピーや CDROM や他のリムーバブルメディアのマウントを一般ユーザーに許可するには? 一般ユーザーでもデバイスをマウントできるようにすることができます。 手順は次のとおりです。 root になって、 sysctl 変数である vfs.usermount を 1 に設定します。 &prompt.root; sysctl -w vfs.usermount=1 root になって、 リムーバブルメディアに関連するブロックデバイスに適切なパーミッションを設定します。 例として、最初のフロッピーデバイスをユーザーがマウントできるようにするには、 次のようにします。 &prompt.root; chmod 666 /dev/fd0 operator グループに所属するユーザが CDROM ドライブをマウントできるようにするには 以下のようにします。 &prompt.root; chgrp operator /dev/cd0c &prompt.root; chmod 640 /dev/cd0c 最後に vfs.usermount=1 という行を /etc/sysctl.conf ファイルに追加し、 ブート時にセットされるようにしておきます。 これで、すべてのユーザは フロッピー /dev/fd0 を 自身の所有するディレクトリへマウントすることができます。 &prompt.user; mkdir ~/my-mount-point &prompt.user; mount -t msdos /dev/fd0 ~/my-mount-point これで、operator グループに所属するユーザは CDROM /dev/cd0c を 自身の所有するディレクトリへマウントすることができます。 &prompt.user; mkdir ~/my-mount-point &prompt.user; mount -t msdos /dev/cd0c ~/my-mount-point デバイスのアンマウントは簡単です。 &prompt.user; umount ~/my-mount-point しかし、 vfs.usermount を有効にすることは、セキュリティ上よいことではありません。 MSDOS 形式のメディアにアクセスには、Ports コレクションにある パッケージ mtools を使用した方がよいでしょう。 システムを新しい巨大ディスクへ移すにはどうするのですか? 一番良いのは新しいディスクに OS を再インストールして、 それからユーザデータを移すことです。特にあなたが -stable を 複数のリリースを跨いで追い掛けている場合にはこの方法をおすすめします。 あなたは &man.boot0cfg.8; を使うことで booteasy を両方の ディスクにインストールでき、新しい配置で満足している間 デュアルブートができます。これを行ったあとデータを移す 方法を探すなら次の段落は読み飛ばしてください。 何もないディスクへインストールしないことに決めたならば /stand/sysinstall、なり &man.fdisk.8; と &man.disklabel.8; なりを使って新しいディスクに パーティションとディスクラベルを作らなければなりません。 また &man.boot0cfg.8; で booteasy を両方のディスクに インストールして、コピーの作業が終わったあとに 古いシステムからでも新しいディスクからでも起動できるように しておく必要があります。この作業の詳細は formatting-media tutorial を見てください。 新しいディスクの立ち上げが終わってデータの移動を 待つばかりになりました。しかし悲しいかな、無闇やたらと コピーすればいいというものではありません。デバイスファイル (/dev) やシンボリックリンクなどは 失敗の元になります。これらを理解するツール、すなわち &man.dump.8; や &man.tar.1; 等を使う必要があります。 データの移転はシングルユーザで行うことをお勧めしますが、 絶対と言うわけではありません。 あなたは &man.dump.8; と &man.restore.8; 以外のもので root ファイルシステムを移行してはなりません。 &man.tar.1; コマンドでもたぶんうまく行くでしょうが、 やらないほうがいいでしょう。パーティション一つを もう一つのからのパーティションに移すときは &man.dump.8; と &man.restore.8; 使うべきです。 パーティションのデータを新しいパーティションに移すのに dump を使うやり方は以下の通りです。 新しいパーティションに newfs をかける。 それを暫定的なマウントポイントにマウントする。 そのディレクトリに cd。 古いパーティションを dump し、 その出力をパイプで新しい方へ。 たとえば root を /dev/ad1s1a へ、暫定的なマウントポイントを /mnt として移そうとすると以下のようになります。 &prompt.root; newfs /dev/ad1s1a &prompt.root; mount /dev/ad1s1a &prompt.root; cd /mnt &prompt.root; dump 0uaf - / | restore xf - もしパーティションの構成を変えようと思っているなら - つまり一つだったものを二つにしたり二つだったものをくっつけたり しようとしているなら、自前であるディレクトリ以下のすべてを 新しい場所へ移す必要が出てくるかも知れません。&man.dump.8; は ファイルシステムに働くのでこの目的には使えません。この場合は &man.tar.1; を使います。一般に /old から /new への移動は &man.tar.1; で 以下のようにします。 &prompt.root; (cd /old; tar cf - .) | (cd /new; tar xpf -) /old に他のファイルシステムが マウントされていて、そのデータの移動までは考えてないならば 最初の &man.tar.1; に 'l' フラグを追加します。 &prompt.root; (cd /old; tar clf - .) | (cd /new; tar xpf -). tar のかわりに cpio(1) や pax(1)、cpdup (ports/sysutils/cpdup) 等を 使っても構いません。 システムを最新の -STABLE にアップデートしようとしたのですが -RC や -BETA になってしまいました! 何が起こったのですか? 短い答え: ただの名前です。RC は リリース候補 (Release Candidate) に 由来するもので、リリースが間近であることを意味します。 また、FreeBSD における -BETA は通常、 リリース前のコードフリーズ期間に入っているという意味になります。 長い答え: FreeBSD はそのリリースを 2 ヶ所あるうちの 一方から派生させます。3.0-RELEASE や 4.0-RELEASE の様な (0 のマイナー番号を持つ) メジャーリリースは、一般に -CURRENT と呼ばれる 開発版の流れから分岐させられてできます。3.1-RELEASE や 4.2-RELEASE などのマイナーリリースはアクティブな -STABLE ブランチ (枝) の スナップショットでした。 4.3-RELEASE からは、リリース毎にブランチが作成されるように なりました。ものすごく保守的な開発速度 (主にセキュリティ 勧告のみ) を求めている人は、このブランチを追跡すると よいでしょう。 リリースを作る時になるとそれを分岐させるブランチは 特定のプロセスへ突入します。そのプロセスの一つは コードフリーズ (コードの凍結) です。コードフリーズが 始まると、そのブランチの名前がリリースになろうとしていることを 反映するものに変えられます。たとえば、4.0-STABLE と 呼ばれていたブランチは名前が 4.1-BETA へと 変えられ、コードフリーズとリリース前のテストが 始まったことを示します。 バグの修正はリリースの一部としてコミットされます。 ソースコードがリリースの形を取ったなら名前が 4.1-RC へと 変えられ、それからリリースが作られることを示します。 ひとたび RC のステージになってしまうと、発見された もっとも致命的なバグの修正しかできなくなります。 ひとたびリリースが (この例では 4.1-RELEASE) 作られれば、 そのブランチは 4.1-STABLE と改名されます。 新しいカーネルを入れようとしたのですが、 chflags に失敗します。どうすれば良いのでしょう? 簡単な回答: 多分、セキュアレベルが 0 より大きくなっているのでしょう。 直接シングルユーザモードで再起動して、 カーネルをインストールしてください。 詳しい回答: FreeBSD では、セキュアレベルが 0 より大きい場合、 システムフラグの変更が禁止されます。 現在のセキュアレベルは、次のコマンドを使って調べることができます。 &prompt.root; sysctl kern.securelevel セキュアレベルを下げる操作は、できないようになっています。 そのため、カーネルをインストールするには、 シングルユーザモードで起動するか、/etc/rc.conf のセキュリティ設定を変更して再起動する必要があります。 セキュアレベルの詳細は &man.init.8; を、 rc.conf の詳細は /etc/defaults/rc.conf および、 &man.rc.conf.5; のマニュアルページをご覧ください。 システムの時刻を 1 秒以上変更することができないのです! どうすれば良いのでしょう? 簡単な回答: 多分、セキュアレベルが 1 より大きくなっているのでしょう。 直接シングルユーザモードで再起動して、 時刻の変更をしてください。 詳しい回答: FreeBSD では、セキュアレベルが 1 より大きい場合、 1 秒以上の時刻変更が禁止されます。 現在のセキュアレベルは、次のコマンドを使って調べることができます。 &prompt.root; sysctl kern.securelevel セキュアレベルを下げる操作は、できないようになっています。 そのため、システムの時刻を変更するには、 シングルユーザモードで起動するか、/etc/rc.conf のセキュリティ設定を変更して再起動する必要ばあります。 セキュアレベルの詳細は &man.init.8; を、 rc.conf の詳細は /etc/defaults/rc.conf および、 &man.rc.conf.5; のマニュアルページをご覧ください。 &man.rpc.statd.8; にメモリリークを見つけました! メモリを 256 メガバイトも使っています。 いいえ。それはメモリリークではありませんし、 256 メガバイトのメモリを使っている、ということでもありません。 おそらく (ほとんどの場合)、 処理に都合が良いように非常にたくさんの量のメモリを そのプロセスのアドレス空間にマッピングしているのでしょう。 技術的な見地から考えても、これは大きな害があることではなく、 単に &man.top.1; や &man.ps.1; といったツールの表示に影響がある程度です。 &man.rpc.statd.8; は、(/var にある) ステータスファイルを自分のアドレス空間にマッピングします。 マッピングは、後で大きな空間が必要になった時に再マッピングしないで済むよう、 非常に大きなサイズを指定して行なわれます。 これは、ソースコードに含まれる &man.mmap.2; 関数のマッピング長を示す引数に 0x10000000 が指定されていることからも分かります。 この数字が IA32 アーキテクチャの持つアドレススペース全体の 16 分の 1、すなわち、ちょうど 256 メガバイトに相当するのです。 X Window System と仮想コンソール 訳: &a.motoyuki; 1997 年 11 月 13 日 X を動かしたいのですが、どうすればいいのですか? もっとも簡単な方法は FreeBSD のインストールの際に X を動かすことを指定するだけです。 それから xf86config ツールのドキュメントを読んでこれに従ってください。 このツールはあなたのグラフィックカードやマウスなどに合わせて XFree86(tm) の設定を行うのを助けてくれます。 Xaccel サーバーについて調べてみるのもいいでしょう。 詳しくは Xi Graphics について か Metro Link をご覧ください。 X を実行しようとして startx と入力したのですが、 KDENABIO failed (Operation not permitted) というエラーが表示されます。 何かおかしなことをやってしまったんでしょうか? あなたのシステムは高いセキュアレベルで運用されていますね? 実は、高いセキュアレベルで X を起動することはできないのです。 どうしてなのかについては、&man.init.8; のマニュアルページに書かれています。 では、代わりにどうすれば良いのかお答えしましょう。 基本的に 2 つの方法があります。 一つはセキュアレベルを 0 にする (通常、これは /etc/rc.conf で指定します) こと、 もう一つは起動時 (セキュアレベルを上げる前) に &man.xdm.1; を実行するかです。 起動時に &man.xdm.1; を実行する方法の詳細については、 を参照してください。 私のマウスはなぜ X で動かないのでしょうか? syscons (デフォルトのコンソールドライバ) を使っているのであれば、 それぞれの仮想スクリーンでマウスポインターをサポートするように FreeBSD を設定できます。X でのマウスの衝突を避けるために、syscons は /dev/sysmouse という仮想デバイスをサポートしています。 本物のマウスデバイスから入力されたすべてのマウスのイベントは、 moused を経由して sysmouse デバイスへ出力されます。 一つ以上の仮想コンソールと X の 両方で マウスを使いたい場合、 を参照して moused を設定してください。 そして、/etc/XF86Config を編集し、 次のように書かれていることを確認してください。 Section Pointer Protocol "SysMouse" Device "/dev/sysmouse" ..... 上の例は、XFree86 3.3.2 以降の場合の例です。 それより前のバージョンでは、 Protocol という部分を MouseSystems と置き換える必要があります。 X で /dev/mouse を使うのを好む人もいます。 この場合は、 /dev/mouse を /dev/sysmouse (&man.sysmouse.4; 参照) にリンクしてください。 &prompt.root; cd /dev &prompt.root; rm -f mouse &prompt.root; ln -s sysmouse mouse わたしのマウスにはホイール機能が付いているのですが、X で使うことはできますか? はい、もちろん使えますが、そのためには X クライアントプログラムを適切に設定する必要があります。これについては、 Colas Nahaboo 氏のウェブページ(http://www.inria.fr/koala/colas/mouse-wheel-scroll/) を参照してください。 imwheel というプログラムを使う場合は、 次のような簡単な手順にしたがってください。 ホイールイベントの変換 imwheel は、 マウスのボタン 4、ボタン 5 をキー押下イベントに変換するプログラムです。 そのためホイールマウスで利用するには、マウスホイールのイベントをボタン 4、 ボタン 5 のイベントに変換するマウスドライバを利用する必要があります。 この変換を行なうには二つの方法があります。 一つは &man.moused.8; で行なう方法、二つめは X サーバ自身に変換を行なわせる方法です。 ホイールイベントの変換に &man.moused.8; を使う &man.moused.8; にイベントを変換させるには、 &man.moused.8; 起動時にオプション を追加します。 たとえば、普段 &man.moused.8; を moused -p /dev/psm0 として起動しているなら、その代わりに moused -p /dev/psm0 -z 4 とします。 もし、 /etc/rc.conf を使って自動的に起動するように設定しているなら、 /etc/rc.conf の中の moused_flags という変数に を追加するだけです。 そして、5 ボタンマウスを使うことを X サーバに伝える必要があります。 これを行なうには /etc/XF86Config の Pointer セクションに Buttons 5 という行を追加するだけです。 そうすると /etc/XF86Config の Pointer は、 たとえば次のようになるでしょう。 moused による変換を利用してホイールマウスを 使用するための XFree86 3.3.x 系列の XF86Config の <quote>Pointer</quote> セクションの設定例 Section "Pointer" Protocol "SysMouse" Device "/dev/sysmouse" Buttons 5 EndSection 自動的なプロトコル認識機能およびボタン配置変換機能を 利用し、ホイールマウスを使用するための XFree86 4.x 系列の XF86Config の <quote>InputDevice</quote> セクションの設定例 Section "InputDevice" Identifier "Mouse1" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/psm0" Option "Buttons" "5" Option "ZAxisMapping" "4 5" EndSection ホイールマウスで Emacs 上でのページスクロールを 行うための <quote>.emacs</quote> の設定例 ;; wheel mouse (global-set-key [mouse-4] 'scroll-down) (global-set-key [mouse-5] 'scroll-up) X サーバを使ったホイールイベントの変換 &man.moused.8; を起動していなかったり、 ホイールイベントの変換に &man.moused.8; を起動したくない場合には、その代わりに X サーバを使うことができます。 これには、/etc/XF86Config ファイルを書き換える必要があります。 まず最初に必要なのは、 マウスがどのプロトコルを使っているのかを確認することです。 ほとんどのホイールマウスは IntelliMouse プロトコルを使用していますが、 XFree86 サーバはその他のプロトコル、 たとえば Logitech MouseMan+ マウスが利用している MouseManPlusPS/2 プロトコルなどもサポートしています。 使用されているプロトコルが確認できたら Pointer セクションに Protocol の行を追加してください。 つぎに、 ホイールのスクロールイベントをマウスボタン 4、 マウスボタン 5 に割り当てることを X サーバに伝えます。 これを行なうには ZAxisMapping オプションを使用します。 たとえば、&man.moused.8; が起動していない状態で、 PS/2 マウスポートに IntelliMouse が接続されているとしたら /etc/XF86Config はおそらく次のようになります。 X サーバによる変換を利用してホイールマウスを使用するための XF86Config の <quote>Pointer</quote> セクションの設定例 Section "Pointer" Protocol "IntelliMouse" Device "/dev/psm0" ZAxisMapping 4 5 EndSection imwheel のインストール さて、つぎに Ports Collection から imwheel をインストールします。 これがあるのは x11 カテゴリです。 このプログラムは、 マウスイベントをキーボードイベントに変換します。 たとえば、マウスホイールを前に回した時、 imwheel は PageUp をアプリケーションプログラムに送るような動作をするわけです。 Imwheel はホイールイベントとキーボード押下の対応を設定ファイルを使って設定するため、 アプリケーション毎に異なる対応を持たせることも可能です。 imwheel のデフォルトの設定ファイルは /usr/X11R6/etc/imwheelrc にインストールされます。 これを ~/.imwheelrc にコピーして編集し、 お好きなように imwheel で利用したいアプリケーションの設定をカスタマイズしてください。 設定ファイルの書式は &man.imwheel.1; に説明されています。 Emacs で Imwheel を使うように設定する (必須ではありません) emacs や Xemacs で利用するには、 ~/.emacs にいくらか書き加える必要があります。 emacs の場合は次の部分を追加してください。 <application>Imwheel</application> を利用するための <application>Emacs</application> の設定例 ;;; For imwheel (setq imwheel-scroll-interval 3) (defun imwheel-scroll-down-some-lines () (interactive) (scroll-down imwheel-scroll-interval)) (defun imwheel-scroll-up-some-lines () (interactive) (scroll-up imwheel-scroll-interval)) (global-set-key [?\M-\C-\)] 'imwheel-scroll-up-some-lines) (global-set-key [?\M-\C-\(] 'imwheel-scroll-down-some-lines) ;;; end imwheel section Xemacs の場合は ~/.emacs に次の部分を追加してください。 <application>Imwheel</application> を利用するための <application>XEmacs</application> の設定例 ;;; For imwheel (setq imwheel-scroll-interval 3) (defun imwheel-scroll-down-some-lines () (interactive) (scroll-down imwheel-scroll-interval)) (defun imwheel-scroll-up-some-lines () (interactive) (scroll-up imwheel-scroll-interval)) (define-key global-map [(control meta \))] 'imwheel-scroll-up-some-lines) (define-key global-map [(control meta \()] 'imwheel-scroll-down-some-lines) ;;; end imwheel section Imwheel の実行 インストールが完了していれば、単に xterm (訳注: 日本語環境で広く使われている kterm でも構いません) から imwheel を入力するだけで起動できます。 起動するとバックグラウンドで動作し、すぐに利用できます。 imwheel をいつも使うように設定するには、 .xinitrc か .xsession のファイルにそのままコマンドを追加してください。 imwheel が PID ファイルに関する警告を表示するかも知れませんが、 無視しても危険はありません。この警告が意味を持つのは、 Linux 版の imwheel だけです。 X のメニューやダイアログボックスがうまく動きません。 Num Lock キーをオフにしてください。 Num Lock キーがデフォルトで起動時にオンになる場合は、 XF86Config ファイルの Keyboard セクションに以下の行を加えてもいいでしょう。 # Let the server do the NumLock processing. This should only be # required when using pre-R6 clients ServerNumLock 訳注 この問題は XFree86 3.2 以降では解決しています。 仮想コンソールとは何ですか? どうやったら使えますか? 仮想コンソールは、簡単にいうと、ネットワークや X を動かすなどの複雑なことを行なわずに、 いくつかのセッションを同時に行なうことを可能にします。 システムのスタート時には、 起動メッセージが出た後に login プロンプトが表示されます。そこで ログイン名とパスワードを入力すると 1 番目の仮想コンソール上で仕事 (あるいは遊び) を始めることができます。 他のセッションを始めたい場合もあるでしょう。 それは動かしているプログラムのドキュメントを見たり、 FTP の転送が終わるまで待つ間、 メールを読もうとしたりすることかもしれません。 Alt-F2 を押す (Alt キーを押しながら F2 キーを押す) と、 2 番目の「仮想コンソール」で ログインプロンプトが待機していることがわかります。 最初のセッションに戻りたいときは Alt-F1 を押します。 標準の FreeBSDインストールでは、 3 枚 (3.3-RELEASE では 8 枚) の仮想コンソールが有効になっていて、 Alt-F1、 Alt-F2、 Alt-F3 で仮想コンソール間の切替えを行ないます。 より多くの仮想コンソールを有効にするには、 /etc/ttys (&man.ttys.5; 参照) を編集して Virtual terminals のコメント行の後に ttyv4 から ttyvc の手前までのエントリを加えます (以下の例は先頭には空白は入りません)。 # /etc/ttys には ttyv3 がありますので # "off" を "on" に変更します。 ttyv3 "/usr/libexec/getty Pc" cons25 on secure ttyv4 "/usr/libexec/getty Pc" cons25 on secure ttyv5 "/usr/libexec/getty Pc" cons25 on secure ttyv6 "/usr/libexec/getty Pc" cons25 on secure ttyv7 "/usr/libexec/getty Pc" cons25 on secure ttyv8 "/usr/libexec/getty Pc" cons25 on secure ttyv9 "/usr/libexec/getty Pc" cons25 on secure ttyva "/usr/libexec/getty Pc" cons25 on secure ttyvb "/usr/libexec/getty Pc" cons25 on secure 多くするか少なくするかはあなたの自由です。 より多くの仮想ターミナルを使うとより多くのリソースを使うことになります。 8MB 以下のメモリしかない場合はこれは重要な問題です。 もし必要があれば secure を insecure に変更してください。 X を使いたいのであれば、 最低一つの仮想ターミナル (のエントリ) を使わずに残しておくか、 off にしておく必要があります。 つまり、12 個の Alt-ファンクションキーすべてでログインプロンプトを 出したいのならば、 残念ながら X は利用できないということです。 同じマシンで X サーバーも動かしたいのならば 11 個しか使えません。 仮想コンソールを無効にするもっとも簡単な方法は、 コンソールを off にすることです。 たとえば 12 個すべてのターミナルを割り当てている状態で X を動かしたいときは、 仮想ターミナル 12 を変更します。 ttyvb "/usr/libexec/getty Pc" cons25 on secure これを次のように変更します。 ttyvb "/usr/libexec/getty Pc" cons25 off secure キーボードにファンクションキーが 10 個しかないのであれば、 次のように設定します。 ttyv9 "/usr/libexec/getty Pc" cons25 off secure ttyva "/usr/libexec/getty Pc" cons25 off secure ttyvb "/usr/libexec/getty Pc" cons25 off secure (これらの行を消すだけでもいいです。) /etc/ttys を編集したら、 次は十分な数の仮想ターミナルデバイスを作らなくてはなりません。 もっとも簡単な方法を示します。 &prompt.root; cd /dev &prompt.root; ./MAKEDEV vty12 (12 個のデバイスをつくる場合) さて、仮想コンソールを有効にするもっとも簡単 (そして確実) な方法は、 再起動することです。しかし、再起動したくない場合は、 X ウィンドウシステムを終了させて次の内容を (root権限で) 実行します。 &prompt.root; kill -HUP 1 重要な点は、 このコマンドを実行する前に X ウィンドウシステムを完全に終了させておくことです。 もしそうしないと kill コマンドを実行した後、 システムはおそらくハングアップするでしょう。 X から仮想コンソールに切替えるにはどうすればよいのですか? 仮想コンソールへ戻るには Ctrl Alt Fn を使ってください。 最初の仮想コンソールへは Ctrl Alt F1 で戻れます。 テキストコンソールへ移った後は、その中で移動するのに 今度はいつもどおり Alt Fn を使ってください。 X のセッションへ戻るには X の走っている仮想コンソールへ 切り替える必要があります。もしあなたが X をコマンドラインから 実行していたのであれば (たとえば startx を使う) X のセッションはそれを実行したテキストコンソールではなく 最初の使われていない仮想コンソールに割り当てられているはずです。 あなたが仮想端末を 8 個用意している場合は X を 9 番目の コンソールにいるはずで、 Alt F9 を使うことになります。 訳注 X に戻るには、 3 枚の仮想コンソールが有効になっている場合は Alt-F4 です。 有効な仮想コンソールの数 +1 のファンクションキーの 位置に X が割り当てられます。 XDM を起動時に起動させるにはどうしますか? xdm の起動方法については二つの流派があります。 一方の流派では提供された例を使用して xdm を /etc/ttys (&man.ttys.5; 参照) から起動し、もう一方の流派では xdm を単に rc.local (&man.rc.8; 参照) または /usr/local/etc/rc.d においた X.sh スクリプトから起動します。 どちらも正しく、片方が動作しない場合は、もう片方が動作するでしょう。 どちらも場合でも結果は同じであり、X はグラフィカルな login: プロンプトを表示します。 ttys を利用する方法の利点は、 どの vty で X が起動したかの記録が残せることと、 ログアウト時に X サーバを再起動する責任を init に押しつけることができることでしょう。 rc.local からロードされる場合、 xdm は引数を持たずに (すなわち、デーモンとして) 起動します。 xdm は getty が起動した後にロードされなければなりません。 そうでないと、xdm は getty と衝突し、コンソールをロックアウトしてしまいます。 この問題に対処する最善の方法は、 起動スクリプト (訳注: rc.local のこと) で 10 秒ほどの sleep を実行させ、 その後に xdm をロードすることです。 /etc/ttys から xdm を起動させている場合には、 xdm と getty が衝突する可能性があります。 この問題を回避するには、/usr/X11R6/lib/X11/xdm/Xservers に vt 番号を追加してください。 :0 local /usr/X11R6/bin/X vt4 上の例は、/dev/ttyv3 を X サーバに対応させます。番号は 1 から始まりますので注意してください。 X サーバは vty を 1 から数えますが、 FreeBSD カーネルは vty を 0 から数えます。 xconsole を動かそうとすると Couldn't open console とエラーが出ます。 X を startx で起動しますと、/dev/console のパーミッションは 変更ができないようになっていますので、 xterm -C や xconsole は動きません。 これはコンソールのパーミッションが、 標準ではそのように設定されているからです。 マルチユーザシステムでは、 ユーザの誰もがシステムコンソールに書き込むことが可能である必要は必ずしもありません。 VTY を使い直接マシンにログインするユーザのために、 このような問題を解決するために &man.fbtab.5; というファイルがあります。 要点を述べると、次のような形式の行を /etc/fbtab (&man.fbtab.5; 参照) に加えます。 /dev/ttyv0 0600 /dev/console そうすると、 /dev/ttyv0 からログインしたユーザが コンソールを所有することになるでしょう。 わたしはいつも XFree86 を一般ユーザから起動していたのですが、 最近になって root ユーザでなければならないと言われるようになりました。 すべての X サーバは、 ビデオハードウェアに直接アクセスするために root ユーザで実行される必要があります。 古いバージョンの XFree86 (<= 3.3.6) に含まれるすべてのサーバは、 自動的に root 権限で実行されるように (root ユーザに setuid されて) インストールされます。 X サーバは大きく複雑なプログラムであり、 これは明らかにセキュリティを危険に晒す要因となります。 そのため新しいバージョンの XFree86 では、 サーバを root ユーザに seruid しないでインストールするようになりました。 X サーバを root ユーザで動かすというのは、 明らかにセキュリティ的に不適当で受け入れられないことです。 X を一般ユーザで実行するには、二つの方法があります。 一つは xdm や、その他のディスプレイマネージャ (たとえば kdm など) を使うこと、 もう一つは Xwrapper を使うことです。 xdm は、 グラフィカルなログイン画面を扱うデーモンです。 通常、起動時に実行され、 各ユーザの認証とユーザセションを開始させる機能を実現します。 基本的に、getty と login のグラフィック版、と考えて良いでしょう。 xdm の詳細については、 XFree86 関連文書 および FAQ 項目をご覧ください。 Xwrapper とは、X サーバ用のラッパ (wrapper) のことです。 これは必要なセキュリティを確保しつつ、一般ユーザが X サーバを実行できるようにした小さなユーティリティで、 コマンドライン引数の正当性チェックを行ない、 それを通過すれば適切な X サーバを起動します。 何らかの理由でディスプレイマネージャを使いたくない場合に これを使うと良いでしょう。 Ports Collection 全体をインストールしていれば、 /usr/ports/x11/wrapper にあります。 私の PS/2 マウスは X ウィンドウシステム上でうまく動きません。 あなたのマウスとマウスドライバがうまく同期していないからかもしれません。 FreeBSD 2.2.5 までのバージョンでは、X から仮想ターミナルへ切替えて、 また X へ戻ると再同期するかもしれません。 この問題がよく起きるようであれば、カーネルコンフィグレーション ファイルに次のオプションを書いてカーネルを再構成してみてください。 options PSM_CHECKSYNC もし、カーネルの再構築を行なったことがないのであれば、 カーネルを構築するの項を参照してください。 このオプションにより、 マウスとドライバの同期で問題が起きる可能性は少なくなるでしょう。 もしそれでもこの問題が起きるようならば、 再同期させるにはマウスを動かさないようにしておいて マウスボタンのどれかを押してください。 このオプションは残念ながらすべてのシステムで働くわけではなく、 また、PS/2 マウスポートにつながれているのが タップ (tap) 機能を持つ アルプス社製 GlidePoint デバイスの場合、 タップ機能が無効となってしまいます。 FreeBSD 2.2.6 以降のバージョンでは、 同期のチェック方法が少し改善されたので標準で有効になっています。 GlidePoint でもうまく働きます (同期チェックが標準の機能になったので PSM_CHECKSYNC オプションはこれらのバージョンからは削除されました)。 しかしながら、 まれにドライバが間違って (訳注: 問題がないのに) 同期に関して問題があると報告し、カーネルから psmintr: out of sync (xxxx != yyyy) というメッセージが出力されて、マウスが正しく動作していないように見える ことがあるかもしれません。 もしこのようなことが起こる場合には、PS/2 マウスドライバのフラグに 0x100 を指定して同期チェックを無効にしてください。システムの起動時に 起動オプションを与えて UserConfig に入ります。 boot: -c boot: UserConfig のコマンドラインで以下のように入力してください。 UserConfig> flags psm0 0x100 UserConfig> quit MouseSystems の PS/2 マウスがうまく動きません。 MouseSystems の PS/2 マウスのあるモデルは、 高解像度モードの場合にのみ正しく動作するということが報告されています。 それ以外のモードでは、 マウスカーソルがしょっちゅうスクリーン左上に行ってしまうかもしれません。 残念ながら FreeBSD 2.0.X や 2.1.X のバージョンでは、 この問題の解決する方法はありません。 2.2 から 2.2.5 のバージョンでは、 以下のパッチを /sys/i386/isa/psm.c に適用しカーネルの再構築を行なってください。 もし、カーネルの再構築を行なったことがないのであれば、 カーネルの構築の項を参照してください。 @@ -766,6 +766,8 @@ if (verbose >= 2) log(LOG_DEBUG, "psm%d: SET_DEFAULTS return code:%04x\n", unit, i); + set_mouse_resolution(sc->kbdc, PSMD_RES_HIGH); + #if 0 set_mouse_scaling(sc->kbdc); /* 1:1 scaling */ set_mouse_mode(sc->kbdc); /* stream mode */ FreeBSD 2.2.6 以降のバージョンでは、 PS/2 マウスドライバのフラグに 0x04 を指定してマウスを高解像度モードにします。 システムの起動時に 起動オプションを与えて UserConfig に入ります。 boot: -c UserConfig のコマンドラインで以下のように入力してください。 UserConfig> flags psm0 0x04 UserConfig> quit マウスに関する不具合の他の原因の可能性については、 直前のセクションも見てみてください。 X のアプリケーションを構築する時に、 imake can't find Imake.tmpl となります。どこにあるのでしょうか? Imake.tmpl は X の標準アプリケーション構築ツールである Imake パッケージの一部です。 Imake.tmpl は、 X アプリケーションの構築に必要な多くのヘッダファイルと同様に、 X のプログラムディストリビューションに含まれています。 sysinstall を使うか、 手動で X のディストリビューションファイルからインストールすることができます。 マウスのボタンを入れ替える方法はありますか? .xinitrc か .xsession で xmodmap というコマンドを実行してください。 スプラッシュスクリーンのインストールはどうするのですか。 どこで見つけることができますか? FreeBSD 3.1 のリリース直前に、起動メッセージの表示期間に いわゆる "スプラッシュ" スクリーンを表示させることができる新しい機能が追加されました。 いまのところスプラッシュスクリーンは 256 色のビットマップ (*.BMP) か ZSoft PCX (*.PCX) ファイルです。 それに加えて、標準の VGA アダプタでの動作させるには 320x200 以下の解像度である必要があります。 カーネルに VESA サポートを追加すれば 1024x768 までのより大きいビットマップを使用できます。 VESA サポートを有効化するにはまず、 カーネルが VM86 カーネルオプションとともにコンパイルされている必要があることに注意してください。 VESA サポートそのものは VESA カーネルコンフィグオプション によって直接カーネル中にコンパイルするか、 起動時に VESA kld モジュールを読み込ませることができます。 スプラッシュスクリーンを使うには、 FreeBSD の起動プロセスをコントロールするスタートアップファイルを書き換える必要があります。 これらのファイルは FreeBSD 3.2 のリリース以前に変更されましたので、 現在は、スプラッシュスクリーンを読み込む方法が二つあります。 FreeBSD 3.1 の場合 まず最初のステップは、 スプラッシュスクリーンのビットマップ版を探してくることです。 3.1-RELEASE では Windows のビットマップ形式のスプラッシュスクリーンだけをサポートしています。 お望みのスプラッシュスクリーンを見つけたなら、それを /boot/splash.bmp にコピーします。次に、これらの行が書かれた /boot/loader.rc ファイルが必要です。 load kernel load -t splash_image_data /boot/splash.bmp load splash_bmp autoboot FreeBSD 3.2 以降の場合 PCX 形式のスプラッシュスクリーンのサポートが追加されると同時に、 FreeBSD 3.2 には起動プロセスを設定する、 より洗練された方法が含まれています。 もしお望みなら、上に示した FreeBSD 3.1 用の方法を使うこともできます。 もしそうしたくて、かつ PCX 形式を使いたいなら、 splash_bmp を splash_pcx と読み換えてください。 そうではなくて、新しい起動設定方法を使うのなら、 次の数行が書かれた /boot/loader.rc ファイルと、 include /boot/loader.4th start 次の数行が含まれた /boot/loader.conf ファイルを作ることが必要です。 splash_bmp_load="YES" bitmap_load="YES" この例では、スプラッシュスクリーンとして /boot/splash.bmp を使うことを想定しています。PCX 形式のファイルを使う場合には、 そのファイルを /boot/splash.pcx にコピーして、 上で示したように /boot/loader.rc を作ります。 そして、次の内容の /boot/loader.conf というファイルを作ってください。 splash_pcx_load="YES" bitmap_load="YES" bitmap_name="/boot/splash.pcx" さて、あとはスプラッシュスクリーンを用意するだけです。 それには http://www.baldwin.cx/splash/ のギャラリーをサーフしてみてください。 X で Windows(tm) キーを使うことはできるのでしょうか? はい、もちろん。 どういう動作をするかについて定義するには &man.xmodmap.1; を使います。 標準的な "Windows(tm)" キーボードの場合、 対応するキーコードは 3 種類あります。 115 - 左の Ctrl と Alt の間にある Windows(tm) キー 116 - 右の Alt と Gr の間にある Windows(tm) キー 117 - 右の Ctrl の左隣にあるメニューキー 左にある Windows(tm) キーを押すとカンマ記号が入力されるようにするには、 こんな風にします。 &prompt.root; xmodmap -e "keycode 115 = comma" 設定を反映させるには、おそらくウィンドウマネージャを再起動する必要があります。 Windows(tm) キーのキーマップを X 起動時に毎回、 自動的に有効化するには xmodmap コマンドを ~/.xinitrc に追加するか、 もしくはおすすめできる方法として ~/.xmodmaprc というファイルを作成して、 そのファイルの一行一行に xmodmap のオプションを記述し、次の一行 xmodmap $HOME/.xmodmaprc を ~/.xinitrc に追加するという方法があります。 たとえば、先ほどあげた三つのキーを F13、F14、F15 に割り当てるとします。 こうしておけば、後ほど示すように、アプリケーションや ウィンドウマネージャの便利な機能を その三つのキーに簡単に割り当てることができます。 こうするには、次の内容を ~/.xmodmaprc に追加します。 keycode 115 = F13 keycode 116 = F14 keycode 117 = F15 たとえば fvwm2 を使っていたら、 F13 をカーソル下のウィンドウのアイコン化、 F14 をウィンドウの前面/背面化、 F15 を、あたかもデスクトップにカーソルが存在しないかのように、 メインワークスペース (アプリケーション) のメニューを呼び出せる機能に割り当てられます。 最後の機能は、そのデスクトップがまったく見えないときに便利です。 (また、キートップのロゴにもぴったりです) ~/.fvwmrc の次のエントリは、前述の 設定を実現します。 Key F13 FTIWS A Iconify Key F14 FTIWS A RaiseLower Key F15 A A Menu Workplace Nop ネットワーキング 訳: &a.jp.arimura;、 &a.jp.shou;、 にしか nishika@cheerful.com、 &a.jp.kiroh;、 1998 年 10 月 4 日 ディスクレスブート (diskless boot) に関する情報はどこで得られますか? ディスクレスブート (diskless boot) というのは、FreeBSD がネットワーク上で起動し、 必要なファイルを自分のハードディスクではなくてサーバから読み込むものです。 詳細については FreeBSD ハンドブックの「ディスクレスブート」を読んでください。 FreeBSD をネットワークのルータ (router) として使用することはできますか? インターネット標準やこれまでのよい経験によって指摘されている通り、 FreeBSD は標準ではパケットを転送 (forward) するように設定されていません。 しかし、 &man.rc.conf.5; の中で次の変数の値を YES とする事によってこの機能を有効にすることができます。 gateway_enable=YES # Set to YES if this host will be a gateway このオプションによって &man.sysctl.8; の変数 net.inet.ip.forwarding が 1 になります。 ほとんどの場合、 ルータについての情報を同じネットワークの他の計算機等に知らせるために、 経路制御のためのプロセスを走らせる必要があるでしょう。 FreeBSD には BSD の標準経路制御デーモンである &man.routed.8; が付属していますが、より複雑な状況に対処するためには GaTeD(http://www.gated.org/ から入手可能) を使用することもできます。 3_5Alpha7 において FreeBSD がサポートされています。 注意してほしいのは、FreeBSD をこのようにして使用している場合でも、 ルータに関するインターネット標準の必要条件を完全には満たしていない ということです。しかし、普通に使用する場合にはほとんど問題ありません。 Win95 の走っているマシンを、FreeBSD 経由でインターネットに接続できますか? 通常、この質問が出てくる状況は自宅に二台の PC があり、一台では FreeBSD が、もう一台では Win95 が走っているような場合です。 ここでやろうとしていう事は FreeBSD の走っている計算機をインターネット に接続し、Win95 の走っているマシンからは FreeBSD の走っているマシンを経由して接続を行なう事です。 これは二つ前の質問の特別な場合に相当します。 …で、答えは「はい」です。 FreeBSD 3.x のユーザモード ppp には オプションがあります。 ppp を オプション付きで起動し、 /etc/rc.conf にある gateway_enable を YES に設定します。 そして Windows マシンを正しく設定すれば、 きちんと動作するでしょう。 設定に関するさらに詳しい情報は、 Steve Sims 氏による Pedantic PPP Primer にあります。 カーネルモード ppp を利用する場合や、 インターネットとのイーサネット接続が利用できる場合は、 natd を利用する必要があります。 この FAQ の natd のセクションを参照してください。 ISC からリリースされている BIND の最新版はコンパイルできないんでしょうか? BIND の配布物と FreeBSD とでは cdefs.h というファイルの中でデータ型の矛盾があります。 compat/include/sys/cdefs.h を削除してください。 FreeBSD で SLIP と PPP は使えますか? 使えます。FreeBSD を用いて他のサイトに接続する場合には、 &man.slattach.8;、&man.sliplogin.8;、&man.ppp.8; そして &man.pppd.8; のマニュアルページをご覧ください。 &man.ppp.8; と &man.pppd.8; は、 PPP のサーバ、クライアント両方の機能を持っています。 その一方で、&man.sliplogin.8; は SLIP のサーバ専用で、 &man.slattach.8; は SLIP のクライアント専用です。 これらを使うためのさらなる情報については、ハンドブックの PPP と SLIP の章をご覧ください。 「シェルアカウント」を通じてのみインターネットへアクセス可能な場合、 slirp package みたいなものが欲しくなるかもしれませんね。 これを使えば、ローカルマシンから直接 ftp や http のようなサービスに (限定的ではありますが) アクセスすることができます。 FreeBSD は NAT か IP マスカレードをサポートしていますか? ローカルなサブネット (一台以上のローカルマシン) を持っているが、 インターネットプロバイダから 1 つしか IP アドレスの割り当てを受けていない場合 (または IP アドレスを動的に割り当てられている場合でも)、 &man.natd.8; プログラムを使いたくなるかもしれませんね。 natd を使えば、 1 つしか IP アドレスを持っていない場合でも、 サブネット全体をインターネットに接続させることができます。 &man.ppp.8; も同様の機能を持っており、 スイッチで有効にすることができます。 どちらの場合も alias ライブラリ (&man.libalias.3;) が使われます。 /dev/ed0 デバイスを作成することができません。 Berkeley UNIX におけるネットワークの構成において、 ネットワークのインタフェースはカーネルコードからのみ、 直接あつかうことができます。 より詳しく知りたい場合は、 /etc/rc.network というファイルや、 このファイルの中に書いてある、 さまざまなプログラムについてのマニュアルページを見てください。 それでもまだ分からない場合には、 他の BSD 系の OS のネットワーク管理についての本を読むべきでしょう。 ごく少しの例外をのぞいては、FreeBSD のネットワーク管理は SunOS 4.0 や Ultrix と基本的に同じです。 Ethernet アドレスのエイリアス (alias) はどのようにして設定できますか? &man.ifconfig.8; のコマンドラインに netmask 0xffffffff を追加して、次のように書いてください。 &prompt.root; ifconfig ed0 alias 204.141.95.2 netmask 0xffffffff 3C503 で他のネットワークポートを使用するにはどのようにすればよいですか? 他のポートを使用したい場合には、 &man.ifconfig.8; のコマンドラインにパラメータを追加しなければなりません。 デフォルトでは link0 が用いられるようになっています。 BNC のかわりに AUI ポートを使用したい場合には、 link2 というパラメータを追加してください。 これらのフラグは、 /etc/rc.conf (&man.rc.conf.5; 参照) にある ifconfig_* の変数を使って指定されるはずです。 FreeBSD との間で NFS がうまくできません。 PC 用のネットワークカードによっては、 NFS のような、 ネットワークを酷使するアプリケーションにおいて問題を起こすものがあります。 この点に関しては FreeBSD ハンドブックの「NFS」を参照してください。 何故 Linux のディスクを NFS マウントできないのでしょうか? Linux の NFS のコードには、 許可されたポートからのリクエストしか受けつけないものがあります。 以下を試してみてください。 &prompt.root; mount -o -P linuxbox:/blah /mnt 何故 Sun のディスクを NFS マウントできないのでしょうか? SunOS 4.X が走っている Sun Workstation は、 許可されたポートからのマウント要求しか受けつけません。 以下を試してみてください。 &prompt.root; mount -o -P sunbox:/blah /mnt mountd から can't change attributes というメッセージがずっと出続けていて、 FreeBSD の NFS サーバでは bad exports list と表示されます。これは何が原因なのでしょう? 最も良くある問題は、&man.exports.5; のマニュアルページの以下の部分を正しく理解していないことです。
このファイルの各行 (# ではじまるコメント行を除く) は、 NFS サーバのローカルファイルシステムに存在する、 他のホストにエクスポートされるマウントポイント (複数可) と、 それに対するエクスポートフラグを指定します。 特定のエクスポート先ホストおよび、 すべてのホストに適用されるデフォルトエントリは両方とも、 サーバの各ローカルファイルシステムに対して一回だけしか指定できません。
さて、ありがちな間違いをご覧になればはっきりするでしょう。 もし /usr 以下が単一のファイルシステムである (つまり /usr に何もマウントされない) 場合、 次の exports リストは正しくありません。 /usr/src client /usr/ports client 一つのファイルシステムに対して属性の指定が二行になっています。 /usr は同じホスト client にエクスポートされますから、 正しい書き方は次のようになります。 /usr/src /usr/ports client もう一度マニュアルページの文章を確認すると、 あるホストにエクスポートされる各ファイルシステムの属性は すべて一行に書かれていなければならない、となっています (ここでは、「アクセス可能なすべてのホスト」 も一つの独立したホストとして扱われることに注意してください)。 このことは、ファイルシステムをエクスポートするために 奇妙な書式を使わなければならない原因にもなっているのですが、 ほとんどの人にとって、これは問題にはならないでしょう。 次に示すのは、有効な exports リストの例です。 ここでは、/usr と /exports がローカルファイルシステムです。 # Export src and ports to client01 and client02, but only # client01 has root privileges on it /usr/src /usr/ports -maproot=0 client01 /usr/src /usr/ports client02 # The "client" machines have root and can mount anywhere # up /exports. The world can mount /exports/obj read-only /exports -alldirs -maproot=0 client01 client02 /exports/obj -ro PPP で NeXTStep に接続する際に問題があるのですが。 /etc/rc.conf (&man.rc.conf.5; 参照) の中で次の変数を NO にして、 TCP extension を無効にしてみてください。 tcp_extensions=NO Xylogic の Annex も同様の問題がありますので、 Annex 経由で PPP を行なう場合にもこの変更を行ってください。 IP マルチキャスト (multicast) を有効にするには? FreeBSD 2.0 かそれ以降では、 標準の状態で完全にマルチキャストに対応しています。 現在使用している計算機をマルチキャストのルータ (router) として使用するには、 MROUTING というオプションを定義したカーネルを作ったうえで、 mrouted を走らせる必要があります。2.2 かそれ以降の FreeBSD ならば、 /etc/rc.conf でフラグ mrouted_enable を YES にセットしておくことで、 起動時に mrouted を起動できます。 MBONE 用のツールは ports 内の専用のカテゴリー mbone にあります。 vic や vat といった会議用のツールを探している場合は、 この場所を見てください。 詳しい情報は Mbone Information Web にあります。 DEC の PCI チップセットを用いているネットワークカードには、 どのような物がありますか? Glen Foster 氏による一覧に、 最近の製品を追加したものを以下に示します。 Vendor Model ---------------------------------------------- ASUS PCI-L101-TB Accton ENI1203 Cogent EM960PCI Compex ENET32-PCI D-Link DE-530 Dayna DP1203, DP2100 DEC DE435, DE450 Danpex EN-9400P3 JCIS Condor JC1260 Linksys EtherPCI Mylex LNP101 SMC EtherPower 10/100 (Model 9332) SMC EtherPower (Model 8432) TopWare TE-3500P Znyx (2.2.X) ZX312, ZX314, ZX342, ZX345, ZX346, ZX348 (3.X) ZX345Q, ZX346Q, ZX348Q, ZX412Q, ZX414, ZX442, ZX444, ZX474, ZX478, ZX212, ZX214 (10mbps/hd) 何故自分のサイトのホストに対して FQDN を使用する必要があるのですか? 実際にはそのホストは別のドメインにあるのではないですか。 たとえば、foo.bar.edu というドメインの中から、 bar.edu ドメインにある mumble というホストを指定したい場合には、 mumble だけではダメで、 mumble.bar.edu という FQDN (fully-qualified domain name) で指定しなければなりません。 伝統的に、BSD の BIND のリゾルバ (resolver) ではこのような事は可能でしたが、 FreeBSD に入っている bind (&man.named.8; 参照) の現在のバージョンでは、 自分以外のドメインに対して FQDN でない別名を自動的につけてくれるような事はありません。 したがって mumble というホスト名は、 mumble.foo.bar.edu という名前か、もしくは root ドメイン内にある場合にしか適用されません。 これは、 mumble.bar.edu と mumble.edu ということなったドメイン名に対してホスト名のサーチが行なわれていた 以前の振る舞いとは異なったものです。このような事が悪い例もしくは セキュリティホールとみなされる理由については RFC 1535 を見てください。 /etc/resolv.conf ファイル (&man.resolv.conf.5; 参照) の中で domain foo.bar.edu と書いてある行を、 search foo.bar.edu bar.edu のように書きかえることで、上のような事ができます。しかし、 RFC 1535 にあるように、 検索順序が「内部 (local) と外部 (public) の管理の境界」をまたがないようにしてください。 すべてのネットワークの操作に対して Permission denied というメッセージが表示されるのですが。 IPFIREWALL オプションを付けてカーネルをコンパイルした場合には、 2.1-STABLE の開発の途中から変更になった 2.1.7R の標準的な方針として、 明示的に許可されていないすべてのパケットは落とされる設定 になっている事を覚えておいてください。 もしファイアウォールの設定を間違えた場合にネットワークの操作が再びできる ようにするには、root でログインして次のコマンドを実行してください。 &prompt.root; ipfw add 65534 allow all from any to any /etc/rc.conf に firewall_type='open' を追加してもよいでしょう。 FreeBSD のファイアウォールの設定についての情報は FreeBSD ハンドブックの「ファイアウォール」にあります。 IPFW のオーバヘッドはどのくらいでしょうか? この答えは、 使っているルールセットとプロセッサのスピードによってほとんど決まります。 イーサネットに対して少しのルールセットだけを使っている場合には、 ほとんどその影響は無視できる程度です。 実際の測定値を見ないと満足できない方々のために、 実際の測定結果をお見せしましょう。 次の測定は 486-66 (訳注: Intel 社製 CPU i486、66MHz のこと) 上で 2.2.5-STABLE を使用して行なわれました。 IPFW は変更が加えられて、ip_fw_chk ルーチン内でかかる時間を 測定して 1000 パケット毎に結果をコンソールに表示するようになっています。 それぞれ 1000 ずつのルールが入っている 2 つのルールセットでテストが行なわれました。 ひとつ目のルールセットは最悪のケースを見るために ipfw add deny tcp from any to any 55555 というルールを繰り返したものです。 IPFW のパケットチェックルーチンは、 パケットが (ポート番号のせいで) このルールにマッチしないことがわかるまでに、 何度も実行されます。そのため、これは最悪のケースを示します。 このルールを 999 個繰り返し並べた後に allow ip from any to any が書かれています。 2つ目のルールセットは、なるべく早くチェックが終了するように書かれたものです。 ipfw add deny ip from 1.2.3.4 to 1.2.3.4 このルールでは、発信元の IP アドレスがマッチしないので、 チェックはすぐに終了します。上のルールセットとおなじように、 1000 個目のルールは allow ip from any to any です。 1 つ目のルールセットの場合、 パケットあたりのオーバヘッドはおよそ 2.703ms/packet、 これはだいたい 1 つのルールあたり 2.7 マイクロ秒かかっていることになります。 したがって、 このルールにおけるパケット処理時間の理論的な限界は、 毎秒約 370 パケットです。 10Mbps のイーサネットで 1500 バイト以下のパケットサイズを仮定すると、 バンド幅の利用効率は 55.5% が限界となることになります。 2 つ目のルールセットでは、それぞれのパケットがおよそ 1.172msで処理されていますので、 だいたい 1 つのルールあたり 1.2 マイクロ秒かかっていることになります。 パケット処理時間の理論的な限界は、 毎秒約 853 パケットとなりますので、 10Mbps Ethernet のバンド幅を使い切ることができます。 このテストでのルール数は多過ぎるため、 実際に使用する際の結果を反映している訳ではありません。 これらは上に示した数値を出すためだけに用いられたものです。 効率の良いルールセットを作るためには、 次のような事を考えておけばよいでしょう。 「確定している」ルールは先頭の方に持ってきてください。 これは、多数の TCP のトラフィックがこのルールで処理されるためです。 そしてこのルールの前には allow tcp という記述を置かないでください。 良く使われるルールを、あまり良く使われないルールよりも 前の方に (もちろんファイアウォールの許可設定を変えない範囲で) 持ってきてください。 ipfw -a l のようしてパケット数の統計を取ることで、 どのルールが最もよく使われているかを調べることができます。 &man.ipfw.8; fwd ルールを使って他のマシンにサービスをリダイレクトしたのですが、 うまく動いてくれないようです。どうしてなんでしょう? おそらく、あなたが期待している動作とは、 単なるパケット転送ではなくネットワークアドレス変換 (NAT) と呼ばれるものだからでしょう。 fwd ルールは文字どおり、本当に転送しか行ないません。 パケットの中身については一切手を加えないのです。 そのため、次のようなルールを設定したとすると、 01000 fwd 10.0.0.1 from any to foo 21 宛先アドレスに foo と書かれたパケットが このルールを設定したマシンに到着した場合、そのパケットは 10.0.0.1 に転送されますが、宛先アドレスは foo のままになります。 つまり、パケットに宛先アドレスが 10.0.0.1 に書き換えられるということはありません。 自分宛でないパケットを受けとったマシンは、 おそらくほとんどの場合、そのパケットを破棄すると思います。 そのため fwd ルールは、 そのルールを書いたユーザが意図したようには動かないことが良くあります。 この動作はバグではなく、仕様なのです。 サービスの転送をきちんと動作させる方法については、 サービスのリダイレクトに関する FAQ や &man.natd.8; のマニュアルページ、 Ports Collection にいくつか含まれているポート転送ユーティリティなどをご覧になると良いでしょう。 サービス要求を他のマシンにリダイレクトするには? FTP などのサービスのリクエストは、socket パッケージを利用してリダイレクトできます。 socket パッケージは ports の sysutils カテゴリに含まれています。 (/etc/inet.confに書かれている) コマンド行を、次のように socket を呼ぶように変更してください。 ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.foo.com ftp ここで ftp.foo.com はリダイレクト先のホスト名、 行の最後の ftp はポート名です。 バンド幅の管理を行なえるツールはどこで手に入れられますか? FreeBSD 用のバンド幅管理ツールには、無料で手に入れられる ALTQ と、 Emerging Technologies から入手できる Bandwidth Manager という市販のものの 2 種類があります。 なぜ /dev/bpf0: device not configured が出るのでしょうか? バークレーパケットフィルタ (&man.bpf.4;) ドライバは、それを利用するプログラムを実行する前に有効にしておく必要があります。 カーネルコンフィグファイルに、次のように追加してカーネルの再構築をしてください。 pseudo-device bpfilter # Berkeley Packet Filter そして再起動してから、次にデバイスノードを作成する必要があります。 これは、次のように入力し、/dev を変更することで行ないます。 &prompt.root; sh MAKEDEV bpf0 デバイスノードの作成の詳細は、 FreeBSD ハンドブックの「デバイスノード」を参照してください。 Linux の smbmount のように、 ネットワーク上の Windows マシンのディスクをマウントするにはどうしたら良いのでしょう? Ports Collection に含まれる sharity light パッケージを使ってください、 icmp-response bandwidth limit 300/200 pps というメッセージがログファイルに現れるのですが、 どういうことでしょう? これは、カーネル自身から「ICMP や TCP のリセット (RST) 応答を、妥当な数よりも多く送っている」ということを、 あなたに伝えるメッセージです。 ICMP 応答は良く、使われていない UDP ポートに接続しようとした結果として生成されます。 また、TCP リセットはオープンされていない TCP ポートに接続しようとした結果として生成されます。 その他、これらのメッセージが表示される原因となる状況として、 以下のようなものがあります。 (特定のセキュリティ上の弱点を悪用しようとする攻撃ではなく) 膨大な数のパケットを使った強引なサービス妨害 (DoS) 攻撃。 (一部のウェルノウンポートを狙ったものではなく) 非常に広い範囲のポートに接続を試みるポートスキャン。 メッセージ中の最初の数字は、 上限を設定しなかった場合にカーネルが送っていたであろうパケットの数を示し、 二番目の数字は、パケット数の上限値を示します。 この上限値は net.inet.icmp.icmplim という sysctl 変数を使うことで、以下のように変更可能です。 ここでは上限を 1 秒あたりのパケット数で 300 にしています。 &prompt.root; sysctl -w net.inet.icmp.icmplim=300 カーネルの応答制限を無効にせず、 ログファイル中のメッセージだけを抑制したい場合、 net.inet.icmp.icmplim_output sysctl 変数を次のようにすることで出力を止めることができます。 &prompt.root; sysctl -w net.inet.icmp.icmplim_output=0 最後に、もし応答制限を無効にしたい場合は、 net.inet.icmp.icmplim sysctl 変数に (上の例のようにして) 0 を設定することで実現できます。 ただし応答制限を無効化するのは、上記の理由からおすすめしません。 PPP ppp が動きません。どこを間違えているのでしょう? まず &man.ppp.8; のマニュアルと、 FreeBSD ハンドブックの「PPP」を読んでみましょう。 次に、 set log Phase Chat Connect Carrier lcp ipcp ccp command という命令を ppp のコマンドプロンプトに対して打ち込むか、 設定ファイル /etc/ppp/ppp.conf に加えて (default セクションの先頭に加えるのが一番良いでしょう) ログを有効にしてみてください。 その際、 /etc/syslog.conf (&man.syslog.conf.5; 参照) に !ppp *.* /var/log/ppp.log と書かれた行が含まれているか、また、 /var/log/ppp.log が存在しているかどうか確かめておいてください。 さて、これで何が起きているのか突き止めるために、 ログファイルからたくさんの情報を得られるようになりました。 ログに訳の分らない部分があっても心配ご無用。 あなたが助けを求めた誰かにとっては、 その部分が意味をなす場合があるのです。 訳注 ログの取得に syslog を使用するようになったのは 2.2.5 以降からです。 使用中の ppp のバージョンで set log 命令を解釈しない場合は、最新版をダウンロードすべきです。 FreeBSD の 2.1.5 以降でビルドできます。 ppp を実行するとハングします ホスト名の解決がうまくいっていないのでしょう。まず、 リゾルバ (resolver) が /etc/hostsを参照するように、 /etc/host.conf の最初の行に host と書き込んでください。 つぎに、/etc/hosts に使用しているマシンのエントリを書き加えます。 ローカルでネットワークを使用していない場合は、 localhost の行を以下のように変更してください。 127.0.0.1 foo.bar.com foo localhost 使用しているホストのエントリを追加してもかまいません。 詳細は関連するマンページを参照してください。 ppp が モードでダイアルしてくれない まず最初に、デフォルトルートが確立しているかどうかチェックしてください。 netstat -rn (&man.netstat.1; 参照) を実行すると、以下のような情報が表示されるはずです。 Destination Gateway Flags Refs Use Netif Expire default 10.0.0.2 UGSc 0 0 tun0 10.0.0.2 10.0.0.1 UH 0 0 tun0 これはあなたがハンドブックやマニュアル、 ppp.conf.sample の中で出てくるアドレスを使用していると仮定した場合の例です。 デフォルトルートが確立していない場合、 ppp.conf の中の HISADDR が理解できない、 古いバージョンの &man.ppp.8; が走っている可能性があります。 FreeBSD 2.2.5 より前のバージョンに付属していた ppp を使用している場合、 add 0 0 HISADDR と書かれた行を以下のように修正してください。 add 0 0 10.0.0.2 netstat -rn でデフォルトルートの情報が表示されない場合、もう一つ、 /etc/rc.conf (&man.rc.conf.5; 参照) (2.2.2 より前のリリースでは /etc/sysconfig と呼ばれていました) の中でデフォルトのルータを誤って設定し、 ppp.conf から delete ALL の行をうっかり消してしまった可能性があります。 この場合は、 FreeBSD ハンドブックの「システムの最終設定」の項を読み直してください。 No route to host とはどういう意味ですか? このエラーは通常、 /etc/ppp/ppp.linkup に以下のようなセクションが無い場合に起こります。 MYADDR: delete ALL add 0 0 HISADDR これは動的 IP アドレスを使用している場合、 またはゲートウェイのアドレスを知らない場合にのみ必要な設定です。 インタラクティブモードを使用している場合、 パケットモードに入った後で (プロンプトが PPP と大文字に変わったらパケットモードに入ったしるしです)、 以下の命令を入力してください。 delete ALL add 0 0 HISADDR 詳しい情報については、 FreeBSD ハンドブックの「PPP と動的 IP 設定」の項を参照してください。 3 分ほど経つと接続が切れてしまう ppp のタイムアウトは デフォルトでは 3 分です。 これは set timeout NNN という命令によって調整することができます。 NNN には、 接続が切れるまでのアイドル時間が秒数で入ります。 NNN が 0 の場合、 タイムアウトによる切断は起こりません。 このコマンドは ppp.conf に入れることも、 インタラクティブモードでプロンプトから入力することも できます。 ソケットを用いる &man.telnet.1; か &man.pppctl.8; を使用し、 ppp サーバに接続することによって、 回線がアクティブな間に限定してタイムアウトの時間を調整することも可能です。 訳注 pppctl は 2.2.5R からです。 詳しい情報は &man.ppp.8; のマニュアルページを参照してください。 負荷が高いと接続が切れてしまう Link Quality Reporting (LQR) の設定を行っている場合、 マシンと接続先の間で非常にたくさんの LQR パケットが失われている可能性があります。結果として ppp は回線の具合いが悪いと考え、 回線を切断するのです。2.2.5 より前のバージョンの FreeBSD では LQR はデフォルトで有効になっています。 現在ではデフォルトの状態で無効です。 LQR は以下の命令で無効にすることができます。 disable lqr 接続がランダムに切れてしまう ノイズの多い回線、あるいは待ち機能付きの回線では、 時々モデムが (誤って) キャリアを失ったと思い込み、 回線が切断されてしまうことがあります。 大多数のモデムでは、 一時的なキャリアの喪失をどれくらいの時間で検出するかを、 設定で決めることができます。 たとえば USR Sportster では、S10 レジスタ の値を 10 倍した秒数がその値になります。 この場合、モデムをもっとのんびり屋さんにするには、 dial 行に次のような文字列を加えると良いでしょう。 set dial "...... ATS10=10 OK ......" 詳しくはお使いのモデムのマニュアルをご覧ください。 接続が不規則にハングアップしてしまう たくさんの人が、原因不明のハングアップを経験しています。 検証のために必要なのは、まずどちら側のリンクでそれが起こっているか、 ということです。 外部接続型モデムを利用しているなら、 単に ping を使うことで、 データを送信するときに TD ランプが点灯するかどうかを確認することができます。 もし、TD ランプが点灯して、 RD ランプが点灯しなければ、 問題は回線の向こう側にあります。TD が点灯しなければ、 問題は回線のこちら側です。内蔵型モデムの場合、 ppp.conf ファイルに set server コマンドを入れる必要があるでしょう。 回線が切断されたとき、pppctl を使って ppp に接続してください。 そのとき、 ネットワーク接続が急に復旧 (診断ソケットへのアクセスで、 ppp が復活します) するか、 もしくは接続自体が全くできない (ただし、 ppp 起動時に set socket コマンドがちゃんと実行されているとします) としたら、 問題は回線のこちら側です。 もし、接続可能で、かつ状況が変化しなければ、 set log local async を使ってローカル非同期ログ (async logging) を有効にし、 ping を他のウィンドウかターミナルから使ってください。 非同期ログには、こちら側のリンクの送受信データが記録されます。 もし、データが送信されたにもかかわらず返って来ていなければ、 問題は回線の向こう側にあることになります。 問題が回線のどちら側かにあることが分かったら、 つぎの二つの可能性が考えられるでしょう。 回線の向こう側での反応がない これに対処できることはほとんどありません。大部分の ISP は、Microsoft 社製 OS 以外の利用者に対してのサポートを拒否するでしょう。 ppp.conf ファイルの中に enable lqr を記述することで ppp が回線の向こう側で発生する切断を検出することができますが、 この検出は比較的遅いため、あまり役に立ちません。また、あなたは user-ppp を利用していることを ISP に知られたくないと思うかも知れませんね。 まず最初に、こちら側の圧縮機能をすべて無効にしてみてください。 それには、設定ファイルをつぎのようにします。 disable pred1 deflate deflate24 protocomp acfcomp shortseq vj deny pred1 deflate deflate24 protocomp acfcomp shortseq vj そして再接続し、変更前と同じように通信できることを確認します。 もしこれによって状況が改善されるか、完全に解決したら、 (上の設定のうち) どの設定で状況が変化したのかを、 色々な組合せで試してみてください。これは、ISP に問い合わせを行なうときの有効な情報となります (ただし、 あなたが Microsoft 社製品以外のものを利用していることも明らかにしてしまいますが)。 ISP に問い合わせを行なう前に、こちら側の非同期ログを有効にして、 接続がハングアップするまで待ってください。この作業は、 非常に多くのディスク空間を消費するかも知れません。 興味の対象となっているのは、通信ポートから最後に読み込まれたデータです。 それは通常 ASCII データで、 問題点の詳細 (Memory fault, core dump など) が 記載されている可能性があります。 回線の向こう側で通信ログを監視することは可能なはずですので、 切断が発生した時、ISP の対応が好意的ならば どうして ISP 側で問題が発生したのかこちらに伝えてくれるかも知れません。 brian@Awfulhak.org まで詳細を送って頂くか、ISP に直接私に連絡するように伝えて下さっても構いません。 ppp がハングアップする ベストな方法は、 CFLAGS+=-g と STRIP= を ppp の Makefile に追加して、 ppp を再構築し、 そして make clean && make && make install を行なうことです。 ppp がハングアップした時、 ps ajxww | fgrep ppp を使って ppp のプロセス ID を調べ、 gdb ppp PID を実行してください。 gdb のプロンプトから、 bt を使ってスタックをトレースすることができます。 スタックトレースの結果は、brian@Awfulhak.org まで送ってください。 Login OK! のメッセージが出た後、何も起こらない 2.2.5 より前のリリースの FreeBSD では、 &man.ppp.8; はリンクが確立した後、接続先が Line Control Protocol (LCP) を発信するのを待ちます。しかし、多くの ISP ではネゴシエーションを自分からは起こさず、 クライアントが起こすのを待っています。 ppp に強制的に LCP を発信させるには、 次の命令を使います。 set openmode active 両方の側がネゴジェーションを起こしても、 大抵の場合は何の問題もありません。 ですから、現在では openmode はデフォルトで active になっています。 次のセクションでこれが問題になる場合を説明します。 でもまだ magic is the same というエラーが出る 時折、接続直後のログに magic is the same というメッセージがあらわれることがあります。 このメッセージがあらわれても何も起きない場合もありますし、 どちらかの側が接続を切ってしまう場合もあります。 ppp の実装の多くはこの問題に対応できておらず、 その場合にはちゃんと link が上がっている状態であっても、 ppp が最終的にあきらめてしまい、 接続を切るまで設定のリクエストが繰り返し送られ、 設定が行われたという通知がログファイルに残ると思います。 これは通常、 ディスクアクセスの遅いサーバマシンのシリアルポートで getty が生きていて、 ppp がログインスクリプトか、 ログイン直後に起動されたプログラムから実行されている場合に起こります。 slirp を使用している場合に同様の症状が見られたという報告もあります。 原因は getty の終了されるまでと、 ppp が実行され、 クライアント側の ppp が Line Control Protocol (LCP) を送り始めるまでのタイミングにあります。 サーバ側のシリアルポートで ECHO が有効なままになっているので、 クライアント側の ppp にパケットが「反射」してしまうのです。 LCP ネゴシエーションの一部として、 リンクの両サイドで magic number を定めて、 「反射」が起きていないかどうか確かめる作業があります。 規約では、接続相手がこちらと同じ magic number を提示してきたら、 NAK を送って新しい magic number を選択しなければならないと定めています。 この作業の間、サーバのシリアルポートの ECHO がずっと有効になったままなので、 クライアント側の ppp は LCP パケットを送り、 パケットが反射して全く同じ magic number が送られてくるのを見つけ、 それに対して NAK を送るのです。一方 NAK 自体も (これは ppp が magic number を変更しなければいけないことを意味しています) 反射してくるので、 結果として magic number が数えきれないほど変更され、 そのすべてがサーバの tty バッファの中に積み重なることになるのです。 サーバでスタートした ppp は、すぐに magic number であふれかえってしまい、 LCP のネゴシエーションを十分に行ったものと判断して、 さっさと接続を切ってしまいます。 一方、 クライアント側は反射が帰ってこなくなったので満足しますが、 それもサーバが接続を切ったことを知るまでです。 この事態は、以下の行を ppp.conf の中に書いて、 相手がネゴシエーションを開始できるようにする事によって回避できます。 set openmode passive これで ppp はサーバが LCP ネゴシエーションを起こすのを待つようになります。 しかし、 自分からは決してネゴジェーションを起こさないサーバもあるかもしれません。 もしこの状況に遭遇した場合には、次のようにしてください。 set openmode active 3 これによって ppp は 3 秒間 passive モードを続けた後で、 LCP リクエストを送り始めます。 この間に相手がリクエストを送り始めた場合には 3 秒間待たずにこのリクエストに即座に応答します。 接続が切れるまで LCP のネゴシエーションが続くのですが。 現在の ppp は、まだ LCP や CCP、 IPCP の返事が、 元のリクエストと連携してくれる機能がきちんと実装されていません。 その結果、ある ppp が相手よりも 6 秒以上遅い場合には、 - LCP 設定ののリクエストをさらに 2 回送ります。 + LCP 設定のリクエストをさらに 2 回送ります。 これは致命的な物です。 A と Bという 2 つの実装を考えてみましょう。 A が接続の直後に LCP リクエストを送り、 一方 B の方はスタートするのに 7 秒かかったとします。B がスタートする時には A は LCP リクエストを 3 回送ってしまっています。 前の節で述べた magic number の問題が起きないよう、 ECHO は off になっていると考えています。 B は REQ を送ります。 するとこれは A の REQ のうち、 最初の物に対する ACK となります。 結果として、A は OPENED の状態に入り、 B に対して (最初の) ACK を送ります。 そのうちに B は、 B がスタートする前に A から送られたもう 2 つの REQ に対する ACK を送り返します。 B は A からの最初の ACK を受け取り OPENED の状態に入ります。 A は B からの 2 つ目の ACK を受け取りますので、 REQ-SENTの状態に戻り、 さらに、RFC のとおりに (4 つ目の) REQ を送ります。そして 3 つ目の ACK を受け取って OPENED の状態に入ります。 一方、B は A からの 4 つ目の REQ を受け取りますので、 ACK-SENT の状態に入り、2 つ目の REQ と 4 つ目の ACK を RFC のとおりに送ります。 Aは、 REQ を受けとると REQ-SENT の状態になり、さらに REQ を送ります。 そしてすぐに ACK を受け取って OPENED の状態に入ります。 これが、片方の ppp があきらめてしまうまで続きます。 これを回避する最も良い方法は、 片方を passive モードに設定する、 すなわち反対側がネゴシエーションを開始するまで待つようにする事です。 これは、 set openmode passive というコマンドでできます。 このオプションは気を付けて使わないといけません。さらに set stopped N というコマンドを追加して、 ppp がネゴシエーションが開始するまで待つ 最大の時間を設定してください。もしくは、 set openmode active N というコマンド (ここで、 N はネゴシエーションが始まるまで待つ時間) を使うこともできます。 詳しくはマニュアルページを参照してください。 ppp が接続直後に固まってしまう 2.2.5 より前のバージョンの FreeBSD では、ppp が Predictor1 圧縮のネゴシエーションを誤って解釈して、 接続直後にリンクを無効にしている可能性があります。 これは両サイドが異なる Compression Control Protocols (CCP) を使ってネゴジェーションを行った場合にのみ発生します。 この問題は現在は解決していますが、あなたの走らせている ppp のバージョンが古い場合でも、次の命令で解決することができます。 disable pred1 ppp の内部でシェルを起動しようとすると固まってしまう shell あるいは ! コマンドを使用すると、 ppp はシェルを起動し (何か引数を渡した場合は、 ppp は引数も実行します)、 コマンドが終了するまで処理を中断します。 コマンドを実行中に ppp のリンクを使おうとすると、 リンクが固まっているように見えますが、 これは ppp がコマンドの終了を待っているからです。 このような場合は、代わりに !bg コマンドを使用してください。 与えられたコマンドがバックグラウンドで実行されるので、 ppp はリンクに関するサービスを継続することができます。 ヌルモデムケーブルを使用しているとき、 ppp が終了しない ヌルモデムケーブルを使用して直接接続している場合、 ppp は自動的には接続の終了を知ることができません。 これはヌルモデムシリアルケーブルの配線に起因しています。 この種の接続形態を用いる場合は、 以下の命令を用いて LQR を常に有効にする必要があります。 enable lqr こうすると、接続先がネゴシエーションを行う場合、デフォルトで LQR の使用を受け入れるようになります。 ppp を モードで動かすと、 勝手にダイアルすることがある ppp が思いもしないときにダイアルを始める場合、その原因を突き止め、 防止のためにダイヤルフィルタ (dfilters) をかけてやる 必要があります。 原因を突き止めるためには、以下の命令を使用してください。 set log +tcp/ip これで接続を通過するすべてのトラフィックをログに残すことができるようになりました。 次に突然回線がつながったときのログのタイムスタンプをたどれば、 原因を突き止めることができるはずです。 原因がわかったら、次に、このような状況ではダイヤルが起こらないようにしましょう。 通常、この手の問題は、DNS で名前の解決をしようとしたために起こります。 DNS による名前の解決によって、 接続が行われるのを防止するには、 次のような手段を用います (これは ppp の既に確立した接続に関してパケットのフィルタリングをするものではありません)。 set dfilter 1 deny udp src eq 53 set dfilter 2 deny udp dst eq 53 set dfilter 3 permit 0/0 0/0 これはデマンドダイヤル機能に問題を生じさせるため、 常に適切であるとはかぎりません。 ほとんどのプログラムは他のネットワーク関連の処理を行なう前に DNS への問い合わせが必要になります。 DNS の場合は、 何が実際にホスト名を検索しようとしているのかを突き止めるべきでしょう。 大抵の場合は、 &man.sendmail.8; が犯人です。 設定ファイルで sendmail が DNS に問い合わせないようになっているか確認すべきです。 自分用の設定ファイルを作成するための詳しい方法は、 メールの設定 の項をご覧ください。 または、 .mc ファイルに次のような行を追加してもよいでしょう。 define(`confDELIVERY_MODE', `d')dnl この行を追加すると、sendmail はメールキューを処理する (通常 sendmail は 30 分ごとにキューを処理するよう、 というオプションを付けて起動されます) までか、 または (多分 ppp.linkup というファイルの中で) sendmail -q というコマンドが実行されるまで、 すべてのメールをキューに溜めるようになります。 訳注 sendmail -q はその時点のメールキューの内容を処理して終了します。 CCP エラーとはどういう意味ですか ログファイル中の以下のエラーは、 CCP: CcpSendConfigReq CCP: Received Terminate Ack (1) state = Req-Sent (6) のネゴシエーションにおいて ppp は Predictor1 圧縮を用いるべく主張したのに対して、 接続先は圧縮を使用しないことを主張した場合に起こります。 このメッセージには何の害もありませんが、 出るのが嫌なら、以下の命令を用いてこちら側でも Predictor1 圧縮を無効にすることで対応できます。 disable pred1 ファイル転送の途中で、ppp が IO エラーを出して固まってしまう FreeBSD 2.2.2 以前のバージョンの tun ドライバには、tun インタフェースの MTU のサイズより大きなパケットを受け取ることができないというバグがありました。 MTU のサイズより大きなパケットを受け付けると IO エラーが起こり、 syslogd 経由で記録されるのです。 ppp の仕様では、 LCP のネゴシエーションを行う場合を含むどのような場合でも最低 1500 オクテットの Maximum Receive Unit (MRU) を受け入れる必要があります。 ですから、MTU を 1500 以下に設定した場合でも、ISP はそれに関係なく 1500 の大きさのパケットを送ってくるでしょう。 そしてこのイケてない機能にぶちあたって、 リンクが固まるのを目にすることになるのです。 FreeBSD 2.2.2 以前のバージョンでは、MTU を決して 1500 より小さくしないことで、 この問題を回避することができます。 どうして ppp は接続速度をログに残さないんでしょう? モデムとの「やり取り」すべての行をログに残すには、 以下のようにして接続速度のログの有効化を行ってください。 set log +connect これは &man.ppp.8; に最後にくることが要求されている expect という文字列がくるまでのすべてのものをログに記録させます。 接続速度はログにとりたいけれど、PAP や CHAP を使っている (その結果、ダイヤルスクリプト中の CONNECT 以降に全く「やりとり」を行わない - set login スクリプトには何も書かない) のであれば、 ppp に expect を含んだ CONNECT 行すべてがくるまで待たせるようにしないといけません、 以下のようになります。 set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 4 \"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n" ここで、CONNECT を受信してから、 何も送らず、復帰改行 (linefeed) を待っています、 ppp に CONNECT の応答すべてを読み込ませているわけです。 私の chat スクリプトでは \ という文字を PPP が解釈してくれません。 PPP は設定ファイルを読み込むときに、 set phone "123 456 789" のような文字列を正しく解釈し、 番号が実際に1 つの引数であると理解します。 " という文字を指定するには、バックスラッシュ (backslash; \) でエスケープしなければなりません。 chat の各引数が解釈されるときには、 \P や \T のような特別なエスケープシーケンス (マニュアルページ参照のこと) を見付けるために、 もう 1 回、字句解析を行います。 このように字句解析は 2 回繰り返されますので、 正しい回数だけエスケープ処理を行わないといけません。 モデムにたとえば \ のような文字を送りたい場合には、 次のようにする必要があります。 set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK" 実際にモデムに送られる文字列は次のようになります。 ATZ OK AT\X OK 他の例ですと set phone 1234567 set dial "\"\" ATZ OK ATDT\\T" は次のようになります。 ATZ OK ATDT1234567 ppp が segmentation fault になるのですが、 ppp.core ファイルがありません ppp (や他のプログラム) は決して core を吐いてはいけません。 ppp は実効 uid が 0 で動いていますので、 オペレーティングシステムは ppp を終了させる前にディスクに core イメージを書き込みません。 しかし ppp は実際にはセグメンテーション違反や、 他の core を吐く原因となるようなシグナルによって終了して おり、 さらに最新のバージョン (このセクションの始めを見てください) を使用しているならば、次のようにしてください。 &prompt.user; tar xfz ppp-*.src.tar.gz &prompt.user; cd ppp*/ppp &prompt.user; echo STRIP= >>Makefile &prompt.user; echo CFLAGS+=-g >>Makefile &prompt.user; make clean all &prompt.user; su &prompt.root; make install &prompt.root; chmod 555 /usr/sbin/ppp これでデバッグ可能なバージョンの ppp がインストールされます。 root で ppp を実行し、 すべての特権が無効になっているようにする必要があるでしょう。 ppp を実行する時には、 カレントディレクトリが make したディレクトリであるようにしてください。 これで、ppp がセグメンテーション例外を受け取ったときには ppp.core という名前の core ファイルを吐くようになります。core が 吐かれたら次のようにしてください。 &prompt.user; su &prompt.root; gdb /usr/sbin/ppp ppp.core (gdb) bt ..... (gdb) f 0 .... (gdb) i args .... (gdb) l ..... 質問する際には、これらすべての情報を提供して、 問題点の分析ができるようにしてください。 gdb の使い方に慣れている場合には、実際に dump の原因となった理由やそのアドレス、 関連した変数の値なども調べる事ができるでしょう。 auto モードでダイアルをするようなプロセスが接続されない。 これは ppp がローカル側の IP アドレスを、 動的に通信相手と交渉するように設定されている時に発生する良く知られた障害でした。 最新のバージョンでは、 この問題は修正されています。 iface をマニュアルページから検索してみてください。 これは、最初のプログラムが &man.connect.2; を呼び出した時、tun インターフェイスの IP アドレスが、 ソケットの終端に割り当てられてしまうという問題です。 カーネルは、 外へ出ていく最初のパケットを作り、それを tun デバイスへ書き込みます。 そして ppp は、 そのパケットを読み込んで接続を確立します。 ppp は動的に IP アドレスを割り当てるため、 もしインターフェイスのアドレスが変化してしまうと、 最初に割り当てられたソケット終端の IP アドレスは無効になってしまいます。 そのため、それ以降相手に送られるすべてのパケットは通常、 相手に届くことはないでしょう。もし仮に届いたとしても、 既にこちらの IP アドレスは変更されているので、 どんな反応も最初のマシンには戻ってきません。 この問題に対処する理論的な方法がいくつかあります。もし可能なら、 相手が再度、同じ IP アドレスを割り当ててくれることが一番です :-) ppp の現在のバージョンはこれを行ないますが、 他のほとんどの実装はそういった動作をしません。 我々の側から対処できる最も簡単な方法は、tun インターフェイスの IP アドレスを固定する事です。またそのかわりに、 外に出ていくパケットを変更して、 発信元 IP アドレスをインターフェイスの IP アドレスから、交渉によって得られた IP アドレスに、 適宜書きかえる事によっても対処できます。 これは、基本的に ppp の最新バージョンにある iface-alias オプションが行なっていることと同じです (&man.libalias.3; および、ppp の スイッチにも関係します)。それは、以前の IP アドレスをすべて管理し、 それらを最後の交渉によって得られた IP アドレスに対して NAT 機能を有効化します。 もう 1 つの (おそらく最も信頼できる) 方法は、bind された すべてのソケットの IP アドレスを、 異なるものに変更できるシステムコールを実装することです。 pppは、 交渉によって新しい IP アドレスを得た時、 このシステムコールを用いて実行されているプログラムにある、 すべてのソケットを書きかえてやるわけです。 同じシステムコールが、DHCP クライアントが利用するソケットを 強制的に再 bind するのにも使うことができるでしょう。 3 つ目の方法は、IP アドレスを指定しないでインターフェイスを利用できるようにすることです。 外に出ていくパケットは、最初の SIOCAIFADDR ioctl の完了まで、 255.255.255.255 という IP アドレスが与えられます。 これによって、ソケットは常に bind することができます。 ppp に対して発信元 IP アドレスを変更させる事になりますが、 もしそれが 255.255.255.255 になっていたら、IP アドレスと IP チェックサムだけ変更すれば良ければの話になります。 この方法はちょっとした変更ですが、 他の機構が今までのように、IP アドレスを固定して利用する場合に、 カーネルが不適切に設定されたインターフェイスに向けて、 正常でないパケットを送り出してしまう可能性があります。 何故ほとんどのゲームが スイッチ付きだと動かないんですか? libalias を使っている時にゲームなどの類のものが動作しない理由は、 外側にあるマシンが接続しようとしているか、内側にあるマシンに (余計な) UDP パケットを送信しようとしているからです。 内側のマシンにこれらのパケットを送るべきかについて、 NAT ソフトウェアは関知しません。 うまく動かすためには、 実行中のものが問題の発生しているソフトウェアだけであるかを確認し、 ゲートウェイの tun インタフェースに対して tcpdump を実行するか、 ゲートウェイ上で ppp の TCP/IP ログ記録を有効化 (set log +tcp/ip) してください。 行儀の悪いソフトウェアを起動する際に、 ゲートウェイマシンを通過するパケットを監視すべきです。 外側から何かパケットが戻ってきた時に、 そのパケットは破棄されるでしょう (それが問題なのです)。 これらのパケットのポート番号に注意して、 その行儀の悪いソフトウェアを停止してください。 これを数回繰り返してポート番号が常に同じであるかを確認してみてください。 同じであった場合は、 /etc/ppp/ppp.conf の適切なセクションに次の行を入れると、 そのソフトウェアは動作するようになるでしょう。 nat port proto internalmachine:port port ここで proto は tcp か udp であり、 internalmachine はパケットを送りたいマシン、そして port はパケットの送信先のポート番号です。 上記のコマンドを変更せずに、 他のマシン上でそのソフトウェアを使用できるようにはしたくないかもしれません。 そして同時に二つの内部のマシン上でそのソフトウェアを実行することは、 この質問の範囲を超えています。結局、外側の世界からは、 内部ネットワーク全体がただ一つのマシンとして見えるのです。 ポート番号が常に同じとは限らない場合、さらに三つのオプションがあります。 libalias でサポートするようにし、結果を送り付ける。 特定の場合の例は /usr/src/lib/libalias/alias_*.c にあります (alias_ftp.c は良いプロトタイプです)。これには通常、外向きの特定のパケットを読み、 内部の計算機のある特定のポートへの接続を開始するような命令が、 外部の計算機対して送られていることを見分け、 後続のパケットがどこに行けばいいのかが分かるように、 エイリアステーブル中の route の部分を設定する、という作業が含まれます。 これは最も難しい方法ですが、最も良い方法でもありますし、ソフトウェアが 複数の計算機で動くようにできます。 プロキシ (proxy) を使う。アプリケーションが、たとえば socks5 をサポートしているか、(cvsup のように) passive オプションを持っているとこの方法が使えます。 passive とは相手側のほうから接続を求めてくることを避けるためにあるオプションです。 nat addr を使ってなんでもかんでも内部の計算機に向けて流してしまう。 これはちょっと無理矢理な解決法です。 有用なポート番号のリストはありませんか? まだ出来ていません。しかし、 これは (関心を持って頂けるならば) そういったリストにしていく予定です。 それぞれの例にある internal は、 ゲームで遊ぶマシンの IP アドレスに置き換えてください。 Asheron's Call nat port udp internal:65000 65000 手動でゲームのポート番号を 65000 に変更してください。 マシンが複数ある場合は、それぞれのマシンに重複しないポート番号 (つまり 65001、65002 など) を設定し、その設定ごとに nat port の行を追加します。 Half Life nat port udp internal:27005 27015 PCAnywhere 8.0 nat port udp internal:5632 5632 nat port tcp internal:5631 5631 Quake nat port udp internal:6112 6112 このように設定する代わりに、 www.battle.net で Quake のプロキシ (proxy) がサポートされているか調べてもいいでしょう。 Quake2 alias port udp internal:27901 27910 Red Alert nat port udp internal:8675 8675 nat port udp internal:5009 5009 FCS エラーって何? FCS とは Frame Check Sequence (フレームチェックシーケンス) の略です。 個々の ppp パケットには、 送受信するデータが正しいかを調べるためのチェックサムが含まれています。 受信したパケットの FCS が正しくない場合は、そのパケットは廃棄され、 HDLC FCS カウントが増やされます。 HDLC エラーの数は、 show hdlc コマンドを使って表示できます。 リンクの品質が悪かったり、 シリアルドライバがパケットを取りこぼしていたりすると、 FCS エラーがたびたび発生します。 FCS エラーは、 圧縮プロトコルの速度低下の原因にはなりますが、 特に心配する必要はありません。 外付けモデムを使っている場合は、 ケーブルがちゃんとシールドされているかを確認してください。 そうでない場合、 FCS エラーの原因となる場合があります。 接続直後からリンクがフリーズし、大量の FCS エラーが発生する場合は、 リンクが 8 ビットクリーンでない可能性があります。 ソフトウェアフロー制御 (XON/XOFF) が使われていないことを確認してください。 どうしてもソフトウェアフロー制御を使わなければならない場合は、 set accmap 0x000a0000 コマンドを使用して、 ppp に ^Q と ^S をエスケープさせてください。 リモートホストが PPP プロトコルを使用してない場合も、大量の FCS エラーが発生します。 この場合はログをとりながら非同期で接続し、 ログインプロンプトやシェルプロンプトが送られて来ていないか確認してください。 ログファイルにリンクを終了した原因となるような記録がない場合は、 リモートホスト (プロバイダ?) の管理者に、 セッションを終了された理由を尋ねてください。 ゲートウェイで PPPoE を実行すると MacOS や Windows 98 との接続がフリーズしてしまうのですが、 これはなぜなのでしょうか? Michael Wozniak mwozniak@netcom.ca 氏が、この現象に関して説明してくれました。 また、Dan Flemming danflemming@mac.com 氏は MacOS での解決策を提供してくれました。 情報の提供に感謝します。 これは、いわゆる「ブラックホールルータ (Black Hole router)」に原因があります。 Windows 98 と MacOS (および、おそらく他の Microsoft 社製 OS) の TCP パケット送出は、 PPPoE のフレーム (Ethernet の MTU は標準で 1500) に入らないような大きなセグメントサイズを要求します。 そしてさらに分割禁止 ("don't fragment") フラグビットを (TCP パケットにデフォルトで) セットするのですが、 Telco のルータは、分割が必須 ("must fragment") であることを示す ICMP メッセージを、接続しようとするウェブサイトに対して送出しません (つまり、ルータは正しく ICMP パケットを送出しているのですが、 ウェブサイトのファイアウォールがそれを落としているのです)。 そのためウェブサーバが PPPoE 接続に対して大きすぎるフレームを送出すると Telco のルータはそのフレームを捨ててしまい、 見ようとしたページが表示されないという症状が現われます (MSS より小さいページや画像は表示されます)。 ほとんどの Telco PPPoE 設定は、標準でこのように設定されているようです。 (ああ、彼らがルーティングプログラムの作り方を理解してさえいれば…)。 一つの解決法は、Windows 95/98 マシンで regedit を使い、 次のレジストリエントリを追加することです。 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\NetTrans\0000\MaxMTU レジストリエントリは、1450 の値 (もっと正確に言うと、TCP パケットを PPPoE フレームに完全に適合させるには 1464 であるべきでですが、 1450 とすると、現われる可能性がある他の IP プロトコルに対してエラーマージンを確保することができます) にする必要があります。 このレジストリキーは、Windows2000 で Tcpip\Parameters\Interfaces\ID for adapter\MTU に移されたという報告がありました。 FreeBSD/NAT/PPPoE ルータと共存させるために Windoze の MTU を変更する方法に関する詳細は、 Microsoft Knowledge Base にある、 番号 Q158474 - Windows TCPIP Registry Entries、 および番号 Q120642 - TCPIP & NBT Configuration Parameters for Windows NT を参照してください。 残念なことに、MacOS には TCP/IP 設定を変更する方法がありません。 しかし、Sustainable Softworks 社 が販売している OTAdvancedTuner (OT は OpenTransport という MacOS の TCP/IP スタックの名前のこと) のような商用ソフトウェアが存在します。 このソフトウェアは、ユーザから TCP/IP 設定の変更を行なうことを可能にします。 MacOS NAT ユーザはドロップダウンメニューから ip_interface_MTU を選択し、 ボックスにある 1500 の代わりに 1450 を入力し、 Save as Auto Configure の隣のボックスをクリックして Make Active をクリックする必要があります。 ppp の最新版 (2.3 かそれ以降) には、自動的に MSS を適切な値に調節する enable tcpmssfixup コマンドがあります。 この機能は標準で有効になっています。 もし旧バージョンの ppp を使わなければならない状況にあるなら、 tcpmssd の port をご覧になると良いでしょう。 どれにも当てはまらない! どうしたらいいの? これまでのすべての質問に当てはまらない場合、設定ファイル、 ppp の実行方法、ログファイルの該当部分と netstat -rn コマンドの出力 (接続前と接続後) を含む、 あなたの持っているすべての情報を &a.questions; や comp.unix.bsd.freebsd.misc ニュースグループへ送ってください。誰かがあなたを正しい方向へ導いてくれるでしょう。 シリアル接続 訳: 一宮 亮 ryo@azusa.shinshu-u.ac.jp、 1997 年 11 月 16 日 このセクションでは、FreeBSD でシリアル接続をする時の一般的な質問に答えます。 PPP および SLIP については、 のセクションを参照してください。 どうやったら FreeBSD がシリアルポートを認識したことを知る事ができますか? FreeBSD のカーネルが起動する時、カーネルはその設定にしたがって、 システムのシリアルポートを検出します。起動時に表示されるメッセージをよく観察するか、 起動後に次のコマンドを実行する事によって確認できます。 dmesg | grep sio ここに上に挙げたコマンドの出力例を示します。 sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A これは、二つのシリアルポートを示しています。1 番目は、 irq が 4 で 0x3f8 のポートアドレスを使用しています。 そして、16550A-type UART チップが存在します。 2 番目は、同じチップを使っていますが、 irq は 3 で、0x2f8 のポートアドレスを使用しています。内蔵のモデムカードは、 通常のシリアルポートと同じように扱われますが、 常時シリアルポートにモデムが接続されているという点で異なります。 GENERIC カーネルは、上の例と同じ irq とポートアドレスの設定の二つのシリアルポートをサポートしています。 これらの設定があなたのシステムに合わない場合、 またはモデムカードを追加した場合やカーネルの設定以上にシリアルポートを持っている場合は、 カーネルを再構築してください。 詳しくは、 カーネルの構築の項を参照してください。 どうやったら FreeBSD がモデムカードを認識したことを知ることができますか? 前の質問を参照してください。 FreeBSD 2.0.5 にアップグレードしたら tty0X が見つからなくなってしまったのですが 心配ありません。ttydX に統合されました。 ただ、古い設定ファイルのすべてを更新する必要があります。 どうやったら FreeBSD でシリアルポートにアクセスできますか? 3 番目のポート sio2 (&man.sio.4; をご覧ください。DOS では、COM3 と呼ばれます。) には、 ダイヤルアウトデバイスとしては /dev/cuaa2、 ダイヤルインデバイスとして /dev/ttyd2 があります。 それではこの両者にはどのような違いがあるのでしょうか? まず、ダイヤルインの時には ttydX を使います。 /dev/ttydX をブロッキングモードでオープンすると、 プロセスは対応する cuaaX デバイスがインアクティブになるのを待ちます。 次に CD 信号がアクティブになるのを待ちます。 cuaaX デバイスをオープンすると、シリアルポートが ttydX デバイスによってすでに使われていないかどうかを確認します。 もしこのポートが使用可能であれば、ポートの使用権を ttydX から「奪い取る」のです。 また、cuaXX デバイスは CD 信号を監視しません。 この仕組みと自動応答モデムによって、 リモートユーザーをログインさせたり、 同じモデムでダイヤルアウトしたりすることができ、 システムのあらゆるトラブルの面倒を見ることができるでしょう。 マルチポートシリアルカードをサポートさせるにはどうしたらよいのでしょうか? 繰り返しになりますが、 カーネルコンフィグレーションのセクションでは、 あなたのカーネルの設定についての情報が得られるでしょう。 マルチポートシリアルカードを使用するためには、カーネルの設定ファイルに、 カードの持つそれぞれのシリアルポートに対応する &man.sio.4; の行を記述する必要があります。しかし、 irq とベクタアドレスは一つのエントリにのみ記述してください。 カード上のすべてのポートは一つの irq を共有しなければなりません。 一貫性を持たせるためにも、 最後のシリアルポートの所で irq を指定してください。 また、COM_MULTIPORT オプションも付けてください。 次に示す例は、AST の 4 ポートシリアルカードを irq 7 で設定したものです。 options "COM_MULTIPORT" device sio4 at isa? port 0x2a0 tty flags 0x781 device sio5 at isa? port 0x2a8 tty flags 0x781 device sio6 at isa? port 0x2b0 tty flags 0x781 device sio7 at isa? port 0x2b8 tty flags 0x781 irq 7 vector siointr このフラグはマスタポートがマイナー番号 7 (0x700) を持っていて、 検出時の診断機能を有効にし (0x080)、 そしてすべてのポートで irq を共有する (0x001) ということを意味しています。 FreeBSD で複数のマルチポートシリアルカード間で irq を共有することはできますか? 現在のところはできません。それぞれのカード毎に異なった irq を使ってください。 ポートにデフォルトのパラメータを設定する事は出来ますか? ttydX デバイス (または cuaaX デバイス) は、 アプリケーションのためにオープンする標準的なデバイスです。 プロセスがそのポートをオープンする時、 プロセスはデフォルトの端末 I/O 設定を取得します。 これらの設定は次のコマンドで確認することができます。 stty -a -f /dev/ttyd1 このデバイスに対する設定を変更した場合、 その設定はデバイスをクローズするまで有効です。 デバイスを再オープンした場合、それらの設定はデフォルトに戻ってしまいます。 デフォルトの設定に変更を加えるために、 「初期設定」デバイスをオープンし、 設定を修正することができます。 たとえば、CLOCAL モード、8 ビット、 XON/XOFF フロー制御という設定を ttyd5 のデフォルトにしたい場合、次のように行なってください。 stty -f /dev/ttyid5 clocal cs8 ixon ixoff この設定を行なうためのコマンドを記述するのに適切なファイルは、 /etc/rc.serial です。 これでアプリケーションが ttyd5 をオープンした時に、 これらの設定をデフォルトで取得します。 しかし、こういったリンクによる設定は変更可能です。 「設定固定」デバイスを調整してやることによって、 アプリケーションによる設定の変更を禁止することができます。 たとえば、ttyd5 の通信速度を 57600bps に固定するには、次のように行ってください。 stty -f /dev/ttyld5 57600 これにより、アプリケーションは ttyd5 をオープンし、ポートの通信速度を変更しようとしますが、 通信速度は 57600bps のままになります。 当然のことながら、初期設定デバイスおよび、設定固定デバイスは root のみが書き込みできるようになっていなければなりません。 しかし、&man.MAKEDEV.8; スクリプトはデバイスエントリを作成する時に、 このような設定は行いません。 どのようにしたらモデム経由でダイヤルアップログインができるのでしょうか? つまり、インターネットサービスプロバイダーになりたいのですね。 それにはまず、1 台ないし複数の自動応答モデムが必要です。 モデムには、キャリアーを検出した時には CD 信号を出力し、 そうでない場合には出力しないことが必要とされます。 また DTR 信号が on から off になった時には、 電話回線を切断し、モデム自身をリセットしなければなりません。 おそらく、RTS/CTS フロー制御を使うか、 ローカルフロー制御をまったく使わないかのどちらかでしょう。 最後に、コンピュータとモデムの間は固定速度でなければなりません。 ただ、(ダイヤルアップの発呼者に対して親切であるためには、 ) こちらのモデムと相手側のモデムの間の速度を、 モデム間で自動調整できるようにすべきでしょう。 多くあるヘイズコマンド互換モデムに対して、次のコマンドはこれらの設定を行ない、 その設定を不揮発性メモリーに保存します。 AT&C1&D3&K3&Q6S0=1&W MS-DOS のターミナルプログラムに頼らずに AT コマンドを送出するには、 「AT コマンドを入力するには」のセクションを参照してください。 次に、モデム用のエントリを /etc/ttys (&man.ttys.5; 参照) に作成しましょう。 このファイルには、 オペレーティングシステムがログインを待っているすべてのポートが記述されています。 以下のような行を追加してください。 ttyd1 "/usr/libexec/getty std.57600" dialup on insecure この行は、2 番目のシリアルポート (/dev/ttyd1) には、 57600bps の通信速度でノンパリティ (std.57600: これは /etc/gettytab に記述されています。&man.gettytab.5; 参照) のモデムが接続されていることを示しています。 このポートの端末タイプは dialup です。 またこのポートは、on すなわちログイン可能であり、 insecure これは root がこのポートから直接ログインするのは、 許可されていないということを意味します。 このようなダイヤルインポートに対しては、 ttydX のエントリを使用してください。 これが一般的な、ターミナルタイプとして dialup を使う方法です。多くのユーザーは、 .profile や .login で、 ログイン時の端末タイプが dialup であった場合には、 実際の端末タイプをユーザーに問い合わせるように設定しています。 この例は、ポートが insecure でした。このポートで root になるには、 一般ユーザーとしてログインし、それから su を使って root になってください。 もし、secure を指定したならば、 直接 root がそのポートからログインできます。 /etc/ttys に変更を加えた後は、HUP シグナル (SIGHUP) を &man.init.8; プロセスに送る必要があります。 &prompt.root; kill -HUP 1 この操作は init プロセスに /etc/ttys を再読み込みさせます。 これにより、init プロセスは getty プロセスをすべての on となっているポートに起動させます。 次のようにして、ポートがログイン可能かを知ることができます。 &prompt.user; ps -ax | grep '[t]tyd1' ログイン可能であれば、次のような出力が得られるはずです。 747 ?? I 0:00.04 /usr/libexec/getty std.57600 ttyd1 ダムターミナルを FreeBSD マシンに接続するにはどうしたらよいのでしょうか? もし、他のコンピューターを FreeBSD の端末として接続したいのならば、 お互いのシリアルポート間をつなぐヌルモデムケーブル (訳注: リバースケーブルもしくはクロスケーブルとも呼ばれます) を用意してください。 もし、既製の端末を使う場合は、付属するマニュアルを参照してください。 そして、/etc/ttys (&man.ttys.5; 参照) を上と同じように変更してください。 たとえば、WYSE-50 という端末を 5 番目のポートに接続するならば、 次のようなエントリを使用してください。 ttyd4 "/usr/libexec/getty std.38400" wyse50 on secure この例は、/dev/ttyd4 ポートにノンパリティ、 端末タイプが wyse50、通信速度が 38400bps (std.38400: この設定は、 /etc/gettytab に記述されています。&man.gettytab.5; 参照) の端末が存在しており、 root のログインが許可されている (secure) であることを示しています。 どうして tip や cu が動かないのですか? おそらくあなたのシステムでは &man.tip.1; や &man.cu.1; は uucp ユーザーか、 dialer グループによってのみ実行可能なのでしょう。 dialer グループは、 モデムやリモートシステムにアクセスするユーザーを管理するために、 使用することができます。 それには、/etc/group ファイルの dialer グループにあなた自身を追加してください。 そうする代わりに、次のようにタイプすることにより、 あなたのシステムの全ユーザーが tip や cu を実行できるようになります。 &prompt.root; chmod 4511 /usr/bin/cu &prompt.root; chmod 4511 /usr/bin/tip 私の Hayes モデムはサポートされていないのですが、 どうしたらいいのでしょうか。 実際、 &man.tip.1; のオンラインマニュアルは古くなっています。 すでに、Hayes ダイアラが実装されています。 /etc/remote ファイル (&man.remote.5; 参照) で、 at=hayes と指定してください。 Hayes ドライバは、最近のモデムの新しい機能である、 BUSY、 NO DIALTONE、 CONNECT 115200 などのメッセージを認識できるほど賢くはなく、 単に混乱を起こすだけです。 &man.tip.1; を使う場合には (ATX0&Wとするなどして)、 これらのメッセージを表示させないようにしなくてはいけません。 また、tip のダイヤルのタイムアウトは 60 秒です。 モデムのタイムアウト設定はそれより短くすべきであり、 そうしないと tip は通信に問題があると判断するでしょう。 ATS7=45&W を実行してください。 実際、デフォルトの tip は Hayes の完全なサポートをしているわけではありません。 解決方法は /usr/src/usr.bin/tip/tip の下の tipconf.h を変更することです。 もちろん、これにはソース配布ファイルが必要です。 #define HAYES 0 と記述されている行を #define HAYES1 と変更し、そして make と make install を実行します。これでうまく動作するでしょう。 これらの AT コマンドを入力するには? /etc/remote ファイル (&man.remote.5; 参照) の中で direct エントリを作ります。 たとえばモデムが 1 番目のシリアルポートである /dev/cuaa0に接続されている場合、 次のようにします。 cuaa0:dv=/dev/cuaa0:br#19200:pa=none モデムがサポートする最大の bps レートを br フィールドに使います。 そして tip cuaa0 (&man.tip.1; 参照) を実行すると、モデムが利用できるようになります。 /dev/cuaa0がシステムに存在しない場合は、次のようにします。 &prompt.root; cd /dev &prompt.root; ./MAKEDEV cuaa0 または root になって以下のように cu コマンドを実行します。 &prompt.root; cu -lline -sspeed line にはシリアルポート (たとえば /dev/cuaa0)を指定します。 そして speed には接続する速度 (たとえば 57600) を指定します。 その後 AT コマンドを実行したら、 ~. と入力すれば終了します。 pn 機能の <@> 記号が使えません! 電話番号 (pn) 機能の中での <@> 記号は、 tip に /etc/phones にある電話番号を参照するように伝えます。しかし <@> の文字は /etc/remote のような設定ファイルの中では特殊文字となります。 そこで、バックスラッシュを使ってエスケープを行います。 pn=\@ コマンドラインから電話番号を指定するには? generic エントリと呼ばれるものを /etc/remote ファイル (&man.remote.5; 参照) に追加します。 たとえば、次のようにします。 tip115200|Dial any phone number at 115200 bps:\ :dv=/dev/cuaa0:br#115200:at=hayes:pa=none:du: tip57600|Dial any phone number at 57600 bps:\ :dv=/dev/cuaa0:br#57600:at=hayes:pa=none:du: そして tip -115200 5551234 のように利用できます。 &man.tip.1; より &man.cu.1; を使いたい場合、 cu の generic エントリを使います。 cu115200|Use cu to dial any number at 115200bps:\ :dv=/dev/cuaa1:br#57600:at=hayes:pa=none:du: そして cu 5551234 -s 115200 と実行します。 毎回 bps レートを入力しなければいけませんか? tip1200 や cu1200 用のエントリを記述し、 適切な通信速度を br フィールドに設定します。 &man.tip.1; は 1200bps が正しいデフォルト値であるとみなすので、 tip1200 エントリを参照します。 もちろん 1200bps を使わなければならないわけではありません。 ターミナルサーバを経由して複数のホストへアクセスしたいのですが。 毎回接続されるのを待って CONNECT <host> と入力するかわりに、 tip の cm 機能を使います。 たとえば、/etc/remote (&man.remote.5; 参照) に次のようなエントリを追加します。 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 ファイル (&man.remote.5; 参照) に作成して、 pn のフィールドには <\@> を使います。 big-university:\ :pn=\@:tc=dialout dialout:\ :dv=/dev/cuaa3:br#9600:at=courier:du:pa=none: そして /etc/phones ファイル (&man.phones.5; 参照) に大学の電話番号の一覧を書きます。 big-university 5551111 big-university 5551112 big-university 5551113 big-university 5551114 &man.tip.1; は一連の電話番号を上から順に試みて、 最終的に接続できなければあきらめます。リトライを続けさせたい場合は、 tip を while ループに入れて実行します。 CTRL+P を 1 回送るために 2 度押す必要があるのはなぜ? CTRL+P は通常「強制 (force)」文字であり、 &man.tip.1; に次の文字がリテラルデータであることを伝えます。 強制文字は「変数の設定」を意味する ~s エスケープによって、 他の文字にすることができます。 ~sforce=<single-char> と入力して改行します。 <single-char> は、任意の 1 バイト文字です。 <single-char> を省略すると NUL 文字になり、 これは CTRL+2 や CTRL+SPACE を押しても入力できます。 いくつかのターミナルサーバで使われているのを見ただけですが、 <single-char> に SHIFT+CTRL+6 に割り当てるのもよいでしょう。 $HOME/.tiprc に次のように定義することで、 任意の文字を強制文字として利用できます。 force=<single-char> 打ち込んだ文字が突然すべて大文字になりました?? CTRL+A を押してしまい、caps-lock キーが壊れている場合のために設計された &man.tip.1; の raise character モードに入ったのでしょう。 既に述べた ~s を使って、 raisechar をより適切な値に変更してください。 もしこれら両方の機能を使用しないのであれば、 強制文字と同じ設定にすることもできます。 以下は CTRL+2 や CTRL+A などを頻繁に使う必要のある Emacs ユーザにうってつけの .tiprc ファイルのサンプルです。 force=^^ raisechar=^^ ^ は SHIFT+CTRL+6 です。 tip でファイルを転送するには? もし他の UNIX のシステムと接続しているなら、 ~p (送信) や ~t (受信) でファイルの送受信ができます。 これらのコマンドは、相手のシステムの上で &man.cat.1; や &man.echo.1; を実行することで送受信をします。書式は以下のようになります。 ~p <ローカルのファイル名> [<リモートのファイル名>] ~t <リモートのファイル名> [<ローカルのファイル名>] この方法ではエラーチェックを行いませんので、 zmodem などの他のプロトコルを使った方がよいでしょう。 tip から zmodem を実行するには? まず始めに、FreeBSD Ports Collection (lrzszと rzsz との、2 つの通信カテゴリーのプログラムのどちらか) をインストールします。 ファイルを受信するには、リモート側で送信プログラムを起動します。 そして、Enter キーを押してから ~C rz (lrzsz をインストールした場合は ~C lrz) と入力すると、 ローカル側へのファイルの受信が始まります。 ファイルを送信するには、リモート側で受信プログラムを起動します。 そして、Enter キーを押してから ~C sz <files> (lrzsz をインストールした場合は ~C lsz <files>) と入力すると、リモート側へのファイルの送信が始まります。 設定が正しいのにもかかわらず、FreeBSD がシリアルポートを見付けられません。 マザーボードやシリアルカードが Acer の UART チップを使った物の場合、 FreeBSD の sio ドライバでは正しく検出する事が出来ません。 この問題を解決するためには、 www.lemis.com からパッチを入手してください。 その他の質問 訳: &a.jp.yoshiaki;、 &a.jp.sugimura;、 福間 康弘 yasuf@big.or.jp、 1997 年 11 月 10 日 - 1999 年 5 月 8 日 FreeBSD は Linux より多くのスワップ領域を消費するのはなぜですか? 実際にはそうではありません。 FreeBSD は Linux よりもスワップを多く使っているように見えるだけです。 この点における FreeBSD と Linux の主な違いは、 FreeBSD はより多くのメインメモリを有効利用できるようにするため、 完全にアイドルになったものやメインメモリ上の使われなくなったページを、 スワップにあらかじめ積極的に移動しているということです。 Linux では、 最後の手段としてページをスワップに移動させるだけという傾向があります。 このスワップの使い方は、 メインメモリをより効果的に使用することによってバランスが保たれています。 FreeBSD はこのような状況では先手策を取りますが、 システムが本当に空き状態の時に、 理由も無くページをスワップしようと決めることはないということに注意してください。 したがって、 夜中に使わずにおいたシステムが朝起きたとき、 すべてページアウトされているということはないのです。 ほとんどプログラムは実行されていないのに、 どうして &man.top.1; は非常に少ない free memory を報告するのでしょうか? 簡単に言えば、free memory とは無駄になっているメモリのことだからです。 プログラムが確保しているメモリ以外のすべてのメモリは、 FreeBSD カーネル内でディスクキャッシュとして利用されます。 この値は &man.top.1; において Inact、 Cache Buf として表示され、 それぞれは異なるエージングレベル (訳注: データがどれだけ古いかを示す評価値) でキャッシュされた全データを表します。 データがキャッシュされると言うのは、 最近アクセスされたデータであれば、 再度そのデータをアクセスするためにシステムが遅いディスクにアクセスする必要がない、 ということを意味します。 そのため、全体のパフォーマンスが向上します。 一般的に、&man.top.1; で表示される Free メモリが小さい値を示すことは良いことで、 自由に使えるメモリの残量が本当に少ない、 ということを表しているわけではありません。 FreeBSD の実行フォーマットの a.out、ELF とはどのようなものですか? また、a.out、ELF を使う理由は何でしょう? FreeBSD が何故 ELF フォーマットを利用しているのかを理解するためには、 まず UNIXにおいて現在「優勢」な 3 種類の実行フォーマットについて いくらか知っておく必要があります。 FreeBSD 3.x より前の FreeBSD では a.out フォーマットが使われていました。 &man.a.out.5; 最も古く 「由緒正しい」 unix オブジェクトフォーマットです。 マジックナンバを含む短くてコンパクトなヘッダが先頭にあり、 これがフォーマットの特徴とされています (&man.a.out.5; に詳細な内容があります)。 ロードされる 3種類のセグメント、 .text、 .data、 .bss と加えてシンボルテーブルと文字列テーブルを含みます。 COFF SVR3 のオブジェクトフォーマットです。 ヘッダは単一のセクションテーブルから成り、 .text、 .data、 .bss セクション以外の部分を持つことができます。 ELF COFFの後継です。複数のセクションをサポートし、32-bit と 64-bitのいずれの値も可能です。大きな欠点の一つは、ELF はそれぞれのシステムアーキテクチャ毎に単一の ABI のみが存在するという仮定で設計されていることです。 この仮定はまったく正しくありません。 商用の SYSV の世界でさえそうです (少なくとも SVR4、 Solaris、SCO の 3種類の ABI があります)。 FreeBSD はこの問題を解決するための試みとして、 既知の ELF 実行ファイルに ABI に応じた情報を 書き加えるユーティリティを提供しています。 詳しくは &man.brandelf.1; のマニュアルページを参照してください。 FreeBSD は伝統的な立場をとり、数多くの世代の BSD のリリースで試され、実証されてきた &man.a.out.5; フォーマットを伝統的に使用しています。 いつかは FreeBSD システムでネイティブ ELF バイナリを作り、 実行することができるようになるかもしれませんが、 初期の頃 FreeBSD では ELF をデフォルトのフォーマットに変更するという動きは ありませんでした。なぜでしょうか? ところで Linux においては、 ELF への苦痛をともなった変更は、 その時に a.out 実行フォーマットから逃れたというよりは、 ジャンプテーブルベースの共有ライブラリのメカニズムの柔軟性の低さからの脱却でした。 これはベンダや開発者全体にとって、 共有ライブラリの作成が非常に難しかった原因でした。 ELF のツールには共有ライブラリの問題を解決することができるものが提供されており、 またいずれにせよ一般的に「進歩」していると考えられます。 このため移行のコストは必要なものとして容認され、 移行は行なわれました。 FreeBSD の場合は、共有ライブラリのメカニズムは Sun の SunOS スタイルの共有ライブラリのメカニズムに極めて近いものになっていて、 非常に使いやすいものになっています。 しかしながら、FreeBSD では 3.0 から ELF バイナリをデフォルトのフォーマットとして公式にサポートしています。 a.out 実行フォーマットはよいものを私達に提供してくれているものの、 私たちの使っているコンパイラの作者である GNU の人々は a.out フォーマットのサポートをやめてしまったのでした。 このことは、 私たちに別バージョンのコンパイラとリンカを保守することを余儀なくされることとなり、 最新の GNU 開発の努力による恩恵から遠ざかることになります。 その上、ISO C++ の、 とくにコンストラクタやデストラクタがらみの要求もあって、今後の FreeBSD のリリースでネイティブの ELF のサポートされる方向へと話が進んでいます。 それにしても、なぜそんなに多くのフォーマットがあるのですか? もうおぼろげになってしまった暗い過去に、単純なハードウェアがありました。 この単純なハードウェアは、単純で小さなシステムをサポートしていました。 a.out はこの単純なシステム (PDP-11) での作業を行なうバイナリとして完全に適したものだったのです。 人々はこの単純なシステムから UNIX を移植する際に、a.out フォーマットをそのまま使いました。というのは Motorola 68k、VAXen、 といったアーキテクチャへの UNIX の初期の移植ではこれで十分だったからです。 やがてある聡明なエンジニアが、 ソフトウェアでちょっとしたトリックを使うことを決めました。 彼はいくつかのゲートを削り取って CPU のコアをより速く走らせることができたのです。 これは新しい種類のハードウェア (今日では RISC として知られています) で動いたのです。 a.out はこのハードウェアには適していなかったので、 このハードウェア上で多くのフォーマットが、 限定された単純な a.out フォーマットでのものよりもより良いパフォーマンスを出すことを目指して開発されたのです。 COFF、ECOFF、 そしていくつかの有名でないフォーマットが ELF が標準になる前に開発され、 それらの限界が探求されたのです。 さらに、プログラムサイズは巨大になり、 ディスク (および物理メモリ) は依然として相対的に小さかったため、 共用ライブラリのコンセプトが誕生しました。 また、VM システムはより複雑なものになりました。 これらの個々の進歩は a.out フォーマットを使用して遂げられましたが、 その有用性は新しい機能とともにどんどん広がってきました。 これらに加え、実行時に必要なものを動的にロードする、 または初期化コードの実行後にプログラムの一部を破棄し、 コアメモリおよびスワップ空間を節約するという要望が高まりました。 プログラミング言語はさらに複雑になり、main 関数の前に自動的にコールされるコードの要望が高まりました。 多くの機能拡張が行なわれ、a.out フォーマットがこれらすべてを実現できるようになり、 それらはしばらくは基本的に動作していました。 やがて、a.out はコードでのオーバヘッドと複雑さを増大させずに、 これらの問題すべてを処理することに無理がでてきました。 一方、ELF はこれらの問題の多くを解決しますが、 現状稼働しているシステムからの切替えは厄介なものになるでしょう。 そのため ELF は、a.out のままでいることが ELF への移行よりももっと厄介なものになるまで待つ必要がありました。 しかし時が経つにつれ、FreeBSD のビルドツールの元となったツール群 (特にアセンブラとローダ) と FreeBSD のビルドツール群は異なった進化の経路をたどりました。 FreeBSD のツリーでは、共有ライブラリが追加され、 バグフィックスも行われました。 もともとのツール群を作成した GNU の人たちは、プログラムを書き直し、 クロスコンパイラのサポート、 異なるフォーマットを任意に取り込む機能などを追加していきました。 多くの人々が FreeBSD をターゲットとしたクロスコンパイラの構築を試みましたが、 FreeBSD の使っている as と ld の古いプログラムコードはクロスコンパイルをサポートしておらず、 うまくいきませんでした。 新しい GNU のツール群 (binutils) は、 クロスコンパイル、共有ライブラリ、C++ 拡張などの機能をサポートしています。 さらに数多くのベンダが ELF バイナリをリリースしています。 FreeBSD にとって ELF バイナリが実行できることは、 非常にメリットがあります。ELF バイナリが FreeBSD で動くのなら、a.out を動かすのに手間をかける必要はありませんね。 長い間忠実によく働いた老いた馬は、 そろそろ牧草地で休ませてあげましょう。 ELF は a.out に比べてより表現力があり、 ベースのシステムに対してより幅広い拡張性を提供できます。 ELF 用のツールはよりよく保守されています。 また多くの人にとって重要なクロスコンパイルもサポートしています。 ELF の実行速度は、ほんの少し a.out より遅いかもしれませんが、 実際に速度の差をはかるのは困難でしょう。 ELF と a.out の間には、ページマッピング、 初期化コードの処理など多くの違いがありますが、 とりたてて重要なものはありません。しかし違いがあるのは確かです。ほどなく、 GENERIC カーネルから a.out のサポートが外されます。 a.out のプログラムを実行する必要性がなくなれば、 最終的に a.out のサポートはカーネルから削除されます。 シンボリックリンクの許可属性を chmod で変えられないのはなぜですか? シンボリックリンクは許可属性を持ちません。 また &man.chmod.1; のデフォルト動作は、 シンボリックリンクをたどってリンク先のファイルの許可属性を変更するようになっていません。 そのため、 foo というファイルがあり、 このファイルへのシンボリックリンク bar があったとすると、 以下のコマンドは常に成功します。 &prompt.user; chmod g-w bar しかしこの場合、foo の許可属性は変更されません。 この場合、 か のどちらかのオプションを と同時に使う必要があります。 &man.chmod.1; と &man.symlink.7; のマニュアルページにはもっと詳しい情報があります。 オプションは再帰的に chmod を実行します。ディレクトリやディレクトリへのシンボリックリンクを chmod する場合は気をつけてください。 シンボリックリンクで参照されている単一のディレクトリのパーミッションを変更したい場合は、 &man.chmod.1; をオプションをつけずに、 シンボリックリンクの名前の後ろにスラッシュ (/) をつけて使います。たとえば、foo がディレクトリ bar へのシンボリックリンクである場合、 foo (実際には bar) のパーミッションを変更したい場合には、このようにします。 &prompt.user; chmod 555 foo/ 後ろにスラッシュをつけると、 &man.chmod.1; はシンボリックリンク foo を追いかけてディレクトリ bar のパーミッションを変更します。 ログイン名がいまだに 8 文字に制限されているのはなぜですか? UT_NAMESIZE を変更してシステム全体を作り直せば十分で、 それだけでうまくいくだろうとあなたは考えるかもしれません。 残念ながら多くのアプリケーションやユーティリティ (システムツールも含めて) は、 小さな数値を構造体やバッファなどに使っています (必ずしも 8 や 9 ではなく、 15 や 20 などの変った値を使うものもあります)。 (固定長のレコードを期待するところで可変長レコードになるため、 ) 台無しになったログファイルを得ることになるということだけでなく、 Sun の NIS のクライアントの場合は問題が起きますし、他の UNIX システムとの関連においてこれら以外の問題も起きる可能性があります。 しかし、FreeBSD 3.0 以降では 16 文字となり、 多くのユーティリティのハードコードされた名前の長さの問題も解決されます。 実際にはシステムのあまりに多くの部分を修正するために、 3.0 になるまでは変更が行われませんでした。 それ以前のバージョンでは、これらの問題が起こった場合に、 問題を自分自身で発見し、解決できることに絶対的な自信がある場合は /usr/include/utmp.h を編集し、 UT_NAMESIZE の変更にしたがって、 長いユーザ名を使うことができます。 また、 UT_NAMESIZE の変更と一致するように /usr/include/sys/param.h の MAXLOGNAME 更新しなくてはなりません。 最後に、ソースからビルドする場合は /usr/include を毎回アップデートする必要があることを忘れないように! /usr/src/.. 上のファイルを変更しておいて置き換えましょう。 FreeBSD 上で DOS のバイナリを動かすことはできますか? はい、FreeBSD 3.0 からは、 統合と改良が重ねられた BSDI の doscmd DOS エミュレーションサブシステムを使ってできるようになりました。 今なお続けられているこの努力に興味を持って参加していただけるなら、 &a.emulation; へメールを送ってください。 FreeBSD 3.0 以前のシステムでは、 pcemu という巧妙なユーティリティが FreeBSD Ports Collection にあり、 8088 のエミュレーションと DOS のテキストモードアプリケーションを動かすに十分な BIOS サービスを行ないます。これは X ウィンドウシステムが必要です (XFree86 として提供されています)。 どこで無料の FreeBSD のアカウントを取得できますか? FreeBSD はいずれのサーバーにもアクセスを開放していませんが、 Unix システムへの自由なアクセスを提供しているところがあります。 費用はまちまちで、限定されたサービスが利用できます。 M-Net としても知られる Arbornet, Inc は 1983 年から Unix システムへのアクセスを提供しています。 System III が動作する Altos に始まり、1991 年には BSD/OS に移行しました。2000 年 6 月には、再び FreeBSD に 移行しています。M-Net には SSH または telnet 経由で アクセスすることができ、FreeBSD ソフトウェア一式が 利用できるようになっています。ただし、ネットワーク接続は 会員と、非営利組織として運営されているシステムに寄付をする 後援者に制限されています。また、M-Net は掲示板システムと 双方向チャットも提供しています。 Grex は、 掲示板システムと双方向チャットソフトウェアが同じであることも含め、 M-Net とよく似たサイトを提供しています。しかし、 マシンは Sun 4M で、SunOS が動作しています。 sup とは何で、 どのようにして使うものなのでしょうか? SUP とは、ソフトウェアアップデートプロトコル (Software Update Protocol) で カーネギーメロン大学 (CMU) で開発ツリーの同期のために開発されました。 私たちの中心開発ツリーをリモートサイトで同期させるために使っていました。 SUP はバンド幅を浪費しますので、今は使っていません。 ソースコードのアップデートの現在のおすすめの方法は FreeBSD ハンドブックの「CVSup」にあります。 FreeBSD をクールに使うには? FreeBSD を動かす時に温度測定を行なった人はいますか? Linux は dos よりも温度が下がるということは知っていますが、FreeBSD についてはこのようなことに触れたものを見たことはありません。 実際熱くなっているように見えます。 いいえ。 私たちは 250 マイクログラムの LSD-25 をあらかじめ与えておいたボランティアに対する、 目隠し味覚テストを大量に行なっています。 35% のボランティアは FreeBSD はオレンジのような味がすると言っているのに対し、 Linux は紫煙のような味わいがあると言っている人もいます。 両方のグループとも温度の不一致については何も触れていません。 この調査で、非常に多くのボランティアがテストを行なった部屋から不思議そうに出てきて、 このようなおかしな結果を示したことに私たちは当惑させられました。 私たちは、ほとんどのボランティアは Apple にいて彼らの最新の「引っかいて匂いをかぐ」GUI を使っているのではないかと考えています。 私たちは奇妙な古い仕事をしているのでしょう! 真面目に言うと、FreeBSD や Linux は共に HLT (停止) 命令をシステムのアイドル (idle) 時に使い、 エネルギーの消費を押えていますので熱の発生も少なくなります。 また、APM (advanced power management) を設定してあるなら FreeBSD は CPU をローパワーモードにすることができます。 誰かが私のメモリカードをひっかいているのですか?? FreeBSDでカーネルのコンパイルをしている時、 メモリから引っかいているような奇妙な音が聞こえるようなことはあるのでしょうか? コンパイルをしている時 (あるいは起動時にフロッピドライブを認識した後の短い間など)、 奇妙な引っかくような音がメモリカードのあたりから聞こえてきます。 その通り! BSD の文書には良く、デーモン (daemon) という言葉が出てきます。 ほとんどの人は知らないのですが、 デーモンとは、あなたのコンピュータを依り代とする、 純粋で非物質的な存在のことです。 メモリから聞こえるひっかくような音は、 さまざまあるシステム管理タスクの扱いをいかに最善なものにするか、 といったことを決めるときにデーモンたちが交わす、 かん高いささやき声なのです。 この雑音が聞こえたとき、DOS から fdisk /mbr というプログラムを実行すれば、 うまくデーモンを追い出すことができるでしょう。 でも、デーモンはそれに歯向かって fdisk の実行をやめさせようとするかも知れません。 もし、それを実行しているときにスピーカならビル ゲイツ (Bill Gates) の悪魔のささやきが聞こえてきたら、 すぐに立ち上がって逃げてください。決して振り返ってはいけません! BSD のデーモンたちが押え込んでいた双子のデーモン、DOS と Windows が解放され、 あなたの魂を永遠の破滅へ導こうとマシンを再び支配してしまうことでしょう。 それを知った今や、選べと言われたら、 むしろひっかき音に慣れる方を選ぶのではありませんか? "MFC" とはどういう意味ですか MFC とは、 「CURRENT との合流 (Merged From -CURRENT)」の頭文字をとったものです。 CVS ログで -CURRENT から -STABLE ブランチへの合流を示します。 "BSD" とはどういう意味ですか? この言葉は、仲間うちだけに分かる隠語で何とかという意味です。 文字どおりに訳すことはできませんが、 BSD の訳は「F1 のレーシングチーム」か「ペンギンはおいしいスナック」、 あるいは「俺たちゃ Linux より洒落は利いてるぜ」とかそのへんだと言っておけばおっけーでしょう。 :-) 冗談はさておき、BSD とは、Berkeley CSRG (コンピュータシステム評議会) が彼らの UNIX の配布形態の名前として当時選んだ "Berkeley Software Distribution" の略です。 リポジトリ・コピー (repo-copy) とは一体何のことでしょう? repo-copy (repository copy の略) とは、 CVS リポジトリの中で直接ファイルをコピーすることを示す用語です。 repo-copy を行なわない場合を考えます。 リポジトリの中の異なる場所にファイルをコピーしたり、 移動したりする必要性が生じると、コミッターは ファイルを新しい場所に置くために cvs add を、 そして古いファイルが削除される場合は、古いファイルに対して cvs rm を実行するでしょう。 この方法の欠点は、ファイルの変更履歴 (たとえば CVS ログのエントリ) が新しい場所にコピーされないことです。 FreeBSD プロジェクトではこの変更履歴をとても有用なものだと考えているため、 前述の方法の代わりにリポジトリコピーが良く用いられます。 この操作は cvs プログラムを利用するのではなく、 リポジトリの管理担当者がリポジトリの中でファイルを直接コピーすることによって行なわれます。 なんでバイク小屋 (bikeshed) の色にまで気を使わなければいけないんですか? 一言で言ってしまえば、そうすべきではありません。 もう少し詳しく説明しましょう。 たとえば、あなたがバイク小屋を建てる技術を持っていたとします。 しかしそれは、塗ろうとしている色が気に入らないからと言って、 他人がバイク小屋を建てようとしているのを止めて良い理由にはなりませんよね。 これは、自分の行動について十分な理解を持っているなら、 あなたは細かな機能すべてにわたって議論する必要はないことを示す比喩です。 ある変更によって産み出されるノイズの総量は、 その変更の複雑さに反比例するのだと言っている人達もいます。 さらに詳しく、完全な回答を紹介しましょう。 Poul-Henning Kamp は、 「&man.sleep.1; は分数の秒数を引数として取るべきか」という 非常に長い議論の後で、 A bike shed (any colour will do) on greener grass... というタイトルの長文を投稿しました。 関係のある部分だけを以下に掲載します。
1999 年 10 月 2 日 freebsd-hackers にて Poul-Henning Kamp このバイク小屋、どうだろう? 誰かがたずねました。 長い…というか、むしろ古い話になりますが、 中身はわりと簡単な話です。パーキンソン (C. Northcote Parkinson) は 1960 年代初頭に パーキンソンの法則 と呼ばれる本を書きました。 この中にはさまざまな経営の力学に関する洞察が含まれています。 [ この本に関する解説があったが省略 ] バイク小屋に関連する例として、 もう一つの重要な構成要素となっているのは原子力発電所です。 この本の年代がわかりますね。 パーキンソンは、あなたが重役会に出席して 数百万から数10億ドル規模の原子力発電所の建設の承認を得る ことはできるでしょうが、あなたが建てたいのがバイク小屋ならば、 終わりなき議論に巻き込まれるだろうと言っています。 パーキンソンはこのように説明しています。 これは原発が余りに巨大で高価で複雑なので誰もこれを一手に握ることができず、 それを試みるくらいならむしろ、手が出せなくなる前に 他の誰かがすべてを詳細にチェックすることを 引き受けることに頼るのです。 リチャード・ファインマン (Richard P. Feynmann) は、 ロスアラモスでこの手の重要な経験を何度も見てきたと本に書いています。 一方でバイク小屋の場合は、誰でも週末にこれを作り上げることができ、 しかも TV の試合を見る時間があまるほどです。 なので、どんなに準備が整えてあって、どんなに計画が順当であったとしても、 わたしは仕事をやっているよ、 わたしは注意を払っているよ、そして わたしはここにいるよ、 ということを示そうとする人が必ず現れます。 デンマークではこれを「指紋をつける」と呼んでいます。 これは個人的なプライドや名声を求め、 ある場所を指し示して「ここ! ここは俺が やったんだぜ〜」というようなものです。 これは政治家に見られる強い特徴ですが、 その他のほとんどの人もこういう風に振舞う可能性はあるのです。 生乾きのセメントにつけられた足跡のことを考えればお分かりでしょう。
ひとつの電球を取り替えるのに、何人の FreeBSD ハッカーが必要? 1,172人です。 電球が消えていると -CURRENT で文句を言うのに 23 人。 設定上の問題で -questions で話をすべきことについて騒ぐのに 4 人。 それを send-pr (訳注: 障害報告) するのに 3 人 (そのうちのひとつは間違って doc カテゴリに送りつけられたうえに、 内容が「暗くなった」というだけのもの)。 buildworld を失敗させ、5 分後には元に戻されるような電球を テストもせずにコミットするのに 1 人。 send-pr した人に、パッチが含まれていないと「いちゃもん」を付けるのに 8 人。 buildworld が失敗すると文句を言うのに 5 人。 自分のところではちゃんと動く、 cvsup したタイミングが悪かったんだろうと答えるのに 31 人。 新しい電球のためのパッチを -hackers に投げるのに 1 人。 自分は 3 年も前にパッチを作ったが、それを -CURRENT に投げたときには無視されただけだった、 自分は send-pr のシステムには嫌な経験があると (おまけに、 提案された新しい電球には柔軟性が無いとまで) 文句を言うのに 1 人。 電球が基本システムに組み込まれていない、 committer はコミュニティの意見を聞くこと無しにこんなことをする権利は無いと叫び、 「こんなときに -core は何をやってるんだ!?」とわめきちらすのに 37 人。 自転車置き場の色に文句を言うのに 200 人。 パッチが style(9) 違反だと指摘するのに 3 人。 提案された新しい電球は GPL の下にあると文句を言うのに 70 人。 GPL と BSD ライセンスと MIT ライセンスと NPL と、 某 FSF 創立者らの個人的な健康法の優位性についての論争を戦わすのに 586 人。 スレッドのあちこちの枝を -chat や -advocacy に移動するのに 7 人。 提案された電球を、古いのよりずっと薄暗いのにコミットしてしまうのに 1 人。 FreeBSD に薄暗い電球を付けるくらいなら真っ暗のほうがましだという、 コミットメッセージへの凄まじい非難の嵐によって、 それを元に戻すのに 2 人。 薄暗い電球が帳消しにされたことに対してどなり声で口論し、 -core の声明を要求するのに 46 人。 もし FreeBSD をたまごっちに移植することになったときに都合がいいように、 もっと小さな電球を要求するのに 11 人。 -hackers と -chat の S/N比に文句を言い、 抗議のため講読を取りやめるのに 73 人。 「unsubscribe」「どうやったら講読をやめられるんですか?」 「このメーリングリストからわたしを外してください」といった メッセージを、例のフッタをくっつけて投稿するのに 13 人。 みんなが激論を戦わせるのに忙がしくて気付かない間に、 作業中の電球をコミットするのに 1 人。 新しい電球は TenDRA を使ってコンパイルされた場合に 0.364% も明るくなる (ただし電球を立方体にしなければならない)、 だから FreeBSD は EGCS から TenDRA に変えるべきだと指摘するのに 31 人。 新しい電球は美しさに欠けていると文句を言うのに 1 人。 「MFC って何ですか?」と聞くのに 9 人 (send-pr した人も含む)。 電球が取り替えられてから 2 週間も消えっぱなしだと文句を言うのに 57 人。 &a.nik; による追記 これには爆笑しました。 それからわたしは考えました。 「ちょっと待てよ? このリストのどこかに、 『これを文書にまとめるのに 1人』というのがあってもいいんじゃないか?」 それからわたしは悟りを開いたのです :-) この項目の著作権は Copyright (c) 1999 &a.des; にあります。 無断で使用しないでください。 まじめな FreeBSD ハッカーだけの話題 訳: &a.iwasaki;、 1997 年 11 月 8 日 SNAP とか RELEASE とかは何? 現在、FreeBSD の CVS リポジトリ には、三つのアクティブ/準アクティブなブランチがあります (アクティブな開発ブランチは三つしか存在しないため、 おそらく RELENG_2 ブランチの変更は年に 2 回だけになるでしょう)。 RELENG_2_2 通称 2.2-STABLE RELENG_3 通称 3.X-STABLE RELENG_4 通称 4-STABLE HEAD 通称 あるいは 5.0-CURRENT HEAD は他の二つと違って、 実際のブランチタグではなく、 「current、 分岐していない開発本流」のための単なるシンボリックな定数です。 私たちはこれを -CURRENT と呼んでいます。 現在、 -CURRENT は 5.0 の開発本流であり、 4.0-STABLE ブランチ、 つまり RELENG_4 は 2000 年 3 月に -CURRENT から分岐しています。 2.2-STABLE ブランチ、 RELENG_2_2 は 1996 年 11 月に -CURRENT から分岐しました。 これは保守が完全に終了しています。 自分用のカスタムリリースを構築するには? リリースを構築するには三つのことが必要です。まず、 &man.vn.4; ドライバが組み込まれたカーネルを実行させている必要があります。 以下をカーネルコンフィグレーションファイルに追加し、 カーネルを作り直してください。 pseudo-device vn #Vnode driver (turns a file into a device) 次に、CVS リポジトリ全体を手元においておく必要があります。 これを入手するには CVSUP が使用できますが、supfile で release の名称を cvs にして 他のタグや date フィールドを削除する必要があります。 *default prefix=/home/ncvs *default base=/a *default host=cvsup.FreeBSD.org *default release=cvs *default delete compress use-rel-suffix ## Main Source Tree src-all src-eBones src-secure # Other stuff ports-all www doc-all そして cvsup -g supfile を実行して自分のマシンに CVS リポジトリ全体をコピーします…。 最後に、ビルド用にかなりの空き領域を用意する必要があります。 そのディレクトリを /some/big/filesystem として、 上の例で CVS リポジトリを /home/ncvs に置いたものとすると、 以下のようにしてリリースを構築します。 &prompt.root; setenv CVSROOT /home/ncvs # or export CVSROOT=/home/ncvs &prompt.root; cd /usr/src &prompt.root; make buildworld &prompt.root; cd /usr/src/release &prompt.root; make release BUILDNAME=3.0-MY-SNAP CHROOTDIR=/some/big/filesystem/release
ただし、すでに /usr/obj 以下に構築物が存在しているなら、buildworld の必要はありません。
処理が終了すると、 リリース全体が /some/big/filesystem/release に構築され、完全な FTP インストール用の配布物が /some/big/filesystem/release/R/ftp に作成されます。 -current 以外の開発ブランチの SNAP を自分で構築したい場合は、 RELEASETAG=SOMETAG を上の make release のコマンドラインに追加します。 たとえば、RELEASETAG=RELENG_2_2 とすると最新の 2.2-STABLE snapshot が構築されます。 カスタムのインストールディスクを作るにはどうすればいいのですか? /usr/src/release/Makefile のいろいろなターゲットとしてインストールディスク、 ソース、バイナリアーカイブを作る完全な処理を自動的に行なうようになっています。 Makefile に十分な情報があります。 しかし、実行には make world が必要で、 多くの時間とディスクの容量が必要です。 make world を行なうと既存のバイナリを上書きしてしまうのですが。 ええ、それが一般的な考え方です。名前が示しているように make world はすべてのシステムのバイナリを最初から作り直しますので、結果として、 クリーンで一貫性のある環境を得ることができます (これがそれだけ長い時間がかかる理由です)。 環境変数 DESTDIR を make world や make install を実行する時に定義しておくと、新しく作られたバイナリは ${DESTDIR}を root とみなしたディレクトリツリーにインストールされます。 あるでたらめな共有ライブラリの変更やプログラムの再構築によって make world は失敗することもあります。 システム起動時に (bus speed defaulted) とメッセージが出ます。 Adaptec の 1542 SCSI ホストアダプタは、 ユーザがソフトウェア的にバスアクセス速度の設定を行なうことができます。 以前のバージョンの 1542 ドライバは、 使用可能な最大の速度を求めてアダプタをその設定にしようとしました。 これは特定のユーザのシステムでは問題がある事がわかり、 現在ではカーネルコンフィグオプションに TUNE_1542 が加えられています。 これを使用すると、これが働くシステムではディスクが速くなりますが、 データの衝突が起きて速くはならないシステムもあるでしょう インターネットアクセスに制限があっても current を追いかけられますか? はい、 CTM システムを使って、 ソースツリー全体のダウンロードを行なわずに追いかけることができます。 どのようにして配布ファイルを 240KB に分割しているのですか? 比較的新しい BSD ベースのシステムでは、 split に任意のバイト境界で分割する オプションがあります。 以下は /usr/src/Makefile からの例です。 bin-tarball: (cd ${DISTDIR}; \ tar cf - . \ gzip --no-name -9 -c | \ split -b 240640 - \ ${RELEASEDIR}/tarballs/bindist/bin_tgz.) 私はカーネルに拡張を行ないました。 誰に送ればいいですか? FreeBSD ハンドブックの「FreeBSD への貢献」を参照してください。 あなたのアイディアに感謝します! PnP ISA カードの検出と初期化はどのように行なうのですか? Frank Durda IV 氏 より:
要点は、ホストが認識されていないボードを探す時に、すべての PnP ボードが応答することのできる少数の I/O ポートがあるということです。 それにより、PnP プローブルーチンが開始したとき、PnP ボードが存在するなら、すべての PnP ボードは自分のモデル番号を返します。 そのポートを I/O read するとプローブルーチンは問いに対するワイアード-OR された yes を得ます。この場合は 少なくとも 1 ビットが ON になります。 そして、プローブルーチンはモデル ID (Microsoft/Intel によって割り当てられています)が X より小さいボードを オフライン にすることができます。 この操作を行ない、問い合わせに応答しているボードがまだ 残っているかどうかを調べます。 もし 0 が返ってくるなら X より大きな ID を持つボードはないことになります。 今度は X よりも小さな値を持つボードについて問い合わせます。 もしあるのであれば、 プローブルーチンはモデル番号が X より小さいことを知ります。 今度は、X-(limit/4) より大きな値を持つボードをオフラインにして問い合わせを繰り返します。 この ID の範囲による準バイナリサーチを十分繰り返すことにより、 プローブルーチンはマシンに存在するすべての PnP ボードの値を最終的に得ることができます。その繰り返しの回数は 2^64 よりはるかに少ない回数です。 ID は二つの 32-bit (つまり 64bit) フィールド + 8 bit チェックサムからなります。最初の 32 bits はベンダの識別子です。 これは公表されてはいませんが、 同一のベンダから供給されている異なるタイプのボードでは異なる 32-bit ベンダ ID を持つことができるように考えられます。 製造元を特定するだけのために 32-bit はいくらか過剰です。 下位の 32-bit はシリアル番号、 イーサネットアドレスなどのボードを特定するものです。 ベンダは上位 32 bits が異なっていないのであれば、 下位 32-bit が同一である 2枚目のボードを製造することはありません。 したがって、同じタイプの複数のボードをマシンにいれることができ、 この場合でも 64-bit 全体ではユニークです。 32-bit のフィールドはすべてを 0 にすることはできません。 これは初期化のバイナリサーチの間ワイアード-OR によって 0 ではない ビットを参照するからです。 システムがすべてのボードの与えられた ID を認識すると、 それぞれのボードに対応した処理を一つずつ (同一の I/O ポートを通して) 行ないます。 そして、利用できる割り込みの選択などのボードが必要とするリソースを検出します。 すべてのボードについてこの情報を集めます。 この情報はハードディスク上の ECU ファイルなどの情報とまとめられ、 マザーボードの BIOS にも結合されます。 マザーボード上のハードウェアへの ECU と BIOS PnP のサポートは通常は統合されていますが、 周辺機器については真の PnPであるとはいえません。 しかし、BIOS の情報に ECU の情報を加えて調査することで、 プローブルーチンは PnP デバイスが再配置できなくなることを避けることができます。 それから、再度 PnP デバイスにアクセスし、I/O、DMA、IRQ、 メモリマップアドレスの設定をします。 デバイスはこのアドレスに見えるようになり、 次に再起動するまでこの位置を占めます。しかし、 あなたの望む時に移動させることが不可能である、 といっているわけではありません。 以上の話では大きく単純化をしてありますが、 基本的な考え方は得られたでしょう。 マイクロソフトは、ボードのロジックが対立する I/O サイクルではデコードしていない (訳注: おそらく read 時しかデコードされていず write 時はポートが空いているという意味でしょう)、 プライマリプリンタのステータスポートのいくつかを PnP のために占有しました。 私は初期の PnP の提案レビュー時に IBM 純正のプリンタボードでステータスポートの write のデコードがされているということに気がつきましたが、 MS は tough (頑固、不運、無法な) と言っています。 そしてプリンタのステータスポートへアドレスの設定のために write を行なっています。また、 そのアドレス + 0x800 と read のための 3番目の I/O ポートが 0x200 から 0x3ff の間のどこかに置かれるでしょう。
FreeBSD は、他のアーキテクチャをサポートしないんですか? いくつかのグループの人々が、FreeBSD の他のアーキテクチャへの移植に関心を示しており、 FreeBSD/AXP (ALPHA) はこれらの成果としてはとても成功したものの一つです。 FreeBSD/AXP は現在 ftp://ftp.FreeBSD.org/pub/FreeBSD/alpha から入手できます。 ALPHA への移植版が現在動く機種は増えつつあり、 その中には AlphaStation、AXPpci、PC164、Miata そして Multia といったモデルが含まれています。 現状についての情報を得るには freebsd-alpha@FreeBSD.orgメーリングリストに参加してください。 その他に FreeBSD の SPARC アーキテクチャへの移植があります。 プロジェクトへの参加に興味がある方は freebsd-sparc@FreeBSD.orgメーリングリスト に参加してください。 進行中のプラットホームのリストにもっとも最近追加されたのが IA-64 と PowerPCです。詳細は freebsd-ia64@FreeBSD.org および/あるいは freebsd-ppc@FreeBSD.orgメーリングリストに参加してください。 新しいアーキテクチャに関する一般的な議論については 新しいアーキテクチャに関する一般的な議論については freebsd-platforms@FreeBSD.orgメーリングリスト へ参加してください。 デバイスドライバを開発したので、メジャー番号が欲しいのですが。 これは、開発したドライバを公開するかどうかに依存します。 公開するのであれば、ドライバのソースコード、 files.i386 の変更、 コンフィグファイルのサンプル、 デバイスが使うスペシャルファイルを作成する &man.MAKEDEV.8; のコードを私たちに送ってください。 公開するつもりがない場合、ライセンスの問題により公開できない場合は、 キャラクタメジャー番号 32 および、 ブロックメジャー番号 8 がこのような目的のために予約されています。 これらの番号を使用してください。 どちらの場合であれ、ドライバに関する情報を &a.hackers; に流して頂けると助かります。 代替のディレクトリ配置ポリシー 現在使われているディレクトリの配置ポリシーは、 私が 1983 年に書いたものから全く変更されていません。 私は当初の配置ポリシーを、オリジナルの fast filesystem のために書き、 まったく改定していません。 このポリシーはシリンダグループを使い尽くすのを防ぐにはうまくいきましたが、 お気づきの方もいる通り find の動作には不適切です。 ほとんどのファイルシステムの内容は、 深さ優先検索 (ftw とも呼ばれます) によって作られたアーカイブから、 抽出 (restore) して作成されます。この際、 ディレクトリは、シリンダグループにまたがって配置され、 以降の深さ優先検索を行うには、 考え得る限り最悪の状態になります。 もし作成するディレクトリの総数がわかっていれば、 解決方法はあります。(総数/シリンダグループ数) 個のディレクトリを、 シリンダグループごとにまとめて作成すれば良いのです。 もちろん最適なディレクトリ配置になるように、 総数を予測する方法を考えなければなりません。 しかし仮にシリンダグループあたりのディレクトリ数を 10 くらいの小さな数に固定してしまったとしても、 大幅な改善が望めるでしょう。 このポリシーを用いるべきリストア作業を、通常の作業 (おそらく既存のポリシーを使用したほうが良いでしょう) を区別するには、 10 秒間の間に作成されたディレクトリを最大 10 個までまとめて単一のシリンダグループに書き込むという手順が使えるでしょう。 とにかく私の結論は、そろそろ実験を始めて見る時期だろうということです。 カーネルパニックを最大限に利用する この節は、freebsd-current メーリングリストに &a.wpaul; 氏が投稿したメールを、 &a.des; 氏が校正し、[] 内のコメントを追加して引用したものです。 From: Bill Paul <wpaul@skynet.ctr.columbia.edu> Subject: Re: the fs fun never stops To: ben@rosengart.com Date: Sun, 20 Sep 1998 15:22:50 -0400 (EDT) Cc: current@FreeBSD.ORG [<ben@rosengart.com> が以下のパニックメッセージを投稿しました。] > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x40 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xf014a7e5 ^^^^^^^^^^ > stack pointer = 0x10:0xf4ed6f24 > frame pointer = 0x10:0xf4ed6f28 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 80 (mount) > interrupt mask = > trap number = 12 > panic: page fault このようなメッセージが表示された場合、問題が起きる状況を確認して、 情報を送るだけでは十分ではありません。 下線をつけた命令ポインタ値は重要な値ですが、 残念ながらこの値は構成に依存します。つまり、 この値は使っているカーネルのイメージに依存するのです。 もしスナップショットなどの GENERIC カーネルを使っているのであれば、 他の人間が問題のある関数について追試をすることができますが、 カスタマイズされたカーネルの場合は、 使っている本人にしか問題の起こった場所は特定できないのです。 何をすれば良いのでしょう? 命令ポインタ値をメモします。 0x8: という部分は今回必要ありません。 必要なのは 0xf0xxxxxx という部分です。 システムが再起動したら、以下の操作を行います。 &prompt.user; nm -n /kernel.that.caused.the.panic | grep f0xxxxxx ここで、f0xxxxxx は命令ポインタ値です。 カーネルシンボルのテーブルは関数のエントリポイントを含み、 命令ポインタ値は、関数内部のある点であり最初の点ではないため、 この操作を行っても完全に一致するものが表示されない場合もあります。 この場合は、 最後の桁を省いてもういちどやってみてください。 このようになります。 &prompt.user; nm -n /kernel.that.caused.the.panic | grep f0xxxxx これでも一致しない場合は、 桁を減らしながら何らかの出力があるまで繰り返してください。 何か出力されたら、 それがカーネルパニックを引き起こした可能性のある関数のリストです。 これは、問題点を見付ける正確な方法ではありませんが、何もないよりましです。 このようなパニックメッセージを投稿している人はよく見掛けますが、 このように、命令ポインタ値を、 カーネルシンボルテーブルの中の関数とつき合わせて調べている人はまれです。 パニックの原因を突き止める最良の方法は、クラッシュダンプをとり、 gdb(1) でスタックトレースを行うことです。 どっちにしろ、私は普通以下のようにします。 カーネルコンフィグファイルを作ります。 カーネルデバッガが必要そうであれば options 'DDB' を加えても良いです (私は永久ループが起こっていそうな場合に、 ブレークポイントを設定するのに使っています)。 config -g KERNELCONFIG としてビルドディレクトリを設定します。 cd /sys/compile/KERNELCONFIG; make を実行します。 カーネルのコンパイルが終了するのを待ちます。 make install を実行します。 再起動します。 &man.make.1; プロセスは２つのカーネル、 kernel と kernel.debug をビルドします。 kernel は /kernel としてインストールされ、 kernel.debug は gdb(1) のデバッグ用シンボル情報を取り出すために利用されます。 確実にクラッシュダンプをとるには、/etc/rc.conf を編集して dumpdev を使用しているスワップパーティションに指定する必要があります。 こうすると rc(8) スクリプトから dumpon(8) コマンドが実行され、 クラッシュダンプ機能が有効になります。 手動で dumpon(8) コマンドを実行してもかまいません。 パニックの後、クラッシュダンプは savecore(8) コマンドを使用して取り出すこと ができます。 dumpdev が /etc/rc.conf で設定されていれば、 rc(8) スクリプトから savecore(8) が自動的に実行され、クラッシュダンプを /var/crash に保存します。 FreeBSD のクラッシュダンプのサイズは、 ふつう物理メモリサイズと同じです。 つまり 64MB のメモリを積んでいれば、 64MB のクラッシュダンプが生成されることになります。 /var/crash に十分な空き容量があることを確認してください。手動で savecore(8) を実行すれば、 もっと空き容量のあるディレクトリにクラッシュダンプを保存できます。 options MAXMEM=(foo) という行をカーネルコンフィグファイルに追加することで、 カーネルのメモリ使用量を制限できます。 たとえば 128MB のメモリがある場合も、 カーネルのメモリ使用量を 16MB に制限し、クラッシュダンプのサイズも 128MB ではなく 16MB にすることができます。 クラッシュダンプを取り出せたら、 以下のように gdb(1) を使ってスタックトレースをとります。 &prompt.user; gdb -k /sys/compile/KERNELCONFIG/kernel.debug /var/crash/vmcore.0 (gdb) where 必要な情報が 1 画面に収まらないことも多いので、できれば script(1) を使って出力を記録します。 strip していないカーネルイメージを使うことで、 すべてのデバッグシンボルが参照でき、 パニックの発生したカーネルのソースコードの行が表示されているはずです。 通常、正確なクラッシュへの過程を追跡するには、 出力を最後の行から逆方向に読まなければなりません。 また gdb(1) を使って、 変数や構造体の内容を表示させ、 クラッシュした時のシステムの状態を調べられます。 もしあなたがデバッグ狂で、同時に別のコンピュータを利用できる環境にあれば、 gdb(1) をリモートデバッグに使うこともできます。 リモートデバッグを使うと、あるコンピュータ上の gdb(1) を使って、 別のコンピュータのカーネルをデバッグできます。 ブレークポイントの設定、カーネルコードのステップ実行など、 ふつうのプログラムのデバッグと変わりません。 コンピュータを 2 台並べてデバッグするチャンスにはなかなか恵まれないので、 私はまだリモートデバッグを試したことはありません。 Bill による追記 DDB を有効にしていてカーネルがデバッガに 落ちたら、ddb のプロンプトで "panic" と入力すれば、強制的にパニックを起こしクラッシュダンプさせることができます。 パニックの途中で、再びデバッガに落ちるかもしれませんが、 "continue" と入力すれば、 クラッシュダンプを最後まで実行させられます。 dlsym() が ELF 実行形式では動作しなくなります! ELF のツール類は、 デフォルトでは実行形式の中に定義されているシンボルを、 ダイナミックリンカから見えるようにはしません。 このため、dlopen(NULL, flags) を呼び出して得られたハンドルに対して、 dlsym() で探索を行っても、 こういったシンボルを見つけられません。 もし、あなたがプロセスの中心にあたる実行形式の中にあるシンボルを探索したければ、 ELF リンカ (&man.ld.1;) に オプションを付けて実行形式をリンクする必要があります。 カーネルアドレス空間を大きくしたり、 小さくするにはどうしたら良いのですか? カーネルアドレス空間は、FreeBSD 3.X 上で 256MB、FreeBSD 4.X 上で 1GB がデフォルトになっています。 負荷の高いネットワークサーバ (たとえば大きな FTP、HTTP サーバ) を運用する場合は、256MB では足りないことに気付くかも知れません。 では、アドレス空間を大きくするにはどうしたら良いのでしょうか? それには、二つの段階を踏みます。まず、 より大きいアドレス空間を割り当てることをカーネルに知らせる必要があります。 次に、カーネルはアドレス空間の先頭にロードされるため、 アドレスの先頭が天井 (訳注:カーネルアドレス空間の最下端アドレスのこと) と ぶつかることのないように、ロードアドレスを今までより低位に設定する必要があります。 最初の段階は、src/sys/i386/include/pmap.h にある NKPDE の値を増加させることで行ないます。 ここに 1GB のアドレス空間にするために、どのようにすれば良いかを示します。 #ifndef NKPDE #ifdef SMP #define NKPDE 254 /* addressable number of page tables/pde's */ #else #define NKPDE 255 /* addressable number of page tables/pde's */ #endif /* SMP */ #endif 正確な NKPDE の値を計算するには、 望みのアドレス空間の大きさ (メガバイト単位) を 4 で割って、 それから単一プロセッサ (UP) なら 1、SMP なら 2 を引き算してください。 次の段階を行なうには、ロードアドレスを正確に計算することが必要です。 単純に、アドレス空間の大きさ (バイト単位) を 0x100100000 から引き算してください。 1GB アドレス空間の場合、その結果は 0xc0100000 になります。 そして、src/sys/i386/conf/Makefile.i386 にある LOAD_ADDRESS に、今計算した値を入れます。また、次のように src/sys/i386/conf/kernel.script のセクションの始めの方にあるロケーションカウンタにも同じ値を入れてください。 OUTPUT_FORMAT("elf32-i386", "elf32-i386", "elf32-i386") OUTPUT_ARCH(i386) ENTRY(btext) SEARCH_DIR(/usr/lib); SEARCH_DIR(/usr/obj/elf/home/src/tmp/usr/i386-unknown-freebsdelf/lib); SECTIONS { /* Read-only sections, merged into text segment: */ . = 0xc0100000 + SIZEOF_HEADERS; .interp : { *(.interp) } それが完了したら、config し直してカーネルを再構築してください。 おそらく、ps(1)、top(1) などに不具合が出るでしょう。 それらを正常にするために、make world (もしくは、変更した pmap.h を /usr/include/vm/ にコピーした後に、 libkvm、 ps および top を手動で再構築すること) を行なうべきです。 カーネルアドレス空間の大きさは、4MB の倍数である必要があります。 &a.dg; 氏による補足 カーネルアドレス空間は 2 の乗数である必要があると思いますが、 それが確かなことかどうかははっきりしていません。 昔の起動コードには、良く高位アドレスビットのトリックが使われていたため、 少なくとも 256MB の粒度であることが想定されていたと思います。 謝辞 訳: &a.jp.y-koga;、 1997 年 11 月 10 日
FreeBSD Core Team この FAQ について問題を見つけたり、何か登録したい場合は、 &a.faq; までメールを送ってください。 フィードバックしてくれるみなさんには感謝感謝なのです。 みなさんに手伝ってもらわないとこの FAQ はよくなりませんから!
&a.jkh; たまに起こす FAQ の並べ替えや更新の発作 &a.dwhite; freebsd-questions メーリングリストでの義務を超えたサービス &a.joerg; Usenet (NetNews) での義務を超えたサービス &a.wollman; ネットワーク節の執筆と文書整形 Jim Lowe マルチキャストについて &a.pds; FreeBSD FAQ タイピング機械奴隷 FreeBSD チーム 不平を言ったり、うめいたり、情報提供してくれたり あと、抜けてしまった他の方々に対して、謝罪と心からの感謝を捧げます! FreeBSD FAQ 日本語化について FreeBSD 日本語ドキュメンテーションプロジェクトは、 FreeBSD 関係の日本語文書が少ないことを嘆いた数人の FreeBSD ユーザの提唱によって 1996 年 2 月 26 日にスタートし、 FreeBSD 日本語ハンドブックの作成をはじめとした活動を行なってきました。 FreeBSD FAQ の日本語化についてはオリジナルの翻訳作業だけでなく、 日本国内に固有の話題についても広く情報を集め、 日本の FreeBSD ユーザにとって真に有益なドキュメントを提供しようと考えています。 オリジナルの FAQ は日毎に更新されており、 私たちもまたこれに追い付くために作業を続けていきます。もちろん、新しいメンバも大歓迎です。 日本語翻訳版について、何かお気づきの点がありましたら、 &a.jp.doc-jp; までご連絡ください。 また、もし私たちの作業を手伝ってくれるなら、 FreeBSD 日本語ドキュメンテーションプロジェクトのページをご覧の上、是非参加してください。 翻訳者 (五十音順) &a.jp.arimura; 一宮 亮 ryo@azusa.shinshu-u.ac.jp &a.iwasaki; &a.jp.yoshiaki; &a.kuriyama; &a.jp.y-koga; &a.motoyuki; &a.jp.sugimura; &a.jp.nakai; にしか nishika@cheerful.com &a.hanai; &a.jp.kiroh; &a.jp.shou; 福間 康弘 yasuf@big.or.jp &a.jp.mrt; 山下 淳 junkun@esys.tsukuba.ac.jp 査読者 (五十音順) &a.asami; &a.iwasaki; &a.jp.yoshiaki; 大橋 健 ohashi@mickey.ai.kyutech.ac.jp &a.kuriyama; &a.motoyuki; &a.jp.saeki; &a.jp.sugimura; &a.hanai; &a.jp.nao; &a.jp.kiroh; &a.jp.hino; 檜山 卓 shiyama@intercity.or.jp &a.jp.shou; &a.jp.mrt; 若井 久史 earth@hokuto7.or.jp 作業環境整備 (五十音順) 一宮 亮 ryo@azusa.shinshu-u.ac.jp &a.jp.iwasaki; &a.jp.simokawa; 鈴木 秀幸 hideyuki@jp.FreeBSD.org diff --git a/ja_JP.eucJP/books/fdp-primer/tools/chapter.sgml b/ja_JP.eucJP/books/fdp-primer/tools/chapter.sgml index 5369e3ead0..f3d9ffa75b 100644 --- a/ja_JP.eucJP/books/fdp-primer/tools/chapter.sgml +++ b/ja_JP.eucJP/books/fdp-primer/tools/chapter.sgml @@ -1,307 +1,307 @@ ツール FDP では FreeBSD の文書を管理したり, - 他の出力形式にに整形したりするため, さまざまなソフトウェアツールを利用します. + 他の出力形式に整形したりするため, さまざまなソフトウェアツールを利用します. FreeBSD の文書で作業するには, あなた自身がそれらのツールを使う必要があります. これらのツールはすべて FreeBSD の port や package として入手可能で, インストール作業は非常に簡単です. 以下の章に書かれた例を試すには, あらかじめ これらのツールがインストールされていなければなりません. 各ツールの実際の利用方法は, その例が書かれた章で説明されています. できるだけ <filename role="package">textproc/docproj</filename> を利用してください textproc/docproj の port を使うとインストールする手間を大きく省くことができます. これは メタ (meta) port と呼ばれる port で, その中にソフトウェアが含むかわりに, 他のさまざまな port が正しくインストールされるように依存関係がつくられているものです. この port をインストールすると, この章であげられているソフトウェアが 自動的にすべてダウンロードされ, インストールされます. 必要となるパッケージの一つに, JadeTeX マクロセットというものがあります. このマクロセットは, インストール時に TeX がインストールされていることを必要とします. TeX は非常に大きなパッケージですが, Postscript や PDF 形式の出力を行なわないならばインストールの必要はありません. 時間とディスクスペースの節約のため, この port をインストールする際に, JadeTeX (すなわち TeX を含む) を必要とするかどうかを指定する必要があります. 次のいずれかを, 場合に応じて実行して下さい. &prompt.root; make JADETEX=yes install &prompt.root; make JADETEX=no install JADETEX=no を指定してツールをインストールすると, HTML や ACSII テキストだけを出力することができます. PostScript や PDF を出力するには TeX が必要です. 必須のツール ソフトウェア 以下のプログラムは, FreeBSD の文書で快適に作業するために必要なものであり, 文書を HTML, プレインテキストや RTF 形式に変換することができます. これらはすべて, textproc/docproj に含まれています. SP (textproc/sp) 正当性検査のための SGML パーサや SGML 正規化ツールを含むアプリケーションのセットです. Jade (textproc/jade) DSSSL の実装です. これはマークアップされた文書を HTML や TeX といった他の形式に変換するために使われます. Tidy (www/tidy) HTML 整形ツールです. これは自動生成された HTML 文書を整形し, より利用しやすいものにするために使われます. Links (www/links) HTML ファイルをプレインテキストに変換することのできる テキストモードの WWW ブラウザです. peps (graphics/peps) いくつかの文書には画像が含まれており, その中には EPS 形式で格納されているファイルがあります. ウェブブラウザが表示できるように PNG 形式に変換するために使われます. 文書型定義 (DTD) と実体宣言 (entity) 以下にあげるのは, FDP で使われている DTD と実体宣言集合 (entity set)です. これらはいずれも, 文書を取り扱う前に必要となります. HTML DTD (textproc/html) HTML は, World Wide Web で採用されているマークアップ言語です. これは FreeBSD ウェブサイト全体でも利用されます. DocBook DTD (textproc/docbook) DocBook は, 技術文書のマークアップのために設計された DTD です. FreeBSD の文書はすべて DocBook で記述されています. ISO 8879 公開実体宣言 (textproc/iso8879) ISO 8879:1986 に規定された 19 種類の 文字実体集合です. これはたくさんの DTD で利用されるもので, 数学記号や latin 文字集合の追加文字 (アクセント記号, 発音記号など), ギリシャ文字などが含まれます. スタイルシート スタイルシートは, 文書を画面表示や印刷などに利用される形式に変換, 整形するために使われます. Modular DocBook Stylesheets (textproc/dsssl-docbook-modular) Modular DocBook Stylesheets は, DocBook DTD でマークアップされた文書を HTML や RTF 形式に変換するのに使われます. 必須でない (optional) ツール もし必要性を感じないなら, 以下にあげるソフトウェアはインストールしなくともかまいません. しかしインストールしていれば, 文書の取り扱いに便利だと感じるでしょうし, これらを使うことで, より多様な出力形式で文書を出力することが可能となります. ソフトウェア JadeTeX および teTeX (print/jadetex および print/teTeX) Jade と teTeX は, DocBook 文書を DVI, Postscript, PDF の各形式に変換するのに使われます. また, このとき JadeTeX マクロも必要となります. 文書をそのような形式に変換しなくて良い (たとえば HTML, プレインテキスト, RTF で十分であるような) 場合には, JadeTeX および teTeX をインストールする必要はありません. これらのインストールには大きなディスクスペースと時間を必要とします. teTeX は, 30MB を超える大きなものです. JadeTeX と teTeX をインストールする場合には, JadeTeX がインストールされた後, teTeX の設定を行なわなければなりません. 必要な手順の詳細は, print/jadetex/pkg-message に説明されています. Emacs もしくは xemacs (editors/emacs もしくは editors/xemacs) このエディタは両方とも, SGML DTD でマークアップされた文書を編集するための特別なモードを備えています. このモードには, - 必要なタイプ量や誤りをを低減するためのコマンドがあります. + 必要なタイプ量や誤りを低減するためのコマンドがあります. どのようなテキストエディタでもマークアップされた文書を編集することは可能ですので, これらを使う必要があるというわけではありません. しかしおそらく, これらは便利なものだと感じると思います. もし, この他に SGML 文書を扱うために有用なソフトウェアをご存知でしたら, &nik; までお知らせ下さい. このリストに加えさせていただきます. diff --git a/ja_JP.eucJP/books/handbook/eresources/chapter.sgml b/ja_JP.eucJP/books/handbook/eresources/chapter.sgml index 709e373284..2eadee17b0 100644 --- a/ja_JP.eucJP/books/handbook/eresources/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/eresources/chapter.sgml @@ -1,1295 +1,1295 @@ インターネット上のリソース 訳: &a.jp.yuki;, 1996 年 8 月 28 日 FreeBSD の進歩は急速であり, 印刷したメディアは最新の開発をフォローするのに実用的ではありません. それだけしかない, というわけではありませんが, 最新情報を入手する方法としては電子的なリソースがベストです. FreeBSD はボランティアの努力によって, ユーザコミュニティ自体が, 一種のテクニカルサポート部門としての役割も通常果たしており, 電子メールや Usenet のニュースがこれらのコミュニティにたどり着く最も効果的な方法になっています. 以下に, FreeBSD ユーザコミュニティに連絡を取る場合の最も重要な点についての 概略を示します. もしここに書かれていない他のリソースに気がついた場合は, それらを &a.doc; に送って頂ければ, それらをここに含めるかもしれません. メーリングリスト 多くのFreeBSDの開発メンバはUSENETを読むことができますが, もし, comp.unix.bsd.freebsd.* のグループの一つに質問を投稿したとしても タイムリにその質問を受け取るということは保証できません. 質問を適切なメーリングリストに投稿すれば, 私たちかFreeBSDの関係者から, よりよい (そして少なくともより早い) 反応がいつでも得られることでしょう. さまざまなメーリングリストの憲章を このドキュメントの最後に記載しま す. 私たちは, メーリングリストの質, 特に技術面に関する質を高く保つ ために努力しているので, メーリングリストに参加する前にその憲章を読んで ください. 私たちのメーリングリストの参加者のほとんどは, 現在非常 にたくさんの FreeBSD に関連したメッセージを毎日受け取っており, メーリン グリストに対するふさわしい 用いられ方をするための憲章やルールを決めるこ とによって, メーリングリストの S/N 比を高くする保つように励んでいます. そうしないと, 結果的に, メーリングリストがプロジェクトにとって 事実上のコミュニケーションの手段になってしまうでしょう. メーリングリストはいずれもアーカイブされており, それらは FreeBSD World Wide Web server で検索することができます. キーワード検索可能なアーカイブの提供は, 良くある質問に対する回答を見つけるすぐれた方法ですから, 質問を投稿する前に調べてみるべきでしょう. メーリングリストの概説 一般的なメーリングリスト: 以下のものは誰でも自由に参加できる (そしておすすめの) 一般的なものです: リスト 目的 cvs-all FreeBSD ソースツリーへ加えられた変更について freebsd-advocacy FreeBSD の福音伝道 freebsd-announce 重要なイベントやプロジェクトのマイルストン freebsd-arch アーキテクチャ, 設計に関する議論 freebsd-bugs バグレポート freebsd-chat FreeBSD コミュニティに関連する技術的ではない話題 freebsd-config FreeBSD のインストールと設定用のツールの開発に関する話題 freebsd-current FreeBSD-current の使用に関連する議論 freebsd-isp FreeBSD を用いている インターネットサービスプロバイダの話題 freebsd-jobs FreeBSD 関連の雇用機会に関する話題 freebsd-newbies FreeBSD 初心者ユーザの活動と議論 freebsd-policy FreeBSD Core team のポリシーに関する議論. 流量は少なく, 投稿することはできません freebsd-questions ユーザからの質問と技術サポート freebsd-stable FreeBSD-stable の使用に関連する議論 freebsd-test メッセージの送信試験を行なうために, 実際のメーリングリストの代わりに使うアドレス 技術的なメーリングリスト: 以下のメーリングリストは, 技術的な 議論のためのものです. それらの利用や内容のためにしっかりとしたガイドラ インがあるので, これらのメーリングリストに入ったり, どれか一つにメール を送ったりする前には, それらのメーリングリストの憲章を注意深く読むべきで す. リスト 目的 freebsd-afs FreeBSD へのAFSの移植 freebsd-alpha FreeBSD の Alpha への移植 freebsd-atm FreeBSD での ATM ネットワーク使用に関する話題 freebsd-audit ソースコード監査プロジェクト freebsd-database FreeBSD 上でのデータベースの利用や開発に関する議論 freebsd-doc FreeBSD 関連ドキュメントの作成 freebsd-emulation Linux/DOS/Windows のような他のシステムのエミュレーション freebsd-fs ファイルシステム freebsd-hackers 一般的な技術の議論 freebsd-hardware FreeBSD の走るハードウェアの一般的な議論 freebsd-i18n FreeBSD の国際化 freebsd-ia64 FreeBSD の Intel が開発中の IA64 システムへの移植 freebsd-ipfw IP firewall コードの再設計に関する技術的議論 freebsd-isdn ISDN 開発者 freebsd-java Java 開発者や, FreeBSD へ JDK を移植する人たち freebsd-libh 第 2 世代のインストール, パッケージシステム freebsd-mobile モーバイルコンピューティングについての議論 freebsd-mozilla mozilla の FreeBSD への移植に関する議論 freebsd-new-bus バスアーキテクチャに関する技術的な議論 freebsd-net ネットワークおよび TCP/IP ソースコードに関する議論 freebsd-platforms Intel 以外のアーキテクチャのプラットフォームへの移植 freebsd-ports Ports コレクションに関する議論 freebsd-ppc FreeBSD の PowerPC への移植 freebsd-realtime FreeBSD 用のリアルタイム拡張の開発に関する話題 freebsd-scsi SCSI サブシステム freebsd-security セキュリティに関する話題 freebsd-security-notifications セキュリティに関する通知 freebsd-small 組み込みアプリケーションにおける FreeBSD の利用 freebsd-smp 対称 / 非対称の マルチプロセッシングの設計に関する議論 freebsd-sparc FreeBSD の Sparc への移植 freebsd-tokenring FreeBSD でのトークンリングのサポート 制限されているメーリングリスト: 以下のメーリングリストはより特化された (そしてより厳しい) メンバーのためのものであり, 一般的な興味を惹くようなものでは ありません. このようなメーリングリストに参加する前に, 技術的なメーリングリストで 自らの存在感をアピールするのは良い考えです. そうすることにより, 議論の際のエチケットを学ぶことができるでしょう. メーリングリスト 目的 freebsd-core FreeBSDコアチーム freebsd-hubs ミラーサイトを運営している人達 (基盤のサポート) freebsd-install インストール関係の開発 freebsd-user-groups ユーザグループの調整 freebsd-www www.freebsd.org の管理者 メーリングリストのダイジェスト版: 上述のメーリングリストの多くでダイジェスト版が利用できます. ダイジェスト版ではメーリングリストに新たに投稿された記事が集められ, 100KB を超えた時点で一つのメールとしてまとめて配送されます. ダイジェスト版が利用できる メーリングリストは以下のとおりです. メーリングリスト freebsd-afs-digest freebsd-alpha-digest freebsd-chat-digest freebsd-current-digest freebsd-cvs-all-digest freebsd-database-digest freebsd-hackers-digest freebsd-ia64-digest freebsd-isdn-digest freebsd-java-digest freebsd-questions-digest freebsd-security-digest freebsd-sparc-digest freebsd-stable-digest freebsd-test-digest CVSメーリングリスト: 以下のメーリングリストはソースツリーの さまざまな場所の変更のログメッセージを見ることに 興味のある人向けです. これらは読み専用のリストで, これらにメールを送る事は出来ません. メーリングリスト ソースの範囲 (ソースの) 範囲の説明 cvs-all /usr/src ツリーのすべての変更 (スーパーセット) 参加方法 どのメーリングリストもFreeBSD.ORGにあるので, メーリングリストにメールを送るには, ただ <listname@FreeBSD.org> にメールを送るだけです. すると, メーリングリストに登録されている世界中のメンバに 再配布されます. メーリングリストに参加するには, subscribe <listname> [<optional address>] という内容をメッセージの本文に含むメールを &a.majordomo; に送ります. 例えば, freebsd-announce に参加したい場合は次のようにします: &prompt.user; mail majordomo@FreeBSD.org subscribe freebsd-announce ^D もし, あなたが, 自分自身を違う名前 (メールアドレス) で登録したい場合, あるいは, ローカルなメーリングリスト (もしあなたのサイトに, 興味を持った仲間がいるなら, これはより有効ですし, 私たちにとっても非常に嬉しいことです.) を登録する申し込みをおこないたいのであれば, 次のようにします: &prompt.user; mail majordomo@FreeBSD.org subscribe freebsd-announce local-announce@somesite.com ^D 最後に, majordomo に対して 他のタイプのコントロールメッセージを送ることで メーリングリストから脱退したり, メーリングリストの他のメンバのリストを 得たり, 再びメーリングリストのリストを見たりすることも可能です. 利用できるコマンドの完全なリストを入手するには, 次のようにします: &prompt.user; mail majordomo@FreeBSD.org help ^D 再度言いますが, 私たちは技術的なメーリングリストでは技術的な議論を保つよう 要求します. もし, 重要なアナウンスにのみ興味があるなら, freebsd-announce への参加をお勧めします. これには, あまりたくさんのメールは流れません. メーリングリストの憲章 全て FreeBSD メーリングリストは誰でもそれらを利用することに 固守しなければいけないという一定の簡単なルールがあります. これらのルー ルに従わないと, 結果として FreeBSD の Postmaster postmaster@FreeBSD.orgから 2 回までは警 告を受けます. 3回違反すると, 投稿者は全てのFreeBSDのメーリングリストか ら削除され, そのメーリングリストへのさらなる投稿から締め出されるでしょ う. これらのルールや対策が必要なのは残念です. しかし, 今日のインターネッ トはずいぶんいやらしい環境になっており, 一般の人々は, その(対策の) メカニズムがいかにもろいかという事すら 認識する事が出来ていないと思われます. 道標 いかなる投稿記事もそのメーリングリストの 基本的な憲章を守るべきで す. 例えば, そのメーリングリストが技術的な問題に関するものであ れば, 技術的な議論を含む投稿でなければなりません. 現在継続中の 不適切な憲章やフレイムは, 所属している全ての人に対してメーリングリスト の価値を下げてしまうだけですし, 許される行為ではないでしょう. とくに話題のない自由形式の議論に対してはfreebsd-chat freebsd-chat@FreeBSD.orgメーリ ングリストが自由に認可されているので, かわりに使うべきでしょう. 一度に 3 つ以上のメーリングリストには決して投稿すべきでは ありません. 2 つのメーリングリストには双方に明確な必要性がある場合にのみ 投稿すべきです. どのリ ストに対しても, (メーリングリストの)参加者は(複数のメーリングリ ストに)重複して参加しており, 関連する部分が少ない(例えば, "-stable と -scsi")メーリングリストを除いては, 一度に複数のメー リングリストに投稿する理由は全くありません. もし, Cc に複数の メーリングリストがそのような形で現れて, あなたに届いたのであれば, 再びそのメールに返事を出す前に, Cc の部分もまた編集するべきです. 元記事を書いたのが誰であっても, あなた自身のクロスポストに まだ責任があります. ユーザであれ開発者であれ, (議論の中で) 個人を攻撃したり冒涜した りすることは許されません. 個人的なメールを引用したり再投稿したり する許可をもらえなかったり, もらえそうにない時に, それをおこなう ようなネチケット (訳注: ネットワークにおけるエチケット) に対する ひどい違反は好まれませんが, してはならないと特別に定められている わけではありません. しかしながら, そのような内容がメー リングリストの憲章に沿う場合はほとんどありません. このため, メー リングリストの憲章に違反しているということだけで警告 (または禁止) に値するものと考えていいでしょう. FreeBSD 以外の関連する製品やサービスの広告は, 絶対に禁止し, spam による違反者が宣伝していることが明確であったら, すぐに禁止しま す. 個々のメーリングリストの憲章: FREEBSD-AFS Andrew ファイルシステム このリストは, CMU/Transarc の AFS の移植や使用に関する議論のためです． FREEBSD-ANNOUNCE 重要なイベント/マイルストン これは, 単にたまに発表される重要な freebsd のイベントに関心がある人のた めのメーリングリストです. これは, スナップショットやその他のリリースに ついてのアナウンスを含みます. そのアナウンスは新しいFreeBSDの機能のア ナウンスを含んでいます. ボランティア等の呼びかけがあるかもしれませ ん. これは流通量の少ないメーリングリストで, 完全なモデレートメーリン グリストです. FREEBSD-ARCH アーキテクチャと設計の議論 これは, FreeBSD のアーキテクチャに関する議論を行なうためのメーリングリストです. 当然, その内容は原則的に技術的なものに限定されます. このメーリングリストにふさわしい話題は以下のようなものです. 複数のカスタマイズされたビルドを同時に行うには, ビルドシステムをどういじり直せばよいか VFS で Heidemann レイヤを動作させるには, 何を修正する必要があるか 同一のデバイスドライバを多数のバス, アーキテクチャに共通で使えるようにするには, デバイスドライバインタフェースをどう改変すれば良いか ネットワークドライバの書き方 FREEBSD-AUDIT ソースコード監査プロジェクト これは, FreeBSD ソースコード監査プロジェクトのメーリングリストです. 本来はセキュリティ関連の変更を行なうためのものだったのですが, 現在の憲章では, ソースコードに対する監査全般のレビューを行なうためのもの, というように拡張されました. このメーリングリストは修正パッチを含んだ, 非常に大きなメッセージが流れます. おそらく, 普通の FreeBSD ユーザが興味を持つものではないでしょう. セキュリティに関する議論のうち, ソースコードの変更とは関係のないものについては freebsd-security で扱われています. 逆に FreeBSD 開発者は修正パッチをこのメーリングリストに送り, レビューを受けてください. これは, その修正パッチにあるバグがシステムの完全性に悪い影響を与える 可能性があるような箇所を扱う場合は特に必要になります. FREEBSD-BUGS バグレポート これは, FreeBSD のバグレポートのためのメーリングリストです. 可能である 場合はいつでも, バグは &man.send-pr.1; を使うか, WEB interfaceを用い て送られる必要があります. FREEBSD-CHAT FreeBSDのコミュニティに関する 技術的ではない話題 このメーリングリストは技術的ではなく, 社会的な情報について, 他のメーリングリストでは取り扱わない話題を含みます. これは, Jordanがシロイタチに似ているかどうか, 大文字で打つかどうか, 誰がたくさんコーヒーを飲むか, どこのビールが一番うまいか, 誰が地下室でビールを作っているか, などについての議論を含みます. 時々重要なイベント (将来開催されるパーティーや, 結婚式, 誕生日, 新しい仕事など) のお知らせが, 技術的なメーリングリストから でてきます. しかし, フォローは直接 -chatメーリングリストにするべきです. FREEBSD-CORE FreeBSDコアチーム これは, コアメンバが使う内部メーリングリストです. FreeBSDに関連する深 刻なやっかい事の裁定や ハイレベルな綿密な調査を要求するときに, このメー リングリストにメッセージを送る事が出来ます. FREEBSD-CURRENT FreeBSD-currentの使用に関する議論 これは freebsd-current のユーザのためのメーリングリストです. メーリングリストでの話題は, -current で登場した新しい機能について, その新機能によってユーザに影響することについての注意, および -current のままでいるために必要な手順についての説明を含みます. current を走らせている人はこのメーリングリストに 登録しなくてはなりません. これは技術的なメーリングリストなので, 完全に技術的な内容を要求します. FREEBSD-CURRENT-DIGEST FreeBSD-currentの使用に関する議論 freebsd-current メーリングリストのダイジェスト版です. このダイジェストは freebsd-current に送られたすべてのメッセージをまとめたものを, 1つのメールにして送り出します. このメーリングリストは 読み専用です. メールを送るような事はしないでください. FREEBSD-DOC ドキュメンテーションプロジェクト このメーリングリストは FreeBSD 向けの文書の作成に関連する事柄やプロジェクトについて議論を行なうためのものです. このメーリングリストに参加しているメンバは, FreeBSD ドキュメンテーションプロジェクトに参加していることになります. このメーリングリストは公開されているので, 参加や投稿は自由に行なうことができます. FREEBSD-FS ファイルシステム FreeBSDのファイルシステムに関する議論 これは技術的なメーリングリストなので, 完全に技術的な内容を要求します. FREEBSD-IPFW IP Firewall これは FreeBSD の IP firewall コードの再設計に関する 技術的な議論のためのフォーラムです. これは技術的なメーリングリストなので, 完全に技術的な内容を要求します. FREEBSD-IA64 FreeBSD の IA64 への移植 これは FreeBSD の Intel の IA-64 プラットフォームへの 移植に参加している人達のための技術的なメーリングリストで, 問題を提起し解決策を議論するためのものです. このような技術的な議論に興味を持つ個人は歓迎します. FREEBSD-ISDN ISDNコミュニケーション このメーリングリストは, FreeBSDに対するISDNサポートの開発の議論を おこなう人のためのものです． FREEBSD-JAVA Javaの開発 このメーリングリストは, FreeBSD - 向けのの重要なJavaアプリケーションの開発や, JDK + 向けの重要なJavaアプリケーションの開発や, JDK の移植やメンテナンスの 議論をする人のためのものです． FREEBSD-HACKERS 技術的な議論 これはFreeBSDに関する技術的な議論のための フォーラムです. これは最もテクニカルなメーリングリストです. このメーリングリストは, FreeBSD 上でアクティブに活動をしている人のためのもので, 問題を持ち出したり, 代わりの解決法を議論します. 技術的な議論をフォローするのに興味がある人も歓迎します. これは技術的なメーリングリストなので, 完全に技術的な内容を要求します. FREEBSD-HACKERS-DIGEST 技術的な議論 freebsd-hackersメーリングリストのダイジェスト版です. このダイジェスト はfreebsd-hackers に送られたすべてのメッセージをまとめたものを, 1つのメー ルにして送り出します. このメーリングリストは読み専用です. メールを送るような事はしないでください. FREEBSD-HARDWARE FreeBSDのハードウェアの一般的な議論 FreeBSDが走っているハードウェアのタイプや, 何を買ったり避けたりするかに関する様々な問題や, 提案に関する議論. FREEBSD-HUBS ミラーサイト FreeBSD ミラーサイトを運用している人達向けの, アナウンスと議論を行なうメーリングリストです. FREEBSD-INSTALL インストールに関する議論 このメーリングリストは将来のリリースの インストールに関する開発の議論のためのものです. FREEBSD-ISP インターネットサービスプロバイダのについての話題 このメーリングリストは, FreeBSDを用いたインターネット サービスプロバイダ (ISP) に関する話題の議論のためのものです. これは技術的なメーリングリストなので, 完全に技術的な内容を要求します. FREEBSD-NEWBIES 初心者の活動の議論 どのメーリングリストでも扱われていなかった 初心者の活動すべてをカバーします. 独学や問題解決, リソースの見つけ方や使い方, 質問のしかた, メーリングリストの使い方, どのメーリングリストを読めばいいのか, 普通の世間話, 間違いの犯し方, 自慢話, アイディアの共有, 物語, 道徳的な (技術的でない) お手伝い, FreeBSD コミュニティでの貢献のしかたなどの話題をが含まれます. これらの問題を取り扱い, freebsd-questions へ質問できるようサポートします. また, 初心者の頃にはまった同じ事柄に悩んでいる 他の初心者との出会いの場としてfreebsd-newbies を活用してください. FREEBSD-PLATFORMS Intel以外のプラットフォームへの移植 クロスプラットフォームのFreeBSDの問題. Intel 以外のプラットフォームへの FreeBSD の移植についての一般的な議論や提案. これは技術的なメーリングリストなので, 完全に技術的な内容を要求します. FREEBSD-POLICY コアチームのポリシーに関する議論 このメーリングリストは, FreeBSD コアチームのポリシーに 関する議論のためのものです. 流量は少なく, 投稿することはできません. FREEBSD-PORTS ports の議論 FreeBSD Ports コレクション (/usr/ports) に関連する話題や, 新たな ports の提案, Ports コレクションの基盤の変更および一般的な構成の整備活動に関する議論. これは技術的なメーリングリストなので, 厳密に技術的な内容のみが扱われます. FREEBSD-QUESTIONS ユーザからの質問 - FreeBSDに関する質問のためののメーリングリストです. + FreeBSDに関する質問のためのメーリングリストです. その質問がかなり技術的だと思わないのであれば, どのようにして という質問を技術的なメーリングリストに 送るべきではありません. FREEBSD-QUESTIONS-DIGEST ユーザからの質問 freebsd-questions メーリングリストのダイジェスト版です. このダイジェストは freebsd-questions に送られたすべてのメッセージをまとめたものを, 1つのメールにして送り出します. FREEBSD-SCSI SCSIサブシステム これは FreeBSD のための scsi サブシステムについて作業している人向けです. これは技術的なメーリングリストなので, 完全に技術的な内容を要求します. FREEBSD-SECURITY セキュリティの関連の話題 FreeBSDコンピュータのセキュリティの話題 (DES, Kerberos, よく知られている セキュリティホールや, それらのふさぎ方など) これは技術的なメーリングリストなので, 完全に技術的な内容を要求します. FREEBSD-SECURITY-NOTIFICATIONS セキュリティ関連の通知 FreeBSD のセキュリティ問題や, 修正に関する通知を行ないます. このメーリングリストは議論を行なうための メーリングリストではありません. 議論は FreeBSD-security で行ないます. FREEBSD-SMALL 組み込み用に FreeBSD を使う 特殊な FreeBSD 小型システムおよび FreeBSD の組み込み技術に関する議論. これは技術的なメーリングリストなので, 完全に技術的な内容を要求します. FREEBSD-STABLE FreeBSD-stable の使用に関する議論 これは freebsd-stable のユーザ用のメーリングリスト です. メーリングリストでの話題は, -stable で登場した新しい 機能について, その新機能によってユーザに影響すること についての注意, および -stable のままでいるために必要な手順についての説明を含みます. stable を走らせている人はこの メーリングリストに登録すべきです. これは技術的なメーリングリストなので, 完全に技術的な 内容を要求します. FREEBSD-USER-GROUPS ユーザグループの調整のメーリングリスト これは, ローカルなユーザグループがお互いに, または, コアチームが指定した個人と問題を議論する, それぞれのローカルエリアのユーザグループからの 調整人向けの メーリングリストです. このメーリングリストはユーザグループ間の ミーティングの概要やプロジェクトの調整に 制限されるべきです. Usenet ニュースグループ 2つのFreeBSD用のニュースグループがあります. ここでは FreeBSDの議論をするたくさんの様々な人がおり, 他にもFreeBSD関連するユーザがいます. これらのいくつかのニュースグループは Warren Toomey wkt@cs.adfa.edu.au によって Keyword searchable archives で, 検索できるようになっています. BSD用のニュースグループ comp.unix.bsd.freebsd.announce comp.unix.bsd.freebsd.misc 関連する他のUnixのニュースグループ comp.unix comp.unix.questions comp.unix.admin comp.unix.programmer comp.unix.shell comp.unix.user-friendly comp.security.unix comp.sources.unix comp.unix.advocacy comp.unix.misc comp.bugs.4bsd comp.bugs.4bsd.ucb-fixes comp.unix.bsd X Window システム comp.windows.x.i386unix comp.windows.x comp.windows.x.apps comp.windows.x.announce comp.windows.x.intrinsics comp.windows.x.motif comp.windows.x.pex comp.emulators.ms-windows.wine World Wide Web サイト &chap.eresources.www.inc; Email アドレス 以下のユーザーグループは, メンバーに FreeBSD に関係する メールアドレスを提供しています. 管理者はアドレスがどのような形であれ 悪用された場合に, アドレスを無効にする権利を留保しています. ドメイン 内容 ユーザーグループ 管理者 ukug.uk.FreeBSD.org forward のみ freebsd-users@uk.FreeBSD.org Lee Johnston lee@uk.FreeBSD.org シェルアカウント 以下のユーザーグループは, FreeBSD Project を活発にサポートしてくれる 人たちにシェルアカウントを提供しています. 管理者はアカウントがどのような形であれ悪用された場合に, アカウントを取り消す権利を留保しています. ホスト アクセス方法 提供内容 管理者 storm.uk.FreeBSD.org SSH のみ Read-only cvs, personal web space, email &a.brian dogma.freebsd-uk.eu.org Telnet/FTP/SSH E-Mail, Web space, Anonymous FTP Lee Johnston lee@uk.FreeBSD.org diff --git a/ja_JP.eucJP/books/handbook/hw/chapter.sgml b/ja_JP.eucJP/books/handbook/hw/chapter.sgml index af08e5436b..a9e37157c5 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 ボートモジュール. ポートそれぞれ最大 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つのグループにに大きく分けられるということを意味しています. + 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/printing/chapter.sgml b/ja_JP.eucJP/books/handbook/printing/chapter.sgml index 1781020969..709a84008b 100644 --- a/ja_JP.eucJP/books/handbook/printing/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/printing/chapter.sgml @@ -1,5296 +1,5296 @@ プリンタの利用 原作: Sean Kelly kelly@ad1440.net、1995 年 9 月 30 日 改訂: &a.jim;、2000 年 3 月 訳: &a.jp.kimura;、1996 年 9 月 3 日 この章では LPD スプーリングシステム 印刷 FreeBSD でプリンタを使用するためには、 バークレーラインプリンタスプーリングシステム (LPD スプーリングシステムとしても知られています) が機能するようにプリンタをセットアップする必要があります。 本章では設定例を通して、LPD スプーリングシステム (大抵の場合、単に LPD と呼ばれる) について紹介します。 もし、LPD や他のプリンタスプーリングシステムについてすでに詳しい知識をお持ちの方は、 スプーリングシステムのセットアップから読み始めても構いません。 はじめに LPD はあるホストのプリンタに関する制御の一切を行ないます。 ここで言う制御としては、次のことがあげられます。 ホストに接続されたプリンタ、 あるいはネットワーク上の他ホストに接続されたプリンタに対するアクセス制御を行ないます。 プリントジョブ ファイルをプリントする要求に対して許可を与えます。 この要求は特にジョブと呼ばれています。 各々のプリンタのキューを管理することにより、 複数のユーザがあるプリンタに対して同時にアクセスすることを防ぎます。 ヘッダページ (バナーまたは バーストページとしても知られています) をプリントすることができます。 これにより、 プリントアウトの山の中から自分がプリントしたジョブを見つけやすくなります。 シリアルポートに接続したプリンタ用に通信パラメータを管理します。 ネットワーク経由で他のホスト上の LPD スプーラにジョブを送ることができます。 様々なプリンタ言語やプリンタの能力に応じてジョブの形式を整えるため、 特別なフィルタを起動することができます。 プリンタの使用に対して課金を行なうことができます。 設定ファイルを通して、あるいは特別なフィルタプログラムを用いることにより、 多種多様なプリンタ機器に対して、 上述の機能の全部または一部を LPD システムに行なわせることができます。 どうしてスプーラを使うべきなのか あなたのシステムを利用するのがあなた一人だけだとしたら、 アクセス制御もヘッダページも プリンタ利用に対する課金も必要ないのに、 なぜわざわざスプーラに煩わされなければならないのか疑問に思うかも知れません。 プリンタに対する直接アクセスを許可することもできるのですが、 とにかくスプーラを使用するべきです。その理由は、 LPD はジョブをバックグラウンドで処理します。 データがプリンタに送信されるまで待つ必要がなくなります。 TeX LPD ではジョブをフィルタを通してプリントすることが簡単にできます。 これにより、印刷物のヘッダに時刻や日付を入れたり、 特別なファイル形式 (TeX の DVI ファイルなど) をプリンタが処理できる形式に変更することができ、 これらの作業を手動で行なう必要がなくなります。 プリント処理を行なうフリー、 または商用のプログラムのほとんどは、 システムのスプーラとやりとりするように作られています。 スプーリングシステムをセットアップすることで、 今後加えるかもしれない、あるいは、 すでに持っている別のソフトウェアをより簡単にサポートすることができるでしょう。 基本的なセットアップ LPD スプーリングシステムを用いてプリンタを使用するためには、 プリンタ機器と LPD 用ソフトウェアの両方を準備する必要があります。 本文書では次の二段階のレベルに分けて説明をします。 プリンタを接続する方法、 プリンタにどのように通信するかを LPD に指示する方法や、 プレインテキストをプリンタで印字する方法については、 プリンタの簡単な設定をご覧ください。 様々な形式のファイルを印字する方法、 ヘッダページを印字する方法、 ネットワーク経由でプリンタに印字する方法、 プリンタを制御する方法、 プリンタの使用に対する課金を行なう方法についてはプリンタ設定 上級編をご覧ください。 プリンタ設定導入編 この節では、プリンタ機器やプリンタを使用するための LPD 用ソフトウェアを設定する方法について述べます。 この節の概要は次のとおりです。 プリンタ機器の設定では、 プリンタをコンピュータに接続するためのヒントがいくつか書かれています。 ソフトウェアの設定では、 LPDのスプーラ設定ファイル /etc/printcap の設定方法について書かれています。 データをプリンタに送るためにシリアルまたはパラレルインタフェースではなく、 ネットワークプロトコルを使用する場合は、 ネットワークにおけるデータストリームインタフェースを持つプリンタをご覧ください。 この節のタイトルは プリンタ設定導入編 ですが、 実際の設定はかなり複雑です。 プリンタをコンピュータに接続し、 LPD スプーラを起動させることは一番困難な作業です。 ヘッダページを出力させたり課金したりするオプションの設定は、 一度プリンタがうまく動くようになればとても簡単です。 プリンタ機器の設定 この節では、プリンタに PC を接続するための様々な方法について説明しています。 ここでは、ポートやケーブルの種類、 FreeBSD がプリンタとの通信に必要なカーネルコンフィグレーションについても言及しています。 もしプリンタが既に接続されていて、 他のオペレーティングシステム上でプリンタからの印字に成功している場合は、 ソフトウェアの設定まで読み飛ばすことが多分できるでしょう。 ポートとケーブル 最近の PC 用のプリンタほとんどには次のインタフェースの一つもしくは両方がついています。 プリンタ シリアル シリアルインタフェースでは、 プリンタにデータを送信するためにコンピュータにあるシリアルポートが使用されます。 シリアルインタフェースはコンピュータ業界で共通して使用されています。 そのケーブルは容易に手に入りますし、簡単に自作することもできます。 シリアルインタフェースの場合は時々、 特別なケーブルや何か複雑な通信方式選択の設定が必要になることがあります。 プリンタ パラレル パラレルインタフェースではプリンタにデータを送信するために、 コンピュータにあるパラレルポートを使用します。 パラレルインタフェースは PC 業界では良く使われます。 ケーブルの入手は容易ですが、 自作するのはシリアルよりも困難です。 パラレルインタフェースには通常、通信方式の選択はなく、 設定は極めて単純です。 セントロニクス パラレルプリンタ パラレルインタフェースは セントロニクス インタフェースとして知られています。 これは、プリンタ用のコネクタタイプとして採用された後に名付けられました。 シリアルインタフェースはパラレルインタフェースよりも普通はデータの伝送速度が遅くなります。 パラレルインタフェースでは、通常、 (コンピュータからプリンタへの) 単方向通信のみを行なうのに対して、 シリアルインタフェースは双方向通信を行ないます。 FreeBSD でも IEEE1284 準拠のケーブルを使えば、 最近のパラレルポートとプリンタの多くで双方向通信を行なうことができます。 PostScript 通常、プリンタで双方向通信が必要となるのは、プリンタが PostScript 言語に対応しているときだけです。 PostScript プリンタは非常に冗長に動作させることができます。 事実、PostScript によるジョブでは、プログラムを本当にプリンタに送信します。 このことは、印字作業を必ずしもする必要がないことを意味しますし、 そのプログラムの結果はコンピュータに直接返されるかも知れません。 PostScript プリンタでは双方向通信を使って PostScript プログラムのエラーや紙づまりといった問題をコンピュータに報告します。 ユーザはそれらの情報を知りたいと思うかも知れません。 また、PostScript プリンタで課金作業をもっとも効率よく行なうためには、 双方向通信が必要となります。 この方法ではまず、プリンタの現在のページカウント (起動してから今まで何枚の紙を印字したか) の情報を得ます。 次に、ユーザのジョブを実行し、終了後、再びページカウントを得ます。 この二つの数を差によって、 課金対象となる紙の枚数を知ることができるのです。 パラレルポート プリンタをパラレルインタフェースを使って接続する場合は、 セントロニクスケーブルでプリンタとコンピュータを接続してください。 詳しい説明はプリンタやコンピュータに付属する説明書に書かれているはずです。 その際、 どのパラレルポートを使用したかを覚えておいてください。 FreeBSD では最初のポートは /dev/lpt0、 二番目 /dev/lpt1 であ り、 三番目以降も同様に続きます。 シリアルポート シリアルインタフェースを使ってプリンタを使う場合は、 適切なシリアルケーブルでプリンタとコンピュータを接続してください。 詳しい説明はプリンタ、コンピュータ、あるいは両方に付属する説 明書に書かれているはずです。 適切なシリアルケーブル が良くわからないときは、 次のどれかを試してみてください。 モデム用ケーブルでは、 それぞれのピンは他方のコネクタの対応するピンと線でつながっています。 このタイプのケーブルは DTE-DCE 間ケーブルとしても知られています (訳注: 日本ではストレートケーブルという名前で売られています)。 ヌルモデム用ケーブル ヌルモデム用ケーブルでは、 あるピンは対応するピンとを接続していますが、 あるピン (たとえば、データ送信用とデータ受信用のピン) が交差して接続したり、 いくつかのピンは内部で短絡していたりします。 このタイプのケーブルは、 DTE-DTE 間ケーブルと呼ばれています (訳注: 日本ではクロスケーブルという名前で売られています)。 A シリアルプリンタ用ケーブルは、 ある特定のプリンタで必要とされるものです。 ヌルモデムケーブルと似ていますが、 内部で短絡させる代わりに、 ある信号を他方側に送るために使用しています。 ボーレート パリティ フローコントロールプロトコル この他に、 プリンタ用の通信パラメータを設定する必要があります。 通常、 プリンタのフロントパネルや DIP スイッチによって制御します。 コンピュータとプリンタの双方で設定できる最高の通信速度 [bps] (ビット/秒、 ボーレートと示されているときもある) を選んでください。そして、データビット (7 または 8)、 パリティ (偶/奇/なし)、ストップビット (1 または 2) を選んでください。 そして、フローコントロールの有無 (制御なし、または XON/XOFF (イン・バンド または ソフトウェア フローコントロールとも呼ばれる)) を選びます。 以下に続くソフトウェアの設定のために、 ここでの設定を覚えておいてください。 ソフトウェアの設定 本節では FreeBSD の LPD スプーリングシステムで印字をおこなうために 必要となるソフトウェアの設定について説明しています。 本節の概要は次のようになります。 プリンタで使用するポートのために、必要があれば、 カーネルの書き変えをおこないます。「カーネルの変更」で、 このためにしなくてはならないことを説明しています。 パラレルポートを使用している場合は、 パラレルポートのための通信モードの設定します。詳細は、「 パラレルポートの通信モードを設定する 」で説明しています。 オペレーティングシステムからプリンタにデータが送ら れているかをテストします。「 プリンタとの通信状況を調べる」で、 どのようにテストするかの提案をいくつかおこなっています。 ファイル/etc/printcapを変更し、 LPDの設定をおこないます。この節で、どのように変更するかを 説明しています。 カーネルの変更 オペレーティングシステムのカーネルの コンパイルをおこなうことによって、 指定されたのデバイスが機能するようになります。シリアル、 または、パラレルインタフェースをプリンタで使用する場合、 必要なデバイスがこの指定の中に含まれていなくてはなりません。 したがって、 必要なデバイスがカーネルに組み込まれていない場合、 追加のシリアル、または、パラレルポートをサポートするために、 カーネルの再コンパイルが必要となるかもしれません。 シリアルポートが現在使用しているカーネルで サポートされているかどうかを調べるためには、 次のように入力します。 &prompt.root; dmesg | grep sioN ここで、N はシリアルポートの番号を示し、この番号は 0 から始まります。 次のような出力があった場合、 カーネルはそのポートをサポートしています。 sio2 at 0x3e8-0x3ef irq 5 on isa sio2: type 16550A パラレルポートが現在使用しているカーネルで サポートされているかどうかを調べるためには、 次のように入力します。 &prompt.root; dmesg | grep lptN ここで、N はパラレルポートの番号を示し、この番号は 0 から始まります。 次のような出力があった場合、 カーネルはそのポートをサポートしています。 lpt0 at 0x378-0x37f on isa 上記の出力が得られない場合、プリンタを使うため、 オペレーティングシステムにパラレル、または、 シリアルポートを認識し、使用できるようにするためには カーネルを変更する必要があります。 シリアルポートをサポートさせるには、「 FreeBSDカーネルのコンフィグレーション」の節をご覧く ださい。パラレルポートをサポートさせる場合も、その節と、 あわせて、 この節に続く節もご覧ください。 ポート用エントリを <filename>/dev</filename> に追加する カーネルがシリアル、または、パラレルポートを通じての通 信をサポートしていたとしても、システム上で動いているプログ ラムがデータの送受信をおこなうための ソフトウェアインタフェースがさらに必要になります。 そのインタフェースは、/dev ディレクトリにあるエントリに相当します。 /dev エントリにポートを加えるために &man.su.1; コマンドで root になります。su コマンド でパスワードを聞かれたら、ルート用のパスワードを入力し ます。 /dev ディレクトリに移動します。 &prompt.root; cd /dev 次のように入力します。 &prompt.root; ./MAKEDEV port ここで、port は、 作成するポート名です。1 番目 のパラレルポートのときは lpt0 に、2 番目のときは lpt1 になり、以降同様になります。 1番目のシリア ルポートのときは、 ttyd0 に、2 番目のときは ttyd1 になり、 これも以降同様となります。 次を入力し、デバイスのエントリができたか確認します。 &prompt.root; ls -l port パラレルポートの通信モードを設定する パラレルインタフェースを使用している場合、FreeBSD では、 割り込み駆動型にするか、 プリンタとの通信の状況をカーネルに監 視させるかのいずれかを選択できます。 GENERIC カーネルでは割り込み駆動方式が、 デフォルトになっています。この方式では、 オペレーティングシ ステムはプリンタがデータを受け付けられるかどうかを調べ るために、IRQ ラインを一つ使用します。 監視方式では、 オペレーティングシステムにプ リンタがもっとデータを受け付けられるかどうかを繰り返し 尋ねるように指示します。そして、受け付けるという応答を 受けたとき、 カーネルはさらなるデータを送信します。 割り込み駆動方式は、いくらか高速になりますが、貴重な IRQ ラインを一つ消費します。 うまく機能するものをお使いください。 通信モードを設定するためには 2 つの方法があります。 1つはカー ネルを変更することで、もう一つは &man.lptcontrol.8; プログラムを使用する方法です。 カーネルを設定することによって、 通信モードを変更する。 カーネルコンフィグレーションファイルを変更します。 lpt0 のエントリを探すか追加してください。2 番目 のパラレルポートを設定するときは、代わりに lpt1 を使います。以下、 3 番目のポートは lpt2 となってい きます。 イベント駆動方式にする場合は、 irq 指定を追加します。 device lpt0 at isa? port? tty irq N vector lptintr ここで、N はパラレルポート用の IRQ 番号です。 監視方式を使用する場合は、 irq を追加してはいけません。 device lpt0 at isa? port? tty vector lptintr ファイルをセーブし、config プログラムを起動し、 カーネルの構築、インストールをおこないます。そして、 リブートしてください。詳細は、「 FreeBSDカーネルのコンフィグレーション」を参照 してください。 &man.lptcontrol.8; で通信モードを設定する場合 lptN をイベント駆動方式に設定する場合は、 次のように入力します。 &prompt.root; lptcontrol -i -u N lptN を監視方式に設定する場合は、次のように入力します。 &prompt.root; lptcontrol -p -u N これらのコマンドを /etc/rc.local ファイルに追加 しておくと、システムをブートする度に通信モードを設定する ことができます。詳細については、 &man.lptcontrol.8; をご覧ください。 プリンタとの通信状況を調べる スプーリングシステムの設定に進む前に、オペレーティング システムがプリンタにデータを送ることに成功しているかどうか を確かめるべきでしょう。これにより、印字がうまくいかないと き、プリンタとの通信が問題なのか、スプーリングシステムが問 題なのかを分けて調べることがかなり容易になります。 プリンタをテストするためには、 プリンタに何かのテキストを送 信してみます。送信した文字をすぐに印字してくれるプリンタに は、&man.lptest.1; コマンドを使うと有用です。このコマンドは印 字可能な 96 文字の ASCII 文字すべてを 96 行生成します。 PostScript PostScript (または他の言語に対応した) プリンタの場合 は、もっと巧妙なテストが必要になります。次のような、簡単な PostScript プログラムを使えば十分でしょう。 %!PS 100 100 moveto 300 300 lineto stroke 310 310 moveto /Helvetica findfont 12 scalefont setfont (Is this thing working?) show showpage 上の PostScript コードはファイルに保存し、 以降の節で例として示されているように利用することができます。 PCL このドキュメントでプリンタ用言語を参照するときは、 PostScript のような言語を仮定しており、Hewlett Packard の PCL は考慮していません。PCL は非常に機能的なの ですが、 プレインテキストにエスケープシーケンスを混ぜること ができます。PostScript ではプレインテキストを直接印字 することはできません。 このような種類のプリンタ言語に対しては、 特別な対応をおこなわなければなりません。 パラレルポートのプリンタとの接続を調べる プリンタ パラレル この節では、FreeBSD がパラレルポートに接続されたプリ ンタと通信できているかどうかを調べる方法について説明し ています。 パラレルポートのプリンタをテストするために &man.su.1; コマンドで root になります。 プリンタにデータを送ります。 プリンタがプレインテキストを印字できる場合、 &man.lptest.1; コマンドを使います。 次のように入力してください。 &prompt.root; lptest > /dev/lptN ここで、N はパラレルポートの番号で、番号は 0 から始まります。 プリンタが PostScript か他のプリンタ 言語を使用している場合、そのプリンタに簡単なプロ グラムを送信してください。次のように入力します。 &prompt.root; cat > /dev/lptN そして、一行一行、 プログラムを慎重に入力して 下さい。RETUREN または ENTER キーを入力してしま うと、その行は編集できなくなります。プログラムの 入力が終わったら、CONTROL+D か、あなたが設定して いるファイル終了のキーを押してください。 もしくは、プログラムを入力したファイルがある 場合は、次のように入力してください。 &prompt.root; cat file > /dev/lptN ここで、file はプログラムが格納されていて、 プリンタに送信するファイルの名前です。 これで何かがプリントされることでしょう。 印字されたテキ ストがおかしくても心配しなくても構いません。それについ ては、後で修正します。 シリアルポートのプリンタとの接続を調べる プリンタ シリアル この節では、FreeBSDがシリアルポートに接続されたプリ ンタと通信できているかどうかを調べる方法について述べられ ています。 シリアルポートのプリンタをテストするために &man.su.1; コマンドで root になります。 /etc/remote ファイルを編集します。次のエントリを加えてください。 printer:dv=/dev/port:br#bps-rate:pa=parity bit/秒 シリアルポート パリティ ここで、port シリアルポート (ttyd0、 ttyd1 など) のデバイスエントリで、 bps-rateは プリンタとの通信の転送速度[bit/秒]、 parityはプリ ンタとの通信で必要とされるパリティ (even、odd、 none、 zeroのいずれか) を表わしていま す。 次の例は、 プリンタをシリアルケーブルでパリティなし、転送速度 19200bps で第 3 番目のシリアルポートに接続した場 合です。 printer:dv=/dev/ttyd2:br#19200:pa=none &man.tip.1; コマンドでプリンタと接続します。 次のように入力してください。 &prompt.root; tip printer これがうまくいかなかった場合は、 /etc/remoteを編集して、 /dev/ttydN の代わりに /dev/cuaaN を試してみてください。 プリンタにデータを送ります。 プリンタがプレインテキストを印字できる場合、 &man.lptest.1; コマンドを使います。 次のように入力してください。 ~$lptest プリンタが PostScript か他のプリンタ 言語を使用している場合、そのプリンタに簡単なプロ グラムを入力します。一行一行、 プログラムを慎 重に入力してください。 バックスペースキーや他の編集用のキーは、 プリンタの制御コードに割り当てられ ているかもしれません。プログラムが終了したことを プリンタに伝えるための特別なファイル終了キーを入 力する必要があるかもしれません。PostScript プリンタの場合、CONTROL+D を入力します。 もしくは、プログラムを入力したファイルがある 場合は、次のように入力してください。 ~>file ここで、file はプログラムが格納されているファイル名です。 &man.tip.1; コマンドでファイルを送信した後は、 ファイル終了を表わすキーを入力する必要があります。 これで何かがプリントされることでしょう。 印字されたテキ ストがおかしくても心配しなくても構いません。 それについては、後で修正します。 スプーラに許可を与える: <filename>/etc/printcap</filename> ファイル ここまでで、プリンタはコンピュータに接続され、(必要なら) プリンタと通信できるようにカーネルを変更し、簡単なデータをプ リンタに送信することができているはずです。これで、LPD にプリ ンタへのアクセスを 制御させる設定をおこなう準備が整いました。 LPD の設定は /etc/printcap を編集することでおこないます。 LPD スプーリングシステムはスプーラが使われる毎にこのファイル を参照します。そのため、ファイルを更新するとすぐにその変更が 反映されます。 プリンタ ケイパビリティ &man.printcap.5; ファイルの書式は簡単です。 /etc/printcap の編集はお好みのテキストエディタをお 使いください。このファイルの書式は、 /usr/share/misc/termcap や /etc/remote といった他のケイパビリティファイルと一致しています。 この書式 のついての詳細な情報については &man.cgetent.3; をご覧ください。 スプーラの単純な設定法は、 次のステップでおこないます。 プリンタに名前 (と簡単な別名 2 〜 3 個) を付け、それを /etc/printcap ファイルに記述します。 これについては、「 プリンタに名前を付ける」 を参照してください。 ヘッダページ sh の項目を追加することで、 ヘッダページの出力を禁止します (デフォルトは許可)。 これについては、「 ヘッダページの印字を禁止する」 を参照してください。 スプール用のディレクトリを作成し、その位置を sd 項目で指定します。これについては、 「 スプーリングディレクトリの作成」 を参照してください。 プリンタを使用するために /dev エントリを設定し、/etc/printcap の lp 項目でそのエントリを指定します。 これについては、「 プリンタデバイスの特定」 を参照してください。 プリンタをシリアルポートに接続した場合は、 fs、fc、 xs、xc の項目を設定する必要があります。こちらについては、 「 スプーラのための通信パラメータの設定」 を参照してください。 プレインテキスト用の入力フィルタのインストールを おこないます。「 テキストフィルタのインストール」 を参照してください。 &man.lpr.1; コマンドで何かを印字することで設定のテス トをおこないます。 印字してみよう と トラブルシューティング を参照してください。 PostScript プリンタのような、 プリンタ言語を使用しているプリンタには、 プレインテキストを直接印字させることができません。 上にアウトラインを示し、 以下の節で説明する簡単な設定方法の説明では、 そのようなプリンタを設置している場合は、 プリンタが認識できるファイルだけを印字の対象としているという 仮定をしています。 多くの場合、 利用者はシステムに設置されているプリンタすべてで プレインテキストが印字できることを期待しています。 印字作業をおこなうために LPD のインタフェースを利用するプログラムでも、 通常、そのような仮定を置きます。 プリンタ言語を使用するプリンタを設置しており、 そのプリンタ言語で記述されたジョブと、 これに加えて、 プレインテキストのジョブも印字できるようにしたいならば、 上で示した簡単な設定方法に加えて、 さらなる設定をおこなうことを強くお勧めします。すなわち、 原始的なプレインテキストから PostScript (もしくは、 他のプリンタ言語) に変換するプログラムをインストールしてください。「 プレインテキストのジョブを PostScript プリンタで印字する」 で、それをどのようにおこなえばよいのかが説明されています。 訳注 日本語を印字したい場合は、プリンタ言語を使用し ていない「日本語プリンタ」についても、 プリンタ固有のエスケープシーケンスを送る必要があります。 また、漢字コードをプリン タが設定しているものに変換したりする必要があり、 各プリンタ毎に、日本語用のフィルタが必要になります。 プリンタに名前を付ける 最初の (簡単な) ステップで、プリンタの名前を考えます。 プリンタには別名をいくつか付けることもできるので、 機能的な名前 でも風変わりな名前でもどちらを選んでもまったく 問題はありません。 少なくとも1つのプリンタには、 /etc/printcap の中で、 lp という別名を持たせるべきでしょう。 この名前はデフォルトのプリンタ名になっています。 ユーザが環境変数 PRINTER を設定しておらず、 かつ、LPD コマンドのコマンドラインで プリンタの名前が指定されていない場合、lp がデフォルトのプリンタ名となり、 そのプリンタに出力されます。 それから、これは共通の慣習ですが、 プリンタの最後の別名には、 メーカーやモデル名を含むプリンタの完全な名称をつけることに なっています。 名前と別名のいくつかを決めたら、 /etc/printcap ファイルに設定します。 プリンタ名は一番左のカラムから書き始めます。 別名はそれぞれ縦棒によって区切られ、 最後の別名の後ろにコロンを置きます。 次の例では、2 台のプリンタ (Diablo 630 ラインプリンタと Panasonic KX-P4455 PostScript レーザライタプリンタ) が定義 されている /etc/printcap のスケルトンを記しています。 # # /etc/printcap for host rose # rattan|line|diablo|lp|Diablo 630 Line Printer: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4: この例では、最初のプリンタに rattan という名前と別名として、line、 diablo、lp そして Diablo 630 Line Printer が付けられています。別名とし て lp があるので、このプリンタはデフォルトのプリンタとなっ ています。2 番目は bamboo と名付けられ、 別名として、ps と PS、S、 panasonic、Panasonic KX-P4455 PostScript v51.4 が付けられています。 ヘッダページの印字を禁止する 印刷 ヘッダページ LPDスプーリングシステムでは、 デフォルトでジョブ毎に ヘッダページを印字します。 ヘッダページにはジョブを要求したユーザ名、 ジョブが送られたホスト名、そして、ジョブの名前が素晴 らしい大きな文字で印字されています。 残念なことに、この余分なテキストすべてが、 簡単なプリンタ設定法のデバッグの際に紛れ込んできてしまいます。 このため、ヘッダページの出力を禁止しておきます。 ヘッダページの出力を禁止するには、 /etc/printcap にあるプリンタのエントリに sh の項目を追加します。次に、sh を加えた /etc/printcap の例を示します。 # # /etc/printcap for host rose - no header pages anywhere # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh: この書式を正しく使うための注意をしておきます。 最初の行は左端のカラムから始まります。それに続く行は TAB ひとつ分だけ字下げします。最後の行以外のすべての行は、 行末にバックスラッシュを記述します。 スプーリングディレクトリの作成 プリンタスプール プリントジョブ スプーラの簡単な設定の次のステップでは、 スプーリングディレクトリを作成します。 プリンタに送られるジョブは、 その印字が終了するまでこのディレクトリに置かれます。また、 他のたくさんのスプーラもこのディレクトリにファイルを置きます。 様々な事情によりスプーリングディレクトリは、通常、慣例 として /var/spool の下に置きます。 また、スプーリングディレクトリの内容は バックアップをする必要はありません。 &man.mkdir.1; によってディレクトリを 作るだけでスプーリングディレクトリの復旧は完了します。 スプーリングディレクトリの名前は、これも慣例ですが、 次のようにプリンタの名前と同じにします。 &prompt.root; mkdir /var/spool/printer-name しかしながら、ネットワーク上に使用可能なプリンタがたく さんあるならば、LPD で印字するための専用のディレクトリに スプーリングディレクトリを置きたいと思うかもしれません。 例に出てきたプリンタ rattan と bamboo について、この方式を採用すると、 次のようになります。 &prompt.root; mkdir /var/spool/lpd &prompt.root; mkdir /var/spool/lpd/rattan &prompt.root; mkdir /var/spool/lpd/bamboo 各ユーザが印字するジョブのプライバシを守りた いと考えているならば、スプーリングディレクトリを保護し て、これを誰からでもアクセスできないようにしたいと思う かもしれません。スプーリングディレクトリは、deamon ユー ザと daemon グループに所有され、読み込み、書き込み、検 索可能であり、他からはアクセスできないようにするべきで す。例題のプリンタに対して、次のようにすることにしましょ う。 &prompt.root; chown daemon:daemon /var/spool/lpd/rattan &prompt.root; chown daemon:daemon /var/spool/lpd/bamboo &prompt.root; chmod 770 /var/spool/lpd/rattan &prompt.root; chmod 770 /var/spool/lpd/bamboo 最後に、/etc/printcap ファイルで、 これらのディ レクトリの位置を LPD に伝える必要があります。 スプーリ ングディレクトリのパス名は sd 項目で指定します。 # # /etc/printcap for host rose - added spooling directories # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo: プリンタ名が最初のカラムから始まっており、そのプリンタ に関して記述される他のエントリは TAB で字下げされてい ること、各行がバックスラッシュで終わっていることに注意 してください。 sd によりスプーリングディレクトリが指定されていな い場合、 スプーリングシステムは /var/spool/lpd デフォルト値として使用します。 プリンタデバイスの特定 「ポート用エントリを /dev に追加する」では、FreeBSD でプリン タとの通信に使用される /dev ディレクトリ内のエントリを特定します。そして、LPD にその情報を伝えます。印字するジョブを受け取ると、 スプーリングシステムは、 (プリンタにデータを渡す義務がある) フィルタプログラムに 代わって指定されたデバイスをオープンします。 /etc/printcap ファイルで lp 項目を使って /dev エントリを記入します。 ここでの例では、rattan は 1 番目のパラレルポートに、bamboo は 6 番目のシリアルポートに接続されていることにしましょう。 このとき、/etc/printcap には 次のようになります。 # # /etc/printcap for host rose - identified what devices to use # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:\ :lp=/dev/ttyd5: /etc/printcap でプリンタの lp 項目が指定 されていない場合は、LPD はデフォルトとして /dev/lp を使用します。/dev/lp は、現在の FreeBSD には存在していません。 設置したプリンタがパラレルポートに 接続されている場合は、 「 テキストフィルタのインストール」 まで読み飛ばしてください。 そうでない場合は、次節の説明に続いてください。 スプーラのための通信パラメータの設定 プリンタ シリアル シリアルポートにプリンタを接続した場合、 プリンタにデータを送信するフィルタプログラムに代わり、 通信速度やパリティ、 その他のシリアル通信パラメータを設定することができます。 このことによる利点は、 /etc/printcap を編集するだけで、 様々な通信パラメータを試してみることができます。 フィルタプログラムを再コンパイルする必要はありません。 スプーリングシステムで、 シリアル通信の設定が異なっているかもしれない複数のプリンタに 同じフィルタプログラムを使うことが可能になります。 次の /etc/printcap の項目で、 lp で指定された デバイスのシリアル通信パラメータを制御できます。 br#bps-rate デバイスの通信速度を bps-rate に設定します。 ここ で、bps-rate は 50、 75、110、134、150、200、300、600、1200、1800、2400、 4800、9600、19200、38400[bit/秒] のいずれかです。 fc#clear-bits デバイスをオープンした後で、 sgttyb 構造体の clear-bits フラグビットをクリアします。 fs#set-bits sgttyb 構造体の clear-bits フラグビットをセットします。 xc#clear-bits デバイスをオープンした後で、ローカルモードビット clear-bits をクリアします。 xs#set-bits ローカルモードビット set-bits をセットします。 fc、fs、 xc、そして xs のビットに関する詳しい情報については、 /usr/include/sys/ioctl_compat.h を参照してください。 項目 lp で指定されたデバイスを LPD がオープンするとき、LPD は sgttyb 構造体のフラグビットを読み出します。そして、項目 fc の全ビットをクリアします。次に、 項目 fs のビットをセットし、 その結果を設定します。 ローカルモードビットに関しても同様におこなわれます。 例題のプリンタで6番目のシリアルポートに接続された プリンタの設定を追加してみましょう。 通信速度は 38400bps に設定します。 フラグビットとして、TANDEM、ANYP、LITOUT、 FLUSHO、PASS8 をセットします。ローカルモードビットでは、 LITOUT と PASS8 フラグをセットします。 bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:\ :lp=/dev/ttyd5:fs#0x82000c1:xs#0x820: テキストフィルタのインストール プリントフィルタ ここまでで、 プリンタにジョブを送るために使うテキストフィ ルタを LPD に設定する準備が整いました。 テキストフィルタとは、 入力フィルタとしても知られていますが、 印字するジョブがあるときに LPD が起動するプログラムです。 LPD がプリンタのためにテキストフィルタを起動するとき、LPD はフィルタの標準入力からプリントするジョブを入力し、 フィルタの標準出力に項目 lp で指定されたプリンタデバイスを接続します。フィルタは、 標準入力からジョブを読み込み、 プリンタのための必要な変換をおこなった後、 その結果を標準出力に出力する、 これにより印字がなされることを期待されています。 テキストフィルタについての更に詳しい情報については、「 フィルタはどのように機能しているか」 をご覧ください。 ここでの簡単なプリンタ設定では、 プリンタにジョブを送るため、/bin/cat を実行するだけの簡単なシェルスクリプトで間に合います。 FreeBSD に標準で付属している lpf というフィルタでは、バックスペース文字を使った 下線引きの動作をおこなう文字ストリームをうまく扱うことができない プリンタのための代替処理をおこなってくれます。 もちろん、 他のどんなフィルタプログラムを使っても構いません。 フィルタ lpf については、「テキストフィルタ lpf」で詳しく説明します。 最初に、簡単なテキストフィルタであるシェルスクリプト /usr/local/libexec/if-simple を作ってみましょう。 次のテキストをお好みのテキストエディタでファイルに 書き込んでください。 #!/bin/sh # # if-simple - Simple text input filter for lpd # Installed in /usr/local/libexec/if-simple # # Simply copies stdin to stdout. Ignores all filter arguments. /bin/cat && exit 0 exit 2 そして、このファイルを実行可能にします。 &prompt.root; chmod 555 /usr/local/libexec/if-simple LPD にこのテキストフィルタを使うことを設定するためには、 /etc/printcap に if 項目を使って指定します。これまでの /etc/printcap の例のプリンタ 2 台に、 このフィルタを加えてみましょう。 # # /etc/printcap for host rose - added text filter # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:\ :lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:\ :if=/usr/local/libexec/if-simple: LPD を起動します &man.lpd.8; は lpd_enable 変数に従って /etc/rc から実行されます。この変数の デフォルト値は NO です。まだ そうしていなかったならば lpd_enable="YES" の行を /etc/rc.conf に追加して 計算機を再起動するか、そのまま &man.lpd.8; を 起動してください。 &prompt.root; lpd 印字してみよう 簡単な LPD 設定も終わりにたどり着きました。残念ながら、 設定はこれでおしまいというわけではありません。なぜなら、 さらに、設定をテストし、 すべての問題点を解決しなくてはならないからです。 設定をテストするために、 何かを印字してみましょう。LPD システムで印字をするためには、 &man.lpr.1; コマンドを使います。このコマンドは、 印字するためのジョブを投入する働きをします。 &man.lpr.1; コマンドを 「 プリンタとの通信状況を調べる」で紹介した、 あるテスト用のテキストを生成してくれる &man.lptest.1; プログラムと一緒に使うこともできます。 簡単な LPD 設定をテストするために: 次のように入力してください。 &prompt.root; lptest 20 5 | lpr -Pprinter-name ここで、printer-name は /etc/printcap で指定したプリンタ名 (もしくはその別名) です。デフォルト のプリンタを使用する場合は、 引数を付けないで &man.lpr.1; を打ち込んでください。もう一度述べますが、 ポストスクリプトを期待しているプリンタをテストするならば、 &man.lptest.1; を使う代わりに PostScript で書かれた プログラムをプリンタに送ってください。 プログラムを送るためには、プログラムをファイルに格納して、 lpr file と打ち込みます。 PostScript プリンタの場合、 送信したプログラムによる結果が得られるでしょう。 &man.lptest.1; を使った場合は、 以下のような結果が見られるでしょう。 !"#$%&'()*+,-./01234 "#$%&'()*+,-./012345 #$%&'()*+,-./0123456 $%&'()*+,-./01234567 %&'()*+,-./012345678 更にプリンタをテストしたい場合は、 (言語ベースのプリンタのための) もっと大きなプログラムを送信するか、 引数を変えて &man.lptest.1; を実行します。例えば、lptest 80 60 で、それぞれ 80 文字の行を 60 行生成します。 プリンタがうまく動かなかった場合は、次の節、「 トラブルシューティング」をご覧ください。 プリンタ設定上級編 この節では、特殊な形式のファイルを印字するためのフィルタ、 ヘッダページ、ネットワーク越しのプリンタへの印字、そして、 プリンタ使用の制限や課金について説明しています。 フィルタ プリントフィルタ LPD では、ネットワークプロトコル、キュー、アクセス制御、 そして、印字のためのその他の側面について扱いますが、 実際の作業のほとんどは フィルタ よっておこなわれています。 フィルタは、プリンタと通信し、 プリンタのデバイス依存性や特殊な要求を扱うプログラムです。 簡単なプリンタ設定では、 プレインテキストのためのフィルタをインストールしました。 このプレインテキストフィルタは、 ほとんどのプリンタで機能する極めて単純なものでした (「 テキストフィルタのインストール」を参照)。 しかしながら、形式変換やプリンタ課金、特定のプリンタの癖、 など をうまく利用するためには、 フィルタがどのように機能するかという ことを理解しておくべきです。これらの側面を扱うためには、 最終的には、フィルタの責任であるからです。 そして、これは悪い情報ですが、ほとんどの場合において、 あなた自身が フィルタを供給する必要があるということです。また都合のよいことには、 たくさんのフィルタが一般的に利用できるということです。 もしフィルタがなかったとしても、 普通はフィルタを作るのは簡単です。 FreeBSD にも、プレインテキストを印字させることができる /usr/libexec/lpr/lpf というフィルタが 1 つ付いています (このフィルタはファイルに含まれるバックスペースやタブを扱います また、課金をすることもできますが、 できることはこれだけしかありません)。 いくつかのフィルタとフィルタの構成要素は FreeBSD Ports Collection にもあります。 この節で述べることは次の通りです。 「 フィルタはどのように機能しているか」では、 印字の過程におけ るフィルタの役割を概説します。 この節を読むことで、LPD がフィルタを使うときに、 見えないところで 何が 起こっているかが理解できるでしょう。このことを知っておくと、 プリンタそれぞれに様々なフィルタをインストールしたときに 遭遇するかもしれない問題を予期したり、 デバッグするときに役立つでしょう。 LPD では、すべてのプリンタからデフォルトで プレインテキストを印字できることを期待しています。このことは、 プレインテキストを直接印字できない PostScript (また は他の言語用の) プリンタでは問題を引き起こします。「 プレインテキストのジョブを PostScript プリンタで印字する」 で、 この問題を克服する方法について述べます。 PostScript プリンタをお持ちの方は、 この節をお読みになることをおすすめします。 PostScript は様々なプログラムのための有名な出 力形式です。ある人たちは (著者自身を含めて) PostScript のコードさえも直接書いてしまいます。しかし、PostScript プリンタは高価です。「非 PostScript プリンタで PostScript をシミュレートする」では、PostScript データを非 PostScript プリンタに受けつけさせ、 印字させるために、 どのようにしてプリンタ用のテキストフィルタをさらに変更すればよいのか、 ということについて述べます。PostScript プリンタを持っていない方は、 この節をお読みになることをおすすめします。 「 変換フィルタ」では、 図形や組版データといった特定のファイル形式を、 プリンタが理解できる形式へ変換する作業を自動的におこなわせる方法について述べます。 この節を読むと、troff のデータを印字するには lpr -t、または、TeX DVI を印字するには lpr -d、 ラスタイメージデータを印字するには lpr -v、 などといったようにユーザが入力することができるように プリンタの設定をおこなうことができます。 この節もお読みになることをお薦めします。 「出力フィルタ」 では、あまり使われない LPD の機能のすべて、すなわち、 出力フィルタに関することが記述されています。ヘッダページ (「 ヘッダページ」参照) を印字させていない場合は、 多分、この節は飛ばしても構わないでしょう。 「テキストフィルタ lpf」では、lpf についての説明が、ほぼ完全におこなわれています。これは FreeBSD に付属するラ インプリンタ (または、 ラインプリンタのように動作するレーザプリンタ) のための、 単純なテキストフィルタです。 プレインテキストを印字したことに対して課金をおこなう方法が 至急必要な場合、もしくは、バックスペース文字を印字しようと すると煙を発するプリンタを持っている場合は、絶対に lpf を検討するべきです。 フィルタはどのように機能しているか 既に言及したように、フィルタとは、プリンタにデータを送る際に、 デバイスに依存した部分を取り扱うために LPD によって起動される実行プログラムです。 LPD がジョブ中のファイルを印字しようとするとき、LPD はフィルタプログラムを起動します。このとき、 フィルタの標準入力を印字するファイルに、 標準出力をプリンタに、そして、標準エラー出力を エラーログファイル (/etc/printcap 内の lf 項目で指定されたファイル、または、 指定されていない場合は、デフォルトとして /dev/console) にセットします。 troff LPD が起動するフィルタと、その引数が何であるかは、 /etc/printcap ファイルの内容と、ジョブの起動時にユーザが指定した &man.lpr.1; コマンドの引数に依存しています。 例えば、ユーザが lpr -t と入力した場合は、 LPD は出力先のプリンタ用の tf 項目で指定されている troff 用のフィルタを起動させるでしょう。 ユーザがプレインテキストの印字を指示したときは、 if で指定されたフィルタが起動されるでしょう (このことはほとんどの場合にあてはまります。 詳細については、「 出力フィルタ」をご覧ください)。 /etc/printcap で指定可能なフィルタは次の3種類があります。 テキストフィルタ (LPD のドキュメントでは紛らわしいことに 入力フィルタと呼んでいますが) は一般のテキストの印字を扱います。これはデフォルトのフィルタと 考えてください。LPD では、すべてのプリンタに対して、 デフォルトでプレインテキストが印字できることを期待しています。 さらに、バックスペースやタブを正しく扱い、また、 他の特殊な文字が入力されてもプリンタに混乱を来さないように するのはテキストフィルタの仕事であると考えています。 プリンタの使用に対して課金をしなくてはならない環境にあ るときは、テキストフィルタが印字したページ数を数える作 業もしなくてはなりません。この作業は、通常、印字した行 数を数え、これをプリンタが 1 ページ当たりに印字できる行 数と比較することでおこなわれます。 テキストフィルタは、次のような引数を付けて起動されます。 filter-name -c -wwidth -llength -iindent -n login -h host acct-file ここで、 lpr -l によってジョブが入力されたときに与えられます。 width /etc/printcap で指定された pw (page width) 項目の値が与えられます。デフォルトは、 132 です。 length pl (page length) 項目で指定された値が与えられます。 デフォルトは 66 です。 indent lpr -i によって与えられた字下げの量で、 デフォルトは 0 です。 login ファイルを印字したユーザのアカウント名が 与えられます。 host ジョブが入力されたホスト名が 与えられます。 acct-file af 項目で指定されている課金データファイル の名前が与えられます。 プリンタ フィルタ 変換フィルタは、 特定のファイル形式をプリンタ が紙に印字できるようなものに変換します。例えば、 プリンタで ditroff 組版データを直接印字することはできません。 しかし、ditroff データをプリンタが消化し、 印字することができる形式へ変換するために、ditroff ファイル用フィルタをインストールすることができます。 「 変換フィルタ」 で、これらに関するすべてについて説明します。 プリンタの課金をする必要がある場合は、 変換フィルタでも印字ページを数える作業が必要となります。 変換フィルタは次の引数をとって起動されます。 filter-name -xpixel-width -ypixel-height -n login -h host acct-file ここで、pixel-width は、 px 項目で指定された値 (デフォルトは 0)、 pixel-height は、 py 項目で指定された値 (デフォルトは 0) です。 出力フィルタは、 テキストフィルタが指定されて おらず、かつ、 ヘッダページの出力が許可されている場合にのみ使われます。 「 出力フィルタ」で、これらのことについて説明します。 アウトプットフィルタに対する引数は次の 2 つだけです。 filter-name -wwidth -llength ここで、 と は、 テキストフィルタの場合と同じです。 フィルタは、次に示すの終了状態をもってプログラムを exit するべきです。 exit 0 フィルタがファイルを正常に印字した場合。 exit 1 フィルタはファイルの印字に失敗したが、LPD に再度ファイルの印字を試みて欲しい場合。 この終了状態で終了した場合、LPD はフィルタを再スタートします。 exit 2 フィルタはファイルの印字に失敗し、かつ、LPD に再出力を試みて欲しくない場合。この場合、LPD はそのファイルを放棄します。 FreeBSD に付属するテキストフィルタ /usr/libexec/lpr/lpf は、FORM FEED 文字が送られたときやプリンタ使用に対する課金をどのようにするかを決定するために、 ページ幅やページ長の引数を利用します。また、 課金用のエントリを作成するため、ログイン名、ホスト名、 課金ファイル名の引数を利用します。 もし、フィルタの購入を検討しているならば、LPD と互換性があるかどうかを確認してください。もしそうならば、 上述の引数リストをサポートしていなければなりません。 一般向けの使用のためにフィルタを作成する計画をしている場合は、 同じ引数リストと終了コードをサポートしてください。 プレインテキストのジョブを PostScript プリンタで印字する プリントジョブ コンピュータと PostScript (または、他の言語に対応した) プリンタをあなたしか使用しない場合は、プリンタにプレ インテキストを絶対に送らない、そして、 プリンタにプレインテキストを送りたがっている 様々なプログラムの機能を決して使わないことにしてください。そうすれば、 この節に書かれたことに心を煩わせる必要はまったくなくなります。 しかし、PostScript とプレインテキストの両方のジョブをプリンタへ送りたいと思っている場合は、 プリンタ設定についての要求が増えるでしょう。 両者をプリンタへ送信するためには、 到着したジョブがプレインテキストであるか PostScript であるかを検出するテキストフィルタが必要です。 PostScript のジョブはすべて %! で始まらなければならないことになっています (他のプリンタ言語に関しては、 プリンタのドキュメントをご覧ください)。 ジョブの最初の 2 文字がこれならば、PostScript であることが分かります。 したがって、 ジョブのそれ以降の部分をプリンタに直接送ることができます (訳注: PostScript では、% 以降はコメントとして扱われるので、最初の %! の行を読み捨てても問題はない)。 最初の2文字が %! でない場合は、 フィルタはテキストを PostScript に変換し、 その結果を使って印字をおこないます。 この作業をどうやってやればよいのでしょうか。 プリンタ シリアル シリアルポートにプリンタを接続した場合は、 lprps をインストールすることをお勧めします。 lprps は PostScript 用のフィルタで、 プリンタとの双方向通信をおこないます。 このフィルタでは、プリンタからの冗長な情報を得ることで、 プリンタの状況を示すファイルが更新されていきます。 したがって、ユーザや管理者は (トナー残量少や 紙詰まりといった) プリンタの状況を正確に知ることができます。しかし、 もっと重要なことは、psif と呼ばれるプログラムが含まれているということです。 このプログラムは、 入力されたジョブがプレインテキストかどうかを検出し、 これを PostScript に変換するために、textps (lprps に付属する別のプログラム) を呼び出します。そして、このジョブをプリンタに送るために、 lprps が使われます。 lprps は FreeBSD Ports Collection に含まれています (Ports Collection を参照してください)。 もちろん、自分自身でプログラムを取ってきて、コンパイルし、 インストールすることもできます。lprps をインストールした後は、lprps の一部である psif プログラムのパス名を指定するだけです。Ports Collection から lprps をインストールしたときは、 /etc/printcap の中のシリアル接続した PostScript プリンタのエントリに対して、次を使ってください。 :if=/usr/local/libexec/psif: LPD にプリンタをリード・ライトモードでオープンさせるために、 rw 項目も指定すべきです。 パラレルポートに接続したプリンタの場合 (すなわち、 lprps が 必要としているプリンタとの双方向通信ができない)、 テキストフィルタとして次のシェルスクリプトを使うことができます。 #!/bin/sh # # psif - Print PostScript or plain text on a PostScript printer # Script version; NOT the version that comes with lprps # Installed in /usr/local/libexec/psif # IFS="" read -r first_line first_two_chars=`expr "$first_line" : '\(..\)'` if [ "$first_two_chars" = "%!" ]; then # # PostScript job, print it. # echo "$first_line" && cat && printf "\004" && exit 0 exit 2 else # # Plain text, convert it, then print it. # ( echo "$first_line"; cat ) | /usr/local/bin/textps && printf "\004" && exit 0 exit 2 fi 上記のスクリプトにおいて、textps はプレインテキストから PostScript へ変換するために別にインストールしたプログラムです。 テキストから PostScript へ変換するのには、お好みのどんなプロ グラムでも使うことができます。FreeBSD Ports Collection (Ports Collection を参照してください) には、a2ps と呼ばれるテキストから PostScript に変換するプログラムが入っています。 非 PostScript プリンタで PostScript をシミュレートする PostScript エミュレーション Ghostscript PostScript は質の高い組版と印字をおこなうための事実 上の標準です。しかしながら、PostScript は、 高価な標準です。ありがたいことに、 Alladin Enterprises から Ghostscript と呼ばれる、 PostScript 互換の動作をするフリーのプログラムが出されていて、 FreeBSD で動きます。 Ghostscript はほとんどの PostScript ファイルを読むことができ、 これらの各ページをたくさんのブランドの非 PostScript プリンタを含む 様々なデバイス用に変換することができます。 Ghostscript をインストールし、 プリンタ用の特別なテキストフィルタを使うことによって、 非 PostScript プリンタをあたかも本物の PostScript プリンタであるかのように動作させることができます。 Ghostscript は FreeBSD Ports Collection に入っていますので、 そこからインストールすることができます。また、 自分でソースプログラムを持ってきて、コンパイルし、インストー ルすることもできます。この作業はとても簡単にできます。 PostScript プリンタをシミュレートさせる場合は、 テキストフィルタに PostScript ファイルを印字しようとしているかどうかを検出させます。 PostScript ファイルでない場合は、 フィルタはそのファイルを直接プリンタに送ります (訳注: テキストファイルを直接印字できない場合は、もちろん、 変換フィルタを通す必要があります)。PostScript の場合は、 まず、Ghostscript を使い、 ファイルをそのプリンタが理解できる形式へ変換します。 次の例のスクリプトは、Hewlett Packard DeskJet 500 プリンタ用 のテキストフィルタです。 他のプリンタで用いるときは、 引数を gs (Ghostscript) コマンドに変えてください (gs -h と入力すると、現在インストールされている Ghostscript でサポートされているデバイスのリストが得られます)。 #!/bin/sh # # ifhp - Print Ghostscript-simulated PostScript on a DeskJet 500 # Installed in /usr/local/libexec/hpif # # Treat LF as CR+LF: # printf "\033&k2G" || exit 2 # # Read first two characters of the file # IFS="" read -r first_line first_two_chars=`expr "$first_line" : '\(..\)'` if [ "$first_two_chars" = "%!" ]; then # # It is PostScript; use Ghostscript to scan-convert and print it. # # Note that PostScript files are actually interpreted programs, # and those programs are allowed to write to stdout, which will # mess up the printed output. So, we redirect stdout to stderr # and then make descriptor 3 go to stdout, and have Ghostscript # write its output there. Exercise for the clever reader: # capture the stderr output from Ghostscript and mail it back to # the user originating the print job. # exec 3>&1 1>&2 /usr/local/bin/gs -dSAFER -dNOPAUSE -q -sDEVICE=djet500 \ -sOutputFile=/dev/fd/3 - && exit 0 # /usr/local/bin/gs -dSAFER -dNOPAUSE -q -sDEVICE=djet500 -sOutputFile=- - \ && exit 0 else # # Plain text or HP/PCL, so just print it directly; print a form # at the end to eject the last page. # echo "$first_line" && cat && printf "\033&l0H" && exit 0 fi exit 2 最後に、if 項目を通して、LPD にこのフィルタを教えてやる必要があります。 :if=/usr/local/libexec/hpif: これでおしまいです。lpr plain.text とか lpr whatever.ps と入力してみましょう。どちらも正常に印字されるはずです。 訳注 日本語を印字する場合は、 日本語対応の Ghostscript が必要です。日本語対応版の Ghostscript も Ports Collection に入っています。 変換フィルタ 「プリンタ設定導入編」 に書かれた簡単な設定が完了したら、最初に、 やってみたいと思うことは、多分 (プレイン ASCII テキストに加えて) 好みのファイル形式のための変換フィルタをインストールすることでしょう。 なぜ、変換フィルタをインストールするのか? TeX dvi ファイルの印刷 変換フィルタによって、 様々な種類のファイルを印字することが簡単になります。例えば、TeX 組版システムでたくさんの仕事をしたと仮定しましょう。 そして、PostScript プリンタが接続 されているとします。 すると、TeX で DVI ファイルを作成する度に、DVI ファイルを印字するために、 これを PostScript ファイルに変換する必要があります。 このコマンドは次のようになるでしょう。 &prompt.user; dvips seaweed-analysis.dvi &prompt.user; lpr seaweed-analysis.ps DVI ファイル用の変換フィルタがインストールしてあると、 LPD に 変換を肩代わりさせることで毎回毎回 おこなわなければならなかった面倒な変換作業を省くことができます。 つまり、DVI を生成したら、 次のような 1 回のコマンド入力だけで、これが印字されます。 &prompt.user; lpr -d seaweed-analysis.dvi LPD に DVI ファイルの変換をさせるためには、 オプション を指定します。 変換オプションのリストは「 整形と変換に関するオプション」 に載せてあります。 変化のオプションのそれぞれをプリンタに サポートさせるためには、 変換フィルタをインストールし、 そのパス名を /etc/printcap の中で指定しなくてはなりません。変換フィルタは、 プレインテキストを印字する代わりに、フィルタはファイルを プリンタが理解できる形式に変換するところを除けば、 「プリンタの簡単な設定」で説明したテキストファイル (「 テキストフィルタのインストール」 を見て下さい) に似ています。 どの変換フィルタをインストールすべきか? 使いたいと思う変換フィルタをインストールすべきです。 DVI のデータを頻繁に印字するならば、DVI 変換フィルタ をインストールするのが適切でしょう。印字しなくてはなら ない troff を大量に抱えている場合は、多分、 troff フィルタが欲しくなるはずです。 次の表は、LPD で動作するフィルタと、 /etc/printcap ファイルでのエントリする項目、そして、 lpr コマンドで呼び出す方法をまとめたものです。 ファイル形式 /etc/printcap項目 lpr オプション cifplot cf DVI df plot gf ditroff nf FORTRAN text rf troff tf raster vf プレインテキスト if なし、、または 先の例のように、lpr -d を使うためには、出力先のプリンタの /etc/printcap 内のエントリで、 df 項目が必要であることが分かります。 fortran 反論はあるかも知れませんが、FORTRAN テキストや plot のような形式は、多分、廃れてていくでしょう。 あなたのサイトで、自前のフィルタをインストールするだけで、 プリントオプションのいくつか、あるいは、 全部に新しい意味を与えることができます。例えば、 Prinerleaf ファイル (Interleaf デスクトップパブリッシングプログラムによるファイル) を直接印字したいとします。 そして、Printerleaf 用の変換フィルタを gf 項目で 指定したパスにインストールすれば、lpr -g の意味は Printerleaf ファイルを印字する 意味だとユーザに教えることができます。 変換フィルタのインストール 変換フィルタは FreeBSD の基本システムのインストールとは別にインストールするプログラムなので、 変換フィルタは、多分、 /usr/local ディレクトリの下に置くべきです。 フィルタは LPD だけが実行する特別なプログラム、 すなわち、一般ユーザが実行する必要すらないプログラムなので、 /usr/local/libexec ディレクトリに置くのが普通です。 変換フィルタを使用可能にするためには、 /etc/printcap の目的のプリンタの適切な項目に フィルタがあるパス名を指定します。 DVI 変換フィルタをプリンタ bamboo のエントリに加えてみましょう。プリンタ bamboo の df 項目を新たに加えた /etc/printcap ファイルの例を以下に再掲します。 # # /etc/printcap for host rose - added df filter for bamboo # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:\ :lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf: DVI フィルタは /usr/local/libexec/psdf という 名前のシェルスクリプトです。 このスクリプトは次のようになっています。 #!bin/sh # # psdf - DVI to PostScript printer filter # Installed in /usr/local/libexec/psdf # # Invoked by lpd when user runs lpr -d # exec /usr/local/bin/dvips -f | /usr/local/libexec/lprps "$@" このスクリプトでは、dvips をフィルタモード (引数 ) で、 標準入力上で起動しています。標準入力は印字するジョブです。 それから、PostScript プリンタ用フィルタ lprps (これについては「 プレインテキストのジョブを PostScript プリンタで印字する」 を参照してください) を LPD に与えられた引数を付けて起動します。 lprps はこれらの引数を印字されたページ分の課金をおこなうために使われます。 変換フィルタのその他の例 変換フィルタのインストールには決まったステップがないので、 その代わりに、例をもっと挙げることにします。 これを自分でフィルタを作る際のガイドにしてください。 適当な例があったら、それをそのまま使ってください。 次のスクリプト例は、Hewlett Packard LaserJet III-Si のための、raster (ええと・・実は、GIF ファイル) 用の変換フィルタです。 #!/bin/sh # # hpvf - Convert GIF files into HP/PCL, then print # Installed in /usr/local/libexec/hpvf PATH=/usr/X11R6/bin:$PATH; export PATH giftopnm | ppmtopgm | pgmtopbm | pbmtolj -resolution 300 \ && exit 0 \ || exit 2 ここでは、GIF ファイルから PNM (portable anymap) 形式に変換し、次に PGM (portable graymap) 形式に変換してから、 LaserJet/PCL-互換データに変換しています。 上記のフィルタを使うプリンタのためのエントリを付け加えた /etc/printcap ファイルは次のようになります。 # # /etc/printcap for host orchid # teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\ :lp=/dev/lpt0:sh:sd=/var/spool/lpd/teak:mx#0:\ :if=/usr/local/libexec/hpif:\ :vf=/usr/local/libexec/hpvf: 次のスクリプトは、PostScript プリンタ bamboo のための groff 組版システムの troff データのための変換フィルタです。 #!/bin/sh # # pstf - Convert groff's troff data into PS, then print. # Installed in /usr/local/libexec/pstf # exec grops | /usr/local/libexec/lprps "$@" 上記のスクリプトではプリンタとの通信をおこなうため、 lprps をまた利用しています。 プリンタがパラレルポートに接続されている場合は、代わりに、 次のスクリプトを使うかもしれません。 #!/bin/sh # # pstf - Convert groff's troff data into PS, then print. # Installed in /usr/local/libexec/pstf # exec grops これで完成しました。次に、フィルタを使用可能にするため に /etc/printcap に加える必要があるエントリを示します。 :tf=/usr/local/libexec/pstf: 次の例をみたら、FORTRAN のベテランは赤面するかもしれません。 この FORTRAN テキストフィルタは、 プレインテキストを直接印字できるすべてのプリンタで利用できます。 このフィルタをプリンタ teak にインストールすることにしましょう。 #!/bin/sh # # hprf - FORTRAN text filter for LaserJet 3si: # Installed in /usr/local/libexec/hprf # printf "\033&k2G" && fpr && printf "\033&l0H" && exit 0 exit 2 そして、このフィルタを使用可能にするため、以下の行を /etc/printcap のプリンタ teak のエントリに加えます。 :rf=/usr/local/libexec/hprf: これが最後の、そして、若干複雑な例です。前に紹介した LaserJet プリンタ teak に、DVI フィルタを加える ことにしましょう。最初に、 簡単な部分をおこないます。すなわち、DVI フィルタの位置を /etc/printcap に書き加えます。 :df=/usr/local/libexec/hpdf: さて、難しい部分であるフィルタの作成をおこないます。 このために、DVI から LaserJet/PCL への変換プログラムが必要です。FreeBSD の Ports Collection (Ports Collection を参照してください) には、それがあります。 dvi2xx というのがそのパッケージの名前です。 これをインストールすると、必要なプログラム dvilj2p が使えます。このプログラムは DVI を LaserJet IIp、LaserJet III、そして LaserJet 2000 の互換コードへ変換してくれます。 dvilj2p はフィルタ hpdf を極めて複雑にしています。 なぜなら、dvilj2p は標準入力からデータを読み込むことができないからです。 このプログラムを働かせるためには、ファイル名が必要です。 もっと悪いことに、ファイル名は .dvi で終わっている必要があり、標準入力の代わりに、 /dev/fd/0 を使うのは問題があります。 この問題は、(.dvi で終わる) 一時的なファイル名から/dev/fd/0 に (シンボリックな) リンクを張る ことで回避することができます。これで、 dvilj2p に強制的に標準入力からデータを読み込ませることができます。 もう1つの問題は、一時的なリンクを張るために /tmp ディレクトリを使うことができないという事実です。 シンボリックリンクはユーザ、グループが bin であるユーザに所有されています。フィルタはユーザ daemon として起動します。そして、 /tmp ディレクトリはスティッキービットが立っています。 フィルタはリンクを作ることができます。しかし、 リンクは別のユーザに所有されているため、 作業が終了したとき、このリンクを削除することができません。 その代わりに、シンボリックリンクは現在の作業ディレクトリ、 すなわち、スプーリングディレクトリ (/etc/printcap の sd 項目で指定する) に作ることにします。 フィルタが作業するにはここの場所は完璧な場所で、なぜなら、 特に、スプーリングディレクトリのディ スクの空き容量は (ときどき) /tmp ディレクトリよりもたくさんあるからです。 以下に示すのが最後のフィルタです。 #!/bin/sh # # hpdf - Print DVI data on HP/PCL printer # Installed in /usr/local/libexec/hpdf PATH=/usr/local/bin:$PATH; export PATH # # Define a function to clean up our temporary files. These exist # in the current directory, which will be the spooling directory # for the printer. # cleanup() { rm -f hpdf$$.dvi } # # Define a function to handle fatal errors: print the given message # and exit 2. Exiting with 2 tells LPD to do not try to reprint the # job. # fatal() { echo "$@" 1>&2 cleanup exit 2 } # # If user removes the job, LPD will send SIGINT, so trap SIGINT # (and a few other signals) to clean up after ourselves. # trap cleanup 1 2 15 # # Make sure we are not colliding with any existing files. # cleanup # # Link the DVI input file to standard input (the file to print). # ln -s /dev/fd/0 hpdf$$.dvi || fatal "Cannot symlink /dev/fd/0" # # Make LF = CR+LF # printf "\033&k2G" || fatal "Cannot initialize printer" # # Convert and print. Return value from dvilj2p does not seem to be # reliable, so we ignore it. # dvilj2p -M1 -q -e- dfhp$$.dvi # # Clean up and exit # cleanup exit 0 自動変換: その他の変換フィルタ ここまでに述べてきたフィルタによって、 印字環境の能率が上がったことと思います。しかし、 これはどのフィルタを使うかを (&man.lpr.1; のコマンドライン上で) ユーザが指定しなくてはならないという代価を支払って実現されています。 コンピュータの事情にあまり詳しくないユーザにとって、 フィルタのオプションを指定させられるということは いらいらさせられるものになるでしょう。更に悪いことに、 間違ったフィルタオプションを指定されると、 間違った形式のファイルがそのフィルタに適用されることになり、 その結果、何百枚もの紙を吐き出すことになるかもしれません。 そのような結果になるならば、 変換フィルタをインストールするよりもむしろ、 テキストフィルタ (これがデフォルトフィルタなので) に印字するよう要求されたファイルの形式を検出させ、自動的に、 適切な変換フィルタを起動するようにしたいと思うかもしれません。 ここでは file コマンドのようなツールを役立たせることができます。 もちろん、いくつかの ファイル形式の違いを見分けることは難しいことでしょう。 そして、もちろん、それらのファイルに対しては、 変換フィルタを提供するだけで済ますこともできるのです。 apsfilter プリンタ フィルタ apsfilter FreeBSD Ports Collection には、apsfilter と呼ばれる自動変換をおこなうテキストフィルタがあります。 このフィルタは プレインテキスト、PostScript、DVI ファイルを検出し、適当な変換をおこなった後、 データを印字することができます。 出力フィルタ LPD スプーリングシステムでは、 ここまでにまだ取り上げていないフィルタ形式、 出力フィルタをサポートしています。出力フィルタは、 テキストフィルタのように、 プレインテキストのみを印字するために意図されたものですが、 非常に簡単化されています。テキストフィルタを用いずに、 出力フィルタを使っている場合は、次のようになります。 LPD はジョブ中の各ファイルに一度ではなく、 ジョブ全体に対して一度だけ出力フィルタを起動します。 LPD は出力フィルタに対し、 ジョブ中のファイルの先頭や末尾を特定するための対策を 一切おこなっていません。 LPD はユーザのログイン名やホスト名をフィルタに渡しません。 したがって、課金の処理をおこなうことは考えていません。 実際、出力フィルタには、以下2つの引数しか与えられません。 filter-name -wwidth -llength ここで、width は対象となるプリンタの pw 項目、 length は pl 項目に指定された数です。 出力フィルタの簡便さに誘惑されてはいけません。もし、 ジョブ中のそれぞれのファイルに別のページ番号を付加しようとしても、 出力フィルタはうまく動作しないでしょう。 そのような動作を期待しているならば、 (入力フィルタとしても知られている) テキストフィルタを使ってください。 詳しくは、「 テキストフィルタのインストール」をご覧ください。 さらに、出力フィルタは、実のところ、 もっと複雑になっています。まず、 特殊なフラグ文字を検出するために、 フィルタに送られてくるバイトストリームを検査する必要があります。 また、LPD に代わって、 自分自身にシグナルを送らなければなりません。 しかしながら、ヘッダページの印字をおこないたい場合、 また、 エスケープシーケンスやヘッダページを印字できるようにする その他の初期化文字列を送信する必要がある場合、 出力ファイルが必要です。 1台のプリンタに対し、LPD では出力フィルタとテキスト、 または、他のフィルタを両方使うことができます。 このような場合、LPD はヘッダページ (「 ヘッダページ」 を参照してください) だけを印字させるために、出力フィルタを起動させます。 それから LPD では、アウトプットフィルタに 2 バイトの文字 (ASCII 031 の次に ASCII 001) を送ることで、 出力フィルタが自力で停止することを期待しています。 2 バイト (031, 001) が出力フィルタに送られたとき、 出力フィルタは自分自身にシグナル SIGSTOP を送ることによって停止するべきです。 LPD がその他のフィルタの起動を完了したとき、 LPD は出力フィルタにシグナル SIGCONT を送ることで、出力フィルタを再起動させます。 出力フィルタがあり、 テキストフィルタがない場合、LPD はプレインテキストのジョブをおこなう際に、 出力フィルタを使います。前述したように、出力フィルタでは、 ジョブ中の各ファイルの並びの間に FROM FEED 文字や紙を排出する他の文字を入れることはしません。 この動作は多分、 あなたが求めているものとは異なっているでしょう。 ほとんどすべての場合において、 テキストフィルタが必要とされるはずです。 プログラム lpf は、 テキストフィルタの項で既に紹介しましたが、 出力フィルタとしても動作させることができます。もし、 簡便で極悪な出力フィルタが必要で、かつ、 バイトストリームを検査したりシグナルを送るコードを書きたくないときには、 lpf をお試しください。 あるいは、プリントが要求する初期化コードを送るために、 lpf をシェルスクリプトに包んで使うこともできます。 テキストフィルタ <command>lpf</command> プログラム /usr/libexec/lpr/lpf は、 FreeBSD の バイナリ配布に付属しているテキストフィルタ (入力フィルタ) で、出力を字下げしたり (lpr -i でジョブが入力さ れたとき)、 文字を未処理のままプリンタに送ったり (lpr -l でジョブが入力されたとき)、 ジョブ中のバックスペースやタブの印字位置を調節したり、 印字したページに対して課金したりすることができます。また、 このフィルタは出力フィルタとしても動作させることができます。 lpf は多くの印字環境において使用することに適しています。 このフィルタには、プリンタに初期化文字列を送る機能はありませんが、 必要とされる初期化をおこない、それから lpf を実行させるためのシェルスクリプトを作成するのはたやすいことです。 ページ課金 課金 プリンタ lpf に対して、 印字ページへの課金を正確におこなわせるためには、 /etc/printcap ファイルの中の pw と pl の項目に正確な値を入れておく必要があります。これらの値は、 どのくらいの量のテキストがページにフィットするか、また、 ユーザのジョブが何ページあるのかを調べるために使われます。 プリンタの課金についての詳しい情報については、「 プリンタの利用に対する課金」をご覧ください。 ヘッダページ あなたが管理するシステムのユーザが たくさんおり、 ユーザ全員が様々なプリンタを使用する場合、多分、 必要悪であるヘッダページを 印字させることを検討したいと思うかもしれません。 バナーページ ヘッダページ ヘッダページ ヘッダページは、バナー とか バーストページ としても知られていますが、 出力されたジョブが誰によるものなのかを特定させる働きがあります。 印字結果の山の中において、 ユーザのジョブによって印字された本物のドキュメント部分よりも際立たせるために、 ヘッダページは、通常、多分、縁が装飾されている大きな太文字で印字されます。 ヘッダページにより、 ユーザは自分が出したジョブがどこにあるのかをすばやく見つけることができます。 ヘッダページの欠点は、明らかに、すべてのジョブに対して、 紙が 1 枚余分に印字されるということです。 この紙の有効期間は短く、2 〜 3 分も続きません。最終的に、 これらの紙は再利用紙入れの中かくずの山に入れられることでしょう (ヘッダページはジョブ中の各ファイル毎に印字されるのではなく、 ジョブ毎に印字されるということに注意してください。したがって、 紙の消費はそれほどひどくはないかもしれません)。 もし、 プリンタがプレインテキストを直接印字できるならば、LPD システムは印字物に対して自動的にヘッダページを付けることができます。 PostScript プリンタを使っている場合は、 ヘッダページを生成する外部プログラムが必要になります。これについては、 「PostScript プリンタでのヘッダページ」をご覧ください。 ヘッダページの印字を許可する 「プリンタ設定導入編 」 では、/etc/printcap ファイルの sh (``suppress header'' : ヘッダを供給しない という意味) を指定して、 ヘッダページの印字を止めていました。 プリンタでのヘッダページの印字を許可するには、 sh 項目を取り除くだけよい訳です。 とても簡単そうに見えるけど、本当かな? それは本当です。 プリンタに初期化文字列を送るための 出力フィルタを用意しなくてはならないかもしれません。次に、Hewlett Packard PCL 互換プリンタの例を挙げます。 #!/bin/sh # # hpof - Output filter for Hewlett Packard PCL-compatible printers # Installed in /usr/local/libexec/hpof printf "\033&k2G" || exit 2 exec /usr/libexec/lpr/lpf of 項目に出力フィルタのパス名を指定してください。 詳細については、「出力フィルタ」 をご覧ください。 次に、以前紹介したプリンタ teak のための /etc/printcap ファイルの例を示します。ここでは、 ヘッダページの印字を許可し、上記の出力フィルタを追加しました。 # # /etc/printcap for host orchid # teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\ :lp=/dev/lpt0:sd=/var/spool/lpd/teak:mx#0:\ :if=/usr/local/libexec/hpif:\ :vf=/usr/local/libexec/hpvf:\ :of=/usr/local/libexec/hpof: さて、ユーザが teak からジョブを印字させたとき、 それぞれのジョブ毎にヘッダページが印字されます。 もし、ユーザが印字物を探すのに時間を費やしたいと思うなら、 lpr -h によってジョブを入力することで、 ヘッダページの印字を止めることができます。 これ以外の &man.lpr.1; のオプションについては、 「 ヘッダページ用オプション」 をご覧ください。 LPD では、ヘッダページの最後に、FORM FEED 文字が印 字されます。プリンタに紙排出をさせるために、別な文字、 もしくは、別な文字列が利用されている場合は、 /etc/printcap 中の ff 項目で指定することができます。 ヘッダページを制御する ヘッダページの印字が許可されていると、LPD は 長いヘッ ダを作ります。これには、 紙全面に大きな文字でユーザ名、ホスト名、 ジョブ名が書かれています。次に、このヘッダページの例を示 します (kelly が ジョブ名 outline を rose というホストから印字 された場合)。 k ll ll k l l k l l k k eeee l l y y k k e e l l y y k k eeeeee l l y y kk k e l l y y k k e e l l y yy k k eeee lll lll yyy y y y y yyyy ll t l i t l oooo u u ttttt l ii n nnn eeee o o u u t l i nn n e e o o u u t l i n n eeeeee o o u u t l i n n e o o u uu t t l i n n e e oooo uuu u tt lll iii n n eeee r rrr oooo ssss eeee rr r o o s s e e r o o ss eeeeee r o o ss e r o o s s e e r oooo ssss eeee Job: outline Date: Sun Sep 17 11:04:58 1995 LPD はこのテキストの終わりに FROM FEED 文字を加えます ので、ジョブは新しいページから開始されます (ただし、 /etc/printcap で出力先のプリンタのエントリに sf (suppress form feeds) が指定されているときはこ の限りではありません)。 お望みならば、LPD に短いヘッダページを出力させることもできます。 この場合は、 /etc/printcap ファイルの中で sb (short banner) を指定してください。 ヘッダページは次のようになります。 rose:kelly Job: outline Date: Sun Sep 17 11:07:51 1995 デフォルトでは、LPD はヘッダページを最初に印字し、 次にジョブの印字をおこないます。この順番を逆にするときは、 /etc/printcap で hl (header last) を指定してください。 ヘッダページに対する課金 LPD に備わっているヘッダページ出力機能を使うと、 入力されたジョブに対して課金をおこなうことができても、 ヘッダページは無料で提供しなくてはならない、 という特有のやり方を強要されます。 なぜでしょうか。 出力フィルタは単なる外部プログラムなので、 課金をするための制御をおこなうとすれば、 それはヘッダページを印字するときですが、出力フィルタには、 ユーザ名とホスト名 の情報や課金情報を格納するファイルがどれな のかということが知らされません。それゆえ、出力ファイルには、 誰にプリンタ利用の課金をおこなえばよいのかが分からないのです。 テキストフィルタやその他の変換フィルタ (これらのフィルタはユーザやホストの情報が知らされます) が出力ページの枚数に 1ページ分水増しする だけでは十分ではありません。 なぜなら、ユーザは lpr -h に よってヘッダページの出力を止めることができるからです。 やみくもに 1 ページを水増しすると、 印字されてもいないヘッダページに対する 料金をとることになります。基本的に、lpr -h は環境に優しい心を持つユーザに好まれるオプションですが、 これを使うように奨励することもできません。 各々のフィルタに独自のヘッダページを生成させる (その結果、ヘッダページに課金することができる) という方法でも十分であるとはいえません。 この場合、LPD はフィルタに の情報を送りませんので、lpr -h によってヘッダページを印字しないオプションを選択したとしても、 依然としてヘッダページは印字され、 その分の課金がおこなわれてしまいます。 では、どのような選択肢があるのでしょうか。 ヘッダページへの課金に関しては、 次のことができます。 LPD のやり方を受け入れ、 ヘッダページは無料とする。 LPRng などの LPD の代替品をインストールする。 LPD と入れ替えが可能な他のスプーリングソフトウェアに関しては、 標準スプーラの代替品をご覧ください。 スマートな 出力フィルタを作成する。通常、 出力フィルタはプリンタを初期化するか、 単純な文字列変換をする程度の働きしかしません。 (テキスト (入力) フィルタがない場合) 出力フィルタはヘッダページとプレインテキストの印字をおこなうのに適しています。 プレインテキストを印字するためのテキストフィルタがない場合、 LPD はヘッダページを印字するためだけの目的で出力フィルタを起動します。 そして、LPD が生成するヘッダページのテキストを解析することにより、 出力フィルタはヘッダページに課金するために必要なユーザ名と ホスト名を取得することができます。この方式の唯一の問題点は、 出力フィルタは課金情報を格納するデータファイルの名前を知ることが できないということです (af 項目で指定されたファイル名は 出力ファイルに渡されません)。しかし、既知の 名前の課金データファイルを使うのならば、 その名前を出力フィルタのプログラム中に埋め込むことができます。 解析の手順を簡単にするためには、 /etc/printcap で sh 項目 (短いヘッダを指定) を使うとよいでしょう。 そしてまた、 ここまでの方法は少なからぬトラブルを生じさせるかもしれません。 そうなれば、もちろんユーザはヘッダページを無料で 提供してくれる気前のよいシステム管理者に感謝することでしょう。 PostScript プリンタでのヘッダページ これまでに述べたように、LPD ではプレインテキストのヘッダページを たくさんのプリンタに合うように生成することができます。 残念ながら、PostScript プリンタは、 プレインテキストを直接印字することができません。ですから、 LPD のヘッダページ機能はまったく役に立たない、 あるいはほとんどの場合で役に立ちません。 ヘッダページを出力するための自明な方法の1つに、 すべての変換フィルタとテキストフィルタにヘッダページを生成させる方法があります。 フィルタは、 適切なヘッダページを生成するために、 ユーザ名とホスト名の引数を使うべきです。この方法の欠点は、いつでも、 lpr -h によってジョブが入力された場合でさえも、 ヘッダページが印字されるということです。 この方法で試してみましょう。次のスクリプトは、3 つの引数 (ユーザ のログイン名、ホスト名、ジョブ名) をとり、簡単な PostScript 用 のヘッダページを生成します。 #!/bin/sh # # make-ps-header - make a PostScript header page on stdout # Installed in /usr/local/libexec/make-ps-header # # # These are PostScript units (72 to the inch). Modify for A4 or # whatever size paper you are using: # page_width=612 page_height=792 border=72 # # Check arguments # if [ $# -ne 3 ]; then echo "Usage: `basename $0` <user> <host> <job>" 1>&2 exit 1 fi # # Save these, mostly for readability in the PostScript, below. # user=$1 host=$2 job=$3 date=`date` # # Send the PostScript code to stdout. # exec cat <<EOF %!PS % % Make sure we do not interfere with user's job that will follow % save % % Make a thick, unpleasant border around the edge of the paper. % $border $border moveto $page_width $border 2 mul sub 0 rlineto 0 $page_height $border 2 mul sub rlineto currentscreen 3 -1 roll pop 100 3 1 roll setscreen $border 2 mul $page_width sub 0 rlineto closepath 0.8 setgray 10 setlinewidth stroke 0 setgray % % Display user's login name, nice and large and prominent % /Helvetica-Bold findfont 64 scalefont setfont $page_width ($user) stringwidth pop sub 2 div $page_height 200 sub moveto ($user) show % % Now show the boring particulars % /Helvetica findfont 14 scalefont setfont /y 200 def [ (Job:) (Host:) (Date:) ] { 200 y moveto show /y y 18 sub def } forall /Helvetica-Bold findfont 14 scalefont setfont /y 200 def [ ($job) ($host) ($date) ] { 270 y moveto show /y y 18 sub def } forall % % That is it % restore showpage EOF そして、変換フィルタやテキストフィルタがそれぞれ、 最初にこのスクリプトを起動することで、 ヘッダページが出力され、それから、 ユーザのジョブの印字をおこないます。次に、 このドキュメントの始めのほうで紹介した DVI 変換フィルタを、 ヘッダページを印字するように変更したものを示します。 #!/bin/sh # # psdf - DVI to PostScript printer filter # Installed in /usr/local/libexec/psdf # # Invoked by lpd when user runs lpr -d # orig_args="$@" fail() { echo "$@" 1>&2 exit 2 } while getopts "x:y:n:h:" option; do case $option in x|y) ;; # Ignore n) login=$OPTARG ;; h) host=$OPTARG ;; *) echo "LPD started `basename $0` wrong." 1>&2 exit 2 ;; esac done [ "$login" ] || fail "No login name" [ "$host" ] || fail "No host name" ( /usr/local/libexec/make-ps-header $login $host "DVI File" /usr/local/bin/dvips -f ) | eval /usr/local/libexec/lprps $orig_args このフィルタがユーザ名やホスト名を決定するために 引数リストをどのように解析しなくてはならないかという点に注意してください。 この解析方法は他の変換フィルタに対しても同様です。 しかしながら、テキストフィルタについては、 引数の設定が少し異なっています (これについては、「 フィルタはどのように機能しているか」 をご覧ください)。 前述の通り、上記の手法は、極めて単純なのにも関らず、 lpr で ヘッダページを印字しない オプション ( オプション) が使えなくなっています。 ユーザが森林資源を (あるいは、 ヘッダページが課金されているならば、その僅かな金額を)、 節約したいと望んでいる場合でも、 すべてのフィルタがすべてのジョブ毎にヘッダページを印字 することになっているので、節約することはできません。 ジョブ毎に印字されるヘッダページを ユーザが抑制できるようにするためには、「 ヘッダページに対する課金」で紹介したトリックを 使う必要があります。すなわち、LPD が生成するヘッダページの解析をおこない、PostScript 版のヘッダページを出力させる出力フィルタを作るのです。 この場合、ユーザが lpr -h でジョブを入力すると、 LPD はヘッダページを生成しなくなり、また、 出力フィルタも起動されません。そうでないならば、 作成した出力フィルタが LPD からのテキストを読み込み、 ヘッダページを印字する適当な PostScript のコードがプリンタに送られるでしょう。 PostScript プリンタがシリアルポートに接続されている場合、 出力フィルタとして lprps を、 上記の動作をおこなうものとして psof を使うことができます。ただし、psof はヘッダページに対して課金をおこないませんので注意してください。 リモートプリンタからの出力 プリンタ ネットワーク ネットワークプリンタ FreeBSD では、ネットワーク越しの印字、すなわち、 ジョブをリモートプリンタに送ることをサポートしています。 リモートプリンタからの出力をするには、一般に、 次の 2 つを参照してください。 リモートホストに接続されたプリンタにアクセスする方法。 プリンタがあるホストのシリアル、 または、パラレルインタフェースに接続されている場合、 ネットワーク上の他のホストからこのプリンタにアクセスできるように LPD を設定します。「リモートホストに 接続されたプリンタ」 でどのようにするかを説明します。 ネットワークに直接接続されているプリンタにアクセスする方法。 プリンタに、旧来のシリアル、または、 パラレルインタフェースに加えて (もしくは、これらに代わって) ネットワーク用のインタフェースがある場合。 そのようなプリンタは次のように動作するでしょう。 そのプリンタが LPD のプロトコルを理解でき、 リモートホストからのジョブを キューに入れることさえできる場合。この場合、 プリンタは、LPD が起動している一般のホストのように振る舞います。 そのようなプリンタを設定するために、 「 リモートホストに接続されたプリンタ」 と同様の手順をおこなってください。 そのプリンタが、 データストリームによるネットワーク接続をサポートしている場合。 この場合、ネットワーク上の1つのホストとしてプリンタを 接続 します。 このホストは、ジョブをスプーリングする責任を負い、 スプーリングされたジョブはプリンタに送られます。 そのようなプリンタをインストールするためのいくつかの提案が 「 ネットワークにおけるデータストリームの インタフェースを持つプリンタ」にあります。 リモートホストに接続されたプリンタ LPD スプーリングシステムでは LPD (または LPD 互換のシステム) が起動している他のホストへジョブを送る機能が 始めからサポートされています。この機能により、 あるホストに接続されたプリンタへ、 他のホストからアクセスできるようになります。また、 LPD プロトコルを理解するネットワークインタフェースを持ったプリンタに対しても、 この機能は働きます。 リモートプリンタへの出力を許可するためには、最初に、 あるホスト (これを、 プリンタホストと呼びます) にプリンタを接続します。そして、「 プリンタ設定導入編」 に書かれた簡単なプリンタの設定をおこなってください。 必要ならば、「プリンタ設定上級編」 にある、更に進んだ設定をおこなってください。そして、 そのプリンタをテストしてうまく動作することを確認し、LPD に許可した機能がうまく働くかどうかを見てください。さらに ローカルホストが プリンタホストの LPD サービスの使用を 許可されているか確認して下さい (「 リモートホストからのプリンタの利用を制限する 」参照)。 プリンタ ネットワーク ネットワークプリンタ LPD 互換のネットワークインタフェースを持つプリンタを使用している場合は、 そのプリンタ自身が以下で説明する プリンタホストになります。そして、 プリンタ名とは、 そのプリンタに設定した名前のことを指します。 これについては、プリンタ、および (または)、 プリンタのネットワークインタフェースに付属するドキュメントを参照してください。 ヒューレット・パッカード社の Laserjet シリーズを使用している場合には、 プリンタ名を text とすると、 自動的に LF から CRLF への変換が行なわれます。 そのため、hpif スクリプトは必要ありません。 次に、 そのプリンタにアクセスしたいと思っている他ホストにおいて、 そのホストの /etc/printcap ファイルに次にあげるエントリを作ります。 名前のエントリ。どんな名前でもよいのですが、簡単のため、多分、 プリンタホストで設定されたプリンタ名や別名と同じものを使いたいと思うでしょう。 lp 項目で指定されるデバイスは明示的に空にする (:lp=: とする)。 スプーリングディレクトリを作成し、 sd 項目でその位置を指定する。LPD では、プリンタホストにジョブを送信するまでの間、 このディレクトリにジョブを格納します。 rm 項目でプリンタホストの名前を指定します。 rp 項目で プリンタホストに接続したプリンタ名を指定します。 これで終わりです。 変換フィルタやページの大きさやその他の事項を /etc/printcap に加える必要はありません。 次に、 リモートホストに接続されたプリンタで印字するための設定例 を示します。ホスト rose には2台のプリンタ bamboo と rattan が接続されています。これらのプリンタをホスト orchid のユーザが使えるようにしましょう。最初に orchid の /etc/printcap を示します (このファイルは、「 ヘッダページの出力を許可する」 で参照することができます)。このファイルには、既に、プリンタ teak 用のエントリがありました。以下では、 これに、 ホスト rose にある2台のプリンタ用のエントリが加えられています。 # # /etc/printcap for host orchid - added (remote) printers on rose # # # teak is local; it is connected directly to orchid: # teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\ :lp=/dev/lpt0:sd=/var/spool/lpd/teak:mx#0:\ :if=/usr/local/libexec/ifhp:\ :vf=/usr/local/libexec/vfhp:\ :of=/usr/local/libexec/ofhp: # # rattan is connected to rose; send jobs for rattan to rose: # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :lp=:rm=rose:rp=rattan:sd=/var/spool/lpd/rattan: # # bamboo is connected to rose as well: # bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :lp=:rm=rose:rp=bamboo:sd=/var/spool/lpd/bamboo: orchid で必要となる作業はスプーリングディレクトリを作ることだけです。 &prompt.root; mkdir -p /var/spool/lpd/rattan /var/spool/lpd/bamboo &prompt.root; chmod 770 /var/spool/lpd/rattan /var/spool/lpd/bamboo &prompt.root; chown daemon:daemon /var/spool/lpd/rattan /var/spool/lpd/bamboo これで、orchid のユーザが rattan と bamboo で印字す ることができるようになりました。 例えば、orchid のユーザが次のように入力したとします。 &prompt.user; lpr -P bamboo -d sushi-review.dvi すると、orchid の LPD システムは、 ジョブをスプーリングディレクトリ /var/spool/lpd/bamboo にコピーし、これが DVI ファイルを印字するジョブであることを記録します。 ホスト rose の bamboo 用のスプーリングディレクトリに十分な容量が確保でき次第、 両者の LPD は、ジョブのファイルを rose に転送します。 このファイルは、そのすべてが印字されるまで、rose のキューに留まります。 (bamboo は PostScript プリンタなので) DVI から PostScript への変換は rose でおこなわれます。 ネットワークにおけるデータストリームの インタフェースを持つプリンタ プリンタのネットワークインタフェースカードは、 2 種類に分類することができます。 1 つはスプーラをエミュレートするもの (高価) で、もう 1 つはシリアルやパラレルポートを使うように プリンタにデータを送ることができるだけのもの (安価) です。この節では、 後者の使い方を説明します。前者のプリンタは、前節「 リモートホストに接続されたプリンタ」 の方法が適用できます。 /etc/printcap ファイルでは、 シリアルかパラレルのインタフェースのどちらを使うのか、 そして、(シリアルインタフェースを使う場合) そのボーレートはいくらであるか、フロー制御は使うのか、 タブのための遅延を加えるのか、 改行文字を変換するかなどの指定をおこなうことができます。 しかし、TCP/IP や他のネットワークポートからデータを受け取るプリンタを 接続するための指定をおこなうことはでき ません。 ネットワーク接続されたプリンタにデータを送るためには、 テキストフィルタと変換フィルタから呼び出すことができる 通信プログラムを開発する必要があります。以下に、 そのようなプログラムの例を示します。スクリプト netprint では、 標準入力から印字データをすべて受け取り、 ネットワーク接続されたプリンタにこれを送ります。 netprint の最初の引数でプリンタのホスト名を、 2 番目の引数で接続するポート番号を指定します。 このプログラムでは単方向通信 (FreeBSD からプリンタ) のみをサポートしていることに注意してください。 ネットワークプリンタの多くは双方向通信をサポートしていますので、 その恩恵 (プリンタの状態を得たり、 課金をおこなうなど) にあずかりたいと思われるかもしれません。 #!/usr/bin/perl # # netprint - Text filter for printer attached to network # Installed in /usr/local/libexec/netprint # $#ARGV eq 1 || die "Usage: $0 <printer-hostname> <port-number>"; $printer_host = $ARGV[0]; $printer_port = $ARGV[1]; require 'sys/socket.ph'; ($ignore, $ignore, $protocol) = getprotobyname('tcp'); ($ignore, $ignore, $ignore, $ignore, $address) = gethostbyname($printer_host); $sockaddr = pack('S n a4 x8', &AF_INET, $printer_port, $address); socket(PRINTER, &PF_INET, &SOCK_STREAM, $protocol) || die "Can't create TCP/IP stream socket: $!"; connect(PRINTER, $sockaddr) || die "Can't contact $printer_host: $!"; while (<STDIN>) { print PRINTER; } exit 0; このスクリプトは、 様々なフィルタが利用することができます。仮に、Diablo 750-N ラインプリンタを持っており、 これがネットワークに接続されているとしましょう。 プリンタはポート番号 5100 にて印字するデータを受け取ります。 プリンタのホスト名は scrivener とします。このとき、 このプリンタのテキストフィルタは次のようになります。 #!/bin/sh # # diablo-if-net - Text filter for Diablo printer `scrivener' listening # on port 5100. Installed in /usr/local/libexec/diablo-if-net # exec /usr/libexec/lpr/lpf "$@" | /usr/local/libexec/netprint scrivener 5100 プリンタの利用に制約を与える プリンタ 利用制限 本節では、プリンタの利用に制約を与えるための情報を記しています。 LPD システムでは、プリンタ (ローカル、 リモートのいずれに接続されていても) にアクセスできる人を制限する機能、 複数部のコピーの印字の可否を制御する機能、 ジョブのサイズの最大値やプリンタキューに入る ジョブの最大個数を制御する機能を提供しています。 複数部のコピーの印字を制限する LPD システムではユーザが複数部のコピーの印字を簡単におこなう 機能を提供しています。ユーザが、(例えば) lpr -#5 コマンドを使ってジョブを印字すると、 ジョブのそれぞれのファイルのコピーを 5 部得ることができます。 これがよい機能であると思うかどうかは人それぞれでしょう。 複数部のコピーの印字によってプリンタが 必要以上に消耗してしまうと感じるならば、 /etc/printcap ファイルに sc 項目を加えてください。これにより、 &man.lpr.1; の オプションの使用が禁止されます。 このオプションが指定されているにも関らず、 オプションを使うと、 次のようなメッセージが表示され、 このオプションの利用できない旨を伝えます。 lpr: multiple copies are not allowed リモートホストからプリンタをアクセスできる 設定にしている場合 (この 設定については、「 リモートホストに接続されたプリンタ」 をご覧ください)、そのリモートホストの /etc/printcap にも同じように sc 項目を追加する必要があることに注意してください。 そうしないと、ユーザは別なホストから複数部のコピーの 印字することができてしまいます。 例を使って説明しましょう。次に示す /etc/printcap ファイルは、ホスト rose のものです。プリンタ rattan は極めて頑丈なので、 複数部のコピーの印字は許可されています。しかし、 レーザプリンタの bamboo はもう少しデリケートで、 このプリンタから複数部のコピーを印字することを sc 項目を追加することで禁止しています。 # # /etc/printcap for host rose - restrict multiple copies on bamboo # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:sc:\ :lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf: さらに、orchid の /etc/printcap にも sc 項目を追加する必要があります (orchid でこの編集をおこなっているときに、ついでに、プリンタ teak でも複数部のコピーの印字を禁止することにしましょう)。 # # /etc/printcap for host orchid - no multiple copies for local # printer teak or remote printer bamboo teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\ :lp=/dev/lpt0:sd=/var/spool/lpd/teak:mx#0:sc:\ :if=/usr/local/libexec/ifhp:\ :vf=/usr/local/libexec/vfhp:\ :of=/usr/local/libexec/ofhp: rattan|line|diablo|lp|Diablo 630 Line Printer:\ :lp=:rm=rose:rp=rattan:sd=/var/spool/lpd/rattan: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :lp=:rm=rose:rp=bamboo:sd=/var/spool/lpd/bamboo:sc: sc 項目を指定することにより、 lpr -# の使用を防ぐことができます。しかし、この状態では &man.lpr.1; を複数回起動したり、 1 回のジョブで次のように同じファイルを複数個指定することを防ぐまでには至っていません。 &prompt.user; lpr forsale.sign forsale.sign forsale.sign forsale.sign forsale.sign このような悪用を防ぐ方法は (その指示を無視することも含めて) たくさんあります。 各自で調べてみてください。 プリンタを使用できる人を限定する それぞれのプリンタを使用できる人を限定するには、Unix の グループ権限のメカニズムを利用し、さらに、 /etc/printcap で rg 項目を指定することでおこないます。 あるプリンタにアクセスさせてもよいと思うユーザすべてを Unix のあるグループに入れてください。そして、 そのグループ名を rg で指定します。 このとき、そのグループに含まれないユーザ (root も含む) には、次のようなメッセージが表示され、 プリンタの使用はできません。 lpr: Not a member of the restricted group sc (suppress multiple copies : 複数部のコピーの印字を禁止する) を指定するときと同様に、rg が指定されたプリンタがリモートホストからもアクセスでき (この設定については、 「 リモートホストに接続されたプリンタ」 をご覧ください)、かつ、 そのホストでもプリンタを使用できる人を限定するのが 妥当であると思う場合は、 そのホストの /etc/printcap にも rg 指定をおこなう必要があります。 例えば、プリンタ rattan は誰でも利用できるが、bamboo はグループ artists に属している人のみが利用できるようにしてみましょう。 以下に、もうお馴染みとなったホスト rose の /etc/printcap を示します。 # # /etc/printcap for host rose - restricted group for bamboo # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:sc:rg=artists:\ :lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf: これ以外の /etc/printcap ファイル (ホスト orchid のもの) はそのままにしておくことにします。もちろん、 orchid のユーザは全員 bamboo を利用することができます。これは、 orchid には特定のユーザのみにしかアクセスさせておらず、 そのユーザにはプリンタを利用させたいと思っているからなのかもしれませんし、 そうでないかもしれません。 1台のプリンタを複数グループのユーザに利用させることはできません。 入力可能なジョブのサイズを制限する プリントジョブ たくさんのユーザからプリンタが利用される場合には、多分、 ユーザが印字要求を出すことができるファイルのサイズに 上限値を置く必要が生じるでしょう。結局のところ、 スプーリングディレクトリ が置かれているファイルシステムの空き容量がその 上限値になる訳ですが、 あるユーザがこれを独占的に使用すること避けるために、 他ユーザからのジョブ用の空き容量を確保する必要もあります。 プリントジョブ 制御 LPD では、mx 項目を指定することにより、 ジョブ中の個々のファイルのサイズの上限値を制限する機能を提供しています。 指定される ファイルサイズの単位は BUFSIZ ブロックで、1 BUFSIZ ブロックは 1024バイトを表わします。この mx 項目の値として 0 が指定されると、 ファイルサイズの制限はなくなります。 mx が指定されない場合は、 デフォルトの制限として 1000 ブロックが使われます。 この制限はジョブ中の各 ファイルに対して適用されるものであり、 ジョブ全体のサイズ を制限するものではありません。 ところで、 プリンタに設定された上限値を超えるファイルサイズの ファイルが入力された場合でも、LPD はこれを拒否しません。 その代わりに、このファイルは、 その先頭から上限値のファイルサイズまでしかキューに入れられません。 そして、その部分までが印字され、 残りの部分は捨てられます。 これが正しい動作といえるのかどうかは議論の余地があるところです。 それでは、設定例に登場しているプリンタ rattan と bamboo の印字可能なファイルサイズに制限を加えてみましょう。artists グループの人達が作る PostScript ファイルのサイズは 巨大になる傾向があるので、上限値を 5M バイトとします。 それから、 プレインテキスト用のラインプリンタは無制限とします。 # # /etc/printcap for host rose # # # No limit on job size: # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:mx#0:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple: # # Limit of five megabytes: # bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:sc:rg=artists:mx#5000:\ :lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf: この場合もそうですが、この制限はローカル (ホスト rose) のユーザのみに適用されます。 リモートホストからプリンタを利用できるように設定している場合は、 そのリモートホストのユーザはこの制限を受けません。 これらのユーザにも制限を加える場合は、リモートホストの /etc/printcap の mx を指定する必要があります。 リモートホストから印字するための詳しい情報については、 「 リモートホストに接続されたプリンタ」 を参照してください。 リモートホストに接続されたプリンタへのジョブの サイズを制限する特別な方法は他にもあります。これについては、 「 リモートホストからのプリンタの利用を制限する」 を参照してください。 リモートホストからのプリンタの利用を制限する LPD スプーリングシステムでは、リモートホストから要求された ジョブの印字を制限するための方法がいくつか提供されています。 ホストの制限 ローカルの LPD が印字要求を受け付けるリモートホストは、ファイル /etc/hosts.equiv と /etc/hosts.lpd によって制御することができます。LPD では、 あるホストから印字の要求がきたとき、 このホストの名前がこれら 2 つのファイルのどちらかに含まれている かどうかを調べます。これが含まれていない場合は、LPD はこの要求を拒否します。 これらのファイルの形式は単純です。 各行にホストの名前を 1つずつ書いていきます。ファイル /etc/hosts.equiv の方は &man.ruserok.3; プロトコルでも利用され、 &man.rsh.1; や &man.rcp.1; といったプログラムの動作に影響するので注意が必要です。 /etc/hosts.equiv の記述は慎重におこないましょう。 例として、以下にホスト rose の /etc/hosts.lpd を示します。 orchid violet madrigal.fishbaum.de この例では、rose はホスト orchid、violet、 そして madrigal.fishbaum.de からの要求を受け付けることになります。 その他のホストが rose の LPD にアクセスしようと しても、LPD はそのジョブを拒否します (訳注: 拒否されるのは、そのホストが /etc/hosts.equiv にも含まれていない場合です)。 サイズの制限 スプーリングディレクトリがある ファイルシステムに残しておく必要がある 空き容量の大きさを制御することができます。 ローカルプリンタ用のスプーリングディレクトリに minfree という名前のファイルを作成します。そして、 そのファイルの中にリモートホストからのジョブの 要求を受け付けるために必要な空き容量のディスクブロックサイズ (1 ディスクブロック = 512 バイト) を記します。 これで、 リモートホストのユーザにファイルシステムを満杯にされないことが保証されます。 この機能を使うと、 ローカルホストのユーザに対してある種の優先権を与えることもできます。 ローカルホストのユーザは、 minfree ファイルで指定された値よりもディスクの空き容量が下回った後でもずっと、 ジョブをキューに入れることができるのです。 例えば、プリンタ bamboo 用の minfree を作ってみましょう。 このプリンタのスプーリングディレクトリを調べるために、 /etc/printcap を調べてみましょう。 以下に、bamboo のエントリ部分を示します。 bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:sc:rg=artists:mx#5000:\ :lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:mx#5000:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf: スプーリングディレクトリは sd で指定されます。LPD がリモートホストからのジョブを受け付けるために必要な ファイルシステムの空き容量を 3M バイト (=6144 ディスクブロック) にすることにしましょう。 &prompt.root; echo 6144 > /var/spool/lpd/bamboo/minfree 利用ユーザの制限 /etc/printcap の rs 項目を指定することで、 ローカルプリンタを利用できるリモートホストのユーザを 制限することができます。 ローカルホストに接続されたプリンタ用のエントリに rs 項目が指定されている場合、LPD は印字を要求したユーザのアカウントと同じログイン名が ローカルホストに登録されている場合に限り、 そのジョブが受け付けられます。 そうでないユーザからのジョブは LPD は拒否します。 この機能は、(例えば) 複数の部署がネットワークを共有しており、 この内のあるユーザが部署の境界を越えて活動している場合には特に有用です。 そのようなユーザに対して、システムのアカウントを与えるだけで、 これらのユーザは自分が所属する部署のシステムから そのシステムに接続されているプリンタを使用することができます。 これらのユーザにはむしろ、 プリンタの使用だけを認め、 その他のコンピュータ資源を利用させたくないときは、 それらのユーザにはホームディレクトリを与えず、 ログインシェルはシェルとしては何の役にも立たない /usr/bin/false などを指定して、 これらのユーザのアカウントはプリンタ用の 形式的な ものとします。 プリンタの利用に対する課金 課金 プリンタ という訳で、印字するためには料金をとることが必要です。 取らない理由などありましょうか。紙やインクにはお金がかかります。 そして、プリンタの維持費もかかります。 プリンタには可動部分が搭載されており、 これらの部分は壊れやすいという傾向があります。 プリンタや、その利用形態、維持費について調査をし、1 ページ (1 フィート、1 メートルなど) 当たりにかかるコストを調べておいてください。 これに基づき、プリンタの利用に対する課金を、実際に、 どのように始めればよいのでしょうか。 さて、残念ながら、この部分に関しては LPD スプーリングシステムはほとんど役に立ちません。 課金は使用しているプリンタの種類、印字するもののファイルの形式、 プリンタの利用に対する課金での あなた自身の要求に大きく左右されます。 課金システムを実現するためには、プリンタのテキストフィルタ (プレインテキストのジョブに対して課金するため) と変換フィルタ (その他のファイル形式に対して課金するため) を変更して、 印字したページを数えたり、 プリンタに印字したページ数を取得するための要求を送る必要があります。 ただし、出力フィルタのみを利用している場合は、 課金をおこなうことができません。フィルタに関しては、 「 フィルタ」をご覧ください。 一般に、課金方式には次の 2 つがあります。 定期的に課金する方法 はよく利用される方法です。この理由は、 恐らく比較的簡単に実現できるからです。 誰かがジョブを印字する度に、フィルタはそのユーザ名、 ホスト名、印字したページ数を課金データファイルに記録します。 毎月、毎学期、毎年、その他お好みの時期に、 各プリンタの課金用ファイルを集め、 それぞれのユーザが印字したページ数を合計して その分の課金をおこないます。 次回の課金期間をデータを 0 にして課金を再開するために、 すべてのログファイルを削除します。 利用毎に課金する方法 はあまり利用されていません。これは、 実現するのが比較的難しいからです。この方式では、 プリンタを使用したらすぐに、 フィルタがユーザにその利用に対する課金をおこないます。 ディスククオータのように、課金作業は瞬時におこなわれます。 この方式では、ユーザのアカウントが赤字になる場合に、 ユーザが印字をおこなうことを拒否することができます。 また、ユーザに プリンタ版 quota を調べたり、 調整したりする方法を提供したいと思うかもしれ ません。 これを実現するためには、ユーザとその quota を追跡するために、 あるデータベース用のコードが必要となります。 LPD スプーリングシステムでは、 両方式を簡単にですがサポートしています。これは、(ほとんどの場合で) 印字作業をフィルタがおこなっていたように、 課金作業もこのためのコードも用意することで実現されています。 しかし、明るい面もあります。 それは、課金方式に関して、非常に大きな柔軟性が与えられたということです。 例えば、「定期的に課金する方法」か、 「利用毎に課金する方法」のどちらかを選びまず、そして、 どんな情報 (ユーザ名、ホスト名、ジョブのタイプ、印字された頁数、 使用した紙の大きさ、印字をするために要した時間など) をログに記録するかを決めます。 以上のことをおこなうには、上記の情報を保持するために、 フィルタを変更しなくてはなりません。 手軽なプリンタ課金方法 FreeBSD には、「定期的に課金する方法」による課金を すぐに設定できるように、2 個のプログラムを添付しています。 その内の1つはテキストフィルタ lpf で、 これについては、「 テキストフィルタ lpf」をご覧ください。もう1つは、 &man.pac.8; で、 これはプリンタの課金データファイルからのエントリを集め、 これを合計するプログラムです。 「 フィルタはどのように機能しているか」で述べたように、 LPD ではテキストフィルタや変換フィルタを起動しますが、 そのコマンドラインで使用している課金データファイルの名前が指定されます。 両フィルタはこの引数を使って、 どの課金データファイルのエントリに書き込めばよいのかを知ることができます。 このファイルの名前は /etc/printcap 中の af 項目によって指定されます。 このファイルが絶対パ スで指定されない場合は、 スプーリングディレクトリからの相対パスとして扱われます。 LPD は、紙のページの幅と行数 (pw と pl 項目で 指定される) を引数として lpf を起動します。lpf では、何ページ印字したかを決定するためにこれらの引数を使用します。 ファイルをプリンタに送った後、 課金情報を課金データファイルに書き込みます。 このファイルは次のようになります。 2.00 rose:andy 3.00 rose:kelly 3.00 orchid:mary 5.00 orchid:mary 2.00 orchid:zhang 課金データファイルはプリンタ毎に分けて作るべきです。 これは、lpf にはデータファイルをロックする機構が組み込まれていないためです。 したがって、lpf が 2 つ起動されたとき、 同じファイルに同時に書き込みをおこなった場合、 お互いのエントリが破壊されてしまうかもしれません。 課金用ファイルを各プリンタ毎に確実に分けるには、 /etc/printcap 中の af=acct 項目を使います。 プリンタの利用に対してユーザに課金する準備ができたら、 スプーリングディレクトリに移動した後、 &man.pac.8; と入力してください。 次のような、ドル中心主義の課金リストが表示されます (訳注: ドル中心主義という表現は、 表示がドルで出ることへの著者の皮肉でしょう。 セントがあるので小数点以下が表示されますが、 この機能も日本では邪魔ですね)。 Login pages/feet runs price orchid:kelly 5.00 1 $ 0.10 orchid:mary 31.00 3 $ 0.62 orchid:zhang 9.00 1 $ 0.18 rose:andy 2.00 1 $ 0.04 rose:kelly 177.00 104 $ 3.54 rose:mary 87.00 32 $ 1.74 rose:root 26.00 12 $ 0.52 total 337.00 154 $ 6.74 &man.pac.8; が受け付ける引数には次のようなものがあります。 プリンタ printer の利用に対する課金リストを作成します。 このオプションは、/etc/printcap の af が絶対パスで指定されていた場合に限り、動作します。 ユーザ名のアルファベット順ではなく、 課金額の低い順にリストを並べます。 課金データファイルにあるホスト名を無視します。 このオプションを使用すると、ホスト alpha のユーザ smith とホスト gamma のユーザ smith は同一人物として扱われます。 このオプションが指定されない場合は、 両者は別なユーザとして扱います。 /etc/printcap の pc 項目で指定された値、または、 デフォルトの値 (2 セント) に代わり、紙1ページ、または、 1フィート当たりの価格を指定します。 price として、 浮動小数点数を指定することができます。 リストの並べる順番を逆順にします。 課金リストを作成し、 課金データファイルを削除します。 name … ユーザ names に対する課金情報のみを表示します。 &man.pac.8; が生成するデフォルトのリストには、 各ホストのユーザ別に印字ページ数が表示されます。 (ユーザがサイト内のすべてのホストを使用できるため) ホスト名の情報が意味を持たない場合、 pac -m を実行してください。次のようなリストが得られます。 Login pages/feet runs price andy 2.00 1 $ 0.04 kelly 182.00 105 $ 3.64 mary 118.00 35 $ 2.36 root 26.00 12 $ 0.52 zhang 9.00 1 $ 0.18 total 337.00 154 $ 6.74 課金額を決めるために、 &man.pac.8; は /etc/printcap ファイルの pc 項目で指定された値 (デフォルト値は 200、すなわち 1 ページ当たり 2 セント) を使います。この項目で、印字物に課金したい ファと思う 1 ページ当たり、 または、1 フィート当たりの価格を 100 分の 1 セント単位で指定します。 &man.pac.8; を オプション付きで起動すると、 この値を置き換えることができます。 この オプションで指定する額の単位は、 100 分の 1 セント単位ではなく、ドル単位です。例えば、次の指定では、 1 ページ当たりの単価が 1 ドル 50 セントになります。 &prompt.root; pac -p1.50 このオプションを使うと、 実際の課金額を集計することができます。 最後に、pac -s を起動すると、課金情報は課金データ累計ファイルに保存されます。 このファイルの名前は、プリンタの課金データファイルの後ろに _sum を付けたものとなります。そして、 課金データファイルは削除されます。次に &man.pac.8; が起動されると、 その時点までの累計金額を得るために、 課金データ累計ファイルが読み込まれ、 通常の課金データファイルからの情報に加算されます。 印字されたページ数をどのように数えるか? 課金を、リモートホストからの印字でさえも、 正確におこなうためには、 ジョブで使用された紙が何ページであるかを特定できる必要があります。 このことは、プリンタ利用に対する課金をおこなう上の根本的な問題です。 プレインテキストのジョブの場合、 問題を解決するのはさほど難しくはありません。 ジョブが何行であったかを数え、プリンタがサポートしている紙 1 ページに印字できる最大の行数と比較すればよいのです。 重ね打ちするために利用されるファイル中のバックスペース文字や、 物理的に複数の行に渡る長い論理行に対する取り扱いを忘れずにおこなってください。 (「テキストフィルタ lpf」で紹介した) テキストフィルタ lpf では、課金をおこなうときに、 これらの取り扱いをおこなってくれます。 課金をおこなうために必要なテキストフィルタを作成している方は、 lpf のソースコードが参考になるでしょう。 これに対して、他のファイル形式の処理はどのようにすれば よいのでしょうか。 まず、DVI から LaserJet、または、DVI から PostScript への変換の場合、フィルタが dvilj や dvips の 出力メッセージを解析することで、 何ページ分の変換がおこなわれたかを知ることができます。 他のファイル形式とその変換プログラムに関しても、 同様のことができるかもしれません。 しかし、この方式には問題点があります。それは、 変換されたページがすべて印字されるとは限らないということです。 例えば、プリンタが紙詰まりを起こしたり、トナー切れになったり、 はたまた、爆発したりするかもしれません。 そのような状況により印字が途中で中止されたとしても、この方式では、 ユーザは全ページ分の料金を課されてしまうのです。 それでは、どのような対策をたてることができるのでしょうか。 正確な 課金をおこなうための唯一の確実な方法は、 何ページ印字したのかを知らせることができるプリンタを入手し、 これをシリアルポートかネットワークに接続することです。 ほとんどすべての PostScript プリンタではこの概念がサポートされています。 他のプリンタも同様です (Imagen レーザプリンタをネットワーク接続するなど)。 それぞれのプリンタのフィルタを、 ジョブを印字した後で印字ページ数を得るように変更してください。 そして、課金情報はここで得られた値のみに 基づいて記録してください。行数を数えたり、 エラーが生じやすいファイルの調査は必要とされません。 もちろん、 気前よく印字料金をすべて無料にすることもできます。 プリンタを使う プリンタ 使い方 この節では、FreeBSD で設定したプリンタを使う方法について説明します。 ここでは、ユーザレベルでのコマンドを概説します。 &man.lpr.1; 印字をおこないます。 &man.lpq.1; プリンタキューを調べます。 &man.lprm.1; プリンタキューにあるジョブを削除します。 管理者用コマンド &man.lpc.8; もありますが、 これは「プリンタを管理する」 に記します。このコマンドは、 プリンタやそのキューの制御のために用いられます。 &man.lpr.1;、&man.lprm.1;、そして &man.lpq.1; の 3 コマンドは、 オプションをとり、これによって、 /etc/printcap のように操作の対象となる プリンタやキューを指定します。 これによって、様々なプリンタに対してジョブを送る、 取り消す、調査することができます。 が使われなかった場合は、これらのコマンドは PRINTER 環境変数で指定されたプリンタを使用します。 そして、PRINTER 環境変数がなかった場合は、 これらのコマンドはデフォルトのプリンタ lp を使います。 以下では、デフォルトプリンタ という用語が意味するプリンタは、PRINTER 環境変数で指定されたプリンタ、もしくは、PRINTER 環境変数がない場合は、lp という名前のプリンタです。 印字する ファイルを印字するためには、 次のように入力してください。 &prompt.user; lpr filename ... 印刷 これにより、 入力されたファイルのそれぞれをデフォルトのプリンタ から印字します。ファイル名が与えられなかった場合、 &man.lpr.1; は標準入力から印字するデータを読み込みます。例えば、 次のコマンドにより、ある重要なシステムファイルが印字されます。 &prompt.user; lpr /etc/host.conf /etc/hosts.equiv 印字させるプリンタを選択するためには、 次のように入力します。 &prompt.user; lpr -P printer-name filename ... 次の例では、プリンタ rattan に、 カレントディレクトリにあるファイルの詳細なリストを印字しています。 &prompt.user; ls -l | lpr -P rattan 上記の &man.lpr.1; コマンドではファイル名の指定がないので、 lpr は標準入力から印字するデータ、 この場合、ls -l コマンドの出力、を読み込みます。 &man.lpr.1; コマンドでは、 出力の整形を制御したり、ファイル変換を適用したり、 複数部数のコピーを作成したり、 などといた様々な幅広いオプションを受け付けることもできます。 詳細については、 「 その他の印字オプション」をご覧ください。 ジョブの処理状況を調べる プリントジョブ &man.lpr.1; コマンドを使って印字をする場合、プリントしようと するデータは プリントジョブ と呼ばれる箱に一緒に置かれ、 これが LPD スプーリングシステムに送られます。 プリンタにはそれぞれジョブ用のキューがあり、 送られてきたジョブはあなたや他のユーザからの別のジョブと一緒にそのキューで並んで、 処理される順番を待ちます。 プリンタは到着順にこれらのジョブの印字をおこないます。 デフォルトプリンタのキューの状態を表示するには、 &man.lpq.1; と入力します。プリンタを指定するときは、 オプションを使います。例えば、次のコマンド &prompt.user; lpq -P bamboo は、プリンタ bamboo のキューの状態を表示します。この lpq コマンドの出力結果の例を次に示します。 bamboo is ready and printing Rank Owner Job Files Total Size active kelly 9 /etc/host.conf, /etc/hosts.equiv 88 bytes 2nd kelly 10 (standard input) 1635 bytes 3rd mary 11 ... 78519 bytes この例では、bamboo のキューに 3 つのジョブがあることが分かります。 最初のジョブはユーザ kelly からのものであり、 ジョブ番号 9 が割り当てられています。 プリンタのすべてのジョブには一意なジョブ番号が付けられています。 ほとんどの場合、このジョブ番号は無視することができますが、 ジョブをキャンセルするときにはこの番号が必要になります。 このことの詳細については、「ジョブの削除 」をご覧ください。 ジョブ番号 9 のジョブは 2 つのファイルを処理します。すなわち、 &man.lpr.1; のコマンドラインに複数のファイル名が与えられたときは、 1つのジョブとして扱われるのです。このジョブは、現在、 アクティブジョブ (Rank の欄の active という後に注目) になっています。 これは、プリンタからそのジョブが現在印字されているはずであることを意味しています。 2 番目のジョブでは、 &man.lpr.1; コマンドに標準入力からデータが与えられています。 3番目のジョブはユーザ mary から与えられました。 このジョブのサイズはとても大きくなっています。 彼女がプリントしようとしたファイルのパス名はここで表示させるには長すぎるため、 &man.lpq.1; コマンドはドットを 3 つだけ表示しています。 &man.lpq.1; からの出力で一番最初の行もまた有益な情報を与えています。 この行から、プリンタが現在何をしているか (あるいは、少なくとも LPD がプリンタがしていると思っていること) が分かります。 &man.lpq.1; コマンドは オプションもサポートしています。 これにより、 詳しい情報が表示されます。 lpq -l の実行例を次に示します。 waiting for bamboo to become ready (offline ?) kelly: 1st [job 009rose] /etc/host.conf 73 bytes /etc/hosts.equiv 15 bytes kelly: 2nd [job 010rose] (standard input) 1635 bytes mary: 3rd [job 011rose] /home/orchid/mary/research/venus/alpha-regio/mapping 78519 bytes ジョブの削除 印字するようジョブを 送った後で印字を中断したくなったときは、 &man.lprm.1; コマンドで、 キューの中からそのジョブを削除することができます。 大抵の場合、アクティブジョブでさえも &man.lprm.1; を使って削除することができますが、 そのジョブの一部またはすべてが印字されてしまうかもしれません。 デフォルトプリンタへのジョブを削除するためには、最初に、 &man.lpq.1; を使ってそのジョブ番号を調べます。 すなわち、それから、 次のように入力して、ジョブを削除します。 &prompt.user; lprm job-number 特定のプリンタへのジョブを削除するときは、 オプションを使ってそのプリンタを指定します。 例えば、プリンタ bamboo のキューからジョブ番号 10 のジョブを削除するには次のようにします。 &prompt.user; lprm -P bamboo 10 &man.lprm.1; コマンドには略記法がいくつかあります。 lprm - あなたが (デフォルトプリンタへ) 送ったジョブをすべて削除します。 lprm user ユーザ user が (デフォルトプリンタへ) 送ったジョブをすべて削除します。 他のユーザのジョブを削除できるのはスーパユーザだけです。 あなたは、あなた自身のジョブしか削除することはできません。 lprm ジョブ番号もユーザ名もシンボル も指定されないときは、 &man.lprm.1; は現在のアクティブジョブを、 そのジョブを送ったのがあなた自身であるときに限り、 デフォルトプリンタから削除します。ただし、 スーパユーザは任意のアクティブジョブを削除することができます。 上記の略記法をデフォルトプリンタではなく 特定のプリンタに対しておこなうときは、 オプションでそのプリンタを指定するだけよ いのです。例えば、 プリンタ rattan のキューへあなたが送ったジョブを すべて削除するためには次のようにします。 &prompt.user; lprm -P rattan - ネットワーク環境で作業をしている場合、 あるホストから送られたプリンタジョブは、これを送ったホストで &man.lprm.1; を使った場合に限って、 これを削除することができます。 他のホストで同じプリンタを使えたとしても、 このジョブを削除することはできません。 次の例では、他ホストからジョブを削除することを試みています。 &prompt.user; lpr -P rattan myfile &prompt.user; rlogin orchid &prompt.user; lpq -P rattan Rank Owner Job Files Total Size active seeyan 12 ... 49123 bytes 2nd kelly 13 myfile 12 bytes &prompt.user; lprm -P rattan 13 rose: Permission denied &prompt.user; logout &prompt.user; lprm -P rattan 13 dfA013rose dequeued cfA013rose dequeued その他の印字オプション &man.lpr.1; コマンドには、テキストの整形や、 図や他のファイル形式の変換、複数部コピーの生成、 - ジョブの扱いなどをを制御することができます。 + ジョブの扱いなどを制御することができます。 この節では、これに関するオプションについて記しています。 整形と変換に関するオプション 以下の &man.lpr.1; 用のオプションはジョブにおける ファイルの整形の制御に関するものです。 このオプションは、ジョブにプレインテキストが含まれない場合や &man.pr.1; ユーティリティを使ってプレインテキストを整形する場合に用いてください。 TeX 次の例では、プリンタ bamboo に (TeX 組版システムによる) DVI ファイル fish-report.dvi を印字しています。 &prompt.user; lpr -P bamboo -d fish-report.dvi このオプションは、 ジョブに含まれるすべてのファイルに対して適用されます。 したがって、1 つのジョブに (例えば) DVI ファイルと ditroff ファイルを混在させることはできません。その代わりに、 ファイルを形式毎に別々のジョブに分け、 それぞれのジョブでその形式用の変換オプションを使って印字してください。 と を除くすべてのオプションを使用 するためには、 出力先プリンタ用の変換フィルタが必要です。例えば、 オプションを使用するには、DVI 用の変換フィルタが必要 です。詳細については、「 変換フィルタ」で説明しています。 cifplot ファイルを印字します。 DVI ファイルを印字します。 FORTRAN プログラムを印字します。 plot のデータを印字します。 出力に対して、number カラム分の字下げをおこないます。 number が省略されると、 8 カラム分字下げされます。 このオプションはある変換フィルタと一緒の指定されたときのみに機能します。 と数字の間に空白を入れてはいけません。 制御文字を含む文字通りのテキストデータを印字します。 ditroff (device independent troff) データを印字します。 -p 印字する前に &man.pr.1; によってプレインテキストを整形します。 詳細については &man.pr.1; をご覧ください。 &man.pr.1; コマンドにより生成されるヘッダを、 ファイル名の代わりに title とする。 このオプションは、 と一緒に使ったときのみ機能する。 troff データを印字します。 ラスタのデータを印字します。 次の例では、&man.ls.1; のマニュアルを美しく整形したものをデフォルトプリンタで印字しています。 &prompt.user; zcat /usr/share/man/man1/ls.1.gz | troff -t -man | lpr -t &man.zcat.1; コマンドで &man.ls.1; のマニュアルのソースファイルの圧縮を復元し、これを &man.troff.1; コマンドに渡しています。 これによりソースファイルが整形され GNU troff の形式となります。 その結果は &man.lpr.1; に渡され、 LPD スプーラへジョブの要求が発せられます。 &man.lpr.1; には オプションが使われているため、 スプーラでジョブを印字したときに GNU troff の形式から、デフォルトプリンタ解釈できる形式へと変換されます。 ジョブに関するオプション 以下のオプションは、&man.lpr.1; によって、 そのジョブを特殊な扱いにするよう LPD に指示するためのものである。 -# copies ジョブに含まれるファイルのそれぞれを 1 部だけ印字するのではなく、 copies 部のコピーを生成させるものです。管理者によっては、 プリンタの消耗を避け、コピー機による複製を奨励するために このオプションの使用が禁止されているかもしれません。 これに関しては、「 複数部のコピーの印字を制限する 」をご覧ください。 次の例では、デフォルトプリンタで parser.c を3 部コピーし、次に、 parser.h を3部コピーしています。 &prompt.user; lpr -#3 parser.c parser.h -m 印字ジョブが完了した後で、メールを送ります。 このオプショ ンを付けると、LPD システムはジョブの扱いが終了したときに、 あなたのアカウントにメールを送ります。 メールのメッセージには、ジョブが正常終了したのか、あるいは、 何か異常があり、(しばしば) その異常が何であったのかが書かれています。 -s 印字ファイルをスプールディレクトリにコピーせず、 代わりに、 シンボリックリンクを作成するよう指示します。 印字させるジョブのサイズが大きいとき、 このオプションを使うと便利かもしれません。このオプションにより、 スプー ルディレクトリの容量が節約されます (それに、 巨大なジョブのお陰でスプールディレクトリのあるファイルシステムの空き容量がなくなってしまうかもしれません)。 さらに、LPD がいちいちすべてのデータをコピーする必要がなくなりますので、 時間の節約にもなります。 ただし、欠点もあります。LPD はオリジナルのファイルを直接参照するので、 印字が終了するまでそのファイルを変更したり削除することができません。 リモートのプリンタで印字している場合、LPD は、 結局のところ、 ローカルホストからリモートホストにファイルをコピーする必要があります。したがって、 オプションはローカルのスプーリングディレクトリの空き容量を節約するだけで、 リモート側では節約されません。それにも関わらず、 このオプションはそれでも有用です。 -r ジョブに含まれるファイルを、 スプーリングディレクトリに ファイルをコピーした後に削除します。もしくは、 オプションと一緒に使われた場合は、 印字終了後に削除されます。 このオプションの使用には十分注意して下さい。 ヘッダページ用オプション 以下のオプションにより、 ジョブのヘッダページに通常印字さ れるテキストを &man.lpr.1; に調整させることができます。 対象のプリンタからヘッダページが出力されない場合は、 これらのオプションは何の効力も持ちません。 ヘッダページの設定に関する情報については、 「 ヘッダページ」を参照してください。 -C text ヘッダページに印字されるホスト名を text に置き換えます。なお、 ホスト名の場所には、通常、 ジョブの要求があったホストの名前が印字されます。 -J text ヘッダページに印字されるジョブ名を text に置き換えます。 ジョブ名の場所には、通常、ジョブの最初のファイル名、 または、標準入力からデータが印字されたときは stdin が印字されます。 -h ヘッダページを出力を禁止します。 サイトによっては、 そのヘッダページの生成方法により、 このオプションの効果が現れないかもしれません。 詳細は、「 ヘッダページ」をご覧ください。 プリンタを管理する プリンタの管理者として、プリンタの設置、設定、 そして、それらのテストをおこなう必要がありました。 &man.lpc.8; コマンドにより、 これまでとは別な管理方法がプリンタと対話的におこなわれます。 &man.lpc.8; により、次のことが可能となります。 プリンタの起動、停止をおこなう。 キューへの入力の許可、禁止をおこなう。 それぞれのキューにあるジョブの順番を変更する。 最初に用語に関する注意をしておきます。 プリンタが停止しているとは、 キューの中にあるどのジョブも印字されることがない状態 を言います。この状態においても、 ユーザはまだジョブの要求をおこなうことができますが、 これらのジョブはキューの中で、 プリンタがスタートする状態になるまで、 あるいは、キューの内容が削除されるまで待たされることになります。 キューが禁止状態にあるとは、(root 以外の) すべてのユーザが プリンタにジョブを要求することができない状態のことを言います。 キューが許可状態にある場合は、 ジョブの入力が許可されます。 キューが禁止状態にある場合でも、 プリンタをスタートす る状態にすることは可能です。この場合は、 キューが空になるまで、 キュー内のジョブの印字が続けられます。 一般的に、 &man.lpc.8; コマンドを使用するには root の権限を持っている必要があります。一般のユーザも &man.lpc.8; コマンドを使うことはできますが、 プリンタの状態を取得することとハングしたプリンタ を再スタートすることだけに使用が制限されています。 以下に、 &man.lpc.8; コマンドに関する説明の要約を述べます。 ほとんどのコマンドでは、操作対象となるプリンタを指定するため printer-name 引数を与えます。 printer-name の代わりに all が与えられると、操作は /etc/printcap 内にある全プリンタに対しておこなわれることになります。 abort printer-name 現在のジョブをキャンセルし、プリンタを停止させます。 キューが許可状態にある場合は、 ユーザはまだジョブを入力することができます。 clean printer-name プリンタのスプーリングディレクトリから、 ジョブの古いファイルを削除します。状況によって、 とりわけ、印字途中でエラーが発生していたり、 管理操作が頻発していた場合には、 ジョブで作られたファイルを LPD が完全に削除しないことが あります。このコマンドでは、 スプーリングディレクトリに入っていないファイルを見つけ出し、 それを削除しています。 disable printer-name キューに新しいジョブを入れることを禁止します。 プリンタ がスタート状態にあるときは、 キューに残っているジョブの印字は続けられます。ただし、 キューが禁止状態にあったとしても、スーパーユーザ (root) は常にジョブを入力することができます。 このコマンドは、 新しいプリンタやフィルタを設置している間に使用すると有用です。 すなわち、キューを禁止状態にしておくと、 root によるジョブのみが入力されます。そして、 その他のユーザは、テストが完了し、 enable コマンドでキューが再度許可状態になるまで、 ジョブの入力はできなくなります。 down printer-name message プリンタをダウンさせます。これは、 disable をおこなった後で、 stop をおこなった場合と等価になります。 message は、ユーザが &man.lpq.1; コマンドでプリンタのキューの状態を調べたり、 lpc status でプリンタの状態を調べたときに、 プリンタの状況として表示されるメッセージです。 enable printer-name プリンタのキューを許可状態にします。 ユーザはジョブの入力ができるようになりますが、 プリンタがスタートの状態になるまでは、 プリンタからは何も印字されません。 help command-name command-name コマンドのヘルプメッセージを表示します。 command-name が指定されなかった場合は、 利用できるコマンドの要約が表示されます。 restart printer-name プリンタをスタートさせます。通常のユーザは、 LPD がある異常な状況でハングしたときに限り、 このコマンドを使用することができます。しかし、 stop または down コマンドにより、 停止状態にあるプリンタをスタートさせることはできません。 restart コマンドは、 abort の後に start をおこなったことと同じになります。 start printer-name プリンタをスタートさせます。 プリンタのキューにあるジョブを印字することでしょう。 stop printer-name プリンタを停止します。プリンタは、 現在のジョブを終了させ、そして、 キューにあるその他のジョブは印字しません。 プリンタが停止状態にあったとしても、まだ、 許可状態にあるキューに対して、ジョブを送ることができます。 topq printer-name job-or-username printer-name のキューに対して、ジョブ番号 job のジョブ、または、ユーザ username から送られたジョブを置き換えて、キューの先頭に持ってきます。 このコマンドに関しては、 printer-name の代わりに all を使用することはできません。 up printer-name プリンタをアップ状態にします。これの反対のコマンドが down です。start の次に enable をおこなったことと等しくなります。 コマンドラインから上記のコマンドを入力すると、 &man.lpc.8; はこれを受け付けます。コマンドが入力されなかった場合は、 &man.lpc.8; は対話モードに入り、 exit、quit、 または、 ファイル終端文字が入力されるまでコマンドの入力ができます。 標準スプーラの代替品 このマニュアルを最初から通読されている方ならば、ここまでで、 FreeBSD 付属の LPD スプーリングシステムに関して知っておくべき ことすべてを学ばれたことと思います。 多分、このシステムにあるたくさんの欠点について認識できたことでしょう。 すると、 (FreeBSD 上で動作する) スプーリングシステムには他にどのようなものがあるのか という疑問が自然と湧いてきます。 LPRng LPRng LPRng は、その称するところの意味は 次世代の LPR です。これは PLP を完全に書き換えたものになっています。 Patrick Powell と Justin Mason (PLP の主要な管理者) の共同で LPRng が作成されました。 LPRng の主要サイトは ftp://dickory.sdsu.edu/pub/LPRng/ です。 トラブルシューティング &man.lptest.1; を使った簡単なテストをおこなった結果、 正しい出 力を得られずに、以下に示すような出力が得られるかもしれません。 しばらくしたら出力される、または、 紙の全体が出てこない プリンタは上で示されたような印字を おこなったのですが、しばらくして止まってしまい、 動かなくなってしまいました。 印字された結果をプリンタから取り出すためには、 プリンタにある PRINT REMAINING ボタン、または、FORM FEED ボタンを押す必要があるようです。 この場合は、 おそらくジョブはプリントをする前に 更にデータが送られてこないか待ち続けているのでしょう。 この問題を解決するためには、プリンタに FORM FEED 文字 (あるいは特定の必要な文字コード) を 送るテキストフィルタを使ってください。 プリンタ内部に残ったデータをプリンタにすぐに印字させるには、 普通はこれで十分です。 次のジョブが前のジョブの最終ページの中央の どこかから印字を開始させないためにも、 紙の途中で印字のジョブが終了したかどうかを確認するのは有益です。 シェルスクリプト /usr/local/libexec/if-simple を次のように変更して、プリンタへジョブを送信した後に FORM FEED 文字を印字させるようにします。 #!/bin/sh # # if-simple - Simple text input filter for lpd # Installed in /usr/local/libexec/if-simple # # Simply copies stdin to stdout. Ignores all filter arguments. # Writes a form feed character (\f) after printing job. /bin/cat && printf "\f" && exit 0 exit 2 階段効果 が現れた 次のような印字結果が得られた。 !"#$%&'()*+,-./01234 "#$%&'()*+,-./012345 #$%&'()*+,-./0123456 MS-DOS OS/2 ASCII あなたは「階段効果」 の新たなる犠牲者になってしまいました。この原因は、 改行を表わすべき文字がなんであるか の解釈が混乱していることにあります。Unix スタイルのオペレーティングシステムでは、改行文字は ASCII コード 10 の line feed (LF) の 1 文字が使われています。MS-DOS や OS/2 などは ASCII コード 10の LF と、ASCII コード 13 の文字 (carriage return または CR) をペアで使います (訳注: Machintosh では CR のみで表現されています)。大抵のプリンタでは、 改行を表わすために MS-DOS の慣習にしたがいます。 FreeBSD で印字する場合、印字したテキストは LF 文字だけ が使われていました。プリンタでは LF 文字を見つけると、紙を 1 行分送り出しました。しかし、 次の文字を印字するた めの紙の水平方向の位置は維持されました。すなわち、CR 文字が意味することは、 次の文字を印字する位置を紙の左端に動かすことです。 FreeBSD がプリンタに動作をして欲しいと思っている動作を以下に示します。 プリンタが CR を受け取ったとき CR 動作 (復帰) をおこなう プリンタが LF を受け取ったとき CR + LF 動作 (復帰、改行) をおこなう このように動作させるための方法がいくつかあります。 これらの文字の解釈を変えるために、 プリンタの設定スイッチかコントロールパネルを操作する方法。 どのようにして設定をするかはプリンタのマニュアルを参照してください。 FreeBSD 以外のオペレーティングシステムを切り替えて使う場合、 CR と LF 文字の解釈をそのオペレーティングシステムで使われているようにプリンタを 再設定する必要があるかもしれません。 以下に示す解決方法のいずれかを 選ぶのがよいかもしれませんね。 自動的に LF を CR+LF に変換してくれる FreeBSD 用のシリアルドライバを入手する方法。 もちろん、このドライバはプリンタ専用に接続される シリアルポート のみで動作します。 この機能を許可するためには、 /etc/printcap ファイルで対象プリンタの fs 項目で CRMOD ビットをセットします。 LF 文字の扱いを一時的に変更するための エスケープコード をプリンタに送る方法。 プリンタがサポートしているかもしれないエスケープコード については、 プリンタのマニュアルを参照してください。 適切なエスケープコードが見つかったら、 最初にそのコードを送り、次にプリントジョブを送信 するようにテキストフィルタを変更してください。 PCL 次に、Hewlett Packard 社の PCL エスケープコードに対応しているプリンタのための テキストフィルタの例を示します。 このフィルタでは、プリンタ に LF 文字を LF と CR の2文字として扱わせます。 その後に、プリンタにジョブを送ります。最後に、 ジョブの最終ページの紙を排出するため、FROM FEED 文字を送ります。このフィルタは Hewlett Packard 社のほとんどすべてのプリンタで機能するはずです。 #!/bin/sh # # hpif - Simple text input filter for lpd for HP-PCL based printers # Installed in /usr/local/libexec/hpif # # Simply copies stdin to stdout. Ignores all filter arguments. # Tells printer to treat LF as CR+LF. Ejects the page when done. printf "\033&k2G" && cat && printf "\f" && exit 0 exit 2 ホスト orchid にある /etc/printcap の例を以下に示します。ここには、 一番目のパラレルポートにプリンタ (Hewlett Packard LaserJet 3Si) が一台接続されており、そのプリンタ名は teak です。 # # /etc/printcap for host orchid # teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\ :lp=/dev/lpt0:sh:sd=/var/spool/lpd/teak:mx#0:\ :if=/usr/local/libexec/hpif: 訳注 LF を CR+LF に置き換える cat コマンドを作る方法も当然考えられます。 そして、このコマンドと、if-simple の cat の部分を置き換えればよいわけです。 具体的にどのようにするかは、 読者への練習問題としましょう。 各行が重ね書きされてしまった プリンタは紙送りをまったくしませんでした。 テキストすべての行がある行の上で重ねて印字されてしまいました。 この問題は、 階段現象とは 正反対 な問題で、 ほとんどまれにしか起こりません。FreeBSD では行末として扱われる LF 文字が、紙の左端に印字位置を復帰しますが、 紙送りはしない CR 文字として扱われています。 プリンタの設定スイッチかコントロールパネルを使って、 LF と CR の文字を次のような解釈をするようにしてください。 プリンタが受け取ったとき プリンタがおこなう CR CR 動作 (復帰) LF CR + LF (復帰、改行) 訳注 LF を CR+LF に置き換える cat コマンドを作る方法も当然考えられます。 そして、このコマンドと、 if-simple の cat の部分を置き換えればよいわけです。 具体的にどのようにするかは、 読者への練習問題としましょう。 プリンタが文字を紛失してしまう 印字しているのですが、 各行の 2 〜 3 文字が印字されません。 プリンタを動かせば動かすほど、 もっとたくさんの文字が紛失されていき、 この問題は更に悪くなっていくかもしれませんでした。 この問題は、 シリアルポートを通してコンピュータから送られてくるデータの速度に、 プリンタがついていけないことに起因します (この問題は、パラレルポートに接続された プリンタでは発生することはありません)。 この問題を克服する方法が2つあります。 プリンタが XON/XOFF のフロー制御をサポート している場合は、項目 fs で TANDEM ビット をセットして、FreeBSD にこの機能を使用させてください。 プリンタがキャリアフロー制御をサポートして いる場合は、項目 fs で MDMBUF ビットをセットして下さい。それから、 プリンタとコンピュータを接続しているシリアルケーブルが キャリアフロー制御用に正しく配線されたものかどうかを確認してください。 プリンタがフロー制御をまったく サポートしていない場合は、項目 fs の NLDELAY と TBDELAY、 CRDELAY、VTDELAY、BSDELA のいくつかのビットを組み合わせて使い、 プリンタへ送るデータの流れに適当な遅延を加えてください。 プリンタは意味不明な文字列を印字した プリンタはランダムなゴミのように 見えるものを印字しましたが、 意図したテキストは印字してくれませんでした。 この問題は、通常、 シリアルポートに接続したプリンタでの 通信パラメータの誤りからくる前項とは別の症状です。 br 項目の通信速度と fs と fc 項目のパリティビットの設定を共に調べてみてください。 また、プリンタでの設定が /etc/printcap ファイルで設定した 内容と一致しているかどうかも確認してください。 訳注 simple-if のような単純なフィルタだけの状態で、 日本語を含むテキストを印字しようとした場合にも、 シリアルポート、パラレルポートの使用に関係なく、 このような症状は見られます。日本語プリンタの場合、 漢字コードそのもの を送信しただけでその漢字を印字してくれるものは、 少なくとも訳者は見たことがありません。 漢字を印字するための制御 コードを別途送信するフィルタが必要となります。 また、そのようなフィルタを使用していても、 そのフィルタが想定してる漢字コードと異なった文書を プリントしようとしたときもこのような症状は出ます。 もちろん、これはプリンタ用の 言語を持たないプリンタの話で、PostScript プリンタ などにプレインテキストを送信しても、日本語対応、 非対応に関らず、意味不明な文字列が印字される (もしくは、何も印字されない) ことでしょう。 何も起きない もしプリンタが何の動作もしないのであれば、 ハード的な問題ではなく、多分 FreeBSD の中に問題があります。 /etc/printcap ファイルで、 デバッグしているプリンタのエントリに (lf 項目で) ログファイルを取るように 設定を追加してください。例えば、プリンタ rattan 用のエントリの項目 lf は次のようになります。 rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple:\ :lf=/var/log/rattan.log 次に、もう一度印字をおこなってみます。そして、 発生したと思われるエラーメッセージを見るためにログファイル (上記の例では、 /var/log/rattan.log) を調べます。そこで見られたメッセージを元に、 問題を解決してみてください。 項目 lf が指定されていない場合、LPD はデフォルト のログファイルとして /dev/console を使います。