diff --git a/ja_JP.eucJP/man/man7/build.7 b/ja_JP.eucJP/man/man7/build.7 index d520af5789..9eff76d0fb 100644 --- a/ja_JP.eucJP/man/man7/build.7 +++ b/ja_JP.eucJP/man/man7/build.7 @@ -1,206 +1,206 @@ .\" Copyright (c) 2000 .\" Mike W. Meyer .\" .\" Redistribution and use in source and binary forms, with or without .\" modification, are permitted provided that the following conditions .\" are met: .\" 1. Redistributions of source code must retain the above copyright .\" notice, this list of conditions and the following disclaimer. .\" 2. Redistributions in binary form must reproduce the above copyright .\" notice, this list of conditions and the following disclaimer in the .\" documentation and/or other materials provided with the distribution. .\" .\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE .\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF .\" SUCH DAMAGE. .\" -.\" %FreeBSD: src/share/man/man7/build.7,v 1.24 2003/11/16 15:16:19 simon Exp % +.\" %FreeBSD: src/share/man/man7/build.7,v 1.25 2004/06/16 08:33:56 ru Exp % .\" .\" $FreeBSD$ .Dd March 15, 2002 .Dt BUILD 7 .Os .Sh 名称 .Nm build .Nd システムの構築方法についての情報 .Sh 解説 .Fx システムおよびアプリケーションのソースコードは、異なる 3 つの ディレクトリに格納されています。通常は、 .Pa /usr/src , .Pa /usr/doc , .Pa /usr/ports です。 .Pa /usr/src には .Dq "ベースシステム" のソースが含まれています。ベースシステムとは、システムを使える 状態に構築し直すのに必要なものとして大雑把に定義されています。 .Pa /usr/doc にはシステムドキュメントのソースが含まれています。ただし、マニュアル ページは除きます。 .Pa /usr/ports は、サードパーティのアプリケーションを構築し、インストールするための 一貫したインタフェースを提供しているツリーです。 .Pp これら 3 つのディレクトリそれぞれに格納されているものを構築し インストールするには、 .Xr make 1 コマンドを使用します。これら 3 つのディレクトリ、もしくは サブディレクトリ内のどこででも .Xr make 1 コマンドを実行すれば、 そのディレクトリ配下のサブディレクトリ内すべてで同一のコマンドを 発行したのと同じ効果があります。 ターゲットを指定しなければ、make コマンドを実行した ディレクトリ内にあるものを単純に構築します。 次のリストはその他のターゲットの名称およびアクションを示した ものです: .Bl -tag -width indent-two .It Cm clean 構築プロセス中で生成されたファイルをすべて消去します。 .It Cm install このディレクトリに対する構築結果をインストールします。 .It Cm update 更新されたソースを .Pa /etc/make.conf で設定されている通りに取得します。 .El .Pp その他の .Pa /usr/src での make ターゲットは次のものがあります: .Bl -tag -width indent-two .It Cm buildworld カーネル以外のすべてのものを再構築し、 .Pa /etc ディレクトリ内のファイルを設定してリリースします。 .It Cm installworld .Cm buildworld で構築したものすべてをインストールします。 .It Cm world .Cm buildworld と .Cm installworld を足したものです。 .It Cm buildkernel カーネルとカーネルモジュールを再構築します。 .It Cm installkernel カーネルとカーネルモジュールをインストールします。 .It Cm reinstallkernel カーネルとカーネルモジュールを再インストールします。 .El .Pp ports の構築プロセスに関する情報については、 .Xr ports 7 を参照してください。 .Sh 環境変数 .Bl -tag -width ".Va TARGET_ARCH" .It Va TARGET_ARCH ターゲットとなるマシンプロセッサアーキテクチャ。 この環境変数は .Dq Nm uname Fl p の出力と同じものです。 異なるアーキテクチャ用にクロスビルドするにはこの 環境変数を設定してください。 .It Va TARGET ターゲットとなるハードウェアプラットフォーム。 この環境変数は .Dq Nm uname Fl m の出力と同じものです。 ターゲットアーキテクチャをクロスビルドするのに必要な 変数です。 例えば、PC98 マシン用にクロスビルドを行うには .Va TARGET_ARCH Ns = Ns Li i386 と .Va TARGET Ns = Ns Li pc98 が必要です。 .It Va NO_WERROR 定義されている場合、警告が出ても構築が停止することはありません。 makefile が別のことを言ってきても停止しません。 .It Va DESTDIR 生成したバイナリをインストールするディレクトリ階層を指します。 .El .Sh 関連ファイル .Bl -tag -width ".Pa /usr/share/examples/etc/make.conf" -compact .It Pa /etc/make.conf .It Pa /usr/doc/Makefile .It Pa /usr/doc/share/mk/doc.project.mk .It Pa /usr/ports/Mk/bsd.port.mk .It Pa /usr/ports/Mk/bsd.sites.mk .It Pa /usr/share/examples/etc/make.conf .It Pa /usr/src/Makefile .It Pa /usr/src/Makefile.inc1 .El .Sh 使用例 最新のソースからシステムを更新するのには 次のようにするのが .Dq よい とされています: .Bd -literal -offset indent make buildworld make buildkernel KERNCONF=FOO make installkernel KERNCONF=FOO -.Aq 新規カーネルをシングルユーザモードでリブート +<新規カーネルをシングルユーザモードでリブート> make installworld mergemaster .Ed .Pp .Dq Li FOO のところは、カーネルを構築する際に必要となるカーネル設定ファイル名で 置き換える必要があります。 この代わりに、 .Pa /etc/make.conf ファイル中にある .Va KERNCONF 変数を構築するカーネル名に設定することができます。 この場合、 .Cm buildkernel および .Cm installkernel コマンドの .Va KERNCONF Ns = Ns Li FOO の部分は省略可能です。 .Pp これらのコマンドの実行後は、システムをリブートする必要があります。 リブートしないと、再構築されたプログラムの多く ( .Xr ps 1 や .Xr top 1 等) は、まだ動作している古いカーネルでは動かない可能性が あります。 極最近のソースからアップグレードするほとんどの場合には 厳密には必要とはならないのですが、 古いカーネルからのアップグレード時や、そのカーネルで .Dq 奇妙な現象 が発生することが分かっている時には、 シングルユーザモードでのリブートは非常に重要です。 .Pp i386 のホストで Alpha アーキテクチャ用のシステムをクロスビルド するには、次のコマンドシーケンスを使用できます: .Bd -literal -offset indent cd /usr/src make TARGET_ARCH=alpha buildworld make TARGET_ARCH=alpha DESTDIR=/clients/axp installworld .Ed .Sh 関連項目 .Xr cc 1 , .Xr install 1 , .Xr make 1 , .Xr make.conf 5 , .Xr ports 7 , .Xr release 7 , .Xr mergemaster 8 , .Xr reboot 8 , .Xr shutdown 8 .Sh 作者 .An Mike W. Meyer Aq mwm@mired.org です。 diff --git a/ja_JP.eucJP/man/man7/firewall.7 b/ja_JP.eucJP/man/man7/firewall.7 index c0dbb1d9c0..9820bee418 100644 --- a/ja_JP.eucJP/man/man7/firewall.7 +++ b/ja_JP.eucJP/man/man7/firewall.7 @@ -1,373 +1,373 @@ .\" Copyright (c) 2001, Matthew Dillon. Terms and conditions are those of .\" the BSD Copyright as specified in the file "/usr/src/COPYRIGHT" in .\" the source tree. .\" -.\" %FreeBSD: src/share/man/man7/firewall.7,v 1.18 2003/04/26 09:30:34 brueffer Exp % +.\" %FreeBSD: src/share/man/man7/firewall.7,v 1.19 2004/06/16 08:33:56 ru Exp % .\" $FreeBSD$ .Dd May 26, 2001 .Dt FIREWALL 7 .Os .Sh 名称 .Nm firewall .Nd FreeBSD で動作する簡単なファイアウォール .Sh ファイアウォールの基礎 ファイアウォールは一般に、外部から行われるネットワーク内部への不正なアクセス を防ぐために使われます。また、LAN 内だけでサービスされるべき NFS や SMBFS のようなサービスに対して、内部の IP アドレスを偽装して外部から行わ れる攻撃を防ぐためにも用いられます。 .Pp また、 .Fx のファイアウォール機構は、 .Xr dummynet 4 を用いた帯域制限を行うこともできます。この機能は特に重要な目的のために 帯域幅を保証したい場合などに有効でしょう。たとえば、オフィスの T1 (1.5MBits/s) を用いてビデオ会議を行う場合に、他の通信を 1MBits/s までに押えて、 ビデオ会議用のコネクションに最低でも 0.5MBits/s を確保することができます。 また同様に、共用機器で有名なウェブサイトや FTP サイトを運用している場合には、 プロバイダからの高額な帯域課金を避けるために使うこともできます。 .Pp それから、 .Fx のファイアウォール機構はパケットが正しい到達先に行くようにパケットを divert したり、次のホップのアドレスを変更したりすることもできます。 パケットの divert は主に、プライベート IP アドレス空間から外部へのブラウズなど のアクセスを可能にする NAT (ネットワークアドレス変換) を実現するために 用いられます。 .Pp ファイアウォールを構築することは簡単なようですが、多くの人が間違いを犯し ています。最も多い間違いは、包括的なファイアウォールでなく、 排他的なファイアウォールを作ってしまうことです。排他的なファイアウォールは、 ルールセットに適合しなかったすべてのパケットを通過させるもので、 包括的なファイアウォールはルールセットにマッチしたパケットだけを通過させます。 包括的なファイアウォールのほうが、排他的なものよりもはるかに安全ですが、 正しく動くものを 作るのが難しくなります。次に多い間違いは、通過させたくないものすべてを 廃棄してしまうことです。TCP/IP が正常に動作するためには、 たとえば MTU ディスカバリの実装のように、 いくつかの ICMP エラーを必要とします。 同様に、多くのデーモンは、コネクションを要求するユーザを認証するために、 .Sy auth サービスに逆向きのコネクションを張ります。auth は危険ですが、正しい対応 はただパケットを廃棄するのでなく、TCP reset を返すようにすることです。 以下で示す、ファイアウォールのサンプルではこれらの事項を満たすように してあります。 .Sh IPFW を使うためのカーネルの設定 IP ファイアウォールの機能を使用するためには、 カスタムカーネルを作成する必要はありません。 .Em /etc/rc.conf (後述) でファイアウォールを有効にすれば、 ipfw カーネルモジュールが必要な時に自動的にロードされます。 あなたが偏執したいならば、 .Sy IPFIREWALL オプションを設定することで、IPFW を直接 .Fx カーネルに組み込むこともできます。 このファイアウォールは、何も設定しないとすべてのパケットを通過させないように なっています。 .Em /etc/rc.conf で、再起動時に適切なルールセットを読み込むようになっていないと、 コンソールに触ることができない場合、マシンにアクセスすらできなくなります。 また、新しいリリースのカーネルに更新する時に、 バイナリ (訳注: コマンドやライブラリのこと) を更新する前に リブートを実行してしまうことがよくあります。 この結果 .Xr ipfw 8 とカーネルが非互換になってしまい、ブートシーケンスで .Xr ipfw 8 が動作しないことにより、マシンにアクセスできなくなってしまいます。 このために、 .Sy IPFIREWALL_DEFAULT_TO_ACCEPT というカーネルオプションが用意されており、これによってファイアウォールの 初期状態をすべてのパケットを通過させる設定にすることができます。 しかし、 このオプションを設定することは、システムブート中の短期間、 ファイアウォールが全パケットを通すかもしれないことに注意してください。 それでも本オプションの使用は、 .Fx ファイアウォールに十分慣れるまでの期間には有用です。 どのように動作するかすべて分かったら、これを削除して、抜け穴を塞いてください。 第 3 のオプションとして、 .Sy IPDIVERT があります。これは、ファイアウォールがパケットをユーザプログラムに divert することができるようにするもので、 .Xr natd 8 によって、プライベートネットワークから外部へアクセスできるようにするとき に必要です。 トラフィックタイプによる帯域制限には、 .Em ipfw pipe ルールを有効にするために、 .Sy DUMMYNET オプションが必要です。 .Sh IPFW によるファイアウォールの例 ここに示すのは、3 つのインタフェースカードをもつマシンで動作している ipfw ベースのファイアウォールの例です。 fxp0 が「外側の」LAN に接続されています。 この LAN 上のマシンは、10. で始まる内部 IP アドレスと、 インターネットにルーティングされる IP アドレスを持ち、 デュアルホームとなっています。 たとえば、 192.100.5.x がインターネットにルーティングされる IP ブロックを指し、 10.x.x.x が内部ネットワークを指します。 例として適切ではないかもしれませんが、 10.0.1.x が fxp0 の接続されている LAN のアドレス、 10.0.2.x が fxp1 の接続されている LAN のアドレス、 そして 10.0.3.x が fxp2 のものであるとします。 .Pp この例では、3 つの LAN すべてをインターネットから隔離し、またそれぞれを も隔離したいものとします。同時に、すべての内部アドレスから、この マシンで走っている NAT ゲートウェイを経由してインターネットへアクセスが 可能であるようにします。NAT ゲートウェイを動作させるためには、fxp0 に 内部アドレスの 10. のほかに、インターネットから見えるアドレスを持たせる 必要があります。このアドレス (ここでは示していません) が、このマシンの 公式なアドレスであり、もうひとつの外部から見えるアドレス (この例では 192.100.5.5 です) が NAT ゲートウェイとしてのアドレスとなります。 この例は、外部から見える LAN のマシンにも内部アドレス 10.0.0.x を割り当てること によって、すこし複雑になっています。しかしこの方法によって、 内部サービスは内部アドレスにのみバインドし、インターネットから守れます。 外から見える IP アドレスにバインドする サービスは、インターネットに対して公開しようとするものだけにするのです。 .Pp この例では、ネットワーク 10.0.0.x はファイアウォールによって保護されてい ません。このネットワークを外部からのアドレス偽装から守るために、 インターネットルータによる保護を確認して下さい。 また例では、外部から見えるホストが 内部 IP アドレスを通じてサービスを操作する場合、 内部のネットワークに非常に自由にアクセス可能としています。 この方法にはいくらかのセキュリティ上の危険が伴っており、 外部から見えるホストに問題がある場合には何が起きるかわかりません。 この危険を回避するためには、ルール 01010 と 01011 を削除して、 LAN0 経由で入ってくるものすべてを firewall を経由するようにするべきです。 .Pp また、この例では内部アドレス空間を使うことがファイアウォールによる保護機構 の重要な点であることに着目してください。適切なアドレス偽装対策を行うこ とにより、外部から、内部 (LAN1 および LAN2) のホストに直接アクセスするこ とは不可能となります。 .Bd -literal # /etc/rc.conf # firewall_enable="YES" firewall_type="/etc/ipfw.conf" # ファイアウォールを通過する一時的なポート割り当ての範囲を設定 # # 注意 : ファイアウォールを通じて行われるサービスの負荷が高い場合には、 # より広いポート割当の範囲を必要とすることになります。そのような際には # 4000-10000 や 4000-30000 がより良い選択でしょう。 ip_portrange_first=4000 ip_portrange_last=5000 \&... .Ed .Pp .Bd -literal # /etc/ipfw.conf # # FIREWALL: ファイアウォール兼 NAT ゲートウェイ # LAN0 10.0.0.X と 192.100.5.X (デュアルホーム) # LAN1 10.0.1.X # LAN2 10.0.2.X # sw: イーサネットスイッチ (管理対象外) # # 192.100.5.x は、インターネットから見える IP アドレス (インターネットから # ルーティングされる) を意味します。10.x.x.x は、内部 IP アドレス # (外からは見えない) を表します。 # # [LAN1] # ^ # | # FIREWALL -->[LAN2] # | # [LAN0] # | # +--> 外側のホスト A # +--> 外側のホスト B # +--> 外側のホスト C # | # インターネットルータ (2 番目のファイアウォール) # | # [インターネット] # # 注意！ ここには書かれていませんが、インターネットルータは発信元アドレスが # 10. であるパケットを許可しないように設定される必要があります。 # これは、デュアルホームの 10.0.0.x ブロックを保護するためです。 # そうでなければ、外部から見えるホストは、この例では守られていません。 # これらのホストは、外部に見せるサービスのみを外部から見えるアドレスに # バインドすべきです。内部サービスは、安全に内部アドレスにバインド可能です。 # # NAT ゲートウェイは、内部の IP アドレスから外部の IP アドレスへ # 向けて送られるパケットを、ポート 8668 で listen している natd に転送す # ることによって動作します。この動作はルール 00300 によって指定されています。 # 外界から natd に返ってくるパケットも同様に、ルール 00301 によって natd に # 送られます。この例で興味深いのは、外に見せているホストへの内部からの # リクエストは、natd (ルール 00290) を通す必要がないということです。 # これは、外部に見せているホストも内部の 10. ネットワークのことがわかるので # 可能であり、natd の負荷を軽減することができます。内部のトラフィックも # natd を通す必要がありません。これらのホストは、内部の 10. ネットワークの # ルーティングのことがわかるためです。 # /etc/rc.local からは、natd は以下のように起動されます。 # natd のカーネル組み込み型のバージョンである ipnat についても参照してく # ださい。 # # natd -s -u -a 208.161.114.67 # # add 00290 skipto 1000 ip from 10.0.0.0/8 to 192.100.5.0/24 add 00300 divert 8668 ip from 10.0.0.0/8 to not 10.0.0.0/8 add 00301 divert 8668 ip from not 10.0.0.0/8 to 192.100.5.5 # 高い帯域のアクセスがルールセット全体を通過していくのを防ぐためのショート # カットルールを設定します。すでに確立されている TCP コネクションはそのまま # 通し、また外へ出るパケットも同様にします。ファイアウォールを通す # のは入力パケットだけにします。 # # 確立された TCP コネクションをそのまま通してしまうことは小さなセキュリティ # ホールになりますが、ファイアウォールの過剰な負荷を避ける意味で必要 # になることもあります。もし心配ならばこのルールを、アドレス偽装チェック # のうしろに移動することもできます。 # add 01000 allow tcp from any to any established add 01001 allow all from any to any out via fxp0 add 01001 allow all from any to any out via fxp1 add 01001 allow all from any to any out via fxp2 # アドレス偽装防止のルールです。これは、内部ネットワークのパケットを # どれくらい信頼するかによって変わってきます。fxp1 を経由するパケットは必ず、 # 10.0.1.x からのものでなければなりません。fxp2 を経由するもの # は 10.0.2.x からです。fxp0 を経由するものが LAN1 や LAN2 ブロックから # のものであることもあり得ません。ここでは 10.0.0.x を保護することはでき # ないので、ルータを適切に設定する必要があります。 # add 01500 deny all from not 10.0.1.0/24 in via fxp1 add 01500 deny all from not 10.0.2.0/24 in via fxp2 add 01501 deny all from 10.0.1.0/24 in via fxp0 add 01501 deny all from 10.0.2.0/24 in via fxp0 # この例のルールセットでは、内部ホスト間には何の制約も設けていません。 # 外部から見える LAN 上のホストであっても、内部 IP アドレスを使用する # 限りにおいてはそうです。これはセキュリティホールになる可能性があります # (外部から見えるホストに何かがあったらどうなるでしょうか ?)。これら # 3 つの LAN の間の通信を完全に制限したいのであれば、以下のふたつのルール # を削除してください。 # # LAN1 と LAN2 を孤立させて、しかし外部から見えるホスト間の自由なアクセスを # 許したければ、ルール 01010 だけを削除して、01011 は残して下さい。 # # (コメントアウトしてありますが、より制約の少ないファイアウォールにする # 場合はこれらを有効にしてください) #add 01010 allow all from 10.0.0.0/8 to 10.0.0.0/8 #add 01011 allow all from 192.100.5.0/24 to 192.100.5.0/24 # # 特定の LAN からは特定のサービスへのアクセスを許可する場合 # # より制約の強いファイアウォールを使う場合には、特定の LAN からファイア # ウォール上で動作している特定のサービスにアクセスできるようにすることに # なります。この例では、LAN1 がファイアウォール上で動いているファイル共有 # を必要とすると仮定します。もし、ルール 01010 が有効になっているような、 # 制約の緩いファイアウォールであればこれらのルールは不要です。 # add 01012 allow tcp from 10.0.1.0/8 to 10.0.1.1 139 add 01012 allow udp from 10.0.1.0/8 to 10.0.1.1 137,138 # 内部と外部の LAN の横断を許可する一般的なサービス # # DNS 参照、ntalk, ntp といった特定の UDP サービスは通過させます。 # 内部サービスはアドレス偽装不可の内部アドレス (10. ネット) を持つことにより # 保護されているので、これらのルールは外部から見える IP アドレスにバインド # されているサービスに対してのみ意味を持ちます。また、UDP フラグメントは # 許可する必要があります。そうしないと、フラグメントされるような大きな # UDP パケットはファイアウォールを通過できません。 # # DNS 参照に対する応答など、大きなポート番号を用いた一時的なサービスを # 行う必要があるかもしれません。この例ではそのようなポート番号を # 4000-65535 としています。外部から見える全マシンが一時ポートをこの # 外部から見えるポートにバインドするように、/etc/rc.conf の変数で設定 # しています (上の、rc.conf の例を参照してください)。 # add 02000 allow udp from any to any 4000-65535,domain,ntalk,ntp add 02500 allow udp from any to any frag # 同様のサービスを TCP についても許可します。ここでも、外部から見える # アドレスにバインドするサービスにのみ適用されます。また、この例では # 'auth' を通過させていますが、実際には外部から見えるポートでは identd # を動作させていません。これによって、auth 要求を受け取ったマシンは # TCP RESET を発行します。パケットを捨ててしまうと、ident 参照を行ってくる # サービスへの接続の遅延の原因となります。 # # TCP フラグメントを許可していないことに注意して下さい。UDP 以外では、 # 一般にフラグメントを許さないのです。TCP の、MTU ディスカバリプロトコル # が正しく動作して、TCP フラグメントが存在しないものと期待しています。 # add 03000 allow tcp from any to any http,https add 03000 allow tcp from any to any 4000-65535,ssh,smtp,domain,ntalk add 03000 allow tcp from any to any auth,pop3,ftp,ftp-data # いくつかのタイプの ICMP を通過させることは重要です。 # 一般形な ICMP タイプをここに列挙します。 # ICMP タイプ 3 を通過させることが重要であることに注意してください。 # # 0 エコーリプライ # 3 到達不能 # 4 始点抑制 (通常は許可されません) # 5 リダイレクト (通常は許可されません。危険です !) # 8 エコー # 11 時間超過 # 12 パラメータ問題 # 13 タイムスタンプ # 14 タイムスタンプリプライ # # 状況によってはタイプ 5 の ICMP リダイレクトパケットを許可しなければな # らない場合がありますが、そのような場合にはインターネットルータでそれが # 禁止されていることを確認して下さい。 # add 04000 allow icmp from any to any icmptypes 0,3,8,11,12,13,14 # ここまで通って残ったフラグメントのログをとります。役にたつかもしれ # ませんが、邪魔なだけかもしれません。最後の deny ルールは、カーネルの設定 # がどうであっても、ファイアウォールが包括的なものであることを保証する # ものです。 # add 05000 deny log ip from any to any frag add 06000 deny all from any to any .Ed .Sh 内部向け、外部向けサービスのポートバインディング マルチホームなホストで、サービスをどちらのアドレスにバインドするかという ことについて触れましたが、説明はしていません。複数の IP アドレスを持つホ ストでは、それぞれのサービスをすべての IP アドレスにバインドするのではな く、特定の IP アドレスやインタフェースにバインドすることが可能です。た とえばこの例のファイアウォールマシンには、インタフェースが 3 つあり、 その 1 つには 2 つの外部から見える IP アドレスがあるので、このマシンには 5 つの IP アドレス (10.0.0.1, 10.0.1.1, 10.0.2.1, 192.100.5.5, 192.100.5.1) があることになります。Windows の LAN セグメント (LAN1 とします) に対してファイル共有サービスを提供するのであれば、samba の 'bind interfaces' という設定項目で、LAN1 の IP アドレスにだけ samba をバインドできます。 こうすることで、他の LAN セグメントではこのファイル共有サービスを利用 できなくなります。また、LAN2 に UNIX エンジニアリングワークステーション があれば、nfsd を 10.0.2.1 にバインドするように設定することで NFS でも同様 のことができます。どのサービスをどのようにバインドするかはほとんどの場合 に指定できますし、またそれが指定できない場合には .Xr jail 8 を使うことによって、間接的にそれを行うこともできます。 .Sh 関連項目 .Xr ipnat 1 , .Xr dummynet 4 , .Xr ipnat 5 , .Xr rc.conf 5 , -.Xr smb.conf 5 [ /usr/ports/net/samba ] , -.Xr samba 7 [ /usr/ports/net/samba ] , +.Xr smb.conf 5 Pq Pa ports/net/samba , +.Xr samba 7 Pq Pa ports/net/samba , .Xr config 8 , .Xr ipfw 8 , .Xr jail 8 , .Xr natd 8 , .Xr nfsd 8 .Sh 関連文書 .Xr ipf 5 , .Xr ipf 8 , .Xr ipfstat 8 .Sh 歴史 .Nm マニュアルページは最初、 .An Matthew Dillon によって書かれ、2001 年 5 月に .Fx 4.3 ではじめて登場しました。 diff --git a/ja_JP.eucJP/man/man7/hier.7 b/ja_JP.eucJP/man/man7/hier.7 index 6997765249..1c88f0ae7a 100644 --- a/ja_JP.eucJP/man/man7/hier.7 +++ b/ja_JP.eucJP/man/man7/hier.7 @@ -1,823 +1,844 @@ .\" Copyright (c) 1990, 1993 .\" The Regents of the University of California. All rights reserved. .\" .\" Redistribution and use in source and binary forms, with or without .\" modification, are permitted provided that the following conditions .\" are met: .\" 1. Redistributions of source code must retain the above copyright .\" notice, this list of conditions and the following disclaimer. .\" 2. Redistributions in binary form must reproduce the above copyright .\" notice, this list of conditions and the following disclaimer in the .\" documentation and/or other materials provided with the distribution. .\" 3. All advertising materials mentioning features or use of this software .\" must display the following acknowledgement: .\" This product includes software developed by the University of .\" California, Berkeley and its contributors. .\" 4. Neither the name of the University nor the names of its contributors .\" may be used to endorse or promote products derived from this software .\" without specific prior written permission. .\" .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE .\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF .\" SUCH DAMAGE. .\" .\" @(#)hier.7 8.1 (Berkeley) 6/5/93 -.\" %FreeBSD: src/share/man/man7/hier.7,v 1.97 2004/04/14 16:06:19 harti Exp % +.\" %FreeBSD: src/share/man/man7/hier.7,v 1.103 2004/06/21 14:43:09 mpp Exp % .\" .\" $FreeBSD$ -.Dd June 5, 1993 +.Dd June 13, 2004 .Dt HIER 7 .Os .Sh 名称 .Nm hier .Nd ファイルシステムのレイアウト .Sh 解説 ファイルシステムの階層構成についての概略です。 -.Bl -tag -width "/stand/" +.Bl -tag -width ".Pa /libexec/" .It Pa / ファイルシステムのルートディレクトリ。 .It Pa /bin/ ユーザ用ユーティリティの基本的なもの。 シングルユーザ環境、マルチユーザ環境どちらでも使用する。 .It Pa /boot/ オペレーティングシステムのブートストラップ中に使用される プログラムと設定ファイル。 .Pp -.Bl -tag -width defaults/ -compact +.Bl -tag -width ".Pa defaults/" -compact .It Pa defaults/ デフォルトのブートストラップ用設定ファイル。 .Xr loader.conf 5 参照。 .It Pa kernel/ カーネルの pure な実行可能ファイル (ブート時にメモリに読み込まれる オペレーティングシステム)。 .It Pa modules/ サードパーティのロード可能なカーネルモジュール。 .Xr kldstat 8 参照。 .El .It Pa /cdrom/ CD-ROM ドライブのデフォルトマウントポイント .Xr ( sysinstall 8 が作成します)。 .It Pa /compat/ 通常は、 .Pa /usr/compat へのリンクです。 そうでない場合、 .Pa /usr/compat コメントがあてはまります。 .Xr ( sysinstall 8 が作成します)。 .It Pa /dev/ ブロックデバイスおよびキャラクタデバイスファイル。 .Pp .Bl -tag -width ".Pa fd/" -compact .It Pa fd/ ファイル記述子ファイル。 .Xr \&fd 4 参照。 .El .It Pa /dist/ .Xr sysinstall 8 が使用するマウントポイント。 .It Pa /etc/ システムの設定ファイル、およびスクリプト。 .Pp -.Bl -tag -width "disklabels/" -compact +.Bl -tag -width ".Pa defaults/" -compact .It Pa defaults/ デフォルトのシステム設定ファイル。 .Xr rc 8 参照。 .It Pa gnats/ gnats 設定ファイル。 .Xr send-pr 1 参照。 .It Pa isdn/ isdn4bsd の設定ファイル。 .Xr isdnd 8 参照。 .It Pa localtime ローカルタイムゾーン情報。 .Xr ctime 3 参照。 .It Pa mail/ sendmail の制御情報。 .It Pa mtree/ mtree 設定ファイル。 .Xr mtree 8 参照。 .It Pa namedb/ named 設定ファイル。 .Xr named 8 参照。 .It Pa pam.d/ プラグ可能認証モジュール (Pluggable Authentication Modules; PAM) ライブラリの設定ファイル。 .Xr pam 8 参照。 .It Pa periodic/ .Xr cron 8 により、毎日/毎週/毎月実行されるスクリプト。 .Xr periodic 8 参照。 .It Pa ppp/ .Xr ppp 8 ppp 設定ファイル。 .Xr ppp 8 参照。 .It Pa ssl/ OpenSSL 設定ファイル。 .El .It Pa /kernel カーネルの pure な実行可能ファイル (ブート時にメモリに読み込まれる オペレーティングシステム)。 .It Pa /modules/ ロード可能なカーネルモジュール。 .Xr kldstat 8 参照。 .It Pa /lib/ .Pa /bin と .Pa /sbin のバイナリに必要な、重要なシステムライブラリ。 +.Pp +.Bl -tag -width ".Pa geom/" -compact +.It Pa geom/ +.Xr geom 8 +ユーティリティ用のクラス特有のライブラリ。 +.El .It Pa /libexec/ .Pa /bin と .Pa /sbin のバイナリに必要な、重要なシステムユーティリティ。 .It Pa /mnt/ 通常、システム管理者が一時的なマウントポイントとして使用する 空のディレクトリ。 .It Pa /proc/ プロセスファイルシステム。 .Xr procfs 5 , .Xr mount_procfs 8 参照。 .It Pa /rescue/ 緊急回復時に使用される、静的にリンクされたプログラム群です。 .Xr rescue 8 を参照してください。 .It Pa /root/ root のホームディレクトリ。 .It Pa /sbin/ システムプログラム、および基本的な管理者用ユーティリティ。 シングルユーザ環境、マルチユーザ環境どちらでも使用する。 .It Pa /stand/ スタンドアロン環境で使用されるプログラム。 .It Pa /tmp/ システムリブートをまたがった永続性が保証されない、一時ファイル。 .It Pa /usr/ ユーザ用ユーティリティ、およびアプリケーションの大部分を含む。 .Pp -.Bl -tag -width "libdata/" -compact +.Bl -tag -width ".Pa libdata/" -compact .It Pa bin/ 一般的なユーティリティ、プログラミングツール、アプリケーション。 .It Pa compat/ Linux 等の他のオペレーティングシステムとのバイナリ互換性をサポートするために 必要なファイル .Xr ( sysinstall 8 が作成します)。 .It Pa games/ 有用でちょっとふざけたプログラム。 .It Pa include/ 標準 C 言語インクルードファイル。 .Pp -.Bl -tag -width "kerberos5/" -compact +.Bl -tag -width ".Pa kerberos5/" -compact +.It Pa altq/ +ALTQ 用の C 言語インクルードファイル。 .It Pa arpa/ インターネットサービスプロトコルのための C 言語インクルードファイル。 .It Pa bsnmp/ SNMP デーモン用の C 言語インクルードファイル。 .It Pa cam/ Common Access Methods Layer 用 C インクルードファイル。 -.Bl -tag -width "kerberos5/" -compact +.Bl -tag -width ".Pa kerberos5/" -compact .It Pa scsi/ CAM 上の SCSI デバイス。 .El .It Pa dev/ 様々な .Fx デバイスのプログラミング用の C インクルードファイル。 -.Bl -tag -width "kerberos5/" -compact +.Bl -tag -width ".Pa kerberos5/" -compact .It Pa ic/ ドライバ/バス独立なハードウェア回路を記述する、様々なヘッダファイル。 .It Pa ofw/ OpenFirmware サポート。 .It Pa ppbus/ パラレルポートバス。 .Xr ppbus 4 参照。 .It usb/ USB サブシステム。 .It Pa utopia/ ATM インタフェース用の物理チップドライバ。 .Xr utopia 4 参照。 .It Pa wi/ .Xr wi 4 WaveLAN ドライバ。 .El .It Pa fs/ -.Bl -tag -width "kerberos5/" -compact +.Bl -tag -width ".Pa kerberos5/" -compact .It Pa fdescfs/ プロセス毎のファイル記述子ファイルシステム。 .It Pa fifofs/ .St -p1003.1 FIFO ファイルシステム。 .It Pa msdosfs/ MS-DOS ファイルシステム。 .It Pa ntfs/ NTFS ファイルシステム。 .It Pa nullfs/ ループバックファイルシステム。 .It Pa nwfs/ NetWare ファイルシステム。 .It Pa portalfs/ ポータルファイルシステム。 .It Pa procfs/ プロセスファイルシステム。 .It Pa smbfs/ SMB/CIFS ファイルシステム。 .It Pa udf/ UDF ファイルシステム。 .It Pa umapfs/ uid/gid マッピングを変えるファイルシステム .It Pa unionfs ユニオンファイルシステム。 .El .It Pa g++/ GNU C++ 言語インクルードファイル。 -.Bl -tag -width "kerberos5/" -compact +.Bl -tag -width ".Pa kerberos5/" -compact .It Pa std/ GNU C++ 言語 libstdc++ インクルードファイル。 .El +.It Pa geom/ +GEOM フレームワーク。 +.Bl -tag -width ".Pa kerberos5/" -compact +.It Pa concat/ +CONCAT GEOM クラス。 +.It Pa gate/ +GATE GEOM クラス。 +.It Pa nop/ +NOP GEOM クラス。 +.It Pa stripe/ +STRIPE GEOM クラス。 +.El +.Pp .It Pa isc/ ISC ユーティリティライブラリ libisc インクルードファイル。 .It Pa isofs/ -.Bl -tag -width "kerberos5/" -compact +.Bl -tag -width ".Pa kerberos5/" -compact .It Pa cd9660/ iso9660 形式ファイルシステム。 .El .It Pa libmilter/ libmilter 用の C インクルードファイルであり、 .Xr sendmail 8 メールフィルタ の API です。 .It Pa machine/ マシン固有機能の C 言語インクルードファイル。 .It Pa net/ その他のネットワーク機能用 C 言語インクルードファイル。 .It Pa netatalk/ Appletalk プロトコル。 .It Pa netatm/ ATM のインクルードファイル。 .Xr atm 8 参照。 .It Pa netinet/ インターネット標準プロトコル用 C 言語インクルードファイル。 .Xr inet 4 参照。 .It Pa netinet6/ インターネットプロトコルバージョン 6 用の C インクルードファイル。 .Xr inet6 4 参照。 .It Pa netipx/ IPX/SPX プロトコルスタック。 .It Pa netkey/ カーネルの鍵管理サービス。 .It Pa netnatm/ NATM インクルードファイル。 .Xr natm 4 参照。 .It Pa netsmb/ SMB/CIFS リクエスタ。 .It Pa nfs/ NFS (Network File System) 用 C 言語インクルードファイル。 .It Pa objc/ Objective C のインクルードファイル。 .It Pa posix4/ POSIX リアルタイム拡張のインクルードファイル。 .Xr p1003_1b 9 参照。 .It Pa openssl/ OpenSSL (Cryptography/SSL ツールキットの) ヘッダ。 .It Pa pccard/ PC-CARD コントローラ。 .It Pa protocols/ Berkeley サービスプロトコル用 C 言語インクルードファイル。 .It Pa readline/ ユーザからの一行入力機能 (編集機能付き)。 .Xr readline 3 参照。 .It Pa rpc/ リモート手続き呼び出し。 .Xr rpc 3 参照。 .It Pa rpcsvc/ RPC サービス構造の定義。 .Xr rpc 3 参照。 .It Pa security/ PAM。 .Xr pam 8 参照。 .It Pa sys/ システム用 C 言語インクルードファイル (カーネルデータ構造)。 .\" .It Pa tcl/ .\" Tcl 言語。 .\" .Xr Tcl n .\" 参照。 -.\" .Bl -tag -width "kerberos5/" -compact +.\" .Bl -tag -width ".Pa kerberos5/" -compact .\" .It Pa generic/ .\" ??? .\" .It Pa unix/ .\" ??? .\" .El .It Pa ufs/ UFS (U-word File System) 用 C 言語インクルードファイル。 -.Bl -tag -width "kerberos5/" -compact +.Bl -tag -width ".Pa kerberos5/" -compact .It Pa ffs/ Fast filesystem。 .It Pa ufs/ UFS ファイルシステム。 .El .It Pa vm/ 仮想記憶。 .Xr vmstat 8 参照。 .El .Pp .It Pa lib/ アーカイブライブラリ。 .Bl -tag -width Fl -compact .It Pa aout/ a.out アーカイブライブラリ。 .It Pa compat/ 互換性維持用の共有ライブラリ。 .Bl -tag -width Fl -compact .It Pa aout/ a.out 後方互換ライブラリ。 .El .El .Pp .It Pa libdata/ その他のユーティリティデータファイル。 .Bl -tag -width Fl -compact .It Pa gcc/ .Xr gcc 1 の設定用データ .It Pa ldscripts/ リンカスクリプト。 .Xr ld 1 参照。 .It Pa lint/ さまざまな lint 用ライブラリ (事前に構築されている)。 .Xr lint 1 参照。 .El .Pp .It Pa libexec/ システムデーモンおよびシステムユーティリティ。 (他のプログラムから実行されるもの)。 .Bl -tag -width Fl -compact .It Pa aout/ a.out 実行形式を操作するユーティリティ。 .It Pa elf/ ELF 実行形式を操作するユーティリティ。 .It Pa lpr/ LP プリントシステムのユーティリティとフィルタ。 .Xr lpr 1 参照。 .It Pa sendmail/ .Xr sendmail 8 バイナリ。 .Xr mailwrapper 8 参照。 .It Pa sm.bin/ .Xr sendmail 8 用制限付きシェル。 .Xr smrsh 8 参照。 .El .Pp .It Pa local/ ローカルの実行可能ファイル、ライブラリなど。 .Fx ports フレームワークのデフォルトのインストール先としても使用されます。 local/以下では、 .Nm で /usr に関して 記述された一般的な配置が使用されます。 例外は、man ディレクトリ (local/share/ の下ではなく local/ の直下に存在)、 ports のドキュメント (share/doc// に置かれます)、 /usr/local/etc (/etc の模倣) です。 .It Pa obj/ アーキテクチャ依存のターゲットツリー。 /usr/src ツリーを構築することで作成される。 .It Pa ports/ .Fx ports コレクション (オプション扱い)。 .It Pa sbin/ (ユーザによって実行される) システムデーモン、およびシステムユーティリティ。 .It Pa share/ アーキテクチャに依存しないファイル。 .Pp -.Bl -tag -width "calendar/" -compact +.Bl -tag -width ".Pa calendar/" -compact .It Pa calendar/ 事前に組み立てられた calendar ファイルいろいろ。 .Xr calendar 1 参照。 .It Pa dict/ 単語リスト。 .Xr look 1 参照。 .Pp .Bl -tag -width Fl -compact .It Pa freebsd .Fx 固有の術語、固有の名前、隠語。 .It Pa words 一般の単語 .It Pa web2 Webster's 2nd International からの単語 .It Pa papers/ リファレンスデータベース。 .Xr refer 1 参照。 .El .Pp .It Pa doc/ その他の文書。 ( .Tn USENIX association から入手できる) .Bx マニュアルのほとんどのソース。 .Bl -tag -width Fl -compact .It Pa FAQ/ しばしば行なわれる質問とその答え (Frequently Asked Questions)。 .It Pa IPv6/ IPv6 の実装に関する注。 .It Pa bind/ BIND (Berkeley Internet Name Domain) に属する文書。 .It Pa es/ /usr/share/doc 中の文書のスペイン語への翻訳。 .It Pa handbook/ .Fx ハンドブック .It Pa ja/ /usr/share/doc 中の文書の日本語への翻訳。 .It Pa ncurses/ ncurses に属する HTML 文書。 .Xr ncurses 3X 参照 .It Pa ntp/ Network Time Protocol に属する HTML 文書。 .It Pa papers/ UNIX 関連の論文 .It Pa psd/ UNIX プログラマ用補助文書 .It Pa ru/ /usr/share/doc 中の文書のロシア語への翻訳。 .It Pa smm/ UNIX システム管理者用マニュアル .It Pa tutorials/ .Fx チュートリアル。 .It Pa usd/ UNIX ユーザ用補助文書 .It Pa zh/ /usr/share/doc 中の文書の中国語への翻訳。 .El .Pp .It Pa examples/ 一般ユーザやプログラマ向けのさまざまな用例。 .It Pa games/ 各種のゲームで使用される ASCII テキストファイル。 .It Pa groff_font/ デバイス名ごとに用意されたデバイス記述ファイル。 .It Pa info/ GNU Info ハイパーテキストシステム。 .It Pa isdn/ ISDN。 .It Pa locale/ ローカル化関係のファイル。 .Xr setlocale 3 参照。 .It Pa man/ マニュアルページ。 .It Pa me/ me マクロパッケージで使用するマクロ。 .Xr me 7 参照。 .It Pa misc/ その他システム全体の ASCII テキストファイル。 .Bl -tag -width Fl -compact .It Pa fonts/ ??? .It Pa pcvtfonts/ pcvt フォント。 .Xr pcvt 4 参照。 .It Pa termcap 端末の特性を記述するデータベース。 .Xr termcap 5 参照。 .El .It Pa mk/ make 用テンプレート。 .Xr make 1 参照。 .It Pa nls/ 各国語サポート (National Language Support) ファイル。 .Xr mklocale 1 参照。 .It Pa pcvt/ pcvt の文書とその他の例。 .Xr pcvt 4 参照。 .It Pa security/ .Xr mac_lomac 4 等のセキュリティポリシ用のデータファイル。 .It Pa sendmail/ .Xr sendmail 8 の設定ファイル。 .It Pa skel/ 新しいアカウントのための . (ドット) ファイルの例。 .It Pa snmp/ SNMP デーモン用の MIB やサンプルファイル、ツリー定義。 .Bl -tag -width Fl -compact .It Pa defs/ .Xr gensnmptree 1 とともに使用されるツリー定義ファイル。 .It Pa mibs/ MIB ファイル。 .El .It Pa syscons/ syscons が使用するファイル。 .Xr syscons 4 参照。 -.Bl -tag -width "scrnmaps/xx" -compact +.Bl -tag -width ".Pa scrnmaps/" -compact .It Pa fonts/ コンソールフォント。 .Xr vidcontrol 1 と .Xr vidfont 1 参照。 .It Pa keymaps/ コンソールキーボードマップ。 .Xr kbdcontrol 1 と .Xr kbdmap 1 参照。 .It Pa scrnmaps/ コンソールスクリーンマップ。 .El .It Pa tabset/ 各種端末用タブ記述ファイル。termcap ファイルの中で使用される。 .Xr termcap 5 参照。 .It Pa tmac/ テキスト処理マクロ。 .Xr nroff 1 および .Xr troff 1 参照。 .It Pa vi/ .Xr vi 1 のローカライズサポートとユーティリティ。 .It Pa zoneinfo/ タイムゾーン設定情報。 .Xr tzfile 5 参照。 .El .It Pa src/ .Bx とサードパーティとローカルのソースファイル。 .Pp -.Bl -tag -width "kerberos5/" -compact +.Bl -tag -width ".Pa kerberos5/" -compact .It Pa bin/ /bin 内のファイルのソース。 .It Pa contrib/ 寄贈されたソフトウェアのソース。 .It Pa crypto/ 寄贈された暗号化ソフトウェアのソース。 .It Pa etc/ /etc 内のファイルのソース。 .It Pa games/ /usr/games 内のファイルのソース。 .It Pa gnu/ GNU General Public License で保護されたユーティリティ。 .It Pa include/ /usr/include 内のファイルのソース。 .It Pa kerberos5/ Kerberos version 5 のビルドインフラストラクチャ。 .It Pa lib/ /usr/lib 内のファイルのソース。 .It Pa libexec/ /usr/libexec 内のファイルのソース。 .It Pa release/ .Fx のリリースを生成するために必要なファイル。 .It Pa sbin/ /sbin 内のファイルのソース。 .It Pa secure/ /usr/src/crypto 中のファイル用のビルドディレクトリ。 .It Pa share/ /usr/share 内のファイルのソース。 .It Pa sys/ カーネルのソースファイル。 .It Pa tools/ .Fx のメンテナンスとテストに使用するツール。 .It Pa usr.bin/ /usr/bin 内のファイルのソース。 .It Pa usr.sbin/ /usr/sbin 内のファイルのソース。 .El .Pp .It Pa X11R6/ X11R6 配布パッケージの実行可能形式ファイル、ライブラリなど (オプション扱い)。 -.Bl -tag -width "include/" -compact +.Bl -tag -width ".Pa include/" -compact .It Pa bin/ X11R6 のバイナリ (サーバ、ユーティリティ、ローカルな packages/ports)。 .It Pa etc/ X11R6 の設定ファイルとスクリプト。 .It Pa include/ X11R6 のインクルードファイル。 .It Pa lib/ X11R6 のライブラリ。 .It Pa man/ X11R6 のマニュアルファイル。 .It Pa share/ アーキテクチャ独立なファイル。 .El .El .It Pa /var/ さまざまな用途のログファイル、一時ファイル、遷移的ファイル、 スプールファイル。 .Pp -.Bl -tag -width "preserve/" -compact +.Bl -tag -width ".Pa preserve/" -compact .It Pa account/ システムアカウンティングファイル。 .Pp .Bl -tag -width Fl -compact .It Pa acct 実行アカウントファイル。 .Xr acct 5 参照。 .El .Pp .It Pa at/ 指定した時間に動くコマンドのスケジュールファイル。 .Xr \&at 1 参照。 -.Bl -tag -width "preserve/" -compact +.Bl -tag -width ".Pa preserve/" -compact .It Pa jobs/ ジョブファイルを含むディレクトリ。 .It Pa spool/ 出力スプールファイルを含むディレクトリ。 .El .Pp .It Pa backups/ さまざまなバックアップファイル。 .It Pa crash/ カーネルクラッシュダンプを保存するデフォルトのディレクトリ。 .Xr crash 8 と .Xr savecore 8 参照。 .It Pa cron/ cron が使用するファイル。 .Xr cron 8 参照。 -.Bl -tag -width "preserve/" -compact +.Bl -tag -width ".Pa preserve/" -compact .It Pa tabs/ crontab ファイル。 .Xr crontab 5 参照。 .El .Pp .It Pa db/ システム固有のさまざまなデータベースファイル。自動生成される。 .It Pa empty/ 特別に空のディレクトリが必要なプログラムによって使用される、空のディレクトリ。 例えば、特権分離のために .Xr sshd 8 が使用します。 .Xr sshd 8 参照 .It Pa games/ さまざまなゲームのステータスおよびスコアファイル。 .It Pa heimdal/ Kerberos サーバデータベース。 .Xr kdc 8 参照。 .It Pa log/ さまざまなシステムログファイル。 .Pp .Bl -tag -width Fl -compact .It Pa wtmp login/logout ログ。 .Xr wtmp 5 参照。 .El .Pp .It Pa mail/ ユーザのメールボックスファイル。 .It Pa msgs/ システムメッセージのデータベース。 .Xr msgs 1 参照。 .It Pa preserve/ エディタの不慮の死の際に保存されるファイルを一時的に安置するディレクトリ。 .Xr \&ex 1 参照。 .It Pa quotas/ ファイルシステムのクォータ情報のファイル。 .It Pa run/ ブートされてからのシステムについての各種情報を記述した システム情報ファイル。 .Pp .Bl -tag -width Fl -compact .It Pa named/ .Dq bind ユーザが書き込み可能です。 .Xr named 8 参照。 .It Pa ppp/ コマンドの接続ソケット用に、 .Dq network グループが書き込み可能です。 .Xr ppp 8 参照。 .It Pa utmp 現在のユーザについてのデータベース。 .Xr utmp 5 参照。 .El .Pp .It Pa rwho/ rwho データファイル。 .Xr rwhod 8 , .Xr rwho 1 , .Xr ruptime 1 参照。 .It Pa spool/ さまざまなプリンタ、メールシステムのスプールディレクトリ。 .Pp .Bl -tag -width Fl -compact .It Pa ftp/ 一般に ~ftp となる部分。anonymous ftp のルートディレクトリ。 .It Pa mqueue/ 配送されていないメールのキュー。 .Xr sendmail 8 参照。 .It Pa output/ ラインプリンタ用スプールディレクトリ。 .El .Pp .It Pa tmp/ システムリブートをまたがって保持される、一時ファイル。 .Bl -tag -width Fl -compact .It Pa vi.recover/ vi のリカバリファイルを格納しておくディレクトリ。 .El .It Pa yp NIS マップ。 .El .El .Sh 注 このマニュアルページはデフォルトの .Fx ファイルシステムレイアウトを 記述しており、 各システムの実際の階層構造はシステム管理者の裁量に委ねられています。 よく維持管理されたインストールにおいては、 カスタマイズされた本ドキュメントが付属するでしょう。 .Sh 関連項目 .Xr apropos 1 , .Xr find 1 , .Xr finger 1 , .Xr grep 1 , .Xr ls 1 , .Xr whatis 1 , .Xr whereis 1 , .Xr which 1 , .Xr fsck 8 .Sh 歴史 .Nm マニュアルページは .At v7 で登場しました。 .\"ZZZ: 3.0-RELEASE compliant by N. Kumagai 98-12-26 diff --git a/ja_JP.eucJP/man/man7/ports.7 b/ja_JP.eucJP/man/man7/ports.7 index ec3ee3f3e8..7070ccd84f 100644 --- a/ja_JP.eucJP/man/man7/ports.7 +++ b/ja_JP.eucJP/man/man7/ports.7 @@ -1,417 +1,487 @@ .\" .\" Copyright (c) 1997 David E. O'Brien .\" .\" All rights reserved. .\" .\" Redistribution and use in source and binary forms, with or without .\" modification, are permitted provided that the following conditions .\" are met: .\" 1. Redistributions of source code must retain the above copyright .\" notice, this list of conditions and the following disclaimer. .\" 2. Redistributions in binary form must reproduce the above copyright .\" notice, this list of conditions and the following disclaimer in the .\" documentation and/or other materials provided with the distribution. .\" .\" THIS SOFTWARE IS PROVIDED BY THE DEVELOPERS ``AS IS'' AND ANY EXPRESS OR .\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES .\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. .\" IN NO EVENT SHALL THE DEVELOPERS BE LIABLE FOR ANY DIRECT, INDIRECT, .\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT .\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, .\" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY .\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT .\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF .\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. .\" -.\" %FreeBSD: src/share/man/man7/ports.7,v 1.41 2003/11/12 08:26:08 brueffer Exp % +.\" %FreeBSD: src/share/man/man7/ports.7,v 1.45 2004/06/16 07:29:21 krion Exp % .\" .\" $FreeBSD$ -.Dd January 25, 1998 +.Dd June 16, 2004 .Dt PORTS 7 .Os .Sh 名称 .Nm ports .Nd 寄贈されたアプリケーション .Sh 解説 .Fx ports コレクション によって、ユーザや管理者は簡単にアプリケーションをインストールする ことができます。 .Em port はそれぞれ、オリジナルのソースコードを .Bx 上でコンパイルして実行 させるために必要なパッチのすべてを含んでいます。アプリケーションの コンパイルは、 port のディレクトリで .Nm make Cm build と入力するだけで簡単にできます。 port の .Pa Makefile は、ローカルディスクからもしくは FTP を使って、自動的にアプリケーションの ソースコードを取得 .Pq fetch して、自分のシステムでそれを展開して、 パッチを当て、コンパイルします。すべてが順調に進んだ場合、 .Nm make Cm install を実行することにより、アプリケーションがインストールされます。 .Pp インストールされたシステムよりも新しい ports を、 .Fx リポジトリからダウンロードして使用できます。 ただし、最初に適切な .Dq "アップグレードキット" を .Pa http://www.FreeBSD.org/ports/ から取得してインストールすることが重要です! 新しい ports をダウンロードするときには、 .Xr portcheckout 1 スクリプト (もちろんこれも port です!) が役立つでしょう。 .Pp port の利用に関してさらに情報が必要ならば、 .%B "The FreeBSD Handbook" の .Dq "Packages and Ports" (原文 .Pa file:/usr/share/doc/en_US.ISO8859-1/books/handbook/ports.html または、 .Pa http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/ports.html 、和文 .Pa file:/usr/share/doc/ja_JP.eucJP/books/handbook/ports.html または、 .Pa http://www.FreeBSD.org/doc/ja_JP.eucJP/books/handbook/ports.html ) に目を通して下さい。 port を新規に作成するための情報については、 .%B "The Porter's Handbook" .Pa ( file:/usr/share/doc/en_US.ISO8859-1/books/porters-handbook/index.html または、 .Pa http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/porters-handbook/ ) に目を通して下さい。 .Sh ターゲット ターゲットのいくつかは、サブディレクトリを再帰的に make して行きます。 これにより、例えば、 .Dq Li biology の port すべてをインストールすることが できます。再帰的に make を行なうターゲットは、 .Cm build , checksum , clean , configure , .Cm depends , extract , fetch , install , .Cm package です。 .Pp 次のターゲットは、それぞれすぐ手前のターゲットによって順に自動的に 実行されます。すなわち、 .Cm build は、 (必要があれば、) .Cm install によって実行されます。以下のターゲットそれぞれについて、同様のルールが .Cm fetch まで順次適用されます。 通常は、ターゲットとして、 .Cm install を指定するだけでよいはずです。 .Bl -tag -width ".Cm configure" +.It Cm config +.Xr dialog 1 +を使用して、この port の +.Va OPTIONS +を設定します。 .It Ar fetch .Va MASTER_SITES と .Va PATCH_SITES でリストされたサイトから、 この port を構築するために必要なファイルすべてを取得 .Pq fetch します。 .Va FETCH_CMD と .Va MASTER_SITE_OVERRIDE とを参照して下さい。 .It Cm checksum 取得した distfile のチェックサムが port で動作確認されたものと 一致するかどうかを検証します。 .Va NO_CHECKSUM を定義することで、このステップを飛ばすことができます。 .It Cm depends 現在の port と依存関係にある port をインストール (もしくは、必要がある場合のみコンパイル) します。ターゲット .Cm extract もしくは .Cm fetch により呼び出された場合、 .Cm fetch-depends , .Cm build-depends などとしてひとつずつ実行されます。 .Va NO_DEPENDS を定義することで、このステップを飛ばすことができます。 .It Cm extract distfile を作業用ディレクトリに展開します。 .It Cm patch port に必要なパッチすべてを適用します。 .It Cm configure port を構成 (configure) します。port によっては、この段階で質問して くるものもあります。 .Va INTERACTIVE と .Va BATCH を参照して下さい。 .It Cm build port を構築します。これはターゲット .Cm all を呼び出すことと同じです。 .It Cm install port をインストールし、この port をインストールしたことを package (訳注: .Fx の package system におけるパッケージを指す場合にこう表記します) システムに登録します。このターゲットは、実際に必要なこと すべてを行なってくれます。 .El .Pp 次のターゲットは、通常のインストールプロセスでは実行されません。 .Bl -tag -width ".Cm fetch-recursive" +.It Cm showconfig +この port の +.Va OPTIONS +設定を表示します。 +.It Cm rmconfig +この port の +.Va OPTIONS +設定を削除します。 .It Cm fetch-list -この port を構築するために取得が必要なファイルのリストを表示します。 +この port を構築するために取得されるファイルのリストを表示します。 .It Cm fetch-recursive この port と依存するものの distfile を取得します。 .It Cm fetch-recursive-list .Cm fetch-recursive で取得されるファイルのリストを表示します。 .It Cm pretty-print-run-depends-list , pretty-print-build-depends-list コンパイル依存 port リストと実行依存 port リストを表示します。 また、これらの依存 port リストが依存する port についても表示します。 .It Cm clean 展開されたソースコードを削除します。 .Va NOCLEANDEPENDS を定義しておかない限り、削除は依存関係にある port に再帰的に適用されます。 .It Cm distclean その port の distfile を削除し、 .Cm clean ターゲットを実行します。 .Va NOCLEANDEPENDS を定義しておかない限り、 .Cm clean の部分は依存関係にある port に再帰的に適用されます。しかし、 .Cm distclean の部分は決して再帰的に適用されません (この挙動はひょっとするとバグかもしれません)。 .It Cm reinstall .Cm deinstall を使用すべきところでうっかり .Xr pkg_delete 1 を使ってしまった場合、このターゲットを使って port を復活させて下さい。 .It Cm deinstall .Xr pkg_delete 1 と同様に、インストールした port をシステムから削除します。 .It Cm deinstall-all 同じ .Va PKGORIGIN のインストール済 ports すべてを、システムから削除します。 .It Cm package この port のバイナリ package を作成します。まだインストールされて いなかった場合、その port をインストールします。 package は .Pa .tbz ファイルであり、その port を他のマシンに .Xr pkg_add 1 を使ってインストールする際に使用することができます。 .Va PACKAGES で指定されたディレクトリが存在しなければ、package はカレントディレクトリに 置かれます。 .Va PKGREPOSITORY と .Va PKGFILE とを参照して下さい。 .It Cm package-recursive .Cm package と似ていますが、依存する各 port に対しても package を作成します。 .It Cm readmes その port の .Pa README.html ファイルを生成します。 これは、あなたのシステム上の全 port をウェブでブラウズできるようにするために、 .Pa /usr/ports から使用可能です。 .It Cm search .Pa INDEX ファイルを、 .Cm key -(port の名前、コメント、依存を調べます) または +(port の名前、コメント、依存関係を調べます)、 .Cm name -(port の名前のみを調べます) の +(port の名前のみを調べます)、 +.Va path +(port のパスを調べます)、 +.Va info +(port の情報を調べます)、 +.Va maint +(port のメンテナを調べます)、 +.Va cat +(port のカテゴリを調べます)、 +.Va bdeps +(port の構築依存関係を調べます)、 +.Va rdeps +(port の実行依存関係を調べます) などの .Xr make 1 -変数で指定されたパターンで検索します。 +変数や、その逆の意味をもつ +.Va xname , xkey +などで指定されたパターンで検索します。 例えば、次のように入力します: .Pp .Dl "cd /usr/ports && make search name=query" .Pp すると、全 ports のうち名前が .Dq Li query に適合するものが探されます。 結果には、適合する ports のパス、コメント、メンテナ、構築依存、実行依存が 含まれます。 +.Bd -literal -offset indent +cd /usr/ports && make search name=pear- \e + xbdeps=apache +.Ed +.Pp +名前に +.Dq Li pear- +を含み、apache が構築依存関係に含まれていないすべての ports を検索します。 +.Bd -literal -offset indent +cd /usr/ports && make search name=pear- \e + xname='ht(tp|ml)' +.Ed +.Pp +名前に +.Dq Li pear- +を含みますが、 +.Dq Li html +や +.Dq Li http +は含まないすべての ports を検索します。 +.Bd -literal -offset indent +make search key=apache display=name,path,info keylim=1 +.Ed +.Pp +.Dq Li apache +が名前、パス、情報フィールドのどれかに含まれるすべての ports を検索します。 +他のレコードは無視します。 +.It Cm describe +.Pa INDEX +ファイル中で使用される、各 port の 1 行説明を生成します。 .It Cm index .Pa /usr/ports/INDEX を作成します。 これは、 .Cm pretty-print-* および .Cm search のターゲットで使用されます。 -CVS リポジトリのマスタ -.Pa INDEX -ファイルは定期的に更新されますが、 .Cm index ターゲットを実行することで、 .Pa INDEX ファイルが ports ツリーに対して最新であることを保証します。 +.It Cm fetchindex +.Fx +クラスタから +.Pa INDEX +ファイルを取得します。 .El .Sh 環境変数 これら環境変数のすべてを変更することができます。 .Bl -tag -width ".Va MASTER_SITES" .It Va PORTSDIR port ツリーの場所を指定します。これは .Fx と .Ox では .Pa /usr/ports で、 .Nx では .Pa /usr/pkgsrc です。 .It Va WRKDIRPREFIX 一時ファイルを作成する場所です。 .Va PORTSDIR が読み込み専用の場合 (おそらく CD-ROM をマウントした場合) 有用です。 .It Va DISTDIR distfile を探す場所であり、取得した distfile を置く場所です。通常は .Va PORTSDIR の下の .Pa distfiles/ です。 .It Va PACKAGES ターゲット .Cm package でのみ使用されます。 package ツリーのベースディレクトリです。通常は、 .Va PORTSDIR の下の .Pa packages/ です。 このディレクトリが存在する場合、package ツリーが (部分的に) 構築されます。 このディレクトリは存在する必要はありません。存在しない場合、package は カレントディレクトリに置かれます。もしくは、以下のいずれか一方を定義 することができます。 .Bl -tag -width ".Va PKGREPOSITORY" .It Va PKGREPOSITORY package を置くディレクトリ。 .It Va PKGFILE その package のフルパス。 .El .It Va PREFIX 一般に、成果物をどこにインストールするかを指定します (通常は .Pa /usr/local か、 .Pa /usr/X11R6 です)。 .It Va MASTER_SITES ローカルマシンに配布ファイルが存在しない場合、最初に取得しに行くサイトです。 .It Va PATCH_SITES ローカルマシンにパッチファイルが存在しない場合、最初に取得しに行くサイトです。 .It Va MASTER_SITE_FREEBSD これが設定されている場合、すべてのファイルを .Fx のマスタサイトに 取りに行きます。 .It Va MASTER_SITE_OVERRIDE すべてのファイルとパッチについて、まずこれらのサイトに行って取得を試みます。 .It Va NOCLEANDEPENDS これが定義されている場合、依存関係にある port に対して .Cm clean を再帰的に適用しません。 .It Va FETCH_CMD ファイルを取得する際に使用するコマンドです。通常は .Xr fetch 1 です。 .It Va FORCE_PKG_REGISTER これが設定されている場合、既にシステムに存在する package 登録情報を 上書きします。 .It Va MOTIFLIB .Pa libXm. Ns Brq Pa a , Ns Pa so の位置を指定します。 .It Va INTERACTIVE これが設定されている場合、ユーザ入力が必要な port にのみ動作します。 .It Va BATCH これが設定されている場合、100% 自動的にインストールできる port にのみ 動作します。 +.It Va OPTIONS +定義されている場合、この port が受け付ける +.Va WITH_* +オプションのリストです。 +.Em 注意 : +.Va OPTIONS +が実際にちゃんと動作するには、 +.Va WITH_* +変数をテストし始める前に +.Pa bsd.port.pre.mk +をインクルードする必要があります。 .El .Sh 関連ファイル .Bl -tag -width ".Pa /usr/ports/Mk/bsd.port.mk" -compact .It Pa /usr/ports デフォルトの port ディレクトリ .No ( Fx と .Ox ) 。 .It Pa /usr/pkgsrc デフォルトの port ディレクトリ .Po .Nx .Pc 。 .It Pa /usr/ports/Mk/bsd.port.mk .\"kuma: big Kahuna というのはモアイのような巨大石のものらしい。 .\"kuma: だれか教えて?! ご本尊様であらしゃいます。 .El .Sh 関連項目 .Xr make 1 , .Xr pkg_add 1 , .Xr pkg_create 1 , .Xr pkg_delete 1 , .Xr pkg_info 1 , .Xr pkg_version 1 .Pp 次に示すものは ports コレクションの一部です: .Pp .Xr pib 1 , .Xr portcheckout 1 , .Xr portlint 1 .Rs .%B "The FreeBSD Handbook" .Re .Pp .Pa http://www.FreeBSD.org/ports (port すべてが検索可能なインデックス) .Sh 作者 .An -nosplit このマニュアルページは、もともとは .An David O'Brien によるものです。 .Sh 歴史 ports コレクション は、 .Fx 1.0 で登場しました。 その後、 .Nx と .Ox にも広まりました。 .Sh バグ port に関する文書が 4 か所に分散されてしまっています。 .Pa /usr/ports/Mk/bsd.port.mk と .%B "The Porter's Handbook" と .%B "The FreeBSD Handbook" の .Dq "Packages and Ports" セクションと、 このマニュアルページ の 4 つです。 .Pp このマニュアルページは長過ぎです。 .\"ZZZ: 3.0-RELEASE compliant by N. Kumagai, 98-12-26 diff --git a/ja_JP.eucJP/man/man7/release.7 b/ja_JP.eucJP/man/man7/release.7 index 25cb0d05d1..14c0ee31dd 100644 --- a/ja_JP.eucJP/man/man7/release.7 +++ b/ja_JP.eucJP/man/man7/release.7 @@ -1,505 +1,527 @@ .\" Copyright (c) 2002 Murray Stokely .\" All rights reserved. .\" .\" Redistribution and use in source and binary forms, with or without .\" modification, are permitted provided that the following conditions .\" are met: .\" 1. Redistributions of source code must retain the above copyright .\" notice, this list of conditions and the following disclaimer. .\" 2. Redistributions in binary form must reproduce the above copyright .\" notice, this list of conditions and the following disclaimer in the .\" documentation and/or other materials provided with the distribution. .\" .\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE .\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF .\" SUCH DAMAGE. .\" -.\" %FreeBSD: src/share/man/man7/release.7,v 1.35 2004/01/28 21:07:36 jhb Exp % +.\" %FreeBSD: src/share/man/man7/release.7,v 1.38 2004/06/21 14:43:09 mpp Exp % .\" $FreeBSD$ .\" .\" WORD: clean system まっさらのシステム[release.7] .\" .Dd March 12, 2002 .Dt RELEASE 7 .Os .Sh 名称 .Nm release .Nd "リリース構築基盤" .Sh 解説 .Fx は、ユーザが .Fx オペレーティングシステムのリリース全てを作成できるような完全な構築環境を 提供しています。 リリースを構築するために必要なツールの全ては、 CVS リポジトリ中の .Pa src/release に揃っています。 実のところ、 CD-ROM を焼く際に使える ISO イメージ、インストール用フロッピ、 FTP インストール用ディレクトリの生成をはじめとして、完全なリリースを コマンド一発で構築できます。 このコマンドは、 .Dq Li "make release" と、うまい名前が付けられています。 .Pp リリースを構築する前に、 .Xr build 7 の内容によく馴染んでおいてください。 また、 .Dq Li "make world" によるソースからのシステムアップグレードの経験も必須です。 リリース構築プロセスは、 .Dq Li "make buildworld" の結果を .Pa /usr/obj に置いておくことを要求します。 完全なシステムのためのオブジェクトファイルを、まっさらの .Xr chroot 8 環境にインストールできるようにするために、これが必要となります。 リリースを進めるには、 .Xr md 4 (メモリディスク) デバイスドライバがカーネルに存在する (コンパイル済み、またはモジュールとして利用可能のいずれも可) ことも必要です。 .Pp この文書は、ソースコード管理、品質管理など、 リリースエンジニアリングプロセスに関するその他の側面は扱いません。 .Sh ターゲット リリース用 makefile .Pq Pa src/release/Makefile は、かなり難解です。 ほとんどの場合、 .Cm release ターゲットのことを考えるだけで済むと思います。 .\" XXX: Some sort of introduction to this list? All the others have one. .Bl -tag -width ".Cm rerelease" .It Cm release .Dq Li "make installworld" を用いて、ファイルシステムの .Xr chroot 8 環境にまっさらのシステムをインストールします。 指定したバージョンのソースコードをチェックアウトし、 .Dq Li "make world" を用いて、まっさらの環境に完全なシステムを再構築します。 そのあとに、ディストリビューション別のパッケージング(まとめ上げ)、 インストール用フロッピディスクの構築、リリース文書の構築などの 細かいステップが続きます。 .Pp このターゲットは、 .Va kern.securelevel sysctl を \-1 (デフォルト) とした root で構築する必要があります。 .It Cm rerelease このターゲットは、リリース構築作業の結果を手で修正し、前の .Dq Li "make release" の中間結果を使い、最小のステップ数でリリースを再構築することを 想定したものです。 .It Cm floppies 新規のブートおよび fixit フロッピの組を作成します。 .Cm release.5 , .Cm release.9 , .Cm floppies.1 , .Cm floppies.2 , .Cm floppies.3 ターゲットを呼び、直前の .Dq Li "make release" のフロッピイメージを再作成します。 このターゲットは、カスタムブートフロッピの作成にもっとも良く使用されます。 .El .Pp .Dq Li "make release" により呼び出されるターゲットは次のとおりです。 .Bl -tag -width ".Cm fetch-distfiles" .It Cm release.1 ディレクトリ .Pa ${CHROOTDIR}/R をまっさらにし、 .Xr mtree 8 を用いてシステム用のディレクトリ階層を構築します。 .It Cm release.2 システムをディストリビューション用ディレクトリにインストールします。 .It Cm release.3 .Dq base ディストリビューションに対し、 非 crypto バージョンのいくつかのツールをビルドおよびインストールします。 .It Cm release.4 .Pa GENERIC カーネルを作り、インストールします。 同時に .Va KERNELS にリストされた他のカーネルも、作成しインストールします。 .It Cm release.5 .Xr crunchgen 1 を用いて、インストール用フロッピに収容する .Dq crunched バイナリを構築します。 .It Cm release.6 合成ディストリビューションを構築し、 また、作成されたディストリビューションツリーを掃除しきれいにします。 .It Cm release.7 組み立てられたディストリビューションツリーの tarball を 生成します。 .It Cm release.8 ソースディストリビューションを作成します。 .It Cm release.9 MFS root ファイルシステムを生成します。 .It Cm floppies.1 boot と kernel フロッピを生成します。 .It Cm floppies.2 fixit フロッピを生成します。 .It Cm floppies.3 .Pa ${CHROORDIR}/R/ftp/stage/floppies ステージディレクトリでの作業の仕上げをします。 .It Cm ftp.1 FTP インストールに適切な領域を .Pa ${CHROOTDIR}/R/ftp に整えます。 .It Cm cdrom.1 CD-ROM イメージ構築に適切な領域を .Pa ${CHROOTDIR}/R/cdrom に整えます。 .It Cm iso.1 CD-ROM リリース領域から ISO イメージを 2 つ構築します (インストール用と .Dq live ファイルシステムの 2 つ)。 デフォルトでは無効になっています。 以下の .Va MAKE_ISOS を参照してください。 .It Cm fetch-distfiles リリースビルドに必要な distfile で .Va RELEASEDISTFILES にはまだ無いものを取得します。 .It Cm doc.1 .Fx ドキュメンテーションプロジェクトのソースドキュメント (SGML, XML) を リリースに含める HTML / テキストドキュメントに変換するために 必要なツール全てを構築します。 また、現在存在するユーザドキュメントも構築、インストールします。 これには、Handbook, FAQ, article などが含まれます。 .It Cm doc.2 リリースドキュメントを構築します。 これには、リリースノート、ハードウェアガイド、インストール作業説明書 (installation instructions) が含まれます。 .El .Sh 環境変数 指定しなければならない環境変数は以下のとおりです。 .Bl -tag -width ".Va BUILDNAME" .It Va BUILDNAME 構築するリリースの名前。 この名前は、 .Pa sys/conf/newvers.sh の中で .Va RELEASE の値を設定するのに使用します。 この値は .Xr uname 1 の出力を変更します。 .It Va CHROOTDIR .Xr chroot 8 環境として、全リリース構築に使用するディレクトリ。 .\" XXX: I recommend against hardcoding specific numbers like "2.3" here; .\" XXX: perhaps it should be replaced with something to the effect of .\" XXX: "we don't know how much space you'll need, but make sure you have .\" XXX: at least 3 GB to be safe" (I know i'm still hardcoding a number, .\" XXX: but at least it looks less like a decree and more like an estimate. i386 アーキテクチャの場合、これが存在するファイルシステムには 少なくとも 2.3GB の空き領域が必要です。 .It Va CVSROOT .Fx CVS リポジトリの位置です。 このパス名は、実システムルートから参照され、 .Xr chroot 8 されたディレクトリツリーのルートからの参照では .Em ありません。 .El .Pp オプションの変数は次のとおりです。 .Bl -tag -width ".Va NO_PREFETCHDISTFILES" .It Va CVSCMDARGS .Xr cvs 1 のコマンド .Ic checkout と .Ic update への追加の引数です。 例えば、この変数を .Dq Li "-D '01/01/2002 00:00:00 GMT'" に設定して .Dq Li "make release" または .Dq Li "make rerelease" すると、 .Xr cvs 1 はそれぞれ 2002 年 1 月 1 日 00:00:00 GMT のソースを チェックアウトまたはアップデートするよう .Xr cvs 1 に指示します。 .It Va LOCAL_PATCHES .Pa /usr/src に対するパッチファイル。 このパッチは、リリース構築を開始する前に、 .Xr chroot 8 環境で適用されます。 .It Va PATCH_FLAGS パッチファイル .It Va DOC_LANG 構築すべき SGML ベースドキュメンテーションの、言語とコード。 設定されないと、使用可能なすべての言語に対し、 ドキュメンテーションが構築されます。 .It Va DOCRELEASETAG ドキュメンテーションツリーのチェックアウト時に使用する CVS タグ。 通常、デフォルトで、ドキュメンテーションツリーの先頭が使用されます。 .Va RELEASETAG がリリースタグを指定する場合、 関連付けられたリリースバージョンがデフォルトの代りに使用されます。 .It Va EXTLOCALDIR .Pa ${CHROOTDIR}/usr/local にコピーされるディレクトリ。 .It Va KERNEL_FLAGS リリース構築中のカーネル構築時に、この変数の内容が .Xr make 1 に渡されます。 例えば、この変数を .Dq Li "-j 4" に設定すると、 .Xr make 1 に最大 4 プロセスまで同時に実行することを指示することになります。 .It Va KERNELS コンパイルして .Dq ベース 配布にインストールする、追加のカーネル設定のリストを指定します。 各カーネルは、 .Pa /boot/ にインストールされ、ローダから .Dq Li "boot " でブートできるようになります。 .Va LOCAL_PATCHES を適用する際に用いる .Xr patch 1 コマンドに渡す引数。 .It Va LOCAL_SCRIPT .Xr chroot 8 環境で、ローカルパッチ適用直後に実行されるスクリプト。 .It Va MAKE_ISOS これを定義した場合、CD-ROM ステージのディレクトリの内容から、 ブータブル ISO CD-ROM イメージを生成します。 +.It Va DISC1_LABEL +disc1 の内容から生成される CD-ROM 用に使われるラベルです。 +デフォルトは +.Dq Li fbsd_miniinst +です。 +.It Va DISC1_NAME +disc1 の内容から生成される CD-ROM の ISO の +ファイル名の一部として使用される名前です。 +デフォルトは +.Dq Li miniinst +です。 +.It Va DISC2_LABEL +disc2 の内容から生成される CD-ROM 用に使われるラベルです。 +デフォルトは +.Dq Li fbsd_livefs +です。 +.It Va DISC2_NAME +disc2 の内容から生成される CD-ROM の ISO の +ファイル名の一部として使用される名前です。 +デフォルトは +.Dq Li disc2 +です。 .It Va NOCDROM 定義した場合、CD-ROM ステージのディレクトリを生成しません。 .It Va NODOC 定義した場合、 .Fx ドキュメンテーションプロジェクトの SGML ベースのドキュメントを生成しません。 しかしながら、 .Pa src/share/doc にある最小のドキュメンテーションセットから .Dq doc ディストリビューションが依然として作成されます。 .It Va NO_FLOPPIES 定義した場合、boot, fixit フロッピディスクイメージファイルを生成しません (i386 のみ)。 .It Va NOPORTS 定義した場合、Ports Collection はリリースから省略されます。 .It Va NOPORTREADMES これを定義した場合、 Ports Collection の各 port に対する readme ファイルを作成しません。 デフォルトの動作は、 .Dq Li "make release" が .Dq Li "make readmes" を .Pa ${CHROOTDIR}/usr/ports から実行するというものであり、莫大な時間を費すことになります。 .It Va PORTSRELEASETAG ports ツリーのチェックアウト時に使用する CVS タグ。 通常、デフォルトで、ports ツリーの先頭が使用されます。 .Va RELEASETAG がリリースタグを指定する場合、 関連付けられたリリースバージョンがデフォルトの代りに使用されます。 .It Va NO_PREFETCHDISTFILES この変数が定義されている場合、 .Xr chroot 8 環境に入る前に、リリース構築に必要な distfile がダウンロードされません。 .Va NO_PREFETCHDISTFILES が設定されていない場合、取得が行われるのは、 .Va RELEASEDISTFILES から distfile を取得完了した後であることに注意してください。 .It Va RELEASEDISTFILES ports 用として、リリース構築に必要となる ディストリビューションファイルが存在するディレクトリです。 これにより、低速なリンク経由で distfiles をダウンロードする際に費やされる莫大な時間を 節約することができます。 .It Va RELEASENOUPDATE .Dq Li "make rerelease" の際にこの変数の値を設定した場合、 .Dq Li "cvs update" によるソースコード更新を行ないません。 .It Ev RELEASETAG 構築するリリースに相当する CVS タグ。 未定義の場合、CVS ツリーの .Dv HEAD .Dq ( "-CURRENT スナップショット" ) から構築されます。 .It Va TARGET_ARCH ターゲットとなるマシンプロセッサアーキテクチャ。 この環境変数は .Dq Nm uname Fl p の出力と同じものです。 異なるアーキテクチャ用にクロスビルドするにはこの環境変数を設定してください .It Va TARGET ターゲットとなるハードウェアプラットフォーム。 この環境変数は .Dq Nm uname Fl m の出力と同じものです。 ターゲットアーキテクチャをクロスビルドするのに必要な変数です。 例えば、PC98 マシン用にクロスビルドを行うには .Va TARGET_ARCH Ns = Ns Li i386 と .Va TARGET Ns = Ns Li pc98 が必要です。 .It Va WORLDDIR .Dq Li "make buildworld" が実行されたディレクトリです。 デフォルトは .Pa ${.CURDIR}/.. であり、通常は .Pa /usr/src を指します。 .It Va WORLD_FLAGS リリース構築中の世界 (world) 構築時に、この変数の内容が .Xr make 1 に渡されます。 例えば、この変数を .Dq Li "-j 4" に設定すると、 .Xr make 1 に最大 4 プロセスまで同時に実行することを指示することになります。 .El .Sh 関連ファイル .Bl -tag -compact .It Pa /etc/make.conf .It Pa /usr/doc/Makefile .It Pa /usr/doc/share/mk/doc.project.mk .It Pa /usr/ports/Mk/bsd.port.mk .It Pa /usr/ports/Mk/bsd.sites.mk .It Pa /usr/share/examples/etc/make.conf .It Pa /usr/src/Makefile .It Pa /usr/src/Makefile.inc1 .It Pa /usr/src/release/Makefile .It Pa /usr/src/release/${arch}/drivers.conf .It Pa /usr/src/release/${arch}/boot_crunch.conf .It Pa /usr/src/release/${arch}/fixit_crunch.conf .El .Sh 使用例 以下のコマンド列は .Fx 4.5 release を構築する際に使用したものです。 .Bd -literal -offset indent cd /usr cvs co -rRELENG_4_5_0_RELEASE src cd src make buildworld cd release make release CHROOTDIR=/local3/release BUILDNAME=4.5-RELEASE \\ CVSROOT=/host/cvs/usr/home/ncvs RELEASETAG=RELENG_4_5_0_RELEASE .Ed .Pp これらのコマンドを実行すると、FTP ディストリビューション用と、 CD-ROM ディストリビューション用として使える完全なシステムが ディレクトリ .Pa /local3/release/R にできます。 .Pp 次のコマンド列は、ローカルで修正したソースツリーの .Dq "-CURRENT スナップショット" を構築するために使用できます。 .Bd -literal -offset indent cd /usr/src cvs diff -u > /path/to/local.patch make buildworld cd release make release CHROOTDIR=/local3/release BUILDNAME=5.0-CURRENT \\ CVSROOT=/host/cvs/usr/home/ncvs LOCAL_PATCHES=/path/to/local.patch .Ed .Sh 関連項目 .Xr cc 1 , .Xr crunchgen 1 , .Xr cvs 1 , .Xr install 1 , .Xr make 1 , .Xr patch 1 , .Xr uname 1 , .Xr md 4 , .Xr drivers.conf 5 , .Xr make.conf 5 , .Xr build 7 , .Xr ports 7 , .Xr chroot 8 , .Xr mtree 8 , .Xr sysctl 8 .Rs .%T "FreeBSD Release Engineering" .%O http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/releng/ .Re .Rs .%T "FreeBSD Release Engineering of Third Party Packages" .%O http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/releng-packages/ .Re .Rs .%T "FreeBSD Developers' Handbook" .%O http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/developers-handbook/ .Re .Sh 歴史 .Fx 1.x では、チェックリストを手でチェックしながら、 .An Rod Grimes によりコンパイルされ、リリースが作成されました。 不完全さはさておくにしても、このチェックリストには、 ファイルシステムを使えるようにするためのこまごまとした要求が大量に 含まれており、その実行は拷問としかいいようがないものでした。 .Pp .Fx 2.0 リリースエンジニアリングを続ける中で、 .Pa src/release/Makefile を直して、隔離された無菌環境でリリースを構築する際の退屈な作業の ほとんどを自動的に行なえるようにすることに、顕著な努力が払われました。 .Pp 複数のブランチにまたがる 1000 回近くの改版を経て、 .Pa src/release/Makefile の .Xr cvs 1 ログには、リリースエンジニアたちが経験した苦難のいくばくかを示す 生々しい歴史の記録が刻み込まれています。 .Sh 作者 .Pa src/release/Makefile は、もともとは .An -nosplit .An Rod Grimes , .An Jordan Hubbard , .An Poul-Henning Kamp が書きました。 このマニュアルページは、 .An Murray Stokely Aq murray@FreeBSD.org が書きました。 .Sh バグ .Fx ドキュメンテーションに対するインフラストラクチャ変更は頻繁で、 これが原因でセキュリティブランチ上のリリース構築が失敗することがあります。 最後に完全にサポートされた .Fx リリースから ドキュメンテーションをチェックアウトし、リリース構築することで、 この問題を回避できます。 例: .Pp .Dl "make release RELEASETAG=RELENG_4_5 DOCRELEASETAG=RELEASE_4_5_0 ..." diff --git a/ja_JP.eucJP/man/man7/security.7 b/ja_JP.eucJP/man/man7/security.7 index 1815c3f25b..1405746520 100644 --- a/ja_JP.eucJP/man/man7/security.7 +++ b/ja_JP.eucJP/man/man7/security.7 @@ -1,756 +1,874 @@ .\" Copyright (c) 1998, Matthew Dillon. Terms and conditions are those of .\" the BSD Copyright as specified in the file "/usr/src/COPYRIGHT" in .\" the source tree. .\" -.\" %FreeBSD: src/share/man/man7/security.7,v 1.34 2004/02/18 18:52:09 ceri Exp % +.\" %FreeBSD: src/share/man/man7/security.7,v 1.37 2004/06/15 12:48:50 ru Exp % .\" .\" $FreeBSD$ .Dd September 18, 1999 .Dt SECURITY 7 .Os .Sh 名称 .Nm security -.Nd FreeBSD におけるセキュリティ入門 +.Nd +.Fx +におけるセキュリティ入門 .Sh 解説 セキュリティは、システム管理者とともに始まり、システム管理者と ともに終る機能です。 .Bx マルチユーザシステムは、昔ながらのセキュリティをいくらかは備えて いますが、さらなるセキュリティ機構を組み込んで維持していくことで、ユーザを -.Sq 正直に +.Dq 正直に し続ける仕事は、システム管理者の最も大きな責務の一つでしょう。マシンは、 管理者が設定しただけのセキュリティしか示しません。セキュリティに関する 問題は、むしろ、便利さを求める人間との競合問題です。一般に、 .Ux システムは莫大な数のプロセスを同時に実行させることができ、 それも、サーバとして動作するものが多いのです。つまり、外部の何者かが 接続してきて、サーバプロセスと会話することができるということなのです。 昨日まで使われていたミニコンピュータやメインフレームは、今日では デスクトップコンピュータが取って代わり、しかも、それらはネットワークで結ばれて インターネットと接続されるようになりました。これにより、セキュリティは 昔と比べてはるかに大きな問題となっています。 .Pp セキュリティは、タマネギの階層のようなアプローチを通すと最もよく実装できます。 手短に言って、やりたいことは、便利さを損ねない程度にできるだけ多くの 階層を作り、システムに侵入されていないかを注意深く監視することです。 セキュリティの階層を作りすぎたくはありません。作りすぎると、侵入の 検出が妨げられることになるでしょう。どんなセキュリティ機構でも、 侵入の検出をすることが唯一とても重要なことなのですから。 例えば、システムの各バイナリに -.Pa schg +.Cm schg フラグ ( .Xr chflags 1 参照) -を設定するのは大して意味がありません。フラグを設定すると、一時的には -バイナリを保護することができますが、侵入してきたクラッカーが、 -マシンのセキュリティ機構がクラッカーの侵入を全く検知できなくなるような -変更ではあるが、管理者が容易に検出できるような変更をできなくしてしまう -からです。 +を設定するのは大して意味がありません。 +このフラグを設定すると、一時的にはバイナリを保護することができますが、 +侵入してきた攻撃者が容易に検知可能な変更をすることを妨げてしまい、 +結果として、マシンのセキュリティ機構が攻撃者を +まったく検知できなくなってしまうからです。 .Pp システムセキュリティには、さまざまな形での攻撃に対処することも ついて回ります。攻撃には、root を破ろうとはしないが、システムを クラッシュさせたり、さもなければ、システムを使用不能にしたり しようとするものも含まれています。 セキュリティに関する問題は、いくつかのカテゴリに分類することができます。 .Bl -enum -offset indent .It -サービス不能攻撃 +サービス不能攻撃 (DoS) .It ユーザアカウントにかかる危険 .It アクセス可能なサーバを経由した root 権限にかかる危険 .It ユーザアカウントを通した root 権限にかかる危険 .It 裏口の作成 .El .Pp サービス不能攻撃とは、マシンから必要な資源を奪う行為です。 サービス不能攻撃は、普通は、そのマシンで実行されるサーバや ネットワークスタックを圧倒して、マシンをクラッシュさせたり、 さもなければマシンを使えなくしたりするような力任せの方法です。 サービス不能攻撃のいくつかは、 ネットワークスタックのバグを利用して、パケット一つでマシンを クラッシュさせようとします。後者は、 カーネルにバグ修正を施すことによってのみ修正することができます。 サーバプロセスに対する攻撃は、オプションを適切に指定して、 不利な状況にあるシステムにおいて、サーバプロセスが引き起こす負荷に限界を設けることで 修正することができます。これらに比べると、ネットワークへの力任せの攻撃への 対応はずっと難しくなります。たとえば、偽造パケットによる攻撃 .Pq spoof-packet attack は、インターネットからシステムを切り離す以外の方法で防ぐことは ほとんど不可能です。 それによって、マシンを落としてしまうことはできないかもしれませんが、 インターネット回線をいっぱいにしてしまうことはできます。 .Pp ユーザアカウントを危険に晒してしまう問題は、サービス不能攻撃よりもずっとよくある -問題です。このご時勢でも、自分たちのマシンで標準の telnetd, rlogind, rshd, ftpd +問題です。このご時勢でも、自分たちのマシンで標準の +.Xr telnetd 8 , +.Xr rlogind 8 , +.Xr rshd 8 , +.Xr ftpd 8 サーバを実行させているシステム管理者は多いのです。これらの サーバは、デフォルトでは、暗号化されたコネクション上で動作していません。 その結果、抱えているユーザ数が標準くらいであれば、リモートログイン (そのシステムにログインするには最も普通で便利な方法です) しているユーザのうち一人以上は、パスワードを覗き見られて しまうでしょう。 システム管理者が注意深い人ならば、たとえログインが成功していたとしても、 リモートアクセスログを解析して、疑わしいソースアドレスを探すものです。 .Pp ひとたび攻撃者がユーザアカウントへのアクセス権を入手すると、攻撃者が root の権限を破る可能性があることを仮定するべきです。しかし、 セキュリティを十分維持し、手入れの行き届いたシステムにおいては、 あるユーザアカウントへのアクセスが可能となっても、攻撃者に必ずしも root へのアクセス権を与えるとは限らないのが現実です。この違いは重要です。 というのは、root へのアクセス権がなければ、一般的に、攻撃者は自分の 侵入の痕跡を隠蔽することができませんし、そのユーザのファイルを引っかき回したり、 マシンをクラッシュさせたりできるのがせいぜいです。 ユーザアカウントが危険に晒されるということは、たいへんよく起こることです。 なぜなら、ユーザは、システム管理者ほどには前もって注意を払わない 傾向があるからです。 .Pp システム管理者は、あるマシン上で root の権限を破る方法は、潜在的に 何通りもあるのだということを 心しておかねばなりません。攻撃者が root のパスワードを知ってしまうかも しれません。攻撃者が root の権限で実行されるサーバのバグを見つけ、 ネットワークからそのサーバへ接続して root の権限を破ることができるかも しれません。ひとたびユーザアカウントを破ると、ユーザアカウントから -root の権限を破ることが可能であるというバグを持つ suid-root プログラムの +root の権限を破ることが可能であるというバグを持つ SUID-root プログラムの 存在を、攻撃者は知っているかもしれません。 あるマシン上で、攻撃者が root の権限を破る方法を知ったとすると、 攻撃者は、裏口を作る必要などないかもしれません。 -発見され、ふさがれた root の穴の多くには、クラッカーが侵入した跡を消そうとして +発見され、ふさがれた root の穴の多くには、攻撃者が侵入した跡を消そうとして たくさん仕事した結果が含まれています。 -そのためにこそ、多くのクラッカーは裏口を作るのです。この裏口は、クラッカーの -検出をするのに便利なやり方です。クラッカーに裏口を作らせないようにする +そのためにこそ、多くの攻撃者は裏口を作るのです。この裏口は、攻撃者の +検出をするのに便利なやり方です。攻撃者に裏口を作らせないようにする ということは、セキュリティにとっては実際には良くないことかもしれません。 -なぜなら、そうすることで、クラッカーが最初に侵入してくるために発見した +なぜなら、そうすることで、攻撃者が最初に侵入してくるために使用した セキュリティホールがふさがるわけではないからです。 .Pp セキュリティを改善する方法は、常に、 -.Sq タマネギの皮剥き +.Dq タマネギの皮剥き のように 複数の層のアプローチで実装されるべきです。これらは次のように分類できます。 .Bl -enum -offset indent .It root とスタッフのアカウントの安全性を高める。 .It -root の安全性を高める - root 権限のサーバと suid/sgid バイナリ。 +root の安全性を高める \(em root 権限のサーバと SUID/SGID バイナリ。 .It ユーザアカウントの安全性を高める。 .It パスワードファイルの安全性を高める。 .It カーネルのコア、raw デバイス、ファイルシステムの安全性を高める。 .It システムに対して行なった、不適切な変更をすばやく検出する。 .It 偏執狂的方法。 .El .Sh root アカウントとスタッフアカウントの安全性を高める root のアカウントの安全性を確保しないうちからスタッフのアカウントの安全性を うんぬんしてもしかたがありません。ほとんどのシステムでは、root アカウントに 割り当てたパスワードが 1 つあります。まず最初にすべきことは、 このパスワードは -.Sq いつでも +.Em いつでも 危険に晒されていると仮定することです。 ここでは、root のパスワードを消すべきだと言っているのではありません。 パスワードは、マシンにコンソールからアクセスするのには、ほとんどいつでも 必要なものです。ここで言いたいのは、コンソール以外からは、おそらくは、 .Xr su 1 -コマンドを用いてすらパスワードを使えるようにするべきではないということです。 -例えば、pty が、 -.Sq Pa /etc/ttys -ファイルで安全でないものと指定されているのかを確認してください。 -そうすることで、telnet や rlogin 越しに root でログインできないようになります。 -sshd のような、別のログインサービスを使っている場合でも同様に、 +ユーティリティを用いてすらパスワードを使えるようにするべきではないと +いうことです。 +例えば、PTY が、 +.Pa /etc/ttys +ファイルで +.Dq Li unsecure +と指定されているかを確認してください。 +そうすることで、 +.Xr telnet 1 +や +.Xr rlogin 1 +越しに root でログインできないようになります。 +.Xr sshd 8 +のような、別のログインサービスを使っている場合でも同様に、 直接 root へログインすることを許していないかどうか確認してください。 -アクセスする手段、例えば ftp のようなサービスが、たびたびクラックの手に落ちる +アクセスする手段、例えば +.Xr ftp 1 +のようなサービスが、たびたびクラックの手に落ちる ことを考えてみてください。root に直接ログインできるのは、システムコンソール を通したときのみにすべきです。 .Pp システム管理者として、自分は root になれるようにしておかねばならないの はもちろんですから、穴をいくつか空けておきます。しかし、それらの穴を 動作させるには、さらに追加のパスワード認証が必要であるようにして おきます。root でアクセス可能とする方法の一つとして、 適切なスタッフアカウントを ( .Pa /etc/group ) の -wheel グループに加えることがあります。 -wheel グループに置かれたスタッフメンバには、 -.Sq su +.Dq Li wheel +グループに加えることがあります。 +.Li wheel +グループに置かれたスタッフメンバには、 +.Xr su 1 を使って root になることが許されます。パスワードエントリにおいて、 -スタッフメンバを wheel グループを置くことで、スタッフメンバに -wheel のアクセス権を与えてはいけません。スタッフメンバのアカウントは -.Sq staff -に置くべきです。そして -.Sq Pa /etc/group -ファイルを通して wheel グループに加えるべきです。 -実際に root アクセスの必要な staff メンバのみ wheel グループに置くように -すべきです。kerberos のような認証方法を使用する場合、root アカウントで -.Sq Pa .k5login -ファイルを使って、誰も wheel グループに置く必要なく root に +スタッフメンバを +.Li wheel +グループを置くことで、スタッフメンバに +.Li wheel +のアクセス権を与えてはいけません。スタッフメンバのアカウントは +.Dq Li staff +グループに置くべきです。そして +.Pa /etc/group +ファイルを通して +.Li wheel +グループに加えるべきです。 +実際に root アクセスの必要な staff メンバのみ +.Li wheel +グループに置くように +すべきです。Kerberos のような認証方法を使用する場合、root アカウントで +.Pa .k5login +ファイルを使って、誰も +.Li wheel +グループに置く必要なく root に .Xr ksu 1 を許すようにすることもできます。 -このやり方はよりよい解決策なのかもしれません。なぜなら、wheel のメカニズム +このやり方はよりよい解決策なのかもしれません。なぜなら、 +.Li wheel +のメカニズム では、侵入者がパスワードファイルを手に入れ、staff アカウントのいずれか 1 つを破ることができると、root を破ることがまだできてしまうからです。 -wheel のメカニズムを用いる方が、何もしないよりは良いのですが、必ずしも +.Li wheel +のメカニズムを用いる方が、何もしないよりは良いのですが、必ずしも 最も安全な選択肢とは限りません。 .Pp root アカウントの安全性を高める間接的な方法として、別のログインアクセス の方法を用いて、スタッフのアカウントの暗号化パスワードを\ * にして おくことで、スタッフのアカウントの安全性を高めるものがあります。この方法 -だと、侵入者がパスワードファイルを盗むことができるかもしれませんが、 -スタッフアカウントを破ることはできないでしょう。また、たとえ root が暗号化 -パスワードをパスワードファイルに付けていたとしても、間接的には root -アカウントも破ることができないでしょう。 +だと、侵入者はパスワードファイルを盗むことができるかもしれませんが、 +スタッフアカウントを破ることはできないでしょう。 +また、たとえ root が暗号化パスワードをパスワードファイルに付けていたとしても、 +root アカウントも破ることはできないでしょう +(もちろん、コンソールへの root によるアクセスが限定されているものとします)。 スタッフメンバがスタッフアカウントでログインする際には、 .Xr kerberos 1 や .Xr ssh 1 のような、公開鍵 / 秘密鍵の鍵の組を使う -安全性の高いログインの仕組みを使います。kerberos のような仕掛けを使う場合、 -一般に、kerberos サーバを実行するマシンと自分のデスクトップ -ワークステーションとの安全性を確保しなければなりません。ssh で -公開鍵 / 秘密鍵の組を使う場合、一般に、ログイン元マシン -(通常は自分のワークステーション) +安全性の高いログインの仕組みを使います。Kerberos のような仕掛けを使う場合、 +一般に、Kerberos サーバを実行するマシンと自分のデスクトップ +ワークステーションとの安全性を確保しなければなりません。SSH で +公開鍵 / 秘密鍵の組を使う場合、一般に、ログイン +.Em 元 +マシン (通常は自分のワークステーション) の安全性を確保しなければなりません。ここで、 .Xr ssh-keygen 1 で公開鍵 / 秘密鍵の組を生成する際、鍵の組をパスワードで防御することにより、 鍵の組への防御層を追加することもできます。スタッフアカウントの パスワードを\ * で外すことができると、管理者自身が設定 した安全性の高い方法でしかスタッフメンバがログインできないことも保証 できます。こうして、多くの侵入者が使う重大なセキュリティの穴 (安全性の低い無関係なマシンからネットワークを覗き見る方法) を塞ぐようなセッションを提供する、安全性の高い暗号化されたコ ネクションを使うことを、スタッフメンバ全員に強制することができ るのです。 .Pp より間接的なセキュリティの仕組みでは、制限の強いサーバから制限の弱い サーバへログインすることを前提としています。例えば、メインマシンで、 様々な種類のサーバを実行させている場合、ワークステーションではそれらの サーバを実行させてはなりません。ワークステーションを十分に 安全にしておくためには、実行するサーバの数を、一つもサーバ が実行されていないというくらいにまでできる限り減らすべきです。 また、パスワードで保護されたスクリーンセーバを走らせておくべきです。 ワークステーションへの物理的アクセスが与えられたとすると、もちろん 言うまでもなく、攻撃者は管理者が設定したいかなる種類のセキュリティ をもうち破ることができるのです。これは、管理者として必ず考えておか ねばならない問題ですが、システム破りの大多数は、ネットワーク経由で リモートから、ワークステーションやサーバへの物理的アクセス手段を持 たない人々によって行われるという事実もまた、念頭に置いておく必要 があります。 .Pp -kerberos のような方法を使うことで、スタッフアカウントのパスワードの変更 +Kerberos のような方法を使うことで、スタッフアカウントのパスワードの変更 もしくは停止を一箇所で行なうことと、スタッフメンバがアカウントを持つ すべてのマシンに即時にその効果を及ぼすことが可能となります。スタッフメンバの アカウントが危険に晒されたときに、すべてのマシンでスタッフメンバのパスワードを 即座に変更する能力を過小評価してはいけません。パスワードが分散されている状況では、 N 台のマシンでパスワードを変更すると、てんやわんやの事態を招く可能性が -あります。kerberos を使用すると、パスワードの再発行に制限 +あります。Kerberos を使用すると、パスワードの再発行に制限 (re-passwording restriction) を課することもできます。この機能を使うことにより、 -ある kerberos チケットをしばらく経つとタイムアウトにすることが +ある Kerberos チケットをしばらく経つとタイムアウトにすることが できるだけでなく、一定期間 (例えば、1 ヶ月に 1 回) 経つと、ユーザに新しいパスワードを選ぶように要求することもできます。 -.Sh root の安全性を高める - root 権限のサーバと suid/sgid バイナリ +.Sh root の安全性を高める \(em root 権限のサーバと SUID/SGID バイナリ 用心深いシステム管理者は、自分に必要なサーバプロセスだけを過不足なく 実行させるものです。第三者製のサーバは、よくバグを持っていがちだと -いうことに注意して下さい。例えば、古いバージョンの imapd や popper +いうことに注意して下さい。例えば、古いバージョンの +.Xr imapd 8 +や +.Xr popper 8 を実行させておくのは、全世界に共通の root の切符を与えてい るようなものです。 自分で注意深くチェックしていないサーバは、決して実行してはいけません。 -root で実行させる必要のあるサーバはほとんどありません。例えば、ntalk, comsat, -finger デーモンを、特別の「砂場 -.Pq sandbox +root で実行させる必要のあるサーバはほとんどありません。 +例えば、 +.Xr talkd 8 , +.Xr comsat 8 , +.Xr fingerd 8 +デーモンを、特別の「砂場 +.Dq sandbox 」ユーザで実行させることができます。 .\"kuma hellofalot of trouble って何や？ .\" hell of a lot of trouble みたいですね。;-) (金ん田 '99.02.11) 管理者が膨大な数の問題に直面していないのなら、この「砂場」は完璧では ありませんが、セキュリティに関するタマネギ的アプローチはここでも 成り立ちます。砂場で実行されているサーバプロセスを経由して侵入を 果たすことができたとしても、攻撃者はさらに砂場から外に脱出しなければ なりません。攻撃者が通過せねばならない層の数が増えれば増えるほど、 それだけ攻撃者が侵入に成功する確率が減ります。root の抜け穴は 歴史的に、基本システムサーバも含め、 root 権限で実行されるほとんどすべてのサーバプロセスで発見されています。 -ユーザが sshd 経由でのみログインし、 -telnetd, rshd, rlogind 経由でログインすること -が決してないマシンを稼働させているのであれば、それらのサービスを停止させて下さい。 +ユーザが +.Xr sshd 8 +経由でのみログインし、 +.Xr telnetd 8 , +.Xr rshd 8 , +.Xr rlogind 8 +経由でログインすることが決してないマシンを稼働させているのであれば、 +それらのサービスを停止させて下さい。 .Pp .Fx -では、今では ntalkd, comsat, finger は砂場で実行させることが +では、今では +.Xr talkd 8 , +.Xr comsat 8 , +.Xr fingerd 8 +は砂場で実行させることが デフォルトになっています。次に砂場で実行させるべきプログラムの候補として、 .Xr named 8 -があります。デフォルトの rc.conf ファイルには、named を砂場で実行する +があります。デフォルトの +.Pa rc.conf +ファイルには、 +.Xr named 8 +を砂場で実行する ために必要な引数がコメントアウトされた形式で含まれています。新しい システムをインストールしているか、それとも既存のシステムを アップグレードして使っているかに依存しますが、砂場として使用する 特別のユーザアカウントがインストールされていないかもしれません。 用心深いシステム管理者であれば、できるだけいつでも研究を怠らず、 サーバに砂場を仕込むものでしょう。 .Pp -通常、砂場で実行しないサーバが他にいくつかあります。sendmail, popper, -imapd, ftpd などです。これらのうちいくつかのサーバには代わりとなるも +通常、砂場で実行しないサーバが他にいくつかあります。 +.Xr sendmail 8 , +.Xr popper 8 , +.Xr imapd 8 , +.Xr ftpd 8 +などです。これらのうちいくつかのサーバには代わりとなるも のがありますが、 代わりのものをインストールするには、それだけ多くの仕事が必要になるので、 結局これらを喜んで入れてしまいます (便利さという要素がまたも勝利を収めるわけです)。 これらのサーバは、root 権限で実行せねばならいかもしれません。また、 これらのサーバ経由で生じる侵入 を検出するためには、他の仕組みに頼らなくてはならないかもしれません。 .Pp システムの root 権限の潜在的な穴で他に大きなものとして、システムに -インストールされた suid-root/sgid バイナリがあります。 -これらのバイナリは、rloginのように、 -.Pa /bin , -.Pa /sbin , -.Pa /usr/bin , -.Pa /usr/sbin +インストールされた SUID-root/SGID バイナリがあります。 +これらのバイナリは、 +.Xr rlogin 1 +のように、 +.Pa /bin , /sbin , /usr/bin , /usr/sbin に存在するものがほとんどです。 100% 安全なものは存在しないとはいえ、システムデフォルトの -suid/sgid バイナリは比較的安全といえます。それでもなお、root の穴が +SUID/SGID バイナリは比較的安全といえます。それでもなお、root の穴が これらのバイナリにときおり発見されています。1998 年に Xlib で見つかった -root の穴は、xterm -(普通、suid 設定されています) +root の穴は、 +.Xr xterm 1 +(普通、SUID 設定されています) を攻撃可能にしていました。 安全である方がよいので、用心深いシステム管理者は残念に思いながらも、 -スタッフのみが実行する必要がある suid バイナリは、スタッフのみが +スタッフのみが実行する必要がある SUID バイナリは、スタッフのみが アクセス可能な特別なグループに含めるように制限を加え、 -誰も使わない suid バイナリは -.Pq Li chmod 000 を実行して -片付けてしまうでしょう。 -ディスプレイを持たないサーバは、一般的に xterm のバイナリを必要としません。 -sgid バイナリもほとんど同様の危険な存在になり得ます。 -侵入者が kmem に sgid されたバイナリを破ることができた場合、 +誰も使わない SUID バイナリは +.Pq Dq Li "chmod 000" +を実行して片付けてしまうでしょう。 +ディスプレイを持たないサーバは、一般的に +.Xr xterm 1 +のバイナリを必要としません。 +SGID バイナリもほとんど同様の危険な存在になり得ます。 +侵入者が kmem に SGID されたバイナリを破ることができた場合、 その侵入者は .Pa /dev/kmem を読み出すことができるようになります。 つまり、暗号化されたパスワードファイルを読み出すことができる ようになるので、パスワードを持つどのアカウントをも、 .Pq 潜在的な 危険に晒すことになります。 -代わりに、kmem グループを破った侵入者が pty を通して送られたキーストロークを +代わりに、 +.Dq Li kmem +グループを破った侵入者が PTY を通して送られたキーストロークを 監視できます。キーストロークには、安全な方法でログインするユーザが使っている -pty も含まれます。tty グループを破った侵入者は、ほぼ任意のユーザの tty へ +PTY も含まれます。 +.Dq Li tty +グループを破った侵入者は、ほぼ任意のユーザの TTY へ 書き込みができます。ユーザが端末プログラムやキーボードをシミュレーション する機能を持ったエミュレータを使っている場合、侵入者は潜在的に、 結局そのユーザとして実行されるコマンドをユーザの端末にエコーさせる データストリームを生成できる可能性があります。 .Sh ユーザアカウントの安全性を高める ユーザアカウントは、普通、安全性を高めることが最も困難です。 スタッフに対して、アテナイのドラコのような厳格なアクセス制限を課し、 スタッフのパスワードを\ * で外すことができるとはいえ、管理者が持ちうる 一般ユーザすべてのアカウントに対して同じことはできないかもしれません。 管理者が十分に統率をとることができるなら、管理者は勝利し、ユーザの アカウントの安全を適切に確保できるかもしれません。それが できないならば、よりいっそう気を配って一般ユーザのアカウントを 監視するよりほかありません。一般ユーザアカウントに対し -ssh や kerberos を利用することには、システム管理がさらに増えたり +SSH や Kerberos を利用することには、システム管理がさらに増えたり テクニカルサポートが必要になるなどの問題があります。 それでも、暗号化パスワードファイルと比較するとはるかに良い解です。 .Sh パスワードファイルの安全性を高める できるだけ多くのパスワードを\ * で外し、それらのアカウントのアクセスには -ssh や kerberos を使うようにすることが、唯一の確実な方法です。たとえ暗号化 +SSH や Kerberos を使うようにすることが、唯一の確実な方法です。たとえ暗号化 パスワードファイル .Pq Pa /etc/spwd.db が root でのみ読み出し可能だとしても、 侵入者がそのファイルの読み出しアクセス権限を得ることは可能かもしれません。 たとえ root の書き込み権限が得られないにしてもです。 .Pp セキュリティスクリプトは常にパスワードファイルの変更をチェックし、報告 するようにすべきです -(後述の「ファイルの完全性のチェック」を参照して下さい)。 +(後述の +.Sx 「ファイルの完全性のチェック」 +を参照して下さい)。 .Sh カーネルのコア、raw デバイス、ファイルシステムの安全性を高める root の権限を破ると、攻撃者は何でもできますが、 もっと簡便なこともいくつかあります。例えば、最近のカーネルは、 組み込みのパケット覗き見デバイス .Pq packet sniffing device ドライバを備えているものがほとんどです。 .Fx では -.Sq bpf +.Xr bpf 4 デバイスと呼ばれています。侵入者は普通、危険に晒された マシンでパケット覗き見プログラムを実行させようと試みます。侵入者に -わざわざそういう機能を提供する必要はないので、ほとんどのシステムで bpf +わざわざそういう機能を提供する必要はないので、ほとんどのシステムで +.Xr bpf 4 デバイスを組み込むべきではありません。 .Pp -bpf デバイスを外し、モジュールローダを無効にしても、 +.Xr bpf 4 +デバイスを外し、モジュールローダを無効にしても、 .Pa /dev/mem と .Pa /dev/kmem という悩みの種がまだ残っています。この問題に関しては、侵入者は raw デバイスに書き込むこともできます。 また、 .Xr kldload 8 という、別のカーネル機能があります。 やる気まんまんの侵入者は、KLD モジュールを使って -自分独自の bpf もしくはその他覗き見デバイスを動作中のカーネルに +自分独自の +.Xr bpf 4 +もしくはその他覗き見デバイスを動作中のカーネルに インストールすることができます。 この問題を避けるため、システム管理者は カーネルをより高い安全レベル .Pq securelevel 、少なくとも安全レベル 1 で実行させる必要があります。 -sysctl を使って kern.securelevel 変数に安全レベルを設定することが +.Xr sysctl 8 +を使って +.Va kern.securelevel +変数に安全レベルを設定することが できます。ひとたび安全レベルに 1 を設定すると、 raw デバイスに対する書き込みアクセスは拒否され、例えば -.Sq schg -のような -特別な chflags フラグが効果を発揮します。これに加えて、 +.Cm schg +のような特別な +.Xr chflags 1 +フラグが効果を発揮します。これに加えて、 起動時において重要なバイナリ・ディレクトリ・スクリプトファイルなど、 安全レベルが設定されるまでの間に実行されるものすべてに対しても -.Sq schg +.Cm schg フラグを確実に on にしておく必要があります。この設定をやり過ぎても 構いませんが、より高い安全レベルで動作している場合、システムの アップグレードがはるかに困難になります。システムをより高い安全レベルで 実行させるようにするが、お天道さまの下にあるすべてのシステムファイルと -ディレクトリに schg フラグを設定しないという妥協をする方法もあります。 -もう一つの可能性としては、単純に / および /usr を読み込み専用でマウント +ディレクトリに +.Cm schg +フラグを設定しないという妥協をする方法もあります。 +もう一つの可能性としては、単純に +.Pa / +と +.Pa /usr +を読み込み専用でマウント することです。ここで特筆すべきことは、システムを守ろうとしてアテナイのドラコ のように厳しくしすぎると、侵入を検出するという非常に重要なことが できなくなってしまうということです。 .Sh ファイルの完全性のチェック: バイナリ、設定ファイルなど ことこの問題に至ると、システム管理者にできることは、 便利さという要素がその醜い頭を上げない程度に、 コアシステムの設定 / 制御ファイルを防御することだけです。 -例えば、/ および /usr にある大部分のファイルに schg ビットを -設定するために chflags を使用するのは、おそらく逆効果でしょう。 +例えば、 +.Pa / +と +.Pa /usr +にある大部分のファイルに +.Cm schg +ビットを設定するために +.Xr chflags 1 +を使用するのは、おそらく逆効果でしょう。 なぜなら、そうすることでファイルは保護できますが、侵入を検出 する窓を閉ざしてしまうことにもなるからです。 セキュリティのタマネギの最後の層はおそらく最も重要なもの、すなわち検出です。 セキュリティの残りのものは、突然の侵入を検出できなければ、全然有用では ありません( あるいは、もっと悪ければ、間違った安全性に対する感覚を 植え付けてしまいます )。 -タマネギの仕事の半分は、均衡状態にあるとき、攻撃中に検出側に攻撃者を -捕まえるきっかけを与えるため、攻撃者を食い止めるのではなく -侵入を遅らせることなのです。 +タマネギの仕事の半分は、攻撃者を食い止めるのではなく、侵入を遅らせることにより、 +攻撃中の攻撃者を捕まえる機会を検出層に与えることなのです。 .Pp 侵入を検出する最も良い方法は、変更されていたり、消えていたり、入れた覚えが ないのに入っているファイルを探すことです。 変更されたファイルを探すのに最も良い方法は、もう一つの ( しばしば中央に集められた ) アクセスが制限されたシステムから行なうものです。 さらに安全でアクセス制限されたシステム上でセキュリティ用スクリプトを書けば、 -スクリプトは潜在的なクラッカー達からはほぼ見えなくなります。 +スクリプトは潜在的な攻撃者達からはほぼ見えなくなります。 これは重要なことです。 最大限に優位に立つために、一般的にビジネスで使う他のマシンへの重要な アクセスは、アクセスの制限されたマシンにやらせなくてはいけません。 普通は、他のマシンからアクセス制限されたマシンへ読み込み専用で NFS エクスポートしたり、アクセス制限されたマシンから他のマシンへ -ssh を行なうために、ssh 鍵のペアを作ったりすることで行います。 +SSH を行なうために、SSH 鍵のペアを作ったりすることで行います。 ネットワークのトラフィックを別にして、NFS は最も可視性のない方法です。 事実上検出されない各クライアント上のファイルシステムを監視できるようになります。 アクセス制限されたサーバがスイッチを通してクライアントに接続する場合、 たいてい NFS がより良い選択肢です。アクセス制限されたサーバがハブを通したり、 いくつかのルーティング層を通したりしてクライアントに接続する場合、 -NFS はあまりにも危険な方法かもしれず ( ネットワークの面で )、ssh の方が +NFS はあまりにも危険な方法かもしれず ( ネットワークの面で )、SSH の方が 認証の道筋は跡となって残りますが、それでもより良い方法かもしれません。 .Pp アクセス制限されたマシンに、少なくとも監視することを前提とした クライアントシステムへの読み込みアクセスをひとたび与えると、 実際に監視するためのスクリプトを書かなくてはいけません。 NFS マウントをすれば、 .Xr find 1 や .Xr md5 1 などの単純なシステムユーティリティでスクリプトを書くことができます。 -少なくとも 1 日 1 回、クライアントのファイルを直接 md5 にかけ、 -さらにもっと頻繁に +少なくとも 1 日 1 回、クライアントのファイルを直接 +.Xr md5 1 +にかけ、さらにもっと頻繁に .Pa /etc および .Pa /usr/local/etc にあるようなコントロール用ファイルを試験するのが一番です。 試験ファイルは、アクセス制限されたマシンが適性であると知っている、基となる -md5 情報と比べて違いが見つかった場合、システム管理者に調べて欲しいと +MD5 情報と比べて違いが見つかった場合、システム管理者に調べて欲しいと 訴えるようにするべきです。 優れたセキュリティ用スクリプトは、 .Pa / および .Pa /usr -などのシステムパーティション上で不適当に suid されたバイナリや、 +などのシステムパーティション上で不適当に SUID されたバイナリや、 新たに作成されたファイルや削除されたファイルもチェックするのでしょう。 .Pp -NFS ではなく、ssh を使用する場合は、セキュリティ用スクリプトを書くのはずっと +NFS ではなく、SSH を使用する場合は、セキュリティ用スクリプトを書くのはずっと 難しいことです。スクリプトをクライアントから見えるようにし、 動かすためには、クライアントに対して -.Pa scp +.Xr scp 1 を必ず行わなくてはいけません。 -そして、安全のため、スクリプトが使うバイナリ ( find など ) を scp する必要も -あります。クライアントの ssh デーモンはすでに危険に晒されているかもしれません。 -以上のことから、安全でないリンク上の場合は ssh は必要かもしれませんが、 -ssh を扱うのはとても大変なことです。 +そして、安全のため、スクリプトが使うバイナリ ( +.Xr find 1 +など ) を +.Xr scp 1 +する必要もあります。クライアントの +.Xr sshd 8 +デーモンはすでに危険に晒されているかもしれません。 +以上のことから、安全でないリンク上の場合は SSH は必要かもしれませんが、 +SSH を扱うのはとても大変なことです。 .Pp 優れたセキュリティ用スクリプトは、ユーザやスタッフメンバの アクセス設定ファイルもチェックするものです。 -.Pa .rhosts , -.Pa .shosts , -.Pa .ssh/authorized_keys +.Pa .rhosts , .shosts , .ssh/authorized_keys などがそれですが、MD5 のチェックの範囲外になってしまうかもしれません。 .Pp ユーザ用のディスク容量が非常に大きい場合は、パーティション上の各ファイルを 見て回るのに大変な時間がかかるかもしれません。この場合は、マウントフラグを -設定して、このパーティションに suid されたバイナリやデバイスを置けないように +設定して、このパーティションに SUID されたバイナリやデバイスを置けないように するのが良い考えです。 -.Sq nodev +.Cm nodev および -.Sq nosuid +.Cm nosuid オプション ( .Xr mount 8 参照) が調べたいものでしょう。私なら、ともかくも週に 1 度はファイルシステムを スキャンするでしょう。なぜなら、この層での目的は、侵入が意味があるかどうかに 関わらず、侵入を検出することだからです。 .Pp プロセスアカウンティング ( .Xr accton 8 参照) は、比較的オーバヘッドの低いオペレーティングシステムの機能で、 マシンに侵入されてしまった後の評価の仕組みとして使用することをお勧め します。 侵入を受けた後でも当該ファイルが無傷である場合に、 侵入者が実際にどのようにしてシステムに侵入したかを 追跡するのに特に有益です。 .Pp 最後に、セキュリティスクリプトはログファイルを処理するようにし、 ログファイル自体もできるだけ安全性の高い方法で .Sq リモート syslog は極めて有益になり得ます 生成するようにすべきです。侵入者は自分の侵入の痕跡を覆い隠そう としますし、また、ログファイルはシステム管理者が最初の侵入の時 刻と方法を追跡してゆくために極めて重要です。 ログファイルを永久に残しておくための 1 つの方法は、システムコンソールを シリアルポートにつないで走らせ、コンソールを監視している安全なマシンを通して 絶えず情報を集めることです。 .Sh 偏執狂的方法 多少偏執狂的になっても決して悪いことにはなりません。原則的に、 システム管理者は、便利さに影響を与えない範囲でいくつでもセキュリティ 機能を追加することができます。また、いくらか考慮した結果、便利さに 影響を与えるセキュリティ機能を追加することもできます。 -もっと重要なことには、セキュリティ管理者とは少し喧嘩になる -はずなのですが、もしあなたが、このマニュアルページに書かれている -勧告をそのまま使用したりした場合は、 -予想されるクラッカーはやはりこのマニュアルを読んでいるわけですから、 -防御策を渡してしまうことになります。 -.Sh サービス不能攻撃 (D.O.S. attack) についての特記事項 +もっと重要なことは、セキュリティ管理者は少々ごちゃごちゃに +すべきだということです。 +というのも、このマニュアルページに書かれている勧告をそのまま使用した場合は、 +予想される攻撃者はやはりこのマニュアルを読んでいるわけですから、 +防御策を漏らしてしまうことになるからです。 +.Sh サービス不能攻撃 (DoS attack) についての特記事項 このセクションではサービス不能攻撃を扱います。サービス不能攻撃は、普通は、 パケット攻撃です。ネットワークを飽和させる最先端の偽造パケット .Pq spoofed packet 攻撃に対してシステム管理者が打てる手はそれほど多く ありませんが、一般的に、その種の攻撃によってサーバがダウン しないことを確実にすることで、被害をある限度に食い止める ことはできます。 .Bl -enum -offset indent .It サーバの fork の制限 .It 踏み台攻撃の制限 .Pq ICMP 応答攻撃、ping broadcast など .It カーネルの経路情報のキャッシュ .El .Pp 普通に見られるサービス不能攻撃に、fork するサーバプロセスに対する ものがあります。これは、サーバにプロセス・ファイル記述子・メモリを 食い尽くさせて、マシンを殺そうとするものです。 -inetd ( .Xr inetd 8 -参照) -には、この種の攻撃を制限するオプションがいくつかあります。マシンが +サーバには、この種の攻撃を制限するオプションがいくつかあります。マシンが ダウンすることを防止することは可能ですが、この種の攻撃によりサービスが 崩壊することを防止することは一般的に言ってできないことに注意する必要が -あります。inetd のマニュアルページを注意深く読んで下さい。特に、 -.Fl c , -.Fl C , -.Fl R -オプションに注意して下さい。IP 偽造攻撃 -(spoofed-IP attack) -は inetd の +あります。 +.Xr inetd 8 +のマニュアルページを注意深く読んで下さい。特に、 +.Fl c , C , R +オプションに注意して下さい。IP 偽造攻撃 (spoofed-IP attack) は +.Xr inetd 8 +の .Fl C オプションの裏をかけるので、一般にオプションを 組み合わせて使用するべきであることに注意して下さい。スタンドアロンサーバ の中には、自分自身で fork を制限するパラメータを持っているものがあります。 .Pp -sendmail には、 +.Xr sendmail 8 +デーモンには、 .Fl OMaxDaemonChildren オプションがあります。負荷には遅れがあるので、 -sendmail の負荷に限界を設けるオプションを使うよりも、 +.Xr sendmail 8 +の負荷に限界を設けるオプションを使うよりも、 このオプションを使う方がまともに動作する可能性ははるかに高いです。 sendmail の実行を開始する際に、 -.Cm MaxDaemonChildren +.Va MaxDaemonChildren パラメータを設定するべきです。その値は、 通常見込まれる負荷を扱える程度に十分高いが、 -それだけの数の sendmail を操作しようとすると +それだけの数の +.Xr sendmail 8 +を操作しようとすると マシンが卒倒してしまうほどには高くないような値に設定するべきです。 -sendmail をキュー処理モード +.Xr sendmail 8 +をキュー処理モード .Pq Fl ODeliveryMode=queued -で実行することや、 -sendmail デーモン -.Pq Cm sendmail -bd +で実行することや、デーモン +.Pq Dq Nm sendmail Fl bd をキュー処理用プロセス -.Pq Cm sendmail -q15m +.Pq Dq Nm sendmail Fl q15m と別に実行することも、用心深いことと言えます。それでもなおリアルタイムでの 配送を望むのであれば、 .Fl q1m のようにすることで、キュー処理をはるかに短い時間間隔で 行うことができます。いずれにしても、 -.Cm MaxDaemonChildren -オプションに -合理的な値を確実に指定して、sendmail がなだれをうって失敗することが -ないようにして下さい。 +.Va MaxDaemonChildren +オプションに合理的な値を確実に指定して、 +.Xr sendmail 8 +がなだれをうって失敗することがないようにして下さい。 .Pp -syslogd は直接攻撃される可能性があるので、可能ならばいつでも +.Xr syslogd 8 +デーモンは直接攻撃される可能性があるので、可能ならばいつでも .Fl s オプションを用いることを強く推奨します。これができないなら、 .Fl a オプションを使って下さい。 .Pp tcpwrapper の逆 identd などの接続返し (connect-back) を行うサービスに ついては十分注意を払うようにするべきです。これらは直接攻撃を受ける可能性が あります。こういう事情があるので、tcpwrapper の逆 ident 機能を使おうとは 思わないのが一般的です。 .Pp 境界ルータのところでファイアウォールを設けて、外部からのアクセスに対して 内部サービスを防御するという考えは実によいものです。この考えは、LAN の外部 からの飽和攻撃を防ぐことにあり、root ネットワークベースの root 権限への攻撃から内部サービスを防御することには、あまり考慮を払って いません。ファイアウォールは常に排他的に設定して下さい。つまり、 「ポート A, B, C, D と M から Z まで -.Eo * -以外 -.Ec * +.Em 以外 のすべてにファイアウォールを設ける」というふうにです。 -このようにすることで、named +このようにすることで、 +.Xr named 8 (ゾーンのプライマリである場合), -ntalkd, sendmail など、インターネットにアクセスを提供するサービス +.Xr talkd 8 , +.Xr sendmail 8 +など、インターネットにアクセスを提供するサービス として特に指定するもの以外の、小さい番号のポートすべてをファイアウォールで 防御することができます。ファイアウォールをこの他のやり方、つまり 包含的もしくは受容的なファイアウォールとして設定しようとする場合、 -.Sq close +.Dq close することを忘れてしまうサービスがいくつか出てきたり、新しい内部サービスを 追加したのにファイアウォールの更新を忘れたりする可能性がよく出てきます。 ファイアウォール上の大きい番号のポートを開けておいて、小さい番号のポートを 危険に晒すことなく受容的な動作を許すことができます。 .Fx -では、net.inet.ip.portrange への sysctl -.Pq Li "sysctl -a | fgrep portrange" +では、 +.Va net.inet.ip.portrange +への sysctl +.Pq Dq Li "sysctl net.inet.ip.portrange" , をいろいろ使用することで、 動的バインドに使用されるポート番号の範囲を制御できることを記憶にとどめて おいて下さい。これによりファイアウォールの設定の複雑性を緩和できます。 私は、ファイアウォールに通常のfirst/last の範囲として、 4000 から 5000 を、 高位ポートの範囲として、49152 から 65535 を使用しています。そして、 (いくつかのインターネットアクセス可能なポートを ブロックから除外するのはもちろんですが) 4000 より下のすべてをブロックしています。 .Pp また別のありふれたサービス不能攻撃として、踏み台攻撃 (springboard attack) と呼ばれるものがあります。これは、サーバが自分自身、ローカルネットワーク、 そして他のマシンを過負荷に追い込むような応答を生成させる方法でサーバを 攻撃します。この種の攻撃の中で最もありふれたものは、ICMP PING BROADCAST 攻撃があります。攻撃者は、実際に攻撃したいマシンのアドレスをソース アドレスに設定した ping パケットを偽造して、対象の LAN の ブロードキャストアドレスに向けてパケットを送信します。境界にあるルータが ブロードキャストアドレスに対する ping パケットを握り潰すように設定されていない 場合、LANは、詐称されたソースアドレスに向けて応答パケットを生成するはめになり、犠牲となるマシンが飽和するところまで行ってしまいます。攻撃者が同じトリックを 異なるネットワーク上のいくつものブロードキャスト アドレスに対して同時に使用した場合、とくにひどいことになります。 これまでに、120 メガビット以上のブロードキャスト攻撃が観測されています。 2 番目の踏み台攻撃は、ICMP エラー報告の仕掛けを狙うものです。ICMP エラー 応答を生成するパケットを生成することにより、攻撃者はサーバの 受信ネットワークを飽和させることができ、同時に、サーバが送信 ネットワークを ICMP 応答で飽和させるようにすることができます。 -mbuf を消費し尽くさせることにより、この種の攻撃でサーバを +.Vt mbuf +を消費し尽くさせることにより、この種の攻撃でサーバを クラッシュさせることも可能です。サーバの ICMP 応答生成が速過ぎて、 ICMP 応答の送信が追い付かない場合、とくにひどいことになります。 .Fx -カーネルには、この種の攻撃の効果を抑制する ICMP_BANDLIM と -呼ばれる新しいコンパイルオプションがあります。 -3つめの主要なクラスに属す踏み台攻撃は、udp echo サービスのような、 -ある種の内部 inetd サービスに関連するものです。攻撃者は、単に +カーネルには、この種の攻撃の効果を抑制する +.Dv ICMP_BANDLIM +と呼ばれる新しいコンパイルオプションがあります。 +3つめの主要なクラスに属す踏み台攻撃は、UDP echo サービスのような、 +ある種の内部 +.Xr inetd 8 +サービスに関連するものです。攻撃者は、単に ソースアドレスがサーバ A の echo ポートであり、ディスティネーション アドレスがサーバ B の echo ポートであるかのように UDP パケットを 偽造します。ここでサーバ A, B はともに自分の LAN に接続されています。 この 2 つのサーバは、この一つのパケットを両者の間で互いに相手に対して 打ち返しあいます。このようにしてパケットをいくつか注入するだけで、 攻撃者は両方のサーバと LAN を過負荷状態にすることができます。 同様の問題が内部 chargen ポートにも存在します。有能なシステム管理者は -この手の inetd 内部テストサービスのすべてを無効にしておくものです。 +この手の +.Xr inetd 8 +内部テストサービスのすべてを無効にしておくものです。 .Pp 偽造パケット攻撃は、カーネルの経路情報キャッシュに過負荷を生じさせるために -用いられることもあります。net.inet.ip.rtexpire, rtminexpire, rtmaxcache -の sysctl パラメータを参照して下さい。でたらめなソース IP を用いた +用いられることもあります。 +.Va net.inet.ip.rtexpire , net.inet.ip.rtminexpire , net.inet.ip.rtmaxcache +の +.Xr sysctl 8 +パラメータを参照して下さい。でたらめなソース IP を用いた この偽造パケット攻撃により、カーネルは、一時的なキャッシュ経路を 経路情報テーブルに生成します。これは -.Sq netstat -rna \&| fgrep W3 +.Dq Li "netstat -rna | fgrep W3" . で見ることができます。これらの経路は、普通は 1600 秒程度でタイムアウトに なります。カーネルがキャッシュ経路テーブルが大きくなり過ぎたことを -検知すると、カーネルは動的に rtexpire を減らしますが、rtminexpire より -小さくなるようには決して減らしません。ここに問題が 2 つあります。 +検知すると、カーネルは動的に +.Va rtexpire +を減らしますが、 +.Va rtminexpire +より小さくなるようには決して減らしません。ここに問題が 2 つあります。 (1) 負荷の軽いサーバが突然攻撃された場合、カーネルが十分素早く反応 できないこと。(2) カーネルが攻撃に耐え生き延びられるほど十分 -rtminexpire が低く設定されていないこと。の2つです。 +.Va rtminexpire +が低く設定されていないこと。の 2 つです。 自分のサーバが T3 もしくはそれより 良質の回線でインターネットに接続されている場合、 .Xr sysctl 8 -を用いて rtexpire と rtminexpire とを手動で上書きしておくことが思慮深いこと +を用いて +.Va rtexpire +と +.Va rtminexpire +とを手動で上書きしておくことが思慮深いこと といえます。 (自分のマシンをクラッシュさせたくないのであれば :-)) どちらか一方でも 0 に は決してしないで下さい。両パラメータを 2 秒に設定すれば、 攻撃から経路情報テーブルを守るには十分でしょう。 -.Sh kerberos および ssh を用いたアクセスの問題 -もしあなたが、kerberos および ssh を使用したいのだとしたら、両者に関して +.Sh Kerberos および SSH を用いたアクセスの問題 +もしあなたが、Kerberos および SSH を使用したいのだとしたら、両者に関して 言っておく必要のある問題がいくつかあります。 -kerberos V は大変優れた認証プロトコルですが、kerberos 処理された telnet や -rlogin は、バイナリストリームを扱うのに不向きになってしまうようなバグがあります。 -さらに、デフォルトでは、kerberos は +Kerberos5 は大変優れた認証プロトコルですが、kerberos 化された +.Xr telnet 1 +や +.Xr rlogin 1 +は、バイナリストリームを扱うのに不向きになってしまうようなバグがあります。 +さらに、デフォルトでは、Kerberos は .Fl x オプションを使わない限りセッションを暗号化してくれません。 -ssh では、デフォルトですべてを暗号化してくれます。 +SSH では、デフォルトですべてを暗号化してくれます。 .Pp -ssh はあらゆる場面でとても良く働いてくれます。ただし、 +SSH はあらゆる場面でとても良く働いてくれます。ただし、 暗号鍵を送ってしまう場合を除けばです。これはつまり、暗号鍵を持った安全な ワークステーションがあって、この暗号鍵で残りのシステムとアクセスできる -ようになっている場合では、安全でないマシンへ ssh を行なう時に暗号鍵が +ようになっている場合では、安全でないマシンへ +.Xr ssh 1 +を行なう時に暗号鍵が 見えてしまうということです。実際の鍵そのものが見えてしまうわけでは -ありませんが、ssh は、login を持続させるために配送用ポートを作ります。 -クラッカーが安全でないマシンの root を破ると、クラッカーは、 +ありませんが、 +.Xr ssh 1 +は、login している間、配送用ポートを作ります。 +攻撃者が安全でないマシンの root を破ると、攻撃者は、 このポートを使って暗号鍵を取得し、暗号鍵でロックの外れる他のマシンへの アクセスを得ます。 .Pp -staff のログインには、kerberos を組み合せた ssh を使用することを勧めます。 -ssh は、kerberos と一緒にコンパイルできます。こうすると、見えて -しまうかもしれない ssh 鍵をあまりあてにしないで良いようになります。 -また、それと同時に、kerberos 経由でパスワードを保護することもできます。 -ssh 鍵は、安全なマシンからの自動化されたタスク (kerberos では不向きな -ものなど ) 用のみに使用するべきです。また、ssh の設定で -ssh 鍵を送らないようにするか、あるいは、 +staff のログインには、Kerberos を組み合せた SSH を使用することを勧めます。 +SSH は、Kerberos と一緒にコンパイルできます。こうすると、見えて +しまうかもしれない SSH 鍵をあまりあてにしないで良いようになります。 +また、それと同時に、Kerberos 経由でパスワードを保護することもできます。 +SSH 鍵は、安全なマシンからの自動化されたタスク (Kerberos では不向きな +ものなど ) 用のみに使用するべきです。また、SSH の設定で +SSH 鍵を送らないようにするか、あるいは、 .Pa authorized_keys ファイル中で -.Pa "from=IP/DOMAIN" +.Va from Ns = Ns Ar IP/DOMAIN オプションを使用して、特定のマシンからログインしてきたもののみに -有効になる鍵を ssh が生成できるようにすることも勧めます。 +有効になる鍵を SSH が生成できるようにすることも勧めます。 .Sh 関連項目 .Xr chflags 1 , .Xr find 1 , .Xr md5 1 , .Xr netstat 1 , .Xr openssl 1 , .Xr ssh 1 , .Xr xdm 1 , .Xr group 5 , .Xr ttys 5 , .Xr accton 8 , .Xr init 8 , .Xr sshd 8 , .Xr sysctl 8 , .Xr syslogd 8 , .Xr vipw 8 .Sh 歴史 .Nm マニュアルページは、もともと .An Matthew Dillon によって書かれました。 最初に現れたのは、 .Fx 3.1 で 1998 年 12 月のことです。 .\" translated by Norihiro Kumagai, 98-12-29 diff --git a/ja_JP.eucJP/man/man7/tuning.7 b/ja_JP.eucJP/man/man7/tuning.7 index 0d25b7de26..b176d6104a 100644 --- a/ja_JP.eucJP/man/man7/tuning.7 +++ b/ja_JP.eucJP/man/man7/tuning.7 @@ -1,927 +1,917 @@ .\" Copyright (c) 2001, Matthew Dillon. Terms and conditions are those of .\" the BSD Copyright as specified in the file "/usr/src/COPYRIGHT" in .\" the source tree. .\" -.\" %FreeBSD: src/share/man/man7/tuning.7,v 1.62 2003/09/14 23:44:55 hmp Exp % +.\" %FreeBSD: src/share/man/man7/tuning.7,v 1.63 2004/06/06 12:30:21 schweikh Exp % .\" .\" $FreeBSD$ .Dd June 25, 2002 .Dt TUNING 7 .Os .Sh 名称 .Nm tuning .Nd FreeBSD における性能チューニング .Sh システム設定 - disklabel, newfs, tunefs, スワップ -.Xr disklabel 8 +.Xr bsdlabel 8 または .Xr sysinstall 8 を使ってハードディスク上にファイルシステムをレイアウトする場合、 ディスクの内周トラックよりも外周トラックのほうがずっと速くデータを 転送できることを意識することが重要です。 この利点を生かすには、 小さいファイルシステムやスワップを外周トラックに近いほうから 詰めていくべきです。 より大きいファイルシステムは内周へ近いほうへ詰めていき、 最も大きいファイルシステムを最後にします。 後でマシンを増強した時にシステム標準のファイルシステムの大きさを 変更しなくて済むような大きさに決めることが重要です。 私は大抵、順番にルートパーティションに 128M、スワップに 1G、 .Pa /var に 128M、 .Pa /var/tmp に 128M、 .Pa /usr に 3G、 そして残りを .Pa /home に割り当てます。 .Pp 典型的にはメインメモリの約 2 倍のスワップスペースを用意すべきです。 RAM がそれほど多くない場合は、一般にもっとスワップが必要でしょう。 256M より小さいスワップを設定するのは奨められません。 スワップ パーティションの大きさを決めるときは将来のメモリ増設のことを 考えておくべきです。 カーネルの VM ページングアルゴリズムは、スワップの大きさが メインメモリの少なくとも 2 倍ある場合に最高の 性能が出るようにチューンされています。 スワップを小さくしすぎると、 VM ページ走査コードが効率的に動かなくなります。 メモリをさらに追加した時も同様です。 最後に、複数の SCSI ディスク (あるいは異なるコントローラ上にある 複数の IDE ディスク) を備えた大規模なシステムにおいては、 それぞれのドライブにスワップを置くことを強く推奨します。 各ドライブ上のスワップパーティションがほぼ同じ大きさになる ようにしてください。 カーネルは任意の大きさを扱うことができますが、内部のデータ構造は 最大のスワップパーティションのものの 4 倍の大きさになってしまいます。 スワップパーティションをだいたい同じ大きさにすることで、 カーネルは最適な方法でスワップ空間を N 台のディスクに対し ストライピングします。 少々のやりすぎを気にする必要はありません。 スワップ空間は .Ux が優雅に動作するためのものです。 普段それほどスワップを使っていなくても、 プログラムの暴走で強制的にリブートしてしまう前に、 回復作業をするための時間稼ぎになります。 .Pp .Pa /var パーティションをどれだけの大きさにするかは、そのマシンを 何に使うかということに大きく依存します。 このパーティションは主にメールボックスやプリントスプール、 ログファイルの保存場所に使われます。 .Pa /var/log を別のパーティションにする人もいます (しかし、パーティション ID を 消費しないほうが良い極端な場合は例外です)。 メールサーバやプリントサーバ、あるいは 訪問数が非常に多い Web サーバとしてマシンが動作するなら、 極めて大きいパーティション \(en おそらく 1 ギガバイト以上 \(en を 作成することを考えるべきでしょう。 ログファイルの保存に必要な大きさは、小さく見積もられがちです。 .Pp .Pa /var/tmp の大きさは、テンポラリファイルの類が どれだけ使われる必要があるかで決まります。 最低でも 128M にすることを推奨します。 また sysinstall は .Pa /tmp ディレクトリも作成します。 テンポラリファイル領域専用に 1 つのパーティションを 割り当てることは重要で、2 つの理由があります: クラッシュ時のファイルシステムの破壊の可能性を 減らすのと、 .Oo Pa /var Oc Ns Pa /tmp を一杯にしてしまう ような暴走プロセスが、さらに重要なサブシステム (メールやログ等) に影響を与える可能性を減らすためです。 .Oo Pa /var Oc Ns Pa /tmp が一杯になってしまうのはよくある問題です。 .Pp かつては .Pa /tmp と .Pa /var/tmp の間には違いがありましたが、 .Pa /var (と .Pa /var/tmp ) の導入によってプログラマは大変混乱し、 今日では両方がでたらめに使われています。 つまりこの 2 つは実際には区別することができません。 したがって、1 つのテンポラリディレクトリだけにして、 他の .Pa tmp ディレクトリからここへソフトリンクを張ることは意味があります。 どのように .Pa /tmp を扱ったとしても、 それがルートパーティションにあるのは好ましくないでしょう。 一杯になったり、クラッシュやリブートにより破壊される 可能性があるからです。 .Pp .Pa /usr パーティションはシステムをサポートするために 必要なファイルの大部分を持っており、そのサブディレクトリ .Pa /usr/local は .Xr ports 7 階層からインストールされるファイルの大部分が置かれます。 ports をあまり使わず、システムのソース .Pq Pa /usr/src を保持するつもりがなければ .Pa /usr は 1 ギガバイトで十分でしょう。 しかし、大量の ports (特にウィンドウマネージャや Linux エミュレーションされるバイナリ) をインストールする場合は、 少なくとも 2 ギガバイトの .Pa /usr を推奨します。 さらに、システムのソースを保持するつもりであれば、3 ギガバイトの .Pa /usr を推奨します。 このパーティションに対して必要な領域の大きさを過小評価 しないでください。 これは緩やかに成長し、驚かされることになります ! .Pp .Pa /home パーティションはユーザ固有のデータを保持するのに使われます。 私は大抵ディスクの残りを使います。 .Pp 何故 パーティションを切るのでしょう ? 1 つの大きな .Pa / パーティションを作るだけで良いのではないでしょうか ? そうすれば小さすぎないかどうか気にする必要はないのに ! はい、その考えが良くないのは、いくつか理由があります。 1 つめは、それぞれのパーティションは運用上の性格が 異なるのですが、それらを分離することでファイルシステムに対し その性格に適したチューンをすることが可能になるからです。 例えばルートパーティションや .Pa /usr パーティションはほとんど読み込みであり、ほとんど書き込みがありません。 一方で .Pa /var や .Pa /var/tmp に対しては大量の読み込みや書き込みがあるでしょう。 システムをうまく分割することで、書き込みが多いパーティションの破壊に よる被害が、ほとんど読み込みのみのパーティションに及ばないようします。 加えて、書き込みが多いパーティションをディスクの端 (すなわちパーティションテーブルにおいて、 本当に大きなパーティションの後ろではなく、前の方) の方に置くことで、そのパーティションについて性能が向上します。 より大きなパーティションについても入出力性能が必要なのも確かですが、 .Pa /var をディスクの端に置くと大きな改善が可能であるのに対し、 巨大なパーティションをディスクの端に置いてもそれほど性能の 改善にはつながりません。 最後は安全性に関わることです。 小さく、簡潔な、本質的に読み込みのみの ルートパーティションとすることで、クラッシュを生き延びるチャンスを 大きくすることができます。 .Pp システムを正しく分割することで、 .Xr newfs 8 や .Xr tunefs 8 に与えるパラメータをチューンすることも可能になります。 .Xr newfs 8 のチューニングにはさらに経験が必要ですが、かなりの性能改善につながります。 比較的安全にチューンできる 3 つのパラメータがあります: .Em blocksize , .Em bytes/inode , .Em cylinders/group です。 .Pp .Fx は 8K または 16K のファイルシステムブロックサイズを使用した時に 最高の性能が得られます。 デフォルトは 16K であり、 ほとんどのアプリケーションで良い結果となりますが、 大きなファイルにランダムアクセスするアプリケーション (データベースサーバソフトウェア等) は例外です。 このようなアプリケーションでは、 小さなブロックサイズで良い結果となる傾向がありますが、 最近のディスクの特性においては、 小さなブロックサイズの使用は考慮に値しないでしょう。 16K より大きなブロックサイズを使用すると バッファキャッシュの断片化を招き、性能が低下します。 .Pp デフォルトは、 多大な inode を必要とするファイルシステムや、 多大な小ファイルを保持することを意図したファイルシステムには 向かないかもしれません。 このようなファイルシステムは、 8K または 4K のブロックサイズで作成されるべきです。 これはまた、小さなフラグメントサイズを指定する必要があります。 常にブロックサイズの 1/8 のフラグメントサイズにすることを推奨します (他のフラグメントサイズの割合ではあまりテストされていません)。 この場合の .Xr newfs 8 オプションは .Dq Li "newfs -f 1024 -b 8192 ..." となるでしょう。 .Pp 大きなパーティションに、データベースファイルのような 少数の大きなファイルを置くのであれば、 .Em bytes/inode の比率を増やすことができます。 これは、そのパーティションの inode の数 (ファイルやディレクトリの最大の数) を減らします。 inode の数を減らすことで、クラッシュ後の .Xr fsck 8 による修復時間を大幅に減らすことができます。 本当にこのパーティションに大きなファイルを置くのでない限り、 このオプションを使わないでください。 空き領域が大量にあるのにファイルを収容できなくなるかもしれません。 bytes/inode は、32768 か 65536 か 262144 とすることが推奨されます。 もっと大きな値にすることができますが、 .Xr fsck 8 による修復時間を増やすだけでしょう。 例えば、 .Dq Li "newfs -i 32768 ..." のようにして値を与えます。 .Pp .Xr tunefs 8 はファイルシステムをさらにチューンするのに使えます。 このコマンドは、シングルユーザモードで実行することができ、 ファイルシステムの再フォーマットは不要です。 しかし、おそらく最も誤って使用されているプログラムでしょう。 多くの人はファイルシステムの利用可能な空き領域を増やそうとして、 min-free 比率を 0 に設定します。 これはファイルシステムの猛烈な断片化につながるので、推奨されません。 ここで、唯一本当に価値がある .Xr tunefs 8 のオプションは、 .Dq Li "tunefs -n enable /filesystem" として .Em softupdates を有効にすることです (注意: .Fx 4.5 以降では .Xr newfs 8 に .Fl U オプションを与えることで softupdates を有効に することができます。 そして .Xr sysinstall 8 は、ルート以外のファイルシステムの softupdates を標準で 自動的に有効にします)。 softupdates はメタデータの性能、 主にファイルの作成と削除の性能を劇的に改善します。 大部分のファイルシステムで softupdates を有効にすることを推奨します。 しかしながら、ファイルシステムで softupdates を使うかどうか判断する際に 気をつけるべき 2 つの制限があります。 1 つめは、softupdates はクラッシュ時における ファイルシステムの一貫性は保証しますが、 未反映の物理ディスク書き込みより何秒か (1 分になることもあります!) おそらく遅れていることです。 クラッシュした場合、より多くの成果が消えてしまうかもしれません。 2 つめは、softupdates はファイルシステムブロックを解放するのを遅らせる ということです。 あるファイルシステム (例えばルートファイルシステム) が満杯近くの時に それに対する大規模な更新、たとえば .Dq Li "make installworld" をすると、空き領域を使い果たして更新が失敗してしまうことがあります。 そのため標準的なインストールではルートファイルシステムの softupdates を 有効にしません。 ルートファイルシステムは滅多に書き込まれませんので、性能上の損失はありません。 .Pp .Xr mount 8 実行時のいくつかのオプションはファイルシステムをチューンするのに役立ちます。 最も明らかで、しかも最も危険なのは .Cm async です。 これは決して使わないでください。 大変危険です。 比較的危険度が低く、より役に立つ .Xr mount 8 のオプションは .Cm noatime です。 通常 .Ux ファイルシステムは、ファイルやディレクトリにアクセスが あった場合は常に、その最終アクセス時刻を更新します。 .Fx では、この動作は遅延書き込みで行なわれ、 通常は大した負荷にはなりません。 しかし、大量のファイルが連続してアクセスされた場合、 バッファキャッシュがアクセス時刻の更新で汚染され 大きな負荷となります。 例えば、高負荷の web サイトや大量の読者を抱えるニューズサーバ では、この .Xr mount 8 のオプションで大きなパーティションにおける アクセス時刻の更新を停止することが考えられます。 根拠もなく、すべての場所でアクセス時刻の更新を停止しないでください。 例えば、 .Pa /var ファイルシステムは、慣習的にメールボックスを保持し、 新規メールのメールボックス中の有無判定に atime (および mtime) が使用されます。 読み込み専用パーティション、 .Pa / や .Pa /usr では、atime をオンにしておいた方が良いでしょう。 システムユーティリティには、atime フィールドを使用するものがあるので、 .Pa / では特に有用です。 .Sh ディスクのストライピング 大きなシステムでは、いくつかのドライブのパーティションを互いに ストライピングして、全体として巨大なパーティションを作ることもあります。 ストライピングは、入出力操作を複数のディスクに振り分けることで ファイルシステムの性能を向上させることができます。 .Xr vinum 8 および .Xr ccdconfig 8 ユーティリティは、シンプルなストライピングされたファイルシステムを 作るのに使われます。 一般に、ルートや .Pa /var/tmp のような小さなパーティション、 あるいは .Pa /usr のような本質的に読み込みのみのパーティションを ストライピングしても時間の無駄にしかなりません。 本当に入出力性能を必要とするパーティションのみをストライピングするべきです。 典型的には .Pa /var や .Pa /home あるいはデータベースや Web ページを 保持するカスタムパーティションです。 適切なストライプサイズを選ぶことも重要です。 ファイルシステムはメタデータを 2 の累乗の境界で格納する傾向にあり、 大抵はシークを増やすのではなく減らしたいでしょう。 これは、1152 セクタといったような、 シーケンシャルな I/O が両方のディスクをシークしないように、 かつメタデータが単一のディスクに集中するのではなく両方に分散するような、 中心を外れた (off-centered) 大きな ストライプサイズにしたい、ということを意味します。 本当に性能が必要なら、 .Fx がサポートする本物のハードウェア RAID コントローラを 使うことを勧めます。 .Sh sysctl によるチューニング .Xr sysctl 8 変数は、実行時に、システムの動作のモニタおよび制御を可能とします。 sysctl には、単にシステムの動作を報告するものもありますが、 システムの動作を変更するものもあります。 ブート時に .Xr rc.conf 5 を使用して設定可能なものもありますが、大部分は .Xr sysctl.conf 5 で設定可能です。 システムには数百の .Xr sysctl 8 変数が存在します。 そのなかには、チューニングの候補のように見えますが本当は そうでないものも多く含まれます。 この文書では システムに最も大きな影響を与えるものだけを扱います。 .Pp .Va kern.ipc.shm_use_phys sysctl は、デフォルトが 0 (オフ) であり、 0 (オフ) または 1 (オン) にセットすることができます。 このパラメータを 1 にセットすると、全ての System V 共有メモリセグメントが ページング不可の物理メモリにマップされます。 これは、(A) 大量 (数百) のプロセス間で少量の共有メモリを マッピングしているか、(B) 任意個のプロセス間で大量の共有メモリを マッピングしている、のいずれかの場合に効果があります。 この機能は、共有メモリをスワップ不可にすることで、 共有メモリをコアに結び付ける時に生じる、 カーネルにおける内部のメモリ管理によるページ追跡 オーバヘッドをかなり減らします。 .Pp .Va vfs.vmiodirenable sysctl は、デフォルトは 1 (オン) です。 このパラメータは、ディレクトリがシステムによってどのように キャッシュされるかを制御します。 ほとんどのディレクトリは小さく、 ファイルシステムにおいては単一フラグメント (典型的には 1K) であり、バッファキャッシュではさらに小さくなっています (典型的には 512 バイト)。 しかし、デフォルトモードで動作している時は、 大量のメモリを搭載していても バッファキャッシュは固定数のディレクトリしかキャッシュしません。 この sysctl をオンにすると、バッファキャッシュが VM ページキャッシュを、ディレクトリをキャッシュするために使うことを可能に します。 これによる利点は、全てのメモリがディレクトリを キャッシュするのに使えるようになるということです。 欠点は、キャッシュに使われる最小のメモリの大きさが 512 バイトではなく 物理ページサイズ (大抵は 4K) になることです。 メモリに制約があるシステムでは、 このオプションをオフにすることを推奨します。 一方、オンにすると、多数のファイルを操作するサービスの性能が向上します。 そのようなサービスには、web キャッシュや、大規模なメールシステム、 ニューズシステムなどが含まれます。 このオプションは一般に メモリを消費しますが、性能を削減することはありません。 ただし実験して調べてみるべきでしょう。 .Pp .Va vfs.write_behind sysctl は、デフォルトで 1 (オン) です。 これによって、 ファイルシステムからメディアへの書き込みが、クラスタ分が集まった時に 発行されるようになります。 そのような状況は、典型的には、大きな シーケンシャルファイルへ書き込んでいる時に起こります。 これは、I/O パフォーマンスに寄与しないであろう場合に、 ダーティなバッファでバッファキャッシュが飽和するのを避けるという アイデアです。 しかしながら、これによってプロセスが止まるかも しれないので、状況によっては この機能を切りたいと望むかもしれません。 .Pp .Va vfs.hirunningspace sysctl は、任意の時点においてシステム全体で、 ディスクコントローラのキューに入れて未完了状態にして良い、 書き込み I/O の量を決定します。 通常、デフォルト値で十分ですが、 ディスクをたくさん持つマシンでは 4、5メガバイトに増やしたくなるかもしれません。 値を大きくしすぎる (バッファキャッシュの 書き込みの閾値を超えて) と、クラスタリングの効果が極端に悪くなる 可能性があるので注意してください。 この値を思いつきで大きくしては いけません! また書き込みのキュー値を大きくすると、同時に発生した 読みだしが待たされるかもしれません。 .Pp 他にもバッファキャッシュと VM ページキャッシュに関連した、様々な sysctl が 存在します。 これらを変更することは推奨されません。 .Fx 4.3 について言えば、VM システムは自分自身のチューニングに関して大変良い 仕事をしています。 .Pp .Va net.inet.tcp.sendspace sysctl と .Va net.inet.tcp.recvspace sysctl は、ネットワークに関連するアプリケーションを 稼動している場合は特に重要です。 これは、TCP コネクションの 送信および受信バッファ領域の大きさを調節します。 デフォルトでは、送信バッファは 32K で、受信バッファは 64K です。 このデフォルトを増やすことで 各コネクションについてカーネルメモリがさらに消費されますが、 帯域幅の利用率が改善することがあります。 同時に数百とか数千のコネクションを扱っている場合、 このデフォルトを増やすことは推奨されません。 失速してしまったコネクションが蓄積することで、 システムがメモリをすぐに使い果たしてしまうからです。 しかし、少ない数のコネクションについて広い帯域幅が必要ならば、 特にギガビットイーサネットの場合、このデフォルトを大幅に増やす ことができます。 入力データと出力データのバッファを個別に調整することができます。 たとえば、主に web サービスをしているマシンならば recvspace を 減らすことで、それほど大量にカーネルメモリを消費せずに sendspace を増やすことができます。 経路表 ( .Xr route 8 を参照 ) に対しては、経路に特化した送受信バッファを導入することが できるということに注意してください。 .Pp 付加的な管理ツールとして、ファイアウォールルールにおいて パイプ (pipe) を使うことで ( .Xr ipfw 8 を参照)、特定の IP ブロックやポートへ行く、あるいはそこから 来る帯域幅を制限することができます。 例えば T1 回線を持っている場合、 web トラフィックは回線の 70% に制限し、残りをメールと インタラクティブな用途に使いたいと思うでしょう。 通常高い負荷の web サーバは、ネットワーク回線が 使い切られていても、他のサービスに大きな遅延を与えることは ありませんが、制限をかけることは物事を円滑にし長期的な安定につながります。 また、多くの人が、帯域超過による課金をされないように 意図的な帯域制限をかけています。 .Pp .Va net.inet.tcp.rfc1323 sysctl で制御可能な TCP プロトコルのウィンドウスケーリング拡張を 両方のホストがサポートしない限り、 TCP の送信あるいは受信バッファサイズを 65535 を超えて指定しても ほとんど性能の改善はありません。 ある種のネットワークリンクから良い性能を引き出すために、 これらの拡張を有効にし、 TCP バッファサイズを 65536 より大きく設定すべきです。 特に、ギガビット WAN リンクや、高レイテンシの衛星リンクが対象となります。 RFC1323 サポートは、デフォルトでオンになっています。 .Pp .Va net.inet.tcp.always_keepalive sysctl は、TCP 実装が、コネクション上に断続的に .Dq keepalives を配送することで死んでしまった TCP コネクションの検出を試みるか どうかを決定します。 デフォルトで、これはすべてのアプリケーションについて許可されています。 この sysctl を 0 に設定すると、特に keepalives を要求した アプリケーションだけが検出機能を利用できます。 大抵の環境において、死んでしまった TCP コネクションを失効にすることで、 TCP keepalives はシステム状態の管理を改善します。 特にダイヤルアップのユーザにサービスを提供しているシステムでは 効果があります。 なぜならユーザがネットワークとのコネクションを切る前に いつも個々の TCP コネクションを終了するとは限らないからです。 しかしながら、ある種の環境では、一時的なネットワークの停止が 誤ってセッションの死と判断されるかもしれません。 結果として 予期しない TCP コネクションの終了となります。 その様な環境では、sysctl を 0 に設定することで、 TCP のセッション切断の発生を減らせるかもしれません。 .Pp .Va net.inet.tcp.delayed_ack TCP 機能は大きく誤解されています。 歴史的には、この機能は、転送されたデータに対する確認応答を、 応答と共に返せるようにするためにデザインされました。 例えば、リモートシェル上でキー入力しているとき、 あなたが送信した文字への確認応答は、文字のエコーを表すデータと共に返されます。 遅延確認応答をオフにすると、 リモートサービスが丁度受け取ったデータをエコーする機会を得る前に、 確認応答がそれだけを含むパケットで送られてしまうかもしれません。 この同じ考え方がすべての対話的プロトコル (例 SMTP, WWW, POP3) にあてはまり、 ネットワークの片一方を流れている小パケットを減らせるのです。 .Fx の遅延確認応答の実装も、TCP プロトコルの規則に従っています。 すなわち、標準の 100ms のタイムアウトが経過しなくても、 2 パケットに 1 回は確認応答を行います。 通常、遅延確認応答が行う最悪のことは、コネクションの破壊を少々遅らせること、 スロースタート TCP コネクションの立ち上がりを少々遅らせることです。 確かなことは分かりませんが、 SAMBA や SQUID といった package に関連する FAQ が 遅延確認応答をオフにするように勧めているのは、 スロースタートの問題に言及しているのでしょう。 .Fx では、スロースタートフライトサイズを .Va net.inet.tcp.slowstart_flightsize sysctl で増やすことの方が、遅延確認応答をオフにするより、利益があるでしょう。 .Pp .Va net.inet.tcp.inflight_enable sysctl は、すべての TCP コネクションに対し、 バンド幅と遅延の積による制限を適用します。 システムは、各コネクションに対してバンド幅と遅延の積を計算し、 ネットワークにキューされるデータ量を、 最適なスループットを確保するのに必要な量に限定しようとします。 この機能が有用なのは、モデムやギガビットイーサや高速 WAN リンク (といったバンド幅と遅延の積が大きなネットワーク) 経由でデータを 提供している場合であり、 特に有用なのは、ウィンドウスケーリングを併用している場合や 大きな送信ウィンドウを設定した場合です。 本オプションを有効にする場合、 .Va net.inet.tcp.inflight_debug を 0 (デバッグ無効) に設定することを忘れずに。 実運用では、 .Va net.inet.tcp.inflight_min を少なくとも 6144 に設定すると有用でしょう。 しかしながら、最低値を大きく設定すると、 リンクによってはバンド幅制限を無効にする結果となり得ることに注意してください。 本限定機能は、 中間ルータやスイッチのパケットキューに蓄積されるデータ量を減らし、 ローカルホストのインタフェースキューに蓄積されるデータ量をも減らします。 キューされるパケット数が少ないと、対話的コネクション、 特に低速モデム経由のものは、短い往復時間での動作が可能になります。 しかしながら、この機能はデータ送信 (アップロード / サービス側) にのみ影響することに注意してください。 データ受信 (ダウンロード) には影響しません。 .Pp .Va net.inet.tcp.inflight_stab の調整はお勧めしません。 このパラメータのデフォルトは 20 であり、 バンド幅と遅延の積のウィンドウ計算に対して 2 個の極大パケットが追加されることを示します。 アルゴリズムの安定化のために、追加のウィンドウが必要となり、 状態の変化に対する応答性を高めます。 しかしながら、遅いリンク越しでは、ping の遅延を大きくしてしまいます (それでも、inflight アルゴリズム無しと比べれば、低いものです)。 このような場合、このパラメータを 15, 10, 5 に減らし、 .Va net.inet.tcp.inflight_min も (例えば 3500 へ) 減らすことで、望む効果が得られるかもしれません。 これらのパラメータを減らすのは、最終手段としてください。 .Pp .Va net.inet.ip.portrange.* sysctls は、 自動的に TCP や UDP ソケットに結合されるポート番号の範囲を制御します。 3 種類の範囲があります。 すなわち、下位の範囲、デフォルトの範囲、高位の範囲であり、 .Dv IP_PORTRANGE .Xr setsockopt 2 呼び出しで選択可能です。 ほとんどのネットワークプログラムが使用するのはデフォルトの範囲であり、 .Va net.inet.ip.portrange.first と .Va net.inet.ip.portrange.last で制御されます。 それぞれ 1024 と 5000 がデフォルトです。 範囲を限定されたポート範囲は外向きコネクションに使用され、 ある条件下ではシステムがポートを使い尽してしまう場合があります。 これは、高負荷のウェブプロキシを実行している場合に、よく発生します。 通常のウェブサーバ等の主に内向きコネクションを扱うサーバや、 メールリレー等の外向きコネクションが限られているサーバを実行している場合、 これは問題とはなりません。 ポートを使い果たしてしまう場合、適度に .Va net.inet.ip.portrange.last を増やしてみてください。 10000, 20000, 30000 といった値は大丈夫でしょう。 ポートの範囲を変えるときには、ファイアウォールの影響も考慮に入れるべきです。 ファイアウォールによっては、広い範囲のポート (通常は下位のポート) を遮蔽し、システムが高位のポートを外向きコネクションに 使用することを期待します。 このため、 .Va net.inet.ip.portrange.first を低下させることはお勧めできません。 .Pp .Va kern.ipc.somaxconn sysctl は、新しい TCP コネクションを受け付けるための listen キューの サイズを制限します。 高負荷の web サーバ環境では、 デフォルト値の 128 は新しいコネクションを余裕をもって扱うには低すぎます。 そのような環境では、この値を 1024 以上に増やすことが推奨されます。 サービスデーモン (例えば .Xr sendmail 8 や apache) は自分自身の listen キューのサイズを制限しているかもしれませんが、設定ファイルで キューのサイズを増やすディレクティブを持つようになるでしょう。 listen キューを大きくすることは、サービス拒否攻撃を防ぐのにも役立ちます。 .Pp .Va kern.maxfiles sysctl は、システムがどれだけの数のファイルをオープンできるかを 決めます。 デフォルトは典型的には数千ですが、データベースや記述子を 大量に使うデーモンを稼働している場合は 10000 や 20000 に引き上げる必要 があるかもしれません。 読み込み専用の .Va kern.openfiles sysctl を検査することで、システム上で開かれているファイル数を判定可能です。 .Pp .Va vm.swap_idle_enabled sysctl は、多数のユーザがシステムに出入りして大量のアイドルプロセスが ある大きなマルチユーザシステムで便利です。 そのようなシステムでは、フリーメモリの予約に対し、 継続して重大な負担をかける傾向にあります。 これをオンにして .Va vm.swap_idle_threshold1 sysctl と .Va vm.swap_idle_threshold2 sysctl でスワップアウトヒステリシス (アイドルの秒数) を調整することで アイドルプロセスに与えられているページの優先度を通常のページアウト アルゴリズムよりも速やかに下げることができます。 これはページアウトデーモンを手助けします。 必要がないかぎり、 このオプションはオンにしないでください。 これによって起こるトレードオフは、本質的に、 スワップとディスク帯域幅をより多く消費してメモリのプリページングを より早いうちに行うことだからです。 小さなシステムではこのオプションは有害となるでしょうが、 すでにある程度ページングが発生している大きなシステムでは、 このオプションによって、全体のプロセスがより容易にメモリへ入ったり 出たりするようにできるでしょう。 .Sh ローダのチューナブル システムの動作の一部は、 そのためのメモリ割り当てをブート処理の初期に行う必要があるために、 実行時には調整不可能です。 ローダのチューナブルを変更するには、これらの値を .Xr loader.conf 5 に設定し、システムをリブートする必要があります。 .Pp .Va kern.maxusers は、静的なシステムテーブルの大きさを制御します。 これには、 オープンファイルの最大数、ネットワークメモリ資源の大きさ等が含まれます。 .Fx 4.5 の時点では、 .Va kern.maxusers は、ブート時に、システムで利用可能なメモリ量に応じて、 大きさが自動的に決定されます。 また、実行時に、読み取り専用の .Va kern.maxusers sysctl 値を見て決定することも可能です。 サイトによっては、 .Va kern.maxusers を大きくしたり小さくしたりする必要があり、 これはローダチューナブルで設定可能です。 64, 128, 256 は、変な値ではありません。 膨大なファイル記述子が必要なのでない限り、 256 より大きくすることは勧められません。 .Va kern.maxusers によってデフォルト値が決定される多くのチューナブル値は、 本文書の別の場所に記述した方法で、 個々にブート時または実行時に上書き可能です。 .Fx 4.4 より古いシステムでは、 カーネルの .Xr config 8 オプションの .Cd maxusers を設定する必要があります。 .Pp .Va kern.ipc.nmbclusters を調整することで、システムが割り当てようとしている ネットワーク mbuf の数を増やすことができます。 それぞれのクラスタは約 2K のメモリに相当するので、 1024 は 2M のカーネルメモリをネットワークバッファに 予約することを示します。 簡単な計算でどれだけ必要なのかがわかります。 web サーバが同時に最大 1000 本のコネクションを扱い、 各コネクションが 16K の受信バッファと 16K の送信バッファを消費する場合、 約 32MB に相当するネットワークバッファを扱う必要があります。 経験から得た方法によると、2 倍すると良いとされています。 つまり 32MBx2 = 64MB/2K = 32768 です。 したがって、この場合は .Va kern.ipc.nmbclusters を 32768 に設定します。 中くらいの量のメモリが搭載されたマシンでは 1024 から 4096、 さらに大量のメモリが搭載されているなら 4096 から 32768 の値を 推奨します。 決して大きい値を指定すべきではありません。 ブート時にクラッシュを引き起こす可能性があります。 .Xr netstat 1 に .Fl m オプションを与えることで、ネットワーククラスタの使用状況が分かります。 古い .Fx ではこのチューナブルを持ちませんので、 代りにカーネルの .Xr config 8 オプションの .Dv NMBCLUSTERS を設定する必要があります。 .Pp ますます多くのプログラムが .Xr sendfile 2 システムコールを使ってネットワークを通じてファイルを 転送しています。 .Va kern.ipc.nsfbufs sysctl は .Xr sendfile 2 の実行時にファイルシステムバッファをどれだけの数だけ 使えるかを制御します。 通常このパラメータは .Va kern.maxusers に比例しているので、極端な場合を除いては このパラメータに手を出す必要はありません。 詳細は、 .Xr sendfile 2 マニュアルページの .Sx チューニング 節を参照してください。 .Sh カーネル構成におけるチューニング 大規模なシステムでは、いくつかのカーネルオプションを操作しなければ ならないかもしれません。 これらのオプションを変更する場合、あなたは ソースから新しいカーネルをコンパイルできなければなりません。 .Xr config 8 マニュアルページやハンドブックが良い入門となるでしょう。 あなただけのカスタムカーネルを作るときに一般に最初にすることは、 使用しないドライバやサービスをすべて削ることです。 .Dv INET6 や使わないドライバを削除することで、カーネルのサイズを時に 1 メガバイト以上減らすことができ、アプリケーションにさらに メモリを与えることができます。 .Pp .Dv SCSI_DELAY と .Dv IDE_DELAY は、システムの起動時間を減らすために使うことができます。 このデフォルト値はかなり大きく、ブート処理の中で 15 秒以上を占めるでしょう。 .Dv SCSI_DELAY を 5 秒に減らしても大抵はうまく動きます (特に最近のドライブでは)。 .Dv IDE_DELAY を減らしてもうまくいきますが、少々慎重になる必要があります。 .Pp .Dv *_CPU オプションの多くはコメントアウトできます。 そのカーネルを Pentium クラスの CPU だけで動かすなら、 .Dv I386_CPU と .Dv I486_CPU は削除することができます。 ただし、 .Dv I586_CPU は、CPU が Pentium II 以上として認識されることを確認してから 削除してください。 Pentium や 486 としてさえ認識されるクローンが存在し、 その場合はこれらのオプションがないと起動することができません。 もし動いたらすごいことです ! オペレーティングシステムは、MMU や タスク切り替え、タイムベース、デバイス操作に至る、より高度な機能を より利用することができるようになります。 加えてより高度な CPU は、カーネルがカーネル自身をメモリにマップする 4MB の MMU ページをサポートします。 これは高いシステムコール負荷の 下での効率を上げます。 .Sh IDE ライトキャッシュ .Fx 4.3 では IDE のライトキャッシュがオフになりました。 これは IDE ディスクへの書き込み帯域幅を減らしてしまうことになりますが、 ハードドライブベンダに起因するデータの一貫性に関する重大な問題のために、 必要なことだと考えられました。 基本的には、書き込み完了時期について IDE ドライブが嘘をつくという問題です。 IDE ライトキャッシュがオンであると、 IDE ハードドライブはデータを順番に書きこまないばかりか、 ディスクの負荷が高い時にはいくつかのブロックの書き込みを 無期限に延期してしまいます。 クラッシュや電源故障の場合、ファイルシステムの重大な破壊を もたらします。したがって私たちはデフォルトを安全側に変更しました。 残念ながら、これは大変な性能の低下をもたらし、私たちはあきらめて このリリース後にオンに戻しました。 .Va hw.ata.wc sysctl 変数を見て、デフォルトをチェックしてみるべきです。 もし IDE ライトキャッシュがオフになっていたら、 .Va hw.ata.wc ローダチューナブルを 1 に設定することでオンに戻すことができます。 ATA ドライバシステムのチューニングに関する更なる情報は、 .Xr ata 4 を参照してください。 -.Pp -IDE ハードドライブの実験的な新機能として、 -.Va hw.ata.tags -と呼ばれるものがあり (これもブートローダで設定します)、 -ライトキャッシュを安全にオンにすることができます。 -これは SCSI のタギング機能を IDE ドライブに持ち込んだものです。 -これを書いている時点では、IBM DPTA と DTLA ドライブだけがこの機能を -サポートしています。 -警告! これらのドライブは品質管理に問題 -があるようなので、私は現時点ではこれらの製品を買うことはおすすめしません。 性能が必要なら SCSI を使いましょう。 .Sh CPU、メモリ、ディスク、ネットワーク 負荷が上がるとシステムのどの部分がボトルネックになりはじめているかによって、 チューニングの種類が違ってきます。 CPU を使い果たしている (アイドル時間が常に 0%) ならば、CPU を アップグレードしたり SMP マザーボード (CPU を複数にする) に移行 したり、あるいは負荷の原因となっているプログラムを見直して最適化する ことを考える必要があるでしょう。 スワップに対して大量のページングがあるなら メモリをもっと増やす必要があるでしょう。 ディスク性能が飽和している場合、CPU アイドル時間は高く、全般的に ディスクが飽和状態になっています。 .Xr systat 1 でこれらをモニタすることができます。 ディスク性能の飽和を解決するにはいろいろな方法があります: キャッシュのためのメモリを増やす、ディスクをミラーリングする、 複数のマシンに操作を分散させる等です。 ディスク性能が問題で、IDE ドライブを使っている場合、 SCSI に切り替えることでずいぶんよくなります。 生のシーケンシャルな帯域幅については、最近の IDE ドライブは SCSI のものに 匹敵していますが、調べると大抵 SCSI ドライブが勝っています。 .Pp 最後に、ネットワーク性能を使い果たしているかもしれません。 ネットワーク性能を改善するために最初に確認すべきことは、 ハブではなくスイッチを使っているか、ということです。 特に最近はスイッチは安くなっています。 ハブが高負荷になると、コリジョンバックオフのために深刻な問題が発生します。 また、1 台のホストに問題があると、LAN 全体の性能を大幅に低下させます。 次に、できるだけネットワーク経路を最適化することです。 例えば .Xr firewall 7 で説明した内部ホストを守るファイアウォールでは、 外部から見えるホストはファイアウォールを通さないトポロジです。 必要に応じて 10BaseT ではなく 100Base-T を、あるいは 100BaseT ではなく 1000BaseT を使いましょう。 最大のボトルネックは WAN 回線です (モデム、T1、DSL 等)。 回線を増強できないのであれば、 .Xr dummynet 4 機能を使ってピーク削減やその他のトラフィックシェイピングを 行い過負荷のサービス (web サービス等) が他のサービス (電子メール等) に影響を与えるのを防いでください。逆もまた同様です。 これは、家庭環境において、外部に公開しているサービス (web サービスや電子メール) よりも インタラクティブなトラフィック (ブラウザや .Xr ssh 1 ログイン) を 優先するために使うことができるでしょう。 .Sh 関連項目 .Xr netstat 1 , .Xr systat 1 , .Xr ata 4 , .Xr dummynet 4 , .Xr login.conf 5 , .Xr rc.conf 5 , .Xr sysctl.conf 5 , .Xr firewall 7 , .Xr hier 7 , .Xr ports 7 , .Xr boot 8 , +.Xr bsdlabel 8 , .Xr ccdconfig 8 , .Xr config 8 , -.Xr disklabel 8 , .Xr fsck 8 , .Xr ifconfig 8 , .Xr ipfw 8 , .Xr loader 8 , .Xr mount 8 , .Xr newfs 8 , .Xr route 8 , .Xr sysctl 8 , .Xr sysinstall 8 , .Xr tunefs 8 , .Xr vinum 8 .Sh 歴史 .Nm マニュアルページは、もともと .An Matthew Dillon によって書かれました。 最初に登場したのは .Fx 4.3 で、2001 年 5 月のことです。