os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Merge from English version.

Browse source 
commercial.sgml     : 1.3  -> 1.4
    hackers.sgml        : 1.12 -> 1.16
    network.sgml        : 1.15 -> 1.22
    troubleshoot.sgml   : 1.5  -> 1.9

Submitted by: Hiroki Sato <hrs@geocities.co.jp>
              Motoyuki Konno <motoyuki@freebsd.org>
This commit is contained in:
Motoyuki Konno 1999-05-06 02:11:15 +00:00
parent 937e1bd06c
commit 2af25beec3
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=4820
8 changed files with 990 additions and 226 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

103
ja/FAQ/commercial.sgml
View file

@ -1,6 +1,6 @@
<!-- $Id: commercial.sgml,v 1.3 1998-08-09 16:21:27 kuriyama Exp $ -->
<!-- $Id: commercial.sgml,v 1.4 1999-05-06 02:11:14 motoyuki Exp $ -->
<!-- The FreeBSD Japanese Documentation Project -->
<!-- Original revision: 1.3 -->
<!-- Original revision: 1.4 -->
<sect>
<heading>商用アプリケーション<label id="commercial"></heading>
@ -19,7 +19,63 @@
<sect1>
<heading>FreeBSD 用の Motif はどうやったら手に入りますか</heading>
<p>FreeBSD 用の Motif 2.0 に関する情報は
<p>FreeBSD 用の ELF 版 Motif 2.1 に関する情報は
<ref id="apps2go" name="Apps2go"> から
手に入れることができます.<label id="apps2go">
<p>この製品は以下の物が含まれています:
<itemize>
<item>OSF/Motif manager, xmbind, panner, wsm.
<item>uil, mrm, xm, xmcxx, インクルードファイルや Imake
ファイルといった開発者向けキット
<item>FreeBSD 3.0 以降で利用できる ELF 版スタティックライブラリ,
およびダイナミックライブラリ
<item>デモンストレーションプログラム
</itemize>
<p>注文する際には FreeBSD 用の Motif であることをきちんと
確認してください. NetBSD や OpenBSD 用の Motif もまた, <em>Apps2go</em>
から販売されています. 現在, FTP によるダウンロードのみ利用可能です.
<descrip>
<tag/より詳しい情報は/
<url url="http://www.apps2go.com/" name="Apps2go WWW page">
<tag/問い合わせは/ <url url="mailto:sales@apps2go.com" name="Sales"> または
<url url="mailto:support@apps2go.com" name="Support"> 電子メールアドレス.
<tag/もしくは/ phone (817) 431 8775 or +1 817 431-8775
</descrip>
<p>他の FreeBSD 用 Motif 2.1(ELF 版, a.out 版) に関する情報は
<ref id="metrox" name="Metro Link"> から手に入れることができます.
<p>この製品は以下の物が含まれています:
<itemize>
<item>OSF/Motif manager, xmbind, panner, wsm.
<item>uil, mrm, xm, xmcxx, インクルードファイルや Imake
ファイルといった開発者向けキット
<item>スタティックライブラリ, およびダイナミックライブラリ.
(FreeBSD 3.0 以降で利用できる ELF 版か,
FreeBSD 2.2.8 以前で利用できる a.out 版を指定して下さい)
<item>デモンストレーションプログラム
<item>整形済みのマニュアルページ
</itemize>
<p>注文する際には FreeBSD 用の Motif であることをきちんと
確認してください. Linux 用の Motif も <em>Metri Link</em>
から販売されています. 現在, CDROM および FTP
によるダウンロードが利用可能です.
<p>FreeBSD 用の a.out 版 Motif 2.0 に関する情報は
<ref id="xig" name="Xi Graphics"> から
手に入れることができます.
@ -30,7 +86,8 @@
<item>uil, mrm, xm, xmcxx, インクルードファイルや Imake
ファイルといった開発者向けキット
<item>スタティックライブラリ, およびダイナミックライブラリ
<item>FreeBSD 2.2.8 以前のバージョンで利用できるスタティックライブラリ,
およびダイナミックライブラリ
<item>デモンストレーションプログラム
@ -38,7 +95,7 @@
</itemize>
<p>注文する際には FreeBSD 用の Motif であることをきちんと
確認してください. BSDI や Linux 用の Motif も <em>Xi Graphics</em>
確認してください. BSDI や Linux 用の Motif もまた, <em>Xi Graphics</em>
から販売されています. 現在フロッピーディスク 4枚組ですが,
将来的には CDE のように統合された CD に変わるでしょう.
@ -48,24 +105,48 @@
<p>FreeBSD 用の CDE 1.0.10 に関する情報は
<ref id="xig" name="Xi Graphics"> から
手に入れることができます. これは Motif 1.2.5 を含んでおり,
Motif 2.0 と一緒に使用することができます.
a.out 版 Motif 2.0 と一緒に使用することができます.
<p>これは FreeBSD 用と Linux 用の統合された CD-ROM です.
<p>これは FreeBSD と Linux の両方に対応した CD-ROM で配布されているものです.
<sect1>
<heading>
高機能な商用 X サーバってあるんですか?<label id="xig">
高機能な商用 X サーバってあるんですか?
</heading>
<p>はい, <url url="http://www.xig.com" name="Xi Graphics">
<p>はい, <url url="http://www.xig.com" name="Xi Graphics"> と
<url url="http://www.metrolink.com" name="Metro Link">
から, FreeBSD ほか Intel ベースのシステムで動作する
Accelerated-X という製品が販売されています.
<label id="xig">
<p>この高性能な X サーバは楽に設定をおこなえるほか, 数多くのビデオボード
<p>Metro Link は, FreeBSD のパッケージ操作ツールを利用することで
容易に設定が行なえるほか, 数多くのビデオボードをサポートした
高機能な X サーバを提供しています. 配布はバイナリ形式のみで,
FTP が利用可能です. もちろん, とても安価($39)に手に入れることができます.
<label id="metrox">
<p>また, Metro Link は ELF 版, a.out 版の FreeBSD 用 Motif
も販売しています(前を参照).
<descrip>
<tag/より詳しい情報は/
<url url="http://www.metrolink.com/" name="Metro Link WWW page">
<tag/問い合わせは/ <url url="mailto:sales@metrolink.com" name="Sales">
または
<url url="mailto:tech@metrolink.com" name="Support"> 電子メールアドレス
<tag/もしくは/ phone (954) 938-0283 or +1 954 938-0283
</descrip>
<p>Xi Graphics が提供している高性能な X サーバは楽に設定をおこなえるほか,
数多くのビデオボード
をサポートしています. サーバはバイナリのみが含まれます.
FreeBSD 用と Linux 用の統合されたフロッピーディスクに入っています.
Xi Graphics は Laptop サポートに特化した高性能 X サーバも提供しています.
<p>バージョン 3.1 の「互換デモ」が無料で入手できます.
<p>バージョン 5.0 の「互換デモ」が無料で入手できます.
<p>また Xi Graphics は FreeBSD 用の Motif と CDE も販売しています (前を参照).

89
ja/FAQ/hackers.sgml
View file

@ -1,6 +1,6 @@
<!-- $Id: hackers.sgml,v 1.8 1999-03-01 17:18:52 motoyuki Exp $ -->
<!-- $Id: hackers.sgml,v 1.9 1999-05-06 02:11:14 motoyuki Exp $ -->
<!-- The FreeBSD Japanese Documentation Project -->
<!-- Original revision: 1.12 -->
<!-- Original revision: 1.15 -->
<sect>
<heading>まじめな FreeBSD ハッカーだけの話題<label id="hackers"></heading>
@ -52,7 +52,7 @@
<p>次に, CVS リポジトリ全体を手元においておく必要があります.
これを入手するには
<url url="../handbook/cvsup.html" name="CVSUP">
<url url="../handbook/synching.html#CVSUP" name="CVSUP">
が使用できますが, supfile で release の名称を cvs にして
他のタグや date フィールドを削除する必要があります:
@ -138,10 +138,12 @@
<sect1>
<heading>
インターネットアクセスに制限があっても current を追いかけられますか? <label id="ctm">
インターネットアクセスに制限があっても current を追いかけられますか?
<label id="ctm">
</heading>
<p>はい, <url url="../handbook/ctm.html" name="CTM システム ">を使って
<p>はい, <url url="../handbook/synching.html#CTM" name="CTM システム ">を
使って
ソースツリー全体のダウンロードを<tt/おこなわず/に追いかけることができます.
<sect1>
@ -502,4 +504,81 @@ Cc: current@FreeBSD.ORG
name="ELF リンカ"> に <tt>-export-dynamic</tt> オプションを
付けて実行形式をリンクする必要があります.
</sect1>
<sect1>
<heading>カーネルアドレス空間を大きくしたり、小さくするにはどうしたら良いのですか?</heading>
<p>
カーネルアドレス空間は, FreeBSD 3.x 上で
256MB, FreeBSD 4.x 上で 1GB がデフォルトになっています.
負荷の高いネットワークサーバ(例えば大きな FTP, HTTP サーバ)を運用する場合は,
256MB では足りないことに気付くかも知れません.
<p>
では, アドレス空間を大きくするにはどうしたら良いのでしょうか?
それには, 二つの段階を踏みます. まず,
より大きいアドレス空間を割り当てることをカーネルに知らせる必要があります.
次に, カーネルはアドレス空間の先頭にロードされるため,
アドレスの先頭が天井(訳注:カーネルアドレス空間の最下端アドレスのこと)と
ぶつかることのないように, ロードアドレスを今までより低位に設定する必要があります.
<p>
最初の段階は, <tt>src/sys/i386/include/pmap.h</tt> にある
<tt/NKPDE/ の値を増加させることで行ないます.
ここに 1GB のアドレス空間にするために, どのようにすれば良いかを示します.
<verb>
#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
</verb>
<p>
正確な <tt/NKPDE/ の値を計算するには,
望みのアドレス空間の大きさ(メガバイト単位)を 4 で割って,
それから UP のために 1, SMP のために 2 を引き算して下さい.
<p>
次の段階を行なうには, ロードアドレスを正確に計算することが必要です.
単純に, アドレス空間の大きさ(バイト単位)を 0x100100000 から引き算して下さい.
1GB アドレス空間の場合, その結果は 0xc0100000 になります.
そして, <tt>src/sys/i386/conf/Makefile.i386</tt> にある <tt/LOAD_ADDRESS/
に, 今計算した値を入れます. また, 次のように
<tt>src/sys/i386/conf/kernel.script</tt> のセクションの始めの方にある
ロケーションカウンタにも同じ値を入れて下さい.
<verb>
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) }
</verb>
<p>
それが完了したら, config し直してカーネルを再構築して下さい.
おそらく, <tt/ps(1)/, <tt/top(1)/ などに不具合が出るでしょう.
それらを正常にするために, <tt/make world/ (もしくは,
変更した <tt/pmap.h/ を <tt>/usr/include/vm/</tt>
にコピーした後に, <tt/libkvm/, <tt/ps/ および <tt/top/ を
手動で再構築すること)を行なうべきです.
<p>
注意: カーネルアドレス空間の大きさは, 4 メガバイトの倍数である必要があります.
<p>
[<url url="mailto:dg@freebsd.org" name="David Greenman">
による補足: <em> カーネルアドレス空間は 2 の乗数である必要があると思いますが,
それが確かなことかどうかははっきりしていません.
昔の起動コードには, 良く高位アドレスビットのトリックが使われていたため,
少なくとも 256MB の粒度であることが想定されていたと思います.]</em>
</sect>

301
ja/FAQ/network.sgml
View file

@ -1,6 +1,6 @@
<!-- $Id: network.sgml,v 1.10 1998-10-05 15:43:29 motoyuki Exp $ -->
<!-- $Id: network.sgml,v 1.11 1999-05-06 02:11:15 motoyuki Exp $ -->
<!-- The FreeBSD Japanese Documentation Project -->
<!-- Original revision: 1.15 -->
<!-- Original revision: 1.22 -->
<sect>
<heading>ネットワーキング<label id="networking"></heading>
@ -118,7 +118,7 @@
<item><url url="../handbook/ppp.html"
name="ハンドブックの PPP (kernel バージョン) の節">
<item><url url="../handbook/userppp.html"
<item><url url="../handbook/ppp-and-slip.html#USERPPP"
name="ハンドブックの PPP (user モードバージョン) の節">
</itemize>
@ -153,7 +153,7 @@
</heading>
<p>まず <htmlurl url="http://www.freebsd.org/cgi/man.cgi?ppp"
name="ppp"> のマニュアルと, <url url="../handbook/userppp.html"
name="ppp"> のマニュアルと, <url url="../handbook/ppp-and-slip.html#USERPPP"
name="ハンドブックの ppp のセクション">を読んでみましょう. 次に,
<verb>
@ -247,7 +247,7 @@ default 10.0.0.2 UGSc 0 0 tun0
<p>の行をうっかり消してしまった可能性があります.
この場合は, ハンドブックの
<url url="../handbook/userppp:final.html"
<url url="../handbook/ppp-and-slip.html#USERPPP-FINAL"
name="システムの最終設定"> の項を読み直してください.
<sect2>
@ -273,7 +273,7 @@ default 10.0.0.2 UGSc 0 0 tun0
</verb>
<p>詳しい情報については, ハンドブックの
<url url="../handbook/userppp:dynamicIP.html"
<url url="../handbook/ppp-and-slip.html#USERPPP-DYNAMICIP"
name="PPP と動的 IP 設定"> の項を参照してください.
<sect2>
@ -336,13 +336,93 @@ default 10.0.0.2 UGSc 0 0 tun0
<p>詳しくはお使いのモデムのマニュアルをご覧ください.
<sect2>
<heading>接続が不規則にハングアップしてしまう</heading>
<p>たくさんの人が, 原因不明のハングアップを経験しています.
検証のために必要なのは, まずどちら側のリンクでそれが起こっているか,
ということです.
<p>外部接続型モデムを利用しているなら, 単に <tt/ping/ を使うことで,
データを送信するときに <tt/TD/ ランプが点灯するかどうかを確認することができます.
もし, <tt/TD/ ランプが点灯して, <tt/RD/ ランプが点灯しなければ,
問題は回線の向こう側にあります. <tt/TD/ が点灯しなければ,
問題は回線のこちら側です. 内蔵型モデムの場合, <tt/ppp.conf/ ファイルに
<tt/set server/ コマンドを入れる必要があるでしょう.
回線が切断されたとき, pppctl を使って ppp に接続してください.
そのとき, ネットワーク接続が急に復旧(診断ソケットへのアクセスで,
ppp が復活します)するか, もしくは接続自体が全くできない
(ただし, ppp 起動時に <tt/set socket/
コマンドがちゃんと実行されているとします)としたら,
問題は回線のこちら側です. もし, 接続可能で, かつ状況が変化しなければ,
<tt/set log local async/ を使ってローカル非同期ログ(async logging)を有効にし,
<tt/ping/ を他のウィンドウかターミナルから使ってください.
非同期ログには, こちら側のリンクの送受信データが記録されます.
もし, データが送信されたにもかかわらず返って来ていなければ,
問題は回線の向こう側にあることになります.
<p>問題が回線のどちら側かにあることが分かったら,
つぎの二つの可能性が考えられるでしょう.
<sect3>
<heading>回線の向こう側での反応がない</heading>
<p>これに対処できることはほとんどありません. 大部分の ISP
は, Microsoft 社製 OS 以外の利用者に対してのサポートを拒否するでしょう.
<tt/ppp.conf/ ファイルの中に <tt/enable lqr/ を記述することで
ppp が回線の向こう側で発生するハングアップを検出することができますが,
この検出は比較的遅いため, あまり役に立ちません. また, あなたは
user-ppp を利用していることを ISP に知られたくないと思うかも知れませんね.
<p>まず最初に, こちら側の圧縮機能を全て無効にしてみて下さい.
それには, 設定ファイルをつぎのようにします.
<verb>
disable pred1 deflate deflate24 protocomp acfcomp shortseq vj
deny pred1 deflate deflate24 protocomp acfcomp shortseq vj
</verb>
<p>そして再接続し, 変更前と同じように通信できることを確認します.
もしこれによって状況が改善されるか, 完全に解決したら,
(上の設定のうち)どの設定で状況が変化したのかを,
色々な組合せで試してみて下さい. これは, ISP
に問い合わせを行なうときの有効な情報となります(ただし,
あなたが Microsoft 社製品以外のものを利用していることも
明らかにしてしまいますが).
<p>ISP に問い合わせを行なう前に, こちら側の非同期ログを有効にして,
接続がハングアップするまで待って下さい. この作業は,
非常に多くのディスク空間を消費するかも知れません.
興味の対象となっているのは, 通信ポートから最後に読み込まれたデータです.
それは通常 ASCII データで, 問題点の詳細(``Memory fault, core dump''など)が
記載されている可能性があります.
<p>回線の向こう側で通信ログを監視することは可能なはずですので,
ハングアップが発生した時, ISP の対応が好意的ならば
どうして ISP 側で問題が発生したのかこちらに伝えてくれるかも知れません.
<url url="mailto:brian@Awfulhak.org" name="brian@Awfulhak.org">
まで詳細を送って頂くか, ISP に直接私に連絡するように伝えて下さっても構いません.
<sect3>
<heading>ppp がハングアップする</heading>
<p>ベストな方法は, <tt/CFLAGS+=-g/ と <tt/STRIP=/ を ppp の Makefile
に追加して, ppp を再構築し, そして
<tt/make clean &amp;&amp; make &amp;&amp; make install/ を行なうことです.
ppp がハングアップした時, <tt/ps ajxww | fgrep ppp/ を使って ppp
のプロセス ID を調べ, <tt/gdb ppp PID/ を実行して下さい.
gdb のプロンプトから, <tt/bt/ を使ってスタックをトレースすることができます.
<p>スタックトレースの結果は, <url url="mailto:brian@Awfulhak.org"
name="brian@Awfulhak.org"> まで送って下さい.
<sect2>
<heading>Login OK! のメッセージが出た後, 何も起こらない</heading>
<p>2.2.5 より前のリリースの FreeBSD では,
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?ppp"
name="ppp"> はリンクが確立した後, 接続先が Line Control Protocol (LCP)
を発信するのを待ちます. しかし, 多くの ISP ではネゴジェーションを
を発信するのを待ちます. しかし, 多くの ISP ではネゴシエーションを
自分からは起こさず, クライアントが起こすのを待っています.
<bf/ppp/ に強制的に LCP を発信させるには, 次の命令を使います.
@ -505,7 +585,7 @@ default 10.0.0.2 UGSc 0 0 tun0
enable lqr
</verb>
<p>こうすると, 接続先がネゴジェーションを行う場合, デフォルトで
<p>こうすると, 接続先がネゴシエーションを行う場合, デフォルトで
LQR の使用を受け入れるようになります.
<sect2>
@ -729,49 +809,65 @@ default 10.0.0.2 UGSc 0 0 tun0
理由やそのアドレス, 関連した変数の値なども調べる事ができるでしょう.
<sect2>
<heading>
auto modeでdialをするようなprocessがconnectしてくれない
</heading>
<heading>auto mode でダイアルをするようなプロセスが接続されない</heading>
<p>これは<bf/ppp/が動的なlocalのIP numberを相手とnegotiateする
ように設定されている時のknown problemです. 最初のプログラムが
<p>これは <bf/ppp/ がローカル側の IP アドレスを,
動的に通信相手と交渉するように設定されている時に発生する
良く知られた障害でした. 最新のバージョンでは,
この問題は修正されています.
<bf/iface/ をマニュアルページから検索してみて下さい.
これは, 最初のプログラムが
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?connect"
name="connect(2)">を呼び出した時, tun intergaceのIP numberが
socketのendpointに割り当てられます. kernelは最初に外へ出ていく
packetを作り, それをtunデバイスへ書きます. 次に<bf/ppp/はpacket
を読んで接続を確立します. <bf/ppp/の動的IP割り当ての結果として,
interfaceのアドレスは変わりますので, 一番最初のsocketのendpoint
のは無効になります. そしてそれ以降相手に送られるpacketは落とされ
てしまいます. 仮にそうでないとしても, 既にIP numberは変更されて
いるので, どんな返事も始めのmachineには戻ってきません.
name="connect(2)"> を呼び出した時, tun インターフェイスの IP
アドレスが, ソケットの終端に割り当てられてしまうという問題です.
カーネルは, 外へ出ていく最初のパケットを作り, それを tun デバイスへ書き込みます.
そして <bf/ppp/ は, そのパケットを読み込んで接続を確立します.
<bf/ppp/ は動的に IP アドレスを割り当てるため,
もしインターフェイスのアドレスが変化してしまうと,
最初に割り当てられたソケット終端の IP アドレスは無効になってしまいます.
そのため, それ以降相手に送られる全てのパケットは通常,
相手に届くことはないでしょう. もし仮に届いたとしても,
既にこちらの IP アドレスは変更されているので,
どんな反応も最初のマシンには戻ってきません.
<p>この問題に対処する理論的な方法がいくつかあります. もし可能なら,
相手が同じIP numberを割り当てなおす事ができるのが最も良いです<tt/:-)/
相手が再度, 同じ IP アドレスを割り当ててくれることが一番です <tt/:-)/
<bf/ppp/ の現在のバージョンはこれを行ないますが,
他のほとんどの実装はそういった動作をしません.
<p>我々の側から対処できる最も簡単な方法は, tun interfaceのIP
numberを固定する事ですが, かわりに外に出ていくpacketを変更して
source IP numberをinterfaceのIPからnegotiateされたIPに書きかえる
事によっても対処できます. これが,
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?libalias"
name="libalias(3)"> (およびpppの<bf/-alias/ switch)の行っている
方法です.
<p>我々の側から対処できる最も簡単な方法は, tun インターフェイスの
IP アドレスを固定する事です. またそのかわりに,
外に出ていくパケットを変更して, 発信元 IP アドレスをインターフェイスの IP
アドレスから, 交渉によって得られた IP アドレスに,
適宜書きかえる事によっても対処できます. こ
これは, 基本的に <bf/ppp/ の最新バージョンにある <tt/iface-alias/ オプションが
行なっていることと同じです(<htmlurl url="http://www.freebsd.org/cgi/man.cgi?libalias"
name="libalias(3)"> および, ppp の <bf/-alias/
スイッチにも関係します). それは, 以前の IP アドレスを全て管理し,
それらを最後の交渉によって得られた IP アドレスの別名として扱えるようにします.
<p>もう1つの(最も確かな)方法は, 全てのbindされているsocketの
IPを変更するようにsystem callを実装する事です. <bf/ppp/は,
新しくIP numberがnegotiateされた時に, このsystem callを用いて
全てのsocketを書きかえるのです.
<p>もう 1 つの(おそらく最も信頼できる)方法は, bind された
全てのソケットの IP アドレスを,
異なるものに変更できるシステムコールを実装することです.
<bf/ppp/は, 交渉によって新しい IP アドレスを得た時,
このシステムコールを用いて実行されているプログラムにある,
全てのソケットを書きかえてやるわけです.
同じシステムコールが, DHCP クライアントが利用するソケットを
強制的に再 bind するのにも使うことができるでしょう.
<p>3つ目の方法は, interfaceをIP number無しで立ち上げる事を許す
ことです. 外に出ていくpacketは最初のSIOCAIFADDR ioctlが終わるまで
は255.255.255.255というIP numberを与えられます. これによって
socketを完全にbindすることができます. <bf/ppp/に対してsource IP
numberを変更させる事になりますが, もしそれが255.255.255.255になって
おり, IP numberとIP checksumだけ変更すれば良ければの話になります.
しかし, この方法は, 他の部分の仕組みが古い物との互換性を持つよう
変更されてしまった場合には, kernelが適切に設定されていないinterface
に対して悪いpacketを送信してしまいます.
<p>現在のところ, これらの方法のどれもまだ実装されていません.
<p>3 つ目の方法は, IP
アドレスを指定しないでインターフェイスを利用できるようにすることです.
外に出ていくパケットは, 最初の SIOCAIFADDR ioctl の完了まで,
255.255.255.255 という IP アドレス が与えられます.
これによって. ソケットは常に bind することができます.
<bf/ppp/に対して発信元 IP アドレスを変更させる事になりますが,
もしそれが 255.255.255.255 になっていたら, IP アドレスと
IP チェックサムだけ変更すれば良ければの話になります.
この方法はちょっとした変更ですが, 他の機構が今までのように, IP
アドレスを固定して利用する場合に, カーネルが
不適切に設定されたインターフェイスに向けて, 正常でないパケットを
送り出してしまう可能性があります.
<sect2>
<heading>何故ほとんどのゲームが -alias スイッチ付きだと動かないんですか?</heading>
@ -1054,90 +1150,94 @@ default 10.0.0.2 UGSc 0 0 tun0
<sect1>
<heading>すべてのネットワークの操作に対して ``Permission denied'' というメッセージが表示されるのですが. </heading>
<p><tt/IPFIREWALL/オプションを付けてkernelをコンパイルした場合には,
<p><tt/IPFIREWALL/ オプションを付けてカーネルをコンパイルした場合には,
2.1-STABLE の開発の途中から変更になった 2.1.7R の標準的な方針として,
明示的に許可されていないすべてのパケットは落とされる設定
になっている事を覚えておいてください.
<p>もしfirewallの設定を間違えた場合にネットワークの操作が再びできる
ようにするには, root で login して次のコマンドを実行してください.
<p>もしファイアウォールの設定を間違えた場合にネットワークの操作が再びできる
ようにするには, root でログインして次のコマンドを実行してください.
<verb>
ipfw add 65534 allow all from any to any
</verb>
<p><tt>/etc/rc.conf</tt>に"firewall_type='open'"を追加してもよい
<p><tt>/etc/rc.conf</tt> に "firewall_type='open'" を追加してもよい
でしょう.
<p>FreeBSD の firewall の設定についての情報は
<p>FreeBSD のファイアウォールの設定についての情報は
<url url="../handbook/firewalls.html" name="FreeBSD ハンドブック">
にあります.
<sect1>
<heading>IPFWのオーバーヘッドはどのくらいでしょうか?</heading>
<heading>IPFW のオーバーヘッドはどのくらいでしょうか?</heading>
<p>この答えはあなたのrule setとprocessorのスピードによって
ほとんど決まります. Ethernetに対して少しのrule setだけを使っ
<p>この答えはあなたのルールセットとプロセッサのスピードによって
ほとんど決まります. イーサネットに対して少しのルールセットだけを使っ
ているほどんどの場合には, その影響は無視できる程度です. 実
際の測定値を見ないと満足できない方々のために, 実際の測定結
果をお見せしましょう.
<p>次の測定は486-66上で2.2.5-STABLEを使用しておこなわれました.
IPFWは変更が加えられて, <tt/ip_fw_chk/ルーチン内でかかる時間を
測定して1000パケット毎に結果をconsoleに表示するようになっています.
<p>次の測定は 486-66(訳注: Intel 社製 CPU i486, 66MHz のこと)上で
2.2.5-STABLE を使用しておこなわれました.
IPFW は変更が加えられて, <tt/ip_fw_chk/ ルーチン内でかかる時間を
測定して 1000 パケット毎に結果をコンソールに表示するようになっています.
<p>それぞれ1000ずつのruleが入っている2つのrule setでテストが
おこなわれました. ひとつ目のsetは最悪のケースを見るために
<p>それぞれ 1000 ずつのルールが入っている 2 つのルールセットでテストが
おこなわれました. ひとつ目のルールセットは最悪のケースを見るために
<verb>
ipfw add deny tcp from any to any 55555
</verb>
というruleを繰り返したものです.
というルールを繰り返したものです.
<p>このsetを用いますと, (port番号によって) packetが全てのruleにマッチ
しない事が最終的に決まるまでに, IPFWのpacketをチェックするルーチン
のほとんど全てが実行されますので, 最悪のケースとなります. この
ruleを999個繰り返した後に<tt>allow ip from any to any</tt>が
<p>パケットが(ポート番号のせいで)このルールにマッチしないことがわかるまでに,
何度も実行される IPFW のパケットチェックルーチンによって,
これは最悪のケースを示します.
このルールを 999 個繰り返し並べた後に <tt>allow ip from any to any</tt>が
書かれています.
<p>2つ目のsetは, なるべく早くチェックが終了するように書かれたものです:
<p>2つ目のルールセットは, なるべく早くチェックが終了するように書かれたものです:
<verb>
ipfw add deny ip from 1.2.3.4 to 1.2.3.4
</verb>
<p>このruleではsource側のIPアドレスがマッチしないのでチェックは
すぐに終了します. 上のsetとおなじように, 1000個目のruleは
<p>このルールでは, 発信元の IP アドレスがマッチしないのでチェックは
すぐに終了します. 上のルールセットとおなじように, 1000 個目のruleは
<tt>allow ip from any to any</tt>です.
<p>1つ目のsetでは, packetあたりのoverheadはだいたい2.703ms/packet,
言いかえると1つのruleあたり2.7マイクロ秒です. したがってこのruleに
おけるpacketを処理する時間の理論的な限界は1秒あたり約370 packetです.
10MbpsのEthernetで1500 byte以下のpacketサイズを仮定すると, 55.5%の
バンド幅までしか使えない事になります.
<p>1 つ目のルールセットでは, パケットあたりのオーバヘッドはおよそ
2.703ms/packet, これはだいたい 1 つのルールあたり 2.7 マイクロ秒
かかっていることになります.
したがって, このルールにおけるパケット処理時間の理論的な限界は,
毎秒約 370 パケットです.
10Mbps のイーサネットで 1500 バイト以下のパケットサイズを仮定すると,
バンド幅の利用効率は 55.5% が限界となることになります.
<p>2つ目のsetでは, それぞれのpacketはだいたい1.172msで処理されて
いますので1つのruleあたり1.2マイクロ秒となります. packetの
処理時間の理論的な限界はだいたい1秒あたり853 packetとなりますので
<p>2 つ目のルールセットでは, それぞれのパケットがおよそ
1.172msで処理されていますので, だいたい 1 つのルールあたり 1.2 マイクロ秒
かかっていることになります.
パケット処理時間の理論的な限界は, 毎秒約 853 パケットとなりますので,
10Mbps Ethernetのバンド幅を使い切ることができます.
<p>このテストでのruleの数は多過ぎますので, 実際に使用している際の
<p>このテストでのルール数は多過ぎるため, 実際に使用する際の
結果を反映している訳ではありません. これらは上に示した数値を出す
ためだけに用いられたものです. 実際に効率の良いrule setを作るために
は, 次のような事を考えておけばよいでしょう.
ためだけに用いられたものです. 効率の良いルールセットを作るためには,
次のような事を考えておけばよいでしょう.
<itemize>
<item>`確定している' ruleは, TCPのtrafficの多数を処理するために
前の方に持ってきてください. そしてこのruleの前には<tt>allow tcp</tt>
という記述をしないでください.
<item>`確定している' ルールは先頭の方に持ってきてください.
これは, 多数の TCP のトラフィックがこのルールで処理されるためです.
そしてこのルールの前には <tt>allow tcp</tt> という記述を置かないでください.
<item>良く使われるruleを, あまり良く使われないruleよりも
前の方に(もちろん<bf>firewallの許可の設定を変えない範囲で</bf>)
<item>良く使われるルールを, あまり良く使われないルールよりも
前の方に(もちろん<bf>ファイアウォールの許可設定を変えない範囲で</bf>)
持ってきてください.
<tt>ipfw -a l</tt>のようにしてpacket数の統計を取ることによって
どのruleが最もよく使われているかが分かります.
<tt>ipfw -a l</tt> のようしてパケット数の統計を取ることで,
どのルールが最もよく使われているかを調べることができます.
</itemize>
@ -1147,7 +1247,7 @@ default 10.0.0.2 UGSc 0 0 tun0
<p>FTP などのサービスのリクエストは, 'socket' パッケージを利用
してリダイレクトできます. 'socket' パッケージは ports の
'sysutils' カテゴリに含まれています. リダイレクトしたいサービ
ス(<tt>/etc/inet.conf</tt>のコマンド行を socket を呼ぶように変
ス(<tt>/etc/inet.conf</tt>のコマンド行をソケットを呼ぶように変
更してください. 変更例:
<verb>
@ -1157,4 +1257,35 @@ ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.foo.com ftp
<p>ここで 'ftp.foo.com' はリダイレクト先のホスト名, 行の最後の'ftp'
はポートです.
<sect1>
<heading>バンド幅の管理を行なえるツールはどこで手に入れられますか?</heading>
<p>FreeBSD 用のバンド幅管理ツールには, 無料で手に入れられる
<url url="http://www.csl.sony.co.jp/person/kjc/programs.html"
name="ALTQ"> と,
<url url="http://www.etinc.com" name="Emerging Technologies">
から入手できる Bandwidth Manager という市販のものの 2 種類があります.
<sect1>
<heading>なぜ ``/dev/bpf0: device not configured" が出るのでしょうか?</heading>
<p>バークレーパケットフィルタ<htmlurl
url="http://www.FreeBSD.org/cgi/man.cgi?bpf" name="(bpf)">
ドライバは, それを利用するプログラムを実行する前に有効にしておく必要があります.
カーネルコンフィグファイルに, 次のように追加してカーネルの再構築をして下さい.
<verb>
pseudo-device bpfilter # Berkeley Packet Filter
</verb>
<p>そして再起動してから, 次にデバイスノードを作成する必要があります.
これは, 次のように入力し, <tt>/dev</tt> を変更することで行ないます.
<tscreen><verb>
# sh MAKEDEV bpf0
</verb></tscreen>
<p>デバイスノードの作成の詳細は, <htmlurl url="../handbook/kernelconfig-nodes.html"
name="FreeBSD ハンドブックのデバイスノードに関する節"> を参照して下さい.
</sect>

115
ja/FAQ/troubleshoot.sgml
View file

@ -1,6 +1,6 @@
<!-- $Id: troubleshoot.sgml,v 1.4 1998-07-21 07:57:10 hanai Exp $ -->
<!-- $Id: troubleshoot.sgml,v 1.5 1999-05-06 02:11:15 motoyuki Exp $ -->
<!-- The FreeBSD Japanese Documentation Project -->
<!-- Original revision: 1.5 -->
<!-- Original revision: 1.9 -->
<sect>
<heading>トラブルシューティング<label id="troubleshoot"></heading>
@ -28,18 +28,81 @@
ARRE (Auto Read Reallocation Enbld): 1
</verb>
<p>他の種類のディスクでは, オペレーティングシステムからサポート
されているかによります. 残念ながら, この目的のために FreeBSD
が提供する ``bad144'' コマンドはかなり手を入れる必要があります...
<p>以下は, <url url="mailto:tedm@toybox.placo.com" name="Ted Mittelstaedt">
から寄せられたものです.
<p>IDE ディスクは, おそらく不良ブロックの再マップを内蔵していると
思います; ディスクの説明書がある場合は, この機能が無効になって
いるかを確認するとよいでしょう. しかし, ESDI, RLL, ST-506
ディスクは, 通常これをおこないません.
<p>IDE ドライブの場合は通常, 不良ブロックは潜在的な障害の兆候です.
最近の IDE ドライブは, 内部の不良ブロック再マッピング機能を有効にした状態で
出荷されています. また, 今日の IDE ハードディスクメーカは,
出荷以降に不良ブロックが発生することに関して保証を提供していて,
不良ブロックのあるディスクドライブを交換するサービスを行なっています.
<p>再マップが可能になっていて不良ブロックを見つけたのであれば,
ドライブを交換することを考えましょう. 不良ブロックの状態は時間と
ともに悪い方向にしか行きません.
<p>もし, 不良ブロックのある IDE ディスクドライブを復旧しようと思うなら,
IDE ドライブメーカが提供する IDE 診断プログラムをダウンロードして,
そのドライブに使ってみてください. この種のプログラムは大抵,
ドライブの制御部分に対して不良ブロックを再走査し,
不良ブロックを使用不能にするようにセットすることができます.
<p>ESDI, RLL および MFM ドライブの場合, 不良ブロックはドライブの
正常な部分であり, 一般的に言って障害を表すものではありません.
PC では, ディスクドライブコントローラカードと BIOS が不良ブロックの
使用不能化の作業を行ないます. DOS など, ディスクアクセスに BIOS
を経由する OS にとっては有効に働きますが, FreeBSD
のディスクドライバは BIOS を利用しません. そのため,
代替として bad144 という機構が存在します.
bad144 は, wd ドライバにだけ作用し, SCSI ドライバに利用することは
*できません*. bad144 は, 検出された不良セクタをスペシャルファイルに
記録するという働きを持っています.
<p>bad144 を利用する上で, 注意しなければならない点が一つあります.
それは, 不良ブロックスペシャルファイルは, ディスクの最終トラックに
置かれるということです. このファイルには, ディスクの先頭の付近,
/kernel ファイルが位置しているであろう部分で発生した不良セクタが
記録されています. したがって, このファイルは BIOS コールを使って
カーネルファイルを読み込む起動プログラムがアクセス可能でなければなりません.
これはつまり, bad144 を利用するディスクは, 1024 シリンダ,
16 ヘッド, 63 セクタを超えてはならないということを意味し,
bad144 を利用したディスクが実質 500MB を超えられないことになります.
<p>bad144 を使うには, FreeBSD のインストール時に表示される fdisk 画面で,
"Bad Block" 走査を ON に設定するだけです. これは, FreeBSD 2.2.7 以降で
機能します. ディスクは, 1024 シリンダ以内でなければなりません.
ディスクドライブは事前に少なくとも 4 時間, ディスクが温度によって膨張し,
トラックに曲がりが出るまで回転させることをお薦めします(訳注: 温度変化に
対する膨張によって, ディスクが微小変形することにより発生する不良セクタを
確実に検出するためです).
<p>大容量の ESDI ドライブのように, 1024 シリンダを超えるディスクの場合,
DOS 上でそのディスクが利用できるように, ESDI コントローラは特殊な変換モードを
利用します. fdisk の "set geometry" コマンドを使って
"変換された(translated)" ジオメトリに切替えると, wd ドライバは
この変換モードを解釈できます.
その際, FreeBSD パーティションを作成するのに "dangerously dedicated" モードを
利用してはいけません. このモードは, そのようなジオメトリを無視するからです.
たとえ fdisk がオーバーライドされたジオメトリ情報を使ったとしても,
已然としてディスクの真の大きさを保持しているため, 大きすぎる FreeBSD
パーティションを作成しようとしてしまうでしょう.
ディスクジオメトリ情報が変換されたジオメトリ情報にかわっている場合は,
手動でブロック数を入力し, パーティションを作成する必要があります.
<p>大容量の ESDI ディスクを ESDI コントローラでセットアップするには,
ちょっとしたトリックを使います. まず, DOS のディスクで起動して
そのディスクを DOS パーティションとしてフォーマットします.
そして FreeBSD を起動し, インストーラの fdisk 画面で
DOS パーティションのブロックサイズとブロック数を読みとり, メモしておきます.
ジオメトリ情報を DOS が利用しているものと同一に再設定し,
DOS パーティションを削除して "cooperative" FreeBSD パーティションを
先程記録したブロックサイズを使って作成して下さい.
そのパーティションを起動可能パーティションに設定し, 不良ブロック走査を
有効にして下さい. 実際のインストールでは, ファイルシステムが作成される前に
bad144 が最初に実行されます(Alt-F2 を押すことで状況を確認できます).
不良セクタファイルを作成中に何らかの障害が発生したなら,
システムを再起動して, もう一度最初からやり直しになります.
おそらくディスクジオメトリ情報の設定を大きくしすぎているのでしょう.
(やり直しは, DOS によるフォーマットとパーティション確保を含みます)
<p>もし, 不良ブロックの再マッピングを有効にしていて不良ブロックが見付かったら,
ドライブの交換を考えて下さい. 不良ブロックは, 時間とともに悪化するからです.
<sect1>
<heading>Bustek 742a EISA SCSI が認識されません.</heading>
@ -450,5 +513,33 @@
します. (訳注: 日本語が必要な場合は <tt>kterm</tt> 等を
利用します)
</itemize>
<sect1>
<heading>私のマシンで "calcru: negative time..." と表示されるのですが</heading>
<p>これは, 割り込みに関連するさまざまな不具合によって発生します.
あるいは, あるデバイスが元々持っているバグが表面化したのかも知れません.
この症状を再現させる一つの方法として, パラレルポート上で,
TCP/IP を 大きな MTU で走らせるというものがあります.
グラフィックアクセラレータがこの症状を起こすことがありますが,
その場合はまず, カードの割り込み設定を確認して下さい.
<p>この問題の副作用として, プロセスが "SIGXCPU exceeded cpu time limit"
というメッセージとともに終了してしまう, というものがあります.
<p>1998 年 11 月 29 日に公開された FreeBSD 3.0 以降で
この問題が解決しないなら, 次の sysctl 変数をセットしてください.
<verb>
sysctl -w kern.timecounter.method=1
</verb>
<p>これは, パフォーマンスへ強い影響を与えますが, 問題の発生に比べれば
おそらく気にならない程度でしょう. もし, これでもまだ問題が残るようなら,
カーネルオプションの "NTIMECOUNTER" を大きな値に増やして下さい.
"NTIMECOUNTER=20" にまで増やしても解決しない場合は,
計時処理の信頼性が保てない程の割り込みが, そのマシン上で起こっていることを
意味します.
</sect>

103
ja_JP.eucJP/FAQ/commercial.sgml
View file

@ -1,6 +1,6 @@
<!-- $Id: commercial.sgml,v 1.3 1998-08-09 16:21:27 kuriyama Exp $ -->
<!-- $Id: commercial.sgml,v 1.4 1999-05-06 02:11:14 motoyuki Exp $ -->
<!-- The FreeBSD Japanese Documentation Project -->
<!-- Original revision: 1.3 -->
<!-- Original revision: 1.4 -->
<sect>
<heading>商用アプリケーション<label id="commercial"></heading>
@ -19,7 +19,63 @@
<sect1>
<heading>FreeBSD 用の Motif はどうやったら手に入りますか</heading>
<p>FreeBSD 用の Motif 2.0 に関する情報は
<p>FreeBSD 用の ELF 版 Motif 2.1 に関する情報は
<ref id="apps2go" name="Apps2go"> から
手に入れることができます.<label id="apps2go">
<p>この製品は以下の物が含まれています:
<itemize>
<item>OSF/Motif manager, xmbind, panner, wsm.
<item>uil, mrm, xm, xmcxx, インクルードファイルや Imake
ファイルといった開発者向けキット
<item>FreeBSD 3.0 以降で利用できる ELF 版スタティックライブラリ,
およびダイナミックライブラリ
<item>デモンストレーションプログラム
</itemize>
<p>注文する際には FreeBSD 用の Motif であることをきちんと
確認してください. NetBSD や OpenBSD 用の Motif もまた, <em>Apps2go</em>
から販売されています. 現在, FTP によるダウンロードのみ利用可能です.
<descrip>
<tag/より詳しい情報は/
<url url="http://www.apps2go.com/" name="Apps2go WWW page">
<tag/問い合わせは/ <url url="mailto:sales@apps2go.com" name="Sales"> または
<url url="mailto:support@apps2go.com" name="Support"> 電子メールアドレス.
<tag/もしくは/ phone (817) 431 8775 or +1 817 431-8775
</descrip>
<p>他の FreeBSD 用 Motif 2.1(ELF 版, a.out 版) に関する情報は
<ref id="metrox" name="Metro Link"> から手に入れることができます.
<p>この製品は以下の物が含まれています:
<itemize>
<item>OSF/Motif manager, xmbind, panner, wsm.
<item>uil, mrm, xm, xmcxx, インクルードファイルや Imake
ファイルといった開発者向けキット
<item>スタティックライブラリ, およびダイナミックライブラリ.
(FreeBSD 3.0 以降で利用できる ELF 版か,
FreeBSD 2.2.8 以前で利用できる a.out 版を指定して下さい)
<item>デモンストレーションプログラム
<item>整形済みのマニュアルページ
</itemize>
<p>注文する際には FreeBSD 用の Motif であることをきちんと
確認してください. Linux 用の Motif も <em>Metri Link</em>
から販売されています. 現在, CDROM および FTP
によるダウンロードが利用可能です.
<p>FreeBSD 用の a.out 版 Motif 2.0 に関する情報は
<ref id="xig" name="Xi Graphics"> から
手に入れることができます.
@ -30,7 +86,8 @@
<item>uil, mrm, xm, xmcxx, インクルードファイルや Imake
ファイルといった開発者向けキット
<item>スタティックライブラリ, およびダイナミックライブラリ
<item>FreeBSD 2.2.8 以前のバージョンで利用できるスタティックライブラリ,
およびダイナミックライブラリ
<item>デモンストレーションプログラム
@ -38,7 +95,7 @@
</itemize>
<p>注文する際には FreeBSD 用の Motif であることをきちんと
確認してください. BSDI や Linux 用の Motif も <em>Xi Graphics</em>
確認してください. BSDI や Linux 用の Motif もまた, <em>Xi Graphics</em>
から販売されています. 現在フロッピーディスク 4枚組ですが,
将来的には CDE のように統合された CD に変わるでしょう.
@ -48,24 +105,48 @@
<p>FreeBSD 用の CDE 1.0.10 に関する情報は
<ref id="xig" name="Xi Graphics"> から
手に入れることができます. これは Motif 1.2.5 を含んでおり,
Motif 2.0 と一緒に使用することができます.
a.out 版 Motif 2.0 と一緒に使用することができます.
<p>これは FreeBSD 用と Linux 用の統合された CD-ROM です.
<p>これは FreeBSD と Linux の両方に対応した CD-ROM で配布されているものです.
<sect1>
<heading>
高機能な商用 X サーバってあるんですか?<label id="xig">
高機能な商用 X サーバってあるんですか?
</heading>
<p>はい, <url url="http://www.xig.com" name="Xi Graphics">
<p>はい, <url url="http://www.xig.com" name="Xi Graphics"> と
<url url="http://www.metrolink.com" name="Metro Link">
から, FreeBSD ほか Intel ベースのシステムで動作する
Accelerated-X という製品が販売されています.
<label id="xig">
<p>この高性能な X サーバは楽に設定をおこなえるほか, 数多くのビデオボード
<p>Metro Link は, FreeBSD のパッケージ操作ツールを利用することで
容易に設定が行なえるほか, 数多くのビデオボードをサポートした
高機能な X サーバを提供しています. 配布はバイナリ形式のみで,
FTP が利用可能です. もちろん, とても安価($39)に手に入れることができます.
<label id="metrox">
<p>また, Metro Link は ELF 版, a.out 版の FreeBSD 用 Motif
も販売しています(前を参照).
<descrip>
<tag/より詳しい情報は/
<url url="http://www.metrolink.com/" name="Metro Link WWW page">
<tag/問い合わせは/ <url url="mailto:sales@metrolink.com" name="Sales">
または
<url url="mailto:tech@metrolink.com" name="Support"> 電子メールアドレス
<tag/もしくは/ phone (954) 938-0283 or +1 954 938-0283
</descrip>
<p>Xi Graphics が提供している高性能な X サーバは楽に設定をおこなえるほか,
数多くのビデオボード
をサポートしています. サーバはバイナリのみが含まれます.
FreeBSD 用と Linux 用の統合されたフロッピーディスクに入っています.
Xi Graphics は Laptop サポートに特化した高性能 X サーバも提供しています.
<p>バージョン 3.1 の「互換デモ」が無料で入手できます.
<p>バージョン 5.0 の「互換デモ」が無料で入手できます.
<p>また Xi Graphics は FreeBSD 用の Motif と CDE も販売しています (前を参照).

89
ja_JP.eucJP/FAQ/hackers.sgml
View file

@ -1,6 +1,6 @@
<!-- $Id: hackers.sgml,v 1.8 1999-03-01 17:18:52 motoyuki Exp $ -->
<!-- $Id: hackers.sgml,v 1.9 1999-05-06 02:11:14 motoyuki Exp $ -->
<!-- The FreeBSD Japanese Documentation Project -->
<!-- Original revision: 1.12 -->
<!-- Original revision: 1.15 -->
<sect>
<heading>まじめな FreeBSD ハッカーだけの話題<label id="hackers"></heading>
@ -52,7 +52,7 @@
<p>次に, CVS リポジトリ全体を手元においておく必要があります.
これを入手するには
<url url="../handbook/cvsup.html" name="CVSUP">
<url url="../handbook/synching.html#CVSUP" name="CVSUP">
が使用できますが, supfile で release の名称を cvs にして
他のタグや date フィールドを削除する必要があります:
@ -138,10 +138,12 @@
<sect1>
<heading>
インターネットアクセスに制限があっても current を追いかけられますか? <label id="ctm">
インターネットアクセスに制限があっても current を追いかけられますか?
<label id="ctm">
</heading>
<p>はい, <url url="../handbook/ctm.html" name="CTM システム ">を使って
<p>はい, <url url="../handbook/synching.html#CTM" name="CTM システム ">を
使って
ソースツリー全体のダウンロードを<tt/おこなわず/に追いかけることができます.
<sect1>
@ -502,4 +504,81 @@ Cc: current@FreeBSD.ORG
name="ELF リンカ"> に <tt>-export-dynamic</tt> オプションを
付けて実行形式をリンクする必要があります.
</sect1>
<sect1>
<heading>カーネルアドレス空間を大きくしたり、小さくするにはどうしたら良いのですか?</heading>
<p>
カーネルアドレス空間は, FreeBSD 3.x 上で
256MB, FreeBSD 4.x 上で 1GB がデフォルトになっています.
負荷の高いネットワークサーバ(例えば大きな FTP, HTTP サーバ)を運用する場合は,
256MB では足りないことに気付くかも知れません.
<p>
では, アドレス空間を大きくするにはどうしたら良いのでしょうか?
それには, 二つの段階を踏みます. まず,
より大きいアドレス空間を割り当てることをカーネルに知らせる必要があります.
次に, カーネルはアドレス空間の先頭にロードされるため,
アドレスの先頭が天井(訳注:カーネルアドレス空間の最下端アドレスのこと)と
ぶつかることのないように, ロードアドレスを今までより低位に設定する必要があります.
<p>
最初の段階は, <tt>src/sys/i386/include/pmap.h</tt> にある
<tt/NKPDE/ の値を増加させることで行ないます.
ここに 1GB のアドレス空間にするために, どのようにすれば良いかを示します.
<verb>
#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
</verb>
<p>
正確な <tt/NKPDE/ の値を計算するには,
望みのアドレス空間の大きさ(メガバイト単位)を 4 で割って,
それから UP のために 1, SMP のために 2 を引き算して下さい.
<p>
次の段階を行なうには, ロードアドレスを正確に計算することが必要です.
単純に, アドレス空間の大きさ(バイト単位)を 0x100100000 から引き算して下さい.
1GB アドレス空間の場合, その結果は 0xc0100000 になります.
そして, <tt>src/sys/i386/conf/Makefile.i386</tt> にある <tt/LOAD_ADDRESS/
に, 今計算した値を入れます. また, 次のように
<tt>src/sys/i386/conf/kernel.script</tt> のセクションの始めの方にある
ロケーションカウンタにも同じ値を入れて下さい.
<verb>
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) }
</verb>
<p>
それが完了したら, config し直してカーネルを再構築して下さい.
おそらく, <tt/ps(1)/, <tt/top(1)/ などに不具合が出るでしょう.
それらを正常にするために, <tt/make world/ (もしくは,
変更した <tt/pmap.h/ を <tt>/usr/include/vm/</tt>
にコピーした後に, <tt/libkvm/, <tt/ps/ および <tt/top/ を
手動で再構築すること)を行なうべきです.
<p>
注意: カーネルアドレス空間の大きさは, 4 メガバイトの倍数である必要があります.
<p>
[<url url="mailto:dg@freebsd.org" name="David Greenman">
による補足: <em> カーネルアドレス空間は 2 の乗数である必要があると思いますが,
それが確かなことかどうかははっきりしていません.
昔の起動コードには, 良く高位アドレスビットのトリックが使われていたため,
少なくとも 256MB の粒度であることが想定されていたと思います.]</em>
</sect>

301
ja_JP.eucJP/FAQ/network.sgml
View file

@ -1,6 +1,6 @@
<!-- $Id: network.sgml,v 1.10 1998-10-05 15:43:29 motoyuki Exp $ -->
<!-- $Id: network.sgml,v 1.11 1999-05-06 02:11:15 motoyuki Exp $ -->
<!-- The FreeBSD Japanese Documentation Project -->
<!-- Original revision: 1.15 -->
<!-- Original revision: 1.22 -->
<sect>
<heading>ネットワーキング<label id="networking"></heading>
@ -118,7 +118,7 @@
<item><url url="../handbook/ppp.html"
name="ハンドブックの PPP (kernel バージョン) の節">
<item><url url="../handbook/userppp.html"
<item><url url="../handbook/ppp-and-slip.html#USERPPP"
name="ハンドブックの PPP (user モードバージョン) の節">
</itemize>
@ -153,7 +153,7 @@
</heading>
<p>まず <htmlurl url="http://www.freebsd.org/cgi/man.cgi?ppp"
name="ppp"> のマニュアルと, <url url="../handbook/userppp.html"
name="ppp"> のマニュアルと, <url url="../handbook/ppp-and-slip.html#USERPPP"
name="ハンドブックの ppp のセクション">を読んでみましょう. 次に,
<verb>
@ -247,7 +247,7 @@ default 10.0.0.2 UGSc 0 0 tun0
<p>の行をうっかり消してしまった可能性があります.
この場合は, ハンドブックの
<url url="../handbook/userppp:final.html"
<url url="../handbook/ppp-and-slip.html#USERPPP-FINAL"
name="システムの最終設定"> の項を読み直してください.
<sect2>
@ -273,7 +273,7 @@ default 10.0.0.2 UGSc 0 0 tun0
</verb>
<p>詳しい情報については, ハンドブックの
<url url="../handbook/userppp:dynamicIP.html"
<url url="../handbook/ppp-and-slip.html#USERPPP-DYNAMICIP"
name="PPP と動的 IP 設定"> の項を参照してください.
<sect2>
@ -336,13 +336,93 @@ default 10.0.0.2 UGSc 0 0 tun0
<p>詳しくはお使いのモデムのマニュアルをご覧ください.
<sect2>
<heading>接続が不規則にハングアップしてしまう</heading>
<p>たくさんの人が, 原因不明のハングアップを経験しています.
検証のために必要なのは, まずどちら側のリンクでそれが起こっているか,
ということです.
<p>外部接続型モデムを利用しているなら, 単に <tt/ping/ を使うことで,
データを送信するときに <tt/TD/ ランプが点灯するかどうかを確認することができます.
もし, <tt/TD/ ランプが点灯して, <tt/RD/ ランプが点灯しなければ,
問題は回線の向こう側にあります. <tt/TD/ が点灯しなければ,
問題は回線のこちら側です. 内蔵型モデムの場合, <tt/ppp.conf/ ファイルに
<tt/set server/ コマンドを入れる必要があるでしょう.
回線が切断されたとき, pppctl を使って ppp に接続してください.
そのとき, ネットワーク接続が急に復旧(診断ソケットへのアクセスで,
ppp が復活します)するか, もしくは接続自体が全くできない
(ただし, ppp 起動時に <tt/set socket/
コマンドがちゃんと実行されているとします)としたら,
問題は回線のこちら側です. もし, 接続可能で, かつ状況が変化しなければ,
<tt/set log local async/ を使ってローカル非同期ログ(async logging)を有効にし,
<tt/ping/ を他のウィンドウかターミナルから使ってください.
非同期ログには, こちら側のリンクの送受信データが記録されます.
もし, データが送信されたにもかかわらず返って来ていなければ,
問題は回線の向こう側にあることになります.
<p>問題が回線のどちら側かにあることが分かったら,
つぎの二つの可能性が考えられるでしょう.
<sect3>
<heading>回線の向こう側での反応がない</heading>
<p>これに対処できることはほとんどありません. 大部分の ISP
は, Microsoft 社製 OS 以外の利用者に対してのサポートを拒否するでしょう.
<tt/ppp.conf/ ファイルの中に <tt/enable lqr/ を記述することで
ppp が回線の向こう側で発生するハングアップを検出することができますが,
この検出は比較的遅いため, あまり役に立ちません. また, あなたは
user-ppp を利用していることを ISP に知られたくないと思うかも知れませんね.
<p>まず最初に, こちら側の圧縮機能を全て無効にしてみて下さい.
それには, 設定ファイルをつぎのようにします.
<verb>
disable pred1 deflate deflate24 protocomp acfcomp shortseq vj
deny pred1 deflate deflate24 protocomp acfcomp shortseq vj
</verb>
<p>そして再接続し, 変更前と同じように通信できることを確認します.
もしこれによって状況が改善されるか, 完全に解決したら,
(上の設定のうち)どの設定で状況が変化したのかを,
色々な組合せで試してみて下さい. これは, ISP
に問い合わせを行なうときの有効な情報となります(ただし,
あなたが Microsoft 社製品以外のものを利用していることも
明らかにしてしまいますが).
<p>ISP に問い合わせを行なう前に, こちら側の非同期ログを有効にして,
接続がハングアップするまで待って下さい. この作業は,
非常に多くのディスク空間を消費するかも知れません.
興味の対象となっているのは, 通信ポートから最後に読み込まれたデータです.
それは通常 ASCII データで, 問題点の詳細(``Memory fault, core dump''など)が
記載されている可能性があります.
<p>回線の向こう側で通信ログを監視することは可能なはずですので,
ハングアップが発生した時, ISP の対応が好意的ならば
どうして ISP 側で問題が発生したのかこちらに伝えてくれるかも知れません.
<url url="mailto:brian@Awfulhak.org" name="brian@Awfulhak.org">
まで詳細を送って頂くか, ISP に直接私に連絡するように伝えて下さっても構いません.
<sect3>
<heading>ppp がハングアップする</heading>
<p>ベストな方法は, <tt/CFLAGS+=-g/ と <tt/STRIP=/ を ppp の Makefile
に追加して, ppp を再構築し, そして
<tt/make clean &amp;&amp; make &amp;&amp; make install/ を行なうことです.
ppp がハングアップした時, <tt/ps ajxww | fgrep ppp/ を使って ppp
のプロセス ID を調べ, <tt/gdb ppp PID/ を実行して下さい.
gdb のプロンプトから, <tt/bt/ を使ってスタックをトレースすることができます.
<p>スタックトレースの結果は, <url url="mailto:brian@Awfulhak.org"
name="brian@Awfulhak.org"> まで送って下さい.
<sect2>
<heading>Login OK! のメッセージが出た後, 何も起こらない</heading>
<p>2.2.5 より前のリリースの FreeBSD では,
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?ppp"
name="ppp"> はリンクが確立した後, 接続先が Line Control Protocol (LCP)
を発信するのを待ちます. しかし, 多くの ISP ではネゴジェーションを
を発信するのを待ちます. しかし, 多くの ISP ではネゴシエーションを
自分からは起こさず, クライアントが起こすのを待っています.
<bf/ppp/ に強制的に LCP を発信させるには, 次の命令を使います.
@ -505,7 +585,7 @@ default 10.0.0.2 UGSc 0 0 tun0
enable lqr
</verb>
<p>こうすると, 接続先がネゴジェーションを行う場合, デフォルトで
<p>こうすると, 接続先がネゴシエーションを行う場合, デフォルトで
LQR の使用を受け入れるようになります.
<sect2>
@ -729,49 +809,65 @@ default 10.0.0.2 UGSc 0 0 tun0
理由やそのアドレス, 関連した変数の値なども調べる事ができるでしょう.
<sect2>
<heading>
auto modeでdialをするようなprocessがconnectしてくれない
</heading>
<heading>auto mode でダイアルをするようなプロセスが接続されない</heading>
<p>これは<bf/ppp/が動的なlocalのIP numberを相手とnegotiateする
ように設定されている時のknown problemです. 最初のプログラムが
<p>これは <bf/ppp/ がローカル側の IP アドレスを,
動的に通信相手と交渉するように設定されている時に発生する
良く知られた障害でした. 最新のバージョンでは,
この問題は修正されています.
<bf/iface/ をマニュアルページから検索してみて下さい.
これは, 最初のプログラムが
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?connect"
name="connect(2)">を呼び出した時, tun intergaceのIP numberが
socketのendpointに割り当てられます. kernelは最初に外へ出ていく
packetを作り, それをtunデバイスへ書きます. 次に<bf/ppp/はpacket
を読んで接続を確立します. <bf/ppp/の動的IP割り当ての結果として,
interfaceのアドレスは変わりますので, 一番最初のsocketのendpoint
のは無効になります. そしてそれ以降相手に送られるpacketは落とされ
てしまいます. 仮にそうでないとしても, 既にIP numberは変更されて
いるので, どんな返事も始めのmachineには戻ってきません.
name="connect(2)"> を呼び出した時, tun インターフェイスの IP
アドレスが, ソケットの終端に割り当てられてしまうという問題です.
カーネルは, 外へ出ていく最初のパケットを作り, それを tun デバイスへ書き込みます.
そして <bf/ppp/ は, そのパケットを読み込んで接続を確立します.
<bf/ppp/ は動的に IP アドレスを割り当てるため,
もしインターフェイスのアドレスが変化してしまうと,
最初に割り当てられたソケット終端の IP アドレスは無効になってしまいます.
そのため, それ以降相手に送られる全てのパケットは通常,
相手に届くことはないでしょう. もし仮に届いたとしても,
既にこちらの IP アドレスは変更されているので,
どんな反応も最初のマシンには戻ってきません.
<p>この問題に対処する理論的な方法がいくつかあります. もし可能なら,
相手が同じIP numberを割り当てなおす事ができるのが最も良いです<tt/:-)/
相手が再度, 同じ IP アドレスを割り当ててくれることが一番です <tt/:-)/
<bf/ppp/ の現在のバージョンはこれを行ないますが,
他のほとんどの実装はそういった動作をしません.
<p>我々の側から対処できる最も簡単な方法は, tun interfaceのIP
numberを固定する事ですが, かわりに外に出ていくpacketを変更して
source IP numberをinterfaceのIPからnegotiateされたIPに書きかえる
事によっても対処できます. これが,
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?libalias"
name="libalias(3)"> (およびpppの<bf/-alias/ switch)の行っている
方法です.
<p>我々の側から対処できる最も簡単な方法は, tun インターフェイスの
IP アドレスを固定する事です. またそのかわりに,
外に出ていくパケットを変更して, 発信元 IP アドレスをインターフェイスの IP
アドレスから, 交渉によって得られた IP アドレスに,
適宜書きかえる事によっても対処できます. こ
これは, 基本的に <bf/ppp/ の最新バージョンにある <tt/iface-alias/ オプションが
行なっていることと同じです(<htmlurl url="http://www.freebsd.org/cgi/man.cgi?libalias"
name="libalias(3)"> および, ppp の <bf/-alias/
スイッチにも関係します). それは, 以前の IP アドレスを全て管理し,
それらを最後の交渉によって得られた IP アドレスの別名として扱えるようにします.
<p>もう1つの(最も確かな)方法は, 全てのbindされているsocketの
IPを変更するようにsystem callを実装する事です. <bf/ppp/は,
新しくIP numberがnegotiateされた時に, このsystem callを用いて
全てのsocketを書きかえるのです.
<p>もう 1 つの(おそらく最も信頼できる)方法は, bind された
全てのソケットの IP アドレスを,
異なるものに変更できるシステムコールを実装することです.
<bf/ppp/は, 交渉によって新しい IP アドレスを得た時,
このシステムコールを用いて実行されているプログラムにある,
全てのソケットを書きかえてやるわけです.
同じシステムコールが, DHCP クライアントが利用するソケットを
強制的に再 bind するのにも使うことができるでしょう.
<p>3つ目の方法は, interfaceをIP number無しで立ち上げる事を許す
ことです. 外に出ていくpacketは最初のSIOCAIFADDR ioctlが終わるまで
は255.255.255.255というIP numberを与えられます. これによって
socketを完全にbindすることができます. <bf/ppp/に対してsource IP
numberを変更させる事になりますが, もしそれが255.255.255.255になって
おり, IP numberとIP checksumだけ変更すれば良ければの話になります.
しかし, この方法は, 他の部分の仕組みが古い物との互換性を持つよう
変更されてしまった場合には, kernelが適切に設定されていないinterface
に対して悪いpacketを送信してしまいます.
<p>現在のところ, これらの方法のどれもまだ実装されていません.
<p>3 つ目の方法は, IP
アドレスを指定しないでインターフェイスを利用できるようにすることです.
外に出ていくパケットは, 最初の SIOCAIFADDR ioctl の完了まで,
255.255.255.255 という IP アドレス が与えられます.
これによって. ソケットは常に bind することができます.
<bf/ppp/に対して発信元 IP アドレスを変更させる事になりますが,
もしそれが 255.255.255.255 になっていたら, IP アドレスと
IP チェックサムだけ変更すれば良ければの話になります.
この方法はちょっとした変更ですが, 他の機構が今までのように, IP
アドレスを固定して利用する場合に, カーネルが
不適切に設定されたインターフェイスに向けて, 正常でないパケットを
送り出してしまう可能性があります.
<sect2>
<heading>何故ほとんどのゲームが -alias スイッチ付きだと動かないんですか?</heading>
@ -1054,90 +1150,94 @@ default 10.0.0.2 UGSc 0 0 tun0
<sect1>
<heading>すべてのネットワークの操作に対して ``Permission denied'' というメッセージが表示されるのですが. </heading>
<p><tt/IPFIREWALL/オプションを付けてkernelをコンパイルした場合には,
<p><tt/IPFIREWALL/ オプションを付けてカーネルをコンパイルした場合には,
2.1-STABLE の開発の途中から変更になった 2.1.7R の標準的な方針として,
明示的に許可されていないすべてのパケットは落とされる設定
になっている事を覚えておいてください.
<p>もしfirewallの設定を間違えた場合にネットワークの操作が再びできる
ようにするには, root で login して次のコマンドを実行してください.
<p>もしファイアウォールの設定を間違えた場合にネットワークの操作が再びできる
ようにするには, root でログインして次のコマンドを実行してください.
<verb>
ipfw add 65534 allow all from any to any
</verb>
<p><tt>/etc/rc.conf</tt>に"firewall_type='open'"を追加してもよい
<p><tt>/etc/rc.conf</tt> に "firewall_type='open'" を追加してもよい
でしょう.
<p>FreeBSD の firewall の設定についての情報は
<p>FreeBSD のファイアウォールの設定についての情報は
<url url="../handbook/firewalls.html" name="FreeBSD ハンドブック">
にあります.
<sect1>
<heading>IPFWのオーバーヘッドはどのくらいでしょうか?</heading>
<heading>IPFW のオーバーヘッドはどのくらいでしょうか?</heading>
<p>この答えはあなたのrule setとprocessorのスピードによって
ほとんど決まります. Ethernetに対して少しのrule setだけを使っ
<p>この答えはあなたのルールセットとプロセッサのスピードによって
ほとんど決まります. イーサネットに対して少しのルールセットだけを使っ
ているほどんどの場合には, その影響は無視できる程度です. 実
際の測定値を見ないと満足できない方々のために, 実際の測定結
果をお見せしましょう.
<p>次の測定は486-66上で2.2.5-STABLEを使用しておこなわれました.
IPFWは変更が加えられて, <tt/ip_fw_chk/ルーチン内でかかる時間を
測定して1000パケット毎に結果をconsoleに表示するようになっています.
<p>次の測定は 486-66(訳注: Intel 社製 CPU i486, 66MHz のこと)上で
2.2.5-STABLE を使用しておこなわれました.
IPFW は変更が加えられて, <tt/ip_fw_chk/ ルーチン内でかかる時間を
測定して 1000 パケット毎に結果をコンソールに表示するようになっています.
<p>それぞれ1000ずつのruleが入っている2つのrule setでテストが
おこなわれました. ひとつ目のsetは最悪のケースを見るために
<p>それぞれ 1000 ずつのルールが入っている 2 つのルールセットでテストが
おこなわれました. ひとつ目のルールセットは最悪のケースを見るために
<verb>
ipfw add deny tcp from any to any 55555
</verb>
というruleを繰り返したものです.
というルールを繰り返したものです.
<p>このsetを用いますと, (port番号によって) packetが全てのruleにマッチ
しない事が最終的に決まるまでに, IPFWのpacketをチェックするルーチン
のほとんど全てが実行されますので, 最悪のケースとなります. この
ruleを999個繰り返した後に<tt>allow ip from any to any</tt>が
<p>パケットが(ポート番号のせいで)このルールにマッチしないことがわかるまでに,
何度も実行される IPFW のパケットチェックルーチンによって,
これは最悪のケースを示します.
このルールを 999 個繰り返し並べた後に <tt>allow ip from any to any</tt>が
書かれています.
<p>2つ目のsetは, なるべく早くチェックが終了するように書かれたものです:
<p>2つ目のルールセットは, なるべく早くチェックが終了するように書かれたものです:
<verb>
ipfw add deny ip from 1.2.3.4 to 1.2.3.4
</verb>
<p>このruleではsource側のIPアドレスがマッチしないのでチェックは
すぐに終了します. 上のsetとおなじように, 1000個目のruleは
<p>このルールでは, 発信元の IP アドレスがマッチしないのでチェックは
すぐに終了します. 上のルールセットとおなじように, 1000 個目のruleは
<tt>allow ip from any to any</tt>です.
<p>1つ目のsetでは, packetあたりのoverheadはだいたい2.703ms/packet,
言いかえると1つのruleあたり2.7マイクロ秒です. したがってこのruleに
おけるpacketを処理する時間の理論的な限界は1秒あたり約370 packetです.
10MbpsのEthernetで1500 byte以下のpacketサイズを仮定すると, 55.5%の
バンド幅までしか使えない事になります.
<p>1 つ目のルールセットでは, パケットあたりのオーバヘッドはおよそ
2.703ms/packet, これはだいたい 1 つのルールあたり 2.7 マイクロ秒
かかっていることになります.
したがって, このルールにおけるパケット処理時間の理論的な限界は,
毎秒約 370 パケットです.
10Mbps のイーサネットで 1500 バイト以下のパケットサイズを仮定すると,
バンド幅の利用効率は 55.5% が限界となることになります.
<p>2つ目のsetでは, それぞれのpacketはだいたい1.172msで処理されて
いますので1つのruleあたり1.2マイクロ秒となります. packetの
処理時間の理論的な限界はだいたい1秒あたり853 packetとなりますので
<p>2 つ目のルールセットでは, それぞれのパケットがおよそ
1.172msで処理されていますので, だいたい 1 つのルールあたり 1.2 マイクロ秒
かかっていることになります.
パケット処理時間の理論的な限界は, 毎秒約 853 パケットとなりますので,
10Mbps Ethernetのバンド幅を使い切ることができます.
<p>このテストでのruleの数は多過ぎますので, 実際に使用している際の
<p>このテストでのルール数は多過ぎるため, 実際に使用する際の
結果を反映している訳ではありません. これらは上に示した数値を出す
ためだけに用いられたものです. 実際に効率の良いrule setを作るために
は, 次のような事を考えておけばよいでしょう.
ためだけに用いられたものです. 効率の良いルールセットを作るためには,
次のような事を考えておけばよいでしょう.
<itemize>
<item>`確定している' ruleは, TCPのtrafficの多数を処理するために
前の方に持ってきてください. そしてこのruleの前には<tt>allow tcp</tt>
という記述をしないでください.
<item>`確定している' ルールは先頭の方に持ってきてください.
これは, 多数の TCP のトラフィックがこのルールで処理されるためです.
そしてこのルールの前には <tt>allow tcp</tt> という記述を置かないでください.
<item>良く使われるruleを, あまり良く使われないruleよりも
前の方に(もちろん<bf>firewallの許可の設定を変えない範囲で</bf>)
<item>良く使われるルールを, あまり良く使われないルールよりも
前の方に(もちろん<bf>ファイアウォールの許可設定を変えない範囲で</bf>)
持ってきてください.
<tt>ipfw -a l</tt>のようにしてpacket数の統計を取ることによって
どのruleが最もよく使われているかが分かります.
<tt>ipfw -a l</tt> のようしてパケット数の統計を取ることで,
どのルールが最もよく使われているかを調べることができます.
</itemize>
@ -1147,7 +1247,7 @@ default 10.0.0.2 UGSc 0 0 tun0
<p>FTP などのサービスのリクエストは, 'socket' パッケージを利用
してリダイレクトできます. 'socket' パッケージは ports の
'sysutils' カテゴリに含まれています. リダイレクトしたいサービ
ス(<tt>/etc/inet.conf</tt>のコマンド行を socket を呼ぶように変
ス(<tt>/etc/inet.conf</tt>のコマンド行をソケットを呼ぶように変
更してください. 変更例:
<verb>
@ -1157,4 +1257,35 @@ ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.foo.com ftp
<p>ここで 'ftp.foo.com' はリダイレクト先のホスト名, 行の最後の'ftp'
はポートです.
<sect1>
<heading>バンド幅の管理を行なえるツールはどこで手に入れられますか?</heading>
<p>FreeBSD 用のバンド幅管理ツールには, 無料で手に入れられる
<url url="http://www.csl.sony.co.jp/person/kjc/programs.html"
name="ALTQ"> と,
<url url="http://www.etinc.com" name="Emerging Technologies">
から入手できる Bandwidth Manager という市販のものの 2 種類があります.
<sect1>
<heading>なぜ ``/dev/bpf0: device not configured" が出るのでしょうか?</heading>
<p>バークレーパケットフィルタ<htmlurl
url="http://www.FreeBSD.org/cgi/man.cgi?bpf" name="(bpf)">
ドライバは, それを利用するプログラムを実行する前に有効にしておく必要があります.
カーネルコンフィグファイルに, 次のように追加してカーネルの再構築をして下さい.
<verb>
pseudo-device bpfilter # Berkeley Packet Filter
</verb>
<p>そして再起動してから, 次にデバイスノードを作成する必要があります.
これは, 次のように入力し, <tt>/dev</tt> を変更することで行ないます.
<tscreen><verb>
# sh MAKEDEV bpf0
</verb></tscreen>
<p>デバイスノードの作成の詳細は, <htmlurl url="../handbook/kernelconfig-nodes.html"
name="FreeBSD ハンドブックのデバイスノードに関する節"> を参照して下さい.
</sect>

115
ja_JP.eucJP/FAQ/troubleshoot.sgml
View file

@ -1,6 +1,6 @@
<!-- $Id: troubleshoot.sgml,v 1.4 1998-07-21 07:57:10 hanai Exp $ -->
<!-- $Id: troubleshoot.sgml,v 1.5 1999-05-06 02:11:15 motoyuki Exp $ -->
<!-- The FreeBSD Japanese Documentation Project -->
<!-- Original revision: 1.5 -->
<!-- Original revision: 1.9 -->
<sect>
<heading>トラブルシューティング<label id="troubleshoot"></heading>
@ -28,18 +28,81 @@
ARRE (Auto Read Reallocation Enbld): 1
</verb>
<p>他の種類のディスクでは, オペレーティングシステムからサポート
されているかによります. 残念ながら, この目的のために FreeBSD
が提供する ``bad144'' コマンドはかなり手を入れる必要があります...
<p>以下は, <url url="mailto:tedm@toybox.placo.com" name="Ted Mittelstaedt">
から寄せられたものです.
<p>IDE ディスクは, おそらく不良ブロックの再マップを内蔵していると
思います; ディスクの説明書がある場合は, この機能が無効になって
いるかを確認するとよいでしょう. しかし, ESDI, RLL, ST-506
ディスクは, 通常これをおこないません.
<p>IDE ドライブの場合は通常, 不良ブロックは潜在的な障害の兆候です.
最近の IDE ドライブは, 内部の不良ブロック再マッピング機能を有効にした状態で
出荷されています. また, 今日の IDE ハードディスクメーカは,
出荷以降に不良ブロックが発生することに関して保証を提供していて,
不良ブロックのあるディスクドライブを交換するサービスを行なっています.
<p>再マップが可能になっていて不良ブロックを見つけたのであれば,
ドライブを交換することを考えましょう. 不良ブロックの状態は時間と
ともに悪い方向にしか行きません.
<p>もし, 不良ブロックのある IDE ディスクドライブを復旧しようと思うなら,
IDE ドライブメーカが提供する IDE 診断プログラムをダウンロードして,
そのドライブに使ってみてください. この種のプログラムは大抵,
ドライブの制御部分に対して不良ブロックを再走査し,
不良ブロックを使用不能にするようにセットすることができます.
<p>ESDI, RLL および MFM ドライブの場合, 不良ブロックはドライブの
正常な部分であり, 一般的に言って障害を表すものではありません.
PC では, ディスクドライブコントローラカードと BIOS が不良ブロックの
使用不能化の作業を行ないます. DOS など, ディスクアクセスに BIOS
を経由する OS にとっては有効に働きますが, FreeBSD
のディスクドライバは BIOS を利用しません. そのため,
代替として bad144 という機構が存在します.
bad144 は, wd ドライバにだけ作用し, SCSI ドライバに利用することは
*できません*. bad144 は, 検出された不良セクタをスペシャルファイルに
記録するという働きを持っています.
<p>bad144 を利用する上で, 注意しなければならない点が一つあります.
それは, 不良ブロックスペシャルファイルは, ディスクの最終トラックに
置かれるということです. このファイルには, ディスクの先頭の付近,
/kernel ファイルが位置しているであろう部分で発生した不良セクタが
記録されています. したがって, このファイルは BIOS コールを使って
カーネルファイルを読み込む起動プログラムがアクセス可能でなければなりません.
これはつまり, bad144 を利用するディスクは, 1024 シリンダ,
16 ヘッド, 63 セクタを超えてはならないということを意味し,
bad144 を利用したディスクが実質 500MB を超えられないことになります.
<p>bad144 を使うには, FreeBSD のインストール時に表示される fdisk 画面で,
"Bad Block" 走査を ON に設定するだけです. これは, FreeBSD 2.2.7 以降で
機能します. ディスクは, 1024 シリンダ以内でなければなりません.
ディスクドライブは事前に少なくとも 4 時間, ディスクが温度によって膨張し,
トラックに曲がりが出るまで回転させることをお薦めします(訳注: 温度変化に
対する膨張によって, ディスクが微小変形することにより発生する不良セクタを
確実に検出するためです).
<p>大容量の ESDI ドライブのように, 1024 シリンダを超えるディスクの場合,
DOS 上でそのディスクが利用できるように, ESDI コントローラは特殊な変換モードを
利用します. fdisk の "set geometry" コマンドを使って
"変換された(translated)" ジオメトリに切替えると, wd ドライバは
この変換モードを解釈できます.
その際, FreeBSD パーティションを作成するのに "dangerously dedicated" モードを
利用してはいけません. このモードは, そのようなジオメトリを無視するからです.
たとえ fdisk がオーバーライドされたジオメトリ情報を使ったとしても,
已然としてディスクの真の大きさを保持しているため, 大きすぎる FreeBSD
パーティションを作成しようとしてしまうでしょう.
ディスクジオメトリ情報が変換されたジオメトリ情報にかわっている場合は,
手動でブロック数を入力し, パーティションを作成する必要があります.
<p>大容量の ESDI ディスクを ESDI コントローラでセットアップするには,
ちょっとしたトリックを使います. まず, DOS のディスクで起動して
そのディスクを DOS パーティションとしてフォーマットします.
そして FreeBSD を起動し, インストーラの fdisk 画面で
DOS パーティションのブロックサイズとブロック数を読みとり, メモしておきます.
ジオメトリ情報を DOS が利用しているものと同一に再設定し,
DOS パーティションを削除して "cooperative" FreeBSD パーティションを
先程記録したブロックサイズを使って作成して下さい.
そのパーティションを起動可能パーティションに設定し, 不良ブロック走査を
有効にして下さい. 実際のインストールでは, ファイルシステムが作成される前に
bad144 が最初に実行されます(Alt-F2 を押すことで状況を確認できます).
不良セクタファイルを作成中に何らかの障害が発生したなら,
システムを再起動して, もう一度最初からやり直しになります.
おそらくディスクジオメトリ情報の設定を大きくしすぎているのでしょう.
(やり直しは, DOS によるフォーマットとパーティション確保を含みます)
<p>もし, 不良ブロックの再マッピングを有効にしていて不良ブロックが見付かったら,
ドライブの交換を考えて下さい. 不良ブロックは, 時間とともに悪化するからです.
<sect1>
<heading>Bustek 742a EISA SCSI が認識されません.</heading>
@ -450,5 +513,33 @@
します. (訳注: 日本語が必要な場合は <tt>kterm</tt> 等を
利用します)
</itemize>
<sect1>
<heading>私のマシンで "calcru: negative time..." と表示されるのですが</heading>
<p>これは, 割り込みに関連するさまざまな不具合によって発生します.
あるいは, あるデバイスが元々持っているバグが表面化したのかも知れません.
この症状を再現させる一つの方法として, パラレルポート上で,
TCP/IP を 大きな MTU で走らせるというものがあります.
グラフィックアクセラレータがこの症状を起こすことがありますが,
その場合はまず, カードの割り込み設定を確認して下さい.
<p>この問題の副作用として, プロセスが "SIGXCPU exceeded cpu time limit"
というメッセージとともに終了してしまう, というものがあります.
<p>1998 年 11 月 29 日に公開された FreeBSD 3.0 以降で
この問題が解決しないなら, 次の sysctl 変数をセットしてください.
<verb>
sysctl -w kern.timecounter.method=1
</verb>
<p>これは, パフォーマンスへ強い影響を与えますが, 問題の発生に比べれば
おそらく気にならない程度でしょう. もし, これでもまだ問題が残るようなら,
カーネルオプションの "NTIMECOUNTER" を大きな値に増やして下さい.
"NTIMECOUNTER=20" にまで増やしても解決しない場合は,
計時処理の信頼性が保てない程の割り込みが, そのマシン上で起こっていることを
意味します.
</sect>