diff --git a/ja/handbook/submitters.sgml b/ja/handbook/submitters.sgml index 10342e6381..3fbf2b1667 100644 --- a/ja/handbook/submitters.sgml +++ b/ja/handbook/submitters.sgml @@ -1,1572 +1,1576 @@ - + - + FreeBSD への貢献

原作: &a.jkh;.

訳: &a.iwasaki;.27 April 1997.

あなたも何か FreeBSD のために貢献したくなりましたか? 素晴らしい! 私たちは常に支援を受ける用意がありますし, FreeBSD は生き残るためにユー ザベースの貢献に頼るようなシステムの一つです. あなたの貢献は 感謝されるだけではなく, FreeBSD が成長し続けるために極めて重要なものな のです!

一部の人達が言っているのとは逆に, 貢献を受け付けてもらうために腕利 きのプログラマーになるとか FreeBSD コアチームの人と親友になる必要はあ りません. FreeBSD プロジェクトの開発は, 多くのそして益々増加する世界中 の貢献者達によってなされており, 彼らの年齢, 専門技術分野は多岐に渡りま す. そして手の空いている人よりも成されるべき仕事の方が常に多いのです.

FreeBSD プロジェクトがカーネルや散在しているユーティリティよりも, オペレーティングシステム環境 (と, そのインストール) に対して責任を持つ ようになったため, 私たちの「TODO」リストはドキュメンテーション, ベータテ スト, 高度に専門化されたタイプのカーネル開発の好例を紹介するなど非常に 広い範囲のタスクに渡ります. あなたの技能レベルに関わらず, プロジェクト を支援できることが必ず何かあります!

FreeBSD 関連の事業に従事している商業団体が私たちにコンタクトすること も歓迎します. あなたの製品を (FreeBSD 上で) 動作させるには, 特別な拡張 が必要ではありませんか? あまりにも風変わりな要求でなければ, それを受け 入れる用意が私たちにあるとわかるはずです. 付加価値のある製品ですか? 私たちに知らせてください! 多分私たちは, ある 面において共同して作業をすることができるでしょう. フリーソフトウェア界 は, ソフトウェアがそのライフサイクルを通してどのように開発され, 売られ, 保守されていくかについて, 既存の仮説に挑戦しています. 少なくとももう一 度考慮してみることを私たちは強くお奨めします. 何が必要?

次のタスクとサブプロジェクトのリストは, コアチームの色々な TODO リ ストと最近2ヶ月で集めたユーザリクエストを合わせたものです. 可能なとこ ろでは, 緊急度によってタスクがランクづけされています. もしここにあるタ スクの実行に興味があるのでしたら, コーディネータの名前をクリックしてメー ルを送ってください. もしコーディネータが決まっていなければ, あなたがボ ランティアしてみませんか? 優先度の高いタスク

次のタスクは通常, ひどく壊れているとか, とても必要とされている何かを 表しているため, 急務と考えられています: 第3ステージ・ブート問題. 全体コーディネーション: &a.hackers

64MB を越えるメモリの正しい自動検出. userconfig (-c) の 第3ステージ・ブートへの移動. 第3ステージがディスクの BIOS ジオメトリの正確なマッピングを提供 できるように WinNT コンパチブルなドライブの追跡をおこなう. ファイルシステム問題. 全体コーディネーション: &a.fs MSDOS ファイルシステムの修正. nullfs ファイルシステムコードのクリーンアップと ドキュメンテーション. コーディネータ: &a.gibbs union ファイルシステムの修正. コーディネータ: &a.dyson カーネル vm86 及びユーザ vm86 サポート実装. コーディネータ: &a.hackers Int13 vm86 ディスクドライバの実装. コーディネータ: &a.hackers SCSI ドライバ問題. 全体コーディネーション: &a.hackers

タグキューイングの一般的なサポート. 私たちのおこなっている コマンドキューイング方法の書換えが必要だが, とにかく優先度付けされた I/O にはこれが必要 (CD-R ライタ / スキャナ). エラー処理の改善 (ビジー・ステータスおよびリトライ). 統合された Scatter-Gather リスト生成コード. カーネル問題. 全体コーディネーション: &a.hackers

すべての現存ドライバの eisaconf 変換の達成. すべての割り込みルーチンをユニット番号を使う代わりに (void *) を 取るように変更. EISA/PCI/ISAの割り込み登録コードの統合. PCI/EISA/ISA デバイス検出を bt742a.c(WIP) のようなドライバから分割. syscons の ALT-Fn/vt 切替えによるハングの修正. コーディネータ: &a.sos Intel Etherexpress 16 ドライバの書換え. 3c509と3c590 ドライバの統合 (本質的には PCI デバイス検出の ep.c への提供). Adaptec 3985 (シンプルな3チャネル SCSI カードとしては最初のもの) のサポート. コーディネータ: &a.gibbs Advansys SCSI コントローラ製品のサポート. コーディネータ: &a.gibbs 優先度がさほど高くないタスク

次のタスクはやっておくべきではありますが, 特にさし迫っているわけで はありません: AFS (Andrew ファイルシステム) の FreeBSD への移植 コーディネータ: MCA サポート? これは続けるにしても止めてしまうにしても結論を出 すべき. 完全な LKM ベースのドライバのサポート / コンフィグレーションマネー ジャ.

ld なしですべての LKM の登録をおこなう方法を考案する. これは カーネル中にある種のシンボルテーブルを持たせることを意味します. 穏やかな方法でハードウェアを検知するコンフィグレーションマネージャ の作成 (第3ステージ・ブートの中に?). ハードウェアが必要とする LKM だけを 残す等. PCMCIA/PCCARD. コーディネータ: &a.nate と &a.phk ドキュメンテーション! pcic ドライバの信頼性のある操作 (テスト要). sio.c のリコグナイザとハンドラ (ほぼ完了). ed.c のリコグナイザとハンドラ (ほぼ完了). ep.c のリコグナイザとハンドラ (ほぼ完了). User-mode のリコグナイザとハンドラ (部分的に完了). 先進的なパワーマネージメント. コーディネータ: &a.nate と &a.phk APM サブドライバ (ほぼ完了). IDE/ATA ディスクサブドライバ (部分的に完了). syscons/pcvt サブドライバ. PCMCIA/PCCARD ドライバ群との統合 (サスペンド / レジューム). 優先度の低いタスク

次のタスクは全くのあら隠し, または誰もすぐにおこないそうもない投資 のような仕事を表します:

最初の20項目は Terry Lambert <terry@lambert.org> からのもので す. プロセッサ上で V86 モードを使用して, プロテクトモードからの BIOS コールができるようにし, マップされた割り込み IPC 機構を経由してプロテ クトモードの呼出し元に結果を返すようにする. DOS と同じように, 実際の下位ハードウェアから独立になるよう, BIOS コール機構を使用したカーネルの中に組み込まれたドライバ. これは DOS ベー スのローダプログラムで BSD がロードされる前に DOS にロードされていたネッ トワークドライバや ASPI ドライバも含みます. このことは潜在的なポーリン グ, つまりプロテクトモードカーネルによる V86 マシンのための DOS-not-busy 割り込みの生成を意味します. ハードウェア固有のプロテクトモードのドライバがロードされて活性化 された後で, デフォルトのカーネル実行形式の中の, そのようなドライバデー タとテキストエリアを追跡して, カーネルアドレス空間のその部分が回復され るようにするためのイメージ形式. これは個々の BIOS ベースのドライバを互いに分離することを含みます. なぜ なら全く実行しないよりも, すべてのケースにおいて BIOS ベースのドライバ と共に実行した方が良いためです. バスインタフェース機構の抽象化. 現在のところ, PCMCIA, EISA そし て PCI バスはブリッジで ISA バスに接続されていると仮定しています. こう いった仮定はおこなうべきではありません. パワーマネージメントイベント, カードの挿入, 取り出し, そしてバス (PNPISA と PCMCIA とのブリッジチップ) 対カードのレベルのイベント管理を 含む PNP イベントを解釈するコンフィグレーションマネージャ. 固定デバイスによる他の再割当可・不可のデバイス空間リソースの使用 と衝突しない, 再割当可能なアドレスの割り当てのためのトポロジカルソート 機構. ハードウェアサービス登録のための登録ベースの機構. 特にタイマ, サウンドおよび他のシステムクリティカルなサービス供給源のためのデバイス 中心の登録機構. 単一の独立していないサービス供給源の一つの例として Timer2, Timer0 そしてスピーカサービスを考慮する必要があります. 配置転換とシンボル空間操作をおこなう LKM ローダ機構からアクセス 可能な, カーネルのデータ空間内にあるエキスポートされたシンボル空間. こ のインタフェースの目的は, 必要な時にカーネルモジュールをロードして, 必 要がなくなればアンロードできる能力をサポートすることです. ネットワークカードと一緒に提供される ODI カードドライバを使用で きるようにする, NetWare サーバ (プロテクトモードの ODI ドライバ) ロー ダとサブサービス. NDIS ドライバと NetWare の SCSI ドライバについても同 様. 前のリビジョンの FreeBSD マシンではなく, Linux マシンで動作する 「アップグレード システム」オプション. 移植を簡単にするためと, X, ThinkPad, PS/2マウス, LED, コンソール スイッチング, しつこい NumLock などの問題を全部一度に片付けるためのコ ンソールドライバの抽象レイヤへの分割. 機会が許したら, 他の外部ドライバのための他のカーネルのエミュレー ション環境. SCO と Solaris は UnixWare などに続く良い候補です. 異なるアーキテクチャのバイナリの実行のためのプロセッサエミュレー ション環境. これはシステムコールインタフェースがあまり変わらなければ, 思ったより簡単です. 商用のストリームドライバを使用可能にするためのストリーム機構. カーネルのマルチスレッド化 (カーネルのプリエンプションが必要). カーネルのプリエンプション付き対称マルチプロセッシング (カーネル のプリエンプションが必要). ポータブルコンピュータのサポートにおける協調の試み. これは PCMCIA ブリッジング規則と電源管理イベント処理の変更により, いく らかは処理できます. しかし, 内蔵ディスプレイと外部ディスプレイの検出, この2種類のディスプレイがあるという事実に基づく異なる解像度の選択, マ シンがドックにある場合にはディスクのモータ停止を防止すること, マシンの ブート能力に影響を与えずにドックベースのカードの消滅を可能にすること (PCMCIA と同じ問題) などの問題があります. マルチプラットフォームへの移植のためのソースツリーの再組織化. 「make world」できちんと「世界を創造する」ができるようにする. (もし「make regress 訳注: 後退する」と呼び方が適当であれば, そのように 名前を変える) 最小必要メモリ 4MB 化 (もっと小さければなお良し!). もっと簡単なタスク

上のセクションで挙げたタスクは膨大な時間の投資または FreeBSD のカーネルに関する深い知識を必要とします(もしくはそのどちらも). しかしながら, "週末ハッカー"やプログラミングのスキルを持 たない人々に適した立派なタスクも数多くあります. FreeBSD-current を運用しており, 状態の良いインターネット接続があ るならば, current.freebsd.org という一日に一回フルリリースを行っている マシンがあります - 時おり最新のリリースをそこからインストールし, その 過程で何か問題があるなら報告して下さい. freebsd-bugs メーリングリストを読んでください. そこではあなたが建 設的なコメントを付たりテストできるパッチが提供されているような問題がある かもしれません. もしくはそれらの問題の一つをあなた自身で修正することさえ できるかもしれません. 定期的に FAQ とハンドブックを通して読んでみてください. もしまずい説明や古い事柄や完全に間違っていることなどがあれば我々に しらせて下さい. さらに良いのは我々に修正案を送ることです (SGML は学ぶのにそれほど難しくありませんが, プレインテキストでも問題は ありません). (もしまだないならば) FreeBSD のドキュメントを自分の母国語に翻訳 するのを手伝ってください - 作業している人がいるかどうか &a.doc にメールを 送って聞くだけです. とはいっても, そうすることによってあなたが全ての FreeBSD ドキュメントの翻訳に携わるようになるというわけではないですから ね - 実際, もっとも翻訳が必要とされているドキュメントはインストール方 法です. たまに(もしくは定期的に) freebsd-questions メーリングリストや comp.unix.bsd.freebsd.misc を読んでください. これは, あなたの持ってい る専門知識を共有したり誰かが抱えている問題を解決するのに非常に有効な ものになり得ることです. 時にはあなた自身で新しいことを学ぶことさえ できるかもしれません. これらのフォーラムはやるべきことのアイディア の源にもなり得るのです. -current に正しく当てられるがしばらく経っても(通常は 2, 3 週間) -stable に取り込まれてないようなバグフィックスがあるならばコミッターに 丁寧に思い出させてください. 寄贈ソフトウェアをソースツリーの src/contrib に移動させてください. src/contrib 以下のコードが最新のものであるか確認してください. 2000 年問題に関するバグを探してください(そして, 見つけたら修正してください!). ソースツリー全体(もしくはその一部)を, 警告を詳細に報告するようにして構築してみてください. そして警告が出ないようにしてください. ports で, gets() を使っているとか malloc.h をインクルードしている などといった警告が出ないようにしてください. もしなんらかの ports に関わっているなら, あなたのパッチを作者に フィードバックしてください(次のバージョンが出た時にあなたが楽になります). このリストに追加するタスクを提案して下さい! 貢献の仕方

一般的に, システムへの貢献は次の6つのカテゴリの1つ以上に分類されます: バグ報告と一般的な論評

報告するべきバグがあったり, 提案したいことがあれば:

一般的な技術的関心事に関するアイデアや提案は &a.hackers; へメールしてください. 同様に, このような事柄に興味のある (そして膨大なメール! に耐えられる) 人は, &a.majordomo; へメールを送って hackers メーリングリストに参加すると良いでしょう. 情報については を参照してください. バグを発見したり変更を送付しようとしている場合は send-pr(1) プログラムか を使用して報告してください. バグレポートの各項目を埋めるようにしてください. 65KB を超えるのでなければ, レポート中に直接 パッチを入れてくださって結構です. 20KB を超える場合は, それらを compress して uuencode(1) することも検討してください. レポートがファイリングされれば, バグ報告の確認と トラッキング番号をメールで受け取るはずです. このトラッキング番号を覚えておき, 問題に関する詳細情報を に メールで送って更新できるようにしてください. 例えば "Re: kern/3377" のように, この番号をサブジェクト行に使用してください. すべてのバグレポートの追加情報は, この方法で送付されなければいけません. もしタイムリに (あなたの電子メール接続形態にもよりますが, 3日から 1週間) 確認を受けとれないとか, 何らかの理由で send-pr(1) コマンドが 使用できない場合には, &a.bugs; へメールを送り, 誰か代りにバグ報告を 送付してもらうようたずねてください. 文書の変更

文書の変更は &a.doc; が監督しています. に記述されているように send-pr コマンドを使用して, 提案や変更 (どんな些細なものでも歓迎します!) を送ってください. 現存のソースコードの変更

現存のソースコードへの追加または変更は, いくらかトリッキーな仕事で あり, core の FreeBSD 開発の現状にあなたがどれだけ通じているかに大 きく依存します. 「FreeBSD-current」として知られる FreeBSD の特別な 継続的リリースがあります. FreeBSD-current は開発者の積極的な活動の 便宜のために, 色々な方法で利用可能になっています. FreeBSD-current の入手と使用方法についての詳しい情報については を参照してください. 不幸にして古いソースをもとに仕事をすることは, 時々あなたの変更が時 代遅れ, または FreeBSD への簡単な再統合に合わなくなっていることを意 味します. システムの現状に関する議論がおこなわれている &a.announce と &a.current へ参加することで, この可能性を最小限にすることができます. 完全な最新のソースを変更のベースにできることが確実になったと仮定し て, 次のステップは FreeBSD の保守担当者へ送る差分ファイルの生成です. これは diff(1) コマンドを使用しておこないますが, 「context diff」形式が好まれるようです. 例えば: diff -c oldfile newfile または diff -c -r olddir newdir これで指定されたソースファイルまたはディレクトリ階層に対するコンテ キスト形式の差分が生成されます. 詳しい説明は diff(1) のマ ニュアルページを参照してください. 差分ファイル (patch(1) コマンドでテストできます) を作ったら, それらを FreeBSD に含めてもらうようメールで送ってください. に記述されているように send-pr コマンドを使用してください. 差分ファイルだけを &a.hackers; へ送ってはいけません. 途方にくれてしまいます! 私たちは多忙なので, あなたの提案に大変感謝します (これはボランティアのプロジェクトです!). すぐに取りかかることはできませんが, 処理されるまでは ちゃんと pr データベースに残っています. あなたがそうした方がいいと思う場合 (例えば, ファイルの追加, 削除または名称変更など), 変更を tar ファイルにまとめ, uuencode(1) プログラムにかけてください. Shar アーカイブも歓迎します. 例えばあなたがそれ自身のさらなる配布を管理するコピーライト問題を良 く分かっていないとか, 単に厳しいレビューをおこなっておらず, リリース する準備ができていないなど, あなたの変更が潜在的に不安定な性質をも つものである場合, send-pr(1) で送付するよりむしろ &a.core; へ直接送ってください. コアチームメーリングリスト宛のメールは, 日々の仕 事のほとんどを FreeBSD でおこなっている人たちの, より小さなグルー プに届きます. このグループもまたとても忙しい ことに注意し て, 本当に必要な場合にコアチームの彼らにメールを送るだけにしてください. コーディングスタイルに関する情報は man 9 intro および man 9 style を参照してください. コードを提出する前には, 少なくともこの情報を意識しておいてくださるようお願いします. 新たなコードやメジャーな付加価値の高いパッケージ

重要な大きい仕事の寄贈や, 重要な新しいフィーチャーを FreeBSD に追加 する稀な場合には, 変更点を tar/uuencode したファイルにして送るか, それらを私たちの ftp サイト へアップロードす ることのどちらかが通常必要になります. 大量のコードを伴った仕事の場合, コピーライトの神経過敏な問題が常に 出てきます. FreeBSD に含めるコードのコピーライトとして受け入れるこ とができるのは, 以下の二つです: BSD コピーライト. このコピーライトは「権利に縛られない」性格 と商用企業にとって一般的な魅力をもつために最も好まれま す. FreeBSD プロジェクトは商用利用を阻んだりせず, 何かを FreeBSD へ投資する気になった商業関係者による参加を積極的に奨励 します. GNU一般公有使用許諾, または「GPL」. このライセンスはコード を商用目的に使用する場合に余分な努力が求められるため, 私たち にあまり評判が良いというわけではありません. しかし, 私たちは 既に GPL 下の高品質なコード (コンパイラ, アセンブラ, テキスト フォーマッタ等) の提供を受けており, 私たちは現在それを必要と しています. そのため, このライセンスによる新たな貢献を拒絶す るというのは愚かなことでしょう. GPL 下のコードはソースツリー の別の部分, 現在のところ /sys/gnu か /usr/src/gnu に入っています. そのため, GPL が問題と なるような人は, 誰でも簡単にそれとわかるようになっています.

これ以外のタイプのコピーライトによる寄贈は, FreeBSD へ含めることを 考慮する前に, 注意深いレビューを受けなければなりません. 作者が独自 のチャネルを通して配布しており, そのような変更をおこなうことを常に 奨励している場合でも, 特に限定的な商用のコピーライトが適用される寄 贈は一般に拒否されます. あなたの作品に「BSD-スタイル」のコピーライトを付けるには, 保護した いソースコードファイルすべての一番最初に以下のテキストを入れて, `%%' の間を適切な情報に置き換えください. Copyright (c) %%適切な年%% %%あなたの名前%%, %%あなたの州%% %%郵便番号%%. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer as the first lines of this file unmodified. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS SOFTWARE IS PROVIDED BY %%あなたの名前%% ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL %%あなたの名前%% BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. $Id$ 便宜をはかるため, このテキストのコピーは次の場所に置いてあります. /usr/share/examples/etc/bsd-style-copyright. (訳注: 以下は神田敏広氏より寄贈された bsd-style-copyright の日本語訳です. ソースファイルに含めるものは原文の方であることに注意してご利用ください. また, 原文との間に趣旨の差異が生じた場合, 原文の内容が FreeBSD プロジェクトの 意思であるものとします.) Copyright (C) [年] [あなたの名前] All rights reserved. ソースとバイナリ形式の再配布および使用は, 変更の有無にかかわらず以下の 条件を満たす場合に限り許可される: 1. ソースコードの再配布は, 上記の著作権表示・この条件のリスト・下記の 否認声明文を保持しなければならない. 2. バイナリ形式の再配布は, 上記の著作権表示・この条件のリスト・下記の 否認声明文を, 配布物と共に提供される文書および/または他の資料の中に 含めなければならない. (訳注:ここから「否認声明文」です) このソフトウェアは[あなたの名前]および貢献者によって ``あるがままの状態'' で提供され, 商品性と特定の目的に対する適合性についての暗黙の保証に留ま らず, いかなる明示および暗黙の保証を認めない. [あなたの名前]および貢献 者は, あらゆる直接的・間接的・偶発的・特殊的・典型的・必然的な損害 (代 替製品または代替サービスの獲得費; 効用・データ・利益の喪失; または業務 中断を含み, またそれだけに留まらない損害) に対して, たとえどのようにし て生じたとしても, そしてこのソフトウェアの使用によってどのようにであれ 生じる, 契約上であろうと, 厳密な責任内であろうと, あるいは不正行為 (過 失やそうでない場合を含む) における場合であろうとも, いかなる責任論上も, たとえそのような損害の可能性が予見されていたとしても, 一切の責任を持た ない. 翻訳: 神田敏広 御協力 (五十音順・敬称略): 池田研二, 内川 喜章, 藤村 英治, むらたしゅういちろう 杢野 雅一, 横田＠宇都宮 &porting; 金銭, ハードウェアまたはインターネットアクセス

FreeBSD プロジェクトの目的を進めるための寄付や, 私たちと同じような ボランティアの細く長い ! 努力を, 私たちは常に喜んで受け入れています. また一般的に私たちは自分達で周辺機器を買う資金が不足しているため, 周辺機器のサポートを充実させるのにハードウェアの寄付はとても重要です. 資金の寄付

FreeBSD プロジェクトは501(C3) (非営利) 企業ではないため, いかなる寄 付に対しても特別な税金の優遇措置を提供することができません. このような 寄付はプロジェクトを代表して FreeBSD, Inc により感謝をもって受け入れら れるでしょう.

FreeBSD, Inc.は FreeBSD プロジェクトの推進とプロジェクトに企業とし ての最小限の体裁を持たせることを目的として, 1995年の初めに &a.jkh と &a.davidg により設立されました. 寄付されたすべての資金は (最終的に FreeBSD, Inc.によりもたらされるであろうすべての利益も同様に) プロジェク トの目標を推進するためだけに使われるでしょう. 支払い先を FreeBSD, Inc. とした小切手を, 次の住所気付けで送ってください: FreeBSD, Inc. c/o Jordan Hubbard -4041 Pike Lane, suite #D. +4041 Pike Lane, suite #F. Concord CA, 94520 [私書箱が開設されるまで一時的に Walnut Creek CDROM の住所を使用] 電信振替は次の所まで直接送れるでしょう: Bank Of America Concord Main Office P.O. Box 37176 San Francisco CA, 94137-5176 Routing #: 121-000-358 Account #: 01411-07441 (FreeBSD, Inc.) 寄付に関することは全て電子メールもしくは上記 FreeBSD, Inc. の住所宛の郵政省メールにて までお送りくださるようお願いします. もし の節で匿名を希望される 方は, 寄付の際にその旨お伝えください. Thanks! ハードウェアの寄贈

FreeBSD プロジェクトは, 次の3つのカテゴリのどんなハードウェアの寄贈 も, 喜んで受け付けます: ディスクドライブ, メモリまたは完全なシステムといった一般用途のハー ドウェアは, 資金の寄付の節にある FreeBSD, Inc. の住所まで送っ てください. 進行中の受け入れテストのためのハードウェアが必要とされていま す. 新たなリリース毎に適切な逆行テストができるように, 私たちは現在, FreeBSD がサポートするすべてのコンポーネントのテストラボを設置しよう としています. 私たちにはまだ, たくさんの重要な部品 (ネットワークカード, マザーボードなど) が不足していますので, このような寄贈をしたいと思って いるならば, &a.davidg へコンタクトしてどの部品がまだ必要とされているか の情報を得てください. 現在 FreeBSD にサポートされていないハードウェアで, サポートに追 加して欲しいもの. 私たちが新しいハードウェアを受けとる前にそのタスクを 引き受けてくれる開発者を探す必要があるため, その部品を送る前に &a.core; にコンタクトを取ってください. インターネットアクセスの寄付

私たちは常に FTP, WWW や cvsup の新しいミラーサイトを募集しています. ミラーサイトになりたい場合には にコンタクトを取って, 詳し い情報を手に入れてください. 寄贈者ギャラリー

FreeBSD プロジェクトは次の寄贈者に恩義を受けており, ここに公表して 感謝の意を表したいと思います. セントラルサーバプロジェクトへの寄贈者:

次に挙げる個人および企業からは, セントラルサーバマシンのための 部品の寄贈を頂いており, それによって freefall.freebsd.org をリプレースして新たに FreeBSD プロジェクトのセントラルサーバマシンを 構築することができました: と彼の所属する は, Pentium Pro (P6) 200Mhz CPU を寄贈してくださいました. は, Tyan 1662 マザーボード を寄贈してくださいました. の は, Kingston イーサネットコントローラを寄贈してくださいました. は, NCR 53C875 SCSI コントローラカード を寄贈してくださいました. の は, 128MB のメモリ, そして 4 GB のディスクドライブと匡体 を寄贈してくださいました. 直接的な資金提供:

次に挙げる個人および企業からは FreeBSD プロジェクトに対する直接的な 資金提供を頂いております: Sean Eric Fagan の 日本の はいくつかの FreeBSD CD の販売利益の一部を寄付してくれました. は、はじめての FreeBSD の売り上げの一部を FreeBSD プロジェクト及び XFree86 プロジェクトへ寄付してくれました. は FreeBSD 関連の書籍の売り上げの一部を FreeBSD プロジェクト及び FreeBSD 友の会へ寄付してくれました. からは FreeBSD プロジェクトへ多大な寄付をいただきました. ハードウェアの寄贈者:

次に挙げる個人および企業からは, テストやデバイスドライバの開発 / サポート のためのハードウェアの寄贈を頂いております: Walnut Creek CDROM は, ネットワークへのアクセスおよび 他のハードウェアリソースの寄贈はいうまでもなく, 開発に使うための Pentium P5-90 と 486/DX2-66 EISA/VL のシステム数台を 提供してくださいました. TRW Financial Sysytems社は, PC 130台, 68 GB のファイルサーバ 3台, 12のイーサネット, ディスクレスコードのデバッグをおこなうための ルータ 2台及び ATM スイッチを提供してくださいました. また, 彼らは 2, 3人の FreeBSD ハッカーを雇って, FreeBSD に専念させて くださっております. ありがとうございます! Dermot McDonnell は, 東芝 XM3401B CD-ROM ドライブを 寄贈してくださいました. その CD-ROM ドライブは現在 freefall で使用されています. &a.chuck; は, 実験用のフロッピーテープストリーマを 寄付してくださいました. Larry Altneu と &a.wilko;は, wt ドライバを改良するために Wangtek と Archive の QIC-02 テープドライブを提供してくださいました. Ernst Winter は, このプロジェクトへ 2.88 MB のフロッピードライブを提供してくださいました. うまくいけば, これでフロッピーディスクドライバを書き直すための プレッシャーが増えるでしょう. ;-) は NCR ドライバや AMD ドライバと自社のカードの逆行テストのため FAST/ULTRA SCSI ホストアダプタ DC-390, DC-390U, DC-390F を 各１枚提供してくださいました. また, フリーな OS のためのドライバの ソースを自社の FTP サーバ で公開されていることも 称賛に値するでしょう. は Symbios Sym8751S SCSI カードを寄贈してくださっただけでなく, Ultra-2 や LVD をサポートする次期チップ Sym53c895 のものを含む データブックのセットと, 最新の Symbios SCSI チップが持つ先進的機能を 安全に使う方法について書かれた最新のプログラミングマニュアルも 寄贈してくださいました. 本当にありがとうございます ! は, IDE CD-ROM ドライバ開発用の FX120 12 倍速 Mitsumi CD-ROM ドライブ を提供してくださいました. 特筆すべき寄贈者:

は, 言い表せないほど多くの寄付をしてくださいました (詳細は を参照). 特に, 私たちのもともとのプライマリ開発マシンである freefall.FreeBSD.ORG, テストおよびビルドマシンである thud.FreeBSD.ORG で使用しているハードウェアに対し 感謝したいと思います. また彼らには, 数年にわたる色々な貢献者への資金提供や, インターネット への T1 コネクションの無制限使用を提供して頂いた恩義があります. は, &a.joerg; を根気よく サポートしてくださいました. 彼は本職より FreeBSD の仕事を好みがちであり, 彼個人の接続があまりに 遅くなったり途切れたりして仕事にならない時は必ず interface business の (非常に高価な) EUnet インターネット接続に頼ったものです... は, 同社の DOS エミュレータのコードを BSD コミュ ニティ全体に対して提供してくれました. このコードは, dosemu コマンドに利用されています. BSD派生ソフトウェアへのコントリビュータ

このソフトウェアは最初は William F. Jolitz の 386BSD release 0.1 から派生しましたが, オリジナルの 386BSD に固有のコードはほとんど 残っていません. このソフトウェアは基本的にはカリフォルニア大学 バークレイ校の Computer Science Research Group (CSRG) とその共同研究者 たちによる 4.4BSD-Lite リリースから再実装されました. - また, NetBSD の一部も FreeBSD に取り込まれています. したがって私たちは - NetBSD へ貢献した人々すべてに感謝します. + また, NetBSD や OpenBSD の一部も FreeBSD に取り込まれています. + したがって私たちは NetBSD と OpenBSD へ貢献した人々すべてに感謝します. その他の FreeBSD へのコントリビュータ

(名前でアルファベット順に): A JOSEPH KOSHY ABURAYA Ryushirou Ada T Lim Adam Glass + Adam McDougall Adrian T. Filipi-Martin Akito Fujita Alain Kalker Alan Cox Andreas Kohout Andreas Lohr Andrew Gordon Andrew Herbert Andrew McRae Andrew Moore Andrew Stevenson Andrew V. Stesin Andrey Zakhvatov Andy Whitcroft Angelo Turetta Anthony Yee-Hang Chan Ari Suutari Brent J. Nordquist Bernd Rosauer Bill Kish &a.wlloyd Bob Wilcox Boyd Faulkner Brent J. Nordquist Brett Taylor Brian Clapper Brian Handy Brian Tao Brion Moss Bruce Gingery Carey Jones Carl Fongheiser Charles Hannum Charles Mott Chet Ramey Chris Dabrowski Chris G. Demetriou Chris Shenton Chris Stenton Chris Timmons Chris Torek Christian Gusenbauer Christian Haury Christoph Robitschko Choi Jun Ho Chuck Hein Conrad Sabatier Cornelis van der Laan Craig Struble Cristian Ferretti Curt Mayer Dai Ishijima Dan Cross Daniel Baker Daniel M. Eischen Daniel O'Connor Danny J. Zerkel Dave Bodenstab Dave Burgess Dave Chapeskie Dave Edmondson Dave Rivers David A. Bader David Dawes David Holloway David Leonard Dean Huxley Dirk Froemberg Dmitrij Tejblum Dmitry Kohmanyuk &a.whiteside; Don Yuniskis Donald Burr Doug Ambrisko Douglas Carmichael Eiji-usagi-MATSUmoto ELISA Font Project Eric A. Griff Eric Blood Eric J. Chet Eric J. Schwertfeger Francis M J Hsieh Frank Bartels Frank Chen Hsiung Chan Frank Maclachlan Frank Nobis FUJIMOTO Kensaku FURUSAWA Kazuhisa Gary A. Browning Gary Kline Gerard Roudier Greg Ungerer Harlan Stenn Havard Eidnes Hideaki Ohmon Hidekazu Kuroki Hidetoshi Shimokawa Hideyuki Suzuki Hironori Ikura Holger Veit Hung-Chi Chu Ian Vaudrey Igor Vinokurov Ikuo Nakagawa IMAMURA Tomoaki Ishii Masahiro Issei Suzuki Itsuro Saito J. David Lowe J.T. Conklin James Clark James da Silva et al Janusz Kokot Jason Thorpe Javier Martin Rueda Jeff Bartig Jeffrey Wheat Jian-Da Li Jim Binkley Jim Lowe Jim Wilson Joao Carlos Mendes Luis Joel Sutton Johann Tonsing John Capo John Heidemann John Perry John Polstra John Rochester + Jonathan Hanna Josef Karthauser Joseph Stein Josh Gilliam Josh Tiefenbach Juergen Lock Juha Inkari Julian Assange Julian Jenkins Julian Stacey Junichi Satoh Kapil Chowksey Kazuhiko Kiriyama Keith Bostic Keith Moore Kenneth Monville Kent Vander Velden Kirk McKusick Kiroh HARADA Koichi Sato Kostya Lukin Kurt Olsen - Lars Koeller Lars Köller Lucas James Luigi Rizzo Makoto MATSUSHITA Manu Iyengar Marc Frajola Marc Ramirez Marc Slemko Marc van Kempen Mario Sergio Fujikawa Ferreira Mark Huizer Mark J. Taylor Mark Krentel Mark Tinguely Martin Birgmeier Martti Kuparinen Masachika ISHIZUKA Mats Lofkvist Matt Bartley Matt Thomas Matt White Matthew Hunt Matthew N. Dodd Matthew Stein Maurice Castro Michael Butschky Michael Elbel Michael Searle Miguel Angel Sagreras Mikael Hybsch Mikhail Teterin Mike McGaughey Mike Peck Ming-I Hseh MITA Yoshio MOROHOSHI Akihiko Murray Stokely NAKAMURA Kazushi Naoki Hamada Narvi NIIMI Satoshi Nick Sayer Nicolas Souchu Nisha Talagala Nobuhiro Yasutomi Nobuyuki Koganemaru Noritaka Ishizumi Oliver Fromme Oliver Laumann Oliver Oberdorf Paul Fox Paul Kranenburg Paul Mackerras Paulo Menezes Paul T. Root Pedro Giffuni Pedro A M Vazquez Peter Cornelius Peter Haight Peter Hawkins Peter Stubbs Pierre Beyssac Phil Maker R. Kym Horsell Randall Hopper Richard Hwang Richard Seaman, Jr. Richard Stallman Richard Wiwatowski Rob Mallory Rob Shady Rob Snow Robert Sanders Robert Withrow Ronald Kuehn Roland Jesse Ruslan Shevchenko Samuel Lam Sander Vesik Sandro Sigala Sascha Blank Sascha Wildner Satoshi Taoka Scott Blachowicz Scott A. Kenney Serge V. Vakulenko Sheldon Hearn Simon Marlow Slaven Rezic (Tomic) Soren Dayton Soren Dossing Stefan Moeding Stephane Legrand Stephen J. Roznowski Steve Gerakines Suzuki Yoshiaki Tadashi Kumano Taguchi Takeshi Takayuki Ariga Terry Lambert Terry Lee Tetsuya Furukawa Theo Deraadt Thomas König Þórður Ívarsson Tim Kientzle Tim Wilkinson Tom Samplonius Torbjorn Granlund Toshihiro Kanda Trefor S. Ville Eerola Werner Griessl Wes Santee Wilko Bulte Wolfgang Stanglmeier Wu Ching-hong Yen-Shuo Su Yoshiaki Uchikawa Yoshiro Mihira - Yukihiro Nakai + Yukihiro Nakai Yuval Yarom Yves Fonk 386BSD パッチキットへのパッチ提供者

(名前でアルファベット順): Adam Glass Adrian Hall Andrey A. Chernov Andrew Herbert Andrew Moore Andy Valencia Arne Henrik Juul Bakul Shah Barry Lustig Bob Wilcox Branko Lankester Brett Lymn Charles Hannum Chris G. Demetriou Chris Torek Christoph Robitschko Daniel Poirot Dave Burgess Dave Rivers David Dawes David Greenman Eric J. Haug Felix Gaehtgens Frank Maclachlan Gary A. Browning Gary Howland Geoff Rehmet Goran Hammarback Guido van Rooij Guy Harris Havard Eidnes Herb Peyerl Holger Veit Ishii Masahiro, R. Kym Horsell J.T. Conklin Jagane D Sundar James Clark James Jegers James W. Dolter James da Silva et al Jay Fenlason Jim Wilson Jörg Lohse Jörg Wunsch John Dyson - John Woods Jordan K. Hubbard Julian Elischer Julian Stacey Karl Lehenbauer Keith Bostic Ken Hughes Kent Talarico Kevin Lahey Marc Frajola Mark Tinguely Martin Renters Michael Clay Michael Galassi Mike Durkin Naoki Hamada Nate Williams Nick Handel Pace Willisson Paul Kranenburg Paul Mackerras Paul Popelka Peter da Silva Phil Sutherland Poul-Henning Kamp Ralf Friedl Rick Macklem Robert D. Thrush Rodney W. Grimes Sascha Wildner Scott Burris Scott Reynolds Sean Eric Fagan Simon J Gerraty Stephen McKay Terry Lambert Terry Lee Tor Egge Warren Toomey Wiljo Heinen William Jolitz Wolfgang Solfrank Wolfgang Stanglmeier Yuval Yarom diff --git a/ja/handbook/userppp.sgml b/ja/handbook/userppp.sgml index 4088aef68e..4e8cac7710 100644 --- a/ja/handbook/userppp.sgml +++ b/ja/handbook/userppp.sgml @@ -1,974 +1,974 @@ - + - + ユーザ ppp の設定

ユーザ ppp は FreeBSD 2.0.5-RELEASE において, 既存のカーネル実装版の PPP に加えて導入されました. それでは, これまでの pppd との違い, すなわち この新しい PPP が追加された理由とは いったい何なのでしょうか? マニュアルから引用してみます: これはユーザプロセス PPP ソフトウェアパッケージです. 通常, PPP は (例えば pppd でそうなっているように) カーネルの一部として 実装されていますので, デバッグや動作の変更が少々困難です. しかし, この実装では, PPP はトンネルデバイスドライバ (tun) の 助けにより, ユーザプロセスとして実装されています. 本質として, これは常に PPP デーモンを実行しておかなくても, 必要な時に ppp プログラムを実行できるということを意味します. このプログラムはカーネルとのデータ送受のために一般のトンネルデバイスを 使うことができるため, PPP インターフェースをカーネルに組み込んでおく 必要がありません. 以降では, ユーザ ppp と pppd のような他の PPP クライアント/サーバ ソフトウェアとを区別する必要が無い場合には, ユーザ ppp を単に ppp とだけ 呼びます. 特に断らない限り, このセクションのすべてのコマンドは root 権限で 実行する必要があります. 訳者注: 以前の日本語ハンドブックでは, iij-ppp のオリジナルアーカイブに 附属する日本語ドキュメントの参照をおすすめしていました. しかし最近では FreeBSD 独自の拡張がいろいろと追加され, もともとの iij-ppp のドキュメントではカバーしきれなくなって来ています. ですが心配はいりません. 日本語マニュアルプロジェクトから FreeBSD の日本語版マニュアルページが配布されるようになりました. こちらもハンドブックとあわせて参照されることをおすすめします. スタートの前に

このドキュメントでは, あなたが およそ以下のような状況にあると仮定しています: PPP 接続の使えるインターネットサービスプロバイダ (ISP) のアカウントを 持っている. さらに, 接続済みのモデム (またはその他のデバイス) があり, プロバイダとの接続が可能なように正しく設定されている. 以下の情報を手に入れておく必要があるでしょう:

プロバイダの電話番号.

ログイン名とパスワード. これは通常の unix 形式のログイン名と パスワードの組かもしれませんし, PPP PAP または CHAP の ログイン名とパスワードの組かもしれません.

プロバイダのゲートウェイの IP アドレス. ゲートウェイとは, あなたがそこに接続をおこなって, デフォルトルートとして設定することになるマシンです. もしプロバイダがこのアドレスを明示していなくても大丈夫. 適当に設定しておいて, 接続時にプロバイダの PPP サーバから 教えてもらうことができます.

このアドレスは, 以降HISADDRと呼ぶことにします.

プロバイダのネットマスク設定. 繰り返しますが, 不明な場合には ネットマスクとして 255.255.255.0 を使用しておけば問題ありません.

一つ以上のネームサーバの IP アドレス. 通常, IP アドレスが二つ プロバイダから指示されているはずです. 自分でネームサーバを 動かしているのでなければ, この情報は絶対に必要です.

もしプロバイダから固定の IP アドレスとホスト名の割り当てを 受けているのなら, 同様にそれも必要になるでしょう. そうでなければ, どのアドレス範囲から IP アドレスの割り当てが おこなわれるかを知っておく必要があるでしょう. もし範囲が示されていないとしても, 任意の IP アドレスを 受け入れるようにすることが可能です (後で説明します). もし, これらの情報のうち不明なものがあれば, プロバイダに連絡して 確認しておいてください. ppp 対応カーネルの構築

説明でも述べているように, ``ppp'' はカーネルの ``tun'' デバイスを使います. そのため, このデバイスがカーネルに組み込まれているかどうかを 確認しておかなくてはいけません. これを確認するには, カーネルコンパイルディレクトリ (/sys/i386/conf または /sys/pc98/conf) に移動して, カーネルコンフィグレーションファイルを調べます. 以下の行がどこかに含まれている必要があります. pseudo-device tun 1 元々の GENERIC カーネルは標準でこれを含んでいますので, カスタムカーネルをインストールしているのではなかったり, /sys ディレクトリが存在しないのであれば, 何も変更する必要はありません.

この行がカーネルコンフィグレーションファイルに含まれていなかったり, tun デバイスが一つでは足りない場合 (例えば, 同時に 16 本の ダイアルアップ PPP 接続を処理できるサーバを立ち上げるとしたら, ``1'' のかわりに ``16'' を指定する必要があるでしょう), この行を追加して カーネルの再コンパイルとインストールをおこなう必要があります. それからこの新しいカーネルを使ってブートしてください. カーネルコンフィグレーションの詳細については, を参照してください.

以下のコマンドを実行することで, 現在のカーネルにトンネルデバイスが いくつ組み込まれているかを調べることができます: # ifconfig -a tun0: flags=8051 mtu 1500 inet 200.10.100.1 --> 203.10.100.24 netmask 0xffffffff tun1: flags=8050 mtu 576 tun2: flags=8051 mtu 1500 inet 203.10.100.1 --> 203.10.100.20 netmask 0xffffffff tun3: flags=8050 mtu 1500 この例ではトンネルデバイスが四つあって, うち二つに設定がおこなわれていて 現在使用中であることがわかります.

トンネルデバイスがカーネルに組み込まれておらず, 何らかの理由で カーネルの再構築ができない場合でも, 方法がないわけではありません. 動的にデバイスをロードすることができるはずです. 詳細については modload(8) や lkm(4) など, 適切なマニュアルを参照してください.

この機会にファイアウォールも設定しておきたいと思っているのであれば, 詳細についてはセクションを 参照してください. tun デバイスの確認

ほとんどのユーザは ``tun'' デバイス (tun0) が一つあれば充分でしょう. より多くのデバイスを使う場合 (すなわち, カーネルコンフィグレーション ファイルで tun 疑似デバイスの行に `1' 以外の数値を指定している場合), 以下で ``tun0'' と書かれている部分をすべて, あなたが使うデバイスの番号に あわせて読みかえてください. tun0 デバイスが正しく作成されていることを確認する最も簡単な方法は, それを作り直すことです. そのためには, 以下のコマンドを実行します: # cd /dev # ./MAKEDEV tun0

カーネルに 16 個のトンネルデバイスを組み込んだのであれば, tun0 だけでなく他の tun デバイスも作成しておく必要があるでしょう: # cd /dev # ./MAKEDEV tun15

また, カーネルが正しく設定されているかどうかを調べるために 以下のコマンドを実行して, このような出力が得られることを確認します: $ ifconfig tun0 tun0: flags=8050 mtu 1500 $ 名前の解決に関する設定

リゾルバ (resolver) はシステムの一部分で, IP アドレスとホスト名との 変換をおこないます. IP アドレスとホスト名を対応させるためのマップを, 二つの場所のうちの一つから探すように設定できます. 一つめは/etc/hosts (man 5 hosts) と呼ばれるファイルです. 二つめはインターネット ドメインネームサービス (DNS) と呼ばれる 分散データベースですが, これに関する議論は このドキュメントで扱う範囲を 越えていますので, これについての説明はおこないません.

このセクションではリゾルバの設定方法について簡単に説明します.

リゾルバは名前のマッピングをおこなうシステムコールの集合体です. ただし どこからマッピング情報を見つけるのかは, 最初に指示しておく必要があります. これは まず/etc/host.confファイルを編集することでおこないます. 混乱の元になりますので, このファイルを/etc/hosts.confと 呼んだりしてはいけません (余分な ``s'' がついていますね). /etc/host.conf ファイルの編集

このファイルには 以下の 2 行が書かれているはずです: hosts bind これは, 最初に/etc/hostsファイルを調べ, そこで目的の名前が 見つけられなかった場合に DNS を引きにいくようリゾルバに指示します. /etc/hosts(5) ファイルの編集

このファイルはローカルネットワーク上に存在するマシンの IP アドレスと ホスト名を含んでいるはずです. 最低でも ppp を動作させるマシンのエントリが 含まれている必要があります. そのマシンのホスト名が foo.bar.com で, IP アドレスが 10.0.0.1 であると仮定すると, /etc/hostsは 以下の行を含んでいなければいけません: 127.0.0.1 localhost 10.0.0.1 foo.bar.com foo 一つめの行は ``localhost'' を現在のマシンの別名として定義しています. マシン固有の IP アドレスが何であっても, この行の IP アドレスは 常に 127.0.0.1 でなければいけません. 二つめの行はホスト名 ``foo.bar.com'' (と, その省略形 ``foo'') を IP アドレス 10.0.0.1 にマップします. もしプロバイダから固定の IP アドレスとホスト名を割り当てられて いるのであれば, それを 10.0.0.1 エントリのかわりに使ってください. /etc/resolv.conf ファイルの編集

/etc/resolv.confはリゾルバの振舞いを指定します. もし自前の DNS サーバを走らせているのなら, このファイルは空のままに しておくこともできます. 通常は, 以下のように書いておく必要があるでしょう: nameserver x.x.x.x nameserver y.y.y.y domain bar.com x.x.x.x と y.y.y.y はプロバイダが指示するアドレスで, 接続するプロバイダが提供している「ネームサーバ」を すべて書いてください. ``domain'' に指定するのは このマシンのデフォルトのドメイン名で, おそらく 書かなくても問題は無いでしょう. このファイルの各エントリの詳細については, resolv.conf のマニュアルページを参照してください. ppp の設定

ユーザ ppp と pppd (カーネルレベルの PPP 実装) は どちらも/etc/pppディレクトリに置かれた設定ファイルを使います. ここには設定ファイルのサンプルが用意されていて, ユーザ ppp の設定を おこなう際に大変参考になりますので, 削除したりしないでください.

ppp の設定をするためには, 必要に応じていくつかのファイルを編集する必要が あります. 書き込む内容は, プロバイダが静的に IP アドレスを割り当てる (つまり, 固定の IP アドレスを一つ与えられて, 常にそれを使う) か, または動的に IP アドレスを割り当てる (つまり, PPP セッションごとに IP アドレスが変化する可能性がある) かということに ある程度依存します. 静的 IP アドレスによる PPP 接続

まず/etc/ppp/ppp.confという設定ファイルを作成する必要があります. これは以下の例とほとんど同じようなものになるでしょう. ``:'' で終る行は 1 カラム目から始め, その他の行はスペースまたはタブで以下の例のように 段をつける (インデントする) 必要があることに注意してください. 1 default: 2 set device /dev/cuaa0 3 set speed 115200 4 set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" ATE1Q0 OK-AT-OK \\dATDT\\T TIMEOUT 40 CONNECT" 5 provider: 6 set phone "(0123) 456 7890" 7 set login "TIMEOUT 10 gin:-BREAK-gin: foo word: bar col: ppp" 8 set timeout 300 9 deny lqr 10 set ifaddr x.x.x.x y.y.y.y 11 delete ALL 12 add 0 0 HISADDR ファイルでは行番号を取り除いておいてください. これは解説の際に参照する行を示すためにつけたものです. /dev/cuaa0に, COM2: は/dev/cuaa1になります. chat(8)言語に似た, 受信待ち文字列と 送信文字列の対からなるスクリプトを使用します. この言語の機能に関しては, マニュアルページを参照してください. J. Random Provider login: foo password: bar protocol: ppp このスクリプトは必要に応じて書きかえる必要があるでしょう. PAP や CHAP を使うのなら, ここでログインは おこないませんので ログイン文字列は空白のままにしておきます. 詳細については を参照してください. 10.0.0.2/0 を使用しておいてください. もし「仮の」アドレスを使用する必要がある場合には, に関する指示に従って, /etc/ppp/ppp.linkup にエントリを作成していることを 確認してください. この行が省略されていると, ppp を -auto モードや -dynamic モードで動作させることはできません. HISADDR は, 9 行目で指定された ゲートウェイのアドレスで置きかえられます. HISADDR は 9 行目までは初期化されていませんので, その行よりも後でしか使えないことに注意してください.

静的な IP アドレスを持っていて, 接続が完了する前にルーティングテーブルの エントリが正しく設定されているのであれば, ppp.linkup に エントリを追加する必要はありません. しかし, この場合でもエントリを追加して, 接続が完了した時点で プログラムを呼び出したいことがあるかもしれません. これについては後ほど sendmail を例として説明します.

これらの設定ファイルのサンプルが/etc/pppディレクトリに 置かれています. 動的 IP アドレスによる PPP 接続

プロバイダが静的な IP アドレスの割り当てをおこなっていない場合, pppが相手側のホスト (ゲートウェイ) と交渉して, こちら側と相手側のアドレスを決めるように設定することができます. これは, 起動時には「仮の」アドレスを使っておいて, 接続後に IP コンフィグレーション プロトコル (IPCP) を使用して ppp が IP アドレスを正しく設定できるようにすることで実現されます. に 以下の変更を加える以外は, ppp.conf の設定は同じです: 10 set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 繰り返しますが, 行番号は取り除いておいてください. これは解説の際に参照する行を示すためにつけたものです. なお, 少なくともスペース 1 個分の段づけ (インデント) が必要です. 0.0.0.0 を追加すると うまく動くように なることがあります: set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 このようにすると, ppp は 10.0.0.1 のかわりに 0.0.0.0 を使用して交渉を開始します. ここで set ifaddr コマンドの最初の引数として 0.0.0.0/0 を指定してはいけません. さもないと, -auto モードや -ddial モードで 動作させる際に 初期経路を設定することができなくなります.

/etc/ppp/ppp.linkup にもエントリを作成しておく必要があります. ppp.linkup は接続が確立された後に使用されます. この時点では, ppp は実際にどの IP アドレスを使うべきなのか わかっているはずです. 以下のエントリは存在する仮の経路を削除し, 正しい経路を作成します: 1 provider: 2 delete ALL 3 add 0 0 HISADDR ppp.linkup のエントリを検索します: まず ppp.conf で使用されたのと同じラベルを探します. もし見つからなければ, ゲートウェイの IP アドレスのエントリを 探します. このエントリは 4 オクテットの IP アドレス形式の ラベルです. それでも まだエントリが見つからなければ, MYADDR エントリを探します. HISADDR への経路をデフォルトルートとして 追加するように ppp に指示します. HISADDR は IPCP で 決定されたゲートウェイの IP アドレスで置きかえられます.

詳細なサンプルについては, /etc/ppp/ppp.conf.sample ファイル中の pmdemand エントリと /etc/ppp/ppp.linkup.sample を参照してください. かかってきた電話を ppp で受けるには

このセクションでは ppp をサーバとして設定する方法について説明します.

かかってきた電話をpppが受けるように設定する場合, PPP接続についてだけパケットを転送するようにするのか, すべてのインターフェースについて転送するようにするのか, それとも一切転送をおこなわないのかを決定しなければいけません. PPP 接続についてだけ転送をおこなうためには, ppp.confファイルに 以下の行を追加しておきます. enable proxy すべてのインターフェースについてパケットの転送をおこなう場合には, /etc/rc.confで以下のオプションを指定してください. (このファイルは 以前のバージョンの FreeBSD では/etc/sysconfigと呼ばれていました) gateway=YES どの getty を使いますか?

getty でダイアルアップサービスをおこなう場合の優れた解説が にあります.

getty に代わるものとしては, があります. これは getty をより柔軟にしたもので, ダイアルアップ回線での使用を意図して設計されています.

mgetty を使う場合の利点は, mgetty が積極的にモデムと通信する ということです. つまり, もし/etc/ttysでポートを閉じている場合, モデムは電話をとらなくなります.

最近のバージョンの mgetty (0.99beta 以降) では, PPP ストリームの 自動検出もサポートされています. これにより, クライアント側で スクリプトを準備しなくてもサーバにアクセスすることができます.

mgetty に関する, より詳細な情報については を参照してください. ppp の実行許可

ppp は通常, ID 0 のユーザ (root) として動作しなければいけませんが, 以下で説明するように, ppp を通常のユーザとしてサーバモードで実行させたい 場合には, そのユーザを /etc/group の network グループに 追加して, ppp を実行する許可を与えておかなければいけません. 動的 IP ユーザのための ppp シェルの設定

/etc/ppp/ppp-shellという名前で, 以下のような内容のファイルを 作成します: #!/bin/sh IDENT=`echo $0 | sed -e 's/^.*-\(.*\)$/\1/'` CALLEDAS="$IDENT" TTY=`tty` if [ x$IDENT = xdialup ]; then IDENT=`basename $TTY` fi echo "PPP for $CALLEDAS on $TTY" echo "Starting PPP for $IDENT" exec /usr/sbin/ppp -direct $IDENT

このスクリプトには実行可能属性をつけておきます. 次に, 以下のコマンドを実行し, ppp-dialupという名前で このスクリプトへのリンクを作成します: # ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-dialup

すべてのダイアルアップ ppp ユーザのログインシェルとして このスクリプトを使用します. 以下は pchilds というユーザ名の ダイアルアップユーザを/etc/passwordへ登録した場合の例です. (パスワードファイルを直接エディタで編集したりせず, vipwを使ってください) pchilds:*:1011:300:Peter Childs PPP:/home/ppp:/etc/ppp/ppp-dialup

任意のユーザが読むことのできる, /home/pppディレクトリを 作成します. /etc/motdが表示されないようにするため, このディレクトリには以下のように大きさが 0 バイトのファイルを 作成しておきます. -r--r--r-- 1 root wheel 0 May 27 02:23 .hushlogin -r--r--r-- 1 root wheel 0 May 27 02:22 .rhosts 静的 IP ユーザのための PPP シェルの設定

上記と同じようにppp-shellファイルを作成し, 静的な IP アドレスを割り当てるアカウントそれぞれについて ppp-shellへのシンボリックリンクを作成します.

例えば, クラス C ネットワークの経路制御を必要とする, 三人のダイアルアップユーザ fred, sam, mary がいるとすると, 以下のコマンドを実行することになります: # ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-fred # ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-sam # ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-mary

これらのユーザのダイアルアップアカウントでは, 上で作成した それぞれのシンボリックリンクをログインシェルとして設定しておきます. (つまり, ユーザ mary のログインシェルは/etc/ppp/ppp-maryに なります). 動的 IP ユーザのための ppp.conf の設定

/etc/ppp/ppp.confファイルは, 大体以下のような内容になるでしょう: default: set debug phase lcp chat set timeout 0 ttyd0: set ifaddr 203.14.100.1 203.14.100.20 255.255.255.255 enable proxy ttyd1: set ifaddr 203.14.100.1 203.14.100.21 255.255.255.255 enable proxy

上の例のように段をつける (インデントする) 必要があることに注意してください.

default: エントリはセッションごとにロードされます. /etc/ttysで有効にしてある各ダイアルアップ回線ごとに一つ, 上記のttyd0:のようなエントリを作成します. 各行の相手側アドレスとして, それぞれ別の IP アドレスを 動的 IP ユーザのための IP アドレスのプールから割り当てておく必要があります. 静的 IP ユーザのための ppp.conf の設定

上のサンプルの/etc/ppp/ppp.confの内容に加えて, 静的に IP を割り当てられたダイアルアップユーザ それぞれのためのエントリを追加する必要があります. ここでも fred, sam, mary の例を使うことにしましょう. fred: set ifaddr 203.14.100.1 203.14.101.1 255.255.255.255 sam: set ifaddr 203.14.100.1 203.14.102.1 255.255.255.255 mary: set ifaddr 203.14.100.1 203.14.103.1 255.255.255.255

必要であれば, それぞれの静的 IP ユーザに対する経路制御情報も /etc/ppp/ppp.linkupファイルに書いておくべきでしょう. 以下の例ではクライアントの PPP リンクを経由する, クラス C の203.14.101.0ネットワークへの経路を追加しています. fred: add 203.14.101.0 netmask 255.255.255.0 HISADDR sam: add 203.14.102.0 netmask 255.255.255.0 HISADDR mary: add 203.14.103.0 netmask 255.255.255.0 HISADDR mgetty, AutoPPP, マイクロソフト拡張の詳細 Mgetty と AutoPPP

AUTO_PPP オプションつきでコンパイルした mgetty を使えば, mgetty が PPP 接続の LCP フェーズを検出して, 自動的に PPP シェルを起動するように 設定することができます. しかし この場合, デフォルトの login/password シーケンスは発生しないので, ユーザの認証は PAP または CHAP を使っておこなう必要があります.

このセクションでは, ユーザ (あなた) が問題なく AUTO_PPP オプションつきの mgetty (v0.99beta またはそれ以降) の設定, コンパイル, インストールができているものと仮定しています.

/usr/local/etc/mgetty+sendfax/login.configファイルが 以下の行を含んでいることを確認してください: /AutoPPP/ - - /etc/ppp/ppp-pap-dialup

これにより, PPP 接続を検出したら mgetty がppp-pap-dialup スクリプトを実行するようになります.

/etc/ppp/ppp-pap-dialupという名前で, 以下のような内容のファイルを 作成します (このファイルには実行可能属性をつけておく必要があります): #!/bin/sh TTY=`tty` IDENT=`basename $TTY` exec /usr/sbin/ppp -direct pap$IDENT

/etc/ttysで有効になっている各ダイアルアップ回線ごとに, 対応するエントリを一つ/etc/ppp/ppp.confに作成します. これは上で作成した定義と問題なく共存できるでしょう. papttyd0: enable pap set ifaddr 203.14.100.1 203.14.100.20 255.255.255.255 enable proxy papttyd1: enable pap set ifaddr 203.14.100.1 203.14.100.21 255.255.255.255 enable proxy

この方法でログインする それぞれのユーザは, PAP によるユーザ認証を おこなうために/etc/ppp/ppp.secretファイルにユーザ名とパスワードを 書いておくか, または/etc/passwordファイルを使うように, enable passwdauth オプションを (/etc/ppp/ppp.conf に) 追加しておく必要があるでしょう. (*)

(*) このオプションは 2.2-961014-SNAP および それ以降のシステムか, または 2.1.x のシステムにおいて ppp のコードを更新している場合にだけ 使用可能だということに注意してください. (詳細に関しては, 以下のマイクロソフト拡張を参照してください) マイクロソフト拡張

2.2-961014-SNAP 以降では, DNS と NetBIOS ネームサーバの自動交渉 (negotiation) をサポートしている クライアント (例えば Win95/NT クライアント) との間で この機能を使うことができます. プロトコルの詳細については RFC1877 を参照してください.

これらの拡張機能を/etc/ppp/ppp.confファイルで有効にした例を 以下に示します. default: set debug phase lcp chat set timeout 0 enable msext set ns 203.14.100.1 203.14.100.2 set nbns 203.14.100.5

これにより, クライアントはプライマリとセカンダリのネームサーバアドレス および NetBIOS ネームサーバホストを知ることができます. PAP および CHAP による認証

いくつかのプロバイダでは、PAP または CHAP のいずれかの認証メカニズムを 使用して接続時の認証をおこなうようにシステムを設定しています. この場合, プロバイダは接続の際に login: プロンプトを送信せず, 最初から PPP で通信を始めようとするでしょう. PAP ではパスワードがそのまま送られてしまうため, CHAP に比べると安全性が 低くなりますが, このパスワードはシリアル回線のみを通して送られます. そのため, クラッカーが「盗み聞き」する余地は多くないので, 通常ここの セキュリティは問題にはなりません. または の セクションに戻って, 以下の変更をおこないます: 7 set login ..... 13 set authname MyUserName 14 set authkey MyPassword これまでと同様に, 行番号は取り除いておいてください. これは解説の際に参照する行を示すためにつけたものです. なお, 少なくともスペース 1 個分の段づけ (インデント) が必要です. MyUserName に 正しい値を入れておく必要があります. MyPassword に 正しい値を入れておく必要があります. PAP と CHAP はデフォルトで受け付けられるようになっていますが, PAP や CHAP を使用するという意思を明示するために, 15 accept PAP または 15 accept CHAP という行を追加しておくのも良いでしょう.

注:(set log +commandで) コマンド記録をオンにしていると, authkey も記録されてしまいます. ppp のログファイルの許可モードを 決定する際には, このことに注意しておいてください. 動作中の ppp の設定変更

適切なパスワードさえ設定されていれば, バックグラウンドで動作している ppp プログラムと通信することができます.

通常の設定では, ppp は 3000 + tunno 番の TCP ポートをモニタして コマンドを待ちうけます. ここで tunno は, その ppp が使用する tun デバイスの番号です. ただし, ローカルマシン用のパスワードが /etc/ppp/ppp.secret で 設定されていなければ, その ppp サーバに接続することはできません. パスワードを設定するためには, 以下の行を内容とするファイルを /etc/ppp/ppp.secret として作成しておきます: foo MyPassword ここで foo はローカルのホスト名 (正しい名前を知るためには hostname -s を実行してください) で, MyPassword は 暗号化されていないパスワードそのものです. /etc/ppp/ppp.secret は ID 0 のユーザ (root) 以外の誰からも アクセス可能であってはいけません. つまり, /, /etc および /etc/ppp は 書き込み可能であってはならず, また ppp.secret は ID 0 のユーザ (root) に所有され, 許可モード 0600 であるべきです.

また, ppp が使用するポート番号を変更することや, TCP ソケットではなく ローカル UNIX ドメインのソケットをモニタするように指定することも可能です. 詳細に関しては, マニュアルページの set socket コマンドを 参照してください.

一旦ソケットの設定が終了したら, スクリプト中で pppctl(8) を 使用して, 動作中の ppp を操作することができるでしょう. システムの最終設定

これで ppp の設定は終りました. しかし ppp を動かす前に, まだ少し必要なことがあります. それらの設定は, すべて/etc/rc.confファイルを 編集することでおこないます. (このファイルは以前には/etc/sysconfigと呼ばれていました) このファイルを上から順に設定していきます. まずは ``hostname='' の行が設定されていることを確認します. 例えば以下のように: hostname=foo.bar.com

もしプロバイダが静的な IP アドレスとホスト名を割り当てているのなら, ホスト名としてそれを使うのが おそらくベストでしょう.

次に network_interfaces 変数を調べます. 必要に応じて (on demand) プロバイダにダイアルするようにシステムを設定したい場合には, tun0 デバイスがこのリストに追加されていることを確認しておきます. それ以外の場合には, tun0 デバイスをリストから削除しておきます. network_interfaces="lo0 tun0" ifconfig_tun0= ifconfig_tun0変数が空で, /etc/start_if.tun0 という名前の ファイルが作成されていなければならない ということに注意してください. このファイルの内容は以下のようになります. ppp -auto mysystem このスクリプトはネットワークの設定時に実行され, ppp デーモンを自動モードで立ち上げます. このマシンがもし LAN のゲートウェイであれば, -alias スイッチも使用したいと思うかもしれません. 詳細に関しては, マニュアルページを参照してください.

以下のようにルータプログラムを ``NO'' に設定します. router_enable=NO (/etc/rc.conf) router=NO (/etc/sysconfig) routedは, ppp が作成したデフォルトのルーティングテーブル エントリを削除してしまう場合がありますので, (初期設定では起動されるようになっている) routedデーモンが 起動されないようにしておくことが重要です.

``sendmail_flags'' 行が ``-q'' オプションを含まないように 設定しておいた方がよいでしょう. さもないと, sendmail が アドレスを調べようとして発信をおこなってしまう場合があります. 以下のような設定で良いでしょう: sendmail_flags="-bd" この結果, PPP リンクを立ち上げた時には いつでも以下のコマンドを実行して, キューにたまっているメールを sendmail に送信させる作業が必要になるでしょう. # /usr/sbin/sendmail -q

ppp.linkup 中で !bg コマンドを使用することで, これを自動的に おこなうこともできます: 1 provider: 2 delete ALL 3 add 0 0 HISADDR 4 !bg sendmail -bd -q30m

こうするのが嫌であれば, SMTP トラフィックをブロックするように "dfilter" を設定しておくこともできます. 詳細についてはサンプルファイルを参照してください.

後はマシンをリブートするだけです.

リブートが終ったら, # ppp コマンドを実行し, 続いて PPP セッションを開始させるために ``dial provider'' と入力することもできますし, (start_if.tun0 スクリプトを作成していない場合に), 外部へのトラフィックが発生した時に, ppp が自動的に セッションを確立してくれるようにしたいのであれば, 以下のコマンドを実行することもできます. # ppp -auto provider まとめ

要約すると, 初めて ppp を設定する際には, 以下のステップが不可欠です:

クライアント側: カーネルに tun デバイスが組み込まれていることを確認. /devディレクトリに tunX デバイスファイルが 存在することを確認. /etc/ppp/ppp.confにエントリを作成. ほとんどのプロバイダでは, pmdemand の例で充分でしょう. 動的 IP アドレスを使用するなら, /etc/ppp/ppp.linkupに エントリを作成. /etc/rc.conf (または sysconfig) ファイルを更新. 必要に応じてダイヤル (demand dialing) したいのであれば, start_if.tun0 スクリプトを作成.

サーバ側: カーネルに tun デバイスが組み込まれていることを確認. /devディレクトリに tunX デバイスファイルが 存在することを確認. (vipw(8) コマンドを使って) /etc/passwd にエントリを作成. このユーザのホームディレクトリに ``ppp -direct direct-server'' か何かを実行するプロファイルを作成. /etc/ppp/ppp.confにエントリを作成. direct-serverの例で充分でしょう. /etc/ppp/ppp.linkupにエントリを作成. /etc/rc.conf (または sysconfig) ファイルを更新. 謝辞

ハンドブックの このセクションは, 1997 年 9 月 7 日に &a.brian によって 更新されました.

以下の人々による情報提供, 批評そして提案に感謝します:

&a.nik

&a.dirkvangulik

&a.pjc