diff --git a/ja/FAQ/network.sgml b/ja/FAQ/network.sgml index 99d7f7839c..91300b1e26 100644 --- a/ja/FAQ/network.sgml +++ b/ja/FAQ/network.sgml @@ -1,1029 +1,1092 @@ - + - + ネットワーキング

訳: &a.arimura; &a.shou; &a.nishika; . 24 December 1997. ``diskless boot'' に関する情報はどこで得られますか?

``diskless boot'' というのは, FreeBSD がネットワーク上で起動し, 必要なファイルを自分のハードディスクではなくてサーバから読み込むものです. 詳細については を読んでください. FreeBSD をネットワークの router として使用することはできますか?

インターネット標準やこれまでのよい経験によって指摘されている通り, FreeBSD は標準ではパケットを forward するように設定されていません. しかし, の中で次の変数の値を gateway_enable=YES # Set to YES if this host will be a gateway

このオプションによって の変数 ほとんどの場合, router についての情報を同じネットワーク の他の計算機等に知らせるために, 経路制御のためのの process を走らせる必要があるでしょう. FreeBSD には BSD の標準経路制御デーモン である が付属していますが, より複雑な状況に対処するためには 注意してほしいのは, FreeBSD をこのようにして使用している場合でも, router に関するインターネット標準の必要条件を完全には満たしていない ということです. しかし, 普通に使用する場合にはほとんど問題ありません. Win95 の走っているマシンを, FreeBSD 経由でインターネットに接続できますか?

通常, この質問が出てくる状況は自宅に二台の PC があり, 一台では FreeBSD が, もう一台では Win95 が走っているような場合です. ここでやろうとしていう事はFreeBSDの走っている計算機をインターネット に接続し, Win95 の走っているマシンからは FreeBSD の走っているマシンを 経由して接続をおこなう事です. これは二つ前の質問の特別な場合に相当します.

FreeBSDをとして設定する方法については, 役に立つ文書があります.

や のような また, に関する節も参照してください. +

また, に関する節も参照してください. ISC からリリースされている BIND の最新版は compile できないんでしょうか?

BIND の配布物と FreeBSD とでは ``compat/include/sys/cdefs.h を削除してください. FreeBSD で SLIP と PPP は使えますか?

使えます. FreeBSD を用いて他のサイトに接続する場合には, , , そして のマニュアルページを見てください. は SLIP のサーバ専用で, は SLIP のクライアント専用です.

これらのプログラムの解説が, の以下のセクションにあります.

「シェルアカウント」を通じてのみインターネットへアクセス可能な場合, package みたいなものが欲しくなるかもしれませんね. これを使えば, ローカルマシンから直接 ftp や http のようなサービスに (限定的ではありますが) アクセスすることができます. FreeBSD は NAT か IP マスカレードをサポートしていますか?

ローカルなサブネット (一台以上のローカルマシン) を持っているが, インターネットプロバイダから 1 つしか IP アドレスの割り当てを 受けていない場合 (または IP アドレスを動的に割り当てられている場合でも), プログラムを使いたくなるかもしれませんね. も, 同様の機能を持っており, が使われます.

まず のマニュアルと, を読んでみましょう. 次に, set log Phase Chat Connect Carrier lcp ipcp ccp command

という命令を /etc/ppp/ppp.conf に加えて (default セクションの先頭に加えるのが一番良いでしょう) ログを有効にしてみてください. その際, に !ppp *.* /var/log/ppp.log

と書かれた行が含まれているか, また, /var/log/ppp.log が存在しているかどうか確かめておいてください. さて, これで 何が起きているのか突き止めるために, ログファイルからたくさんの 情報を得られるようになりました. ログに訳の分らない部分があっても 心配ご無用. あなたが助けを求めた誰かにとっては, その部分が 意味をなす場合があるのです.

訳注: ログの取得に syslog を使用するようになったのは 2.2.5 以降からです.

使用中の ppp のバージョンで "set log" 命令を解釈しない場合は, をダウンロードすべきです. FreeBSD の 2.1.5 以降でビルドできます. ppp が -auto モードでダイアルしてくれない

まず最初に, デフォルトルートが確立しているかどうかチェックして ください. を実行すると, 以下のような情報が表示されるはずです. 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 の中の が走っている可能性があります. FreeBSD 2.2.5 より前の バージョンに付属していた add 0 0 HISADDR

と書かれた行を以下のように修正してください. add 0 0 10.0.0.2

netstat -rn でデフォルトルートの情報が表示されない場合, もう一つ, (2.2.2 より前のリリースでは /etc/sysconfig と呼ばれていました) の中でデフォルトの ルータを誤って設定し, ppp.conf から delete ALL

の行をうっかり消してしまった可能性があります. この場合は, ハンドブックの の項を読み直してください. "No route to host" とはどういう意味ですか?

このエラーは通常, /etc/ppp/ppp.linkup に以下のような セクションが無い場合に起こります. MYADDR: delete ALL add 0 0 HISADDR

これは動的 IP アドレスを使用している場合, またはゲートウェイの アドレスを知らない場合にのみ必要な設定です. インタラクティブモード を使用している場合, delete ALL add 0 0 HISADDR

詳しい情報については, ハンドブックの の項を参照してください. 3 分ほど経つと接続が切れてしまう

ppp のタイムアウトは デフォルトでは 3 分です. これは set timeout NNN

という命令によって調整することができます. ppp.conf に入れることも, インタラクティブモードでプロンプトから入力することも できます. ソケットを用いる か を使用し, 訳注 pppctl は 2.2.5R からです.

詳しい情報は のマニュアルを参照してください. 負荷が高いと接続が切れてしまう

Link Quality Reporting (LQR) の設定を行っている場合, マシンと接続先の間で非常にたくさんの LQR パケットが失われている 可能性があります. 結果として ppp は回線の具合いが悪いと考え, 回線を切断するのです. 2.2.5 より前のバージョンの FreeBSD では LQR はデフォルトで有効になっています. 現在ではデフォルトの状態で 無効です. LQR は以下の命令で無効にすることができます. disable lqr 接続がランダムに切れてしまう

時々, ノイズの多い回線, あるいは待ち機能付きの回線では, モデムが (誤って) キャリアを失ったと思い込み, ハングアップしてしまう ことがあります.

大多数のモデムでは, 一時的なキャリアの喪失にどれだけ我慢するか 設定で決めることができます. 例えば USR Sportster では, S10 レジスタ の値を 10 倍した秒数がその値になります. この場合, モデムをもっと のんびり屋さんにするには, dial 行に次のような文字列を加えると 良いでしょう. set dial "...... ATS10=10 OK ......"

詳しくはお使いのモデムのマニュアルをご覧ください. Login OK! のメッセージが出た後, 何も起こらない

2.2.5 より前のリリースの FreeBSD では, はリンクが確立した後, 接続先が Line Control Protocol (LCP) を発信するのを待ちます. しかし, 多くの ISP ではネゴジェーションを 自分からは起こさず, クライアントが起こすのを待っています. set openmode active

でもまだ "magic is the same" というエラーが出る

時折, 接続直後のログに "magic is the same" というメッセージが あらわれることがあります. このメッセージがあらわれても何も起きない 場合もありますし, どちらかの側が接続を切ってしまう場合もあります. ppp の実装の多くはこの問題に対応できておらず, その場合にはちゃんと link が上がっている状態であっても, ppp が最終的にあきらめてしまい 接続を切るまで, 設定のリクエストが繰り返し送られ, 設定が行われた という通知が log ファイルに残ると思います.

これは通常, ディスクアクセスの遅いサーバマシンのシリアルポートで 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のnegotiationが続く.

これが, 片方のこれを回避する最も良い方法は, 片方を set openmode passive というコマンドでできます. このオプションは気を付けて使わないといけ ません. さらに set stopped N というコマンドを追加して, set openmode active N というコマンド(ここで, ppp が接続直後に固まってしまう

2.2.5 より前のバージョンの FreeBSD では, disable pred1 ppp の内部でシェルを起動しようとすると固まってしまう

このような場合は, 代わりに ヌルモデムケーブルを使用しているとき, ppp が終了しない

ヌルモデムケーブルを使用して直接接続している場合, enable lqr

こうすると, 接続先がネゴジェーションを行う場合, デフォルトで LQR の使用を受け入れるようになります. ppp を -auto モードで動かすと, 勝手にダイアルすることがある

原因を突き止めるためには, 以下の命令を使用してください. set log +tcp/ip

これで接続を通過する全てのトラヒックをログに残すことができるように なりました. 次に突然回線がつながったときのログのタイムスタンプを たどれば, 原因を突き止めることができるはずです.

原因がわかったら, 次に, このような状況ではダイヤルが起こらないように しましょう. 通常, この手の問題は, DNS で名前の解決をしようとしたために 起こります. DNS による名前の解決によって, 接続が行われるのを防止する には, 次のような手段を用います (これは 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 の場合は, 何が実際にホスト名を検索しようとしているのかを 突き止めるべきでしょう. 大抵の場合は, が犯人です. 設定ファイルで sendmail が DNS に問い合わせないようになっているか確認すべきです. 自分用の設定ファイルを作成するための詳しい方法は の節をご覧ください. または, define(`confDELIVERY_MODE', `d')dnl

この行を追加すると, sendmailはメールキューを処理する (通常sendmailは30分ごとにキューを処理するよう, ``-bd -q30m'' というオプションを付けて起動されます) までか, または (多分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

これは に最後にくることが要求されている "expect" という文字列がくるま でのすべてのものをログに記録させます.

接続速度はログにとりたいけれど, PAP や CHAP を使っている (その結果, dial スクリプト中の 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 を 待っています, 私のchatスクリプトでは`\'という文字をPPPが解釈して くれません

PPPは設定ファイルを読み込むときに, chatの各引数が解釈されるときには, ``\P''や``\T''のような 特別なescape sequence (man pageを見てください)を見付けるために もう1回parseを行います. このようにparseは2回繰り返されま すので, 正しい回数だけescapeを行わないといけません.

モデムにたとえば``\''のような文字を送りたい場合には, 次のように する必要があります: 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 は 実効 uid が 0 で動いていますので, オペレーティングシステム は ppp を終了させる前にディスクに core イメージを書き込みません. しかし ppp は実際にはセグメンテーション違反や他の core を吐く原因 となるようなシグナルによって $ tar xfz ppp-*.src.tar.gz $ cd ppp*/ppp $ echo STRIP= >>Makefile $ echo CFLAGS+=-g >>Makefile $ make clean all $ su # make install # chmod 555 /usr/sbin/ppp

これで debug 可能なバージョンの ppp がインストールされます. root で ppp を実行し, 全ての特権が無効になっているようにする必要 があるでしょう. ppp を実行する時には, current directory が make した directory であるようにしてください.

これで, ppp がセグメンテーション例外を受け取ったときには ppp.core という名前の core ファイルを吐くようになります. core が 吐かれたら次のようにしてください: $ su # gdb /usr/sbin/ppp ppp.core (gdb) bt ..... (gdb) f 0 ..... (gdb) i args ..... (gdb) l .....

質問する際には, これら全ての情報を提供して, 問題点の分析ができ るようにしてください.

gdb の使い方に慣れている場合には, 実際に dump の原因となった 理由やそのアドレス, 関連した変数の値なども調べる事ができるでしょう. auto modeでdialをするようなprocessがconnectしてくれない

これはを呼び出した時, tun intergaceのIP numberが socketのendpointに割り当てられます. kernelは最初に外へ出ていく packetを作り, それをtunデバイスへ書きます. 次にこの問題に対処する理論的な方法がいくつかあります. もし可能なら, 相手が同じIP numberを割り当てなおす事ができるのが最も良いです我々の側から対処できる最も簡単な方法は, tun interfaceのIP numberを固定する事ですが, かわりに外に出ていくpacketを変更して source IP numberをinterfaceのIPからnegotiateされたIPに書きかえる 事によっても対処できます. これが, (およびpppのもう1つの(最も確かな)方法は, 全てのbindされているsocketの IPを変更するようにsystem callを実装する事です. 3つ目の方法は, interfaceをIP number無しで立ち上げる事を許す ことです. 外に出ていくpacketは最初のSIOCAIFADDR ioctlが終わるまで は255.255.255.255というIP numberを与えられます. これによって socketを完全にbindすることができます. 現在のところ, これらの方法のどれもまだ実装されていません. + + 何故ほとんどのゲームが -alias スイッチ付きだと動かないんですか? + +

訳注:この問題は佐藤 淳一さん作の NAT パッチを使っても解決できます. + をご覧ください. + +

libalias を使っている時にゲームなどの類のものが動作しない理由は, + 外側にあるマシンが接続しようとしているか, 内側にあるマシンに (余計な) + UDP パケットを送信しようとしているからです. + 内側のマシンにこれらのパケットを送るべきかについて, + packet alias ソフトウェアは関知しません. + +

うまく動かすためには, 実行中のものが問題の発生している + ソフトウェアだけであるかを確認し, ゲートウェイの tun インタフェースに対して + tcpdump を実行するか, ゲートウェイ上で ppp tcp/ip logging を有効化 + (``set log +tcp/ip'') してください. + +

行儀の悪いソフトウェアを起動する際に, ゲートウェイマシンを + 通過するパケットを監視すべきです. 外側から何かパケットが戻ってきた時に, + そのパケットは破棄されるでしょう (それが問題なのです). + これらのパケットの port 番号に注意して, その行儀の悪いソフトウェアを + 停止してください. + これを数回繰り返して port 番号が常に同じであるかを確認してみてください. + 同じであった場合は, /etc/ppp/ppp.conf の適切なセクションに次の行を入れると, + そのソフトウェアは動作するようになるでしょう. + + + + alias port proto internalmachine:port port + + +

ここで ``proto'' は ``tcp'' か ``udp'' であり, + ``internalmachine'' はパケットを送りたいマシン, そして + ``port'' はパケットのディストネーションの port 番号です. + +

上記のコマンドを変更せずに他のマシン上でそのソフトウェアを + 使用できるようにはしたくないかもしれません. そして + 同時に二つの内部のマシン上でそのソフトウェアを実行することは + この質問の範囲を超えています. 結局, 外側の世界からは + 内部ネットワーク全体がただ一つのマシンとして見えるのです. + +

port 番号が常に同じとは限らない場合, さらに三つのオプションがあります. + +

1)libalias でサポートするようにし, 結果を送り付ける. + 特定の場合の例は /usr/src/lib/libalias/alias_*.c にあります + (alias_ftp.c は良いプロトタイプです). これには通常, 外向きの特定のパケットを読み, + 内部の計算機のある特定のポートへの接続を開始するような命令が + 外部の計算機対して送られていることを見分け, 後続のパケットがどこに行けば + いいのかが分かるように, エイリアステーブル中の ``route'' の部分を設定する, + という作業が含まれます. + +

これは最も難しい方法ですが, 最も良い方法でもありますし, ソフトウェアが + 複数の計算機で動くようにできます. + +

2)プロクシを使う. アプリケーションが, 例えば socks5 + をサポートしているか, (cvsup のように) ``passive'' オプションを持っていると + この方法が使えます. ``passive'' とは相手側のほうから接続を求めてくることを + 避けるためにあるオプションです. + +

3)''alias addr''を使ってなんでもかんでも内部の計算機に向けて + 流してしまう. これはちょっと無理矢理な解決法です. + どれにも当てはまらない! どうしたらいいの?

これまでの全ての質問に当てはまらない場合, 設定ファイル, コマンドの出力 (接続前と接続後) を含む, あなたの持っている全ての情報を メーリングリストや ニュースグループへ 送ってください. 誰かがあなたを正しい方向へ導いてくれるでしょう. /dev/ed0 デバイスを作成することができません.

Berkeley UNIX におけるネットワークの構成においては, ネットワーク のインタフェースは kernel のコードからのみ直接あつかうことが できます. より詳しく知りたい場合は, /etc/rc.network というファイルや, このファイルの中に書いてあるさまざまなプログラム についてのマニュアルページを見てください. それでもまだ分からない場合には, 他の BSD 系の OS のネットワーク管理についての本を読むべきでしょう. ごく少しの例外をのぞいては, FreeBSD のネットワーク管理は SunOS 4.0 や Ultrix と基本的に同じです. Ethernet アドレスのエイリアスはどのようにして設定できますか?

のコマンドラインに `` ifconfig ed0 alias 204.141.95.2 netmask 0xffffffff 3C503 で他のネットワークの port を使用するにはどのようにすればよいですか?

他の port を使用したい場合には, のコマンドラインにパラメータを 追加しなければなりません. default は ``. の using the ifconfig_* の変数を使って指定されるはずです. FreeBSD との間で NFS がうまくできません.

PC 用のネットワークカードによっては NFS のようなネットワークを 酷使するアプリケーションにおいて問題を起こすものがあります.

この点に関しては を見てください. 何故 Linux のディスクを NFS マウントできないのでしょうか?

Linux の NFS のコードによっては許可されたportからの リクエストからしか受けつけないものがあります. 以下を試してみてください. mount -o -P linuxbox:/blah /mnt 何故 Sun のディスクを NFS マウントできないのでしょうか?

SunOS 4.X が走っている Sun Workstation は許可された port からの mount のリクエストしか受けつけません. 以下を試してみてください. mount -o -P sunbox:/blah /mnt PPP で NeXTStep に接続する際に問題があるのですが.

の中で次の変数を NO にして, TCP extension を無効にしてみてください. tcp_extensions=NO

Xylogic の Annex も同様の問題がありますので, Annex 経由で PPP をおこなう 場合にもこの変更を行ってください. IP multicast を有効にするには?

FreeBSD 2.0 においては multicast は標準で完全に対応しています. 現在使用している計算機を multicast の router として使用するには, MBONE用のツールは ports 内の専用のカテゴリー mbone にあります. vic や vat といった会議用のツールを探している場合にはこの場所を 見てください.

詳しい情報は にあります. DEC の PCI チップセットを用いている network カードにはどのような物がありますか?

による一覧に, よりmodernな物を追加したものを 以下に示します. Vendor Model ---------------------------------------------- ASUS PCI-L101-TB Accton ENI1203 Cogent EM960PCI Compex ENET32-PCI D-Link DE-530 Dayna DP1203, DP2100 DEC DE435 Danpex EN-9400P3 JCIS Condor JC1260 Linksys EtherPCI Mylex LNP101 SMC EtherPower 10/100 (Model 9332) SMC EtherPower (Model 8432) TopWare TE-3500P Zynx ZX342 何故自分のサイトのホストに対して FQDN を使用する必要があるのですか?

実際にはそのホストは別のドメインにあるのではないですか. たとえば, foo.bar.edu というドメインの中から, bar.edu ドメインにある ``mumble'' というホストを指定したい場合には, ``mumble'' だけでは 駄目で, ``mumble.bar.edu'' という fully-qualified domain name で 指定しなければなりません.

伝統的に, BSD の BIND の resolver ではこのような事は可能でしたが, FreeBSD に入っている の現在のバージョンでは, 自分以外のドメインに対して FQDN でない別名を自動的につけてくれるような事はありません. したがって mumble というホスト名は mumble.foo.bar.edu という名前か, もしくは root ドメイン内にある場合にしか適用されません.

これは, mumble.bar.edu と mumble.edu ということなったドメイン名に対してホスト名のサーチがおこなわれていた 以前の振る舞いとは異なったものです. このような事が悪い例もしくは セキュリティホールとみなされる理由については RFC 1535 を見てください.

の中で domain foo.bar.edu

と書いてある行を search foo.bar.edu bar.edu

のように書きかえることで, 上のような事ができます. しかし, RFC 1535 にあるように, search order が ``ローカルな管理と パブリックな管理の境界'' をまたがないようにしてください. すべてのネットワークの操作に対して ``Permission denied'' というメッセージが表示されるのですが.

もしfirewallの設定を間違えた場合にネットワークの操作が再びできる ようにするには, root で login して次のコマンドを実行してください. ipfw add 65534 allow all from any to any

/etc/rc.confに"firewall_type='open'"を追加してもよい でしょう.

FreeBSD の firewall の設定についての情報は にあります. IPFWのオーバーヘッドはどのくらいでしょうか?

この答えはあなたのrule setとprocessorのスピードによって ほとんど決まります. Ethernetに対して少しのrule setだけを使っ ているほどんどの場合には, その影響は無視できる程度です. 実 際の測定値を見ないと満足できない方々のために, 実際の測定結 果をお見せしましょう.

次の測定は486-66上で2.2.5-STABLEを使用しておこなわれました. IPFWは変更が加えられて, それぞれ1000ずつのruleが入っている2つのrule setでテストが おこなわれました. ひとつ目のsetは最悪のケースを見るために ipfw add deny tcp from any to any 55555 というruleを繰り返したものです.

このsetを用いますと, (port番号によって) packetが全てのruleにマッチ しない事が最終的に決まるまでに, IPFWのpacketをチェックするルーチン のほとんど全てが実行されますので, 最悪のケースとなります. この ruleを999個繰り返した後にallow ip from any to anyが 書かれています.

2つ目のsetは, なるべく早くチェックが終了するように書かれたものです: ipfw add deny ip from 1.2.3.4 to 1.2.3.4

このruleではsource側のIPアドレスがマッチしないのでチェックは すぐに終了します. 上のsetとおなじように, 1000個目のruleは allow ip from any to anyです.

1つ目のsetでは, packetあたりのoverheadはだいたい2.703ms/packet, 言いかえると1つのruleあたり2.7マイクロ秒です. したがってこのruleに おけるpacketを処理する時間の理論的な限界は1秒あたり約370 packetです. 10MbpsのEthernetで1500 byte以下のpacketサイズを仮定すると, 55.5%の バンド幅までしか使えない事になります.

2つ目のsetでは, それぞれのpacketはだいたい1.172msで処理されて いますので1つのruleあたり1.2マイクロ秒となります. packetの 処理時間の理論的な限界はだいたい1秒あたり853 packetとなりますので 10Mbps Ethernetのバンド幅を使い切ることができます.

このテストでのruleの数は多過ぎますので, 実際に使用している際の 結果を反映している訳ではありません. これらは上に示した数値を出す ためだけに用いられたものです. 実際に効率の良いrule setを作るために は, 次のような事を考えておけばよいでしょう. `確定している' ruleは, TCPのtrafficの多数を処理するために 前の方に持ってきてください. そしてこのruleの前にはallow tcp という記述をしないでください. 良く使われるruleを, あまり良く使われないruleよりも 前の方に(もちろんfirewallの許可の設定を変えない範囲で) 持ってきてください. ipfw -a lのようにしてpacket数の統計を取ることによって どのruleが最もよく使われているかが分かります. diff --git a/ja/FAQ/preface.sgml b/ja/FAQ/preface.sgml index 35e0420589..c99777e18b 100644 --- a/ja/FAQ/preface.sgml +++ b/ja/FAQ/preface.sgml @@ -1,525 +1,556 @@ - + - + まえがき -

訳: &a.kuriyama;, &a.hanai;, &a.nakai;. +

訳: &a.kuriyama;, &a.hanai;, &a.nakai;, + &a.motoyuki;. 5 November 1997.

FreeBSD 2.X FAQ へようこそ! この FAQ の目的は?

Usenet の FAQ がそうであるように, この文書も FreeBSD オペレーティングシステムに関して頻繁に尋ねられる質問を 網羅することを目的としています (もちろんそれに対する答えも!). FAQ は本来バンド幅を減らし, 同じ質問が何度も繰り返されるのを 避けるために作られたものですが, 最近は有用な情報源と 見なされるようになってきました.

この FAQ をできる限り有用なものにしようと, あらゆる努力が はらわれています. もし何かしらの改善案が浮かんだら, ぜひ - まで + まで メールを送ってください. FreeBSD って何?

FreeBSD 2.X はカリフォルニア大学バークレイ校が i386 系の プラットフォーム向けにリリースした 4.4BSD-lite をもとにした UN*X ライクなオペレーティングシステムです. 間接的には同じ バークレイ校の Net/2 を William Jolitz が i386 系に移植した 386BSD も基にしていますが, 386BSD のコードはほとんど残って いません. FreeBSD についての詳細と, 何ができるかについては を参照してください.

FreeBSD は企業やインターネットサービスプロバイダ, 研究者, コンピュータ専門家, 学生, 家庭のユーザなどにより, 業務や教育, 娯楽に用いられています. これらに関しては を参照してください.

FreeBSD に関するより詳しい情報は を参照してください. FreeBSD が目指しているもの

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

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

(訳注1) GPL では, 「ソースコードを実際に受け取るか, あるいは, 希望しさえすればそれを入手することが可能であること」を求めています. どうして FreeBSD と呼ばれているのですか?

無料 (free) で使うことができる (商利用も含む). オペレーティングシステムの完全なソースコードが自由に (freely) 手に入り, 商利用・非商利用にかかわらず, 最低限の制限で他の仕事への利用, 配布, 導入が可能. 改良やバグフィックスがある場合, 誰でも (free) その コードを提出でき, ソースツリーに加えることができます (いくつかの簡単な条件には従ってもらいます).

母国語が英語でない読者のために, ここでは ``free'' という単語が 二通りに用いられていることを指摘しておくとわかりやすいかも しれません. ひとつは「無料である」ということ, もうひとつは 「自分のやりたいようにできる」ということです. FreeBSD のコードで FreeBSD の最新バージョンは? -

- が最新の stable バージョンで, 1997 年 10 月にリリース +

+ が最新の stable バージョンで, 1998 年 3 月にリリース されました. また, これは最新の release バージョンでもあります.

簡単に言ってしまうと, -stable は 最新のリリースのすばらしい新機能の数々よりも, 安定性と変更回数の 少なさを好む ISP や他の企業のユーザをターゲットにしています. 今のところ, これらのバージョンは同一のものですが, この状況も -currentブランチが一般のリリースとして十分に洗練されるまでの ことでしょう.

これは 3.0-current snapshot がビジネスサービス向けとしては不安定である, と言っているわけではなく, 3.0 特有の機能 (新しいコンパイラ技術や 高速なネットワークコードなど) を必要とする多くの人たちは, これを 使う決定をし, 良い成果を収めています. 私たちとしては, このブランチでさらに実績を積むまでは, 3.0 が自信を持っておすすめめできるものあるということを 「保証」したくないだけなのです. FreeBSD-currentって何?

は オペレーティングシステムのの開発バージョンで, やがて 3.0-RELEASE となります. よってこれは, そこに携わっている開発者や, どんな障害をも乗り越えていけるタフな愛好家たちにとってのみ 興味深いものです. -current の使用に際しての詳細は の を参照してください.

オペレーティングシステムに馴染みがない場合や一時的な問題か 本物の問題かを見極める能力がない場合は, FreeBSD-current を 使うべきではありません. このブランチは時々急激に拡張されたり, ビルドできない状態になることもちょっちゅうあります. FreeBSD-current を使う人は, 問題を分析して「小さな欠陥」では なく間違いであると思われるものだけを報告できるものと想定され ています. 「make world したら group 関係でエラーがでました」 のような質問は -current メーリングリストでは軽蔑の眼差しで あしらわれることもあります.

時たま, -current の開発コードから が作成され, snapshot の中からは 配布 CD-ROM が作成されることもあります. それぞれの snapshot には以下のような目的があります: インストールプログラムの最新版のテスト. 試してみたいけれど, 基礎的な所から毎日変わるような ものを追いかける時間もバンド幅も無い, という人にも -current を使えるようにする. また, そのような人たち のシステム移行のための手っ取り早い方法を提供する. あとでとんでもないことをしてしまった時のために, 問題となるコードの特定の参照基準点を保存しておく. (通常は CVS がこういうハプニングのような恐ろしい事態を防止して いるんですけどね :) テストが必要な新しい機能を, できる限り多くの 隠れテスターに試してもらう.

どんな目的であれ, snapshot が「製品レベルの品質」であるとの考えに 基づく要求は行わないでください. 安定性やテスト十分性にこだわる人は 完全なリリースから離れてはいけません.

3.0-current および 2.2-stable ブランチ両方の snapshot は, 平均的に一日に一度生成されており, から直接入手することが できます. FreeBSD-stable のコンセプトって何?

FreeBSD 2.0.5 がリリースされた後, 私たちは FreeBSD の開発を 2 系統に分割することにしました. 一つは というブランチで, バグの修正はしっかりテストされ, 機能の強化は少しずつしか行われません (急な変更や実験的機能を望まない, インターネットサービスプロバイダや営利企業向け). もう一方のブランチは で, 2.0 がリリースされて以来 3.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年3月) | | | [2.2-stable] - *BRANCH* 2.2.1 -> 2.2.2-RELEASE -> 2.2.5-RELEASE -> ... - | (1997年3月) (1997年10月) + *BRANCH* 2.2.1 -> 2.2.2-RELEASE -> 2.2.5 -> 2.2.6 -> 2.2.7 + | (1997年3月) (97年10月) (98年4月) (98年7月) | | 3.0-SNAPs (1997年第一四半期開始) | | - 3.0.0-RELEASE (1998年第一四半期) + 3.0.0-RELEASE (1998年10月) | \|/ + [今後の 3.x リリース群]

以前の 2.1-stable ブランチが 2.2.0 がリリースされたことによって 終了し, 「安定版ブランチ」がいわゆる 2.2-stable として新しくなったのに対して, -current ブランチは 3.0 とその先へ向けてゆっくりと進化を続けています. 3.0-current は, 実際に 3.0 がリリースされるまで, 活発な開発の 舞台として続いていくでしょう. その時点で 3.0 は別のブランチとなり, 3.1-current が次の「最新ブランチ」となる予定です. 2.1-stable ブランチが 2.1.7.1 で終わったのはなぜですか?

三つのブランチの開発を続けたいのはやまやまなのですが, 残念ながら このような状況を効率的に扱えるバージョン管理ツールがまだ 存在しないのです. 現在我々が使っているツールで, 複数のブランチを数ヶ月以上の 長期間に渡って並行してバージョン管理し続けることは, まさに 悪夢のような作業なのです. 一方で 2.1-stable ブランチは一年以上も続いていますから, FreeBSD の開発者たちの作業の大変さを考えると, このまま継続することは 深刻な問題に陥りかねません. おそらくみんなが望むものを提供してくれるような方法がそのうち 考え出されるでしょうし, また, 我々もそのような方法について 検討中なのですが, 現状では古い -stable ブランチを (2.1.7 の後の最終リリース) で終了し, 2.2.2 からを新たな -stable とすることが 最善の手段であると考えています. FreeBSD のリリースはいつ作られるのですか?

原則的には, FreeBSD コアチームは新しい機能やバグフィックスが 充分集まり, リリースの安定性を損なうことが無いようにさまざま な変更が十分に安定しているという条件を満たしている場合にのみ, 新しいバージョンの FreeBSD をリリースします. たとえこの用心深さが新しい機能が使えるようになることを 待ち望んでいるユーザを欲求不満にさせるとしても, 多くのユーザは このことを FreeBSD の最も良い所の一つだと考えています.

平均的には, だいたい 6 ヶ月ごとにリリースが作成されます.

もう少し刺激が欲しい (あるいは待ち遠しい) 方々向けに SNAP というものが存在し, これは特にリリースに近付いてきた数ヶ月 ぐらいの期間により頻繁に公開されます. FreeBSD は PC 用だけしかないの? -

現時点ではそうですが, DEC Alpha アーキテクチャへの移植 +

現時点ではそうですが, + と アーキテクチャへの移植 が計画されています. 異なるアーキテクチャのマシンを 持っていて, ゆっくり待てないという場合には次の URL を 参照してください. または . 誰が FreeBSD の責任者?

プロジェクトの全体的な方向性や, 誰にソースツリーにコードの 書き込み権限を与えるか, などといった FreeBSD プロジェクトに関する 重要な意思決定は 17 名からなる によってなされます. ソースツリーを直接変更できる人はもっと多く, 80 名以上の がいます.

しかし, 通常の変更ではないものはで先行して議論されますが, この議論への参加については一切の制限はありません. どこから FreeBSD を入手できますか?

FreeBSD のすべての主要なリリースは anonymous FTP 経由で から入手できます: - 現在の 2.2-stable リリース, 2.2.5R は - にあります. + 現在の 2.2-stable リリース, 2.2.6R は + にあります. 現在の 3.0-current, 3.0-SNAP は にあります. 次の 2.2 ブランチのリリースへと向かっている - RELENG_2_2 ブランチ (2.2.5 -> 2.2.x) に基づき一日に一回, + RELENG_2_2 ブランチ (2.2.6 -> 2.2.x) に基づき一日に一回, リリースが作成されます. 不慮の手違いによるまれな例外もありますが, RELENG_2_2 ブランチは 注意深く保守されています (実験的な変更はなく, -current でテスト済みの 変更だけが入ります). リリースも ブランチ用に一日に一回 作成されており, これらは純粋に最先端の開発者およびテスターのために 提供されています.

また, FreeBSD は CD-ROM でも入手でき, 次のところでオーダできます.

Walnut Creek CDROM 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: WWW:

オーストラリアでは, 次のところに問い合わせてください.

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 の IRC (Internet Relay Chat) について何か情報はありますか? -

FreeBSD の IRC に関して二つのチャンネルがあります. +

あります. FreeBSD チャットチャンネルのもっとも主要な IRC + ネットワークホストは以下の通りです: + + + EFNET の Channel #FreeBSD が恐らく最も + 人気があります. irc.chat.org のサーバー上にあります. + + DALNET の Channel #FreeBSD はアメリカでは + irc.dal.net, ヨーロッパでは irc.eu.dal.net + にあります. - - メインのチャンネルは, EFNET 上の #FreeBSD です. - 正式な IRC サーバが使用できます. + UNDERNET の Channel #FreeBSD はアメリカでは + us.undernet.org, ヨーロッパでは eu.undernet.org + にあります. - IRC クライアントで + 最後に, BSDNET の #FreeBSD に入ることもできます. + BSD 専用の小さなチャットネットワークで irc.FreeBSD.org + にあります. + + + +

それぞれのチャンネルは別個のもので互いに接続されていません. + チャットのスタイルも違っているので自分のチャットのスタイルにあった + ものを見つけるために一つ一つ試すのもいいでしょう. FreeBSD の本

Greg Lehey の本 ``Installing and Running FreeBSD'' が - Walnut Creek から出版されており 2.2.5 の CD-ROM が付属しています. + Walnut Creek から出版されており 2.2.6 の CD-ROM が付属しています. また, より詳しい本が ``The Complete FreeBSD'' というタイトルで - 出ており, 印刷されたマニュアルページと 2.2.5 の CD-ROM + 出ており, 印刷されたマニュアルページと 2.2.6 の CD-ROM が付属しています. 現在大抵の大型書店で入手できるはずです.

FreeBSD ドキュメンテーションプロジェクトがありますので, doc メーリングリストにコンタクトしてみてください (さらに参加すればもっとよいでしょう). - . + . このリストは FreeBSD のドキュメントに関して議論するためのものです. FreeBSD に関する質問に対しては questions というメーリングリストがあります: - . + .

FreeBSD の「ハンドブック」もあり, から読むことができます. 現在作業中ですので不完全な部分もあることに注意してください. +

FreeBSD のガイド本の決定版は Greg Lehey が書いた + ``The Complete FreeBSD'' で Walnut Creek CDROM Books から出版されて + います. 現在は第二版になっていて, インストール, システム管理ガイド, + プログラム設定のヘルプ, マニュアルページまでの内容が 1,750 ページに + わたって書かれています. + この本は (そして現在の FreeBSD リリースは) can be ordered from + , + , または + 最寄りの書店で注文することができます. + ISBN コードは 1-57176-227-2 です. +

しかし, FreeBSD 2.2.X は Berkeley 4.4BSD-Lite2 ベースなので, ほとんどの 4.4BSD のマニュアルが FreeBSD 2.2.X にも応用できます. 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 + : 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 + : 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 + : 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 + : 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 + : 1-56592-079-1

WWW 経由で以下の URL から, これらの詳細な説明を読むことができます. + name="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 + 0-201-54979-4

システム管理について参考になる本は次のものです.

Evi Nemeth, Garth Snyder, Scott Seebass & Trent R. Hein, ``Unix System Administration Handbook'', Prentice-Hall, 1995 - ISBN: 0-13-151051-7 + : 0-13-151051-7

この本は TCP/IP だけでなく DNS, NFS, SLIP/PPP, sendmail, INN/NNTP, 印刷などの基礎を扱っています. 高価ですが (およそ US$45-$55), 買う価値はあります. また, 色々なツールのソースコードが入った CD-ROM が付属しています. - しかし, それらのほとんどは FreeBSD 2.2.5R CD-ROM に収録されています + しかし, それらのほとんどは FreeBSD 2.2.6R CD-ROM に収録されています (さらに FreeBSD CD-ROM の収録物の方がより新しい場合があります). Problem Report (障害報告) データベースにアクセスする方法は?

ユーザ変更要求のすべてが公開されている Problem Report データベースは 障害報告の と の web ベースのインタフェースを通して, 問い合わせ (または提出) をおこなうことができます. また, send-pr(1) コマンドを使用して, 電子メール経由で障害報告や変更要求を提出することもできます. その他の情報

以下のニュースグループには FreeBSD ユーザに直接関係のある 議論が行われてます. (moderated)

Web 上のリソース: .

FreeBSD handbook には本当に完璧な の一覧があり, 買うべき本をさがしている方は読む価値があります. diff --git a/ja/FAQ/troubleshoot.sgml b/ja/FAQ/troubleshoot.sgml index 284c8e12ec..de89bc8617 100644 --- a/ja/FAQ/troubleshoot.sgml +++ b/ja/FAQ/troubleshoot.sgml @@ -1,423 +1,454 @@ - + - + トラブルシューティング

訳: &a.yoshiaki;.10 November 1997. ハードディスクに不良ブロックがあります!

SCSI ディスクの場合は自動的に再マップする機能があるはずです. しかし, 理解し難い理由から多くのドライブがこの機能が無効化 されて出荷されています...

これを有効化するには, 最初のデバイスのモードページを変更する 必要があります. これは次のコマンドを実行することで, FreeBSD 上でおこなうことができます (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

他の種類のディスクでは, オペレーティングシステムからサポート されているかによります. 残念ながら, この目的のために FreeBSD が提供する ``bad144'' コマンドはかなり手を入れる必要があります...

IDE ディスクは, おそらく不良ブロックの再マップを内蔵していると 思います; ディスクの説明書がある場合は, この機能が無効になって いるかを確認するとよいでしょう. しかし, ESDI, RLL, ST-506 ディスクは, 通常これをおこないません. +

再マップが可能になっていてで不良ブロックを見つけたのであれば, + ドライブを交換することを考えましょう. 不良ブロックの状態は時間と + ともに悪い方向にしか行きません. + 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 に合わせる必要があるでしょう.

742a EISA カードには, の節で説明している 「16 MB を越える」ことによる問題はありません. これは Vesa-Local Buslogic SCSI カードで発生する問題です. HP Netserver 上のオンボード SCSI コントローラが認識されません.

基本的にこれは既知の問題です. HP Netserver マシンの EISA オンボード SCSI コントローラは EISA のスロット番号 11 を占有しますが, 「本当の」EISA スロットはすべてそれよりも 前のアドレスに配置されているのです. 残念ながら, 10 番以上の EISA スロットは PCI に割り当てられたアドレス空間 と衝突し, FreeBSD の自動コンフィグレーションは, 現状ではうまくこの状況を 処理できていないのです.

ですから現時点での最良の方法は, カーネルオプションの に記述されているようにしてカーネルをコンパイルし, 構築してください.

もちろん, これはこのようなマシンにインストールする際に 卵が先か鶏が先か」といった問題を生み出すことになります. この問題を回避するために, ユーザコンフィグ (UserConfig) の中には特別な仕組みが組み込まれています. このとき ``visual'' インタフェースは使用せず, コマンドラインインタフェースを使用してください. 単純に eisa 12 quit

とプロンプト上から打ち込み, 後は普通にインストールをおこなってください. とにかくカスタムカーネルのコンパイルとインストールをおこなうことを おすすめしますが, も現時点ではこの値の変更を認識するようになっています.

うまくいけば, 将来のバージョンではこの問題が解決していることでしょう.

をご覧ください. この CMD640 IDE コントローラはどこかおかしいようです.

それは壊れているのです. 両方のチャンネルを同時に制御できないのです.

現在ではこのチップを使っているシステムでは自動的に検出して うまく動かすためのしくみが使えるようになっています. くわしくは マニュアルページのディスクドライバ (man 4 wd) を参照してください.

CMD640 IDE コントローラを使っているシステムで FreeBSD 2.2.1 あるいは 2.2.2 を使っている場合でセカンダリのチャネルを 使いたいのであれば ``

たぶん IRQ の衝突が原因でしょう (二つのボードが同じ IRQ を使用しているなど). FreeBSD 2.0.5R 以前では, これに関しては 寛大で IRQ の衝突があってもネットワークドライバは機能して いました. しかし 2.0.5R 以降は IRQ の衝突はもはや寛大では ありません. -c オプションをつけてブートして ed0/de0/... の エントリをボードの設定に合わせてください.

ネットワークカードの BNC コネクタ (訳注: 10BASE-2 タイプ のインターフェース) を使っている場合, デバイスのタイムアウト はターミネーションの不良によっても起きます. これをチェックするにはケーブルを外してターミネータを直接 NIC に接続します. そしてエラーメッセージが消えるかどうか 確認します. +

NE2000 コンパチブルカードのなかには UTP ポートのリンクが + なかったりケーブルが接続されていない場合にこのエラーを出す + ものがあります. + CDROM をマウントしようとすると ``Incorrect super block'' と言われます.

にマウントしたいデバイスのタイプを指定する必要 があります. デフォルトでは はファイルシステムを `` オプションをつけて明示する必要があります. これはもちろん CDROM が ISO 9660 ファイルシステムである場合です. ほとんどの CDROM はこの形式です. 1.1R の FreeBSD では (訳注: 現行の 2.1.5R, 2.2R でも同様です) 自動的に Rock Ridge 拡張 (長いファイル名への対応) をうまく解釈します.

CDROM のデバイス ``/dev/cd0c'' を /mnt にマウントしたい場合の例では, 次のようにします: mount -t cd9660 /dev/cd0c /mnt

デバイスの名前はインタフェースによっては別の名前になっている かもしれないので注意してください (``/dev/cd0c'' は この場合の例です). オプション `` mount_cd9660 /dev/cd0c /mnt CDROM をマウントしようとすると ``Device not configured'' と言われます.

これは 一般的に CDROM ドライブの中に CDROM が入っていないか, ドライブがバス上に見えないことを意味します. ドライブに CDROM を入れるか, IDE (ATAPI) であれば master/slave の状態をチェック してください. CDROM ドライブに CDROM を入れてから認識するまで 数秒かかりますので少し待ってみてください.

SCSI CDROM ではバスリセットへの応答時間が遅いために失敗する ことがあるかもしれません. SCSI CDROM を持っている場合は カーネルコンフィグレーションファイルに以下の行を加えて 再コンパイルして試してみてください. options "SCSI_DELAY=15"

(訳注: 現在の GENERIC カーネルでは上の設定はデフォルトに なっています. 問題のある場合は SCSI_DELAY の数値を増やして みてください.) 私のプリンタはとてつもなく遅いのです. どうしたらよいのでしょう?

パラレルインタフェースで, 問題はとんでもなく遅いだけであるなら, プリンタボートを ``polled'' モードに設定してみてください: lptcontrol -p

HP の新しいプリンタのいくつかは割り込みモードでは 使えないようです. (完全にわかったわけではありませんが) タイミングの問題のように思われます. 私のプログラムは時々 ``Signal 11'' のエラーで止まってしまいます.

これはハードウェア (メモリ, マザーボードなど) の不具合いが 原因です. PC でメモリテストプログラムを動かしてみてください. ただしメモリが正常に動作していると報告されたとしても, ぎりぎりで メモリテストにパスしたメモリは, 処理の内容 (例えば kernel のコンパイルや特にシステムの負荷が高いような場合には, Adaptec 1542 などの SCSI コントローラのバスマスタ DMA など) によっては問題が起きる可能性は大いにあります.

SIG11 FAQ (後で URLを示します) では遅いメモリが一般的に問題 を起こしがちであることを指摘しています. BIOS セットアップで ウエイトステート数を増やすかメモリを速いものに交換してください.

私の場合はキャッシュ RAM やオンボードキャッシュコントローラ の問題でした. このような問題ではないか確認するために BIOS セットアップでオンボード (セカンダリ) キャッシュを無効にして みてください.

以下のところには広い範囲の FAQ があります. ブートの時に画面が真っ暗になって同期も取れません.

これは ATI Mach 64 ビデオカードの既知の問題です. この問題はカードがアドレス ドライバのバグ (仕様?) のため4番目のシリアルポートがなくても, 通常この アドレスを使う sio3 (4 番目のポートにあたります) を無効にしても, ドライバはこのアドレスをさわります.

バグが修正されるまでは, 次のようにして対処してください. ブートプロンプトが出たら 問題はありません. exit とタイプしてブートを続行します.

もしシリアルポートを有効にしたいのであれば以下の変更をおこなって 新しいカーネルを作る必要があります. /usr/src/sys/i386/isa/sio.c の中で1ヵ所ある この対処をおこなった後でもまだ X ウィンドウシステムはうまく 動かないかもしれません. いくつかの新しい ATI Mach 64 ビデオカード (特に ATI Mach Xpression) は現在のバージョンの を見てベータリリースへのリンクを追ってください. 以下のファイルを持ってきましょう.

AccelCards, BetaReport, Cards, Devices, FILES, README.ati, README.FreeBSD, README.Mach64, RELNOTES, VGADriver.Doc, X312BMa64.tgz

古いファイルをこの新しいバージョンのファイルに置き換え, をもう一度実行します. 128MB の RAM があるのですが, 64MB しか認識しません.

FreeBSD がメモリのサイズを BIOS から取得する方法の制限により, KB 単位で 16 ビット分までしか検出できません (すなわち最大 65535Kb=64MB です)(これより少ない場合もあります. ある BIOS の場合はメモリサイズが 16MB に制限されます). 64MB 以上のメモリを積んでいる場合, FreeBSD はそれを検出しようとし ます. しかしその試みは失敗するかもしれません.

この問題を回避するには, 以下に示すカーネルオプションを 使用する必要があります. 完全なメモリ情報を BIOS から取得する 方法もありますが, ブートブロックに空きが無いため実装できません. ブートブロックの問題が解決されれば, いつか拡張 BIOS 機能を使用して完全なメモリ情報を取得できるようになるでしょう. とりあえず現在は, カーネルオプションを使ってください. options "MAXMEM=<n>"

FreeBSD 2.0 が ``kmem_map too small!'' と言ってパニックします.

このパニックは, ネットワークバッファ (特に mbuf クラスタ) の仮想メモリが無くなったことを示します. 以下のオプションを カーネルコンフィグファイルに追加して mbuf クラスタに使用できる 仮想メモリの量を増やしてください.

options "NMBCLUSTERS=<n>"

<n> には, 同時に使用したい TCP コネクションの数に応じて 512 から 4096 までの数値を指定できます. とりあえず 2048 を 試してみるのを勧めます. これでパニックは完全の予防できるはずです. mbuf クラスタの割り当て／使用状況については, で知ることができます. - + name="netstat -m"> で知ることができます. NMBCLUSTERS の + デフォルト値は + 新しいカーネルでリブートすると ``CMAP busy panic'' となってパニックを起こしてしまいます.

ファイル /var/db/kvm_*.db において範囲外のデータを 検出するためのロジックは失敗することがあり, こうした矛盾のある ファイルを使用することでパニックを引き起こすことがあります.

これが起こったなら, シングルユーザでリブートした後に, 以下のコマンドを実行してください. rm /var/db/kvm_*.db ahc0: brkadrint, Illegal Host Access at seqaddr 0x0 というエラーが出ます

これは Ultrastor SCSI Host Adapter と衝突しています.

ブート時に kernel configuration メニューに入り, 問題を起こしている を disable にしましょう. sendmailが ``mail loops back to myself'' というメッセージを出すのですが.

この事は, sendmail FAQ に次のように書いてあります. * "Local configuration error" というメッセージが出ます. 例えば: 553 relay.domain.net config error: mail loops back to myself 554 ... 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 release とは一緒には保守されて いません. しかし次のネットニュースに定期的に投稿されてます. , , , , . また, メール経由でコピーを入手する場合は 宛まで本文に "send usenet/news.answers/mail/sendmail-faq" と書いて送ります. + + リモートマシン上のフルスクリーンアプリケーションがうまく動かない + +

リモートマシンのターミナルタイプが FreeBSD のコンソールで + つかわれている cons25 以外のものです. +

この問題を解決する方法はいろいろあります: + + リモートマシンに login した後, shell 変数の TERM に + ansi か sco のいずれかを設定します. + ローカル側で のような VT100 エミュレータを使用します. + screen は一つのターミナルの中で複数のセッションを + 並列動作させることができますし, 本来の機能も優れています. + リモートマシンのターミナルデータベースに cons25 + のエントリをインストールします. + Xを起動してリモートマシンに xterm から login + します. (訳注: 日本語が必要な場合は kterm 等を + 利用します) + diff --git a/ja_JP.eucJP/FAQ/network.sgml b/ja_JP.eucJP/FAQ/network.sgml index 99d7f7839c..91300b1e26 100644 --- a/ja_JP.eucJP/FAQ/network.sgml +++ b/ja_JP.eucJP/FAQ/network.sgml @@ -1,1029 +1,1092 @@ - + - + ネットワーキング

訳: &a.arimura; &a.shou; &a.nishika; . 24 December 1997. ``diskless boot'' に関する情報はどこで得られますか?

``diskless boot'' というのは, FreeBSD がネットワーク上で起動し, 必要なファイルを自分のハードディスクではなくてサーバから読み込むものです. 詳細については を読んでください. FreeBSD をネットワークの router として使用することはできますか?

インターネット標準やこれまでのよい経験によって指摘されている通り, FreeBSD は標準ではパケットを forward するように設定されていません. しかし, の中で次の変数の値を gateway_enable=YES # Set to YES if this host will be a gateway

このオプションによって の変数 ほとんどの場合, router についての情報を同じネットワーク の他の計算機等に知らせるために, 経路制御のためのの process を走らせる必要があるでしょう. FreeBSD には BSD の標準経路制御デーモン である が付属していますが, より複雑な状況に対処するためには 注意してほしいのは, FreeBSD をこのようにして使用している場合でも, router に関するインターネット標準の必要条件を完全には満たしていない ということです. しかし, 普通に使用する場合にはほとんど問題ありません. Win95 の走っているマシンを, FreeBSD 経由でインターネットに接続できますか?

通常, この質問が出てくる状況は自宅に二台の PC があり, 一台では FreeBSD が, もう一台では Win95 が走っているような場合です. ここでやろうとしていう事はFreeBSDの走っている計算機をインターネット に接続し, Win95 の走っているマシンからは FreeBSD の走っているマシンを 経由して接続をおこなう事です. これは二つ前の質問の特別な場合に相当します.

FreeBSDをとして設定する方法については, 役に立つ文書があります.

や のような また, に関する節も参照してください. +

また, に関する節も参照してください. ISC からリリースされている BIND の最新版は compile できないんでしょうか?

BIND の配布物と FreeBSD とでは ``compat/include/sys/cdefs.h を削除してください. FreeBSD で SLIP と PPP は使えますか?

使えます. FreeBSD を用いて他のサイトに接続する場合には, , , そして のマニュアルページを見てください. は SLIP のサーバ専用で, は SLIP のクライアント専用です.

これらのプログラムの解説が, の以下のセクションにあります.

「シェルアカウント」を通じてのみインターネットへアクセス可能な場合, package みたいなものが欲しくなるかもしれませんね. これを使えば, ローカルマシンから直接 ftp や http のようなサービスに (限定的ではありますが) アクセスすることができます. FreeBSD は NAT か IP マスカレードをサポートしていますか?

ローカルなサブネット (一台以上のローカルマシン) を持っているが, インターネットプロバイダから 1 つしか IP アドレスの割り当てを 受けていない場合 (または IP アドレスを動的に割り当てられている場合でも), プログラムを使いたくなるかもしれませんね. も, 同様の機能を持っており, が使われます.

まず のマニュアルと, を読んでみましょう. 次に, set log Phase Chat Connect Carrier lcp ipcp ccp command

という命令を /etc/ppp/ppp.conf に加えて (default セクションの先頭に加えるのが一番良いでしょう) ログを有効にしてみてください. その際, に !ppp *.* /var/log/ppp.log

と書かれた行が含まれているか, また, /var/log/ppp.log が存在しているかどうか確かめておいてください. さて, これで 何が起きているのか突き止めるために, ログファイルからたくさんの 情報を得られるようになりました. ログに訳の分らない部分があっても 心配ご無用. あなたが助けを求めた誰かにとっては, その部分が 意味をなす場合があるのです.

訳注: ログの取得に syslog を使用するようになったのは 2.2.5 以降からです.

使用中の ppp のバージョンで "set log" 命令を解釈しない場合は, をダウンロードすべきです. FreeBSD の 2.1.5 以降でビルドできます. ppp が -auto モードでダイアルしてくれない

まず最初に, デフォルトルートが確立しているかどうかチェックして ください. を実行すると, 以下のような情報が表示されるはずです. 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 の中の が走っている可能性があります. FreeBSD 2.2.5 より前の バージョンに付属していた add 0 0 HISADDR

と書かれた行を以下のように修正してください. add 0 0 10.0.0.2

netstat -rn でデフォルトルートの情報が表示されない場合, もう一つ, (2.2.2 より前のリリースでは /etc/sysconfig と呼ばれていました) の中でデフォルトの ルータを誤って設定し, ppp.conf から delete ALL

の行をうっかり消してしまった可能性があります. この場合は, ハンドブックの の項を読み直してください. "No route to host" とはどういう意味ですか?

このエラーは通常, /etc/ppp/ppp.linkup に以下のような セクションが無い場合に起こります. MYADDR: delete ALL add 0 0 HISADDR

これは動的 IP アドレスを使用している場合, またはゲートウェイの アドレスを知らない場合にのみ必要な設定です. インタラクティブモード を使用している場合, delete ALL add 0 0 HISADDR

詳しい情報については, ハンドブックの の項を参照してください. 3 分ほど経つと接続が切れてしまう

ppp のタイムアウトは デフォルトでは 3 分です. これは set timeout NNN

という命令によって調整することができます. ppp.conf に入れることも, インタラクティブモードでプロンプトから入力することも できます. ソケットを用いる か を使用し, 訳注 pppctl は 2.2.5R からです.

詳しい情報は のマニュアルを参照してください. 負荷が高いと接続が切れてしまう

Link Quality Reporting (LQR) の設定を行っている場合, マシンと接続先の間で非常にたくさんの LQR パケットが失われている 可能性があります. 結果として ppp は回線の具合いが悪いと考え, 回線を切断するのです. 2.2.5 より前のバージョンの FreeBSD では LQR はデフォルトで有効になっています. 現在ではデフォルトの状態で 無効です. LQR は以下の命令で無効にすることができます. disable lqr 接続がランダムに切れてしまう

時々, ノイズの多い回線, あるいは待ち機能付きの回線では, モデムが (誤って) キャリアを失ったと思い込み, ハングアップしてしまう ことがあります.

大多数のモデムでは, 一時的なキャリアの喪失にどれだけ我慢するか 設定で決めることができます. 例えば USR Sportster では, S10 レジスタ の値を 10 倍した秒数がその値になります. この場合, モデムをもっと のんびり屋さんにするには, dial 行に次のような文字列を加えると 良いでしょう. set dial "...... ATS10=10 OK ......"

詳しくはお使いのモデムのマニュアルをご覧ください. Login OK! のメッセージが出た後, 何も起こらない

2.2.5 より前のリリースの FreeBSD では, はリンクが確立した後, 接続先が Line Control Protocol (LCP) を発信するのを待ちます. しかし, 多くの ISP ではネゴジェーションを 自分からは起こさず, クライアントが起こすのを待っています. set openmode active

でもまだ "magic is the same" というエラーが出る

時折, 接続直後のログに "magic is the same" というメッセージが あらわれることがあります. このメッセージがあらわれても何も起きない 場合もありますし, どちらかの側が接続を切ってしまう場合もあります. ppp の実装の多くはこの問題に対応できておらず, その場合にはちゃんと link が上がっている状態であっても, ppp が最終的にあきらめてしまい 接続を切るまで, 設定のリクエストが繰り返し送られ, 設定が行われた という通知が log ファイルに残ると思います.

これは通常, ディスクアクセスの遅いサーバマシンのシリアルポートで 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のnegotiationが続く.

これが, 片方のこれを回避する最も良い方法は, 片方を set openmode passive というコマンドでできます. このオプションは気を付けて使わないといけ ません. さらに set stopped N というコマンドを追加して, set openmode active N というコマンド(ここで, ppp が接続直後に固まってしまう

2.2.5 より前のバージョンの FreeBSD では, disable pred1 ppp の内部でシェルを起動しようとすると固まってしまう

このような場合は, 代わりに ヌルモデムケーブルを使用しているとき, ppp が終了しない

ヌルモデムケーブルを使用して直接接続している場合, enable lqr

こうすると, 接続先がネゴジェーションを行う場合, デフォルトで LQR の使用を受け入れるようになります. ppp を -auto モードで動かすと, 勝手にダイアルすることがある

原因を突き止めるためには, 以下の命令を使用してください. set log +tcp/ip

これで接続を通過する全てのトラヒックをログに残すことができるように なりました. 次に突然回線がつながったときのログのタイムスタンプを たどれば, 原因を突き止めることができるはずです.

原因がわかったら, 次に, このような状況ではダイヤルが起こらないように しましょう. 通常, この手の問題は, DNS で名前の解決をしようとしたために 起こります. DNS による名前の解決によって, 接続が行われるのを防止する には, 次のような手段を用います (これは 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 の場合は, 何が実際にホスト名を検索しようとしているのかを 突き止めるべきでしょう. 大抵の場合は, が犯人です. 設定ファイルで sendmail が DNS に問い合わせないようになっているか確認すべきです. 自分用の設定ファイルを作成するための詳しい方法は の節をご覧ください. または, define(`confDELIVERY_MODE', `d')dnl

この行を追加すると, sendmailはメールキューを処理する (通常sendmailは30分ごとにキューを処理するよう, ``-bd -q30m'' というオプションを付けて起動されます) までか, または (多分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

これは に最後にくることが要求されている "expect" という文字列がくるま でのすべてのものをログに記録させます.

接続速度はログにとりたいけれど, PAP や CHAP を使っている (その結果, dial スクリプト中の 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 を 待っています, 私のchatスクリプトでは`\'という文字をPPPが解釈して くれません

PPPは設定ファイルを読み込むときに, chatの各引数が解釈されるときには, ``\P''や``\T''のような 特別なescape sequence (man pageを見てください)を見付けるために もう1回parseを行います. このようにparseは2回繰り返されま すので, 正しい回数だけescapeを行わないといけません.

モデムにたとえば``\''のような文字を送りたい場合には, 次のように する必要があります: 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 は 実効 uid が 0 で動いていますので, オペレーティングシステム は ppp を終了させる前にディスクに core イメージを書き込みません. しかし ppp は実際にはセグメンテーション違反や他の core を吐く原因 となるようなシグナルによって $ tar xfz ppp-*.src.tar.gz $ cd ppp*/ppp $ echo STRIP= >>Makefile $ echo CFLAGS+=-g >>Makefile $ make clean all $ su # make install # chmod 555 /usr/sbin/ppp

これで debug 可能なバージョンの ppp がインストールされます. root で ppp を実行し, 全ての特権が無効になっているようにする必要 があるでしょう. ppp を実行する時には, current directory が make した directory であるようにしてください.

これで, ppp がセグメンテーション例外を受け取ったときには ppp.core という名前の core ファイルを吐くようになります. core が 吐かれたら次のようにしてください: $ su # gdb /usr/sbin/ppp ppp.core (gdb) bt ..... (gdb) f 0 ..... (gdb) i args ..... (gdb) l .....

質問する際には, これら全ての情報を提供して, 問題点の分析ができ るようにしてください.

gdb の使い方に慣れている場合には, 実際に dump の原因となった 理由やそのアドレス, 関連した変数の値なども調べる事ができるでしょう. auto modeでdialをするようなprocessがconnectしてくれない

これはを呼び出した時, tun intergaceのIP numberが socketのendpointに割り当てられます. kernelは最初に外へ出ていく packetを作り, それをtunデバイスへ書きます. 次にこの問題に対処する理論的な方法がいくつかあります. もし可能なら, 相手が同じIP numberを割り当てなおす事ができるのが最も良いです我々の側から対処できる最も簡単な方法は, tun interfaceのIP numberを固定する事ですが, かわりに外に出ていくpacketを変更して source IP numberをinterfaceのIPからnegotiateされたIPに書きかえる 事によっても対処できます. これが, (およびpppのもう1つの(最も確かな)方法は, 全てのbindされているsocketの IPを変更するようにsystem callを実装する事です. 3つ目の方法は, interfaceをIP number無しで立ち上げる事を許す ことです. 外に出ていくpacketは最初のSIOCAIFADDR ioctlが終わるまで は255.255.255.255というIP numberを与えられます. これによって socketを完全にbindすることができます. 現在のところ, これらの方法のどれもまだ実装されていません. + + 何故ほとんどのゲームが -alias スイッチ付きだと動かないんですか? + +

訳注:この問題は佐藤 淳一さん作の NAT パッチを使っても解決できます. + をご覧ください. + +

libalias を使っている時にゲームなどの類のものが動作しない理由は, + 外側にあるマシンが接続しようとしているか, 内側にあるマシンに (余計な) + UDP パケットを送信しようとしているからです. + 内側のマシンにこれらのパケットを送るべきかについて, + packet alias ソフトウェアは関知しません. + +

うまく動かすためには, 実行中のものが問題の発生している + ソフトウェアだけであるかを確認し, ゲートウェイの tun インタフェースに対して + tcpdump を実行するか, ゲートウェイ上で ppp tcp/ip logging を有効化 + (``set log +tcp/ip'') してください. + +

行儀の悪いソフトウェアを起動する際に, ゲートウェイマシンを + 通過するパケットを監視すべきです. 外側から何かパケットが戻ってきた時に, + そのパケットは破棄されるでしょう (それが問題なのです). + これらのパケットの port 番号に注意して, その行儀の悪いソフトウェアを + 停止してください. + これを数回繰り返して port 番号が常に同じであるかを確認してみてください. + 同じであった場合は, /etc/ppp/ppp.conf の適切なセクションに次の行を入れると, + そのソフトウェアは動作するようになるでしょう. + + + + alias port proto internalmachine:port port + + +

ここで ``proto'' は ``tcp'' か ``udp'' であり, + ``internalmachine'' はパケットを送りたいマシン, そして + ``port'' はパケットのディストネーションの port 番号です. + +

上記のコマンドを変更せずに他のマシン上でそのソフトウェアを + 使用できるようにはしたくないかもしれません. そして + 同時に二つの内部のマシン上でそのソフトウェアを実行することは + この質問の範囲を超えています. 結局, 外側の世界からは + 内部ネットワーク全体がただ一つのマシンとして見えるのです. + +

port 番号が常に同じとは限らない場合, さらに三つのオプションがあります. + +

1)libalias でサポートするようにし, 結果を送り付ける. + 特定の場合の例は /usr/src/lib/libalias/alias_*.c にあります + (alias_ftp.c は良いプロトタイプです). これには通常, 外向きの特定のパケットを読み, + 内部の計算機のある特定のポートへの接続を開始するような命令が + 外部の計算機対して送られていることを見分け, 後続のパケットがどこに行けば + いいのかが分かるように, エイリアステーブル中の ``route'' の部分を設定する, + という作業が含まれます. + +

これは最も難しい方法ですが, 最も良い方法でもありますし, ソフトウェアが + 複数の計算機で動くようにできます. + +

2)プロクシを使う. アプリケーションが, 例えば socks5 + をサポートしているか, (cvsup のように) ``passive'' オプションを持っていると + この方法が使えます. ``passive'' とは相手側のほうから接続を求めてくることを + 避けるためにあるオプションです. + +

3)''alias addr''を使ってなんでもかんでも内部の計算機に向けて + 流してしまう. これはちょっと無理矢理な解決法です. + どれにも当てはまらない! どうしたらいいの?

これまでの全ての質問に当てはまらない場合, 設定ファイル, コマンドの出力 (接続前と接続後) を含む, あなたの持っている全ての情報を メーリングリストや ニュースグループへ 送ってください. 誰かがあなたを正しい方向へ導いてくれるでしょう. /dev/ed0 デバイスを作成することができません.

Berkeley UNIX におけるネットワークの構成においては, ネットワーク のインタフェースは kernel のコードからのみ直接あつかうことが できます. より詳しく知りたい場合は, /etc/rc.network というファイルや, このファイルの中に書いてあるさまざまなプログラム についてのマニュアルページを見てください. それでもまだ分からない場合には, 他の BSD 系の OS のネットワーク管理についての本を読むべきでしょう. ごく少しの例外をのぞいては, FreeBSD のネットワーク管理は SunOS 4.0 や Ultrix と基本的に同じです. Ethernet アドレスのエイリアスはどのようにして設定できますか?

のコマンドラインに `` ifconfig ed0 alias 204.141.95.2 netmask 0xffffffff 3C503 で他のネットワークの port を使用するにはどのようにすればよいですか?

他の port を使用したい場合には, のコマンドラインにパラメータを 追加しなければなりません. default は ``. の using the ifconfig_* の変数を使って指定されるはずです. FreeBSD との間で NFS がうまくできません.

PC 用のネットワークカードによっては NFS のようなネットワークを 酷使するアプリケーションにおいて問題を起こすものがあります.

この点に関しては を見てください. 何故 Linux のディスクを NFS マウントできないのでしょうか?

Linux の NFS のコードによっては許可されたportからの リクエストからしか受けつけないものがあります. 以下を試してみてください. mount -o -P linuxbox:/blah /mnt 何故 Sun のディスクを NFS マウントできないのでしょうか?

SunOS 4.X が走っている Sun Workstation は許可された port からの mount のリクエストしか受けつけません. 以下を試してみてください. mount -o -P sunbox:/blah /mnt PPP で NeXTStep に接続する際に問題があるのですが.

の中で次の変数を NO にして, TCP extension を無効にしてみてください. tcp_extensions=NO

Xylogic の Annex も同様の問題がありますので, Annex 経由で PPP をおこなう 場合にもこの変更を行ってください. IP multicast を有効にするには?

FreeBSD 2.0 においては multicast は標準で完全に対応しています. 現在使用している計算機を multicast の router として使用するには, MBONE用のツールは ports 内の専用のカテゴリー mbone にあります. vic や vat といった会議用のツールを探している場合にはこの場所を 見てください.

詳しい情報は にあります. DEC の PCI チップセットを用いている network カードにはどのような物がありますか?

による一覧に, よりmodernな物を追加したものを 以下に示します. Vendor Model ---------------------------------------------- ASUS PCI-L101-TB Accton ENI1203 Cogent EM960PCI Compex ENET32-PCI D-Link DE-530 Dayna DP1203, DP2100 DEC DE435 Danpex EN-9400P3 JCIS Condor JC1260 Linksys EtherPCI Mylex LNP101 SMC EtherPower 10/100 (Model 9332) SMC EtherPower (Model 8432) TopWare TE-3500P Zynx ZX342 何故自分のサイトのホストに対して FQDN を使用する必要があるのですか?

実際にはそのホストは別のドメインにあるのではないですか. たとえば, foo.bar.edu というドメインの中から, bar.edu ドメインにある ``mumble'' というホストを指定したい場合には, ``mumble'' だけでは 駄目で, ``mumble.bar.edu'' という fully-qualified domain name で 指定しなければなりません.

伝統的に, BSD の BIND の resolver ではこのような事は可能でしたが, FreeBSD に入っている の現在のバージョンでは, 自分以外のドメインに対して FQDN でない別名を自動的につけてくれるような事はありません. したがって mumble というホスト名は mumble.foo.bar.edu という名前か, もしくは root ドメイン内にある場合にしか適用されません.

これは, mumble.bar.edu と mumble.edu ということなったドメイン名に対してホスト名のサーチがおこなわれていた 以前の振る舞いとは異なったものです. このような事が悪い例もしくは セキュリティホールとみなされる理由については RFC 1535 を見てください.

の中で domain foo.bar.edu

と書いてある行を search foo.bar.edu bar.edu

のように書きかえることで, 上のような事ができます. しかし, RFC 1535 にあるように, search order が ``ローカルな管理と パブリックな管理の境界'' をまたがないようにしてください. すべてのネットワークの操作に対して ``Permission denied'' というメッセージが表示されるのですが.

もしfirewallの設定を間違えた場合にネットワークの操作が再びできる ようにするには, root で login して次のコマンドを実行してください. ipfw add 65534 allow all from any to any

/etc/rc.confに"firewall_type='open'"を追加してもよい でしょう.

FreeBSD の firewall の設定についての情報は にあります. IPFWのオーバーヘッドはどのくらいでしょうか?

この答えはあなたのrule setとprocessorのスピードによって ほとんど決まります. Ethernetに対して少しのrule setだけを使っ ているほどんどの場合には, その影響は無視できる程度です. 実 際の測定値を見ないと満足できない方々のために, 実際の測定結 果をお見せしましょう.

次の測定は486-66上で2.2.5-STABLEを使用しておこなわれました. IPFWは変更が加えられて, それぞれ1000ずつのruleが入っている2つのrule setでテストが おこなわれました. ひとつ目のsetは最悪のケースを見るために ipfw add deny tcp from any to any 55555 というruleを繰り返したものです.

このsetを用いますと, (port番号によって) packetが全てのruleにマッチ しない事が最終的に決まるまでに, IPFWのpacketをチェックするルーチン のほとんど全てが実行されますので, 最悪のケースとなります. この ruleを999個繰り返した後にallow ip from any to anyが 書かれています.

2つ目のsetは, なるべく早くチェックが終了するように書かれたものです: ipfw add deny ip from 1.2.3.4 to 1.2.3.4

このruleではsource側のIPアドレスがマッチしないのでチェックは すぐに終了します. 上のsetとおなじように, 1000個目のruleは allow ip from any to anyです.

1つ目のsetでは, packetあたりのoverheadはだいたい2.703ms/packet, 言いかえると1つのruleあたり2.7マイクロ秒です. したがってこのruleに おけるpacketを処理する時間の理論的な限界は1秒あたり約370 packetです. 10MbpsのEthernetで1500 byte以下のpacketサイズを仮定すると, 55.5%の バンド幅までしか使えない事になります.

2つ目のsetでは, それぞれのpacketはだいたい1.172msで処理されて いますので1つのruleあたり1.2マイクロ秒となります. packetの 処理時間の理論的な限界はだいたい1秒あたり853 packetとなりますので 10Mbps Ethernetのバンド幅を使い切ることができます.

このテストでのruleの数は多過ぎますので, 実際に使用している際の 結果を反映している訳ではありません. これらは上に示した数値を出す ためだけに用いられたものです. 実際に効率の良いrule setを作るために は, 次のような事を考えておけばよいでしょう. `確定している' ruleは, TCPのtrafficの多数を処理するために 前の方に持ってきてください. そしてこのruleの前にはallow tcp という記述をしないでください. 良く使われるruleを, あまり良く使われないruleよりも 前の方に(もちろんfirewallの許可の設定を変えない範囲で) 持ってきてください. ipfw -a lのようにしてpacket数の統計を取ることによって どのruleが最もよく使われているかが分かります. diff --git a/ja_JP.eucJP/FAQ/preface.sgml b/ja_JP.eucJP/FAQ/preface.sgml index 35e0420589..c99777e18b 100644 --- a/ja_JP.eucJP/FAQ/preface.sgml +++ b/ja_JP.eucJP/FAQ/preface.sgml @@ -1,525 +1,556 @@ - + - + まえがき -

訳: &a.kuriyama;, &a.hanai;, &a.nakai;. +

訳: &a.kuriyama;, &a.hanai;, &a.nakai;, + &a.motoyuki;. 5 November 1997.

FreeBSD 2.X FAQ へようこそ! この FAQ の目的は?

Usenet の FAQ がそうであるように, この文書も FreeBSD オペレーティングシステムに関して頻繁に尋ねられる質問を 網羅することを目的としています (もちろんそれに対する答えも!). FAQ は本来バンド幅を減らし, 同じ質問が何度も繰り返されるのを 避けるために作られたものですが, 最近は有用な情報源と 見なされるようになってきました.

この FAQ をできる限り有用なものにしようと, あらゆる努力が はらわれています. もし何かしらの改善案が浮かんだら, ぜひ - まで + まで メールを送ってください. FreeBSD って何?

FreeBSD 2.X はカリフォルニア大学バークレイ校が i386 系の プラットフォーム向けにリリースした 4.4BSD-lite をもとにした UN*X ライクなオペレーティングシステムです. 間接的には同じ バークレイ校の Net/2 を William Jolitz が i386 系に移植した 386BSD も基にしていますが, 386BSD のコードはほとんど残って いません. FreeBSD についての詳細と, 何ができるかについては を参照してください.

FreeBSD は企業やインターネットサービスプロバイダ, 研究者, コンピュータ専門家, 学生, 家庭のユーザなどにより, 業務や教育, 娯楽に用いられています. これらに関しては を参照してください.

FreeBSD に関するより詳しい情報は を参照してください. FreeBSD が目指しているもの

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

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

(訳注1) GPL では, 「ソースコードを実際に受け取るか, あるいは, 希望しさえすればそれを入手することが可能であること」を求めています. どうして FreeBSD と呼ばれているのですか?

無料 (free) で使うことができる (商利用も含む). オペレーティングシステムの完全なソースコードが自由に (freely) 手に入り, 商利用・非商利用にかかわらず, 最低限の制限で他の仕事への利用, 配布, 導入が可能. 改良やバグフィックスがある場合, 誰でも (free) その コードを提出でき, ソースツリーに加えることができます (いくつかの簡単な条件には従ってもらいます).

母国語が英語でない読者のために, ここでは ``free'' という単語が 二通りに用いられていることを指摘しておくとわかりやすいかも しれません. ひとつは「無料である」ということ, もうひとつは 「自分のやりたいようにできる」ということです. FreeBSD のコードで FreeBSD の最新バージョンは? -

- が最新の stable バージョンで, 1997 年 10 月にリリース +

+ が最新の stable バージョンで, 1998 年 3 月にリリース されました. また, これは最新の release バージョンでもあります.

簡単に言ってしまうと, -stable は 最新のリリースのすばらしい新機能の数々よりも, 安定性と変更回数の 少なさを好む ISP や他の企業のユーザをターゲットにしています. 今のところ, これらのバージョンは同一のものですが, この状況も -currentブランチが一般のリリースとして十分に洗練されるまでの ことでしょう.

これは 3.0-current snapshot がビジネスサービス向けとしては不安定である, と言っているわけではなく, 3.0 特有の機能 (新しいコンパイラ技術や 高速なネットワークコードなど) を必要とする多くの人たちは, これを 使う決定をし, 良い成果を収めています. 私たちとしては, このブランチでさらに実績を積むまでは, 3.0 が自信を持っておすすめめできるものあるということを 「保証」したくないだけなのです. FreeBSD-currentって何?

は オペレーティングシステムのの開発バージョンで, やがて 3.0-RELEASE となります. よってこれは, そこに携わっている開発者や, どんな障害をも乗り越えていけるタフな愛好家たちにとってのみ 興味深いものです. -current の使用に際しての詳細は の を参照してください.

オペレーティングシステムに馴染みがない場合や一時的な問題か 本物の問題かを見極める能力がない場合は, FreeBSD-current を 使うべきではありません. このブランチは時々急激に拡張されたり, ビルドできない状態になることもちょっちゅうあります. FreeBSD-current を使う人は, 問題を分析して「小さな欠陥」では なく間違いであると思われるものだけを報告できるものと想定され ています. 「make world したら group 関係でエラーがでました」 のような質問は -current メーリングリストでは軽蔑の眼差しで あしらわれることもあります.

時たま, -current の開発コードから が作成され, snapshot の中からは 配布 CD-ROM が作成されることもあります. それぞれの snapshot には以下のような目的があります: インストールプログラムの最新版のテスト. 試してみたいけれど, 基礎的な所から毎日変わるような ものを追いかける時間もバンド幅も無い, という人にも -current を使えるようにする. また, そのような人たち のシステム移行のための手っ取り早い方法を提供する. あとでとんでもないことをしてしまった時のために, 問題となるコードの特定の参照基準点を保存しておく. (通常は CVS がこういうハプニングのような恐ろしい事態を防止して いるんですけどね :) テストが必要な新しい機能を, できる限り多くの 隠れテスターに試してもらう.

どんな目的であれ, snapshot が「製品レベルの品質」であるとの考えに 基づく要求は行わないでください. 安定性やテスト十分性にこだわる人は 完全なリリースから離れてはいけません.

3.0-current および 2.2-stable ブランチ両方の snapshot は, 平均的に一日に一度生成されており, から直接入手することが できます. FreeBSD-stable のコンセプトって何?

FreeBSD 2.0.5 がリリースされた後, 私たちは FreeBSD の開発を 2 系統に分割することにしました. 一つは というブランチで, バグの修正はしっかりテストされ, 機能の強化は少しずつしか行われません (急な変更や実験的機能を望まない, インターネットサービスプロバイダや営利企業向け). もう一方のブランチは で, 2.0 がリリースされて以来 3.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年3月) | | | [2.2-stable] - *BRANCH* 2.2.1 -> 2.2.2-RELEASE -> 2.2.5-RELEASE -> ... - | (1997年3月) (1997年10月) + *BRANCH* 2.2.1 -> 2.2.2-RELEASE -> 2.2.5 -> 2.2.6 -> 2.2.7 + | (1997年3月) (97年10月) (98年4月) (98年7月) | | 3.0-SNAPs (1997年第一四半期開始) | | - 3.0.0-RELEASE (1998年第一四半期) + 3.0.0-RELEASE (1998年10月) | \|/ + [今後の 3.x リリース群]

以前の 2.1-stable ブランチが 2.2.0 がリリースされたことによって 終了し, 「安定版ブランチ」がいわゆる 2.2-stable として新しくなったのに対して, -current ブランチは 3.0 とその先へ向けてゆっくりと進化を続けています. 3.0-current は, 実際に 3.0 がリリースされるまで, 活発な開発の 舞台として続いていくでしょう. その時点で 3.0 は別のブランチとなり, 3.1-current が次の「最新ブランチ」となる予定です. 2.1-stable ブランチが 2.1.7.1 で終わったのはなぜですか?

三つのブランチの開発を続けたいのはやまやまなのですが, 残念ながら このような状況を効率的に扱えるバージョン管理ツールがまだ 存在しないのです. 現在我々が使っているツールで, 複数のブランチを数ヶ月以上の 長期間に渡って並行してバージョン管理し続けることは, まさに 悪夢のような作業なのです. 一方で 2.1-stable ブランチは一年以上も続いていますから, FreeBSD の開発者たちの作業の大変さを考えると, このまま継続することは 深刻な問題に陥りかねません. おそらくみんなが望むものを提供してくれるような方法がそのうち 考え出されるでしょうし, また, 我々もそのような方法について 検討中なのですが, 現状では古い -stable ブランチを (2.1.7 の後の最終リリース) で終了し, 2.2.2 からを新たな -stable とすることが 最善の手段であると考えています. FreeBSD のリリースはいつ作られるのですか?

原則的には, FreeBSD コアチームは新しい機能やバグフィックスが 充分集まり, リリースの安定性を損なうことが無いようにさまざま な変更が十分に安定しているという条件を満たしている場合にのみ, 新しいバージョンの FreeBSD をリリースします. たとえこの用心深さが新しい機能が使えるようになることを 待ち望んでいるユーザを欲求不満にさせるとしても, 多くのユーザは このことを FreeBSD の最も良い所の一つだと考えています.

平均的には, だいたい 6 ヶ月ごとにリリースが作成されます.

もう少し刺激が欲しい (あるいは待ち遠しい) 方々向けに SNAP というものが存在し, これは特にリリースに近付いてきた数ヶ月 ぐらいの期間により頻繁に公開されます. FreeBSD は PC 用だけしかないの? -

現時点ではそうですが, DEC Alpha アーキテクチャへの移植 +

現時点ではそうですが, + と アーキテクチャへの移植 が計画されています. 異なるアーキテクチャのマシンを 持っていて, ゆっくり待てないという場合には次の URL を 参照してください. または . 誰が FreeBSD の責任者?

プロジェクトの全体的な方向性や, 誰にソースツリーにコードの 書き込み権限を与えるか, などといった FreeBSD プロジェクトに関する 重要な意思決定は 17 名からなる によってなされます. ソースツリーを直接変更できる人はもっと多く, 80 名以上の がいます.

しかし, 通常の変更ではないものはで先行して議論されますが, この議論への参加については一切の制限はありません. どこから FreeBSD を入手できますか?

FreeBSD のすべての主要なリリースは anonymous FTP 経由で から入手できます: - 現在の 2.2-stable リリース, 2.2.5R は - にあります. + 現在の 2.2-stable リリース, 2.2.6R は + にあります. 現在の 3.0-current, 3.0-SNAP は にあります. 次の 2.2 ブランチのリリースへと向かっている - RELENG_2_2 ブランチ (2.2.5 -> 2.2.x) に基づき一日に一回, + RELENG_2_2 ブランチ (2.2.6 -> 2.2.x) に基づき一日に一回, リリースが作成されます. 不慮の手違いによるまれな例外もありますが, RELENG_2_2 ブランチは 注意深く保守されています (実験的な変更はなく, -current でテスト済みの 変更だけが入ります). リリースも ブランチ用に一日に一回 作成されており, これらは純粋に最先端の開発者およびテスターのために 提供されています.

また, FreeBSD は CD-ROM でも入手でき, 次のところでオーダできます.

Walnut Creek CDROM 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: WWW:

オーストラリアでは, 次のところに問い合わせてください.

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 の IRC (Internet Relay Chat) について何か情報はありますか? -

FreeBSD の IRC に関して二つのチャンネルがあります. +

あります. FreeBSD チャットチャンネルのもっとも主要な IRC + ネットワークホストは以下の通りです: + + + EFNET の Channel #FreeBSD が恐らく最も + 人気があります. irc.chat.org のサーバー上にあります. + + DALNET の Channel #FreeBSD はアメリカでは + irc.dal.net, ヨーロッパでは irc.eu.dal.net + にあります. - - メインのチャンネルは, EFNET 上の #FreeBSD です. - 正式な IRC サーバが使用できます. + UNDERNET の Channel #FreeBSD はアメリカでは + us.undernet.org, ヨーロッパでは eu.undernet.org + にあります. - IRC クライアントで + 最後に, BSDNET の #FreeBSD に入ることもできます. + BSD 専用の小さなチャットネットワークで irc.FreeBSD.org + にあります. + + + +

それぞれのチャンネルは別個のもので互いに接続されていません. + チャットのスタイルも違っているので自分のチャットのスタイルにあった + ものを見つけるために一つ一つ試すのもいいでしょう. FreeBSD の本

Greg Lehey の本 ``Installing and Running FreeBSD'' が - Walnut Creek から出版されており 2.2.5 の CD-ROM が付属しています. + Walnut Creek から出版されており 2.2.6 の CD-ROM が付属しています. また, より詳しい本が ``The Complete FreeBSD'' というタイトルで - 出ており, 印刷されたマニュアルページと 2.2.5 の CD-ROM + 出ており, 印刷されたマニュアルページと 2.2.6 の CD-ROM が付属しています. 現在大抵の大型書店で入手できるはずです.

FreeBSD ドキュメンテーションプロジェクトがありますので, doc メーリングリストにコンタクトしてみてください (さらに参加すればもっとよいでしょう). - . + . このリストは FreeBSD のドキュメントに関して議論するためのものです. FreeBSD に関する質問に対しては questions というメーリングリストがあります: - . + .

FreeBSD の「ハンドブック」もあり, から読むことができます. 現在作業中ですので不完全な部分もあることに注意してください. +

FreeBSD のガイド本の決定版は Greg Lehey が書いた + ``The Complete FreeBSD'' で Walnut Creek CDROM Books から出版されて + います. 現在は第二版になっていて, インストール, システム管理ガイド, + プログラム設定のヘルプ, マニュアルページまでの内容が 1,750 ページに + わたって書かれています. + この本は (そして現在の FreeBSD リリースは) can be ordered from + , + , または + 最寄りの書店で注文することができます. + ISBN コードは 1-57176-227-2 です. +

しかし, FreeBSD 2.2.X は Berkeley 4.4BSD-Lite2 ベースなので, ほとんどの 4.4BSD のマニュアルが FreeBSD 2.2.X にも応用できます. 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 + : 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 + : 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 + : 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 + : 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 + : 1-56592-079-1

WWW 経由で以下の URL から, これらの詳細な説明を読むことができます. + name="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 + 0-201-54979-4

システム管理について参考になる本は次のものです.

Evi Nemeth, Garth Snyder, Scott Seebass & Trent R. Hein, ``Unix System Administration Handbook'', Prentice-Hall, 1995 - ISBN: 0-13-151051-7 + : 0-13-151051-7

この本は TCP/IP だけでなく DNS, NFS, SLIP/PPP, sendmail, INN/NNTP, 印刷などの基礎を扱っています. 高価ですが (およそ US$45-$55), 買う価値はあります. また, 色々なツールのソースコードが入った CD-ROM が付属しています. - しかし, それらのほとんどは FreeBSD 2.2.5R CD-ROM に収録されています + しかし, それらのほとんどは FreeBSD 2.2.6R CD-ROM に収録されています (さらに FreeBSD CD-ROM の収録物の方がより新しい場合があります). Problem Report (障害報告) データベースにアクセスする方法は?

ユーザ変更要求のすべてが公開されている Problem Report データベースは 障害報告の と の web ベースのインタフェースを通して, 問い合わせ (または提出) をおこなうことができます. また, send-pr(1) コマンドを使用して, 電子メール経由で障害報告や変更要求を提出することもできます. その他の情報

以下のニュースグループには FreeBSD ユーザに直接関係のある 議論が行われてます. (moderated)

Web 上のリソース: .

FreeBSD handbook には本当に完璧な の一覧があり, 買うべき本をさがしている方は読む価値があります. diff --git a/ja_JP.eucJP/FAQ/troubleshoot.sgml b/ja_JP.eucJP/FAQ/troubleshoot.sgml index 284c8e12ec..de89bc8617 100644 --- a/ja_JP.eucJP/FAQ/troubleshoot.sgml +++ b/ja_JP.eucJP/FAQ/troubleshoot.sgml @@ -1,423 +1,454 @@ - + - + トラブルシューティング

訳: &a.yoshiaki;.10 November 1997. ハードディスクに不良ブロックがあります!

SCSI ディスクの場合は自動的に再マップする機能があるはずです. しかし, 理解し難い理由から多くのドライブがこの機能が無効化 されて出荷されています...

これを有効化するには, 最初のデバイスのモードページを変更する 必要があります. これは次のコマンドを実行することで, FreeBSD 上でおこなうことができます (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

他の種類のディスクでは, オペレーティングシステムからサポート されているかによります. 残念ながら, この目的のために FreeBSD が提供する ``bad144'' コマンドはかなり手を入れる必要があります...

IDE ディスクは, おそらく不良ブロックの再マップを内蔵していると 思います; ディスクの説明書がある場合は, この機能が無効になって いるかを確認するとよいでしょう. しかし, ESDI, RLL, ST-506 ディスクは, 通常これをおこないません. +

再マップが可能になっていてで不良ブロックを見つけたのであれば, + ドライブを交換することを考えましょう. 不良ブロックの状態は時間と + ともに悪い方向にしか行きません. + 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 に合わせる必要があるでしょう.

742a EISA カードには, の節で説明している 「16 MB を越える」ことによる問題はありません. これは Vesa-Local Buslogic SCSI カードで発生する問題です. HP Netserver 上のオンボード SCSI コントローラが認識されません.

基本的にこれは既知の問題です. HP Netserver マシンの EISA オンボード SCSI コントローラは EISA のスロット番号 11 を占有しますが, 「本当の」EISA スロットはすべてそれよりも 前のアドレスに配置されているのです. 残念ながら, 10 番以上の EISA スロットは PCI に割り当てられたアドレス空間 と衝突し, FreeBSD の自動コンフィグレーションは, 現状ではうまくこの状況を 処理できていないのです.

ですから現時点での最良の方法は, カーネルオプションの に記述されているようにしてカーネルをコンパイルし, 構築してください.

もちろん, これはこのようなマシンにインストールする際に 卵が先か鶏が先か」といった問題を生み出すことになります. この問題を回避するために, ユーザコンフィグ (UserConfig) の中には特別な仕組みが組み込まれています. このとき ``visual'' インタフェースは使用せず, コマンドラインインタフェースを使用してください. 単純に eisa 12 quit

とプロンプト上から打ち込み, 後は普通にインストールをおこなってください. とにかくカスタムカーネルのコンパイルとインストールをおこなうことを おすすめしますが, も現時点ではこの値の変更を認識するようになっています.

うまくいけば, 将来のバージョンではこの問題が解決していることでしょう.

をご覧ください. この CMD640 IDE コントローラはどこかおかしいようです.

それは壊れているのです. 両方のチャンネルを同時に制御できないのです.

現在ではこのチップを使っているシステムでは自動的に検出して うまく動かすためのしくみが使えるようになっています. くわしくは マニュアルページのディスクドライバ (man 4 wd) を参照してください.

CMD640 IDE コントローラを使っているシステムで FreeBSD 2.2.1 あるいは 2.2.2 を使っている場合でセカンダリのチャネルを 使いたいのであれば ``

たぶん IRQ の衝突が原因でしょう (二つのボードが同じ IRQ を使用しているなど). FreeBSD 2.0.5R 以前では, これに関しては 寛大で IRQ の衝突があってもネットワークドライバは機能して いました. しかし 2.0.5R 以降は IRQ の衝突はもはや寛大では ありません. -c オプションをつけてブートして ed0/de0/... の エントリをボードの設定に合わせてください.

ネットワークカードの BNC コネクタ (訳注: 10BASE-2 タイプ のインターフェース) を使っている場合, デバイスのタイムアウト はターミネーションの不良によっても起きます. これをチェックするにはケーブルを外してターミネータを直接 NIC に接続します. そしてエラーメッセージが消えるかどうか 確認します. +

NE2000 コンパチブルカードのなかには UTP ポートのリンクが + なかったりケーブルが接続されていない場合にこのエラーを出す + ものがあります. + CDROM をマウントしようとすると ``Incorrect super block'' と言われます.

にマウントしたいデバイスのタイプを指定する必要 があります. デフォルトでは はファイルシステムを `` オプションをつけて明示する必要があります. これはもちろん CDROM が ISO 9660 ファイルシステムである場合です. ほとんどの CDROM はこの形式です. 1.1R の FreeBSD では (訳注: 現行の 2.1.5R, 2.2R でも同様です) 自動的に Rock Ridge 拡張 (長いファイル名への対応) をうまく解釈します.

CDROM のデバイス ``/dev/cd0c'' を /mnt にマウントしたい場合の例では, 次のようにします: mount -t cd9660 /dev/cd0c /mnt

デバイスの名前はインタフェースによっては別の名前になっている かもしれないので注意してください (``/dev/cd0c'' は この場合の例です). オプション `` mount_cd9660 /dev/cd0c /mnt CDROM をマウントしようとすると ``Device not configured'' と言われます.

これは 一般的に CDROM ドライブの中に CDROM が入っていないか, ドライブがバス上に見えないことを意味します. ドライブに CDROM を入れるか, IDE (ATAPI) であれば master/slave の状態をチェック してください. CDROM ドライブに CDROM を入れてから認識するまで 数秒かかりますので少し待ってみてください.

SCSI CDROM ではバスリセットへの応答時間が遅いために失敗する ことがあるかもしれません. SCSI CDROM を持っている場合は カーネルコンフィグレーションファイルに以下の行を加えて 再コンパイルして試してみてください. options "SCSI_DELAY=15"

(訳注: 現在の GENERIC カーネルでは上の設定はデフォルトに なっています. 問題のある場合は SCSI_DELAY の数値を増やして みてください.) 私のプリンタはとてつもなく遅いのです. どうしたらよいのでしょう?

パラレルインタフェースで, 問題はとんでもなく遅いだけであるなら, プリンタボートを ``polled'' モードに設定してみてください: lptcontrol -p

HP の新しいプリンタのいくつかは割り込みモードでは 使えないようです. (完全にわかったわけではありませんが) タイミングの問題のように思われます. 私のプログラムは時々 ``Signal 11'' のエラーで止まってしまいます.

これはハードウェア (メモリ, マザーボードなど) の不具合いが 原因です. PC でメモリテストプログラムを動かしてみてください. ただしメモリが正常に動作していると報告されたとしても, ぎりぎりで メモリテストにパスしたメモリは, 処理の内容 (例えば kernel のコンパイルや特にシステムの負荷が高いような場合には, Adaptec 1542 などの SCSI コントローラのバスマスタ DMA など) によっては問題が起きる可能性は大いにあります.

SIG11 FAQ (後で URLを示します) では遅いメモリが一般的に問題 を起こしがちであることを指摘しています. BIOS セットアップで ウエイトステート数を増やすかメモリを速いものに交換してください.

私の場合はキャッシュ RAM やオンボードキャッシュコントローラ の問題でした. このような問題ではないか確認するために BIOS セットアップでオンボード (セカンダリ) キャッシュを無効にして みてください.

以下のところには広い範囲の FAQ があります. ブートの時に画面が真っ暗になって同期も取れません.

これは ATI Mach 64 ビデオカードの既知の問題です. この問題はカードがアドレス ドライバのバグ (仕様?) のため4番目のシリアルポートがなくても, 通常この アドレスを使う sio3 (4 番目のポートにあたります) を無効にしても, ドライバはこのアドレスをさわります.

バグが修正されるまでは, 次のようにして対処してください. ブートプロンプトが出たら 問題はありません. exit とタイプしてブートを続行します.

もしシリアルポートを有効にしたいのであれば以下の変更をおこなって 新しいカーネルを作る必要があります. /usr/src/sys/i386/isa/sio.c の中で1ヵ所ある この対処をおこなった後でもまだ X ウィンドウシステムはうまく 動かないかもしれません. いくつかの新しい ATI Mach 64 ビデオカード (特に ATI Mach Xpression) は現在のバージョンの を見てベータリリースへのリンクを追ってください. 以下のファイルを持ってきましょう.

AccelCards, BetaReport, Cards, Devices, FILES, README.ati, README.FreeBSD, README.Mach64, RELNOTES, VGADriver.Doc, X312BMa64.tgz

古いファイルをこの新しいバージョンのファイルに置き換え, をもう一度実行します. 128MB の RAM があるのですが, 64MB しか認識しません.

FreeBSD がメモリのサイズを BIOS から取得する方法の制限により, KB 単位で 16 ビット分までしか検出できません (すなわち最大 65535Kb=64MB です)(これより少ない場合もあります. ある BIOS の場合はメモリサイズが 16MB に制限されます). 64MB 以上のメモリを積んでいる場合, FreeBSD はそれを検出しようとし ます. しかしその試みは失敗するかもしれません.

この問題を回避するには, 以下に示すカーネルオプションを 使用する必要があります. 完全なメモリ情報を BIOS から取得する 方法もありますが, ブートブロックに空きが無いため実装できません. ブートブロックの問題が解決されれば, いつか拡張 BIOS 機能を使用して完全なメモリ情報を取得できるようになるでしょう. とりあえず現在は, カーネルオプションを使ってください. options "MAXMEM=<n>"

FreeBSD 2.0 が ``kmem_map too small!'' と言ってパニックします.

このパニックは, ネットワークバッファ (特に mbuf クラスタ) の仮想メモリが無くなったことを示します. 以下のオプションを カーネルコンフィグファイルに追加して mbuf クラスタに使用できる 仮想メモリの量を増やしてください.

options "NMBCLUSTERS=<n>"

<n> には, 同時に使用したい TCP コネクションの数に応じて 512 から 4096 までの数値を指定できます. とりあえず 2048 を 試してみるのを勧めます. これでパニックは完全の予防できるはずです. mbuf クラスタの割り当て／使用状況については, で知ることができます. - + name="netstat -m"> で知ることができます. NMBCLUSTERS の + デフォルト値は + 新しいカーネルでリブートすると ``CMAP busy panic'' となってパニックを起こしてしまいます.

ファイル /var/db/kvm_*.db において範囲外のデータを 検出するためのロジックは失敗することがあり, こうした矛盾のある ファイルを使用することでパニックを引き起こすことがあります.

これが起こったなら, シングルユーザでリブートした後に, 以下のコマンドを実行してください. rm /var/db/kvm_*.db ahc0: brkadrint, Illegal Host Access at seqaddr 0x0 というエラーが出ます

これは Ultrastor SCSI Host Adapter と衝突しています.

ブート時に kernel configuration メニューに入り, 問題を起こしている を disable にしましょう. sendmailが ``mail loops back to myself'' というメッセージを出すのですが.

この事は, sendmail FAQ に次のように書いてあります. * "Local configuration error" というメッセージが出ます. 例えば: 553 relay.domain.net config error: mail loops back to myself 554 ... 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 release とは一緒には保守されて いません. しかし次のネットニュースに定期的に投稿されてます. , , , , . また, メール経由でコピーを入手する場合は 宛まで本文に "send usenet/news.answers/mail/sendmail-faq" と書いて送ります. + + リモートマシン上のフルスクリーンアプリケーションがうまく動かない + +

リモートマシンのターミナルタイプが FreeBSD のコンソールで + つかわれている cons25 以外のものです. +

この問題を解決する方法はいろいろあります: + + リモートマシンに login した後, shell 変数の TERM に + ansi か sco のいずれかを設定します. + ローカル側で のような VT100 エミュレータを使用します. + screen は一つのターミナルの中で複数のセッションを + 並列動作させることができますし, 本来の機能も優れています. + リモートマシンのターミナルデータベースに cons25 + のエントリをインストールします. + Xを起動してリモートマシンに xterm から login + します. (訳注: 日本語が必要な場合は kterm 等を + 利用します) +