diff options
author | Hideyuki KURASHINA <rushani@FreeBSD.org> | 2004-09-19 17:16:14 +0000 |
---|---|---|
committer | Hideyuki KURASHINA <rushani@FreeBSD.org> | 2004-09-19 17:16:14 +0000 |
commit | 7e639cab9c6cc111683c5e1acc1669d649096807 (patch) | |
tree | a2734b5d2bf9bf20ecb117a66fcf11ff1f54c57c /ja_JP.eucJP | |
parent | 0a1d28aeca82e6d5ad26048cc39d551f2013ebe8 (diff) |
Notes
Diffstat (limited to 'ja_JP.eucJP')
-rw-r--r-- | ja_JP.eucJP/books/faq/book.sgml | 338 |
1 files changed, 163 insertions, 175 deletions
diff --git a/ja_JP.eucJP/books/faq/book.sgml b/ja_JP.eucJP/books/faq/book.sgml index f53cd8f95b..bc3a9cbfcd 100644 --- a/ja_JP.eucJP/books/faq/book.sgml +++ b/ja_JP.eucJP/books/faq/book.sgml @@ -3,7 +3,7 @@ %books.ent; ]> <!-- The FreeBSD Japanese Documentation Project --> -<!-- Original revision: 1.194 --> +<!-- Original revision: 1.197 --> <book> <bookinfo> @@ -783,47 +783,43 @@ <itemizedlist> <listitem> - <para>4.4BSD System Manager's Manual <!-- <br> --> - By Computer Systems Research Group, UC Berkeley <!-- <br> --> - 1st Edition June 1994, 804 pages <!-- <br> --> + <para>4.4BSD System Manager's Manual + By Computer Systems Research Group, UC Berkeley + 1st Edition June 1994, 804 pages <ulink URL="http://www.amazon.com/exec/obidos/ASIN/1-56592-080-5">ISBN</ulink>: - 1-56592-080-5 <!-- <br> --> - </para> + 1-56592-080-5</para> </listitem> <listitem> - <para>4.4BSD User's Reference Manual <!-- <br> --> - By Computer Systems Research Group, UC Berkeley <!-- <br> --> - 1st Edition June 1994, 905 pages <!-- <br> --> + <para>4.4BSD User's Reference Manual + By Computer Systems Research Group, UC Berkeley + 1st Edition June 1994, 905 pages <ulink URL="http://www.amazon.com/exec/obidos/ASIN/1-56592-075-9">ISBN</ulink>: - 1-56592-075-9 <!-- <br> --> - </para> + 1-56592-075-9</para> </listitem> <listitem> - <para>4.4BSD User's Supplementary Documents <!-- <br> --> - By Computer Systems Research Group, UC Berkeley <!-- <br> --> - 1st Edition July 1994, 712 pages <!-- <br> --> + <para>4.4BSD User's Supplementary Documents + By Computer Systems Research Group, UC Berkeley + 1st Edition July 1994, 712 pages <ulink URL="http://www.amazon.com/exec/obidos/ASIN/1-56592-076-7">ISBN</ulink>: - 1-56592-076-7 <!-- <br> --> - </para> + 1-56592-076-7</para> </listitem> <listitem> - <para>4.4BSD Programmer's Reference Manual <!-- <br> --> - By Computer Systems Research Group, UC Berkeley <!-- <br> --> - 1st Edition June 1994, 886 pages <!-- <br> --> + <para>4.4BSD Programmer's Reference Manual + By Computer Systems Research Group, UC Berkeley + 1st Edition June 1994, 886 pages <ulink URL="http://www.amazon.com/exec/obidos/ASIN/1-56592-078-3">ISBN</ulink>: - 1-56592-078-3 <!-- <br> --> - </para> + 1-56592-078-3</para> </listitem> <listitem> - <para>4.4BSD Programmer's Supplementary Documents <!-- <br> --> - By Computer Systems Research Group, UC Berkeley <!-- <br> --> - 1st Edition July 1994, 596 pages <!-- <br> --> + <para>4.4BSD Programmer's Supplementary Documents + By Computer Systems Research Group, UC Berkeley + 1st Edition July 1994, 596 pages <ulink URL="http://www.amazon.com/exec/obidos/ASIN/1-56592-079-1">ISBN</ulink>: - 1-56592-079-1 <!-- <br> --></para> + 1-56592-079-1</para> </listitem> </itemizedlist> @@ -844,22 +840,21 @@ <para> McKusick, Marshall Kirk, Keith Bostic, Michael J Karels, - and John Quarterman.<!-- <br> --> + and John Quarterman. </para> <para> <emphasis>The Design and Implementation of the 4.4BSD Operating - System</emphasis>. Reading, Mass. : Addison-Wesley, 1996.<!-- <br> --> + System</emphasis>. Reading, Mass. : Addison-Wesley, 1996. <ulink URL="http://www.amazon.com/exec/obidos/ASIN/0-201-54979-4">ISBN</ulink>: - 0-201-54979-4<!-- <br> --> - </para> + 0-201-54979-4</para> <para>システム管理について参考になる本は次のものです。</para> - <para>Evi Nemeth, Garth Snyder, Scott Seebass & Trent R. Hein,<!-- <br> --> - ``Unix System Administration Handbook'', Prentice-Hall, 2000<!-- <br> --> + <para>Evi Nemeth, Garth Snyder, Scott Seebass & Trent R. Hein, + ``Unix System Administration Handbook'', Prentice-Hall, 2000 <ulink URL="http://www.amazon.com/exec/obidos/ASIN/0-13-151051-7">ISBN</ulink>: - 0-13-0206016<!-- <br> --></para> + 0-13-0206016</para> <para> <note><para> @@ -1691,7 +1686,7 @@ File: +DESC (ignored)</screen> </para> <para> - IBM <footnote> <para>これは Keith Frechette + IBM <footnote><para>これは Keith Frechette <email>kfrechet@us.ibm.com</email> からのメールによります。</para></footnote> によれば、以下のモデル/BIOS リリース番号には修正が含まれています。 </para> @@ -4297,7 +4292,7 @@ quit</programlisting> <para> <note> <para>HP Netserver - では<emphasis remap=bf>危険覚悟の専用ディスク</emphasis>は使用できません。 + では<literal>危険覚悟の専用ディスク</literal>は使用できません。 詳細については <link linkend="dedicate">この注意事項</link>をご覧ください。 </para> </note> @@ -4769,7 +4764,7 @@ quit</programlisting> とりあえず 2048 を試してみるのをおすすめします。 これでパニックは完全の予防できるはずです。 mbuf クラスタの割り当て、使用状況については、 - <command>netstat -m</command> で知ることができます + <command>netstat -m</command> で知ることができます (&man.netstat.1; をご覧ください)。 <symbol>NMBCLUSTERS</symbol> のデフォルト値は <literal>512 + MAXUSERS * 16</literal> です。 @@ -6091,9 +6086,9 @@ crw-rw-rw- 1 root wheel 41, 1 Oct 15 22:14 spx</screen> <answer> <para> - 推測ですけど、数値演算コプロセッサを持ってないからと思って、 + 推測ですが、数値演算コプロセッサを持ってないからと思って、 <devicename>npx0</devicename> (&man.npx.4; 参照) - をカーネルコンフィグファイルから削除しちゃったんじゃないですか? + をカーネルコンフィグファイルから削除してしまったのではないでしょうか? <devicename>npx0</devicename> は<emphasis>必須</emphasis>です。 コプロセッサがなくても、<devicename>npx0</devicename> デバイスは削除してはいけません。 @@ -6149,7 +6144,7 @@ crw-rw-rw- 1 root wheel 41, 1 Oct 15 22:14 spx</screen> <answer> <para> - <emphasis remap=bf>Q.</emphasis> マルチポートシリアルを + マルチポートシリアルを サポートするコードを含んだカーネルをコンパイルしようとすると、 最初のポートだけ検出され、 残りのポートは割り込みの競合のためスキップされたと言われます。 @@ -6157,7 +6152,6 @@ crw-rw-rw- 1 root wheel 41, 1 Oct 15 22:14 spx</screen> </para> <para> - <emphasis remap=bf>A.</emphasis> ここでの問題は、FreeBSD にはハードウェアまたはソフトウェアの競合により、 カーネルがクラッシュするのを防ぐコードが含まれているという点です。 @@ -6580,7 +6574,7 @@ device sio5 at isa? port 0x2b8 tty flags 0x501 vector siointr</programlisting> <answer> <para> - <emphasis remap=bf>Digital UNIX:</emphasis> + <literal>Digital UNIX</literal>: UFS CDROM は直接 FreeBSD でマウントすることができます。 Digital UNIX やそれ以外のシステムのサポートする UFS のディスクパーティションをマウントすることはもっと複雑なことで、 @@ -6588,15 +6582,13 @@ device sio5 at isa? port 0x2b8 tty flags 0x501 vector siointr</programlisting> </para> <para> - <emphasis remap=bf>Linux:</emphasis> - 2.2 以降は ext2fs パーティションをサポートします。 - マニュアルの - &man.mount.ext2fs.8; - を見てください。より多くの情報があります。 + <literal>Linux</literal>: + 2.2 以降は <literal>ext2fs</literal> パーティションをサポートします。 + 詳しくは、&man.mount.ext2fs.8; を見てください。 </para> <para> - <emphasis remap=bf>NT:</emphasis> + <literal>NT</literal>: FreeBSD 用の読みだしのみ可能な NTFS ドライバがあります。 詳しくは、Mark Ovens 氏によって書かれたチュートリアル <ulink URL="http://ukug.uk.freebsd.org/~mark/ntfs_install.html">http://ukug.uk.freebsd.org/~mark/ntfs_install.html</ulink> @@ -7026,7 +7018,7 @@ C:\="DOS"</programlisting> <para>vn デバイスを作ります</para> <screen>&prompt.root; <userinput>cd /dev</userinput> &prompt.root; <userinput>sh ./MAKEDEV vn0</userinput></screen> - + </listitem> <listitem> @@ -7137,27 +7129,27 @@ C:\="DOS"</programlisting> <itemizedlist> <listitem> - <para>Belgian ISO-8859-1 </para> + <para>Belgian ISO-8859-1</para> </listitem> <listitem> - <para>Brazilian 275 keyboard Codepage 850 </para> + <para>Brazilian 275 keyboard Codepage 850</para> </listitem> <listitem> - <para>Brazilian 275 keyboard ISO-8859-1 </para> + <para>Brazilian 275 keyboard ISO-8859-1</para> </listitem> <listitem> - <para>Danish Codepage 865 </para> + <para>Danish Codepage 865</para> </listitem> <listitem> - <para>Danish ISO-8859-1 </para> + <para>Danish ISO-8859-1</para> </listitem> <listitem> - <para>French ISO-8859-1 </para> + <para>French ISO-8859-1</para> </listitem> <listitem> @@ -7165,79 +7157,79 @@ C:\="DOS"</programlisting> </listitem> <listitem> - <para>German ISO-8859-1 </para> + <para>German ISO-8859-1</para> </listitem> <listitem> - <para>Italian ISO-8859-1 </para> + <para>Italian ISO-8859-1</para> </listitem> <listitem> - <para>Japanese 106 </para> + <para>Japanese 106</para> </listitem> <listitem> - <para>Japanese 106x </para> + <para>Japanese 106x</para> </listitem> <listitem> - <para>Latin American </para> + <para>Latin American</para> </listitem> <listitem> - <para>Norwegian ISO-8859-1 </para> + <para>Norwegian ISO-8859-1</para> </listitem> <listitem> - <para>Polish ISO-8859-2 (programmer's) </para> + <para>Polish ISO-8859-2 (programmer's)</para> </listitem> <listitem> - <para>Russian Codepage 866 (alternative) </para> + <para>Russian Codepage 866 (alternative)</para> </listitem> <listitem> - <para>Russian koi8-r (shift) </para> + <para>Russian koi8-r (shift)</para> </listitem> <listitem> - <para>Russian koi8-r </para> + <para>Russian koi8-r</para> </listitem> <listitem> - <para>Spanish ISO-8859-1 </para> + <para>Spanish ISO-8859-1</para> </listitem> <listitem> - <para>Swedish Codepage 850 </para> + <para>Swedish Codepage 850</para> </listitem> <listitem> - <para>Swedish ISO-8859-1 </para> + <para>Swedish ISO-8859-1</para> </listitem> <listitem> - <para>Swiss-German ISO-8859-1 </para> + <para>Swiss-German ISO-8859-1</para> </listitem> <listitem> - <para>United Kingdom Codepage 850 </para> + <para>United Kingdom Codepage 850</para> </listitem> <listitem> - <para>United Kingdom ISO-8859-1 </para> + <para>United Kingdom ISO-8859-1</para> </listitem> <listitem> - <para>United States of America ISO-8859-1 </para> + <para>United States of America ISO-8859-1</para> </listitem> <listitem> - <para>United States of America dvorak </para> + <para>United States of America dvorak</para> </listitem> <listitem> - <para>United States of America dvorakx </para> + <para>United States of America dvorakx</para> </listitem> </itemizedlist> @@ -7548,7 +7540,7 @@ if-bus.UUCP uucp-dom:if-bus 確かめたい場合には、sendmail の<option>-bt</option> オプションを 使用してください。このオプションによって sendmail は <emphasis>アドレステストモード</emphasis>で起動します。 - <literal>0 </literal> + <literal>0</literal> の後に配送したいアドレスを書いてください。最後の行に、実際に使用される mail agent、この mail agent で送られる送信先のホスト、そして (多分変換されている) アドレスが表示されます。このモードを抜けるには @@ -7580,8 +7572,8 @@ rewrite: ruleset 0 returns: $# uucp-dom $@ if-bus $: foo \ </para> <para> - ダイアルアップ ppp をインターネット接続に使用し、動的に IP - アドレスが割り当てられる場合は、 + ダイアルアップ <application>ppp</application> を + インターネット接続に使用し、動的に IP アドレスが割り当てられる場合は、 インターネットサービスプロバイダ (ISP) のメールサーバにメールボックスがあるはずです。 ISP のドメインが @@ -8278,8 +8270,8 @@ define(`confDELIVERY_MODE', `deferred')dnl</programlisting> 自身の所有するディレクトリへマウントすることができます。 </para> - <screen>&prompt.user; <userinput> mkdir ~/my-mount-point</userinput> -&prompt.user; <userinput> mount -t msdos /dev/cd0c ~/my-mount-point</userinput> + <screen>&prompt.user; <userinput>mkdir ~/my-mount-point</userinput> +&prompt.user; <userinput>mount -t msdos /dev/cd0c ~/my-mount-point</userinput> </screen> <para>デバイスのアンマウントは簡単です。</para> @@ -9222,7 +9214,7 @@ ttyvb "/usr/libexec/getty Pc" cons25 off secure</programlisting> <ulink URL="http://www.FreeBSD.org/cgi/man.cgi?manpath=xfree86&query=X">X</ulink> を <ulink URL="http://www.FreeBSD.org/cgi/man.cgi?manpath=xfree86&query=startx">startx</ulink> で起動しますと、<filename>/dev/console</filename> のパーミッションは - <emphasis>変更ができない</emphasis>ようになっていますので、 + <emphasis>変更できない</emphasis>ようになっていますので、 <ulink URL="http://www.FreeBSD.org/cgi/man.cgi?manpath=xfree86&query=xterm">xterm -C</ulink> や <ulink URL="http://www.FreeBSD.org/cgi/man.cgi?manpath=xfree86&query=xconsole">xconsole</ulink> @@ -10235,7 +10227,7 @@ Znyx (2.2.X) ZX312, ZX314, ZX342, ZX345, ZX346, ZX348 </para> <para> - <filename>/etc/resolv.conf</filename> ファイル + <filename>/etc/resolv.conf</filename> ファイル (&man.resolv.conf.5; 参照) の中で </para> @@ -10650,11 +10642,11 @@ Znyx (2.2.X) ZX312, ZX314, ZX342, ZX345, ZX346, ZX348 <programlisting>set log Phase Chat Connect Carrier lcp ipcp ccp command</programlisting> <para> - という命令を <command>ppp</command> + という命令を <application>ppp</application> のコマンドプロンプトに対して打ち込むか、 設定ファイル <filename>/etc/ppp/ppp.conf</filename> - に加えて (<symbol>default</symbol> + に加えて (<literal>default</literal> セクションの先頭に加えるのが一番良いでしょう) ログを有効にしてみてください。 その際、 @@ -10749,13 +10741,13 @@ default 10.0.0.2 UGSc 0 0 tun0 デフォルトルートが確立していない場合、 <filename>ppp.conf</filename> の中の - <symbol>HISADDR</symbol> + <literal>HISADDR</literal> が理解できない、 古いバージョンの &man.ppp.8; が走っている可能性があります。 FreeBSD 2.2.5 より前のバージョンに付属していた - <command>ppp</command> + <application>ppp</application> を使用している場合、 </para> @@ -10853,7 +10845,7 @@ add 0 0 HISADDR</screen> できます。 ソケットを用いる &man.telnet.1; か &man.pppctl.8; を使用し、 - <command>ppp</command> + <application>ppp</application> サーバに接続することによって、 回線がアクティブな間に限定してタイムアウトの時間を調整することも可能です。 </para> @@ -11087,7 +11079,7 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj</programlisting> を発信するのを待ちます。しかし、多くの <acronym>ISP</acronym> ではネゴシエーションを自分からは起こさず、 クライアントが起こすのを待っています。 - <command>ppp</command> に強制的に + <application>ppp</application> に強制的に <acronym>LCP</acronym> を発信させるには、 次の命令を使います。 </para> @@ -11222,84 +11214,78 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj</programlisting> <answer> <para> - 現在の <command>ppp</command> は、まだ + 現在の <application>ppp</application> は、まだ <acronym>LCP</acronym> や <acronym>CCP</acronym>、 <acronym>IPCP</acronym> の返事が、 元のリクエストと連携してくれる機能がきちんと実装されていません。 その結果、ある - <command>ppp</command> - が相手よりも 6 秒以上遅い場合には、 + <application>ppp</application> + の実装が相手よりも 6 秒以上遅い場合には、 <acronym>LCP</acronym> 設定のリクエストをさらに 2 回送ります。 これは致命的な物です。 </para> <para> - <emphasis>A</emphasis> と <emphasis>B</emphasis>という + <hostid>A</hostid> と <hostid>B</hostid>という 2 つの実装を考えてみましょう。 - <emphasis>A</emphasis> が接続の直後に + <hostid>A</hostid> が接続の直後に <acronym>LCP</acronym> リクエストを送り、 - 一方 <emphasis>B</emphasis> の方はスタートするのに - 7 秒かかったとします。<emphasis>B</emphasis> がスタートする時には - <emphasis>A</emphasis> は <acronym>LCP</acronym> + 一方 <hostid>B</hostid> の方はスタートするのに + 7 秒かかったとします。<hostid>B</hostid> がスタートする時には + <hostid>A</hostid> は <acronym>LCP</acronym> リクエストを 3 回送ってしまっています。 前の節で述べた magic number の問題が起きないよう、 <symbol>ECHO</symbol> は <symbol>off</symbol> になっていると考えています。 - <emphasis>B</emphasis> は <acronym>REQ</acronym> を送ります。 - するとこれは <emphasis>A</emphasis> の <acronym>REQ</acronym> のうち、 + <hostid>B</hostid> は <acronym>REQ</acronym> を送ります。 + するとこれは <hostid>A</hostid> の <acronym>REQ</acronym> のうち、 最初の物に対する <acronym>ACK</acronym> となります。 - 結果として、<emphasis>A</emphasis> - は <symbol>OPENED</symbol> + 結果として、<hostid>A</hostid> + は <acronym>OPENED</acronym> の状態に入り、 - <emphasis>B</emphasis> + <hostid>B</hostid> に対して (最初の) <acronym>ACK</acronym> を送ります。 そのうちに - <emphasis>B</emphasis> は、 - <emphasis>B</emphasis> + <hostid>B</hostid> は、<hostid>B</hostid> がスタートする前に - <emphasis>A</emphasis> + <hostid>A</hostid> から送られたもう 2 つの <acronym>REQ</acronym> に対する <acronym>ACK</acronym> を送り返します。 - <emphasis>B</emphasis> は - <emphasis>A</emphasis> + <hostid>B</hostid> は <hostid>A</hostid> からの最初の <acronym>ACK</acronym> を受け取り - <symbol>OPENED</symbol> の状態に入ります。 - <emphasis>A</emphasis> は - <emphasis>B</emphasis> からの + <acronym>OPENED</acronym> の状態に入ります。 + <hostid>A</hostid> は <hostid>B</hostid> からの 2 つ目の <acronym>ACK</acronym> を受け取りますので、 - <symbol>REQ-SENT</symbol>の状態に戻り、 + <acronym>REQ-SENT</acronym>の状態に戻り、 さらに、RFC のとおりに (4 つ目の) <acronym>REQ</acronym> を送ります。そして 3 つ目の <acronym>ACK</acronym> を受け取って - <symbol>OPENED</symbol> - の状態に入ります。 - 一方、<emphasis>B</emphasis> - は - <emphasis>A</emphasis> + <acronym>OPENED</acronym> 状態に入ります。 + 一方、<hostid>B</hostid> は <hostid>A</hostid> からの 4 つ目の <acronym>REQ</acronym> を受け取りますので、 - <symbol>ACK-SENT</symbol> + <acronym>ACK-SENT</acronym> の状態に入り、2 つ目の <acronym>REQ</acronym> と 4 つ目の <acronym>ACK</acronym> を RFC のとおりに送ります。 - <emphasis>A</emphasis>は、 + <hostid>A</hostid>は、 <acronym>REQ</acronym> を受けとると - <symbol>REQ-SENT</symbol> + <acronym>REQ-SENT</acronym> の状態になり、さらに <acronym>REQ</acronym> を送ります。 そしてすぐに <acronym>ACK</acronym> を受け取って - <symbol>OPENED</symbol> + <acronym>OPENED</acronym> の状態に入ります。 </para> @@ -11312,7 +11298,7 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj</programlisting> <para> これを回避する最も良い方法は、 片方を - <emphasis>passive</emphasis> + <literal>passive</literal> モードに設定する、 すなわち反対側がネゴシエーションを開始するまで待つようにする事です。 これは、 @@ -11329,7 +11315,7 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj</programlisting> <para> というコマンドを追加して、 - <command>ppp</command> がネゴシエーションが開始するまで待つ + <application>ppp</application> がネゴシエーションが開始するまで待つ 最大の時間を設定してください。もしくは、 </para> @@ -11351,14 +11337,14 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj</programlisting> <answer> <para> - 2.2.5 より前のバージョンの FreeBSD では、<command>ppp</command> + 2.2.5 より前のバージョンの FreeBSD では、<application>ppp</application> が Predictor1 圧縮のネゴシエーションを誤って解釈して、 接続直後にリンクを無効にしている可能性があります。 これは両サイドが異なる <acronym>Compression Control Protocols (CCP)</acronym> を使ってネゴジェーションを行った場合にのみ発生します。 この問題は現在は解決していますが、あなたの走らせている - <command>ppp</command> + <application>ppp</application> のバージョンが古い場合でも、次の命令で解決することができます。</para> <programlisting>disable pred1</programlisting> @@ -11406,7 +11392,7 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj</programlisting> <answer> <para> ヌルモデムケーブルを使用して直接接続している場合、 - <command>ppp</command> + <application>ppp</application> は自動的には接続の終了を知ることができません。 これはヌルモデムシリアルケーブルの配線に起因しています。 この種の接続形態を用いる場合は、 @@ -11432,7 +11418,7 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj</programlisting> <answer> <para> - <command>ppp</command> + <application>ppp</application> が思いもしないときにダイアルを始める場合、その原因を突き止め、 防止のためにダイヤルフィルタ (dfilters) をかけてやる 必要があります。 @@ -11456,7 +11442,7 @@ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj</programlisting> で名前の解決をしようとしたために起こります。 <acronym>DNS</acronym> による名前の解決によって、 接続が行われるのを防止するには、 - 次のような手段を用います (これは <command>ppp</command> + 次のような手段を用います (これは <application>ppp</application> の既に確立した接続に関してパケットのフィルタリングをするものでは<emphasis>ありません</emphasis>)。 </para> @@ -11563,7 +11549,7 @@ CCP: Received Terminate Ack (1) state = Req-Sent (6)</programlisting> <acronym>LCP</acronym> のネゴシエーションを行う場合を含む<emphasis>どのような場合でも</emphasis>最低 1500 オクテットの - <acronym>Maximum Receive Unit (MRU)</acronym> + Maximum Receive Unit (<acronym>MRU</acronym>) を受け入れる必要があります。 ですから、<acronym>MTU</acronym> を 1500 以下に設定した場合でも、ISP はそれに関係なく @@ -11609,7 +11595,7 @@ CCP: Received Terminate Ack (1) state = Req-Sent (6)</programlisting> 以降に全く「やりとり」を行わない - <quote><literal>set login</literal></quote> スクリプトには何も書かない) のであれば、 - <command>ppp</command> に + <application>ppp</application> に <quote><literal>expect</literal></quote> を含んだ <literal>CONNECT</literal> 行すべてがくるまで待たせるようにしないといけません、 @@ -11621,7 +11607,7 @@ CCP: Received Terminate Ack (1) state = Req-Sent (6)</programlisting> <para> ここで、<literal>CONNECT</literal> を受信してから、 何も送らず、復帰改行 (linefeed) を待っています、 - <command>ppp</command> に <literal>CONNECT</literal> + <application>ppp</application> に <literal>CONNECT</literal> の応答すべてを読み込ませているわけです。 </para> </answer> @@ -11698,15 +11684,15 @@ ATDT1234567</programlisting> <answer> <para> - <command>ppp</command> (や他のプログラム) は決して + <application>ppp</application> (や他のプログラム) は決して core を吐いてはいけません。 - <command>ppp</command> + <application>ppp</application> は実効 uid が 0 で動いていますので、 - オペレーティングシステムは <command>ppp</command> + オペレーティングシステムは <application>ppp</application> を終了させる前にディスクに core イメージを書き込みません。 - しかし <command>ppp</command> + しかし <application>ppp</application> は実際にはセグメンテーション違反や、 - 他の core を吐く原因となるようなシグナルによって<emphasis>終了して</emphasis> おり、 + 他の core を吐く原因となるようなシグナルによって終了しており、 <emphasis>さらに</emphasis>最新のバージョン (このセクションの始めを見てください) を使用しているならば、次のようにしてください。 @@ -11774,12 +11760,12 @@ ATDT1234567</programlisting> <answer> <para> - これは <command>ppp</command> + これは <application>ppp</application> がローカル側の <acronym>IP</acronym> アドレスを、 動的に通信相手と交渉するように設定されている時に発生する良く知られた障害でした。 最新のバージョンでは、 この問題は修正されています。 - <symbol>iface</symbol> + <literal>iface</literal> をマニュアルページから検索してみてください。 </para> @@ -11792,9 +11778,9 @@ ATDT1234567</programlisting> カーネルは、 外へ出ていく最初のパケットを作り、それを <devicename>tun</devicename> デバイスへ書き込みます。 - そして <command>ppp</command> は、 + そして <application>ppp</application> は、 そのパケットを読み込んで接続を確立します。 - <command>ppp</command> + <application>ppp</application> は動的に <acronym>IP</acronym> アドレスを割り当てるため、 もしインターフェイスのアドレスが変化してしまうと、 @@ -11810,7 +11796,7 @@ ATDT1234567</programlisting> この問題に対処する理論的な方法がいくつかあります。もし可能なら、 相手が再度、同じ <acronym>IP</acronym> アドレスを割り当ててくれることが一番です <literal>:-)</literal> - <command>ppp</command> + <application>ppp</application> の現在のバージョンはこれを行ないますが、 他のほとんどの実装はそういった動作をしません。 </para> @@ -11825,10 +11811,10 @@ ATDT1234567</programlisting> アドレスから、交渉によって得られた <acronym>IP</acronym> アドレスに、 適宜書きかえる事によっても対処できます。 これは、基本的に - <command>ppp</command> の最新バージョンにある <symbol>iface-alias</symbol> + <application>ppp</application> の最新バージョンにある <literal>iface-alias</literal> オプションが行なっていることと同じです (&man.libalias.3; - および、<command>ppp</command> の <option>-nat</option> + および、<application>ppp</application> の <option>-nat</option> スイッチにも関係します)。それは、以前の <acronym>IP</acronym> アドレスをすべて管理し、 それらを最後の交渉によって得られた <acronym>IP</acronym> @@ -11838,8 +11824,8 @@ ATDT1234567</programlisting> もう 1 つの (おそらく最も信頼できる) 方法は、bind された すべてのソケットの <acronym>IP</acronym> アドレスを、 異なるものに変更できるシステムコールを実装することです。 - <command>ppp</command>は、 - 交渉によって新しい <acronym>IP</acronym> アドレスを得た時、 + <application>ppp</application>は、 + 新しい <acronym>IP</acronym> アドレスが割り当てられた時、 このシステムコールを用いて実行されているプログラムにある、 すべてのソケットを書きかえてやるわけです。 同じシステムコールが、<acronym>DHCP</acronym> クライアントが利用するソケットを @@ -11849,19 +11835,19 @@ ATDT1234567</programlisting> <para> 3 つ目の方法は、<acronym>IP</acronym> アドレスを指定しないでインターフェイスを利用できるようにすることです。 - 外に出ていくパケットは、最初の <symbol>SIOCAIFADDR</symbol> + 外に出ていくパケットは、最初の <literal>SIOCAIFADDR</literal> ioctl の完了まで、 255.255.255.255 という <acronym>IP</acronym> アドレスが与えられます。 これによって、ソケットは常に bind することができます。 - <command>ppp</command> に対して発信元 - <acronym>IP</acronym> アドレスを変更させる事になりますが、 - もしそれが 255.255.255.255 になっていたら、<acronym>IP</acronym> アドレスと - <acronym>IP</acronym> チェックサムだけ変更すれば良ければの話になります。 - この方法はちょっとした変更ですが、 - 他の機構が今までのように、<acronym>IP</acronym> - アドレスを固定して利用する場合に、 - カーネルが不適切に設定されたインターフェイスに向けて、 - 正常でないパケットを送り出してしまう可能性があります。 + 発信元 <acronym>IP</acronym> アドレスを変更するのは + <application>ppp</application> の仕事です。ただし、 + それは発信元 <acronym>IP</acronym> アドレスが + 255.255.255.255 になっていて、<acronym>IP</acronym> アドレスと + <acronym>IP</acronym> チェックサムを変更する必要がある場合だけです。 + これは、カーネルが不適切に設定されたインターフェイスへは + 異常なパケットを送出しようとすることを利用して、なにか他の + 仕組みが遡及的に修正を行ってくれることを前提にしている、 + 割り切った方法ではあります。 </para> </answer> </qandaentry> @@ -12067,8 +12053,9 @@ nat port udp <replaceable>internal</replaceable>:5009 5009</programlisting> <answer> <para> <acronym>FCS</acronym> とは - Frame Check Sequence (フレームチェックシーケンス) の略です。 - 個々の <command>ppp</command> パケットには、 + <literal>F</literal>rame <literal>C</literal>heck <literal>S</literal>equence + (フレームチェックシーケンス) の略です。 + 個々の <application>ppp</application> パケットには、 送受信するデータが正しいかを調べるためのチェックサムが含まれています。 受信したパケットの <acronym>FCS</acronym> が正しくない場合は、そのパケットは廃棄され、 <acronym>HDLC</acronym> <acronym>FCS</acronym> カウントが増やされます。 @@ -12139,8 +12126,8 @@ nat port udp <replaceable>internal</replaceable>:5009 5009</programlisting> Windows 98 と MacOS (および、おそらく他の Microsoft 社製 OS) の TCP パケット送出は、 PPPoE のフレーム (Ethernet の MTU は標準で 1500) に入らないような大きなセグメントサイズを要求します。 - <emphasis>そしてさらに</emphasis>分割禁止 ("don't fragment") フラグビットを - (TCP パケットにデフォルトで) セットするのですが、 + <emphasis>そしてさらに</emphasis>分割禁止 (<quote>don't fragment</quote>) + フラグビットを (TCP パケットにデフォルトで) セットするのですが、 Telco のルータは、分割が必須 ("must fragment") であることを示す ICMP メッセージを、接続しようとするウェブサイトに対して送出しません (つまり、ルータは正しく ICMP パケットを送出しているのですが、 @@ -12199,13 +12186,13 @@ HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\NetTrans\0000\MaxMTU <literal>Make Active</literal> をクリックする必要があります。 </para> - <para><emphasis remap=bf>ppp</emphasis> の最新版 + <para><application>ppp</application> の最新版 (2.3 かそれ以降) には、自動的に MSS を適切な値に調節する <command>enable tcpmssfixup</command> コマンドがあります。 この機能は標準で有効になっています。 - もし旧バージョンの <emphasis remap=bf>ppp</emphasis> + もし旧バージョンの <application>ppp</application> を使わなければならない状況にあるなら、 - <emphasis remap=bf>tcpmssd</emphasis> の port + <application>tcpmssd</application> の port をご覧になると良いでしょう。</para> </answer> </qandaentry> @@ -12218,7 +12205,7 @@ HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\NetTrans\0000\MaxMTU <answer> <para> これまでのすべての質問に当てはまらない場合、設定ファイル、 - <command>ppp</command> + <application>ppp</application> の実行方法、ログファイルの該当部分と <command>netstat -rn</command> コマンドの出力 (接続前と接続後) を含む、 @@ -13042,7 +13029,7 @@ raisechar=^^</programlisting> <qandaentry> <question id="zmodem-tip"> - <para><command>tip</command> から zmodem を実行するには?</para> + <para><application>tip</application> から zmodem を実行するには?</para> </question> <answer> @@ -13267,8 +13254,9 @@ raisechar=^^</programlisting> </para> <para> - FreeBSD の場合は、共有ライブラリのメカニズムは Sun の SunOS - スタイルの共有ライブラリのメカニズムに極めて近いものになっていて、 + FreeBSD の場合は、共有ライブラリのメカニズムは Sun の + <application>SunOS</application> 形式の共有ライブラリの + メカニズムに極めて近いものになっていて、 非常に使いやすいものになっています。 しかしながら、FreeBSD では 3.0 から <acronym>ELF</acronym> バイナリをデフォルトのフォーマットとして公式にサポートしています。 @@ -13423,7 +13411,7 @@ raisechar=^^</programlisting> <note> <para> <quote><option>-R</option></quote> オプションは<emphasis>再帰的に</emphasis> - <command>chmod</command> + &man.chmod.1; を実行します。ディレクトリやディレクトリへのシンボリックリンクを <command>chmod</command> する場合は気をつけてください。 シンボリックリンクで参照されている単一のディレクトリのパーミッションを変更したい場合は、 @@ -13508,7 +13496,7 @@ raisechar=^^</programlisting> <answer> <para> はい、FreeBSD 3.0 からは、 - 統合と改良が重ねられた BSDI の <command>doscmd</command> + 統合と改良が重ねられた BSDI の <application>doscmd</application> DOS エミュレーションサブシステムを使ってできるようになりました。 今なお続けられているこの努力に興味を持って参加していただけるなら、 &a.emulation; @@ -13971,21 +13959,21 @@ raisechar=^^</programlisting> <itemizedlist> <listitem> <para> - <symbol>RELENG_2_2</symbol> - 通称 <literal>2.2-STABLE</literal> + <literal>RELENG_2_2</literal> + 通称 <emphasis>2.2-STABLE</emphasis> </para> </listitem> <listitem> <para> - <symbol>RELENG_3</symbol> - 通称 <literal>3.X-STABLE</literal> + <literal>RELENG_3</literal> + 通称 <emphasis>3.X-STABLE</emphasis> </para> </listitem> <listitem> <para> - <symbol>RELENG_4</symbol> + <literal>RELENG_4</literal> 通称 <emphasis>4-STABLE</emphasis></para> </listitem> @@ -14008,17 +13996,17 @@ raisechar=^^</programlisting> <para> 現在、 - <literal>-CURRENT</literal> は 5.0 の開発本流であり、 + <quote>-CURRENT</quote> は 5.0 の開発本流であり、 <literal>4.0-STABLE</literal> ブランチ、 つまり <symbol>RELENG_4</symbol> は 2000 年 3 月に - <literal>-CURRENT</literal> から分岐しています。 + <quote>-CURRENT</quote> から分岐しています。 </para> <para> <literal>2.2-STABLE</literal> ブランチ、 <symbol>RELENG_2_2</symbol> は - 1996 年 11 月に <literal>-CURRENT</literal> から分岐しました。 + 1996 年 11 月に <quote>-CURRENT</quote> から分岐しました。 これは保守が完全に終了しています。 </para> </answer> @@ -14607,7 +14595,7 @@ Cc: current@FreeBSD.ORG</programlisting> <para> 確実にクラッシュダンプをとるには、<filename>/etc/rc.conf</filename> - を編集して <devicename>dumpdev</devicename> + を編集して <literal>dumpdev</literal> を使用しているスワップパーティションに指定する必要があります。 こうすると <command>rc(8)</command> スクリプトから <command>dumpon(8)</command> コマンドが実行され、 @@ -14615,7 +14603,7 @@ Cc: current@FreeBSD.ORG</programlisting> 手動で <command>dumpon(8)</command> コマンドを実行してもかまいません。 パニックの後、クラッシュダンプは <command>savecore(8)</command> コマンドを使用して取り出すこと ができます。 - <devicename>dumpdev</devicename> が + <literal>dumpdev</literal> が <filename>/etc/rc.conf</filename> で設定されていれば、 <command>rc(8)</command> スクリプトから <command>savecore(8)</command> が自動的に実行され、クラッシュダンプを @@ -14706,7 +14694,7 @@ Cc: current@FreeBSD.ORG</programlisting> <acronym>ELF</acronym> のツール類は、 デフォルトでは実行形式の中に定義されているシンボルを、 ダイナミックリンカから見えるようにはしません。 - このため、<literal>dlopen(NULL, flags)</literal> + このため、<function>dlopen(NULL, flags)</function> を呼び出して得られたハンドルに対して、 <function>dlsym()</function> で探索を行っても、 こういったシンボルを見つけられません。 @@ -14793,7 +14781,7 @@ SECTIONS それらを正常にするために、<command>make world</command> (もしくは、変更した <filename>pmap.h</filename> を <filename>/usr/include/vm/</filename> にコピーした後に、 - <literal>libkvm</literal>、 + <filename>libkvm</filename>、 <command>ps</command> および <command>top</command> を手動で再構築すること) を行なうべきです。 </para> |