os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
doc/ja_JP.eucJP/FAQ/network.sgml
Motoyuki Konno dd2c0471a7 Fix typo.
1998-10-05 15:43:37 +00:00

1160 lines
47 KiB
Text
Raw Blame History

<!-- $Id: network.sgml,v 1.10 1998-10-05 15:43:29 motoyuki Exp $ -->
<!-- The FreeBSD Japanese Documentation Project -->
<!-- Original revision: 1.15 -->
<sect>
<heading>ネットワーキング<label id="networking"></heading>
<p><em>訳: &a.arimura; <newline>&a.shou; <newline>&a.nishika;
<newline>&a.kiroh .
<newline>4 October 1998.</em>
<sect1>
<heading>``diskless boot'' に関する情報はどこで得られますか?</heading>
<p>``diskless boot'' というのは, FreeBSD がネットワーク上で起動し,
必要なファイルを自分のハードディスクではなくてサーバから読み込むものです.
詳細については
<url url="../handbook/diskless.html"
name="ハンドブックのディスクレスブートに関する節">
を読んでください.
<sect1>
<heading>
FreeBSD をネットワークの router として使用することはできますか?
</heading>
<p>インターネット標準やこれまでのよい経験によって指摘されている通り,
FreeBSD は標準ではパケットを forward するように設定されていません.
しかし, <htmlurl url="http://www.freebsd.org/cgi/man.cgi?rc.conf"
name="rc.conf"> の中で次の変数の値を
<tt/YES/ とする事によってこの機能を有効にすることができます.
<verb>
gateway_enable=YES # Set to YES if this host will be a gateway
</verb>
<p>このオプションによって<htmlurl
url="http://www.freebsd.org/cgi/man.cgi?sysctl" name="sysctl"> の変数
<tt/net.inet.ip.forwarding/ が <tt/1/ になります.
<p>ほとんどの場合, router についての情報を同じネットワーク
の他の計算機等に知らせるために, 経路制御のためのの process
を走らせる必要があるでしょう. FreeBSD には BSD の標準経路制御デーモン
である
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?routed"
name="routed"> が付属していますが, より複雑な状況に対処するためには
<em/GaTeD/ (<tt/ftp.gated.Merit.EDU/ から FTP で手に入れることができます)
を使用することもできます. 3_5Alpha7 において FreeBSD がサポートされています.
<p>注意してほしいのは, FreeBSD をこのようにして使用している場合でも,
router に関するインターネット標準の必要条件を完全には満たしていない
ということです. しかし, 普通に使用する場合にはほとんど問題ありません.
<sect1>
<heading>
Win95 の走っているマシンを, FreeBSD 経由でインターネットに接続できますか?
</heading>
<p>通常, この質問が出てくる状況は自宅に二台の PC があり, 一台では
FreeBSD が, もう一台では Win95 が走っているような場合です.
ここでやろうとしていう事はFreeBSDの走っている計算機をインターネット
に接続し, Win95 の走っているマシンからは FreeBSD の走っているマシンを
経由して接続をおこなう事です. これは二つ前の質問の特別な場合に相当します.
<p>FreeBSDを<url url="http://www.ssimicro.com/~jeremyc/ppp.html"
name="PPP の Dialup ルータ">として設定する方法については,
役に立つ文書があります.
<p><bf/注:/ これには, Windows の走っているマシンからどれだけの
作業を同時におこなうかによって, 最低 2 個, 場合によってはもっと多くの
固定した IP アドレスが必要です. もし固定した IP アドレスがない場合には,
プライベートな IP アドレスを用いたサブネットを使用し, FreeBSD 上で
<url url="http://squid.nlanr.net/Squid/" name="SQUID">や
<url url="http://www.tis.com/" name="TIS firewall ツールキット">
のような <bf/proxy/ を用いることによって実現することもできます.
<p>また, <ref id="natd"> に関する節も参照してください.
<sect1>
<heading>
ISC からリリースされている BIND の最新版は compile できないんでしょうか?
</heading>
<p>BIND の配布物と FreeBSD とでは ``<tt/cdefs.h/'' というファイルの中で,
データ型の矛盾があります.
<tt>compat/include/sys/cdefs.h</tt> を削除してください.
<sect1>
<heading>FreeBSD で SLIP と PPP は使えますか?</heading>
<p>使えます. FreeBSD を用いて他のサイトに接続する場合には,
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?slattach"
name="slattach">,
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?sliplogin"
name="sliplogin">,
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?pppd"
name="pppd"> そして
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?ppp"
name="ppp">
のマニュアルページを見てください.
<tt/pppd/ と <tt/ppp/ は PPP のサーバ, クライアント両方の
機能を持っています.
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?sliplogin"
name="Sliplogin"> は SLIP のサーバ専用で,
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?slattach"
name="slattach"> は SLIP のクライアント専用です.
<p>これらのプログラムの解説が, <url
url="../handbook/handbook.html" name="ハンドブック">
の以下のセクションにあります.
<itemize>
<item><url url="../handbook/slips.html"
name="ハンドブックの SLIP (サーバ側) の節">
<item><url url="../handbook/slipc.html"
name="ハンドブックの SLIP (クライアント側) の節">
<item><url url="../handbook/ppp.html"
name="ハンドブックの PPP (kernel バージョン) の節">
<item><url url="../handbook/userppp.html"
name="ハンドブックの PPP (user モードバージョン) の節">
</itemize>
<p>「シェルアカウント」を通じてのみインターネットへアクセス可能な場合,
<htmlurl url="http://www.freebsd.org/cgi/ports.cgi?^slirp"
name="slirp"> package みたいなものが欲しくなるかもしれませんね.
これを使えば, ローカルマシンから直接 ftp や http のようなサービスに
(限定的ではありますが) アクセスすることができます.
<sect1>
<heading>
FreeBSD は NAT か IP マスカレードをサポートしていますか?<label id="natd">
</heading>
<p>ローカルなサブネット (一台以上のローカルマシン) を持っているが,
インターネットプロバイダから 1 つしか IP アドレスの割り当てを
受けていない場合 (または IP アドレスを動的に割り当てられている場合でも),
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?natd"
name="natd"> プログラムを使いたくなるかもしれませんね.
<tt/Natd/ を使えば, 1 つしか IP アドレスを持っていない場合でも,
サブネット全体をインターネットに接続させることができます.
<p><htmlurl url="http://www.freebsd.org/cgi/man.cgi?ppp"
name="ppp"> も, 同様の機能を持っており, <tt/-alias/
スイッチで有効にすることができます. どちらの場合も <htmlurl
url="http://www.freebsd.org/cgi/man.cgi?libalias" name="alias library">
が使われます.
<sect1>
<heading>
<tt/ppp/ が動きません. どこを間違えているのでしょう?<label id="userppp">
</heading>
<p>まず <htmlurl url="http://www.freebsd.org/cgi/man.cgi?ppp"
name="ppp"> のマニュアルと, <url url="../handbook/userppp.html"
name="ハンドブックの ppp のセクション">を読んでみましょう. 次に,
<verb>
set log Phase Chat Connect Carrier lcp ipcp ccp command
</verb>
<p>という命令を <bf/ppp/ のコマンドプロンプトに対して打ち込むか,
設定ファイル <tt>/etc/ppp/ppp.conf</tt> に加えて
(<bf>default</bf> セクションの先頭に加えるのが一番良いでしょう)
ログを有効にしてみてください. その際, <htmlurl
url="http://www.freebsd.org/cgi/man.cgi?syslog.conf"
name="/etc/syslog.conf"> に
<verb>
!ppp
*.* /var/log/ppp.log
</verb>
<p>と書かれた行が含まれているか, また, <tt>/var/log/ppp.log</tt>
が存在しているかどうか確かめておいてください. さて, これで
何が起きているのか突き止めるために, ログファイルからたくさんの
情報を得られるようになりました. ログに訳の分らない部分があっても
心配ご無用. あなたが助けを求めた誰かにとっては, その部分が
意味をなす場合があるのです.
<p>訳注: ログの取得に syslog を使用するようになったのは
2.2.5 以降からです.
<p>使用中の ppp のバージョンで "set log" 命令を解釈しない場合は,
<url url="http://www.freebsd.org/~brian" name="最新版">
をダウンロードすべきです. FreeBSD の 2.1.5 以降でビルドできます.
<sect2>
<heading>ppp を実行するとハングします</heading>
<p>ホスト名の解決がうまくいっていないのでしょう. まず,
リゾルバが <tt>/etc/hosts</tt>を参照するように,
<tt>/etc/host.conf</tt> の最初の行に host と書き込んでください.
つぎに, <tt>/etc/hosts</tt>に使用しているマシンのエントリを
書き加えます. ローカルでネットワークを使用していない場合は,
<tt>localhost</tt> の行を以下のように変更してください:
<verb>
127.0.0.1 foo.bar.com foo localhost
</verb>
使用しているホストのエントリを追加してもかまいません.
詳細は関連するマンページを参照してください.
<sect2>
<heading>ppp が -auto モードでダイアルしてくれない</heading>
<p>まず最初に, デフォルトルートが確立しているかどうかチェックして
ください. <htmlurl
url="http://www.freebsd.org/cgi/man.cgi?netstat"
name="netstat -rn"> を実行すると, 以下のような情報が表示されるはずです.
<verb>
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
</verb>
<p>これはあなたがハンドブックやマニュアル, ppp.conf.sample の中で
出てくるアドレスを使用していると仮定した場合の例です.
デフォルトルートが確立していない場合, ppp.conf の中の <tt/HISADDR/
が理解できない, 古いバージョンの <htmlurl
url="http://www.freebsd.org/cgi/man.cgi?ppp"
name="ppp"> が走っている可能性があります. FreeBSD 2.2.5 より前の
バージョンに付属していた <bf/ppp/ を使用している場合,
<verb>
add 0 0 HISADDR
</verb>
<p>と書かれた行を以下のように修正してください.
<verb>
add 0 0 10.0.0.2
</verb>
<p>netstat -rn でデフォルトルートの情報が表示されない場合, もう一つ,
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?rc.conf"
name="/etc/rc.conf"> (2.2.2 より前のリリースでは
<tt>/etc/sysconfig</tt> と呼ばれていました) の中でデフォルトの
ルータを誤って設定し, <tt>ppp.conf</tt> から
<verb>
delete ALL
</verb>
<p>の行をうっかり消してしまった可能性があります.
この場合は, ハンドブックの
<url url="../handbook/userppp:final.html"
name="システムの最終設定"> の項を読み直してください.
<sect2>
<heading>"No route to host" とはどういう意味ですか?</heading>
<p>このエラーは通常, <tt>/etc/ppp/ppp.linkup</tt> に以下のような
セクションが無い場合に起こります.
<verb>
MYADDR:
delete ALL
add 0 0 HISADDR
</verb>
<p>これは動的 IP アドレスを使用している場合, またはゲートウェイの
アドレスを知らない場合にのみ必要な設定です. インタラクティブモード
を使用している場合, <tt/パケットモード/ に入った後で (プロンプトが
<bf/PPP/ と大文字に変わったらパケットモードに入ったしるしです),
以下の命令を入力してください.
<verb>
delete ALL
add 0 0 HISADDR
</verb>
<p>詳しい情報については, ハンドブックの
<url url="../handbook/userppp:dynamicIP.html"
name="PPP と動的 IP 設定"> の項を参照してください.
<sect2>
<heading>3 分ほど経つと接続が切れてしまう</heading>
<p>ppp のタイムアウトは デフォルトでは 3 分です. これは
<verb>
set timeout NNN
</verb>
<p>という命令によって調整することができます. <bf/NNN/ には
接続が切れるまでのアイドル時間が秒数で入ります. NNN が 0 の場合,
タイムアウトによる切断は起こりません. このコマンドは <tt>ppp.conf</tt>
に入れることも, インタラクティブモードでプロンプトから入力することも
できます. ソケットを用いる
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?telnet"
name="telnet"> か
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?pppctl"
name="pppctl"> を使用し, <bf/ppp/s サーバに接続することによって,
回線がアクティブな間に限定してタイムアウトの時間を調整することも
可能です.
<p>訳注 pppctl は 2.2.5R からです.
<p>詳しい情報は
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?ppp"
name="ppp"> のマニュアルを参照してください.
<sect2>
<heading>負荷が高いと接続が切れてしまう</heading>
<p>Link Quality Reporting (LQR) の設定を行っている場合,
マシンと接続先の間で非常にたくさんの LQR パケットが失われている
可能性があります. 結果として ppp は回線の具合いが悪いと考え,
回線を切断するのです. 2.2.5 より前のバージョンの FreeBSD では
LQR はデフォルトで有効になっています. 現在ではデフォルトの状態で
無効です. LQR は以下の命令で無効にすることができます.
<verb>
disable lqr
</verb>
<sect2>
<heading>接続がランダムに切れてしまう</heading>
<p>時々, ノイズの多い回線, あるいは待ち機能付きの回線では,
モデムが (誤って) キャリアを失ったと思い込み, ハングアップしてしまう
ことがあります.
<p>大多数のモデムでは, 一時的なキャリアの喪失にどれだけ我慢するか
設定で決めることができます. 例えば USR Sportster では, S10 レジスタ
の値を 10 倍した秒数がその値になります. この場合, モデムをもっと
のんびり屋さんにするには, dial 行に次のような文字列を加えると
良いでしょう.
<verb>
set dial "...... ATS10=10 OK ......"
</verb>
<p>詳しくはお使いのモデムのマニュアルをご覧ください.
<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 ではネゴジェーションを
自分からは起こさず, クライアントが起こすのを待っています.
<bf/ppp/ に強制的に LCP を発信させるには, 次の命令を使います.
<verb>
set openmode active
</verb>
<p><bf/注/: 両方の側がネゴジェーションを起こしても, 大抵の場合は
何の問題もありません. ですから, 現在では openmode はデフォルトで
active になっています. 次のセクションでこれが問題に<bf/なる/場合を
説明します.
<sect2>
<heading>でもまだ "magic is the same" というエラーが出る</heading>
<p>時折, 接続直後のログに "magic is the same" というメッセージが
あらわれることがあります. このメッセージがあらわれても何も起きない
場合もありますし, どちらかの側が接続を切ってしまう場合もあります.
ppp の実装の多くはこの問題に対応できておらず, その場合にはちゃんと
link が上がっている状態であっても, ppp が最終的にあきらめてしまい
接続を切るまで, 設定のリクエストが繰り返し送られ, 設定が行われた
という通知が log ファイルに残ると思います.
<p>これは通常, ディスクアクセスの遅いサーバマシンのシリアルポートで
getty が生きていて, ppp がログインスクリプトか, ログイン直後に
起動されたプログラムから実行されている場合に起こります. slirp を使用
している場合に同様の症状が見られたという報告もあります. 原因は
getty の終了されるまでと, ppp が実行され, クライアント側の ppp が
Line Control Protocol (LCP) を送り始めるまでのタイミングにあります.
サーバ側のシリアルポートで ECHO が有効なままになっているので,
クライアント側の ppp にパケットが「反射」してしまうのです.
<p>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 のネゴジェーションを十分に行ったものと判断して, さっさと接続を
切ってしまいます. 一方, クライアント側は反射が帰ってこなくなったので
満足しますが, それもサーバが接続を切ったことを知るまでです.
<p>この事態は, 以下の行を ppp.conf の中に書いて, 相手がネゴシェー
ションを開始できるようにする事によって回避できます.
<verb>
set openmode passive
</verb>
<p>これで ppp はサーバが LCP ネゴジェーションを起こすのを待つように
なります. しかし, 自分からは決してネゴジェーションを起こさないサーバ
もあるかもしれません. もしこの状況に遭遇した場合には, 次のようにして
ください.
<verb>
set openmode active 3
</verb>
<p>これによって ppp は 3 秒間 passive モードを続けた後で LCP リク
エストを送り始めます. この間に相手がリクエストを送り始めた場合には
3 秒間待たずにこのリクエストに即座に応答します.
<sect2>
<heading>
接続が切れるまでLCPのnegotiationが続く.
</heading>
<p><bf/ppp/では現在まだ, LCPやCCP, IPCPの返事が元のリクエストと
連携してくれる機能がきちんと実装されていません. その結果, ある
<bf/ppp/が相手よりも6秒以上遅い場合には, LCP configurationのリ
クエストをさらに2回送ります. これは致命的な物です.
<bf/A/と<bf/B/という2つの実装を考えてみましょう. <bf/A/が接続の
直後にLCPリクエストを送り, 一方<bf/B/の方はスタートするのに7秒
かかったとします. <bf/B/がスタートする時には<bf/A/はLCPリクエスト
を3回送ってしまっています. 前の節で述べたmagic numberの問題が起き
ないよう, ECHOはoffになっていると考えています. <bf/B/はREQを送り
ます. するとこれは<bf/A/のREQのうち最初の物に対するACKとなります.
結果として, <bf/A/は<bf/OPENED/の状態に入り, <bf/B/に対して(最初の)
ACKを送ります. そのうちに<bf/B/は, <bf/B/がスタートする前に<bf/A/
から送られたもう2つのREQに対するACKを送り返します. <bf/B/は<bf/A/
からの最初のACKを受け取り, <bf/OPENED/の状態に入ります. <bf/A/は
<bf/B/からの2つ目のACKを受け取りますので, <bf/REQ-SENT/の状態に戻
り, さらに, RFCのとおりに(4つ目の)REQを送ります. そして3つ目のACK
を受け取って<bf/OPENED/の状態に入ります. 一方, <bf/B/は<bf/A/から
の4つ目のREQを受け取りますので<bf/ACK-SENT/の状態に入り, 2つ目の
REQと4つ目のACKをRFCのとおりに送ります. <bf/A/は, REQを受けとると
<bf/REQ-SENT/の状態になり, さらにREQを送ります. そしてすぐにACKを
受け取って<bf/OPENED/の状態に入ります.
<p>これが, 片方の<bf/ppp/があきらめてしまうまで続きます.
<p>これを回避する最も良い方法は, 片方を<bf/passive/モードに設定
する, すなわち反対側がnegotiateを開始するまで待つようにする事です.
これは,
<verb>
set openmode passive
</verb>
というコマンドでできます. このオプションは気を付けて使わないといけ
ません. さらに
<verb>
set stopped N
</verb>
というコマンドを追加して, <bf/ppp/がnegotiationが開始するまで待つ
最大の時間を設定してください. もしくは,
<verb>
set openmode active N
</verb>
というコマンド(ここで, <bf/N/はnegotiationが始まるまで待つ時間です)
を使うこともできます. 詳しくはmanual pageを見てください.
<sect2>
<heading>ppp が接続直後に固まってしまう</heading>
<p>2.2.5 より前のバージョンの FreeBSD では, <bf/ppp/ が Predictor1 圧縮
のネゴジェーションを誤って解釈して, 接続直後にリンクを無効にしている
可能性があります. これは両サイドが 異なる Compression Control
Protocols (CCP) を使ってネゴジェーションを行った場合にのみ発生します.
この問題は現在は解決していますが, あなたの走らせている <bf/ppp/ の
バージョンが古い場合でも, 次の命令で解決することができます.
<verb>
disable pred1
</verb>
<sect2>
<heading>ppp の内部でシェルを起動しようとすると固まってしまう</heading>
<p><tt/shell/ あるいは <tt/!/ コマンドを使用すると, <bf/ppp/ は
シェルを起動し (何か引数を渡した場合は, <bf/ppp/ は引数も
実行します), コマンドが終了するまで処理を中断します. コマンドを
実行中に ppp のリンクを使おうとすると, リンクが固まっているように
見えますが, これは <bf/ppp/ がコマンドの終了を待っているからです.
<p>このような場合は, 代わりに <tt/!bg/ コマンドを使用してください.
与えられたコマンドがバックグラウンドで実行されるので, ppp は
リンクに関するサービスを継続することができます.
<sect2>
<heading>ヌルモデムケーブルを使用しているとき, ppp が終了しない</heading>
<p>ヌルモデムケーブルを使用して直接接続している場合, <bf/ppp/ は
自動的には接続の終了を知ることができません. これはヌルモデム
シリアルケーブルの配線に起因しています. この種の接続形態を用いる
場合は, 以下の命令を用いて LQR を常に有効にする必要があります.
<verb>
enable lqr
</verb>
<p>こうすると, 接続先がネゴジェーションを行う場合, デフォルトで
LQR の使用を受け入れるようになります.
<sect2>
<heading>ppp を -auto モードで動かすと, 勝手にダイアルすることがある</heading>
<p><bf/ppp/ が思いもしないときにダイアルを始める場合, その原因を
突き止め, 防止のために Dial filters (dfilters) をかけてやる
必要があります.
<p>原因を突き止めるためには, 以下の命令を使用してください.
<verb>
set log +tcp/ip
</verb>
<p>これで接続を通過する全てのトラヒックをログに残すことができるように
なりました. 次に突然回線がつながったときのログのタイムスタンプを
たどれば, 原因を突き止めることができるはずです.
<p>原因がわかったら, 次に, このような状況ではダイヤルが起こらないように
しましょう. 通常, この手の問題は, DNS で名前の解決をしようとしたために
起こります. DNS による名前の解決によって, 接続が行われるのを防止する
には, 次のような手段を用います (これは <bf/ppp/ の既に確立した接続
に関してパケットのフィルタリングをするものでは<bf/ありません/).
<verb>
set dfilter 1 deny udp src eq 53
set dfilter 2 deny udp dst eq 53
set dfilter 3 permit 0/0 0/0
</verb>
<p>これはデマンドダイヤル機能に問題を生じさせるため,
常に適切であるとはかぎりません. ほとんどのプログラムは
他のネットワーク関連の処理をおこなう前に DNS への問い合わせ
が必要になります.
<p>DNS の場合は, 何が実際にホスト名を検索しようとしているのかを
突き止めるべきでしょう. 大抵の場合は,
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?sendmail"
name="sendmail"> が犯人です. 設定ファイルで sendmail が
DNS に問い合わせないようになっているか確認すべきです.
自分用の設定ファイルを作成するための詳しい方法は
<ref id="ispmail" name="メールの設定"> の節をご覧ください.
または, <bf/.mc/ファイルに次のような行を追加してもよいでしょう.
<verb>
define(`confDELIVERY_MODE', `d')dnl
</verb>
<p>この行を追加すると, sendmailはメールキューを処理する
(通常sendmailは30分ごとにキューを処理するよう, ``-bd -q30m''
というオプションを付けて起動されます)
までか, または
(多分ppp.linkupというファイルの中で)
``sendmail -q''というコマンドが実行されるまで, 全てのメールを
キューに溜めるようになります．
<p>訳注 ``sendmail -q'' はその時点のメールキューの内容を処理して
終了します．
<sect2>
<heading>CCP エラーとはどういう意味ですか</heading>
<p>ログファイル中の以下のエラーは,
<verb>
CCP: CcpSendConfigReq
CCP: Received Terminate Ack (1) state = Req-Sent (6)
</verb>
<p>ネゴジェーションにおいて ppp は Predictor1 圧縮を用いるべく主張したが,
接続先は圧縮を使用しないことを主張した場合に起こります. このメッセージ
には何の害もありませんが, 出るのが嫌なら, 以下の命令を用いて
こちら側でも Predictor1 圧縮を無効にすることで対応できます.
<verb>
disable pred1
</verb>
<sect2>
<heading>ファイル転送の途中で, ppp が IO エラーを出して固まってしまう</heading>
<p>FreeBSD 2.2.2 以前のバージョンの tun ドライバには, tun インタフェース
の MTU のサイズより大きなパケットを受け取ることができないというバグが
ありました. MTU のサイズより大きなパケットを受け付けると IO エラーが
起こり, syslogd 経由で記録されるのです.
<p>ppp の仕様では, LCP のネゴジェーションを行う場合を含む
<bf>どのような場合でも</bf>最低 1500 オクテットの
Maximum Receive Unit (MRU) を受け入れる必要があります.
ですから, MTU を 1500 以下に設定した場合でも, ISP はそれに関係なく
1500 の大きさのパケットを送ってくるでしょう. そしてこのイケてない
機能にぶちあたって, リンクが固まるのを目にすることになるのです.
<p>FreeBSD 2.2.2 以前のバージョンでは, MTU を決して 1500 より小さく
しないことで, この問題を回避することができます.
<sect2>
<heading>どうして ppp は接続速度をログに残さないんでしょう?</heading>
<p>モデムとの「やり取り」全ての行をログに残すには,
以下のようにして接続速度のログの有効化を行ってください:
<verb>
set log +connect
</verb>
<p>これは
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?ppp" name="ppp">
に最後にくることが要求されている "expect" という文字列がくるま
でのすべてのものをログに記録させます.
<p>接続速度はログにとりたいけれど, PAP や CHAP を使っている
(その結果, dial スクリプト中の CONNECT 以降に全く「やりとり」
を行わない - "set login" スクリプトには何も書かない) のであれ
ば, ppp に "expect" を含んだ CONNECT 行全てがくるまで待たせる
ようにしないといけません, 以下のようになります:
<verb>
set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 4 \"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n"
</verb>
<p>ここで, CONNECT を受信してから, 何も送らず, linefeed を
待っています, <bf/ppp/ に CONNECT の応答全てを読み込ませている
わけです.
<sect2>
<heading>私のchatスクリプトでは`\'という文字をPPPが解釈して
くれません</heading>
<p>PPPは設定ファイルを読み込むときに, <tt/set phone "123 456 789"/
のような文字列を正しく解釈し, 番号が実際に<bf/1つの/引数であると
理解します. ``"''という文字を指定するには, backslash (``\'')で
エスケープしなければなりません.
<p>chatの各引数が解釈されるときには, ``\P''や``\T''のような
特別なescape sequence (man pageを見てください)を見付けるために
もう1回parseを行います. このようにparseは2回繰り返されま
すので, 正しい回数だけescapeを行わないといけません.
<p>モデムにたとえば``\''のような文字を送りたい場合には, 次のように
する必要があります:
<verb>
set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK"
</verb>
<p>実際にモデムに送られる文字列は次のようになります:
<verb>
ATZ
OK
AT\X
OK
</verb>
<p>他の例ですと
<verb>
set phone 1234567
set dial "\"\" ATZ OK ATDT\\T"
</verb>
<p>は次のようになります:
<verb>
ATZ
OK
ATDT1234567
</verb>
<sect2>
<heading>ppp が segmentation fault になるのですが, <tt/ppp.core/
ファイルがありません</heading>
<p>ppp (や他のプログラム) はけして core を吐いてはいけません.
ppp は 実効 uid が 0 で動いていますので, オペレーティングシステム
は ppp を終了させる前にディスクに core イメージを書き込みません.
しかし ppp は実際にはセグメンテーション違反や他の core を吐く原因
となるようなシグナルによって<bf/終了して/ おり, <bf/さらに/ 最新の
バージョン (このセクションの始めを見てください) を使用している
ならば, 次のようにしてください:
<verb>
$ 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
</verb>
<p>これで debug 可能なバージョンの ppp がインストールされます.
root で ppp を実行し, 全ての特権が無効になっているようにする必要
があるでしょう. ppp を実行する時には, current directory が make
した directory であるようにしてください.
<p>これで, ppp がセグメンテーション例外を受け取ったときには
ppp.core という名前の core ファイルを吐くようになります. core が
吐かれたら次のようにしてください:
<verb>
$ su
# gdb /usr/sbin/ppp ppp.core
(gdb) bt
.....
(gdb) f 0
.....
(gdb) i args
.....
(gdb) l
.....
</verb>
<p>質問する際には, これら全ての情報を提供して, 問題点の分析ができ
るようにしてください.
<p>gdb の使い方に慣れている場合には, 実際に dump の原因となった
理由やそのアドレス, 関連した変数の値なども調べる事ができるでしょう.
<sect2>
<heading>
auto modeでdialをするようなprocessがconnectしてくれない
</heading>
<p>これは<bf/ppp/が動的なlocalのIP numberを相手とnegotiateする
ように設定されている時のknown problemです. 最初のプログラムが
<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には戻ってきません.
<p>この問題に対処する理論的な方法がいくつかあります. もし可能なら,
相手が同じIP numberを割り当てなおす事ができるのが最も良いです<tt/:-)/
<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>もう1つの(最も確かな)方法は, 全てのbindされているsocketの
IPを変更するようにsystem callを実装する事です. <bf/ppp/は,
新しくIP numberがnegotiateされた時に, このsystem callを用いて
全てのsocketを書きかえるのです.
<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>現在のところ, これらの方法のどれもまだ実装されていません.
<sect2>
<heading>何故ほとんどのゲームが -alias スイッチ付きだと動かないんですか?</heading>
<p>訳注:この問題は佐藤 淳一さん作の NAT パッチを使っても解決できます.
<htmlurl url="http://www2a.biglobe.ne.jp/~junichi/freebsd/lowtech/nat.html"
name="NAT on iij-ppp">をご覧ください.
<p>libalias を使っている時にゲームなどの類のものが動作しない理由は,
外側にあるマシンが接続しようとしているか, 内側にあるマシンに (余計な)
UDP パケットを送信しようとしているからです.
内側のマシンにこれらのパケットを送るべきかについて,
packet alias ソフトウェアは関知しません.
<p>うまく動かすためには, 実行中のものが問題の発生している
ソフトウェアだけであるかを確認し, ゲートウェイの tun インタフェースに対して
tcpdump を実行するか, ゲートウェイ上で ppp tcp/ip logging を有効化
(``set log +tcp/ip'') してください.
<p>行儀の悪いソフトウェアを起動する際に, ゲートウェイマシンを
通過するパケットを監視すべきです. 外側から何かパケットが戻ってきた時に,
そのパケットは破棄されるでしょう (それが問題なのです).
これらのパケットの port 番号に注意して, その行儀の悪いソフトウェアを
停止してください.
これを数回繰り返して port 番号が常に同じであるかを確認してみてください.
同じであった場合は, /etc/ppp/ppp.conf の適切なセクションに次の行を入れると,
そのソフトウェアは動作するようになるでしょう.
<verb>
alias port proto internalmachine:port port
</verb>
<p>ここで ``proto'' は ``tcp'' か ``udp'' であり,
``internalmachine'' はパケットを送りたいマシン, そして
``port'' はパケットのディストネーションの port 番号です.
<p>上記のコマンドを変更せずに他のマシン上でそのソフトウェアを
使用できるようにはしたくないかもしれません. そして
同時に二つの内部のマシン上でそのソフトウェアを実行することは
この質問の範囲を超えています. 結局, 外側の世界からは
内部ネットワーク全体がただ一つのマシンとして見えるのです.
<p>port 番号が常に同じとは限らない場合, さらに三つのオプションがあります.
<p><bf>1)</bf>libalias でサポートするようにし, 結果を送り付ける.
特定の場合の例は /usr/src/lib/libalias/alias_*.c にあります
(alias_ftp.c は良いプロトタイプです). これには通常, 外向きの特定のパケットを読み,
内部の計算機のある特定のポートへの接続を開始するような命令が
外部の計算機対して送られていることを見分け, 後続のパケットがどこに行けば
いいのかが分かるように, エイリアステーブル中の ``route'' の部分を設定する,
という作業が含まれます.
<p>これは最も難しい方法ですが, 最も良い方法でもありますし, ソフトウェアが
複数の計算機で動くようにできます.
<p><bf>2)</bf>プロクシを使う. アプリケーションが, 例えば socks5
をサポートしているか, (cvsup のように) ``passive'' オプションを持っていると
この方法が使えます. ``passive'' とは相手側のほうから接続を求めてくることを
避けるためにあるオプションです.
<p><bf>3)</bf>''alias addr''を使ってなんでもかんでも内部の計算機に向けて
流してしまう. これはちょっと無理矢理な解決法です.
<sect2>
<heading>FCS エラーって何?</heading>
<p>FCS とは <bf/F/rame <bf/C/heck <bf/S/equence (フレームチェック
シーケンス) の略です. 個々の ppp パケットには, 送受信するデータ
が正しいかを調べるためのチェックサムが含まれています. 受信した
パケットの FCS が正しくない場合は, そのパケットは廃棄され, HDLC
FCS カウントが増やされます. HDLC エラーの数 は, <tt>show hdlc</tt>
コマンドを使って表示できます.
<p>リンクの品質が悪かったり, シリアルドライバがパケットを取り
こぼしていたりすると, FCS エラーがたびたび発生します. FCS エラー
は, 圧縮プロトコルの速度低下の原因にはなりますが, 特に心配する
必要はありません. 外付けモデムを使っている場合は, ケーブルが
ちゃんとシールドされているかを確認してください. そうでない場合,
FCS エラーの原因となる場合があります.
<p>接続直後からリンクがフリーズし, 大量の FCS エラーが発生する
場合は, リンクが 8 ビットクリーンでない可能性があります. ソフト
ウェアフロー制御 (XON/XOFF) が使われていないことを確認してくだ
さい. どうしてもソフトウェアフロー制御を使わなければならない場
合は, <tt>set accmap 0x000a0000</tt> コマンドを使用して, ppp
に ^Q と ^S をエスケープさせてください
<p>リモートホストが <bf/PPP/ プロトコルを使用してない場合も, 大量の
FCS エラーが発生します. この場合はログをとりながら<tt/非同期/で
接続し, ログインプロンプトやシェルプロンプトが送られて来てい
ないか確認してください.
<p>ログファイルにリンクを終了した原因となるような記録がない場合は,
リモートホスト(プロバイダ?)の管理者に, セッションを終了された
理由を尋ねてください.
<sect2>
<heading>どれにも当てはまらない! どうしたらいいの?</heading>
<p>これまでの全ての質問に当てはまらない場合, 設定ファイル, <bf/ppp/
の実行方法, ログファイルの該当部分と
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?netstat"
name="netstat -rn"> コマンドの出力 (接続前と接続後) を含む,
あなたの持っている全ての情報を
<url url="mailto:freebsd-questions@FreeBSD.org"
name="freebsd-questions@FreeBSD.org"> メーリングリストや
<url url="news:comp.unix.bsd.freebsd.misc"
name="comp.unix.bsd.freebsd.misc"> ニュースグループへ
送ってください. 誰かがあなたを正しい方向へ導いてくれるでしょう.
<sect1>
<heading><tt>/dev/ed0</tt> デバイスを作成することができません. </heading>
<p>
Berkeley UNIX におけるネットワークの構成においては, ネットワーク
のインタフェースは kernel のコードからのみ直接あつかうことが
できます. より詳しく知りたい場合は, <tt>/etc/rc.network</tt>
というファイルや, このファイルの中に書いてあるさまざまなプログラム
についてのマニュアルページを見てください. それでもまだ分からない場合には,
他の BSD 系の OS のネットワーク管理についての本を読むべきでしょう.
ごく少しの例外をのぞいては, FreeBSD のネットワーク管理は SunOS 4.0
や Ultrix と基本的に同じです.
<sect1>
<heading>Ethernet アドレスのエイリアスはどのようにして設定できますか?</heading>
<p><htmlurl url="http://www.freebsd.org/cgi/man.cgi?ifconfig"
name="ifconfig"> のコマンドラインに ``<tt/netmask 0xffffffff/''
を追加して, 次のように書いてください.
<verb>
ifconfig ed0 alias 204.141.95.2 netmask 0xffffffff
</verb>
<sect1>
<heading>3C503 で他のネットワークの port を使用するにはどのようにすればよいですか?</heading>
<p>他の port を使用したい場合には, <htmlurl
url="http://www.freebsd.org/cgi/man.cgi?ifconfig"
name="ifconfig"> のコマンドラインにパラメータを
追加しなければなりません. default は ``<tt/link0/''
が用いられるようになっています. BNC のかわりに AUI port
を使用したい場合には ``<tt/link2/'' というパラメータを
追加してください.
これらのフラグは <htmlurl
url="http://www.freebsd.org/cgi/man.cgi?rc.conf" name="/etc/rc.conf">.
の using the ifconfig_* の変数を使って指定されるはずです.
<sect1>
<heading>FreeBSD との間で NFS がうまくできません. </heading>
<p>PC 用のネットワークカードによっては NFS のようなネットワークを
酷使するアプリケーションにおいて問題を起こすものがあります.
<p>この点に関しては <url
url="../handbook/nfs.html" name="ハンドブックの NFS についての節">
を見てください.
<sect1>
<heading>何故 Linux のディスクを NFS マウントできないのでしょうか?</heading>
<p>Linux の NFS のコードによっては許可されたportからの
リクエストからしか受けつけないものがあります.
以下を試してみてください.
<verb>
mount -o -P linuxbox:/blah /mnt
</verb>
<sect1>
<heading>何故 Sun のディスクを NFS マウントできないのでしょうか?</heading>
<p>SunOS 4.X が走っている Sun Workstation は許可された port からの
mount のリクエストしか受けつけません.
以下を試してみてください.
<verb>
mount -o -P sunbox:/blah /mnt
</verb>
<sect1>
<heading>PPP で NeXTStep に接続する際に問題があるのですが. </heading>
<p><htmlurl url="http://www.freebsd.org/cgi/man.cgi?rc.conf"
name="/etc/rc.conf"> の中で次の変数を NO にして,
TCP extension を無効にしてみてください.
<verb>
tcp_extensions=NO
</verb>
<p>Xylogic の Annex も同様の問題がありますので, Annex 経由で PPP をおこなう
場合にもこの変更を行ってください.
<sect1>
<heading>IP multicast を有効にするには?</heading>
<p>2.0 かそれ以降の FreeBSD は, 標準の状態で完全に multicast に対応しています.
現在使用している計算機を multicast の router として使用するには,
<tt/MROUTING/ というオプションを定義したカーネルを作ったうえで,
<tt/mrouted/ を走らせる必要があります. 2.2 かそれ以降の FreeBSD ならば,
<tt>/etc/rc.conf</tt> でフラグ <tt/mrouted_enable/ を "YES" にセットして
おくことで, ブート時に <tt/mrouted/ を起動できます.
<p>MBONE用のツールは ports 内の専用のカテゴリー mbone にあります.
<tt/vic/ や <tt/vat/ といった会議用のツールを探している場合はこの場所を
見てください.
<p>詳しい情報は
<url url="http://www.mbone.com/" name="Mbone Information Web">
にあります.
<sect1>
<heading>DEC の PCI チップセットを用いている network カードにはどのような物がありますか?</heading>
<p><url url="mailto:gfoster@driver.nsta.org"
name="Glen Foster"> による一覧に, よりmodernな物を追加したものを
以下に示します.
<verb>
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
</verb>
<sect1>
<heading>何故自分のサイトのホストに対して FQDN を使用する必要があるのですか?</heading>
<p>実際にはそのホストは別のドメインにあるのではないですか. たとえば,
foo.bar.edu というドメインの中から, bar.edu ドメインにある
``mumble'' というホストを指定したい場合には, ``mumble'' だけでは
駄目で, ``mumble.bar.edu'' という fully-qualified domain name で
指定しなければなりません.
<p>伝統的に, BSD の BIND の resolver ではこのような事は可能でしたが,
FreeBSD に入っている <htmlurl
url="http://www.freebsd.org/cgi/man.cgi?named" name="bind">
の現在のバージョンでは, 自分以外のドメインに対して FQDN
でない別名を自動的につけてくれるような事はありません.
したがって <tt>mumble</tt> というホスト名は <tt>mumble.foo.bar.edu</tt>
という名前か, もしくは root ドメイン内にある場合にしか適用されません.
<p>これは, <tt>mumble.bar.edu</tt> と <tt>mumble.edu</tt>
ということなったドメイン名に対してホスト名のサーチがおこなわれていた
以前の振る舞いとは異なったものです. このような事が悪い例もしくは
セキュリティホールとみなされる理由については RFC 1535 を見てください.
<p><htmlurl url="http://www.freebsd.org/cgi/man.cgi?resolv.conf"
name="/etc/resolv.conf"> の中で
<verb>
domain foo.bar.edu
</verb>
<p>と書いてある行を
<verb>
search foo.bar.edu bar.edu
</verb>
<p>のように書きかえることで, 上のような事ができます. しかし,
RFC 1535 にあるように, search order が ``ローカルな管理と
パブリックな管理の境界'' をまたがないようにしてください.
<sect1>
<heading>すべてのネットワークの操作に対して ``Permission denied'' というメッセージが表示されるのですが. </heading>
<p><tt/IPFIREWALL/オプションを付けてkernelをコンパイルした場合には,
2.1-STABLE の開発の途中から変更になった 2.1.7R の標準的な方針として,
明示的に許可されていないすべてのパケットは落とされる設定
になっている事を覚えておいてください.
<p>もしfirewallの設定を間違えた場合にネットワークの操作が再びできる
ようにするには, root で login して次のコマンドを実行してください.
<verb>
ipfw add 65534 allow all from any to any
</verb>
<p><tt>/etc/rc.conf</tt>に"firewall_type='open'"を追加してもよい
でしょう.
<p>FreeBSD の firewall の設定についての情報は
<url url="../handbook/firewalls.html" name="FreeBSD ハンドブック">
にあります.
<sect1>
<heading>IPFWのオーバーヘッドはどのくらいでしょうか?</heading>
<p>この答えはあなたのrule setとprocessorのスピードによって
ほとんど決まります. Ethernetに対して少しのrule setだけを使っ
ているほどんどの場合には, その影響は無視できる程度です. 実
際の測定値を見ないと満足できない方々のために, 実際の測定結
果をお見せしましょう.
<p>次の測定は486-66上で2.2.5-STABLEを使用しておこなわれました.
IPFWは変更が加えられて, <tt/ip_fw_chk/ルーチン内でかかる時間を
測定して1000パケット毎に結果をconsoleに表示するようになっています.
<p>それぞれ1000ずつのruleが入っている2つのrule setでテストが
おこなわれました. ひとつ目のsetは最悪のケースを見るために
<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>2つ目のsetは, なるべく早くチェックが終了するように書かれたものです:
<verb>
ipfw add deny ip from 1.2.3.4 to 1.2.3.4
</verb>
<p>このruleではsource側のIPアドレスがマッチしないのでチェックは
すぐに終了します. 上のsetとおなじように, 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>2つ目のsetでは, それぞれのpacketはだいたい1.172msで処理されて
いますので1つのruleあたり1.2マイクロ秒となります. packetの
処理時間の理論的な限界はだいたい1秒あたり853 packetとなりますので
10Mbps Ethernetのバンド幅を使い切ることができます.
<p>このテストでのruleの数は多過ぎますので, 実際に使用している際の
結果を反映している訳ではありません. これらは上に示した数値を出す
ためだけに用いられたものです. 実際に効率の良いrule setを作るために
は, 次のような事を考えておけばよいでしょう.
<itemize>
<item>`確定している' ruleは, TCPのtrafficの多数を処理するために
前の方に持ってきてください. そしてこのruleの前には<tt>allow tcp</tt>
という記述をしないでください.
<item>良く使われるruleを, あまり良く使われないruleよりも
前の方に(もちろん<bf>firewallの許可の設定を変えない範囲で</bf>)
持ってきてください.
<tt>ipfw -a l</tt>のようにしてpacket数の統計を取ることによって
どのruleが最もよく使われているかが分かります.
</itemize>
<sect1>
<heading>サービス要求を他のマシンにリダイレクトするには?</heading>
<p>FTP などのサービスのリクエストは, 'socket' パッケージを利用
してリダイレクトできます. 'socket' パッケージは ports の
'sysutils' カテゴリに含まれています. リダイレクトしたいサービ
ス(<tt>/etc/inet.conf</tt>のコマンド行を socket を呼ぶように変
更してください. 変更例:
<verb>
ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.foo.com ftp
</verb>
<p>ここで 'ftp.foo.com' はリダイレクト先のホスト名, 行の最後の'ftp'
はポートです.
</sect>
Reference in a new issue View git blame Copy permalink