diff --git a/documentation/content/ja/books/handbook/advanced-networking/_index.adoc b/documentation/content/ja/books/handbook/advanced-networking/_index.adoc index 6ada5ec7fa..1769fda877 100644 --- a/documentation/content/ja/books/handbook/advanced-networking/_index.adoc +++ b/documentation/content/ja/books/handbook/advanced-networking/_index.adoc @@ -1,4156 +1,4156 @@ --- -title: 第21章 高度なネットワーク +title: 第20章 高度なネットワーク part: パートIV. ネットワーク通信 prev: books/handbook/mail next: books/handbook/partv showBookMenu: true -weight: 26 +weight: 25 path: "/books/handbook/" --- [[advanced-networking]] = 高度なネットワーク :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 -:sectnumoffset: 21 +:sectnumoffset: 20 :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/advanced-networking/ ifdef::env-beastie[] ifdef::backend-html5[] :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [[advanced-networking-synopsis]] == この章では この章では UNIX(R) システム上で良く利用されるネットワークサービスについて説明します。 FreeBSD が利用するすべてのネットワークサービスをどのように定義し、 設定し、テストし、そして保守するのかを扱います。さらに、 本章を通してあなたの役に立つ設定例が載っています。 この章を読めば以下のことが分かります。 * ゲートウェイと経路の基本 * FreeBSD をブリッジとして動作させる方法 * ネットワークファイルシステム (NFS) の設定方法 * ディスクレスマシンのネットワークブートの設定方法 * ユーザアカウントを共有するためのネットワークインフォメーションサーバ (NIS) の設定方法 * DHCP を用いて自動的にネットワーク設定を行う方法 * ドメインネームサーバ (DNS) の設定方法 * NTP プロトコルを用いて日時を同期してタイムサーバを設定する方法 * ネットワークアドレス変換 (NAT) の設定方法 * `inetd` デーモンの管理方法 * PLIP 経由で二台のコンピュータを接続する方法 * FreeBSD で IPv6 を設定する方法 この章を読む前に、以下のことを行っておくべきです。 * [.filename]#/etc/rc# スクリプトの基本を理解していること * 基礎的なネットワーク用語に精通していること [[network-routing]] == ゲートウェイと経路 あるマシンがネットワーク上で他のマシンをみつけることができるようにするには、 あるマシンから他のマシンへどのようにたどり着くかを記述する適切な仕組みが必要です。 この仕組みを__ルーティング__と呼びます。 "経路" (route) は "送信先" (destination) と "ゲートウェイ" の 2 つのアドレスの組で定義します。この組合せは、この _送信先_ へたどり着こうとする場合は、その _ゲートウェイ_ を通じて通信することを示しています。 送信先には個々のホスト、サブネット、"デフォルト" の 3 つの型があります。 "デフォルトルート" は他のどの経路も適用できない場合に使われます。 デフォルトルートについてはのちほどもう少し詳しく述べます。 また、ゲートウェイには、個々のホスト、インタフェース ("リンク" とも呼ばれます)、 イーサネットハードウェアアドレス (MAC アドレス) の 3 つの型があります。 === 例 以下に示す `netstat` の例を使って、ルーティングのさまざまな状態を説明します。 [source,shell] .... % netstat -r Routing tables Destination Gateway Flags Refs Use Netif Expire default outside-gw UGSc 37 418 ppp0 localhost localhost UH 0 181 lo0 test0 0:e0:b5:36:cf:4f UHLW 5 63288 ed0 77 10.20.30.255 link#1 UHLW 1 2421 example.com link#1 UC 0 0 host1 0:e0:a8:37:8:1e UHLW 3 4601 lo0 host2 0:e0:a8:37:8:1e UHLW 0 5 lo0 => host2.example.com link#1 UC 0 0 224 link#1 UC 0 0 .... 最初の 2 行はデフォルトルート (<>で扱います) と、 `localhost` への経路を示しています。 `localhost` に割り当てるインタフェース (`Netif` 欄) としてこのルーティングテーブルが指定しているのは [.filename]#lo0# で、これはループバックデバイスともいいます。 これは結局のところ出たところに戻るだけなので、 この送信先あてのトラフィックは、LAN に送られずに、すべて内部的に処理されます。 次の行では `0:e0:` から始まるアドレスに注目しましょう。 これはイーサネットハードウェアアドレスで、MAC アドレスともいいます。 FreeBSD はローカルなイーサネット上の任意のホスト (この例では `test0`) を自動的に認識し、 イーサネットインタフェース [.filename]#ed0# にそのホストへの直接の経路をつけ加えます。 この種の経路には、タイムアウト時間 (`Expire` 欄) も結びつけられており、 指定された時間内にホストからの応答がないことを判断するのに用いられます。 その場合、そのホストへの経路情報は自動的に削除されます。 これらのホストは RIP (Routing Information Protocol) という、 最短パス判定に基づいてローカルなホストへの経路を決定する仕組みを利用して認識されます。 さらに FreeBSD ではローカルサブネットへの経路情報も加えることができます (`10.20.30.255` は `10.20.30` というサブネットに対するブロードキャストアドレスで、 `example.com` はこのサブネットに結びつけられているドメイン名)。 `link#1` という名称は、 このマシンの一つ目のイーサネットカードのことをさします。 これらについては、 何も追加インタフェースが指定されていないことがわかります。 これら 2 つのグループ (ローカルネットワークホストとローカルサブネット) は、両方とも routed というデーモンによって自動的に経路が設定されます。 routed を動かさなければ、静的に定義した (つまり明示的に設定した) 経路のみが存在することになります。 `host1` の行は私たちのホストのことで、 イーサネットアドレスで示されています。送信側のホストの場合、 FreeBSDはイーサネットインタフェースへ送るのではなく、 ループバックインタフェース ([.filename]#lo0#) を使います。 2 つある `host2` の行は、 man:ifconfig[8] のエイリアスを使ったときにどのようになるかを示す例です (このようなことをする理由については Ethernet の節を参照してください)。 [.filename]#lo0# の後にある `=>` は、 インタフェースが (このアドレスがローカルなホストを参照しているので) ループバックを使っているというだけでなく、 エイリアスになっていることも示しています。 このような経路はエイリアスに対応しているホストにのみ現れます。 ローカルネットワーク上の他のすべてのホストでは、 それぞれの経路に対して単に``link#1`` となります。 最後の行 (送信先サブネット `224`) はマルチキャストで扱うものですが、これは他の節で説明します。 最後に `Flags` (フラグ) 欄にそれぞれの経路のさまざまな属性が表示されます。 以下にフラグの一部と、それが何を意味しているかを示します。 [.informaltable] [cols="1,1", frame="none"] |=== |U |Up: この経路はアクティブです。 |H |Host: 経路の送信先が単一のホストです。 |G |Gateway: この送信先へ送られると、 どこへ送ればよいかを明らかにして、 そのリモートシステムへ送られます。 |S |Static: この経路はシステムによって自動的に生成されたのではなく、 手動で作成されました。 |C |Clone: マシンに接続したときにこの経路に基づく新しい経路が作られます。 この型の経路は通常はローカルネットワークで使われます。 |W |WasCloned: ローカルエリアネットワーク (LAN) の (Clone) 経路に基づいて自動的に生成された経路であることを示します。 |L |Link: イーサネットハードウェアへの参照を含む経路です。 |=== [[network-routing-default]] === デフォルトルート ローカルシステムからリモートホストにコネクションを張る必要がある場合、 既知の経路が存在するかどうかを確認するためにルーティングテーブルをチェックします。 到達するための経路を知っているサブネットの内部にリモートホストがある場合 (Cloned routes)、 システムはそのインタフェースから接続できるかどうか確認します。 知っているパスがすべて駄目だった場合でも、 システムには最後の手段として "デフォルト" ルートがあります。このルートはゲートウェイルート (普通はシステムに 1 つしかありません) の特別なものです。そして、 フラグ欄には必ず `c` が表示されています。このゲートウェイは、LAN 内のホストにとって、どのマシンでも外部へ (PPP リンク、DSL、ケーブルモデム、T1、 またはその他のネットワークインタフェースのいずれかを経由して) 直接接続するために設定されるものです。 外部に対するゲートウェイとして機能するマシンでデフォルトルートを設定する場合、 デフォルトルートはインターネットサービスプロバイダ (ISP) のサイトのゲートウェイマシンになるでしょう。 それではデフォルトルートの一例を見てみましょう。 一般的な構成を示します。 image::net-routing.png[] ホスト `Local1` とホスト `Local2` はあなたのサイト内にあります。`Local1` はダイアルアップ PPP 接続経由で ISP に接続されています。 この PPP サーバコンピュータは、その ISP のインターネットへの接続点に向けた外部インタフェースを備えた他のゲートウェイコンピュータへ LAN を通じて接続しています。 あなたのマシンのデフォルトルートはそれぞれ次のようになります。 [.informaltable] [cols="1,1,1", frame="none", options="header"] |=== | ホスト | デフォルトゲートウェイ | インタフェース |Local2 |Local1 |Ethernet |Local1 |T1-GW |PPP |=== "なぜ (あるいは、どうやって) デフォルトゲートウェイを、`Local1` が接続されている ISP のサーバではなく、`T1-GW` に設定するのか" という質問がよくあります。 PPP 接続で、あなたのサイト側の PPP インタフェースは、 ISP のローカルネットワーク上のアドレスを用いているため、 ISP のローカルネットワーク上のすべてのマシンへの経路は 自動的に生成されています。 つまりあなたのマシンは、どのようにして `T1-GW` に到達するかという経路を既に知っていることになりますから、 ISP サーバにトラフィックを送るのに、 中間的な段階を踏む必要はありません。 一般的にローカルネットワークでは `X.X.X.1` というアドレスをゲートウェイアドレスとして使います。ですから (同じ例を用います)、あなたの class-C のアドレス空間が `10.20.30` で ISP が `10.9.9` を用いている場合、 デフォルトルートは次のようになります。 [.informaltable] [cols="1,1", frame="none", options="header"] |=== | ホスト | デフォルトルート |Local2 (10.20.30.2) |Local1 (10.20.30.1) |Local1 (10.20.30.1, 10.9.9.30) |T1-GW (10.9.9.1) |=== デフォルトルートは [.filename]#/etc/rc.conf# ファイルで簡単に定義できます。この例では、 `Local2` マシンで [.filename]#/etc/rc.conf# に次の行を追加しています。 [.programlisting] .... defaultrouter="10.20.30.1" .... man:route[8] コマンドを使ってコマンドラインから直接実行することもできます。 [source,shell] .... # route add default 10.20.30.1 .... 経路情報を手動で操作する方法について詳しいことは man:route[8] のマニュアルページをご覧ください。 === デュアルホームホスト ここで扱うべき種類の設定がもう一つあります。 それは 2 つの異なるネットワークにまたがるホストです。 技術的にはゲートウェイとして機能するマシン (上の例では PPP コネクションを用いています) はすべてデュアルホームホストです。 しかし実際にはこの言葉は、2 つの LAN 上のサイトであるマシンを指す言葉としてのみ使われます。 2 枚のイーサネットカードを持つマシンが、 別のサブネット上にそれぞれアドレスを持っている場合があります。 あるいは、イーサネットカードが 1 枚しかないマシンで、 man:ifconfig[8] のエイリアスを使っているかもしれません。 物理的に分かれている 2 つのイーサネットのネットワークが使われているならば前者が用いられます。 後者は、物理的には 1 つのネットワークセグメントで、 論理的には 2 つのサブネットに分かれている場合に用いられます。 どちらにしても、 このマシンがお互いのサブネットへのゲートウェイ (inbound route) として定義されていることが分かるように、 おのおののサブネットでルーティングテーブルを設定します。このマシンが 2 つのサブネットの間のルータとして動作するという構成は、 パケットのフィルタリングを実装する必要がある場合や、 一方向または双方向のファイアウォールを利用したセキュリティを構築する場合によく用いられます。 このマシンが二つのインタフェース間で実際にパケットを受け渡すようにしたい場合は、 FreeBSD でこの機能を有効にしないといけません。 くわしい手順については次の節をご覧ください。 [[network-dedicated-router]] === ルータの構築 ネットワークルータは単にあるインタフェースから別のインタフェースへパケットを転送するシステムです。 インターネット標準およびすぐれた技術的な慣習から、 FreeBSD プロジェクトは FreeBSD においてこの機能をデフォルトでは有効にしていません。 man:rc.conf[5] 内で次の変数を `YES` に変更することでこの機能を有効にできます。 [.programlisting] .... gateway_enable=YES # Set to YES if this host will be a gateway .... このオプションは man:sysctl[8] 変数の `net.inet.ip.forwarding` を `1` に設定します。 一時的にルーティングを停止する必要があるときには、 この変数を一時的に `0` に設定しなおせます。 次に、トラフィックの宛先を決めるために、 そのルータには経路情報が必要になります。 ネットワークが十分簡素なら、静的経路が利用できます。 また、FreeBSD は BSD の標準ルーティングデーモンである man:routed[8] を備えています。これは RIP (バージョン 1 および 2) および IRDP を扱えます。 BGP バージョン 4、OSPF バージョン2、 その他洗練されたルーティングプロトコルは package:net/zebra[] package を用いれば対応できます。 また、より複雑なネットワークルーティングソリューションには、 GateD(R) のような商用製品も利用可能です。 このように FreeBSD を設定したとしても、 ルータに対するインターネット標準要求を完全に満たすわけではありません。 しかし、通常利用に関しては十分といえます。 === 静的な経路の設定 ==== 手動による経路の設定 以下のようなネットワークが存在すると仮定します。 .... INTERNET | (10.0.0.1/24) Default Router to Internet | |Interface xl0 |10.0.0.10/24 +------+ | | RouterA | | (FreeBSD gateway) +------+ | Interface xl1 | 192.168.1.1/24 | +--------------------------------+ Internal Net 1 | 192.168.1.2/24 | +------+ | | RouterB | | +------+ | 192.168.2.1/24 | Internal Net 2 .... このシナリオでは、FreeBSD マシンの `RouterA` がインターネットに向けられたルータとして動作します。 ルータは外側のネットワークへ接続できるように `10.0.0.1` へ向けたデフォルトルートを保持しています。 `RouterB` はすでに適切に設定されており、 どこへ向かう必要があるか、 行き着く方法を知っていると仮定します (この例では、図のように簡単です。 `192.168.1.1` をゲートウェイとして `RouterB` にデフォルトルートを追加するだけです)。 `RouterA` のルーティングテーブルを確認すると、 以下のような出力を得ます。 [source,shell] .... % netstat -nr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 10.0.0.1 UGS 0 49378 xl0 127.0.0.1 127.0.0.1 UH 0 6 lo0 10.0.0/24 link#1 UC 0 0 xl0 192.168.1/24 link#2 UC 0 0 xl1 .... 現在のルーティングテーブルでは、`RouterA` はまだ Internal Net 2 には到達できないでしょう。 `192.168.2.0/24` の経路を保持していないからです。 解決するための一つの方法は、経路を手動で追加することです。 以下のコマンドで `RouterA` のルーティングテーブルに `192.168.1.2` を送り先として、Internal Net 2 ネットワークを追加します。 [source,shell] .... # route add -net 192.168.2.0/24 192.168.1.2 .... これにより、`RouterA` は、 `192.168.2.0/24` ネットワーク上のホストに到達出来ます。 ==== 永続的な設定 上記の例は、 起動しているシステム上に静的な経路を設定する方法としては完全です。 しかしながら、FreeBSD マシンを再起動した際にルーティング情報が残らないという問題が一つあります。 静的な経路を追加するには、[.filename]#/etc/rc.conf# ファイルにルートを追加してください。 [.programlisting] .... # Add Internal Net 2 as a static route static_routes="internalnet2" route_internalnet2="-net 192.168.2.0/24 192.168.1.2" .... `static_routes` の設定変数は、 スペースによって分離される文字列のリストです。 それぞれの文字列は経路名として参照されます。 上記の例では `static_routes` は一つの文字列のみを持ちます。 その文字列は _internalnet2_ です。その後、 `route_internalnet2` という設定変数を追加し、 man:route[8] コマンドに与えるすべての設定パラメータを指定しています。 前節の例では、以下のコマンド [source,shell] .... # route add -net 192.168.2.0/24 192.168.1.2 .... を用いたので、 `"-net 192.168.2.0/24 192.168.1.2"` が必要になります。 上記のように `static_routes` は一つ以上の文字列を持つことが出来るので、 多数の静的な経路を作ることができます。 以下の行は `192.168.0.0/24` および `192.168.1.0/24` ネットワークを、 仮想ルータ上に静的な経路として追加する例です。 [.programlisting] .... static_routes="net1 net2" route_net1="-net 192.168.0.0/24 192.168.0.1" route_net2="-net 192.168.1.0/24 192.168.1.1" .... === ルーティングの伝搬 外部との経路をどのように定義したらよいかはすでに説明しました。 しかし外部から私たちのマシンをどのようにして見つけるのかについては説明していません。 ある特定のアドレス空間 (この例では class-C のサブネット) におけるすべてのトラフィックが、 到着したパケットを内部で転送するネットワーク上の特定のホストに送られるようにルーティングテーブルを設定することができるのは分かっています。 あなたのサイトにアドレス空間を割り当てる場合、 あなたのサブネットへのすべてのトラフィックがすべて PPP リンクを通じてサイトに送ってくるようにサービスプロバイダはルーティングテーブルを設定します。 しかし、国境の向こう側のサイトはどのようにしてあなたの ISP へ送ることを知るのでしょうか? 割り当てられているすべてのアドレス空間の経路を維持する (分散している DNS 情報とよく似た) システムがあり、 そのインターネットバックボーンへの接続点を定義しています。 "バックボーン" とは国を越え、 世界中のインターネットのトラフィックを運ぶ主要な信用できる幹線のことです。 どのバックボーンマシンも、 あるネットワークから特定のバックボーンのマシンへ向かうトラフィックと、 そのバックボーンのマシンからあなたのネットワークに届くサービスプロバイダまでのチェーンのマスタテーブルのコピーを持っています。 あなたのサイトが接続 (プロバイダからみて内側にあることになります) したということを、 プロバイダからバックボーンサイトへ通知することはプロバイダの仕事です。 これが経路の伝搬です。 === トラブルシューティング 経路の伝搬に問題が生じて、 いくつかのサイトが接続をおこなうことができなくなることがあります。 ルーティングがどこでおかしくなっているかを明らかにするのに最も有効なコマンドはおそらく man:traceroute[8] コマンドでしょう。 このコマンドは、あなたがリモートマシンに対して接続をおこなうことができない (たとえば man:ping[8] に失敗するような) 場合も、同じように有効です。 man:traceroute[8] コマンドは、 接続を試みているリモートホストを引数にして実行します。 試みている経路が経由するゲートウェイホストを表示し、 最終的には目的のホストにたどり着くか、 コネクションの欠如によって終ってしまうかのどちらかになります。 より詳しい情報は、man:traceroute[8] のマニュアルページをみてください。 === マルチキャストルーティング FreeBSD はマルチキャストアプリケーションとマルチキャストルーティングの両方にネイティブ対応しています。 マルチキャストアプリケーションを動かすのに FreeBSD で特別な設定をする必要は一切ありません。 アプリケーションは普通はそのままで動くでしょう。 マルチキャストルーティングに対応するには、 下のオプションを追加してカーネルをコンパイルする必要があります。 [.programlisting] .... options MROUTING .... さらに、[.filename]#/etc/mrouted.conf# を編集してルーティングデーモン man:mrouted[8] を設定し、トンネルと DVMRP を設置する必要があります。 マルチキャスト設定についての詳細は man:mrouted[8] のマニュアルページを参照してください。 [[network-wireless]] == 無線ネットワーク === はじめに 常にネットワークケーブルをつないでいるという面倒なことをせずに、 コンピュータを使用できることは、とても有用でしょう。 FreeBSD は無線のクライアントとして、 さらに "アクセスポイント" としても使えます。 === 無線の動作モード 802.11 無線デバイスの設定には、BSS と IBSS の二つの方法があります。 ==== BSS モード BSS モードは一般的に使われているモードです。 BSS モードはインフラストラクチャモードとも呼ばれています。 このモードでは、 多くの無線アクセスポイントが 1 つの有線ネットワークに接続されます。 それぞれのワイヤレスネットワークは固有の名称を持っています。 その名称はネットワークの SSID と呼ばれます。 無線クライアントはこれらの無線アクセスポイントに接続します。 IEEE 802.11 標準は無線ネットワークが接続するのに使用するプロトコルを規定しています。 SSID が設定されているときは、 無線クライアントを特定のネットワークに結びつけることができます。 SSID を明示的に指定しないことにより、 無線クライアントを任意のネットワークに接続することもできます。 ==== IBSS モード アドホックモードとも呼ばれる IBSS モードは、 一対一通信のために設計された通信方式です。 実際には二種類のアドホックモードがあります。 一つは IBSS モードで、アドホックモード、または IEEE アドホックモードとも呼ばれます。 このモードは IEEE 802.11 標準に規定されています。 もう一つはデモアドホックモードもしくは Lucent アドホックモード (そして時々、紛らわしいことに、アドホックモード) と呼ばれるモードです。 このモードは古く、802.11 が標準化する以前のアドホックモードで、 これは古い設備でのみ使用されるべきでしょう。 ここでは、どちらのアドホックモードについてもこれ以上言及しません。 === インフラストラクチャーモード ==== アクセスポイント アクセスポイントは一つ以上の無線クライアントが、 そのデバイスをセントラルハブとして利用できるようにする無線ネットワークデバイスです。 アクセスポイントを使用している間、 すべてのクライアントはアクセスポイントを介して通信します。 家屋や職場、または公園などの空間を無線ネットワークで完全にカバーするために、 複数のアクセスポイントがよく使われます。 アクセスポイントは一般的に複数のネットワーク接続 (無線カードと、 その他のネットワークに接続するための一つ以上の有線イーサネットアダプタ) を持っています。 アクセスポイントは、出来合いのものを購入することもできますし、 FreeBSD と対応している無線カードを組み合わせて、 自分で構築することもできます。 いくつものメーカが、 さまざまな機能をもった無線アクセスポイントおよび無線カードを製造しています。 ==== FreeBSD のアクセスポイントの構築 ===== 要件 FreeBSD で無線アクセスポイントを設定するためには、 互換性のある無線カードが必要です。 現状では Prism チップセットのカードのみに対応しています。 また FreeBSD に対応している有線ネットワークカードも必要になるでしょう (これを見つけるのは難しくないでしょう。 FreeBSD は多くの異なるデバイスに対応しているからです) 。 この手引きでは、 無線デバイスと有線ネットワークカードに接続しているネットワーク間のトラフィックを man:bridge[4] したいと仮定します。 FreeBSD がアクセスポイントを実装するのに使用する hostap 機能はファームウェアの特定のバージョンで一番よく性能を発揮します。 Prism 2 カードは、 1.3.4 以降のバージョンのファームウェアで使用すべきです。 Prism 2.5 および Prism 3 カードでは、バージョン 1.4.9 のバージョンのファームウェアで使用すべきです。 それより古いバージョンのファームウェアは、 正常に動くかもしれませんし、動かないかもしれません。 現時点では、カードのファームウェアを更新する唯一の方法は、 カードの製造元から入手できる Windows(R) 用ファームウェアアップデートユーティリティを使うものです。 ===== 設定 はじめにシステムが無線カードを認識していることを確認してください。 [source,shell] .... # ifconfig -a wi0: flags=8843 mtu 1500 inet6 fe80::202:2dff:fe2d:c938%wi0 prefixlen 64 scopeid 0x7 inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 ether 00:09:2d:2d:c9:50 media: IEEE 802.11 Wireless Ethernet autoselect (DS/2Mbps) status: no carrier ssid "" stationname "FreeBSD Wireless node" channel 10 authmode OPEN powersavemode OFF powersavesleep 100 wepmode OFF weptxkey 1 .... 細かいことは気にせず、 無線カードがインストールされていることを示す何かが表示されていることを確かめてください。 PC カードを使用していて、無線インタフェースを認識できない場合、 詳しい情報を得るために man:pccardc[8] と man:pccardd[8] のマニュアルページを調べてみてください。 次に、アクセスポイント用に FreeBSD のブリッジ機能を担う部分を有効にするために、 モジュールを読み込む必要があるでしょう。 man:bridge[4] モジュールを読み込むには、 次のコマンドをそのまま実行します。 [source,shell] .... # kldload bridge .... モジュールを読み込む時には、何もエラーはでないはずです。 もしもエラーがでたら、カーネルに man:bridge[4] のコードを入れてコンパイルする必要があるかもしれません。 ハンドブックの<>の節が、 この課題を成し遂げる手助けをになるかもしれません。 ブリッジ部分が準備できたので、 どのインタフェース間をブリッジするのかを FreeBSD カーネルに指定する必要があります。 これは、man:sysctl[8] を使って行います。 [source,shell] .... # sysctl net.link.ether.bridge=1 # sysctl net.link.ether.bridge_cfg="wi0,xl0" # sysctl net.inet.ip.forwarding=1 .... FreeBSD 5.2-RELEASE 以降では、次のように指定しなければなりません。 [source,shell] .... # sysctl net.link.ether.bridge.enable=1 # sysctl net.link.ether.bridge.config="wi0,xl0" # sysctl net.inet.ip.forwarding=1 .... さて、無線カードを設定するときです。 次のコマンドはカードをアクセスポイントとして設定します。 [source,shell] .... # ifconfig wi0 ssid my_net channel 11 media DS/11Mbps mediaopt hostap up stationname "FreeBSD AP" .... この man:ifconfig[8] コマンド行は [.filename]#wi0# インタフェースを up 状態にし、SSID を _my_net_ に設定し、 ステーション名を _FreeBSD AP_ に設定します。 `media DS/11Mbps` オプションはカードを 11Mbps モードに設定し、また `mediaopt` を実際に有効にするのに必要です。 `mediaopt hostap` オプションはインタフェースをアクセスポイントモードにします。 `channel 11` オプションは使用するチャネルを 802.11b に設定します。 各規制地域 (regulatory domain) で有効なチャネル番号は man:wicontrol[8] マニュアルページに載っています。 さて、 これで完全に機能するアクセスポイントが立ち上がり、動作しています。 より詳しい情報については、man:wicontrol[8], man:ifconfig[8] および man:wi[4] のマニュアルを読むとよいでしょう。 また、下記の暗号化に関する節を読むこともおすすめします。 ===== ステータス情報 一度アクセスポイントが設定されて稼働すると、 管理者はアクセスポイントを利用しているクライアントを見たいと思うでしょう。 いつでも管理者は以下のコマンドを実行できます。 [source,shell] .... # wicontrol -l 1 station: 00:09:b7:7b:9d:16 asid=04c0, flags=3, caps=1, rates=f<1M,2M,5.5M,11M>, sig=38/15 .... これは一つの局が、 表示されているパラメータで接続していることを示します。 表示された信号は、 相対的な強さを表示しているだけのものとして扱われるべきです。 dBm やその他の単位への変換結果は、 異なるファームウェアバージョン間で異なります。 ==== クライアント 無線クライアントはアクセスポイント、 または他のクライアントに直接アクセスするシステムです。 典型的には、 無線クライアントが有しているネットワークデバイスは、 無線ネットワークカード 1 枚だけです。 無線クライアントを設定するにはいくつか方法があります。 それぞれは異なる無線モードに依存していますが、 一般的には BSS (アクセスポイントを必要とするインフラストラクチャーモード) か、 IBSS (アドホック、またはピアツーピアモード) のどちらかです。 ここでは、アクセスポイントと通信をするのに、 両者のうちで最も広まっている BSS モードを使用します。 ===== 要件 FreeBSD を無線クライアントとして設定するのに、 本当に必要なものはたった 1 つだけです。 FreeBSD が対応している無線カードが必要です。 ===== 無線 FreeBSD クライアントの設定 設定をはじめる前に、 あなたが接続しようとする無線ネットワークについていくつか知っておかなければなりません。 この例では、_my_net_ という名前で暗号化は無効になっているネットワークに接続しようとしています。 [NOTE] ==== この例では暗号化を行っていないのですが、 これは危険な状況です。次の節で、暗号化を有効にする方法と、 なぜそれが重要で、 暗号技術によっては完全にはあなたを保護することができないのはなぜか、 ということを学ぶでしょう。 ==== カードが FreeBSD に認識されていることを確認してください。 [source,shell] .... # ifconfig -a wi0: flags=8843 mtu 1500 inet6 fe80::202:2dff:fe2d:c938%wi0 prefixlen 64 scopeid 0x7 inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 ether 00:09:2d:2d:c9:50 media: IEEE 802.11 Wireless Ethernet autoselect (DS/2Mbps) status: no carrier ssid "" stationname "FreeBSD Wireless node" channel 10 authmode OPEN powersavemode OFF powersavesleep 100 wepmode OFF weptxkey 1 .... それでは、このカードをネットワークに合わせて設定しましょう。 [source,shell] .... # ifconfig wi0 inet 192.168.0.20 netmask 255.255.255.0 ssid my_net .... `192.168.0.20` と `255.255.255.0` を有線ネットワークで有効な IP アドレスとネットマスクに置き換えてください。 アクセスポイントは無線ネットワークと有線ネットワークの間でデータをブリッジしているため、 ネットワーク上の他のデバイスには、このデバイスが、他と同様に、 有線ネットワーク上にあるかのように見えることに注意してください。 これを終えると、 あなたは標準的な有線接続を使用しているかのように、 有線ネットワーク上のホストに ping を送ることができるでしょう。 無線接続に関する問題がある場合は、 アクセスポイントに接続されていることを確認してください。 [source,shell] .... # ifconfig wi0 .... いくらか情報が表示されるはずです。 その中に以下の表示があるはずです。 [source,shell] .... status: associated .... もし `associated` と表示されなければ、 アクセスポイントの範囲外かもしれないし、 暗号化が有効になっているかもしれないし、 または設定の問題を抱えているのかもしれません。 ==== 暗号化 無線ネットワークを暗号化することが重要なのは、 十分保護された領域にネットワークを留める能力がもはやないからです。 無線データはその周辺全体にわたって放送されるので、 それを読みたいと思う人はだれでも読むことができます。 そこで暗号化が役に立ちます。 電波に載せて送られるデータを暗号化することによって、 興味を抱いた者が空中からデータを取得することをずっと難しくします。 クライアントとアクセスポイント間のデータを暗号化するもっとも一般的な方法には、 WEP と man:ipsec[4] の二種類があります。 ===== WEP WEP は Wired Equivalency Protocol (訳注: 直訳すると、有線等価プロトコル) の略語です。WEP は無線ネットワークを有線ネットワークと同程度に安全で確実なものにしようとする試みです。 残念ながら、これはすでに破られており、 破るのはそれほど苦労しません。 これは、機密データを暗号化するという場合に、 これに頼るものではないということも意味します。 なにも無いよりはましなので、 次のコマンドを使って、あなたの新しい FreeBSD アクセスポイント上で WEP を有効にしてください。 [source,shell] .... # ifconfig wi0 inet up ssid my_net wepmode on wepkey 0x1234567890 media DS/11Mbps mediaopt hostap .... クライアントについては次のコマンドで WEP を有効にできます。 [source,shell] .... # ifconfig wi0 inet 192.168.0.20 netmask 255.255.255.0 ssid my_net wepmode on wepkey 0x1234567890 .... _0x1234567890_ をより特異なキーに変更すべきであることに注意してください。 ===== IPsec man:ipsec[4] はネットワーク上で交わされるデータを暗号化するための、 はるかに頑健で強力なツールです。 これは無線ネットワーク上のデータを暗号化する明らかに好ましい方法です。 ハンドブック内の crossref:security[ipsec,IPsec] 節で man:ipsec[4] セキュリティ、 およびその実装方法の詳細を読むことができます。 ==== ツール 無線ネットワークをデバッグしたり設定するのに使うツールがわずかばかりあります。 ここでその一部と、それらが何をしているか説明します。 ===== bsd-airtools パッケージ bsd-airtools パッケージは、 WEP キークラッキング、 アクセスポイント検知などの無線通信を監査するツールを含む完備されたツール集です。 bsd-airtools ユーティリティは package:net/bsd-airtools[] port からインストールできます。 ports のインストールに関する情報はこのハンドブックの crossref:ports[ports,アプリケーションのインストール - packages と ports] を参照してください。 `dstumbler` プログラムは、 アクセスポイントの発見および S/N 比のグラフ化をできるようにするパッケージツールです。 アクセスポイントを立ち上げて動かすのに苦労しているなら、 `dstumbler` はうまく行く手助けになるかもしれません。 無線ネットワークの安全性をテストするのに、 "dweputils" (`dwepcrack`, `dwepdump` および `dwepkeygen`) を使用することで、 WEP があなたの無線安全性への要求に対する正しい解決策かどうか判断するのを助けられるかもしれません。 ===== `wicontrol`, `ancontrol` および `raycontrol` ユーティリティ これらは、無線ネットワーク上で無線カードがどのように動作するかを制御するツールです。 上記の例では、無線カードが [.filename]#wi0# インタフェースであるので、man:wicontrol[8] を使用することに決めました。 もし Cisco の無線デバイスを持っている場合は、それは [.filename]#an0# として動作するでしょうから、 man:ancontrol[8] を使うことになるでしょう。 ===== `ifconfig` コマンド man:ifconfig[8] は man:wicontrol[8] と同じオプションの多くを処理できますが、 いくつかのオプションを欠いています。 コマンドライン引数とオプションについて man:ifconfig[8] を参照してください。 ==== 対応しているカード ===== アクセスポイント 現在のところ (アクセスポイントとして) BSS モードに対応した唯一のカードは Prism 2, 2.5 または 3 チップセットを利用したデバイスです。 man:wi[4] に完全な一覧があります。 ===== クライアント 現在、FreeBSD では、ほとんどすべての 802.11b 無線カードに対応しています。 Prism, Spectrum24, Hermes, Aironet または Raylink のチップセットを利用したほとんどのカードは、 (アドホック、ピアツーピア、そして BSS の) IBSS モードで無線ネットワークカードとして動作するでしょう。 [[network-bluetooth]] == Bluetooth === はじめに Bluetooth は免許のいらない 2.4 GHz の帯域を利用して、 10 m 程度のパーソナルネットワークを作る無線技術です。 ネットワークはたいていの場合、その場その場で、携帯電話や PDA やノートパソコンなどの携帯デバイスから形成されます。 Wi-Fi などの他の有名な無線技術とは違い、 Bluetooth はより高いレベルのサービスを提供します。 たとえば、FTP のようなファイルサーバ、ファイルのプッシュ、 音声伝送、シリアル線のエミュレーションなどのサービスです。 FreeBSD 内での Bluetooth スタックは Netgraph フレームワーク (man:netgraph[4] 参照) を使って実現されています。 man:ng_ubt[4] ドライバは、 多種多様な Bluetooth USB ドングルに対応しています。 Broadcom BCM2033 チップを搭載した Bluetooth デバイスは man:ubtbcmfw[4] および man:ng_ubt[4] ドライバによって対応されています。 3Com Bluetooth PC カード 3CRWB60-A は man:ng_bt3c[4] ドライバによって対応されています。 シリアルおよび UART を搭載した Bluetooth デバイスは man:sio[4], man:ng_h4[4] および man:hcseriald[8] ドライバによって対応されています。 この節では USB Bluetooth ドングルの使用法について説明します。 Bluetooth に対応しているのは FreeBSD 5.0 以降のシステムです。 [NOTE] ==== 5.0, 5.1 Release ではカーネルモジュールは利用可能ですが、 種々のユーティリティとマニュアルは標準でコンパイルされていません。 ==== === デバイスの挿入 デフォルトでは Bluetooth デバイスドライバはカーネルモジュールとして利用できます。 デバイスを接続する前に、 カーネルにドライバを読み込む必要があります。 [source,shell] .... # kldload ng_ubt .... Bluetooth デバイスがシステム起動時に存在している場合、 [.filename]#/boot/loader.conf# からモジュールを読み込んでください。 [.programlisting] .... ng_ubt_load="YES" .... USB ドングルを挿してください。コンソールに (または syslog に) 下記のような表示が現れるでしょう。 [source,shell] .... ubt0: vendor 0x0a12 product 0x0001, rev 1.10/5.25, addr 2 ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2 ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3, wMaxPacketSize=49, nframes=6, buffer size=294 .... [.filename]#/usr/shared/examples/netgraph/bluetooth/rc.bluetooth# を [.filename]#/etc/rc.bluetooth# のようなどこか便利な場所にコピーしてください。 このスクリプトは Bluetooth スタックを開始および終了させるのに使われます。 デバイスを抜く前にスタックを終了するのはよい考えですが、 (たいていの場合) しなくても致命的ではありません。 スタックを開始するときに、下記のような出力がされます。 [source,shell] .... # /etc/rc.bluetooth start ubt0 BD_ADDR: 00:02:72:00:d4:1a Features: 0xff 0xff 0xf 00 00 00 00 00 <3-Slot> <5-Slot> Max. ACL packet size: 192 bytes Number of ACL packets: 8 Max. SCO packet size: 64 bytes Number of SCO packets: 8 .... === ホストコントローラインタフェース (HCI) ホストコントローラインタフェース (HCI) は、 ベースバンドコントローラおよびリンクマネージャへのコマンドインタフェースを提供し、 ハードウェアステータスおよびコントロールレジスタへアクセスします。 このインタフェースは Bluetooth ベースバンド機能へアクセスする画一的な方法を提供します。 ホストの HCI 層は Bluetooth ハードウェア上の HCI ファームウェアと、 データとコマンドをやり取りします。 ホストコントローラトランスポート層 (つまり物理的なバス) のドライバは、 両方の HCI 層に相互に情報を交換する能力を与えます。 一つの Bluetooth デバイスにつき、_hci_ タイプの Netgraph ノードが一つ作成されます。 HCI ノードは通常 Bluetooth デバイスドライバノード (下流) と L2CAP ノード (上流) に接続されます。 すべての HCI 動作はデバイスドライバノード上ではなく、 HCI ノード上で行われなくてはいけません。 HCI ノードのデフォルト名は "devicehci" です。 詳細については man:ng_hci[4] マニュアルを参照してください。 最も一般的なタスクの一つに、無線通信的に近傍にある Bluetooth デバイスの発見があります。 この動作は _inquiry (問い合わせ)_ と呼ばれています。 Inquiry や他の HCI に関連した動作は man:hccontrol[8] ユーティリティによってなされます。 下記の例は、どの Bluetooth デバイスが通信圏内にあるかを知る方法を示しています。 デバイスのリストが表示されるには数秒かかります。 リモートデバイスは _discoverable (発見可能な)_ モードにある場合にのみ inquiry に返答するということに注意してください。 [source,shell] .... % hccontrol -n ubt0hci inquiry Inquiry result, num_responses=1 Inquiry result #0 BD_ADDR: 00:80:37:29:19:a4 Page Scan Rep. Mode: 0x1 Page Scan Period Mode: 00 Page Scan Mode: 00 Class: 52:02:04 Clock offset: 0x78ef Inquiry complete. Status: No error [00] .... `BD_ADDR` は Bluetooth デバイスに固有のアドレスです。 これはネットワークカードの MAC アドレスに似ています。 このアドレスはデバイスとの通信を続けるのに必要となります。 BD_ADDR に人間が判読しやすい名前を割り当てることもできます。 [.filename]#/etc/bluetooth/hosts# ファイルには、 既知の Bluetooth ホストに関する情報が含まれています。 次の例はリモートデバイスに割り当てられている、 人間が判読しやすい名前を得る方法を示しています。 [source,shell] .... % hccontrol -n ubt0hci remote_name_request 00:80:37:29:19:a4 BD_ADDR: 00:80:37:29:19:a4 Name: Pav's T39 .... リモートの Bluetooth デバイス上で inquiry を実行すると、 あなたのコンピュータは "your.host.name (ubt0)" と認識されます。 ローカルデバイスに割り当てられた名前はいつでも変更できます。 Bluetooth システムは一対一接続 (二つの Bluetooth ユニットだけが関係します) または一対多接続を提供します。 一対多接続では、接続はいくつかの Bluetooth デバイス間で共有されます。 次の例は、ローカルデバイスに対するアクティブなベースバンド接続のリストを得る方法を示しています。 [source,shell] .... % hccontrol -n ubt0hci read_connection_list Remote BD_ADDR Handle Type Mode Role Encrypt Pending Queue State 00:80:37:29:19:a4 41 ACL 0 MAST NONE 0 0 OPEN .... _connection handle_ はベースバンド接続の終了が必要とされるときに便利です。 もっとも、通常はこれを手動で行う必要はありません。 Bluetooth スタックはアクティブでないベースバンド接続を自動的に終了します。 [source,shell] .... # hccontrol -n ubt0hci disconnect 41 Connection handle: 41 Reason: Connection terminated by local host [0x16] .... 利用可能な HCI コマンドの完全な一覧を得るには、 `hccontrol help` を参照してください。 HCI コマンドのほとんどはスーパユーザ権限を必要としません。 === ロジカルリンクコントロールおよびアダプテーションプロトコル (L2CAP) ロジカルリンクコントロールおよびアダプテーションプロトコル (L2CAP) は、プロトコル多重化ケーパビリティおよび分割・再編成動作を備えた、 上位層プロトコルへのコネクション指向およびコネクションレスデータサービスを提供します。 L2CAP は上位層プロトコルおよびアプリケーションが 64 KB までの長さの L2CAP データパケットを送受信することを可能にします。 L2CAP は _チャネル_ の概念に基づいています。 チャネルはベースバンド接続の上位に位置する論理的な接続です。 それぞれのチャネルは多対一の方法で一つのプロトコルに結びつけられます。 複数のチャネルを同じプロトコルに結びつけることは可能ですが、 一つのチャネルを複数のプロトコルに結びつけることはできません。 チャネル上で受け取られたそれぞれの L2CAP パケットは、 適切なより上位のプロトコルに渡されます。 複数のチャネルは同じベースバンド接続を共有できます。 一つの Bluetooth デバイスに対して、_l2cap_ タイプの Netgraph ノードが一つ作成されます。 L2CAP ノードは通常 Bluetooth HCI ノード (下流) と Bluetooth ソケットノード (上流) に接続されます。 L2CAP ノードのデフォルト名は "devicel2cap" です。 詳細については man:ng_l2cap[4] マニュアルを参照してください。 便利なコマンドに、他のデバイスに ping を送ることができる man:l2ping[8] があります。Bluetooth 実装によっては、 送られたデータすべては返さないことがあります。 したがって次の例で _0 バイト_ は正常です。 [source,shell] .... # l2ping -a 00:80:37:29:19:a4 0 bytes from 0:80:37:29:19:a4 seq_no=0 time=48.633 ms result=0 0 bytes from 0:80:37:29:19:a4 seq_no=1 time=37.551 ms result=0 0 bytes from 0:80:37:29:19:a4 seq_no=2 time=28.324 ms result=0 0 bytes from 0:80:37:29:19:a4 seq_no=3 time=46.150 ms result=0 .... man:l2control[8] ユーティリティは L2CAP ノード上でさまざまな操作を行うのに使われます。 この例は、ローカルデバイスに対する論理的な接続 (チャネル) およびベースバンド接続の一覧を得る方法を示しています。 [source,shell] .... % l2control -a 00:02:72:00:d4:1a read_channel_list L2CAP channels: Remote BD_ADDR SCID/ DCID PSM IMTU/ OMTU State 00:07:e0:00:0b:ca 66/ 64 3 132/ 672 OPEN % l2control -a 00:02:72:00:d4:1a read_connection_list L2CAP connections: Remote BD_ADDR Handle Flags Pending State 00:07:e0:00:0b:ca 41 O 0 OPEN .... 別の診断ツールが man:btsockstat[1] です。 これは man:netstat[1] と同様の作業を、Bluetooth ネットワークに関するデータ構造についての行います。 下記の例は上の man:l2control[8] と同じ論理的な接続を示します。 [source,shell] .... % btsockstat Active L2CAP sockets PCB Recv-Q Send-Q Local address/PSM Foreign address CID State c2afe900 0 0 00:02:72:00:d4:1a/3 00:07:e0:00:0b:ca 66 OPEN Active RFCOMM sessions L2PCB PCB Flag MTU Out-Q DLCs State c2afe900 c2b53380 1 127 0 Yes OPEN Active RFCOMM sockets PCB Recv-Q Send-Q Local address Foreign address Chan DLCI State c2e8bc80 0 250 00:02:72:00:d4:1a 00:07:e0:00:0b:ca 3 6 OPEN .... === RFCOMM プロトコル RFCOMM プロトコルは L2CAP プロトコルを介してシリアルポートのエミュレーションを提供します。 このプロトコルは ETSI (訳注: 欧州電気通信標準化機構) 標準 TS 07.10 に基づいています。 RFCOMM プロトコルは、単純な伝送プロトコルに RS-232 (EIATIA-232-E) シリアルポートの 9 本の結線をエミュレートする項目を加えたものです。 RFCOMM プロトコルは、二つの Bluetooth デバイス間で、最大 60 までの同時接続 (RFCOMM チャネル) に対応しています。 RFCOMM の目的から、完全な通信経路は、異なるデバイス上 (通信の端点) で動作している二つのアプリケーションと、 その間の通信セグメントを含んでいます。RFCOMM は、それが動いているデバイスのシリアルポートを利用するアプリケーションをカバーするためのものです。 通信セグメントはあるデバイスから他のデバイスへの Bluetooth リンクです (直接接続)。 RFCOMM は直接接続している場合のデバイス間の接続、 またはネットワークの場合のデバイスとモデムの間の接続にだけ関係があります。 RFCOMM は、一方が Bluetooth 無線技術で通信し、 もう一方で有線インタフェースを提供するモジュールのような、 他の構成にも対応できます。 FreeBSD では RFCOMM プロトコルは Bluetooth ソケット層に実装されています。 === デバイスのペアリング デフォルトでは Bluetooth 通信は認証されておらず、 すべてのデバイスが他のすべてのデバイスと通信できます。 Bluetooth デバイス (たとえば携帯電話) は特定のサービス (たとえばダイアルアップサービス) を提供するために、 認証を要求することも選択できます。 Bluetooth 認証は通常 _PIN コード_ で行われます。 PIN コードは最長 16 文字のアスキー文字列です。 ユーザは両デバイスで同じ PIN コードを入力することを要求されます。 一度 PIN コードを入力すると、 両デバイスは _リンクキー_ を作成します。 その後、リンクキーはそのデバイス自身または、 不揮発性記憶デバイス内に格納できます。 次の機会には、両デバイスは前に作成されたリンクキーを使用するでしょう。 このような手続きを__ペアリング (pairing)__ と呼びます。いずれかのデバイス上でリンクキーが失われたときには、 ペアリングをやり直さなければならないことに注意してください。 man:hcsecd[8] デーモンが Bluetooth 認証要求のすべてを扱う責任を負っています。 デフォルトの設定ファイルは [.filename]#/etc/bluetooth/hcsecd.conf# です。 PIN コードが "1234" に設定された携帯電話に関する例は以下の通りです。 [.programlisting] .... device { bdaddr 00:80:37:29:19:a4; name "Pav's T39"; key nokey; pin "1234"; } .... PIN コードには (長さを除いて) 制限はありません。 いくつかのデバイス (たとえば Bluetooth ヘッドフォン) には固定的な PIN コードが組み込まれているかもしれません。 `-d` オプションは man:hcsecd[8] デーモンがフォアグラウンドで動作するように強制するため、 何が起きているのか確認しやすくなります。 リモートデバイスがペアリングを受け取るように設定して、 リモートデバイスへの Bluetooth 接続を開始してください。 リモートデバイスはペアリングが受け入れらた、と応答して PIN コードを要求するでしょう。 [.filename]#hcsecd.conf# 内にあるのと同じ PIN コードを入力してください。 これであなたの PC とリモートデバイスがペアとなりました。 また、リモートデバイスからペアリングを開始することもできます。 以下は `hcsecd` の出力例です。 [.programlisting] .... hcsecd[16484]: Got Link_Key_Request event from 'ubt0hci', remote bdaddr 0:80:37:29:19:a4 hcsecd[16484]: Found matching entry, remote bdaddr 0:80:37:29:19:a4, name 'Pav's T39', link key doesn't exist hcsecd[16484]: Sending Link_Key_Negative_Reply to 'ubt0hci' for remote bdaddr 0:80:37:29:19:a4 hcsecd[16484]: Got PIN_Code_Request event from 'ubt0hci', remote bdaddr 0:80:37:29:19:a4 hcsecd[16484]: Found matching entry, remote bdaddr 0:80:37:29:19:a4, name 'Pav's T39', PIN code exists hcsecd[16484]: Sending PIN_Code_Reply to 'ubt0hci' for remote bdaddr 0:80:37:29:19:a4 .... === サービスディスカバリプロトコル (SDP) サービスディスカバリプロトコル (SDP) は、 クライアントアプリケーションが、 サーバアプリケーションが提供するサービスの存在とその属性を発見する手段を提供します。 サービスの属性には提示されているサービスのタイプまたはクラス、 および、サービスを利用するのに必要な仕組みまたはプロトコルの情報が含まれます。 SDP には SDP サーバと SDP クライアント間の通信が含まれます。 SDP サーバは、サーバに関連づけられたサービスの特性について記述しているサービスレコードの一覧を維持しています。 各サービスレコードにはそれぞれ 1 つのサービスの情報が書かれています。 クライアントは SDP リクエストを出すことによって、 SDP サーバが維持しているサービスレコードから情報を検索できます。 クライアントまたはクライアントに関連づけられたアプリケーションがサービスを利用することにしたら、 サービスを利用するためには、 サービスプロバイダへの接続を別途開かなければなりません。 SDP はサービスとそれらの属性を発見するための仕組みを提供しますが、 そのサービスを利用するための仕組みは提供しません。 通常 SDP クライアントは希望するサービスの特性に基づいてサービスを検索します。 しかしながら、サービスに関する事前の情報なしに、 どのタイプのサービスが SDP サーバのサービスレコードに記述されているか知ることが望ましいことがあります。 この、提供されている任意のサービスを閲覧する手順を、 _ブラウジング (browsing)_ と呼びます。 現在のところ Bluetooth SDP サーバおよびクライアントは、 http://www.geocities.com/m_evmenkin/[ここ] からダウンロードできる第三者パッケージ sdp-1.5 で実装されています。 sdptool はコマンドラインの SDP クライアントです。 次の例は SDP ブラウズの問い合わせ方法を示しています。 [source,shell] .... # sdptool browse 00:80:37:29:19:a4 Browsing 00:80:37:29:19:A4 ... Service Name: Dial-up Networking Protocol Descriptor List: "L2CAP" (0x0100) "RFCOMM" (0x0003) Channel: 1 Service Name: Fax Protocol Descriptor List: "L2CAP" (0x0100) "RFCOMM" (0x0003) Channel: 2 Service Name: Voice gateway Service Class ID List: "Headset Audio Gateway" (0x1112) "Generic Audio" (0x1203) Protocol Descriptor List: "L2CAP" (0x0100) "RFCOMM" (0x0003) Channel: 3 .... ... 等々。 それぞれのサービスは属性の一覧 (たとえば RFCOMM チャネル) を持っていることに注意してください。サービスによっては、 属性のリストの一部についてメモをとっておく必要があるかもしれません。 Bluetooth 実装のいくつかは、サービスブラウジングに対応しておらず、 空の一覧を返してくるかもしれません。この場合、 特定のサービスを検索をすることは可能です。下記の例は OBEX オブジェクトプッシュ (OPUSH) サービスを検索する方法です。 [source,shell] .... # sdptool search --bdaddr 00:07:e0:00:0b:ca OPUSH .... FreeBSD 上における Bluetooth クライアントへのサービス提供は sdpd サーバが行います。 [source,shell] .... # sdpd .... sdptool は、ローカル SDP サーバにサービスを登録するのにも用いられます。 下記の例は PPP (LAN) サービスを備えたネットワークアクセスを登録する方法を示しています。 一部のサービスでは属性 (たとえば RFCOMM チャネル) を要求することに注意してください。 [source,shell] .... # sdptool add --channel=7 LAN .... ローカル SDP サーバに登録されたサービスの一覧は SDP ブラウザの問い合わせを "特別な" BD_ADDR に送ることで得られます。 [source,shell] .... # sdptool browse ff:ff:ff:00:00:00 .... === ダイアルアップネットワーク (DUN) および PPP (LAN) を用いたネットワークアクセスプロファイル ダイアルアップネットワーク (DUN) プロファイルはほとんどの場合、 モデムや携帯電話とともに使用されます。 このプロファイルが対象とする場面は以下のものです。 * コンピュータから携帯電話またはモデムを、 ダイアルアップインターネットアクセスサーバへの接続、 または他のダイアルアップサービスを利用するための無線モデムとして使うこと * データ呼び出しを受けるための、 コンピュータによる携帯電話またはモデムの使用 PPP (LAN) によるネットワークアクセスプロファイルは、 次の状況で利用できます。 * 単一の Bluetooth デバイスへの LAN アクセス * マルチ Bluetooth デバイスへの LAN アクセス * (シリアルケーブルエミュレーション上の PPP ネットワーク接続を使用した) PC から PC への接続 FreeBSD ではどちらのプロファイルも man:ppp[8] と man:rfcomm_pppd[8] (RFCOMM Bluetooth 接続を PPP が制御可能なように変換するラッパ) で実装されています。 いずれかのプロファイルが使用可能となる前に、 [.filename]#/etc/ppp/ppp.conf# 内に新しい PPP ラベルが作成されていなければなりません。 例については、 man:rfcomm_pppd[8] のマニュアルページを参照してください。 次の例では、DUN RFCOMM チャネル上で BD_ADDR が 00:80:37:29:19:a4 のリモートデバイスへの RFCOMM 接続を開くのに man:rfcomm_pppd[8] が使われます。実際の RFCOMM チャネル番号は SDP を介してリモートデバイスから得ます。 手動で RFCOMM チャネルを指定することもでき、その場合 man:rfcomm_pppd[8] は SDP 問い合わせを実行しません。 リモートデバイス上の RFCOMM チャネルを見つけるには、 sdptool を使ってください。 [source,shell] .... # rfcomm_pppd -a 00:80:37:29:19:a4 -c -C dun -l rfcomm-dialup .... PPP (LAN) サービスでネットワークアクセスを提供するためには、 sdpd サーバが動いていなければなりません。 これはローカル SDP サーバに LAN サービスを登録するのにも必要です。 LAN サービスは RFCOMM チャネル属性を必要とすることに注意してください。 [.filename]#/etc/ppp/ppp.conf# ファイル内に LAN クライアントの新しいエントリを作成しなければなりません。 例については man:rfcomm_pppd[8] のマニュアルページを参照してください。 最後に、RFCOMM PPP サーバが実行され、 ローカル SDP サーバに登録されているのと同じ RFCOMM チャネルで待ち受けていなければなりません。 次の例は RFCOMM PPP サーバを起動する方法を示しています。 [source,shell] .... # rfcomm_pppd -s -C 7 -l rfcomm-server .... === OBEX プッシュ (OPUSH) プロファイル OBEX はモバイルデバイス間で広く使われている単純なファイル転送プロトコルです。 これは主に赤外線通信で利用されており、ノートパソコンや PDA 間の汎用的なファイル転送、および PIM アプリケーションを搭載した携帯電話その他のデバイス間で名刺やカレンダーエントリを転送するのに用いられます。 OBEX サーバおよびクライアントは、 http://www.geocities.com/m_evmenkin/[ここ] からダウンロードできる obexapp-1.0 という第三者のパッケージとして実装されています。 このパッケージは openobex ライブラリ (上記の obexapp に含まれます) および package:devel/glib12[] port を必要とします。 なお、obexapp はルート権限を必要としません。 OBEX クライアントは OBEX サーバとの間でオブジェクトを渡したり (プッシュ) および受け取ったり (プル) するのに使用されます。 オブジェクトは、たとえば名刺や予定などになります。 OBEX クライアントは RFCOMM チャネル番号を SDP によってリモートデバイスから得ることができます。 これは RFCOMM チャネル番号の代わりにサービス名を指定することによって行うことができます。 対応しているサービス名は IrMC, FTRN および OPUSH です。 RFCOMM チャネルを番号で指定することもできます。 下記は、デバイス情報オブジェクトを携帯電話から受け取り、 新しいオブジェクト (名刺) が携帯電話に渡される場合の OBEX セッションの例です。 [source,shell] .... % obexapp -a 00:80:37:29:19:a4 -C IrMC obex> get get: remote file> telecom/devinfo.txt get: local file> devinfo-t39.txt Success, response: OK, Success (0x20) obex> put put: local file> new.vcf put: remote file> new.vcf Success, response: OK, Success (0x20) obex> di Success, response: OK, Success (0x20) .... OBEX プッシュサービスを提供するためには、 sdpd サーバが実行されていなければなりません。 また OPUSH サービスをローカル SDP サーバに登録することも必要です。 なお、OPUSH サービスには RFCOMM チャネル属性が必要です。 渡されるオブジェクトをすべて格納するルートフォルダを作成しなければいけません。 ルートフォルダのデフォルトパスは [.filename]#/var/spool/obex# です。 最後に OBEX サーバが実行され、 ローカル SDP サーバに登録されているのと同じ RFCOMM チャネルで待ち受けていなければなりません。 下記の例は OBEX サーバの起動方法を示します。 [source,shell] .... # obexapp -s -C 10 .... === シリアルポート (SP) プロファイル シリアルポート (SP) プロファイルは Bluetooth デバイスが RS232 (または同様の) シリアルケーブルエミュレーションを行えるようにします。 このプロファイルが対象とする場面は、 レガシーアプリケーションが、仮想シリアルポート抽象を介して Bluetooth をケーブルの代替品として使うところです。 man:rfcomm_sppd[1] ユーティリティはシリアルポートプロファイルを実装します。 Pseudo tty が仮想シリアルポート抽象概念として用いられます。 下記の例はリモートデバイスのシリアルポートサービスへ接続する方法を示します。 なお、RFCOMM チャネルを指定する必要はありません。- man:rfcomm_sppd[1] は SDP を介してリモートデバイスからその情報を得ることができます。 これを上書きしたい場合にはコマンドラインで RFCOMM チャネルを指定してください。 [source,shell] .... # rfcomm_sppd -a 00:07:E0:00:0B:CA -t /dev/ttyp6 rfcomm_sppd[94692]: Starting on /dev/ttyp6... .... 接続された pseudo tty はシリアルポートとして利用することができます。 [source,shell] .... # cu -l ttyp6 .... === トラブルシューティング ==== リモートデバイスが接続できません 古い Bluetooth デバイスのなかにはロールスイッチング (role switching) に対応していないものがあります。 デフォルトでは FreeBSD が新しい接続を受け付けるときに、 ロールスイッチを実行してマスタになろうとします。 これに対応していないデバイスは接続できないでしょう。 なお、ロールスイッチングは新しい接続が確立されるときに実行されるので、 ロールスイッチングに対応しているかどうかリモートデバイスに問い合わせることはできません。 ローカル側でロールスイッチングを無効にする HCI オプションがあります。 [source,shell] .... # hccontrol -n ubt0hci write_node_role_switch 0 .... ==== 何かがうまくいっていないみたいです。 何が実際に起こっているか確認できますか? できます。 http://www.geocities.com/m_evmenkin/[ここ] からダウンロードできる第三者パッケージ hcidump-1.5 を使ってください。 hcidump ユーティリティは man:tcpdump[1] と似ています。 これはターミナル上の Bluetooth パケットの内容の表示および Bluetooth パケットをファイルにダンプするのに使えます。 [[network-bridging]] == ブリッジ === はじめに IP サブネットを作成して、 それらのセグメントをルータを使って接続することなしに、 (Ethernet セグメントのような) 一つの物理ネットワークを二つのネットワークセグメントに分割することはとても有効な場合があります。 この方法で二つのネットワークを繋ぐデバイスは "ブリッジ" と呼ばれます。 二つのネットワークインタフェースカードを持つ FreeBSD システムは、ブリッジとして動作することができます。 ブリッジは、各ネットワークインタフェイスに繋がるデバイスの MAC 層のアドレス (Ethernet アドレス) を記憶することにより動作します。 ブリッジはトラフィックの送信元と受信先が異なったネットワーク上にある場合にのみトラフィックを転送します。 多くの点で、ブリッジはポート数の少ない Ethernet スイッチのようなものといえます。 === ブリッジがふさわしい状況 今日ブリッジが活躍する場面は大きく分けて二つあります。 ==== トラフィックの激しいセグメント ひとつは、 物理ネットワークセグメントがトラフィック過剰になっているが、 なんらかの理由によりネットワークをサブネットに分け、 ルータで接続することができない場合です。 編集部門と製作部門がおなじサブネットに同居している新聞社を例に考えてみましょう。 編集部門のユーザはファイルサーバとして全員サーバ `A` を利用し、 製作部門のユーザはサーバ `B` を利用します。 すべてのユーザを接続するのには Ethernet が使われており、 高負荷となったネットワークは遅くなってしまいます。 もし編集部門のユーザを一つのネットワークセグメントに分離することができ、 製作部門のユーザも同様にできるのなら、 二つのネットワークセグメントをブリッジで繋ぐことができます。 ブリッジの "反対" 側へ向かうネットワークトラフィックだけが転送され、 各ネットワークセグメントの混雑は緩和されます。 ==== パケットフィルタ/帯域制御用ファイアウォール もうひとつはネットワークアドレス変換 (NAT) を使わずにファイアウォール機能を利用したい場合です。 ここでは DSL もしくは ISDN で ISP に接続している小さな会社を例にとってみましょう。 この会社は ISP からグローバル IP アドレスを 13 個割り当てられており、ネットワーク上には 10 台の PC が存在します。 このような状況では、サブネット化にまつわる問題から、 ルータを用いたファイアウォールを利用することは困難です。 ブリッジを用いたファイアウォールなら、 IP アドレスの問題を気にすること無く、 DSL/ISDN ルータの下流側に置くように設定できます。 === ブリッジを設定する ==== ネットワークインタフェースカードの選択 ブリッジを利用するには少なくとも 2 枚のネットワークカードが必要です。 残念なことに FreeBSD 4.0 ではすべてのネットワークインタフェースカードがブリッジ機能に対応しているわけではありません。 カードに対応しているかどうかについては man:bridge[4] を参照してください。 以下に進む前に、 二枚のネットワークカードをインストールしてテストしてください。 ==== カーネルコンフィグレーションの変更 カーネルでブリッジ機能を有効にするには [.programlisting] .... options BRIDGE .... という行をカーネルコンフィグレーションファイルに追加して カーネルを再構築してください。 ==== ファイアウォール対応 ファイアウォールとしてブリッジを利用しようとしている場合には `IPFIREWALL` オプションも指定する必要があります。 ブリッジをファイアウォールとして設定する際の一般的な情報に関しては、 ファイアウォールの章 を参照してください。 IP 以外のパケット (ARP など) がブリッジを通過するようにするためには、 ファイアウォール用オプションを設定しなければなりません。 このオプションは `IPFIREWALL_DEFAULT_TO_ACCEPT` です。この変更により、 デフォルトではファイアウォールがすべてのパケットを受け入れるようになることに注意してください。 この設定を行う前に、 この変更が自分のルールセットにどのような影響をおよぼすかを把握しておかなければなりません。 ==== 帯域制御機能 ブリッジで帯域制御機能を利用したい場合、 カーネルコンフィグレーションで `DUMMYNET` オプションを加える必要があります。 詳しい情報に関しては man:dummynet[4] を参照してください。 === ブリッジを有効にする ブリッジを有効にするには、 [.filename]#/etc/sysctl.conf# に以下の行を加えてください。 [.programlisting] .... net.link.ether.bridge=1 .... 指定したインタフェースでブリッジを可能にするには以下を加えてください。 [.programlisting] .... net.link.ether.bridge_cfg=if1,if2 .... (_if1_ および _if2_ は二つのネットワークインタフェースの名前に置き換えてください)。 ブリッジを経由したパケットを man:ipfw[8] でフィルタしたい場合には、 以下の行も付け加える必要があります [.programlisting] .... net.link.ether.bridge_ipfw=1 .... FreeBSD 5.2-RELEASE 以降では、かわりに以下の行を使用してください。 [.programlisting] .... net.link.ether.bridge.enable=1 net.link.ether.bridge.config=if1,if2 net.link.ether.bridge.ipfw=1 .... === その他の情報 ネットワークからブリッジに man:telnet[1] したい場合、 ネットワークカードの一つに IP アドレスを割り当てるのが正しいです。 一般的に、両方のカードに IP アドレスを割り当てるのはよい考えではないとされています。 ネットワーク内に複数のブリッジを設置する場合、 任意のワークステーション間で一つ以上の経路を持つことはできません。 技術的には、 これはスパニングツリーのリンク制御はサポートされていない、 ということを意味します。 ブリッジは、man:ping[8] にかかる時間を遅らせることがあります。特に、 一方のセグメントからもう一方へのトラフィックでそうなります。 [[network-nfs]] == NFS FreeBSD がサポートしている多くのファイルシステムの中には、 NFS とも呼ばれているネットワークファイルシステムがあります。 NFS はあるマシンから他のマシンへと、 ネットワークを通じてディレクトリとファイルを共有することを可能にします。 NFS を使うことで、 ユーザやプログラムはリモートシステムのファイルを、 それがローカルファイルであるかのようにアクセスすることができます。 NFS が提供可能な最も特筆すべき利点いくつかは以下のものです。 * 一般的に使われるデータを単一のマシンに納めることができ、 ユーザはネットワークを通じてデータにアクセスできるため、 ローカルワークステーションが使用するディスク容量が減ります。 * ネットワーク上のすべてのマシンに、 ユーザが別々にホームディレクトリを持つ必要がありません。 NFS サーバ上にホームディレクトリが設定されれば、 ネットワークのどこからでもアクセス可能です。 * フロッピーディスクや CDROM ドライブ、 ZIP ドライブなどのストレージデバイスを、 ネットワーク上の他のマシンで利用することができます。 ネットワーク全体のリムーバブルドライブの数を減らせるかもしれません。 === NFS はどのように動作するのか NFS は最低二つの主要な部分、 サーバと一つ以上のクライアントからなります。 クライアントはサーバマシン上に格納されたデータにリモートからアクセスします。 これが適切に機能するには、 いくつかのプロセスが設定されて実行されていなければなりません。 [NOTE] ==== FreeBSD 5.X では `portmap` ユーティリティは rpcbind ユーティリティに置き換わりました。 したがって FreeBSD 5.X では、ユーザは下記の例で、 portmap の例のすべてを `rpcbind` に置き換える必要があります。 ==== サーバは以下のデーモンを動作させなければなりません。 [.informaltable] [cols="1,1", frame="none", options="header"] |=== | デーモン | 説明 |nfsd |NFS クライアントからのリクエストを処理する NFS デーモン |mountd |man:nfsd[8] から渡されたリクエストを実際に実行する NFS マウントデーモン |portmap |NFS サーバの利用しているポートを NFS クライアントから取得できるようにするためのポートマッパデーモン |=== クライアント側では nfsiod というデーモンも実行できます。 nfsiod デーモンは NFS サーバからのリクエストを処理します。 これは任意であり、性能を改善しますが、 通常の正しい動作には必要としません。詳細については man:nfsiod[8] マニュアルページを参照してください。 [[network-configuring-nfs]] === NFS の設定 NFS の設定は比較的素直な工程です。 動かさなければならないプロセスは [.filename]#/etc/rc.conf# ファイルを少し変更すれば起動時に実行させられます。 NFS サーバでは [.filename]#/etc/rc.conf# ファイルの中で、 以下のオプションが設定されていることを確かめてください。 [.programlisting] .... portmap_enable="YES" nfs_server_enable="YES" mountd_flags="-r" .... `mountd` は NFS サーバが有効になっていれば、 自動的に実行されます。 クライアント側では [.filename]#/etc/rc.conf# 内に以下の設定があることを確認してください。 [.programlisting] .... nfs_client_enable="YES" .... [.filename]#/etc/exports# ファイルは NFS サーバがどのファイルシステムをエクスポート (ときどき "共有" と呼ばれます) するのかを指定します。 [.filename]#/etc/exports# ファイル中の各行は、 エクスポートするファイルシステム、 およびそのファイルシステムにアクセスできるマシンを指定します。 ファイルシステムにアクセスできるマシンとともに、 アクセスオプションも指定できます。 このファイルで指定できるオプションはたくさんありますが、 ここではほんの少しだけ言及します。man:exports[5] マニュアルページを読めば、 他のオプションは簡単にみつけられるでしょう。 いくつか [.filename]#/etc/exports# の設定例を示します。 以下の例はファイルシステムのエクスポートの考え方を示しますが、 あなたの環境とネットワーク設定に応じて設定は少し変わるでしょう。 たとえば次の行は [.filename]#/cdrom# ディレクトリを、サーバと同じドメイン名か (そのため、いずれもドメイン名がありません)、 [.filename]#/etc/hosts# に記述されている三つの例となるマシンに対してエクスポートします。 `-ro` フラグは共有されるファイルシステムを読み込み専用にします。 このフラグにより、 リモートシステムは共有されたファイルシステムに対して何の変更も行えなくなります。 [.programlisting] .... /cdrom -ro host1 host2 host3 .... 以下の設定は IP アドレスで指定した 3 つのホストに対して [.filename]#/home# をエクスポートします。 この設定はプライベートネットワークで DNS が設定されていない場合に便利でしょう。 内部のホスト名に対して [.filename]#/etc/hosts# を設定するという手段もあります。 詳細については man:hosts[5] を参照してください。 `-alldirs` フラグはサブディレクトリがマウントポイントとなることを認めます。 言い替えると、これはサブディレクトリをマウントしませんが、 クライアントが要求するか、 または必要とするディレクトリだけをマウントできるようにします。 [.programlisting] .... /home -alldirs 10.0.0.2 10.0.0.3 10.0.0.4 .... 以下の設定は、サーバとは異なるドメイン名の 2 台のクライアントがアクセスできるように [.filename]#/a# をエクスポートします。 `-maproot=root` フラグは、リモートシステムの `root` ユーザが、 エクスポートされたファイルシステムに `root` として書き込むことを許可します。 `-maproot=root` フラグが無ければ、 リモートマシンの `root` 権限を持っていても、 共有されたファイルシステム上のファイルを変更することはできないでしょう。 [.programlisting] .... /a -maproot=root host.example.com box.example.org .... クライアントがエクスポートされたファイルシステムにアクセスするためには、 そうする権限が与えられていなければなりません。 [.filename]#/etc/exports# ファイルに クライアントが含まれているかどうか確認してください。 [.filename]#/etc/exports# ファイルでは、 それぞれの行が一つのファイルシステムを一つのホストにエクスポートすることを表します。 リモートホストはファイルシステム毎に一度だけ指定することができ、 それに加えて一つのデフォルトエントリを置けます。たとえば [.filename]#/usr# が単一のファイルシステムであると仮定します。 次の [.filename]#/etc/exports# は無効です。 [.programlisting] .... /usr/src client /usr/ports client .... 単一のファイルシステムである [.filename]#/usr# は、2 行に渡って、同じホスト `client` へエクスポートされています。 この場合、正しい書式は次のとおりです。 [.programlisting] .... /usr/src /usr/ports client .... あるホストにエクスポートされるある 1 つのファイルシステムのプロパティは、 1 行ですべて指定しなければなりません。 クライアントの指定のない行は、単一のホストとして扱われます。 これはファイルシステムをエクスポートできる方法を制限しますが、 多くの場合これは問題になりません。 下記は、 [.filename]#/usr# および [.filename]#/exports# がローカルファイルシステムである場合の、 有効なエクスポートリストの例です。 [.programlisting] .... # Export src and ports to client01 and client02, but only # client01 has root privileges on it /usr/src /usr/ports -maproot=root client01 /usr/src /usr/ports client02 # The client machines have root and can mount anywhere # on /exports. Anyone in the world can mount /exports/obj read-only /exports -alldirs -maproot=root client01 client02 /exports/obj -ro .... 変更が有効となるように、 [.filename]#/etc/exports# が変更されたら `mountd` を再起動しなければなりません。 これは `mountd` プロセスに HUP シグナルを送ることで実行できます。 [source,shell] .... # kill -HUP `cat /var/run/mountd.pid` .... 他には、再起動すれば、FreeBSD はすべてを適切に設定します。 しかしながら、再起動は必須ではありません。 `root` 権限で以下のコマンドを実行すれば、すべてが起動するでしょう。 NFS サーバでは [source,shell] .... # portmap # nfsd -u -t -n 4 # mountd -r .... NFS クライアントでは [source,shell] .... # nfsiod -n 4 .... これでリモートのファイルシステムを実際にマウントする準備がすべてできました。 この例では、サーバの名前は `server` で、 クライアントの名前は `client` とします。 リモートファイルシステムを一時的にマウントするだけ、 もしくは設定をテストするだけなら、クライアント上で `root` 権限で以下のコマンドを実行するだけです。 [source,shell] .... # mount server:/home /mnt .... これで、サーバの [.filename]#/home# ディレクトリが、クライアントの [.filename]#/mnt# にマウントされます。もしすべてが正しく設定されていれば、 クライアントの /mnt に入り、 サーバにあるファイルすべてを見れるはずです。 リモートファイルシステムを起動のたびに自動的にマウントしたいなら、 ファイルシステムを [.filename]#/etc/fstab# ファイルに追加してください。 例としてはこのようになります。 [.programlisting] .... server:/home /mnt nfs rw 0 0 .... man:fstab[5] マニュアルページに利用可能なオプションがすべて掲載されています。 === 実用的な使い方 NFS には実用的な使用法がいくつもあります。 ここで典型的な使用法をいくつか紹介しましょう。 * 何台ものマシンで CDROM などのメディアを共有するように設定します。 これは安上がりで、たいていは、 複数のマシンにソフトウェアをインストールするのにより便利な方法です。 * 大規模なネットワークでは、 すべてのユーザのホームディレクトリを格納するメイン NFS サーバを構築すると、ずっと便利でしょう。 どのワークステーションにログインしても、 ユーザがいつでも同じホームディレクトリを利用できるように、 これらのホームディレクトリはネットワークに向けてエクスポートされます。 * 何台ものマシンで [.filename]#/usr/ports/distfiles# ディレクトリを共有できます。こうすると、 何台ものマシン上に port をインストールする必要がある時に、 それぞれのマシンでソースコードをダウンロードすることなく、 直ちにソースにアクセスできます。 [[network-amd]] === amd による自動マウント man:amd[8] (自動マウントデーモン) は、 ファイルシステム内のファイルまたはディレクトリがアクセスされると、 自動的にリモートファイルシステムをマウントします。 また、一定の間アクセスされないファイルシステムは amd によって自動的にアンマウントされます。 amd を使用することは、通常 [.filename]#/etc/fstab# 内に記述する恒久的なマウントに対する、 単純な代替案となります。 amd はそれ自身を NFS サーバとして [.filename]#/host# および [.filename]#/net# ディレクトリに結びつけることによって動作します。 このディレクトリ内のどこかでファイルがアクセスされると、 amd は対応するリモートマウントを調べて、 自動的にそれをマウントします。 [.filename]#/net# が、エクスポートされたファイルシステムを IP アドレスで指定してマウントするのに利用される一方で、 [.filename]#/host# は、エクスポートされたファイルシステムをリモートホスト名で指定してマウントするのに利用されます。 [.filename]#/host/foobar/usr# 内のファイルにアクセスすると、 amd はホスト `foobar` からエクスポートされた [.filename]#/usr# をマウントします。 .amd によるエクスポートされたファイルシステムのマウント [example] ==== `showmount` コマンドを用いて、 リモートホストのマウントで利用できるものが見られます。 たとえば、`foobar` と名付けられたホストのマウントを見るために次のように利用できます。 [source,shell] .... % showmount -e foobar Exports list on foobar: /usr 10.10.10.0 /a 10.10.10.0 % cd /host/foobar/usr .... ==== 例のように `showmount` はエクスポートとして [.filename]#/usr# を表示します。 [.filename]#/host/foobar/usr# にディレクトリを変更すると、 amd はホスト名 `foobar` を解決し、お望みのエクスポートをマウントしようと試みます。 amd は [.filename]#/etc/rc.conf# 内に次の行を記述すれば、 起動スクリプトによって起動されます。 [.programlisting] .... amd_enable="YES" .... さらに `amd_flags` オプションによって amd にフラグをカスタマイズして渡せます。デフォルトでは `amd_flags` は次のように設定されています。 [.programlisting] .... amd_flags="-a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map" .... [.filename]#/etc/amd.map# ファイルは、 エクスポートがマウントされるデフォルトオプションを決定します。 [.filename]#/etc/amd.conf# ファイルは、 amd のより高度な機能の一部を設定します。 詳細については man:amd[8] および man:amd.conf[8] マニュアルページを参照してください。 [[network-nfs-integration]] === 他のシステムとの統合についての問題 ISA バス用のイーサネットアダプタの中には性能が悪いため、 ネットワーク、特に NFS で深刻な問題がおきるものがあります。 これは FreeBSD に限ったことではありませんが FreeBSD でも起こり得ます。 この問題は (FreeBSD を使用した) PC がシリコングラフィックス社やサン・マイクロシステムズ社などの高性能なワークステーションにネットワーク接続されている場合に頻繁に起こります。 NFS マウントはうまく動作するでしょう。 また、いくつかの操作もうまく動作するかもしれませんが、 他のシステムに対する要求や応答は続いていても、 突然サーバがクライアントの要求に対して応答しなくなります。これは、 クライアントが FreeBSD か上記のワークステーションであるときにクライアント側に起きる現象です。 多くのシステムでは、いったんこの問題が現われると、 行儀良くクライアントを終了する手段はありません。 NFS がこの状態に陥ってしまうと正常に戻すことはできないため、 多くの場合クライアントをリセットすることが唯一の解決法となります。 "正しい" 解決法は、より高性能のイーサネットアダプタを FreeBSD システムにインストールすることですが、 満足に動作させる簡単な方法があります。 FreeBSD システムが _サーバ_ になるのなら、 クライアントからのマウント時に `-w=1024` オプションをつけて下さい。FreeBSD システムが _クライアント_ になるのなら、 NFS ファイルシステムを `-r=1024` オプションつきでマウントして下さい。 これらのオプションは自動的にマウントをおこなう場合には クライアントの [.filename]#fstab# エントリの 4 番目のフィールドに指定してもよいですし、 手動マウントの場合は mount コマンドの `-o` パラメータで指定してもよいでしょう。 NFS サーバとクライアントが別々のネットワーク上にあるような場合、 これと間違えやすい他の問題が起きることに注意して下さい。 そのような場合は、ルータが必要な UDP 情報をきちんとルーティングしているかを確かめて下さい。 していなければ、たとえあなたが何をしようと解決できないでしょう。 次の例では `fastws` は高性能ワークステーションのホスト (インタフェース) 名で、 `freebox` は低性能のイーサネットアダプタを備えた FreeBSD システムのホスト (インタフェース) 名です。 また [.filename]#/sharedfs# はエクスポートされる NFS ファイルシステムであり (man:exports[5] を参照) 、 [.filename]#/project# はエクスポートされたファイルシステムの、 クライアント上のマウントポイントとなります。 すべての場合において、アプリケーションによっては `hard` や `soft`, `bg` といった追加オプションがふさわしいかもしれないことに注意して下さい。 クライアント側 FreeBSD システム (`freebox`) の [.filename]#/etc/fstab# の例は以下のとおりです。 [.programlisting] .... fastws:/sharedfs /project nfs rw,-r=1024 0 0 .... `freebox` 上で手動で mount コマンドを実行する場合は次のようにして下さい。 [source,shell] .... # mount -t nfs -o -r=1024 fastws:/sharedfs /project .... サーバ側 FreeBSD システム (`fastws`) の [.filename]#/etc/fstab# の例は以下のとおりです。 [.programlisting] .... freebox:/sharedfs /project nfs rw,-w=1024 0 0 .... `fastws` 上で手動で mount コマンドで実行する場合は次のようにして下さい。 [source,shell] .... # mount -t nfs -o -w=1024 freebox:/sharedfs /project .... 近いうちにどのような 16 ビットのイーサネットアダプタでも、上記の読み出し、 書き込みサイズの制限なしで操作できるようになるでしょう。 失敗が発生したとき何が起きているか関心のある人に、 なぜ回復不可能なのかも含めて説明します。NFS は通常 (より小さいサイズへ分割されるかもしれませんが) 8 K の "ブロック" サイズで動作します。 イーサネットのパケットサイズは最大 1500 バイト程度なので、 上位階層のコードにとっては 1 つのユニットであって、 NFS "ブロック" は複数のイーサネットパケットに分割されるものの、 上位階層のコードにとっては 1 つのユニットであって、 ユニットとして受信され、組み立て直され、 _肯定応答_ (ACK) されなければなりません。 高性能のワークステーションは次々に NFS ユニットを構成するパケットを、 標準の許す限り間隔を詰めて次々に送り出すことができます。 小さく、容量の低いカードでは、 同じユニットの前のパケットがホストに転送される前に、 後のパケットがそれを踏みつぶしてしまいます。 このため全体としてのユニットは、再構成も肯定応答もできません。 その結果、 ワークステーションはタイムアウトして再送を試みますが、 8 K のユニット全体を再送しようとするので、 このプロセスは際限無く繰り返されてしまいます。 ユニットサイズをイーサネットのパケットサイズの 制限以下に抑えることにより、 受信した完全なイーサネットパケットについて個々に肯定応答を返せることが保証されるので、 デッドロック状態を避けられるようになります。 それでも、高性能なワークステーションが力任せに次々と PC システムにデータを送ったときには踏みつぶしが起きるかもしれません。 しかし、高性能のカードを使っていれば、NFS "ユニット" で必ずそのような踏みつぶしが起きるとは限りません。 踏みつぶしが起きたら、影響を受けたユニットは再送されて、 受信され、組み立てられ、肯定応答される十分な見込みがあります。 [[network-diskless]] == ディスクレス稼働 FreeBSD マシンはネットワークを通じて起動でき、 そして NFS サーバからマウントしたファイルシステムを使用して、 ローカルディスクなしで動作することができます。 標準の設定ファイルを変更する以上の、システムの修正は必要ありません。 必要な要素のすべてが用意されているので、 このようなシステムを設定するのは簡単です。 * ネットワークを通じてカーネルを読み込む方法は、 少なくとも二つあります。 ** PXE: Intel(R) の Preboot Execution Environment システムは、 一部のネットワークカードまたはマザーボードに組み込まれた、 スマートなブート ROM の一形態です。 詳細については man:pxeboot[8] を参照してください。 ** port の etherboot (package:net/etherboot[]) は、 ネットワークを通じてカーネルを起動する ROM 化可能なコードを提供します。 コードはネットワークカード上のブート PROM に焼き付けるか、 あるいはローカルフロッピー (ハード) ディスクドライブ、 または動作している MS-DOS(R) システムから読み込むことができます。 多くのネットワークカードに対応しています。 * サンプルスクリプト ([.filename]#/usr/shared/examples/diskless/clone_root#) はサーバ上で、 ワークステーションのルートファイルシステムの作成と維持をやり易くします。 このスクリプトは少し書き換えないといけないでしょうが、 早く取り掛かれるようにします。 * ディスクレスシステム起動を検知しサポートする標準のシステム起動ファイルが [.filename]#/etc# 内にあります。 * 必要なら、NFS ファイルまたはローカルディスクのどちらかにスワップできます。 ディスクレスワークステーションを設定する方法はいろいろあります。 多くの要素が関わっており、 その多くはローカルの状況に合わせてカスタマイズできます。下記は、 単純さと標準の FreeBSD 起動スクリプトとの互換性を強調した完全なシステムの設定を説明します。 記述されているシステムの特徴は次のとおりです。 * ディスクレスワークステーションは、 共有された読み取り専用の [.filename]##ルート##ファイルシステムと、 共有された読み取り専用の [.filename]##/usr## を使用します。 + [.filename]#ルート# ファイルシステムは、 標準的な FreeBSD (典型的にはサーバの) のルートのコピーで、 一部の設定ファイルが、ディスクレス稼働、 また場合によってはそのワークステーションに特有のもので上書きされています。 + 書き込み可能でなければならない [.filename]#ルート# の部分は man:mfs[8] ファイルシステムで覆われます。 システムが再起動するときにはすべての変更が失われるでしょう。 * カーネルは DHCP (または BOOTP) および TFTP を用いて etherboot によって読み込まれます。 [CAUTION] ==== 記述されているとおり、 このシステムは安全ではありません。 ネットワークの保護された範囲で使用されるべきであり、 他のホストから信頼されてはいけません。 ==== === セットアップの手順 ==== DHCP/BOOTP の設定 ネットワークを通じて設定を取得し、 ワークステーションを起動するために一般的に使用されるプロトコルには、 BOOTP と DHCP の 2 つがあります。 それらはワークステーションのブートストラップ時に何ヵ所かで使用されます。 * etherboot はカーネルを見つけるために DHCP (デフォルト) または BOOTP (設定オプションが必要) を使用します (PXE は DHCP を使用します) 。 * NFS ルートの場所を定めるためにカーネルは BOOTP を使用します。 BOOTP だけを使用するようにシステムを設定することもできます。 man:bootpd[8] サーバプログラムは FreeBSD のベースシステムに含まれています。 しかしながら、DHCP には BOOTP に勝る点が多々あります。 (よりよい設定ファイル、PXE が使えること、 そしてディスクレス稼働には直接関係しない多くの長所) ここでは BOOTP だけ利用する場合と、 BOOTP と DHCP を組み合わせた設定を扱います。特に ISC DHCP ソフトウェアパッケージを利用する後者の方法に重点をおきます。 ===== ISC DHCP を使用する設定 isc-dhcp サーバは、 BOOTP および DHCP リクエストの両方に答えることができます。 4.4-RELEASE の時点で isc-dhcp 3.0 はベースシステムの一部では無くなりました。 まずはじめに package:net/isc-dhcp3-server[] port または対応する package をインストールする必要があるでしょう。 ports および package に関する一般的な情報については crossref:ports[ports,アプリケーションのインストール - packages と ports] を参照してください。 isc-dhcp がインストールされると、 動作するために設定ファイルを必要とします (通常 [.filename]#/usr/local/etc/dhcpd.conf# が指定されます) 。 下記にコメントを含めた例を示します。 [.programlisting] .... default-lease-time 600; max-lease-time 7200; authoritative; option domain-name "example.com"; option domain-name-servers 192.168.4.1; option routers 192.168.4.1; subnet 192.168.4.0 netmask 255.255.255.0 { use-host-decl-names on; <.> option subnet-mask 255.255.255.0; option broadcast-address 192.168.4.255; host margaux { hardware ethernet 01:23:45:67:89:ab; fixed-address margaux.example.com; next-server 192.168.4.4;<.> filename "/tftpboot/kernel.diskless";<.> option root-path "192.168.4.4:/data/misc/diskless";<.> } } .... <.> このオプションは `host` 宣言の値を、 ディスクレスホストへのホスト名として送るように `dhcpd` に指示します。 別の方法として、ホスト宣言内に `option host-name margaux` を加えるものがあります。 <.> TFTP サーバを `next-server` ディレクティブに指定します (デフォルトは DHCP サーバと同じホストを使います)。 <.> カーネルとして etherboot が読み込むファイルを `filename` ディレクティブに指定します。 <.> ルートファイルシステムへのパスを、 通常の NFS 書式で `root-path` オプションに指定します。 ===== BOOTP を使用する設定 続けて、`bootpd` で同等のことをする設定です。 これは [.filename]#/etc/bootptab# におきます。 BOOTP を使用するために、デフォルトではない `NO_DHCP_SUPPORT` オプション付きで etherboot をコンパイルしなければならないことと、PXE は DHCP を _必要_ とすることに注意してください。 bootpd の唯一明白な利点は、 これがベースシステムに存在するということです。 [.programlisting] .... .def100:\ :hn:ht=1:sa=192.168.4.4:vm=rfc1048:\ :sm=255.255.255.0:\ :ds=192.168.4.1:\ :gw=192.168.4.1:\ :hd="/tftpboot":\ :bf="/kernel.diskless":\ :rp="192.168.4.4:/data/misc/diskless": margaux:ha=0123456789ab:tc=.def100 .... ==== Etherboot を用いるブートプログラムの準備 http://etherboot.sourceforge.net[Etherboot のウェブサイト] には主に Linux システムについて述べたlink:http://etherboot.sourceforge.net/doc/html/userman/t1.html[ 広範囲の文書] が含まれています。 しかし、それにもかかわらず有用な情報を含んでいます。 下記は FreeBSD システム上での etherboot の使用法についての概観を示します。 まずはじめに package:net/etherboot[] の package または port をインストールしなければなりません。 etherboot port は通常 [.filename]#/usr/ports/net/etherboot# にあります。 ports ツリーがシステムにインストールされている場合、 このディレクトリ内で `make` を実行すれば、よきに計らってくれます。 ports および packages に関する情報は crossref:ports[ports,アプリケーションのインストール - packages と ports] を参照してください。 ここで説明している方法では、ブートフロッピーを使用します。 他の方法 (PROM または DOS プログラム) については etherboot の文書を参照してください。 ブートフロッピーを作成するためには、 etherboot をインストールしたマシンのドライブにフロッピーディスクを挿入します。 それからカレントディレクトリを etherboot ツリー内の [.filename]#src# ディレクトリにして次のように入力します。 [source,shell] .... # gmake bin32/devicetype.fd0 .... _devicetype_ は ディスクレスワークステーションのイーサネットカードタイプに依存します。 正しい _devicetype_ を決定するために、 同じディレクトリ内の [.filename]#NIC# ファイルを参照してください。 ==== TFTP および NFS サーバの設定 TFTP サーバ上で `tftpd` を有効にする必要があります。 [.procedure] ==== . `tftpd` が提供するファイルを置くディレクトリ (たとえば [.filename]#/tftpboot#) を作成してください。 . [.filename]#/etc/inetd.conf# ファイルに以下の行を追加してください。 + [.programlisting] .... tftp dgram udp wait root /usr/libexec/tftpd tftpd -s /tftpboot .... + [NOTE] ====== 少なくとも PXE のいくつかのバージョンが TCP 版の TFTP を要求するようです。その場合 `dgram udp` を `stream tcp` に置き換えた 2 番目の行を追加してください。 ====== + . `inetd` に設定ファイルを再読み込みさせてください。 + [source,shell] .... # kill -HUP `cat /var/run/inetd.pid` .... ==== [.filename]#tftpboot# ディレクトリはサーバ上のどこにでも置けます。 その場所が [.filename]#inetd.conf# および [.filename]#dhcpd.conf# の両方に設定されていることを確かめてください。 さらに NFS を有効にして NFS サーバの適切なファイルシステムをエクスポートする必要があります。 [.procedure] ==== . この行を [.filename]#/etc/rc.conf# に追加してください。 + [.programlisting] .... nfs_server_enable="YES" .... + . 下記を [.filename]#/etc/exports# に加えることで、 ディスクレスマシンのルートディレクトリが位置するファイルシステムをエクスポートしてください (ボリュームのマウントポイントを適当に調節し、 _margaux_ をディスクレスワークステーションの名前に置き換えてください)。 + [.programlisting] .... /data/misc -alldirs -ro margaux .... + . `mountd` に設定ファイルを再読み込みさせてください。 [.filename]#/etc/rc.conf# 内で NFS をはじめて有効にする必要があったのなら、 代わりに再起動した方がよいかもしれません。 + [source,shell] .... # kill -HUP `cat /var/run/mountd.pid` .... ==== ==== ディスクレス用のカーネル構築 次のオプションを (通常のものに) 追加した、 ディスクレスクライアント用のカーネルコンフィグレーションファイルを作成してください。 [.programlisting] .... options BOOTP # Use BOOTP to obtain IP address/hostname options BOOTP_NFSROOT # NFS mount root filesystem using BOOTP info options BOOTP_COMPAT # Workaround for broken bootp daemons. .... `BOOTP_NFSV3` および `BOOTP_WIRED_TO` を利用してもよいかもしれません ([.filename]#LINT# を参照してください)。 カーネルを構築して (crossref:kernelconfig[kernelconfig,FreeBSD カーネルのコンフィグレーション] を参照)、 [.filename]#dhcpd.conf# に記述した名称で tftp ディレクトリにコピーしてください。 ==== ルートファイルシステムの準備 [.filename]#dhcpd.conf# に `root-path` として記載された ディスクレスワークステーションのためのルートファイルシステムを作成する必要があります。 これを行う最も簡単な方法は [.filename]#/usr/shared/examples/diskless/clone_root# シェルスクリプトを使用することです。 このスクリプトは、少なくともファイルシステムが作成される場所 (`DEST` 変数) を調節するために変更する必要があります。 説明についてはスクリプトの一番上にあるコメントを参照してください。 ベースシステムをどのように構築するか、 またファイルがどのようにディスクレス稼働、サブネット、 または個々のワークステーションに固有のバージョンによって、 選択的にオーバライドできるかを説明します。 また、ディスクレスな場合の [.filename]#/etc/fstab# ファイルおよび [.filename]#/etc/rc.conf# ファイルの例を示します。 [.filename]#/usr/shared/examples/diskless# 内の [.filename]#README# ファイルには、多くの興味深い背景情報が書かれています。 しかし [.filename]#diskless# ディレクトリ内の他の例と同じく、 [.filename]#clone_root# と [.filename]#/etc/rc.diskless[12]# で実際に使われているものとは異なる設定方法が説明されています。 ここに書かれている方法は [.filename]#rc# スクリプトの変更が必要になりますが、 こちらの方が気に入ったというのでなければ、 参照にとどめてください。 ==== スワップの設定 必要なら、サーバに置かれたスワップファイルに NFS 経由でアクセスできます。 [.filename]#bootptab# または [.filename]#dhcpd.conf# の正確なオプションは、 現時点では明確には文書化されていません。 下記の設定例は isc-dhcp 3.0rc11 を使用して動作したと報告されているものです。 [.procedure] ==== . [.filename]#dhcpd.conf# に下記の行を追加してください。 + [.programlisting] .... # Global section option swap-path code 128 = string; option swap-size code 129 = integer 32; host margaux { ... # Standard lines, see above option swap-path "192.168.4.4:/netswapvolume/netswap"; option swap-size 64000; } .... + これは、少なくとも FreeBSD クライアントにおいては、 DHCP/BOOTP オプションコードの 128 は NFS スワップファイルへのパスで、オプションコード 129 は KB 単位のスワップサイズだということです。 もっと古いバージョンの `dhcpd` では `option option-128 "...` という書式が受け付けられましたが、 もはや対応していません。 + 代わりに、[.filename]#/etc/bootptab# では次の書式を使います。 + `T128="192.168.4.4:/netswapvolume/netswap":T129=0000fa00` + [NOTE] ====== [.filename]#/etc/bootptab# では、スワップの大きさは 16 進数で表さなければなりません。 ====== + . NFS スワップファイルサーバ側でスワップファイルを作成します。 + [source,shell] .... # mkdir /netswapvolume/netswap # cd /netswapvolume/netswap # dd if=/dev/zero bs=1024 count=64000 of=swap.192.168.4.6 # chmod 0600 swap.192.168.4.6 .... + _192.168.4.6_ はディスクレスクライアントの IP アドレスです。 . NFS スワップファイルサーバ上で [.filename]#/etc/exports# に下記の行を追加してください。 + [.programlisting] .... /netswapvolume -maproot=0:10 -alldirs margaux .... + それから、上述したように mountd にエクスポートファイルを再読み込みさせてください。 ==== ==== 雑多な問題 ===== 読み取り専用の [.filename]#/usr# で動作させる ディスクレスワークステーションが X を起動するように設定されている場合、 xdm 設定ファイルを調整しなければならないでしょう。 これはデフォルトでエラーファイルを [.filename]#/usr# に置きます。 ===== FreeBSD ではないサーバを使用する ルートファイルシステムを提供するサーバが FreeBSD で動作していない場合、 FreeBSD マシン上でルートファイルシステムを作成し、 `tar` または `cpio` を利用して置きたい場所にコピーしなければならないでしょう。 この状況では、major/minor 整数サイズが異なっていることにより [.filename]#/dev# 内のスペシャルファイルに関する問題が時々おこります。 この問題を解決するには、非 FreeBSD サーバからディレクトリをエクスポートして、 そのディレクトリを FreeBSD マシンでマウントし、 FreeBSD マシン上で `MAKEDEV` を実行して正しいデバイスエントリを作成します (FreeBSD 5.0 およびそれ以降では、man:devfs[5] を使用してユーザに意識させずにデバイスノードを割り当てるので、 これらのバージョンでは `MAKEDEV` は必要ありません)。 [[network-isdn]] == ISDN ISDN 技術とハードウェアに関しては、 http://www.alumni.caltech.edu/~dank/isdn/[ Dan Kegel's ISDN Page] がよい参考になるでしょう。 手軽な ISDN の導入手順は以下のようになります。 * ヨーロッパ在住の方は ISDN カードの節に進んでください。 * ダイヤルアップ専用でない回線上で、 インターネットプロバイダをつかってインターネットに接続するために ISDN を使用することを第一に考えている場合は、 ターミナルアダプタの使用を考えてみてください。 この方法はもっとも柔軟性があり、 プロバイダを変更した場合の問題も少ないでしょう。 * 2 つの LAN を接続する場合や、 ISDN 専用線を使用する場合には、 スタンドアロンなルータまたはブリッジの使用を勧めます。 費用はどの解決法を選ぶかを決める重要な要因です。 以下に、最も安価な方法から、高価な方法まで順に説明していきます。 [[network-isdn-cards]] === ISDN カード FreeBSD の ISDN 実装は、パッシブカードを使用した DSS1/Q.931 (または Euro-ISDN) 標準だけに対応しています。FreeBSD 4.4 からは、ファームウェアが他の信号プロトコルにも対応している 一部のアクティブカードにも対応しました。 その中には、はじめて対応された一次群速度インタフェース (PRI) ISDN カードもあります。 isdn4bsd は IP over raw HDLC または同期 PPP を利用して他の ISDN ルータに接続できるようにします。 PPP では、カーネル PPP を man:sppp[4] ドライバを修正した `isppp` ドライバとともに利用するか、または ユーザプロセス man:ppp[8] を利用するかのどちらかになります。ユーザ man:ppp[8] を利用すると、二つ以上の ISDN B チャネルを併せて利用できます。 ソフトウェア 300 ボーモデムのような多くのユーティリティとともに、 留守番電話アプリケーションも利用可能です。 FreeBSD が対応している PC ISDN カードの数は増加しており、 ヨーロッパ全域や世界のその他多くの地域でうまく使えることが報告されています。 対応しているパッシブ ISDN カードのほとんどは Infineon (前身は Siemens) の ISAC/HSCX/IPAC ISDN チップセットを備えたカードですが、 Cologne Chip から供給されたチップを備えた ISDN カード (ISA バスのみ)、Winbond W6692 チップを備えた PCI カード、 Tiger300/320/ISAC チップセットを組み合わたカードの一部、 および AVM Fritz!Card PCI V.1.0 や AVM Fritz!Card PnP のようなベンダ独自のチップセットに基づいたカードもあります。 現在のところ、対応しているアクティブカードは AVM B1 (ISA および PCI) BRI カードと AVM T1 PCI PRI カードです。 isdn4bsd についての文書は FreeBSD システム内の [.filename]#/usr/shared/examples/isdn/# ディレクトリまたは http://www.freebsd-support.de/i4b/[isdn4bsd のウェブサイト]を参照してください。 そこにはヒントや正誤表や http://people.FreeBSD.org/~hm/[isdn4bsd ハンドブック]のような、 さらに多くの文書に対するポインタがあります。 異なる ISDN プロトコルや、現在対応されていない ISDN PC カードに対応することや、その他 isdn4bsd を拡張することに興味があるなら、{hm} に連絡してください。 isdn4bsd のインストール、設定、 そしてトラブルシューティングに関して質問があれば link:{freebsd-isdn-url}[freebsd-isdn] メーリングリストが利用可能です。 === ISDN ターミナルアダプタ ターミナルアダプタ (TA) は ISDN で、 通常の電話線におけるモデムに相当するものです。 ほとんどの TA は、標準のヘイズ AT コマンドセットを使用しているので、 単にモデムと置き換えて使うことができます。 TA は、基本的にはモデムと同じように動作しますが、 接続方法は異なり、通信速度も古いモデムよりはるかに速くなります。 crossref:ppp-and-slip[ppp,PPP] の設定を、 モデムの場合と同じように行ってください。 特にシリアル速度を使用できる最高速度に設定するのを忘れないでください。 プロバイダへの接続に TA を使用する最大のメリットは、動的 PPP を行えることです。 最近 IP アドレス空間がますます不足してきているため、 ほとんどのプロバイダは、 固定 IP アドレスを割り当てないようになっています。 ほとんどのスタンドアローンルータは、動的 IP アドレス割り当てに対応していません。 [NOTE] ==== 最近の ISDN ルータでは IP アドレスの動的割り当てに対応しているものも多いようです。 ただし制限がある場合もありますので、 詳しくはメーカに問い合わせてください。 ==== TA を使用した場合の機能や接続の安定性は、使用している PPP デーモンに完全に依存します。そのため、FreeBSD で PPP の設定が完了していれば、使用している既存のモデムを ISDN の TA に簡単にアップグレードすることができます。ただし、それまでの PPP のプログラムに問題があった場合、その問題は TA に置き換えてもそのまま残ります。 最高の安定性を求めるのであれば、 crossref:ppp-and-slip[userppp,ユーザランド PPP] ではなく、カーネル crossref:ppp-and-slip[ppp,PPP]を使用してください。 以下の TA は、FreeBSD で動作確認ずみです。 * Motorola BitSurfer および Bitsurfer Pro * Adtran 他の TA もほとんどの場合うまく動作するでしょう。TA のメーカーでは、TA がほとんどの標準モデム AT コマンドセットを受け付けるようにするよう努力しているようです。 外部 TA を使う際の最大の問題点は、 モデムの場合と同じく良いシリアルカードが必要であるということです。 シリアルデバイスの詳細と、 非同期シリアルポートと同期シリアルポートの差を理解するには、extref:{serial-uart}[FreeBSD シリアルハードウェア]チュートリアルを参照してください。 標準の PC シリアルポート (非同期) に接続された TA は 128 Kbs の接続を行っていても、最大通信速度が 115.2 Kbs に制限されてしまいます。128 Kbs の ISDN の性能を最大限に生かすためには TA を同期シリアルカードに接続しなければなりません。 内蔵 TA を購入すれば、 同期/非同期問題を回避できるとは思わないでください。内蔵 TA には、 単に標準 PC シリアルポートのチップが内蔵されているだけです。 内蔵 TA の利点といえば、 シリアルケーブルを買わなくていいということと、 電源コンセントが一つ少なくて済むということくらいでしょう。 同期カードと TA の組合せでも、スタンドアロンのルータと同程度の速度は確保できます。 さらに、386 の FreeBSD マシンと組合せると、 より柔軟な設定が可能です。 同期カード/TA を選ぶか、スタンドアロンルータを選ぶかは、 多分に宗教的な問題です。 メーリングリストでもいくつか議論がありました。議論の全容については、 link:https://www.FreeBSD.org/search/[アーカイブ] を検索してください。 === スタンドアロン ISDN ブリッジ/ルータ ISDN ブリッジあるいはルータは、 FreeBSD あるいは他の OS に特有のものでは皆目ありません。 ルーティングやブリッジング技術に関する詳細は、 ネットワークの参考書をご覧ください。 この節では、 ルータとブリッジのどちらでもあてはまるように記述します。 ローエンド ISDN ルータ/ブリッジ製品は、 価格が下がってきていることもあり、 より広く選択されるようになるでしょう。ISDN ルータは、 ローカルイーサネットネットワークに直接接続し、 自身で他のブリッジ/ルータとの接続を制御する小さな箱です。PPP や他の広く使用されているプロトコルをつかって通信するためのソフトウェアが組み込まれています。 ルータは、完全な同期 ISDN 接続を使用するため、通常の TA と比較してスループットが大幅に向上します。 ISDN ルータ/ブリッジを使用する場合の最大の問題点は、 各メーカーの製品間に相性の問題がまだ存在することです。 インターネットプロバイダとの接続を考えている場合には、 プロバイダと相談することをお勧めします。 事務所の LAN と家庭の LAN の間など、二つの LAN セグメントの間を接続しようとしている場合は、 これはもっともメンテナンスが簡単で、安くあがる解決方法です。 接続の両側の機材を購入するので、 リンクがうまくいくであろうことを保証できます。 たとえば、 家庭のコンピュータや支店のネットワークを本社のネットワークに接続するためには、 以下のような設定が使用できます。 .支店または家庭のネットワーク [example] ==== ネットワークは 10 Base 2 イーサネット ("thinnet") のバス型トポロジを用いています。ルータとネットワークの間は、 必要に応じて AUI/10BT トランシーバを使って接続してください。 image::isdn-bus.png[10 Base 2 イーサネット] 家庭/支店で一台しかコンピュータを使用しないのであれば、 クロスのツイストペアケーブルを使用して、 直接スタンドアロンルータに接続することも可能です。 ==== .本社 LAN や他の LAN [example] ==== ネットワークは 10 base T イーサネット ("Twisted Pair") のスター型トポロジを用いています。 image::isdn-twisted-pair.png[ISDN ネットワークダイアグラム] ==== ほとんどのルータ/ブリッジの大きな利点は、 別々の二つのサイトに対して、_同時_ にそれぞれ__独立した__二つの PPP 接続が可能であることです。 これは、シリアルポートを 2 つもった特定の (通常は高価な) モデルを除いて、通常の TA では対応していません。 チャネルボンディングや MPP などと混同しないでください。 たとえば、事務所で専用線 ISDN 接続を使用していて、 別の ISDN 回線を購入したくないときには大変便利な機能です。この場合、 事務所のルータは、インターネットに接続するための一つの専用線 B チャネル接続 (64 Kbs) を管理し、 別の B チャネルを他のデータ接続に使用できます。 2 つ目の B チャネルは他の場所とのダイアルイン、 ダイアルアウトに使用したり、バンド幅を増やすために、 1 つ目の B チャネルと動的に結合すること (MPPなど) ができます。 またイーサネットブリッジは、IP パケット以外も中継できます。 IPX/SPX など、使用するすべてのプロトコルを送ることが可能です。 [[network-nis]] == NIS/YP === NIS/YP とは? NIS とは Network Information Services の略で Sun Microsystems によって UNIX(R) の (もともとは SunOS(TM) の) 集中管理のために開発されました。現在では事実上の業界標準になっており、 主要な UNIX(R) ライクシステム (Solaris(TM), HP-UX, AIX(R), Linux, NetBSD, OpenBSD, FreeBSD、等々) はすべてこれをサポートしています。 NIS は元々、イエローページといっていましたが、 商標問題から Sun はその名前を変えました。 古い用語 (および yp) はまだよく見られ、使用されています。 NIS は RPC を使ったクライアント/サーバシステムです。 これを使うと NIS ドメイン内のマシン間で、 共通の設定ファイルを共有することができます。 また NIS を使うことでシステム管理者は最小限の設定データで NIS クライアントを立ち上げることができ、 1 ヶ所から設定データの追加、削除、変更が可能です。 NIS は Windows NT(R) のドメインシステムに似ています。 内部の実装は似ても似つかないものですが、 基本的な機能を対比することはできます。 === 知っておくべき用語 / プロセス NIS サーバの立ち上げや NIS クライアントの設定など、 NIS を FreeBSD に導入するにあたって、 目にするであろう用語や重要なユーザプロセスがいくつかあります。 [.informaltable] [cols="1,1", options="header"] |=== | 用語 | 説明 |NIS ドメイン名 |NIS マスタサーバとそのクライアントすべて (スレーブサーバを含む) には NIS ドメイン名がついています。 Windows NT(R) ドメイン名と同様に、NIS ドメイン名は DNS とは何の関係もありません。 |portmap |RPC (Remote Procedure Call, NIS で使用されるネットワークプロトコル) を利用するために実行しておかなければなりません。 `portmap` が動作していなければ、 NIS サーバを起動することも、 NIS クライアントとして動作させることもできません。 |ypbind |NIS クライアントを NIS サーバに "結びつけ" ます。 これは NIS ドメイン名をシステムから取得し RPC を用いてサーバに接続します。`ypbind` は NIS 環境におけるクライアントとサーバ間の通信の中枢です。 クライアントマシンの `ypbind` が停止した場合は、NIS サーバへアクセスすることができなくなります。 |ypserv |は NIS サーバでのみ実行されるべきもので、 NIS サーバプロセスそのものです。man:ypserv[8] が停止した場合、サーバはもはや NIS リクエストに応答することができなくなるでしょう (できれば、後を引き継ぐスレーブサーバがあるとよいでしょう)。 今まで使っていたサーバが機能を停止したとき、 別のサーバに再接続しに行かない NIS の実装もいくつかあります (FreeBSD のものは違います)。 そのような場合に復帰するための唯一の方法は、 サーバプロセス (あるいはサーバ全体)、もしくはクライアントの `ypbind` プロセスを再スタートすることです。 |rpc.yppasswdd |NIS マスターサーバで動かすべき、 もう一つのプロセスです。これは NIS クライアントが NIS パスワードを変更することを可能にするデーモンです。 このデーモンが動作していないときは、 ユーザは NIS マスタサーバにログインし、 そこでパスワードを変更しなければなりません。 |=== === 動作のしくみ NIS 環境にあるホストは、 マスターサーバ、スレーブサーバ、クライアントの 3 種類に分類されます。 サーバは、ホストの設定情報の中心的な情報格納庫の役割をします。 マスターサーバは元となる信頼できる情報を保持し、 スレーブサーバは冗長性を確保するためこの情報をミラーします。 そしてクライアントは、サーバから情報の提供を受けて動作します。 この方法を用いることで、数多くのファイルにある情報が共有できます。 よく NIS で共有されるのは、 [.filename]#master.passwd# や [.filename]#group#, [.filename]#hosts# といったファイルです。 クライアント上のプロセスが、 通常ならローカルのファイルにある情報を必要とするときは、 クライアントは代わりに接続している NIS サーバに問い合わせを行います。 ==== マシンの分類 * _NIS マスターサーバ_。 このサーバは Windows NT(R) で言うところのプライマリドメインコントローラにあたります。 すべての NIS クライアントで利用されるファイルを保守します。 [.filename]#passwd# や [.filename]#group#、 その他 NIS クライアントが参照するファイルは、 マスターサーバにあります。 + [NOTE] ==== 一つのマシンが一つ以上の NIS ドメインのマスターサーバになることは可能です。 しかし、ここでは比較的小規模の NIS 環境を対象としているため、 そのような場合については扱いません。 ==== * _NIS スレーブサーバ_。 Windows NT(R) のバックアップドメインコントローラに似たもので、 NIS スレーブサーバは NIS マスターサーバのデータファイルのコピーを保持します。 NIS スレーブサーバは重要な環境で必要とされる冗長性を提供し、 マスターサーバの負荷のバランスをとります。 NIS クライアントは常に最初にレスポンスを返したサーバを NIS サーバとして接続しますが、 これにはスレーブサーバも含まれます。 * _NIS クライアント_。 NIS クライアントは大部分の Windows NT(R) ワークステーションのように、ログオンに際して NIS サーバ (Windows NT(R) ワークステーションの場合は Windows NT(R) ドメインコントローラ) に接続して認証します。 === NIS/YP を使う この節では NIS 環境の立ち上げ例を取り上げます。 [NOTE] ==== この節ではあなたが FreeBSD 3.3 以降を使っているものとします。 ここで与えられる指示は _おそらく_ FreeBSD の 3.0 以降のどのバージョンでも機能するでしょうが、 それを保証するものではありません。 ==== ==== 計画を立てる あなたが大学の小さな研究室の管理人であるとしましょう。 この研究室は 15 台の FreeBSD マシンからなっていて、 現在はまだ集中管理されていません。 すなわち、各マシンは [.filename]#/etc/passwd# と [.filename]#/etc/master.passwd# を各々が持っています。 これらのファイルは手動でお互いに同期させています。 つまり現時点では、新しいユーザをあなたが追加するとき、 `adduser` を 15 ヶ所すべてで実行しなければなりません。 これは明らかに変える必要があるため、 あなたはこのうち 2 台をサーバにして NIS を導入することを決めました。 その結果、研究室の設定はこのようなものになります。 [.informaltable] [cols="1,1,1", options="header"] |=== | マシンの名前 | IP アドレス | 役割 |`ellington` |`10.0.0.2` |NIS マスタ |`coltrane` |`10.0.0.3` |NIS スレーブ |`basie` |`10.0.0.4` |教員用のワークステーション |`bird` |`10.0.0.5` |クライアントマシン |`cli[1-11]` |`10.0.0.[6-17]` |その他のクライアントマシン |=== もし NIS によるシステム管理の設定を行なうのが初めてなら、 どのようにしたいのか、 ひととおり最後まで考えてみることをお勧めします。 ネットワークの規模によらず、 いくつか決めるべきことがあるからです。 ===== NIS ドメイン名を決める ここでいうドメイン名は、今まであなたが使っていた、 いわゆる "ドメイン名" と呼んでいたものとは違います。 正確には "NIS ドメイン名" と呼ばれます。 クライアントがサーバに情報を要求するとき、 その要求には自分が属する NIS ドメインの名前が含まれています。 これは 1 つのネットワークに複数のサーバがある場合に、 どのサーバが要求を処理すれば良いかを決めるために使われます。 NIS ドメイン名とは、 関連のあるホストをグループ化するための名前である、 と考えると良いでしょう。 組織によってはインターネットのドメイン名を NIS ドメイン名に使っているところがあります。 これはネットワークのトラブルをデバッグするときに混乱の原因となるため、 お勧めできません。 NIS ドメイン名はネットワーク内で一意なければいけません。そして、 ドメイン名がドメインに含まれるマシンを表すようなものであれば分かり易いです。 たとえば Acme 社のアート (Art) 部門であれば NIS ドメイン名を "acme-art" とすれば良いでしょう。この例では NIS ドメイン名として _test-domain_ を使用します。 しかしながらオペレーティングシステムによっては (特に SunOS(TM))、 NIS ドメイン名をネットワークドメイン名として使うものもあります。 あなたのネットワークにそのような制限のあるマシンが 1 台でもあるときは、NIS のドメイン名としてインターネットのネットワークドメイン名を使わなければ _いけません_。 ===== サーバマシンの物理的必要条件 NIS サーバとして使うマシンを選ぶ際には、 いくつか注意すべき点があります。 NIS に関する困ったことの一つに、 クライアントのサーバへの依存度があります。 クライアントが自分の NIS ドメインのサーバに接続できないと、 マシンが使用不能になることがあまりに多いのです。 もし、ユーザやグループに関する情報が得られなければ、 ほとんどのシステムは一時的に停止してしまいます。 こういったことを念頭に置いて、頻繁にリブートされるマシンや、 開発に使われそうなマシンを選ばないようにしなければなりません。 理想的には NIS サーバはスタンドアロンで NIS サーバ専用のマシンにするべきです。 ネットワークの負荷が重くなければ、 他のサービスを走らせているマシンを NIS サーバにしてもかまいません。 ただし NIS サーバが使えなくなると、 _すべての_ クライアントに影響をおよぼす、 という点には注意しなければなりません。 ==== NIS サーバ 元となるすべての NIS 情報は、 NIS マスターサーバと呼ばれる 1 台のマシンに格納されます。 この情報が格納されるデータベースを NIS マップと呼びます。 FreeBSD では、このマップは [.filename]#/var/yp/[domainname]# に置かれます。 [.filename]#[domainname]# は、 サーバがサービスする NIS ドメインです。 1 台の NIS サーバが複数のドメインをサポートすることも可能です。 つまり、このディレクトリを各々のドメインごとに作ることができます。 それぞれのドメインは、 独立したマップの集合を持つことになります。 NIS のマスターサーバとスレーブサーバ上では、 `ypserv` デーモンがすべての NIS 要求を処理します。 `ypserv` は NIS クライアントからの要求を受け付け、 ドメイン名とマップ名を対応するデータベースファイルへのパスに変換し、 データをクライアントに返送します。 ===== NIS マスターサーバの設定 やりたいことにもよりますが NIS マスターサーバの設定は比較的単純です。 FreeBSD は初期状態で NIS に対応しています。 必要なのは以下の行を [.filename]#/etc/rc.conf# に追加することだけで、 あとは FreeBSD がやってくれます。 [.procedure] ==== [.programlisting] .... nisdomainname="test-domain" .... . この行はネットワークの設定後に (たとえば再起動後に) NIS のドメイン名を _test-domain_ に設定します。 + [.programlisting] .... nis_server_enable="YES" .... . これは FreeBSD に次にネットワークが立ち上がったとき NIS のサーバプロセスを起動させます。 + [.programlisting] .... nis_yppasswdd_enable="YES" .... . これは `rpc.yppasswdd` デーモンを有効にします。上述したようにこれはユーザが NIS のパスワードをクライアントのマシンから変更することを可能にします。 ==== [NOTE] ==== NIS の設定によっては、 さらに他のエントリを付け加える必要があるかもしれません。 詳細については、下記の <> 節を参照してください。 ==== さて、あとはスーパユーザ権限で `/etc/netstart` コマンドを実行するだけです。 これにより [.filename]#/etc/rc.conf# で定義された値を使ってすべての設定が行なわれます。 ===== NIS マップの初期化 _NIS マップ_ とは [.filename]#/var/yp# ディレクトリにあるデータベースファイルです。 これらは NIS マスタの [.filename]#/etc# ディレクトリの設定ファイルから作られます。 唯一の例外は [.filename]#/etc/master.passwd# ファイルです。これは `root` や他の管理用アカウントのパスワードまでその NIS ドメインのすべてのサーバに伝えたくないという、 もっともな理由によるものです。このため NIS マップの初期化の前に以下を行う必要があります。 [source,shell] .... # cp /etc/master.passwd /var/yp/master.passwd # cd /var/yp # vi master.passwd .... システムに関するアカウント (`bin`, `tty`, `kmem`, `games` など) や、NIS クライアントに伝えたくないアカウント (たとえば `root` や他の UID が 0 (スーパユーザ) のアカウント) をすべて NIS マップから取り除かなければなりません。 [NOTE] ==== [.filename]#/var/yp/master.passwd# が グループまたは誰もが読めるようになっていないようにしてください (モード 600)! 必要なら `chmod` コマンドを使ってください。 ==== すべてが終わったら NIS マップを初期化します! FreeBSD には、これを行うために `ypinit` という名のスクリプトが含まれています (詳細はそのマニュアルページをご覧ください)。 このスクリプトはほとんどの UNIX(R) OS に存在しますが、 すべてとは限らないことを覚えておいてください。 Digital Unix/Compaq Tru64 UNIX では `ypsetup` と呼ばれています。NIS マスタのためのマップを作るためには `-m` オプションを `ypinit` に与えます。上述のステップを完了しているなら、以下を実行して NIS マップを生成します。 [source,shell] .... ellington# ypinit -m test-domain Server Type: MASTER Domain: test-domain Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If you don't, something might not work. At this point, we have to construct a list of this domains YP servers. rod.darktech.org is already known as master server. Please continue to add any slave servers, one per line. When you are done with the list, type a . master server : ellington next host to add: coltrane next host to add: ^D The current list of NIS servers looks like this: ellington coltrane Is this correct? [y/n: y] y [..output from map generation..] NIS Map update completed. ellington has been setup as an YP master server without any errors. .... `ypinit` は [.filename]#/var/yp/Makefile# を [.filename]#/var/yp/Makefile.dist# から作成します。 作成された時点では、そのファイルはあなたが FreeBSD マシンだけからなるサーバが 1 台だけの NIS 環境を扱っていると仮定しています。 _test-domain_ はスレーブサーバを一つ持っていますので [.filename]#/var/yp/Makefile# を編集しなければなりません。 [source,shell] .... ellington# vi /var/yp/Makefile .... 以下の行を (もし既にコメントアウトされていないならば) コメントアウトしなければなりません。 [.programlisting] .... NOPUSH = "True" .... ===== NIS スレーブサーバの設定 NIS スレーブサーバの設定はマスターサーバの設定以上に簡単です。 スレーブサーバにログオンし [.filename]#/etc/rc.conf# ファイルを前回と同様に編集します。唯一の違うところは `ypinit` の実行に `-s` オプションを使わなければいけないことです。 `-s` オプションは NIS マスターサーバの名前を要求し、 コマンドラインは以下のようになります。 [source,shell] .... coltrane# ypinit -s ellington test-domain Server Type: SLAVE Domain: test-domain Master: ellington Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If you don't, something might not work. There will be no further questions. The remainder of the procedure should take a few minutes, to copy the databases from ellington. Transferring netgroup... ypxfr: Exiting: Map successfully transferred Transferring netgroup.byuser... ypxfr: Exiting: Map successfully transferred Transferring netgroup.byhost... ypxfr: Exiting: Map successfully transferred Transferring master.passwd.byuid... ypxfr: Exiting: Map successfully transferred Transferring passwd.byuid... ypxfr: Exiting: Map successfully transferred Transferring passwd.byname... ypxfr: Exiting: Map successfully transferred Transferring group.bygid... ypxfr: Exiting: Map successfully transferred Transferring group.byname... ypxfr: Exiting: Map successfully transferred Transferring services.byname... ypxfr: Exiting: Map successfully transferred Transferring rpc.bynumber... ypxfr: Exiting: Map successfully transferred Transferring rpc.byname... ypxfr: Exiting: Map successfully transferred Transferring protocols.byname... ypxfr: Exiting: Map successfully transferred Transferring master.passwd.byname... ypxfr: Exiting: Map successfully transferred Transferring networks.byname... ypxfr: Exiting: Map successfully transferred Transferring networks.byaddr... ypxfr: Exiting: Map successfully transferred Transferring netid.byname... ypxfr: Exiting: Map successfully transferred Transferring hosts.byaddr... ypxfr: Exiting: Map successfully transferred Transferring protocols.bynumber... ypxfr: Exiting: Map successfully transferred Transferring ypservers... ypxfr: Exiting: Map successfully transferred Transferring hosts.byname... ypxfr: Exiting: Map successfully transferred coltrane has been setup as an YP slave server without any errors. Don't forget to update map ypservers on ellington. .... この例の場合 [.filename]#/var/yp/test-domain# というディレクトリが必要になります。 NIS マスターサーバのマップファイルのコピーは、 このディレクトリに置いてください。 これらを確実に最新のものに維持する必要があります。 次のエントリをスレーブサーバの [.filename]#/etc/crontab# に追加することで、最新のものに保つことができます。 [.programlisting] .... 20 * * * * root /usr/libexec/ypxfr passwd.byname 21 * * * * root /usr/libexec/ypxfr passwd.byuid .... この二行はスレーブサーバにあるマップファイルを、 マスターサーバのマップファイルと同期させるものです。 このエントリは必須というわけではありませんが、マスターサーバは NIS マップに対する変更をスレーブサーバに伝えようとしますし、 サーバが管理するシステムにとってパスワード情報はとても重要なので、 強制的に更新してしまうことはよい考えです。特に、 マップファイルの更新がきちんと行なわれるかどうかわからないくらい混雑するネットワークでは、 重要になります。 スレーブサーバ上でも `/etc/netstart` コマンドを実行して、NIS サーバを再起動してください。 ==== NIS クライアント NIS クライアントは `ypbind` デーモンを使って、特定の NIS サーバとの間に結合 (binding) と呼ばれる関係を成立させます。 `ypbind` はシステムのデフォルトのドメイン (`domainname` コマンドで設定されます) を確認し、RPC 要求をローカルネットワークにブロードキャストします。 この RPC 要求により `ypbind` が結合を成立させようとしているドメイン名が指定されます。 要求されているドメイン名に対してサービスするよう設定されたサーバが ブロードキャストを受信すると、 サーバは `ypbind` に応答し``ypbind`` は応答のあったサーバのアドレスを記録します。複数のサーバ (たとえば一つのマスターサーバと、複数のスレーブサーバ) が利用可能な場合、`ypbind` は、 最初に応答したサーバのアドレスを使用します。 これ以降、クライアントのシステムは、 すべての NIS の要求をそのサーバに向けて送信します。 `ypbind` は、 サーバが順調に動作していることを確認するため、 時々 "ping" をサーバに送ります。 反応が戻ってくるべき時間内に ping に対する応答が来なければ、 `ypbind` は、そのドメインを結合不能 (unbound) として記録し、別のサーバを見つけるべく、 再びブロードキャストパケットの送信を行います。 ===== NIS クライアントの設定 FreeBSD マシンを NIS クライアントにする設定は非常に単純です。 [.procedure] ==== . ネットワークの起動時に NIS ドメイン名を設定して `ypbind` を起動させるために [.filename]#/etc/rc.conf# ファイルを編集して以下の行を追加します。 + [.programlisting] .... nisdomainname="test-domain" nis_client_enable="YES" .... + . NIS サーバから、 利用可能なパスワードエントリをすべて取り込むため、 [.filename]#/etc/master.passwd# からすべてのユーザアカウントを取り除いて、 `vipw` コマンドで以下の行を [.filename]#/etc/master.passwd# の最後に追加します。 + [.programlisting] .... +::::::::: .... + [NOTE] ====== この行によって NIS サーバのパスワードマップにアカウントがある人全員にアカウントが与えられます。 この行を変更すると、 さまざまな NIS クライアントの設定を行なうことが可能です。 詳細は <> を、さらに詳しい情報については、O'Reilly の `Managing NFS and NIS` を参照してください。 ====== + [NOTE] ====== [.filename]#/etc/master.passwd# 内に少なくとも一つのローカルアカウント (つまり NIS 経由でインポートされていないアカウント) を置くべきです。 また、このアカウントは `wheel` グループのメンバーであるべきです。 NIS がどこか調子悪いときには、 リモートからこのアカウントでログインし、 root になって修復するのに利用できます。 ====== + . NIS サーバにあるすべてのグループエントリを取り込むため、 以下の行を [.filename]#/etc/group# に追加します。 + [.programlisting] .... +:*:: .... ==== 上記の手順がすべて完了すれば、 `ypcat passwd` によって NIS サーバの passwd マップが参照できるようになっているはずです。 === NIS セキュリティ 一般にドメイン名さえ知っていれば、 どこにいるリモートユーザでも man:ypserv[8] に RPC を発行して NIS マップの内容を引き出すことができます。 こういった不正なやりとりを防ぐため、 man:ypserv[8] には securenets と呼ばれる機能があります。これは、 アクセスを決められたホストだけに制限するのに使える機能です。 man:ypserv[8] は起動時に [.filename]#/var/yp/securenets# ファイルから securenets に関する情報を読み込みます。 [NOTE] ==== 上記のパス名は `-p` オプションで指定されたパス名によって変わります。このファイルは、 空白で区切られたネットワーク指定とネットマスクのエントリからなっていて、 "#" で始まる行はコメントとみなされます。 簡単な securenets ファイルの例を以下に示します。 ==== [.programlisting] .... # allow connections from local host -- mandatory 127.0.0.1 255.255.255.255 # allow connections from any host # on the 192.168.128.0 network 192.168.128.0 255.255.255.0 # allow connections from any host # between 10.0.0.0 to 10.0.15.255 10.0.0.0 255.255.240.0 .... man:ypserv[8] が上記のルールの一つと合致するアドレスからの要求を受け取った場合、 処理は正常に行なわれます。 もしアドレスがルールに合致しなければ、 その要求は無視されて警告メッセージがログに記録されます。 また [.filename]#/var/yp/securenets# が存在しない場合、 `ypserv` はすべてのホストからの接続を受け入れます。 `ypserv` は Wietse Venema 氏による tcpwrapper パッケージもサポートしています。 そのため [.filename]#/var/yp/securenets# の代わりに tcpwrapper の設定ファイルを使ってアクセス制御を行なうことも可能です。 [NOTE] ==== これらのアクセス制御機能は一定のセキュリティを提供しますが、 どちらも特権ポートのテストのような "IP spoofing" 攻撃に対して脆弱です。すべての NIS 関連のトラフィックはファイアウォールでブロックされるべきです。 [.filename]#/var/yp/securenets# を使っているサーバは、古い TCP/IP 実装を持つ正当なクライアントへのサービスに失敗することがあります。 これらの実装の中にはブロードキャストのホストビットをすべて 0 でセットしてしまったり、 ブロードキャストアドレスの計算でサブネットマスクを見落としてしまったりするものがあります。 これらの問題にはクライアントの設定を正しく行なえば解決できるものもありますが、 問題となっているクライアントシステムを引退させるか、 [.filename]#/var/yp/securenets# を使わないようにしなければならないものもあります。 このような古風な TCP/IP の実装を持つサーバで [.filename]#/var/yp/securenets# を使うことは実に悪い考えであり、 あなたのネットワークの大部分において NIS の機能喪失を招きます。 tcpwrapper パッケージを使うとあなたの NIS サーバのレイテンシ (遅延) が増加します。特に混雑したネットワークや遅い NIS サーバでは、遅延の増加によって、 クライアントプログラムのタイムアウトが起こるかもしれません。 一つ以上のクライアントシステムがこれらの兆候を示したなら、 あなたは問題となっているクライアントシステムを NIS スレーブサーバにして自分自身に結び付くように強制すべきです。 ==== === 何人かのユーザのログオンを遮断する わたしたちの研究室には `basie` という、 教員専用のマシンがあります。わたしたちはこのマシンを NIS ドメインの外に出したくないのですが、 マスタ NIS サーバの [.filename]#passwd# ファイルには教員と学生の両方が載っています。 どうしたらいいでしょう? 当該人物が NIS のデータベースに載っていても、 そのユーザがマシンにログオンできないようにする方法があります。 そうするには __-username__ をクライアントマシンの [.filename]#/etc/master.passwd# ファイルの末尾に付け足します。 _username_ はあなたがログインさせたくないと思っているユーザのユーザ名です。 これは `vipw` で行うべきです。 `vipw` は [.filename]#/etc/master.passwd# への変更をチェックし、編集終了後パスワードデータベースを再構築します。 たとえば、ユーザ _bill_ が `basie` にログオンするのを防ぎたいなら、以下のようにします。 [source,shell] .... basie# vipw [add -bill to the end, exit] vipw: rebuilding the database... vipw: done basie# cat /etc/master.passwd root:[password]:0:0::0:0:The super-user:/root:/bin/csh toor:[password]:0:0::0:0:The other super-user:/root:/bin/sh daemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin operator:*:2:5::0:0:System &:/:/sbin/nologin bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/sbin/nologin tty:*:4:65533::0:0:Tty Sandbox:/:/sbin/nologin kmem:*:5:65533::0:0:KMem Sandbox:/:/sbin/nologin games:*:7:13::0:0:Games pseudo-user:/usr/games:/sbin/nologin news:*:8:8::0:0:News Subsystem:/:/sbin/nologin man:*:9:9::0:0:Mister Man Pages:/usr/shared/man:/sbin/nologin bind:*:53:53::0:0:Bind Sandbox:/:/sbin/nologin uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/sbin/nologin pop:*:68:6::0:0:Post Office Owner:/nonexistent:/sbin/nologin nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin +::::::::: -bill basie# .... [[network-netgroups]] === ネットグループの利用 前節までに見てきた手法は、 極めて少ないユーザ/マシン向けに個別のルールを必要としている場合にはうまく機能します。 しかし大きなネットワークでは、 ユーザに触られたくないマシンへログオンを防ぐのを _忘れるでしょう_ し、 そうでなくとも各マシンを個別に設定して回らなければならず、 __集中__管理という NIS の恩恵を失ってしまいます。 NIS の開発者はこの問題を _ネットグループ_ と呼ばれる方法で解決しました。 その目的と意味合いは UNIX(R) のファイルシステムで使われている一般的なグループと比較できます。 主たる相違は数値 ID が存在しないことと、 ユーザアカウントと別のネットグループを含めたネットグループを定義できることです。 ネットグループは百人/台以上のユーザとマシンを含む、 大きく複雑なネットワークを扱うために開発されました。 あなたがこのような状況を扱わなければならないなら便利なものなのですが、 一方で、この複雑さは単純な例でネットグループの説明をすることをほとんど不可能にしています。 この節の残りで使われている例は、この問題を実演しています。 あなたの行なった、 研究室への NIS の導入の成功が上司の目に止ったとしましょう。 あなたの次の仕事は、あなたの NIS ドメインをキャンパスの他のいくつものマシンを覆うものへ拡張することです。 二つの表は新しいユーザと新しいマシンの名前とその説明を含んでいます。 [.informaltable] [cols="1,1", options="header"] |=== | ユーザの名前 | 説明 |alpha, beta |IT 学科の通常の職員 |charlie, delta |IT 学科の新しい見習い |echo, foxtrott, golf, ... |一般の職員 |able, baker, ... |まだインターン |=== [.informaltable] [cols="1,1", options="header"] |=== | マシンの名前 | 説明 |war, death, famine, pollution |最も重要なサーバ。IT 職員だけがログオンを許されます。 |pride, greed, envy, wrath, lust, sloth |あまり重要でないサーバ。 IT 学科の全員がログオンを許されます。 |one, two, three, four, ... |通常のワークステーション。 _本当の_ 職員だけがログオンを許されます。 |trashcan |重要なデータの入っていないひどく古いマシン。 インターンでもこのマシンの使用を許されます。 |=== もしあなたがこの手の制限を各ユーザを個別にブロックする形で実装するなら、 あなたはそのシステムにログオンすることが許されていない各ユーザについて -_user_ という 1 行を、各システムの [.filename]#passwd# に追加しなければならなくなるでしょう。 もしあなたが 1 エントリでも忘れればトラブルに巻き込まれてしまいます。 最初のセットアップの時にこれを正しく行えるのはありえることかも知れませんが、 遂には連日の業務の間に例の行を追加し__忘れてしまうでしょう__。 結局マーフィーは楽観主義者だったのです。 この状況をネットグループで扱うといくつかの有利な点があります。 各ユーザを別個に扱う必要はなく、 ユーザを一つ以上のネットグループに割り当て、 ネットグループの全メンバのログインを許可したり禁止したりすることができます。 新しいマシンを追加するときはネットグループへログインの制限を定義するだけ、 新しいユーザを追加するときはそのユーザを一つ以上のネットグループへ追加するだけで、 それぞれ行なうことができます。 これらの変更は互いに独立なので、 "ユーザとマシンの組合わせをどうするか" は存在しなくなります。 あなたの NIS のセットアップが注意深く計画されていれば、 マシンへのアクセスを認めるにも拒否するにも中心の設定をたった一カ所変更するだけです。 最初のステップは NIS マップネットグループの初期化です。 FreeBSD の man:ypinit[8] はこのマップをデフォルトで作りませんが、 その NIS の実装はそれが作られさえすればそれをサポートするものです。 空のマップを作るには、単に [source,shell] .... ellington# vi /var/yp/netgroup .... とタイプして内容を追加していきます。 わたしたちの例では、すくなくとも IT 職員、IT 見習い、一般職員、 インターンの 4 つのネットグループが必要です。 [.programlisting] .... IT_EMP (,alpha,test-domain) (,beta,test-domain) IT_APP (,charlie,test-domain) (,delta,test-domain) USERS (,echo,test-domain) (,foxtrott,test-domain) \ (,golf,test-domain) INTERNS (,able,test-domain) (,baker,test-domain) .... `IT_EMP`, `IT_APP` 等はネットグループの名前です。 それぞれの括弧で囲まれたグループが一人以上のユーザアカウントをそれに登録しています。 グループの 3 つのフィールドは . その記述が有効なホスト (群) の名称。 ホスト名を特記しなければそのエントリはすべてのホストで有効です。 もしあなたがホスト名を特記するなら、 あなたは闇と恐怖と全き混乱の領域に入り込んでしまうでしょう。 . このネットグループに所属するアカウントの名称。 . そのアカウントの NIS ドメイン。 もしあなたが一つ以上の NIS ドメインの不幸な仲間なら、 あなたは他の NIS ドメインからあなたのネットグループにアカウントを導入できます。 各フィールドには、ワイルドカードが使えます。 詳細は man:netgroup[5] をご覧ください。 [NOTE] ==== 8 文字以上のネットグループ名は、特にあなたの NIS ドメインで他のオペレーティングシステムを走らせているときは使うべきではありません。 名前には大文字小文字の区別があります。 そのためネットグループ名に大文字を使う事は、 ユーザやマシン名とネットグループ名を区別する簡単な方法です。 (FreeBSD 以外の) NIS クライアントの中には 多数のエントリを扱えないものもあります。 たとえば SunOS(TM) の古い版では 15 以上の _エントリ_ を含むネットグループはトラブルを起こします。 この制限は 15 ユーザ以下のサブネットグループをいくつも作り、 本当のネットグループはこのサブネットグループからなるようにすることで回避できます。 [.programlisting] .... BIGGRP1 (,joe1,domain) (,joe2,domain) (,joe3,domain) [...] BIGGRP2 (,joe16,domain) (,joe17,domain) [...] BIGGRP3 (,joe31,domain) (,joe32,domain) BIGGROUP BIGGRP1 BIGGRP2 BIGGRP3 .... 単一のネットグループに 225 人以上のユーザをいれたいときは、 このやり方を繰り返すことができます。 ==== 新しい NIS マップの有効化と配布は簡単です。 [source,shell] .... ellington# cd /var/yp ellington# make .... これで新しい 3 つの NIS マップ [.filename]#netgroup#, [.filename]#netgroup.byhost#, [.filename]#netgroup.byuser# ができるはずです。 新しい NIS マップが利用できるか確かめるには man:ypcat[1] を使います。 [source,shell] .... ellington% ypcat -k netgroup ellington% ypcat -k netgroup.byhost ellington% ypcat -k netgroup.byuser .... 最初のコマンドの出力は [.filename]#/var/yp/netgroup# の内容に似ているはずです。 2 番目のコマンドはホスト別のネットグループを作っていなければ出力されません。 3 番目のコマンドはユーザに対するネットグループのリストを得るのに使えます。 クライアント側の設定は非常に簡単です。 サーバ _war_ を設定するには、 man:vipw[8] を実行して以下の行 [.programlisting] .... +::::::::: .... を [.programlisting] .... +@IT_EMP::::::::: .... に入れ替えるだけです。 今、ネットグループ _IT_EMP_ で定義されたユーザのデータだけが _war_ のパスワードデータベースに読み込まれ、 そのユーザだけがログインを許されています。 残念ながらこの制限はシェルの ~ の機能や、 ユーザ名や数値の ユーザ ID の変換ルーチンにも影響します。 つまり、 `cd ~user` はうまく動かず、 `ls -l` はユーザ名のかわりに数値の ID を表示し `find . -user joe -print` は "No such user" で失敗します。 これを避けるためには、すべてのユーザのエントリを _サーバにログインすることを許さずに_ 読み込まなければなりません。 これはもう一行を [.filename]#/etc/master.passwd# に追加することで実現できます。その行は以下の `+:::::::::/sbin/nologin` を含んでおり、 これは "すべてのエントリを読み込むが、読み込まれたエントリのシェルは [.filename]#/sbin/nologin# で置き換えられる" ということを意味します。passwd エントリの他のフィールドを [.filename]#/etc/master.passwd# の既定値から置き換えることも可能です。 [WARNING] ==== `+:::::::::/sbin/nologin` の行が `+@IT_EMP:::::::::` の行より後ろに位置することに注意してください。 さもないと NIS から読み込まれた全ユーザが /sbin/nologin をログインシェルとして持つことになります。 ==== この変更の後では、新しい職員が IT 学科に参加しても NIS マップを一つ書き換えるだけで済みます。 同様にして、あまり重要でないサーバのローカルの [.filename]#/etc/master.passwd# のかつての `+:::::::::` 行を以下のように置き換えます。 [.programlisting] .... +@IT_EMP::::::::: +@IT_APP::::::::: +:::::::::/sbin/nologin .... この行は、一般のワークステーションでは以下のようになります。 [.programlisting] .... +@IT_EMP::::::::: +@USERS::::::::: +:::::::::/sbin/nologin .... これでしばらく順調に運用していましたが、 数週間後、ポリシに変更がありました。 IT 学科はインターンを雇い始め、IT インターンは一般のワークステーションと余り重要ではないサーバを使うことが許され、 IT 見習いはメインサーバへのログインが許されました。 あなたは新たなネットグループ IT_INTERN を追加して新しい IT インターンたちをそのグループに登録し、 すべてのマシンの設定を変えて回ることにしました。 古い諺にこうあります。 "集中管理における過ちは、大規模な混乱を導く"。 いくつかのネットグループから新たなネットグループを作るという NIS の機能は、このような状況に対処するために利用できます。 その方法の一つは、役割別のネットグループを作ることです。 たとえば、重要なサーバへのログイン制限を定義するために _BIGSRV_ というネットグループを作り あまり重要ではないサーバへは _SMALLSRV_ というネットグループを、そして一般のワークステーション用に _USERBOX_ という第 3 のネットグループを 作ることができます。これらのネットグループの各々は、 各マシンにログインすることを許されたネットグループを含みます。 あなたの NIS マップネットグループの新しいエントリは、 以下のようになるはずです。 [.programlisting] .... BIGSRV IT_EMP IT_APP SMALLSRV IT_EMP IT_APP ITINTERN USERBOX IT_EMP ITINTERN USERS .... このログイン制限の定義法は、 同一の制限を持つマシンのグループを定義できるときには便利なものです。 残念ながらこのようなケースは例外的なものです。 ほとんどの場合、 各マシンに基づくログイン制限の定義機能が必要となるでしょう。 マシンごとのネットグループの定義は、 上述したようなポリシの変更を扱うことができるもうひとつの方法です。 このシナリオでは、各マシンの [.filename]#/etc/master.passwd# は "+" で始まる 2 つの行からなります。 最初のものはそのマシンへのログインを許されたアカウントを追加するもので、 2 番目はその他のアカウントを [.filename]#/sbin/nologin# をシェルとして追加するものです。 マシン名をすべて大文字で記述したものをネットグループの名前として使うのは良い考えです。 言い換えれば、件の行は次のようになるはずです。 [.programlisting] .... +@BOXNAME::::::::: +:::::::::/sbin/nologin .... 一度、各マシンに対してこの作業を済ませてしまえば、 二度とローカルの [.filename]#/etc/master.passwd# を編集する必要がなくなります。 以降のすべての変更は NIS マップの編集で扱うことができます。 以下はこのシナリオに対応するネットグループマップに、 いくつかの便利な定義を追加した例です。 [.programlisting] .... # Define groups of users first IT_EMP (,alpha,test-domain) (,beta,test-domain) IT_APP (,charlie,test-domain) (,delta,test-domain) DEPT1 (,echo,test-domain) (,foxtrott,test-domain) DEPT2 (,golf,test-domain) (,hotel,test-domain) DEPT3 (,india,test-domain) (,juliet,test-domain) ITINTERN (,kilo,test-domain) (,lima,test-domain) D_INTERNS (,able,test-domain) (,baker,test-domain) # # Now, define some groups based on roles USERS DEPT1 DEPT2 DEPT3 BIGSRV IT_EMP IT_APP SMALLSRV IT_EMP IT_APP ITINTERN USERBOX IT_EMP ITINTERN USERS # # And a groups for a special tasks # Allow echo and golf to access our anti-virus-machine SECURITY IT_EMP (,echo,test-domain) (,golf,test-domain) # # machine-based netgroups # Our main servers WAR BIGSRV FAMINE BIGSRV # User india needs access to this server POLLUTION BIGSRV (,india,test-domain) # # This one is really important and needs more access restrictions DEATH IT_EMP # # The anti-virus-machine mentioned above ONE SECURITY # # Restrict a machine to a single user TWO (,hotel,test-domain) # [...more groups to follow] .... もしユーザアカウントを管理するのにデータベースの類を使っているなら、 データベースのレポートツールからマップの最初の部分を作れるようにするべきです。 そうすれば、新しいユーザは自動的にマシンにアクセスできるでしょう。 最後に使用上の注意を: マシン別のネットグループを使うことが常に賢明というわけではありません。 あなたが数ダースから数百の同一の環境のマシンを学生の研究室に配置しているのならば、 NIS マップのサイズを手頃な範囲に押さえるために、 マシン別のネットグループのかわりに役割別のネットグループを使うべきです。 === 忘れてはいけないこと NIS 環境にある今、 今までとは違ったやり方が必要なことがいくつかあります。 * 研究室にユーザを追加するときは、それをマスター NIS サーバに _だけ_ 追加しなければならず、さらに _NIS マップを再構築することを忘れてはいけません_。 これを忘れると新しいユーザは NIS マスタ以外のどこにもログインできなくなります。 たとえば、新しくユーザ "jsmith" をラボに登録したいときは以下のようにします。 + [source,shell] .... # pw useradd jsmith # cd /var/yp # make test-domain .... + `pw useradd jsmith` のかわりに `adduser jsmith` を使うこともできます。 * _管理用アカウントを NIS マップから削除してください_。 管理用アカウントやパスワードを、 それらのアカウントへアクセスさせてはいけないユーザが居るかも知れないマシンにまで伝えて回りたいとは思わないでしょう。 * _NIS のマスタとスレーブをセキュアに、 そして機能停止時間を最短に保ってください_。 もし誰かがこれらのマシンをクラックしたり、 あるいは単に電源を落としたりすると、 彼らは実質的に多くの人を研究室へログインできなくしてしまえます。 + これはどの集中管理システムにとってももっとも大きな弱点でしょう。 あなたの NIS サーバを守らなければ怒れるユーザと対面することになるでしょう! === NIS v1 との互換性 FreeBSD の ypserv は、 NIS v1 クライアントを部分的にサポートしています。 FreeBSD の NIS 実装は NIS v2 プロトコルのみを使用していますが、 ほかの実装では、古いシステムとの下位互換性を持たせるため v1 プロトコルをサポートしているものもあります。 そのようなシステムに付いている ypbind デーモンは、 必要がないにもかかわらず NIS v1 のサーバとの結合を成立させようとします (しかも v2 サーバからの応答を受信した後でも、 ブロードキャストをし続けるかも知れません)。 FreeBSD の ypserv は、 クライアントからの通常のリクエストはサポートしていますが、 v1 のマップ転送リクエストはサポートしていないことに注意してください。 つまり FreeBSD の ypserv を、 v1 だけをサポートするような古い NIS サーバと組み合わせて マスターやスレーブサーバとして使うことはできません。 幸いなことに、現在、そのようなサーバが使われていることは ほとんどないでしょう。 [[network-nis-server-is-client]] === NIS クライアントとしても動作している NIS サーバ 複数のサーバが存在し、サーバ自身が NIS クライアントでもあるようなドメインで ypserv が実行される場合には注意が必要です。 一般的に良いとされているのは、 他のサーバと結合をつくるようにブロードキャストさせるのではなく、 サーバをそれ自身に結合させることです。 もし、サーバ同士が依存関係を持っていて、一つのサーバが停止すると、 奇妙なサービス不能状態に陥ることがあります。 その結果、すべてのクライアントはタイムアウトを起こして 他のサーバに結合しようと試みますが、 これにかかる時間はかなり大きく、 サーバ同士がまた互いに結合してしまったりすると、 サービス不能状態はさらに継続することになります。 `ypbind` に `-S` オプションフラグを指定して実行することで、 ホストを特定のサーバに結合することが可能です。 NIS サーバを再起動するたびに、これを手動で行いたくないなら、 次の行を [.filename]#/etc/rc.conf# に追加すればよいでしょう。 [.programlisting] .... nis_client_enable="YES" # run client stuff as well nis_client_flags="-S NIS domain,server" .... 詳細については man:ypbind[8] を参照してください。 === パスワード形式 NIS を実装しようする人の誰もがぶつかる問題の一つに、 パスワード形式の互換性があります。 NIS サーバが DES 暗号化パスワード使っている場合には、 同様に DES を使用しているクライアントしか対応できません。 たとえば Solaris(TM)； の NIS クライアントがネットワーク内にある場合、 ほぼ確実に DES 暗号化パスワードを使用しなければならないでしょう。 サーバとクライアントがどのライブラリを使用しているかは、 [.filename]#/etc/login.conf# を確認してください。 ホストが DES 暗号パスワードを使用するように設定されている場合、 `default` クラスには以下のようなエントリが含まれます。 [.programlisting] .... default:\ :passwd_format=des:\ :copyright=/etc/COPYRIGHT:\ [Further entries elided] .... `passwd_format` 特性について他に利用可能な値は `blf` および `md5` (それぞれ Blowfish および MD5 暗号化パスワード) です。 [.filename]#/etc/login.conf# を変更したときは、 ログイン特性データベースも再構築しなければなりません。 これは `root` 権限で下記のようにコマンドを実行すればできます。 [source,shell] .... # cap_mkdb /etc/login.conf .... [NOTE] ==== すでに [.filename]#/etc/master.passwd# 内に記録されているパスワード形式は、 ログイン特性データベースが再構築された__後__、 ユーザが彼らのパスワードをはじめて変更するまで変更されないでしょう。 ==== 次に、 パスワードが選択した形式で暗号化されることを確実にするために、 さらに [.filename]#/etc/auth.conf# 内の `crypt_default` において、 選択したパスワード形式に高い優先順位がついていることも確認してください。 そうするためには、選択した形式をリストの先頭に置いてください。 たとえば DES 暗号化されたパスワードを使用するときは、 エントリは次のようになります。 [.programlisting] .... crypt_default = des blf md5 .... FreeBSD 上の各 NIS サーバおよびクライアントにおいて上記の手順に従えば、 ネットワーク内でどのパスワード形式が使用されるかが それらのマシン間で整合されているということを確信できます。 NIS クライアント上で問題があれば、 ここから問題となりそうな部分を探すと良いでしょう。 覚えておいてください: 異種混在ネットワークに NIS サーバを配置したいときには、 DES が最大公約数的な標準となるでしょうから、 すべてのシステムで DES を使用しなければならないかもしれません。 [[network-dhcp]] == DHCP === DHCP とは何でしょうか? DHCP (Dynamic Host Configuration Protocol) は、 システムをネットワークに接続するだけで、 ネットワークでの通信に必要な情報を入手することができる仕組みです。 FreeBSD では ISC (Internet Software Consortium) による DHCP の実装を使用しています。したがって、 ここでの説明のうち実装によって異なる部分は ISC のもの用になっています。 === この節で説明していること この節は ISC DHCP システムのクライアント側およびサーバ側の構成要素の両方について説明します。 クライアント側のプログラムである `dhclient` は FreeBSD のベースシステム内に含まれています。そして、サーバ側の要素は package:net/isc-dhcp3-server[] port から利用可能です。下記の説明の他に、 man:dhclient[8], man:dhcp-options[5] および man:dhclient.conf[5] マニュアルページが役にたつ情報源です。 === DHCP の動作 クライアントとなるマシン上で、 DHCP のクライアントである `dhclient` を実行すると、 まず設定情報の要求をブロードキャストします。デフォルトでは、 このリクエストには UDP のポート 68 を使用します。 サーバは UDP のポート 67 で応答し、クライアントの IP アドレスと、 ネットマスクやルータ、DNS サーバなどの関連する情報を提供します。 これらの情報のすべては DHCP の "リース" の形で送られ、DHCP サーバ管理者によって決められたある一定の時間内でのみ有効になります。 これによって、ネットワークに存在しなくなったホストの IP アドレスは自動的に回収されることになります。 DHCP クライアントはサーバから非常に多くの情報を取得することができます。 man:dhcp-options[5] に非常に大きなリストが載っています。 === FreeBSD への組み込み FreeBSD は ISC の DHCP クライアントである `dhclient` を完全に組み込んでいます。 DHCP クライアントはインストーラと基本システムの両方で提供されています。 ですから DHCP サーバを走らせているネットワーク上ではネットワーク関係の設定についての詳細な知識は必要になりません。 `dhclient` は、3.2 以降のすべての FreeBSD の配布物に含まれています。 DHCP は sysinstall で対応されており、sysinstall でのネットワークインタフェイス設定の際は、 "このインタフェイスの設定として DHCP を試してみますか? (Do you want to try DHCP configuration of this interface?)" という質問が最初になされます。 これに同意することで `dhclient` が実行され、 それが成功すればネットワークの設定情報は自動的に取得されます。 システム起動時に DHCP を使ってネットワーク情報を取得するように するには、次の二つを行なう必要があります。 * [.filename]#bpf# デバイスがカーネルに組み込まれていることを確認します。 これを組み込むには、カーネルコンフィグレーションファイルに `pseudo-device bpf` という行を追加し、カーネルを再構築します。 カーネルの構築に関する詳細は、 crossref:kernelconfig[kernelconfig,FreeBSD カーネルのコンフィグレーション] を参照してください。 + [.filename]#bpf# デバイスは、 FreeBSD にはじめから用意されている [.filename]#GENERIC# カーネルに組み込まれていますので、 自分で設定を変えたカスタムカーネルを使っているのでなければ、 DHCP を動作させるためにカーネルを再構築する必要はありません。 + [NOTE] ==== セキュリティに関心のある方向けに注意しておきます。 [.filename]#bpf# デバイスは、パケットスニファ (盗聴プログラム) を動作させることができる (ただし `root` 権限が必要) デバイスです。 [.filename]#bpf# は DHCP を動作させるために __かならず__必要ですが、 セキュリティが非常に重要な場面では DHCP をいつか使うかもしれないというだけで [.filename]#bpf# デバイスをカーネルに追加すべきではないでしょう。 ==== * [.filename]#/etc/rc.conf# を編集して、 次の行を追加してください。 + [.programlisting] .... ifconfig_fxp0="DHCP" .... + [NOTE] ==== で説明されているように `fxp0` の部分を、 動的に設定したいインタフェースの名前で置き換えることを忘れないようにしてください。 ==== + もし、使っている `dhclient` の場所を変更していたり、`dhclient` にフラグを渡したい場合は、 同様に下のように書き加えてください。 + [.programlisting] .... dhcp_program="/sbin/dhclient" dhcp_flags="" .... DHCP サーバ `dhcpd` は、Ports Collection に package:net/isc-dhcp3-server[] の一部として収録されています。 この port には ISC DHCP サーバと文書が含まれています。 === 関連ファイル * [.filename]#/etc/dhclient.conf# + `dhclient` は設定ファイル [.filename]#/etc/dhclient.conf# を必要とします。 大抵の場合、このファイルはコメントだけであり、 デフォルトが通常使いやすい設定になっています。 この設定ファイルは man:dhclient.conf[5] マニュアルページで説明しています。 * [.filename]#/sbin/dhclient# + `dhclient` は静的にリンクされており、 [.filename]#/sbin# に置かれています。man:dhclient[8] マニュアルページで `dhclient` コマンドについてより詳しく説明しています。 * [.filename]#/sbin/dhclient-script# + `dhclient-script` は FreeBSD 特有の、 DHCP クライアント設定スクリプトです。これについては man:dhclient-script[8] マニュアルページで説明されていますが、 これを編集する必要はほとんど発生しないでしょう。 * [.filename]#/var/db/dhclient.leases# + DHCP クライアントはこのファイルに有効なリースのデータベースをログとして記録します。 man:dhclient.leases[5] にもうすこし詳しい解説があります。 === 参考になる文献 DHCP のプロトコルは http://www.freesoft.org/CIE/RFC/2131/[RFC 2131] に完全に記述されています。また http://www.dhcp.org/[dhcp.org] にも有用な情報源が用意されています。 [[network-dhcp-server]] === DHCP サーバのインストールと設定 ==== この節で説明していること この節は DHCP の ISC (Internet Software Consortium) 実装を用いて FreeBSD システムを DHCP サーバとして動作させる方法の情報を提供します。 DHCP のサーバ部分は FreeBSD の一部として提供されません。 したがって、このサービスを提供するために package:net/isc-dhcp3-server[] port をインストールする必要があるでしょう。 Ports Collection を使用する情報についての詳細は crossref:ports[ports,アプリケーションのインストール - packages と ports] を参照してください。 ==== DHCP サーバのインストール FreeBSD システムを DHCP サーバとして設定するために、man:bpf[4] デバイスがカーネルに組み込まれていることを保証する必要があります。 そうするためには、カーネルコンフィギュレーションファイルに `pseudo-device bpf` を追加して、 カーネルを再構築してください。 カーネルの構築に関する詳細は crossref:kernelconfig[kernelconfig,FreeBSD カーネルのコンフィグレーション] を参照してください。 [.filename]#bpf# デバイスは、 FreeBSD にはじめから用意されている [.filename]#GENERIC# カーネルの一部なので、DHCP を動作させるためにカスタムカーネルを作成する必要はありません。 [NOTE] ==== セキュリティを特に意識する人は、[.filename]#bpf# [.filename]#bpf# はパケットスニファ (盗聴プログラム) が正常に (このようなプログラムはさらに特権アクセスを必要としますが) 動作することを可能にするデバイスでもあることに注意してください。 [.filename]#bpf# は DHCP を使用するために必要 _です_。 しかし、セキュリティをとても気にしているなら、 DHCP をいつか使うかもしれないというだけで [.filename]#bpf# デバイスをカーネルに含めるべきではないでしょう。 ==== 次に行わねばならないのは、 package:net/isc-dhcp3-server[] port によってインストールされた [.filename]#dhcpd.conf# のサンプルを編集することです。 デフォルトでは、これは [.filename]#/usr/local/etc/dhcpd.conf.sample# で、 編集する前にこれを [.filename]#/usr/local/etc/dhcpd.conf# にコピーするべきでしょう。 ==== DHCP サーバの設定 [.filename]#dhcpd.conf# はサブネットおよびホストに関する宣言で構成されます。 例を使って説明するのが最も簡単でしょう。 [.programlisting] .... option domain-name "example.com";<.> option domain-name-servers 192.168.4.100;<.> option subnet-mask 255.255.255.0;<.> default-lease-time 3600;<.> max-lease-time 86400;<.> ddns-update-style none;<.> subnet 192.168.4.0 netmask 255.255.255.0 { range 192.168.4.129 192.168.4.254;<.> option routers 192.168.4.1;<.> } host mailhost { hardware ethernet 02:03:04:05:06:07;<.> fixed-address mailhost.example.com;<.> } .... <.> このオプションは、 デフォルト探索ドメインとしてクライアントに渡されるドメインを指定します。 これが意味するところの詳細については man:resolv.conf[5] を参照してください。 <.> このオプションはクライアントが使用する、 コンマで区切られた DNS サーバのリストを指定します。 <.> クライアントに渡されるネットマスクです。 <.> クライアントは特定のリース期限を要求することもできます。 それ以外の場合は、サーバはこのリース期限値 (秒) でリースを割り当てるでしょう。 <.> これはサーバがリースする時間の最大値です。 クライアントがこれより長いリースを要求しても、 `max-lease-time` 秒だけしか有効にならないでしょう。 <.> このオプションは、リースが受理、またはリリースされたときに DHCP サーバが DNS を更新しようとするかどうかを指定します。 ISC 実装では、このオプションは _必須_ です。 <.> これはどの範囲の IP アドレスが、 クライアントに割り当てるために予約されたプールに使用されるかを示します。 この範囲に含まれている IP アドレスはクライアントに渡されます。 <.> クライアントに供給されるデフォルトゲートウェイを宣言します。 <.> (リクエストが生じた時に DHCP サーバがホストを認識できるように) ホストのハードウェア MAC アドレスを指定します。 <.> ホストに常に同じ IP アドレスを付与することを指定します。 DHCP サーバはリース情報を返す前にホスト名の名前解決をするので、 ここにホスト名を書いても構いません。 [.filename]#dhcpd.conf# を書き終えたら以下のコマンドでサーバを起動できます。 [source,shell] .... # /usr/local/etc/rc.d/isc-dhcpd.sh start .... 今後サーバの設定に変更を加える必要が生じた時には、 `SIGHUP` シグナルを dhcpd に送っても、 多くのデーモンがそうであるようには、 設定ファイルが再読み込み _されない_ ことに注意してください。 `SIGTERM` シグナルを送ってプロセスを停止し、 それから上記のコマンドを用いて再起動させる必要があります。 ==== ファイル * [.filename]#/usr/local/sbin/dhcpd# + dhcpd は静的にリンクされ [.filename]#/usr/local/sbin# に置かれます。 dhcpd に関するそれ以上の情報は port とともにインストールされる man:dhcpd[8] マニュアルページにあります。 * [.filename]#/usr/local/etc/dhcpd.conf# + dhcpd はクライアントへのサービス提供をはじめる前に設定ファイル [.filename]#/usr/local/etc/dhcpd.conf# を必要とします。このファイルは、 サーバの稼働に関する情報に加えて、 サービスされているクライアントに提供される情報のすべてを含む必要があります。 この設定ファイルについての詳細は、 port によってインストールされる man:dhcpd.conf[5] マニュアルページを参照してください。 * [.filename]#/var/db/dhcpd.leases# + DHCP サーバは発行したリースのデータベースをこのファイルにログとして保持します。 port によってインストールされる man:dhcpd.leases[5] にはもう少し詳しい説明があります。 * [.filename]#/usr/local/sbin/dhcrelay# + dhcrelay は、DHCP サーバがクライアントからのリクエストを、 別のネットワーク上にある DHCP サーバに転送する高度な環境下で使用されます。 この機能が必要なら、package:net/isc-dhcp3-server[] port をインストールしてください。 port とともに提供される man:dhcrelay[8] マニュアルページにはより詳細な情報が含まれます。 [[network-dns]] == DNS === 概観 FreeBSD はデフォルトでは DNS プロトコルの最も一般的な実装である BIND (Berkeley Internet Name Domain) を使用します。DNS はホスト名を IP アドレスに、そして IP アドレスをホスト名に関連づけるプロトコルです。 たとえば `www.FreeBSD.org` に対する問い合わせは The FreeBSD Project の ウェブサーバの IP アドレスを受け取るでしょう。 その一方で `ftp.FreeBSD.org` に対する問い合わせは、 対応する FTP マシンの IP アドレスを返すでしょう。 同様に、その逆のことも可能です。 IP アドレスに対する問い合わせを行うことで、 そのホスト名を解決することができます。 DNS 検索を実行するために、 システム上でネームサーバを動作させる必要はありません。 DNS は、 個々のドメイン情報を格納およびキャッシュした、 権威のあるルートサーバおよび他の小規模なネームサーバによる多少複雑なシステムによって、 インターネット全体にわたって協調して動作します。 この文書は FreeBSD で安定版として利用されている BIND 8.x について説明します。 FreeBSD では BIND 9.x を package:net/bind9[] port からインストールできます。 RFC1034 および RFC1035 は DNS プロトコルを定義しています。 現在のところ BIND は http://www.isc.org/[Internet Software Consortium (www.isc.org)] によって保守されています。 === 用語 この文書を理解するには DNS 関連の用語をいくつか理解しなければいけません。 [.informaltable] [cols="1,1", frame="none", options="header"] |=== | 用語 | 定義 |正引き DNS |ホスト名から IP アドレスへの対応です。 |オリジン (origine) |特定のゾーンファイルによってカバーされるドメインへの参照です。 |named, BIND, ネームサーバ |FreeBSD 内の BIND ネームサーバパッケージの一般名称です。 |リゾルバ (resolver) |マシンがゾーン情報についてネームサーバに問い合わせるシステムプロセスです。 |逆引き DNS |正引き DNS の逆です。つまり IP アドレスからホスト名への対応です。 |ルートゾーン |インターネットゾーン階層の起点です。 すべてのゾーンはルートゾーンの下に属します。 これはファイルシステムのすべてのファイルがルートディレクトリの下に属することと似ています。 |ゾーン |同じ権威によって管理される個々の DNS ドメイン、 DNS サブドメイン、あるいは DNS の一部分です。 |=== ゾーンの例: * `.` はルートゾーンです。 * `org.` はルートゾーンの下のゾーンです。 * `example.org` は `org.` ゾーンの下のゾーンです。 * `foo.example.org.` はサブドメインで、 `example.org.` の下のゾーンです。 * `1.2.3.in-addr.arpa` は 3.2.1.* の IP 空間に含まれるすべての IP アドレスを参照するゾーンです。 見て分かるように、ホスト名のより詳細な部分はその左側に現れます。 たとえば `example.org.` は `org.` より限定的です。同様に `org.` はルートゾーンより限定的です。 ホスト名の各部分のレイアウトはファイルシステムに非常に似ています。 たとえば [.filename]#/dev# はルートの下であることなどです。 === ネームサーバを実行する理由 ネームサーバは通常二つの形式があります: 権威のあるネームサーバとキャッシュネームサーバです。 権威のあるネームサーバは以下の場合に必要です。 * 問い合わせに対して信頼できる返答をすることで、 ある人が DNS 情報を世界に向けて発信したいとき。 * `example.org` といったドメインが登録されており、 その下にあるホスト名に IP アドレスを割り当てる必要があるとき。 * IP アドレスブロックが (IP からホスト名への) 逆引き DNS エントリを必要とするとき。 * プライマリサーバがダウンしているかまたはアクセスできない場合に、 代わりに問い合わせに対してスレーブと呼ばれるバックアップネームサーバが返答しなければならないとき。 キャッシュネームサーバは以下の場合に必要です。 * ローカルのネームサーバが、 外部のネームサーバに問い合わせするよりも、 キャッシュしてより速く返答できるとき。 * ネットワークトラフィックの総量を減らしたいとき (DNS のトラフィックはインターネットトラフィック全体の 5% 以上を占めることが測定されています) `www.FreeBSD.org` に対する問い合わせを発したとき、 リゾルバは大体の場合上流の ISP のネームサーバに問い合わせをして返答を得ます。 ローカルのキャッシュ DNS サーバがあれば、 問い合わせはキャッシュ DNS サーバによって外部に対して一度だけ発せられます。 情報がローカルに蓄えられるので、 追加の問い合わせはいずれもローカルネットワークの外側にまで確認しなくてもよくなります。 === 動作のしくみ FreeBSD では BIND デーモンは自明な理由から named と呼ばれます。 [.informaltable] [cols="1,1", frame="none", options="header"] |=== | ファイル | 説明 |named |BIND デーモン |`ndc` |ネームデーモンコントロールプログラム |[.filename]#/etc/namedb# |BIND のゾーン情報が置かれるディレクトリ |[.filename]#/etc/namedb/named.conf# |デーモンの設定ファイル |=== ゾーンファイルは通常 [.filename]#/etc/namedb# ディレクトリ内に含まれており、ネームサーバによって処理される DNS ゾーン情報を含んでいます。 === BIND の起動 BIND はデフォルトでインストールされているので、 すべてを設定することは比較的単純です。 named デーモンが起動時に開始されることを保証するには、 [.filename]#/etc/rc.conf# に以下の変更をいれてください。 [.programlisting] .... named_enable="YES" .... デーモンを手動で起動するためには (設定をした後で) [source,shell] .... # ndc start .... === 設定ファイル ==== `make-localhost` の利用 次のコマンドが [source,shell] .... # cd /etc/namedb # sh make-localhost .... ローカル逆引き DNS ゾーンファイルを [.filename]#/etc/namedb/localhost.rev# に適切に作成することを確認してください。 ==== [.filename]#/etc/namedb/named.conf# [.programlisting] .... // $FreeBSD$ // // 詳細については named(8) マニュアルページを参照してください。プライマリサーバ // を設定するつもりなら、DNS がどのように動作するかの詳細を確実に理解してくださ // い。単純な間違いであっても、影響をうける相手に対する接続を壊したり、無駄な // インターネットトラフィックを大量に引き起こし得ます。 options { directory "/etc/namedb"; // "forwarders" 節に加えて次の行を有効にすることで、ネームサーバに決して自発的 // に問い合わせを発せず、常にそのフォワーダにたいして尋ねるように強制すること // ができます: // // forward only; // あなたが上流のプロバイダ周辺の DNS サーバを利用できる場合、その IP アドレス // をここに入力し、下記の行を有効にしてください。こうすれば、そのキャッシュの // 恩恵にあやかることができ、インターネット全体の DNS トラフィックが減るでしょう。 /* forwarders { 127.0.0.1; }; */ .... コメントが言っている通り、上流のキャッシュの恩恵を受けるために `forwarders` をここで有効にすることができます。 通常の状況では、ネームサーバはインターネットの特定のネームサーバを調べて、 探している返答を見つけるまで再帰的に問い合わせを行います。 これが有効になっていれば、まず上流のネームサーバ (または 与えられたネームサーバ) に問い合わせて、 そのキャッシュを利用するでしょう。 問い合わせをする上流のネームサーバが極度に通信量が多く、 高速であった場合、これを有効にする価値があるかもしれません。 [WARNING] ==== ここに `127.0.0.1` を指定しても動作 _しません_。 上流のネームサーバの IP アドレスに変更してください。 ==== [.programlisting] .... /* * あなたと利用したいネームサーバとの間にファイアウォールがある場合、 * 下記の quiery-source 指令を有効にする必要があるでしょう。 * 過去の BIND のバージョンは常に 53 番ポートに問い合わせをしますが、 * BIND 8.1 はデフォルトで非特権ポートを使用します。 */ // query-source address * port 53; /* * 砂場内で動作させている場合、ダンプファイルのために異なる場所を指定 * しなければならないかもしれません。 */ // dump-file "s/named_dump.db"; }; // 注意: 下記は将来のリリースで対応されるでしょう。 /* host { any; } { topology { 127.0.0.0/8; }; }; */ // セカンダリを設定することはより簡単な方法で、そのおおまかな姿が下記で説明さ // れています。 // // ローカルネームサーバを有効にする場合、このサーバが最初に尋ねられるように // /etc/resolv.conf に 127.0.0.1 を入力することを忘れないでください。さらに、 // /etc/rc.conf 内で有効にすることも確認してください。 zone "." { type hint; file "named.root"; }; zone "0.0.127.IN-ADDR.ARPA" { type master; file "localhost.rev"; }; zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.INT" { type master; file "localhost.rev"; }; // 注意: 下記の IP アドレスを使用しないでください。これはダミーでありデモや文書 // だけを目的としたものです。 // // セカンダリ設定の例です。少なくともあなたのドメインが属するゾーンに対するセカ // ンダリになることは便利かもしれません。プライマリの責を負っている IP アドレス // をネットワーク管理者に尋ねてください。 // // 逆引き参照ゾーン (IN-ADDR.ARPA) を含めることを決して忘れないでください! // (これは ".IN-ADDR.ARPA" を付け加えられたそれぞれの IP アドレスの最初のバイト // の逆順です。) // // プライマリゾーンの設定をはじめる前に DNS および BIND がどのように動作するか // 完全に理解してください。時々自明でない落し穴があります。それに比べるとセカン // ダリを設定するのは単純です。 // // 注意: 下記の例を鵜呑みにして有効にしないでください。:-) 実際の名前とアドレス // を代わりに使用してください。 // // 注意!!! FreeBSD は bind を砂場のなかで動かします (rc.conf 内の named_flags // を参照してください)。セカンダリゾーンを含んだディレクトリは、bind によって // 書き込み可能でなければなりません。次の手順が推奨されます: // // mkdir /etc/namedb/s // chown bind:bind /etc/namedb/s // chmod 750 /etc/namedb/s .... BIND を砂場 (sandbox) で (訳注: chroot をもちいて) 動作させるための詳細は <> を参照してください。 [.programlisting] .... /* zone "example.com" { type slave; file "s/example.com.bak"; masters { 192.168.1.1; }; }; zone "0.168.192.in-addr.arpa" { type slave; file "s/0.168.192.in-addr.arpa.bak"; masters { 192.168.1.1; }; }; */ .... [.filename]#named.conf# の中で、 上記は転送と逆引きゾーンのためのスレーブエントリの例です。 新しくサービスするそれぞれのゾーンについて、新規のエントリを [.filename]#named.conf# に加えなければいけません。 たとえば `example.org` に対する最もシンプルなゾーンエントリは以下のようになります。 [.programlisting] .... zone "example.org" { type master; file "example.org"; }; .... このゾーンは `type` 命令で示されているようにマスタで、ゾーン情報を `file` 命令で指示された [.filename]#/etc/namedb/example.org# ファイルに保持しています。 [.programlisting] .... zone "example.org" { type slave; file "example.org"; }; .... スレーブの場合、 ゾーン情報は特定のゾーンのマスタネームサーバから転送され、 指定されたファイルに保存されます。 マスタサーバが停止するか到達できない場合には、 スレーブサーバが転送されたゾーン情報を保持していて、 サービスできるでしょう。 ==== ゾーンファイル `example.org` に対するマスタゾーンファイル ([.filename]#/etc/namedb/example.org# に保持されます) の例は以下のようになります。 [.programlisting] .... $TTL 3600 example.org. IN SOA ns1.example.org. admin.example.org. ( 5 ; Serial 10800 ; Refresh 3600 ; Retry 604800 ; Expire 86400 ) ; Minimum TTL ; DNS Servers @ IN NS ns1.example.org. @ IN NS ns2.example.org. ; Machine Names localhost IN A 127.0.0.1 ns1 IN A 3.2.1.2 ns2 IN A 3.2.1.3 mail IN A 3.2.1.10 @ IN A 3.2.1.30 ; Aliases www IN CNAME @ ; MX Record @ IN MX 10 mail.example.org. .... "." が最後についているすべてのホスト名は正確なホスト名であり、 一方で "." で終了しないすべての行はオリジンが参照されることに注意してください。 たとえば `www` は `www + オリジン` に展開されます。この架空のゾーンファイルでは、 オリジンは `example.org.` なので `www` は `www.example.org.` に展開されます。 ゾーンファイルの書式は次のとおりです。 [.programlisting] .... recordname IN recordtype value .... DNS レコードに使われる最も一般的なものは以下のとおりです。 SOA:: ゾーン権威の起点 NS:: 権威のあるネームサーバ A:: ホストのアドレス CNAME:: 別名としての正規の名称 MX:: メールエクスチェンジャ PTR:: ドメインネームポインタ (逆引き DNS で使用されます) [.programlisting] .... example.org. IN SOA ns1.example.org. admin.example.org. ( 5 ; Serial 10800 ; Refresh after 3 hours 3600 ; Retry after 1 hour 604800 ; Expire after 1 week 86400 ) ; Minimum TTL of 1 day .... `example.org.`:: このゾーンのオリジンでもあるドメイン名 `ns1.example.org.`:: このゾーンに対して権威のあるプライマリネームサーバ `admin.example.org.`:: このゾーンの責任者。@ を置き換えた電子メールアドレスを指定します。 (mailto:admin@example.org[admin@example.org] は `admin.example.org` になります) `5`:: ファイルのシリアル番号です。 これはファイルが変更されるたびに増加させる必要があります。 現在では多くの管理者は `yyyymmddrr` という形式をシリアル番号として使用することを好みます。 2001041002 は最後に修正されたのが 2001/04/10 で、後ろの 02 はその日で二回目に修正されたものであるということを意味するでしょう。 シリアル番号は、 それが更新されたときにスレーブネームサーバに対してゾーンを通知するので重要です。 [.programlisting] .... @ IN NS ns1.example.org. .... これは `NS` エントリです。 このゾーンに対して権威のある返答を返すネームサーバはすべて、 このエントリを一つ有していなければなりません。 ここにある `@` は `example.org.` を意味します。 `@` はオリジンに展開されます。 [.programlisting] .... localhost IN A 127.0.0.1 ns1 IN A 3.2.1.2 ns2 IN A 3.2.1.3 mail IN A 3.2.1.10 @ IN A 3.2.1.30 .... `A` レコードはマシン名を示します。 上記のように `ns1.example.org` は `3.2.1.2` に結びつけられるでしょう。 ふたたびオリジンを示す `@` がここに使用されていますが、これは `example.org` が `3.2.1.30` に結び付けられることを意味しています。 [.programlisting] .... www IN CNAME @ .... `CNAME` レコードは通常マシンに別名を与えるときに使用されます。 例では `www` はオリジン、すなわち `example.org` (`3.2.1.30`) のアドレスをふられたマシンへの別名を与えます。 `CNAME` はホスト名の別名、 または複数のマシン間で一つのホスト名をラウンドロビン (訳注: 問い合わせがあるたびに別の IP アドレスを返すことで、 一台にアクセスが集中することを防ぐ手法) するときに用いられます。 [.programlisting] .... @ IN MX 10 mail.example.org. .... `MX` レコードは、 ゾーンに対してどのメールサーバがやってきたメールを扱うことに責任を持っているかを示します。 `mail.example.org` はメールサーバのホスト名で、10 はメールサーバの優先度を示します。 優先度が 3,2 または 1 などのメールサーバをいくつも置くことができます。 `example.org` へ送ろうとしているメールサーバははじめに一番優先度の高いメールサーバに接続しようとします。 そして接続できない場合、二番目に優先度の高いサーバに接続しようとし、 以下、メールが適切に配送されるまで同様に繰り返します。 in-addr.arpa ゾーンファイル (逆引き DNS) に対しても `A` または `CNAME` の代わりに `PTR` エントリが用いられることを除けば、 同じ書式が使われます。 [.programlisting] .... $TTL 3600 1.2.3.in-addr.arpa. IN SOA ns1.example.org. admin.example.org. ( 5 ; Serial 10800 ; Refresh 3600 ; Retry 604800 ; Expire 3600 ) ; Minimum @ IN NS ns1.example.org. @ IN NS ns2.example.org. 2 IN PTR ns1.example.org. 3 IN PTR ns2.example.org. 10 IN PTR mail.example.org. 30 IN PTR example.org. .... このファイルは上記の架空のドメインの IP アドレスからホスト名への対応を与えます。 === キャッシュネームサーバ キャッシュネームサーバはどのゾーンに対しても権威をもたないネームサーバです。 キャッシュネームサーバは単に自分で問い合わせをし、 後で使えるように問い合わせの結果を覚えておきます。 これを設定するには、ゾーンを何も含まずに、 通常通りネームサーバを設定してください。 [[network-named-sandbox]] === 砂場で named を実行する セキュリティを強めるために man:named[8] を非特権ユーザで実行し、 砂場のディレクトリ内に man:chroot[8] して実行したいと思うかもしれません。 こうすると named デーモンは砂場の外にはまったく手を出すことができません。 named が乗っ取られたとしても、 これによって起こりうる損害が小さくなるでしょう。 FreeBSD にはデフォルトで、そのための `bind` というユーザとグループがあります。 [NOTE] ==== 多くの人々は named を `chroot` するように設定する代わりに、 man:jail[8] 環境内で named を実行することを奨めるでしょう。 この節ではそれは扱いません。 ==== named は砂場の外 (共有ライブラリ、ログソケットなど) にアクセスできないので、 named を正しく動作させるためにいくつもの段階を経る必要があります。 下記のチェックリストにおいては、砂場のパスは [.filename]#/etc/namedb# で、 このディレクトリの内容には何も手を加えていないと仮定します。 `root` 権限で次のステップを実行してください。 * named が存在することを期待しているディレクトリをすべて作成します。 + [source,shell] .... # cd /etc/namedb # mkdir -p bin dev etc var/tmp var/run master slave # chown bind:bind slave var/* <.> .... + <.> これらのディレクトリに対して named が必要なのは書き込み権限だけなので、それだけを与えます。 * 基本ゾーンファイルと設定ファイルの編集と作成を行います。 + [source,shell] .... # cp /etc/localtime etc <.> # mv named.conf etc && ln -sf etc/named.conf # mv named.root master # sh make-localhost && mv localhost.rev localhost-v6.rev master # cat > master/named.localhost $ORIGIN localhost. $TTL 6h @ IN SOA localhost. postmaster.localhost. ( 1 ; serial 3600 ; refresh 1800 ; retry 604800 ; expiration 3600 ) ; minimum IN NS localhost. IN A 127.0.0.1 ^D .... + <.> これは named が man:syslogd[8] に正しい時刻でログを書き込むことを可能にします。 * 4.9-RELEASE より前のバージョンの FreeBSD を使用している場合、 静的リンクされた named-xfer を構築し、砂場にコピーしてください。 + [source,shell] .... # cd /usr/src/lib/libisc # make cleandir && make cleandir && make depend && make all # cd /usr/src/lib/libbind # make cleandir && make cleandir && make depend && make all # cd /usr/src/libexec/named-xfer # make cleandir && make cleandir && make depend && make NOSHARED=yes all # cp named-xfer /etc/namedb/bin && chmod 555 /etc/namedb/bin/named-xfer<.> .... + 静的リンクされた `named-xfer` をインストールしたら、 ソースツリーの中にライブラリまたはプログラムの古くなったコピーを残さないように、 掃除する必要があります。 + [source,shell] .... # cd /usr/src/lib/libisc # make cleandir # cd /usr/src/lib/libbind # make cleandir # cd /usr/src/libexec/named-xfer # make cleandir .... + <.> このステップは時々失敗することが報告されています。 もし失敗した場合、次のコマンドを実行してください。そして [.filename]#/usr/obj# ツリーを削除します。これはソースツリーからすべての "がらくた" を一掃します。 もう一度上記の手順を行うと、今度はうまく動作するでしょう。 + バージョン 4.9-RELEASE 以降の FreeBSD を使用している場合 [.filename]#/usr/libexec# にある `named-xfer` のコピーはデフォルトで静的リンクされています。 砂場にコピーするために単純に man:cp[1] が使えます。 * named が見ることができ、 書き込むことのできる [.filename]#dev/null# を作成します。 + [source,shell] .... # cd /etc/namedb/dev && mknod null c 2 2 # chmod 666 null .... * [.filename]#/etc/namedb/var/run/ndc# から [.filename]#/var/run/ndc# へのシンボリックリンクを作成します。 + [source,shell] .... # ln -sf /etc/namedb/var/run/ndc /var/run/ndc .... + [NOTE] ==== これは単に man:ndc[8] を実行するたびに `-c` オプションを指定しなくてもよいようにするだけです。 /var/run の中身は起動時に削除されるため、 これが有用だと思うなら、このコマンドをルートの crontab に `@reboot` オプションを指定して追加してください。 詳細については man:crontab[5] を参照してください。 ==== * named が書き込める追加の [.filename]#log# ソケットを作成するように man:syslogd[8] を設定します。 これを行うためには、[.filename]#/etc/rc.conf# 内の `syslogd_flags` 変数に `-l /etc/namedb/dev/log` を加えてください。 * 次の行を [.filename]#/etc/rc.conf# に加えて named が起動し、 自身を砂場内に `chroot` するように調整します + [.programlisting] .... named_enable="YES" named_flags="-u bind -g bind -t /etc/namedb /etc/named.conf" .... + [NOTE] ==== 設定ファイル _/etc/named.conf_ は _砂場のディレクトリに対して相対的な_ フルパスで表されることに注意してください。 つまり、上記の行で示されたファイルは実際には [.filename]#/etc/namedb/etc/named.conf# です。 ==== 次のステップは named がどのゾーンを読み込むか、 そしてディスク上のどこにゾーンファイルがあるのかを知るために [.filename]#/etc/namedb/etc/named.conf# を編集することです。 下記に例をコメントを加えて示します (ここで特にコメントされていない内容については、 砂場の中で動作させない DNS サーバの設定と同じです)。 [.programlisting] .... options { directory "/";<.> named-xfer "/bin/named-xfer";<.> version ""; // Don't reveal BIND version query-source address * port 53; }; // ndc control socket controls { unix "/var/run/ndc" perm 0600 owner 0 group 0; }; // Zones follow: zone "localhost" IN { type master; file "master/named.localhost";<.> allow-transfer { localhost; }; notify no; }; zone "0.0.127.in-addr.arpa" IN { type master; file "master/localhost.rev"; allow-transfer { localhost; }; notify no; }; zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.int" { type master; file "master/localhost-v6.rev"; allow-transfer { localhost; }; notify no; }; zone "." IN { type hint; file "master/named.root"; }; zone "private.example.net" in { type master; file "master/private.example.net.db"; allow-transfer { 192.168.10.0/24; }; }; zone "10.168.192.in-addr.arpa" in { type slave; masters { 192.168.10.2; }; file "slave/192.168.10.db";<.> }; .... <.> `directory` は [.filename]#/# を指定します。 named が必要とするファイルはすべてこのディレクトリにあります。 (この指定は "通常の" (訳注: 砂場内で動作させない) ユーザにとっての [.filename]#/etc/namedb# と等価です)。 <.> `named-xfer` バイナリへの (named にとっての) フルパスを指定します。 named はデフォルトで `named-xfer` を [.filename]#/usr/libexec# から探すようにコンパイルされているので、これが必要です <.> このゾーンに対するゾーンファイルを named が見つけられるようにファイル名を (上記と同様に `directory` からの相対パスで) 指定します。 <.> このゾーンに対するゾーン情報がマスタサーバからが転送されたあとに、 named がゾーンファイルのコピーを書き込むファイル名を (上記と同様に `directory` からの相対パスで) 指定します。これが、上記のように設定段階で [.filename]#slave# ディレクトリの所有者を `bind` に変更する理由です。 上記のステップを完了したら、サーバを再起動するか man:syslogd[8] を再起動し、man:named[8] を起動してください。その際、 `syslogd_flags` および `named_flags` に新たに指定したオプションが有効になっていることを確かめてください。 これで named を砂場のなかで動作させることができているはずです! === セキュリティ BIND は DNS の最も一般的な実装ではありますが、 常にセキュリティ問題を抱えています。 問題になり得る、また悪用可能なセキュリティホールが時々みつかります。 現在のインターネットおよび FreeBSD のセキュリティ問題について常に最新の情報を得るために http://www.cert.org/[CERT] および crossref:eresources[eresources-mail,freebsd-security-notifications] を購読するとよいでしょう。 [TIP] ==== 問題が生じたとしても、 最新のソースからビルドした named を用意しておけば、 問題にならないかもしれません。 ==== === さらなる情報源 BIND/named のマニュアルページ: man:ndc[8] man:named[8] man:named.conf[8] * http://www.isc.org/products/BIND/[ISC Bind 公式ページ] * http://www.nominum.com/getOpenSourceResource.php?id=6[ BIND FAQ] * http://www.oreilly.com/catalog/dns4/[O'Reilly DNS and BIND 4th Edition] * link:ftp://ftp.isi.edu/in-notes/rfc1034.txt[RFC1034 - Domain Names - Concepts and Facilities] (ドメイン名、その概念と基盤) * link:ftp://ftp.isi.edu/in-notes/rfc1035.txt[RFC1035 - Domain Names - Implementation and Specification] (ドメイン名、その実装と仕様) [[network-ntp]] == NTP === 概説 時間の経過とともに、コンピュータの時計はずれてしまいがちです。 時間が経つと、コンピュータの時計は正確でなくなってゆきます。 NTP (Network Time Protocol) は時計が正確であることを保証する方法の一つです。 インターネットサービスの多くは、 コンピュータの時計が正確であることに依存しているか、 あるいは多くを負っています。 たとえば web サーバ は、 あるファイルがある時刻以降に修正されていたらそのファイルを送ってほしいという要求を受け取るかもしれません。 man:cron[8] のようなサービスは所定の時間にコマンドを実行します。 時計が正確でない場合、 これらのコマンドは期待したとおりには実行されないかもしれません。 FreeBSD は man:ntpd[8] NTP サーバを搭載しています。これは、 マシンの時計を合わせるために他の NTP サーバに問い合わせをしたり、 他のマシンに対して時刻を報じるために使用できます。 === 適切な NTP サーバの選択 時刻を同期するために利用する NTP サーバを、 一つ以上見つける必要があります。 ネットワーク管理者、または ISP はこの目的のために NTP サーバを設定しているかもしれません - 本当にそうなのか確かめるためにドキュメントを確認してください。 あなたの近くの NTP サーバを探せる http://www.eecis.udel.edu/~mills/ntp/servers.html[公にアクセス可能な NTP サーバのリスト] があります。 どのサーバを選択するとしても、そのサーバの運営ポリシを理解し、 要求されているなら利用許可を求めることを忘れないでください。 使用しているサーバのうちのどれかが到達不能になるか、 その時計の信頼性が低い場合、無関係の NTP サーバをいくつか選択するとよいでしょう。 man:ntpd[8] は他のサーバから受け取った応答を賢く利用します - 信頼できないサーバより信頼できるサーバを重視します。 === マシンの設定 ==== 基本設定 マシンが起動するときだけ時計を同期させたい場合は man:ntpdate[8] が使えます。頻繁に再起動され、 たまに同期すれば十分なデスクトップマシンには適切かもしれません。 しかしほとんどのマシンでは man:ntpd[8] を実行するべきです。 man:ntpd[8] を動かしているマシンでも、起動時に man:ntpdate[8] を使用するのはよい考えです。 man:ntpd[8] プログラムは時計を徐々に変更します。しかし man:ntpdate[8] は正しい時刻と現在設定されているマシンの時刻がどんなに離れていようとも時計を設定します。 起動時に man:ntpdate[8] を有効にするためには、 `ntpdate_enable="YES"` を [.filename]#/etc/rc.conf# に追加してください。 さらに、同期したいすべてのサーバおよび、man:ntpdate[8] に渡すあらゆるフラグを `ntpdate_flags` に指定する必要があるでしょう。 ==== 一般設定 NTP は man:ntp.conf[5] に記述された書式の [.filename]#/etc/ntp.conf# ファイルによって設定されます。 簡単な例を以下に示します。 [.programlisting] .... server ntplocal.example.com prefer server timeserver.example.org server ntp2a.example.net driftfile /var/db/ntp.drift .... `server` オプションは、 使用するサーバを一行に一つずつ指定します。サーバが上記の `ntplocal.example.com` のように `prefer` 引数とともに指定された場合、 このサーバは他のサーバより優先されます。 優先されたサーバからの応答は、 他のサーバの応答と著しく異なる場合は破棄されますが、 そうでなければ他の応答を考慮することなく使用されます。 `prefer` 引数は、通常、 特別な時間モニタハードウェアを備えているような非常に正確であるとされている NTP サーバに対して使用されます。 `driftfile` オプションはシステム時計の周波数オフセットを格納するために使用するファイルを指定します。 man:ntpd[8] プログラムは、 時計の自然変動を自動的に補正するためにこれを用います。 これにより、一定時間外部の時刻ソースから切り離されたとしても、 十分正確な時刻を維持することを可能にします。 `driftfile` オプションは、使用している NTP サーバから過去に受け取った応答に関する情報を格納するために、 どのファイルが使用されるか指定します。 このファイルは NTP に関する内部情報を含んでいます。 これは他のプロセスによって修正されてはいけません。 ==== サーバへのアクセス制御 デフォルトでは NTP サーバはインターネット上のすべてのホストからアクセスが可能です。 [.filename]#/etc/ntp.conf# 内で `restrict` オプションを指定することによって、 どのマシンがサーバにアクセスできるかを制御できるようにします。 NTP サーバにアクセスするマシンのすべてを拒否したいのなら、 以下の行を [.filename]#/etc/ntp.conf# に追加してください。 [.programlisting] .... restrict default ignore .... あなたのネットワーク内のマシンにだけサーバに接続して時計を同期することを認めたいが、 それらからサーバに対して設定を行うのを許さず、 同期する端末としても利用されないようにしたいのなら、 以下を加えてください。 [.programlisting] .... restrict 192.168.1.0 mask 255.255.255.0 notrust nomodify notrap .... `192.168.1.0` をあなたのネットワークの IP アドレスに `255.255.255.0` をあなたのネットワークのネットマスクに置き換えてください。 [.filename]#/etc/ntp.conf# には複数の `restrict` オプションを置けます。 詳細に付いては man:ntp.conf[5] の `Access Control Support` サブセクションを参照してください。 === NTP サーバの実行 NTP サーバが起動時に実行されることを保証するために、 `xntpd_enable="YES"` を [.filename]#/etc/rc.conf# に加えてください。 man:ntpd[8] にフラグを追加したい場合は [.filename]#/etc/rc.conf# 内の `xntpd_flags` パラメータを編集してください。 マシンを再起動することなくサーバを実行したいときは、 [.filename]#/etc/rc.conf# 内の `xntpd_flags` で追加されたパラメータをすべて指定して `ntpd` を実行してください。以下に例を示します。 [source,shell] .... # ntpd -p /var/run/ntpd.pid .... [NOTE] ==== FreeBSD 5.X では [.filename]#/etc/rc.conf# 内のさまざまなオプションの名前が変わりました。 したがって、上記の `xntpd` に関するオプションは `ntpd` に置き換えてください。 ==== === 一時的なインターネット接続で ntpd を使用する man:ntpd[8] プログラムは正しく機能するために、 インターネットへの常時接続を必要としません。しかしながら、 オンデマンドでダイアルアップされるように設定された一時的な接続の場合、 NTP トラフィックがダイアルを引き起こしたり、 接続を維持し続けるようなことを避けるようにした方がよいでしょう。 ユーザ PPP を使用している場合、以下の例のように [.filename]#/etc/ppp/ppp.conf# 内で `filter` ディレクティブが使用できます。 [.programlisting] .... set filter dial 0 deny udp src eq 123 # Prevent NTP traffic from initiating dial out set filter dial 1 permit 0 0 set filter alive 0 deny udp src eq 123 # Prevent incoming NTP traffic from keeping the connection open set filter alive 1 deny udp dst eq 123 # Prevent outgoing NTP traffic from keeping the connection open set filter alive 2 permit 0/0 0/0 .... 詳細については man:ppp[8] 内の `PACKET FILTERING` セクション、および [.filename]#/usr/shared/examples/ppp/# 内の例を参照してください。 [NOTE] ==== 小さい番号のポートをブロックするインターネットアクセスプロバイダでは、 応答があなたのマシンに到達しないので NTP がきちんと動作しない場合もあります。 ==== === さらなる情報源 NTP サーバに関する文書は HTML 形式で [.filename]#/usr/shared/doc/ntp/# にあります。 [[network-natd]] == ネットワークアドレス変換 (NAT) [[network-natoverview]] === 概要 一般に man:natd[8] として知られている FreeBSD ネットワークアドレス変換デーモンは、 raw IP パケットを受信して、 ソースアドレスをローカルマシンに変更し、 そのパケットを外向きの IP パケットの流れに再注入するデーモンです。 man:natd[8] は、 データが戻ってきたときに、データの本来の場所を判別し、 もともと要求した相手へデータを返すことができるようにソース IP アドレスとポートを変更します。 NAT の最も一般的な使用法は、 一般的にはインターネット接続共有として知られているものを実行することです。 [[network-natsetup]] === 設定 IPv4 の IP 空間が足りなくなりつつあること、および、 ケーブルや DSL のような高速の加入者回線利用者の増加によって、 人々はますますインターネット接続を共有する手段を必要としています。 一つの接続および IP アドレスを通していくつものコンピュータを回線に接続する能力がある man:natd[8] が合理的な選択になります。 もっともよくあるのは、ユーザが 1 つの IP アドレスでケーブルまたは DSL 回線に接続されたマシンを持っており、 インターネットへのアクセスを LAN 経由でいくつかのコンピュータに提供するのに、 この接続されたコンピュータを使用したいという場合です。 そのためには、インターネットに接続されている FreeBSD マシンはゲートウェイとして動作しなければなりません。 このゲートウェイマシンは 2 つの NIC が必要です (1 つはインターネットルータへ接続するためで、もう 1 つは LAN に接続するためです)。 LAN 上のすべてのマシンはハブまたはスイッチを通して接続されます。 image::natd.png[ネットワークレイアウト] インターネット接続を共有するために、 このような設定がよく使用されています。 LAN 内のマシンの 1 台がインターネットに接続しています。 残りのマシンはその "ゲートウェイ" マシンを通してインターネットにアクセスします。 [[network-natdkernconfiguration]] === 設定 次のオプションがカーネルコンフィギュレーションファイルに必要です。 [.programlisting] .... options IPFIREWALL options IPDIVERT .... さらに、次のオプションを入れてもよいでしょう。 [.programlisting] .... options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_VERBOSE .... 下記の設定を [.filename]#/etc/rc.conf# で行わなければなりません。 [.programlisting] .... gateway_enable="YES" firewall_enable="YES" firewall_type="OPEN" natd_enable="YES" natd_interface="fxp0" natd_flags="" .... [.informaltable] [cols="1,1", frame="none"] |=== |gateway_enable="YES" |マシンがゲートウェイとして動作するように設定します。 `sysctl net.inet.ip.forwarding=1` コマンドを実行しても同じ効果がえられます。 |firewall_enable="YES" |[.filename]#/etc/rc.firewall# にあるファイアウォールルールを起動時に有効にします。 |firewall_type="OPEN" |これはあらかじめ定義されている、 すべてのパケットを通すファイアウォールルールセットを指定します。 他のタイプについては [.filename]#/etc/rc.firewall# を参照してください。 |natd_interface="fxp0" |パケットを転送するインタフェースを指定します (インターネットに接続されたインタフェース)。 |natd_flags="" |起動時に man:natd[8] に渡される追加の引数 |=== [.filename]#/etc/rc.conf# に前述したオプションを定義すると、起動時に `natd -interface fxp0` が実行されます。 これは手動でも実行できます。 [NOTE] ==== オプションの定義に man:natd[8] のコンフィグレーションファイルを使うこともできます。 この場合には、[.filename]#/etc/rc.conf# に以下の行を追加し、 コンフィグレーションファイルを定義してください。 [.programlisting] .... natd_flags="-f /etc/natd.conf" .... [.filename]#/etc/natd.conf# ファイルでは、一行ごとにオプションを設定します。たとえば、 次節の例では以下のような行を含むファイルを用意してください。 [.programlisting] .... redirect_port tcp 192.168.0.2:6667 6667 redirect_port tcp 192.168.0.3:80 80 .... コンフィグレーションファイルに関する、より詳細な情報については、 man:natd[8] マニュアルページの `-f` オプションを調べてください。 ==== LAN にぶら下がっているマシンおよびインタフェースのそれぞれには link:ftp://ftp.isi.edu/in-notes/rfc1918.txt[RFC 1918] で定義されているプライベートネットワーク空間の IP アドレス番号を割り当て、デフォルトゲートウェイアドレスを natd マシンの内側の IP アドレスにすべきです。 たとえば LAN 側のクライアント `A` および `B` は IP アドレス `192.168.0.2` および `192.168.0.3` を割り当てられており、 natd マシンの LAN インタフェースは IP アドレス `192.168.0.1` を割り当てられています。 クライアント `A` および `B` のデフォルトゲートウェイは natd マシンの `192.168.0.1` に設定されなければなりません。 natd マシンの外部、 またはインターネットインタフェースは man:natd[8] の動作に際して特別の修正を必要としません。 [[network-natdport-redirection]] === ポート転送 man:natd[8] の短所は、インターネットから LAN 内のクライアントにアクセスできないということです。 LAN 内のクライアントは外部に向けて接続を行うことはできますが、 入って来るものを受け取ることができません。これは、LAN クライアントのどれかでインターネットサービスを動かそうとした場合に、 問題になります。これを何とかする単純な方法は natd マシンから LAN クライアントへ、 選択したインターネットポートを転送することです。 たとえばクライアント `A` で実行されている IRC サーバがあり、 クライアント `B` 上で実行されている web サーバがあるとします。 これが正しく動作するには、ポート 6667 (IRC) および 80 (web) への接続を対応するマシンに転送しなければなりません。 `-redirect_port` に適切なオプションを加えて man:natd[8] に渡さなければなりません。 書式は以下のとおりです。 [.programlisting] .... -redirect_port proto targetIP:targetPORT[-targetPORT] [aliasIP:]aliasPORT[-aliasPORT] [remoteIP[:remotePORT[-remotePORT]]] .... 上記の例では、引数は以下のようにします。 [.programlisting] .... -redirect_port tcp 192.168.0.2:6667 6667 -redirect_port tcp 192.168.0.3:80 80 .... これで適切な _tcp_ ポートが LAN クライアントマシンに転送されます。 `-redirect_port` 引数は個々のポートを対応させるポート範囲を示すのに使えます。 たとえば _tcp 192.168.0.2:2000-3000 2000-3000_ は 2000 番から 3000番ポートに受け取られたすべての接続を、 クライアント `A` 上の 2000 番から 3000 番に転送します。 これらのオプションは man:natd[8] を直接実行するか、 [.filename]#/etc/rc.conf# 内の `natd_flags=""` オプションで設定するか、 もしくはコンフィグレーションファイルから渡してください。 設定オプションの詳細については man:natd[8] をご覧ください。 [[network-natdaddress-redirection]] === アドレス転送 複数の IP アドレスが利用可能ですが、 それらが 1 台のマシン上になければならないときには、 アドレス転送が便利です。 これを用いれば man:natd[8] は LAN クライアントのそれぞれに外部 IP アドレスを割り当てることができます。 man:natd[8] は LAN クライアントから外部へ出て行くパケットを適切な外部の IP アドレスで書き直し、 そして特定の IP アドレスに対してやって来るトラフィックのすべてを、 指定された LAN クライアントに転送します。 これは静的 NAT としても知られています。 たとえば `128.1.1.1`, `128.1.1.2` および `128.1.1.3` の IP アドレスが、 natd ゲートウェイマシンに属しているとします。 `128.1.1.2` および `128.1.1.3` は LAN クライアントの `A` および `B` に転送される一方で、`128.1.1.1` は natd ゲートウェイマシンの外部 IP アドレスとして使用することができます。 `-redirect_address` の書式は以下のとおりです。 [.programlisting] .... -redirect_address localIP publicIP .... [.informaltable] [cols="1,1", frame="none"] |=== |localIP |LAN クライアントの内部 IP アドレス |publicIP |LAN クライアントに対応する外部 IP アドレス |=== 上記の例では引数は以下のようになります。 [.programlisting] .... -redirect_address 192.168.0.2 128.1.1.2 -redirect_address 192.168.0.3 128.1.1.3 .... `-redirect_port` と同様に、これらの引数は [.filename]#/etc/rc.conf# 内の `natd_flags=""` オプションで設定するか、 コンフィグレーションファイルから渡すことで指定できます。 アドレス転送では、 特定の IP アドレスで受け取られたデータはすべて転送されるので、 port 転送は必要ありません。 natd マシン上の外部 IP アドレスは、 アクティブで外部インタフェースにエイリアスされていなければなりません。 やりかたは man:rc.conf[5] を参照してください。 [[network-inetd]] == inetd"スーパサーバ" [[network-inetd-overview]] === 概観 man:inetd[8] は複数のデーモンに対する接続を制御するので、 "インターネットスーパサーバ" と呼ばれます。 ネットワークサービスを提供するプログラムは、 一般的にデーモン呼ばれます。inetd は他のデーモンを管理するサーバを努めます。 接続が inetd によって受け付けられると、 inetd は接続がどのデーモンに対するものか判断して、 そのデーモンを起動し、ソケットを渡します。 inetd を 1 つ実行することにより、 それぞれのデーモンをスタンドアロンモードで実行することに比べ、 全体としてのシステム負荷を減らします。 基本的に、inetd は他のデーモンを起動するために使用されます。しかし、 chargen, auth および daytime のようなささいなプロトコルは直接扱われます。 この節ではコマンドラインオプションおよび設定ファイル [.filename]#/etc/inetd.conf# による inetd の設定の基本を説明します。 [[network-inetd-settings]] === 設定 inetd は [.filename]#/etc/rc.conf# の仕組によって初期化されます。 デフォルトでは `inetd_enable` オプションは "NO" に設定されています。 しかし多くの場合、sysinstall でセキュリティプロファイルを medium に設定することにより、有効化されます。 [.programlisting] .... inetd_enable="YES" .... または [.programlisting] .... inetd_enable="NO" .... を [.filename]#/etc/rc.conf# に置くことで、起動時に inetd を有効または無効にできます。 さらに `inetd_flags` オプションによって、 いろいろなコマンドラインオプションを inetd に渡すことができます。 [[network-inetd-cmdline]] === コマンドラインオプション inetd 書式 `inetd [-d] [-l] [-w] [-W] [-c maximum] [-C rate] [-a address | hostname] [-p filename] [-R rate] [configuration file]` -d:: デバッグモードにします。 -l:: 成功した接続のログをとります。 -w:: 外部サービスに対して TCP Wrapper を有効にします (デフォルト)。 -W:: inetd 組み込みの内部サービスに対して TCP Wrapper を有効にします (デフォルト)。 -c maximum:: サービス毎に同時に起動可能な最大値のデフォルトを指定します。 デフォルトでは無制限です。サービスごとに指定する `max-child` パラメータで上書きできます。 -C rate:: 1 分間にひとつの IP アドレスから起動されるサービスの、 最大値のデフォルトを指定します。デフォルトは無制限です。 サービスごとに指定する `max-connections-per-ip-per-minute` パラメータで上書きできます。 -R rate:: あるサービスを 1 分間に起動できる最大の数を指定します。 デフォルトは 256 です。rate に 0 を指定すると、 起動可能な数は無制限になります。 -a:: バインドする IP アドレスを一つ指定します。 代わりにホスト名も指定できます。この場合、ホスト名に対応する IPv4 または IPv6 アドレスが使用されます。通常 inetd が man:jail[8] 内で起動される時点で、ホスト名が指定されます。この場合、 ホスト名は man:jail[8] 環境に対応するものです。 + ホスト名指定が使用され、 IPv4 および IPv6 両方にバインドしたい場合、 [.filename]#/etc/inetd.conf# の各サービスに対して、 各バインドに対する適切なプロトコルのエントリが必要です。 たとえば TCP ベースのサービスは、 ひとつはプロトコルに "tcp4" を使用し、 もう一つは "tcp6" を使用する、 2 つのエントリが必要です。 -p:: デフォルトとは異なる PID を保持するファイルを指定します。 [.filename]#/etc/rc.conf# 内の `inetd_flags` オプションを用いて、これらのオプションを inetd に渡すことができます。デフォルトでは `inetd_flags` は "-wW" に設定されており、 これは inetd の内部および外部サービスに対して TCP wrapper を有効にします。 初心者ユーザはこれらのパラメータを変更する必要は通常ありませんし、 [.filename]#/etc/rc.conf# に入力する必要もありません。 [NOTE] ==== 外部サービスは、接続を受け取ったときに起動される inetd の外部にあるデーモンで、 それに対して、内部サービスは inetd 自身が提供する内部のデーモンです。 ==== [[network-inetd-conf]] === [.filename]#inetd.conf# inetd の設定は [.filename]#/etc/inetd.conf# ファイルによって制御されます。 [.filename]#/etc/inetd.conf# が変更されたときは、 以下のように inetd プロセスに HangUP シグナルを送ることにより、inetd に設定ファイルを再読み込みさせられます。 [[network-inetd-hangup]] .inetd への HangUP シグナル送付 [example] ==== [source,shell] .... # kill -HUP `cat /var/run/inetd.pid` .... ==== 設定ファイルのそれぞれの行は、 個々のデーモンについての指示になります。 ファイル内のコメントは "#" が先頭につきます。 [.filename]##/etc/inetd.conf## の書式は以下のとおりです。 [.programlisting] .... service-name socket-type protocol {wait|nowait}[/max-child[/max-connections-per-ip-per-minute]] user[:group][/login-class] server-program server-program-arguments .... IPv4 を利用する ftpd デーモンのエントリの例です。 [.programlisting] .... ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l .... service-name:: これは特定のデーモンのサービス名です。 これは [.filename]#/etc/services# 内のサービスリストに対応していなければなりません。 これは inetd がどのポートで受け付けなければならないかを決定します。 新しいサービスが作成された場合、まずはじめに [.filename]#/etc/services# 内に記載しなければなりません。 socket-type:: `stream`, `dgram`, `raw` または `seqpacket` のどれかを指定します。 `stream` はコネクションに基づいた TCP デーモンに使用しなければならず、 一方で `dgram` は UDP 転送プロトコルを利用したデーモンに対して使用されます。 protocol:: 次のうちのどれか 1 つを指定します。 + [.informaltable] [cols="1,1", options="header"] |=== | プロトコル | 説明 |tcp, tcp4 |TCP IPv4 |udp, udp4 |UDP IPv4 |tcp6 |TCP IPv6 |udp6 |UDP IPv6 |tcp46 |TCP IPv4 および v6 の両方 |udp46 |UDP IPv4 および v6 の両方 |=== {wait|nowait}[/max-child[/max-connections-per-ip-per-minute]]:: `wait|nowait` は inetd から起動したデーモンが、 自分のソケットを管理できるかどうかを示します。 通常マルチスレッド化されている stream ソケットデーモンは `nowait` を使用するべきである一方、 `dgram` ソケットタイプは wait オプションを使用しなければなりません。 `nowait` は新しいソケット毎に子のデーモンを起動する一方で、 `wait` は通常複数のソケットを 1 つのデーモンに渡します。 + inetd が起動できる子のデーモンの最大数は `max-child` オプションで設定できます。 特定のデーモンに対して、起動する数が 10 までという制限が必要な場合、 `nowait` の後に `/10` を置きます。 + `max-child` に加えて、他にある 1 つの場所から特定のデーモンへの最大接続数を制限するオプションが利用できます。 `max-connections-per-ip-per-minute` がそれです。ここに 10 を指定すると、特定の IP アドレスからの特定のサービスへの接続を 1 分間につき 10 回に制限します。 これは故意または故意でない資源の浪費および、 マシンへのサービス不能 (DoS) 攻撃を防ぐのに有用です。 + `wait` または `nowait` はこの欄に必ず必要です。 `max-child` および `max-connections-per-ip-per-minute` は任意です。 + `max-child` または `max-connections-per-ip-per-minute` 制限をかけない stream タイプのマルチスレッドデーモンの設定は `nowait` になります。 + 作成できる子プロセスの上限が 10 である同じデーモンの設定は `nowait/10` になります。 + さらに、 1 分間に IP アドレスあたりの接続制限が 20、 子プロセスの上限が 10 である同じデーモンの設定は `nowait/10/20` になります。 + 以下のように、これらのオプションはすべて fingerd デーモンのデフォルト設定に使われています。 + [.programlisting] .... finger stream tcp nowait/3/10 nobody /usr/libexec/fingerd fingerd -s .... user:: user はあるデーモンが実行するときのユーザ名を指定します。 一般的にデーモンは `root` ユーザとして実行します。セキュリティを考慮して、 いくつかのサーバは `daemon` ユーザ、 または最低の権限が与えられている `nobody` ユーザとして実行することも多く見られます。 server-program:: 接続を受け取ったときに実行するデーモンのフルパスです。 デーモンが inetd によって内部的に提供されるサービスの場合 `internal` を使用します。 server-program-arguments:: ここには、起動するときにデーモンに渡される、 argv[0] から始まる引数を指定して、 `server-program` と協調して動作します。 mydaemon -d がコマンドラインの場合、 `server program arguments` の値に `mydaemon -d` を指定します。 また、デーモンが内部サービスの場合、ここに `internal` を指定します。 [[network-inetd-security]] === セキュリティ インストールの時に選択したセキュリティプロファイルによっては、 多くの inetd のデーモンがデフォルトで有効になっているかもしれません。 あるデーモンが特に必要でない場合には、それを無効にしてください! 問題となっているデーモンが記述されている行の先頭に "#" をおいて <>を送ってください。 fingerd のようないくつかのデーモンは、 動かそうとすべきではないかもしれません。なぜなら、 それらは攻撃者に対してあまりにも多くの情報を与えるからです。 セキュリティをあまり考慮せず、 接続試行に対してタイムアウトまでの時間が長いか、 タイムアウトしないデーモンもあります。 これは、特定のデーモンに攻撃者がゆっくり接続要求を送ることによって、 利用可能なリソースを飽和させることを可能にします。ある種のデーモンに `ip-per-minute` および `max-child` 制限を設けることはよい考えかもしれません。 TCP wrapper はデフォルトで有効です。 inetd から起動されるさまざまなデーモンに対して TCP 制限を設けることの詳細については man:hosts_access[5] マニュアルページを参照してください。 [[network-inetd-misc]] === その他 daytime, time, echo, discard, chargen および auth はすべて inetd が内部的に提供するサービスです。 auth サービスは identity (ident, identd) ネットワークサービスを提供し、 ある程度設定可能です。 詳細については man:inetd[8] マニュアルを参照してください。 [[network-plip]] == パラレルライン IP (PLIP) PLIP はパラレルポート間で TCP/IP 通信を可能にします。 これはネットワークカードの無いマシンやノートパソコンにインストールするときに役に立ちます。 この節では以下について説明します。 * パラレル (ラップリンク または パラレルクロス) ケーブルの作成。 * 2 台のコンピュータの PLIP による接続。 [[network-create-parallel-cable]] === パラレル (クロス) ケーブルの作成 コンピュータ用品店のほとんどでパラレル (クロス) ケーブルを購入することができます。 購入することができないか、 単にケーブルがどのような構造であるか知りたい場合は、 次の表に通常のパラレルプリンタケーブルをもとに作成する方法が示されています。 .ネットワーク向けのパラレル (クロス) ケーブル結線 [cols="1*l,1*l,1*l,1,1*l", options="header"] |=== | A-名称 | A-端 | B-端 | 説明 | Post/Bit | .... DATA0 -ERROR .... | .... 2 15 .... | .... 15 2 .... |Data | .... 0/0x01 1/0x08 .... | .... DATA1 +SLCT .... | .... 3 13 .... | .... 13 3 .... |Data | .... 0/0x02 1/0x10 .... | .... DATA2 +PE .... | .... 4 12 .... | .... 12 4 .... |Data | .... 0/0x04 1/0x20 .... | .... DATA3 -ACK .... | .... 5 10 .... | .... 10 5 .... |Strobe | .... 0/0x08 1/0x40 .... | .... DATA4 BUSY .... | .... 6 11 .... | .... 11 6 .... |Data | .... 0/0x10 1/0x80 .... |GND |18-25 |18-25 |GND |- |=== [[network-plip-setup]] === PLIP の設定 はじめに、ラップリンクケーブルを入手しなければなりません。 次に、両方のコンピュータのカーネルが man:lpt[4] ドライバ対応であることを確認してください。 [source,shell] .... # grep lp /var/run/dmesg.boot lpt0: on ppbus0 lpt0: Interrupt-driven port .... パラレルポートは割り込み駆動ポートでなければなりません。 FreeBSD 4.X では、 以下のような行がカーネルコンフィギュレーションファイル内になければならないでしょう。 [.programlisting] .... device ppc0 at isa? irq 7 .... FreeBSD 5.X では [.filename]#/boot/device.hints# ファイルに以下の行がなければならないでしょう。 [.programlisting] .... hint.ppc.0.at="isa" hint.ppc.0.irq="7" .... それからカーネルコンフィギュレーションファイルに `device plip` という行があるか、または [.filename]#plip.ko# カーネルモジュールが読み込まれていることを確認してください。 どちらの場合でも man:ifconfig[8] コマンドを直接実行したときに、 パラレルネットワークインタフェースが現れるはずです。 FreeBSD 4.X ではこのようになります。 [source,shell] .... # ifconfig lp0 lp0: flags=8810 mtu 1500 .... FreeBSD 5.X ではこのようになります。 [source,shell] .... # ifconfig plip0 plip0: flags=8810 mtu 1500 .... [NOTE] ==== パラレルインタフェースに対して用いられるデバイス名は FreeBSD 4.X ([.filename]#lpX#) と FreeBSD 5.X ([.filename]#plipX#) 間で異なります。 ==== 両方のコンピュータのパラレルインタフェースにラップリンクケーブルを接続します。 両方のネットワークインタフェースパラメータを `root` で設定します。 たとえば、FreeBSD 4.X を動作させている `host1` と FreeBSD 5.X を動作させている `host2` の両ホストを接続したい場合は次のようにします。 [.programlisting] .... host1 <-----> host2 IP Address 10.0.0.1 10.0.0.2 .... 次のコマンドで `host1` 上のインタフェースを設定します。 [source,shell] .... # ifconfig lp0 10.0.0.1 10.0.0.2 .... 次のコマンドで `host2` 上のインタフェースを設定します。 [source,shell] .... # ifconfig plip0 10.0.0.2 10.0.0.1 .... さて、これで接続が確立したはずです。詳細については man:lp[4] および man:lpt[4] マニュアルページをご覧ください。 さらに[.filename]##/etc/hosts## に両ホストを加えるとよいでしょう。 [.programlisting] .... 127.0.0.1 localhost.my.domain localhost 10.0.0.1 host1.my.domain host1 10.0.0.2 host2.my.domain .... 接続がうまくいっているか確かめるために、 両方のホスト上で互いを ping してください。 たとえば `host1` で以下を実行します。 [source,shell] .... # ifconfig lp0 lp0: flags=8851 mtu 1500 inet 10.0.0.1 --> 10.0.0.2 netmask 0xff000000 # netstat -r Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire host2 host1 UH 0 0 lp0 # ping -c 4 host2 PING host2 (10.0.0.2): 56 data bytes 64 bytes from 10.0.0.2: icmp_seq=0 ttl=255 time=2.774 ms 64 bytes from 10.0.0.2: icmp_seq=1 ttl=255 time=2.530 ms 64 bytes from 10.0.0.2: icmp_seq=2 ttl=255 time=2.556 ms 64 bytes from 10.0.0.2: icmp_seq=3 ttl=255 time=2.714 ms --- host2 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 2.530/2.643/2.774/0.103 ms .... [[network-ipv6]] == IPv6 IPv6 (IPng "IP next generation" とも呼ばれます) は、著名な IP プロトコル (IPv4 とも呼ばれます) の新しいバージョンです。 他の最新の *BSD システムと同様に FreeBSD は KAME IPv6 リファレンス実装を含んでいます。したがって、あなたの FreeBSD システムには IPv6を試すために必要なものすべてが備わっています。 この節では IPv6 の設定と実行に関して説明します。 1990 年代のはじめには、人々は IPv4 アドレス空間が急速に縮小していることに気づくようになりました。 インターネットの成長率が増大するにしたがって、 2 つの心配ごとがでてきました。 * アドレスの枯渇。 今日では、プライベートアドレス空間 (`10.0.0.0/8`, `192.168.0.0/24` など) およびネットワークアドレス変換 (NAT) が使用されているので、それほど心配されていません。 * ルーティングテーブルのエントリが大きくなりすぎていました。 これは今でも心配な事柄です。 IPv6 は以下の、そしてその他多くの問題を扱います。 * 128 bit アドレス空間。言い換えると、理論上 340,282,366,920,938,463,463,374,607,431,768,211,456 個のアドレスが利用可能です。これは地球上の一平方メータあたり、 およそ 6.67 * 10^27 個の IPv6 アドレスがあることを意味します。 * ルータは、 ルーティングテーブル内にネットワーク集約アドレスだけを格納することで、 ルーティングテーブルの平均を 8192 項目程度に減らします。 他にも以下のように IPv6 の便利な機能がたくさんあります。 * アドレス自動設定 (RFC2462) * エニーキャスト (anycast) アドレス ("one-out-of many" 訳注: 複数の異なるノードが応答する 1 つのアドレス。 RFC2526 を参照してください)。 * 強制マルチキャストアドレス * IPsec (IP セキュリティ) * シンプルなヘッダ構造 * モバイル IP * IPv4 から IPv6 への移行手段 詳細については下記を参照してください。 * http://www.sun.com[Sun.com] の IPv6 概観 * http://www.ipv6.org[IPv6.org] * http://www.kame.net[KAME.net] * http://www.6bone.net[6bone.net] === IPv6 アドレスの背景 いくつか違うタイプの IPv6 アドレスがあります。 ユニキャスト (Unicast)、エニーキャスト (Anycast) およびマルチキャスト (Multicast) です。 ユニキャストアドレスは周知のアドレスです。 ユニキャストアドレスへ送られたパケットは、 まさにそのアドレスに属するインターフェースに到着します。 エニーキャストアドレスはユニキャストアドレスと構文上判別不可能ですが、 インタフェース群に宛てられています。 エニーキャストアドレスに送られたパケットは (ルータメトリック的に) 最も近いインタフェースに到着します。 エニーキャストアドレスはルータでしか使ってはいけません。 マルチキャストアドレスはインタフェース群を識別します。 マルチキャストアドレスに送られたパケットは、 マルチキャスト群に属するすべてのインタフェースに到着します。 [NOTE] ==== IPv4 のブロードキャストアドレス (通常 `xxx.xxx.xxx.255`) は、IPv6 ではマルチキャストアドレスで表現されます。 ==== .予約された IPv6 アドレス [cols="1,1,1,1", frame="none", options="header"] |=== | IPv6 アドレス | プレフィックス長 (ビット) | 説明 | 備考 |`::` |128 ビット |不特定 |IPv4 の `0.0.0.0` 参照 |`::1` |128 ビット |ループバックアドレス |IPv4 の `127.0.0.1` 参照 |`::00:xx:xx:xx:xx` |96 ビット |IPv4 埋め込みアドレス |下位の 32 ビットは IPv4 アドレスです。 "IPv4 互換 IPv6 アドレス" とも呼ばれます。 |`::ff:xx:xx:xx:xx` |96 ビット |IPv4 射影 IPv6 アドレス |下位の 32 ビットは IPv4 アドレスです。 IPv6 に対応していないホストに対するアドレスです。 |`fe80::` - `feb::` |10 ビット |リンクローカル |IPv4 のループバックアドレス参照 |`fec0::` - `fef::` |10 ビット |サイトローカル | |`ff::` |8 ビット |マルチキャスト | |`001` (基数 2) |3 ビット |グローバルユニキャスト |すべてのグローバルユニキャストアドレスはこのプールから割り当てられます。 はじめの 3 ビットは "001" です。 |=== === IPv6 アドレスを読む 正規の書式では `x:x:x:x:x:x:x:x` と表されます。それぞれの "x" は 16 ビットの 16 進数です。たとえば `FEBC:A574:382B:23C1:AA49:4592:4EFE:9982` となります。 すべてゼロの長い部分文字列がアドレス内によく現れます。 そのため、そのような部分文字列は "::" に短縮することができます。 たとえば、`fe80::1` は正規形の `fe80:0000:0000:0000:0000:0000:0000:0001` に対応します。 3 番目の形式は、最後の 32 ビットの部分を "." を分割文字として使う、 なじみ深い IPv4 (10 進) 形式で書くことです。 たとえば `2002::10.0.0.1` は (16 進) 正規形の `2002:0000:0000:0000:0000:0000:0a00:0001` に対応し、同時に `2002::a00:1` と書くこととも等価です。 ここまで来れば、下記を理解することができるでしょう。 [source,shell] .... # ifconfig .... [.programlisting] .... rl0: flags=8943 mtu 1500 inet 10.0.0.10 netmask 0xffffff00 broadcast 10.0.0.255 inet6 fe80::200:21ff:fe03:8e1%rl0 prefixlen 64 scopeid 0x1 ether 00:00:21:03:08:e1 media: Ethernet autoselect (100baseTX ) status: active .... `fe80::200:21ff:fe03:8e1%rl0` は自動的に設定されたリンクローカルアドレスです。 これは自動設定の一環として、 イーサネット MAC アドレスを変換したものを含んでいます。 IPv6 アドレス構造についての詳細は RFC3513 をご覧ください。 === 接続 現在、他の IPv6 ホストおよびネットワークに接続するためには 4 つの方法があります。 * 6bone 実験ネットワークに参加する。 * 上流のプロバイダから IPv6 ネットワークの割り当てを受ける。 手順については、インターネットプロバイダに問い合わせてください。 * IPv6 over IPv4 によるトンネル。 * ダイアルアップ接続の場合 freenet6 port を使用する。 ここでは、現在もっともよく使われている方法と思われる 6bone へ接続する方法を説明します。 はじめに 6bone サイトをみて、 あなたに最も近い 6bone 接続先を見つけてください。 責任者に連絡すると、少しばかり運がよければ、 接続を設定する方法についての指示を受けられるでしょう。 多くのばあい、これには GRE (gif) トンネルの設定が含まれます。 [NOTE] ==== 6bone は `3ffe::` (16 ビット) という IPv6 アドレスを割り振られた実験目的のネットワークでしたが、 2006 年 6 月に運用を停止することになっています。 他の商用や試験的な IPv6 接続サービスを探してください。 ==== ここに man:gif[4] トンネルを設定する典型的な例を示します。 [source,shell] .... # ifconfig gif0 create # ifconfig gif0 gif0: flags=8010 mtu 1280 # ifconfig gif0 tunnel MY_IPv4_ADDR HIS_IPv4_ADDR # ifconfig gif0 inet6 alias MY_ASSIGNED_IPv6_TUNNEL_ENDPOINT_ADDR .... 大文字になっている単語を、 上流の 6bone ノードから受け取った情報に置き換えてください。 これでトンネルが確立されます。man:ping6[8] を `ff02::1%gif0` に送ることによって、トンネルが動作しているか確かめてください。 ping の応答を 2 つ受け取るはずです。 [NOTE] ==== `ff02:1%gif0` というアドレスに興味をそそられている場合のために説明すると、 これはマルチキャストアドレスです。 `%gif0` は、ネットワークインタフェース [.filename]#gif0# 上のマルチキャストアドレスが使用されるということを示しています。 マルチキャストアドレスに対して `ping` を送ったので、トンネルのもう一方の端も応答します。 ==== ここまで来ると 6bone アップリンクに経路設定することは比較的簡単でしょう。 [source,shell] .... # route add -inet6 default -interface gif0 # ping6 -n MY_UPLINK .... [source,shell] .... # traceroute6 www.jp.FreeBSD.org (3ffe:505:2008:1:2a0:24ff:fe57:e561) from 3ffe:8060:100::40:2, 30 hops max, 12 byte packets 1 atnet-meta6 14.147 ms 15.499 ms 24.319 ms 2 6bone-gw2-ATNET-NT.ipv6.tilab.com 103.408 ms 95.072 ms * 3 3ffe:1831:0:ffff::4 138.645 ms 134.437 ms 144.257 ms 4 3ffe:1810:0:6:290:27ff:fe79:7677 282.975 ms 278.666 ms 292.811 ms 5 3ffe:1800:0:ff00::4 400.131 ms 396.324 ms 394.769 ms 6 3ffe:1800:0:3:290:27ff:fe14:cdee 394.712 ms 397.19 ms 394.102 ms .... この出力はマシンによって異なります。 これで、あなたが package:www/mozilla[] のような IPv6 が利用可能なブラウザを持っていれば、 IPv6 サイト http://www.kame.net[www.kame.net] にいって踊るカメを見ることができるでしょう。 === IPv6 世界の DNS IPv6 のための新しい DNS レコードが 2 種類あります。 * AAAA レコード * A6 レコード AAAA レコードは簡単に使えます。 [.programlisting] .... MYHOSTNAME AAAA MYIPv6ADDR .... 上記をプライマリゾーン DNS ファイルに加えて、 もらったばかりの IPv6 アドレスにホスト名を割り当ててください。 あなた自身で DNS ゾーンを管理していない場合は、 DNS プロバイダに頼んでください。 bind の最新バージョン (バージョン 8.3 および 9) は AAAA レコードに対応しています。 diff --git a/documentation/content/ja/books/handbook/bibliography/_index.adoc b/documentation/content/ja/books/handbook/bibliography/_index.adoc index 352202bdfe..b1e15060b4 100644 --- a/documentation/content/ja/books/handbook/bibliography/_index.adoc +++ b/documentation/content/ja/books/handbook/bibliography/_index.adoc @@ -1,169 +1,169 @@ --- title: 付録B. 参考図書 part: パートV. 付録 prev: books/handbook/mirrors next: books/handbook/eresources showBookMenu: true -weight: 29 +weight: 28 path: "/books/handbook/" --- [appendix] [[bibliography]] = 参考図書 :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :sectnumoffset: B :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/bibliography/ ifdef::env-beastie[] ifdef::backend-html5[] :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] __訳: {nakai}, 1996 年 10 月 12 日。__ FreeBSD オペレーティングシステムの個々の部分については マニュアルページで定義のような説明がなされていますが, どうやってその部分どうしをつなぎあわせて オペレーティングシステム全体を円滑に動作させるかについては, ほとんど説明されていません。 それを補うためにはのよい本や, UNIX(R) システム管理についての 利用者向けのマニュアルが欠かせません。 [[bibliography-freebsd]] == FreeBSD 専門の書籍 __非英語文化圏の書籍:__ * link:http://jdli.tw.FreeBSD.org/publication/book/freebsd2/index.htm[ FreeBSD 入門與應用] (繁体字中国語)。 link:http://www.drmaster.com.tw/[Drmaster] 発行, 1997. ISBN 9-578-39435-7. * FreeBSD Unleashed (簡体字中国語訳), link:http://www.hzbook.com/[China Machine Press] 発行. ISBN 7-111-10201-0. * FreeBSD From Scratch Second Edition (簡体字中国語), China Machine Press 発行. ISBN 7-111-10286-X. * FreeBSD ハンドブック第 2 版 (簡体字中国語訳), link:http://www.ptpress.com.cn/[Posts & Telecom Press] 発行. ISBN 7-115-10541-3. * FreeBSD & Windows (簡体字中国語), link:http://www.tdpress.com/[China Railway Publishing House] 発行. ISBN 7-113-03845-X * FreeBSD Internet Services HOWTO (簡体字中国語), China Railway Publishing House 発行. ISBN 7-113-03423-3 * FreeBSD入門キット AT互換機版 第二版。 宮嵜忠臣 著。 秀和システム。 ISBN 4-87966-535-5 C3055 2900 円。 * ここまでできる FreeBSD パワーガイド。 霜山 滋, 仲道 嘉夫, 山中 右次 著。 秀和システム。 ISBN 4-87966-637-8 2600円。 * link:http://www.shoeisha.co.jp/book/Detail.asp?bid=650[FreeBSD徹底入門]。 あさだ たくや / 天川 修平 / 衛藤 敏寿 / 浜田 直樹 / 細川 達己 / 三田 吉郎 著。 link:http://www.shoeisha.co.jp/[翔泳社]。 ISBN 4-88135-473-6 3600 円。 * link:http://www.ascii.co.jp/pb/book1/shinkan/detail/1322785.html[パーソナル UNIX スターターキット FreeBSD]。 民田 雅人 / 古場 正行 / 増田 佳泰 / 天池 健 / 宮川 晋 共著。 link:http://www.ascii.co.jp/[アスキー]。 ISBN 4-7561-1733-3 3000 円。 * FreeBSD ハンドブック (日本語版)。 link:http://www.ascii.co.jp/[アスキー]。 ISBN 4-7561-1580-2 3800 円。 * FreeBSD mit Methode (ドイツ語版)。 link:http://www.cul.de[Computer und Literatur Verlag]/Vertrieb Hanser 発行。1998。 ISBN 3-932311-31-0 * link:http://www.mitp.de/vmi/mitp/detail/pWert/1343/[ FreeBSD de Luxe] (ドイツ語), link:http://www.mitp.de[Verlag Modere Industrie] 発行, 2003 年。ISBN 3-8266-1343-0. * link:http://www.pc.mycom.co.jp/FreeBSD/install-manual.html[FreeBSD インストール & 活用マニュアル], link:http://www.pc.mycom.co.jp/[ 毎日コミュニケーションズ]発行。1998 年. ISBN 4-8399-0112-0. * Onno W Purbo, Dodi Maryanto, Syahrial Hubbany, Widjil Widodo 著 __link:http://maxwell.itb.ac.id/[FreeBSD を使ったインターネットサーバの構築 (Building Internet Server with FreeBSD)]__ (インドネシア語), link:http://www.elexmedia.co.id/[Elex Media Komputindo] 発行。 * Absolute BSD: The Ultimate Guide to FreeBSD (繁体字中国語訳) link:http://www.grandtech.com.tw/[GrandTech Press] 発行 (2003 年)。ISBN 986-7944-92-5. * link:http://www.twbsd.org/cht/book/[The FreeBSD 6.0 Book] (繁体字中国語), Drmaster 発行 (2006 年)。ISBN 9-575-27878-X. __英語の書籍:__ * link:http://www.absoluteFreeBSD.com/[Absolute FreeBSD, 2nd Edition: The Complete Guide to FreeBSD], http://www.nostarch.com/[No Starch Press] 刊、2007 年。ISBN: 978-1-59327-151-0 * link:http://www.freebsdmall.com/cgi-bin/fm/bsdcomp[ The Complete FreeBSD], http://www.oreilly.com/[O'Reilly]、 2003 年。ISBN: 0596005164 * link:http://www.freebsd-corp-net-guide.com/[The FreeBSD Corporate Networker's Guide], http://www.awl.com/aw/[Addison-Wesley] 刊、 2000 年。ISBN: 0201704811 * link:http://andrsn.stanford.edu/FreeBSD/introbook/[ FreeBSD: An Open-Source Operating System for Your Personal Computer]、The Bit Tree Press 刊、2001 年。 ISBN: 0971204500 * Teach Yourself FreeBSD in 24 Hours, link:http://www.samspublishing.com/[Sams] 刊、 2002 年。ISBN: 0672324245 * FreeBSD 6 unleashed, link:http://www.samspublishing.com/[Sams] 刊、 2006 年。ISBN: 0672328755 * FreeBSD: The Complete Reference, link:http://books.mcgraw-hill.com[McGrawHill] 刊、 2003 年。ISBN: 0072224096 [[bibliography-userguides]] == 利用者向けのガイド * オハイオ州立大学による link:http://www.cs.duke.edu/csl/docs/unix_course/[UNIX Introductory Course]。 オンラインで HTML 版と PostScript 版が利用可能。 + FreeBSD イタリア語ドキュメンテーションプロジェクトの一環 として、このドキュメントの link:https://www.FreeBSD.org/doc/it/books/unix-introduction/[イタリア語訳] が用意されています。 * link:http://www.jp.FreeBSD.org/[FreeBSD 友の会 jpman プロジェクト]。FreeBSD User's Reference Manual (日本語訳)。 link:http://www.pc.mycom.co.jp/[毎日コミュニケーションズ], 1998。ISBN4-8399-0088-4 P3800E。 * link:http://www.ed.ac.uk/[Edinburgh University] による UNIX 環境の初心者向け link:http://www.ed.ac.uk/information-services/help-consultancy/is-skills/catalogue/program-op-sys-catalogue/unix1[オンラインガイド]。 [[bibliography-adminguides]] == 管理者向けのガイド * link:http://www.jp.FreeBSD.ORG/[FreeBSD 友の会 jpman プロジェクト]。FreeBSD System Administrator's Manual (日本語訳)。 link:http://www.pc.mycom.co.jp/[毎日コミュニケーションズ], 1998. ISBN4-8399-0109-0 P3300E. * Dreyfus, Emmanuel. link:http://www.eyrolles.com/Informatique/Livre/9782212114638/[Cahiers de l'Admin: BSD] 第 2 版。(フランス語、「管理者ノート」)、Eyrolles, 2004. ISBN 2-212-11463-X == プログラマ向けのガイド * Computer Systems Research Group, UC Berkeley. _4.4BSD Programmer's Reference Manual_. O'Reilly & Associates, Inc., 1994. ISBN 1-56592-078-3 * Computer Systems Research Group, UC Berkeley. _4.4BSD Programmer's Supplementary Documents_. O'Reilly & Associates, Inc., 1994. ISBN 1-56592-079-1 * Harbison, Samuel P. and Steele, Guy L. Jr. _C: A Reference Manual_. 4th Ed. Prentice Hall, 1995. ISBN 0-13-326224-3 (訳注: 邦訳は以下のものが出版されています。 斎藤 信男監訳。 _新・詳説 C 言語リファレンス [H&Sリファレンス]_。 ソフトバンク, 1994。 ISBN 4-89052-506-8 原本は第 4 版だが, 訳出は第 3 版のみ。) * Kernighan, Brian and Dennis M. Ritchie. _The C Programming Language_. 2nd Ed. PTR Prentice Hall, 1988. ISBN 0-13-110362-8 (訳注: 邦訳は以下のものが出版されています。 石田 晴久 訳。 _プログラミング言語 C 第 2 版(訳書訂正版)_ 共立出版, 1989。 ISBN 4-320-02692-6) * Lehey, Greg. _Porting UNIX Software_. O'Reilly & Associates, Inc., 1995. ISBN 1-56592-126-7 * Plauger, P. J. _The Standard C Library_. Prentice Hall, 1992. ISBN 0-13-131509-9 (訳注: 邦訳は以下のものが出版されています。 福富 寛 / 門倉 明彦 / 清水 恵介 訳。 _標準 C ライブラリ ANSI/ISO/JIS C規格_. トッパン, 1995。 ISBN 4-8101-8541-9) * Spinellis, Diomidis. link:http://www.spinellis.gr/codereading/[Code Reading: The Open Source Perspective]. Addison-Wesley, 2003. ISBN 0-201-79940-5 * Spinellis, Diomidis. link:http://www.spinellis.gr/codequality/[Code Quality: The Open Source Perspective]. Addison-Wesley, 2006. ISBN 0-321-16607-8 * Stevens, W. Richard and Stephen A. Rago. _Advanced Programming in the UNIX Environment_. 2nd Ed. Reading, Mass. : Addison-Wesley, 2005. ISBN 0-201-43307-9 (訳注: 第 1 版の邦訳は以下のものが出版されています。 大木 敦雄 訳。 _詳解 UNIX プログラミング_。トッパン, 1994。 ISBN 4-89052-524-6) * Stevens, W. Richard. _UNIX Network Programming_. 2nd Ed. PTR Prentice Hall, 1998. ISBN 0-13-949876-1 (訳注: 第 1 版の邦訳は以下のものが出版されています. 篠田 陽一 訳. _UNIX ネットワークプログラミング_。 トッパン, 1992. ISBN 4-8101-8509-5) 第 2 版の邦訳は以下のものが出版されています。 篠田 陽一 訳. _UNIX ネットワークプログラミング 第 2 版 Vol.1_。 トッパン, 1999。 ISBN 4-8101-8612-1) == オペレーティングシステム内部 * Andleigh, Prabhat K. _UNIX System Architecture_. Prentice-Hall, Inc., 1990. ISBN 0-13-949843-5 * Jolitz, William. "Porting UNIX to the 386". _Dr. Dobb's Journal_. January 1991-July 1992. * Leffler, Samuel J., Marshall Kirk McKusick, Michael J Karels and John Quarterman _The Design and Implementation of the 4.3BSD UNIX Operating System_. Reading, Mass. : Addison-Wesley, 1989. ISBN 0-201-06196-1 (訳注: 邦訳は以下のものが出版されています。 中村 明 / 相田 仁 / 計 宇生 / 小池 汎平 訳。 _UNIX 4.3BSDの設計と実装_。丸善, 1991。 ISBN 4-621-03607-6) * Leffler, Samuel J., Marshall Kirk McKusick, _The Design and Implementation of the 4.3BSD UNIX Operating System: Answer Book_. Reading, Mass. : Addison-Wesley, 1991. ISBN 0-201-54629-9 (訳注: 邦訳は以下のものが出版されています。 相田 仁 / 計 宇生 / 小池 汎平 訳。 _UNIX 4.3BSDの設計と実装_。 アンサーブック, トッパン, 1991。 ISBN 4-8101-8039-5) * McKusick, Marshall Kirk, Keith Bostic, Michael J Karels, and John Quarterman. _The Design and Implementation of the 4.4BSD Operating System_. Reading, Mass. : Addison-Wesley, 1996. ISBN 0-201-54979-4 + (この本の第二章が FreeBSD ドキュメンテーションプロジェクト の一部として extref:{design-44bsd}[オンライン] で公開されています。) * Marshall Kirk McKusick, George V. Neville-Neil _The Design and Implementation of the FreeBSD Operating System_. Boston, Mass. : Addison-Wesley, 2004. ISBN 0-201-70245-2 * Marshall Kirk McKusick, George V. Neville-Neil, Robert N. M. Watson _The Design and Implementation of the FreeBSD Operating System, 2nd Ed._. Westford, Mass. : Pearson Education, Inc., 2014. ISBN 0-321-96897-2 * Stevens, W. Richard. _TCP/IP Illustrated, Volume 1: The Protocols_. Reading, Mass. : Addison-Wesley, 1996. ISBN 0-201-63346-9 * Schimmel, Curt. _Unix Systems for Modern Architectures_. Reading, Mass. : Addison-Wesley, 1994. ISBN 0-201-63338-8 * Stevens, W. Richard. _TCP/IP Illustrated, Volume 3: TCP for Transactions, HTTP, NNTP and the UNIX Domain Protocols_. Reading, Mass. : Addison-Wesley, 1996. ISBN 0-201-63495-3 (訳注: 邦訳は以下のものが出版されています。 中本 幸一 / 石川 裕次 / 田中 伸佳 訳。 _詳解 TCP/IP Vol.3: トランザクション TCP, HTTP, NNTP, UNIX ドメインプロトコル_, アジソンウェスレイパブリッシャーズジャパン, 1998。 ISBN 4-8101-8039-5) * Vahalia, Uresh. _UNIX Internals -- The New Frontiers_. Prentice Hall, 1996. ISBN 0-13-101908-2 (訳注: 邦訳は以下のものが出版されています。 徳田 英幸 / 中村 明 / 戸辺 義人 / 津田 悦幸 訳。 _最前線UNIXのカーネル_, ピアソンエデュケーション, 2000。 ISBN 4-89471-189-3) * Wright, Gary R. and W. Richard Stevens. _TCP/IP Illustrated, Volume 2: The Implementation_. Reading, Mass. : Addison-Wesley, 1995. ISBN 0-201-63354-X * Messmer, Hans-Peter. _The Indispensable PC Hardware Book_, 4th Ed. Reading, Mass : Addison-Wesley Pub. Co., 2002. ISBN 0-201-59616-4 == セキュリティの参考資料 * Cheswick, William R. and Steven M. Bellovin. _Firewalls and Internet Security: Repelling the Wily Hacker_. Reading, Mass. : Addison-Wesley, 1995. ISBN 0-201-63357-4 (訳注: 邦訳は以下のものが出版されています。 川副 博 監訳。_ファイアウォール_。 ソフトバンク, 1995。 ISBN 4-89052-672-2) * Garfinkel, Simson. _PGP Pretty Good Privacy_ O'Reilly & Associates, Inc., 1995. ISBN 1-56592-098-8 [[bibliography-hardware]] == ハードウェアの参考資料 * Anderson, Don and Tom Shanley. _Pentium Processor System Architecture_. 2nd Ed. Reading, Mass. : Addison-Wesley, 1995. ISBN 0-201-40992-5 * Ferraro, Richard F. _Programmer's Guide to the EGA, VGA, and Super VGA Cards_. 3rd ed. Reading, Mass. : Addison-Wesley, 1995. ISBN 0-201-62490-7 * Intel Corporation は、自社の CPU やチップセットに関する文書を自社の link:http://developer.intel.com/[開発者向け Web サイト] で公開しています。文書のフォーマットは通常 PDF です。 * Shanley, Tom. _80486 System Architecture_. 3rd Ed. Reading, Mass. : Addison-Wesley, 1995. ISBN 0-201-40994-1 * Shanley, Tom. _ISA System Architecture_. 3rd Ed. Reading, Mass. : Addison-Wesley, 1995. ISBN 0-201-40996-8 * Shanley, Tom. _PCI System Architecture_. 4th Ed. Reading, Mass. : Addison-Wesley, 1999. ISBN 0-201-30974-2 * Van Gilluwe, Frank. _The Undocumented PC_, 2nd Ed. Reading, Mass: Addison-Wesley Pub. Co., 1996. ISBN 0-201-47950-8 [[bibliography-history]] == UNIX(R) の歴史 * Lion, John _Lion's Commentary on UNIX, 6th Ed. With Source Code_. ITP Media Group, 1996. ISBN 1573980137 * Raymond, Eric s. _The New Hacker's Dictionary, 3rd edition_. MIT Press, 1996. ISBN 0-262-68092-0 これは link:http://www.catb.org/~esr/jargon/html/index.html[ジャーゴンファイル (Jargon File)] として知られています。 * Saulus, Peter H. _A quarter century of UNIX_. Addison-Wesley Publishing Company, Inc., 1994. ISBN 0-201-54777-5 * Simon Garfinkel, Daniel Weise, Steven Strassmann. _The UNIX-HATERS Handbook_. IDG Books Worldwide, Inc., 1994. ISBN 1-56884-203-1. 絶版となりましたが、link:http://www.simson.net/ref/ugh.pdf[オンライン] で入手できます。 * Don Libes, Sandy Ressler _Life with UNIX_ - special edition. Prentice-Hall, Inc., 1989. ISBN 0-13-536657-7 (訳注: 邦訳は以下のものが出版されています。 坂本 文 監訳. _Life with UNIX_. アスキー, 1990。 ISBN 4-7561-0783-4 邦訳が Special 版の訳出か否かは不明) * _BSD 系 OS の系譜図_。 link:https://svnweb.freebsd.org/base/head/share/misc/bsd-family-tree?view=co[https://svnweb.freebsd.org/base/head/share/misc/bsd-family-tree?view=co] か、もしくは、FreeBSD マシンにある link:file://localhost/usr/share/misc/bsd-family-tree[/usr/share/misc/bsd-family-tree]。 * _Networked Computer Science Technical Reports Library_. * _Computer Systems Research group (CSRG) からの古い BSD リリース集_。link:http://www.mckusick.com/csrg/[http://www.mckusick.com/csrg/]: この 4 枚 CD セットには、1BSD から 4.4BSD までと 4.4BSD-Lite2 が含まれます (残念ながら 2.11BSD は含まれていません)。 また 4 枚目の CD には、最終ソースおよび SCCS ファイルが含まれています。 * Kernighan, Brian _Unix: A History and a Memoir_. Kindle Direct Publishing, 2020. ISBN 978-169597855-3 [[bibliography-journals]] == 定期刊行物、雑誌およびジャーナル * link:http://www.admin-magazin.de/[Admin Magazin] (in German), published by Medialinx AG. ISSN: 2190-1066 * link:http://www.bsdmag.org/[BSD Magazine], published by Software Press Sp. z o.o. SK. ISSN: 1898-9144 * link:http://www.bsdnow.tv/[BSD Now - Video Podcast], published by Jupiter Broadcasting LLC * link:http://bsdtalk.blogspot.com/[BSD Talk Podcast], by Will Backman * link:http://freebsdjournal.com/[FreeBSD Journal], published by S&W Publishing, sponsored by The FreeBSD Foundation. ISBN: 978-0-615-88479-0 diff --git a/documentation/content/ja/books/handbook/book.adoc b/documentation/content/ja/books/handbook/book.adoc index 68f597106f..004a57d9d7 100644 --- a/documentation/content/ja/books/handbook/book.adoc +++ b/documentation/content/ja/books/handbook/book.adoc @@ -1,130 +1,128 @@ --- title: FreeBSD ハンドブック authors: - author: FreeBSD ドキュメンテーションプロジェクト copyright: 1995-2022 The FreeBSD Documentation Project tags: ["FreeBSD ハンドブック", "ハンドブック"] add_split_page_link: true trademarks: ["freebsd", "ibm", "ieee", "redhat", "3com", "adobe", "apple", "intel", "linux", "microsoft", "opengroup", "sun", "realnetworks", "oracle", "3ware", "arm", "adaptec", "google", "heidelberger", "intuit", "lsilogic", "themathworks", "thomson", "vmware", "wolframresearch", "xiph", "xfree86", "general"] --- = FreeBSD ハンドブック :doctype: book :toc: macro :toclevels: 2 :icons: font :sectnums: :sectnumlevels: 6 :partnums: :source-highlighter: rouge :experimental: :book: true :pdf: false :images-path: books/handbook/ ifdef::env-beastie[] ifdef::backend-html5[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] :chapters-path: content/{{% lang %}}/books/handbook/ endif::[] ifdef::backend-pdf,backend-epub3[] :chapters-path: include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] :chapters-path: include::../../../../../shared/asciidoctor.adoc[] endif::[] include::{chapters-path}introduction.adoc[] ''' toc::[] :sectnums!: include::{chapters-path}preface/_index.adoc[leveloffset=+1] :sectnums: // Section one include::{chapters-path}parti.adoc[] include::{chapters-path}introduction/_index.adoc[leveloffset=+1] include::{chapters-path}bsdinstall/_index.adoc[leveloffset=+1] include::{chapters-path}basics/_index.adoc[leveloffset=+1] include::{chapters-path}ports/_index.adoc[leveloffset=+1] include::{chapters-path}x11/_index.adoc[leveloffset=+1] // Section two include::{chapters-path}partii.adoc[] include::{chapters-path}desktop/_index.adoc[leveloffset=+1] include::{chapters-path}multimedia/_index.adoc[leveloffset=+1] include::{chapters-path}kernelconfig/_index.adoc[leveloffset=+1] include::{chapters-path}printing/_index.adoc[leveloffset=+1] include::{chapters-path}linuxemu/_index.adoc[leveloffset=+1] // Section three include::{chapters-path}partiii.adoc[] include::{chapters-path}config/_index.adoc[leveloffset=+1] include::{chapters-path}boot/_index.adoc[leveloffset=+1] -include::{chapters-path}users/_index.adoc[leveloffset=+1] - include::{chapters-path}security/_index.adoc[leveloffset=+1] include::{chapters-path}disks/_index.adoc[leveloffset=+1] include::{chapters-path}l10n/_index.adoc[leveloffset=+1] include::{chapters-path}cutting-edge/_index.adoc[leveloffset=+1] // Section four include::{chapters-path}partiv.adoc[] include::{chapters-path}serialcomms/_index.adoc[leveloffset=+1] include::{chapters-path}ppp-and-slip/_index.adoc[leveloffset=+1] include::{chapters-path}mail/_index.adoc[leveloffset=+1] include::{chapters-path}advanced-networking/_index.adoc[leveloffset=+1] // Section five include::{chapters-path}partv.adoc[] :sectnums!: include::{chapters-path}mirrors/_index.adoc[leveloffset=+1] include::{chapters-path}bibliography/_index.adoc[leveloffset=+1] include::{chapters-path}eresources/_index.adoc[leveloffset=+1] include::{chapters-path}pgpkeys/_index.adoc[leveloffset=+1] // include::{chapters-path}glossary.adoc[leveloffset=+1] // include::{chapters-path}colophon.adoc[leveloffset=+1] :sectnums: diff --git a/documentation/content/ja/books/handbook/boot/_index.adoc b/documentation/content/ja/books/handbook/boot/_index.adoc index aa9f28b298..3afda744ba 100644 --- a/documentation/content/ja/books/handbook/boot/_index.adoc +++ b/documentation/content/ja/books/handbook/boot/_index.adoc @@ -1,376 +1,376 @@ --- title: 第12章 FreeBSD の起動のプロセス part: パートIII. システム管理 prev: books/handbook/config -next: books/handbook/users +next: books/handbook/security showBookMenu: true weight: 16 path: "/books/handbook/" --- [[boot]] = FreeBSD の起動のプロセス :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :sectnumoffset: 12 :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/boot/ ifdef::env-beastie[] ifdef::backend-html5[] :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [[boot-synopsis]] == この章では 計算機を起動しオペレーティングシステムをロードするプロセスは、 "ブートストラッププロセス" もしくは "ブート" と呼ばれます。 FreeBSD の起動プロセスを使えば、 システムをスタートするときに起きることをかなり柔軟にカスタマイズできます。 同じ計算機にインストールされた別のオペレーティングシステムを選択することもできますし、 同じオペレーティングシステムの異なるバージョンを選択することも、 インストールされた別のカーネルを選択することさえできます。 この章では、指定できる設定オプションついて詳しく説明します。 FreeBSD カーネルがスタートし、デバイスを検出し、 man:init[8] を起動するまでに起きることすべてを含む FreeBSD の起動プロセスのカスタマイズ方法について説明します。 これは、起動メッセージのテキストの色が、 明るい白から灰色に変わるまでに起きています。 この章を読むと、以下のことが分かります。 * FreeBSD のブートストラップシステムの構成およびそれらが互いにどう関係しているのか * 起動プロセスを制御するために FreeBSD のブートストラップの各要素に付加できるオプション * device hints の基本的な記述方法 * シングルユーザもしくはマルチユーザモードでの起動方法、 および FreeBSD システムのシャットダウンの方法 [NOTE] ==== この章では Intel x86 および amd64 システム上で動作する FreeBSD の起動プロセスだけを扱います。 ==== [[boot-introduction]] == FreeBSD の起動プロセス 計算機の電源を入れ、オペレーティングシステムをスタートさせるのには、 おもしろいジレンマがあります。定義により、 計算機は、オペレーティングシステムが起動するまでは、 ディスクからプログラムを動かすことも含めて、 何をどうすればよいかまったく知りません。 計算機はオペレーティングシステムなしにディスクからプログラムを実行することができず、 オペレーティングシステムのプログラムがディスク上にあるのなら、 どうやってオペレーティングシステムを起動するのでしょうか? この問題はほらふき男爵の冒険 という本の中に書かれている問題ととてもよく似ています。 登場人物がマンホールの下に半分落っこちて、 靴紐 (ブートストラップ) をつかんで自分を引っぱり、持ち上げるのです。 計算機の黎明期には、_ブートストラップ_ という用語でオペレーティングシステムをロードする機構のことを指していました。 いまはこれを縮めて "ブート (起動)" と言います。 x86 ハードウェアでは、基本入出力システム (Basic Input/Output System: BIOS) にオペレーティングシステムをロードする責任があります。 BIOS はハードディスク上のマスターブートレコード (Master Boot Record: MBR) を探します。 MBR はハードディスク上の特定の場所になければなりません。 BIOS には MBR をロードし起動するのに十分な知識があり、 オペレーティングシステムをロードするために必要な作業の残りは、 場合によっては BIOS の助けを得た上で MBR が実行できることを仮定しています。 [NOTE] ==== FreeBSD は古い標準の MBR、 または新しい GUID Partition Table (GPT) から起動できます。 GPT パーティションは、Unified Extensible Firmware Interface (UEFI) に対応したコンピュータで良く用いられます。 しかしながら、FreeBSD はレガシーな BIOS にのみに対応したコンピュータからも、man:gptboot[8] により、 GPT パーティションから起動できます。 UEFI からの直接の起動への対応は進行中です。 ==== MBR 内部のコードは、 一般的に_ブートマネージャ_と呼ばれます。 とりわけユーザとの対話がある場合にそう呼ばれます。 通常ブートマネージャのもっと多くのコードが、 ディスクの最初のトラック、またはファイルシステム上におかれます。 ブートマネージャの例としては、Boot Easy とも呼ばれる FreeBSD 標準のブートマネージャの boot0、 多くの Linux(R) ディストリビューションが採用している Grub 等があります。 ディスク上にインストールされているオペレーティングシステムが 1 つの時は、MBR はディスク上の最初の起動可能な (アクティブな) スライスを探し、 そのスライスにあるコードを起動してオペレーティングシステムの残りをロードします。 ディスク上に複数のオペレーティングシステムが存在しているのなら、 複数のオペレーティングシステムの一覧を表示できて、 起動するオペレーティングシステムを選択できるような、 別のブートマネージャをインストールすることもできます。 FreeBSD のブートストラップシステムの残りは 3 段階に分かれます。 第 1 ステージは、 計算機を特定の状態にするために必要なことだけを知っていて、 第 2 ステージを起動します。 第 2 ステージでは、第 3 ステージを起動する前に、 もう少しできることがあります。 第 3 ステージでオペレーティングシステムのロード作業を完了します。 起動作業が 3 段階に分かれているのは、 MBR がステージ 1 とステージ 2 で実行できるプログラムのサイズに制限を課しているからです。 これらの作業をつなぎ合わせることによって、 FreeBSD はより柔軟なローダ (loader) を提供しているのです。 その後カーネルが起動し、デバイスの検出と初期化を開始します。 そしてカーネルの起動が終わると、制御はユーザープロセスの man:init[8] へ移されます。man:init[8] はディスクが利用可能であることを確認し、 ファイルシステムのマウント、 ネットワークで利用するネットワークカードのセットアップ、 そしてブート時に起動されるように設定されたプロセスの起動、 といったユーザーレベルでのリソース (資源) 設定を行ないます。 この章では、これらのステージについてより詳細に、また、FreeBSD ブートプロセスにおける対話的な設定方法について説明します。 [[boot-boot0]] === ブートマネージャ MBR のブートマネージャのコードは起動プロセスの_第 0 ステージ_と呼ばれることがあります。 デフォルトでは、FreeBSD は boot0 を使います。 FreeBSD のインストーラがインストールする MBR は、 [.filename]#/boot/boot0# を基にしています。 boot0 のサイズと機能は、 スライステーブルおよび MBR 末尾の識別子 `0x55AA` のため、 446 バイトの大きさに制限されます。 もし、boot0 と複数のオペレーティングシステムをインストールした場合、 起動時に以下のようなメッセージが表示されます。 [[boot-boot0-example]] .[.filename]#boot0# のスクリーンショット [example] ==== [source,shell] .... F1 Win F2 FreeBSD Default: F2 .... ==== 他のオペレーティングシステムは、 FreeBSD の後にインストールを行うと、既存の MBR を上書きしてしまいます。 もしそうなってしまったら、 もしくは既存の MBR を FreeBSD の MBR で置き換えるには、 次のコマンドを使ってください。 [source,shell] .... # fdisk -B -b /boot/boot0 device .... _device_ は起動するデバイス名で、 たとえば 1 番目の IDE ディスクは [.filename]#ad0#、2 番目の IDE コントローラに接続されている 1 番目の IDE ディスクは [.filename]#ad2#、 1 番目の SCSI ディスクは [.filename]#da0# などとなります。 MBR の設定をカスタマイズしたい場合は、 man:boot0cfg[8] を参照してください。 [[boot-boot1]] === 起動ステージ 1 と起動ステージ 2 概念上、第 1 ステージと第 2 ステージはハードディスクの同じ領域上の同一のプログラムの部分部分です。 スペースの制約のため 2 つに分割されていますが、 いつも一緒にインストールされます。 FreeBSD のインストーラまたは `bsdlabel` は、 両者を 1 つにまとめた [.filename]#/boot/boot# をコピーします。 これらの 2 つのステージは、ファイルシステムの外部、 起動スライスの最初のトラックに置かれ、 先頭が最初のセクタにきます。 boot0 またはその他のブートマネージャは、 起動プロセスを続けるために必要なプログラムがそこにあると想定しています。 最初のステージの [.filename]#boot1# は、 512 バイトの大きさでなければならないという制限があるので、 非常に単純なプログラムです。 このプログラムは [.filename]#boot2# を検索して実行するため、そのスライスの情報を保持する FreeBSD の _BSD ラベル_ に関する最低限の情報だけを持っています。 次のステージの [.filename]#boot2# はもう少し高機能です。 これは FreeBSD のファイルシステム上でファイルを見つける機能を持ちます。 実行するカーネルやローダを指定するための簡単なインタフェースを提供します。 [.filename]#boot2# により起動される loader はさらに高機能で、 起動設定が行なえる手段を提供します。 ステージ 2 で起動プロセス中断した時には、 次のようながインタラクティブなが画面が表示されます。 [[boot-boot2-example]] .[.filename]#boot2# のスクリーンショット [example] ==== [source,shell] .... >> FreeBSD/i386 BOOT Default: 0:ad(0,a)/boot/loader boot: .... ==== インストールされた [.filename]#boot1# と [.filename]#boot2# を変更するには、 `bsdlabel` を使ってください。 以下の例では、_diskslice_ は起動するディスクとスライスで、たとえば最初の IDE ディスクの 1 番目のスライスは [.filename]#ad0s1# となります。 [source,shell] .... # bsdlabel -B diskslice .... [WARNING] ==== [.filename]#ad0# のようにディスク名だけを指定すると、 `bsdlabel` は、スライスを持たない "危険な専用モード"を作成してしまいます。 これはおそらく、あなたが望んでいることではないでしょうから、 kbd:[Return] キーを押す前に、 _diskslice_ の部分を二重にチェックしてください。 ==== [[boot-loader]] === 起動ステージ 3 loader は三段階の起動プロセスの最終段階です。 これは通常、ファイルシステム上の [.filename]#/boot/loader# として存在しています。 loader は、 よりさまざまなコマンド群をサポートした強力なインタプリタによって提供される組み込みコマンド群を利用することで、 インタラクティブな設定手段となるように設計されています。 loader は初期化の際にコンソールとディスクの検出を行ない、 どのディスクから起動しているかを調べます。 そして必要な変数を設定してからインタプリタを起動し、 スクリプトからコマンドを送ったり手でコマンドを入力したりできます。 loader は次に [.filename]#/boot/loader.rc# を読み込み、通常、変数の標準値を定義した [.filename]#/boot/defaults/loader.conf# と、そのコンピュータにローカルに変数を定義した [.filename]#/boot/loader.conf# を読み込みます。 [.filename]#loader.rc# はそれらの変数にもとづき、 選択されたモジュールとカーネルをロードします。 loader は最後に、 標準設定で 10 秒のキー入力待ち時間を用意し、 入力がなければカーネルを起動します。 入力があった場合、コマンド群が使えるプロンプトが表示され、 ユーザは変数を調整したり、すべてのモジュールをアンロードしたり、 モジュールをロードしたりすることができます。 その後、最終的な起動や再起動へ移行します。 <>では、 もっともよく使われる loader のコマンドをまとめています。 利用可能なコマンドをすべて知りたい場合には、 man:loader[8] を参照してください。 [[boot-loader-commands]] .ローダの組み込みコマンド [cols="1,1", frame="none", options="header"] |=== | 変数 | 説明 |autoboot _seconds_ |_seconds_ で与えられた時間内に入力がなければ、 カーネルの起動へと進みます。 カウントダウンを表示します。標準設定では 10 秒間です。 |boot `[__-options__] [__kernelname]__` |すぐにカーネルの起動へ進みます。 オプション、カーネル名が指定されている場合は、 それらが使われます。 _unload_ を実行後、 カーネル名をコマンドラインから指定することができます。 _unload_ を実行しないと、 一度読み込まれたカーネルが使われます。 _kernelname_ でパスが指定されていない時には、 _/boot/kernel_ および _/boot/modules_ から調べられます。 |boot-conf |すべてのモジュールの設定を、 起動時と同じように指定された変数 (最も多いのは `kernel`) にもとづいて自動的に行ないます。 このコマンドは、変数を変更する前に、 最初に `unload` を行なった場合にのみ有効に働きます。 |help `[__topic__]` |[.filename]#/boot/loader.help# を読み込み、ヘルプメッセージを表示します。 topic に `index` が指定された場合、 利用可能な topic の一覧を表示します。 |include _filename_ ... |指定されたファイルを読み込み、行単位で解釈します。 エラーが発生した場合、 `include` の実行は直ちに停止します。 |load `[-t __type__]` _filename_ |指定されたファイル名のカーネル、 カーネルモジュール、あるいは type に指定された種類のファイルをロードします。 _filename_ 以降に指定された引数はファイルへと渡されます。 _filename_ でパスが指定されていない時には、 _/boot/kernel_ および _/boot/modules_ から調べられます。 |ls [-l] `[__path__]` |指定された _path_ にあるファイルを表示します。 _path_ が指定されていなければ、ルートディレクトリを表示します。 `-l` が指定されていればファイルサイズも表示されます。 |lsdev [-v] |モジュールがロード可能なすべてのデバイスを表示します。 もし `-v` が指定されていれば、 より詳細な出力がされます。 |lsmod [-v] |ロード済みのモジュールを表示します。 `-v` が指定されていれば、 より詳細な内容が出力されます。 |more _filename_ |`LINES` 行を表示するごとに停止しながら指定されたファイルを表示します。 |reboot |すぐにシステムを再起動します。 |set _variable_, set _variable_=_value_ |ローダの環境変数を設定します。 |unload |すべてのロード済みモジュールを削除します。 |=== 次にあげるのは、ローダの実践的な使用例です。 普段使っているカーネルをシングルユーザモードで起動します。 [source,shell] .... boot -s .... 普段使っているカーネルとモジュールをアンロードし、 古いもしくは別のカーネルをロードするには、 以下のように実行してください。 [source,shell] .... unload load /path/to/kernelfile .... インストール時のデフォルトカーネルを指定するには、完全修飾の [.filename]#/boot/GENERIC/kernel# を使ってください。 また、システムをアップグレードしたり、 もしくはカスタムカーネルを設定した場合に、 直前にインストールされていたカーネルは、 [.filename]#/boot/kernel.old/kernel# で指定できます。 普段のカーネルで使っているモジュールを指定したカーネルでロードする場合は、 次のようにします。 この場合は、完全修飾名を使う必要はありません。 [source,shell] .... unload set kernel="mykernel" boot-conf .... カーネルの自動設定スクリプトをロードします。 [source,shell] .... load -t userconfig_script /boot/kernel.conf .... [[boot-init]] === 最終ステージ カーネルがデフォルトの loader もしくは loader を迂回して boot2 によって読み込まれると、 起動フラグが調べられ、それに応じて動作が調整されます。<> には、 良く使われる起動フラグがまとめられています。 他の起動フラグの詳細については、 man:boot[8] を参照してください。 [[boot-kernel]] .起動時のカーネルオプション [cols="1,1", frame="none", options="header"] |=== | オプション | 説明 |`-a` |カーネル初期化中に、 ルートファイルシステムとしてマウントするデバイスを尋ねます。 |`-C` |CDROM からルートファイルシステムを起動します。 |`-s` |シングルユーザモードで起動します。 |`-v` |カーネル起動時に、より詳細な情報を表示します。 |=== カーネルの起動が完了すると、man:init[8] というユーザプロセスに制御が移されます。 これは [.filename]#/sbin/init#、 もしくは `loader` の `init_path` 変数で指定される場所にあります。 これは起動プロセスの最終ステージです。 起動シーケンスでは、 システム上で利用できるファイルシステムの一慣性を確認します。 もし UFS ファイルシステムにに問題があって `fsck` が不一致を修復できなければ、 管理者が問題を直接解決できるように、init はシステムをシングルユーザモードへと移行させます。 問題がなければ、システムはマルチユーザモードに移行します。 [[boot-singleuser]] ==== シングルユーザモード このモードには、ユーザが起動時に `-s` を指定した場合、あるいは loader で `boot_single` 変数を設定することによって移行します。 マルチユーザモードから `shutdown now` を呼び出すことでもこのモードに移行できます。 シングルユーザモードは、以下のメッセージで開始します。 [.programlisting] .... Enter full pathname of shell or RETURN for /bin/sh: .... ユーザが kbd:[Enter] を入力すると、 システムは Bourne シェルを起動します。 別のシェルを使うには、シェルのフルパスを入力してください。 シングルユーザモードは、 通常ファイルシステムの一貫性に問題があって起動できないシステムを修復したり、 起動設定ファイルの間違いを修正するために使われます。 また、`root` パスワードがわからなくなった場合に、 リセットするために使うことも出来ます。 シングルユーザモードのプロンプトは、 ローカルファイルシステムおよび設定ファイルへのアクセスを与えてくれますが、 ネットワーク接続は出来ません。 シングルユーザモードは、システムの修復には有用ですが、 システムが物理的に安全な場所になければ、 セキュリティのリスクがもたらされます。 デフォルトでは、システムに物理的にアクセス可能なユーザは、 シングルユーザモードで起動後はシステムをすべてコントロールできます。 [.filename]#/etc/ttys# でシステムの `console` が `insecure` に設定されている場合、 システムはシングルユーザモードに移行する前に `root` のパスワードを入力するように求めます。 `root` パスワードがわからなくなった場合のリセット機能が無効になっている間は、 セキュリティ対策が必要となります。 [[boot-insecure-console]] .[.filename]#/etc/ttys# の insecure コンソール [example] ==== [.programlisting] .... # name getty type status comments # # If console is marked "insecure", then init will ask for the root password # when going to single-user mode. console none unknown off insecure .... ==== `insecure` コンソールとは、 コンソールが物理的に安全でない (insecure) と考えられるため、 `root` のパスワードを知る人だけがシングルユーザモードを使えるという意味です。 [[boot-multiuser]] ==== マルチユーザモード init がファイルシステムが正常であると判断するか、 ユーザがシングルユーザモードでのコマンドを終了し、 `exit` を入力してシングルユーザモードを終了すると、 システムはマルチユーザモードへ移行し、 システムのリソースの設定を開始します。 リソース設定システムはデフォルト設定を [.filename]#/etc/defaults/rc.conf# から、 また、システム独自の細かな設定を [.filename]#/etc/rc.conf# から読み込みます。 そして [.filename]#/etc/fstab# に記述されるシステムファイルシステムをマウントします。 その後、ネットワークサービス、さまざまなシステムデーモン、 そして最後に、ローカルにインストールされた package の起動スクリプトを実行します。 リソース設定システムについてもっと知りたい場合には、 man:rc[8] を参照してください。また、[.filename]#/etc/rc.d# にあるスクリプトを実行してみてください。 [[device-hints]] == Device Hints システムの最初のスタートアップ時に、man:loader[8] は man:device.hints[5] を読み込みます。 このファイルにはカーネル起動の環境変数が格納されており、 これらの環境変数は "device hints" と呼ばれることがあります。デバイスドライバは、 デバイスを設定するために "device hints" を使用します。 <> で説明されているように device hints はステージ 3 ブートローダプロンプトでも設定できます。 変数は `set` を用いて追加したり、 `unset` を用いて削除できます。 `show` を用いて一覧を見ることもできます。 [.filename]#/boot/device.hints# に設定されている変数は、 上書きすることもできます。 ブートローダで設定した device hints の効果は一時的なものなので、 次回起動するときには無効になります。 システムが起動すると、man:kenv[1] コマンドですべてのカーネル環境変数をダンプすることができます。 [.filename]#/boot/device.hints# は 1 行につき一つの変数を設定でき、行頭の "#" はその行がコメントであることを示しています。 書式は次の通りです。 [source,shell] .... hint.driver.unit.keyword="value" .... ステージ 3 ブートローダ で設定するときの書式は次の通りです。 [source,shell] .... set hint.driver.unit.keyword=value .... ここで、`driver` はデバイスドライバの名前、 `unit` はデバイスドライバのユニット番号、 `keyword` はヒントキーワードです。 キーワードは以下のようなオプションです。 * `at`: デバイスがどのバスに接続されているか指定します。 * `port`: 使用する I/O ポートの開始アドレスを指定します。 * `irq`: 使用する IRQ を指定します。 * `drq`: 使用する DMA チャネルを指定します。 * `maddr`: 使用する物理メモリアドレスを指定します。 * `flags`: デバイスに対してさまざまなフラグを設定します。 * `disabled`: `1` が設定されていると、そのデバイスは無効になります。 デバイスドライバはこのリスト以外の変数を設定できるかもしれませんし、 このリスト以外の変数を必要とするかもしれないので、 ドライバのマニュアルを読むことをおすすめします。 より多くの情報を知りたければ、man:device.hints[5], man:kenv[1], man:loader.conf[5] および man:loader[8] を参照してください。 [[boot-shutdown]] == シャットダウン動作 man:shutdown[8] を用いてシステムを意図的にシャットダウンした場合、 man:init[8] は [.filename]#/etc/rc.shutdown# というスクリプトの実行を試みます。 そして、すべてのプロセスへ `TERM` シグナルを送り、続いてうまく終了できなかったプロセスへ `KILL` シグナルを送ります。 電源管理機能を持ったシステムで稼働している FreeBSD では `shutdown -p now` によって、 直ちに電源を落とすことができます。FreeBSD システムを再起動するには、 `shutdown -r now` を実行してください。 man:shutdown[8] を実行するには、 `root` か、`operator` のメンバでなければなりません。man:halt[8] や man:reboot[8] を利用することもできます。 より多くの情報を得るために、それらのマニュアルページや man:shutdown[8] を参照してください。 グループのメンバを変更するには、 crossref:users[users-synopsis,「この章では」] を参照してください。 [NOTE] ==== 電源管理機能には man:acpi[4] がモジュールとして読み込まれるか、 カスタムカーネルにコンパイルされて静的に組み込まれている必要があります。 ==== diff --git a/documentation/content/ja/books/handbook/cutting-edge/_index.adoc b/documentation/content/ja/books/handbook/cutting-edge/_index.adoc index e3ddb3e644..889ad80deb 100644 --- a/documentation/content/ja/books/handbook/cutting-edge/_index.adoc +++ b/documentation/content/ja/books/handbook/cutting-edge/_index.adoc @@ -1,1092 +1,1092 @@ --- -title: 第17章 FreeBSD のアップデートとアップグレード +title: 第16章 FreeBSD のアップデートとアップグレード part: パートIII. システム管理 prev: books/handbook/l10n next: books/handbook/partiv description: freebsd-update もしくは Git を使った FreeBSD システムを最新の状態に更新する方法、ベースシステム全体を再構築しインストールする方法などの説明 tags: ["updating", "upgrading", "documentation", "FreeBSD-STABLE", "FreeBSD-CURRENT", "Security Patches"] showBookMenu: true -weight: 21 +weight: 20 path: "/books/handbook/" --- [[updating-upgrading]] = FreeBSD のアップデートとアップグレード :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 -:sectnumoffset: 17 +:sectnumoffset: 16 :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/cutting-edge/ ifdef::env-beastie[] ifdef::backend-html5[] :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [[updating-upgrading-synopsis]] == この章では あるリリースから次のリリースまでの期間にも、 FreeBSD の開発は休みなく続けられています。 最新の開発ツリーと同期することを好む人がいる一方で、公式のリリース版を好んで使う方もいます。 しかしながら、公式のリリースといえども、 セキュリティや他の重要な修正のため、時にはアップデートが行われます。 使用しているバージョンに関わらず、FreeBSD は手元のシステムを最新の開発ツリーと同期するために必要なツールをすべて用意しているので、これらのツールを使ってバージョンのアップグレードを簡単に行うことができます。 この章では、開発ブランチを追いかける方法、および、FreeBSD システムをアップデートする基本的なツールについて解説します。 この章を読んで分かるのは: * freebsd-update もしくは Git を使った FreeBSD システムの更新方法 * インストールされているシステムと、変更が行われていない状態との比較方法。 * Git またはドキュメント用の ports を使って、 インストールされているドキュメントを最新版にアップデートする方法。 * 2 つの開発ブランチ、FreeBSD-STABLE と FreeBSD-CURRENT の違い * ベースシステム全体を再構築しインストールする方法 この章を読む前に、以下の準備をしましょう。 * ネットワーク接続の適切な設定 (crossref:advanced-networking[advanced-networking,高度なネットワーク]) * サードパーティ製のソフトウェアのインストール方法の習得 (crossref:ports[ports,アプリケーションのインストール - packages と ports]) [NOTE] ==== この章を通じて、FreeBSD のソースコードのダウンロードやアップデートに `git` が使われています。 必要に応じて package:devel/git[] port または package が使われることもあります。 ==== [[updating-upgrading-freebsdupdate]] == FreeBSD Update すみやかにセキュリティパッチを適用し、 オペレーティングシステムをアップグレードして、 最新のリリースに保つことは、システム管理における重要な側面です。 これらの処理を行うために FreeBSD には `freebsd-update` と呼ばれるユーティリティが用意されています。 このユーティリティを用いると、FreeBSD のセキュリティおよび eratta アップデートをバイナリによって行うことができます。 手動でパッチもしくは新しいカーネルをコンパイルし、インストールする必要はありません。 バイナリアップデートは、セキュリティチームがサポートしているすべてのアーキテクチャとリリースで利用できます。 https://www.FreeBSD.org/ja/security/[https://www.FreeBSD.org/ja/security/] には、サポートが行われているリリースや保守終了予定日の一覧があります。 このユーティリティは、マイナーリリースであったり、他のリリースブランチへのアップグレードにも対応しています。 新しいリリースにアップデートする前に、アップデートしようとしているリリースのアナウンスに目を通し、重要な情報がないかどうかを確認してください。 リリースのアナウンスは https://www.FreeBSD.org/ja/releases/[https://www.FreeBSD.org/ja/releases/] で確認できます。 [NOTE] ==== もし man:crontab[5] の中に man:freebsd-update[8] の機能が含まれていたら、 オペレーティングシステムのアップグレード作業を終えるまでは無効にしてください。 ==== この節では、`freebsd-update` で使われる設定ファイルの説明、 セキュリティパッチの適応方法のデモンストレーション、 オペレーティングシステムをアップグレードする際に考慮すべき点について説明します。 [[freebsdupdate-config-file]] === 設定ファイル `freebsd-update` のデフォルトの設定ファイルは、そのままでも用いることができます。 [.filename]#/etc/freebsd-update.conf# の設定をデフォルトからきめ細かく調整して、 アップデートプロセスを制御するユーザもいます。 利用可能なオプションについてはこのファイルのコメントで説明されていますが、以下の項目については補足が必要でしょう。 [.programlisting] .... # Components of the base system which should be kept updated. Components world kernel .... このパラメータは、FreeBSD のどの部分を最新に維持するかを設定します。 デフォルトでは、ベースシステム全体、そしてカーネルをアップデートします。 `src/base` や `src/sys` のように、個々の項目を指定することもできます。 この部分についてはデフォルトのままにしておき、アップデートする項目をユーザがリストに加える形にするのがベストでしょう。 ソースコードとバイナリが同期していないと、長い年月の間に悲惨な結果がもたらされる可能性があります。 [.programlisting] .... # Paths which start with anything matching an entry in an IgnorePaths # statement will be ignored. IgnorePaths /boot/kernel/linker.hints .... [.filename]#/bin# や [.filename]#/sbin# 等の特定のディレクトリをアップデートで変更しないように、これらのパスを追加してください。 このオプションは、ローカルの変更点を `freebsd-update` が上書きすることを防ぐ目的にも利用できます。 [.programlisting] .... # Paths which start with anything matching an entry in an UpdateIfUnmodified # statement will only be updated if the contents of the file have not been # modified by the user (unless changes are merged; see below). UpdateIfUnmodified /etc/ /var/ /root/ /.cshrc /.profile .... このオプションは、指定したディレクトリにある設定ファイルを、ローカルで変更されていない場合のみアップデートします。 ユーザがこれらのファイルを変更していると、変更されたファイルの自動アップデートは行われません。 他に、`KeepModifiedMetadata` という別のオプションが存在します。 このオプションは、`freebsd-update` がマージ中に変更点を保存するようにします。 [.programlisting] .... # When upgrading to a new FreeBSD release, files which match MergeChanges # will have any local changes merged into the version from the new release. MergeChanges /etc/ /var/named/etc/ /boot/device.hints .... `freebsd-update` がマージすべきファイルが存在するディレクトリの一覧です。 ファイルのマージのプロセスは、man:mergemaster[8] と同様 man:diff[1] パッチの連続ですが、選択肢は少なく、マージを承認するか、エディタを起動するか、`freebsd-update` を中断するかどうかを選んでください。 もし、心配な点があれば、[.filename]#/etc# をバックアップしてからマージを承認してください。 `mergemaster` の詳細な情報については、man:mergemaster[8] で確認してください。 [.programlisting] .... # Directory in which to store downloaded updates and temporary # files used by FreeBSD Update. # WorkDir /var/db/freebsd-update .... ここではすべてのパッチや一次ファイルを置くディレクトリを指定しています。 バージョンをアップグレードするのであれば、この場所には少なくともギガバイトの空き容量が必要です。 [.programlisting] .... # When upgrading between releases, should the list of Components be # read strictly (StrictComponents yes) or merely as a list of components # which *might* be installed of which FreeBSD Update should figure out # which actually are installed and upgrade those (StrictComponents no)? # StrictComponents no .... このオプションを `yes` に設定すると、`freebsd-update` は `Components` のリストが完全に正しいと判断し、このリスト以外の変更点については取り扱いません。 `freebsd-update` は、効率的に `Components` リストに属するファイルをアップデートします。 [[freebsdupdate-security-patches]] === セキュリティパッチの適用 FreeBSD のセキュリティパッチを適用する過程は簡単になりました。 管理者は `freebsd-update` を使うことで、 システムを完全にパッチがあたった状態に保つ事ができます。 FreeBSD セキュリティ勧告の詳細については、crossref:security[security-advisories,FreeBSD セキュリティ勧告] の節で説明されています。 以下のコマンドを実行すると、FreeBSD のセキュリティパッチがダウンロードされ、インストールされます。 最初のコマンドは、未対応のパッチがあるかどうかを調べます。 もし未対応のパッチがある場合には、パッチが当てられた際に変更されるファイルのリストが作成されます。 2 番目のコマンドはパッチを適用します。 [source,shell] .... # freebsd-update fetch # freebsd-update install .... アップデートによってカーネルにパッチが適用された場合には、システムを再起動して新しいカーネルで起動する必要があります。 もし、実行中のバイナリにパッチが適用された場合には、パッチが当てられたバイナリが使われるように、影響するアプリケーションを再起動する必要があります。 [NOTE] ==== 通常、ユーザはシステムを再起動する必要があります。 カーネルアップデートによりシステムの再起動が必要かどうかを調べるには、`freebsd-version -k` と `uname -r` を実行してください。 これら 2 つのコマンドの結果が異なる場合には、システムを再起動してください。 ==== 毎日一度アップデートがないかどうかを自動的に確認するように設定するには、 以下のエントリを [.filename]#/etc/crontab# に追加してください。 [.programlisting] .... @daily root freebsd-update cron .... パッチが存在すると、自動的にダウンロードされますが、適用はされません。 ``root``宛てにメールで、ダウンロードされたパッチを確認し、`freebsd-update install` とともに手動でインストールする必要のあることが通知されます。 うまく行かなかった場合には、`freebsd-update` を以下のように実行すると、最後の変更までロールバックできます。 [source,shell] .... # freebsd-update rollback Uninstalling updates... done. .... カーネルまたはカーネルモジュールがアップデートされた場合には、 完了後にもう一度システムを再起動して、 影響のあったバイナリを再起動してください。 `freebsd-update` ユーティリティが自動的にアップデートするカーネルは [.filename]#GENERIC# のみです。 カスタムカーネルをインストールしている場合には、`freebsd-update` によりインストールした後、カーネルを再構築し、もう一度インストールする必要があります。 デフォルトのカーネルの名前は _GENERIC_ です。 man:uname[1] コマンドを使ってインストールされているかどうかを確認できます。 [NOTE] ==== [.filename]#GENERIC# カーネルを、常に [.filename]#/boot/GENERIC# に置いておいてください。 さまざまな問題を解決する際や、バージョンをアップグレードする際に助けとなります。 [.filename]#GENERIC# カーネルを用意する方法については、<> を参照してください。 ==== [.filename]#/etc/freebsd-update.conf# のデフォルトの設定を変更しない限り、`freebsd-update` は、他の更新と共にカーネルソースをアップデートします。 新しいカスタムカーネルの再構築と再インストールは、通常通り行うことができます。 `freebsd-update` は、常にカーネルをアップデートするとは限りません。 `freebsd-update install` によってカーネルソースが変更されなかった場合には、カスタムカーネルを再構築する必要はありません。 しかしながら `freebsd-update` は、[.filename]#/usr/src/sys/conf/newvers.sh# を常にアップデートします。 これは、現在のシステムのパッチレベルを `uname -r` が `-p` で表示する時にこのファイルが参照されます。 そのため、何も変更されていない場合でも、カスタムカーネルを再構築することにより、`uname` がシステムの正確なパッチレベルを報告するようになります。 各システムにインストールされているアップデートをすばやく把握できるようになるので、特に複数のシステムを管理するときに助けとなります。 [[freebsdupdate-upgrade]] === メジャーおよびマイナーバージョンのアップグレード FreeBSD のマイナーバージョン間のアップグレード、たとえば、FreeBSD 9.0 から FreeBSD 9.1 へのアップグレードは、_マイナーバージョン_ アップグレードと呼ばれます。 _メジャーバージョン_ アップグレードは、FreeBSD 9.X から FreeBSD 10.X へのアップグレードといった、FreeBSD のメジャーバージョンが変わるようなアップグレードのことです。 どちらのアップグレードも、`freebsd-update` のターゲットにリリース番号を指定する事で実行できます。 [NOTE] ==== カスタムカーネルを使っているシステムでは、アップグレードを行う前に [.filename]#GENERIC# カーネルが、[.filename]#/boot/GENERIC# に置かれている事を確認してください。 [.filename]#GENERIC# カーネルを用意する方法については、<> を参照してください。 ==== 以下のコマンドを実行すると、FreeBSD 9.0 のシステムを FreeBSD 9.1 にアップグレードします。 [source,shell] .... # freebsd-update -r 9.1-RELEASE upgrade .... コマンドを実行すると、`freebsd-update` は設定ファイルと現在のシステムを評価し、 アップデートするために必要な情報を収集します。 画面には、どのコンポーネントが認識され、どのコンポーネントが認識されていないといったリストが表示されます。 たとえば以下のように表示されます。 [source,shell] .... Looking up update.FreeBSD.org mirrors... 1 mirrors found. Fetching metadata signature for 9.0-RELEASE from update1.FreeBSD.org... done. Fetching metadata index... done. Inspecting system... done. The following components of FreeBSD seem to be installed: kernel/smp src/base src/bin src/contrib src/crypto src/etc src/games src/gnu src/include src/krb5 src/lib src/libexec src/release src/rescue src/sbin src/secure src/share src/sys src/tools src/ubin src/usbin world/base world/info world/lib32 world/manpages The following components of FreeBSD do not seem to be installed: kernel/generic world/catpages world/dict world/doc world/games world/proflibs Does this look reasonable (y/n)? y .... ここで、`freebsd-update` はアップグレードに必要なすべてのファイルをダウンロードします。 何をインストールし、どのように進むかといった質問をされることもあります。 カスタムカーネルを使っていると、上記のステップ中に以下のような警告が表示されます。 [source,shell] .... WARNING: This system is running a "MYKERNEL" kernel, which is not a kernel configuration distributed as part of FreeBSD 9.0-RELEASE. This kernel will not be updated: you MUST update the kernel manually before running "/usr/sbin/freebsd-update install" .... この時点ではこの警告を無視してもかまいません。 アップデートされた [.filename]#GENERIC# カーネルは、アップグレードプロセスの途中で利用されます。 すべてのパッチがローカルシステムへダウンロードされたら、次にパッチが適用されます。 このプロセスには時間がかかります。 この時間はコンピュータの性能およびワークロードに依存します。 その後、設定ファイルがマージされます。 このプロセスでは、ユーザはファイルをマージするか、画面上にエディタを立ち上げて手動でマージするかを尋ねられます。 プロセスが進むごとに、成功したマージのすべての結果の情報がユーザに示されます。 マージに失敗したり、無視した場合には、プロセスが中断します。 ユーザによっては [.filename]#/etc# のバックアップを取り、[.filename]#master.passwd# や [.filename]#group# のような重要なファイルを後で手動でマージする方もいます。 [NOTE] ==== すべてのパッチは別のディレクトリでマージされており、まだ、システムには反映されていません。 すべてのパッチが正しく適用され、すべての設定ファイルがマージされてプロセスがスムーズに進んだら、ユーザは以下のコマンドを用いて、変更点をディスクに反映してください。 [source,shell] .... # freebsd-update install .... ==== パッチは最初にカーネルとカーネルモジュールに対して当てられます。 システムがカスタムカーネルを実行している場合には、man:nextboot[8] を使って次回の再起動時のカーネルを、アップデートされた [.filename]#/boot/GENERIC# に設定してください。 [source,shell] .... # nextboot -k GENERIC .... [WARNING] ==== [.filename]#GENERIC# カーネルで再起動する前に、カーネルにシステムが適切に起動するために必要なすべてのドライバが含まれていること、もしアップデートしているコンピュータがリモートでアクセスしているのであれば、ネットワーク接続に必要なすべてのドライバも含まれていることを確認してください。 特に、これまで実行しているカスタムカーネルが、カーネルモジュールとして提供されているビルドインの機能を含んでいるのであれば、これらのモジュールを一時的に [.filename]#/boot/loader.conf# の機能を用いて、[.filename]#GENERIC# に読み込んでください。 アップグレードプロセスが終わるまでは、重要ではないサービスを無効にするとともに、必要のないディスクやネットワークのマウントなども避けることが推奨されています。 ==== アップデートされたカーネルでコンピュータを再起動してください。 [source,shell] .... # shutdown -r now .... システムがオンラインに戻ったら、以下のコマンドを使って `freebsd-update` を再び実行してください。 アップデートプロセスの状態は保存されているので、`freebsd-update` を実行すると、古い共有ライブラリおよびオブジェクトファイルを削除するステップに進みます。 [source,shell] .... # freebsd-update install .... [NOTE] ==== 使用しているライブラリのバージョン番号の付けられ方によって、 3 つのインストールフェーズが 2 つになる場合もあります。 ==== アップグレードはこれで終了です。 もしメジャーアップグレードを行った場合には、<> で説明されているようにすべての ports および package を再構築してください。 [[freebsd-update-custom-kernel-9x]] ==== FreeBSD 9.X 以降のシステムにおけるカスタムカーネル `freebsd-update` を使う前に、[.filename]#GENERIC# カーネルが [.filename]#/boot/GENERIC# に置かれていることを確認してください。 ただ一度だけカスタムカーネルを構築したのであれば、[.filename]#/boot/kernel.old# は [.filename]#GENERIC# カーネルそのものです。 このディレクトリの名前を [.filename]#/boot/GENERIC# へと変更してください。 もし、2 回以上カスタムカーネルを構築した後であったり、カスタムカーネルを構築した回数がわからなければ、現在のオペレーティングシステムのバージョンの [.filename]#GENERIC# カーネルを入手してください。 コンピュータへの物理的なアクセスが可能であれば、インストールメディアから [.filename]#GENERIC# カーネルをインストールできます。 [source,shell] .... # mount /cdrom # cd /cdrom/usr/freebsd-dist # tar -C/ -xvf kernel.txz boot/kernel/kernel .... 別な方法としては、 [.filename]#GENERIC# カーネルをソースから再構築して、 インストールしてください。 [source,shell] .... # cd /usr/src # make kernel __MAKE_CONF=/dev/null SRCCONF=/dev/null .... `freebsd-update` がこのカーネルを [.filename]#GENERIC# カーネルとして認識するために、[.filename]#GENERIC# コンフィグレーションファイルは、とにかく変更してはいけません。 また、特別なオプションを指定しないで構築してください。 `freebsd-update` は、[.filename]#/boot/GENERIC# が存在する事だけを必要とするので、[.filename]#GENERIC# カーネルで再起動する必要はありません。 [[freebsdupdate-portsrebuild]] ==== メジャーバージョンアップグレード後の package のアップグレード 一般的に、マイナーバージョンアップグレードの後では、インストールされているアプリケーションは、問題なく動作するでしょう。 メジャーバージョンが異なるとアプリケーションバイナリーインタフェース (ABI) が異なるため、サードパーティ製のアプリケーションの多くは動作しなくなるでしょう。 メジャーバージョンアップグレード後には、インストールされているすべての packages, ports をアップグレードする必要があります。 package は、`pkg upgrade` を使ってアップグレードできます。 インストールされている ports をアップグレードする場合には、package:ports-mgmt/portmaster[] といったユーティリティを使ってください。 すべての package の強制的なアップグレードでは、バージョン番号が上がらない package に対しても、リポジトリから最新のバージョンで、インストールされている package を置き換えます。 FreeBSD のメージャーバージョンが変わるようなアップグレードでは、ABI のバージョンも変わるため、このようなアップグレードが必要になります。 強制的なアップグレードを行うには、以下のように実行してください。 [source,shell] .... # pkg-static upgrade -f .... インストールされているすべてのアプリケーションを再構築するには、以下のコマンドを実行してください。 [source,shell] .... # portmaster -af .... このコマンドを実行すると、設定を変更するオプションを持つアプリケーションは、設定変更のスクリーンを表示し、ユーザからの指示待ちの状態で停止します。 この振る舞いをやめ、デフォルトのオプションを使用するには、上記のコマンドに `-G` を含めてください。 ソフトウェアのアップグレードが終わったら、最後にもう一度 `freebsd-update` を実行して、すべてのアップグレードプロセスのやり残し作業を行い、アップグレードのプロセスを完了してください。 [source,shell] .... # freebsd-update install .... [.filename]#GENERIC# カーネルを一時的に読み込んでいたのであれば、crossref:kernelconfig[kernelconfig,FreeBSD カーネルのコンフィグレーション] に書かれている手順に従って、新しいカスタムを構築し、インストールしてください。 コンピュータを再起動し、新しい FreeBSD を立ち上げてください。 これでアップグレードのプロセスは完了です。 [[freebsdupdate-system-comparison]] === システムの状態の比較 `freebsd-update` を用いて、インストールされている FreeBSD の状態と、正しく動作することが分かっている状態とを比較できます。 このコマンドは、現在のシステムのユーティリティ、ライブラリ、設定ファイルを評価するので、組み込みの侵入検知システム (IDS) として使うことができます。 [WARNING] ==== このコマンドは、package:security/snort[] のような本当の IDS の置き換えになるものではありません。 `freebsd-update` はデータをディスクに保存するので、不正な変更が行われる可能性があります。 `kern.securelevel` と、`freebsd-update` のデータを使用しないときに、読み取りのみの許可属性に設定されているファイルシステムに置くことで、不正な変更の可能性を低くできますが、よりよい解決方法は、DVD または安全に保存されている外部 USB ディスクのような安全なディスクとシステムを比較することです。 組み込まれているユーティリティを用いた、別の方法による IDS 機能については、crossref:security[security-ids,FreeBSD バイナリによる検出] の節をご覧ください。 ==== 比較を行うには、 結果の出力先のファイル名を指定してください。 [source,shell] .... # freebsd-update IDS >> outfile.ids .... システムは検査され、リリースファイルの SHA256 ハッシュ値と現在インストールされているファイルのハッシュ値がファイルの一覧と共に、指定した出力先のファイルに送られます。 これらの行は極めて長いのですが、出力形式は簡単にすぐに解析できます。 たとえば、これらのリリースで異なっているすべてのファイルを知りたいのであれば、以下のコマンドを実行してください。 [source,shell] .... # cat outfile.ids | awk '{ print $1 }' | more /etc/master.passwd /etc/motd /etc/passwd /etc/pf.conf .... 上の表示例では出力は切り捨てられており、実際にはもっと多くのファイルが存在します。 これらのファイルには、運用中に変更されるファイルがあります。 たとえば、[.filename]#/etc/passwd# はユーザがシステムに追加されると変更されます。 また、カーネルモジュールは、`freebsd-update` によりアップデートされるため、変更されます。 このような特別なファイルやディレクトリを除外するには、それらを [.filename]#/etc/freebsd-update.conf# の `IDSIgnorePaths` オプションに追加してください。 [[updating-bootcode]] == ブートコードのアップデート ブートコードおよびブートローダのアップデートプロセスについては、 man:gpart[8], man:gptboot[8], man:gptzfsboot[8] および man:loader.efi[8] のマニュアルを参照してください。 [[updating-upgrading-documentation]] == ドキュメントのアップデート ドキュメントは、FreeBSD オペレーティングシステムの必須要素です。 FreeBSD ドキュメントの最新バージョンは、FreeBSD ウェブサイト (link:https://docs.FreeBSD.org/[Documentation Portal]) から入手できますが、 FreeBSD ウェブサイト、ハンドブック、FAQ および文書の最新版をローカルに用意しておくと便利です。 この章では、ソースまたは Ports Collection を使って、ローカルの FreeBSD ドキュメントを最新に保つ方法を説明します。 ドキュメントを編集したり、ドキュメントの誤りを報告する方法については、新しい貢献者のための FreeBSD ドキュメンテーションプロジェクト入門 (extref:{fdp-primer}[FreeBSD Documentation Project Primer]) をご覧ください。 [[updating-installed-documentation]] === ソースから FreeBSD ドキュメントをインストールする ソースから FreeBSD ドキュメントを構築するのに必要なツールは、FreeBSD のベースシステムには含まれていません。 必要なツールは、新しい貢献者のための FreeBSD ドキュメンテーションプロジェクト入門で extref:{fdp-primer}[説明されているステップ, overview-quick-start] に従ってインストールしてください。 インストールしたら、git を使って、ドキュメントのソースをダウンロードしてください。 [source,shell] .... # git clone https://git.FreeBSD.org/doc.git /usr/doc .... 最初にドキュメントのソースをダウンロードするには少し時間がかかります。 ダウンロードが終わるまでお待ちください。 ダウンロードしたドキュメントのソースをアップデートするには、 以下のコマンドを実行してください。 [source,shell] .... # git pull .... 最新のドキュメントのソースのスナップショットを [.filename]#/usr/doc# に用意できたら、インストールされているドキュメントをアップデートする準備はすべて整いました。 ドキュメントをアップデートするには、以下のように入力してください。 [source,shell] .... # cd /usr/doc # make .... [[current-stable]] == 開発ブランチを追いかける FreeBSD には二つの開発ブランチがあります。 それは FreeBSD-CURRENT と FreeBSD-STABLE です。 この節ではそれぞれのブランチと対象としている読者についての説明と、 どのようにしてシステムの対応するブランチを最新の状態に保つかについて説明します。 [[current]] === FreeBSD-CURRENT を使う FreeBSD-CURRENT とは FreeBSD の開発の "最前線" なので、FreeBSD-CURRENT のユーザは高い技術力を持つことが要求されます。 そこまでの技術力を持っていないが、開発ブランチを追いかけたいと考えているユーザは、かわりに FreeBSD-STABLE を追いかけると良いでしょう。 FreeBSD-CURRENT は FreeBSD の最新のソースコードであり、中には現在開発途上のソフトウェア、実験的な変更、あるいは過渡的な機能などが含まれています。 また、この中に入っている機能がすべて、次の公式リリースに入るとは限りません。 FreeBSD-CURRENT をソースからほぼ毎日コンパイルしている人はたくさんいますが、短い期間ではコンパイルさえできない状態になっている時期もあります。 これらの問題は可能な限り迅速に解決されますが、FreeBSD-CURRENT が不幸をもたらすか、それとも新しい機能をもたらすかは、まさにソースコードを同期した瞬間によるのです! FreeBSD-CURRENT は、次の 3 つの重要なグループを対象としています。 . ソースツリーのある部分に関して活発に作業している FreeBSD コミュニティのメンバ。 . 活発にテストしている FreeBSD コミュニティのメンバ。 彼らは、種々の問題を解決するのに時間を惜しまない人々であり、 さまざまな変更に関する提案や FreeBSD の大まかな方向付けを行ないたいと思っている人々でもあり、 パッチも提出します。 . さまざまな事に目を向け、 参考のために最新のソースを使いたいと思っていたり、 時々コメントやコードを寄稿したいと考えているユーザ。 FreeBSD-CURRENT は、次のリリースの前に、最も早く新しい機能を入手する手段として、期待しては__いけません__。 リリース前の機能は十分にテストされていないため、バグを含んでいる可能性が大いにあるためです。 また、バグを修正するための素早い方法でもありません。 いかなるコミットは、元からあるバグを修正するのと同じく、新しいバグを生み出すおそれがあります。 FreeBSD-CURRENT には "公式のサポート" はありません。 FreeBSD-CURRENT を追いかけるには . {freebsd-current} と {dev-commits-src-main} メーリングリストに加わってください。 さまざまな人がシステムの現在の状態について述べているコメントを見たり、FreeBSD-CURRENT の現在の状態に関する重要な情報を見逃さないために、 _必須の_ ことです。 + {dev-commits-src-main} メーリングリストでは、それぞれの変更についての commit ログが記録されています。 また、それに関して起こり得る副作用の情報を得ることができますので、参加する価値のあるメーリングリストです。 + これらのメーリングリストに入るには、 {mailing-lists} をたどって参加したいメーリングリストをクリックし、手順の説明にしたがってください。 FreeBSD-CURRENT だけでなく、ソースツリー全体の変更点を追いかけるのであれば、 {dev-commits-src-all} メーリングリストを購読してください。 . FreeBSD-CURRENT のソースを同期してください。 通常は `git` を使って FreeBSD Git リポジトリの `main` ブランチから -CURRENT コードをチェックアウトしてください (crossref:mirrors[git,「Git を使う」] を参照してください)。 . リポジトリのサイズが大きいため、興味のある部分や、パッチを当てる部分のソースのみを同期するユーザもいます。 しかしながら、ソースからオペレーティングシステムをコンパイルしようと思っているユーザは、一部分だけではなく、FreeBSD-CURRENT の _すべて_ をダウンロードする必要があります。 + FreeBSD-CURRENT をコンパイルする前に [.filename]#/usr/src/Makefile# を注意深く読み、<> に書かれている手順に従ってください。 {freebsd-current} と [.filename]#/usr/src/UPDATING# を読めば、次のリリースへ向けて移ってゆくに当たって、ときどき必要となる既存システムからの新システムの構築手順についての最新情報が得られるでしょう。 . アクティブになってください! FreeBSD-CURRENT のユーザには、 拡張やバグ潰しに関して提案することが勧められています。 コードを伴う提案はいつでも歓迎されます! [[stable]] === FreeBSD-STABLE を使う FreeBSD-STABLE とは定期的に公開されるリリースを作成するための開発ブランチです。 このブランチに加えられる変更は FreeBSD-CURRENT よりゆっくりで、原則として、事前に FreeBSD-CURRENT で試験ずみであるという特徴があります。 ただ__そうであっても__、これは開発用ブランチの一つであり、ある時点における FreeBSD-STABLE のソースがどんな場合にも使えるものであるとは限りません。 このブランチはもう一つの開発の流れというだけであって、エンドユーザ向けのものではありません。 もし試験をする資源的な余裕がない場合は、代わりに最新の FreeBSD リリースを使ってください。 FreeBSD の開発プロセスに興味があったり、それに対する貢献を考えていて、特にそれが次回の FreeBSD のリリースに関係するものであるなら FreeBSD-STABLE を追うことを考えると良いでしょう。 FreeBSD-STABLE ブランチはいつもコンパイルができ、安定に動作すべきですが、それが保証されているというわけではありません。 FreeBSD-STABLE のユーザは FreeBSD-CURRENT よりも多いため、FreeBSD-CURRENT で発見されなかったバグが FreeBSD-STABLE で発見され、ときどきそれが問題となることがあるのは避けることができません。 このような理由から、盲目的に FreeBSD-STABLE を追いかけるべきではありません。 特に、開発環境もしくはテスト環境でコードを十分に試験せずに、プロダクション品質が要求されるサーバを FreeBSD-STABLE にアップグレードしては__いけません__。 FreeBSD-STABLE を追いかけるには . FreeBSD-STABLE の構築に関連する事柄や、その他の注意すべき点 に関する情報を得るために、 {freebsd-stable} メーリングリストに加わってください。 また開発者は議論の余地がある修正や変更を考えている場合に、このメーリングリストで公表し、提案された変更に関して問題が生じるかどうかを返答する機会をユーザに与えます。 + 追いかけているブランチに関連する git メーリングリストに参加してください。 たとえば、{betarel-current-major}-STABLE ブランチを追いかけているユーザは {dev-commits-src-branches} メーリングリストに参加してください。 このリストでは、変更がなされるごとに作成される commit log やそれに伴う起こりうる副作用についての情報が記録されています。 + これらのメーリングリストに入るには、 {mailing-lists} をたどって参加したいメーリングリストをクリックし、手順の説明にしたがってください。 ソースツリー全体の変更点を追いかけるには、 {dev-commits-src-all} メーリングリストを購読してください。 . 新しい FreeBSD-STABLE システムをインストールするには、 crossref:mirrors[mirrors,ミラーサイト] から最近の FreeBSD-STABLE リリースをインストールするか、毎月公開されている FreeBSD-STABLE からビルドされたスナップショットを使ってください。 スナップショットの詳細については、link:https://www.FreeBSD.org/ja/snapshots/[www.freebsd.org/ja/snapshots] をご覧ください。 + 既に FreeBSD が動いているシステムを FreeBSD-STABLE にアップグレードするには、 crossref:mirrors[svn,svn] を使って、希望する開発ブランチのソースをチェックアウしてください。 `stable/9` といったブランチ名は、link:https://www.FreeBSD.org/releng/[www.freebsd.org/releng] で説明されています。 . FreeBSD-STABLE をコンパイルしたり FreeBSD-STABLE へとアップグレードする前に、 [.filename]#/usr/src/Makefile# を注意深く読み、 <> に書かれている手順に従ってください。 {freebsd-stable} と [.filename]#/usr/src/UPDATING# を読んで、次のリリースへ向けて移ってゆくに当たって、ときどき必要となる既存システムからの新システムの構築手順についての最新情報を得てください。 [[translate-n-number]] === n-番号 バグを追跡する際は、問題が発生したシステムの構築に用いられたソースコードのバージョンを把握することが重要となります。 FreeBSD は、バージョン情報をカーネルのコンパイル時に埋め込みます。 man:uname[1] を使ってこの情報を調べることができます。以下はその例です。 [source,shell] .... % uname -a FreeBSD 14.0-CURRENT #112 main-n247514-031260d64c18: Tue Jun 22 20:43:19 MDT 2021 fred@machine:/usr/home/fred/obj/usr/home/fred/git/head/amd64.amd64/sys/FRED .... 4 番目のフィールドを見ると、いくつかの要素から構成されていることがわかります。 [source,shell] .... main-n247514-031260d64c18 main <.> n247514 <.> 031260d64c18 <.> <.> .... <.> Git ブランチ名。 注意: n-番号の比較は、FreeBSD プロジェクトで作成されたブランチ (`main`, `stable/XX` および `releng/XX`) でのみ有効です。 ローカルブランチでは、親ブランチのコミットと n-番号が重複してしまいます。 <.> n-番号は、ハッシュ値が含まれるようになった git リポジトリの使用開始からのコミットを数えたものです。 <.> チェックアウトしたツリーのハッシュ値。 <.> `-dirty` が表示されることがあります。 変更点がコミットされていないツリーでカーネルが構築された場合に表示されます。 この例では、チェックアウトから変更なく FRED カーネルが構築されたため、出力されていません。 `git rev-list` コマンドを使って、ハッシュ値に対応する n-番号を調べることができます。 以下はその例です。 [source,shell] .... % git rev-list --first-parent --count 031260d64c18 <.> 247514 <.> .... <.> 変換する git ハッシュ値 (ここでは先の例のハッシュ値を使用しています) <.> n-番号 この数字は通常それほど重要ではありません。 しかしながら、バグの修正がコミットされた時には、この数字を使うことで、使用しているシステムでバグが修正されているかどうかを簡単に調べることができます。 ハッシュ値は簡単に目にする識別子である一方で n-番号はそうではありません。 そのため、開発者は通常 n-番号ではなくコミットのハッシュ値 (または、ハッシュ値を含む URL) を参照します。 セキュリティ勧告および errata 情報では n-番号が示されており、使用しているシステムの番号と直接比較できます。 `git rev-list` コマンドは、レポジトリのリビジョンをすべてカウントしますが、git の shallow clone はその情報を取得しないため、shallow clone を使用しなければならない場合には、n-番号は信頼できません。 [[makeworld]] == ソースを用いた FreeBSD のアップデート ソースをコンパイルしてFreeBSD をアップデートする方法は、 バイナリを用いたアップデートに比べ、いくつもの利点があります。 特定のハードウェアをうまく利用するためのオプションを設定してコードを構築できます。 ベースシステムの特定の箇所の設定をデフォルトの設定から変更したり、必要がない部分を完全に削除して構築することもできます。 システムを構築することによるアップデートは、バイナリアップデートをインストールするだけのアップデートに比べ時間がかかりますが、利用環境に合わせた FreeBSD を作成するような完全なカスタマイズが可能です。 [[updating-src-quick-start]] === クィックスタート 以下は FreeBSD をソースから構築してアップデートする典型的な方法についてのクイックリファレンスです。 その後の節では、各プロセスをより詳細に説明します。 [.procedure] ==== . アップデートおよびビルド + [source,shell] .... # git pull /usr/src <.> check /usr/src/UPDATING <.> # cd /usr/src <.> # make -j4 buildworld <.> # make -j4 kernel <.> # shutdown -r now <.> # etcupdate -p <.> # cd /usr/src <.> # make installworld <.> # etcupdate -B <.> # shutdown -r now <.> .... <.> 最新版のソースを入手してください。 ソースの入手およびアップデートに関する情報については <> をご覧ください。 <.> ソースの構築の前後で必要となる手動の作業について、 [.filename]#/usr/src/UPDATING# を確認してください。 <.> ソースが置かれているディレクトリに移動してください。 <.> world (カーネルを除くすべて) をコンパイルしてください。 <.> カーネルをコンパイルしてインストールしてください。 ここに書かれているコマンドは、`make buildkernel installkernel` と同じです。 <.> 新しいカーネルを使うため、 システムを再起動してください。 <.> installworld を行う前に、[.filename]#/etc/# に置かれている設定ファイルのアップデートとマージを行ってください。 <.> ソースが置かれているディレクトリに移動してください。 <.> world をインストールしてください。 <.> [.filename]#/etc/# に置かれている設定ファイルのアップデートとマージを行ってください。 <.> 新しく構築された world およびカーネルを利用するため、 システムを再起動してください。 ==== [[updating-src-preparing]] === ソースを用いたアップデートのための準備 [.filename]#/usr/src/UPDATING# を読んでください。 このファイルには、 アップデートの前後で必要となる手動の作業について書かれています。 [[updating-src-obtaining-src]] === ソースコードのアップデート FreeBSD のソースコードは [.filename]#/usr/src/# に置かれています。 このソースコードのアップデートには、Git バージョン管理システムを利用する方法が推奨されています。 まず、ソースコードがバージョン管理下にあることを確認してください。 [source,shell] .... # cd /usr/src # git remote --v origin https://git.freebsd.org/src.git (fetch) origin https://git.freebsd.org/src.git (push) .... この結果は、[.filename]#/usr/src/# がバージョン管理下にあり、man:git[1] を使ってアップデートできることを示しています。 [source,shell] .... # git pull /usr/src .... このディレクトリをアップデートしていない期間が長いと、アップデートのプロセスには時間がかかります。 このプロセスが終わると、ソースコードは最新となり、次節以降で説明する構築のプロセスを実行できます。 .ソースコードの入手 [NOTE] ==== `fatal: not a git repository` という出力が出た場合には、ファイルがなかったり、別な方法によりインストールされているので、新しくソースコードをチェックアウトする必要があります。 [[updating-src-obtaining-src-repopath]] .FreeBSD のバージョンおよびリポジトリブランチ [cols="1,1,1", options="header"] |=== | uname -r の出力 | リポジトリパス | 説明 |`_X.Y_-RELEASE` |`releng/_X.Y_` |このリリースバージョンに対する重大なセキュルティへの対応およびバグの修正パッチのみが適用されています。 このブランチは、ほとんどのユーザに推奨されます。 |`_X.Y_-STABLE` |`stable/_X_` | リリースバージョンに対し、 そのブランチにおけるすべての開発の成果が反映されたものです。 _STABLE_ は、 Applications Binary Interface (ABI) が変更されないことを意味しており、 このブランチの以前のバージョンでコンパイルされたソフトウェアは、 このバージョンでも実行できることを意味しています。 たとえば、FreeBSD 10.1 で実行するようにコンパイルされたソフトウェアは、 FreeBSD 10-STABLE においても実行できます。 STABLE ブランチは、 時期によってはユーザに影響するようなバグや非互換性を持つことがあります。 これらは通常すぐに修正されます。 |`_X_-CURRENT` |`main` |リリースが行われていない最新の FreeBSD の開発バージョンです。 CURRENT ブランチは大きなバグや非互換があることもあるので、 高度な知識を持ったユーザのみ使用が推奨されます。 |=== man:uname[1] を使って FreeBSD のバージョンを確認してください。 [source,shell] .... # uname -r 10.3-RELEASE .... <> から分かるように、`10.3-RELEASE` のアップデートのためのソースコードのパスは、`releng/10.3` です。 このパスは、ソースコードをチェックアウトする時に使います。 [source,shell] .... # mv /usr/src /usr/src.bak <.> # git clone --branch releng/10.3 https://git.FreeBSD.org/src.git /usr/src <.> .... <.> この古いディレクトリを、 邪魔にならないように移動してください。 このディレクトリ以下に対して変更を行ってなければ、 削除しても構わないでしょう。 <.> リポジトリの URL に <> に記載されているパスを追加します。 3 番目のパラメータには、 ローカルシステム上でソースコードが置かれるディレクトリを指定します。 ==== [[updating-src-building]] === ソースからの構築 まず最初に _world_ (カーネルを除くオペレーティングシステムのすべて) をコンパイルします。 このステップを最初に実行するのは、カーネルの構築を最新のツールを使って行うようにするためです。 このステップが終わったら、カーネルそのものを構築します。 [source,shell] .... # cd /usr/src # make buildworld # make buildkernel .... コンパイルされたコードは [.filename]#/usr/obj# に書き出されます。 これは基本のステップです。 構築をコントロールする追加のオプションについては、 以下で説明します。 [[updating-src-building-clean-build]] ==== クリーンビルドの実行 FreeBSD ビルドシステムのいくつかのバージョンは、オブジェクトが一時的に置かれるディレクトリ [.filename]#/usr/obj# に前回のコンパイルされたコードを残します。 これにより、変更されていないコードを再コンパイルせずにすむので、その後の構築時間を短縮できます。 すべてを再構築するには、構築を開始する前に、`cleanworld` を実行してください。 [source,shell] .... # make cleanworld .... [[updating-src-building-jobs]] ==== ジョブの数の設定 マルチコアプロセッサを搭載するシステムでは、構築のためのジョブの数を増やすことで、構築にかかる時間を短縮できます。 `sysctl hw.ncpu` を使って、コアの数を確認してください。 ジョブの数がどのように構築の速さに影響するかを確実に知るには、プロセッサにより異なりますし、FreeBSD のバージョンにより使用されるビルドシステムも変わるため、実際に試してみるしか方法はありません。 試してみる最初のジョブの数の候補としては、コアの数の半分から倍の数の間で検討してみてください。 ジョブの数は、`-j` を使って指定します。 [[updating-src-building-jobs-example]] .構築のジョブの数を増やす [example] ==== 以下は 4 つのジョブで world とカーネルを構築する例です。 [source,shell] .... # make -j4 buildworld buildkernel .... ==== [[updating-src-building-only-kernel]] ==== カーネルのみを構築する ソースコードが変更された場合には、`buildworld` を完了しなければいけません。 その後、いつでも `buildkernel` でカーネルを構築できます。 カーネルだけを構築するには、以下のように実行してください。 [source,shell] .... # cd /usr/src # make buildkernel .... [[updating-src-building-custom-kernel]] ==== カスタムカーネルの構築 FreeBSD 標準のカーネルは、[.filename]#GENERIC# と呼ばれる _カーネルコンフィグレーションファイル_ に基づいています。 [.filename]#GENERIC# カーネルには、最も良く使われるデバイスドライバやオプションが含まれています。 しかしながら、特定の目的に合わせてデバイスドライバやオプションを削除したり追加するためには、カスタムカーネルを構築することが有用であったり、必要となることがあります。 たとえば、極端に RAM が制限されているような小さな組み込みのコンピュータを開発しているユーザであれば、 必要のないデバイスドライバやオプションを削除することで、 カーネルを少しでも小さくできるでしょう。 カーネルのコンフィグレーションファイルは、 [.filename]#/usr/src/sys/arch/conf/# に置かれています。ここで、 _arch_ は `uname -m` の出力です。 ほとんどのコンピュータは `amd64` であり、 コンフィグレーションファイルが置かれているディレクトリは [.filename]#/usr/src/sys/amd64/conf/# です。 [TIP] ==== [.filename]#/usr/src# は、削除されたり作り直されたりする可能性があるため、カスタムカーネルのコンフィグレーションファイルは、[.filename]#/root# のような別のディレクトリで管理することが好ましいです。 カーネルコンフィグレーションファイルは、[.filename]#conf# ディレクトリにリンクします。 このディレクトリが削除されたり、上書きされた場合には、カーネルコンフィグレーションファイルを新しいディレクトリにもう一度リンクしてください。 ==== カスタムコンフィグレーションファイルは、[.filename]#GENERIC# コンフィグレーションファイルをコピーして作成できます。 たとえば、ストレージサーバ用の [.filename]#STORAGESERVER# という名前の新しいカスタムカーネルは、以下のようにして作成できます。 [source,shell] .... # cp /usr/src/sys/amd64/conf/GENERIC /root/STORAGESERVER # cd /usr/src/sys/amd64/conf # ln -s /root/STORAGESERVER . .... その後 [.filename]#/root/STORAGESERVER# を編集し、 man:config[5] で示されるデバイスやオプションを追加したり削除してください。 コマンドラインからカーネルコンフィグレーションファイルを `KERNCONF` に指定することで、 カスタムカーネルを構築できます。 [source,shell] .... # make buildkernel KERNCONF=STORAGESERVER .... [[updating-src-installing]] === コンパイルされたコードのインストール `buildworld` および `buildkernel` が完了したら、 新しいカーネルと world をインストールしてください。 [source,shell] .... # cd /usr/src # make installkernel # shutdown -r now # cd /usr/src # make installworld # shutdown -r now .... カスタムカーネルを構築した場合は、 新しいカスタムカーネルを `KERNCONF` に設定して実行してください。 [source,shell] .... # cd /usr/src # make installkernel KERNCONF=STORAGESERVER # shutdown -r now # cd /usr/src # make installworld # shutdown -r now .... [[updating-src-completing]] === アップデートの完了 アップデートの完了までに、いくつかの最終作業が残されています。 デフォルトから変更した設定ファイルを新しいバージョンのファイルにマージし、古くなったライブラリを見つけて削除した後に、システムを再起動します。 [[updating-src-completing-merge-etcupdate]] ==== man:etcupdate[8] を用いた設定ファイルのマージ man:etcupdate[8] は、[.filename]#/etc/# 以下のファイルのように installworld のプロセスで更新されないファイルをアップデートするツールです。 このツールは、ローカルにあるファイルに対する変更点を 3-way マージでアップデートします。 man:mergemaster[8] の対話的なプロンプトと対照的に、このツールはユーザによる操作を最小限になるように設計されています。 [NOTE] ==== 一般的に、man:etcupdate[8] は、実行する際に特定の引数を必要としません。 しかしながら、man:etcupdate[8] を最初に使用した際に、どのようなアップデートが行われたかの健全性をチェックする便利なコマンドがあります。 [source,shell] .... # etcupdate diff .... このコマンドにより、ユーザは設定の変更を検証できます。 ==== man:etcupdate[8] が自動的にファイルをマージできない場合には、 以下を実行することで、手動の操作により衝突を解決できます。 [source,shell] .... # etcupdate resolve .... [WARNING] ==== man:mergemaster[8] から man:etcupdate[8] に移行する際に、 最初に man:etcupdate[8] を実行すると、不適切に変更点がマージされ、誤った衝突が起こる可能性があります。 これを避けるには、ソースを更新して新しく buildworld を行う *前に* 以下のステップを行ってください。 [source,shell] .... # etcupdate extract <.> # etcupdate diff <.> .... <.> [.filename]#/etc# ファイルを保存するデータベースをブートストラップしてください。 詳細については、 man:etcupdate[8] を参照してください。 <.> ブートストラップ後、差分を確認してください。 不必要なローカルでの変更点をなくし、将来的なアップデートにおいて、衝突が起きる可能性が低くなるようにしてください。 ==== [[updating-src-completing-merge-mergemaster]] ==== man:mergemaster[8] を用いた設定ファイルのマージ man:mergemaster[8] を用いることで、システムの設定ファイルに行われている変更を、これらのファイルの新しいバージョンにマージできます。 man:mergemaster[8] は、設定ファイルのアップデートで推奨されている man:etcupdate[8] の代価のツールです。 `-Ui` オプションを使って man:mergemaster[8] を実行すると、 ユーザが手を加えていないファイルのアップデートおよび新しく追加されたファイルのインストールを自動的に行います。 [source,shell] .... # mergemaster -Ui .... ファイルのマージを手動で行う必要がある時は、ファイルの中で残す箇所の選択を対話的におこなうようなインタフェースが表示さます。 詳細については、man:mergemaster[8] をご覧ください。 [[updating-src-completing-check-old]] ==== 使われなくなったファイルやライブラリの確認 アップデート後に、使われなくなったファイルやディレクトリが残ることがあります。 これらのファイルは、 [source,shell] .... # make check-old .... で確認でき、以下のようにして削除できます。 [source,shell] .... # make delete-old .... 同様に使われなくなったライブラリが残ることもあります。 これらのライブラリは、 [source,shell] .... # make check-old-libs .... で確認でき、以下のようにして削除できます。 [source,shell] .... # make delete-old-libs .... これらの古いライブラリを利用しているプログラムは、ライブラリが削除されると動かなくなります。 これらのプログラムは、古いライブラリを削除した後に、再構築もしくは置き換える必要があります。 [TIP] ==== 古いファイルとディレクトリのすべてを削除しても問題ないことを確認したら、コマンドに `BATCH_DELETE_OLD_FILES` を設定することで、各ファイルを削除する際に kbd:[y] および kbd:[Enter] を押さなくても済むようにできます。 以下はその例です。 [source,shell] .... # make BATCH_DELETE_OLD_FILES=yes delete-old-libs .... ==== [[updating-src-completing-restart]] ==== アップデート後の再起動 コンピュータを再起動して、すべての変更を反映させることが、 アップデートの最後におこなう作業です。 [source,shell] .... # shutdown -r now .... [[small-lan]] == 複数のマシンで追いかける 複数のコンピュータで同じソースツリーを追いかけていて、全部のマシンにソースをダウンロードして全部を再構築するのは、ディスクスペース、ネットワーク帯域、そして CPU サイクルの無駄使いです。 解決策は 1 つのマシンに仕事のほとんどをさせ、残りのマシンは NFS 経由でそれをマウントする、というものです。 このセクションではそのやり方を概観します。NFS の使い方の詳細については、crossref:advanced-networking[network-nfs,「NFS」] をご覧下さい。 まず初めに、同じバイナリで動かそうとするマシンたちを決めます。 このマシンたちのことを__ビルドセット__と呼びます。 それぞれのマシンはカスタムカーネルを持っているかもしれませんが、同じユーザランドバイナリを動かそうというのです。 このビルドセットから、 __ビルドマシン__となるマシンを 1 台選びます。 ベースシステムとカーネルを構築するのはこのマシンになります。 理想的には、このマシンは `make buildworld` と `make buildkernel` を実行するのに十分な CPU を持った速いマシンであるべきです。 _テストマシン_ となるべきマシンも選んでください。 更新されたソフトウェアを使う前にそのマシンでテストするのです。 テストマシンはかなり長い時間落ちていても だいじょうぶなマシン__であったほうがいいでしょう__。 ビルドマシンでもかまいませんが、ビルドマシンである必要はありません。 このビルドセットのマシンはすべて [.filename]#/usr/obj# と [.filename]#/usr/src# をビルドマシンから FTP 経由でマウントする必要があります。 ビルドセット自体が複数ある場合は、[.filename]#/usr/src# はひとつのビルドマシン上にあるべきです。 他のマシンからはそれを NFS マウントするようにしましょう。 ビルドセットのすべてのマシン上の [.filename]#/etc/make.conf# と [.filename]#/etc/src.conf# がビルドマシンと一致していることを確認してください。 つまり、ビルドマシンはビルドセットのどのマシンもインストールしようとしているベースシステムを全部ビルドしなければならないということです。 また、各ビルドマシンは [.filename]#/etc/make.conf# にそれぞれのビルドマシンのカーネル名を `KERNCONF` で指定し、ビルドマシンは自分自身のカーネルから順に全部のカーネル名を `KERNCONF` にリストアップしてください。 ビルドマシンは各マシンのカーネル設定ファイルを [.filename]#/usr/src/sys/arch/conf# に持っていなければなりません。 ビルドマシンにて、<> に書いてあるようにカーネルとベースシステムを構築してください。 でも、まだビルドマシンにはインストールしないでください。 そのかわり、ビルドしたカーネルをテストマシンにインストールしてください。 FTP 経由で [.filename]#/usr/src# および [.filename]#/usr/obj# をテストマシンにマウントしてください。 その後、`shutdown now` を実行してシングルユーザモードに移行し、新しいカーネルとベースシステムをインストールし、いつもするように `mergemaster` を実行してください。 終わったら、再起動して通常のマルチユーザ動作に戻します。 テストマシンにあるものすべてがちゃんと動いている確信が得られたら、同じ手順でビルドセットの他のマシンにも新しいソフトウェアをインストールします。 ports ツリーにも同じ方法が使えます。 最初のステップは、ビルドセットのすべてのマシンが NFS 経由で [.filename]#/usr/ports# をマウントすることです。 そして、distfiles を共有するように [.filename]#/etc/make.conf# を設定します。 NFS マウントによってマップされる `root` ユーザが何であれ、`DISTDIR` はそのユーザが書き込める共通の共有ディレクトリに設定する必要があります。 ports をローカルでビルドする場合には、各マシンは `WRKDIRPREFIX` を自分のマシンのビルドディレクトリに設定しなければなりません。 また、ビルドシステムが packages をビルドしてビルドセットのコンピュータに配布するのであれば、`DISTDIR` と同じようにビルドシステム上の `PACKAGES` ディレクトリも設定してください。 diff --git a/documentation/content/ja/books/handbook/disks/_index.adoc b/documentation/content/ja/books/handbook/disks/_index.adoc index c6754f70ee..1689e847d5 100644 --- a/documentation/content/ja/books/handbook/disks/_index.adoc +++ b/documentation/content/ja/books/handbook/disks/_index.adoc @@ -1,1981 +1,1981 @@ --- -title: 第15章 ストレージ +title: 第14章 ストレージ part: パートIII. システム管理 prev: books/handbook/security next: books/handbook/l10n showBookMenu: true -weight: 19 +weight: 18 path: "/books/handbook/" --- [[disks]] = ストレージ :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 -:sectnumoffset: 15 +:sectnumoffset: 14 :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/audit/ ifdef::env-beastie[] ifdef::backend-html5[] :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [[disks-synopsis]] == この章では この章では、FreeBSD におけるディスクの使用方法を説明します。 これにはメモリディスク、ネットワークに接続されたディスク、 および標準的な SCSI/IDE 記憶デバイスが含まれます。 この章では、以下の分野について説明します。 * 物理ディスク上のデータ構成 について記述するために FreeBSD が使用する用語 (パーティションおよびスライス) * システムにハードディスクを追加する方法 * メモリディスクのような仮想ファイルシステムを設定する方法 * 使用できるディスク容量を制限するためにクォータを設定する方法 * 攻撃者から保護するためにディスクを暗号化する方法 * FreeBSD で CD や DVD を作成する方法 * バックアップのためのさまざまな記憶メディアオプション * FreeBSD で利用できるバックアッププログラムの使用方法 * フロッピーディスクにバックアップする方法 * スナップショットとは何か、そしてそれを効果的に使用する方法 [[disks-naming]] == デバイス名 以下は、FreeBSD で対応している物理記憶デバイスとそれに対応するデバイス名のリストです。 [[disk-naming-physical-table]] .物理ディスクへの名前付け [cols="1,1", options="header"] |=== | ドライブの種類 | ドライブのデバイス名 |IDE ハードドライブ |`ad` |IDE CD-ROM ドライブ |`acd` |SCSI ハードドライブおよび USB 大容量記憶デバイス |`da` |SCSI CD-ROM ドライブ |`cd` |その他の非標準的 CD-ROM ドライブ |ミツミ CD-ROM は `mcd`, Sony CD-ROM は `scd`, 松下/パナソニック CD-ROM は `matcd` |フロッピードライブ |`fd` |SCSI テープドライブ |`sa` |IDE テープドライブ |`ast` |フラッシュドライブ |DiskOnChip(R) フラッシュデバイスは `fla` |RAID ドライブ |Adaptec(R) AdvancedRAID は `aacd`, Mylex(R) は `mlxd` および `mlyd`, AMI MegaRAID(R) は `amrd`, Compaq Smart RAID は `idad`, 3ware(R) RAID は``twed`` |=== [[disks-adding]] == ディスクの追加 現在一つしかドライブがない計算機に新しく SCSI ディスクを追加したいとしましょう。まずコンピュータの電源を切り、 コンピュータやコントローラ、 ドライブの製造元の説明書に従ってドライブを取り付けます。 このあたりの手順は非常に多岐にわたるため、 詳細はこの文書の範囲外です。 `root` ユーザでログインします。 ドライブの取り付け後は [.filename]#/var/run/dmesg.boot# を調べて新しいディスクが見つかっていることを確認しておきます。 この例では、新しく付けたドライブは [.filename]#da1# で、 我々はそれを [.filename]#/1# にマウントしたいとしましょう (もし IDE ドライブを付けようとしているのなら、デバイス名は 4.0 以前のシステムでは [.filename]#wd1#, ほとんどの 4.x システムでは [.filename]#ad1# になるでしょう)。 FreeBSD は IBM-PC 互換のコンピュータで動くため、 PC BIOS のパーティションを考慮に入れる必要があります。 これは従来の BSD パーティションとは異なります。PC ディスクは 4 つまでの BIOS パーティションエントリを持つことができます。 もしそのディスクを本当に FreeBSD 専用にしたい場合には _専用_ モードで用いることもできます。 そうでない場合には、FreeBSD は PC BIOS パーティションのどれか一つの中に入れることになります。 FreeBSD では、従来の BSD パーティションと混乱しないように PC BIOS パーティションのことを__スライス__と呼びます。 また、別の OS がインストールされていたコンピュータで使われていたが FreeBSD 専用にするディスク上でもスライスを用いることができます。 これは、他の OS の `fdisk` ユーティリティを混乱させないためです。 スライスの場合、ドライブは [.filename]#/dev/da1s1e# として加えられるでしょう。これは、SCSI ディスクでユニット番号は 1 (二つめの SCSI ディスク), スライスは 1 (PC BIOS のパーティションが 1) で BSD パーティション [.filename]#e#, と読みます。 専用ディスクの場合だと単純に [.filename]#/dev/da1e# として加えられるでしょう。 === man:sysinstall[8] の利用 [.procedure] ==== . sysinstall の操作 + `sysinstall` の使い易いメニューを利用して、 新しいディスクのパーティション分けやラベル付けを行なうことができます。 `root` ユーザでログインするか `su` コマンドを用いるかして root 権限を取得します。 `/stand/sysinstall` を実行して `Configure` メニューに入ります。`FreeBSD Configuration Menu` の中でスクロールダウンして `Fdisk` の項目を選びます。 . fdisk パーティションエディタ + fdisk では、ディスク全体を FreeBSD で使うために `A` を入力します。 "remain cooperative with any future possible operating systems" と聞かれたら `YES` と答えます。 `W` で変更をディスクに書き込みます。ここで `q` と入力して FDISK エディタを抜けます。 次にマスタブートレコードについて聞かれます。 ここでは既に動いているシステムにディスクを追加しようとしているので `None` を選びます。 . ディスクラベルエディタ + 次に sysinstall を終了し、 もう一度起動する必要があります。同じ手順を踏んで今度は `Label` オプションを選択し、 `Disk Label Editor` に入ります。 ここでは従来の BSD パーティションを作成します。 一つのディスクは `a` から `h` までのラベルがついた最大 8 つのパーティションを持つことができます。 いくつかのパーティションラベルは特別な用途に用いられます。 `a` パーティションはルートパーティション ([.filename]#/#) です。したがって、システムディスク (つまり起動ディスク) のみに `a` パーティションがあるべきです。`b` パーティションはスワップパーティションに用いられ、 複数のディスクにスワップパーティションを作ることができます。 `c` は専用モードにおけるディスク全体、 もしくはスライスモードにおけるスライス全体を指します。 他のパーティションは汎用的に用いられます。 + sysinstall のラベルエディタ は、ルートパーティションでもスワップパーティションでもないパーティションには、`e` パーティションを採用しようとします。ラベルエディタでファイルシステムを作成するには `C` を入力してください。 FS (ファイルシステム) かスワップかを聞かれたら `FS` を選びマウントポイント (たとえば [.filename]#/mnt#) を入力します。 インストール後のモードでディスクを追加する場合、 sysinstall は [.filename]#/etc/fstab# にエントリを追加しないため、 ここで指定するマウントポイントはそれほど重要ではありません。 + さて、ディスクに新しいラベルを書き込み、 そこにファイルシステムを作る準備が整いました。早速 `W` を叩いて実行しましょう。 sysinstall からの、 新しいパーティションをマウントできない、 というエラーは無視してください。Label Editor から抜け、 sysinstall を終了します。 . 終了 + 最後に [.filename]#/etc/fstab# を編集し、 新しいディスクのエントリを追加します。 ==== === コマンドラインユーティリティの利用 ==== スライスの利用 このセットアップ方法では、 すでにコンピュータに他のオペレーティングシステムがインストールされていても 正しく協調動作することが可能で、他のオペレーティングシステムの `fdisk` ユーティリティを混乱させることもありません。 新しいディスクにインストールする場合は、 この方法を用いることが推奨されています。 後述する `専用モード` は、 そうしなければならない理由がある時にのみ、 利用するようにしてください。 [source,shell] .... # dd if=/dev/zero of=/dev/da1 bs=1k count=1 # fdisk -BI da1 # 新しいディスクの初期化 # disklabel -B -w -r da1s1 auto # ディスクにラベルを付ける # disklabel -e da1s1 # 作成したディスクラベルを編集し、パーティションを追加する # mkdir -p /1 # newfs /dev/da1s1e # 作成したすべてのパーティションに対してこれを繰り返す # mount /dev/da1s1e /1 # パーティションをマウントする # vi /etc/fstab # /etc/fstab に適切なエントリを追加する .... IDE ディスクを使う場合は [.filename]#da# の部分を [.filename]#ad# とします。4.X より前のシステムでは、 (訳注: [.filename]#ad# ではなく) [.filename]#wd# としてください。 ==== 専用モード 新しいドライブを他の OS と共有しない場合には `専用` モードを用いることもできます。 このモードはマイクロソフトの OS を混乱させることを憶えておいてください (しかし、それらによって壊されることはありません)。 一方、IBM の OS/2(R) はどんなパーティションでも見つけたら理解できなくても "専有" します。 [source,shell] .... # dd if=/dev/zero of=/dev/da1 bs=1k count=1 # disklabel -Brw da1 auto # disklabel -e da1 # `e' パーティションの作成 # newfs -d0 /dev/da1e # mkdir -p /1 # vi /etc/fstab # /dev/da1e エントリの追加 # mount /1 .... もう一つの方法は次の通り。 [source,shell] .... # dd if=/dev/zero of=/dev/da1 count=2 # disklabel /dev/da1 | disklabel -BrR da1 /dev/stdin # newfs /dev/da1e # mkdir -p /1 # vi /etc/fstab # /dev/da1e エントリの追加 # mount /1 .... [NOTE] ==== FreeBSD 5.1-RELEASE から、従来の man:disklabel[8] プログラムは man:bsdlabel[8] ユーティリティに置き換えられました。man:bsdlabel[8] では、 使用されていない数多くのオプションやパラメタが削除されました。 たとえば `-r` オプションは man:bsdlabel[8] では取り除かれました。詳細については man:bsdlabel[8] のマニュアルページを参照してください。 ==== [[raid]] == RAID [[raid-soft]] === ソフトウェア RAID [[ccd]] ==== Concatenated Disk Driver (CCD) の設定 大容量記録に関する解決法を選択する際にもっとも重視すべき要素は、 速度、信頼性、そして費用です。 三つを同時にバランスよく実現することは稀です。 通常、速くて信頼性のある大容量記録装置は高価であり、 費用を抑えようとすると速度または信頼性のどちらかが犠牲になります。 ここで例にあげるシステムの設計においては、 費用が最も重要な要素として、次に速度、最後に信頼性が選択されています。 このシステムでのデータ転送速度は結局のところネットワークによって制限されます。 信頼性は大変重要です。ただし、以下で説明する CCD ドライブは、 データ自体はすでに CD-R に完全にバックアップしてあるもの (したがって交換は簡単にできます) の、オンラインデータの役割をさせています。 あなた自身の要求事項を決定することは、 大容量記録に関する解決法を選択することの最初の段階です。 もしあなたの要求事項が費用より速度または信頼性を優先するなら、 解決法はこのシステムとは違うものになるでしょう。 [[ccd-installhw]] ===== ハードウェアのインストール IDE システムディスクに加えて、Western Digital 製の 30GB, 5400RPM の IDE ディスク三台を使って、 以下に説明されているような約 90GB のオンラインストレージとなる CCD ディスクを作成しました。各 IDE ディスクがそれぞれの IDE コントローラとケーブルをもっていることが理想的ですが、 費用を最低限にするために、 IDE コントローラを追加していません。その代わり、それぞれの IDE コントローラがマスタデバイスを一つ、 スレーブデバイスを一つ持つように、 ディスクはジャンパを使って設定されています。 再起動の際に、システム BIOS が接続されたディスクを自動的に検出するように設定されました。 より重要なことは、FreeBSD が再起動の際にそれらを検出することです。 [.programlisting] .... ad0: 19574MB [39770/16/63] at ata0-master UDMA33 ad1: 29333MB [59598/16/63] at ata0-slave UDMA33 ad2: 29333MB [59598/16/63] at ata1-master UDMA33 ad3: 29333MB [59598/16/63] at ata1-slave UDMA33 .... [NOTE] ==== FreeBSD がディスクをすべて検出しないときは、 ジャンパを正しく設定してあるか確認してください。多くの IDE ドライブは "ケーブルセレクト" ジャンパを持っています。 これはマスタ/スレーブの関係を設定するジャンパでは _ありません_。ドライブの文書を参照して、 正しいジャンパ設定を見つけてください。 ==== 次に、ファイルシステムの一部分として、 それらをどのように接続するのかを考慮します。man:vinum[8] および man:ccd[4] の両方を検討すべきでしょう。この設定では、man:ccd[4] を選択しました。 [[ccd-setup]] ===== CCD の設定 man:ccd[4] ドライバは、いくつかの同じディスクを使って、 一つの論理的ファイルシステムに連結することができます。 man:ccd[4] を使用するためには、カーネルが man:ccd[4] に対応している必要があります。 次の行をカーネルコンフィギュレーションファイルに追加して、 カーネルを再構築し、再インストールしてください。 [.programlisting] .... pseudo-device ccd 4 .... 5.X システムでは、 上記の代わりに次の行を追加しなければなりません。 [.programlisting] .... device ccd .... [NOTE] ==== FreeBSD 5.X では man:ccd[4] デバイスの数を指定する必要はありません。man:ccd[4] デバイスドライバは自己複製するようになりました - 新しいデバイスインスタンスは、 必要に応じてその都度自動的に作成されます。 ==== FreeBSD 3.0 以降では、 カーネルモジュールを読み込んで man:ccd[4] に対応することもできます。 man:ccd[4] を設定するために、まず man:disklabel[8] を使用してディスクにラベルを書き込まなくてはなりません。 [.programlisting] .... disklabel -r -w ad1 auto disklabel -r -w ad2 auto disklabel -r -w ad3 auto .... このコマンドはディスク全体を示す [.filename]#ad1c#, [.filename]#ad2c# および [.filename]#ad3c# に対するディスクラベルを作成します。 [NOTE] ==== FreeBSD 5.1-RELEASE から、従来の man:disklabel[8] プログラムは man:bsdlabel[8] ユーティリティに置き換えられました。man:bsdlabel[8] では、 使用されていない数多くのオプションやパラメタが削除されました。 たとえば `-r` オプションは man:bsdlabel[8] では取り除かれました。詳細については man:bsdlabel[8] のマニュアルページを参照してください。 ==== 次に、ディスクラベルのタイプを変更します。 man:disklabel[8] を使用してディスクラベルを編集してください。 [.programlisting] .... disklabel -e ad1 disklabel -e ad2 disklabel -e ad3 .... このコマンドは `EDITOR` 環境変数に設定されているエディタ (一般的には man:vi[1]) でそれぞれのディスクの現在のディスクラベルを開きます。 変更されていないディスクラベルは以下のようになります。 [.programlisting] .... 8 partitions: # size offset fstype [fsize bsize bps/cpg] c: 60074784 0 unused 0 0 0 # (Cyl. 0 - 59597) .... man:ccd[4] で使用する `e` パーティションを作成します。通常では `c` パーティションの行をコピーすれば良いでしょう。しかし、 `fstype` は `4.2BSD` でなければ _なりません_。 ディスクラベルは以下のようになるでしょう。 [.programlisting] .... 8 partitions: # size offset fstype [fsize bsize bps/cpg] c: 60074784 0 unused 0 0 0 # (Cyl. 0 - 59597) e: 60074784 0 4.2BSD 0 0 0 # (Cyl. 0 - 59597) .... [[ccd-buildingfs]] ===== ファイルシステムの構築 [.filename]#ccd0c# デバイスノードはまだ存在していないかも知れません。 そのときは、次のコマンドを実行して作成してください。 [.programlisting] .... cd /dev sh MAKEDEV ccd0 .... [NOTE] ==== FreeBSD 5.0 では man:devfs[5] が [.filename]#/dev# 以下のデバイスノードを自動的に管理するので、 ``MAKEDEV``を使用する必要はありません。 ==== すべてのディスクにラベルを書き込んだので、 man:ccd[4] を構築してください。 これを行うためには、以下のようなオプションで man:ccdconfig[8] を使います。 [.programlisting] .... ccdconfig ccd0 32 0 /dev/ad1e /dev/ad2e /dev/ad3e .... 各オプションの使用法と意味は以下の通りです。 * 一番目の引数は設定するデバイスです。この例の場合は [.filename]#/dev/ccd0c# です。 [.filename]#/dev/# の部分はオプションです。 * ファイルシステムに対するインタリーブです。インタリーブは、 ディスクブロック内のストライプサイズを定義します。 ディスクブロックは通常 512 バイトです。したがって 32 インタリーブは 16,384 バイトとなります。 * これは man:ccdconfig[8] に対するフラグです。 ドライブミラーリングを有効にしたい場合、 ここにフラグを指定します。 この設定では man:ccd[4] に対するミラーリングは提供しませんので、 0 (ゼロ) を指定しています。 * この man:ccdconfig[8] に対する最後の引数は、 アレイ内に置くデバイスです。 それぞれのデバイスに対する完全なパス名を使用します。 man:ccdconfig[8] を実行すると man:ccd[4] が設定されます。 これでファイルシステムをインストールすることが可能です。 オプションについて man:newfs[8] を参照するか、 次のように実行してください。 [.programlisting] .... newfs /dev/ccd0c .... [[ccd-auto]] ===== 自動的に設定する 一般的に、再起動するたびに man:ccd[4] をマウントしたいと思うでしょう。これを行うために、 まず設定をしなければなりません。次のコマンドを用いて、 現在の設定を [.filename]#/etc/ccd.conf# に書き出します。 [.programlisting] .... ccdconfig -g > /etc/ccd.conf .... [.filename]#/etc/ccd.conf# が存在すると、 再起動の際に `/etc/rc` スクリプトが `ccdconfig -C` を実行します。これにより、 man:ccd[4] は自動的に設定された後、マウントされます。 [NOTE] ==== シングルユーザモードで起動している場合には、 man:ccd[4] を man:mount[8] する前に、 アレイを設定するために次のコマンドを実行する必要があります。 [.programlisting] .... ccdconfig -C .... ==== 自動的に man:ccd[4] をマウントするには、 [.filename]#/etc/fstab# に man:ccd[4] のエントリ追加します。このように設定すると起動時にマウントされます。 [.programlisting] .... /dev/ccd0c /media ufs rw 2 2 .... [[vinum]] ==== Vinum ボリュームマネージャ Vinum ボリュームマネージャは、 仮想ディスクドライブを実装したブロックデバイスドライバです。 Vinum は、ディスクハードウェアをブロックデバイスインタフェースから 分離し、データを配置します。 その結果、ディスク記憶装置を従来のスライスで扱うのと比較して、 柔軟性、性能および信頼性が向上しています。 man:vinum[8] は RAID-0, RAID-1 および RAID-5 モデル、 そしてそれぞれの組合せを実装しています。 man:vinum[8] の詳細については Vinum ボリュームマネジャ を参照してください。 [[raid-hard]] === ハードウェア RAID FreeBSD は、さまざまなハードウェア RAID コントローラにも対応しています。これらのデバイスはアレイを制御するための 特別なソフトウェアを FreeBSD で必要することなく、 RAID サブシステムを制御します。 カード上の BIOS を使用して、 カードはそれ自身でディスク操作のほとんどを制御します。以下は Promise IDE RAID コントローラを使用した設定の簡単な説明です。 このカードがインストールされ、システムが起動したときには、 情報の入力を促すプロンプトを表示します。 指示にしたがってカードの設定画面に進んでください。 接続されたドライブを組み合わせるように設定することができます。 設定後、ディスクは FreeBSD に対して単一のドライブのように見えます。 他の RAID レベルは適宜設定できます。 === ATA RAID1 アレイの再構築 FreeBSD はアレイ内の障害ディスクを動作中に交換できます。 ただし、再起動前にそれを検知していることが必要です。 [.filename]#/var/log/messages# または man:dmesg[8] の出力に次のような行があるでしょう。 [.programlisting] .... ad6 on monster1 suffered a hard error. ad6: READ command timeout tag=0 serv=0 - resetting ad6: trying fallback to PIO mode ata3: resetting devices .. done ad6: hard error reading fsbn 1116119 of 0-7 (ad6 bn 1116119; cn 1107 tn 4 sn 11) status=59 error=40 ar0: WARNING - mirror lost .... man:atacontrol[8] を使用して詳細を調べてください。 [source,shell] .... # atacontrol list ATA channel 0: Master: no device present Slave: acd0 ATA/ATAPI rev 0 ATA channel 1: Master: no device present Slave: no device present ATA channel 2: Master: ad4 ATA/ATAPI rev 5 Slave: no device present ATA channel 3: Master: ad6 ATA/ATAPI rev 5 Slave: no device present # atacontrol status ar0 ar0: ATA RAID1 subdisks: ad4 ad6 status: DEGRADED .... [.procedure] ==== . ディスクを安全に取り外すために、 まずアレイから切り離します。 + [source,shell] .... # atacontrol detach 3 .... + . ディスクを取り外します。 . スペアのディスクを取り付けます。 + [source,shell] .... # atacontrol attach 3 Master: ad6 ATA/ATAPI rev 5 Slave: no device present .... + . アレイを再構築します。 + [source,shell] .... # atacontrol rebuild ar0 .... + . 再構築コマンドは完了するまで他の操作を受け付けません。しかし、 もう一つ別のターミナルを (kbd:[Alt+Fn] を押して) 開き、 次のコマンドを実行すると進行状態を確認することができます。 + [source,shell] .... # dmesg | tail -10 [output removed] ad6: removed from configuration ad6: deleted from ar0 disk1 ad6: inserted into ar0 disk1 as spare # atacontrol status ar0 ar0: ATA RAID1 subdisks: ad4 ad6 status: REBUILDING 0% completed .... + . 操作が完了するまでお待ちください。 ==== [[creating-cds]] == 光メディア (CD & DVD) の作成と使用 === はじめに CD は他の一般的なディスクと異なる様々な特徴を持っています。 そもそもユーザが書き込むことができません。 また遅延なしで連続的に読み出せるように、 トラック間をヘッドが移動しないですむようにデザインされています。 さらにこのサイズのメディアの中ではシステムをまたぐデータの 移動が比較的簡単でもあります。 CD はトラックの概念を持っていますが、 これはデータを連続的に読み出すためのものであってディスクの物理特性ではありません。 FreeBSD で CD を作成するには、まず CD のトラックとなるデータファイルを用意し、 そのトラックを CD に書き込みます。 ISO 9660 ファイルシステムはこの様な差異を扱うべく設計されました。 その結果、ファイルシステムは一般的に使用するのに差しつかえない程度に 制限されて標準化されています。幸いなことに、ISO 9660 ファイルシステムには拡張機構が提供されています。適切に書かれた CD は、 拡張機構に対応したシステムでは拡張を利用して、そうでないシステムでは 拡張機構を使用しない範囲で動作するようになっています。 package:sysutils/mkisofs[] プログラムは ISO 9660 ファイルシステムを含むデータファイルを作成するのに使われます。 これには様々な拡張をサポートするオプションがあり、 以下で説明します。 このソフトウェアは、ports の package:sysutils/mkisofs[] からインストールすることができます。 CD に書き込むためのツールは、お使いの CD ライタが ATAPI 接続か否かにも依存します。ATAPI CD ライタなら、ベースシステムの一部である `burncd` プログラムを使います。SCSI や USB の CD ライタなら、ports の package:sysutils/cdrecord[] をインストールして `cdrecord` プログラムを使うべきでしょう。 `burncd` が対応しているドライブは限定されています。 ドライブが対応されているかどうかを確認するには、 http://www.freebsd.dk/ata/[CD-R/RW supported drives] にある一覧を見てください。 [NOTE] ==== FreeBSD 5.X または FreeBSD 4.8-RELEASE 以降のバージョンを使用している場合、 <> を使用すると ATAPI ハードウェア上で SCSI ドライブ用の `cdrecord` および他のツールを使用できるようになります。 ==== [[mkisofs]] === mkisofs package:sysutils/mkisofs[] は UNIX(R) ファイルシステムの名前空間におけるディレクトリツリーのイメージとして ISO 9660 ファイルシステムを作成します。 最も簡単な使い方は以下の通りです。 [source,shell] .... # mkisofs -o imagefile.iso /path/to/tree .... このコマンドは _/path/to/tree_ 以下のディレクトリツリーのコピーである ISO 9660 ファイルシステムを含んだ _imagefile.iso_ ファイルを作成します。この過程において、ファイル名は標準的な ISO 9660 ファイルシステムの制限に適合するようなファイル名に対応づけられ、 ISO ファイルシステムでファイル名を文字化できないファイルは除外されます。 この制限を回避するために利用できるオプションはいくつもあります。 特に `-R` オプションは UNIX(R) システムで標準的な Rock Ridge 拡張を有効にします。`-J` オプションは Microsoft のシステムで標準的な Joliet 拡張を有効にし、 `-hfs` オプションは Mac OS(R) で使用されている HFS ファイルシステムを作成するために使われます。 FreeBSD でしか使わないのであれば、`-U` オプションを使用するとあらゆるファイル名制限を無効にできます。 さらに `-R` オプションとともに使うことで FreeBSD と同一のファイルシステムイメージを作成できますが、 これは ISO 9660 標準の多くを無視しています。 一般的に使われる最後のオプションは `-b` オプションです。 これは "El Torito" ブータブル CD を作成するのに使う起動イメージのありかを指定します。 このオプションは引数として起動イメージへのパスを、 CD に書き込まれるディレクトリツリーの頂点からの相対位置で取ります。 したがって [.filename]#/tmp/myboot# がブート可能な FreeBSD システムで [.filename]#/tmp/myboot/boot/cdboot# にブートイメージがあるならば、以下のようにすることで ISO 9660 ファイルシステムのイメージを [.filename]#/tmp/bootable.iso# に作成することができます。 [source,shell] .... # mkisofs -U -R -b boot/cdboot -o /tmp/bootable.iso /tmp/myboot .... この後、カーネルで [.filename]#vn# (FreeBSD 4.X) または [.filename]#md# (FreeBSD 5.X) が設定されていれば、 ファイルシステムを以下のようにしてマウントすることができます。 [source,shell] .... # vnconfig -e vn0c /tmp/bootable.iso # mount -t cd9660 /dev/vn0c /mnt .... FreeBSD 4.X および FreeBSD 5.X に対しては以下の通りです。 [source,shell] .... # mdconfig -a -t vnode -f /tmp/bootable.iso -u 0 # mount -t cd9660 /dev/md0 /mnt .... [.filename]#/mnt# と [.filename]#/tmp/myboot# が同一かどうか確認してください。 package:sysutils/mkisofs[] には挙動を細かく制御するために他にもたくさんのオプションがあります。 特に、ISO 9660 レイアウトの変更や Joliet および HFS ディスク作成などの 詳細は man:mkisofs[8] のマニュアルページをご覧ください。 [[burncd]] === burncd あなたが持っているのが ATAPI CD ライタなら、CD に ISO イメージを書き込むために `burncd` コマンドが使えます。 `burncd` はベースシステムの一部で [.filename]#/usr/sbin/burncd# としてインストールされています。 使い方はとても単純でオプションも少ししかありません。 [source,shell] .... # burncd -f cddevice data imagefile.iso fixate .... 以上のコマンドは _imagefile.iso_ のコピーを _cddevice_ に書き込みます。 デフォルトのデバイスは [.filename]#/dev/acd0c# です。 書き込み速度や操作完了後に CD を自動的に取り出す方法、 オーディオデータの書き込みなどのオプションについては man:burncd[8] を見てください。 [[cdrecord]] === cdrecord あなたが持っている CD ライタが ATAPI ではなければ、 CD を書き込むのに `cdrecord` を使う必要があります。 `cdrecord` はベースシステムの一部ではなく、 package:sysutils/cdrtools[] の port または 適切な package を利用してインストールしなければなりません。 なお、ベースシステムを変更するとバイナリに矛盾が発生し、 "コースター" を作ってしまうおそれがあります。 したがって、システムをアップグレードする度にこの port も作り直すか、 あるいは FreeBSD の安定版を追いかけているのならば、 新しいバージョンが利用できるようになった時に ports をアップグレードする必要があります。 `cdrecord` にはたくさんのオプションがありますが、 基本的な使い方は `burncd` よりもさらに簡単です。 ISO 9660 イメージを書き込むには以下のようにします。 [source,shell] .... # cdrecord dev=device imagefile.iso .... `cdrecord` のトリッキーな部分は、使用する `dev` を見つけるところにあります。 適切な設定を見つけるためには `cdrecord` の `-scanbus` フラグを使います。 たとえば、以下のような結果が出力されるでしょう。 [source,shell] .... # cdrecord -scanbus Cdrecord 1.9 (i386-unknown-freebsd4.2) Copyright (C) 1995-2000 Jörg Schilling Using libscg version 'schily-0.1' scsibus0: 0,0,0 0) 'SEAGATE ' 'ST39236LW ' '0004' Disk 0,1,0 1) 'SEAGATE ' 'ST39173W ' '5958' Disk 0,2,0 2) * 0,3,0 3) 'iomega ' 'jaz 1GB ' 'J.86' Removable Disk 0,4,0 4) 'NEC ' 'CD-ROM DRIVE:466' '1.26' Removable CD-ROM 0,5,0 5) * 0,6,0 6) * 0,7,0 7) * scsibus1: 1,0,0 100) * 1,1,0 101) * 1,2,0 102) * 1,3,0 103) * 1,4,0 104) * 1,5,0 105) 'YAMAHA ' 'CRW4260 ' '1.0q' Removable CD-ROM 1,6,0 106) 'ARTEC ' 'AM12S ' '1.06' Scanner 1,7,0 107) * .... リストにあるデバイスに対する適切な `dev` の値がここに示されています。あなたの CD ライタをこのリストから見つけ、 カンマで区切られた 3 つの数値を `dev` の値として使ってください。この例では CRW デバイスは 1,5,0 なので、適切な入力は `dev=1,5,0` となります。 値を明示するもっと簡単な方法もあります。詳細は man:cdrecord[1] を見てください。そこにはオーディオトラックを書き込む方法や、 書き込み速度その他を操作する方法も書かれています。 [[duplicating-audiocds]] === オーディオ CD の複製 CD からオーディオデータを連続したファイルに展開し、ブランク CD にこれらのファイルを書き込むことで、オーディオ CD を複製することができます。 この手順は ATAPI および SCSI ドライブの間で少し異なります。 [.procedure] ==== *Procedure: SCSI ドライブ* . `cdda2wav` を使用してオーディオを展開します。 + [source,shell] .... % cdda2wav -v255 -D2,0 -B -Owav .... + . `cdrecord` を使用して [.filename]#.wav# ファイルに書き出します。 + [source,shell] .... % cdrecord -v dev=2,0 -dao -useinfo *.wav .... + <> に説明されているように _2.0_ が適切に指定されていることを確かめてください。 ==== [.procedure] ==== *Procedure: ATAPI ドライブ* . ATAPI CD ドライバでは、それぞれのトラックを [.filename]#/dev/acddtnn# のように利用できます。 ここで _d_ はドライブ番号であり、 _nn_ は二桁十進のトラック番号です。 一桁の場合 0 を前に付加する必要があります。 したがって、一番目のディスクの一番目のトラックは [.filename]#/dev/acd0t01#、二番目のトラックは [.filename]#/dev/acd0t02#、三番目のトラックは [.filename]#/dev/acd0t03# などとなります。 + 適切なデバイスファイルが [.filename]#/dev# に存在することを確かめてください。 存在しなければ、たとえば次のようにして作成します。 + [source,shell] .... # cd /dev # sh MAKEDEV acd0t99 .... + [NOTE] ====== FreeBSD 5.0 では man:devfs[5] が [.filename]#/dev# にエントリを自動的に作成、 管理するので、`MAKEDEV` を使用する必要はありません。 ====== + . man:dd[1] を使用して各トラックを展開します。 ファイルを展開する際、ブロックサイズを指定しなければなりません。 + [source,shell] .... # dd if=/dev/acd0t01 of=track1.cdr bs=2352 # dd if=/dev/acd0t02 of=track2.cdr bs=2352 ... .... + . `burncd` を使用して、 展開したファイルをディスクに書き込みます。 これらがオーディオファイルであること、 そして書き込みが終了したときに `burncd` がディスクを固定 (fixate) することを明示しなければなりません。 + [source,shell] .... # burncd -f /dev/acd0c audio track1.cdr track2.cdr ... fixate .... ==== [[imaging-cd]] === データ CD の複製 データ CD を、package:sysutils/mkisofs[] を用いて作成されたイメージファイルと機能的に等価なイメージファイルにコピーできます。 これを使用して、すべてのデータ CD を複製することができます。 ここでの例は CDROM デバイスが [.filename]#acd0# であるとしています。あなたの CDROM デバイスに読み替えてください。 CDROM の場合には、パーティション全体またはディスク全体 を指定するために `c` をデバイス名の後に追加しなければなりません。 [source,shell] .... # dd if=/dev/acd0c of=file.iso bs=2048 .... これでディスクイメージを取り出すことができました。 すでに説明した方法を用いて CD に書き込むことができます。 [[mounting-cd]] === データ CD の使用 さて、標準的なデータ CDROM を作成したので、 おそらく次はそれをマウントしてデータを読み出したいと思うでしょう。 デフォルトでは man:mount[8] は、ファイルシステムタイプを `ufs` としています。 次のように実行しようとすると、 [source,shell] .... # mount /dev/cd0c /mnt .... `Incorrect super block` というエラーが返されてマウントできないでしょう。 CDROM は `UFS` ファイルシステムではないために、 このような手順でマウントしようすると失敗します。 ファイルシステムのタイプが `ISO9660` であると man:mount[8] に教えさえすれば、すべてはうまく動作します。 man:mount[8] に `-t cd9660` オプションを指定することでこれを行います。 たとえば [.filename]#/dev/cd0c# の CDROM デバイスを [.filename]#/mnt# にマウントしたい場合は、 以下のように実行します。 [source,shell] .... # mount -t cd9660 /dev/cd0c /mnt .... 使用している CDROM インタフェースによっては、 デバイス名 (この例では [.filename]#/dev/cd0c#) が異なるかもしれないことに注意してください。 また、`-t cd9660` オプションは、単に man:mount_cd9660[8] を実行します。 この例を以下のように短縮することもできます。 [source,shell] .... # mount_cd9660 /dev/cd0c /mnt .... 一般的にこの方法では、すべてのメーカの データ CDROM を使用することができます。しかしながら、特定の ISO 9660 拡張が施されたディスクでは奇妙な動作をするかもしれません。 たとえば Joliet ディスクは、 すべてのファイル名を 2 バイトの Unicode 文字で格納します。 FreeBSD カーネルは (まだ) Unicode を理解できないので、 非英語文字はクエスチョンマークで表示されます (FreeBSD 4.3 以降を使用している場合、CD9660 ドライバには適切な Unicode 変換表を読み込むための急ごしらえのフックが含まれています。 いくつかの共通のエンコードに対するモジュールは package:sysutils/cd9660_unicode[] port から利用可能です)。 CDROM をマウントしようとする時に、 `Device not configured` と表示されるかもしれません。これは、ディスクがトレーにないと CDROM ドライブが判断しているか、 ドライブがバス上に認識できないことを通常意味します。 ディスクが挿入されたことを CDROM ドライブが認識するには数秒かかりますので、 辛抱強く待ってください。 バスのリセットに返答するためのタイムアウトが短いために、時々 SCSI CDROM は認識に失敗するかもしれません。SCSI CDROM を持っている場合は、 次のオプションをカーネルコンフィギュレーションファイルに追加して、 crossref:kernelconfig[kernelconfig-building,カーネルを再構築してください]。 [.programlisting] .... options SCSI_DELAY=15000 .... これより、SCSI バスを起動時に 15 秒間停止させて、 CDROM ドライブがバスリセットに応答する機会を与えます。 [[rawdata-cd]] === Raw データ CD の書き込み ISO 9660 ファイルシステムを作成すること無く、 ファイルを直接 CD に書き込むこともできます。 この方法をバックアップ目的に使用している人もいます。 これは、標準 CD を書き込むよりもさらに速く実行することができます。 [source,shell] .... # burncd -f /dev/acd1c -s 12 data archive.tar.gz fixate .... このように CD に書き込まれたデータを取得するには、 raw デバイスノードからデータを読み込まなくてはなりません。 [source,shell] .... # tar xzvf /dev/acd1c .... このディスクを通常の CDROM としてマウントすることはできません。 このような CDROM は FreeBSD を除いて、 他のすべてのオペレーティングシステムでは読み込むことはできません。 CD をマウントしたいか、 その他のオペレーティングシステムとデータを共有したい場合は、 上記に説明したように package:sysutils/mkisofs[] を使用しなくてはなりません。 [[atapicam]] === ATAPI/CAM ドライバの使用 このドライバは、ATAPI デバイス (CD-ROM, CD-RW, DVD ドライブなど) へ SCSI サブシステムを通じてアクセスすることを可能にします。 これにより、package:sysutils/cdrdao[] または man:cdrecord[1] のようなアプリケーションが使用できるようになります。 このドライバを使用するためには、 カーネルコンフィギュレーションファイルに次の行を追加する必要があります。 [.programlisting] .... device atapicam device scbus device cd device pass .... 次の行もカーネルコンフィギュレーションファイルに必要です。 [.programlisting] .... device ata device atapicd .... 両方がすでに存在しなければなりません。 それから再構築し、新しいカーネルをインストールし、 コンピュータを再起動します。 起動プロセス中にディスクライタは以下のように表示されるでしょう。 [source,shell] .... acd0: CD-RW at ata1-master PIO4 cd0 at ata1 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 16.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed .... ドライブは [.filename]#/dev/cd0# デバイスを通じてアクセスすることが可能となります。 たとえば、次のようにして CD-ROM を [.filename]#/mnt# にマウントします。 [source,shell] .... # mount -t cd9660 /dev/cd0c /mnt .... `root` 権限で次のコマンドを実行して、 ライタの SCSI アドレスを得ることができます。 [source,shell] .... # camcontrol devlist at scbus1 target 0 lun 0 (pass0,cd0) .... したがって、`1,0,0` が man:cdrecord[1] およびその他の SCSI アプリケーションで使用する SCSI アドレスです。 ATAPI/CAM および SCSI システムの詳細は man:atapicam[4] および man:cam[4] マニュアルページを参照してください。 [[floppies]] == フロッピーディスクの作成と使用 フロッピーディスクにデータを格納することはしばしば役にたちます。 たとえば、ある人が他のリムーバブル記録メディアを何も持っていないときや、 小さなデータを他のコンピュータに移動させる必要があるときです。 この節では、FreeBSD におけるフロッピーディスクの使用方法を説明します。 主に 3.5 インチの DOS フロッピーのフォーマットと操作方法を扱いますが、 他のフロッピーディスクの形式についても概念は似ています。 === フロッピーのフォーマット ==== デバイス 他のデバイスと同様に、フロッピーディスクは [.filename]#/dev# にあるエントリを通じてアクセスされます。4.X およびそれ以前のリリースにおいて raw フロッピーディスクにアクセスするには [.filename]#/dev/fdN# または [.filename]#/dev/fdNX# を使用します。_N_ はドライブ番号を表し、 大抵は 0 です。_X_ は文字を表します。 5.0 およびそれ以降のリリースでは、単に [.filename]#/dev/fdN# を使用します。 ===== 4.X およびそれ以前のリリースでのディスクサイズ [.filename]#/dev/fdN.size# というデバイスもあります。 _size_ はフロッピーディスクのサイズをキロバイトで示したものです。 これらのエントリは低レベルフォーマットの際に、 ディスクサイズを決定するのに使用されます。 1440kB は以下の例で使用されるサイズです。 時々 [.filename]#/dev# 下のエントリは (再) 作成されなければなりません。次のコマンドでこれを行います。 [source,shell] .... # cd /dev && ./MAKEDEV "fd*" .... ===== 5.X およびそれ以降のリリースでのディスクサイズ FreeBSD 5.0 では man:devfs[5] が [.filename]#/dev# 内のエントリを自動的に管理するので、 ``MAKEDEV``を使用する必要はありません。 所望のディスクサイズは man:fdformat[1] に `-f` フラグを通して渡されます。対応しているサイズは man:fdcontrol[8] のマニュアルページに掲載されていますが、最良に動作するのは 1440kB だと助言しておきます。 ==== フォーマット フロッピーディスクは、 使用前に低レベルフォーマットをする必要があります。 通常、ベンダは低レベルフォーマット済みのディスクを出荷していますが、 フォーマットはメディアの品質を確認するよい方法です。 より大きな (または小さな) ディスクサイズにすることも可能ですが、 ほとんどのフロッピーディスクのサイズは 1440kB で動作するように設計されています。 フロッピーディスクを低レベルフォーマットするには man:fdformat[1] を使用する必要があります。 このユーティリティは引数としてデバイス名を指定します。 ディスクが良好かあるいは不良であるかを決定するのに役立つので、 エラーメッセージをすべてメモに取っておいてください。 ===== 4.X 以前のリリースでのフォーマット [.filename]#/dev/fdN.size# デバイスを使ってフロッピーをフォーマットします。 新しい 3.5 インチフロッピーディスクをドライブに挿入し、 以下のコマンドを実行してください。 [source,shell] .... # /usr/sbin/fdformat /dev/fd0.1440 .... ===== 5.0 以降のリリースでのフォーマット [.filename]#/dev/fdN# デバイスを使用してフロッピーをフォーマットします。 新しい 3.5 インチフロッピーディスクをドライブに挿入し、 以下のコマンドを実行してください。 [source,shell] .... # /usr/sbin/fdformat -f 1440 /dev/fd0 .... === ディスクラベル ディスクを低レベルフォーマットしたら、 次にディスクラベルを作成する必要があります。 ディスクラベルは後で破棄されますが、 システムがディスクのサイズとジオメトリを決定するのに必要になります。 新しいディスクラベルはディスク全体を引き継ぎ、 フロッピーのジオメトリに関する適切な情報のすべてが含まれます。 ディスクラベルに対するジオメトリの値は [.filename]#/etc/disktab# に掲載されています。 次のように man:disklabel[8] を実行できます。 [source,shell] .... # /sbin/disklabel -B -r -w /dev/fd0 fd1440 .... [NOTE] ==== FreeBSD 5.1-RELEASE から、従来の man:disklabel[8] プログラムは man:bsdlabel[8] ユーティリティに置き換えられました。man:bsdlabel[8] では、 使用されていないオプションおよびパラメタの数多くが削除されました。 たとえば `-r` オプションは man:bsdlabel[8] では取り除かれました。詳細については man:bsdlabel[8] マニュアルページを参照してください。 ==== === ファイルシステム これでフロッピーを高レベルフォーマットする準備ができました。これは FreeBSD がディスクを読み書きする新しいファイルシステムを作成します。 新しいファイルシステムを作成するとディスクラベルは破棄されます。 したがって、ディスクを再フォーマットするときには、 ディスクラベルを再作成しなくてはなりません。 フロッピーのファイルシステムには UFS または FAT を使用できます。 フロッピーに対しては FAT が一般的によりよい選択です。 フロッピー上に新しいファイルシステムを作成するには次のようにします。 [source,shell] .... # /sbin/newfs_msdos /dev/fd0 .... これでディスクが使用できるようになりました。 === フロッピーの使用 フロッピーを使用するために、man:mount_msdos[8] (4.X 以前のリリース) または man:mount_msdosfs[8] (5.0 以後のリリース) を用いてマウントします。 Ports Collection から package:emulators/mtools[] を使用することもできます。 [[backups-tapebackups]] == データテープの作成と使用 一般的なテープメディアには 4mm, 8mm, QIC, ミニカートリッジ、 DLT があります。 [[backups-tapebackups-4mm]] === 4mm (DDS: Digital Data Storage) 4mm テープはワークステーションのバックアップメディアとして QIC に取って代わりつつあります。この傾向は QIC ドライブの主要なメーカであった Archive を Conner が買収し QIC ドライブの製造を中止したことで加速しました。 4mm ドライブは小型で静かですが 8mm ドライブが持っている信頼性ほど、その評判は良くありません。 また、4mm カートリッジは 8mm カートリッジよりも安価で小型 (3 x 2 x 0.5 インチ、76 x 51 x 12 mm) になっています。 ただし、8mm と同様に、4mm のヘッドはヘリカルスキャン方式 (訳注: VTR と同様の回転ヘッドを使う方式) を採用しているため、比較的寿命が短いです。 ドライブのデータスループットは、150 kB/s から 最大で 500 kB/s 程度です。 データ容量は 1.3 GB から 2.0 GB です。 ドライブのほとんどで利用可能なハードウェア圧縮を使用すると、 容量が約 2 倍になります。 マルチドライブテープライブラリユニットは 1 つの筐体に 6 つのドライブを収容可能で、自動的にテープの交換ができます。 ライブラリの容量は 240 GB に達します。 現在の DDS-3 標準は 12 GB (圧縮時 24 GB) までのテープ容量に対応しています。 8mm ドライブと同様に 4mm ドライブはヘリカルスキャンを使用します。 ヘリカルスキャン方式の利点および欠点はすべて 4mm および 8mm ドライブの両方に当てはまります。 テープは 2,000 回のパスあるいは 100 回フルバックアップした後には交換するべきです。 [[backups-tapebackups-8mm]] === 8mm (Exabyte) 8mm テープは SCSI テープドライブとして最もよく使われているもので、 データ交換用として最良の選択です。ほとんどのサイトには Exabyte 2 GB 8mm テープドライブがあるでしょう。8mm ドライブは信頼性が高く、使いやすく、静かです。 カートリッジは安価で小型です (4.8 x 3.3 x 0.6 インチ、122 x 84 x 15 mm)。8mm テープの欠点は、テープとヘッドの相対的な速度が高速なために、 比較的ヘッドとテープの寿命が短いことです。 データスループットは 250 kB/s から 500 kB/s 程度です。データ容量は 300 MB から 7 GB です。 ほとんどのドライブで利用可能なハードウェア圧縮を利用すると、 容量が約 2 倍になります。 これらのドライブは、単一のユニットから 6 つのドライブと 120 本のテープを一つの筐体に収容したマルチドライブテープライブラリまで利用可能です。 テープはユニットによって自動的に取り換えられます。 ライブラリの容量は 840 GB 以上に達します。 Exabyte の "Mammoth" モデルはテープ 1 本あたり 12 GB (圧縮時 24 GB) に対応し、 従来のテープドライブと比べ費用は約 2 倍になります。 データはヘリカルスキャンを用いてテープに記録されます。 ヘッダはメディアに対してある傾き (約 6 度) に配置されます。 テープはヘッドのある円筒の周の 270 度にわたって接触します。 テープが円筒面を走行する間、円筒は回転しています。 この結果、高密度のデータのつまったトラックは、 狭い間隔でテープの上端と下端の間を斜めに横切ります。 [[backups-tapebackups-qic]] === QIC QIC-150 テープとドライブは、 おそらく最も一般的に使われているドライブとメディアでしょう。 QIC テープドライブは "現実的な" バックアップドライブとしては最も高価でないものです。 欠点はメディアのコストです。QIC テープは 8mm や 4mm テープと比較して GB あたりのデータの保存で 5 倍ほど高価です。 しかし、あなたの必要とする量が半ダース程のテープで十分であれば、 QIC は正しい選択かもしれません。QIC は __最も__一般的なテープドライブです。 すべてのサイトに QIC ドライブのどれかの容量のものがあります。問題は、 QIC は同じようなテープ (まったく同じ場合もある) に多様な記録密度があることです。QIC ドライブは静かではありません。 これらのドライブはデータ記録を開始する前に音をたててシークしますし、 リード、ライト、シークの時にはっきりと聞こえる音を出します。 QIC テープの大きさは (6 x 4 x 0.7 インチ、152 x 102 x 17 mm) です。 1/4 インチ幅のテープも使用している <> は別に議論します。テープライブラリやチェンジャはありません。 データスループットは ~1500 kB/s から ~5000 kB/s 程度です。データ容量は 400 MB から 150 GB です。 ハードウェア圧縮が最近のドライブの多くで利用できます。 QIC ドライブは DAT ドライブに置き換えられつつあり、 あまり頻繁には使用されなくなっています。 データは複数のトラックに分かれてテープに記録されます。 トラックはテープメディアの長さ方向の一端からもう一方の端までです (訳注: 1 トラックの read/write が終わるとテープの走行方向を反転させ 次のトラックの read/write を行います)。トラックの数と、 それに対応するトラックの幅はテープの容量によって変わります。 すべてではありませんが、 最近のドライブはほとんど、少なくとも読み出しについては (場合によっては書き込みも) 下位互換性があります。 QIC はデータの安全性についてはよいといわれています (ヘリカルスキャンドライブに比べて機構は単純でより丈夫です)。 テープは 5000 回のバックアップで寿命となるでしょう。 [[backups-tapebackups-mini]] === XXX* ミニカートリッジ [[backups-tapebackups-dlt]] === DLT DLT はここに示したドライブのタイプの中で最高速のデータ転送レートを発揮します。 1/2 インチ (12.5mm) テープが単リールのカートリッジ (4 x 4 x 1 インチ、100 x 100 x 25 mm) に入っています。 カートリッジのひとつの側面全体がスイングゲートになっています。 ドライブの機構がこのゲートを開け、テープリーダを引き出します。 テープリーダには楕円形の穴があり、 ドライブがテープを "引っ掛ける" のに使います。 巻き取りのためのリールはドライブの中にあります。 ここに挙げた他のカートリッジはすべて (9 トラックテープは唯一の例外です) 送り出しリールと巻き取りリールの両方がカートリッジの中にあります。 データスループットは約 1.5 MB/s で、4mm, 8mm, QIC テープドライブの 3 倍です。データ容量は単一のドライブで 10 GB から 20 GB の範囲です。マルチテープチェンジャ、 マルチテープドライブ、5 から 900 巻のテープを 1 から 20 ドライブで扱うマルチドライブテープライブラリがあり、 50 GB から 9 TB の容量が得られます。 圧縮によって、DLT Type IV フォーマットは 70 GB までの容量に対応しています。 データは (QICテープのように) テープの走行方向と平行に複数あるトラックへ記録されます。 2 つのトラックに同時書き込みを行います。 read/write ヘッドの寿命は比較的長いと言えます。 テープの走行が止まればヘッドとテープの間の相対運動は無いからです。 === AIT AIT は、Sony が発表した新しいフォーマットで、 テープ 1 本あたり 50 GB (圧縮時) まで格納できます。 テープにはメモリチップが搭載されており、 テープの内容の索引情報を保持しています。 他のテープではテープ上のファイルの位置を把握するのに数分必要とするのですが、 このテープドライブでは索引情報を読んで直ちに決定することができます。 SAMS:Alexandria のようなソフトウェアは、40 を超える ATI テープライブラリを操作できるのはもちろんのこと、 テープのメモリチップと直接通信して、スクリーンに内容を表示し、 どのファイルがどのテープにバックアップされたかを調べて、 正しいテープを見つけ、読み込み、 テープからデータを復元することができます。 このようなライブラリは大体 $20,000 くらいするので、 愛好家が購入できる価格帯からは外れてしまいます。 === 新品のテープを初めて使う場合 全く新品の空テープを読もうとしたり書き込もうとすると、 処理は失敗するでしょう。 次のようなメッセージがコンソールに出力されるでしょう。 [source,shell] .... sa0(ncr1:4:0): NOT READY asc:4,1 sa0(ncr1:4:0): Logical unit is in process of becoming ready .... テープに識別ブロック (Identifier Block:block number 0) がありません。QIC-525 標準を採用したすべての QIC テープドライブは識別ブロックをテープに書き込みます。 2 つの解決方法があります。 * `mt fsf 1` によりテープドライブはテープに識別ブロックを書き込みます。 * フロントパネルのボタンを押してテープを取り出します。 + 再びテープを挿入し、データをテープに `dump` します。 + `dump` は `DUMP: End of tape detected` と報告し、 コンソールには `HARDWARE FAILURE info:280 asc:80,96` と表示されるでしょう。 + `mt rewind` を使ってテープを巻戻します。 + 次からはテープの操作はうまくいくでしょう。 [[backups-floppybackups]] == フロッピーディスクへのバックアップ [[floppies-using]] === データをバックアップするのにフロッピーは使えますか? フロッピーディスクは以下の理由によって、 実際にバックアップをつくるための適切なメディアではありません。 * メディアの信頼性が (特に長期間の場合) 低い。 * バックアップとリストアがとても遅い。 * 容量が非常に小さい (1 ダースかそこらのフロッピーディスクに ハードディスク全体をバックアップしていた時代は、 はるか遠くに過ぎ去りました)。 しかしながら、データをバックアップする他の手段がないのなら、 バックアップを取らないよりもフロッピーディスクを使う方がましでしょう。 フロッピーディスクを使用せざるを得ないときは、 品質のよいディスクを使用してください。 事務所のその辺に数年転がっていたフロッピーは使わない方が良いでしょう。 評判のよいメーカの新しいディスクを使用することが理想です。 [[floppies-creating]] === それではどうやってデータをフロッピーにバックアップするのですか? フロッピーにバックアップする最もよい方法は、 `-M` (マルチボリューム) オプション付きで man:tar[1] コマンドを使用することです。これで、 複数のフロッピーにわたってバックアップすることが可能になります。 カレントディレクトリとサブディレクトリ内のすべてのファイルをバックアップするには、 以下のコマンドを (`root` 権限で) 使用します。 [source,shell] .... # tar Mcvf /dev/fd0 * .... 1 枚目のフロッピーが一杯になると、 man:tar[1] は次のボリュームを挿入するように要求します (man:tar[1] はさまざまなメディアを扱えるので、 ボリュームと表示します。この文脈ではフロッピーディスクのことです)。 [source,shell] .... Prepare volume 2 for /dev/fd0 and hit return: .... 指定したファイルがすべて保存されるまで (ボリューム番号を増やしながら) これが繰り返されます。 [[floppies-compress]] === バックアップを圧縮することはできませんか? 残念なことに man:tar[1] はマルチボリュームアーカイブに対して、 `-z` オプションを使うことができません。 もちろん、すべてのファイルを man:gzip[1] で圧縮し、 それらを man:tar[1] を用いてフロッピーに保存して、 それから再び man:gunzip[1] することはできます。 [[floppies-restoring]] === どのようにしてバックアップをリストアしたらいいのでしょうか? すべてのアーカイブをリストアするには以下のようにします。 [source,shell] .... # tar Mxvf /dev/fd0 .... 特定のファイルだけをリストアするには 2 つの方法があります。 1 つ目は、1 枚目のフロッピーを用いて以下のようにするものです。 [source,shell] .... # tar Mxvf /dev/fd0 filename .... man:tar[1] ユーティリティは、 必要なファイルを見つけるまで次のディスクを挿入するように要求します。 もう 1 つは、 必要なファイルがどのフロッピーに保存されているか分かっている場合、 そのフロッピーを挿入して上記と同じコマンドを使用するだけでもよいです。 あるフロッピー上にある 1 番目のファイルが、 その前のフロッピーから続いている場合は、 そのファイルのリストアを要求していなくても man:tar[1] はそれをリストアできないと警告することに注意してください! [[backup-basics]] == バックアップの基本 主なバックアッププログラムは man:dump[8], man:tar[1], man:cpio[1] の三つです。 === ダンプとリストア 伝統的な UNIX(R) のバックアッププログラムは `dump` と `restore` です。 これらはファイルシステムによって作成されるファイル、リンク、 ディレクトリといった抽象の下位にある、 ディスクブロックの集合としてドライブを操作します。 `dump` はデバイス上のファイルシステム全体をバックアップします。 ファイルシステムの一部分だけ、 または二つ以上のファイルシステムにわたるディレクトリツリーをバックアップすることはできません。 `dump` はファイルおよびディレクトリをテープに書き込まずに、 ファイルおよびディレクトリを含んだ raw データブロックを書き込みます。 [NOTE] ==== ルートディレクトリで `dump` を使った場合、 [.filename]#/home#, [.filename]#/usr# など、他の多くのディレクトリはバックアップされません。 これらのディレクトリは通常、 他のファイルシステムへのマウントポイントであったり、 シンボリックリンクとなっているためです。 ==== `dump` には AT&T UNIX のバージョン 6 (およそ 1975 年) の初期から残っている癖があります。 デフォルトのパラメタは、現在利用可能な高密度メディア (最大 62,182 ftpi) ではなく、9 トラックテープ (6250 bpi) に最適な値となっています。 現在のテープドライブの容量を利用するために、 これらのデフォルト値をコマンドラインで上書きしなければなりません。 `rdump` と `rrestore` を用いて他のコンピュータに接続されているテープドライブにネットワーク経由でデータをバックアップすることも可能です。 どちらのプログラムもリモートのテープドライブにアクセスするために `rcmd` および `ruserok` に依存しています。 したがって、バックアップを実行するユーザがリモートコンピュータの [.filename]#.rhosts# ファイルに書かれていなければなりません。 `rdump` および `rrestore` の引数はリモートコンピュータに適切なものを用いなければなりません。 FreeBSD コンピュータから `komodo` と呼ばれる Sun に接続されている Exabyte テープへ `rdump` するには以下のようにします。 [source,shell] .... # /sbin/rdump 0dsbfu 54000 13000 126 komodo:/dev/nsa8 /dev/da0a 2>&1 .... 注意: [.filename]#.rhosts# 認証を許可することには、セキュリティに関する暗黙の仮定があります。 あなたの置かれている状況を注意深く調べてください。 `ssh` 越しに `dump` と `restore` をより安全な形で使うこともできます。 .ssh 越しの `dump` の利用 [example] ==== [source,shell] .... # /sbin/dump -0uan -f - /usr | gzip -2 | ssh1 -c blowfish \ targetuser@targetmachine.example.com dd of=/mybigfiles/dump-usr-l0.gz .... ==== または、環境変数 `RSH` を設定して、 `dump` の組み込み機能を利用する。 .`RSH` を設定した ssh 越しの `dump` を利用 [example] ==== [source,shell] .... # RSH=/usr/bin/ssh /sbin/dump -0uan -f targetuser@targetmachine.example.com:/dev/sa0 .... ==== === `tar` man:tar[1] は AT&T UNIX の バージョン 6 (1975 年ごろ) にまで遡ることができます。`tar` はファイルシステムと協調して動作し、 ファイルとディレクトリをテープに書き込みます。`tar` は man:cpio[1] で使用可能なフルレンジのオプションには対応していませんが、 `tar` には `cpio` が使用するような奇妙なコマンドパイプラインは必要ありません。 `tar` の多くの版はネットワーク経由のバックアップには対応していません。 FreeBSD が使用している GNU 版の `tar` は、 `rdump` と同じ構文でリモートデバイスに対応しています。 `komodo` と呼ばれる Sun に接続された Exabyte テープドライブに対して `tar` を実行するには以下のようにします。 [source,shell] .... # /usr/bin/tar cf komodo:/dev/nsa8 . 2>&1 .... リモートデバイスに対応していない版に対しては、パイプラインと `rsh` を使用してリモートテープドライブにデータを送ることができます。 [source,shell] .... # tar cf - . | rsh hostname dd of=tape-device obs=20b .... ネットワークを越えたバックアップのセキュリティを懸念しているなら、 `rsh` の代わりに `ssh` を使うべきです。 === `cpio` man:cpio[1] は本来 UNIX(R) ファイルを磁気メディアで交換するためのプログラムです。 `cpio` はバイトスワッピング、 多くの異なるアーカイブフォーマットの書き込みオプションがあり (それ以外にも多数のオプションがあります)、 パイプで他のプログラムにデータを渡すこともできます。 この最後にあげた特徴が、`cpio` をインストールメディアとしては優れた選択肢にしています。 `cpio` はディレクトリツリーの探索の機能はなく、ファイルリストは [.filename]#stdin# からの入力でなくてはなりません。 `cpio` はネットワーク経由のバックアップには対応していません。 以下のようにパイプラインと `rsh` を用いてリモートテープドライブにデータを送ることができます。 [source,shell] .... # for f in directory_list; do find $f >> backup.list done # cpio -v -o --format=newc < backup.list | ssh user@host "cat > backup_device" .... _directory_list_ はバックアップしたいディレクトリのリストで、 _user_@_host_ はバックアップを実行したいユーザとホスト名の組であり、 _backup_device_ はバックアップを書き込みたいデバイスです (たとえば [.filename]#/dev/nsa0#)。 === `pax` man:pax[1] は `tar` と `cpio` に対する IEEE/POSIX(R) の回答です。長年の間、さまざまな版の `tar` と `cpio` は互いにわずかに非互換になってきていました。 それらをしらみ潰しに標準化する代わりに、POSIX(R) は新しいアーカイブユーティリティを作りました。 `pax` は、いくつもの `cpio` や `tar` のフォーマットの読み書きに対応しようと試みているほか、 専用に新しいフォーマットを開発しました。 コマンド群は `tar` よりも `cpio` の方にいくぶん似ています。 [[backups-programs-amanda]] === Amanda Amanda (Advanced Maryland Network Disk Archiver) は単一のプログラムではなく、 クライアント/サーバ型のバックアップシステムです。 Amanda サーバは、 Amanda クライアントを有する ネットワークに接続されたコンピュータからデータを受け取り、 備え付けられたテープドライブにバックアップします。 いくつもの大容量ディスクを備えたサイトでの共通の問題は、 データディレクトリをテープにバックアップするのに時間がかかりすぎることです。 Amanda はこの問題を解決します。 Amanda は "ホールディングディスク" を使用して、 同時に複数のファイルシステムのバックアップを行うことができます。 Amanda の設定ファイルにかかれたすべてのファイルシステムのフルバックアップを特定の間隔でとるために "アーカイブセット" と呼ばれるテープグループを作成します。 "アーカイブセット" には 夜間に作成されるすべてのファイルシステムの増分 (または差分) のバックアップも含まれます。 障害が起きたファイルシステムのリストアには、 最も新しいフルバックアップと増分のバックアップが必要です。 設定ファイルでは、バックアップの制御と Amanda によるネットワークトラフィック量を設定します。 Amanda は上記のバックアッププログラムのいずれかを使ってデータをテープに書き込みます。 Amanda は port または package として利用可能です。デフォルトではインストールされていません。 === 何もしない "何もしない" というのはコンピュータのプログラムではありませんが、 バックアップの戦略として最も広く採用されています。 これには初期投資が必要ありません。 従わなければならないバックアップスケジュールもありません。 ただ何もしないだけです。データに何か起きたら苦笑いして耐えてください! あなたにとって時間やデータの価値が少ないか、 あるいはまったくないのであれば "何もしない" のはあなたのコンピュータに最も適したバックアッププログラムでしょう。 しかし注意してください。UNIX(R) は便利なツールです。 6 ヶ月も使用していれば、 あなたにとって価値のあるファイルの山が出来上がっているでしょう。 "何もしない" ことはコンピュータが同じものをもう一度作り直すことのできる [.filename]#/usr/obj# やその他のディレクトリツリーについては適切なバックアップ方法です。 一例として、このハンドブックの HTML 版 または PostScript(R) 版を構成するファイルがあります。 これらの文書形式は SGML ファイルから作成されたものです。 HTML または PostScript(R) ファイルのバックアップは必要ありません。 SGML ファイルは定期的にバックアップされています。 === どのバックアッププログラムが最適ですか? man:dump[8] です。_以上。_ Elizabeth D. Zwicky はここで検討したプログラムすべてについて拷問的なテストを行いました。 すべてのデータと UNIX(R) ファイルシステムの状態すべてを保存するのに最適なのは、明らかに `dump` です。 Elizabeth は多種多様の特異な状態 (いくつかはあまり珍しくないものもあります) を含むファイルシステムを作成し、 それらのファイルシステムのバックアップとリストアを行って、 それぞれのプログラムのテストを行いました。特異な状態とは、 ホールがあるファイル、ホールとヌルブロックがあるファイル、 奇妙な文字をファイル名に持つファイル、読み取り不可、 書き込み不可のファイル、デバイスファイル、 バックアップ中のファイルのサイズ変更、 バックアップ中のファイルの作成および削除、などです。 彼女は 1991 年 10 月の LISA V で結果を発表しています。 http://berdmann.dyndns.org/zwicky/testdump.doc.html[torture-testing Backup and Archive Programs] を参照してください。 === 緊急時のリストア手順 ==== 惨事が起きる前に 発生する可能性があるどのような惨事に対しても、 備えるのに必要な手順は以下の 4 ステップだけです。 最初に、 各ディスクのディスクラベルとファイルシステムテーブル ([.filename]#/etc/fstab#)、 ブートメッセージ全体をそれぞれ 2 枚ずつ印刷します (たとえば `disklabel da0 | lpr`)。 2 番目に、ブートフロッピーと fix-it フロッピー ([.filename]#boot.flp# および [.filename]#fixit.flp#) にそのシステムのデバイスがすべて含まれているか確認します。 最も簡単に確認する方法は、フロッピーをドライブに入れてマシンをリブートしてブートメッセージを確認することです。 あなたのシステムのデバイスのすべてが含まれ、 機能していれば 3 番目の手順に進んでください。 さもなければ、 そのシステムのすべてのディスクをマウントでき、 テープドライブにもアクセスできるカーネルを備えた カスタムブートフロッピーを 2 枚作成する必要があります。 これらのフロッピーディスクには `fdisk`, `disklabel`, `newfs`, `mount` と、利用するバックアッププログラムが入っていなければなりません。 これらのプログラムはスタティックリンクされていなければなりません。 `dump` を使用するのなら、このフロッピーには `restore` も含まれていなければなりません。 3 番目に、定期的にバックアップテープを作成します。 最後のバックアップの後で行われた変更は、回復できずに失われます。 バックアップテープにライトプロテクトを施してください。 4 番目に、フロッピーディスク ([.filename]#boot.flp# と [.filename]#fixit.flp#、 か、第 2 段階で作成した 2 枚のカスタムブートフロッピーディスクのどちらか) およびバックアップテープのテストをします。 手順のメモを作りましょう。 このメモはブートフロッピー、印刷した紙、 バックアップテープと一緒に保存しておきます。 リストアを行うときには、 このメモがバックアップテープを壊すのを防ぐくらい取り乱しているかもしれません (どのように? `tar xvf /dev/sa0` の代わりに、うっかり `tar cvf /dev/sa0` と入力してバックアップテープを上書きしてしまうかもしれません)。 .訳注 [NOTE] ==== 上書きはライトプロテクトをしておけば防げますが、 何らかの原因でプロテクトがはずれているかもしれません。 ちなみに訳者の経験から言えば、 上のようなミスタイプは結構起きます。 ==== 安全性を増すために、毎回、 ブートフロッピーを作成し、 2 巻のバックアップテープを取ります。 一方を離れた場所に保管します。 離れた場所は同じ事務所の建物の地下室ではいけません。 世界貿易センタービルにあった数多くの会社は、 苦い経験によりこの教訓を得ました。離れた場所とは、 コンピュータやディスクドライブから十分な距離を取って 物理的に分離されていなければなりません。 .ブートフロッピーを作成するスクリプト [example] ==== [.programlisting] .... #!/bin/sh # # create a restore floppy # # format the floppy # PATH=/bin:/sbin:/usr/sbin:/usr/bin fdformat -q fd0 if [ $? -ne 0 ] then echo "Bad floppy, please use a new one" exit 1 fi # place boot blocks on the floppy # disklabel -w -B /dev/fd0c fd1440 # # newfs the one and only partition # newfs -t 2 -u 18 -l 1 -c 40 -i 5120 -m 5 -o space /dev/fd0a # # mount the new floppy # mount /dev/fd0a /mnt # # create required directories # mkdir /mnt/dev mkdir /mnt/bin mkdir /mnt/sbin mkdir /mnt/etc mkdir /mnt/root mkdir /mnt/mnt # for the root partition mkdir /mnt/tmp mkdir /mnt/var # # populate the directories # if [ ! -x /sys/compile/MINI/kernel ] then cat << EOM The MINI kernel does not exist, please create one. Here is an example config file: # # MINI - A kernel to get FreeBSD onto a disk. # machine "i386" cpu "I486_CPU" ident MINI maxusers 5 options INET # needed for _tcp _icmpstat _ipstat # _udpstat _tcpstat _udb options FFS #Berkeley Fast File System options FAT_CURSOR #block cursor in syscons or pccons options SCSI_DELAY=15 #Be pessimistic about Joe SCSI device options NCONS=2 #1 virtual consoles options USERCONFIG #Allow user configuration with -c XXX config kernel root on da0 swap on da0 and da1 dumps on da0 device isa0 device pci0 device fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr device fd0 at fdc0 drive 0 device ncr0 device scbus0 device sc0 at isa? port "IO_KBD" tty irq 1 vector scintr device npx0 at isa? port "IO_NPX" irq 13 vector npxintr device da0 device da1 device da2 device sa0 pseudo-device loop # required by INET pseudo-device gzip # Exec gzipped a.out's EOM exit 1 fi cp -f /sys/compile/MINI/kernel /mnt gzip -c -best /sbin/init > /mnt/sbin/init gzip -c -best /sbin/fsck > /mnt/sbin/fsck gzip -c -best /sbin/mount > /mnt/sbin/mount gzip -c -best /sbin/halt > /mnt/sbin/halt gzip -c -best /sbin/restore > /mnt/sbin/restore gzip -c -best /bin/sh > /mnt/bin/sh gzip -c -best /bin/sync > /mnt/bin/sync cp /root/.profile /mnt/root cp -f /dev/MAKEDEV /mnt/dev chmod 755 /mnt/dev/MAKEDEV chmod 500 /mnt/sbin/init chmod 555 /mnt/sbin/fsck /mnt/sbin/mount /mnt/sbin/halt chmod 555 /mnt/bin/sh /mnt/bin/sync chmod 6555 /mnt/sbin/restore # # create the devices nodes # cd /mnt/dev ./MAKEDEV std ./MAKEDEV da0 ./MAKEDEV da1 ./MAKEDEV da2 ./MAKEDEV sa0 ./MAKEDEV pty0 cd / # # create minimum file system table # cat > /mnt/etc/fstab <<EOM /dev/fd0a / ufs rw 1 1 EOM # # create minimum passwd file # cat > /mnt/etc/passwd < /mnt/etc/master.passwd <> で説明されている通りに新しいドライブをシステムに設置します。 この例では、新しいハードドライブは [.filename]#/dev/ad4s1c# パーティションに 加えられたものとします。 [.filename]#/dev/ad0s1*# デバイスは、この例のシステム上に存在する標準的な FreeBSD パーティションを表します。 + [source,shell] .... # ls /dev/ad* /dev/ad0 /dev/ad0s1b /dev/ad0s1e /dev/ad4s1 /dev/ad0s1 /dev/ad0s1c /dev/ad0s1f /dev/ad4s1c /dev/ad0s1a /dev/ad0s1d /dev/ad4 .... + . gbde ロックファイルを保持するディレクトリを作成する + [source,shell] .... # mkdir /etc/gbde .... + gbde ロックファイルには、 暗号化されたパーティションにアクセスするのに必要となる情報が格納されています。 ロックファイルにアクセスしない場合、 gbde は 膨大な手動による介在なしには (ソフトウェアは対応していません)、暗号化されたパーティションに含まれるデータを解読することはできないでしょう。 それぞれの暗号化されたパーティションは別々のロックファイルを使用します。 . gbde パーティションを初期化する + gbde パーティションは使用する前に初期化されなければなりません。 この初期化は一度だけ実行される必要があります。 + [source,shell] .... # gbde init /dev/ad4s1c -i -L /etc/gbde/ad4s1c .... + エディタが開くので、 テンプレートをもとにさまざまなオプションを設定してください。 UFS1 または UFS2 で使用するには、sector_size を 2048 に設定してください。 + [.programlisting] .... $FreeBSD: src/sbin/gbde/template.txt,v 1.1 2002/10/20 11:16:13 phk Exp $ # # Sector size is the smallest unit of data which can be read or written. # Making it too small decreases performance and decreases available space. # Making it too large may prevent filesystems from working. 512 is the # minimum and always safe. For UFS, use the fragment size # sector_size = 2048 [...] .... + man:gbde[8] はデータを保護するのに使用するパスフレーズを二度尋ます。 パスフレーズはそれぞれ同じでなければなりません。 データを保護する gbde の能力は、 あなたが選択したパスフレーズの品質に完全に依存します。 + `gbde init` コマンドは gbde パーティションに対するロックファイルを作成します。この例では [.filename]#/etc/gbde/ad4s1c# に格納されます。 + [CAUTION] ====== gbde ロックファイルは、 すべての暗号化されたパーティションの内容とともにバックアップされなければ _なりません_。 ロックファイルだけを削除している間、 ロックファイルなしでは信念の固い攻撃者が gbde パーティションを解読することを防ぐことができない一方で、 正当な所有者は、man:gbde[8] およびこの設計者にまったく支持されない膨大な量の作業なしには、 暗号化されたパーティション上のデータにアクセスすることができないでしょう。 ====== + . カーネルに暗号化されたパーティションを接続する + [source,shell] .... # gbde attach /dev/ad4s1c -l /etc/gbde/ad4s1c .... + 暗号化されたパーティションを初期化する際に選択したパスフレーズを入力するように求められます。 新しい暗号化デバイスは [.filename]#/dev# に [.filename]#/dev/device_name.bde# として現れます。 + [source,shell] .... # ls /dev/ad* /dev/ad0 /dev/ad0s1b /dev/ad0s1e /dev/ad4s1 /dev/ad0s1 /dev/ad0s1c /dev/ad0s1f /dev/ad4s1c /dev/ad0s1a /dev/ad0s1d /dev/ad4 /dev/ad4s1c.bde .... + . 暗号化デバイス上にファイルシステムを作成する + カーネルに暗号化デバイスが接続されると、 デバイス上にファイルシステムを作成できます。 暗号化デバイス上にファイルシステムを作成するには man:newfs[8] を使用します。従来の UFS1 ファイルシステムで初期化するより、 新しい UFS2 ファイルシステムで初期化した方が高速なので、 `-O2` オプションとともに man:newfs[8] を使用することが推奨されています。 + [NOTE] ====== FreeBSD 5.1-RELEASE 以降では、`-O2` オプションはデフォルトです。 ====== + [source,shell] .... # newfs -U -O2 /dev/ad4s1c.bde .... + [NOTE] ====== man:newfs[8] は、デバイス名に [.filename]#*.bde# 拡張子によって認識される、 接続された gbde パーティションに対して実行されなければなりません。 ====== + . 暗号化パーティションをマウントする + 暗号化ファイルシステムに対するマウントポイントを作成します。 + [source,shell] .... # mkdir /private .... + 暗号化ファイルシステムをマウントします。 + [source,shell] .... # mount /dev/ad4s1c.bde /private .... + . 暗号化ファイルシステムが利用可能か確かめる + これで暗号化ファイルシステムは man:df[1] で見ることができ、 利用する準備ができました。 + [source,shell] .... % df -H Filesystem Size Used Avail Capacity Mounted on /dev/ad0s1a 1037M 72M 883M 8% / /devfs 1.0K 1.0K 0B 100% /dev /dev/ad0s1f 8.1G 55K 7.5G 0% /home /dev/ad0s1e 1037M 1.1M 953M 0% /tmp /dev/ad0s1d 6.1G 1.9G 3.7G 35% /usr /dev/ad4s1c.bde 150G 4.1K 138G 0% /private .... ==== === 存在する暗号化ファイルシステムをマウントする システムを起動する度に、すべての暗号化ファイルシステムは 使用前にカーネルに接続し、 エラーの有無をチェックし、マウントする必要があります。 必要なコマンドは `root` ユーザとして実行されなければなりません。 [.procedure] ==== . カーネルに gbde パーティションを接続する + [source,shell] .... # gbde attach /dev/ad4s1c -l /etc/gbde/ad4s1c .... + パーティションの暗号化を初期化する際に選択したパスフレーズを入力するように求められるでしょう。 . ファイルシステムのエラーをチェックする + 暗号化ファイルシステムを自動的にマウントするために [.filename]#/etc/fstab# に設定を掲載することはまだできないため、 マウントする前に man:fsck[8] を実行して、 ファイルシステムのエラーをチェックしなければなりません。 + [source,shell] .... # fsck -p -t ffs /dev/ad4s1c.bde .... + . 暗号化ファイルをマウントする + [source,shell] .... # mount /dev/ad4s1c.bde /private .... + これで暗号化ファイルシステムが利用できるようになりました。 ==== ==== 暗号化パーティションを自動的にマウントする スクリプトを作成して、暗号化パーティションを自動的に接続、 チェック、マウントすることは可能です。しかしながら、 安全上の理由によりスクリプトに man:gbde[8] パスワードを含めるべきではありません。その代わりに、コンソールまたは man:ssh[1] による接続からパスワードを入力するようなスクリプトが手動で実行されることが推奨されます。 === gbde が採用した暗号の保護 man:gbde[8] は 128bit AES の CBC モードを使用してセクタペイロードを暗号化します。 ディスク上のそれぞれのセクタは異なる AES 鍵で暗号化されます。 セクタ鍵がユーザが入力したパスフレーズからどのように導き出されるかを含め、 gbde の暗号手法の設計についての詳細は、 man:gbde[4] を参照してください。 === 互換性に関する問題 man:sysinstall[8] は gbde 暗号化デバイスと互換性がありません。 man:sysinstall[8] を実行する前に [.filename]#*.bde# デバイスはすべてカーネルから切断されなければなりません。 そうしないと、man:sysinstall[8] が初めにデバイスを走査する際にクラッシュしてしまうでしょう。 暗号化デバイスを切断するには、以下のコマンドを使用します。 [source,shell] .... # gbde detach /dev/ad4s1c .... diff --git a/documentation/content/ja/books/handbook/eresources/_index.adoc b/documentation/content/ja/books/handbook/eresources/_index.adoc index 7ee384aa3b..2df394960b 100644 --- a/documentation/content/ja/books/handbook/eresources/_index.adoc +++ b/documentation/content/ja/books/handbook/eresources/_index.adoc @@ -1,1199 +1,1199 @@ --- title: 付録 C. インターネット上のリソース part: パートV. 付録 prev: books/handbook/bibliography next: books/handbook/pgpkeys description: ウェブサイト、メーリングリスト、ミラーサイトといったインターネット上のリソース tags: ["eresources", "Websites", "Mailing Lists", "Usenet", "Newsgroups"] showBookMenu: true -weight: 30 +weight: 29 path: "/books/handbook/" --- [appendix] [[eresources]] = インターネット上のリソース :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :sectnumoffset: C :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/eresources/ ifdef::env-beastie[] ifdef::backend-html5[] :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] FreeBSD の進歩は急速であり、 印刷したメディアは最新の開発をフォローするのに実用的ではありません。 それだけしかない、というわけではありませんが、 最新情報を入手する方法としては電子的なリソースがベストです。 FreeBSD はボランティアの努力によって、ユーザコミュニティ自体が、 一種の "テクニカルサポート部門" としての役割も通常果たしており、 電子メール、ウェブフォーラムおよび Usenet のニュースがこれらのコミュニティにたどり着く最も効果的な方法になっています。 以下に、FreeBSD ユーザコミュニティに連絡を取る場合の最も重要な点についての概略を示します。 ここに書かれていない他のリソースをご存知であれば、 それらをここに含めることができるように、 {freebsd-doc} にお知らせください。 [[eresources-www]] == ウェブサイト * https://forums.FreeBSD.org/[The FreeBSD Forums] は、FreeBSD の質問および技術的な議論のためのウェブベースのフォーラムです。 * http://www.youtube.com/bsdconferences[BSDConferences YouTube Channel] は、世界中で開催されている BSD カンファレンスでのプレゼンテーションの高品質のビデオです。 主要な開発者による FreeBSD の新しい進展についてのプレゼンテーションをぜひともご覧ください。 [[eresources-mail]] == メーリングリスト メーリングリストは、FreeBSD の関係者に対し質問を投稿したり、 技術的な議論を行うのに、最も直接的な方法です。 さまざまな FreeBSD の関連トピックに対し、 幅広いメーリングリストが存在しています。 質問を適切なメーリングリストに投稿すれば、 早く、的確な反応がいつでも得られることでしょう。 さまざまなメーリングリストの憲章をこのドキュメントの最後に記載します。 __私たちは、メーリングリストの質、 特に技術面に関する質を高く保つために努力しているので、 メーリングリストに参加する前にその憲章を読んでください。 __ 私たちのメーリングリストの参加者のほとんどは、 非常にたくさんの FreeBSD に関連したメッセージを毎日受け取っており、 メーリングリストの利用に関する憲章やルールは、 メーリングリストの S/N 比を高く保つためのものです。 そうしないと、結果的に、 メーリングリストがプロジェクトにとって事実上のコミュニケーションの手段になってしまうでしょう。 [NOTE] ==== _FreeBSD メーリングリストにメールを送信できるかどうかを確認するには、 {freebsd-test} にテストメッセージを送信してください。_ 他のメーリングリストには、 テストメッセージを送信しないでください。 ==== どのメーリングリストに質問を投稿すべきか迷った場合には、 extref:{freebsd-questions-article}[How to get best results from the FreeBSD-questions mailing list] をご覧ください。 どこのメーリングリストに投稿する場合でも、メーリングリストを最大限に活用する方法を理解しておいてください。 たとえば、 extref:{mailing-list-faq}[Mailing List Frequently Asked Questions] (FAQ) 文書を読んで、 繰り返し行われる議論を避ける方法を理解してください。 メーリングリストはいずれもアーカイブされており、それらは link:https://www.FreeBSD.org/search/[FreeBSD World Wide Web server] で検索することができます。 キーワード検索可能なアーカイブの提供は、 良くある質問に対する回答を見つけるすぐれた方法ですから、 質問を投稿する前に調べてみるべきでしょう。 このことは、FreeBSD メーリングリストに送信されたメッセージは、 ずっとアーカイブされることを意味しています。 プライバシーの保護が問題になるような場合には、 使い捨てのメールアドレスを用い、公な情報のみを送ってください。 [[eresources-summary]] === メーリングリストの概説 _一般的なメーリングリスト:_ 以下のものは誰でも自由に参加できる (そしておすすめの) 一般的なものです。 [.informaltable] [cols="1,1", frame="none", options="header"] |=== | リスト | 目的 |link:{freebsd-advocacy-url}[freebsd-advocacy] |FreeBSD の福音伝道 |{freebsd-announce} |重要なイベントやプロジェクトのマイルストン (モデレータ制) |link:{freebsd-arch-url}[freebsd-arch] |アーキテクチャ、設計に関する議論 |link:{freebsd-bugbusters-url}[freebsd-bugbusters] |FreeBSD 障害報告データベースおよび関連するツールの管理に関する議論 |link:{freebsd-bugs-url}[freebsd-bugs] |バグレポート |link:{freebsd-chat-url}[freebsd-chat] |FreeBSD コミュニティに関連する技術的ではない話題 |link:{freebsd-chromium-url}[freebsd-chromium] |FreeBSD に固有の Chromium の問題について |{freebsd-current} |FreeBSD-CURRENT の使用に関連する議論 |link:{freebsd-isp-url}[freebsd-isp] |FreeBSD を用いている インターネットサービスプロバイダの話題 |link:{freebsd-jobs-url}[freebsd-jobs] |FreeBSD 関連の雇用機会に関する話題 |link:{freebsd-quarterly-calls-url}[freebsd-quarterly-calls] |四半期開発進捗レポートの呼びかけ (モデレータ制) |link:{freebsd-questions-url}[freebsd-questions] |ユーザからの質問と技術サポート |{freebsd-security-notifications} |セキュリティに関する通知 (モデレータ制) |{freebsd-stable} |FreeBSD-STABLE の使用に関連する議論 |{freebsd-test} |メッセージの送信試験を行なうために、 実際のメーリングリストの代わりに使うアドレス |link:{freebsd-women-url}[freebsd-women] |FreeBSD の女性支援 |=== _技術的なメーリングリスト:_ 以下のメーリングリストは、技術的な 議論のためのものです。 それらの利用や内容のためにしっかりとしたガイドラインがあるので、 これらのメーリングリストに入ったり、 どれか一つにメール を送ったりする前には、 それらのメーリングリストの憲章を注意深く読んでください。 [.informaltable] [cols="1,1", frame="none", options="header"] |=== | リスト | 目的 |{freebsd-acpi} |ACPI および電源管理の開発 |link:{freebsd-fortran-url}[freebsd-fortran] |FreeBSD での Fortran |link:{freebsd-amd64-url}[freebsd-amd64] |FreeBSD の AMD64 システムへの移植 (モデレータ制) |link:{freebsd-apache-url}[freebsd-apache] |Apache に関連した ports についての議論 |link:{freebsd-arm-url}[freebsd-arm] |FreeBSD の ARM(R) プロセッサへの移植 |link:{freebsd-atm-url}[freebsd-atm] |FreeBSD での ATM ネットワーク使用に関する話題 |link:{freebsd-bluetooth-url}[freebsd-bluetooth] |FreeBSD で Bluetooth(R) 技術の使用 |link:{freebsd-cloud-url}[freebsd-cloud] |クラウドプラットフォーム (EC2, GCE, Azure など) での FreeBSD |link:{freebsd-cluster-url}[freebsd-cluster] |FreeBSD のクラスタ環境での利用 |link:{freebsd-database-url}[freebsd-database] |FreeBSD 上でのデータベースの利用や開発に関する議論 |link:{freebsd-desktop-url}[freebsd-desktop] |デスクトップでの FreeBSD の利用や改良について |link:{dev-ci-url}[dev-ci] |継続的インテグレーションサーバからのビルドおよび試験レポート |link:{dev-reviews-url}[dev-reviews] |FreeBSD レビューシステムからの通知 |link:{freebsd-doc-url}[freebsd-doc] |FreeBSD 関連ドキュメントの作成 |link:{freebsd-drivers-url}[freebsd-drivers] |FreeBSD のデバイスドライバの書き方について |link:{freebsd-dtrace-url}[freebsd-dtrace] |FreeBSD における Dtrace の利用と開発 |link:{freebsd-eclipse-url}[freebsd-eclipse] |Eclipse IDE, ツール、 リッチクライアントアプリケーションの FreeBSD ユーザおよび ports |link:{freebsd-elastic-url}[freebsd-elastic] |FreeBSD 固有の ElasticSearch に関する議論 |link:{freebsd-embedded-url}[freebsd-embedded] |組み込みアプリケーションにおける FreeBSD の利用 |link:{freebsd-emulation-url}[freebsd-emulation] |Linux/MS-DOS(R)/Windows(R) のような他のシステムのエミュレーション |link:{freebsd-enlightenment-url}[freebsd-enlightenment] |Enlightenment および Enlightenment アプリケーションの移植 |link:{freebsd-erlang-url}[freebsd-erlang] |FreeBSD 固有の Erlang に関する議論 |link:{freebsd-firewire-url}[freebsd-firewire] |FreeBSD FireWire(R) (iLink, IEEE 1394) に関する技術的な議論 |link:{freebsd-fs-url}[freebsd-fs] |ファイルシステム |link:{freebsd-games-url}[freebsd-games] |FreeBSD でのゲームのサポート |link:{freebsd-gecko-url}[freebsd-gecko] |Gecko レンダリングエンジン に関する議論 |link:{freebsd-geom-url}[freebsd-geom] |GEOM に関連した議論と実装 |link:{freebsd-git-url}[freebsd-git] |FreeBSD プロジェクトでの git の使用に関する議論 |link:{freebsd-gnome-url}[freebsd-gnome] |GNOME および GNOME アプリケーションの移植 |link:{freebsd-hackers-url}[freebsd-hackers] |一般的な技術の議論 |link:{freebsd-haskell-url}[freebsd-haskell] |FreeBSD 固有の Haskell に関する議論 |link:{freebsd-hardware-url}[freebsd-hardware] |FreeBSD の走るハードウェアの一般的な議論 |link:{freebsd-i18n-url}[freebsd-i18n] |FreeBSD の国際化 |link:{freebsd-infiniband-url}[freebsd-infiniband] |FreeBSD での Infiniband の使用 |link:{freebsd-ipfw-url}[freebsd-ipfw] |IP firewall コードの再設計に関する技術的議論 |link:{freebsd-isdn-url}[freebsd-isdn] |ISDN 開発者 |link:{freebsd-jail-url}[freebsd-jail] |man:jail[8] に関する議論 |link:{freebsd-java-url}[freebsd-java] |Java(TM) 開発者や、FreeBSD へ JDK(TM) を移植する人たち |link:{freebsd-kde-url}[freebsd-kde] |KDE および KDE アプリケーションの移植 |link:{freebsd-mips-url}[freebsd-mips] |FreeBSD の MIPS(R) への移植 |link:{freebsd-mono-url}[freebsd-mono] |FreeBSD における Mono および C# アプリケーション |link:{freebsd-new-bus-url}[freebsd-new-bus] |バスアーキテクチャに関する技術的な議論 |link:{freebsd-net-url}[freebsd-net] |ネットワークおよび TCP/IP ソースコードに関する議論 |link:{freebsd-numerics-url}[freebsd-numerics] |高品質な libm 機能の実装に関する議論 |link:{freebsd-ocaml-url}[freebsd-ocaml] |FreeBSD 固有の OCaml に関する議論 |link:{freebsd-office-url}[freebsd-office] |FreeBSD でのオフィスアプリケーションについて |link:{freebsd-performance-url}[freebsd-performance] |ハイパフォーマンス / 高負荷での導入のためのパフォーマンスチューニングに関する質問 |link:{freebsd-perl-url}[freebsd-perl] |数多く存在する Perl に関連する port の管理について |link:{freebsd-pkg-url}[freebsd-pkg] |バイナリ package 管理および package ツールについての議論 |link:{freebsd-pf-url}[freebsd-pf] |パケットフィルタファイアウォールシステムに関する議論および質問 |link:{freebsd-pkg-url}[freebsd-pkg] |バイナリ package 管理および package 関連ツールの議論 |link:{freebsd-pkg-fallout-url}[freebsd-pkg-fallout] |package ビルドに失敗したログ |link:{freebsd-pkgbase-url}[freebsd-pkgbase] |FreeBSD ベースシステムの pkg 化 |link:{freebsd-platforms-url}[freebsd-platforms] |Intel(R) 以外のアーキテクチャのプラットフォームへの移植 |link:{freebsd-ports-url}[freebsd-ports] |Ports Collection に関する議論 |link:{freebsd-ports-announce-url}[freebsd-ports-announce] |Ports Collection に関する重要なニュースと案内 (モデレータ制) |link:{freebsd-ports-bugs-url}[freebsd-ports-bugs] |ports のバグや PR についての議論 |link:{freebsd-ppc-url}[freebsd-ppc] |FreeBSD の PowerPC(R) への移植 |link:{freebsd-proliant-url}[freebsd-proliant] |HP ProLiant サーバプラットフォーム上での FreeBSD に関する技術的な議論 |link:{freebsd-python-url}[freebsd-python] |FreeBSD 固有の Python に関する話題 |link:{freebsd-rc-url}[freebsd-rc] |[.filename]#rc.d# システムおよび開発に関連した議論 |link:{freebsd-realtime-url}[freebsd-realtime] |FreeBSD 用のリアルタイム拡張の開発に関する話題 |link:{freebsd-riscv-url}[freebsd-riscv] |FreeBSD の RISC-V(R) システムへの移植 |link:{freebsd-ruby-url}[freebsd-ruby] |FreeBSD 固有の Ruby に関する議論 |link:{freebsd-scsi-url}[freebsd-scsi] |SCSI サブシステム |{freebsd-security} |FreeBSD に影響するセキュリティに関する話題 |link:{freebsd-snapshots-url}[freebsd-snapshots] |FreeBSD 開発スナップショットのアナウンス |link:{freebsd-sparc64-url}[freebsd-sparc64] |FreeBSD の SPARC(R) ベースシステムへの移植 |link:{freebsd-standards-url}[freebsd-standards] |C99 および POSIX(R) 標準への FreeBSD の適合について |link:{freebsd-sysinstall-url}[freebsd-sysinstall] |man:sysinstall[8] の開発 |link:{freebsd-tcltk-url}[freebsd-tcltk] |FreeBSD 固有の Tcl/Tk に関する議論 |link:{freebsd-testing-url}[freebsd-testing] |FreeBSD における試験 |link:{freebsd-tex-url}[freebsd-tex] |TeX および関連アプリケーションの FreeBSD への移植 |link:{freebsd-threads-url}[freebsd-threads] |FreeBSD のスレッドについて |link:{freebsd-tokenring-url}[freebsd-tokenring] |FreeBSD でのトークンリングのサポート |link:{freebsd-toolchain-url}[freebsd-toolchain] |FreeBSD の統合されたツールチェインのメンテナンス |link:{freebsd-translators-url}[freebsd-translators] |FreeBSD 文書およびプログラムの翻訳 |link:{freebsd-transport-url}[freebsd-transport] |FreeBSD でのトランスポートレベルネットワークプロトコルに関する議論 |link:{freebsd-usb-url}[freebsd-usb] |FreeBSD の USB 対応に関する議論 |link:{freebsd-virtualization-url}[freebsd-virtualization] |FreeBSD によりサポートされているさまざまな仮想化技術についての議論 |link:{freebsd-vuxml-url}[freebsd-vuxml] |VuXML インフラストラクチャに関する議論 |link:{freebsd-wireless-url}[freebsd-wireless] |802.11 スタック、 ツールおよびデバイスドライバの開発に関する議論 |link:{freebsd-x11-url}[freebsd-x11] |FreeBSD での X11 のメンテナンスとサポート |link:{freebsd-xen-url}[freebsd-xen] |FreeBSD の Xen(TM) への移植 - 実装および利用についての議論 |link:{freebsd-xfce-url}[freebsd-xfce] |XFCE の FreeBSD への移植や保守について |link:{freebsd-zope-url}[freebsd-zope] |Zope の FreeBSD への移植や保守について |=== _制限されているメーリングリスト:_ 以下のメーリングリストはより特化された (そしてより厳しい) メンバーのためのものであり、 一般的な興味を惹くようなものではありません。 このようなメーリングリストに参加する前に、 技術的なメーリングリストで自らの存在感をアピールするのは良い考えです。 そうすることにより、 議論の際のエチケットを学ぶことができるでしょう。 [.informaltable] [cols="1,1", frame="none", options="header"] |=== | メーリングリスト | 目的 |link:{freebsd-hubs-url}[freebsd-hubs] |ミラーサイトを運営している人達 (基盤のサポート) |link:{freebsd-user-groups-url}[freebsd-user-groups] |ユーザグループの調整 |link:{freebsd-wip-status-url}[freebsd-wip-status] |FreeBSD の進行中のプロジェクトに関する状況 |=== _メーリングリストのダイジェスト版:_ 上述のメーリングリストのすべてでダイジェスト版を利用できます。 メーリングリストに登録すると、アカウントのオプションセクションで、 ダイジェストのオプションを変更できます。 _コミットメッセージリスト:_ 以下のメーリングリストは、 ソースツリーのさまざまな領域に対する変更に対するログメッセージを見ることに興味のある人向けです。 [.informaltable] [cols="1,1,1", frame="none", options="header"] |=== | メーリングリスト | ソースの範囲 | (ソースの) 範囲の説明 |{dev-commits-doc-all-url}[dev-commits-doc-all] |[.filename]#/usr/doc# |doc リポジトリへ加えられたすべての変更 |{dev-commits-ports-all-url}[dev-commits-ports-all] |[.filename]#/usr/ports# |ports リポジトリへ加えられたすべての変更 |{dev-commits-ports-main-url}[dev-commits-ports-main] |[.filename]#/usr/ports# |ports リポジトリの "main" ブランチに加えられたすべての変更 |{dev-commits-ports-branches-url}[dev-commits-ports-branches] |[.filename]#/usr/ports# |ports リポジトリの四半期ごとのブランチに加えられたすべての変更 |{dev-commits-src-all-url}[dev-commits-src-all] |[.filename]#/usr/src# |src リポジトリへ加えられたすべての変更 |{dev-commits-src-main-url}[dev-commits-src-main] |[.filename]#/usr/src# |src リポジトリの "main" ブランチ (FreeBSD-CURRENT ブランチ) に加えられたすべての変更 |{dev-commits-src-branches-url}[dev-commits-src-branches] |[.filename]#/usr/src# |src リポジトリのすべての stable ブランチに加えられたすべての変更 |=== _SVN メーリングリスト:_ 以下のメーリングリストは、 ソースツリーのさまざまな領域に対する変更の SVN ログメッセージを見ることに興味のある人向けです。 [NOTE] ==== SVN ログメッセージのみが SVN のメーリングリストに送られます。 SVN から Git への移行後は、以下のメーリングリストには、新しいコミットメッセージは送られませんし、購読もできません。 以下の一覧のリンクは、各メーリングリストのアーカイブへのリンクです。 ==== [.informaltable] [cols="1,1,1", frame="none", options="header"] |=== | メーリングリスト | ソースの範囲 | (ソースの) 範囲の説明 |link:{svn-doc-all-url}[svn-doc-all] |[.filename]#/usr/doc# |doc subversion リポジトリへ加えられたすべての変更 ([.filename]#user#, [.filename]#projects# および [.filename]#translations# を除く) |link:{svn-doc-head-url}[svn-doc-head] |[.filename]#/usr/doc# |doc subversion リポジトリの "head" ブランチに加えられたすべての変更 |link:{svn-doc-projects-url}[svn-doc-projects] |[.filename]#/usr/doc/projects# |doc subversion リポジトリの [.filename]#projects# に加えられたすべての変更 |link:{svn-doc-svnadmin-url}[svn-doc-svnadmin] |[.filename]#/usr/doc# |doc subversion リポジトリの管理用スクリプト、 フックおよび他のコンフィグレーションデータに対して加えられたすべての変更 |link:{svn-ports-all-url}[svn-ports-all] |[.filename]#/usr/ports# |ports subversion リポジトリへ加えられたすべての変更 |link:{svn-ports-head-url}[svn-ports-head] |[.filename]#/usr/ports# |ports subversion リポジトリの "head" ブランチに加えられたすべての変更 |link:{svn-ports-svnadmin-url}[svn-ports-svnadmin] |[.filename]#/usr/ports# |ports subversion リポジトリの管理用スクリプト、 フックおよび他のコンフィグレーションデータに対して加えられたすべての変更 |{svn-src-all} |[.filename]#/usr/src# |src subversion リポジトリへ加えられたすべての変更 ([.filename]#user# および [.filename]#projects# を除く) |{svn-src-head} |[.filename]#/usr/src# |src subversion リポジトリの "head" ブランチ (FreeBSD-CURRENT ブランチ) に加えられたすべての変更 |link:{svn-src-projects-url}[svn-src-projects] |[.filename]#/usr/projects# |src subversion リポジトリの [.filename]#projects# に加えられたすべての変更 |link:{svn-src-release-url}[svn-src-release] |[.filename]#/usr/src# |src subversion リポジトリの [.filename]#releases# に加えられたすべての変更 |link:{svn-src-releng-url}[svn-src-releng] |[.filename]#/usr/src# |src subversion リポジトリの [.filename]#releng# ブランチ (セキュリティ / リリースエンジニアリングブランチ) に加えられたすべての変更 |link:{svn-src-stable-url}[svn-src-stable] |[.filename]#/usr/src# |src subversion リポジトリのすべての stable ブランチに加えられたすべての変更 |link:{svn-src-stable-6-url}[svn-src-stable-6] |[.filename]#/usr/src# |src subversion リポジトリの [.filename]#stable/6# ブランチに加えられたすべての変更 |link:{svn-src-stable-7-url}[svn-src-stable-7] |[.filename]#/usr/src# |src subversion リポジトリの [.filename]#stable/7# ブランチに加えられたすべての変更 |link:{svn-src-stable-8-url}[svn-src-stable-8] |[.filename]#/usr/src# |src subversion リポジトリの [.filename]#stable/8# ブランチに加えられたすべての変更 |{svn-src-stable-9} |[.filename]#/usr/src# |src subversion リポジトリの [.filename]#stable/9# ブランチに加えられたすべての変更 |link:{svn-src-stable-10-url}[svn-src-stable-10] |[.filename]#/usr/src# |src subversion リポジトリの [.filename]#stable/10# ブランチに加えられたすべての変更 |link:{svn-src-stable-11-url}[svn-src-stable-11] |[.filename]#/usr/src# |src subversion リポジトリの [.filename]#stable/11# ブランチに加えられたすべての変更 |link:{svn-src-stable-12-url}[svn-src-stable-12] |[.filename]#/usr/src# |src subversion リポジトリの [.filename]#stable/12# ブランチに加えられたすべての変更 |link:{svn-src-stable-other-url}[svn-src-stable-other] |[.filename]#/usr/src# |src subversion リポジトリの古い [.filename]#stable# ブランチに加えられたすべての変更 |link:{svn-src-svnadmin-url}[svn-src-svnadmin] |[.filename]#/usr/src# |src subversion リポジトリの管理用スクリプト、 フックおよび他のコンフィグレーションデータに対して加えられたすべての変更 |link:{svn-src-user-url}[svn-src-user] |[.filename]#/usr/src# |src subversion リポジトリの [.filename]#user# に加えられた実験的なすべての変更 |link:{svn-src-vendor-url}[svn-src-vendor] |[.filename]#/usr/src# |src subversion リポジトリの vender に加えられたすべての変更 |=== [[eresources-subscribe]] === 参加方法 メーリングリストに参加するには、{mailing-lists-url} で、 希望のメーリングリストをクリックしてください。 表示されるページには、 各メーリングリストに登録するために必要な手順が書かれています。 メーリングリストにメールを送るには、 mailto:listname@FreeBSD.org[listname@FreeBSD.org] にメールを送ってください。すると、 メーリングリストに登録されている世界中のメンバに再配布されます。 メーリングリストから登録を解除する場合は、メーリングリストで配信されているメールの最後にある URL をクリックしてください。 または、 mailto:listname+unsubscribe@FreeBSD.org[listname+unsubscribe@FreeBSD.org] にメールを送信することでも登録を解除できます。 技術的なメーリングリストでは、 技術的な議論を保つようにすることが重要です。 もし、重要なアナウンスのみを受け取りたいのであれば、 {freebsd-announce} への参加をお勧めします。 ここには、あまりたくさんのメールは流れません。 [[eresources-charters]] === メーリングリストの憲章 _すべて_ FreeBSD メーリングリストは誰でもそれらを利用することに固守しなければいけないという一定の簡単なルールがあります。 これらのルールに従わないと、結果として FreeBSD の Postmaster mailto:postmaster@FreeBSD.org[postmaster@FreeBSD.org] から 2 回までは警告を受けます。 3 回違反すると、投稿者はすべての FreeBSD のメーリングリストから削除され、 そのメーリングリストへのさらなる投稿から締め出されるでしょう。 これらのルールや対策が必要なのは残念です。 しかし、今日のインターネットはずいぶんいやらしい環境になっており、 一般の人々は、その (対策の) メカニズムがいかにもろいかという事すら認識する事が出来ていないと思われます。 道標 * いかなる投稿記事もそのメーリングリストの基本的な憲章を守るべきです。 そのメーリングリストが技術的な問題に関するものであれば、 技術的な議論を含む投稿でなければなりません。 現在継続中の不適切な憲章やフレイムは、 所属しているすべての人に対してメーリングリストの価値を下げてしまうだけですし、 許される行為ではないでしょう。 とくに話題のない自由形式の議論に対しては {freebsd-chat} が自由に認可されているので、 かわりに使うべきでしょう。 * 一度に 3 つ以上のメーリングリストには決して投稿すべきではありません。 2 つのメーリングリストには双方に明確な必要性がある場合にのみ投稿すべきです。 どのリストに対しても、 (メーリングリストの)参加者は (複数のメーリングリストに) 重複して参加しており、関連する部分が少ない (たとえば、 "-stable" と "-scsi") メーリングリストを除いては、 一度に複数のメーリングリストに投稿する理由は全くありません。 `Cc` に複数のメーリングリストが含まれたメッセージを受信した場合には、 そのメールに返事を出す前に、 `Cc` の部分を編集してください。 _元記事を書いたのが誰であっても、 返信する方にもクロスポストの責任があります。_ * ユーザであれ開発者であれ、(議論の中で) 個人を攻撃したり冒涜したりすることは許されません。 個人的なメールを引用したり再投稿したりする許可をもらえなかったり、 もらえそうにない時に、 それをおこなう ようなネチケット (訳注: ネットワークにおけるエチケット) に対するひどい違反は好まれませんが、 してはならないと特別に定められている わけではありません。 _しかしながら_、 そのような内容がメーリングリストの憲章に沿う場合はほとんどありません。 このため、メーリングリストの憲章に違反しているということだけで警告 (または禁止) に値するものと考えていいでしょう。 * FreeBSD 以外の関連する製品やサービスの広告は、 絶対に禁止し、spam による違反者が宣伝していることが明確であったら、 すぐに禁止します。 _個々のメーリングリストの憲章:_ {freebsd-acpi}:: _ACPI および電源管理開発_ link:{freebsd-fortran-url}[freebsd-fortran]:: _FreeBSD での Fortran_ + FreeBSD での Fortran に関連した ports の議論のためのメーリングリストです。 ラップトップから HPC クラスタまで、 コンパイラ、ライブラリ、 科学および工学のアプリケーションが対象です。 {freebsd-announce}:: _重要なイベント/マイルストン_ + これは、単にたまに発表される重要な FreeBSD のイベントに関心がある人のためのメーリングリストです。 これは、 スナップショットやその他のリリースについてのアナウンスを含みます。 そのアナウンスは新しい FreeBSD の機能のアナウンスを含んでいます。 ボランティア等の呼びかけがあるかもしれません。 これは流通量の少ないメーリングリストで、 完全なモデレートメーリングリストです。 link:{freebsd-arch-url}[freebsd-arch]:: _アーキテクチャと設計の議論_ + これは、FreeBSD のアーキテクチャに関する議論を行なうためのメーリングリストです。 当然、その内容は原則的に技術的なものに限定されます。 このメーリングリストにふさわしい話題は以下のようなものです。 ** 複数のカスタマイズされたビルドを同時に行うには、 ビルドシステムをどういじり直せばよいか ** VFS で Heidemann レイヤを動作させるには、 何を修正する必要があるか ** 同一のデバイスドライバを多数のバス、 アーキテクチャに共通で使えるようにするには、 デバイスドライバインタフェースをどう改変すれば良いか ** ネットワークドライバの書き方 link:{freebsd-bluetooth-url}[freebsd-bluetooth]:: _FreeBSD 上での Bluetooth(R)_ + FreeBSD の Bluetooth(R) ユーザが集まるフォーラムです。 デザイン、実装の詳細、パッチ、障害報告、開発進捗レポート、 機能の要求、Bluetooth(R) に関連したすべての事柄が対象です。 link:{freebsd-bugbusters-url}[freebsd-bugbusters]:: _障害報告の取り扱いに関する調整_ + このメーリングリストは、 バグマイスター、バグバスター、 および他の障害報告データベースに純粋に興味を持っているグループの調整や議論についてのフォーラムです。 このメーリングリストは、個別のバグ、パッチ、 障害報告について議論を行うためのものではありません。 link:{freebsd-bugs-url}[freebsd-bugs]:: _バグレポート_ + これは、FreeBSD のバグレポートのためのメーリングリストです。 可能である場合はいつでも、バグは man:send-pr[1] を使うか、 https://bugs.freebsd.org/bugzilla/enter_bug.cgi[web interface]を用いて送られる必要があります。 link:{freebsd-chat-url}[freebsd-chat]:: _FreeBSD のコミュニティに関する技術的ではない話題_ + このメーリングリストは技術的ではなく、 社会的な情報について、 他のメーリングリストでは取り扱わない話題を含みます。 これは、Jordan がシロイタチに似ているかどうか、 大文字で打つかどうか、誰がたくさんコーヒーを飲むか、 どこのビールが一番うまいか、 誰が地下室でビールを作っているか、 などについての議論を含みます。時々重要なイベント (将来開催されるパーティーや、結婚式、誕生日、 新しい仕事など) のお知らせが、 技術的なメーリングリストからでてきます。しかし、 フォローは直接 -chatメーリングリストにするべきです。 link:{freebsd-chromium-url}[freebsd-chromium]:: _FreeBSD 固有の Chromium の問題_ + FreeBSD における Chromium のサポートについて議論を行うためのメーリングリストです。 Chromium の開発およびインストールに関して議論を行う技術的なメーリングリストです。 link:{freebsd-cloud-url}[freebsd-cloud]:: _さまざまなクラウドプラットフォームでの FreeBSD の実行_ + このメーリングリストでは、FreeBSD を Amazon EC2, Google Compute Engine, Microsoft Azure およびその他のクラウドコンピューティングプラットフォームでの使用について議論を行います。 {core-name}:: _FreeBSD コアチーム_ + これは、コアメンバが使う内部メーリングリストです。 FreeBSD に関連する深刻なやっかい事の裁定やハイレベルな綿密な調査を要求するときに、 このメーリングリストにメッセージを送る事が出来ます。 {freebsd-current}:: _FreeBSD-CURRENT の使用に関する議論_ + これは FreeBSD-CURRENT のユーザのためのメーリングリストです。 メーリングリストでの話題は、-CURRENT で登場した新しい機能について、 その新機能によってユーザに影響することについての注意、 および -CURRENT のままでいるために必要な手順についての説明を含みます。 "CURRENT" を走らせている人はこのメーリングリストに登録しなくてはなりません。 これは技術的なメーリングリストなので、 完全に技術的な内容を要求します。 link:{freebsd-desktop-url}[freebsd-desktop]:: _デスクトップでの FreeBSD の利用や改良について_ + デスクトップでの FreeBSD について議論を行うためのフォーラムです。 主として、デスクトップの移植者やユーザが FreeBSD のデスクトップサポートに関する問題点や改良について議論する場です。 link:{dev-ci-url}[dev-ci]:: _ビルドおよび試験結果の継続的インテグレーションレポート_ + ビルドおよび試験結果に関するすべての継続的インテグレーションのレポート link:{dev-reviews-url}[dev-reviews]:: _FreeBSD レビューツールの進行中の作業の通知_ + パッチを含む FreeBSD レビューツールによる進行中のレビュー作業の自動通知 link:{freebsd-doc-url}[freebsd-doc]:: _ドキュメンテーションプロジェクト_ + このメーリングリストは FreeBSD 向けの文書の作成に関連する事柄やプロジェクトについて議論を行なうためのものです。 このメーリングリストに参加しているメンバは、 "FreeBSD ドキュメンテーションプロジェクト" に参加していることになります。 このメーリングリストは公開されているので、 参加や投稿は自由に行なうことができます。 link:{freebsd-drivers-url}[freebsd-drivers]:: _FreeBSD のデバイスドライバの書き方について_ + このメーリングリストは、FreeBSD のデバイスドライバに関連した技術的なフォーラムです。 主にデバイスドライバを書く人たちが、 FreeBSD カーネルの API を使ったデバイスドライバの書き方について質問を行う場です。 link:{freebsd-dtrace-url}[freebsd-dtrace]:: _FreeBSD における Dtrace の利用と開発_ + DTrace は、 カーネルおよびユーザ空間のプログラムを実行時に解析するためのフレームワークを提供するもので、 FreeBSD に統合されています。 このメーリングリストは、 コードの開発者および利用者の議論のアーカイブです。 link:{freebsd-eclipse-url}[freebsd-eclipse]:: _Eclipse IDE, ツール、 リッチクライアントアプリケーションの FreeBSD ユーザおよび ports_ + このメーリングリストの目的は、FreeBSD プラットフォームでの Eclipse IDE、ツール、リッチクライアントアプリケーションについて、 選択、インストール、利用、 開発および管理に関係するすべての相互支援を提供すること、 そして Eclipse IDE およびプラグインの FreeBSD 環境への移植を手助けすることです。 + このメーリングリストのもう一つの目的は、 Eclipse コミュニティと FreeBSD コミュニティが相互に利益になるような情報交換の場を提供することです。 + このメーリングリストは、主に Eclipse ユーザのニーズに焦点が当てられていますが、 Eclipse フレームワークを用いた FreeBSD アプリケーションの開発に関わる方々のフォーラムにもなっています。 link:{freebsd-embedded-url}[freebsd-embedded]:: _組み込みアプリケーションにおける FreeBSD の利用_ + このメーリングリストは、組み込みシステムにおける FreeBSD の利用に関するトピックを議論するためのものです。 これは技術的なメーリングリストなので、 完全に技術的な内容を要求します。 このメーリングリストにおいて、 組み込みシステムは、 デスクトップや通常の一般的なコンピュータ環境ではなく、 単一の目的のために使われるコンピュータデバイスを意味します。 これらの例は、 携帯電話、ルータやスイッチおよび PBX といったネットワーク機器、 PDA, POS システムといったものです。 link:{freebsd-emulation-url}[freebsd-emulation]:: _Linux/MS-DOS(R)/Windows(R) 等の他のシステムのエミュレーション_ + 他のオペレーティングシステムに書かれたプログラムを、 FreeBSD で走らせることに関連した技術的な議論のためのフォーラムです。 link:{freebsd-enlightenment-url}[freebsd-enlightenment]:: _Enlightenment_ + FreeBSD システムでの Enlightenment デスクトップ環境に関連した議論。 技術的なメーリングリストなので、 完全に技術的な内容が要求されます。 link:{freebsd-firewire-url}[freebsd-firewire]:: _FireWire(R) (iLink, IEEE 1394)_ + このメーリングリストは、FreeBSD における FireWire(R) (IEEE 1394, iLink) サブシステムの設計と実装について議論を行うためのものです。 標準化、バスデバイスとそのプロトコル、 アダプタボード/カード/チップセット、そして、 それらに適切に対応するためのアーキテクチャとコードの実装が特に関連するトピックです。 link:{freebsd-fs-url}[freebsd-fs]:: _ファイルシステム_ + FreeBSD のファイルシステムに関する議論。 これは技術的なメーリングリストなので、 完全に技術的な内容を要求します。 link:{freebsd-games-url}[freebsd-games]:: _FreeBSD のゲーム_ + FreeBSD にゲームを持ち込むことに関連した議論を行うメーリングリストです。 活発にゲームを FreeBSD に移植する作業を行っている方や、 問題を提起したり、 その他の解決方法を議論したりする方のためのものです。 技術的な議論に興味のある方の参加も歓迎されます。 link:{freebsd-gecko-url}[freebsd-gecko]:: _Gecko レンダリングエンジン_ + FreeBSD を使った Gecko アプリケーションについてのフォーラムです。 + このメーリングリストでは、Gecko Ports アプリケーション、インストール、開発および FreeBSD でのサポートといった話題を中心に議論が行われます。 link:{freebsd-geom-url}[freebsd-geom]:: _GEOM_ + GEOM および関連した実装に関する議論。 これは技術的なメーリングリストなので、 完全に技術的な内容が要求されます。 link:{freebsd-git-url}[freebsd-git]:: _FreeBSD での git の使用_ + FreeBSD のプロジェクトコラボレーションおける github ミラーおよびその他の git の使用など、git インフラストラクチャをどのように使うかといった議論が行われます。 FreeBSD github ミラーから git を使用する方々が議論に参加しています。 ミラーの使用を考えている方や、git の一般的な FreeBSD での使用を考えている方はここで質問できます。 link:{freebsd-gnome-url}[freebsd-gnome]:: _GNOME_ + FreeBSD の GNOME Desktop Environment に関する議論。 これは技術的なメーリングリストなので、 完全に技術的な内容を要求します。 link:{freebsd-infiniband-url}[freebsd-infiniband]:: _FreeBSD での Infiniband の使用_ + FreeBSD における Infiniband, OFED および OpenSM に関する技術的なメーリングリストです。 link:{freebsd-ipfw-url}[freebsd-ipfw]:: _IP Firewall_ + これは FreeBSD の IP firewall コードの再設計に関する技術的な議論のためのフォーラムです。 これは技術的なメーリングリストなので、 完全に技術的な内容を要求します。 link:{freebsd-isdn-url}[freebsd-isdn]:: _ISDN コミュニケーション_ + このメーリングリストは、 FreeBSD に対する ISDN サポートの開発の議論をおこなう人のためのものです． link:{freebsd-java-url}[freebsd-java]:: _Java(TM) の開発_ + このメーリングリストは、FreeBSD 向けの重要な Java(TM) アプリケーションの開発や、JDK(TM) の移植やメンテナンスの議論をする人のためのものです． [[eresources-charters-jobs]] link:{freebsd-jobs-url}[freebsd-jobs]:: _求人情報および就職希望情報_ + FreeBSD に関連した就職情報、および FreeBSD に関連した職業を探している方が履歴書を投稿するためのフォーラムです。 このメーリングリストは一般的な就職情報のためのものでは _ありません_。 一般的な就職情報については、 既に別な場所に適切なフォーラムがあるので、 そちらに投稿してください。 + 他の `FreeBSD.org` メーリングリスト同様に、 このメーリングリストは全世界に配信されます。 地域に関する情報や、 在宅勤務なのか移転のための支援を受けられるかどうかを明確にしてください。 + メールでは、オープンフォーマットのみを使う必要があります。 - プレインテキストが好ましいのですが、 多くの読者は、 Portable Document Format (PDF), HTML および他にもいくつかのフォーマットを使用できるでしょう。 Microsoft(R) Word ([.filename]#.doc#) のようなクローズドフォーマットは、 メーリングリストのサーバにより拒否されてしまいます。 link:{freebsd-kde-url}[freebsd-kde]:: _KDE_ + FreeBSD システムにおける KDE に関する議論。 これは技術的なメーリングリストなので、 完全に技術的な内容を要求します。 link:{freebsd-hackers-url}[freebsd-hackers]:: _技術的な議論_ + これは FreeBSD に関する技術的な議論のためのフォーラムです。 これは最もテクニカルなメーリングリストです。 このメーリングリストは、FreeBSD 上でアクティブに活動をしている人のためのもので、 問題を持ち出したり、代わりの解決法を議論します。 技術的な議論をフォローするのに興味がある人も歓迎します。 これは技術的なメーリングリストなので、 完全に技術的な内容を要求します。 link:{freebsd-hardware-url}[freebsd-hardware]:: _FreeBSD のハードウェアの一般的な議論_ + FreeBSD が走っているハードウェアのタイプや、 何を買ったり避けたりするかに関する様々な問題や、 提案に関する議論。 link:{freebsd-hubs-url}[freebsd-hubs]:: _ミラーサイト_ + FreeBSD ミラーサイトを運用している人達向けの、 アナウンスと議論を行なうメーリングリストです。 link:{freebsd-isp-url}[freebsd-isp]:: _インターネットサービスプロバイダのについての話題_ + このメーリングリストは、 FreeBSD を用いたインターネット サービスプロバイダ (ISP) に関する話題の議論のためのものです。 これは技術的なメーリングリストなので、 完全に技術的な内容を要求します。 link:{freebsd-mono-url}[freebsd-mono]:: _FreeBSD における Mono および C# アプリケーション_ + FreeBSD 上での Mono 開発フレームワークに関連した議論を行うためのメーリングリストです。 これは、技術的なメーリングリストです。 Mono または C# アプリケーションの FreeBSD への移植を活発に行っている方が、 問題を提起したり、他の解決方法について議論を行うためのものです。 技術的な議論に興味を持っている方の参加も歓迎されます。 link:{freebsd-ocaml-url}[freebsd-ocaml]:: _FreeBSD 固有の OCaml に関する議論_ + このメーリングリストは、FreeBSD における OCaml に関する議論の場です。 このメーリングリストは技術的なメーリングリストです。 OCaml port、サードパーティ製ライブラリ、 およびフレームワークに関して作業を行っている個人のためのものです。 技術的な議論に興味を持っている個人の参加が歓迎されます。 link:{freebsd-office-url}[freebsd-office]:: _FreeBSD でのオフィスアプリケーション_ + FreeBSD におけるオフィスアプリケーションのインストール、 開発およびサポートについての議論の場です。 link:{freebsd-ops-announce-url}[freebsd-ops-announce]:: _プロジェクトのインフラストラクチャに関するアナウンス_ + FreeBSD.org プロジェクトのインフラストラクチャの変更や関連した問題について興味を持っている向けのメーリングリストです。 + このモデレートメーリングリストは、 アナウンスに制限されています (返答や要求、議論、意見を述べる場ではありません)。 link:{freebsd-performance-url}[freebsd-performance]:: _FreeBSD のチューニングや速度向上に関する議論_ + このメーリングリストは、ハッカー、 管理者および関連グループが、 FreeBSD のパフォーマンスに関するトピックを議論する場です。 このメーリングリストで議論されるべきトピックは、 高負荷における FreeBSD の導入において経験するパフォーマンスの問題や FreeBSD の限界に挑むような話題を含みます。 FreeBSD のパフォーマンスを改善したいと考えている方は、 このメーリングリストに登録してください。 このメーリングリストは、FreeBSD の高速化、 堅牢さ、拡張性に興味をもっている、経験のある FreeBSD ユーザ、ハッカー、管理者向けの高度な技術的メーリングです。 ドキュメントに目を通さずに質問して答えを求めるような Q and A タイプのメーリングリストではなく、 未解決で答えのないパフォーマンスに関連したトピックへの貢献や問い合わせの場です。 link:{freebsd-pkg-url}[freebsd-pkg]:: _バイナリ package 管理および package ツールについての議論_ + ソフトウェアのインストールにバイナリ package を用いる FreeBSD システム管理のすべての側面に関する議論。 バイナリ package のツールキットとフォーマット、 それらの FreeBSD における開発とサポート、 package リポジトリ管理そしてサードパーティ製 package を含みます。 + package の作成に失敗する ports に関する議論は ports の問題として考えるべきであり、 このメーリングリストで議論することは適切ではありません。 link:{freebsd-pf-url}[freebsd-pf]:: _パケットフィルタファイアウォールシステムに関する議論および質問_ + FreeBSD のパケットフィルタ (pf) ファイアウォールシステムに関連した議論。 技術的な議論およびユーザによる質問の両方が歓迎されます。 このメーリングリストは、ALTQ QoS フレームワークについて議論する場でもあります。 link:{freebsd-pkg-fallout-url}[freebsd-pkg-fallout]:: _package ビルドに失敗したログ_ + package ビルドクラスタにおいて package ビルドに失敗したすべてのログ link:{freebsd-pkgbase-url}[freebsd-pkgbase]:: _FreeBSD ベースシステムの pkg 化_ + FreeBSD ベースシステムの pkg 化に関する実装および課題についての議論。 link:{freebsd-platforms-url}[freebsd-platforms]:: _Intel(R) 以外のプラットフォームへの移植_ + クロスプラットフォームの FreeBSD の問題。Intel(R) 以外のプラットフォームへの FreeBSD の移植についての一般的な議論や提案。 これは技術的なメーリングリストなので、 完全に技術的な内容を要求します。 link:{freebsd-ports-url}[freebsd-ports]:: _"ports" の議論_ + FreeBSD "Ports Collection" ([.filename]#/usr/ports#) に関連する話題や、 Ports Collection の基盤および ports の一般的な構成の整備活動に関する議論。 これは技術的なメーリングリストなので、 厳密に技術的な内容のみが扱われます。 link:{freebsd-ports-announce-url}[freebsd-ports-announce]:: _FreeBSD "Ports Collection" に関する重要なニュースと案内_ + "Ports Collection" ([.filename]#/usr/ports#) の開発者、 ports 作成者およびユーザへの重要なニュース。 アーキテクチャ/インフラストラクチャの変更、新しい機能、 重要なアップグレードの案内、 そしてリリースエンジニアリング情報が扱われます。 このメーリングリストの流量は少なく、 アナウンスを目的としたものです。 link:{freebsd-ports-bugs-url}[freebsd-ports-bugs]:: _"ports" のバグに関する議論_ + "Ports Collection" ([.filename]#/usr/ports#) の障害報告や新たな ports や変更についての提案についての議論。 これは技術的なメーリングリストなので、 厳密に技術的な内容のみが扱われます。 link:{freebsd-proliant-url}[freebsd-proliant]:: _HP ProLiant サーバプラットフォーム上での FreeBSD に関する技術的な議論_ + このメーリングリストは、HP ProLiant サーバ上での FreeBSD の利用に関した技術的な議論に用いられます。 ProLiant に特有のドライバ、管理ソフトウェア、設定ツール、および BIOS アップデートなどが含まれます。 hpasmd, hpasmcli および hpacucli モジュールについて議論する主要な場です。 link:{freebsd-python-url}[freebsd-python]:: _FreeBSD における Python_ + FreeBSD における Python サポートの改良に関連した議論を行うためのメーリングリストです。 これは技術的なメーリングリストです。 Python の移植に関する作業を行っている方や、 サードパーティ製モジュールおよび Zope を FreeBSD に移植している方を対象としたメーリングリストです。 技術的な議論に興味を持っている方の参加も歓迎されます。 link:{freebsd-questions-url}[freebsd-questions]:: _ユーザからの質問_ + FreeBSD に関する質問のためのメーリングリストです。 技術的なメーリングリストに対しては、 極めて技術的な質問でなければ、 "どのようにして" という質問を送るべきではありません。 link:{freebsd-ruby-url}[freebsd-ruby]:: _FreeBSD 固有の Ruby に関する議論_ + FreeBSD での Ruby サポートに関連した議論を行うためのメーリングリストです。 これは技術的なメーリングリストです。Ruby ports, サードパーティライブラリおよびフレームワークについて作業を行っている人達を対象としています。 + 技術的な議論に興味を持つ方の参加も歓迎されます。 link:{freebsd-scsi-url}[freebsd-scsi]:: _SCSI サブシステム_ + これは FreeBSD のための SCSI サブシステムについて作業している人向けです。 これは技術的なメーリングリストなので、 完全に技術的な内容を要求します。 {freebsd-security}:: _セキュリティの関連の話題_ + FreeBSD コンピュータのセキュリティの話題 (DES, Kerberos, よく知られているセキュリティホールや、 それらのふさぎ方など) これは技術的なメーリングリストなので、 完全に技術的な議論を要求します。 これは、Q and A のメーリングリストではありません。 FAQ に対する Q and A (質問と答えの両方) の貢献は、歓迎されます。 {freebsd-security-notifications}:: _セキュリティ関連の通知_ + FreeBSD のセキュリティ問題や、 修正に関する通知を行ないます。 このメーリングリストは議論を行なうためのメーリングリストではありません。 議論は FreeBSD-security で行ないます。 link:{freebsd-snapshots-url}[freebsd-snapshots]:: _FreeBSD 開発スナップショットのアナウンス_ + このメーリングリストは、head/ および stable/ ブランチからの新しい FreeBSD 開発スナップショットのアナウンスを行います。 {freebsd-stable}:: _FreeBSD-STABLE の使用に関する議論_ + これは FreeBSD-STABLE のユーザ用のメーリングリストです。 "STABLE" は、 RELEASE 後もバグフィックスおよび新しい機能の追加など、 開発が続いているブランチです。 バイナリ互換性のため、ABI は安定するように維持されます。 メーリングリストでの話題は、-STABLE で登場した新しい機能について、 その新機能によってユーザに影響することについての注意、 および -STABLE のままでいるために必要な手順についての説明を含みます。 "STABLE" を走らせている人はこのメーリングリストに登録すべきです。 これは技術的なメーリングリストなので、 完全に技術的な内容を要求します。 link:{freebsd-standards-url}[freebsd-standards]:: _C99 POSIX への適合_ + C99 および POSIX 標準への FreeBSD の適合に関連した技術的な議論を行うためのフォーラムです。 :: _FreeBSD による教育_ + FreeBSD による教育について議論を行うための技術的ではないメーリングリストです。 link:{freebsd-testing-url}[freebsd-testing]:: _FreeBSD における試験_ + ATF/Kyua、ビルド試験のインフラストラクチャ、 他のオペレーティングシステム (NetBSD, ...) から FreeBSD への移植に関する試験など、FreeBSD の試験に関して議論を行う技術的なメーリングリストです。 link:{freebsd-tex-url}[freebsd-tex]:: _TeX および関連アプリケーションの FreeBSD への移植_ + TeX および関連アプリケーションの FreeBSD への移植について議論する技術的なメーリングリストです。 TeX の FreeBSD への移植作業を活発に行っている個人が、 問題を提起したり、他の解決策について議論するためのものです。 技術的な議論に興味を持っている個人の参加も歓迎されます。 link:{freebsd-toolchain-url}[freebsd-toolchain]:: _FreeBSD の統合されたツールチェインのメンテナンス_ + FreeBSD のツールチェインのメンテナンスに関連した議論を行うためのメーリングリストです。 Clang および GCC の状況についての議論の他に、アセンブラ、 リンカおよびデバッガ等のソフトウェアの議論も行われます。 link:{freebsd-transport-url}[freebsd-transport]:: _FreeBSD でのトランスポートレベルネットワークプロトコルに関する議論_ + The transport mailing list exists for the discussion of issues and designs around the transport level protocols in the FreeBSD network stack, including TCP, SCTP and UDP. TCP, SCTP および UDP などの FreeBSD ネットワークスタックのトランスポートレベルプロトコルに関する問題や設計についての議論を行うためのメーリングリストです。 ドライバ特有の話題であったりネットワークプロトコルなどの他のネットワークに関するトピックは、 で議論してください。 link:{freebsd-translators-url}[freebsd-translators]:: _FreeBSD 文書およびプログラムの翻訳_ + FreeBSD 文書を英語から他の言語へと翻訳を行っている方々が、 翻訳方法やツールについて議論を行うメーリングリストです。 新しいメンバーは、自己紹介と、 興味のある翻訳言語をお知らせください。 link:{freebsd-usb-url}[freebsd-usb]:: _FreeBSD の USB 対応に関する議論_ + これは、FreeBSD の USB 対応に関連した議論を行うメーリングリストです。 link:{freebsd-user-groups-url}[freebsd-user-groups]:: _ユーザグループの調整のメーリングリスト_ + これは、ローカルなユーザグループがお互いに、または、 コアチームが指定した個人と問題を議論する、 それぞれのローカルエリアのユーザグループからの調整人向けのメーリングリストです。 このメーリングリストはユーザグループ間のミーティングの概要やプロジェクトの調整に制限されるべきです。 link:{freebsd-xfce-url}[freebsd-xfce]:: _XFCE_ + これは、XFCE 環境を FreeBSD へ移植することを議論する、技術的なメーリングリストです。 活発に XFCE を FreeBSD に移植する作業を行なっている人に向けたもので、 問題を提起したり、新しい解決法を議論することを目的としています。 技術的な議論に興味を持っている方の参加も歓迎します。 link:{freebsd-zope-url}[freebsd-zope]:: _Zope_ + これは、Zope 環境を FreeBSD へ移植することを議論する、技術的なメーリングリストです。 活発に Zope を FreeBSD に移植する作業を行なっている人に向けたもので、 問題を提起したり、新しい解決法を議論することを目的としています。 技術的な議論に興味を持っている方の参加も歓迎します。 link:{freebsd-virtualization-url}[freebsd-virtualization]:: _FreeBSD によりサポートされているさまざまな仮想化技術についての議論_ + FreeBSD によりサポートされているさまざまな仮想化技術に関する議論。 新しい機能および基本的な機能の実装に焦点を当てる一方で、 仮想化技術の使用の際に問題が起きた場合の手助けや議論のフォーラムでもあります。 link:{freebsd-wip-status-url}[freebsd-wip-status]:: _FreeBSD の進行中のプロジェクトの状況_ + このメーリングリストは、開発者が FreeBSD に関連したプロジェクトの立ち上げや進捗状況のアナウンスに利用するためのものです。 メールはモデレータ制です。 "To:" として最も適切な FreeBSD のメーリングリストを入れ、 このメーリングリストを "BCC:" に入れることが推奨されます。 このメーリングリスト上では、議論が許されていないため、 このように送信することで、 進捗状況の議論を別の適切なメーリングリストで議論できるようになります。 + どのようなメールが適切かについては、 アーカイブで確認してください。 + このメーリングリストへのメッセージの編集ダイジェスト版が、 進捗状況レポート として、数ヶ月おきに FreeBSD ウェブサイトに公開されます。 過去のレポートもアーカイブされています。 link:{freebsd-wireless-url}[freebsd-wireless]:: _802.11 スタック、 ツールおよびデバイスドライバの開発に関する議論_ + FreeBSD のワイヤレスに関するメーリングリストです。 バグ、新しい機能およびメンテナンスについての議論を含む、 802.11 スタック (sys/net80211)、 デバイスドライバおよびツールの開発に焦点が当てられています。 link:{freebsd-xen-url}[freebsd-xen]:: _FreeBSD の Xen(TM) への移植 - 実装および利用についての議論_ + このメーリングリストは、FreeBSD の Xen(TM) への移植に焦点が当てられています。 このメーリングリストのトラフィックは小さいので、 技術的な議論およびデザインの詳細と管理上の問題の両方についてのフォーラムとして期待されています。 [[eresources-mailfiltering]] === メーリングリストのフィルタリング FreeBSD のメーリングリストは、スパム、 ウィルスおよび他の不要なメールを配布してしまわないよう、 いくつかの方法でフィルタリングを行なっています。 この節で説明するフィルタリングは、 メーリングリストを守るために使われている方法のすべてというわけではありません。 メーリングリストでは、以下の添付ファイルを送ることができます。 以下の一覧以外の MIME content type の添付ファイルを含むファイルは、 メーリングリストに流れる前に取り除かれます。 * application/octet-stream * application/pdf * application/pgp-signature * application/x-pkcs7-signature * message/rfc822 * multipart/alternative * multipart/related * multipart/signed * text/html * text/plain * text/x-diff * text/x-patch [NOTE] ==== 他の MIME content type の添付を許可するメーリングリストもありますが、 上の一覧に含まれるものであれば、 ほとんどのメーリングリストで適用できます。 ==== HTML と plain テキストを両方含むメールでは、 HTML の部分が削除されます。 HTML のみを含むメールは、plain テキストに変換されます。 [[eresources-news]] == Usenet ニュースグループ 2 つの FreeBSD 用のニュースグループに加え、他にも FreeBSD の議論をしたり FreeBSD に関連するユーザがいるニュースグループがたくさんあります。 === BSD 用のニュースグループ * link:news:comp.unix.bsd.freebsd.announce[comp.unix.bsd.freebsd.announce] * link:news:comp.unix.bsd.freebsd.misc[comp.unix.bsd.freebsd.misc] * link:news:de.comp.os.unix.bsd[de.comp.os.unix.bsd] (ドイツ) * link:news:fr.comp.os.bsd[fr.comp.os.bsd] (フランス) === 関連する他の UNIX(R) のニュースグループ * link:news:comp.unix[comp.unix] * link:news:comp.unix.questions[comp.unix.questions] * link:news:comp.unix.admin[comp.unix.admin] * link:news:comp.unix.programmer[comp.unix.programmer] * link:news:comp.unix.shell[comp.unix.shell] * link:news:comp.unix.misc[comp.unix.misc] * link:news:comp.unix.bsd[comp.unix.bsd] === X Window システム * link:news:comp.windows.x[comp.windows.x] [[eresources-web]] == オフィシャルミラー <>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <>. [[central-mirrors]] *{central}* * {central-www} [[armenia-mirrors]] *{mirrors-armenia}* * {mirrors-armenia-www-httpv6} (IPv6) [[australia-mirrors]] *{mirrors-australia}* * {mirrors-australia-www-http} * {mirrors-australia-www2-http} [[austria-mirrors]] *{mirrors-austria}* * {mirrors-armenia-www-httpv6} (IPv6) [[czech-republic-mirrors]] *{mirrors-czech}* * {mirrors-czech-www-httpv6} (IPv6) [[denmark-mirrors]] *{mirrors-denmark}* * {mirrors-denmark-www-httpv6} (IPv6) [[finland-mirrors]] *{mirrors-finland}* * {mirrors-finland-www-http} [[france-mirrors]] *{mirrors-france}* * {mirrors-france-www-http} [[germany-mirrors]] *{mirrors-germany}* * {mirrors-germany-www-http} [[hong-kong-mirrors]] *{mirrors-hongkong}* * {mirrors-hongkong-www} [[ireland-mirrors]] *{mirrors-ireland}* * {mirrors-ireland-www} [[japan-mirrors]] *{mirrors-japan}* * {mirrors-japan-www-httpv6} (IPv6) [[latvia-mirrors]] *{mirrors-latvia}* * {mirrors-latvia-www} [[lithuania-mirrors]] *{mirrors-lithuania}* * {mirrors-lithuania-www} [[netherlands-mirrors]] *{mirrors-netherlands}* * {mirrors-netherlands-www} [[norway-mirrors]] *{mirrors-norway}* * {mirrors-norway-www} [[russia-mirrors]] *{mirrors-russia}* * {mirrors-russia-www-httpv6} (IPv6) [[slovenia-mirrors]] *{mirrors-slovenia}* * {mirrors-slovenia-www} [[south-africa-mirrors]] *{mirrors-south-africa}* * {mirrors-south-africa-www} [[spain-mirrors]] *{mirrors-spain}* * {mirrors-spain-www} * {mirrors-spain-www2} [[sweden-mirrors]] *{mirrors-sweden}* * {mirrors-sweden-www} [[switzerland-mirrors]] *{mirrors-switzerland}* * {mirrors-switzerland-www-httpv6} (IPv6) * {mirrors-switzerland-www2-httpv6} (IPv6) [[taiwan-mirrors]] *{mirrors-taiwan}* * {mirrors-taiwan-www} * {mirrors-taiwan-www2} * {mirrors-taiwan-www4} * {mirrors-taiwan-www5-httpv6} (IPv6) [[uk-mirrors]] *{mirrors-uk}* * {mirrors-uk-www} * {mirrors-uk-www3} [[usa-mirrors]] *{mirrors-us}* * {mirrors-us-www5-httpv6} (IPv6) :sectnums: :sectnumlevels: 6 diff --git a/documentation/content/ja/books/handbook/l10n/_index.adoc b/documentation/content/ja/books/handbook/l10n/_index.adoc index 21274c0b82..59234d7330 100644 --- a/documentation/content/ja/books/handbook/l10n/_index.adoc +++ b/documentation/content/ja/books/handbook/l10n/_index.adoc @@ -1,588 +1,588 @@ --- -title: 第16章 地域化 (localization) - i18n/L10n の利用と設定 +title: 第15章 地域化 (localization) - i18n/L10n の利用と設定 part: パートIII. システム管理 prev: books/handbook/disks next: books/handbook/cutting-edge description: FreeBSD は多くの言語への地域化に対応しており、 ユーザは、英語以外の言語を見たり、入力したり、処理したりできます。 tags: ["i18n", "L10n", "localization", "Locale", "LANG", "MM_CHARSET", "cap_mkdb"] showBookMenu: true -weight: 20 +weight: 19 path: "/books/handbook/" --- [[l10n]] = 地域化 (localization) - i18n/L10n の利用と設定 :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 -:sectnumoffset: 16 +:sectnumoffset: 15 :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/l10n/ ifdef::env-beastie[] ifdef::backend-html5[] :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [[l10n-synopsis]] == この章では FreeBSD は、 ユーザーおよび貢献者が世界中に分散したプロジェクトです。 そのため、FreeBSD は多くの言語への地域化に対応しており、 ユーザは、英語以外の言語を見たり、入力したり、処理したりできます。 中国語、ドイツ語、日本語、韓国語、フランス語、ロシア語、 ベトナム語など、主要な言語のほとんどから選ぶことができますが、 これらに限定されるわけではありません。 internationalization は、i18n と短縮して表記されます。 これは `internationalization` の最初と最後の間の文字数に由来します。 L10n も同じ命名法を用いて `localization` を縮めたものです。 i18n/L10n された (すなわち国際化/地域化された) 手法、プロトコル、アプリケーションは、 自分達の好みの言語を使うことを可能にしてくれます。 この章では、FreeBSD の国際化 (internationalization) と地域化 (localization) 機能について解説します。 この章では、以下の分野について説明します。 * ロケール名がどのように定義されるか。 * ログインシェルでロケールを設定するにはどうするか。 * コンソールを英語以外の言語用に設定するにはどうするか。 * 様々な言語で Xorg を設定するにはどうすればよいか。 * 国際化 (i18n) されたアプリケーションの見つけ方。 * 特定の言語に設定するための情報はどこにあるか。 この章を読む前に、以下のことを理解しておく必要があります。 * crossref:ports[ports,サードパーティ製アプリケーションのインストール方法] [[using-localization]] == 地域化の利用 地域化の設定は、言語コード、 国コード、エンコーディングという三つの要素を基本とします。 ロケール名はこれらから以下のように構成されます。 [.programlisting] .... 言語コード_国コード.エンコーディング .... _言語コード_ および _国コード_ は、 国と言語を特定するために用いられます。 <> では、 _言語コード___国コード_ の例を示します [[locale-lang-country]] .言語および国コード [cols="1,1", frame="none", options="header"] |=== | 言語_国コード | 説明 |en_US |英語、合衆国 |ru_RU |ロシア語、ロシア |zh_TW |繁体字中国語、台湾 |=== 利用可能なすべてのロケールを調べるには、 以下のように実行してください。 [source,shell] .... % locale -a | more .... 現在のロケールの設定を調べるには、 以下のコマンドを実行してください。 [source,shell] .... % locale .... 言語固有の、C 言語の char で表現できる ISO8859-1, ISO8859-15, KOI8-R, CP437 といったシングルバイトの文字セットについては、 man:multibyte[3] を参照してください。 現在有効な文字セットのリストは、link:http://www.iana.org/assignments/character-sets[IANA Registry] で確認できます。 いくつかの言語 (例えば中国語や日本語) は、 ASCII 文字では表すことができないので、 ワイド文字や多バイト文字を用いた拡張された言語のエンコードが必要となります。 ワイド/多バイトのエンコーディングの例は、EUC および Big5 です。 古いアプリケーションの中には、 これらのエンコードを誤ってコントロール文字として認識するものがありますが、 最近のアプリケーションは、大抵これらの文字を認識します。 実装方法にも依りますが、アプリケーションのコンパイル時もしくは configure 時に、ワイド/多バイト文字のサポートを指定する必要があるかも知れません。 [NOTE] ==== FreeBSD では、Xorg 互換のロケール符号を用いています。 ==== 以下では、FreeBSD システムにおいてロケールを設定する方法について説明します。 次の節では、i18n に対応するアプリケーションの見つけ方およびコンパイル方法について説明します。 [[setting-locale]] === ログインシェルでロケールを設定する ロケールの設定は、ユーザの [.filename]#~/.login_conf#、 またはユーザのシェルの初期設定ファイルである [.filename]#~/.profile#, [.filename]#~/.bashrc# または [.filename]#~/.cshrc# で行います。 以下の二つの環境変数を設定する必要があります。 * `LANG`: ロケールを設定します。 * `MM_CHARSET`: アプリケーションで使用される MIME 文字セットを指定します。 これらの変数は、ユーザのシェルの設定ファイルに加え、 アプリケーション固有の設定ファイル、 および Xorg の設定ファイルにおいても指定される必要があります。 必要な変数を割り当てるには、二つの方法があります。 <> において割り当てる方法 (推奨される方法です)、および <> で指定する方法です。 次の 2 つの節では、この両方の方法について説明します。 [[login-class]] ==== ログインクラスを用いる方法 最初に説明する方法は、 すべてのシェルにおいて必要なロケール名と MIME 文字セットを環境変数に割り当てます。 これは推奨される方法です。 この割り当て方法としては、各ユーザが行う方法と、 スーパーユーザがすべてのユーザに対して設定する 2 つの方法があります。 以下の簡単な例では、 各ユーザのホームディレクトリの [.filename]#.login_conf# で、両方の変数に Latin-1 エンコーディングを設定します。 [.programlisting] .... me:\ :charset=ISO-8859-1:\ :lang=de_DE.ISO8859-1: .... これは、BIG-5 エンコーディングされた繁体字中国語用の環境変数を設定するユーザの [.filename]#~/.login_conf# の一例です。 中国語、日本語、 韓国語用のロケール変数を正しく認識しないソフトウェアに対応するため、 より多くの変数に対する設定が行われています。 [.programlisting] .... #Users who do not wish to use monetary units or time formats #of Taiwan can manually change each variable me:\ :lang=zh_TW.Big5:\ :setenv=LC_ALL=zh_TW.Big5,LC_COLLATE=zh_TW.Big5,LC_CTYPE=zh_TW.Big5,LC_MESSAGES=zh_TW.Big5,LC_MONETARY=zh_TW.Big5,LC_NUMERIC=zh_TW.Big5,LC_TIME=zh_TW.Big5:\ :charset=big5:\ :xmodifiers="@im=gcin": #Set gcin as the XIM Input Server .... もう一つの方法では、 スーパーユーザがシステム上のすべてのユーザに対する地域化を設定します。 [.filename]#/etc/login.conf# の以下の変数により、ロケールおよび MIME 文字セットを設定します。 [.programlisting] .... language_name|Account Type Description:\ :charset=MIME_charset:\ :lang=locale_name:\ :tc=default: .... よって、先ほどの例における Latin-1 に対する設定は、 以下のようになります。 [.programlisting] .... german|German Users Accounts:\ :charset=ISO-8859-1:\ :lang=de_DE.ISO8859-1:\ :tc=default: .... 詳細に関しては man:login.conf[5] を参照してください。 なお、_russian_ クラスはあらかじめ定義されています。 [.filename]#/etc/login.conf# を編集したら、 忘れずに以下のコマンドを実行してケイパビリティデータベースをアップデートしてください。 [source,shell] .... # cap_mkdb /etc/login.conf .... [NOTE] ==== エンドユーザは、変更を反映させるために、各自の [.filename]#~/.login_conf# に対して `cap_mkdb` コマンドを実行する必要があります。 ==== ===== ログインクラスを変更するユーティリティ [.filename]#/etc/login.conf# を手動により編集する方法に加え、 新たに作成するユーザのロケールを設定するためのユーティリティがあります。 `vipw` を使って新しいユーザを追加する際には、使用する言語を _language_ に指定してください。 [.programlisting] .... user:password:1111:11:language:0:0:User Name:/home/user:/bin/sh .... `adduser` を使って新しいユーザを追加する場合に、 すべてのユーザに対するデフォルトの言語は事前に設定でき、 個々のユーザに対する言語を指定できます。 新しく追加するすべてのユーザが同じ言語を使う場合には、 [.filename]#/etc/adduser.conf# で `defaultclass=_language_` と設定してください。 新しいユーザを作成するときに、この設定を変更するには、 以下のプロンプトにおいて希望するロケールを指定してください。 [source,shell] .... Enter login class: default []: .... もしくは、`adduser` を実行する際にロケールを指定してください。 [source,shell] .... # adduser -class language .... `pw` を使って新しいユーザを追加する場合には、 以下のようにしてロケールを指定してください。 [source,shell] .... # pw useradd user_name -L language .... すでに存在するユーザのログインクラスを変更するには、 `chpass` を使用してください。 引数として変更するユーザ名を与えて、 スーパーユーザの権限で実行してください。 [source,shell] .... # chpass user_name .... [[startup-file]] ==== シェルの初期化ファイルによる方法 この 2 番目の方法は、 使用するシェルごとに手動での設定が必要なため、推奨されません。 シェル毎に設定ファイルが存在し、その構文はシェルに依存します。 たとえば、`sh` シェルに対するドイツ語の設定では、 そのユーザのシェルを設定するためだけに、 [.filename]#~/.profile# に以下の行を追加ます。 これらの行を [.filename]#/etc/profile# または、 [.filename]#/usr/share/skel/dot.profile# に追加すると、 すべてのユーザのシェルを設定することが可能です。 [.programlisting] .... LANG=de_DE.ISO8859-1; export LANG MM_CHARSET=ISO-8859-1; export MM_CHARSET .... しかしながら、`csh` シェルでは、 設定ファイルの名前や構文は異なります。 [.filename]#~/.login#, [.filename]#/etc/csh.login# または [.filename]#/usr/share/skel/dot.login# では同じ設定です。 [.programlisting] .... setenv LANG de_DE.ISO8859-1 setenv MM_CHARSET ISO-8859-1 .... さらに面倒なことに、 Xorg を設定するための [.filename]#~/.xinitrc# における構文は、 使用しているシェルに依存します。 以下の例において、最初は `sh` シェルに対するもので、2 番目が `csh` シェルに対するものです。 [.programlisting] .... LANG=de_DE.ISO8859-1; export LANG .... [.programlisting] .... setenv LANG de_DE.ISO8859-1 .... [[setting-console]] === コンソールの設定 コンソールで利用可能な地域化されたフォントがあります。 利用できるフォントの一覧を調べるには、 `ls /usr/share/syscons/fonts` と入力してください。 コンソールのフォントを設定するには、 [.filename]#.fnt# という拡張子を除いた _フォント名_ を、 [.filename]#/etc/rc.conf# に設定してください。 [.programlisting] .... font8x16=フォント名 font8x14=フォント名 font8x8=フォント名 .... 以下を [.filename]#/etc/rc.conf# に追加することで、 キーマップおよびスクリーンマップを指定できます。 [.programlisting] .... scrnmap=スクリーンマップ名 keymap=キーマップ名 keychange="ファンクションキー番号の並び" .... 利用可能なスクリーンマップの一覧を調べるには、 `ls /usr/share/syscons/scrnmaps` と入力してください。 [.filename]#/etc/rc.conf# で _スクリーンマップ名_ を指定する時は、 [.filename]#.csm# という拡張子を除いてください。 スクリーンフォントが bit 8 列を使っている時に文字を疑似グラフィクス領域から外に移動するように、 VGA アダプタがフォント文字マトリクスで bit 8 を bit 9 に拡張することに対処するため、 フォントに適切にマップされたスクリーンマップが必要となります。 利用可能なキーマップの一覧を調べるには、 `ls /usr/share/syscons/keymaps` と入力してください。 [.filename]#/etc/rc.conf# で _キーマップ名_ を指定する時には、 [.filename]#.kbd# という拡張子を除いてください。 再起動せずにキーマップを試すには、 man:kbdmap[1] を使ってください。 ファンクションキーの並びはキーマップで定義されていないので、 端末タイプに合わせたファンクションキーを設定するために `keychange` のエントリが必要となります。 次に [.filename]#/etc/ttys# の中のすべての仮想端末のエントリに対して、 正しいコンソール端末タイプを設定してください。<> は、 利用可能な端末タイプの一覧です。 [[locale-charset]] .文字セットに対する定義済みの端末タイプ [cols="1,1", frame="none", options="header"] |=== | 文字セット | 端末タイプ |ISO8859-1 もしくは ISO8859-15 |`cons25l1` |ISO8859-2 |`cons25l2` |ISO8859-7 |`cons25l7` |KOI8-R |`cons25r` |KOI8-U |`cons25u` |CP437 (VGA のデフォルト) |`cons25` |US-ASCII |`cons25w` |=== ワイド/多バイト文字の言語については、 その言語に対するコンソールを FreeBSD Ports Collection からインストールしてください。 利用可能な ports は、<> にまとめてあります。 インストール後、各 port の [.filename]#pkg-message# または、マニュアルページを参照して、 設定や使用方法を調べてください。 [[locale-console]] .Ports Collection で利用可能なコンソール [cols="1,1", frame="none", options="header"] |=== | 言語 | port の位置 |繁体字中国語 (BIG-5) |package:chinese/big5con[] |中国語/日本語/韓国語 |package:chinese/cce[] |中国語/日本語/韓国語 |package:chinese/zhcon[] |日本語 |package:chinese/kon2[] |日本語 |package:japanese/kon2-14dot[] |日本語 |package:japanese/kon2-16dot[] |=== [.filename]#/etc/rc.conf# において moused を有効にしている場合には、 追加の設定が必要となるでしょう。 デフォルトでは、man:syscons[4] ドライバのマウスカーソルはキャラクタセット中の `0xd0`-`0xd3` の範囲を占めています。そのため、 利用している言語がこの範囲のキャラクタセットを使っている場合、 次の行を [.filename]#/etc/rc.conf# に追加して カーソルの占める範囲を移動してください。 [.programlisting] .... mousechar_start=3 .... === Xorg の設定 Xorg のインストールおよび設定方法は、 crossref:x11[x11,X Window System] で説明されています。 Xorg を地域化するための追加のフォントおよび入力方法は、 FreeBSD Ports Collection から利用できます。 フォント、メニューなどのアプリケーション固有の国際化 (i18n) の設定は、 [.filename]#~/.Xresources# において指定でき、 グラフィカルアプリケーションのメニューが選んだ言語で表示されます。 X Input Method (XIM) プロトコルは、Xorg で非英字文字を入力するための標準規格です。 FreeBSD Ports Collection から利用可能なインプットメソッドについては、 <> にまとめられています。 追加の Fcitx および Uim アプリケーションも利用できます。 [[locale-xim]] .利用可能なインプットメソッド [cols="1,1", frame="none", options="header"] |=== | 言語 | インプットメソッド |中国語 |package:chinese/gcin[] |中国語 |package:chinese/ibus-chewing[] |中国語 |package:chinese/ibus-pinyin[] |中国語 |package:chinese/oxim[] |中国語 |package:chinese/scim-fcitx[] |中国語 |package:chinese/scim-pinyin[] |中国語 |package:chinese/scim-tables[] |日本語 |package:japanese/ibus-anthy[] |日本語 |package:japanese/ibus-mozc[] |日本語 |package:japanese/ibus-skk[] |日本語 |package:japanese/im-ja[] |日本語 |package:japanese/kinput2[] |日本語 |package:japanese/scim-anthy[] |日本語 |package:japanese/scim-canna[] |日本語 |package:japanese/scim-honoka[] |日本語 |package:japanese/scim-honoka-plugin-romkan[] |日本語 |package:japanese/scim-honoka-plugin-wnn[] |日本語 |package:japanese/scim-prime[] |日本語 |package:japanese/scim-skk[] |日本語 |package:japanese/scim-tables[] |日本語 |package:japanese/scim-tomoe[] |日本語 |package:japanese/scim-uim[] |日本語 |package:japanese/skkinput[] |日本語 |package:japanese/skkinput3[] |日本語 |package:japanese/uim-anthy[] |韓国語 |package:korean/ibus-hangul[] |韓国語 |package:korean/imhangul[] |韓国語 |package:korean/nabi[] |韓国語 |package:korean/scim-hangul[] |韓国語 |package:korean/scim-tables[] |ベトナム語 |package:vietnamese/xvnkb[] |ベトナム語 |package:vietnamese/x-unikey[] |=== [[l10n-compiling]] == 国際化 (i18n) に対応したアプリケーションを見つける 国際化 (i18n) されたアプリケーションは、ライブラリとして i18n 化キットを用いてプログラミングされます。 これは開発者が単純なファイルを書いて、 表示されるメニューやテキストを各国語に翻訳できるようにしてくれます。 link:https://www.FreeBSD.org/ja/ports/[FreeBSD Ports Collection ] の多くのアプリケーションは、 いくつかの言語向けのワイド/多バイト文字への対応を組み込んでいます。 そのようなアプリケーションの名前には、 容易に認識できるように、`-i18n` と付いています。しかしながら、 それらのアプリケーションが必要とする言語に対応しているとは限りません。 いくつかのアプリケーションでは、 特定の文字セットを使うようにコンパイルできます。 これは大抵 [.filename]#Makefile# の中で 対処されているか、configure に値を渡すことで対応しています。 必要な configure の値や port の構築時に使用するコンパイルオプションを決めるための port の [.filename]#Makefile# に関するより詳細な情報については、 各 FreeBSD port のソースにある i18n 文書を参照してください。 [[lang-setup]] == 特定の言語にロケールを設定する この節では、FreeBSD システムをロシア語へ地域化するための設定例を示します。 後半では、他の言語への地域化に関する情報を提供します。 [[ru-localize]] === ロシア語 (KOI8-R エンコーディング) この節では、FreeBSD システムをロシア語へ地域化するための設定例を示します。 各設定に関するより詳しい説明については、 <> を参照してください。 このロケールをログインシェルに設定するには、 以下の行を各ユーザの [.filename]#~/.login_conf# に追加してください。 [.programlisting] .... me:My Account:\ :charset=KOI8-R:\ :lang=ru_RU.KOI8-R: .... コンソールを設定するには、 [.filename]#/etc/rc.conf# に以下の行を追加してください。 [.programlisting] .... keymap="ru.utf-8" scrnmap="utf-82cp866" font8x16="cp866b-8x16" font8x14="cp866-8x14" font8x8="cp866-8x8" mousechar_start=3 .... [.filename]#/etc/ttys# の各 `ttyv` エントリにおいて、 端末タイプとして `cons25r` を指定してください。 プリンタの設定を行うには、 ロシア語用の文字を搭載したほとんどのプリンタはハードウェアコードページ CP866 を使っているため、KOI8-R を CP866 に変換する専用の出力フィルタが必要となります。 この目的のため、FreeBSD はデフォルトフィルタを [.filename]#/usr/libexec/lpr/ru/koi2alt# にインストールします。 このフィルタを使うには、[.filename]#/etc/printcap# に以下のエントリを追加してください。 [.programlisting] .... lp|Russian local line printer:\ :sh:of=/usr/libexec/lpr/ru/koi2alt:\ :lp=/dev/lpt0:sd=/var/spool/output/lpd:lf=/var/log/lpd-errs: .... より詳細な説明については man:printcap[5] を参照してください。 マウントされた MS-DOS(R) ファイルシステムにおいてロシア語ファイル名を使えるように設定するには、 [.filename]#/etc/fstab# にエントリを追加するときに、 以下のように `-L` とロケール名を含めてください。 [.programlisting] .... /dev/ad0s2 /dos/c msdos rw,-Lru_RU.KOI8-R 0 0 .... 詳しくは、man:mount_msdosfs[8] を参照してください。 Xorg にロシア語のフォントを設定するには、 package:x11-fonts/xorg-fonts-cyrillic[] パッケージをインストールしてください。 その後、[.filename]#/etc/X11/xorg.conf# の `"Files"` セクションを確認してください。 既存の `FontPath` エントリの_前に_以下の行を追加しなければなりません。 [.programlisting] .... FontPath "/usr/local/lib/X11/fonts/cyrillic" .... 他の Cyrillic フォントは、 Ports Collection から利用できます。 ロシア語のキーボードを使えるようにするには、 以下の行を [.filename]#xorg.conf# の `"Keyboard"` セクションに追加します。 [.programlisting] .... Option "XkbLayout" "us,ru" Option "XkbOptions" "grp:toggle" .... このファイルの中で `XkbDisable` がコメントアウトされていることを確認してください。 `grp:toggle` では kbd:[Right Alt] を使い、 `grp:ctrl_shift_toggle` では kbd:[Ctrl+Shift] を使います。 `grp:caps_toggle` では、 kbd:[CapsLock] を使います。 従来の kbd:[CapsLock] の機能は、 ラテン文字モードの時のみ kbd:[Shift+CapsLock] で使うことができます。 Xorg では、理由は不明ですが `grp:caps_toggle` は動作しません。 キーボードに "Windows(R)" キーがあり、 そのキーにいくつかの非英字キーが割り当てられているようなら、 [.filename]#xorg.conf# に以下の行を追加してください。 [.programlisting] .... Option "XkbVariant" ",winkeys" .... [NOTE] ==== ロシア語の XKB キーボードは、 地域化されていないアプリケーションではうまく動かないかも知れません。 地域化されたアプリケーションは少なくともプログラムの最初の方で `XtSetLanguageProc (NULL, NULL, NULL);` を呼び出すべきです。 ==== Xorg アプリケーションを地域化する方法については、link:http://koi8.pp.ru/xwin.html[http://koi8.pp.ru/xwin.html] を参照してください。 KOI8-R エンコーディングの詳細については、link:http://koi8.pp.ru/[http://koi8.pp.ru/] を参照してください。 === 言語固有のリソース この節では、 他言語へのロケールの設定に関するリソースの一覧を示します。 台湾向けの繁体字中国語への地域化:: FreeBSD-Taiwan プロジェクトは、 FreeBSD を中国語化するための手引き link:http://netlab.cse.yzu.edu.tw/\~statue/freebsd/zh-tut/[http://netlab.cse.yzu.edu.tw/~statue/freebsd/zh-tut/] を提供しています。 ギリシャ語への地域化:: FreeBSD におけるギリシャ語のサポートについての記事は、 公式の FreeBSD ギリシャ語ドキュメンテーションの一部として link:https://docs.FreeBSD.org/el/articles/greek-language-support/[ここ] で読むことができます。 この文書は、ギリシャ語で書かれています。 日本語/韓国語への地域化:: 日本語に関しては link:http://www.jp.FreeBSD.org/[http://www.jp.FreeBSD.org/] を、韓国語に関しては link:http://www.kr.FreeBSD.org/[http://www.kr.FreeBSD.org/] を参照してください。 英語以外の FreeBSD ドキュメント:: FreeBSD の文書の一部を他の言語に翻訳してくれている貢献者たちがいます。 これらは link:https://www.FreeBSD.org/ja/[FreeBSD ウェブサイト] のリンクを辿るか [.filename]#/usr/share/doc# から入手できます。 diff --git a/documentation/content/ja/books/handbook/mail/_index.adoc b/documentation/content/ja/books/handbook/mail/_index.adoc index cec908a3c6..7de83ca260 100644 --- a/documentation/content/ja/books/handbook/mail/_index.adoc +++ b/documentation/content/ja/books/handbook/mail/_index.adoc @@ -1,811 +1,811 @@ --- -title: 第20章 電子メール +title: 第19章 電子メール part: パートIV. ネットワーク通信 prev: books/handbook/ppp-and-slip next: books/handbook/advanced-networking showBookMenu: true -weight: 25 +weight: 24 path: "/books/handbook/" --- [[mail]] = 電子メール :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 -:sectnumoffset: 20 +:sectnumoffset: 19 :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/mail/ ifdef::env-beastie[] ifdef::backend-html5[] :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [[mail-synopsis]] == この章では "電子メール"、email としてのほうが知られているでしょう、 は現代で最も広く利用されているコミュニケーション手段の一つです。 この章では FreeBSD 上でメールサーバを実行するための基本的な導入を説明します。 しかし、この文書は完璧な参考文献ではなく、 実際のところ考慮すべき重要な点の多くが省略されています。 この件について、より網羅したものについては crossref:bibliography[bibliography,参考図書] に掲載されている多くの優れた書籍を参照してください。 この章では、以下の分野について説明します。 * 電子メールの送受信に関係しているソフトウェアの構成要素 * FreeBSD における sendmail の基本的な設定ファイルのある場所 * スパマーがあなたのメールサーバを踏台として不正に使用することを防ぐ方法 * あなたのシステムに sendmail の置き換えとなる代替の MTA をインストールして設定する方法 * メールサーバにまつわる共通の問題の解決法 * UUCP とともに SMTP を使う方法 * ダイアルアップ接続でメールを使う方法 * セキュリティを向上するために SMTP 認証を設定する方法 この章を読む前に、以下のことを理解しておく必要があります。 * ネットワーク接続の適切な設定方法 (crossref:advanced-networking[advanced-networking,高度なネットワーク]) * あなたのメールホストに対する DNS 情報の適切な設定方法 (crossref:advanced-networking[advanced-networking,高度なネットワーク]) * サードパーティ製ソフトウェアのインストール方法 (crossref:ports[ports,アプリケーションのインストール - packages と ports]) [[mail-using]] == 電子メールを使う email の交換には 5 つの主要な部分があります。 それらは <>、 <>、 <>、 <>、 そしてもちろん <>です。 [[mail-mua]] === ユーザープログラム いくつか名前を挙げれば、 mutt, pine, elm そして mail といったコマンドラインプログラムや balsa, xfmail のような GUI プログラム、WWW ブラウザーのようにさらに "洗練された" ものまであります。 これらのプログラムは、email の処理を <> を呼び出したり TCP 経由で渡したり、といった手段でローカルの <> に任せるだけです。 [[mail-mta]] === メールホストサーバデーモン 通常、これは sendmail (FreeBSD のデフォルト) や qmail, postfix もしくは exim といった他のメールサーバーデーモンの一つです。 他にもあるのですが、以上のものが広く使われています。 サーバーデーモンは通常 2 つの機能 - やってくるメールを受け取るのと出ていくメールを配送する、 を持っています。メールを読むために POP や IMAP で接続する、 ということはできません。 そのためにはもう一つ<>が必要なのです。 いくつかの古いバージョンの sendmail には深刻なセキュリティ問題がありますが、 現在のバージョンを使っていれば特に問題ないことに注意してください。 例のごとく、 どんなソフトウェアを利用する時にも最新の状態にしておくのが大事なのです。 [[mail-dns]] === Email と DNS Domain Name System (DNS) とそのデーモンである `named` は email の配送において大変重要な役割を担ってます。 あなたのサイトからもう一つのサイトへメールを配送するためには、 サーバーデーモンは DNS からそのサイトを探し、 メールの受け取り先のホストを決定します。 メールがあなたに送られた場合にも同じような仕組みになっています。 DNS にはホスト名と IP アドレス、ホスト名とメールホストをマッピングするデータベースがあります。 IP アドレスは A レコードで指定されます。 MX (Mail eXchanger) レコードはあなた宛のメールを受け取るホストを指定します。 あなたのホスト名に対する MX レコードがない場合には、 メールは直接あなたのホストに配送されます。 [[mail-receive]] === メールの受け取り メールはメールホストが受け取ります。 このホストは送られてきたメールを集め、 (ユーザーが) 読んだりピックアップしたりするために保存します。 保存されているメールをピックアップするにはメールホストに接続する必要があります。 これは POP や IMAP を用いて行なわれます。 メールホスト上で直接メールを読みたい時は POP や IMAP のサーバーは必要ありません。 POP や IMAP のサーバーを走らせるためには 2 つのことをやらなければいけません。 [.procedure] ==== . POP や IMAP のデーモンを link:https://www.FreeBSD.org/ports/[ports コレクション] からインストールします。 . [.filename]#/etc/inetd.conf# を修正して POP や IMAP のサーバーが起動されるように設定します。 ==== [[mail-host]] === メールホスト メールホストとは責任をもってメールを配送したり、 あなたのホストや、もしかするネットワークも、に宛てたメールを受け取ったりするホストに与えられる名前です。 [[sendmail]] == sendmail の設定 man:sendmail[8] は FreeBSD のデフォルトの メールトランスファエージェント (MTA) です。 sendmail の仕事はメールユーザエージェント (MUA) からのメールを受け取り、 それを設定ファイルで定義された適当なメーラに届けることです。 sendmail はネットワーク接続を受け入れて、 ローカルのメールボックスにメールを届けたり 別のプログラムにメールを渡したりもできます。 sendmail は次の設定ファイルを使用します。 [.informaltable] [cols="1,1", options="header"] |=== | ファイル名 | 機能 |[.filename]#/etc/mail/access# |sendmail アクセスデータベースファイル |[.filename]#/etc/mail/aliases# |メールボックスエイリアス |[.filename]#/etc/mail/local-host-names# |sendmail が受け付ける配送先ホストのリスト |[.filename]#/etc/mail/mailer.conf# |メーラプログラムの設定 |[.filename]#/etc/mail/mailertable# |メーラ配送表 |[.filename]#/etc/mail/sendmail.cf# |sendmail の主設定ファイル |[.filename]#/etc/mail/virtusertable# |仮想ユーザおよび仮想ドメイン表 |=== === [.filename]#/etc/mail/access# アクセスデータベースは、 どのホストまたは IP アドレスがローカルメールサーバに接続できるか、 そして接続の種類は何か、ということを定義します。 ホストは `OK`, `REJECT`, `RELAY` として指定できます。 または、メーラエラーを指定することで、 単に sendmail の エラー処理ルーチンに渡されます。 `OK` として指定されたホスト (これはデフォルトです) は、 メールの最終宛先がローカルマシンである限り、 このホストへメールを送ることを認められます。 `REJECT` として指定されたホストは、 すべてのメール接続を拒絶されます。 ホスト名に対して `RELAY` オプションを指定されたホストは、 このメールサーバを通過して任意の宛先へメールを送ることを認められます。 .sendmail アクセスデータベースの設定 [example] ==== [.programlisting] .... cyberspammer.com 550 We don't accept mail from spammers FREE.STEALTH.MAILER@ 550 We don't accept mail from spammers another.source.of.spam REJECT okay.cyberspammer.com OK 128.32 RELAY .... ==== この例では五つのエントリがあります。 表の左側に当てはまるメール送信者は、表の右側の動作に支配されます。 はじめの二つの例は、エラーコードを sendmail のエラー処理ルーチンに渡します。 メールが表の左側に当てはまると、リモートホストにそのメッセージが表示されます。 次のエントリは `another.source.of.spam` というインターネット上の特定のホストからのメールを拒絶します。 次のエントリは `okay.cyberspammer.com` からのメール接続を受け入れます。 このエントリは上にある `cyberspammer.com` という行よりもさらに厳密です (厳密に一致すればするほど、そうでないものより優先されます)。 最後のエントリは `128.32` から始まる IP アドレスのホストからの電子メールのリレーを認めます。 これらのホストは他のメールサーバに到達できるこのメールサーバを使ってメールを送ることができるでしょう。 このファイルを変更したら、 データベースを更新するために [.filename]##/etc/mail/## ディレクトリで `make` コマンドを実行する必要があります。 === [.filename]#/etc/mail/aliases# エイリアスデータベースには、 他のユーザ、ファイル、プログラムまたは他のエイリアスに展開される 仮想的なメールボックスの一覧が記載されています。 [.filename]#/etc/mail/aliases# において使用できる例をいくつかあげます。 .メールエイリアス [example] ==== [.programlisting] .... root: localuser ftp-bugs: joe,eric,paul bit.bucket: /dev/null procmail: "|/usr/local/bin/procmail" .... ==== ファイル形式はシンプルです。 コロンの左側にあるメールボックス名は、右側のターゲットに展開されます。 はじめの例は単純に `root` のメールボックスを `localuser` のメールボックスに展開し、 それからエイリアスデータベースをもう一度調べます。 一致するエントリがなければメッセージはローカルユーザである `localuser` に配送されます。 次の例はメールリストです。 `ftp-bugs` のメールボックスへのメールは `joe`, `eric` および `paul` の三つのローカルメールボックスに展開されます。 リモートメールボックスは `user@example.com` のように指定できることに注意してください。 次の例はメールをファイル、この場合 [.filename]#/dev/null# に書き込みます。 最後の例はメールをプログラムに送ります。 この場合メールのメッセージは UNIX(R) パイプを通じて [.filename]#/usr/local/bin/procmail# の標準入力に書き込まれます。 このファイルを変更したら、 データベースを更新するために[.filename]##/etc/mail/## ディレクトリで `make` コマンドを実行する必要があります。 === [.filename]#/etc/mail/local-host-names# これは man:sendmail[8] がローカルホスト名として認めるホスト名のリストです。 sendmail がメールを受け取るすべてのドメインやホストにこのファイルを置いてください。 たとえば、このメールサーバは `example.com` というドメインおよび `mail.example.com` というホストへのメールを受け取るとすると、 [.filename]#local-host-names# ファイルの内容は次のようになるでしょう。 [.programlisting] .... example.com mail.example.com .... このファイルを更新したら、変更を読み込むために man:sendmail[8] を再起動する必要があります。 === [.filename]#/etc/mail/sendmail.cf# sendmail の主設定ファイルである [.filename]#sendmail.cf# は、電子メールアドレスの書き換えから、 リモートメールサーバへ拒絶メッセージを送ることまで sendmail の全般的な動作をすべて制御します。 当然、そのようなさまざまな役割によりこの設定ファイルは大変複雑で、 その詳細についてはこの節の少し範囲外です。好運なことに、 標準的な構成のメールサーバではこのファイルをめったに変更する必要はありません。 sendmail の主設定ファイルは sendmail の機能と動作を決定する man:m4[1] マクロから構築できます。 詳細については [.filename]#/usr/src/contrib/sendmail/cf/README# を参照してください。 このファイルを更新したら、その変更を反映するために sendmail を再起動する必要があります。 === [.filename]#/etc/mail/virtusertable# [.filename]#virtusertable# は仮想ドメインおよび仮想メールボックスに対するアドレスを実際のメールボックスと対応づけます。 これらのメールボックスにはローカル、リモート、 [.filename]#/etc/mail/aliases# に定義されたエイリアス、 またはファイルを使用できます。 .仮想ドメインメール対応表の例 [example] ==== [.programlisting] .... root@example.com root postmaster@example.com postmaster@noc.example.net @example.com joe .... ==== 上の例では `example.com` ドメインへの対応づけをしています。 このファイルはファイルの下までファーストマッチ (訳注: 一致するルールが複数ある場合、 一番最初に一致したルールが適用されること) で処理されます。 はじめの行では `root@example.com` を ローカルの `root` メールボックスに対応づけています。 次のエントリでは `postmaster@example.com` を `noc.example.net` ホスト上の `postmaster` メールボックスに対応づけています。 最後に、今までのところでは `example.com` に関して何も一致しない場合、最後のエントリと一致するでしょう。 これは `example.com` の誰かに送ったすべてのメールが一致します。これは `joe` のローカルメールボックスに対応づけられています。 [[mail-changingmta]] == MTA の変更 すでに述べたように、FreeBSD には MTA (Mail Transfer Agent) として、 sendmail がすでにインストールされています。 したがって、デフォルトではこれがメールの送受信を担当しています。 しかしながら、さまざまな理由によって、 システムの MTA を変更しようと考えるシステム管理者もいるかもしれません。 その理由は、単に他の MTA を試してみたいというものから 他のメーラに依存する特定の機能やパッケージが必要だといったものまで、 多岐にわたることでしょう。 幸い、理由がどんなものであれ、FreeBSD では簡単に変更できます。 === 新しい MTA のインストール さまざまな MTA が利用できます。 crossref:ports[ports,FreeBSD Ports Collection] から探しはじめるのがよいでしょう。 もちろん、どんな場所からでも、あなたが利用したい MTA が FreeBSD で動作する限りすべて自由に使えます。 新しい MTA をインストールすることからはじめましょう。 新しい MTA をインストールすると、 あなたの要求が実際に実現したかどうか決める機会が与えられます。さらに、 サービスを sendmail から引き継ぐ前に 新しいソフトウェアを設定する機会が与えられます。これを行う場合、 新しいソフトウェアが [.filename]#/usr/bin/sendmail# のようなシステムバイナリを上書きしようとしないことを確認してください。 そうしないとあなたが設定する前に新しいメールソフトウェアが本格的に動作しはじめてしまいます。 あなたが選択したソフトウェアを設定する方法についての情報は、 その MTA の文書を参照してください。 === sendmail を無効にする sendmail を起動するために使用されていた手続きは、 4.5-RELEASE と 4.6-RELEASE の間で著しく変更されました。 したがって、それを無効にするための手続きは微妙に違います。 ==== 2002 年 4 月 4 日より前の FreeBSD 4.5-STABLE (4.5-RELEASE とそれ以前のバージョンが該当) [.filename]#/etc/rc.conf# に次の行を加えてください。 [.programlisting] .... sendmail_enable="NO" .... これは sendmail のメール受信機能を無効にします。 しかし [.filename]#/etc/mail/mailer.conf# (下記参照) が変更されていなければ、sendmail はメールの送信にまだ使われるでしょう。 ==== 2002 年 4 月 4 日以降の FreeBSD 4.5-STABLE (4.6-RELEASE とそれ以降のバージョンが該当) sendmail を完全に無効にするためには [.filename]#/etc/rc.conf# に次の行を加えなくてはいけません。 [.programlisting] .... sendmail_enable="NONE" .... [WARNING] ==== もしこの方法で sendmail のメール送信機能を無効にしたのなら、 完全に動作する代替メール配送システムと置き換えることが重要です。 さもなければ、man:periodic[8] などのシステム機能は、 それらの結果を通常想定しているようにメールで配送することができなくなるでしょう。 システムの多くの部分が sendmail 互換のシステムがあることを想定しているかもしれません。 もしそれらを無効にした後に、 アプリケーションがメールを送ろうとするために sendmail のバイナリを使用し続ければ、 メールは使われていない sendmail のキューに入り、そして決して配送されないでしょう。 ==== もし sendmail のメール受信機能だけを無効にしたいのなら [.filename]#/etc/rc.conf# に以下の行を追加してください。 [.programlisting] .... sendmail_enable="NO" .... sendmailの起動オプションに関する詳細は man:rc.sendmail[8] マニュアルをご覧ください。 === 起動時に新しい MTA を起動する 起動時に新しい MTA を起動するには二つの選択肢があります。 ここでも、あなたが稼働させている FreeBSD のバージョンに依存します ==== 2002 年 4 月 11 日より前の FreeBSD 4.5-STABLE (4.5-RELEASE とそれ以前のバージョンが該当) [.filename]#/usr/local/etc/rc.d/# ディレクトリに、 ファイル名が [.filename]#.sh# でおわり、 `root` によって実行可能なスクリプトを追加します。 このスクリプトは `start` および `stop` パラメータを引数として受け付けるようにします。 起動時にシステムスクリプトは次のコマンドを実行するでしょう。 [.programlisting] .... /usr/local/etc/rc.d/supermailer.sh start .... これは手動でサーバを起動するためにも使用できます。 システム終了時にはシステムスクリプトは `stop` オプションを使用して、次のコマンドを実行するでしょう。 [.programlisting] .... /usr/local/etc/rc.d/supermailer.sh stop .... これはシステムが稼働している間に手動でサーバを停止するためにも使えます。 ==== 2002 年 4 月 11 日以降の FreeBSD 4.5-STABLE (4.6-RELEASE とそれ以降のバージョンが該当) より新しいバージョンの FreeBSD では、 上記の方法または次の行を [.filename]#/etc/rc.conf# に設定できます。 [.programlisting] .... mta_start_script="filename" .... _filename_ は、あなたが MTA を立ち上げるために起動時に実行するスクリプト名です。 === システムのデフォルトメーラとして sendmail を置き換える sendmail プログラムは UNIX(R) システム上の標準ソフトウェアとして本当にどこでも利用できるので、 これがすでにインストールおよび設定されているとみなしている ソフトウェアもあるかもしれません。 この理由により、代替となる MTA の多くは sendmail コマンドラインインタフェースと 互換性のある実装を提供しています。 これを "差し込む" ことによって、 sendmail の置き換えとして代替 MTA を使用することが容易になります。 したがって、あなたが互換メーラを使用しているときには、 [.filename]#/usr/bin/sendmail# のような標準 sendmail バイナリを実行しようとするソフトウェアが、 実際にはその代わりにあなたの選択したメーラを実行しているということを 確かめる必要があるでしょう。 好運なことに、FreeBSD はこの仕事をする man:mailwrapper[8] と呼ばれるシステムを提供しています。 インストールされたまま sendmail が稼働しているときには [.filename]#/etc/mail/mailer.conf# には以下のような記述があるでしょう。 [.programlisting] .... sendmail /usr/libexec/sendmail/sendmail send-mail /usr/libexec/sendmail/sendmail mailq /usr/libexec/sendmail/sendmail newaliases /usr/libexec/sendmail/sendmail hoststat /usr/libexec/sendmail/sendmail purgestat /usr/libexec/sendmail/sendmail .... このことは、これらのうちどの共通コマンド ([.filename]#sendmail# 自身のような) が実行されても、 システムは [.filename]#mailer.conf# を確認して、 代わりに [.filename]#/usr/libexec/sendmail/sendmail# を実行する [.filename]#sendmail# という名前の mailwapper のコピーを呼び出すことを意味します。 このようなシステムでは、デフォルトの [.filename]#sendmail# が呼び出されたときに、 どのバイナリが実際に実行されるかを変更するのが簡単になります。 したがって、sendmail の代わりに [.filename]#/usr/local/supermailer/bin/sendmail-compat# を実行させたいのなら、次のように [.filename]#/etc/mail/mailer.conf# を変更してください。 [.programlisting] .... sendmail /usr/local/supermailer/bin/sendmail-compat send-mail /usr/local/supermailer/bin/sendmail-compat mailq /usr/local/supermailer/bin/mailq-compat newaliases /usr/local/supermailer/bin/newaliases-compat hoststat /usr/local/supermailer/bin/hoststat-compat purgestat /usr/local/supermailer/bin/purgestat-compat .... === 完了 あなたのやりたいようにすべてを設定しおえたら、 もはや必要のない sendmail のプロセスを終了して新しいソフトウェアに関するプロセスを起動するか、 単に再起動してください。 再起動することによって、新しい MTA が起動時に正しく立ち上がるように システムが設定されているかどうか確認することもできるでしょう。 [[mail-trouble]] == トラブルシュート === どうして自分のサイトのホストなのに FQDN を使わなければいけないのですか? 恐らく、そのホストは実際には別のドメインにあるのでしょう。 例えば `foo.bar.edu` ドメインにいて、 `bar.edu` というドメイン内の `mumble` というホストにアクセスしたいとします。 この時は単に `mumble` ではなく `mumble.bar.edu` と FQDN で参照しなければなりません。 そもそも、BSD BIND のリゾルバー (resolver) ではこのようなことが可能でしたが、 FreeBSD に入っている最新版の BIND では自分のドメイン以外に対する FQDN でない省略形は許されません。 従ってホストを `mumble` と曖昧に指定した場合は `mumble.foo.bar.edu` という名前があればそれになり、 そうでなければ root ドメインから検索されます。 これは、 `mumble.bar.edu` と `mumble.edu` ということなったドメイン名に対してホスト名のサーチがおこなわれていた以前の振る舞いとは異なったものです。 このような事が悪い例もしくはセキュリティホールとみなされる理由については RFC 1535 を見てください。 [.filename]#/etc/resolv.conf# で [.programlisting] .... domain foo.bar.edu .... と書いてある行を [.programlisting] .... search foo.bar.edu bar.edu .... と書き換えることで上のようなことができます。 しかし、RFC 1535 にあるように検索順序が "内部 (local) と外部 (public) の管理の境界" をまたがないようにしてください。 === sendmail が mail loops back to myself というメッセージを出すのですが。 sendmail FAQ に次のように書いてあります。 [.programlisting] .... Local configuration error というメッセージが出ます。例えば、 553 relay.domain.net config error: mail loops back to myself 554 ... Local configuration error のような感じですが、どうしたら解決できますか? これは、例えば domain.net のようなドメイン宛てのメールを MX レコードで特定のホスト(ここでは relay.domain.net) に送ろうとしたのに、 そのホストでは domain.net 宛てのメールを受け取れるような設定になっていない場合です。 設定の際に FEATURE(use_cw_file) を指定してある場合には /etc/mail/local-host-names の中に domain.net を追加してください。 もしくは、/etc/mail/sendmail.cf の中に Cw domain.net を追加してください。 .... sendmail FAQ は http://www.sendmail.org/faq[http://www.sendmail.org/faq] にありますので、 メールの設定に "おかしなこと" があれば常に読んでください。 === ダイアルアップ PPPPPP ホストでメールサーバを実行するにはどうしたらいいの? LAN 上にある FreeBSD マシンを、 インターネットに接続したいとします。FreeBSD マシンは、その LAN でのメールゲートウェイになります。FreeBSD マシンは専用線接続ではありません (訳注: ダイアルアップ接続など)。 これには、少なくとも二つの方法があります。 一つは UUCP を使うことです。 もう一つの方法は、あなたのドメインに対するセカンダリ MX サービスを提供する常時稼働のインターネットサーバを用意することです。 たとえば、あなたの会社のドメインが `example.com` で、 ISP があなたのドメインに セカンダリ MX サービスを提供するために `example.net` ドメインを 用意するとしたら次のようにします。 [.programlisting] .... example.com. MX 10 example.com. MX 20 example.net. .... 最終的なメール受信先としては、 一つのホストだけが定義されるべきです (`example.com` 上の [.filename]#/etc/mail/sendmail.cf# ファイルに、 `Cw example.com` を追加します)。 送信側の `sendmail` が、 メールを配送しようとしている時、モデムの接続を介してあなたのところ (`example.com`) に接続しようとします。大抵の場合、 あなたのマシンがオンラインでないために、 接続はタイムアウトしてしまうでしょう。 `sendmail` プログラムは自動的に、 たとえばあなたのインターネットプロバイダなどのセカンダリの MX サイト (`example.net`) にメールを配送するでしょう。 セカンダリ MX サイトは定期的にあなたのホストに接続し、 プライマリ MX ホスト (`example.com`) にメールを配送しようとするでしょう。 ログインスクリプトとして、 このようなものを使うとよいでしょう。 [.programlisting] .... #!/bin/sh # Put me in /usr/local/bin/pppmyisp ( sleep 60 ; /usr/sbin/sendmail -q ) & /usr/sbin/ppp -direct pppmyisp .... ユーザごとにログインスクリプトを作りたい場合には、 上記のスクリプトの代わりに、 `sendmail -qRexample.com` を使用することもできます。 このようにすると、 キューの中の `example.com` に対するすべてのメールは、すぐに強制的に処理されます。 さらに、次のような改良もできます。 以下は、link:{freebsd-isp} から抜粋してきたメッセージです。 [.programlisting] .... > 私たちはお客様に対して、セカンダリ MX を提供しています。 > お客様は一日に何回か私たちのサービスに接続し、メールを彼らのプライマリ MX > に受け取ります (彼らのドメインに対するメールが到着した時には、 > 私たちは彼らのサイトを呼び出しません)。 > 私たちの sendmail は、30 分ごとにメールキューに溜っているメールを配送します。 > ちょうどその時に、すべてのメールがプライマリ MX に送られたかどうかを確かめるためには、 > 彼らは 30 分は オンラインでいなければなりません。 > > すべてのメールを今すぐ送るために sendmail を初期化するコマンドはあるでしょうか? > もちろん私たちのマシン上には、ユーザはルート (root) 権限を持っていません。 sendmail.cf の privacy flags セクションに、 Opgoaway,restrictqrun の定義があります。 root 以外のユーザがキューを処理できるようにするには、 restrictqrun を削除してください。また、MX の再調整が必要かもしれません。 あなたがたは、顧客のサイトに対する一番優先度の高い MX なので、 次のように定義します。 # If we are the best MX for a host, try directly instead of generating # local config error. OwTrue このようにすると、リモートサイトからのメールが、 顧客のマシンと接続しようとせず、直接あなたがたのホストマシンに配送されるようになります。 ホストマシンに配送されたメールは、続いて顧客のマシンに送られます。 これはホスト名にのみ有効なので、顧客のメールマシンに、 host.customer.com とは別に、customer.com も定義する必要があります。 DNS 上で、customer.com に対する A レコードを定義してください。 .... === なぜ他のホストにメールを送ろうとすると、いつも Relaying Denied と怒られてしまうの ? FreeBSD がインストールされたデフォルトの状態では、 sendmail は動作しているホストからのメールだけを送るように設定されています。 たとえば POP3 サーバがインストールされているとすると、 ユーザは学校や職場など他のリモートの場所からメールを確認することが できます。しかし、彼らは外部からそのホスト以外へのメールを 送ることはやはりできません。 通常、メールを送ろうとしてから少しすると、 `5.7 Relaying Denied` というエラーメッセージの書かれたメールが MAILER-DAEMON から送られてくるでしょう。 これを解決する方法はいくつかあります。 一番の正攻法は [.filename]#/etc/mail/relay-domains# リレードメインファイルにあなたの ISP のアドレスを書くことです。 これをするのに簡単な方法は次のとおりです。 [source,shell] .... # echo "your.isp.example.com" > /etc/mail/relay-domains .... このファイルを作成または編集したら、 sendmail を再起動してください。 もしあなたがサーバ管理者でメールをローカルに送りたくないか、 ポイントを使用して他のマシン (や、さらに他の ISP) の クライアントまたはシステムへ送りたい時は、とても効果があります。 さらに、あなたが一つあるいは二つだけのメールアカウントを 設定している場合でもこれは非常に有用です。 追加すべきアドレスがたくさんある場合には、 単にこのファイルをあなたの好きなテキストエディタで開いて、 そして一行に一つずつドメインを追加してください。 [.programlisting] .... your.isp.example.com other.isp.example.net users-isp.example.org www.example.org .... これで、リストに掲載されているすべてのホスト (ユーザがあなたのシステムにアカウントを持っていると規定する) からあなたのシステムを通るすべてのメールは送信に成功するでしょう。 これはあなたのシステムから SPAM を送ることを認めることなく、 リモートであなたのシステムからメールを送ることをユーザに 認めるためのとてもよい方法です。 [[mail-advanced]] == 先進的なトピックス これからのセクションでは、 メールの設定やドメイン全体のためのメールの設定といったさらに突込んだ話題について触れます。 [[mail-config]] === 基本事項 あなたのマシンに FreeBSD を普通にインストールして、 [.filename]#/etc/resolv.conf# ファイルを設定するか、 またはネームサーバを走らせれば、 他のホストへ電子メールを送ることができるようになります。 あなたのホスト宛のメールをあなた自身の FreeBSD ホスト上の MTA (たとえば sendmail) に配送するようにしたい場合には、次の二つの方法があります。 * 自身でネームサーバーを実行し、 自分のドメインを持つ。例えば `FreeBSD.org`。 * あなたのホストへ直接メールが配送されるようにする。 これはメールがあなたのマシンの現在の DNS 名に直接配送されるようにすることにより実現できます。 たとえば `example.FreeBSD.org`。 上のどちらを選ぶ場合でも、自分のホストに直接メールが配送されるようにするには恒久的で 静的 な IP アドレス (ほとんどの PPP ダイアルアップ設定で用いられる動的なアドレスではなく) を持っていなければなりません。 もしファイアウォールの中にいるならば、 SMTP トラフィックが通過してくれないといけません。 もし自分のホストでメールを直接受け取りたいならば、 次の二つのうちのどちらかができていることを確認してください。 * 自分のドメインでの (一番値の小さい) MX レコードが自分のホストの IP アドレスを差していることを確認する。 * 自分のドメインの中に自分のホスト用の MX エントリがないことを確認する。 上のどちらかが設定されていれば、 自分のホストでメールを受け取ることができるでしょう。 次のコマンドを実行してみてください。 [source,shell] .... # hostname example.FreeBSD.org # host example.FreeBSD.org example.FreeBSD.org has address 204.216.27.XX .... もしあなたのマシンが上記のメッセージだけを出力したならば、 mailto:yourlogin@example.FreeBSD.org[yourlogin@example.FreeBSD.org] へのメールは問題なく配送されるでしょう (sendmail が `example.FreeBSD.org` 上で正しく動作していると仮定します)。 上記のメッセージの代わりに、 [source,shell] .... # host example.FreeBSD.org example.FreeBSD.org has address 204.216.27.XX example.FreeBSD.org mail is handled (pri=10) by hub.FreeBSD.org .... というメッセージが出力された場合は、 あなたのホスト (`example.FreeBSD.org`) に宛てたメールは全て直接配送されずに `hub` 上の同じユーザー名に配送されます。 上の情報は DNS サーバーが扱います。 メールルーティング情報をもつ DNS レコードは、 __M__ail e__X__change エントリーです。 MX エントリが存在しない場合には、IP アドレスにしたがって、 直接宛先ホストに配送されます。 `freefall.FreeBSD.org` の現時点での MX エントリは、次のようになっています。 [.programlisting] .... freefall MX 30 mail.crl.net freefall MX 40 agora.rdrop.com freefall MX 10 freefall.FreeBSD.org freefall MX 20 who.cdrom.com .... `freefall` は多くの MX エントリを持っています。 一番 MX の値の小さいホストが利用可能な場合は直接メールを受け取ります。 もしなにかの理由でアクセスができない時には、 他のホスト (ときどき "バックアップ MX" と呼ばれます) が一時的にメールを受け取ります。そして、 より値の小さいホストが利用可能になったときにメールを渡し、 最終的に一番値の小さいホストに渡ります。 使い勝手をよくするためには、代替の MX サイトは、それぞれ 別の経路でインターネットへ接続しているとよいでしょう。 インターネットプロバイダまたは他の関連サイトが、このサービスを 提供することができます。 [[mail-domain]] === あなたのドメインに対するメール設定 "メールホスト" (メールサーバーとしても知られています) をセットアップするためには、 いろいろなワークステーションに宛てた全てのメールを受ける必要があります。 基本的には、あなたのドメイン内 (この場合だと `*.FreeBSD.org`) のすべてのホスト名宛てのすべてのメールを "受け取って"、 そのメールをあなたのメールサーバーに配送し、 ユーザーがマスタメールサーバ上でメールをチェックできるようにします。 話を簡単にするために、あるユーザーのアカウントはどのマシンでも同じ__ユーザー名__にすべきです。 そのためには man:adduser[8] を使ってください。 使用する予定のメールホストは、 各ワークステーションごとにメール交換が できるように設定されていなければなりません。 これは DNS の設定で次のように行なうことができます。 [.programlisting] .... example.FreeBSD.org A 204.216.27.XX ; ワークステーション MX 10 hub.FreeBSD.org ; メールホスト .... これは、ワークステーションの A レコードがどこを指していようとも そのワークステーション宛てのメールをメールホストに転送する、というものです。 自前で DNS サーバを運用しているのでなければ、 この作業は自分では行えません。自分で DNS サーバを運用しないとかできないという場合は、 あなたの DNS を提供しているインターネットプロバイダなどに依頼して 作業を行ってもらってください。 もしバーチャル電子メールホストを運用するなら次の情報が役に立つでしょう。 例として、あなたには自分のドメイン、ここでは `customer1.org`、 を持っている顧客がいるとしましょう。 あなたは `customer1.org` 宛ての全てのメールを `mail.myhost.com` というメールホストに集めたいとします。 DNS エントリーは次のようになるでしょう。 [.programlisting] .... customer1.org MX 10 mail.myhost.com .... `customer1.org` に対して電子メールを送りたいだけなら、 A レコードは必要__ありません__。 [NOTE] ==== `customer1.org` に対して ping を実行しても、 A レコードが存在しない限りうまくいかないことに留意しておいてください。 ==== やらなければいけない最後のことは、 メールホスト上の sendmail に対してどんなドメインやホスト宛のメールを受け取るのか、 を教えることです。いくつかの方法がありますが次のどちらかでいいでしょう。 * `FEATURE(use_cw_file)` を使っているなら、 [.filename]#/etc/mail/local-host-names# ファイルにホストを加えます。 もし sendmail のバージョンが 8.10 より前であれば該当ファイルは [.filename]#/etc/sendmail.cw# です。 * [.filename]#/etc/sendmail.cf# もしくは sendmail 8.10 以降なら [.filename]#/etc/mail/sendmail.cf# といったファイルに `Cwyour.host.com` という行を加えます。 [[SMTP-UUCP]] == UUCP とともに SMTP を使う FreeBSD とともに出荷されている sendmail の設定は、 サイトがインターネットに直接接続しているものとして設計されています。 UUCP 経由でメールを交換したいサイトは、 他の sendmail 設定ファイルをインストールしなければいけません。 [.filename]#/etc/mail/sendmail.cf# を手動で調整することは先進的なトピックです。 sendmail のバージョン 8 は設定ファイルを man:m4[1] プリプロセッサから生成します。 これにより、高度に抽象化された設定を行うことができます。 man:m4[1] による設定ファイルは [.filename]#/usr/src/usr.sbin/sendmail/cf# 以下にあります。 もしシステムをすべてのソースとともにインストールしていなければ、 sendmail の設定材料は分割された個別のソース tarball を取得してください。 FreeBSD のソースコードが入った CDROM をマウントしているのなら、 [source,shell] .... # cd /cdrom/src # cat scontrib.?? | tar xzf - -C /usr/src/contrib/sendmail .... と展開してください (展開してもたった数百 KB 程度です)。 [.filename]#cf# ディレクトリの [.filename]#README# ファイルは man:m4[1] による設定の基本的な手引として役に立つでしょう。 UUCP 配送に対応するための一番よい方法は `mailertable` 機能を使用することです。 これは経路を決定するために sendmail が使用できるデータベースを作成します。 まずはじめに [.filename]#.mc# ファイルを作成しなければいけません。 [.filename]#/usr/src/usr.sbin/sendmail/cf/cf# にいくつか例があります。[.filename]#foo.mc# という名前のファイルをあなたが作成したとすると、 有効な [.filename]#sendmail.cf# ファイルへ変換するには次のようにするだけです。 [source,shell] .... # cd /usr/src/usr.sbin/sendmail/cf/cf # make foo.cf # cp foo.cf /etc/mail/sendmail.cf .... 典型的な [.filename]#.mc# ファイルは次のようになるでしょう。 [.programlisting] .... VERSIONID(`Your version number') OSTYPE(bsd4.4) FEATURE(accept_unresolvable_domains) FEATURE(nocanonify) FEATURE(mailertable, `hash -o /etc/mail/mailertable') define(`UUCP_RELAY', your.uucp.relay) define(`UUCP_MAX_SIZE', 200000) define(`confDONT_PROBE_INTERFACES') MAILER(local) MAILER(smtp) MAILER(uucp) Cw your.alias.host.name Cw youruucpnodename.UUCP .... `accept_unresolvable_domains`, `nocanonify` および `confDONT_PROBE_INTERFACES` 機能を含んでいる行は、 メール配送時にまったく DNS を使用しません。 `UUCP_RELAY` の記述は UUCP 配送に対応するのに必要です。 そこにインターネットホスト名を単に書くだけで .UUCP pseudo ドメインアドレスを扱うことができるようになります。 大抵の場合、あなたの ISP のメールリレーをそこに入力するでしょう。 次に、 [.filename]#/etc/mail/mailertable# が必要になります。 メールを配送するリンクが外界との間に一つだけの場合は、 次のようにファイルを記述するだけで十分でしょう。 [.programlisting] .... # # makemap hash /etc/mail/mailertable.db < /etc/mail/mailertable . uucp-dom:your.uucp.relay .... 次はさらに複雑な例です。 [.programlisting] .... # # makemap hash /etc/mail/mailertable.db < /etc/mail/mailertable # horus.interface-business.de uucp-dom:horus .interface-business.de uucp-dom:if-bus interface-business.de uucp-dom:if-bus .heep.sax.de smtp8:%1 horus.UUCP uucp-dom:horus if-bus.UUCP uucp-dom:if-bus . uucp-dom: .... はじめの三行はドメインで宛先を指定されたメールが、 配送路を "近道" するために、 デフォルトルートではなく代わりにいくつかの UUCP 隣接ホストへ送られる特別な場合を扱います。 次の行はメールを SMTP で配送可能なローカルイーサネットドメインへ送ります。 最後に `uucp-neighbor !recipient` がデフォルトルートを上書きすることを許可するための UUCP 隣接ホストは .UUCP 仮想ドメイン記法で言及されます。 最後の行は常に他のすべてが当てはまるシングルドットです。 これは UUCP 隣接ホストへの UUCP 配送をすることで、 世界に向けたあなたの普遍的メールゲートウェイとして役に立ちます。 `uucp-dom:` キーワードの後ろにあるノード名はすべて、 `uuname` コマンドを使用することで確かめられる正しい UUCP 隣接ホストである必要があります。 このファイルは、実際に使用する前に DBM データベース形式に変換する必要があることに注意してください。 これを実行するコマンドラインは [.filename]#mailertable# ファイルの先頭にコメントとして書かれています。 [.filename]#mailertable# を変更するたびにいつもこのコマンドを実行する必要があります。 最後のアドバイス: もし、 いくつかのメールルーティングがうまく動いているかどうか分からないときは sendmail に `-bt` オプションをつけることを覚えておいてください。 これは sendmail を _アドレステストモード_ で起動します。 あなたがテストしたいメールルーティングのアドレスを後につけて、 単純に `3,0` と入力してください。 最後の行は、内部で使われたメールエージェント、 このエージェントが呼び出された目的地ホスト、および (もしかしたら変換された) アドレスを表示します。 このモードを終了するには kbd:[Ctrl+D] を入力します。 [source,shell] .... % sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter
> 3,0 foo@example.com canonify input: foo @ example . com ... parse returns: $# uucp-dom $@ your.uucp.relay $: foo < @ example . com . > > ^D .... [[SMTP-dialup]] == ダイアルアップ接続でメールを使う あなたが固定 IP アドレスを持っているのなら、 デフォルトから何も変更する必要はありません。 割りあてられたインターネット名をホスト名に設定すれば、 sendmail が残りをやってくれます。 あなたが動的に割り当てられた IP アドレスを持っていて、 インターネットに接続するのにダイアルアップ PPP を使用しているのなら、 おそらく ISP のメールサーバにメールボックスがあるでしょう。 ここでは、あなたの ISP のドメインが `example.net`, あなたのユーザ名が `user`, あなたのマシンは `bsd.home` と呼ばれているものとします。 また、ISP から、メールリレーとして `relay.example.net` を使用してよいと通知されているとします。 (訳注: ISP 上の) メールボックスからメールを取得するためには、 取得アプリケーションをインストールしないといけません。 fetchmail ユーティリティは、 さまざまなプロトコルの多くに対応しているのでよい選択肢です。 通常、あなたの ISP は POP3 を提供しています。 このプログラムは、package:mail/fetchmail[] package または Ports Collection からインストールできます。 あなたが ユーザ PPP を使用しているなら、次のエントリを [.filename]#/etc/ppp/ppp.linkup# に追加することで、 インターネット接続が確立したときに自動的にメールを取得することができます。 [.programlisting] .... MYADDR: !bg su user -c fetchmail .... あなたがローカルではないアカウントへのメールを配送するために (下記のような) sendmail を使用しているなら、 インターネット接続が確立するとすぐに、 sendmail があなたのメールキューを処理して欲しいとおそらく考えるでしょう。 これを行うには、[.filename]#/etc/ppp/ppp.linkup# ファイルの `fetchmail` コマンドの後に次のコマンドを追加してください。 [.programlisting] .... !bg su user -c "sendmail -q" .... `bsd.home` 上に `user` というアカウントを所有しているとします。 `bsd.home` 上の `user` のホームディレクトリに [.filename]#.fetchmailrc# ファイルを作成します。 [.programlisting] .... poll example.net protocol pop3 fetchall pass MySecret .... このファイルはパスワード `MySecret` を含んでいるので、`user` を除く他の誰にも読めるようになっていてはいけません。 正しい `from:` ヘッダでメールを送るためには、 sendmail が `user@bsd.home` ではなく `user@example.net` を使用するようにしなくてはいけません。 また、素早くメール送信をするために sendmail にすべてのメールを `relay.example.net` 経由で送るようにもしたいかもしれません。 次の [.filename]#.mc# ファイルで十分でしょう。 [.programlisting] .... VERSIONID(`bsd.home.mc version 1.0') OSTYPE(bsd4.4)dnl FEATURE(nouucp)dnl MAILER(local)dnl MAILER(smtp)dnl Cwlocalhost Cwbsd.home MASQUERADE_AS(`example.net')dnl FEATURE(allmasquerade)dnl FEATURE(masquerade_envelope)dnl FEATURE(nocanonify)dnl FEATURE(nodns)dnl define(`SMART_HOST', `relay.example.net') Dmbsd.home define(`confDOMAIN_NAME',`bsd.home')dnl define(`confDELIVERY_MODE',`deferred')dnl .... [.filename]#.mc# ファイルを [.filename]#sendmail.cf# ファイルに変換する方法の詳細については前の節を参照してください。 また、[.filename]#sendmail.cf# ファイルを変更した後は、 sendmail を再起動し忘れないでください。 [[SMTP-Auth]] == SMTP 認証 メールサーバ上で SMTP 認証を行うと、 多くの利益があります。 SMTP 認証は sendmail にもう一つのセキュリティ層を追加することができます。 さらに、ホストを切りかえるモバイルユーザにとっては、 その都度メールクライアントの設定を変更せずとも 同じメールサーバを利用できるようになります。 [.procedure] ==== . ports から package:security/cyrus-sasl[] をインストールします。 この port は package:security/cyrus-sasl[] にあります。 package:security/cyrus-sasl[] にはここで使用する方法に対する多くのコンパイルオプションがあり、 確実に `pwcheck` オプションを選択してください。 . package:security/cyrus-sasl[] をインストールした後に [.filename]#/usr/local/lib/sasl/Sendmail.conf# を編集して (もし無ければ作成して) 次の行を追加してください。 + [.programlisting] .... pwcheck_method: passwd .... + この方法は sendmail があなたの FreeBSD の [.filename]#passwd# データベースに対して認証することを可能にします。 この方法は SMTP 認証に必要となる、 それぞれのユーザに対する一組の新しいユーザ名とパスワードを 作成する際のトラブルを減らし、 ログインパスワードとメールパスワードを同じままにします。 . ここで [.filename]#/etc/make.conf# 編集し、 次の行を加えます。 + [.programlisting] .... SENDMAIL_CFLAGS=-I/usr/local/include/sasl1 -DSASL SENDMAIL_LDFLAGS=-L/usr/local/lib SENDMAIL_LDADD=-lsasl .... + これらの行は sendmail に対して、 コンパイルするときに package:cyrus-sasl[] とリンクするための適切な設定オプションを与えるものです。 sendmail を再コンパイルする前に package:cyrus-sasl[] がインストールされていることを確かめてください。 . 次のコマンドを入力して sendmail を再コンパイルしてください。 + [source,shell] .... # cd /usr/src/usr.sbin/sendmail # make cleandir # make obj # make # make install .... + sendmail のコンパイルは [.filename]#/usr/src# が大幅に変更されていなくて、 必要な共有ライブラリが利用可能であれば何の問題も起こらないでしょう。 . sendmail をコンパイルして再インストールした後は、 [.filename]#/etc/mail/freebsd.mc# ファイル (またはあなたが [.filename]#.mc# ファイルとして使用しているファイル。 多くの管理者は唯一の名前を用いるために man:hostname[1] の出力を [.filename]#.mc# として使用することを選んでいます) を編集してください。 次の行を加えてください。 + [.programlisting] .... dnl set SASL options TRUST_AUTH_MECH(`GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN')dnl define(`confAUTH_MECHANISMS', `GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN')dnl define(`confDEF_AUTH_INFO', `/etc/mail/auth-info')dnl .... + これらのオプションは、ユーザを認証するために sendmail が利用可能な異なる方法を設定します。 もし pwcheck 以外の方法を使用したいのならドキュメントを参照してください。 . 最後に [.filename]#/etc/mail# で man:make[1] を実行してください。 これにより、新しい [.filename]#.mc# ファイルから [.filename]#freebsd.cf# という名前 (またはあなたの [.filename]#.mc# に使用している名前) の [.filename]#.cf# ファイルが作成されます。 それから `make install restart` コマンドを実行してください。 新しい [.filename]#.cf# ファイルが [.filename]#sendmail.cf# にコピーされ、 sendmail が適切に再起動されるでしょう。 この手続きについての詳細は [.filename]##/etc/mail/Makefile##を参照してください。 ==== すべてがうまくいけば、ログイン情報をメールクライアントに入力し、 テストメッセージを送ることができるでしょう。 より詳細に調べるには sendmail の `LogLevel` を 13 に設定し、 すべてのエラーについて [.filename]#/var/log/maillog# を見てください。 このサービスがシステムを起動した後にいつでも利用可能となるように、 [.filename]#/etc/rc.conf# に次の行を追加しておくとよいでしょう。 [.programlisting] .... sasl_pwcheck_enable="YES" sasl_pwcheck_program="/usr/local/sbin/pwcheck" .... これにより、システムの起動時に SMTP_AUTH が確実に初期化されるでしょう。 詳細については http://www.sendmail.org/~ca/email/auth.html[ SMTP 認証] に関する sendmail の文書を参照してください。 diff --git a/documentation/content/ja/books/handbook/mirrors/_index.adoc b/documentation/content/ja/books/handbook/mirrors/_index.adoc index 59e3898721..9aa8c1feb1 100644 --- a/documentation/content/ja/books/handbook/mirrors/_index.adoc +++ b/documentation/content/ja/books/handbook/mirrors/_index.adoc @@ -1,583 +1,583 @@ --- title: 付録A FreeBSD の入手方法 part: パートV. 付録 prev: books/handbook/partv next: books/handbook/bibliography description: "FreeBSD の入手方法: CD および DVD セット, FTP サイト, Git のインストールおよび利用方法" tags: ["入手方法", "CD", "DVD", "FTP", "Git"] showBookMenu: true -weight: 28 +weight: 27 path: "/books/handbook/" --- [appendix] = FreeBSD の入手方法 :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :sectnumoffset: A :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/mirrors/ ifdef::env-beastie[] ifdef::backend-html5[] :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [[mirrors]] == Mirrors FreeBSD の公式のミラーサイトは、プロジェクトクラスタの管理者により運用されている数多くのコンピュータから構成されています。 GeoDNS により、ユーザには近くの利用可能なミラーが提供されます。 現在ミラーサイトが置かれている地域は、オーストラリア、ブラジル、日本 (2 つのサイト)、マレーシア、オランダ、南アフリカ、台湾、英国、アメリカ合衆国 (カリフォルニア、ニュージャージーおよびワシントン) です。 公式のミラーサービス: [cols="1,1,3"] |=== | サービス名 | プロトコル | 備考 | **download.FreeBSD.org** | link:https://download.FreeBSD.org/[https] link:ftp://download.FreeBSD.org/pub/FreeBSD/[ftp] | `ftp.FreeBSD.org` と同じ内容です。`ftp` は古い名前なので、`download.FreeBSD.org` が推奨されます。 | **git.FreeBSD.org** | `https` および `ssh` 経由の git | 詳細については、link:https://docs.freebsd.org/ja/books/handbook/mirrors/#git[git の利用] の節を参照してください。 | **pkg.FreeBSD.org** | `http` および `https` 経由の man:pkg[8] | man:pkg[8] プログラムにより利用される公式の FreeBSD package リポジトリ |=== すべての公式のミラーは、IPv4 および IPv6 に対応しています。 FreeBSD のウェブサイト (https://www.FreeBSD.org および https://docs.FreeBSD.org) は、GeoDNS インフラストラクチャでは運用されていません。 この実装は、進行中の課題です。 http://ftp-archive.FreeBSD.org は GeoDNS インフラストラクチャではなく、一つ地域 (US) でのみ運用されています。 プロジェクトでは、新しい地域やスポンサーを募集しています。 クラスター管理チームまで連絡してください。 コミュニティおよび他の会社により管理されているミラーの一覧: [cols="1,1,3"] |=== | 国 | ホスト名 | プロトコル | オーストラリア icon:envelope[link=mailto:{mirrors-australia-email}, title="mirror contact"] | ftp.au.FreeBSD.org | link:http://ftp.au.FreeBSD.org/pub/FreeBSD[http] link:http://ftp.au.FreeBSD.org/pub/FreeBSD[http_v6] link:rsync://ftp.au.FreeBSD.org[rsync] link:rsync://ftp.au.FreeBSD.org[rsync_v6] | | ftp3.au.FreeBSD.org | link:http://ftp3.au.FreeBSD.org/pub/FreeBSD[http] link:ftp://ftp3.au.FreeBSD.org/pub/FreeBSD[ftp] link:rsync://ftp3.au.FreeBSD.org[rsync] | オーストリア icon:envelope[link=mailto:{mirrors-austria-email}, title="mirror contact"] | ftp.at.FreeBSD.org | link:http://ftp.at.FreeBSD.org/pub/FreeBSD/[http] link:http://ftp.at.FreeBSD.org/pub/FreeBSD/[http_v6] link:ftp://ftp.at.FreeBSD.org/pub/FreeBSD/[ftp] link:ftp://ftp.at.FreeBSD.org/pub/FreeBSD/[ftp_v6] link:rsync://ftp.at.FreeBSD.org/pub/FreeBSD/[rsync] link:rsync://ftp.at.FreeBSD.org/pub/FreeBSD/[rsync_v6] | ブラジル icon:envelope[link=mailto:{mirrors-brazil-email}, title="mirror contact"] | ftp2.br.FreeBSD.org | link:http://ftp2.br.FreeBSD.org/FreeBSD[http] link:rsync://ftp2.br.FreeBSD.org[rsync] link:rsync://ftp2.br.FreeBSD.org[rsync_v6] | | ftp3.br.FreeBSD.org | link:http://ftp3.br.FreeBSD.org/pub/FreeBSD[http] link:ftp://ftp3.br.FreeBSD.org/pub/FreeBSD[ftp] link:rsync://ftp3.br.FreeBSD.org[rsync] | ブルガリア icon:envelope[link=mailto:{mirrors-bulgaria-email}, title="mirror contact"] | ftp.bg.FreeBSD.org | link:ftp://ftp.bg.FreeBSD.org/pub/FreeBSD[ftp] link:ftp://ftp.bg.FreeBSD.org/pub/FreeBSD[ftp_v6] link:rsync://ftp.bg.FreeBSD.org[rsync] link:rsync://ftp.bg.FreeBSD.org[rsync_v6] | チェコ共和国 icon:envelope[link=mailto:{mirrors-czech-email}, title="mirror contact"] | ftp.cz.FreeBSD.org | link:http://ftp.cz.FreeBSD.org/pub/FreeBSD[http] link:http://ftp.cz.FreeBSD.org/pub/FreeBSD[http_v6] link:rsync://ftp.cz.FreeBSD.org[rsync] link:rsync://ftp.cz.FreeBSD.org[rsync_v6] | デンマーク icon:envelope[link=mailto:{mirrors-denmark-email}, title="mirror contact"] | ftp.dk.FreeBSD.org | link:http://ftp.dk.FreeBSD.org/FreeBSD/[http] link:http://ftp.dk.FreeBSD.org/FreeBSD/[http_v6] link:ftp://ftp.dk.FreeBSD.org/FreeBSD/[ftp] link:ftp://ftp.dk.FreeBSD.org/FreeBSD/[ftp_v6] link:rsync://ftp.dk.FreeBSD.org/FreeBSD/[rsync] link:rsync://ftp.dk.FreeBSD.org/FreeBSD/[rsync_v6] | フィンランド icon:envelope[link=mailto:{mirrors-finland-email}, title="mirror contact"] | ftp.fi.FreeBSD.org | link:ftp://ftp.fi.FreeBSD.org/pub/FreeBSD[ftp] | フランス icon:envelope[link=mailto:{mirrors-france-email}, title="mirror contact"] | ftp.fr.FreeBSD.org | link:http://ftp.fr.FreeBSD.org/pub/FreeBSD[http] link:http://ftp.fr.FreeBSD.org/pub/FreeBSD[http_v6] link:ftp://ftp.fr.FreeBSD.org/pub/FreeBSD[ftp] link:ftp://ftp.fr.FreeBSD.org/pub/FreeBSD[ftp_v6] link:rsync://ftp.fr.FreeBSD.org[rsync] link:rsync://ftp.fr.FreeBSD.org[rsync_v6] | | ftp3.fr.FreeBSD.org | link:ftp://ftp3.fr.FreeBSD.org/pub/FreeBSD[ftp] | | ftp6.fr.FreeBSD.org | link:http://ftp6.fr.FreeBSD.org/pub/FreeBSD[http] link:ftp://ftp6.fr.FreeBSD.org/pub/FreeBSD[ftp] link:rsync://ftp6.fr.FreeBSD.org[rsync] | ドイツ icon:envelope[link=mailto:{mirrors-germany-email}, title="mirror contact"] | ftp.de.FreeBSD.org | link:ftp://ftp.de.FreeBSD.org/pub/FreeBSD[ftp] link:ftp://ftp.de.FreeBSD.org/pub/FreeBSD[ftp_v6] link:rsync://ftp.de.FreeBSD.org[rsync] link:rsync://ftp.de.FreeBSD.org[rsync_v6] | | ftp1.de.FreeBSD.org | link:http://ftp1.de.FreeBSD.org/pub/FreeBSD[http] link:http://ftp1.de.FreeBSD.org/pub/FreeBSD[http_v6] link:ftp://ftp1.de.FreeBSD.org/pub/FreeBSD[ftp] link:ftp://ftp1.de.FreeBSD.org/pub/FreeBSD[ftp_v6] link:rsync://ftp1.de.FreeBSD.org[rsync] link:rsync://ftp1.de.FreeBSD.org[rsync_v6] | | ftp2.de.FreeBSD.org | link:http://ftp2.de.FreeBSD.org/pub/FreeBSD[http] link:http://ftp2.de.FreeBSD.org/pub/FreeBSD[http_v6] link:ftp://ftp2.de.FreeBSD.org/pub/FreeBSD[ftp] link:ftp://ftp2.de.FreeBSD.org/pub/FreeBSD[ftp_v6] link:rsync://ftp2.de.FreeBSD.org[rsync] link:rsync://ftp2.de.FreeBSD.org[rsync_v6] | | ftp5.de.FreeBSD.org | link:ftp://ftp5.de.FreeBSD.org/pub/FreeBSD[ftp] link:ftp://ftp5.de.FreeBSD.org/pub/FreeBSD[ftp_v6] | | ftp7.de.FreeBSD.org | link:http://ftp7.de.FreeBSD.org/pub/FreeBSD[http] link:http://ftp7.de.FreeBSD.org/pub/FreeBSD[http_v6] link:ftp://ftp7.de.FreeBSD.org/pub/FreeBSD[ftp] link:ftp://ftp7.de.FreeBSD.org/pub/FreeBSD[ftp_v6] | ギリシャ icon:envelope[link=mailto:{mirrors-greece-email}, title="mirror contact"] | ftp.gr.FreeBSD.org | link:http://ftp.gr.FreeBSD.org/pub/FreeBSD[http] link:http://ftp.gr.FreeBSD.org/pub/FreeBSD[http_v6] link:ftp://ftp.gr.FreeBSD.org/pub/FreeBSD[ftp] link:ftp://ftp.gr.FreeBSD.org/pub/FreeBSD[ftp_v6] | | ftp2.gr.FreeBSD.org | link:http://ftp2.gr.FreeBSD.org/pub/FreeBSD[http] link:http://ftp2.gr.FreeBSD.org/pub/FreeBSD[http_v6] link:ftp://ftp2.gr.FreeBSD.org/pub/FreeBSD[ftp] link:ftp://ftp2.gr.FreeBSD.org/pub/FreeBSD[ftp_v6] link:rsync://ftp2.gr.FreeBSD.org[rsync] | 日本 icon:envelope[link=mailto:{mirrors-japan-email}, title="mirror contact"] | ftp.jp.FreeBSD.org | link:http://ftp.jp.FreeBSD.org/pub/FreeBSD[http] link:http://ftp.jp.FreeBSD.org/pub/FreeBSD[http_v6] link:ftp://ftp.jp.FreeBSD.org/pub/FreeBSD[ftp] link:ftp://ftp.jp.FreeBSD.org/pub/FreeBSD[ftp_v6] link:rsync://ftp.jp.FreeBSD.org[rsync] link:rsync://ftp.jp.FreeBSD.org[rsync_v6] | | ftp2.jp.FreeBSD.org | link:ftp://ftp2.jp.FreeBSD.org/pub/FreeBSD[ftp] link:rsync://ftp2.jp.FreeBSD.org[rsync] link:rsync://ftp2.jp.FreeBSD.org[rsync_v6] | | ftp3.jp.FreeBSD.org | link:http://ftp3.jp.FreeBSD.org/pub/FreeBSD[http] link:rsync://ftp3.jp.FreeBSD.org[rsync] | | ftp4.jp.FreeBSD.org | link:ftp://ftp4.jp.FreeBSD.org/pub/FreeBSD[ftp] | | ftp6.jp.FreeBSD.org | link:http://ftp6.jp.FreeBSD.org/pub/FreeBSD[http] link:http://ftp6.jp.FreeBSD.org/pub/FreeBSD[http_v6] link:ftp://ftp6.jp.FreeBSD.org/pub/FreeBSD[ftp] link:ftp://ftp6.jp.FreeBSD.org/pub/FreeBSD[ftp_v6] link:rsync://ftp6.jp.FreeBSD.org[rsync] link:rsync://ftp6.jp.FreeBSD.org[rsync_v6] | 韓国 icon:envelope[link=mailto:{mirrors-korea-email}, title="mirror contact"] | ftp.kr.FreeBSD.org | link:http://ftp.kr.FreeBSD.org/pub/FreeBSD[http] link:https://ftp.kr.FreeBSD.org/pub/FreeBSD[https] link:ftp://ftp.kr.FreeBSD.org/pub/FreeBSD[ftp] link:rsync://ftp.kr.FreeBSD.org[rsync] | | ftp2.kr.FreeBSD.org | link:rsync://ftp2.kr.FreeBSD.org[rsync] | ラトビア icon:envelope[link=mailto:{mirrors-latvia-email}, title="mirror contact"] | ftp.lv.FreeBSD.org | link:http://ftp.lv.FreeBSD.org/pub/FreeBSD[http] link:ftp://ftp.lv.FreeBSD.org/pub/FreeBSD[ftp] | オランダ icon:envelope[link=mailto:{mirrors-netherlands-email}, title="mirror contact"] | ftp.nl.FreeBSD.org | link:http://ftp.nl.FreeBSD.org/pub/FreeBSD[http] link:http://ftp.nl.FreeBSD.org/pub/FreeBSD[http_v6] link:ftp://ftp.nl.FreeBSD.org/pub/FreeBSD[ftp] link:ftp://ftp.nl.FreeBSD.org/pub/FreeBSD[ftp_v6] link:rsync://ftp.nl.FreeBSD.org[rsync] link:rsync://ftp.nl.FreeBSD.org[rsync_v6] | | ftp2.nl.FreeBSD.org | link:http://ftp2.nl.FreeBSD.org/pub/FreeBSD[http] link:ftp://ftp2.nl.FreeBSD.org/pub/FreeBSD[ftp] link:rsync://ftp2.nl.FreeBSD.org[rsync] | ニュージーランド icon:envelope[link=mailto:{mirrors-new-zealand-email}, title="mirror contact"] | ftp.nz.FreeBSD.org | link:http://ftp.nz.FreeBSD.org/pub/FreeBSD[http] link:ftp://ftp.nz.FreeBSD.org/pub/FreeBSD[ftp] | ノルウェー icon:envelope[link=mailto:{mirrors-norway-email}, title="mirror contact"] | ftp.no.FreeBSD.org | link:ftp://ftp.no.FreeBSD.org/pub/FreeBSD[ftp] link:ftp://ftp.no.FreeBSD.org/pub/FreeBSD[ftp_v6] link:rsync://ftp.no.FreeBSD.org[rsync] link:rsync://ftp.no.FreeBSD.org[rsync_v6] | ポーランド icon:envelope[link=mailto:{mirrors-poland-email}, title="mirror contact"] | ftp.pl.FreeBSD.org | link:http://ftp.pl.FreeBSD.org/pub/FreeBSD[http] link:http://ftp.pl.FreeBSD.org/pub/FreeBSD[http_v6] link:ftp://ftp.pl.FreeBSD.org/pub/FreeBSD[ftp] link:rsync://ftp.pl.FreeBSD.org[rsync] link:rsync://ftp.pl.FreeBSD.org[rsync_v6] | ロシア icon:envelope[link=mailto:{mirrors-russia-email}, title="mirror contact"] | ftp.ru.FreeBSD.org | link:http://ftp.ru.FreeBSD.org/pub/FreeBSD[http] link:http://ftp.ru.FreeBSD.org/pub/FreeBSD[http_v6] link:ftp://ftp.ru.FreeBSD.org/pub/FreeBSD[ftp] link:ftp://ftp.ru.FreeBSD.org/pub/FreeBSD[ftp_v6] link:rsync://ftp.ru.FreeBSD.org[rsync] link:rsync://ftp.ru.FreeBSD.org[rsync_v6] | | ftp2.ru.FreeBSD.org | link:https://ftp2.ru.FreeBSD.org/pub/FreeBSD[https] link:ftp://ftp2.ru.FreeBSD.org/pub/FreeBSD[ftp] link:rsync://ftp2.ru.FreeBSD.org[rsync] | スロベニア icon:envelope[link=mailto:{mirrors-slovenia-email}, title="mirror contact"] | ftp.si.FreeBSD.org | link:http://ftp.si.FreeBSD.org/pub/FreeBSD[http] link:http://ftp.si.FreeBSD.org/pub/FreeBSD[http_v6] link:ftp://ftp.si.FreeBSD.org/pub/FreeBSD[ftp] link:ftp://ftp.si.FreeBSD.org/pub/FreeBSD[ftp_v6] | 南アフリカ icon:envelope[link=mailto:{mirrors-south-africa-email}, title="mirror contact"] | ftp.za.FreeBSD.org | link:https://ftp.za.FreeBSD.org/pub/FreeBSD[https] link:https://ftp.za.FreeBSD.org/pub/FreeBSD[https_v6] link:rsync://ftp.za.FreeBSD.org[rsync] link:rsync://ftp.za.FreeBSD.org[rsync_v6] | | ftp2.za.FreeBSD.org | link:http://ftp2.za.FreeBSD.org/pub/FreeBSD[http] link:http://ftp2.za.FreeBSD.org/pub/FreeBSD[http_v6] link:ftp://ftp2.za.FreeBSD.org/pub/FreeBSD[ftp_v6] | | ftp4.za.FreeBSD.org | link:http://ftp4.za.FreeBSD.org/pub/FreeBSD[http] link:ftp://ftp4.za.FreeBSD.org/pub/FreeBSD[ftp] link:rsync://ftp4.za.FreeBSD.org[rsync] | スウェーデン icon:envelope[link=mailto:{mirrors-sweden-email}, title="mirror contact"] | ftp.se.FreeBSD.org | link:http://ftp.se.FreeBSD.org/pub/FreeBSD[http] link:http://ftp.se.FreeBSD.org/pub/FreeBSD[http_v6] link:ftp://ftp.se.FreeBSD.org/pub/FreeBSD[ftp] link:ftp://ftp.se.FreeBSD.org/pub/FreeBSD[ftp_v6] link:rsync://ftp.se.FreeBSD.org[rsync] link:rsync://ftp.se.FreeBSD.org[rsync_v6] | 台湾 icon:envelope[link=mailto:{mirrors-taiwan-email}, title="mirror contact"] | ftp4.tw.FreeBSD.org | link:https://ftp4.tw.FreeBSD.org/pub/FreeBSD[https] link:ftp://ftp4.tw.FreeBSD.org/pub/FreeBSD[ftp] link:rsync://ftp4.tw.FreeBSD.org[rsync] | | ftp5.tw.FreeBSD.org | link:http://ftp5.tw.FreeBSD.org/pub/FreeBSD[http] link:ftp://ftp5.tw.FreeBSD.org/pub/FreeBSD[ftp] | ウクライナ icon:envelope[link=mailto:{mirrors-ukraine-email}, title="mirror contact"] | ftp.ua.FreeBSD.org | link:http://ftp.ua.FreeBSD.org/pub/FreeBSD[http] link:ftp://ftp.ua.FreeBSD.org/pub/FreeBSD[ftp] link:ftp://ftp.ua.FreeBSD.org/pub/FreeBSD[ftp_v6] link:rsync://ftp.ua.FreeBSD.org[rsync] link:rsync://ftp.ua.FreeBSD.org[rsync_v6] | 英国 icon:envelope[link=mailto:{mirrors-uk-email}, title="mirror contact"] | ftp.uk.FreeBSD.org | link:http://ftp.uk.FreeBSD.org/pub/FreeBSD[http] link:http://ftp.uk.FreeBSD.org/pub/FreeBSD[http_v6] link:ftp://ftp.uk.FreeBSD.org/pub/FreeBSD[ftp] link:ftp://ftp.uk.FreeBSD.org/pub/FreeBSD[ftp_v6] link:rsync://ftp.uk.FreeBSD.org[rsync] link:rsync://ftp.uk.FreeBSD.org[rsync_v6] | | ftp2.uk.FreeBSD.org | link:http://ftp2.uk.FreeBSD.org/pub/FreeBSD[http] link:http://ftp2.uk.FreeBSD.org/pub/FreeBSD[http_v6] link:https://ftp2.uk.FreeBSD.org/pub/FreeBSD[https] link:https://ftp2.uk.FreeBSD.org/pub/FreeBSD[https_v6] link:ftp://ftp2.uk.FreeBSD.org/pub/FreeBSD[ftp] link:ftp://ftp2.uk.FreeBSD.org/pub/FreeBSD[ftp_v6] | アメリカ合衆国 icon:envelope[link=mailto:{mirrors-us-email}, title="mirror contact"] | ftp11.FreeBSD.org | link:http://ftp11.FreeBSD.org/pub/FreeBSD[http] link:http://ftp11.FreeBSD.org/pub/FreeBSD[http_v6] link:ftp://ftp11.FreeBSD.org/pub/FreeBSD[ftp] link:ftp://ftp11.FreeBSD.org/pub/FreeBSD[ftp_v6] link:rsync://ftp11.FreeBSD.org[rsync] link:rsync://ftp11.FreeBSD.org[rsync_v6] | | ftp14.FreeBSD.org | link:ftp://ftp14.FreeBSD.org/pub/FreeBSD[ftp] link:rsync://ftp14.FreeBSD.org[rsync] (Former official tier 1) | | ftp5.FreeBSD.org | link:http://ftp5.FreeBSD.org/pub/FreeBSD[http] link:http://ftp5.FreeBSD.org/pub/FreeBSD[http_v6] link:ftp://ftp5.FreeBSD.org/pub/FreeBSD[ftp] link:ftp://ftp5.FreeBSD.org/pub/FreeBSD[ftp_v6] |=== コミュニティのミラーによりサポートされているプロトコル一覧は、2022-01-31 に更新されました。 この一覧は保証されているわけではありません。 [[git]] == Git の利用 [[git-intro]] === はじめに 2020 年 12 月、FreeBSD はソースコード、ドキュメントのすべてを管理するメインのバージョン管理システムを git に移行しました。 2021 年 4 月、FreeBSD は Ports Collection のすべてを管理するバージョン管理システムを git に移行しました。 [NOTE] ==== 一般的には Git は開発用ツールです。 ユーザは好みに合わせて、FreeBSD ベースシステムのアップデートに `freebsd-update` (crossref:cutting-edge[updating-upgrading-freebsdupdate,“FreeBSD Update”])、 FreeBSD Ports Collection のアップデートに `portsnap` (crossref:ports[ports-using,“Ports Collection の利用”]を使用できます。 ==== この章では、FreeBSD への Git のインストール方法および FreeBSD ソースコードリポジトリのローカルコピーの作成方法について説明します。 [[git-install]] === インストール Ports Collection または package を使って Git をインストールできます。 [source,shell] .... # pkg install git .... [[git-usage]] === Git の実行 ソースコードをローカルディレクトリに新しくコピーするには、`git clone` を使ってください。 このファイルのあるディレクトリのことを _ワークツリー_ と呼びます。 Git は、リポジトリの指定に URL を用います。 リポジトリには `base`, `doc` および `ports` の 3 種類あります。 `base` は FreeBSD ベースシステムのソースコード、`doc` はドキュメント、そして `ports` は FreeBSD Ports Collection のリポジトリです。 これら 3 つのリポジトリはすべて HTTPS および SSH という 2 つの異なるプロトコル経由でアクセスできます。 たとえば、`https://git.FreeBSD.org/src.git` という URL は、`https` プロトコルによる `src` リポジトリの main ブランチを示します。 [[git-url-table]] .FreeBSD Git リポジトリの URL テーブル [options="header,footer"] |======================================================= |項目 | Git URL | HTTPS 経由の読み取り専用 src リポジトリ | `https://git.FreeBSD.org/src.git` | Anonymous ssh による読み取り専用 src リポジトリ | `ssh://anongit@git.FreeBSD.org/src.git` | HTTPS 経由の読み取り専用 doc リポジトリ | `https://git.FreeBSD.org/doc.git` | Anonymous ssh による読み取り専用 doc リポジトリ | `ssh://anongit@git.FreeBSD.org/doc.git` | HTTPS 経由の読み取り専用 ports リポジトリ| `https://git.FreeBSD.org/ports.git` | Anonymous ssh による読み取り専用 ports リポジトリ | `ssh://anongit@git.FreeBSD.org/ports.git` |======================================================= プロジェクトのメンバーが管理する外部のミラーも存在します。 <> の節を参照してください。 FreeBSD システムのソースコードリポジトリを clone するには、以下のコマンドを実行してください。 [source,shell] .... # git clone -o freebsd https://git.FreeBSD.org/src.git /usr/src .... ここで `-o freebsd` オプションは origin を指定します。 FreeBSD のドキュメントの慣例で、origin は `freebsd` とします。 初めてチェックアウトする際には、リモートリポジトリのすべてのブランチをダウンロードするので時間がかかります。 ワーキングツリーには最初、CURRENT に対応する `main` ブランチのソースコードがダウンロードされます。 13-STABLE に変更するには以下のように実行してください。 [source,shell] .... # cd /usr/src # git checkout stable/13 .... ワーキングツリーは、`git pull` によりアップデートできます。 上記の例で作成された [.filename]#/usr/src# をアップデートするには、以下のようになります。 [source,shell] .... # cd /usr/src # git pull --rebase .... チェックアウトと比較すると、このアップデートでは変更点のあるファイルのみが転送されるので高速です。 === ウェブベースのリポジトリブラウザ FreeBSD プロジェクトは、現在 cgit をウェブベースのリポジトリブラウザ (link:https://cgit.FreeBSD.org/[https://cgit.FreeBSD.org/]) として使用しています。 === 開発者向けの説明 リポジトリへの書き込みアクセスについてはの詳細は、extref:{committers-guide}[Committer's Guide, git-mini-primer] をご覧ください。 [[external-mirrors]] === 外部ミラー FreeBSD.org は以下のミラーを管理していませんが、プロジェクトのメンバーが現在も維持しています。 ユーザおよび開発者は自由にこれらのミラーのリポジトリを pull したりブラウザで見ることができます。 `doc` GitHub リポジトリへの pull request は accept されますが、 それ以外について、これらのミラーとのプロジェクトワークフローは議論中です。 Codeberg:: - doc: https://codeberg.org/FreeBSD/freebsd-doc - ports: https://codeberg.org/FreeBSD/freebsd-ports - src: https://codeberg.org/FreeBSD/freebsd-src GitHub:: - doc: https://github.com/freebsd/freebsd-doc - ports: https://github.com/freebsd/freebsd-ports - src: https://github.com/freebsd/freebsd-src GitLab:: - doc: https://gitlab.com/FreeBSD/freebsd-doc - ports: https://gitlab.com/FreeBSD/freebsd-ports - src: https://gitlab.com/FreeBSD/freebsd-src === メーリングリスト FreeBSD プロジェクトにおける git の一般的な使用方法や質問についてのメインのメーリングリストは https://lists.freebsd.org/subscription/freebsd-git[freebsd-git] です。 コミットメッセージの一覧などの詳細については、crossref:handbook/eresources[eresources-mail, メーリングリスト] の章をご覧ください。 === SSH ホスト鍵 * gitrepo.FreeBSD.org ホスト鍵のフィンガープリント: ** ECDSA 鍵のフィンガープリントは `SHA256:seWO5D27ySURcx4bknTNKlC1mgai0whP443PAKEvvZA` です。 ** ED25519 鍵のフィンガープリントは `SHA256:lNR6i4BEOaaUhmDHBA1WJsO7H3KtvjE2r5q4sOxtIWo` です。 ** RSA 鍵のフィンガープリントは `SHA256:f453CUEFXEJAXlKeEHV+ajJfeEfx9MdKQUD7lIscnQI` です。 * git.FreeBSD.org ホスト鍵のフィンガープリント: ** ECDSA 鍵のフィンガープリントは `SHA256:/UlirUAsGiitupxmtsn7f9b7zCWd0vCs4Yo/tpVWP9w` です。 ** ED25519 鍵のフィンガープリントは `SHA256:y1ljKrKMD3lDObRUG3xJ9gXwEIuqnh306tSyFd1tuZE` です。 ** RSA 鍵のフィンガープリントは `SHA256:jBe6FQGoH4HjvrIVM23dcnLZk9kmpdezR/CvQzm7rJM` です。 これらは DNS の SSHFP レコードとしても公開されています。 [[svn]] == Subversion の利用 [[svn-intro]] === はじめに 2020 年 12 月より、FreeBSD のソースコード、ドキュメントのすべてを管理するメインのバージョン管理システムは git に移行しました。 git リポジトリの `stable/11`, `stable/12` および関連するリリースのブランチは、subversion リポジトリにエクスポートされます。 このエクスポートは、各ブランチの保守終了予定日まで行われる予定です。 2012 年 7 月から 2021 年 3 月までの間 FreeBSD は、FreeBSD Ports Collection のすべてを管理するバージョン管理システムに Subversion を使用していました。 2021 年 4 月より、FreeBSD の Ports Collection のすべてを管理するメインのバージョン管理システムは git に移行しました。 [NOTE] ==== -一般的には Subversion は開発者向けのツールです。 ユーザは好みに応じて、FreeBSD のベースシステムのアップデートに `freebsd-update` (crossref:cutting-edge[updating-upgrading-freebsdupdate,「FreeBSD Update」])、Ports Collection のアップデートには `portsnap` (crossref:ports[ports-using,「Ports Collection の利用」]) を使用できます。 2021 年 3 月以降、subversion はレガシーブランチ (`stable/11` および `stable/12`) でのみ使用されます。 ==== この節では、FreeBSD システムへの Subversion のインストール方法、および FreeBSD リポジトリをローカルに作成する方法について説明します。 さらに Subversion を利用するための情報についても紹介します。 [[svn-svnlite]] === Svnlite FreeBSD には、Subversion より軽い `svnlite` がインストールされています。 Subversion の port または package は、Python もしくは Perl API が必要な時や、最新の Subversion を使用したい時のみ必要となります。 通常の Subversion と、 `svnlite` との違いは、 使用する時のコマンド名が異なるだけです。 [[svn-install]] === インストール `svnlite` を利用できない場合や、 フルバージョンの Subversion を使いたいのであれば、 事前に Subversion をインストールしておく必要があります。 Subversion は Ports Collection からインストールできます。 [source,shell] .... # cd /usr/ports/devel/subversion # make install clean .... package を使って Subversion をインストールすることもできます。 [source,shell] .... # pkg install subversion .... [[svn-usage]] === Subversion の実行 ローカルディレクトリにソースコードをダウンロードするには、 `svn` コマンドを使ってください。 このディレクトリにあるファイルを、 _ローカル作業コピー_ と呼びます。 [WARNING] ==== `checkout` をはじめて使う前に、 ローカルディレクトリを移動するか削除してください。 `svn` 以外の方法で用意されたディレクトリでチェックアウトすると、 すでに存在するファイルと、 リポジトリから持ってきたファイルとの間で衝突が起きてしまいます。 ==== Subversion では、リポジトリの指定に _protocol://hostname/path_ 形式の URL を用います。 以下に記載されているように、 アクセスする FreeBSD リポジトリは、パス (path) の最初で指定します。 リポジトリは 3 つあります。 `base` は FreeBSD ベースシステムのソースコード、`ports` は Ports Collection、 そして `doc` はドキュメントのリポジトリです。 たとえば、`https://svn.FreeBSD.org/base/head/` という URL は、`https` プロトコルによる src リポジトリのメインブランチを示しています。 以下のように入力して、リポジトリからチェックアウトしてください。 [source,shell] .... # svn checkout https://svn.FreeBSD.org/repository/branch lwcdir .... ここで、_repository_, _branch_ および _root_ は以下のとおりです。 * _repository_ には、 プロジェクトリポジトリの `base`, `ports` または `doc` のどれかひとつを指定します。 * _branch_ は、使うリポジトリによります。 `ports` および `doc` では、ほとんどの変更が `head` ブランチで行われます。 `base` リポジトリでは、`head` ブランチで -CURRENT の最新バージョンを管理しています。 -STABLE ブランチの最新バージョンは、 11._x_ は `stable/11`, そして 12._x_ は `stable/12` で管理しています。 * _lwcdir_ は、 指定したブランチの中身が置かれるターゲットのディレクトリです。 通常 `ports` は [.filename]#/usr/ports#、 `base` は [.filename]#/usr/src#、 そして `doc` では [.filename]#/usr/doc# と指定します。 以下の例では、ソースツリーを FreeBSD リポジトリから HTTPS プロトコルを使ってチェックアウトします。 それらは、[.filename]#/usr/src# のローカル作業コピーに置かれます。 もし [.filename]#/usr/src# がすでに存在していて、それが `svn` によって生成されたものでなければ、チェックアウトする前に、名前を変更するか削除してください。 [source,shell] .... # svn checkout https://svn.FreeBSD.org/base/head /usr/src .... 初めてチェックアウトする際には、 リモートリポジトリのすべてのブランチをダウンロードする必要があるので、時間がかかります。 我慢してください。 初めてのチェックアウト後は、 以下を実行することでローカル作業コピーをアップデートできます。 [source,shell] .... # svn update lwcdir .... この例で作成された [.filename]#/usr/src# をアップデートするには、 以下のようにしてください。 [source,shell] .... # svn update /usr/src .... アップデートはチェックアウトにくらべ、 変更点のあるファイルのみが転送されるので高速です。 チェックアウト後、ローカル作業コピーをアップデートするもうひとつの方法は、 [.filename]#/usr/ports#, [.filename]#/usr/src# または [.filename]#/usr/doc# ディレクトリの [.filename]#Makefile# で提供されています。 `SVN_UPDATE` を設定して `update` ターゲットを使ってください。 たとえば、[.filename]#/usr/src# をアップデートするには、以下のようにしてください。 [source,shell] .... # cd /usr/src # make update SVN_UPDATE=yes .... [[svn-mirrors]] === Subversion ミラーサイト FreeBSD Subversion リポジトリは、 [.programlisting] .... svn.FreeBSD.org .... です。これは、公にアクセス可能なミラーネットワークで、 GeoDNS を用いて適切なバックエンドサーバを選択しています。 ブラウザを用いて FreeBSD の Subversion リポジトリを参照するには、link:https://svnweb.FreeBSD.org/[https://svnweb.FreeBSD.org/] を利用してください。 HTTPS は推奨されているプロトコルです。 自動的に証明書を検証するために、package:security/ca_root_nss[] port をインストールする必要があります。 === より詳しい情報 Subversion の利用に関する他の情報は、 http://svnbook.red-bean.com/[Version Control with Subversion] や http://subversion.apache.org/docs/[Subversion Documentation] といった "Subversion Book" をご覧ください。 [[mirrors-cdrom]] == CD および DVD セット FreeBSD の CD および DVD のセットは以下のオンライン業者から入手できます。 * FreeBSD Mall, Inc. + 1164 Claremont Dr + Brentwood, CA + 94513 + USA + Phone: +1 925 240-6652 + Fax: +1 925 674-0821 + Email: info@freebsdmall.com + WWW: https://www.freebsdmall.com * Getlinux + WWW: https://www.getlinux.fr/ * Dr. Hinner EDV + Schäftlarnstr. 10 // 4. Stock + D-81371 München + Germany + Phone: +49 171 417 544 6 + Email: infow@hinner.de + WWW: http://www.hinner.de/linux/freebsd.html diff --git a/documentation/content/ja/books/handbook/partiv.adoc b/documentation/content/ja/books/handbook/partiv.adoc index b9a5161a9f..427bea675d 100644 --- a/documentation/content/ja/books/handbook/partiv.adoc +++ b/documentation/content/ja/books/handbook/partiv.adoc @@ -1,22 +1,22 @@ --- title: パートIV. ネットワーク通信 prev: books/handbook/cutting-edge next: books/handbook/serialcomms showBookMenu: true -weight: 22 +weight: 21 path: "/books/handbook/" --- [[network-communication]] = ネットワーク通信 FreeBSD は、 高性能なネットワークサーバとして最も広く使用されているオペレーティングシステムの 1 つです。 各章の内容は以下の通りです。 * シリアル通信 * PPP と PPP オーバイーサネット (PPPoE) * 電子メール * ネットワークサーバの運用 * ファイアウォール * その他の高度なネットワークに関する話題 各章は、必要になった時に個別に参照できるように構成されています。 どの順番で読んでも構いませんし、ネットワーク環境で FreeBSD を使うのに、 すべてを読み通す必要がある、というわけでもありません。 diff --git a/documentation/content/ja/books/handbook/partv.adoc b/documentation/content/ja/books/handbook/partv.adoc index 359580d680..c507360d28 100644 --- a/documentation/content/ja/books/handbook/partv.adoc +++ b/documentation/content/ja/books/handbook/partv.adoc @@ -1,11 +1,11 @@ --- title: パートV. 付録 prev: books/handbook/advanced-networking next: books/handbook/mirrors showBookMenu: true -weight: 27 +weight: 26 path: "/books/handbook/" --- [[appendices]] = 付録 diff --git a/documentation/content/ja/books/handbook/pgpkeys/_index.adoc b/documentation/content/ja/books/handbook/pgpkeys/_index.adoc index 5ed591f80b..bd695f05af 100644 --- a/documentation/content/ja/books/handbook/pgpkeys/_index.adoc +++ b/documentation/content/ja/books/handbook/pgpkeys/_index.adoc @@ -1,75 +1,75 @@ --- title: 付録 D. OpenPGP Keys part: パートV. 付録 prev: books/handbook/eresources next: books/handbook/freebsd-glossary showBookMenu: true -weight: 31 +weight: 30 path: "/books/handbook/" --- [appendix] [[pgpkeys]] = PGP 公開鍵 :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :sectnumoffset: D :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/pgpkeys/ ifdef::env-beastie[] ifdef::backend-html5[] :pgpkeys-path: ../../../../../ :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] :pgpkeys-path: include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] :pgpkeys-path: ../../../../../ include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] :pgpkeys-path: ../../../../../ include::../../../../../shared/asciidoctor.adoc[] endif::[] `FreeBSD.org` オフィサの PGP 公開鍵を以下に示します。 これらの公開鍵は、署名を検証したり、 オフィサに暗号メールを送る必要がある場合に使用できます。 すべての FreeBSD 公開鍵の一覧は、 extref:{pgpkeys}[PGP Keys] にあります。 また、完全なキーリングは link:https://docs.FreeBSD.org/pgpkeys/pgpkeys.txt[pgpkeyring.txt] からダウンロードできます。 [[pgpkeys-officers]] == オフィサ === {security-officer-name} `<{security-officer-email}>` include::{pgpkeys-path}static/pgpkeys/security-officer.key[] === {secteam-secretary-name} `<{secteam-secretary-email}>` include::{pgpkeys-path}static/pgpkeys/secteam-secretary.key[] === {core-secretary-name} `<{core-secretary-email}>` include::{pgpkeys-path}static/pgpkeys/core-secretary.key[] === {portmgr-secretary-name} `<{portmgr-secretary-email}>` include::{pgpkeys-path}static/pgpkeys/portmgr-secretary.key[] === `{doceng-secretary-email}` include::{pgpkeys-path}static/pgpkeys/doceng-secretary.key[] :sectnums: :sectnumlevels: 6 diff --git a/documentation/content/ja/books/handbook/ppp-and-slip/_index.adoc b/documentation/content/ja/books/handbook/ppp-and-slip/_index.adoc index 1cdbf574cc..2566362cab 100644 --- a/documentation/content/ja/books/handbook/ppp-and-slip/_index.adoc +++ b/documentation/content/ja/books/handbook/ppp-and-slip/_index.adoc @@ -1,1672 +1,1672 @@ --- -title: 第19章 PPP と SLIP +title: 第18章 PPP と SLIP part: パートIV. ネットワーク通信 prev: books/handbook/serialcomms next: books/handbook/mail showBookMenu: true -weight: 24 +weight: 23 path: "/books/handbook/" --- [[ppp-and-slip]] = PPP と SLIP :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 -:sectnumoffset: 19 +:sectnumoffset: 18 :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/ppp-and-slip/ ifdef::env-beastie[] ifdef::backend-html5[] :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] == この章では もしあなたがモデムを使ってインターネットに接続したり, 他の人々に FreeBSD によるインターネットへのダイヤルアップ接続を 提供しようとしているのでしたら, PPP または SLIP 接続を選択することができます. この節では 3 種類の PPP について説明しています. それは _ユーザ_, _カーネル_, そして _PPPoE_ (PPP オーバイーサネット) です. また SLIP のクライアントとサーバの設定についても記述しています. 最初に説明するのは, ユーザ PPP です. ユーザ PPP は FreeBSD に 2.0.5-RELEASE の時に, 既に存在していたカーネル実装の PPP に加えて導入されました. ユーザ PPP とカーネル PPP の主な違いは何かと疑問に思われるかも 知れませんが, その答えは簡単です. ユーザ PPP はデーモンとしては実行されず 必要に応じて実行されるのです. PPP インタフェイスを組み込んだカーネルは 必要ではなく, ユーザプロセスとして実行されカーネルとのデータの やり取りにはトンネルデバイスドライバ ([.filename]#tun#) を 使用します. この節ではこれ以降ユーザ PPP のことは, `pppd` のような他の PPP ソフトウエアと特に区別する必要がある場合を除いて, 単に ppp と記述します. またこの節に記述されているコマンドは すべて root で実行されなければなりません. [[userppp]] == ユーザ ppp の利用 === ユーザ PPP ==== 前提条件 以下の情報を手に入れておく必要があるでしょう: * PPP で接続するインターネットサービスプロバイダ (ISP) のアカウント. さらに, 接続済みのモデム (またはその他のデバイス) があり, プロバイダとの接続が可能なように正しく設定されている. * プロバイダの電話番号. * ログイン名とパスワード. これは通常の unix 形式のログイン名と パスワードの組という場合もありますし, PPP PAP または CHAP の ログイン名とパスワードの組という場合もあります. * 一つ以上のネームサーバの IP アドレス. 通常, プロバイダから IP アドレスを二つ指示されている はずです. 一つすら提供されていないならば, [.filename]#ppp.conf# ファイル中で `enable dns` コマンドを使って ppp にネームサーバを設定するよう 指示できます. プロバイダからは以下の情報が提供されているはずですが, どうしても必要というわけではありません: * プロバイダのゲートウェイの IP アドレス. ゲートウェイとは, あなたがそこに接続をおこなって, _デフォルトルート_ として設定することになるマシンです. プロバイダがこのアドレスを明示していなくても, 最初は 適当に設定しておいて, 接続時にプロバイダの PPP サーバから 正しいアドレスを教えてもらうことができます. + このアドレスは, ppp から ``HISADDR``として参照されます. * プロバイダのネットマスク設定. プロバイダが明示していないとしても, ネットマスクとして `255.255.255.0` を使用しておけば問題ありません. * もしプロバイダから固定の IP アドレスとホスト名の割り当てを 受けていれば, その情報を指定しておくこともできます. 割り当てを受けていなければ, 接続先から適切な IP アドレスを指定してもらいます. もし, 必要な情報が不足していれば, プロバイダに連絡を取って 確認しておいてください. ==== ppp 対応カーネルの構築 説明でも述べているように, `ppp` はカーネルの [.filename]#tun# デバイスを使います. 使っているカーネルがどれであっても, [.filename]#tun# デバイスを設定しなければなりません. FreeBSDに付属しているデフォルトの [.filename]#GENERIC# カーネルに合うように [.filename]#tun# デバイスは前もって設定されています. しかしながら, 自分で修正したカーネルをインストールするのであれば, pppが正しく動くよう, カーネルが設定されているか確認しなくてはいけません. これを確認するには, カーネルコンパイルディレクトリ ([.filename]#/sys/i386/conf# または [.filename]#/sys/pc98/conf#) に移動して, カーネルコンフィグレーションファイルを調べます. 以下の行がどこかに含まれている必要があります. [.programlisting] .... pseudo-device tun 1 .... この行がカーネルコンフィグレーションファイルに 含まれていない場合, この行を追加して カーネルの再コンパイルとインストールをおこなう必要があります. 元々の [.filename]#GENERIC# カーネルは 標準でこれを含んでいますので, カスタムカーネルをインストールしているのではなかったり, [.filename]#/sys# ディレクトリが存在しないのであれば, 何も変更する必要はありません. カーネルコンフィグレーションの詳細については, crossref:kernelconfig[kernelconfig,FreeBSD カーネルのコンフィグレーション] を参照してください. 以下のコマンドを実行することで, 現在のカーネルにトンネルデバイスが いくつ組み込まれているかを調べることができます: [source,shell] .... # 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=8010 mtu 1500 .... [NOTE] ==== FreeBSD 4.0やより最近のリリースでは, すでに使われている [.filename]#tun# デバイスしか見つけることが できないでしょう. これは, __全く__ [.filename]##tun## デバイスを見つけることが できないかもしれないということです. しかし, もしこうなって しまっても, 心配することはありません. そのデバイスは `ppp` が使おうとする時に動的に作られるはず だからです. ==== この例ではトンネルデバイスが四つ存在し, そのうち二つに 設定がおこなわれ, 使用中であることがわかります. 上の例で `RUNNING` フラグがオンになっている ものがありますが, これは そのインタフェースが何かに使用されていることを示している だけであるということに注意してください. つまり, `RUNNING` になっていない インタフェースがあったとしても, それはエラーではありません. トンネルデバイスがカーネルに組み込まれておらず, 何らかの理由で カーネルの再構築ができない場合でも, 方法がないわけではありません. 動的にデバイスをロードすることができるはずです. 詳細については man:modload[8] や man:lkm[4] など, 適切なマニュアルを参照してください. ==== tun デバイスの確認 ほとんどのユーザは [.filename]#tun# デバイス ([.filename]#/dev/tun0#) が一つあれば充分でしょう. より多くのデバイスを使う場合 (すなわち, カーネルコンフィグレーション ファイルで `pseudo-device tun` の行に `1` 以外の数値を指定している場合), 以下で [.filename]#tun0# と書かれている部分をすべて, あなたが使うデバイスの番号に あわせて読みかえてください. [.filename]#tun0# デバイスが正しく作成されていることを確認する最も簡単な方法は, それを作り直すことです. そのためには, 以下のコマンドを実行します: [source,shell] .... # cd /dev # ./MAKEDEV tun0 .... カーネルに 16 個のトンネルデバイスを組み込んだのであれば, [.filename]#tun0# だけでなく他の tun デバイスも作成しておく必要があるでしょう: [source,shell] .... # cd /dev # ./MAKEDEV tun15 .... また, カーネルが正しく設定されているかどうかを調べるために 以下のコマンドを実行して, このような出力が得られることを確認します: [source,shell] .... # ifconfig tun0 tun0: flags=8050 mtu 1500 .... まだ `RUNNING` フラグがセットされていない場合もあります. その時は以下のような出力が得られるでしょう: [source,shell] .... # ifconfig tun0 tun0: flags=8010 mtu 1500 .... 前述したように, FreeBSD 4.0 以降のリリースでは [.filename]#tun# デバイスは要求に応じて 作られるので, もしそのデバイスがまだ使われていなければ, 見つけられないかもしれないということを思い出してください. ==== 名前の解決に関する設定 リゾルバ (resolver) はシステムの一部分で, IP アドレスとホスト名との 変換をおこないます. IP アドレスとホスト名を対応させるためのマップを, 二つの場所のうちの一つから探すように設定できます. 一つめは [.filename]#/etc/hosts# (`man 5 hosts`) と呼ばれるファイルです. 二つめはインターネット ドメインネームサービス (DNS) と呼ばれる 分散データベースですが, これに関する議論は このドキュメントで扱う範囲を 越えていますので, これについての説明はおこないません. リゾルバは名前のマッピングを おこなうシステムコールの集合体です. ただし どこからマッピング情報を見つけるのかは, 最初に指示しておく必要があります. これは まず [.filename]#/etc/host.conf# ファイルを編集することでおこないます. 混乱の元になりますので, このファイルを [.filename]##/etc/hosts.conf##と 呼んだりしては__いけません__ (余分な `s` がついていますね). ===== [.filename]#/etc/host.conf# ファイルの編集 このファイルには 以下の 2 行が (この順番で) 書かれているはずです: [.programlisting] .... hosts bind .... これは, 最初に [.filename]#/etc/hosts# ファイルを調べ, そこで目的の名前が 見つけられなかった場合に DNS を引きにいくようリゾルバに指示します. ===== /etc/hosts(5) ファイルの編集 このファイルはローカルネットワーク上に存在するマシンの IP アドレスと ホスト名を含んでいるはずです. 最低でも ppp を動作させるマシンのエントリが 含まれている必要があります. そのマシンのホスト名が `foo.bar.com` で, IP アドレスが `10.0.0.1` であると仮定すると, [.filename]#/etc/hosts# は 以下の行を含んでいなければいけません: [.programlisting] .... 127.0.0.1 localhost.bar.com localhost 127.0.0.1 localhost.bar.com. 10.0.0.1 foo.bar.com foo 10.0.0.1 foo.bar.com. .... 一つめの行は `localhost` を現在のマシンの別名として定義しています. マシン固有の IP アドレスが何であっても, この行の IP アドレスは 常に `127.0.0.1` でなければいけません. 二つめの行はホスト名 `foo.bar.com` (と, その省略形 `foo`) を IP アドレス `10.0.0.1` にマップします. もしプロバイダから固定の IP アドレスとホスト名を割り当てられて いるのであれば, それを `10.0.0.1` エントリのかわりに使ってください. ===== [.filename]#/etc/resolv.conf# ファイルの編集 [.filename]#/etc/resolv.conf# はリゾルバの振舞いを指定します. もし自前の DNS サーバを走らせているのなら, このファイルは空のままに しておくこともできます. 通常は, 以下のように書いておく必要があるでしょう: [.programlisting] .... domain bar.com nameserver x.x.x.x nameserver y.y.y.y .... `_x.x.x.x_` と `_y.y.y.y_` はプロバイダから指示されたアドレスで, 接続するプロバイダが提供しているネームサーバを すべて書いてください. `domain` に指定するのは このマシンのデフォルトのドメイン名で, おそらく 書かなくても問題は無いでしょう. このファイルの各エントリの詳細については, [.filename]#resolv.conf# のマニュアルページを参照してください. バージョン 2 以降の ppp を使用している場合には, `enable dns` コマンドを使用してネームサーバのアドレスを プロバイダに問い合わせるように指示することができます. 上の指定とは異なるアドレスをプロバイダが指定してきた場合 (または [.filename]#/etc/resolv.conf# でネームサーバが指定されていない場合), ppp はプロバイダが指定したアドレスで [.filename]#resolv.conf# を書きかえます. ==== `ppp` の設定 ユーザ ppp と `pppd` (カーネルレベルの PPP 実装) は どちらも [.filename]#/usr/shared/examples/ppp# ディレクトリに置かれた設定ファイルを使います. ここには設定ファイルのサンプルが用意されていて, ユーザ ppp の設定を おこなう際に大変参考になりますので, 削除したりしないでください. `ppp` の設定をするためには, 必要に応じていくつかのファイルを編集する必要が あります. 書き込む内容は, プロバイダが静的に IP アドレスを割り当てる (つまり, 固定の IP アドレスを一つ与えられて, 常にそれを使う) か, または動的に IP アドレスを割り当てる (つまり, PPP セッションごとに IP アドレスが変化する可能性がある) かということに ある程度依存します. [[userppp-staticIP]] ===== 静的 IP アドレスによる PPP 接続 まず [.filename]#/etc/ppp/ppp.conf# という設定ファイルを作成する必要があります. これは以下の例とほとんど同じようなものになるでしょう. [NOTE] ==== `:` で終る行は 1 カラム目から始め, その他の行はスペースまたはタブで以下の例のように 段をつける (インデントする) 必要があります. ==== [.programlisting] .... 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\\TTIMEOUT 40 CONNECT" 5 provider: 6 set phone "(123) 456 7890" 7 set login "TIMEOUT 10 \"\" \"\" gin:--gin: foo word: bar col: ppp" 8 set timeout 300 9 set ifaddr x.x.x.x y.y.y.y 255.255.255.0 0.0.0.0 10 add default HISADDR 11 enable dns .... ファイルでは行番号を取り除いておいてください. これは解説の際に参照する行を示すためにつけたものです. Line 1::: デフォルトエントリを指定します. このエントリ中のコマンドは ppp が起動された際に自動的に実行されます. Line 2::: モデムが接続されているデバイスを指定します. [.filename]#COM1:# は [.filename]#/dev/cuaa0# に, [.filename]#COM2:# は [.filename]#/dev/cuaa1# になります. Line 3::: 通信速度 (DTE 速度) を指定します. もし 115200 が使えない (最近のモデムなら大抵使えるはずですが) 場合には, かわりに 38400 を指定してみてください. Line 4::: ダイアルスクリプトを指定します. ユーザ PPP は man:chat[8] 言語に似た, 受信待ち文字列と 送信文字列の対からなるスクリプトを使用します. この言語の機能に関しては, マニュアルページを参照してください. Line 5::: 接続するプロバイダの名前 "provider" を エントリ名として指定します. Line 6::: このプロバイダの電話番号を指定します. 複数の電話番号を `:` や `|` で区切って指定することができます. これら区切り文字の違いについては, man:ppp[8] に 詳しく書かれています. 要約すると, 毎回違う番号に かけたいのであれば `:` を使います. 常に まず先頭の番号にかけてみて, つながらない時にだけ 2 番目以降の番号に かけたいのであれば `|` を使います. 例に示されているように, 常に電話番号全体を引用符で くくって (クォートして) おきます. Line 7::: ダイアルスクリプトと同様に, ログインスクリプトも chat 言語風の記述をおこないます. この例は, 以下のようなログインセッションを使用する プロバイダのためのものです: + [source,shell] .... J. Random Provider login: foo password: bar protocol: ppp .... + このスクリプトは必要に応じて 書きかえなければならないでしょう. 初めてスクリプトを書く時には, 予想した通りに 処理が進んだかどうかを確認するため, "chat" ログを とるようにしておいた方が良いでしょう. + PAP や CHAP を使用する場合には, ここでログインすることは ありませんから, ログイン文字列は空白のままにしておくべきです. 詳細については <>を参照してください. Line 8::: デフォルトの接続タイムアウト時間を (秒数で) 指定します. この例では, 300 秒間 通信がおこなわれなければ 自動的に接続を切るように指定しています. タイムアウトさせたくない場合には, この値を 0 に設定します. Line 9::: インタフェースのアドレスを指定します. 文字列 _x.x.x.x_ は プロバイダに割り当てられた IP アドレスで置きかえてください. 文字列 _y.y.y.y_ はプロバイダから指示されたゲートウェイ (接続先となるマシン) の IP アドレスで置きかえてください. プロバイダがゲートウェイのアドレスを 指示していない場合は, `10.0.0.2/0` を使用しておいてください. もし "仮の" アドレスを使用する必要がある場合には, <>に関する指示に従って, [.filename]#/etc/ppp/ppp.linkup# にエントリを作成していることを 確認してください. この行が省略されている場合, ppp を `-auto` モードで動作させることはできません. Line 10::: プロバイダのゲートウェイへの経路を デフォルトルートとして 追加します. 特殊文字列 `HISADDR` は, 9 行目で指定された ゲートウェイのアドレスで置きかえられます. `HISADDR` は 9 行目までは初期化されていませんので, その行よりも後でしか使えないことに 注意してください. Line 11::: ネームサーバのアドレスが正しいか どうかを確認するため, プロバイダに問い合わせをおこなうよう ppp に指示します. プロバイダがこの機能をサポートしていれば, ppp は [.filename]#/etc/resolv.conf# のネームサーバエントリを 正しいアドレスに更新することができます. 静的な IP アドレスを持っていて, 接続が完了する前にルーティングテーブルの エントリが正しく設定されているのであれば, [.filename]#ppp.linkup# に エントリを追加する必要はありません. しかし, この場合でもエントリを追加して, 接続が完了した時点で プログラムを呼び出したいことがあるかもしれません. これについては後ほど sendmail を例として説明します. これらの設定ファイルのサンプルが [.filename]#/usr/shared/examples/ppp# ディレクトリに 置かれています. [[userppp-dynamicIP]] ===== 動的 IP アドレスによる PPP 接続 プロバイダが静的な IP アドレスの割り当てをおこなっていない場合, `ppp` が相手側のホスト (ゲートウェイ) と交渉して, こちら側と相手側のアドレスを 決めるように設定することができます. これは, 起動時には"仮の"アドレスを使っておいて, 接続後に IP コンフィグレーション プロトコル (IPCP) を使用して `ppp` が IP アドレスを正しく設定できるようにすることで実現されます. <>に 以下の変更を加える以外は, [.filename]#ppp.conf# の設定は同じです: [.programlisting] .... 9 set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 .... 繰り返しますが, 行番号は取り除いておいてください. これは解説の際に参照する行を示すためにつけたものです. なお, 少なくともスペース 1 個分の段づけ (インデント) が必要です. Line 9::: `/` 文字の後ろの数字は, アドレス交渉の際に固定しておきたい ビットの数です. 場合によっては, もっと適切な IP アドレスを 指定しておきたいこともあるかもしれませんが, ほとんどの場合には 上の例の通りで問題ありません. + 最後の引数 (`0.0.0.0`) は, アドレスの交渉の際に `10.0.0.1` ではなく `0.0.0.0` を使用するよう ppp に指示するためのものです. `set ifaddr` コマンドの最初の引数として `0.0.0.0` を指定してはいけません. さもないと, `-auto` モードで動作させる際に 初期経路を設定することができなくなります. バージョン 1.X の ppp を使用する場合, [.filename]#/etc/ppp/ppp.linkup# にもエントリを作成しておく必要があります. [.filename]#ppp.linkup# は接続が確立された後に使用されます. この時点では, `ppp` は__実際に__どの IP アドレスを使うべきなのか わかっているはずです. 以下のエントリは存在する仮の経路を削除し, 正しい経路を作成します: [.programlisting] .... 1 provider: 2 delete ALL 3 add default HISADDR .... Line 1::: 接続を確立する際に, `ppp` は以下のルールに従って [.filename]#ppp.linkup# のエントリを検索します: まず [.filename]#ppp.conf# で使用されたのと同じラベルを探します. もし見つからなければ, ゲートウェイの IP アドレスのエントリを 探します. このエントリは 4 オクテットの IP アドレス形式の ラベルです. それでも まだエントリが見つからなければ, `MYADDR` エントリを探します. Line 2::: この行は, 使用する tun インタフェースに関する既存の経路を (ダイレクトルートのエントリを除き) すべて削除するよう `ppp` に指示します. Line 3::: この行は `HISADDR` への経路をデフォルトルートとして 追加するように ppp に指示します. `HISADDR` は IPCP で 決定されたゲートウェイの IP アドレスで置きかえられます. 詳細なサンプルについては, [.filename]#/usr/shared/examples/ppp/ppp.conf.sample# ファイル中のpmdemand エントリと [.filename]#/usr/shared/examples/ppp/ppp.linkup.sample# を参照してください. バージョン 2 の ppp から "sticky routes" が導入されました. `MYADDR` や `HISADDR` を含む `add` コマンドと `delete` コマンドを記憶して, `MYADDR` や `HISADDR` の アドレスが変化した際には経路の再設定をおこないます. したがって, これらのコマンドを [.filename]#ppp.linkup# に 繰り返し記述する必要は無くなりました. ===== かかってきた電話を `ppp` で受けるには かかってきた電話を `ppp` が受けるように設定する際に, そのマシンが LAN に接続されているのであれば, パケットを LAN に転送するかどうかを決定する必要があります. 転送をおこなう場合には, その LAN のサブネットから IP アドレスを ppp クライアントに割り当て, 以下のコマンドを指定するのが良いでしょう. [.programlisting] .... gateway_enable=YES .... ====== どの getty を使いますか? getty でダイアルアップサービスをおこなう場合の優れた解説が crossref:serialcomms[dialup,FreeBSD でダイアルアップサービスをおこなうための設定 ]にあります. `getty` に代わるものとしては, http://www.leo.org/~doering/mgetty/index.html[mgetty] があります. これは `getty` をより柔軟にしたもので, ダイアルアップ回線での使用を意図して 設計されています. `mgetty` を使う場合の利点は, `mgetty` が積極的にモデムと__通信する__ ということです. つまり, もし [.filename]#/etc/ttys# でポートを閉じている場合, モデムは電話をとらなくなります. 最近のバージョンの `mgetty` (0.99beta 以降) では, PPP ストリームの 自動検出もサポートされています. これにより, クライアント側で スクリプトを準備しなくてもサーバに アクセスすることができます. `mgetty` に関する, より詳細な情報については <> を参照してください. ====== ppp の実行許可 `ppp` は通常, ID 0 のユーザ (root) として動作しなければいけませんが, 以下で説明するように, `ppp` を通常のユーザとしてサーバモードで実行させたい 場合には, そのユーザを [.filename]#/etc/group# の `network` グループに 追加して, ppp を実行する許可を与えておかなければいけません. また, そのユーザが設定ファイル内の目的のエントリに アクセスできるように, 以下のように `allow` コマンドで許可を与えておく必要があります: [.programlisting] .... allow users fred mary .... このコマンドがデフォルトエントリに 書かれている場合には, 指定されたユーザは すべてのエントリをアクセスできるようになります. ====== 動的 IP ユーザのための ppp シェルの設定 [.filename]#/etc/ppp/ppp-shell# という名前で, 以下のような内容のファイルを 作成します: [.programlisting] .... #!/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 .... このスクリプトには実行可能属性をつけておきます. 次に, 以下のコマンドを実行し, [.filename]#ppp-dialup# という名前で このスクリプトへのリンクを作成します: [source,shell] .... # ln -s ppp-shell /etc/ppp/ppp-dialup .... すべてのダイアルアップ ppp ユーザのログイン__シェル__として このスクリプトを使用します. 以下は `pchilds` というユーザ名の ダイアルアップユーザを [.filename]#/etc/password# へ登録した場合の例です. (パスワードファイルを直接エディタで編集したりせず, `vipw` を使ってください) [.programlisting] .... pchilds:*:1011:300:Peter Childs PPP:/home/ppp:/etc/ppp/ppp-dialup .... 任意のユーザが読むことのできる, [.filename]#/home/ppp# ディレクトリを 作成します. [.filename]#/etc/motd# が表示されないようにするため, このディレクトリには以下のように大きさが 0 バイトのファイルを 作成しておきます. [source,shell] .... -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 シェルの設定 上記と同じように [.filename]#ppp-shell# ファイルを作成し, 静的な IP アドレスを割り当てるアカウントそれぞれについて [.filename]#ppp-shell# へのシンボリックリンクを作成します. 例えば, クラス C ネットワークの経路制御を必要とする, 三人のダイアルアップユーザ `fred`, `sam`, `mary` がいるとすると, 以下のコマンドを実行することになります: [source,shell] .... # 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` のログインシェルは [.filename]#/etc/ppp/ppp-mary# に なります). ====== 動的 IP ユーザのための ppp.conf の設定 [.filename]#/etc/ppp/ppp.conf# ファイルは, 大体以下のような内容になるでしょう: [.programlisting] .... 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 .... [NOTE] ==== 上の例のように段をつける (インデントする) 必要があることに注意してください. ==== `default:` エントリはセッションごとにロードされます. [.filename]#/etc/ttys# で有効にしてある各ダイアルアップ回線ごとに一つ, 上記の `ttyd0:` のようなエントリを作成します. 各行の相手側アドレスとして, それぞれ別の IP アドレスを 動的 IP ユーザのための IP アドレスのプールから割り当てておく必要があります. ====== 静的 IP ユーザのための [.filename]#ppp.conf# の設定 上のサンプルの [.filename]#/usr/shared/examples/ppp/ppp.conf# の内容に加えて, 静的に IP を割り当てられたダイアルアップユーザ それぞれのためのエントリを追加する必要があります. ここでも `fred`, `sam`, `mary` の例を使うことにしましょう. [.programlisting] .... 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 ユーザに対する経路制御情報も [.filename]#/etc/ppp/ppp.linkup# ファイルに書いておくべきでしょう. 以下の例ではクライアントの PPP リンクを経由する, クラス C の `203.14.101.0` ネットワークへの経路を追加しています. [.programlisting] .... 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, マイクロソフト拡張の詳細 [[userppp-mgetty]] ====== `mgetty` と AutoPPP `AUTO_PPP` オプションつきでコンパイルした `mgetty` を使えば, `mgetty` が PPP 接続の LCP フェーズを検出して, 自動的に PPP シェルを起動するように 設定することができます. しかし この場合, デフォルトの login/password シーケンスは発生しないので, ユーザの認証は PAP または CHAP を使っておこなう必要があります. このセクションでは, ユーザ (あなた) が問題なく `AUTO_PPP` オプションつきの `mgetty` (v0.99beta またはそれ以降) の設定, コンパイル, インストールができているものと仮定しています. [.filename]#/usr/local/etc/mgetty+sendfax/login.config# ファイルが 以下の行を含んでいることを確認してください: [.programlisting] .... /AutoPPP/ - - /etc/ppp/ppp-pap-dialup .... これにより, PPP 接続を検出したら `mgetty` が [.filename]#ppp-pap-dialup# スクリプトを実行するようになります. [.filename]#/etc/ppp/ppp-pap-dialup# という名前で, 以下のような内容のファイルを 作成します (このファイルには実行可能属性を つけておく必要があります): [.programlisting] .... #!/bin/sh exec /usr/sbin/ppp -direct pap .... さらに, かかってきた電話すべてを自分で扱うエントリを [.filename]#/etc/ppp/ppp.conf# に作成します. [.programlisting] .... pap: enable pap set ifaddr 203.14.100.1 203.14.100.20-203.14.100.40 enable proxy .... この方法でログインする それぞれのユーザは, PAP によるユーザ認証を おこなうために [.filename]#/etc/ppp/ppp.secret# ファイルにユーザ名とパスワードを 書いておくか, または [.filename]#/etc/password# ファイルを使うように, [.programlisting] .... enable passwdauth .... ユーザに静的な IP アドレスを割り当てる場合には, そのアドレスを [.filename]#/etc/ppp/ppp.secret# の第三引数として指定することができます. サンプルについては, [.filename]#/usr/shared/examples/ppp/ppp.secret.sample# を参照してください. ====== マイクロソフト拡張 クライアントからの要求に応じて, ppp が DNS や NetBIOS ネームサーバの アドレスを通知するように 設定をおこなうこともできます. バージョン 1.X の ppp で これらの拡張機能を有効にするには, 以下の行を [.filename]#/etc/ppp/ppp.conf# の適切なセクションに追加する必要があるでしょう. [.programlisting] .... enable msext set ns 203.14.100.1 203.14.100.2 set nbns 203.14.100.5 .... バージョン 2 以降の ppp では, 以下のようになります: [.programlisting] .... accept dns set dns 203.14.100.1 203.14.100.2 set nbns 203.14.100.5 .... これにより, クライアントはプライマリと セカンダリのネームサーバアドレス および NetBIOS ネームサーバホストを知ることができます. バージョン 2 以降の ppp では, `set dns` の行を省略した場合には [.filename]#/etc/resolv.conf# に書かれているネームサーバのアドレスを使用します. [[userppp-PAPnCHAP]] ===== PAP および CHAP による認証 いくつかのプロバイダでは, PAP または CHAP のいずれかの認証メカニズムを 使用して接続時の認証をおこなうように システムを設定しています. この場合, プロバイダは接続の際に `login:` プロンプトを送信せず, 最初から PPP で通信を始めようとするでしょう. PAP ではパスワードがそのまま送られてしまうため, CHAP に比べると安全性が 低くなりますが, このパスワードはシリアル回線のみを通して送られます. そのため, クラッカーが "盗み聞き" する余地は多くないので, 通常ここの セキュリティは問題にはなりません. <>または <>の セクションに戻って, 以下の変更をおこないます: [.programlisting] .... 7 set login ... 12 set authname MyUserName 13 set authkey MyPassword .... これまでと同様に, 行番号は取り除いておいてください. これは解説の際に参照する行を示すためにつけたものです. なお, 少なくともスペース 1 個分の段づけ (インデント) が必要です. Line 7::: PAP または CHAP を使用する場合, 通常 プロバイダはサーバへの ログインを必要としません. そのため, "set login" 文字列を 無効にしておかなければいけません. Line 12::: この行は PAP/CHAP ユーザ名を指定します. _MyUserName_ に 正しい値を入れておく必要があります. Line 13::: この行は PAP/CHAP パスワードを指定します. _MyPassword_ に 正しい値を入れておく必要があります. PAP と CHAP はデフォルトで両方とも 受け付けられるようになって いますが, PAP や CHAP を使用するという 意思を明示するために, + [.programlisting] .... 15 accept PAP .... または [.programlisting] .... 15 accept CHAP .... という行を追加しておくのも良いでしょう. ===== 動作中の ppp の設定変更 適切な診断ポートが設定されている場合には, バックグラウンドで動作中の `ppp` プログラムと通信することができます. この設定をおこなうためには, 以下の行を設定ファイルに追加しておきます: [.programlisting] .... set server /var/run/ppp-tun%d DiagnosticPassword 0177 .... これにより, ppp は指定された unix ドメインの ソケットをモニタして, クライアントから正しいパスワードを受け取った後に アクセスを許可します. このソケット名に含まれる `%d` は, この ppp が使用している [.filename]#tun# デバイスの デバイス番号で置きかえられます. 一旦ソケットの設定が終了したら, スクリプト中で man:pppctl[8] を 使用して, 動作中の ppp を操作することができるでしょう. [[userppp-final]] ==== システムの最終設定 これで `ppp` の設定は終りました. しかし `ppp` を動かす前に, まだ少し必要なことがあります. それらの設定は, すべて [.filename]#/etc/rc.conf# ファイルを 編集することでおこないます. (このファイルは以前には [.filename]#/etc/sysconfig# と呼ばれていました) このファイルを上から順に設定していきます. まずは `hostname=` の行が設定されていることを確認します. 例えば以下のように: [.programlisting] .... hostname="foo.bar.com" .... もしプロバイダが静的な IP アドレスとホスト名を割り当てているのなら, ホスト名としてそれを使うのが おそらくベストでしょう. 次に `network_interfaces` 変数を調べます. 必要に応じて (on demand) プロバイダにダイアルするようにシステムを設定したい場合には, [.filename]#tun0# デバイスがこのリストに追加されていることを確認しておきます. それ以外の場合には, tun0 デバイスをリストから削除しておきます. [.programlisting] .... network_interfaces="lo0 tun0" ifconfig_tun0= .... [NOTE] ==== `ifconfig_tun0` 変数が空で, [.filename]#/etc/start_if.tun0# という名前の ファイルが作成されていなければなりません. このファイルの内容は以下のようになります. [.programlisting] .... ppp -auto mysystem .... このスクリプトはネットワークの設定時に実行され, ppp デーモンを自動モードで立ち上げます. このマシンがもし LAN のゲートウェイであれば, `-alias` スイッチも使用したいと思うかもしれません. 詳細に関しては, マニュアルページを参照してください. ==== 以下のようにルータプログラムを `NO` に設定します. [.programlisting] .... router_enable="NO" .... `routed` は, `ppp` が作成したデフォルトのルーティングテーブル エントリを削除してしまう場合がありますので, (初期設定では起動されるようになっている) `routed` デーモンが 起動されないようにしておくことが重要です. `sendmail_flags` 行が `-q` オプションを含まないように 設定しておいた方がよいでしょう. さもないと, `sendmail` が アドレスを調べようとして発信をおこなってしまう場合があります. 以下のような設定で良いでしょう: [.programlisting] .... sendmail_flags="-bd" .... この結果, PPP リンクを立ち上げた時には いつでも以下のコマンドを実行して, キューにたまっているメールを `sendmail` に送信させる作業が必要になるでしょう. [source,shell] .... # /usr/sbin/sendmail -q .... [.filename]#ppp.linkup# 中で `!bg` コマンドを使用することで, これを自動的に おこなうこともできます: [.programlisting] .... 1 provider: 2 delete ALL 3 add 0 0 HISADDR 4 !bg sendmail -bd -q30m .... こうするのが嫌であれば, SMTP トラフィックをブロックするように "dfilter" を設定しておくこともできます. 詳細についてはサンプルファイルを参照してください. 後はマシンをリブートするだけです. リブートが終ったら, [source,shell] .... # ppp .... コマンドを実行し, 続いて PPP セッションを開始させるために `dial provider` と入力することもできますし, ([.filename]#start_if.tun0# スクリプトを作成していない場合に), 外部へのトラフィックが発生した時に, `ppp` が自動的に セッションを確立してくれるようにしたいのであれば, 以下のコマンドを実行することもできます. [source,shell] .... # ppp -auto provider .... ==== まとめ 要約すると, 初めて ppp を設定する際には, 以下のステップが不可欠です: クライアント側: [.procedure] ==== . カーネルに [.filename]#tun# デバイスが組み込まれていることを確認. . [.filename]#/dev# ディレクトリに [.filename]#tunX# デバイスファイルが 存在することを確認. . [.filename]#/etc/ppp/ppp.conf# にエントリを作成. ほとんどのプロバイダでは, [.filename]#pmdemand# の例で充分でしょう. . 動的 IP アドレスを使用するなら, [.filename]#/etc/ppp/ppp.linkup# に エントリを作成. . [.filename]#/etc/rc.conf# (または [.filename]#sysconfig#) ファイルを更新. . 必要に応じてダイヤル (demand dialing) したいのであれば, [.filename]#start_if.tun0# スクリプトを作成. ==== サーバ側: [.procedure] ==== . カーネルに [.filename]#tun# デバイスが組み込まれていることを確認. . [.filename]#/dev# ディレクトリに [.filename]#tunX# デバイスファイルが 存在することを確認. . (man:vipw[8] コマンドを使って) [.filename]#/etc/passwd# にエントリを作成. . このユーザのホームディレクトリに `ppp -direct direct-server` か何かを実行するプロファイルを作成. . [.filename]#/etc/ppp/ppp.conf# にエントリを作成. [.filename]#direct-server# の例で充分でしょう. . [.filename]#/etc/ppp/ppp.linkup# にエントリを作成. . [.filename]##/etc/rc.conf##ファイルを更新. ==== [[ppp]] == カーネル PPP の利用 === カーネル PPP の設定 PPP の設定を始める前に, `pppd` が [.filename]#/usr/sbin# にあり, また [.filename]#/etc/ppp# という ディレクトリが存在することを確認してください. `pppd` はふたつのモードで動作します. . "クライアント" モード. シリアル接続やモデムを利用して, そのマシンを 外部のネットワークに PPP 接続したい場合に用います. . "サーバ" モード. そのマシンがネットワーク上にあるときに, PPP を使って ほかのコンピュータを接続する際に用います. どちらの場合でも, オプションファイルを設定する必要があります ([.filename]#/etc/ppp/options# または, そのマシン上で PPP を使用する人が 複数いる場合には [.filename]#~/.ppprc#). また, ダイヤルとリモートホストへの接続をおこなうために, シリアル接続やモデムを 操作する, なんらかのソフトウェアが必要です (kermit が適しているでしょう). === PPP クライアントとしての動作 わたしは, CISCO ターミナルサーバの PPP 回線に接続するために, 下記のような [.filename]#/etc/ppp/options# を使用しています. [.programlisting] .... crtscts # enable hardware flow control modem # modem control line noipdefault # remote PPP server must supply your IP address. # if the remote host doesn't send your IP during IPCP # negotiation , remove this option passive # wait for LCP packets domain ppp.foo.com # put your domain name here : # put the IP of remote PPP host here # it will be used to route packets via PPP link # if you didn't specified the noipdefault option # change this line to : defaultroute # put this if you want that PPP server will be your # default router .... 接続方法: [.procedure] ==== . kermit (またはその他のモデム操作プログラム) を使ってリモートホストに ダイヤルし, 接続してください. そして, あなたのユーザ名とパスワード (必要 であれば, その他にもリモートホストで PPP を有効にするための操作) を入力 します. . kermit を抜けてください. (回線を切断せずに) . 下記のように入力します: + [source,shell] .... # /usr/src/usr.sbin/pppd.new/pppd /dev/tty01 19200 .... + (通信速度とデバイス名には, あなたの環境に適したものを入れてください) ==== これでこのコンピュータは PPP で接続されました. もし, なんらかの理由で 接続に失敗したならば, [.filename]#/etc/ppp/options# ファイルに `debug` オプションを追加して, 問題点を突き止めるために, コンソールに表示される メッセージを調べてください. 下記の [.filename]#/etc/ppp/pppup# スクリプトは, 上記の作業を すべて自動的におこないます: [.programlisting] .... #!/bin/sh ps ax |grep pppd |grep -v grep pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing pppd, PID=' ${pid} kill ${pid} fi ps ax |grep kermit |grep -v grep pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing kermit, PID=' ${pid} kill -9 ${pid} fi ifconfig ppp0 down ifconfig ppp0 delete kermit -y /etc/ppp/kermit.dial pppd /dev/tty01 19200 .... [.filename]#/etc/ppp/kermit.dial# は kermit 用のスクリプトで, ダイヤルして, リモートホストでの認証に必要なすべての処理をおこないます. (そのようなスクリプトの例は この文書の終わりに添付してあります) PPP 接続を切断するには, 下記のような [.filename]#/etc/ppp/pppdown# スクリプトを 使用します: [.programlisting] .... #!/bin/sh pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'` if [ X${pid} != "X" ] ; then echo 'killing pppd, PID=' ${pid} kill -TERM ${pid} fi ps ax |grep kermit |grep -v grep pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing kermit, PID=' ${pid} kill -9 ${pid} fi /sbin/ifconfig ppp0 down /sbin/ifconfig ppp0 delete kermit -y /etc/ppp/kermit.hup /etc/ppp/ppptest .... PPP が動作中かどうかを調べます ([.filename]#/usr/etc/ppp/ppptest#): [.programlisting] .... #!/bin/sh pid=`ps ax| grep pppd |grep -v grep|awk '{print $1;}'` if [ X${pid} != "X" ] ; then echo 'pppd running: PID=' ${pid-NONE} else echo 'No pppd running.' fi set -x netstat -n -I ppp0 ifconfig ppp0 .... モデム回線を切断します ([.filename]#/etc/ppp/kermit.hup#): [.programlisting] .... set line /dev/tty01 ; put your modem device here set speed 19200 set file type binary set file names literal set win 8 set rec pack 1024 set send pack 1024 set block 3 set term bytesize 8 set command bytesize 8 set flow none pau 1 out +++ inp 5 OK out ATH0\13 echo \13 exit .... 次は `kermit` の代わりに `chat` を使う方法です. pppd 接続を確立するためには, 次の二つのファイルの設定だけで十分です. [.filename]#/etc/ppp/options#: [.programlisting] .... /dev/cuaa1 115200 crtscts # enable hardware flow control modem # modem control line connect "/usr/bin/chat -f /etc/ppp/login.chat.script" noipdefault # remote PPP serve must supply your IP address. # if the remote host doesn't send your IP during # IPCP negotiation, remove this option passive # wait for LCP packets domain # put your domain name here : # put the IP of remote PPP host here # it will be used to route packets via PPP link # if you didn't specified the noipdefault option # change this line to : defaultroute # put this if you want that PPP server will be # your default router .... [.filename]#/etc/ppp/login.chat.script#: [NOTE] ==== (実際には一行になります.) ==== [.programlisting] .... ABORT BUSY ABORT 'NO CARRIER' "" AT OK ATDT CONNECT "" TIMEOUT 10 ogin:-\\r-ogin: TIMEOUT 5 sword: .... 正しくインストールし編集した後は, 必要な事はこれだけです [source,shell] .... # pppd .... このサンプルは主に Trev Roydhouse から寄せられた情報に基づいており, 承諾を得て使用しています. === PPP サーバとしての動作 [.filename]#/etc/ppp/options#: [.programlisting] .... crtscts # Hardware flow control netmask 255.255.255.0 # netmask ( not required ) 192.114.208.20:192.114.208.165 # ip's of local and remote hosts # local ip must be different from one # you assigned to the ethernet ( or other ) # interface on your machine. # remote IP is ip address that will be # assigned to the remote machine domain ppp.foo.com # your domain passive # wait for LCP modem # modem line .... 下記のような [.filename]#/etc/ppp/pppserv# スクリプトで, そのマシンを PPP サーバにすることができます. [.programlisting] .... #!/bin/sh ps ax |grep pppd |grep -v grep pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing pppd, PID=' ${pid} kill ${pid} fi ps ax |grep kermit |grep -v grep pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing kermit, PID=' ${pid} kill -9 ${pid} fi # reset ppp interface ifconfig ppp0 down ifconfig ppp0 delete # enable autoanswer mode kermit -y /etc/ppp/kermit.ans # run ppp pppd /dev/tty01 19200 .... PPP サーバを終了するには, この [.filename]#/etc/ppp/pppservdown# スクリプト を使用します: [.programlisting] .... #!/bin/sh ps ax |grep pppd |grep -v grep pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing pppd, PID=' ${pid} kill ${pid} fi ps ax |grep kermit |grep -v grep pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing kermit, PID=' ${pid} kill -9 ${pid} fi ifconfig ppp0 down ifconfig ppp0 delete kermit -y /etc/ppp/kermit.noans .... 下記の kermit スクリプトは, モデムの自動応答機能を有効, または無効にします ([.filename]#/etc/ppp/kermit.ans#): [.programlisting] .... set line /dev/tty01 set speed 19200 set file type binary set file names literal set win 8 set rec pack 1024 set send pack 1024 set block 3 set term bytesize 8 set command bytesize 8 set flow none pau 1 out +++ inp 5 OK out ATH0\13 inp 5 OK echo \13 out ATS0=1\13 ; change this to out ATS0=0\13 if you want to disable ; autoanswer mod inp 5 OK echo \13 exit .... この [.filename]#/etc/ppp/kermit.dial# スクリプトは, リモートホストに ダイヤルし, 認証手続きをするのに使用します. あなたは必要に応じて, これを 変更しないといけないでしょう. あなたのユーザ名とパスワードをこの スクリプトに書かなければいけませんし, モデムやリモートホストからの 応答によっては, 入力待ちの文を変更する必要もあります. [.programlisting] .... ; ; put the com line attached to the modem here: ; set line /dev/tty01 ; ; put the modem speed here: ; set speed 19200 set file type binary ; full 8 bit file xfer set file names literal set win 8 set rec pack 1024 set send pack 1024 set block 3 set term bytesize 8 set command bytesize 8 set flow none set modem hayes set dial hangup off set carrier auto ; Then SET CARRIER if necessary, set dial display on ; Then SET DIAL if necessary, set input echo on set input timeout proceed set input case ignore def \%x 0 ; login prompt counter goto slhup :slcmd ; put the modem in command mode echo Put the modem in command mode. clear ; Clear unread characters from input buffer pause 1 output +++ ; hayes escape sequence input 1 OK\13\10 ; wait for OK if success goto slhup output \13 pause 1 output at\13 input 1 OK\13\10 if fail goto slcmd ; if modem doesn't answer OK, try again :slhup ; hang up the phone clear ; Clear unread characters from input buffer pause 1 echo Hanging up the phone. output ath0\13 ; hayes command for on hook input 2 OK\13\10 if fail goto slcmd ; if no OK answer, put modem in command mode :sldial ; dial the number pause 1 echo Dialing. output atdt9,550311\13\10 ; put phone number here assign \%x 0 ; zero the time counter :look clear ; Clear unread characters from input buffer increment \%x ; Count the seconds input 1 {CONNECT } if success goto sllogin reinput 1 {NO CARRIER\13\10} if success goto sldial reinput 1 {NO DIALTONE\13\10} if success goto slnodial reinput 1 {\255} if success goto slhup reinput 1 {\127} if success goto slhup if < \%x 60 goto look else goto slhup :sllogin ; login assign \%x 0 ; zero the time counter pause 1 echo Looking for login prompt. :slloop increment \%x ; Count the seconds clear ; Clear unread characters from input buffer output \13 ; ; put your expected login prompt here: ; input 1 {Username: } if success goto sluid reinput 1 {\255} if success goto slhup reinput 1 {\127} if success goto slhup if < \%x 10 goto slloop ; try 10 times to get a login prompt else goto slhup ; hang up and start again if 10 failures :sluid ; ; put your userid here: ; output ppp-login\13 input 1 {Password: } ; ; put your password here: ; output ppp-password\13 input 1 {Entering SLIP mode.} echo quit :slnodial echo \7No dialtone. Check the telephone line!\7 exit 1 ; local variables: ; mode: csh ; comment-start: "; " ; comment-start-skip: "; " ; end: .... [[pppoe]] == PPP オーバイーサネット (PPPoE) の利用 以下の解説は, PPPoE として知られる, PPP オーバイーサネットの設定法です. === 必要なもの あなたのシステムで PPPoE を適切に機能させるためには, 以下のものが必要です. * FreeBSD 3.4やそれより新しいバージョンのカーネルソース * FreeBSD 3.4やそれより新しいバージョンのppp === カーネルコンフィギュレーション 以下に示すオプションをカーネルコンフィギュレーションファイルに 追加して, その後 crossref:kernelconfig[kernelconfig,新しいカーネルを コンパイルする]必要があります. * options NETGRAPH 以下は任意 * options NETGRAPH_PPPOE * options NETGRAPH_SOCKET この機能は実行時には有効ではありませんが, 要求に応じて ppp は関係のあるモジュールを 読み込みます. === [.filename]#ppp.conf# の設定 これは動作している [.filename]#ppp.conf# の 例です: [.programlisting] .... default: # or name_of_service_provider set device PPPoE:xl1 # replace xl1 with your ethernet device set mru 1492 set mtu 1492 set authname YOURLOGINNAME set authkey YOURPASSWORD set log Phase tun command # you can add more detailed logging if you wish set dial set login set ifaddr 10.0.0.1/0 10.0.0.2/0 add default HISADDR nat enable yes # if you want to enable nat for your local net papchap: set authname YOURLOGINNAME set authkey YOURPASSWORD .... extref:{faq}[-nat オプションを付けてPPPoE, PPPoEwithNAT]を起動する際には注意するべきです. === PPP の起動 以下を root 権限において実行することで, 起動させることができます: [source,shell] .... # ppp -ddial name_of_service_provider .... === システム起動時に PPP を立ち上げる [.filename]#/etc/rc.conf# ファイルに以下の行を追加 してください: [.programlisting] .... ppp_enable="YES" ppp_mode="ddial" ppp_nat="YES" ppp_profile="default" # or your provider .... [[slip]] == SLIP の利用 [[slipc]] === SLIPクライアントのセットアップ ここには FreeBSD マシンを静的アドレスのネットワークにつなげる場合の SLIPのセットアップの一つの方法を書いてあります. ホスト名を動的に割り当てる(つまり, ダイヤルアップするたびにアドレスが かわる)ためには, おそらくもっと凝ったことが必要です. まず, モデムがどのシリアルポートにつながっているか決めましょう. 私は [.filename]##/dev/cuaa1## から [.filename]##/dev/modem##へというシンボリックリンクを張り, コンフィグレーションではその名前だけを使っています. [.filename]##/etc## や[.filename]##.kermrc## など, システム全体に散らばっているファイルを修正する 必要がでるとまったく煩わしいのです! [NOTE] ==== ここで, [.filename]##/dev/cuaa0##は [.filename]##COM1##であり, [.filename]##cuaa1##は[.filename]##COM2##です. ==== カーネルのコンフィグレーションファイルに [.programlisting] .... pseudo-device sl 1 .... という記述があるのを確認してください. これは [.filename]#GENERIC# カーネルに含まれている ので削除していない限り大丈夫でしょう. ==== 最初の設定 [.procedure] ==== . [.filename]#/etc/hosts# ファイルにあなたのマシンのゲートウェイとネームサーバ を加えてください. 私のは以下のようになっています. + [.programlisting] .... 127.0.0.1 localhost loghost 136.152.64.181 silvia.HIP.Berkeley.EDU silvia.HIP silvia 136.152.64.1 inr-3.Berkeley.EDU inr-3 slip-gateway 128.32.136.9 ns1.Berkeley.edu ns1 128.32.136.12 ns2.Berkeley.edu ns2 .... + . [.filename]#/etc/host.conf# ファイル中で ``hosts``が``bind`` よりも前にあること を確認してください. さもないとヘンなことが起こるかもしれません. . [.filename]#/etc/rc.conf# ファイルを編集してください. なお, お使いの FreeBSD が 2.2.2 よりも前のバージョンのものの場合は, [.filename]#/etc/sysconfig# を編集してください. .. 行 + [.programlisting] .... hostname=myname.my.domain .... + を編集してホスト名をセットしてください. 完全なInternetホスト名を与えるべきです. .. 行 + [.programlisting] .... network_interfaces="lo0" .... + を + [.programlisting] .... network_interfaces="lo0 sl0" .... + へ変更することにより ネットワークインタフェースのリストに sl0 を加えてください. .. 行 + [.programlisting] .... ifconfig_sl0="inet ${hostname} slip-gateway netmask 0xffffff00 up" .... + を加えて sl0 のスタートアップフラグをセットしてください. .. 行 + [.programlisting] .... defaultrouter=NO .... + を + [.programlisting] .... defaultrouter=slip-gateway .... + へ変更してデフォルトのルータを 指定してください. + . 次の + [.programlisting] .... domain HIP.Berkeley.EDU nameserver 128.32.136.9 nameserver 128.32.136.12 .... + という内容を含むファイル [.filename]#/etc/resolv.conf# を作ってください. 見ればわかるように, これらはネームサーバホストを設定しています. もちろん, 実際のドメイン名やアドレスは あなたの環境に依存します. . root と toor (及びパスワードを持っていない他のアカウントすべて) のパスワード を設定してください. passwdコマンドを使いましょう. [.filename]#/etc/passwd# や [.filename]#/etc/master.passwd# といったファイルを編集してはいけません! . マシンを再起動して正しいホスト名で 立ち上がることを確認してください. ==== ==== SLIP接続をおこなう [.procedure] ==== . モデムを起動, つながったらプロンプトで ``slip``とタイプし, マシン名と パスワードを入力してください. 入力する必要があるものは環境に よって異なります. 私は次のようなスクリプトでkermitを使っています. + [.programlisting] .... # kermit setup set modem hayes set line /dev/modem set speed 115200 set parity none set flow rts/cts set terminal bytesize 8 set file type binary # The next macro will dial up and login define slip dial 643-9600, input 10 =>, if failure stop, - output slip\x0d, input 10 Username:, if failure stop, - output silvia\x0d, input 10 Password:, if failure stop, - output ***\x0d, echo \x0aCONNECTED\x0a .... + (もちろん, ホスト名とパスワードは変える必要があります). 接続するためには kermit のプロンプトで ``slip``とタイプするだけです. + [NOTE] ====== ファイルシステムのどんなところにもプレインテキスト にパスワードを書いておくのは一般的にはよくありません. 覚悟の上で やってください. 私は単に不精なだけです. ====== + . ここでkermitから抜け出し (``z``でkermitをサスペンドできます), root で + [source,shell] .... # slattach -h -c -s 115200 /dev/modem .... + と入力しましょう. もしルータの向う側のホストへ ``ping`` できるなら接続成功です! もしうまく いかなければslattachへの引数として ``-c`` の代わりに``-a``とやってみてください. ==== ==== 接続の切り方 slattachを殺すためにrootで [source,shell] .... # kill -INT `cat /var/run/slattach.modem.pid` .... とタイプしてください. そして kermit に戻り (もしkermitをサスペンドしていたなら `fg`), kermitから抜けてください (`q`). slattachのマニュアルページにはインタフェースを落すために ``ifconfig sl0 down``をしなければいけないと書いていますが, 私には差がないように見えます. (``ifconfig sl0``とやっても同じ結果が得られる.) 時にはモデムがキャリアを落すのを 拒絶するかもしれません(私のは よくそうなります). その時は単にkermitをスタートしてまた終了 してください. 普通は2回目で落ちます. ==== トラブルシューティング もし動かなければ自由に私に質問してください. 今までいろんな人がつまずいた のは次のようなことです. * slattach で `-c` や `-a` を使わなかった(私はなぜこれが致命的になり得るのか わかりませんが, このフラグを付けることで少なくとも一人の 問題は解決しました.) * `sl0` の代わりに `s10` を使った(いくつかのフォントでは見分けるのは難しい かもしれません). * インタフェースの状態を見るために `ifconfig sl0` をやってみてください. 私は, + [source,shell] .... # ifconfig sl0 sl0: flags=10 inet 136.152.64.181 --> 136.152.64.1 netmask ffffff00 .... + となります. * また, pingが "no route to host" というメッセージを返す時には ``netstat -r``でルーティングテーブルを確認しましょう. 私のは, + [source,shell] .... # netstat -r Routing tables Destination Gateway Flags Refs Use IfaceMTU Rtt Netmasks: (root node) (root node) Route Tree for Protocol Family inet: (root node) => default inr-3.Berkeley.EDU UG 8 224515 sl0 - - localhost.Berkel localhost.Berkeley UH 5 42127 lo0 - 0.438 inr-3.Berkeley.E silvia.HIP.Berkele UH 1 0 sl0 - - silvia.HIP.Berke localhost.Berkeley UGH 34 47641234 lo0 - 0.438 (root node) .... + となります. (これはたくさんのファイルを転送した後でのもので, あなたの見る数字はもっと小さいかも しれません). [[slips]] === SLIPサーバのセットアップ方法 この文書の目的は, SLIPサーバ機能を FreeBSDシステムのもとで設定するため の助言を提供することです. SLIPサーバ機能を設定するということは, リモー トの SLIPクライアントがログインできるようにするために, 自動的に接続処 理をおこなうようにすることです. この文書は著者の経験に基づいておりますが, 実際のシステム構成や要望は異なりますから, すべての疑問にこの文書が答え ることはできません. なお, ここでの助言を試みた結果, あなたのシステムへ の悪影響やデータの損失が生じたとしても, 著者が責任を持つことはできませ んのでご了解をお願いします. [[slips-prereqs]] ==== 前提 この文書の内容はテクニカルなものなので, 前提知識が必要です. すなわち, TCP/IPネットワークプロトコルについての知識, 特に, ネットワークとノード のアドレス指定をはじめ, ネットワークアドレスマスク, サブネット化, ルー ティング, および RIPなどのルーティングプロトコルなどに関する知識を前提 としています. ダイヤルアップサーバで SLIP機能を設定するためには, これ らの概念についての知識が必要ですから, もし不案内であると思われる方は, O'Reilly & Associates, Inc.から出版されている Craig Hunt氏の _TCP/IP Network Administration_ (ISBN 0-937175-82-X)か, または Douglas Comer氏の TCP/IPプロトコルに関する一連の書籍をお読みください. 前提知識に加え, さらに, モデムの設定が完了しており, そのモデムを経由し てログインできるように, システムファイル群が適切に記述できているものと 仮定しています. もしモデムの準備ができていないときには, あらかじめダイヤ ルアップ機能の設定についてのチュートリアルをお読みください. Webブラ ウザが使えるのであれば http://www.FreeBSD.org/[ http://www.FreeBSD.org/ ] におけるチュー トリアルの一覧を調べてください. あるいは, この文書を見つけた場所を調べ て, [.filename]#dialup.txt# やそれに類似した名前の文書をお読みください. 関連す るマニュアルページとしては, シリアルポート向けデバイスドライバについて の man:sio[4] をはじめ, モデムからのログインを 受理できるようにシステ ムを設定するための man:ttys[5], man:gettytab[5], man:getty[8], man:init[8] など, さらには, シリアルポート関連パラメータ ( たと えば直接接続シリアルインタフェースの `clocal` ) についての man:stty[1] なども助けになるかもしれません. ==== 概要 一般的な設定内容で FreeBSDを SLIPサーバとして利用すると, その動作は次 のようになります. まず, SLIPユーザが FreeBSD による SLIPサーバへ電話し て, SLIP専用IDでログインします. なお, このIDを持ったユーザはシェルとし て [.filename]#/usr/sbin/sliplogin# を使います. この `sliplogin` は, ファイル [.filename]#/etc/sliphome/slip.hosts# の中から, ログインIDと一致する 記述行を探します. もし一致する行があれば, ログインしたシリアル回線を, 利用可能な SLIPインタフェースへ接続し, その後にシェルスクリプト [.filename]#/etc/sliphome/slip.login# で SLIPインタフェースを設定します. ===== SLIPサーバへのログイン例 仮に SLIPユーザIDが `Shelmerg` とします. すると, [.filename]#/etc/master.passwd# における `Shelmerg` のエントリは次のよ うなものになります (実際には一つの行に続いている) . [.programlisting] .... Shelmerg:password:1964:89::0:0:Guy Helmer - SLIP:/usr/users/Shelmerg:/usr/sbin/sliplogin .... `Shelmerg` がログインすると, `sliplogin` は, ファイル [.filename]#/etc/sliphome/slip.hosts# からユーザIDと一致する行を探しま す. いま仮に, [.filename]#/etc/sliphome/slip.hosts# に次のような記述がなされていたとします. [.programlisting] .... Shelmerg dc-slip sl-helmer 0xfffffc00 autocomp .... `sliplogin` が上記のエントリを見つけると, _Shelmerg_ が使用して いるシリアル回線を, 利用可能な SLIPインタフェースのなかの最初のものへ 接続し, 次の内容の [.filename]#/etc/sliphome/slip.login# を実行します. [.programlisting] .... /etc/sliphome/slip.login 0 19200 Shelmerg dc-slip sl-helmer 0xfffffc00 autocomp .... もし上記の手順が正常に処理されると, [.filename]#/etc/sliphome/slip.login# は, `sliplogin` が割り当てた SLIPインタフェース (この例では [.filename]#slip.login# で与えられたパラメータのうちで最初の値である SLIP インタフェース0である) に対して `ifconfig` を実行し, ローカル IPアドレス (`dc-slip`)をはじめ, リモート IPアドレス (`sl-helmer`), SLIPインタフェースへのネットワークマスク (`0xfffffc00`), およびその他のフラグ (`autocomp`)を設定 します. 逆に, さきほどの手順が正常に終了しなかった場合, 通常は `sliplogin` は十分な情報を syslog の `daemon` 機能経由で [.filename]#/var/log/messages# へ記録します ( man:syslogd[8] や man:syslog.conf[5] のマニュアルページを参照のうえ, さらに [.filename]#/etc/syslog.conf# を調べて `syslogd` がどのファイルへ記 録するかを確認のこと) . 例はこのくらいにして, さっそくシステムのセットアップを始めてみましょう. ==== カーネルのコンフィグレーション FreeBSD のデフォルトのカーネルには, 通常, 二つの SLIPインタフェースが 準備されています ([.filename]#sl0# と [.filename]#sl1#) . これらのインタフェー スが使用中のカーネルに準備されているかどうかを調べるには, `netstat -i` を実行してください. `netstat -i` の出力例 [source,shell] .... Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll ed0 1500 0.0.c0.2c.5f.4a 291311 0 174209 0 133 ed0 1500 138.247.224 ivory 291311 0 174209 0 133 lo0 65535 79 0 79 0 0 lo0 65535 loop localhost 79 0 79 0 0 sl0* 296 0 0 0 0 0 sl1* 296 0 0 0 0 0 .... `netstat -i` の出力に [.filename]#sl0# と [.filename]#sl1# のインタフェー スが含まれているということから, カーネルには二つの SLIPインタフェー スが組み込まれているということを示しています. (`sl0` と `sl1` に付いたアスタリスクは, `netstat -i` の実行時点で はインタフェースが "ダウン" していることを表しています. ) なお, パケットのフォワード機能は FreeBSD のデフォルトのカーネルでは設定 されていません (すなわちルータとしては動作しない) . もしインターネット 接続ホストについての RFC要件 ( RFC 1009 [Requirements for Internet Gateways] と 1122 [Requirements for Internet Hosts - Communication Layers], おそらく 1127 [A Perspective on the Host Requirements RFCs] も ) に準拠して, FreeBSDによる SLIPサー バをルータとして動作させたいときには, [.filename]#/etc/rc.conf# (バージョ ン 2.2.2 より前の FreeBSD では [.filename]#/etc/sysconfig#) ファイル の `gateway_enable` 変数を `YES` としてください. もし古いシステ ムで [.filename]#/etc/sysconfig# ファイルすらないときには, 次のコマン ドを [.filename]#/etc/rc.local# へ追加してください. [.programlisting] .... sysctl -w net.inet.ip.forwarding = 1 .... この新しい設定を有効とするには, リブートする必要があります. デフォルトのカーネルコンフィグレーションファイル ([.filename]#/sys/i386/conf/GENERIC#) の最後の部分に, 次のような行がありま す. [.programlisting] .... pseudo-device sl 2 .... この行によって, 使用可能な SLIPデバイスの総数が決まります. すなわち, 行 末の数値が, 同時に動作可能な SLIP接続の最大数となります. カーネルの再構築については, crossref:kernelconfig[kernelconfig,FreeBSDカー ネルのコンフィグレーション] を参照ください. ==== Sliploginのコンフィグレーション すでにご説明したように, [.filename]##/usr/sbin/sliplogin## のコンフィグレー ションのために, 3種類のファイルが[.filename]##/etc/sliphome## ディレクトリに あります (`sliplogin` についての実際のマニュアルページとしては man:sliplogin[8] を参照のこと) . ファイル [.filename]##slip.hosts## は SLIPユーザおよびその IPアドレスを決めます. 通常, ファイル [.filename]##slip.login## は, SLIPインタフェースを設定することだけに使 用します. [.filename]##slip.logout## はオプションのファイルで, [.filename]##slip.login## で設定した内容を, シリアル接続が終了した時点で解除 するときに使用します. ===== [.filename]#slip.hosts# のコンフィグレーション [.filename]#/etc/sliphome/slip.hosts# には, 少なくとも 4 つの項目をホワイ トスペース (スペースやタブ) で区切って指定します. * SLIPユーザのログインID * SLIPリンクのローカル (SLIPサーバ側) アドレス * SLIPリンクのリモートアドレス * ネットワークマスク ホスト名をローカルおよびリモートのアドレスとして 記述できます (IPアドレ スの決定は, [.filename]#/etc/host.conf# の指定内容に応じて, [.filename]#/etc/hosts# か DNSのいずれかによって決定される) . また, ネット ワークマスクも [.filename]#/etc/networks# ファイルに記述された名前を参照す ることで, 指定することもできると思います. これまでの例としてあげたシス テムでの [.filename]#/etc/sliphome/slip.hosts# は次のようになります. [.programlisting] .... # # login local-addr remote-addr mask opt1 opt2 # (normal,compress,noicmp) # Shelmerg dc-slip sl-helmerg 0xfffffc00 autocomp .... それぞれの行の最後には, 次に示すオプションを一つ以上指定できます. * `normal` - ヘッダを圧縮しない * `compress` - ヘッダを圧縮する * `autocomp` - リモートの設定に応じて, ヘッダを圧縮する * `noicmp` - ICMPパケットを禁止する ( "ping" パケットは送出されず, バンド幅を占有しない) なお, FreeBSDバージョン2の初期リリースの `sliplogin` は, 旧 FreeBSD 1.xでは有効であった上記のオプションを無視していましたので, `normal`, `compress`, `autocomp`, そして `noicmp` などのオプションは FreeBSD 2.2でサポートされるまでは効果がありませんでした (た だしこれらのフラグを使うためには [.filename]#slip.login# スクリプトへ記述する 必要がある) . SLIPリンクでのローカルとリモート向けのアドレスの 選び方は, TCP/IPサブネッ トを専用に割り当てるか, または "プロキシ ARP" を SLIPサーバへ用いるかによって違います ( "プロキシ ARP" という用語のここでの使い方は本来のものではないが, 説明のためにこの用語を使う) . もし, どちらの方式を選ぶべきか判らなかったり, IPアドレスの割り当て方が不明のときには, 上述の <> の節で紹介した TCP/IP関連書籍を参考になさるか, またはあなたの IPネットワークを管理している方に相談なさると よいでしょう. 独立したサブネットを SLIPクライアントへ適用するときには, すでに割り当てられている IPネットワーク番号の範囲からサブネット番号を割り当て, 同 時にそのサブネットの範囲内で有効な IPアドレスを SLIPクライアントの IP 番号として割り当てる必要があります. さらに, この SLIPサブネットから SLIPサーバを経由して最も近い IPルータへの経路を静的に設定するか, または `gated` を FreeBSDによる SLIPサーバへインストールして, 適当 なルーティングプロトコルを使って, SLIPサーバ経由のサブネットへの経路情 報をルータ群へ通知できるように設定するか, のいずれかをおこなう必要があります. "プロキシ ARP" 方式を採用するときには, SLIPクライアント向けの IPアドレス として, SLIPサーバのサブネットの範囲から 選んで割り当てるとともに, man:arp[8] コマンドを使うために [.filename]##/etc/sliphome/slip.login## と[.filename]##/etc/sliphome/slip.logout## のスクリプトを修正して, SLIPサー バにおける ARPテーブル内のプロキシ ARPエントリへ 反映させる必要がありま す. ===== [.filename]#slip.login# のコンフィグレーション ファイル [.filename]#/etc/sliphome/slip.login# の一般的な内容は次にようになります. [.programlisting] .... #!/bin/sh - # # @(#)slip.login 5.1 (Berkeley) 7/1/90 # # generic login file for a slip line. sliplogin invokes this with # the parameters: # 1 2 3 4 5 6 7-n # slipunit ttyspeed loginname local-addr remote-addr mask opt-args # /sbin/ifconfig sl$1 inet $4 $5 netmask $6 .... この [.filename]#slip.login# ファイルの役目は単に, SLIPインタフェースにつ いてのローカルとリモートのアドレス, およびそのネットワークマスクを `ifconfig` コマンドで設定することです. もし "プロキシ ARP" 方式を採用する (SLIPクライアントへ独立したサブネットを使わない) ときには, ファイル [.filename]#/etc/sliphome/slip.login# は次のような内容になります. [.programlisting] .... #!/bin/sh - # # @(#)slip.login 5.1 (Berkeley) 7/1/90 # # generic login file for a slip line. sliplogin invokes this with # the parameters: # 1 2 3 4 5 6 7-n # slipunit ttyspeed loginname local-addr remote-addr mask opt-args # /sbin/ifconfig sl$1 inet $4 $5 netmask $6 # Answer ARP requests for the SLIP client with our Ethernet addr /usr/sbin/arp -s $5 00:11:22:33:44:55 pub .... この [.filename]#slip.login# で追加された行 `arp -s $5 00:11:22:33:44:55 pub` は, SLIPサーバにおける ARPテーブルへ新たなエントリを作ります. SLIPサーバ は, この ARPエントリが作られると, SLIPクライアントの IPアドレスと話し たい他の IPノードが要求してきたときにはいつも, SLIPサーバ の Ethernet MACアドレスを返すようになります. 上記の例を実際に流用なさるときには, 例にある Ethernet MACアドレス (`00:11:22:33:44:55`) を, あなたのシステムの実際のEthernetカー ドの MACアドレスと置き換えなければ "プロキシ ARP" はうまく動作しません! SLIPサーバの Ethernet MACアドレスを調べるには `netstat -i` コマ ンドを利用してください. 実行結果の第2行は次のようなものになるはずです. [source,shell] .... ed0 1500 0.2.c1.28.5f.4a 191923 0 129457 0 116 .... この例での Ethernet MACアドレスは `00:02:c1:28:5f:4a` であると 読みます. なお man:arp[8] における MAC アドレスの指定に際しては, コマンド `netstat -i` が付けた Ethernet MACアドレスのピリオド記 号をコロン記号と置き換え, かつ単一桁の 16 進数にはゼロを先頭に加える必 要があります. この指定についての正確な情報は man:arp[8] を参照く ださい. [NOTE] ==== [.filename]#/etc/sliphome/slip.login# と [.filename]#/etc/sliphome/slip.logout# を作成したならば, ファイル属性の "実行" ビット (すなわち `chmod 755 /etc/sliphome/slip.login /etc/sliphome/slip.logout`) を 設定しなければなりません. さもなければ `sliplogin` が うまく実行されません. ==== ===== [.filename]#slip.logout# のコンフィグレーション ファイル [.filename]#/etc/sliphome/slip.logout# は必ずしも必要なものではあ りません (ただし "プロキシ ARP" を利用する場合を除く) . もしこのファイルを 作成するときには, 次に示す標準的な [.filename]#slip.logout# スクリプト例を 参考にしてください. [.programlisting] .... #!/bin/sh - # # slip.logout # # logout file for a slip line. sliplogin invokes this with # the parameters: # 1 2 3 4 5 6 7-n # slipunit ttyspeed loginname local-addr remote-addr mask opt-args # /sbin/ifconfig sl$1 down .... "プロキシ ARP" を利用する場合, この [.filename]#/etc/sliphome/slip.logout# を 使って, 特定の SLIPクライアント向けの ARPエントリを削除したくなるようなときがあります. [.programlisting] .... #!/bin/sh - # # @(#)slip.logout # # logout file for a slip line. sliplogin invokes this with # the parameters: # 1 2 3 4 5 6 7-n # slipunit ttyspeed loginname local-addr remote-addr mask opt-args # /sbin/ifconfig sl$1 down # Quit answering ARP requests for the SLIP client /usr/sbin/arp -d $5 .... コマンド `arp -d $5` は, SLIPクライアントがログインした 際に, "プロキシ ARP" を使った [.filename]#slip.login# によって追加され た ARPエントリを削除します. これによって, 繰り返して利用することができるわけです. 必ず, [.filename]#/etc/sliphome/slip.logout# を作成した後に, 実行ビットを設定し てください ( `chmod 755 /etc/sliphome/slip.logout` ) . ==== ルーティングについての考慮点 "プロキシ ARP" 方式を利用せずに SLIPクライアントとその他のネットワーク (Internetも含む) の構成要素との間でパケットをルーティングするときには, SLIPサーバ経由で SLIPクライアントが属するサブネットまでの経路を, 最も 近いデフォルトのルータ群へ静的な経路情報として 追加しなければならないか, または `gated` を FreeBSDによる SLIPサーバへインストールして, SLIP サブネットについての経路情報を, 適当なルーティングプロトコルでルー タ群へ通知できるように設定するか, のどちらかをおこなわなければなりません. ===== 静的な経路 静的な経路を最も近いデフォルトの ルータ群へ追加することが困難なことがあ ります (経路情報を追加できる権限がなければそもそも不可能となる). もし あなたの組織に複数のルータで構成された ネットワークがあるならば, ある種 のルータ (たとえば Ciscoや Proteonなど) は, 静的な経路を SLIPサブネッ トへ使うようにルータを設定しなければならないだけでなく, その静的経路を 他のどのルータへ知らせるのかもあらかじめ 指定しておく必要がありますから, 静的経路に基づくルーティングを軌道に乗せるには それなりの専門的技術やト ラブルシューティングやコツが必要だと思います. ===== ``gated``の稼働 静的経路についての頭痛への代替手段は, `gated` を FreeBSDによる SLIPサー バへインストールして, 適切なルーティングプロトコル (RIP/OSPF/BGP/EGP) を使って SLIPサブネットについての経路情報を他のルータへ知らせるように 設定することです. crossref:ports[ports,ports コレクション]から `gated` を用いることもできますし, link:ftp://ftp.gated.merit.edu/research.and.development/gated/[GateD 匿名 FTP サイト] から探して自分自身で構築することもで きます. この文章を執筆時点の最新バージョンは [.filename]#gated-R3_5Alpha_8.tar.Z# であり, このファイル "だけで" FreeBSDで 動作させることができます. `gated` についてのすべての情報と文書 は http://www.gated.merit.edu/[Merit GateD コンソーシアム] からはじまる Web 上で入手でき ます. `gated` のコンパイルとインストールを行ったならば, 独自の 設定のために [.filename]#/etc/gated.conf# ファイルを記述してください. 次の 例は, 筆者が FreeBSDによる SLIP サーバで使っている内容と類似のものです. [.programlisting] .... # # gated configuration file for dc.dsu.edu; for gated version 3.5alpha5 # Only broadcast RIP information for xxx.xxx.yy out the ed Ethernet interface # # # tracing options # traceoptions "/var/tmp/gated.output" replace size 100k files 2 general ; rip yes { interface sl noripout noripin ; interface ed ripin ripout version 1 ; traceoptions route ; } ; # # Turn on a bunch of tracing info for the interface to the kernel: kernel { traceoptions remnants request routes info interface ; } ; # # Propagate the route to xxx.xxx.yy out the Ethernet interface via RIP # export proto rip interface ed { proto direct { xxx.xxx.yy mask 255.255.252.0 metric 1; # SLIP connections } ; } ; # # Accept routes from RIP via ed Ethernet interfaces import proto rip interface ed { all ; } ; .... この [.filename]#gated.conf# ファイルの例では, SLIPのサブネット _xxx.xxx.yy_ についての経路情報を RIPを使って Ethernetへブロー ドキャストしています. もし [.filename]#ed# ドライバ以外の Ethernetドライバを使うのであれば, [.filename]#ed# インタフェースの記述を適切なものに置き換えてくだ さい. またこの例では, ``gated``の動作をデバッグするために, [.filename]#/var/tmp/gated.output# へトレース情報を出力するように指示して います. ``gated`` が希望通りに動作したならば, このトレースオプショ ンを止めることができます. なお, 例における _xxx.xxx.yy_ を, あ なた自身の SLIPサブネットのネットワークアドレスに換えてください (また ``proto direct`` 部分のネットワークマスクも換えることを忘れないこ と) . ``gated`` のコンパイルとインストールが終了し, コンフィグレーショ ンファイルの作成も完了したら, FreeBSDシステムではデフォルトの ``routed``に代わって ``gated`` を起動してください. そのため には, [.filename]#/etc/netstart# の [.filename]#routed/gated# 起動パラメータを 適切な値に設定してください. ``gated`` のコマンドラインパラメータにつ いての情報は, ``gated`` のマニュアルページを参照してください. diff --git a/documentation/content/ja/books/handbook/security/_index.adoc b/documentation/content/ja/books/handbook/security/_index.adoc index 56f1ad8df2..c35dd56eba 100644 --- a/documentation/content/ja/books/handbook/security/_index.adoc +++ b/documentation/content/ja/books/handbook/security/_index.adoc @@ -1,1818 +1,1818 @@ --- -title: 第14章 セキュリティ +title: 第13章 セキュリティ part: パートIII. システム管理 -prev: books/handbook/users +prev: books/handbook/boot next: books/handbook/disks showBookMenu: true -weight: 18 +weight: 17 path: "/books/handbook/" --- [[security]] = セキュリティ :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 -:sectnumoffset: 14 +:sectnumoffset: 13 :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/security/ ifdef::env-beastie[] ifdef::backend-html5[] :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [[security-synopsis]] == この章では 物理的もしくは仮想的に関わらず、 セキュリティは幅広いトピックであり、 業界全体がセキュリティとともに成長しています。 システムおよびネットワークを安全にする標準的な方法は数多く文書化されており、 FreeBSD のユーザも、 攻撃や侵入者から守る方法を理解しなければなりません。 この章では、セキュリティの基礎や技術について説明します。 FreeBSD システムは、複数のレイヤに関連するセキュリティを提供します。 そして、安全性を高めるためにサードパーティ製のユーティリティを利用することもできます。 この章を読むと、以下のことがわかります。 * FreeBSD における基本的なシステムセキュリティの考え方 * FreeBSD で利用できるさまざまな暗号化手法 * ワンタイムパスワード認証の設定方法 * man:inetd[8] と組み合わせて TCP Wrappers を設定する方法 * FreeBSD における Kerberos の設定方法 * IPsec を設定して VPN を構築する方法 * FreeBSD にける OpenSSH の設定および使用方法 * ファイルシステム ACL (アクセス制御リスト) の使用方法 * Ports Collection からインストールされたサードパーティ製ソフトウェア packages を Portaudit を使って監査する方法 * FreeBSD セキュリティ勧告の利用方法 * プロセスアカウンティングがどのようなものか、 FreeBSD 上で有効にする方法について * リソース制限データベースとは何か、 この仕組みを使ったユーザ資源の管理方法 この章を読む前に、次のことが必要になります。 * FreeBSD およびインターネットの基本概念の理解 [[security-intro]] == はじめに セキュリティを高めることはすべての人の責任です。 システムに弱い侵入ポイントが存在すると、侵入者は重要な情報を得たり、 ネットワーク全体に被害を及ぼすことができるようになります。 多くのセキュリティのトレーニングでは、 情報システムの機密性 (confidentiality)、 完全性 (integrity) および可用性 (availability) を意味するセキュリティの 3 要素である CIA が取り扱われます。 CIA の 3 要素は、 コンピュータセキュリティの基本となる考えです。 顧客やエンドユーザは、データのプライバシーを期待します。 彼らは、データが変更されないことや、 情報が隠されていることを期待します。 彼らはまた、いつでも情報にアクセスできることを期待します。 これらは、システムの機密性、完全性、可用性を構成します。 セキュリティのプロフェッショナルは、CIA を守るために、多層防衛の戦略を採用します。 この多層防衛戦略ではセキュリティのレイアを複数用意することで、 一つのレイヤが破られても、 セキュリティシステム全体が破られることを防ぎます。 システムの管理者は、ファイアウォールを単に有効にするだけではなく、 ネットワークもしくはシステムを安全に保つ必要があります。 アカウントを監査し、バイナリの完全性、 悪意のあるツールがインストールされていないことを確認する必要があります。 このために、 管理者は脅威がどのようなものかを理解する必要があります。 [[security-threats]] === 脅威 コンピュータセキュリティおける脅威とは何でしょうか？ 長年、脅威はリモートの攻撃者、 すなわち遠隔からの許可のないシステムへのアクセスを企てる人々と考えられていました。 今日では、この定義は従業員、悪意のあるソフトウェア、 不正なネットワークデバイス、自然災害、セキュリティの脆弱性、 そして競合する会社でさえも含めるように拡張されています。 毎日、数千ものシステムおよびネットワークが攻撃され、 数百ものシステムが許可なくアクセスされています。 簡単なアクシデントといったものから、リモートからの攻撃、 産業スパイであったり、以前働いていた従業員からの攻撃といったケースもあります。 システムのユーザとしては、 間違いがセキュリティ違反に繋がった場合には、 可能性のある問題をセキュリティチームに報告することが重要です。 管理者としては、脅威を把握し、 その脅威の影響を小さくするように準備をしておくことが重要です。 [[security-groundup]] === ボトムアップアプローチ セキュリティを考える上で、 しばしばボトムアップアプローチが一番良い方法となります。 この考えでは、管理者が基本的なアカウント、システム設定を行ってから、 サードパーティ製ユーティリティの設定、 そしてネットワークレイヤに設定を広げていきます。 システムポリシーおよび手続きを行う上では、 このような設定の側面があります。 ビジネスの多くの環境では、 使用するデバイスの設定に対するセキュリティポリシがすでに策定されています。 このポリシには、最低限エンドユーザのワークステーション、 デスクトップ、携帯電話やラップトップといったモバイルデバイス、および 製品および開発サーバの両方に対するセキュリティの設定が含まれているべきです。 多くの場合には、コンピュータのセキュリティを考える際に、 標準作業手続書 (SOP) がすでに存在します。 わからなければ、セキュリティチームに尋ねてください。 [[security-accounts]] === システムおよびユーザアカウント システムを安全にするにあたり、最も適切な出発点は、 アカウントの監査です。 ルートアカウントのパスワードが強力であること、 シェルアクセスを必要としないアカウントは無効にすることを確実におこなってください。 また、権限を必要とするユーザに対しては、 package:security/sudo[] をインストールして、 アクセスが必要となるアプリケーションのみにアクセスを許可するようにしてください。 root ユーザのパスワードは、決して共有すべきではありません。 アカウントへのアクセスを無効にする方法は二通りあります。 一つ目の方法は、アカウントをロックする方法です。例として、 toor アカウントをロックする方法を以下に示します。 [source,shell] .... # pw lock toor .... このコマンドは、アカウントの設定を "toor:*:0:0::0:0:Bourne-again Superuser:/root:" から "toor:*LOCKED**:0:0::0:0:Bourne-again Superuser:/root:" へと変更します。 ときには (おそらく追加のサービスのために)、 この方法が使えない場合があります。 そのような場合には、以下の例のように、 シェルを /sbin/nologin に変更することで、 ログインアクセスを拒否できます。 [source,shell] .... # chsh -s /usr/sbin/nologin toor .... [NOTE] ==== 他のユーザのシェルは、スーパーユーザのみが変更できます。 通常のユーザが行おうとすると失敗します。 ==== アカウント情報は、以下のように最後のエントリが "nologin" シェルとなります。 [.programlisting] .... toor:*:0:0::0:0:Bourne-again Superuser:/root:/usr/sbin/nologin .... [.filename]#/usr/sbin/nologin# シェルは、 man:login[1] コマンドがこのユーザにシェルを割り当てることをブロックします。 [[security-sudo]] === アカウントの権限を拡大する 場合によっては、 システム管理者へのアクセスを他のユーザと共有する必要があります。 FreeBSD はこのために二つの方法を用意しています。 第一の方法は推奨されませんが、 ルートのパスワードを共有し、ユーザを `wheel` グループに加える方法です。 これを行うにには、[.filename]#/etc/group# を編集し、 最初のグループの最後にユーザを追加してください。 ユーザはカンマ区切りで管理されています。 権限の拡大をする適切な方法は、 package:security/sudo[] port を使う方法です。 この port は、追加の監査、よりきめ細かいユーザ管理、および ユーザを man:service[8] のような権限が与えられたコマンのみの実行に制限することもできます。 インストールが終わったら、 `visudo` インタフェースを使って [.filename]#/usr/local/etc/sudoers# ファイルを編集してください。 以下の例では、新しく webadmin グループが作成され、 `trhodes` ユーザがこのグループに追加されます。 その後、ユーザに package:apache24[] を再起動するアクセス権限を与えます。 この手続きは以下のようになります。 [source,shell] .... # pw groupadd webadmin -M trhodes -g 6000 .... [source,shell] .... # visudo .... [.programlisting] .... %webadmin ALL=(ALL) /usr/sbin/service apache24 * .... ローカルのユーザ管理において、 package:security/sudo[] は、 非常に貴重なリソースを提供します。 また、パスワードを不必要にして、デフォルトを man:ssh[1] 鍵の方法だけにすることもできます。 man:sshd[8] 経由のパスワードによるログインを無効にし、 `sudo` へのローカルパスワードのみを使うようにするには、 <> をご覧ください。 [[security-passwords]] === パスワード パスワードは、テクノロジーにおける必要悪です。 パスワードは極めて複雑であるだけではなく、 パスワードを保護する強力なハッシュメカニズムもまた必要となります。 この文書を書いている時点では、 FreeBSD は `crypt()` ライブラリで DES, MD5, Blowfish, SHA256 および SHA512 に対応しています。 デフォルトは SHA512 であり、 強度の弱い暗号へは変更すべきではありません。 しかしながら、Blowfish を好むユーザもおります。 DES を除く各メカニズムでは、 開始の文字、使用しているハッシュメカニズムを識別可能な特徴を持っています。 MD5 メカニズムでは、シンボルは "$" の符号です。 SHA256 または、 SHA512 では、シンボルは "$6$"、 そして Blowfish は "$2a$" です。 暗号強度の弱いパスワードを使用している場合には、 次回のログイン時にユーザが man:passwd[1] を実行して再ハッシュ化することを促すべきです。 [NOTE] ==== この文書を書いている時点で、Blowfish は AES でなければ、 FIPS (Federal Information Processing Standards) に準拠もしていません。 そのため、使用できない環境があります。 ==== ネットワークに接続しているシステムについては、 二要素認証を使用すべきです。 この認証では、通常あなたが所有する要素と知っている要素が用いられます。 FreeBSD のベースシステムに含まれている OpenSSH および ssh-keys では、 ネットワークへのすべてのログインにおける二要素認証の交換で、 パスワードを使用すべきではありません。 より詳細な情報については、ハンドブックの <> 節をご覧ください。 Kerberose のユーザは、ネットワークで OpenSSH を実装するために追加の変更が必要になるでしょう。 [[security-rkhunter]] === バックドアおよびルートキット バックドアおよびルートキットは、 それらがインストールされた後に脅威となります。 インストールされると、この悪意のあるソフトウェアは、 攻撃者のために侵入口を設置します。 実際的には、システムが一度汚染された後に、調査が行われ、 消去されます。 慎重なセキュリティやシステムエンジニアでさえも、 攻撃者が残したソフトウェアを見逃してしまうという恐ろしいリスクが存在しています。 バックドアまたはルートキットソフトウェアは、 管理者にとって役に立つことが一つあります。 それは、一度検出すると、 システムのどこかが危険に冒されていることの痕跡となります。 しかし、通常この種のアプリケーションは、とてもうまく隠れています。 バックドアおよびルートキットを検出するツールが存在しており、 それうちの一つが、 package:security/rkhunter[] です。 インストール後、以下のコマンドでシステムをチェックできます。 実行すると多くの情報が出力されます。 [source,shell] .... # rkhunter -c .... このプロセスを実行中に kbd:[ENTER] キーを何度か押す必要があります。 完了すると、ステータスメッセージが画面に表示されます。 このメッセージは、チェックしたファイルの量、疑わしいファイルの数、 可能性のあるルートキット等の情報を含みます。 チェックの最中、隠されたファイル、 OpenSSH プロトコルの選択、そして、 時には、インストールされているソフトウェアの漸弱性のバージョンに関する一般的なセキュリティの警告が出力されます。 すぐに、もしくはより詳細な解析が行われた後に、対応が可能です。 管理者は皆、 担当しているシステム上で何が実行されているかを把握している必要があります。 rkhunter, lsof や man:netstat[1] および man:ps[1] といったネイティブのツールは、 システムに関するかなり多くの情報を与えてくれます。 正常な状態がどのような状態であるかを把握しておき、 本来と違う状況になった場合には、質問をしたり、 疑い深くなってください。 セキュリティが破られることを避けることは理想ですが、 破られたことを把握することは必須です。 [[security-ids]] === バイナリ検証 システムファイルおよびバイナリの検証は、 システム管理者およびセキュリティチームに対して、 システムの変更に関する情報を提供してくれるため重要です。 いかなるシステムにおいても、システム管理チームの知らないところで、 内部のコマンドやアプリケーションは変更すべきではありません。 システムの変更ををモニタリングするソフトウェアアプリケーションは、 侵入検知システム (Intrusion Detection System) または IDS と呼ばれます。 FreeBSD は、基本的な IDS システムをネイティブで提供しています。 実際に、毎晩の man:periodic[8] セキュリティに関するメールの中では、 管理者に変更点を通知します。 情報はローカルに保存されているので、 悪意のあるユーザが変更し、情報を "欺く" 可能性があります。 そのため、バイナリの署名の別のセットを作成して、 読み取り専用の root 所有のディレクトリ、できれば、 USB ディスクまたは rsync サーバといったシステムとは別のシステムに保存してください。 まず最初に、シードを生成する必要があります。 これは、数値定数で、ハッシュ値の生成やハッシュ値の検証で使われます。 このシードがないと、 ファイルのチェックサムの値を偽ったり検証が可能になります。 以下の例では、シードは `-s` フラグで指定されています。 最初に以下のコマンドを用いて [.filename]#/bin# のハッシュ値およびチェックサムを生成してください。 [source,shell] .... # mtree -s 3483151339707503 -c -K cksum,sha256digest -p /bin > bin_chksum_mtree .... このコマンドの出力は以下のようになります。 [source,shell] .... # mtree: /bin checksum: 3427012225 .... [.filename]#bin_cksum_mtree# ファイルを見ると、 以下のような出力となります。 [.programlisting] .... # user: root # machine: dreadnaught # tree: /bin # date: Mon Feb 3 10:19:53 2014 # . /set type=file uid=0 gid=0 mode=0555 nlink=1 flags=none . type=dir mode=0755 nlink=2 size=1024 \ time=1380277977.000000000 \133 nlink=2 size=11704 time=1380277977.000000000 \ cksum=484492447 \ sha256digest=6207490fbdb5ed1904441fbfa941279055c3e24d3a4049aeb45094596400662a cat size=12096 time=1380277975.000000000 cksum=3909216944 \ sha256digest=65ea347b9418760b247ab10244f47a7ca2a569c9836d77f074e7a306900c1e69 chflags size=8168 time=1380277975.000000000 cksum=3949425175 \ sha256digest=c99eb6fc1c92cac335c08be004a0a5b4c24a0c0ef3712017b12c89a978b2dac3 chio size=18520 time=1380277975.000000000 cksum=2208263309 \ sha256digest=ddf7c8cb92a58750a675328345560d8cc7fe14fb3ccd3690c34954cbe69fc964 chmod size=8640 time=1380277975.000000000 cksum=2214429708 \ sha256digest=a435972263bf814ad8df082c0752aa2a7bdd8b74ff01431ccbd52ed1e490bbe7 .... コンピュータのホスト名、現在の日付と時間、man:mtree[8] を実行したユーザの情報すべてがこのレポートには含まれています。 また、各バイナリに対するチェックサム、サイズ、タイムスタンプおよび SHA256 ダイジェストも含まれています。 バイナリ署名の検証のために、 以下のコマンドを実行すると、現在の署名のリストを読み込み、 結果を出力します。 [source,shell] .... # mtree -s 3483151339707503 -p /bin < bin_chksum_mtree >> bin_chksum_output .... このコマンドを実行すると、すでにチェックサムを生成している [.filename]#/bin# に対して、同様のチェックサムを生成します。 このコマンドを実行してから変更が行われていないので、 [.filename]#bin_chksum_output# への主力は空となります。 変更が行われた場合をシミュレートするために、 [.filename]#/bin/cat# ファイルの日付を man:touch[1] を使って変更して、 再度検証のコマンドを実行してみます。 [source,shell] .... # touch /bin/cat .... [source,shell] .... # mtree -s 3483151339707503 -p /bin < bin_chksum_mtree >> bin_chksum_output .... [source,shell] .... # cat bin_chksum_output .... [.programlisting] .... cat changed modification time expected Fri Sep 27 06:32:55 2013 found Mon Feb 3 10:28:43 2014 .... package:security/aide[] のような、 より高度な IDS システムもありますが、 ほとんどのケースにおいて、 man:mtree[8] は管理者が必要とする機能を提供します。 悪意のあるユーザが、 シード値およびチェックサムの出力を見れないようにすることが重要です。 [[security-tuning]] === セキュリティのためのシステムの調整 システムの機能の多くは、man:sysctl[8] を使って調整できます。 Denial of Service (DOS) スタイルの攻撃を避けるためのセキュリティ機能に対しても同様です。 この節では、より重要な調整についても触れています。 man:sysctl[8] により、設定が変更された時はいつでも、 望まない危害が起こる可能性は高まり、 システムの可用性に影響します。 システム全体の設定を変更する時には、 システムの CIA を考える必要があります。 以下では、man:sysctl[8] の一覧、 および変更がシステムにどのように影響するかを説明します。 デフォルトでは、FreeBSD のカーネルはセキュリティレベル -1 で起動します。 このセキュリティレベルは、 変更不可のファイルフラグを外したり、 すべてのデバイスに対して読み込みおよび書き込みができたりするので、 "insecure mode" と呼ばれます。 このセキュアレベルは、管理者または man:init[8] による起動時のスクリプトにより変更されない限り -1 のままです。 [.filename]#/etc/rc.conf# において、 `kern_securelevel_enable` を `YES` とし、 `kern_securelevel` に必要とする値を設定することで、 システム起動時にセキュアレベルを高めることができます。 これらの設定についてのより詳細な情報については、 man:security[7] および man:init[8] をご覧ください。 [WARNING] ==== `securelevel` を大きくしすぎると、 Xorg が動かなくなったり、他の問題が起きる可能性があります。 デバッグの心づもりをしてください。 ==== つぎに変更を検討すべき man:sysctl[8] は、 net.inet.tcp.blackhole および net.inet.udp.blackhole です。 これらを設定すると、閉じたポートに対して届く SYN パケットはドロップされ、 RST レスポンスを返しません。 通常は、RST を返し、 そのポートが閉じられていることを伝えます。 これにより、システムに対する "ステルス" スキャンに対し、ある程度の防御となります。 net.inet.tcp.blackhole を "2"、 net.inet.udp.blackhole を "1" に設定してください。 詳細な情報について man:blackhole[4] をご覧ください。 さらに、net.inet.icmp.drop_redirect および net.inet.ip.redirect も設定すべきです。 これら 2 つの man:sysctl[8] は、リダイレクト攻撃を防ぐ助けとなるでしょう。 リダイレクト攻撃は、 故意に通常のネットワークでは必要としないような大量の ICMP タイプ 5 のパケットを発生します。 そのため net.inet.icmp.drop_redirect を "1"、 net.inet.ip.redirect を "0" に設定して下さい。 ソースルーティングは、 内部ネットワーク上でルーティングできないアドレスを検出したりアクセスするための方法です。 通常ルーティングできないアドレスは、 意図してルーティングできないようにしているので、 この設定はおそらく無効にすべきです。 この機能を無効にするには、 net.inet.ip.sourceroute および net.inet.ip.accept_sourceroute を "0" に設定してください。 ブロードキャストアドレスに対するすべての ICMP エコーリクエストは、ドロップしてください。 ネットワーク上のコンピュータがサブネットにあるすべてのホストにメッセージを送る必要がある場合には、 メッセージはブロードキャストアドレスに送られます。 外部のホストについては、 このような送信をする必要はないので、 外部からブロードキャストへのリクエストをすべて拒否するように、 net.inet.icmp.bmcastecho を "0" に設定してください。 まだ多くの man:sysctl[8] が man:security[7] で説明されています。 さらに多くの情報を調べることが推奨されます。 [[one-time-passwords]] == ワンタイムパスワード デフォルトで、FreeBSD は One-time Passwords In Everything (OPIE) に対応しています。 OPIE はデフォルトでは MD5 ハッシュを使用します。 三種類の異なる「パスワード」があります。 まず一つ目は、通常の UNIX(R) スタイル、もしくは Kerberos のパスワードです。 二つ目は、man:opiekey[1] によって生成され、 man:opiepasswd[1] およびログインプロンプトが受け付けるワンタイムパスワードです。 三つ目のパスワードは、man:opiekey[1] と場合により `opiepasswd` に対してワンタイムパスワードを生成するのに使われる "秘密のパスワード" です。 秘密のパスワードは、UNIX(R) パスワードと何の関連性もありません。 両者を同一に設定することは可能ですが、お奨めしません。古い UNIX(R) パスワードは長さが 8 文字に制限されていました 。 これに対し、OPIE の秘密のパスワードには 8 文字の制限はありません。 6 語から 7 語からなるパスフレーズがふつうです。ほとんどの部分で、 OPIE システムは UNIX(R) のパスワードシステムと完全に独立して動作するようになっています。 パスフレーズに加え、OPIE システムにとって重要な 2 種類のデータがあります。一つは "シード (seed: 種)" または "キー (key: 鍵)" と呼ばれるもので、2 つの文字と 5 つの数字で構成されます。もう一つは "シーケンス番号 (iteration count)" で、1 から 100 までの整数です。 OPIE はここまでに述べたデータを利用してワンタイムパスワードを生成します。 その方法は、まずシードと秘密のパスフレーズを連結し、 それに対してシーケンス番号の回数だけ MD5 ハッシュを繰り返し計算します。 そしてその結果を 6 つの短い英単語に変換します。 この 6 つの英単語がワンタイムパスワードです。 認証システム (主は PAM) は、 前回最後に受け付けたワンタイムパスワードを記録しています。 そして、その前回のワンタイムパスワードと、 ユーザが入力したワンタイムパスワードを 1 回ハッシュ関数にかけた結果とが一致した場合に、 このユーザは認証されます。 一方向ハッシュ関数を使っているので、 もし正しく認証されたワンタイムパスワードが一回盗聴されたとしても、 次回以降に使われる複数のワンタイムパスワードを生成することは不可能です。 シーケンス番号はログインが成功するたびに一つずつ減らされて、 ユーザとログインプログラムの間で同期が取られます。 シーケンス番号が 1 まで減ったら、 OPIE を再度初期化する必要があります。 このプロセスに関連するいくつかのプログラムがあります。 man:opiekey[1] は、シーケンス番号と、シードと、 秘密のパスフレーズを受け付けて、ワンタイムパスワード 1 つ、 または一連のワンタイムパスワードの一覧を生成します。 man:opiepasswd[1] は、OPIE の初期化に加え、パスワード、 シーケンス番号やシードを変更するためにも使用されます。 このプログラムを実行するには、秘密のパスフレーズか、 または、シーケンス番号とシードとワンタイムパスワードの 1 組かの、どちらかを与えます。 man:opieinfo[1] は、 認証ファイル ([.filename]#/etc/opiekeys#) を調べて、 プログラムを起動したユーザの現在のシーケンス番号とシードを表示します。 4 種類の異なる操作があります。 1 つ目は、man:opiepasswd[1] を信頼できる通信路上で利用して、 最初にワンタイムパスワードを設定したり、 秘密のパスフレーズやシードを変更する操作です。 2 つ目は、同じことを行うために man:opiepasswd[1] を信頼できない通信路上で利用する操作です。 この場合は信頼できる通信路経由の man:opiekey[1] を併用します。3 つ目は、man:opiekey[1] を使い、信頼できない通信路を通じてログインする操作です。 4 番目は、man:opiekey[1] を使って複数のワンタイムパスワードを一気に生成する操作です。 ここで生成した複数のワンタイムパスワードは、 メモしたり印刷したりして携帯し、 信頼できる通信路が一切ないところからの接続に利用できます。 (訳注: ワンタイムパスワードを記録した紙をなくさないこと! 電話番号や IP アドレス、ユーザ名を一緒にメモしていたら最悪です!!) === 信頼できる通信路での初期化 OPIE を初めて初期化するには、 man:opiepasswd[1] を実行してください。 [source,shell] .... % opiepasswd -c [grimreaper] ~ $ opiepasswd -f -c Adding unfurl: Only use this method from the console; NEVER from remote. If you are using telnet, xterm, or a dial-in, type ^C now or exit with no password. Then run opiepasswd without the -c parameter. Using MD5 to compute responses. Enter new secret pass phrase: Again new secret pass phrase: ID unfurl OTP key is 499 to4268 MOS MALL GOAT ARM AVID COED .... `Enter new secret pass phrase:` または `Enter secret password:` というプロンプトに対して、 パスワードまたはパスフレーズを入力してください。 このパスワードは、 ログインするときに使うワンタイムパスワードを生成するために使うものであり、 ログインのためのパスワードではありません。 "ID" から始まる行は、1 回分のパラメータで、 ログイン名とシーケンス番号とシードです。 ログインするときには、 システム側がこれらのパラメータを覚えていて表示してくれるので、 これらのパラメータを覚えておく必要はありません。 最後の行が、今述べたパラメータと入力された秘密のパスワードから計算されたワンタイムパスワードです。 次にログインするときに打ち込むべきワンタイムパスワードがこれです。 === 信頼できない通信路での初期化 信頼できない通信路を使って秘密のパスフレーズを初期化または変更するためには、 man:opiekey[1] を実行するための信頼できる通信路を用意しておく必要があります。 たとえばそれは、 信頼できるマシンのシェルプロンプトだったりするでしょう。 (訳注: ここでの通信路とはマシンそのものになります。 信頼できるマシンとは、 信頼できる人がしっかり管理しているマシンということです)。 他に準備しておくものとして、シーケンス番号 (100 は適切な値といえるでしょう) と、場合によっては自分で考えた、 またはランダムに生成されたシードがあります。 信頼できない通信路を使うときには、man:opiepasswd[1] を使ってコンピュータを初期化してください。 [source,shell] .... % opiepasswd Updating unfurl: You need the response from an OTP generator. Old secret pass phrase: otp-md5 498 to4268 ext Response: GAME GAG WELT OUT DOWN CHAT New secret pass phrase: otp-md5 499 to4269 Response: LINE PAP MILK NELL BUOY TROY ID mark OTP key is 499 gr4269 LINE PAP MILK NELL BUOY TROY .... デフォルトのシードで構わなければ、kbd:[Return] を押してください。アクセスパスワードを入れる前に、 あらかじめ用意しておいた信頼できる通信路へ移って、 先ほどと同じパラメータを入力します。 [source,shell] .... % opiekey 498 to4268 Using the MD5 algorithm to compute response. Reminder: Do not use opiekey from telnet or dial-in sessions. Enter secret pass phrase: GAME GAG WELT OUT DOWN CHAT .... 信頼できない通信路の方に戻って、 生成されたワンタイムパスワードをコピーして対応するプログラムに入力します。 === ワンタイムパスワードを一つ生成する OPIE を初期化したら、 ログイン時には以下のようなプロンプトが出てくるでしょう。 [source,shell] .... % telnet example.com Trying 10.0.0.1... Connected to example.com Escape character is '^]'. FreeBSD/i386 (example.com) (ttypa) login: <ユーザ名> otp-md5 498 gr4269 ext Password: .... OPIE のプロンプトには便利な機能が備わっています。 パスワードプロンプトに対して、 kbd:[Return] を押すとエコーモードに切り替わり、 タイプした文字がそのまま見えるようになるのです。 これは、 紙に印刷していたりするワンタイムパスワードを手で入力しなければならない場合に役立つ機能です。 次に、 このログインプロンプトに対して入力するワンタイムパスワードを生成してください。 これは、man:opiekey[1] プログラムを使える信頼できるマシン上で行わなければなりません。 このプログラムには Windows(R), Mac OS(R) および FreeBSD 版があります。 どちらも、 コマンドラインからシーケンス番号とシードを指定しなければなりません。 ログインしようとしているマシンのログインプロンプトから直接カットアンドペーストすると楽でしょう。 信頼できるシステムで [source,shell] .... % opiekey 498 to4268 Using the MD5 algorithm to compute response. Reminder: Do not use opiekey from telnet or dial-in sessions. Enter secret pass phrase: GAME GAG WELT OUT DOWN CHAT .... ワンタイムパスワードが生成されたので、 ログインを続けてください。 === 複数のワンタイムパスワードを生成する 都合によっては、 信頼できるマシンや信頼できる通信路が一切確保できないようなことがあるでしょう。 このような場合には、man:opiekey[1] を使って複数のワンタイムパスワードを生成できます。 たとえば [source,shell] .... % opiekey -n 5 30 zz99999 Using the MD5 algorithm to compute response. Reminder: Do not use opiekey from telnet or dial-in sessions. Enter secret pass phrase: 26: JOAN BORE FOSS DES NAY QUIT 27: LATE BIAS SLAY FOLK MUCH TRIG 28: SALT TIN ANTI LOON NEAL USE 29: RIO ODIN GO BYE FURY TIC 30: GREW JIVE SAN GIRD BOIL PHI .... `-n 5` という引数によって 5 個のワンタイムパスワードを順に生成します。 また `30` は、 最後のシーケンス番号となるべき数字です。出力は使う順番とは _逆_ に出力されていることに注意してください (訳注: 一番最初に使うワンタイムパスワードは一番最後に出力されたものです)。 もしあなたがセキュリティに偏執するなら、 この結果を紙と鉛筆を使って手で書き移した方がよいかもしれません。 そうでなければ、この結果を印刷すると良いでしょう。 ここで、 出力の各行はシーケンス番号とそれに対応する一回分のワンタイムパスワードです。 消費済みのワンタイムパスワードをペンで消していってください。 === UNIX(R) パスワードの利用を制限する OPIE は、ログインセッションの IP アドレスをベースとした UNIX(R) パスワードの使用を制限できます。 関連ファイルは、[.filename]#/etc/opieaccess# で、 デフォルトで用意されています。 このファイルの詳細や、 このファイルを使用する際に考慮すべきセキュリィについては man:opieaccess[5] を確認してください。 以下は [.filename]#opieaccess# の例です。 [.programlisting] .... permit 192.168.0.0 255.255.0.0 .... この行では、(なりすましされやすい) IP ソースアドレスが、 ある値やマスクにマッチするユーザに対して、 UNIX(R) パスワードをいつでも許可します。 もし [.filename]#opieaccess# のどのルールにも一致しなければ、 デフォルトでは非 OPIE ログインは使えません。 [[tcpwrappers]] == TCP Wrappers TCP Wrappers は、 すべてのサーバデーモンに対するサポートをその管理下で提供できるように、 crossref:advanced-networking[network-inetd,「inetd 「スーパサーバ」」] の機能を拡張します。 この方法を使うことで、ログへの対応、 接続に対してメッセージを返したり、 内部の接続だけを許可するようにデーモンを設定することが可能となります。 これらの機能のいくつかはファイアウォールでも実装できますが、 TCP Wrappers は、 システムを守るためのレイヤを追加し、 ファイアウォールが提供する以上の管理機能を提供します。 TCP Wrappers は、 適切に設定されたファイアウォールの置き換えと考えるべきではありません。 TCP Wrappers は、 ファイアウォールや他のセキュリティ強化のツールと組み合わせて使うべきです。 === 初期設定 FreeBSD 上で TCP Wrappers を有効にするには、 [.filename]#rc.conf# から `-Ww` オプションで man:inetd[8] サーバが起動されることを確認してください。 その後、[.filename]#/etc/hosts.allow# を適切に設定してください。 [NOTE] ==== 他の TCP Wrappers の実装と異なり、 [.filename]#hosts.deny# は廃止されました。 すべての設定オプションは [.filename]#/etc/hosts.allow# に書かれている必要があります。 ==== 最も簡単な設定におけるデーモンの接続ポリシは、 [.filename]#/etc/hosts.allow# の中で、 オプションごとに許可またはブロックするように設定するというものです。 FreeBSD のデフォルトの設定では、man:inetd[8] から起動されたすべてのデーモンの接続を許可します。 基本的な設定は、通常 `daemon : address : action` という形式です。ここで、 `daemon` は、 man:inetd[8] が起動するデーモンの名前です。 `address` の部分は、有効なホスト名、 IP アドレスまたは、 括弧 ([ ]) で囲まれた IPv6 アドレスです。 `action` は、 `allow` または `deny` です。 TCP Wrappers は、 最初にマッチしたルールが適用されます。 これは、設定ファイルに対するルールにマッチするかどうかのスキャンは、 昇順に行われることを意味しています。 マッチすると、ルールが適用され、 検索のプロセスは終了します。 例として、POP3 の接続を package:mail/qpopper[] デーモン経由で許可するには、以下の行を [.filename]#hosts.allow# に追加してください。 [.programlisting] .... # This line is required for POP3 connections: qpopper : ALL : allow .... この行を追加したら、 man:inetd[8] を再起動してください。 [source,shell] .... # service inetd restart .... === 高度な設定 TCP Wrappers は、 接続を取り扱う以上の制御を行う高度な設定も提供しています。 ある時は、 接続しているホストまたはデーモンにコメントを返すことが適切であることがあります。 別の場合では、おそらくログエントリを記録したり、 管理者にメールで送る必要があることもあるでしょう。 またその他の状況としては、 サービスをローカルの接続のみの使用に制限する必要がある場合もあります。 これらはすべて、`ワイルドカード` と呼ばれる設定のオプション (拡張文字および外部コマンドの実行) で可能となります。 ==== 外部コマンド 接続は拒否しなければならないが、 その理由を接続の確立を試みた相手に送りたい状況を考えてください。 このアクションは、`twist` を使うことで実現可能です。 接続が試みられると、`twist` はシェルコマンドまたはスクリプトを実行します。 この場合の例は、 [.filename]#hosts.allow# に書かれています。 [.programlisting] .... # The rest of the daemons are protected. ALL : ALL \ : severity auth.info \ : twist /bin/echo "You are not welcome to use %d from %h." .... この例では、 "You are not allowed to use `daemon` from `hostname`." というメッセージを、 アクセスファイルの中で設定されていないすべてのデーモンに対して返します。 接続元に対し、 確立された接続が破棄された直後に返答することは有効です。 返信に使われるメッセージは、引用符 (`"`) で囲む _必要_ があります。 [WARNING] ==== 攻撃者や攻撃者のグループは、 これらのデーモンの接続のリクエストであふれさせることにより、 サーバに対して DoS 攻撃を仕掛けることができます。 ==== 他の可能性は `spawn` を使うことです。 `twist` と同様に、 `spawn` は、暗黙のうちに接続を拒否し、 外部のシェルコマンドやスクリプトを実行できます。 `twist` と異なり、`spawn` は、 接続を確立した相手に対し、返事を返すことはありません。 たとえば、以下のような設定の行を考えてみてください。 [.programlisting] .... # We do not allow connections from example.com: ALL : .example.com \ : spawn (/bin/echo %a from %h attempted to access %d >> \ /var/log/connections.log) \ : deny .... この行は、`*.example.com` からの接続をすべて拒否します。 ホスト名、IP アドレスおよびアクセスを試みたデーモンが、 [.filename]#/var/log/connections.log# に記録されます。 この例では、置換文字 `%a` および `%h` が使われています。 置換文字の完全な一覧は man:hosts_access[5] をご覧ください。 ==== ワイルドカードオプション `ALL` オプションは、 デーモン、ドメインまたは IP アドレスのすべてのインスタンスのどれかにマッチするかどうかに使われます。 他のワイルドカードは、偽造された IP アドレスを提供するホストにマッチするかどうかに用いられる `PARANOID` です。 たとえば、`PARANOID` を使うことで、 ホスト名と異なる IP アドレスからの接続があった時のアクションを定義できます。 以下の例では、ホスト名から検索される IP アドレスと異なる IP アドレスを持つ man:sendmail[8] への接続のすべてのリクエストを拒否します。 [.programlisting] .... # Block possibly spoofed requests to sendmail: sendmail : PARANOID : deny .... [CAUTION] ==== クライアントもしくはサーバの DNS の設定が間違っている場合に、 `PARANOID` ワイルドカードを使うと、 サーバがとても使いづらくなります。 管理者の慎重さが求められます。 ==== ワイルドカードおよび関連する機能についてもっと知りたい場合には、 man:hosts_access[5] をご覧ください。 上記の設定が動作するには、[.filename]#hosts.allow# の中で、 最初の設定の行がコメントアウトされている必要があります。 [[kerberos5]] == Kerberos5 Kerberos は、 サーバのサービスによってユーザが安全に認証を受けられるようにするための、 ネットワークの付加システムおよびプロトコルです。 Kerberos は、 身元確認プロキシシステムや、 信頼される第 3 者認証システムとも説明されます。 ユーザが Kerberos を使って認証を行った後は、 通信は暗号化され、 プライバシおよびデータの完全性を保証することができます。 Kerberos の唯一の機能は、 ネットワーク上のユーザの安全な認証を提供することです。 承認 (どのユーザが許可されているか) や監査 (ユーザがどのような作業を行っているか) の機能は提供しません。 Kerberos を使う際は、 承認および監査サービスを提供する他のセキュリティの手段との利用が、 推奨されます。 この節では、FreeBSD 用として配布されている Kerberos をセットアップする際のガイドを提供します。 完全な説明が必要な場合には、 マニュアルページを参照してください。 この節における Kerberos のインストールのデモでは、以下のような名前空間が使われます。 * DNS ドメイン ("ゾーン") は、 `example.org` です。 * Kerberos の領域は、 `EXAMPLE.ORG` です。 [NOTE] ==== Kerberos の設定では、 内部での使用でも実際のドメイン名を使ってください。 DNS の問題を避けることができ、 他の Kerberos のレルム (realm) との相互運用を保証します。 ==== === 歴史 Kerberos は、 ネットワークのセキュリティ問題を解決するために、 MIT で開発されました。 Kerberos プロトコルは、 必ずしも安全ではないインターネット接続においても、 サーバに対して (逆もまた同様に)、 強い暗号を使って身元を証明します。 Kerberos は、 ネットワーク認証プロトコルの名前であり、 Kerberos telnet のように、 このプログラムを実装しているプログラムを表すための形容詞でもあります。 プロトコルの現在のバージョンはバージョン 5 で、 RFC 1510 として文書化されています。 このプロトコルのいくつものフリーの実装が、 さまざまなオペレーティングシステムで利用できます。 最初の Kerberos を開発したマサチューセッツ工科大学 (MIT) は、 開発した Kerberos パッケージを継続的に保守しています。 アメリカ合衆国では暗号製品として良く使われていますが、 歴史的には、 アメリカ合衆国 の輸出規制により制限されてきました。 MIT で実装された Kerberos は、 package:security/krb5[] package または port から利用できます。 バージョン 5 のもう一つの実装が、 Heimdal Kerberos です。 この実装は、アメリカ合衆国の外で開発されたため、 輸出の制限を避けることができます。 Heimdal Kerberos は package:security/heimdal[]> package または port からインストールできますが、最小構成は FreeBSD の base インストールに含まれています。 以下の説明では FreeBSD に含まれている Heimdal ディストリビューションの使用を想定しています。 === Heimdal KDC の設定 鍵配布センター (KDC) は、 Kerberos が提供する中心的な認証サービスで、 Kerberos チケットを発行するコンピュータです。 KDC は、 Kerberos のレルムの中のすべてのコンピュータから "信頼"されています。 そのため、厳重なセキュリティに対する配慮が必要となります。 Kerberos サーバの実行にコンピュータのリソースはほとんど必要ありませんが、 セキュリティの観点から、KDC としてのみ機能する専用のコンピュータが推奨されます。 KDC を設定するにあたって、 KDC として動作するために、 適切に [.filename]#/etc/rc.conf# が設定されていることを確認してください。 必要に応じて、 システムの設定を反映するようにパスを調整する必要があります。 [.programlisting] .... kerberos5_server_enable="YES" kadmind5_server_enable="YES" .... 次に、[.filename]#/etc/krb5.conf# を以下のように編集してください。 [.programlisting] .... [libdefaults] default_realm = EXAMPLE.ORG [realms] EXAMPLE.ORG = { kdc = kerberos.example.org admin_server = kerberos.example.org } [domain_realm] .example.org = EXAMPLE.ORG .... [.filename]#/etc/krb5.conf# の中で、 KDC は、 完全修飾されたホスト名 `kerberos.example.org` を使うことが想定されています。 KDC が異なるホスト名を持つ場合には、 名前の解決が行われるように、適切に CNAME (エイリアス) エントリをゾーンファイルに追加してください。 [NOTE] ==== 適切に DNS サーバが設定されている大きなネットワークでは、 上記の例は、以下のように整理されます。 [.programlisting] .... [libdefaults] default_realm = EXAMPLE.ORG .... そして、`example.org` ゾーンファイルには、以下の行が付け加えられます。 [.programlisting] .... _kerberos._udp IN SRV 01 00 88 kerberos.example.org. _kerberos._tcp IN SRV 01 00 88 kerberos.example.org. _kpasswd._udp IN SRV 01 00 464 kerberos.example.org. _kerberos-adm._tcp IN SRV 01 00 749 kerberos.example.org. _kerberos IN TXT EXAMPLE.ORG .... ==== [NOTE] ==== クライアントが、 Kerberos サービスを見つけるためには、 [.filename]#/etc/krb5.conf# を完全に設定するか、 [.filename]#/etc/krb5.conf# を最低限に設定し、 _さらに_ DNS サーバを適切に設定する _必要_ があります。 ==== 次に Kerberos データベースを作成してください。 このデータベースには、 マスター鍵により暗号化されたすべてのプリンシパルの鍵が含まれています。 このパスワードは、 [.filename]#/var/heimdal/m-key# に保存されるため、 覚える必要はありません。 マスター鍵を作成するには、man:kstash[8] を実行して、 パスワードを入力してください。 マスター鍵を作成したら、`kadmin -l` を使ってデータベースを初期化してください。 このオプションを使うと、man:kadmin[8] は、 man:kadmind[8] ネットワークサービスを使わず、 ローカルのデータベースファイルを直接変更します。 これにより、 データベースを作成する前に、データベースへの接続を試みてしまうという、 卵が先か鶏が先かという問題を回避できます。 man:kadmin[8] プロンプトで、 `init` を使って、 レルムに関する初期のデータベースを作成してください。 最後に、man:kadmin[8] プロンプトで `add` を使って最初のプリンシパルを作成して下さい。 差し当たりは、 プリンシパルに対するデフォルトのオプションに従ってください。 後で `modify` を使うことで、 変更することができます。 man:kadmin[8] プロンプトで `?` と入力すると、 利用可能なオプションを確認できます。 データベース作成のセッションの例は以下のようになります。 [source,shell] .... # kstash Master key: xxxxxxxx Verifying password - Master key: xxxxxxxx # kadmin -l kadmin> init EXAMPLE.ORG Realm max ticket life [unlimited]: kadmin> add tillman Max ticket life [unlimited]: Max renewable life [unlimited]: Attributes []: Password: xxxxxxxx Verifying password - Password: xxxxxxxx .... 次に KDC サービスを起動してください。 `service kerberos start` および `service kadmind start` を実行してサービスを起動してください。 この時点で、kerberos 化されたデーモンが走っていなくても、 KDC のコマンドラインから、作成したばかりの (ユーザ) プリンシパルのチケットを入手したり、 一覧を表示することができることを確認できます。 [source,shell] .... % kinit tillman tillman@EXAMPLE.ORG's Password: % klist Credentials cache: FILE:/tmp/krb5cc_500 Principal: tillman@EXAMPLE.ORG Issued Expires Principal Aug 27 15:37:58 Aug 28 01:37:58 krbtgt/EXAMPLE.ORG@EXAMPLE.ORG .... 必要がなくなった時には、チケットを破棄できます。 [source,shell] .... % kdestroy .... === Heimdal Kerberos サービスを有効にする。 最初に [.filename]#/etc/krb5.conf# を KDC からクライアントコンピュータへ、 man:scp[1] または物理的にリムーバブルディスクを使うといった安全な方法でコピーしてください。 次に [.filename]#/etc/krb5.keytab# を作成してください。 これが Kerberos 化されたデーモンを提供するサーバとワークステーションの間での大きな違いです: サーバには [.filename]#keytab# が置かれている必要があります。 このファイルには、サーバのホスト鍵が含まれています。 この鍵により、ホストおよび KDC が他の身元の検証ができます。 鍵が公開されてしまうと、 サーバのセキュリティが破られてしまうため、 このファイルは安全にサーバに転送しなければなりません。 一般的には、man:kadmin[8] を使って、 [.filename]#keytab# をサーバに転送します。 ホストプリンシパル (KDC 側の [.filename]#krb5.keytab#) も man:kadmin[8] を使って作成するので便利です。 すでにチケットを入手し、そのチケットは、 man:kadmin[8] インタフェースで使用できることが [.filename]#kadmind.acl# で許可されている必要があります。 アクセスコントロールリストの設計の詳細については、 `info heimdal` の "Remote administration" というタイトルの章をご覧ください。 リモートからの `kadmin` アクセスを有効にする代わりに、 管理者は、ローカルコンソールまたは man:ssh[1] を用いて安全に KDC に接続し、 `kadmin -l` を使用して、 ローカルで管理作業を行うことができます。 [.filename]#/etc/krb5.conf# をインストールしたら、 Kerberos サーバから `add --random-key` を使ってください。 このコマンドは、サーバのホストプリンシパルを追加します。 そして、`ext` を用いて、 サーバのホストプリンシパルを keytab に抽出してください。 以下は、使用例です。 [source,shell] .... # kadmin kadmin> add --random-key host/myserver.example.org Max ticket life [unlimited]: Max renewable life [unlimited]: Attributes []: kadmin> ext host/myserver.example.org kadmin> exit .... `ext` は、デフォルトでは、抽出された鍵を [.filename]#/etc/krb5.keytab# に保存します。 KDC 上で man:kadmind[8] を走らせていない場合で、 リモートから man:kadmin[8] に接続出来ない場合には、 ホストプリンシパル (`host/myserver.EXAMPLE.ORG`) を直接 KDC 上で追加し、 その後、以下のように KDC 上の [.filename]#/etc/krb5.keytab# の上書きを避けるため、 一時ファイルに抽出してください。 [source,shell] .... # kadmin kadmin> ext --keytab=/tmp/example.keytab host/myserver.example.org kadmin> exit .... その後、man:scp[1] またはリムーバブルディスクを使って、 keytab を安全にサーバコンピュータにコピーしてください。 KDC 上の keytab を上書きすることを避けるため、 デフォルトとは異なる名前を指定してください。 これでサーバは、 [.filename]#krb5.conf# を使って KDC と通信ができるようになりました。 そして、[.filename]#krb5.keytab# によって身元を証明できるようになったので、 Kerberos サービスを有効にする準備が出来ました。 この例では、 man:telnetd[8] サービスが [.filename]#/etc/inetd.conf# で有効に設定され、 `service inetd restart` によって、 man:inetd[8] サービスを再起動します。 [.programlisting] .... telnet stream tcp nowait root /usr/libexec/telnetd telnetd -a user .... 重要な変更箇所は、`-a` 認証がユーザに設定されていることです。 詳細については、 man:telnetd[8] を参照してください。 === Heimdal Kerberos クライアントを有効にする クライアントコンピュータの設定は簡単です。 [.filename]#/etc/krb5.conf# のみが必要です。 このファイルをセキュリティ的に安全な方法で、KDC からクライアントコンピュータへコピーしてください。 クライアントから、man:kinit[1], man:klist[1] および man:kdestroy[1] を使用し、 上記で作成したプリンシパルに対するチケットの入手、表示、 削除を行い、クライアントコンピュータを試験してください。 Kerberos アプリケーションを使って Kerberos が有効なサーバに接続することもできるはずです。 もしうまく機能しない場合でも、チケットを入手できるのであれば、 問題はおそらくサーバにあり、 クライアントまたは KDC の問題ではないと考えられます。 Kerberos 化されたアプリケーションを試験する際には、 man:tcpdump[1] といったパケットスニファを使用して、 パスワードが平文で送られていないことを確認してください。 コア以外の さまざまな Kerberos クライアントアプリケーションが利用可能です。 FreeBSD の "最小" インストールでは、 インストールされる Kerberos 化された唯一のサービスは、man:telnetd[8] です。 Heimdal port は、 Kerberos 化されている man:ftpd[8], man:rshd[8], man:rcp[1], man:rlogind[8] および他のあまり一般的ではないプログラムをインストールします。 MIT port も、すべての Kerberos クライアントアプリケーションをインストールします。 === ユーザ設定ファイル: [.filename]#.k5login# および [.filename]#.k5users# レルムのユーザは、一般的には、 ローカルユーザアカウントに対応する Kerberos プリンシパルを持ちます。 しかしながら、時々 Kerberos プリンシパルに対応しないローカルユーザアカウントへのアクセスが必要となることがあります。 たとえば、 `tillman@EXAMPLE.ORG` が、ローカルユーザアカウント `webdevelopers` へのアクセスが必要となることがあります。そして、 他のプリンシパルが同じローカルアカウントにアクセスが必要になることもあります。 ユーザのホームディレクトリに置かれた [.filename]#.k5login# および [.filename]#.k5users# ファイルを使うことで、 この問題を解決出来ます。 たとえば、以下の行を含む [.filename]#.k5login# を `webdevelopers` のホームディレクトリに置くと、 一覧にある両方のプリンシパルは、 共有のパスワードを必要としなくても、 このアカウントにアクセス出来ます。 [source,shell] .... tillman@example.org jdoe@example.org .... [.filename]#.k5users# の詳細については、 man:ksu[1] を参照してください。 === Kerberos Tips, Tricks, およびトラブルシューティング * Heimdal または MITKerberos ports のどちらを使う場合でも、 `PATH` は、 Kerberos 版のクライアント アプリケーションが、 システムにあるアプリケーションより先に見つかるように設定されていることを確認してください。 * レルムにあるすべてのコンピュータの間で時刻が同期していないと、 認証に失敗してしまいます。 NTP を用いた、時刻の同期方法については、 crossref:advanced-networking[network-ntp,「NTP」] をご覧ください。 * MIT および Heimdal 間の運用は、 標準化されていない man:kadmin[8] を除けばうまく機能します。 * ホスト名が変更された場合は、 `host/` プリンシパルを変更し、keytab をアップデートする必要があります。 Apache の package:www/mod_auth_kerb[] で使われる `www/` プリンシパルのような特別な keytab エントリでも必要となります。 * レルムの中のすべてのホストは、DNS、 もしくは、最低限 [.filename]#/etc/hosts# において正引きおよび逆引き両方で名前解決できる必要があります。 CNAME は動作しますが、A および PTR レコードは、 正しく適切な位置に記述されている必要があります。 名前が解決できない場合のエラーメッセージは、 次の例のように、直感的に原因が分かるようなものではありません。 `Kerberos5 refuses authentication because Read req failed: Key table entry not found`. * KDC に対しクライアントとして振る舞うオペレーティングシステムの中には、 man:ksu[1] に対して、 `root` 権限に setuid を許可しないものがあります。 この設定では、 man:ksu[1] は動作しないことを意味します。 これは KDC のエラーではありません。 * MITKerberos において、 プリンシパルが、デフォルトの 10 時間を超えるチケットの有効期限としたい場合には、 man:kadmin[8] のプロンプトで `modify_principal` を使って、 対象のプリンシパルおよび `krbtgt` プリンシパル両方の有効期限の最大値を変更してください。 プリンシパルは、 `kinit -l` を使用して、 長い有効期限のチケットを要求できます。 * [NOTE] ==== トラブルシューティングのために、 KDC でパケットスニファを走らせ、 一方で、ワークステーションにおいて man:kinit[1] を実行すると、 man:kinit[1] を実行するやいなや、 パスワードを入力し終わる前でも、 Ticket Granting Ticket (TGT) が送られてきます。 これに関する説明は、以下の通りです。 Kerberos サーバは、 いかなる未承認のリクエストに対して、 自由に TGT を送信します。 しかしながら、すべての TGT は、 ユーザのパスワードから生成された鍵により、暗号化されています。 そのため、ユーザがパスワードを入力した時には、 パスワードは KDC には送られません。 その代わりこのパスワードは、man:kinit[1] がすでに入手した TGT の復号化に使われます。 もし、復号化の結果、 有効なチケットで有効なタイムスタンプの場合には、 ユーザは、有効な Kerberos クレデンシャルを持ちます。 このクレデンシャルには、 Kerberos サーバ自身の鍵により暗号化された実際の TGT とともに、将来 Kerberos サーバと安全な通信を確立するためのセッション鍵が含まれています。 この暗号の 2 番目のレイヤは、 Kerberos サーバが、 各 TGT の真偽の検証を可能にしている部分です。 ==== * たとえば一週間といった長い有効期限のチケットを使いたい場合で、 OpenSSH を使って、 チケットが保存されているコンピュータに接続しようとする場合は、 Kerberos `TicketCleanup` が [.filename]#sshd_config# において `no` と設定されているか、 チケットが、ログアウト時に削除されることを確認してください。 * ホストプリンシパルは長い有効期限のチケットを持つことができます。 もし、ユーザプリンシパルが 1 週間の有効期限を持ち、 接続しているホストが、9 時間の有効期限を持っている場合には、 ユーザキャッシュは有効期限が切れたホストプリンシパルを持つことになり、 想定したように、 チケットキャッシュが振る舞わないことが起こりえます。 * man:kadmind[8] で説明されているような、 特定の問題のあるパスワードが使われることを避けるために [.filename]#krb5.dict# を設定する時には、 パスワードポリシが割り当てられたプリンシパルにのみ適用されることを覚えていてください。 [.filename]#krb5.dict# で使われている形式では、 一行に一つの文字列が置かれています。 [.filename]#/usr/share/dict/words# にシンボリックリンクを作成することは、有効です。 === MIT port との違いについて MIT と Heimdal 版の大きな違いは、 man:kadmin[8] に関連しています。 このプログラムは、異なる (ただし等価な) コマンド群を持ち、そして、 異なるプロトコルを使用します。 もし KDC に MIT を使用している場合には、 Heimdal 版の man:kadmin[8] を使って KDC をリモートから (逆も同様に) 管理できないことを意味しています。 クライアントアプリケーションでは、同じタスクを行う際に、 若干異なるコマンドラインのオプションが使われることもあります。 MIT Kerberos link:http://web.mit.edu/Kerberos/www/[ウェブサイト] に書かれているガイドに従うことが推奨されます。 path の問題について注意してください。 MIT port はデフォルトで [.filename]#/usr/local/# にインストールします。 そのため、もし `PATH` においてシステムのディレクトが最初に書かれている場合には、 MIT 版ではなく、"通常の" システムアプリケーションが起動してしまいます。 [NOTE] ==== FreeBSD の MITpackage:security/krb5[] port において、 man:telnetd[8] および `klogind` 経由でのログインが奇妙な振る舞いをすることを理解するには、 port からインストールされる [.filename]#/usr/local/share/doc/krb5/README.FreeBSD# を読んで下さい。 "incorrect permissions on cache file" の振る舞いを修正するには、 フォワードされたクレデンシャリングの所有権を適切に変更できるように、 `login.krb5` バイナリが認証に使われる必要があります。 ==== [.filename]#rc.conf# を以下のように変更する必要もあります。 [.programlisting] .... kerberos5_server="/usr/local/sbin/krb5kdc" kadmind5_server="/usr/local/sbin/kadmind" kerberos5_server_flags="" kerberos5_server_enable="YES" kadmind5_server_enable="YES" .... これを行うのは、 MIT Kerberos のアプリケーションは、 [.filename]#/usr/local# 構造の下にインストールされるためです。 === Kerberos で見つかった制限を緩和する ==== Kerberos は、All or Nothing アプローチです。 ネットワーク上で有効なすべてのサービスは、 Kerberos 化されるか、 または、ネットワーク攻撃に対して安全であるべきです。 さもないと、ユーザのクレデンシャルが盗まれ、 利用されることが起きるかもしれません。 この例は、 Kerberos 化されたすべてのリモートシェルです。 パスワードを平文で送るような POP3 メールサーバは変換していません。 ==== Kerberos は、 シングルユーザのワークステーションでの使用を想定しています。 マルチユーザの環境では、 Kerberos は安全ではありません。 チケットは [.filename]#/tmp# に保管され、 このチケットは、すべてのユーザが読むことができるためです。 もし、ユーザがコンピュータを他のユーザと同時に共有していると、 他のユーザは、そのユーザのチケットを盗んだり、 コピーが出来てしまいます。 この問題は、`-c` コマンドラインオプションまたは、好ましくは `KRB5CCNAME` 環境変数によって克服されます。 この問題への対応には、 チケットをユーザのホームディレクトリに保存し、 ファイルの許可属性を設定することが一般的に行われます。 ==== KDC は、単一障害点である 設計上、KDC は、 マスターパスワードのデータベースと同様に安全である必要があります。 KDC では、 絶対に他のサービスを走らせるべきではありませんし、 物理的に安全であるべきです。 Kerberos は、 KDC 上で、ファイルとして保存されている同じ "マスター" 鍵で暗号化されたすべてのパスワードを保存しているので、 非常に危険です。 マスター鍵が漏洩しても、 懸念するほど悪いことにはなりません。 マスター鍵は、Kerberos データベースの暗号時にのみ、 乱数を生成するためのシードとして使われます。 KDC へのアクセスが安全である限りにおいては、 マスター鍵を用いて、それほど多くのことはできません。 さらに、KDC が利用できないと、 認証ができないため、ネットワークサービスを利用できなくなります。 この攻撃による被害は、 ひとつのマスタ KDC とひとつまたはそれ以上のスレーブ、 そして、セカンダリもしくは PAM を用いたフォールバック認証を注意深く実装することにより軽減できます。 ==== Kerberos の欠点 Kerberos は、 ユーザ、ホストおよびサービスの間での認証を可能にしますが、 KDC とユーザ、 ホストまたはサービスとの間の認証のメカニズムは提供しません。 これは、トロイの木馬の man:kinit[1] が、 すべてのユーザ名とパスワードを記録できることを意味しています。 package:security/tripwire[] のような、ファイルシステムの完全性を確認するためのツールにより、 この危険性を軽減することができます。 === Kerberos および man:ssh[1] を用いたアクセスの問題 Kerberos と man:ssh[1] を使う場合には、 両者に関して知っておかねばならない問題がいくつかあります。 Kerberos は大変優れた認証プロトコルですが、Kerberos 化された man:telnet[1] および man:rlogin[1] には、 バイナリストリームを扱うのに不向きになるようなバグがあります。 デフォルトでは、Kerberos は `-x` を使わない限りセッションを暗号化してくれません。 一方 man:ssh[1] では、 デフォルトですべてを暗号化してくれます。 man:ssh[1] はとても良く動作しますが、 デフォルトで暗号鍵を転送してしまいます。 このため、man:ssh[1] を安全なワークステーションから、 安全でないマシンへのアクセスに使っているユーザに、 セキュリティリスクを引き起こします。 鍵そのものが見えてしまうわけではありませんが、 man:ssh[1] は login している間、転送用ポートを作ります。 攻撃者が安全でないマシンの `root` を破ったら、 このポートを使って、 この暗号鍵でロックが外れる他のマシンへのアクセスを得てしまいます。 可能な時はいつでも、スタッフのログインには Kerberos を組み合せた man:ssh[1] を使用することを勧めます。 man:ssh[1] は、Kerberos 対応機能と一緒にコンパイルできます。 このようにすることで、見えてしまう可能性のある SSH 鍵への依存を減らし、 一方で、Kerberos 経由によりパスワードが保護されます。 鍵は、安全なマシンからの自動化されたタスクのみに使用すべきです。 Kerberos はこの用途には不向きです。 また、SSH の設定で鍵転送をしないようにするか、 あるいは [.filename]#authorized_keys# の `from=IP/DOMAIN` を使用して、 特定のマシンからログインしてきたときのみ鍵が有効にすることをお勧めします。 === リソースおよび他の情報源 * http://www.faqs.org/faqs/Kerberos-faq/general/preamble.html[The Kerberos FAQ] * http://web.mit.edu/Kerberos/www/dialogue.html[Designing an Authentication System: a Dialog in Four Scenes] * http://www.ietf.org/rfc/rfc1510.txt?number=1510[RFC 1510, The Kerberos Network Authentication Service (V5)] * http://web.mit.edu/Kerberos/www/[MIT Kerberos home page] * http://www.pdc.kth.se/heimdal/[Heimdal Kerberos home page] [[openssl]] == OpenSSL FreeBSD には、OpenSSL ツールキットが含まれています。 OpenSSL は、 通常の通信層の上位にあるトランスポート層を暗号化し、 多くのネットワークアプリケーションおよびサービスと組み合わせて使用できます。 OpenSSL は、 メールクライアントの暗号化された認証、 クレジットカードでの支払いといったウェブベースの取引などで使われます。 package:www/apache22[] および package:mail/claws-mail[] といった多くの port では、 OpenSSL とともに構築するコンパイルに対応しています。 [NOTE] ==== 多くの場合、Ports Collection は、 make の `WITH_OPENSSL_BASE` が明示的に "yes" に設定されていないと、 package:security/openssl[] port の構築を試みます。 ==== FreeBSD に含まれている OpenSSL 　のバージョンは、Secure Sockets Layer v2/v3 (SSLv2/SSLv3) および Transport Layer Security v1 (TLSv1) ネットワークセキュリティプロトコルに対応しており、 多目的な暗号化ライブラリとして使うことができます。 [NOTE] ==== OpenSSL は、 IDEA アルゴリズムに対応していますが、 合衆国の特許により、デフォルトでは無効になっています。 もし使用したいのであれば、ライセンス条項を必ず確認し、 ライセンス条項に合致するのであれば、 [.filename]#/etc/make.conf# において `MAKE_IDEA` 変数を設定してください。 ==== 最も一般的な OpenSSL の利用方法のひとつは、 ソフトウェアアプリケーションが使えるように証明書を提供することです。 これらの証明書により、会社または個人の公開鍵が、 改ざんやなりすましが行われていないことを確認できます。 もし問題となっている証明書が、"認証局" (CA) により検証されなければ、 警告が表示されます。 CA は、link:http://www.verisign.com[VeriSign] のような会社で、個人または会社の公開鍵の検証を行えるように、 証明書に署名を行います。 証明書を作成するには費用がかかり、 証明書の使用は必要条件ではありませんが、 証明書を使うことで、 ユーザを安心させることができます。 === 証明書の作成 以下のコマンドにより、証明書を作成できます。 [source,shell] .... # openssl req -new -nodes -out req.pem -keyout cert.pem Generating a 1024 bit RSA private key ................++++++ .......................................++++++ writing new private key to 'cert.pem' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:PA Locality Name (eg, city) []:Pittsburgh Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company Organizational Unit Name (eg, section) []:Systems Administrator Common Name (eg, YOUR name) []:localhost.example.org Email Address []:trhodes@FreeBSD.org Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []:SOME PASSWORD An optional company name []:Another Name .... "Common Name" プロンプト直後に表示されているのは、 ドメイン名です。 このプロンプトでは、検証するサーバ名の入力が必要となります。 ドメイン名以外を入力すると、役に立たない証明書が作成されます。 他のオプションとして、有効期限を指定したり、 別の暗号化アルゴリズムを選択することができます。 オプションの完全なリストは、 man:openssl[1] で説明されています。 このコマンドを実行したディレクトリには、 2 つのファイルが作成されているはずです。 1 つは、証明書要求 [.filename]#req.pem# です。 このファイルを CA に送ると、 CA は含まれている内容を検証し、 検証に成功すると、証明書要求に署名を行い、 作成された証明書を送り返します。 もうひとつ、[.filename]#cert.pem# と呼ばれるファイルが生成されます。 これは証明書の秘密鍵であり、 どのようなことがあっても保護しなくてはなりません。 もし、他の人の手に渡ると、手に入れた人は、 ユーザまたはサーバになりすますことができてしまいます。 CA の署名が必要ない場合には、 自己署名証明書を作成できます。 最初に RSA の鍵を生成してください。 [source,shell] .... # openssl dsaparam -rand -genkey -out myRSA.key 1024 .... 次に、CA 鍵を生成してください。 [source,shell] .... # openssl gendsa -des3 -out myca.key myRSA.key .... この鍵を使って証明書を作成してください。 [source,shell] .... # openssl req -new -x509 -days 365 -key myca.key -out new.crt .... 新しく 2 つのファイルがこのディレクトリに作成されます。 プライベート鍵 [.filename]#myca.key# および 証明書 [.filename]#new.crt# です。 これらのファイルを、好ましくは [.filename]#/etc# 以下で、 `root` のみが読むことのできるディレクトリに置く必要があります。 許可属性は 0700 が適切です。 許可属性は man:chmod[1] を使って設定できます。 === 証明書の使用 証明書の一つの利用方法は、SendmailMTA への接続を暗号化することです。 これにより、 ローカルの MTA 経由でメールを送信するユーザが、 テキスト認証を使用しなくてもすむようになります。 [NOTE] ==== いくつかの MUA は、 ユーザが証明書をローカルにインストールしていないと、 エラーを出力します。 証明書のインストールに関する詳細な情報については、 ソフトウェアに付随の文書を参照してください。 ==== Sendmail を設定するには、以下の行をローカルの [.filename]#.mc# ファイルに含めてください。 [.programlisting] .... dnl SSL Options define(`confCACERT_PATH',`/etc/certs')dnl define(`confCACERT',`/etc/certs/new.crt')dnl define(`confSERVER_CERT',`/etc/certs/new.crt')dnl define(`confSERVER_KEY',`/etc/certs/myca.key')dnl define(`confTLS_SRV_OPTIONS', `V')dnl .... この例では、 ローカルで証明書および鍵ファイルは、ローカルの [.filename]#/etc/certs/# に置かれています。 ファイルの編集を保存し終わったら、 [.filename]#/etc/mail# において `make install` と入力することで、ローカルの [.filename]#.cf# ファイルを再構築する必要があります。 その後、`make restart` と入力して、Sendmail デーモンを再起動してください。 すべてがうまくいっていれば、 [.filename]#/var/log/maillog# にはエラーメッセージは出力されず、 Sendmail がプロセスの一覧に表示されます。 以下は簡単な試験の例で、man:telnet[1] を使って、 メールサーバに接続しています。 [source,shell] .... # telnet example.com 25 Trying 192.0.34.166... Connected to example.com Escape character is '^]'. 220 example.com ESMTP Sendmail 8.12.10/8.12.10; Tue, 31 Aug 2004 03:41:22 -0400 (EDT) ehlo example.com 250-example.com Hello example.com [192.0.34.166], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-AUTH LOGIN PLAIN 250-STARTTLS 250-DELIVERBY 250 HELP quit 221 2.0.0 example.com closing connection Connection closed by foreign host. .... 出力に "STARTTLS" 行が表示されれば、 すべてが適切に機能しています。 [[ipsec]] == VPN over IPsec === IPsec を理解する この節では、IPsec を設定する過程を説明します。 IPsec を設定するためには、 カスタムカーネルの構築方法をよく知っている必要があります (crossref:kernelconfig[kernelconfig,FreeBSD カーネルのコンフィグレーション] をご覧ください)。 _IPsec_ は、インターネットプロトコル (IP) レイヤのトップにあるプロトコルです。 二つもしくはそれ以上のホスト間で安全に通信することを可能にします。 FreeBSD の IPsec "ネットワークスタック" は、 IPv4 および IPv6 の両方に対応している http://www.kame.net/[KAME] 実装をベースとしています。 IPsec は二つのサブプロトコルから構成されます。 * _Encapsulated Security Payload (ESP)_: このプロトコルは、Blowfish, 3DES といった対称暗号アルゴリズムを使ってデータを暗号化することで、 サードパーティのインタフェースから IP パケットデータを保護します。 * _Authentication Header AH(AH)_: このプロトコルは、暗号チェックサムを計算し、IP パケットのヘッドフィールドを安全なハッシュ関数でハッシュ化することで、 IP パケットヘッダをサードパーティのインタフェースやなりすましから守ります。 ハッシュを含む追加のヘッダが追加され、 パケット情報の検証が可能になります。 ESP および AH は、使用する環境に合わせて、 一緒に使うことも別々に使うこともできます。 IPsec は、直接二つのホスト間のトラフィックを暗号化する _Transport Mode_、もしくは "virtual tunnels" を構築する _Tunnel Mode_ のどちらでも用いることができます。 後者のモードはより一般的には、 _Virtual Private Network (VPN)_ として知られています。 FreeBSD での IPsec サブシステムに関するより詳細な情報については、 man:ipsec[4] を参照してください。 カーネルに IPsec のサポートを追加するには、 カスタムカーネルコンフィグレーションファイルに以下のオプションを追加してください。 [source,shell] .... options IPSEC #IP security device crypto .... IPsec のデバッグサポートが必要であれば、 以下のカーネルオプションを追加してください。 [source,shell] .... options IPSEC_DEBUG #debug for IP security .... === 家庭と会社間の VPN VPN の構成についての標準はありません。 VPN は、数多くの技術と共に実装することが可能です。 その各技術には、それ自身の長所と短所があります。 この節では、以下のシナリオに対して VPN を実装する戦略について説明します。 * 少なくとも 2 つのサイトがあり、 それぞれのサイトは内部で IP を使っています。 * 2 つのサイトは、FreeBSD で運用されているゲートウェイを通して、 インターネットに接続しています。 * それぞれのネットワークのゲートウェイは、 少なくとも一つのパブリック IP アドレスを持っています。 * 2 つのネットワークの内部アドレスは、 パブリックでもプライベート IP アドレスでも構いません。 しかしながら、アドレス空間は衝突してはいけません。 たとえば、両方のネットワークが `192.168.1.x` を使ってはいけません。 ==== FreeBSD 上で IPsec を設定する。 最初に Ports Collection から package:security/ipsec-tools[] をインストールしてください。 このソフトウェアは、 設定をサポートする数多くのアプリケーションを提供します。 次に、パケットをトンネリングし、 両方のネットワークが適切に通信するように、 2 つの man:gif[4] 疑似デバイスを作成します。 `root` 権限で以下のコマンドを実行してください。 ただし、実行する際には、以下のコマンドの中の _internal_ および _external_ を、 2 つのゲートウェイの内部および外部インタフェースの実際の IP アドレスに置き換えてください。 [source,shell] .... # ifconfig gif0 create .... [source,shell] .... # ifconfig gif0 internal1 internal2 .... [source,shell] .... # ifconfig gif0 tunnel external1 external2 .... この例では、会社の LAN の外部 IP アドレスを `172.16.5.4`、 内部 IP アドレスを `10.246.38.1` とします。また、家庭 LAN の外部 IP アドレスを `192.168.1.12`、 内部のプライベート IP アドレスを `10.0.0.5` とします。 この説明で分かりにくい場合は、以下の man:ifconfig[8] コマンドの出力例をご覧ください。 [.programlisting] .... Gateway 1: gif0: flags=8051 mtu 1280 tunnel inet 172.16.5.4 --> 192.168.1.12 inet6 fe80::2e0:81ff:fe02:5881%gif0 prefixlen 64 scopeid 0x6 inet 10.246.38.1 --> 10.0.0.5 netmask 0xffffff00 Gateway 2: gif0: flags=8051 mtu 1280 tunnel inet 192.168.1.12 --> 172.16.5.4 inet 10.0.0.5 --> 10.246.38.1 netmask 0xffffff00 inet6 fe80::250:bfff:fe3a:c1f%gif0 prefixlen 64 scopeid 0x4 .... 設定が完了したら、両方の内部 IP アドレスは、man:ping[8] で到達できるようになっているはずです。 [.programlisting] .... priv-net# ping 10.0.0.5 PING 10.0.0.5 (10.0.0.5): 56 data bytes 64 bytes from 10.0.0.5: icmp_seq=0 ttl=64 time=42.786 ms 64 bytes from 10.0.0.5: icmp_seq=1 ttl=64 time=19.255 ms 64 bytes from 10.0.0.5: icmp_seq=2 ttl=64 time=20.440 ms 64 bytes from 10.0.0.5: icmp_seq=3 ttl=64 time=21.036 ms --- 10.0.0.5 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 19.255/25.879/42.786/9.782 ms corp-net# ping 10.246.38.1 PING 10.246.38.1 (10.246.38.1): 56 data bytes 64 bytes from 10.246.38.1: icmp_seq=0 ttl=64 time=28.106 ms 64 bytes from 10.246.38.1: icmp_seq=1 ttl=64 time=42.917 ms 64 bytes from 10.246.38.1: icmp_seq=2 ttl=64 time=127.525 ms 64 bytes from 10.246.38.1: icmp_seq=3 ttl=64 time=119.896 ms 64 bytes from 10.246.38.1: icmp_seq=4 ttl=64 time=154.524 ms --- 10.246.38.1 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 28.106/94.594/154.524/49.814 ms .... 予想通り、プライベートアドレスを使って、 両方のネットワークから ICMP パケットを送受信できます。 次に、どちらのネットワークからもメッセージを送信できるように、 パケットのルーティング情報を両方のゲートウェイに設定する必要があります。 これは以下のコマンドで設定できます。 [source,shell] .... # corp-net# route add 10.0.0.0 10.0.0.5 255.255.255.0 .... [source,shell] .... # corp-net# route add net 10.0.0.0: gateway 10.0.0.5 .... [source,shell] .... # priv-net# route add 10.246.38.0 10.246.38.1 255.255.255.0 .... [source,shell] .... # priv-net# route add host 10.246.38.0: gateway 10.246.38.1 .... これで、ネットワーク内のコンピュータは、 ゲートウェイおよびゲートウェイの奥のコンピュータから到達可能となっています。 もう一度 man:ping[8] で確認してください。 [.programlisting] .... corp-net# ping 10.0.0.8 PING 10.0.0.8 (10.0.0.8): 56 data bytes 64 bytes from 10.0.0.8: icmp_seq=0 ttl=63 time=92.391 ms 64 bytes from 10.0.0.8: icmp_seq=1 ttl=63 time=21.870 ms 64 bytes from 10.0.0.8: icmp_seq=2 ttl=63 time=198.022 ms 64 bytes from 10.0.0.8: icmp_seq=3 ttl=63 time=22.241 ms 64 bytes from 10.0.0.8: icmp_seq=4 ttl=63 time=174.705 ms --- 10.0.0.8 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 21.870/101.846/198.022/74.001 ms priv-net# ping 10.246.38.107 PING 10.246.38.1 (10.246.38.107): 56 data bytes 64 bytes from 10.246.38.107: icmp_seq=0 ttl=64 time=53.491 ms 64 bytes from 10.246.38.107: icmp_seq=1 ttl=64 time=23.395 ms 64 bytes from 10.246.38.107: icmp_seq=2 ttl=64 time=23.865 ms 64 bytes from 10.246.38.107: icmp_seq=3 ttl=64 time=21.145 ms 64 bytes from 10.246.38.107: icmp_seq=4 ttl=64 time=36.708 ms --- 10.246.38.107 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 21.145/31.721/53.491/12.179 ms .... トンネリングの設定は以上のように簡単ですが、 リンクを安全にするには、もう少し掘り下げた設定が必要となります。 以下の設定では、事前共有 (PSK) RSA 鍵を使います。 IP アドレスを除けば、両方のゲートウェイの [.filename]#/usr/local/etc/racoon/racoon.conf# は同じで、以下のようになります。 [.programlisting] .... path pre_shared_key "/usr/local/etc/racoon/psk.txt"; #location of pre-shared key file log debug; #log verbosity setting: set to 'notify' when testing and debugging is complete padding # options are not to be changed { maximum_length 20; randomize off; strict_check off; exclusive_tail off; } timer # timing options. change as needed { counter 5; interval 20 sec; persend 1; # natt_keepalive 15 sec; phase1 30 sec; phase2 15 sec; } listen # address [port] that racoon will listen on { isakmp 172.16.5.4 [500]; isakmp_natt 172.16.5.4 [4500]; } remote 192.168.1.12 [500] { exchange_mode main,aggressive; doi ipsec_doi; situation identity_only; my_identifier address 172.16.5.4; peers_identifier address 192.168.1.12; lifetime time 8 hour; passive off; proposal_check obey; # nat_traversal off; generate_policy off; proposal { encryption_algorithm blowfish; hash_algorithm md5; authentication_method pre_shared_key; lifetime time 30 sec; dh_group 1; } } sainfo (address 10.246.38.0/24 any address 10.0.0.0/24 any) # address $network/$netmask $type address $network/$netmask $type ( $type being any or esp) { # $network must be the two internal networks you are joining. pfs_group 1; lifetime time 36000 sec; encryption_algorithm blowfish,3des,des; authentication_algorithm hmac_md5,hmac_sha1; compression_algorithm deflate; } .... 利用可能なオプションの説明については、 racoon のマニュアルページを参照してください。 FreeBSD および racoon がホスト間のネットワークトラフィックを暗号化、 復号化できるようにするには、 Security Policy Database (SPD) の設定が必要です。 これは、会社のゲートウェイ上で、 以下のようなシェルスクリプトで設定できます。 このファイルをシステムの初期化中に使われるようにするには、 [.filename]#/usr/local/etc/racoon/setkey.conf# に保存する必要があります。 [.programlisting] .... flush; spdflush; # To the home network spdadd 10.246.38.0/24 10.0.0.0/24 any -P out ipsec esp/tunnel/172.16.5.4-192.168.1.12/use; spdadd 10.0.0.0/24 10.246.38.0/24 any -P in ipsec esp/tunnel/192.168.1.12-172.16.5.4/use; .... 設定ファイルを適切に置くと、以下のコマンドにより、 両方のゲートウェイ上で racoon を起動できます。 [source,shell] .... # /usr/local/sbin/racoon -F -f /usr/local/etc/racoon/racoon.conf -l /var/log/racoon.log .... 出力は以下のようになるでしょう。 [.programlisting] .... corp-net# /usr/local/sbin/racoon -F -f /usr/local/etc/racoon/racoon.conf Foreground mode. 2006-01-30 01:35:47: INFO: begin Identity Protection mode. 2006-01-30 01:35:48: INFO: received Vendor ID: KAME/racoon 2006-01-30 01:35:55: INFO: received Vendor ID: KAME/racoon n2006-01-30 01:36:04: INFO: ISAKMP-SA established 172.16.5.4[500]-192.168.1.12[500] spi:623b9b3bd2492452:7deab82d54ff704a 2006-01-30 01:36:05: INFO: initiate new phase 2 negotiation: 172.16.5.4[0]192.168.1.12[0] 2006-01-30 01:36:09: INFO: IPsec-SA established: ESP/Tunnel 192.168.1.12[0]->172.16.5.4[0] spi=28496098(0x1b2d0e2) 2006-01-30 01:36:09: INFO: IPsec-SA established: ESP/Tunnel 172.16.5.4[0]->192.168.1.12[0] spi=47784998(0x2d92426) 2006-01-30 01:36:13: INFO: respond new phase 2 negotiation: 172.16.5.4[0]192.168.1.12[0] 2006-01-30 01:36:18: INFO: IPsec-SA established: ESP/Tunnel 192.168.1.12[0]->172.16.5.4[0] spi=124397467(0x76a279b) 2006-01-30 01:36:18: INFO: IPsec-SA established: ESP/Tunnel 172.16.5.4[0]->192.168.1.12[0] spi=175852902(0xa7b4d66) .... トンネリングが適切に行われているかどうかを確認するため、 別のコンソール上で man:tcpdump[1] を使い、 以下のようなコマンドでネットワークの通信を確認してください。 ただし、以下の例の `em0` の部分は、 必要に応じて使用しているネットワークインタフェースに置き換えてください。 [source,shell] .... # tcpdump -i em0 host 172.16.5.4 and dst 192.168.1.12 .... 以下のようなデータがコンソールに表示されます。 もし、表示されない場合は、設定に何か問題があるので、 表示されるデータを使ってデバッグする必要があります。 [.programlisting] .... 01:47:32.021683 IP corporatenetwork.com > 192.168.1.12.privatenetwork.com: ESP(spi=0x02acbf9f,seq=0xa) 01:47:33.022442 IP corporatenetwork.com > 192.168.1.12.privatenetwork.com: ESP(spi=0x02acbf9f,seq=0xb) 01:47:34.024218 IP corporatenetwork.com > 192.168.1.12.privatenetwork.com: ESP(spi=0x02acbf9f,seq=0xc) .... これで 2 つのネットワークは、 1 つのネットワークのように利用できます。 多くの場合、 両方のネットワークはファイアウォールにより保護されています。 両方を流れる通信を許可するには、 パケットが両方を行き来できるようにルールを追加する必要があります。 man:ipfw[8] を使ったファイアウォールの場合は、 ファイアウォールの設定ファイルに、以下の行を追加してください。 [.programlisting] .... ipfw add 00201 allow log esp from any to any ipfw add 00202 allow log ah from any to any ipfw add 00203 allow log ipencap from any to any ipfw add 00204 allow log udp from any 500 to any .... [NOTE] ==== ルール番号は、 現在のホストの設定によっては変更する必要があるでしょう。 ==== man:pf[4] または man:ipf[8] を使用しているシステムでは、 以下のルールで上手くいくでしょう。 [.programlisting] .... pass in quick proto esp from any to any pass in quick proto ah from any to any pass in quick proto ipencap from any to any pass in quick proto udp from any port = 500 to any port = 500 pass in quick on gif0 from any to any pass out quick proto esp from any to any pass out quick proto ah from any to any pass out quick proto ipencap from any to any pass out quick proto udp from any port = 500 to any port = 500 pass out quick on gif0 from any to any .... 最後に、システムの初期化中に VPN が起動するように、以下の行を [.filename]#/etc/rc.conf# に追加してください。 [.programlisting] .... ipsec_enable="YES" ipsec_program="/usr/local/sbin/setkey" ipsec_file="/usr/local/etc/racoon/setkey.conf" # allows setting up spd policies on boot racoon_enable="yes" .... [[openssh]] == OpenSSH OpenSSH はリモートマシンへのセキュアなアクセスに使われるネットワーク接続ツールの集合です。 また、TCP/IP 接続を OpenSSH 接続経由でセキュアにトンネル/フォワードすることもできます。 OpenSSH はすべてのトラフィックを暗号化し、 盗聴や接続の乗っ取り等のネットワークレベルの攻撃を事実上無効化します。 OpenSSH は OpenBSD プロジェクトによって維持管理されており、 FreeBSD にはデフォルトでインストールされています。 OpenSSH は、 SSH バージョン 1 と 2 の両方に互換性があります。 === OpenSSH を使うことの利点 データがネットワークを平文で流れてしまうと、 ネットワークをクライアントとサーバの間のどこかで盗聴することで、 あなたのユーザ/パスワード情報やセション中を流れるデータを盗むことが可能です。 OpenSSH はこれらを予防する為にさまざまな認証と暗号化の方法を提供します。 === SSH サーバを有効にする man:sshd[8] が有効になっているかどうかを確認するには、 [.filename]#/etc/rc.conf# の以下の行を確認してください。 [.programlisting] .... sshd_enable="YES" .... この設定により、次のシステムの初期化時に OpenSSH のデーモンプログラムである man:sshd[8] が起動します。 もしくは man:service[8] を使って、すぐに OpenSSH を起動することもできます。 [source,shell] .... # service sshd start .... === SSH クライアント man:ssh[1] を使って、 man:sshd[8] が動いているシステムに接続するには、 ログインをするユーザ名とホストを指定してください。 [source,shell] .... # ssh user@example.com Host key not found from the list of known hosts. Are you sure you want to continue connecting (yes/no)? yes Host 'example.com' added to the list of known hosts. user@example.com's password: ******* .... SSH はクライアントが接続した時、 サーバの信頼性の検証のために鍵指紋システム (key fingerprint system) を利用します。 初めての接続の際に、ユーザは `yes` と入力することを要求されます。 これ以降の login では保存されていた鍵指紋を照合することで検証が行われ、 man:ssh[1] クライアントは保存されていた鍵指紋が login しようとした際に送られてきたものと異なっていた場合には警告を表示します。 指紋は [.filename]#~/.ssh/known_hosts# に保存されます。 デフォルトでは、man:sshd[8] の最近の版では SSH v2 の接続のみを受け付けるように設定されています。 クライアントは可能であればバージョン 2 を用い、 バージョン 1 にフォールバックします。 クライアントは、プロトコル v1 と v2 についてそれぞれ、引数 `-1` または `-2` を渡すことで、利用するプロトコルを指定できます。 クライアントにおけるバージョン 1 への互換性は、 古いバージョンへの上位互換のために維持されています。 === Secure copy ローカルのファイルをリモートマシンへ、 あるいはリモートマシンのファイルをローカルに安全な方法でコピーするには、 man:scp[1] を使用してください。 [source,shell] .... # scp user@example.com:/COPYRIGHT COPYRIGHT user@example.com's password: ******* COPYRIGHT 100% |*****************************| 4735 00:00 # .... 前回の例でこのホストの指紋がすでに保存されていれば この man:scp[1] を使う時に検証が行なわれます。 man:scp[1] に渡される引数は、man:cp[1] のものと似ており、コピーするファイル (1 つまたは複数) が 1 つめの引数になり、コピー先が 2 つめの引数になります。 ファイルはネットワーク越しに SSH 接続を通して送られるので、 引数に指定するファイルに `user@host:` という形式をとるものがあります。 === 設定 システム全体の設定ファイルは、OpenSSH デーモン、クライアントの両方とも [.filename]#/etc/ssh# にあります。 [.filename]#ssh_config# はクライアントの動作設定、 [.filename]#sshd_config# はデーモンの動作設定を行ないます。 それぞれのファイル毎にマニュアルページが用意されており、 利用可能な設定オプションについて説明されています。 [[security-ssh-keygen]] === man:ssh-keygen[1] パスワードの代わりに man:ssh-keygen[1] を使ってユーザの認証用の DSA または RSA 暗号鍵を作ることができます。 [source,shell] .... % ssh-keygen -t dsa Generating public/private dsa key pair. Enter file in which to save the key (/home/user/.ssh/id_dsa): Created directory '/home/user/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/user/.ssh/id_dsa. Your public key has been saved in /home/user/.ssh/id_dsa.pub. The key fingerprint is: bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8f:79:17 user@host.example.com .... man:ssh-keygen[1] は認証に使う為の公開鍵と秘密鍵のペアを作ります。 DSA または RSA 鍵に応じて、 秘密鍵は [.filename]#~/.ssh/id_dsa# または [.filename]#~/.ssh/id_rsa# に保存され、 公開鍵は [.filename]#~/.ssh/id_dsa.pub# または [.filename]#~/.ssh/id_rsa.pub# にそれぞれ保存されます。 公開鍵はセットアップのために、 DSA または RSA のどちらを使う場合にも、 リモートマシンの [.filename]#~/.ssh/authorized_keys# に含まれてなければなりません。 この設定により、パスワードに代わり、 SSH 鍵を使ってリモートマシンに接続できるようになります。 [WARNING] ==== 多くのユーザは、鍵が設計上安全と信じ、 パスフレーズなしに鍵を利用しています。 このような使用方法は _危険_ です。 管理者が鍵にパスフレーズが設定されているかを確認する方法は、 手動で鍵を調べる方法です。 秘密鍵のファイルに `ENCRYPTED` という単語が含まれている場合には、 鍵の所有者は、パスフレーズを使用しています。 弱いパスフレーズが使われている間、 少なくともシステムが危険にさらされているときには、 他のサイトへのアクセスには、 あるレベルでのパスワード類推が必要となります。 さらに、公開鍵ファイルに `from` を含めることで、 エンドユーザをより安全にできます。 たとえば、 `ssh-rsa` または `rsa-dsa` の前に、 `from="192.168.10.5` を加えることで、 この IP を持つホストからのユーザのみがアクセスできるようになります。 ==== man:ssh-keygen[1] でパスフレーズを使っている場合は、 秘密鍵を使うためにユーザは毎回パスフレーズを入力する必要があります。 長いパスフレーズを毎回入力しなくてはならない負担は、 man:ssh-agent[1] を使うと軽減できます。 これについては、 <> で説明されています。 [WARNING] ==== OpenSSH のバージョンによって、 オプションやファイルに違いが出てくることがあります。 man:ssh-keygen[1] を参照して、 問題が起こることを避けてください。 ==== [[security-ssh-agent]] === SSH Agent による鍵のキャッシュ パスフレーズを毎回入力することなしに、 SSH 鍵を利用できるようにメモリに読み込むには、 man:ssh-agent[1] および man:ssh-add[1] を使用してください。 man:ssh-agent[1] は、 読み込まれた秘密鍵による認証を取り扱います。 man:ssh-agent[1] は他のアプリケーションの起動に用いられる必要があります。 基本的なレベルではシェル、 またはウィンドウマネージャを起動します。 シェル上で man:ssh-agent[1] を使うには、 引数としてシェルを起動してください。 次に、man:ssh-add[1] を実行し、 秘密鍵のパスフレーズを入力することにより、 鍵を追加してください。 一度この過程を終えてしまえば、ユーザは、 対応する公開鍵が置かれているホストに man:ssh[1] でログインできるようになります。 以下はその例です。 [source,shell] .... % ssh-agent csh % ssh-add Enter passphrase for /home/user/.ssh/id_dsa: Identity added: /home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa) % .... Xorg 上で man:ssh-agent[1] を使うには、 man:ssh-agent[1] への呼び出しが [.filename]#~/.xinitrc# に置かれている必要があります。 これにより、Xorg 上で起動されるすべてのプログラムにおいて、 man:ssh-agent[1] サービスが提供されるようになります。 [.filename]#~/.xinitrc# の例は以下となります。 [.programlisting] .... exec ssh-agent startxfce4 .... これで、Xorg を開始するときにはいつでも man:ssh-agent[1] が起動され、 このプログラムから XFCE が起動されます。 Xorg を再起動した後は有効になりますので、 man:ssh-add[1] を実行して、 すべての SSH 鍵を読み込ませてください。 [[security-ssh-tunneling]] === SSH トンネリング OpenSSH は暗号化されたセッションの中に他のプロトコルをカプセル化するトンネルを作ることができます。 以下のコマンドは man:ssh[1] で man:telnet[1] 用のトンネルを作成します。 [source,shell] .... % ssh -2 -N -f -L 5023:localhost:23 user@foo.example.com % .... この例では、以下のオプションを使っています。 `-2`:: サーバへの接続に man:ssh[1] バージョン 2 を使うことを指示します。 `-N`:: はトンネルだけでコマンドはないことを示します。 省略されると man:ssh[1] は通常のセッションを開始します。 `-f`:: man:ssh[1] にバックグラウンド実行を強制します。 `-L`:: ローカルトンネルを _localport:remotehost:remoteport_ という形式で指定します。 `user@foo.example.com`:: 指定したリモート SSH サーバへログインに用いるログイン名。 SSH のトンネルは `localhost` の指定されたポートに listen するソケットを作ることで実現されています。 SSH はローカルのホスト/ポートで受けた接続すべてを SSH 接続経由で指定されたリモートホストのポートへ転送します。 この例では、`localhost` のポート _5023_ がリモートマシンの `localhost` のポート _23_ に転送されるようになっています。 _23_ は man:telnet[1] で用いられるので、これは SSH トンネルを通る暗号化された man.telnet.1; セッションを作ります。 このようにして SMTP や POP3 および FTP といったセキュアではない TCP プロトコルをカプセル化できます。 .man:ssh[1] を用いた SMTP 用の安全なトンネルの作成 [example] ==== [source,shell] .... % ssh -2 -N -f -L 5025:localhost:25 user@mailserver.example.com user@mailserver.example.com's password: ***** % telnet localhost 5025 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 mailserver.example.com ESMTP .... man:ssh-keygen[1] と別のユーザアカウントを組み合わせて使うことでより透過的な SSH のトンネル環境を作ることができます。 パスワードを入力するところで暗号鍵を使い、 トンネルは別のユーザ権限で実行することが可能です。 ==== ==== 実用的な SSH トンネルの例 ===== POP3 サーバへの安全な接続 ここでの例は、外部からの接続を受ける SSH サーバがあるとします。 同じネットワークには、POP3 サーバが動いているメールサーバがあるとします。 電子メールを安全なやり方で見るようにするには、 SSH サーバへの SSH 接続を行い、 メールサーバへのトンネルを作成することです。 [source,shell] .... % ssh -2 -N -f -L 2110:mail.example.com:110 user@ssh-server.example.com user@ssh-server.example.com's password: ****** .... トンネルが作成されて動作したら、 メールクライアントに対し `localhost` のポート 2110 に POP3 リクエストを送るように指示してください。 そこへの接続は、トンネルを経由して安全に `mail.example.com` に転送されます。 ===== 厳格なファイアウォールをすり抜ける 内向けおよび外向きの接続両方をフィルタするファイアウォールルールを課すネットワーク管理者もいます。 たとえば、 リモートのマシンからのアクセスに、man:ssh[1] および web サーフィンのための 22 番および 80 番ポートにしか接続させてもらえないかもしれません。 この場合 22 または 80 番以外を使う他のサービスへのアクセスを妨げます。 それに対する解決策は、 あなたが接続しているネットワークのファイアウォールの外部にあるマシンに対して SSH 接続を行い、 希望するサービスへのトンネルに利用することです。 [source,shell] .... % ssh -2 -N -f -L 8888:music.example.com:8000 user@unfirewalled-system.example.org user@unfirewalled-system.example.org's password: ******* .... この例では、ストリーミング Ogg Vorbis クライアントを `localhost` の 8888 番ポートに向けると、 `music.example.com` の 8000 番ポートに転送され、ファイアウォールをすり抜けられます。 === `AllowUsers` オプション ログインできるユーザや接続元を `AllowUsers` を使って制限することは、通常は良い考えです。 たとえば、 `root` が `192.168.1.32` からのみログインできるようにするには、 以下の行を [.filename]#/etc/ssh/sshd_config# に追加してください。 [.programlisting] .... AllowUsers root@192.168.1.32 .... `admin` がどこからでもログインできるようにするには、 ユーザ名そのものを記述してください。 [.programlisting] .... AllowUsers admin .... 複数のユーザは、以下のように同じ行に追加してください。 [.programlisting] .... AllowUsers root@192.168.1.32 admin .... [NOTE] ==== 注意すべきことは、 このコンピュータにログインする必要のあるすべてのユーザを指定することです。 設定されていないと、そのユーザはログインできなくなります。 ==== [.filename]#/etc/ssh/sshd_config# への変更が終わったら、 以下を実行して、設定ファイルを man:sshd[8] に読み込ませてください。 [source,shell] .... # service sshd reload .... === もっと詳しく知りたい人へ http://www.openssh.com/[OpenSSH] ウェブサイト クライアントオプションについて man:ssh[1], man:scp[1], man:ssh-keygen[1], man:ssh-agent[1], man:ssh-add[1] および man:ssh_config[5] サーバオプションについて man:sshd[8], man:sftp-server[8], man:sshd_config[5] [[fs-acl]] == ファイルシステムアクセス制御リスト (ACL) アクセス制御リスト (ACL) は、標準的な UNIX(R) のパーミッションモデルを、 POSIX(R).1e に互換する方法で拡張しています。 これにより、管理者がより洗練されたセキュリティモデルを利用し、 その恩恵を受けられるようになります。 FreeBSD の [.filename]#GENERIC# カーネルは、 UFS ファイルシステム用の ACL サポートを提供します。 カスタムカーネルをコンパイルして使用するユーザは、 カスタムカーネルのコンフィグレーションファイルに以下を追加してください。 [.programlisting] .... options UFS_ACL .... もしこのオプションが組み込まれていなければ、ACL に対応したファイルシステムをマウントしようとすると、 警告が表示されます。ACL は、ファイルシステムの拡張属性が有効になっていることに依存しています。 拡張属性は、UFS2 でネイティブ対応されています。 [NOTE] ==== UFS1 に拡張属性を付すように設定するのは、 UFS2 よりも高いレベルの管理オーバヘッドが必要になります。 また、UFS2 における拡張属性のパフォーマンスも大きく上がっています。 そのため、アクセス制御リストを利用する上では UFS2 を使うことが推奨されます。 ==== ACL は、マウント時の管理フラグ `acls` で有効にされます。 これは [.filename]#/etc/fstab# に記述できます。 マウント時のフラグは、man:tunefs[8] を使って、ファイルシステムヘッダのスーパブロックにある ACL フラグを変更するという方法で、 常に自動で設定されるようになります。一般的には、 下記の理由からスーパブロックフラグを使う方がよいでしょう。 * マウント時に指定した ACL フラグは `mount -u` による再マウントでは変更できません。 完全に man:umount[8] した上で、新たに man:mount[8] するしかありません。これは、起動後にルートファイルシステムで ACL を有効にできないことを意味します。 また、ファイルシステムを利用し始めた後では、 その配列を変えられないことも意味しています。 * スーパブロックフラグを設定すると、[.filename]#fstab# に記述されていなかったり、デバイスの順番が変わってしまっても、常に ACL が有効な状態でマウントされます。 こうすることで、ファイルシステムを ACL を有効にしないままマウントしてしまい、ACL が正しくないかたちで強制されるセキュリティの問題を防ぎます。 [NOTE] ==== 予期せず ACL を有効にしないでマウントしてしまうことを防ぐことが望まれます。 ACL を有効にし、その後無効にしてから、 拡張属性を取り消さないでまた有効にしてしまうと、 大変な状況になってしまいます。 一般的には、一度ファイルシステムで ACL を有効にしたら、無効にすべきではありません。そうしてしまうと、 ファイル保護がシステムのユーザの意図と齟齬をきたす可能性があるばかりか、 ACL を再度有効にすると、 それまでパーミッションが変更されてきたファイルに古い ACL を割り当ててしまい、 予想しない動作につながることも考えられます。 ==== ACL を有効にしたファイルシステムは、 パーミッション設定の表示に `+` (プラス) 記号がつきます。例えば、次のようになります。 [.programlisting] .... drwx------ 2 robert robert 512 Dec 27 11:54 private drwxrwx---+ 2 robert robert 512 Dec 23 10:57 directory1 drwxrwx---+ 2 robert robert 512 Dec 22 10:20 directory2 drwxrwx---+ 2 robert robert 512 Dec 27 11:57 directory3 drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_html .... この例では、ディレクトリ [.filename]#directory1#, [.filename]#directory2# および [.filename]#directory3# のすべてで ACL が働いています。 一方 [.filename]#public_html# は対象外です。 === ACL を利用する man:getfacl[1] は、 ファイルシステムの ACL を表示します。 たとえば、[.filename]#test# の ACL 設定を表示するには、 以下のコマンドを実行してください。 [source,shell] .... % getfacl test #file:test #owner:1001 #group:1001 user::rw- group::r-- other::r-- .... このファイルの ACL 設定を変更するには、 man:setfacl[1] を使用してください。 [source,shell] .... % setfacl -k test .... ファイルまたはファイルシステムから、 現在設定されている ACL をすべて取り除くには、`-k` を使ってください。 しかしながら、より好ましい方法は、 `-b` を使う方法です。 このオプションを使うと、ACL が動作するのに必要な基本のフィールドは残ります。 [source,shell] .... % setfacl -m u:trhodes:rwx,group:web:r--,o::--- test .... この例では、`-m` は、デフォルト ACL エントリを修正するために使われています。 先ほどのコマンドで設定は削除されたため、 定義されたエントリはありません。 このコマンドは、デフォルトオプションに戻し、 指定したオプションを割り当てます。 システムに存在しないユーザまたはグループを追加すると、 `Invalid argument` エラーが出力されてしまいます。 [[security-portaudit]] == サードパーティ製ソフトウェアのセキュリティ問題を監視する 近年、セキュリティの分野では、 脆弱性の評価方法に関して多くの改善が行わています。 今日ではどのオペレーティングシステムにおいても、 システムへの侵入の脅威は、 サードパーティ製ユーティリティをインストールし、 設定するほどに増加していきます。 脆弱性を評価することは、セキュリティにおいて主要な要素です。 FreeBSD は、ベースシステムに対して勧告を発行していますが、 すべてのサードパーティ製ユーティリティに対して勧告を発行することは、 FreeBSD プロジェクトの能力を超えています。 サードパーティ製ユーティリティに関わる脆弱性を軽減し、 管理者に対し、既知のセキュリティ問題について警告する方法が存在します。 FreeBSD には、portaudit と呼ばれる追加のユーティリティが、 この目的のために用意されています。 package:ports-mgmt/portaudit[] port は、FreeBSD セキュリティチームおよび ports 開発者がアップデートし、管理している、 既知のセキュリティ問題に対するデータベースを入手します。 Ports Collection から portaudit をインストールするには、以下のように実行してください。 [source,shell] .... # cd /usr/ports/ports-mgmt/portaudit && make install clean .... インストールの途中で、 man:periodic[8] の設定ファイルはアップデートされ、 毎日のセキュリティに関するスクリプトの実行中に portaudit が出力するように設定されます。 毎日のセキュリティに関するスクリプトの実行結果のメールが読めることを確認してください。 このメールは、`root` アカウントに送られます。 他の設定は必要ありません。 インストールが終わったら、管理者は以下のコマンドを実行することで、 データベースをアップデートし、インストールされている package の脆弱性を調べることができます。 [source,shell] .... # portaudit -Fda .... [NOTE] ==== データベースは、 man:periodic[8] の実行中に自動的にアップデートされます。 先程のコマンドの実行は任意で、 データベースを手動で直ちにアップデートするときに使われます。 ==== Ports Collection からインストールされたサードパーティ製ユーティリティを監査するには、 管理者は以下のコマンドを実行する必要があります。 [source,shell] .... # portaudit -a .... portaudit は、インストールされている package の中で、 脆弱性のあるものについて以下のようなメッセージを出力します。 [.programlisting] .... Affected package: cups-base-1.1.22.0_1 Type of problem: cups-base -- HPGL buffer overflow vulnerability. Reference: 1 problem(s) in your installed packages found. You are advised to update or deinstall the affected package(s) immediately. .... 表示されている URL をウェブブラウザで開くと、管理者は、 脆弱性についてより多くの情報を得ることができます。 ここでの出力では、影響するバージョンが FreeBSD の port バージョンにより示され、 セキュリティ勧告を含む他のウェブサイトが含まれています。 portaudit は強力で、 portmaster port と共に使うときわめて有用なユーティリティです。 [[security-advisories]] == FreeBSD セキュリティ勧告 多くの高品質なオペレーティングシステムと同様、 FreeBSD は "セキュリティ勧告" を発行しています。 これらの勧告は、通常セキュリティに関連したのメーリングリストに投稿され、 サポートされているリリースに対してパッチが作成された後、 Errata に記載されます。 この章では、セキュリティ勧告とは何か、どのように理解すべきか、 システムにパッチを当てるにはどのように対応すればよいかについて説明します。 === セキュリティ勧告はどのようなものか？ FreeBSD セキュリティ勧告では、 以下のようなフォーマットが用いられています。 [.programlisting] .... ============================================================================= FreeBSD-SA-XX:XX.UTIL Security Advisory The FreeBSD Project Topic: denial of service due to some problem <.> Category: core <.> Module: sys <.> Announced: 2003-09-23 <.> Credits: Person <.> Affects: All releases of FreeBSD <.> FreeBSD 4-STABLE prior to the correction date Corrected: 2003-09-23 16:42:59 UTC (RELENG_4, 4.9-PRERELEASE) 2003-09-23 20:08:42 UTC (RELENG_5_1, 5.1-RELEASE-p6) 2003-09-23 20:07:06 UTC (RELENG_5_0, 5.0-RELEASE-p15) 2003-09-23 16:44:58 UTC (RELENG_4_8, 4.8-RELEASE-p8) 2003-09-23 16:47:34 UTC (RELENG_4_7, 4.7-RELEASE-p18) 2003-09-23 16:49:46 UTC (RELENG_4_6, 4.6-RELEASE-p21) 2003-09-23 16:51:24 UTC (RELENG_4_5, 4.5-RELEASE-p33) 2003-09-23 16:52:45 UTC (RELENG_4_4, 4.4-RELEASE-p43) 2003-09-23 16:54:39 UTC (RELENG_4_3, 4.3-RELEASE-p39) <.> CVE Name: CVE-XXXX-XXXX <.> For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit http://www.FreeBSD.org/security/. I. Background <.> II. Problem Description <.> III. Impact <.> IV. Workaround <.> V. Solution <.> VI. Correction details <.> VII. References <.> .... <.> `Topic` フィールドでは、 問題について明記されています。 セキュリティ勧告の導入部であり、 脆弱性に影響されるユーティリティを示します。 <.> `Category` フィールドでは、 脆弱性がシステムのどの部分に影響するかを示します。 `core`, `contrib` または `ports` のどれかが示されます。 `core` カテゴリは、 FreeBSD オペレーティングシステムの `core` コンポーネントに影響する脆弱性であることを意味します。 `contrib` カテゴリは、 Sendmail のように、FreeBSD の外で開発され、FreeBSD プロジェクトに取り込まれたソフトウェアに影響する脆弱性であることを意味します。 `ports` カテゴリは、Ports Collection からインストールされるソフトウェアに影響する脆弱性であることを示しています。 <.> `Module` フィールドは、 影響するコンポーネントについて言及します。 この例では、`sys` モジュールに影響することがわかります。 そのため、この脆弱性は、 カーネルの中で使われるコンポーネントに影響します。 <.> `Announced` フィールドは、 セキュリティ勧告が発行された日、 またはアナウンスされた日が記載されています。 セキュリティチームによりこの問題が存在することが確認され、 パッチが FreeBSD ソースコードリポジトリにコミットされたことを意味します。 <.> `Credits` フィールドは、 脆弱性を通知し、報告した個人または組織を示します。 <.> `Affects` フィールドは、この脆弱性がどの FreeBSD リリースに影響するかを説明します。 カーネルでは、影響するファイルに対して man:ident[1] を実行すると、 その出力からリビジョンを簡単に確認できます。 ports の場合には、 [.filename]#/var/db/pkg# の port の名前の後に、バージョン番号が示されています。 もし、システムが FreeBSD Subversion リポジトリと同期していなかったり、 再構築が毎日行われているような状況でなければ、 おそらく、そのシステムには影響しているでしょう。 <.> `Corrected` フィールドは、 脆弱性が修正された日、時間、 タイムゾーン、およびリリースが示されます。 <.> http://cve.mitre.org[Common Vulnerabilities and Exposures] データベースにおいて、 脆弱性を探すために使用できる識別情報を示します。 <.> `Background` フィールドは、 影響しているユーティリティに関する情報を示します。 大体の場合は、なぜユーティリティが FreeBSD に存在するか、 何のために使われているか、 どのように用いられるようになってきたか、 といった情報が示されます。 <.> `Problem Description` フィールドは、 より深くセキュリティホールについて説明します。 問題のあるコードの情報や、 このユーティリティが悪意のある使い方により、 どのようにセキュリティホールを開けうるかといったことが示されます。 <.> `Impact` フィールドは、 この問題がシステムに対して、 どのような形式の影響を与えるかについて示します。 たとえば、DoS 攻撃によるものか、 ユーザに対して意図しない特権を持たせてしまうものか、 または、攻撃者にスーパユーザのアクセスを与えるようなものか、 といったことが示されます。 <.> `Workaround` フィールドは、 時間による制限や、ネットワークの可用性または他の理由により、 システムをアップグレードできないシステム管理者に対して、 回避方法を提供します。 セキュリティを甘く見るべきではなく、 影響するシステムにはパッチを当てるか、 セキュリティホールの回避方法を実行すべきです。 <.> `Solution` フィールドは、 影響のあるシステムにパッチを当てる手順を提供します。 ここではステップごとにシステムにパッチを当て、 安全に動作するように、 試験され検証された方法が記載されます。 <.> `Correction Details` フィールドは、 Subversion ブランチまたはリリース名のピリオドをアンダースコアに置き換えたものを示します。 ここでは、 各ブランチにおいて影響するファイルのリビジョン番号も示します。 <.> `References` フィールドは、 通常、ウェブページの URL, books, メーリングリストおよびニュースグループといった、 ほかの情報へのソースを提供します。 [[security-accounting]] == プロセスアカウンティング プロセスアカウンティングは、 管理者が使用されているシステムのリソースを記録したり、 リソースのユーザへの割り当て、 システムのモニタリングおよびユーザのコマンドの最低限の記録を提供します。 これは実際には、長所と短所があります。 長所の一つは、侵入を入り口の時点で絞ることができます。 短所は、プロセスアカウンティングにより生成されるログの量で、 多くのディスク容量を必要とします。この節では、 管理者を対象にプロセスアカウンティングの基礎を説明します。 === プロセスアカウンティングを有効にする プロセスアカウンティングを使用する前に、 以下のコマンドを使って、 プロセスアカウンティングを有効にしておく必要があります。 [source,shell] .... # touch /var/account/acct # chmod 600 /var/account/acct # accton /var/account/acct # echo 'accounting_enable="YES"' >> /etc/rc.conf .... 一度有効に設定すると、アカウンティングは、 CPU の統計、 実行されたコマンドの情報の追跡を開始します。 すべてのアカウンティングログは、 人が読めるような形式ではなく、 man:sa[8] を使って見ることができます。 オプションを設定せずに実行すると、 man:sa[8] はユーザコールの数、全経過時間 (分)、 全 CPU、ユーザの時間 (分)、および I/O 操作の平均数などを出力します。 実行されたコマンドに関する情報を見るには、 man:lastcomm[1] を使ってください。 このコマンドは、 ユーザが特定の man:ttys[5] で実行したコマンドを出力します。 たとえば、以下のコマンドは `ttyp1` ターミナル上で `trhodes` が実行した man:ls[1] の使用について、記録されているすべて示します。 [source,shell] .... # lastcomm ls trhodes ttyp1 .... 他にも有用なオプションが多くあり、 man:lastcomm[1], man:acct[5] および man:sa[8] で説明されています。 [[security-resourcelimits]] == リソースの制限 長年にわたり FreeBSD は、 リソースを制限するためのデータベースとしてフラットファイル形式の [.filename]#/etc/login.conf# により管理していました。 この方法は、現在でも使われていますが、 リソースを管理する方法としては最適な方法でないことが、 以前から議論されています。 フラットファイル形式では、 クラスとして知られるグループラベルにユーザを分類する必要があります。 この場合、フラットファイルだけではなく、 パスワードデータベースに対しても変更が必要となります。 潜在的に、より多くの制限を加えられたユーザ対してはラベルの追加や、 `cap_mkdb` を使ったリソースデータベースの再構築、 [.filename]#/etc/master.passwd# への変更が必要となります。 さらに、パスワードデータベースは、 `pwd_mkdb` を使って再構築する必要があります。 この複数回に渡るプロセスは、 多くのユーザについて設定する必要がある場合には、 大変な時間の浪費につながる可能性があります。 FreeBSD の新しいコマンドである man:rctl[8] は、 ユーザに対して、 よりきめ細かにリソースの制限を管理する方法を提供します。 このコマンドは、ユーザだけではなく、プロセス、jails およびオリジナルのログインクラスに対してもリソースの制限を行うことができます。 これらの高度な機能は、管理者およびユーザに対し、 リソースをコマンドラインで管理したり、 設定ファイルを用いることで、システムの初期化時に、 ルールを設定する方法を提供します。 この機能を有効にするには、以下の行を [.filename]#GENERIC# またはカスタムカーネルコンフィグレーションファイルに追加し、 再構築してください。 [.programlisting] .... options RACCT options RCTL .... その後、システムの再起動が必要になります。 この過程の手順については、crossref:kernelconfig[kernelconfig,FreeBSD カーネルのコンフィグレーション] をご覧ください。 これらの準備が完了すると、`rctl` を用いてシステムにルールを設定できるようになります。 ルールの構文は簡単で、 _subject_, _subject-id_, _resource_ および _action_ を使って管理されます。 以下のルールの例を参照してください。 [.programlisting] .... user:trhodes:maxproc:deny=10/user .... これは基本的なルールです。 ここで、subject は `user`、 subject-id は `trhodes` です。 maxproc はもちろんプロセスの最大数であり、resource です。 ここで action は、`deny` と設定されており、 新しいプロセスの生成がブロックされます。 この例では、ユーザ `trhodes` のプロセスは `10` 個に制限され、それ以上のプロセスは作成できません。 コンソールにログを出力したり、 man:devd[8] に対し通知したり、プロセスに sigterm を送ったりといった、 他の action も利用できます。 ルールを追加する際には、注意すべき点がいくつかあります。 上の例では、ログインして `screen` セッションを実行してしまうと、 不幸にもユーザは最も簡単なタスクの実行ですらブロックされてしまうでしょう。 リソースの制限が適応されると、エラーが出力されます。 この例では以下のような出力が行われます。 [source,shell] .... % man test /usr/bin/man: Cannot fork: Resource temporarily unavailable eval: Cannot fork: Resource temporarily unavailable .... 他の例としては、man:rctl[8] を使って jail がメモリの制限を超えることを防ぐことができます。 このルールは以下のように書くことができます。 [source,shell] .... # rctl -a jail:httpd:memoryuse:deny=2G/jail .... ルールを [.filename]#/etc/rctl.conf# に追加すると、 再起動してもルールは持続します。 フォーマットは、ルールから最初のコマンドの部分を除いたものとなります。 たとえば、上のルールを追加するには、 以下のように追加してください。 [.programlisting] .... # Block jail from using more than 2G memory: jail:httpd:memoryuse:deny=2G/jail .... ルールを削除するには、`rctl` に対し、 リストから削除するように指定してください。 [source,shell] .... # rctl -r user:trhodes:maxproc:deny=10/user .... マニュアルページには、 ルールをすべて削除する方法が記載されています。 しかしながら、特定のユーザのルールをすべて削除するには、 以下のようなコマンドを実行してください。 [source,shell] .... # rctl -r user:trhodes .... `subjects` をコントロールするリソースは他にも多く用意されています。 これらについて知るには、man:rctl[8] をご覧ください。 diff --git a/documentation/content/ja/books/handbook/serialcomms/_index.adoc b/documentation/content/ja/books/handbook/serialcomms/_index.adoc index 60596b4a04..5ff625061b 100644 --- a/documentation/content/ja/books/handbook/serialcomms/_index.adoc +++ b/documentation/content/ja/books/handbook/serialcomms/_index.adoc @@ -1,1327 +1,1327 @@ --- -title: 第18章 シリアル通信 +title: 第17章 シリアル通信 part: パートIV. ネットワーク通信 prev: books/handbook/partiv next: books/handbook/ppp-and-slip showBookMenu: true -weight: 23 +weight: 22 path: "/books/handbook/" --- [[serialcomms]] = シリアル通信 :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 -:sectnumoffset: 18 +:sectnumoffset: 17 :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/serialcomms/ ifdef::env-beastie[] ifdef::backend-html5[] :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [[serial-synopsis]] == この章では Unix は現在に至るまで、常にシリアル通信機能をサポートしていました。 実際、本当に初期の Unix マシンは、ユーザとの入出力にシリアル通信を使っていました。 10 文字毎秒のシリアルプリンタ、 キーボードから構成された "端末(terminal)" が広く使われていた当時とは、 何もかもがすっかり変わっています。この章では、FreeBSD でシリアル通信を行なういくつかの方法について説明しています。 この章を読むと、以下のことがわかります。 * FreeBSD システムへの端末の接続方法 * リモートホストへダイヤルするためのモデムの使い方 * リモートのユーザがモデムでシステムにログインできるようにする方法 * シリアルコンソールからのシステム起動方法 この章を読む前に、以下のことを行っておくべきです。 * 新しいカーネルを構成してインストールする方法を覚える (crossref:kernelconfig[kernelconfig,FreeBSD カーネルのコンフィグレーション])。 * Unix のパーミッションとプロセスについて理解する (crossref:basics[basics,UNIX の基礎知識])。 * FreeBSD で使おうとしているシリアルハードウェア (モデムまたはマルチポートカード) のテクニカルマニュアルを読めるようにする。 [[serial]] == はじめに [[serial-terminology]] === 用語解説 bps:: Bits per Second の略で、 データの転送速度を表す単位。 DTE:: Data Terminal Equipment の略。 たとえばコンピュータ本体のこと DCE:: Data Communications Equipment の略で、具体的にはモデムのこと。 RS-232:: EIA (米電気産業協会) のハードウェアシリアル通信の標準規格 通信におけるデータ転送速度に関して、 このセクションでは "ボー" (baud) という用語は使いません。 ボーというのは一定時間に生じうる電気的状態の変化の数を表すにすぎず、 "bps" (bits per second) という単位の方が__正しい__からです (少なくとも、こういう表現をしておけば、 意地の悪い人に怒られることもないのではないかと思います)。 [[serial-cables-ports]] === ケーブルとポート モデムまたはシリアル端末を FreeBSD システムに接続するためには、 コンピュータ上のシリアルポートと、 シリアルデバイスに接続する適切なケーブルが必要です。 ハードウェアとそれが必要とするケーブルについてよく理解しているなら、 この節は飛ばしても問題ありません。 [[term-cables]] ==== ケーブル シリアルケーブルにはさまざまな種類があります。 我々の目的にあうもっとも一般的な 2 種類は、 ヌルモデムケーブル と、スタンダード (ストレート) RS-232 ケーブルです ハードウェアの説明文書に必要なケーブルの種類が記載されているはずです。 [[term-cables-null]] ===== ヌルモデムケーブル ヌルモデムケーブル (またはリバースケーブルあるいはクロ スケーブル) は、たとえば "signal ground" 信号のように、いくつかの信 号はそのまま通しますが、 他の信号は途中で入れ替えて通します。たとえば、"send data" 信号のピンは、反対側のコネクタの "receive data" 信号の ピンと繋がっています。 自分で使うケーブルは自分で作りたいということであれば、 端末で使うヌルモデムケーブルを作成できます。この表では、 RS-232C の信号線の名前と、DB-25 コネクタ上のピンの番 号を示しています。 [.informaltable] [cols="1,1,1,1,1", frame="none", options="header"] |=== | Signal | Pin # | | Pin # | Signal |TxD |2 |connects to |3 |RxD |RxD |3 |connects to |2 |TxD |DTR |20 |connects to |6 |DSR |DSR |6 |connects to |20 |DTR |SG |7 |connects to |7 |SG |DCD |8 |connects to |4 |RTS |RTS |4 | |5 |CTS |CTS |5 |connects to |8 |DCD |=== [NOTE] ==== DCD と RST では、コネクタ内部でピン4を5に接続し、 そして逆側のコネクタのピン8と接続します。 ==== [[term-cables-std]] ===== スタンダード RS-232C ケーブル スタンダードシリアルケーブル (またはストレートケーブル) の場合は、すべての RS-232C 信号をそのまま通します。つまり、片方の "send data" 信号のピンは、逆側の "send data" 信号のピンと繋がっています。モデムを FreeBSD に接続するときや、一部の端末を接続するときにこのタイプの ケーブルを使用します。 [[term-ports]] ==== ポート シリアルポートは、FreeBSDが動作しているホスト コンピュータと端 末の間でデータのやりとりを行うために用いるデバイスです。 ここでは、現在存在するポートの種類と FreeBSD でのポートのアクセス方法について解 説します。 [[term-portkinds]] ===== ポートの種類 シリアルポートには何種類かのものがあります。 ケーブルを購 入したり自作したりする前に、 そのケーブルのコネクタの形状が端末および FreeBSD システムのポートの形状と一致していることを 確認してください。 ほとんどの端末は DB25 ポートを搭載しています。 FreeBSDが動作しているも のを含めて、PCは DB25 または DB9 ポートを搭載しています。マルチポート のシリアルカードの場合は、RJ-12 や RJ-45 のポートを搭載しているかもし れません。 利用されているポートの種類に関しては、 ハードウェアについてきたドキュメントを参照してください。 また、多くの場合、ポートの形状から判断することもできるでしょう。 [[term-portnames]] ===== ポートの名前 FreeBSDでは、[.filename]#/dev# ディレクトリ内のエントリを介 してシリアルポートへのアクセスがおこなわれます。 2種類の異なったエン トリがあります。 * 着信用のポートの名前は、 [.filename]#/dev/ttydN# (_N_ は 0から始まるポート番号) となっています。一般に端末の接続には 着信用ポートを用います。着信用のポートでは、 シリアルラインのデータ キャリア検出 (DCD) 信号がオンになっている必要があります。 * 発信用のポートの名前は、 [.filename]#/dev/cuaaN# となっています。 発信用のポートは普通モデムの接続に用い、端末の接続には 利用しません。ただ、 ケーブルまたは端末がキャリア検出信号を使えない タイプのものの場合は、 発信用のポートを使うとよいでしょう。 たとえば、端末を一つ目のシリアルポート (MS-DOS でいうところの [.filename]#COM1#) に接 続したとすると、[.filename]#/dev/ttyd0# がこの端末を指すことになります。また、 二つ目のシリアルポート ([.filename]#COM2#) ならば [.filename]#/dev/ttyd1# となり、 以下この形式のデバイスエントリを使います。 === カーネルの設定 デフォルトでは、FreeBSD は 4 つのシリアルポートに対応しています。MS-DOS の世界では、 [.filename]#COM1#, [.filename]#COM2#, [.filename]#COM3# および [.filename]#COM4# と呼ばれています。 FreeBSD では、現在のところ BocaBoard の 1008 や 2016 などの、 "単純な"マルチポートシリアルインタフェースや、 Digiboard や Stallion Technologies が製造しているよりインテリジェントなマルチポートカードにも対応しています。 しかしながら、デフォルトのカーネルは、標準の COM ポートしか見ません。 搭載されているシリアルポートのいずれかを、 カーネルが認識しているかどうか確認したい場合は、 カーネルの起動時のメッセージを注意深く見るか、あるいは `/sbin/dmesg` コマンドを使って、 起動時の出力メッセージを確認してください。特に、 `sio` で始まるメッセージをよく見てください。 [TIP] ==== 以下のコマンドで `sio` という文字列を含むメッセージだけを表示できます。 [source,shell] .... # /sbin/dmesg | grep 'sio' .... ==== たとえば、シリアルポートを四つ持つシステムの場合は、 以下のようなシリアルポートに関するメッセージがカーネルによって表示されます。 [source,shell] .... sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A sio2 at 0x3e8-0x3ef irq 5 on isa sio2: type 16550A sio3 at 0x2e8-0x2ef irq 9 on isa sio3: type 16550A .... もし、カーネルに正常に認識されないポートがある場合は、 おそらくカスタマイズした FreeBSD カーネルを構築する必要があるでしょう。 カーネルコンフィグレーションの詳細については crossref:kernelconfig[kernelconfig,FreeBSD カーネルのコンフィグレーション] をご覧ください。 カーネルコンフィグレーションの該当するデバイス行は、 次のようになります。 [.programlisting] .... device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr device sio2 at isa? port "IO_COM3" tty irq 5 vector siointr device sio3 at isa? port "IO_COM4" tty irq 9 vector siointr .... システムに搭載されていないデバイスに関する記述は、 コメントアウトまたは削除してしまってかまいません。 man:sio[4] のマニュアルを見て、 マルチポートのボードのためのコンフィグレーションファイルの記述の仕方を確認してください。 デバイスのフラグの指定方法がバージョンによって異なりますので、 別のバージョンの FreeBSD で利用していたコンフィグレーションファイルを流用する場合には十分注意してください。 [NOTE] ==== なお、`port "IO_COM1"`, `IO_COM2`, `IO_COM3` および `IO_COM4` は、 それぞれのポートの一般的なアドレスである `0x3f8`, `0x2f8`, `0x3e8` および `0x2e8` を表します。また、割り込み番号 4, 3, 5 と 9 は、それぞれ [.filename]#COM1:# から [.filename]#COM4:# のポートで一般的に使用される IRQ です。また、ISA バスのコンピュータの場合、 一般的なシリアルポートは複数のポートで一つの IRQ を共有することが __できません__ので注意が必要です (マルチポートのシリアルボードの場合は、複数の 16550A ベースのポートで一つまたは二つの IRQ を共有するための機構を備えています)。 ==== === デバイススペシャルファイル カーネルに組み込まれているほとんどのデバイスは、 [.filename]#/dev# ディレクトリにある、 "デバイススペシャルファイル"を介してアクセスされます。 [.filename]#sio# デバイスの場合は、着信用の [.filename]#/dev/ttydN# および、発信用の [.filename]#/dev/cuaaN# が利用されます。さらに、FreeBSD は、初期化デバイス ([.filename]#/dev/ttyidN# と [.filename]#/dev/cuai0N#) およびロッキングデバイス ([.filename]#/dev/ttyldN# と [.filename]#/dev/cual0N#) も用意しています。 初期化デバイスは、通信ポートがオープンされる度に、 そのポートの初期設定を行うために使われます。たとえば、 `RTS/CTS` によるフロー制御を行うモデムが接続されている場合の `crtscts` などのパラメータの初期化が行われます。 ロッキングデバイスは、ポートの設定をロックし、 他のユーザやプログラムにこれらを変更されることのないようにするために利用されます。 通信ポートの設定、デバイスのロックと初期化および設定の変更に関しては、 それぞれ man:termios[4], man:sio[4] と man:stty[1] のマニュアルをご覧ください。 ==== デバイススペシャルファイルの作成 [NOTE] ==== FreeBSD 5.0 には、 必要に応じてデバイスノードを自動的に作成する `devfs` ファイルシステムがあります。 `devfs` が有効になっているバージョンの FreeBSD を動かしているなら、 この節は飛ばしてかまいません。 ==== デバイススペシャルファイルの管理は、ディレクトリ [.filename]#/dev# にあるシェルスクリプト `MAKEDEV` で行います。 `MAKEDEV` を使って、 [.filename]#COM1# (ポート 0) をダイアルアップのポートとして利用するための デバイススペシャルファイルを作るには、 [.filename]#/dev# に `cd` してから、 `MAKEDEV ttyd0` と実行してください。 同様に、`MAKEDEV ttyd1` とすることで、 [.filename]#COM2# (ポート 1) 用のデバイススペシャルファイルを作成できます。 `MAKEDEV` は、 [.filename]#/dev/ttydN# のデバイススペシャルファイルだけでなく、 [.filename]#/dev/cuaaN#, [.filename]#/dev/cuaiaN#, [.filename]#/dev/cualaN#, [.filename]#/dev/ttyldN# および [.filename]#/dev/ttyidN# ノードも作成します。 デバイススペシャルファイルの作成後、 これらのファイルの許可属性が適切に設定されていて、 これらのデバイスを利用してもよいユーザのみが読み書きできるようになっていることを確認してください (特に [.filename]#/dev/cua*# の許可属性には注意を払ってください)。 この確認を怠ると、 一般のユーザがあなたのモデムを使うことができるようなことになりかねません。 デフォルトの [.filename]#/dev/cua*# の許可属性は、以下のようになっていて、 たいていの場合適切なものだと思います。 [source,shell] .... crw-rw---- 1 uucp dialer 28, 129 Feb 15 14:38 /dev/cuaa1 crw-rw---- 1 uucp dialer 28, 161 Feb 15 14:38 /dev/cuaia1 crw-rw---- 1 uucp dialer 28, 193 Feb 15 14:38 /dev/cuala1 .... 上の設定では、ユーザ `uucp` と、グループ `dialer` に属するユーザが発信用のデバイスを利用できます。 [[serial-hw-config]] === シリアルポートの設定 [.filename]#ttydN# (または [.filename]#cuaaN#) デバイスは、 アプリケーション上でシリアルポートをオープンする時に使用する、 標準的なデバイスです。プロセスがデバイスをオープンする際、端末 I/O 設定のデフォルトセットが適用されます。これらの設定内容は、 次のコマンドで確認することができます。 [source,shell] .... # stty -a -f /dev/ttyd1 .... このデバイスの設定を変更した場合、 その設定はデバイスがクローズされるまで有効です。 デバイスが再びオープンされる時、デフォルトの設定値に戻ります。 デフォルトの設定を変更するためには、"初期状態" を設定したいデバイスをオープンして調節できます。 たとえば、[.filename]#ttyd5# というデバイスに対して、デフォルトで `CLOCAL` モード, 8 bits, `XON/XOFF` フロー制御を設定したい場合は、 次のように入力してください。 [source,shell] .... # stty -f /dev/ttyid5 clocal cs8 ixon ixoff .... システム全体のシリアルデバイス初期化は [.filename]#/etc/rc.serial# で制御されています。 このファイルは、シリアルデバイスのデフォルトの設定を決めます。 また、"ロック状態"のデバイスに調節を加えることで、 アプリケーションがある種の設定を変更してしまうことを防げます。 たとえば、[.filename]#ttyd5# の速度を 57600 bps に固定したい場合には、次のように入力してください。 [source,shell] .... # stty -f /dev/ttyld5 57600 .... これで、[.filename]#ttyd5# をオープンして、 シリアルポートの転送スピードを変更しようとするアプリケーションは 57600 bps で頭打ちになります。 本来、初期状態やロックされているデバイスに書き込めるのは `root` アカウントだけにすべきです。 [[term]] == シリアル端末 シリアル端末を利用することで、 コンピュータのコンソールのそばにいないときや、 手近にネットワーク接続されているコンピュータがないときでも、 FreeBSD の機能を便利に、かつ安価に利用することができます。 ここでは、FreeBSD にシリアル端末を接続する方法を解説します。 [[term-uses]] === 端末の種類と利用方法 もともと Unix システムにはコンソールがありませんでした。 ユーザはコンピュータのシリアルポートに接続された端末からログインしてプログラムを利用していました。 ちょうどモデムと通信ソフトを使ってリモートのコンピュータにログインし、 テキストベースのプログラムを利用するのとよく似ています。 最近の PC は、 高品質の画像を表示できるコンソールを搭載していますが、 ほとんどすべての Unix 系 OS には未だにシリアルポートを使ってログインするための機能があり、 FreeBSD でもこの機能がサポートされています。 現在使用されていないシリアルポートに端末を接続することでシステムにログインし、 通常はコンソールや X ウィンドウシステムの `xterm` のウィンドウ上で起動しているテキストベースのプログラムであれば何でも利用できます。 職場での利用ということで考えるならば、FreeBSD が動作しているコンピュータに接続された何台ものシリアル端末を各社員の机に配置するというようなことが可能です。 また、家庭での利用方法としては、余っている古い IBM PC や Macintosh を FreeBSD が動いているパワフルなコンピュータの端末として利用できます。 普通ならシングルユーザのコンピュータを、 パワフルなマルチユーザのシステムに変えることができるのです。 FreeBSD では、以下に挙げる 3 種類の端末が利用できます。 * <> * <> * <> 以下は、それぞれについての解説です。 [[term-dumb]] ==== ダム端末 ダム端末は、 シリアルライン経由でのコンピュータとの接続専用のハードウェアです。 ダム端末は、テキストの送受信および表示ができる程度の計算能力しかもっていないので、 "dumb" (間抜け) というように呼ばれています。 この端末上でプログラムを実行することはできません。 テキストエディタ、コンパイラ、E-mail、 ゲームなどなどのプログラムを実行するのは、 ダム端末を接続しているコンピュータの方です。 Digital Equipment 社の VT-100 や、Wyse 社の WY-75 を初めとして、多くのメーカが何百種類ものダム端末を作っています。 ほとんどどんな種類のダム端末でも FreeBSD に接続して使用できます。さらに、 高性能の端末の中には画像を取り扱えるものもありますが、 限られた数のソフトウェアパッケージしかこういった機能には対応していません。 ダム端末は、 X ウィンドウシステムで提供されるようなグラフィックアプリケーションを必要としない職場で広く用いられています。 [[term-pcs]] ==== PC を端末として利用する <> がテキストの表示および送受信の機能をそなえただけのものならば、 言うまでもなく、どんな PC もダム端末になり得ます。 必要なものは適切なケーブルと、その PC の上で動作する__端末エミュレーション__ を行うソフトウェアのみです。 このような環境は、家庭においてよく利用されます。 たとえば、あなたの同居人が FreeBSD のコンソールを専有している時などに、 あまりパワーのないコンピュータを FreeBSD システムにシリアル端末として接続し、 その端末上でテキストだけを用いる作業をおこなうことができます。 [[term-x]] ==== X 端末 X 端末は、 既存のものの中で最も洗練された種類の端末といえます。 X 端末は、たいていの場合シリアルポートではなく、 イーサネットのようなネットワークを利用した接続をおこないます。 また、アプリケーションの利用においても、 テキストベースのものだけでなく、 X アプリケーションの利用が可能です。 ここでは、参考までに端末について紹介しただけで、 X 端末の設定や利用についての解説は _おこないません_。 [[term-config]] === 設定 ここでは、端末からのログインを可能にするために必要な FreeBSD 側の設定について解説します。 既に端末を接続するポートが利用できるように kernel の設定をおこない、端末が接続されているものと考えて、解説を進め ます。 crossref:boot[boot,FreeBSD の起動のプロセス] で述べたように `init` プロセスは、 システム起動時にすべてのプロセス管理や初期化をおこなっています。 `init` が行っている仕事の一つは、 [.filename]#/etc/ttys# ファイルを読んで、利用可能な端末上で `getty` プロセスを起動することです。 `getty` プロセスは、 ログイン名を読み込み `login` プログラムを起動します。 したがって、FreeBSD の端末を設定するには、 `root` で次の手順を踏まなければなりません。 [.procedure] ==== . 端末を接続するポートの [.filename]#/dev# のエントリが含ま れている行がまだ存在しなければ、これを [.filename]#/etc/ttys# に追加してく ださい。 . `/usr/libexec/getty` が対象となるポートに対して 実行されるように指定してください。また、 [.filename]#/etc/gettytab# ファイ ル内の適切な _getty_ タイプのエントリを指定してください。 . デフォルトのターミナルタイプを指定してください。 . 対象となるポートを "on" に設定してください。 . そのポートが "secure" であるかどうかを指定してください。 . `init` に [.filename]#/etc/ttys# を読み込みなおさせてく ださい。 ==== また、必要に応じて [.filename]#/etc/gettytab# を変更し、上の 2で使用する _getty_ のエントリを追加してください。 この章ではこの方法については特に解説しませんので、man:gettytab[5] および man:getty[8] のマニュアルをご覧ください。 [[term-etcttys]] ==== [.filename]#/etc/ttys# へのエントリの追加 [.filename]#/etc/ttys# には、 FreeBSDシステム上のログインを許可するすべての ポートを記述します。たとえば、一つ目の仮想コンソール [.filename]#ttyv0# のエン トリもこのファイルにあります。このエントリのおかげで、 コンソールからの ログインが可能になっています。 このファイルには、他の仮想コンソール、シ リアルポートおよび仮想端末のエントリも含まれています。 端末を接続する場合は、そのポートの [.filename]#/dev# のエントリを、 [.filename]#/dev# の部分を省略して記述します (たとえば [.filename]#/dev/ttyv0# については、 [.filename]#ttyv0# として記述します)。 FreeBSD のデフォルトのインストール状態では、 [.filename]#ttyd0# から [.filename]#ttyd3# までの、初めの 4 つのシリアルポートに対応した [.filename]#/etc/ttys# ファイルが置かれています。 これらのポートのいずれかに端末を接続する場合は、 新たにエントリを追加する必要はありません。 [[ex-etc-ttys]] .端末の項目を [.filename]#/etc/ttys# に追加する [example] ==== システムに 2 台の端末、Wyse-50 と、VT-100 端末をエミュレートしている Procomm 端末ソフトウェアを動かしている古い 286 IBM PC をシステムに接続しようとしていると考えてください。 Wyse は 2 番目のシリアルポートに、286 は 6 番目のシリアルポート (マルチポートシリアルカード上のポート) に接続します。 [.filename]#/etc/ttys# 内の対応する項目は次のようになります。 [.programlisting] .... ttyd1 "/usr/libexec/getty std.38400" wy50 on insecure ttyd5 "/usr/libexec/getty std.19200" vt100 on insecure .... * 最初のフィールドには、通常 [.filename]#/dev# にある端末のスペシャルファイル名を指定します。 * 2 番目のフィールドは、 この回線に対して実行するコマンドで、通常は man:getty[8] です。`getty` は、回線を初期化して開き、速度を設定して、 ユーザ名を入力するプロンプトを出して man:login[1] プログラムを実行します。`getty` プログラムは、 コマンドラインから (省略可能な) パラメータ _getty_ タイプを受け取ります。 _getty_ タイプは、 bps レートやパリティのような端末回線の特性を示します。 `getty` プログラムは、 これらの特性を [.filename]#/etc/gettytab# ファイルから読み込みます。[.filename]#/etc/gettytab# ファイルには、 端末回線について新旧多くの項目があります。 ほとんどの場合、`std` で始まる項目は、ケーブルで接続された端末に働きます。 これらの項目はパリティを無視します。110 から 115200 までの間の bps レートそれぞれに対して一つ `std` 項目があります。もちろん、 このファイルに独自の項目を加えてもかまいません。 man:gettytab[5] のマニュアルに詳しい情報が載っています。[.filename]#/etc/ttys# ファイルに _getty_ タイプを設定する時は、 端末の通信設定が対応していることを確かめましょう。たとえば、Wyse-50 はパリティなしで、38400 bps で接続します。286 PC はパリティなしで、19200 bps で接続します。 * 第 3 フィールドは、その tty 回線に通常つながる端末の種別です。 ダイアルアップポートでは、実際、 ユーザがどんな種類の端末やソフトウェアで接続してくることもありうるので、 このフィールドには `unknown` または `dialup` がよく使われています。 ケーブルで配線された端末については、 端末種別は変わりませんので、man:termcap[5] データベースファイルから実際の端末種別を、 このフィールドに記入できます。我々の例では、Wyse-50 には実際の端末種別を使っていますが、 Procomm を動かしている 286 PC は、VT-100 をエミュレートするように設定します。 * 4 番目のフィールドは、 ポートを有効にすべきかどうかを指定します。 ここに `on` と記入すると、 `init` プロセスが 2 番目のフィールドに記載されているプログラム、 `getty` を起動します。 このフィールドを `off` にすると、 `getty` は動かず、 そのポートからはログインできません。 * 最後のフィールドは、 そのポートが安全かどうか指定します。 あるポートが安全だということは、そのポートから `root` (またはその他の UID が 0 の) アカウントのログインを許可してよいと信頼しているということです。 安全でないポートからは、`root` のログインは許可されません。安全でないポートでは、 ユーザは特権を持たないアカウントでログインした後に、 man:su[1] や類似の仕組みを使ってスーパユーザ特権を獲得します。鍵のかかる部屋にある端末であっても、"insecure" にしておくことが強く推奨されます。 スーパユーザ特権が必要なら、ログインしてから `su` を使うのは十分簡単です。 ==== [[term-hup]] ==== `init` にファイル [.filename]#/etc/ttys# の再読み込みをさせる 必要な変更を [.filename]#/etc/ttys# ファイルに加えたら、SIGHUP (ハングアップ) シグナルを `init` プロセスに送って設定ファイルを強制的に再読み込みさせます。 たとえば [source,shell] .... # kill -HUP 1 .... [NOTE] ==== `init` は、システムで最初に起動するプロセスなので、 PID は常に 1 です。 ==== すべての設定が正しくおこなわれ、 すべてのケーブルがただしく接続されていて、 かつ端末の電源が入っていれば、この時点で各端末で `getty` プロセスが動いていて、 ログインプロンプトが表示されているはずです。 [[term-debug]] === 接続のトラブルシューティング 細心の注意を払って設定をおこなっても、 ときには端末の接続がう まくいかない場合があるでしょう。以下に、 よく見られる問題とその解決方法 を示します。 ==== ログインプロンプトが表示されない 端末の電源が接続され、 スイッチが入っていることを確認してください。もし、PC を端末として利用している場合は、 通信ソフトが適切なシリアルポー トを利用する設定になっているかどうか確かめてください。 ケーブルがしっかりと端末と FreeBSDが動作しているコンピュータの両方に接続され ていることを確認してください。また、 正しい種類のケーブルを利用している か確かめてください。 端末と FreeBSD の間の通信速度とパリティの設定が一致していることを確認 してください。 出力をモニタに表示するタイプの端末の場合は、モニタ のコントラストと明るさの設定を確認してください。また、 出力が印刷 されるタイプの端末の場合は、 紙とインクが十分にあるかどうかを確かめてく ださい。 `getty` が動いていて、 端末を認識していることを確認してください。 たとえば、動作中の `getty` プロセスの一覧を `ps` で取得するには、以下のように入力してください。 [source,shell] .... # ps -axww|grep getty .... その端末に対応する項目が表示されるはずです。 たとえば、以下の表示例は、`getty` は 2 番目のシリアルポート (`ttyd1`) に対して [.filename]#/etc/gettytab# 中の `std.38400` エントリを使って動作しているということを示しています。 [source,shell] .... 22189 d1 Is+ 0:00.03 /usr/libexec/getty std.38400 ttyd1 .... もし、`getty` プロセスが一つも動いていないようであれば、 [.filename]#/etc/ttys# の中で、 そのポートを利用可能にする設定をしたかどうか確かめてください。 また、[.filename]#ttys# ファイルを変更したら、`kill -HUP 1` を実行するのを忘れないでください。 ==== ログインプロンプトの代わりにゴミが表示される 端末と FreeBSD の間の通信速度およびパリティの設定が一致していることを確 かめてください。また、`getty` プロセスの情報を調べて、適切な _getty_ のタイプが使用されていることを確認してください。間違った _getty_ タイプが使用されている場合は、 [.filename]#/etc/ttys# を修正し てから、 `kill -HUP 1` を実行してください。 ==== 文字が重複して表示される、入力したパスワードが表示される 端末または通信ソフトの設定で、"半二重 (half duplex)" あるいは "ローカ ルエコー" となっているところを、"全二重 (full duplex)" に変更してください。 [[dialup]] == ダイアルインサービス _訳: . 6 September 1996._ FreeBSD システムをダイアルインサービス用に設定することは、 端末の代わりにモデムを扱うこと以外は、 端末の接続によく似ています。 === 外づけモデムと内蔵モデムについて ダイアルアップのサービスに関していえば、 外づけのモデムの方が適している ようです。これは、 多くの外づけのモデムは設定を不揮発ラムに書き込んで半 永久的に保存することができますし、また RS-232 に関する重要な情報を知る ための点滅するライトによるインディケータが 搭載されているからです。点滅 するライトは、 システムを見に来た訪問者に強い印象を与えるという効果だけ でなく、モデムが適切に動作しているかどうかを知るためにも 有効です。 一方、たいていの内蔵型のモデムには 不揮発性ラムが搭載されていないため、ディップ スイッチの変更以外に設定を保存する方法がありません。また、も しインディケータがついていても、おそらくコンピュータのケース カバーが 外されていなければその状態を確認するのは 難しいでしょう。 ==== モデムとケーブル 外付けモデムを使用しているなら、 それにあったケーブルが必要です。 通常の信号が全て接続されている限り、標準的な RS-232C ケーブルで十分でしょう。 * Transmitted Data (SD) * Received Data (RD) * Request to Send (RTS) * Clear to Send (CTS) * Data Set Ready (DSR) * Data Terminal Ready (DTR) * Carrier Detect (CD) * Signal Ground (SG) FreeBSD で 2400bps 以上の転送速度を利用する場合には、 フロー制御のため に RTS 信号と CTS 信号が必要です。また、 接続の確立と回線の切 断を検出するために CD 信号を利用します。さらに、 DTR 信号を使っ て回線切断後のモデムのリセットを行います。ケーブルの中には、 総ての必要 な信号線が接続されていないものもありますので、 たとえば、回線切断後でも ログイン セッションが残ってしまうといった問題が発生した場合などには、 ケーブルに問題がある可能性もあります。 FreeBSD も他の Unix 系 OS と同様、回線の接続およ び切断の検出や回線の切断および回線切断後の モデムの初期化にハードウェア シグナルを利用します。FreeBSD は、モデムに対するコマンドの送信やモデ ムの状態の監視を行いません。パソコンで運用されている BBS への接続に慣 れている方にとっては、 ちょっとめんどうかもしれませんね。 === シリアル インタフェースについて FreeBSD では、NS8250-、NS16450-、NS16550- および NS16550A- に基づ いた EIA RS-232C (CCITT V.24) 規格のシリアル インタフェースをサポート しています。8250 および 16450 ベースのディバイスには1文字のキャラクタ バッファが搭載されています。また、16550 系のディバイスには、 16文字分 のバッファが搭載されていて、 はるかによいパフォーマンスを得られます (ただし、無印の 16550 では、バグがあって 16 文字バッファが利用できませ んので、可能であれば 16550A 系のディバイスを利用してください)。1文字 のバッファの物は、 16550 系のものと比べて OS にかける負荷が大きいので、16550A 系ディバイスの利用を強く推奨します。多数のシリアル ポートを利 用する場合や、負荷の高いシステムにおいては、 16550A 系ディバイスを使う ことで、 エラー発生率を低く押さえることができます。 === 概要 端末に関しては、 ダイアルイン接続に割り当てられたそれぞれのシリアルポートに対して、 `init` が `getty` を起動します。たとえば、モデムが [.filename]#/dev/ttyd0# に割り当てられていたら、`ps ax` コマンドを実行すると、以下のような出力が得られるはずです。 [source,shell] .... 4850 ?? I 0:00.09 /usr/libexec/getty V19200 ttyd0 .... ユーザがモデムに電話をかけ、モデム同士が接続されると、 モデムの CD (Carrier Detect) が検出されます。その結果、 kernel がキャリア信号を検出して、`getty` によるポートのオープンの処理が終了します。 `getty` は、`login:` プロンプトを指定されている初期回線速度で送信します。 `getty` は、 正常に文字列を受信できるかどうか監視し、通常の設定では、 もし異常な文字列を検出した場合 (理由としては、 `getty` の速度とモデ ムの接続速度が異なっているような場合が考えられます)、 正常に文字列が 受信できるまで、`getty` は速度を変え続けます。 ユーザがログイン名を入力すると、 `getty` は [.filename]#/usr/bin/login# を起動して、 パスワードの入力を要求し、その 後ユーザのシェルを起動します。 === 設定ファイル FreeBSD のシステムへのダイアルアップによるアクセスを実現するために編集が必要と思われる設定ファイルが、 [.filename]#/etc# ディレクトリに 3 つあります。まず、 [.filename]#/etc/gettytab# には、 [.filename]#/usr/libexec/getty# デーモンの設定を記述します。つぎに、 [.filename]#/etc/ttys# に保存されている情報から、 [.filename]#/sbin/init# はどの [.filename]#tty# デバイスに対して `getty` のプロセスを実行するべきか判断します。 最後に、[.filename]#/etc/rc.serial# スクリプトに、 シリアルポートの初期化のためのコマンドを記述することができます。 Unix にダイアルアップモデムを接続する方法には、 二つの考え方があります。一つの方法は、 ダイアルインしてくるユーザの接続速度に関係なく、 常にモデムとローカルのコンピュータの RS-232 インタフェースの接続速度を一定に保つように設定する方法です。 この設定の長所は、ユーザがダイアルインして接続されると、 即座にシステムからのログインプロンプトが送信されるということです。 短所は、システムが実際のモデム間の速度を知ることができないために、 Emacs のようなフルスクリーンのプログラムが、 端末との接続速度が遅い場合でも、 そのような場合に効果的な方法で画面出力を行わない点です。 もう一つは、モデムの RS-232 インタフェースとコンピュータの接続速度を、 モデム間の接続速度に応じて変化させるような設定です。たとえば、 モデム間 の接続が V.32bis (14.4 Kbps) ならば、 モデムとコンピュータの間の接続を 19.2 Kbps とし、 モデム間の接続が 2400 bps の時には、モデムとコンピュータ間も 2400 bps で接続するような設定をします。この場合、 `getty` は、モデムが返すリザルトコードからモデムとコンピュータの接続速度を認識することができませんので、 `getty` は、まず初期速度で `login:` という文字列を送信して、それに対する応答の文字列を監視します。 ここで、ユーザ側の端末に無意味な文字列が表示された場合、 ユーザは意味のある文字列を受信するまで Enter キーを繰り返し押さなければならないということを知っていると仮定しています。 もし接続速度が間違っている場合、`getty` は、 ユーザから送られた文字を無意味な文字列として扱い、 次の速度を試します。そして、ここで再度 `login:` プロンプトを送信します。 この一連の動作が異常な回数繰り返されることも考えられますが、 普通は 1 度か 2 度のキー入力があれば、 ユーザはまともなプロンプトを受信できます。 このログインの動作が前者の固定速度による方法に比べて美しくないのは明らかですが、 この方法では、低速度で接続しているユーザに対するフルスクリーンのプログラムからのレスポンスが改善されます。 このセクションでは、両方の設定方法について解説しますが、 どちらかというとモデム間の速度に応じて RS-232 インタフェースの速度が変化するような 設定の方に偏った説明になってしまうと思います。 ==== [.filename]#/etc/gettytab# [.filename]#/etc/gettytab# は、man:getty[8] の設定ファイルで、man:termcap[5] と同様の形式で記述されます。ファイルのフォーマットや定 義できる機能についての詳細については、man:gettytab[5] のマニュアルを ご覧ください。 ===== 固定速度の設定 モデムとコンピュータ間の通信速度を固定して使う場合、 おそらく [.filename]#/etc/gettytab# に特に変更を加える必要はないはずです。 ===== 可変速度の設定 `getty` が利用するモデムとコンピュータの接続速度に関する情報を [.filename]#/etc/gettytab# に記述する必要があります。もし、2400 bps のモ デムをお使いになるのであれば、既存の `D2400` のエントリがそのまま利 用できるでしょう。 [.programlisting] .... # # Fast dialup terminals, 2400/1200/300 rotary (can start either way) # D2400|d2400|Fast-Dial-2400:\ :nx=D1200:tc=2400-baud: 3|D1200|Fast-Dial-1200:\ :nx=D300:tc=1200-baud: 5|D300|Fast-Dial-300:\ :nx=D2400:tc=300-baud: .... 高速モデムをお使いの場合は、おそらく [.filename]#/etc/gettytab# に新たなエントリを追加する必要があります。 以下の例は、14.4 Kbps のモデムを、 最大インタフェース速度を 19.2 Kbps として利用するためのエントリです。 [.programlisting] .... # # Additions for a V.32bis Modem # um|V300|High Speed Modem at 300,8-bit:\ :nx=V19200:tc=std.300: un|V1200|High Speed Modem at 1200,8-bit:\ :nx=V300:tc=std.1200: uo|V2400|High Speed Modem at 2400,8-bit:\ :nx=V1200:tc=std.2400: up|V9600|High Speed Modem at 9600,8-bit:\ :nx=V2400:tc=std.9600: uq|V19200|High Speed Modem at 19200,8-bit:\ :nx=V9600:tc=std.19200: .... 上記の例を利用した場合、 パリティなし、8ビットの接続が行われます。 上記の例では、まず 19.2 Kbps (V.32bis) によるモデムとコンピュータ間の接続を試み、続いて 9600 bps (V.32)、2400 bps、1200 bps、300 bpsと順に試み、再び 19.2 Kbps による接続を試みるという循環に入ります。 この接続速度の循環は、`nx=`("next table") の機能で実現されています。また、 各行はそれぞれ `tc=`("table continuation") の機能を使って、 その他の接続速度に依存した "標準的な" 設定を取り込んでいます。 もし、お使いのモデムが 28.8 Kbps であったり、14.4 Kbps の圧縮転送の機能を有効に利用したい場合は、19.2 Kbps よりも速い速度を利用するように設定する必要があります。 以下に 57.6 Kbps から接続を試みる [.filename]#gettytab# の設定例を示しておきます。 [.programlisting] .... # # Additions for a V.32bis or V.34 Modem # Starting at 57.6 Kbps # vm|VH300|Very High Speed Modem at 300,8-bit:\ :nx=VH57600:tc=std.300: vn|VH1200|Very High Speed Modem at 1200,8-bit:\ :nx=VH300:tc=std.1200: vo|VH2400|Very High Speed Modem at 2400,8-bit:\ :nx=VH1200:tc=std.2400: vp|VH9600|Very High Speed Modem at 9600,8-bit:\ :nx=VH2400:tc=std.9600: vq|VH57600|Very High Speed Modem at 57600,8-bit:\ :nx=VH9600:tc=std.57600: .... もし、お使いの CPU が低速のものであったり、CPU に対する負荷が高い場合で、16550A 系のシリアルポートをお使いでない場合、 57.6 Kbps の接続において、`sio` の "silo" エラーが発生するかもしれません。 [[dialup-ttys]] ==== [.filename]#/etc/ttys# [.filename]#/etc/ttys# ファイルの設定は、<> で扱われています。 モデムの設定も似たようなものですが、`getty` に異なる引数を渡して、異なる端末種別を指定しなければなりません。 固定速度および可変速度両方に共通する形式は次のようになります。 [.programlisting] .... ttyd0 "/usr/libexec/getty xxx" dialup on .... 1 番目の項目は、このエントリで対象とするデバイススペシャルファイルです。 上の例では `ttyd0` として、 [.filename]#/dev/ttyd0# を `getty` に監視させることを表しています。2 番目の項目 `"/usr/libexec/getty xxx"` (_xxx_ は初期段階で使われる [.filename]#gettytab# のエントリに置き換えてください) が、`init` がこのディバイスに対して起動するプロセスです。3 番目の `dialup` は、デフォルトのターミナルタイプです。 4 番目の `on` は、 この行が有効であることを `init` に対して示しています。5 番目の項目に `secure` を指定することもできますが、これは、 たとえばシステムのコンソールのように、 物理的に安全な端末に対してのみ指定するようにしてください。 デフォルトのターミナルタイプ (上記の例では `dialup`) は、ローカルのユーザの好みによって異なってきます。 ユーザがログインスクリプトをカスタマイズして、ターミナルタイプが `dialup` の時には自動的に他のターミナルタイプを設定できるように、 ダイアルアップのポートのデフォルトのターミナルタイプには `dialup` が伝統的に用いられています。 しかし、筆者のサイトでは、ほとんどのユーザが VT102 エミュレーションを使っているので、 ダイアルアップのポートのデフォルトターミナルタイプとして `vt102` を指定しています。 [.filename]#/etc/ttys# の修正がすんだら、 以下のようなコマンドを使って `init` プロセスに HUP シグナルを送り、[.filename]#/etc/ttys# を読み込み直させてください。 [source,shell] .... # kill -HUP 1 .... ただ、もし初めてシステムを設定しているのであれば、 モデムが適切に設定されて接続されるまでは、 `init` に対してシグナルを送らない方がいいかもしれません。 ===== 固定速度の設定 速度を固定する設定では、[.filename]#/etc/ttys# の中で、`getty` に対し て固定速度のエントリを指定する必要があります。たとえば、 以下の例はポートのスピードが 19.2 Kbps に固定されたモデムのための [.filename]#ttys# のエントリです。 [.programlisting] .... ttyd0 "/usr/libexec/getty std.19200" dialup on .... モデムが異なる速度で固定されている場合は、 `std.19200` のかわりに `std.speed` を適切な値に置き換えたものにしてください。 [.filename]#/etc/gettytab# に挙がっている適切な種類を使うようにしてください。 ===== 可変速度の設定 可変速度の設定では、[.filename]#ttys# のエントリが、[.filename]#/etc/gettytab# の中の適切な "自動速度調整" の初期設定のエントリを参照していなければな りません。 たとえば、もし前述の 19.2 Kbps から接続を試みる可変速度の設定例 (`V19200` の [.filename]#gettytab# エントリ)をそのまま _ttys_ に追加したのであれば、 [.filename]#ttys# エントリは以下のようになります。 [.programlisting] .... ttyd0 "/usr/libexec/getty V19200" dialup on .... ==== [.filename]#/etc/rc.serial# V.32、V.32bis または V.34 モデムのような高速モデムを利用する場合、ハードウェア ([.filename]#RTS/CTS#) フロー制御を行う必要があります。FreeBSD kernel のモデムポートにハードウェアフロー制御のフラグを設定するための `stty` コマンドを、 [.filename]#/etc/rc.serial# に記述できます。 たとえば、シリアルポート 1 番 ([.filename]#COM2#) のダイヤルインおよびダイヤルアウト初期化デバイスに `termios` フラグ `crtscts` を設定するには、次の行を [.filename]#/etc/rc.serial# に追加するとよいでしょう。 [.programlisting] .... # Serial port initial configuration stty -f /dev/ttyid1 crtscts stty -f /dev/cuai01 crtscts .... === モデムの設定 もし、あなたのモデムがパラメータを不揮発ラムに 保存できるタイプならば、MS-DOS 上の Telix や FreeBSD 上の `tip` などのような通信プログラム を使って、 パラメータを設定してください。`getty` が利用する初期速度でモデムに接続して、以下の条件を満たすよ うに不揮発ラムの設定を変更してください。 * 接続時に CD 信号がオンになる * 接続時に DTR がオンになり、 オフで回線を切断しモ デムをリセットする。 * 送信時フロー制御には CTS を利用。 * XON/XOFF によるフロー制御を行わない。 * 受信時のフロー制御は RTS を使用。 * Quiet mode (リザルト コードを返さない) * コマンド エコーを返さない。 これらを実現するためのコマンドやディップ スイッチの設定に関しては、モ デムのマニュアルを参照してください。 以下に、USRobotics Sportster の 14,400 bps の外づけモデムの設定例を示 しておきます。 [.programlisting] .... ATZ ATC1D2H1I0R2W .... ことのついでに、たとえば、V42.bis や MNP5 のデータ圧縮を使用するかど うかなどのモデムの他の設定について確認、 調整しておくのもよいかもしれま せん。 さらに、USRobotics Sportster の 14,400 bps の外づけモデムでは、以下の ようなディップ スイッチの設定も必要です。他のモデムをお使いの方も、以 下の例を設定の参考にしてください。 * スイッチ 1: UP - DTR 標準 * スイッチ 2: N/A (リザルトコードを単語形式にするか数値形式にするか) * スイッチ 3: UP - リザルトコードを返さない * スイッチ 4: DOWN - コマンドエコーを返さない * スイッチ 5: UP - 自動着信 * スイッチ 6: UP - CD 標準 * スイッチ 7: UP - 不揮発ラムからデフォルト値をロードする * スイッチ 8: N/A (Smart Mode/Dumb Mode) リザルト コードを返さないように設定しておかないと、 `getty` が誤っ て `login:` プロンプトをコマンド モードのモデムに送信してしまった場 合に、 モデムがこの入力をエコーしたり、この入力に対するリザルト コード を返してしまったりすることになります。この結果として、 モデムと `getty` の間で延々と無意味なやりとりが続いてしまう可能性があります。 ==== 固定速度の設定 固定速度の設定では、 モデムとコンピュータ間の通信速度をモデムとモデム間 の接続速度に関係なく、常に一定に保つように、 モデムを設定する必要があり ます。USRobotics Sportster の 14,400 bps 外づけモデムの場合、以下のコ マンドで、 モデムとコンピュータ間の速度が、コマンド送信時の速度に固定さ れます。 [.programlisting] .... ATZ ATB1W .... ==== 可変速度の設定 可変速度の設定では、シリアル ポートの速度が、 着信速度に応じて変化する ように設定しなければいけません。 USRobotics Sporster の 14,400 bps 外 づけモデムの場合、 以下のコマンドで、エラー訂正機能を利用した通信の場合 は、 コマンドを送信した時の通信速度にシリアル ポートの速度を固定し、エ ラー訂正機能を利用しない接続では、 シリアル ポートの速度が変化するよう に設定されます。 [.programlisting] .... ATZ ATB2W .... ==== モデムの設定の確認 ほとんどの高速モデムには、 現在の設定をある程度人間にも理解できる形式に して表示させるコマンドがあります。USRobotics Sporster の 14,400 bps 外づけモデムの場合は、`ATI5` コマンドで、現在の不揮発ラムの設定を 表示することができます。 さらに、ディップ スイッチの設定も含めた現在の 設定を確認するためには、`ATZ` コマンドを送信してから、`ATI4` コマンドを送信してください。 他のメーカーのモデムをお使いの場合は、 モデムのマニュアルで設定値の確認 方法を確認してください。 === トラブルシューティング 以下の手順でダイアル アップ モデムの動作を確認することができます。 ==== FreeBSD システムの動作確認 モデムを FreeBSD システムに接続し、 システムをブートします。あなたのモ デムにモデムの状態を確認するためのインジケータがあれば、 DTR のイ ンジケータの状態に注目してください。もし、 システムのコンソールに `login:` プロンプトが表示された時に、DTR のインジケータが点灯 すれば、FreeBSD が適切なポートに対して `getty` を起動し、モデムへ の着信を待っている状態であることを意味しています。 もし DTR のインジケータが点灯しない場合は、システムのコンソールから FreeBSD にログインして、`ps ax` を実行し、 FreeBSD が適切なポートに対して``getty`` プロセスを起動しようとしているのかどうか確認してください。 プロセスに関する情報の中に、 以下のような行が表示されるはずです。 [source,shell] .... 114 ?? I 0:00.10 /usr/libexec/getty V19200 ttyd0 115 ?? I 0:00.10 /usr/libexec/getty V19200 ttyd1 .... モデムにまだ着信がない状態の時に、 以下のように上とは異なる出力があった 場合、`getty` は既にモデム ポートのオープンを終了したということに なります。 [source,shell] .... 114 d0 I 0:00.10 /usr/libexec/getty V19200 ttyd0 .... `getty` は、CD (carrier detect) 信号がオンの状態になるまで、 ポートのオープンを完了することはできませんので、 この場合は接続に問題が あるか、あるいはモデムの設定に問題があることが考えられます。 もし、期待した [.filename]#ttydN# ポートをオープンしようとしている `getty` が見あたらない場合は、再度 [.filename]#/etc/ttys# の内容を確認し、 書式などに誤りがないか 調べてみてください。また、ログ ファイル [.filename]#/var/log/messages# に `init` および `getty` から何か出力がないかどうかも確認してみてく ださい。 もし何かメッセージが記録されていたら、再度 [.filename]#/etc/ttys#、 [.filename]#/etc/gettytab# の二つの設定ファイルと、 ディバイス スペシャルファイル [.filename]#/dev/ttydN# を確認し、 記述に誤りがないか、足りないエントリがないか、 足りないディバイス スペシャルファイルがないかといった 点について調べてみてください。 ==== モデムで接続してみる 実際にモデムを使って別のコンピュータから 接続してみてください。この時、8 ビット、パリティなし、 1 ストップビットで接続するようにしてください。 接続後すぐにプロンプトが返ってこない場合や、 無意味な文字列が表示される 場合は、1秒に1回くらいの割合で Enter キーを押してみてください。 しばらくたって、なおも `login:` プロンプトが現れない場合 は、`BREAK` 信号を送信してみてください。この時、端末側で使って いるモデムが高速モデムならば、 このモデムのインタフェースの接続速度を固 定してから、 再度ダイアル インしてみてください。(たとえば、USRobotics Sportster の場合は、`ATB1`) それでもまだ `login:` プロンプトが表示されない場合は、 [.filename]#/etc/gettytab# の以下の点について再度確認してみてください。 * [.filename]#/etc/ttys# の対応する行の 2番目の項目で、[.filename]#/etc/gettytab# の中で定義されているエントリが指定されているか * 各 `nx=` で [.filename]#/etc/gettytab# の中で定義されているもの が指定されているか * 各 `tc=` で [.filename]#/etc/gettytab# の中で定義されているもの が指定されているか もしダイアル インしても、FreeBSD システム側のモデムが応答しない場合は、FreeBSD 側のモデムが DTR がオンになった時に電話にでるように設定さ れているかを確認してください。 もしモデムの設定に問題がなさそうならば、 モデムのインジケータ (がもしあれば) で、 DTR がオンになっているか を確認してください。 この確認のステップを数回繰り返しても うまくいかない場合は、一度休憩して、 しばらくたってから挑戦してみましょう。それでもだめなら、 おそらく {freebsd-questions} にあなたのモデムについての情報と問題を書いたメールを送れ ば、 メーリング リストのメンバーが問題の解決を助けるべく努力してくれる でしょう。 [[dialout]] == ダイアルアウトサービス 以下はモデムを利用して他のコンピュータと 接続する方法を説明しています。 これはリモートホストとターミナル接続を確立するための 適切な方法です。 これは BBS に接続するときによく使います。 この種の接続は PPP 接続に問題がある場合、Internet 上にあるファイルを 転送するのに非常に役に立ちます。FTP で何らかのファイルを転送したいのに PPP 接続を確立できない場合は、ファイルを FTP 転送するためにターミナルセッション を利用します。そして ZMODEM を利用してファイルを転送します。 === 私の Hayes モデムはサポートされていません、 どうすればよいでしょう? 実際、`tip` の マニュアルページは古くなっています。既に Hayes ダイアラが組み込まれています。[.filename]#/etc/remote# ファイル中で `at=hayes` を使ってください。 Hayes ドライバは、最近のモデムの新しい機能である ``BUSY``、``NO DIALTONE``、 ``CONNECT 115200``などのメッセージを 認識できるほど賢くはなく、単に混乱を起こすだけです。 ``tip``を使う場合には、 (``ATX0W`` とするなどして) これらの メッセージを表示させないようにしなくてはいけません。 また、`tip` のダイアルのタイムアウトは 60秒です。モデムの タイムアウト設定はそれより短くすべきであり、 そうしないと `tip` は通信に問題があると判断するでしょう。 `ATS7=45W` を実行してください。 [NOTE] ==== デフォルトの `tip` は、 Hayes モデムに完全に対応しているわけではありません。解決方法は [.filename]#/usr/src/usr.bin/tip/tip# の下の [.filename]#tipconf.h# を変更することです。 もちろんこれにはソース配布ファイルが必要です。 `#define HAYES 0` と記述されている行を `#define HAYES 1` と変更し、そして `make`, `make install` を実行します。これでうまく動作するでしょう。 ==== [[direct-at]] === これらの AT コマンドを入力するには? [.filename]#/etc/remote# ファイルの中で "direct" エントリを作ります。たとえばモデムが 1番目のシリアルポートである [.filename]#/dev/cuaa0# に接続されている場合、次のようにします: [.programlisting] .... cuaa0:dv=/dev/cuaa0:br#19200:pa=none .... モデムがサポートする最大の bps レートを br フィールドに使います。そして `tip cuaa0` を実行すると、モデムが利用できるようになります。 [.filename]#/dev/cuaa0# がシステムに存在しない場合は、次のようにします: [source,shell] .... # cd /dev # sh MAKEDEV cuaa0 .... または `root` になって以下のように `cu` コマンドを実行します: [source,shell] .... # cu -lline -sspeed .... _line_ にはシリアルポートを指定します (例えば [.filename]#/dev/cuaa0#)。そして _speed_ には接続する速度を指定します (例えば `57600`)。その後 AT コマンドを実行したら、kbd:[~.] と入力すれば終了します。 === pn 機能の `@` 記号が使えません! 電話番号 (pn) 機能の中での `@` 記号は、 tip に [.filename]#/etc/phone# にある電話番号を参照するように伝えます。しかし `@` の文字は [.filename]#/etc/remote# のような 設定ファイルの中では特殊文字となります。 バックスラッシュを使ってエスケープをおこないます: [.programlisting] .... pn=\@ .... === コマンドラインから電話番号を指定するには? "generic" エントリと呼ばれるものを [.filename]#/etc/remote# に追加します。 例えば次のようにします: [.programlisting] .... tip115200|Dial any phone number at 115200 bps:\ :dv=/dev/cuaa0:br#115200:at=hayes:pa=none:du: tip57600|Dial any phone number at 57600bps:\ :dv=/dev/cuaa0:br#57600:at=hayes:pa=none:du: .... そして [source,shell] .... # tip -115200 5551234 .... のように利用できます。 `tip` より `cu` を使いたい場合、 `cu` の generic エントリを使います。 [.programlisting] .... cu115200|Use cu to dial any number at 115200bps:\ :dv=/dev/cuaa1:br#57600:at=hayes:pa=none:du: .... そして [source,shell] .... # cu 5551234 -s 115200 .... と実行します。 === 毎回 bps レートを入力しなければいけませんか? `tip1200` や `cu1200` 用のエントリを記述し、適切な通信速度を br フィールドに設定します。`tip` は 1200 bps が正しいデフォルト値であるとみなすので、 `tip1200` エントリを参照します。もちろん 1200 bps を使わなければならないわけではありません。 === ターミナルサーバを経由して複数のホストへアクセスしたいです 毎回接続されるのを待って `CONNECT host` と入力する かわりに、tip の `cm` 機能を使います。 例えば、[.filename]#/etc/remote# に次のようなエントリを追加します: [.programlisting] .... pain|pain.deep13.com|Forrester's machine:\ :cm=CONNECT pain\n:tc=deep13: muffin|muffin.deep13.com|Frank's machine:\ :cm=CONNECT muffin\n:tc=deep13: deep13:Gizmonics Institute terminal server:\ :dv=/dev/cuaa2:br#38400:at=hayes:du:pa=none:pn=5551234: .... これで、`tip pain` や `tip muffin` と実行すると pain や muffin のホストに接続することができ、 `tip deep13` を実行するとターミナルサーバに接続します。 === tip を使ってそれぞれのサイトの 複数の回線に接続できますか? これは大学に電話回線がいくつかあって 数千人の学生が接続しようとする 場合によくある問題です。 あなたの大学のエントリを [.filename]#/etc/remote# ファイルに作成して、`pn` のフィールドには `@` を使います: [.programlisting] .... big-university:\ :pn=\@:tc=dialout dialout:\ :dv=/dev/cuaa3:br#9600:at=courier:du:pa=none: .... そして [.filename]#/etc/phone# ファイルに大学の電話番号の一覧を書きます: [.programlisting] .... big-university 5551111 big-university 5551112 big-university 5551113 big-university 5551114 .... `tip` は一連の電話番号を試みて、 最終的に接続できなければあきらめます。 リトライを続けさせたい場合は、`tip` を while ループに入れて 実行します。 === kbd:[Ctrl+P] を 1 回送るために kbd:[Ctrl+P] を 2 度押す必要があるのはなぜ? kbd:[Ctrl+P] はデフォルトの "force (強制)" 文字であり、 `tip` に次の文字が リテラルデータであることを伝えます。force 文字は "変数の設定" を意味する `~s` エスケープによって他の文字にすることができます。 `~sforce=single-char` と入力して改行します。_single-char_ は、任意の 1 バイト文字です。 _single-char_ を省略すると NUL 文字になり、これは kbd:[Ctrl+2] や kbd:[Ctrl+Space] を押しても入力できます。また、 _single-char_ に kbd:[Shift+Ctrl+6] を割り当てる方法を使っているターミナルサーバもあります。 [.filename]#$HOME/.tiprc# に次のように定義することで、任意の文字を force 文字として利用できます: [.programlisting] .... force=single-char .... === 打ち込んだ文字が突然すべて大文字になりました?? kbd:[Ctrl+A] を押してしまい、caps-lock キーが壊れている場合のために設計された `tip` の "raise character" モードに入ったのでしょう。 既に述べたように `~s` を使って、 `raisechar` をより適切な値に 変更してください。もしこれら両方の機能を使用しないのであれば、 force 文字と同じ設定にすることもできます。 以下は kbd:[Ctrl+2] や kbd:[Ctrl+A] などを頻繁に使う必要のある Emacs ユーザにうってつけの .tiprc ファイルのサンプルです。 [.programlisting] .... force=^^ raisechar=^^ .... ^^ は kbd:[Shift+Ctrl+6] です。 === `tip` でファイルを転送するには? もし他の Unix のシステムと接続しているなら、 `~p`(put) や `~t`(take) でファイルの送受信ができます。これらのコマンドは 相手のシステムの上で `cat` や `echo` を実行することで 送受信をします。 書式は以下のようになります: `~p` ローカルのファイル名 [ リモートのファイル名 ] `~t` リモートのファイル名 [ ローカルのファイル名 ] この方法ではエラーチェックをおこないませんので、zmodem などの他のプロトコルを使った方がよいでしょう。 === `tip` から zmodem を実行するには? ファイルを受信するには、 リモート側で送信プログラムを起動します。そして `~C rz` と入力すると、ローカル側へのファイルの受信が 始まります。 ファイルを送信するには、 リモート側で受信プログラムを起動します。そして `~C sz files` と入力すると、 リモート側への ファイルの送信が始まります。 [[serialconsole-setup]] == シリアルコンソールの設定 [[serialconsole-intro]] === 導入 FreeBSD は、 コンソールとしてシリアルポート上のダム端末しか持たないシステムでも起動します。 この様な構成はきっと次のような二種類の人達に便利でしょう。それは、 キーボードやモニタのないマシンに FreeBSD をインストールしたいシステム管理者と、 カーネルやデバイスドライバをデバッグしたい開発者です。 crossref:boot[boot,FreeBSD の起動のプロセス] で説明されているように、 FreeBSD は 3 ステージ構成のブートストラップを用いています。 最初の 2 つのステージは、 ブートディスクにある FreeBSD スライスの最初に格納されている、 ブートブロックのコードが行います。 それからブートブロックは、第 3 ステージのコードとしてブートローダ ([.filename]#/boot/loader#) を読み込み、実行します。 シリアルコンソールを設定するためには、ブートブロックコード、 ブートローダコード、カーネルを設定する必要があります。 [[serialconsole-howto]] === シリアルコンソールの設定 [.procedure] ==== . シリアルケーブルを用意してください。 + ヌルモデムケーブル、 もしくは標準シリアルケーブルとヌルモデムアダプタが必要となります。 シリアルケーブルについては <> をご覧ください。 . キーボードをはずして下さい。 + たいていの PC システムは Power-On Self-Test (POST) の間にキーボードを検出し、もし見つからなければエラーと なります。また、キーボードがないことを大きな音で知らせ、 キーボードが接続されるまでは起動を中断するようなマシンもあります。 + コンピュータがエラーを表示していても、 とにかく起動するなら特別な対応は必要ありません (Phoenix BIOS を搭載しているマシンには、 `Keyboard failed` と表示されても、正常に起動するものがあります)。 + あなたのコンピュータがキーボードを接続していない状態で 起動しないようなら、(もし可能ならば) エラーを無視するように BIOS を設定する必要があります。設定方法の詳細については、 マザーボードのマニュアルを調べてください。 + [TIP] ====== BIOS の設定でキーボードを "Not installed" にするということは、キーボードを使えないということを 意味しているわけでは__ありません__。これは、BIOS がキーボードがなくても文句を言わないように、電源投入時には キーボードを探すな、と指示するだけです。このフラグを "Not installed" にしていてもキーボードを 接続したままにできますし、ちゃんと動作します。 ====== + [NOTE] ====== あなたのシステムが PS/2 マウスを使っているなら、 おそらくマウスもキーボード同様にはずす必要があるでしょう。 というのは、PS/2 マウスは部分的にキーボードとハードウェアを 共有しており、マウスを接続したままにしていると、 キーボードも存在する、と誤って検出してしまう可能性があるからです。 AMI BIOS を持つ Gateway 2000 Pentium 90MHz システム はこれに該当すると言われています。 一般的にこれは問題ではありません。なぜなら、どっちにしても マウスはキーボードなしではたいして役に立たないからです。 ====== + . [.filename]#COM1# ([.filename]#sio0#) にダム端末を接続してください。 + ダム端末がなければ、かわりに古い PC/XT でモデム プログラムを走らせて使ったり、シリアルポートに他の Unix マシンを繋いだりできます。もしも [.filename]#COM1# ([.filename]#sio0#) がなければ、作成してください。 今のところ、[.filename]#COM1# 以外のポートを 選択するためにはブートブロックの再コンパイルが必要です。 すでに [.filename]#COM1# を他の装置に 使っていた場合は、一時的にその装置をはずして いったん FreeBSD がうまく動作してから、 新しいブートブロックとカーネルをインストールしてください。 (上記はとにかくファイル/演算/端末サーバの [.filename]#COM1# が利用可能であると仮定して います。あなたが本当に何かのために [.filename]#COM1# が必要 (で、なおかつその何かを [.filename]#COM2# ([.filename]#sio1#) に付け替えることができない) ならば、多分、そもそも 悩んでる場合ではありません。) . カーネルコンフィグファイルの [.filename]#COM1# ([.filename]#sio0#) に適切なフラグを 設定していることを確認してください。 + 関連するフラグ: + `0x10`::: このポートのコンソールサポートを有効にします。 このフラグが設定されない場合、他のフラグは無視されます。 現在のところ、一つのポートしかコンソールサポートを有効に できません。(config ファイルに書かれた順番で) 最初にこのフラグを 指定されたポートが選択されます。 なお、このオプションを指定するだけでシリアルポートが コンソールとして使えるわけではありません。 このフラグと一緒に、以下のフラグも指定するかもしくは `-h` オプションも使ってください。 `0x20`::: 後述される `-h` オプション を無視して、(他に優先度の高いコンソールがない限り) このポートをコンソールとして指定します。 このフラグは FreeBSD バージョン 2._X_ の `COMCONSOLE` オプションに対応するものです。 フラグ `0x20` は必ず フラグ `0x10` と一緒に指定されなければなりません。 `0x40`::: (`0x10` と組み合わせることで) このポートを予約し、通常のアクセスができない ようにします。 このフラグは、シリアルコンソールとして使いたいポートに 指定すべきではありません。 唯一の使い道は、ユニットがカーネルのリモートデバッグ用 であることを指定することです。 リモートデバッグの詳細については extref:{developers-handbook}[The Developer's Handbook] を参照してください。 + [NOTE] ====== FreeBSD 4.0 以降では、 フラグ `0x40` の意味が若干異なり、 シリアルポートにリモートデバッグを指定するためには、 別のフラグを使います。 ====== + 例: + [.programlisting] .... device sio0 at isa? port "IO_COM1" tty flags 0x10 irq 4 .... + 詳細については man:sio[4] のマニュアルを参照してください。 + もしこれらのフラグがセットされていなければ、(別のコンソールで) UserConfig を実行するか、 カーネルを再コンパイルする必要があります。 . ブートドライブの `a` パーティションの ルートディレクトリに [.filename]#boot.config# を作成してください。 + このファイルは、ブートブロックコードに対してどのように システムを起動したいかを教えます。 シリアルコンソールを活かすためには、以下のオプションを幾つか - 複数の場合も一行で、設定する必要があります: + `-h`::: 内蔵コンソールとシリアルコンソールの切替えを行います。 これを使用してコンソールデバイスを変更できます。 例えば、内蔵 (ビデオ) コンソールからブートした場合、 カーネルとブートローダがコンソールデバイスとして シリアルポートを使用するようにするため、 `-h` を使って指示できます。 反対に、シリアルポートからブートした場合、 ブートローダとカーネルがコンソールとして代わりに ビデオディスプレイを使用するようにするため、 `-h` を使用できます。 `-D`::: シングルとデュアルのコンソール設定を切り替えます。 シングル設定では、上記の `-h` オプションの状態によって、コンソールは内蔵コンソール (ビデオディスプレイ)かシリアルポートのいずれかになります。 デュアルコンソール設定では、ビデオディスプレイと シリアルポートの両方が、`-h` オプションの状態によらず、同時にコンソールになります。 しかし、デュアルコンソール設定は、ブートブロックが 実行されている間でしか効果を持ちません。 一旦ブートローダに制御が移ると、`-h` オプションによって指定されたコンソールが 唯一のコンソールになります。 `-P`::: ブートブロックがキーボードを検出するようにします。 キーボードが発見できなかった場合には、 `-D` と `-h` オプションが自動的にセットされます。 + [NOTE] ====== 現バージョンのブートブロックでは容量の制限により、 `-P` オプションは拡張キーボードしか 検出できません。キーが 101 個より少ない (そして F11 と F12 がない) キーボードは検出されない可能性があります。 この制限から、いくつかのラップトップコンピュータの キーボードは正しく検出されないでしょう。 もし、あなたのシステムがこのようなキーボードを使っているのであれば、 `-P` オプションを外してください。 残念ながら、この問題の回避策はありません。 ====== + `-P` オプションを使ってコンソールを 自動的に選ぶか、`-h` オプションを使って シリアルコンソールを有効にしてください。 + さらに man:boot[8] で説明されている他のオプションも使う ことができます。 + `-P` 以外のオプションはブートローダ ([.filename]#/boot/loader#) に渡されます。 ブートローダは、`-h` オプションだけの状態を 調べることで内蔵ビデオとシリアルポートのどちらがコンソールに なるのか決めます。 つまり、[.filename]#/boot.config# の中で `-D` オプションを指定して `-h` オプションを指定しなかった場合、 ブートブロック実行中でのみシリアルポートをコンソールとして 使うことができます。ブートローダは内蔵ビデオディスプレイを コンソールとして使います。 . マシンを起動する。 + FreeBSD を起動したとき、ブートブロックは [.filename]#/boot.config# の内容をコンソールに表示 します。例えば、 + [source,shell] .... /boot.config: -P Keyboard: no .... + 行の二番目は、 [.filename]#/boot.config# にオプション `-P` が指定してあるときだけ表示され、 キーボードが存在するかどうかを表します。 これらのメッセージは、シリアルか内蔵のいずれか、 あるいはその両方のコンソールに表示されます。 どちらに表示されるかは、 [.filename]#/boot.config# の設定によって変わります。 + [.informaltable] [cols="1,1", frame="none", options="header"] |=== | オプション指定 | メッセージの表示される場所 |なし |内蔵 |`-h` |シリアル |`-D` |シリアルと内蔵の両方 |`-Dh` |シリアルと内蔵の両方 |`-P`、キーボードが存在する場合 |内蔵 |`-P`、キーボードが存在しない場合 |シリアル |=== + このメッセージが表示された後、 ブートブロックがブートローダのロードを再開し、 他の全てのメッセージがコンソールに表示されるまで、 若干時間がかかります。通常の環境では、ブートブロックに 割り込みをかける必要はありませんが、 ちゃんとセットアップされているかどうか確かめるために、 割り込みをかけることができるようになっています。 + ブートプロセスに割り込みをかけるには、 コンソールの (Enter 以外の) キーをたたいて下さい。 ブートブロックはその時、操作を指定するためのプロンプトを表示します。 こんな風に表示されるでしょう。 + [source,shell] .... >> FreeBSD/i386 BOOT Default: 0:wd(0,a)/boot/loader boot: .... + 上に示したメッセージが、シリアルか内蔵、 あるいはその両方といった、[.filename]#/boot.config# で指定したとおりのコンソールに表示されることを確認して下さい。 メッセージが正しいコンソールに表示されたら、 Enter キーを押してブートプロセスを継続してください。 + もし、シリアルコンソールを利用するように設定しているのに シリアル端末にプロンプトが出てこない場合は、 設定のどこかに間違いがあります。 ブートブロック(とブートローダ、カーネル)に対して シリアルポートをコンソールに使うことを伝えるため、 割り込みをかけた時に `-h` を入力し、 (可能ならば) Enter/Return キーを押して下さい。そして、 一度システムを起動させてから、どこが悪いのかをチェックして下さい。 ==== ブートローダがロードされ、ブートプロセスの第三ステージに いる時には、まだ内蔵コンソールとシリアルコンソールを切り替えることができます。 それにはブートローダの環境変数を適切に設定すれは良いのですが、 詳細については <> を参照してください。 [[serialconsole-summary]] === まとめ このセクションで扱ったさまざまな設定と、 最終的に選択されるコンソールに関するまとめです。 ==== Case 1: [.filename]#sio0# の flags に 0x10 をセットした場合 [.programlisting] .... device sio0 at isa? port "IO_COM1" tty flags 0x10 irq 4 .... [.informaltable] [cols="1,1,1,1", frame="none", options="header"] |=== | /boot.config 内のオプション | ブートブロック実行中のコンソール | ブートローダ実行中のコンソール | カーネルのコンソール |なし |内蔵 |内蔵 |内蔵 |`-h` |シリアル |シリアル |シリアル |`-D` |内蔵、シリアルの両方 |内蔵 |内蔵 |`-Dh` |内蔵、シリアルの両方 |シリアル |シリアル |`-P`、キーボードが存在する場合 |内蔵 |内蔵 |内蔵 |`-P`、キーボードが存在しない場合 |内蔵、シリアルの両方 |シリアル |シリアル |=== ==== Case 2: sio0 の flags に 0x30 をセットした場合 [.programlisting] .... device sio0 at isa? port "IO_COM1" tty flags 0x30 irq 4 .... [.informaltable] [cols="1,1,1,1", frame="none", options="header"] |=== | /boot.config 内のオプション | ブートブロック実行中のコンソール | ブートローダ実行中のコンソール | カーネルのコンソール |なし |内蔵 |内蔵 |シリアル |`-h` |シリアル |シリアル |シリアル |`-D` |内蔵、シリアルの両方 |内蔵 |シリアル |`-Dh` |内蔵、シリアルの両方 |シリアル |シリアル |`-P`、キーボードが存在する場合 |内蔵 |内蔵 |シリアル |`-P`、キーボードが存在しない場合 |内蔵、シリアルの両方 |シリアル |シリアル |=== [[serialconsole-tips]] === シリアルコンソールを利用する上で役に立つ情報 ==== シリアルポートの通信速度をもっと速いものに設定するには デフォルトのシリアルポート通信速度は、9600 ボー、 8 ビット、パリティなし、ストップビット 1 です。 通信速度を変更したい場合には、少なくとも ブートブロックの再コンパイルが必要になります。 [.filename]#/etc/make.conf# に次のような行を追加して、 新しくブートブロックをコンパイルして下さい。 [.programlisting] .... BOOT_COMCONSOLE_SPEED=19200 .... もし、シリアルコンソールがブート時の `-h` オプション以外の方法で設定されていたり、 カーネルが利用するシリアルコンソールが ブートブロック実行中のものと異なる場合には、 カーネルコンフィグレーションファイルに次のオプションを追加して、 新しくカーネルをコンパイルしなければなりません。 [.programlisting] .... options CONSPEED=19200 .... [[serialconsole-com2]] ==== [.filename]#sio0# 以外のシリアルポートを コンソールとして使うには [.filename]#sio0# 以外のポートをコンソールとして使うには、再コンパイルが必要です。 それがどんな理由であれ、他のポートを使用する場合には ブートブロック、ブートローダ、カーネルを 次のようにして再コンパイルして下さい。 [.procedure] ==== . カーネルソースを取得する (crossref:cutting-edge[updating-upgrading,FreeBSD のアップデートとアップグレード] をご覧ください)。 . [.filename]#/etc/make.conf# を編集し、 `BOOT_COMCONSOLE_PORT` に 使用したいポートのアドレス(0x3F8、0x2F8、0x3E8 or 0x2E8)を 設定してください。使用可能なのは [.filename]#sio0# から [.filename]#sio3# ([.filename]#COM1# から [.filename]#COM4#) までで、 マルチポートシリアルカードは使えません。 また、ここで割り込みの設定をする必要はありません。 . 設定を変更するために新たなカーネルコンフィグレーションファイルを作成し、 使いたいシリアルポートのフラグを適切に設定します。 例えば、[.filename]#sio1# ([.filename]#COM2#) をコンソールにしたければ、 + [.programlisting] .... device sio1 at isa? port "IO_COM2" tty flags 0x10 irq 3 .... + または、 + [.programlisting] .... device sio1 at isa? port "IO_COM2" tty flags 0x30 irq 3 .... + とします。その際、 他のシリアルポートにコンソールフラグをつけてはいけません。 . ブートブロックを再コンパイルし、インストールする。 + [source,shell] .... # cd /sys/boot/i386/boot2 # make # make install .... + . ブートローダを再コンパイルし、インストールする。 + [source,shell] .... # cd /sys/boot/i386/loader # make # make install .... + . カーネルを再構築し、インストールする。 . man:disklabel[8] を使ってブートブロックをブートディスクに書き込み、 新しいカーネルから起動する。 ==== ==== シリアルポートから DDB デバッガを起動するには シリアルコンソールからカーネルデバッガを起動したい(これは リモートで診断する際に便利ですが、もしおかしな BREAK 信号がシリアルポートに送られるような場合には危険です!) 場合には、次のオプションを使ってカーネルをコンパイルして下さい。 [.programlisting] .... options BREAK_TO_DEBUGGER options DDB .... ==== シリアルコンソールにログインプロンプトを表示させるには シリアルコンソールからブートメッセージを確認したり、 シリアルコンソールを経由してカーネルデバッグセッションに入ることが できるので、これは必要がないかもしれませんが、 _login_ プロンプトをシリアルポートに 出力するように設定することもできます。 これには、次のようにします。 エディタで [.filename]#/etc/ttys# というファイルを開き、 次に示す行に移動して下さい。 [.programlisting] .... ttyd0 "/usr/libexec/getty std.9600" unknown off secure ttyd1 "/usr/libexec/getty std.9600" unknown off secure ttyd2 "/usr/libexec/getty std.9600" unknown off secure ttyd3 "/usr/libexec/getty std.9600" unknown off secure .... `ttyd0` から `ttyd3` は、 [.filename]#COM1# から [.filename]#COM4# に対応しています。 設定したいポートの `off` を `on` に変更して下さい。 また、もしシリアルポートの通信速度を変更しているなら、 `std.9600` が実際の通信速度になるように、 例えば `std.19200` のように変更して下さい。 さらに、実際のシリアル端末に合わせて、 端末タイプを `unknown` から変更することも可能です。 ファイルの編集が終了したら、 変更を有効化するために `kill -HUP 1` を実行しなければなりません。 [[serialconsole-loader]] === ブートローダからコンソールを変更するには 前セクションは、ブートブロックの設定を変更することでシリアルコンソールを セットアップする方法について解説していました。 このセクションでは、ブートローダへのコマンド入力と環境変数設定で コンソールの指定を行なう方法を紹介します。 ブートローダがブートブロックの後、 ブートプロセスの第三ステージで呼び出されたとき、 ブートローダの設定には、ブートブロックの設定がそのまま使われます。 ==== シリアルコンソールをセットアップする ブートローダとカーネルに対して シリアルコンソールを使用するように設定するには、 単に [.filename]#/boot/loader.rc# のファイルに、次のような一行を書くだけで実現できます。 [.programlisting] .... set console=comconsole .... これは、前セクションで扱ったブートブロックの設定に 全く関係なく機能します。 上に示した行は、 [.filename]#/boot/loader.rc# の最初の行に書き込まなくてはいけません。 これはできるだけ早く、ブートメッセージをシリアルコンソールに 出力させるために必要なことです。 同様にして、次のように内蔵コンソールを指定することもできます。 [.programlisting] .... set console=vidconsole .... もし、ブートローダの環境変数 `console` が設定されていない場合、 ブートローダ、そしてその次に起動するカーネルは ブートブロックで指定された `-h` オプションに 示されたコンソールを使用します。 3.2 以降のバージョンにおいては [.filename]#/boot/loader.rc# ではなく、 [.filename]#/boot/loader.conf.local# や [.filename]#/boot/loader.conf# にコンソール指定を書き込みます。 その場合、 [.filename]#/boot/loader.rc# は次のようになっていなければなりません。 [.programlisting] .... include /boot/loader.4th start .... それから、[.filename]#/boot/loader.conf.local# を作成して、次の行をそこに追加して下さい。 [.programlisting] .... console=comconsole .... か、もしくは [.programlisting] .... console=vidconsole .... です。詳細については、man:loader.conf[5] を参照して下さい。 [NOTE] ==== その際、ブートローダはオプション指定なし (ブートブロックに `-P` オプションが指定されたのと等価)になり、 キーボードの存在を調べて 内蔵コンソールとシリアルコンソールを自動的に選択する機能は働きません。 ==== ==== [.filename]#sio0# 以外のシリアルポートを コンソールとして使うには [.filename]#sio0# 以外のシリアルポートを コンソールとして使うには、ブートローダを再コンパイルする必要があります。 それには、 <> に書かれている説明にしたがって下さい。 [[serialconsole-caveats]] === 注意 シリアルコンソールというアイデアは、 グラフィック出力用のハードウェアやキーボードが接続されていない 専用サーバのセットアップを可能にするためのものです。 ほとんどのシステムはキーボードなしで起動できますが、 不幸にも、グラフィックアダプタなしでは起動できないシステムはたくさんあります。 AMI BIOS を採用しているマシンでは、CMOS 設定の `graphics adapter` を `Not Installed` にするだけで、 グラフィックアダプタがなくとも起動できるように設定することができます。 しかしながら、多くのマシンはこのようなオプションを持っていませんし、 ディスプレイハードウェアがシステムに存在しないと起動しないように なっています。そのようなマシンでは、 モニタを接続する必要がなかったとしても、 適当なグラフィックカード(モノクロのジャンク品でも構いません)を 挿入したままにしておく必要があるでしょう。 また、AMI BIOS をインストールする、という手もあります。 diff --git a/documentation/content/ja/books/handbook/users/_index.adoc b/documentation/content/ja/books/handbook/users/_index.adoc deleted file mode 100644 index 120c3ce312..0000000000 --- a/documentation/content/ja/books/handbook/users/_index.adoc +++ /dev/null @@ -1,527 +0,0 @@ ---- -title: 第13章 ユーザと基本的なアカウントの管理 -part: パートIII. システム管理 -prev: books/handbook/boot -next: books/handbook/security -showBookMenu: true -weight: 17 -path: "/books/handbook/" ---- - -[[users]] -= ユーザと基本的なアカウントの管理 -:doctype: book -:toc: macro -:toclevels: 1 -:icons: font -:sectnums: -:sectnumlevels: 6 -:sectnumoffset: 13 -:partnums: -:source-highlighter: rouge -:experimental: -:images-path: books/handbook/users/ - -ifdef::env-beastie[] -ifdef::backend-html5[] -:imagesdir: ../../../../images/{images-path} -endif::[] -ifndef::book[] -include::shared/authors.adoc[] -include::shared/mirrors.adoc[] -include::shared/releases.adoc[] -include::shared/attributes/attributes-{{% lang %}}.adoc[] -include::shared/{{% lang %}}/teams.adoc[] -include::shared/{{% lang %}}/mailing-lists.adoc[] -include::shared/{{% lang %}}/urls.adoc[] -toc::[] -endif::[] -ifdef::backend-pdf,backend-epub3[] -include::../../../../../shared/asciidoctor.adoc[] -endif::[] -endif::[] - -ifndef::env-beastie[] -toc::[] -include::../../../../../shared/asciidoctor.adoc[] -endif::[] - -[[users-synopsis]] -== この章では - -FreeBSD は、複数のユーザが同時にコンピュータを使えるようにします。 スクリーンとキーボードの前に一度に座れるのはその中の一人だけですが ユーザは何人でもネットワークを通してログインできます。 システムを使うためには、 どのユーザもアカウントがなければなりません。 - -この章では、以下のことを説明します。 - -* FreeBSD システムにおけるさまざまな種類のユーザアカウントについて -* ユーザアカウントを追加、削除および変更する方法 -* ユーザやグループが利用できるリソースの上限を制御する方法 -* グループの作成、 およびグループにユーザをメンバとして追加する方法 - -[[users-introduction]] -== アカウントの種類 - -FreeBSD システムへアクセスするには、 かならずアカウントが使われ、 また、プロセスもすべてユーザによって実行されるので、 ユーザとアカウントの管理は、重要なものです。 - -アカウントには大きく分けて三種類あります。 システムアカウント (system accounts)、ユーザアカウント (user accounts)、 そしてスーパーユーザ (superuser) です。 - -[[users-system]] -=== システムアカウント - -システムアカウントは、DNS、メール、 ウェブサーバといった各種サービスを運用するために使われます。 この目的は、セキュリティを確保するためです。 もしすべてのサービスがスーパーユーザで実行されていると、 それらのサービスはどんな動作でも可能となり、 適切な制限を適用することができません。 - -システムアカウントの具体例は、 `daemon`, `operator`, `bind`, `news` および `www` といったものです。 - -`nobody` は通常の特権を持たないシステムアカウントです。 しかし、`nobody` を利用するサービスが増えれば増えるほど、 それに所属するファイルやプロセスも増え、 その特権も大きくなるということを忘れないようにしてください。 - -[[users-user]] -=== ユーザアカウント - -ユーザアカウントは、 主に現実のユーザがシステムにアクセスする手段として用いられるものです。 システムにアクセスするすべてのユーザは、 それぞれ唯一のユーザアカウントを持つべきです。 こうすることで管理者は誰が何を行なっているかがわかりますし、 他の人の設定を壊してしまうようなことを避けることができます。 - -それぞれのユーザは快適にシステムを利用するため、 シェル、エディタ、キー設定、言語など、 各自の環境をセットアップすることができます。 - -FreeBSD システム上のどのアカウントにも、 以下のような情報がなにかしら結び付けられています。 - -ユーザ名:: -`login:` プロンプトに対して入力するユーザの名前です。 ユーザ名はそのシステムで一意でなければならず、 2 名のユーザに同じユーザ名をつけることはできません。 有効なユーザ名を作成するには man:passwd[5] に記載されているいくつもの規則があります。 アプリケーションの上位互換性を保つために、 8 文字以下の小文字からなるユーザ名を使うことが推奨されています。 - -パスワード:: -それぞれのユーザアカウントにはパスワードがあります。 パスワードは空白にもできますが、 行うべきではありません。 - -ユーザ ID (UID):: -ユーザ ID (UID) は、 FreeBSD システムがユーザを一意に識別するための数値です。 ユーザ名を指定できるコマンドは、 ユーザ名を UID に変換してから扱っています。 65535 より大きな UID は、32 ビット以上の整数に対応していないソフトウェアにおいて互換性の問題を引き起こす可能性があるので、 65535 以下の UID を使用することが推奨されています。 - -グループ ID (GID):: -グループ ID (GID) は、 ユーザが属する第一グループを一意に識別するための数値です。 グループは、UID ではなく、 ユーザの GID に基づいて資源へのアクセスを制御する仕組みです。 これは、ある種の設定ファイルのサイズを大幅に小さくします。 ユーザは、複数のグループに所属できます。 65535 より大きな GID は、ソフトウェアに問題を引き起こす可能性があるので、 65535 以下の GID を使うことを推奨します。 - -ログインクラス:: -ログインクラスはグループの仕組みを拡張したもので、 別々のユーザに対してシステムを調整する時に、 さらなる柔軟性を提供します。ログインクラスの詳細については、 <> で説明します。 - -パスワード変更時間:: -デフォルトでは、FreeBSD は定期的にパスワードを変更することをユーザに強制しません。 これを man:pw[8] を使用してユーザごとに設定し、 一部またはすべてのユーザに、 一定の時間がたったらパスワードを強制的に変更させることができます。 - -アカウント失効時間:: -デフォルトでは、FreeBSD はアカウントを失効させません。 たとえば学校で生徒のアカウントがある場合など、 限られた期間だけのアカウントを作成するなら、 そのアカウントがいつ失効するか man:pw[8] を使って指定できます。 有効期間が経過したら、 そのアカウントのディレクトリやファイルは残っていますが、 システムへのログインはできなくなります。 - -ユーザの氏名:: -FreeBSD ではユーザ名でアカウントを一意に識別しますが、 必ずしもユーザの本名を反映したものではありません。 この情報をアカウントに関連付けることもできます。 この情報は、コメントのように、空白、大文字、および 8 字以上で記載できます。 - -ホームディレクトリ:: -ホームディレクトリは、システム中のディレクトリへのフルパスです。 これはユーザがログインした時に作業を開始するディレクトリです。 一般的な慣習は、すべてのユーザのホームディレクトリを [.filename]#/home/username# か [.filename]#/usr/home/username# の下に置くことです。 各ユーザは、個人のファイルやサブディレクトリを、 ユーザのホームディレクトリに保存します。 - -ユーザシェル:: -シェルは、 ユーザがシステムと対話するデフォルトの環境を提供します。 いろいろな種類のシェルがあり、 経験を積んだユーザはそれぞれ好みがあり、 それをアカウントの設定に反映できます。 - -[[users-superuser]] -=== スーパーユーザアカウント - -スーパーユーザアカウントは通常 `root` と呼ばれ、 システム管理を行なうために使われ、権限に制限がありません。 そのため、このアカウントはメールのやりとり、システムの調査、 プログラミングといった日常的な作業を行なうために使われるべきものではありません。 - -その理由は、スーパーユーザが通常のユーザアカウントと異なり、 操作にまったく制限を受けないことによります。 そのためスーパーユーザアカウントで操作を間違えると、 システムに重大な影響を与えてしまう恐れがあるのです。 ユーザアカウントでは、 仮に操作を間違えてもシステムを壊してしまうようなことはできないようになっています。 そのため、ユーザアカウントでログインし、 高い権限が必要なコマンドを実行するときだけスーパーユーザになることが推奨されています。 - -スーパーユーザで実行するコマンドはいつでも、 二回、三回と確認してください。 なぜならスペースが多かったり、文字が欠けていたりするだけで、 取り返しのつかないデータの破壊につながる可能性があるからです。 - -スーパーユーザの権限を得るには、さまざまな方法があります。 `root` ユーザとしてログインする方法もありますが、 これはまったくお勧めできません。 - -スーパーユーザの権限を手に入れるには、かわりに man:su[1] を使って下さい。 `-` オプションをつけて実行すると、 実行したユーザに root ユーザの環境が設定されます。 このコマンドは `wheel` グループに入ってるユーザのみが実行でき、他のユーザは実行出来ません。 また、実行時には `root` ユーザのパスワードを必要とします。 - -以下の例では、`make install` を行うときにスーパーユーザの権限が必要なので、 このコマンドを実行する時だけユーザはスーパーユーザになります。 コマンドを実行したら、ユーザは `exit` を実行してスーパーユーザからログアウトし、 通常のユーザアカウントの権限に戻ります。 - -.スーパーユーザ権限でプログラムをインストールする -[example] -==== - -[source,shell] -.... -% configure -% make -% su - -Password: -# make install -# exit -% -.... - -==== - -1 人の管理者が一台のマシン、 もしくは小規模なネットワークを管理する場合には、 man:su[1] のフレームワークはうまく機能するでしょう。 この代わりとなるのは、 package:security/sudo[] package または port です。これはログ機能や、 スーパーユーザの権限で実行できるユーザやコマンドを設定できます。 - -[[users-modifying]] -== アカウント情報の管理 - -FreeBSD には、 ユーザアカウントを操作するのにさまざまなコマンドが用意されています。 もっとも一般的なコマンドを以下に示し、 それに続いて詳しい使用例を示します。 - -[.informaltable] -[cols="1,1", frame="none", options="header"] -|=== -| コマンド -| 要約 - -|man:adduser[8] -|コマンドラインからユーザを追加するための推奨アプリケーション - -|man:rmuser[8] -|コマンドラインからユーザを削除するための推奨アプリケーション - -|man:chpass[1] -|ユーザデータベースの情報を変更するための柔軟なツール - -|man:passwd[1] -|ユーザのパスワードを変更する簡単なコマンドラインツール - -|man:pw[8] -|ユーザアカウントのあらゆる箇所を変更する強力で柔軟なツール -|=== - -[[users-adduser]] -=== `adduser` - -man:adduser[8] は、 新しいユーザを登録するためのシンプルなプログラムです。 ユーザを追加すると、 このプログラムは、[.filename]#/etc/passwd# と [.filename]#/etc/group# を自動的に更新します。 また、新規ユーザのホームディレクトリを作成し、 [.filename]#/usr/shared/skel# から、デフォルトで使用される設定ファイルをコピーします。 また、新しく作成されたユーザに対して、 ウェルカムメッセージをメールで送信することも可能です。 - -.FreeBSD におけるユーザの追加 -[example] -==== - -[source,shell] -.... -# adduser -Username: jru -Full name: J. Random User -Uid (Leave empty for default): -Login group [jru]: -Login group is jru. Invite jru into other groups? []: wheel -Login class [default]: -Shell (sh csh tcsh zsh nologin) [sh]: zsh -Home directory [/home/jru]: -Home directory permissions (Leave empty for default): -Use password-based authentication? [yes]: -Use an empty password? (yes/no) [no]: -Use a random password? (yes/no) [no]: -Enter password: -Enter password again: -Lock out the account after creation? [no]: -Username : jru -Password : **** -Full Name : J. Random User -Uid : 1001 -Class : -Groups : jru wheel -Home : /home/jru -Shell : /usr/local/bin/zsh -Locked : no -OK? (yes/no): yes -adduser: INFO: Successfully added (jru) to the user database. -Add another user? (yes/no): no -Goodbye! -# -.... - -==== - -[NOTE] -==== -入力したパスワードは画面に表示されませんので、 ユーザアカウントを作成する際には、 パスワードを間違えて入力してしまわないように注意してください。 -==== - -[[users-rmuser]] -=== `rmuser` - -システムから完全にユーザを削除するには、 man:rmuser[8] を使います。 このコマンドは、次の手順を実行します。 - -[.procedure] -==== -. 指定されたユーザの man:crontab[1] エントリが存在する場合には削除。 -. 指定されたユーザの man:at[1] ジョブをすべて削除。 -. 指定されたユーザが所有するすべてのプロセスを強制終了。 -. ローカルパスワードファイルから、 指定されたユーザのエントリを削除。 -. 指定されたユーザのホームディレクトリを削除 (ディレクトリの所有者が指定されたユーザのものだった場合)。 -. [.filename]#/var/mail# から、指定されたユーザの到着メールファイルを削除。 -. [.filename]#/tmp# のような一時ファイル保存領域から、 指定されたユーザの所有するファイルを削除。 -. そして最後に、 [.filename]#/etc/group# にある すべてのグループから、指定されたユーザを削除します。 -+ -[NOTE] -====== -指定されたユーザと同じ名前のグループで、 そのユーザが削除されると空のグループとなる場合は、 そのグループ自体が削除されます。 これは man:adduser[8] によってユーザごとに作成される、 ユニークなグループに対応するものです。 -====== -==== - -スーパユーザアカウントの削除に man:rmuser[8] を利用することはできません。 スーパユーザアカウントの削除はほとんどすべての場合、 大規模なシステムの破壊を意味するからです。 - -デフォルトでは、以下の例のような対話モードが使われます。 - -.`rmuser` による対話的なアカウントの削除 -[example] -==== - -[source,shell] -.... -# rmuser jru -Matching password entry: -jru:*:1001:1001::0:0:J. Random User:/home/jru:/usr/local/bin/zsh -Is this the entry you wish to remove? y -Remove user's home directory (/home/jru)? y -Updating password file, updating databases, done. -Updating group file: trusted (removing group jru -- personal group is empty) done. -Removing user's incoming mail file /var/mail/jru: done. -Removing files belonging to jru from /tmp: done. -Removing files belonging to jru from /var/tmp: done. -Removing files belonging to jru from /var/tmp/vi.recover: done. -# -.... - -==== - -[[users-chpass]] -=== `chpass` - -man:chpass[1] を用いて、 パスワード、シェル、その他の個人情報といった、 ユーザデータベース情報を変更できます。 - -スーパユーザ権限に限り、 man:chpass[1] を用い、 他のユーザの情報やパスワードを変更できます。 - -ユーザ名の他にオプションを指定しないと、 man:chpass[1] はユーザ情報を編集するエディタを表示します。 ユーザがエディタを終了すると、 ユーザデータベースが新しい情報に更新されます。 - -[NOTE] -==== -スーパユーザでない場合は、 エディタを抜けた後にパスワードを聞かれます。 -==== - -.スーパユーザによる対話的な `chpass` -[example] -==== - -[source,shell] -.... -#Changing user database information for jru. -Login: jru -Password: * -Uid [#]: 1001 -Gid [# or name]: 1001 -Change [month day year]: -Expire [month day year]: -Class: -Home directory: /home/jru -Shell: /usr/local/bin/zsh -Full Name: J. Random User -Office Location: -Office Phone: -Home Phone: -Other information: -.... - -==== - -ユーザは、この情報の限られた部分のみ変更が可能です。 また、変更できるのはそのユーザ自身のアカウント情報のみです。 - -.通常のユーザによる対話的な `chpass` -[example] -==== - -[source,shell] -.... -#Changing user database information for jru. -Shell: /usr/local/bin/zsh -Full Name: J. Random User -Office Location: -Office Phone: -Home Phone: -Other information: -.... - -==== - -[NOTE] -==== -man:chfn[1] および man:chsh[1] はいずれも、 man:chpass[1] へのリンクです。 また、man:ypchpass[1], man:ypchfn[1] および man:ypchsh[1] も同様です。 NIS のサポートは自動的に行なわれますので、 コマンドの先頭に `yp` をつける必要はありません。 NIS の設定については、 で説明されています。 -==== - -[[users-passwd]] -=== `passwd` - -man:passwd[1] は、 ユーザが自分のパスワードを変更する通常の方法です。 スーパユーザ権限では、 他のユーザのパスワードを変更するのに使われます。 - -[NOTE] -==== -誤って、または不正なパスワードの変更を避けるため、 新しいパスワードを設定する前に、 もとのパスワードを入力しなければなりません。 スーパーユーザの権限でユーザのパスワードを変更する際には、 もとのパスワードを入力する必要はありません。 -==== - -.自分のパスワードの変更 -[example] -==== - -[source,shell] -.... -% passwd -Changing local password for jru. -Old password: -New password: -Retype new password: -passwd: updating the database... -passwd: done -.... - -==== - -.スーパーユーザ権限での他のユーザのパスワード変更 -[example] -==== - -[source,shell] -.... -# passwd jru -Changing local password for jru. -New password: -Retype new password: -passwd: updating the database... -passwd: done -.... - -==== - -[NOTE] -==== -man:chpass[1] 同様、man:yppasswd[1] は、 man:passwd[1] へのリンクになっていますので、 NIS はどちらのコマンドでも動作します。 -==== - -[[users-pw]] -=== `pw` - -man:pw[8] は、ユーザやグループの作成、削除、 変更および表示を行なうコマンドラインのユーティリティです。 これは、システムユーザファイルやシステムグループファイルの フロントエンドとして働きます。man:pw[8] はとても強力な一連のコマンドラインオプションを有しており、 シェルスクリプトで使うのに向いていますが、新しいユーザは、 この章で紹介されている他のコマンドに比べて難しいと感じるかもしれません。 - -[[users-limiting]] -== ユーザへの制限 - -FreeBSD は、 個々のユーザが利用できるシステム資源の量を管理者が制限できる方法をいくつも用意しています。 その種の制限は、ディスククォータ (quota) とその他の資源の制限の 2 つの章で説明します。 - -ディスククォータは、ユーザが利用できるディスク容量を制限し、 その都度計算しなくてもディスク使用量を簡単に確認できる手段も提供しています。 クォータについては、crossref:disks[quotas,「ファイルシステムクォータ」] で解説しています。 - -その他のリソースの制限とは、ユーザが消費できる CPU、メモリなどのリソースを制限する手段のことです。 これはログインクラスを用いて定義されているもので、 この後で解説しています。 - -ログインクラスは [.filename]#/etc/login.conf# で定義します。詳細な説明は man:login.conf[5] に詳しく記載されています。 各ユーザアカウントにはログインクラスが割り当てられていて (デフォルトでは `default` です)、 それぞれのログインクラスにはログインケーパビリティの集合が割り当てられています。 ログインケーパビリティとは、 `名称=値` の組のことで、_名称_ は周知の識別子、_値_ は、_名称_ に応じて処理される任意の文字列です。 ログインクラスとケーパビリティを設定するのはどちらかといえば簡単なことで、 man:login.conf[5] でも説明されています。 - -[NOTE] -==== -FreeBSD は通常、直接 [.filename]#/etc/login.conf# から設定を読み込まず、 より速く検索できる [.filename]#/etc/login.conf.db# データベースから読み込みます。[.filename]#/etc/login.conf# を編集する時には [.filename]#/etc/login.conf.db# を次のコマンドを実行してアップデートする必要があります。 - -[source,shell] -.... -# cap_mkdb /etc/login.conf -.... - -==== - -リソースの制限は、 2 つの点で標準的なログインケーパビリティと異なっています。 第一に、どの制限についても、ソフト (現在の) リミットとハードリミットがあります。 ソフトリミットは、ユーザやアプリケーションが調整できますが、 ハードリミットを超えることはできません。 ユーザはハードリミットを下げることはできますが、 上げることはスーパユーザのみができます。 第二に、ほとんどのリソースの制限は特定のユーザに対してプロセス毎に適用されるもので、 そのユーザが利用するリソースの総量を制限するものではありません。 ただし、この違いは制限を特別扱いすることで実現されるものであり、 ログインケーパビリティフレームワークの実装によるものではありません。 - -以下が最もよく使われるリソースの制限になります。 残りは、他のすべてのログインケーパビリティと並んで man:login.conf[5] に書かれています。 - -`coredumpsize`:: -プログラムが生成する core ファイルのサイズにかかる制限は、 `filesize` やディスククォータなどの、 ほかのディスク使用に関する制限に従属します。 この制限は、ディスク領域の消費を制御するあまり厳しくない手段としてよく使われています。 ユーザは core ファイルを自分で生成するわけではなく、 削除しないことも多いので、 これを設定すれば大きなプログラムが異常終了してもディスクの空きがなくならずに済みます。 - -`cputime`:: -そのユーザのプロセスが消費できる CPU 時間 の上限です。 これを超えたプロセスは、カーネルにより終了されます。 -+ - -[NOTE] -==== -これは、消費される CPU _時間_ についての制限であって、man:top[1] や man:ps[1] のフィールドで表示される CPU の割合に関するものではありません。 -==== - -`filesize`:: -ユーザが所有できるファイルの大きさの上限です。crossref:disks[quotas,ディスククォータ] と違い、 この制限はユーザのファイルをすべてまとめた集合にではなく、 個々のファイルにかかります。 - -`maxproc`:: -ユーザが実行できるプロセス数の上限です。 フォアグラウンドプロセスとバックグラウンドプロセスの両方を扱います。 この上限は、man:sysctl[8] 変数 `kern.maxproc` で指定されたシステムの制限を超えることはできません。 同時に複数ログインすることや、 パイプライン実行することは便利なことが多いので、 この値をあまり小さな値に設定すると、 そのユーザの生産性が悪化する可能性があります。 大きなプログラムをコンパイルする場合のように、 タスクによっては複数のプロセスやプリプロセッサが実行されます。 - -`memorylocked`:: -これは、1 つのプロセスが man:mlock[2] によりメインメモリにロックされることを要求できるメモリの最大容量です。 man:amd[8] のようなシステムで重要なプログラムは、 メインメモリへロックして、システムがスワップする際に、 ディスクのスラッシングを引き起こさないようにします。 - -`memoryuse`:: -これは、どの時点かを問わず、 あるプロセスが消費できる最大のメモリ容量です。 これは、メインメモリとスワップの使用量を合わせたものです。 メモリ消費を抑えるための包括的な制限ではありませんが、 手始めにはよいでしょう。 - -`openfiles`:: -これは、あるプロセスが開いておける最大のファイル数です。 FreeBSD では、ファイルはまた、ソケットや IPC チャンネルを表わすのにも使われています。 ですから、あまり低い値に設定しないよう注意してください。 これに対応するシステム全体の制限は man:sysctl[8] `kern.maxfiles` で定義されています。 - -`sbsize`:: -これは、あるユーザが消費できるネットワークメモリ (つまり mbuf) の上限の量です。ユーザは、 ネットワーク通信を制限するのに使えます。 - -`stacksize`:: -これは、プロセスのスタックサイズの上限です。 あるプログラムが使用しうるメモリの量を制限するには、 これだけでは十分ではありません。 したがって、他の制限と組み合わせて使わなければなりません。 - -リソースの制限を設定するにあたり、 ほかにもいくつか覚えておかなければならないことがあります。 以下は、一般的なこつやお勧め、さまざまなコメントになります。 - -* システム起動時に [.filename]#/etc/rc# から起動されたプロセスは、`daemon` ログインクラスに割り当てられます。 -* システムに付属していた [.filename]#/etc/login.conf# はほとんどの制限について妥当な値になっていますが、 すべてのシステムにおいてふさわしいというわけではありません。 制限をあまり緩くするとシステムを悪用しやすくしてしまいますし、 厳しくしすぎると生産性を悪化させてしまいます。 -* Xorg のユーザには、 他のユーザより多くのリソースを与えるべきかもしれません。 Xorg そのものが多くのリソースを使うだけでなく、 より多くのプログラムを並行して使うことをユーザに促します。 -* 多くの制限は個々のプロセスにかかるもので、 一人のユーザにまとめてかかるものではありません。 例えば、`openfiles` を 50 に設定することは、 ユーザが動かすそれぞれのプロセスが最大 50 個のファイルを開けるということです。 あるユーザが開けるファイルの総数は、 `openfiles` の値に `maxproc` をかけたものになります。 同じことがメモリ消費量にもあてはまります。 - -リソースの制限と、ログインクラス、 ログインケーパビリティ一般についての詳しい情報は、 man:cap.mkdb[1], man:getrlimit[2] および man:login.conf[5] をご覧ください。 - -[[users-groups]] -== グループの管理 - -グループとは、ユーザを羅列したものです。 グループは、グループ名と GID で識別されます。 FreeBSD では、 あるプロセスが何かするのを許可するかどうかをカーネルが判断する際に、 プロセスの UID とそのユーザが所属するグループの一覧を利用します。 ほとんどの場合、ユーザもしくはプロセスの GID は一覧の最初のグループを指しています。 - -グループ名から GID への写像は [.filename]#/etc/group# にあります。 これは、コロンで区切られた 4 項目からなるテキストファイルです。 1 番目の項目はグループ名、 2 番目は暗号化されたパスワード、 3 番目が GID、 4 番目がカンマで区切られたメンバの一覧です。 文法についての完全な説明は、man:group[5] をご覧ください。 - -スーパーユーザは、[.filename]#/etc/group# をテキストエディタで編集できます。 もしくは、man:pw[8] を使ってグループの追加や編集をできます。 たとえば、`teamtwo` というグループを追加して、その存在を確認するには、 次のように使います。 - -.man:pw[8] によるグループの追加 -[example] -==== - -[source,shell] -.... -# pw groupadd teamtwo -# pw groupshow teamtwo -teamtwo:*:1100: -.... - -==== - -この例では、`1100` という番号は、 `teamtwo` の GID です。 この時点では、`teamtwo` にメンバはいません。 以下のコマンドは、 `jru` を `teamtwo` のメンバに追加します。 - -.man:pw[8] により新しいグループにメンバを追加する -[example] -==== - -[source,shell] -.... -# pw groupmod teamtwo -M jru -# pw groupshow teamtwo -teamtwo:*:1100:jru -.... - -==== - -`-M` の引数は、 カンマで区切られた新しい (空の) グループに追加するもしくは存在するグループのメンバを置き換えるユーザの一覧です。 ユーザにとっては、このグループのメンバーシップはパスワードファイルに記載されているプライマリのグループとは異なります。 man:pw[8] の `groupshow` コマンドを使った時は、 そのユーザはグループの一員として表示されませんが、man:id[1] などのツールを使って情報を問い合わせれば、 その情報を引き出せます。ユーザをグループに追加をする際に、man:pw[8] は [.filename]#/etc/group# しか扱わず、 [.filename]#/etc/passwd# から追加のデータを読んだりはしません。 - -.man:pw[8] によるグループへのユーザ追加 -[example] -==== - -[source,shell] -.... -# pw groupmod teamtwo -m db -# pw groupshow teamtwo -teamtwo:*:1100:jru,db -.... - -==== - -この例では、`-m` の引数は、 カンマで区切られたグループに追加するユーザの一覧です。 前の例と異なり、これらのユーザはグループ一覧に追加され、 グループのユーザ一覧を置き換えることはありません。 - -.グループに所属しているユーザを調べるための man:id[1] の使い方 -[example] -==== - -[source,shell] -.... -% id jru -uid=1001(jru) gid=1001(jru) groups=1001(jru), 1100(teamtwo) -.... - -==== - -この例では、`jru` は `jru` グループと `teamtwo` グループのメンバです。 - -このコマンドや [.filename]#/etc/group# のフォーマットの詳細については、 man:pw[8] および man:group[5] をご覧ください。