FreeBSD 日本語マニュアル検索 (jman/japropos/jwhatis)


日本語 man コマンド類 (ja-man-1.1j_5) と日本語 man ドキュメント (ja-man-doc-5.4 (5.4-RELEASE 用) など) をインストールすると、以下のような man コマンド閲覧、キーワード検索が コンソールからできるようになります。

4.11-RELEASE-K, 5.4-RELEASE-K, 5.5-RELEASE-K, 6.0-RELEASE-K から 6.4-RELEASE-K, 7.0-RELEASE-K から 7.4-RELEASE-K, 8.0-RELEASE-K から 8.4-RELEASE-K, 9.0-RELEASE-K から 9.3-RELEASE-K, 10.0-RELEASE-K から 10.3-RELEASE-K, 11.0-RELEASE-K から 11.4-RELEASE-K, 12.0-RELEASE-K, 12.1-RELEASE-K は、 プライベート版 (小金丸が編集してまとめたもの) ですが、 より多くの翻訳したファイルが含まれています。 (5.4-RELEASE-K から 6.4-RELEASE-K, 7.0-RELEASE-K から 7.4-RELEASE-K, 8.0-RELEASE-K から 8.4-RELEASE-K, 9.0-RELEASE-K から 9.3-RELEASE-K, 10.0-RELEASE-K から 10.3-RELEASE-K, 11.0-RELEASE-K から 11.4-RELEASE-K, 12.0-RELEASE-K から 12.3-RELEASE-K, 13.0-RELEASE-K から 13.2-RELEASE-K は、全翻訳済み)

13.3-STABLE-K, 15.0-CURRENT-K は現在、作成中で日々更新されています。



検索コマンド: man apropos whatis
コマンド/キーワード:
日本語マニュアル RELEASE :
セクション:
Table of Contents
名称 | 書式 | 解説 | 互換性 | 関連項目 | 歴史 | バグ
YP(8)                  FreeBSD システム管理者マニュアル                  YP(8)

名称
     yp -- YP/NIS システムの説明

書式
     yp

解説
     YP サブシステムを使用すると、passwd, group, netgroup, hosts, services,
     rpc, bootparams, ethers の各ファイルのエントリを次の関数を通してネット
     ワーク管理することができます: getpwent(3), getgrent(3), getnetgrent(3),
     gethostent(3), getnetent(3), getrpcent(3)ethers(3)bootparamd(8)
     デーモンは、NIS ライブラリを直接呼び出します。なぜなら、標準 C ライブラリ
     では、bootparams を読み込む関数が存在しないからです。NIS サポートは、
     nsswitch.conf(5) で有効にします。

     YP サブシステムは、/etc/rc.conf ファイル中で初期設定されていて、かつ、
     /var/yp ディレクトリが存在していれば (デフォルトの配布物では存在していま
     す)、/etc/rc ファイル中で自動的に起動されます。デフォルトの NIS ドメイン
     は、domainname(1) コマンドで設定される必要があります。これについても、
     /etc/rc.conf ファイルで指定されていれば、システム起動時に自動的に行われま
     す。

     NIS は、RPC ベースのクライアント / サーバシステムであり、NIS ドメイン内の
     マシンのグループが同じ設定ファイルを共有できるようにするシステムです。NIS
     を使用することで、システム管理者は、最低限の設定データだけで NIS クライア
     ントシステムを立ち上げることができ、1 つの場所から設定データを追加した
     り、削除したり、変更したりすることができます。

     NIS のすべての情報の正当なコピーは、NIS マスタサーバと呼ばれる 1 つのマシ
     ン上に保存されます。情報を保存するのに使用されるデータベースは、NIS マッ
     プと呼ばれています。FreeBSD では、これらのマップは、/var/yp/<domainname>
     に保存されます。ここで、<domainname> は、サービスを受けている NIS ドメイ
     ン名です。1 つの NIS サーバで一度に複数のドメインをサポートすることができ
     ます。そのため、このような名前のディレクトリが複数あるということもあり得
     ます。サポートされるドメイン 1 つにつき、1 つのディレクトリを持ちます。ド
     メインは、それぞれ独立した NIS マップの集合を持っています。

     FreeBSD では、NIS マップは、Berkeley DB ハッシュのデータベースファイル
     (これは、passwd(5) データベースファイルで使用されているフォーマットと同じ
     ものです) になっています。他のオペレーティングシステムで、NIS をサポート
     しているものでは、古い形式の ndbm データベースを代わりに使用しています
     (その主な理由は、Sun Microsystems 社が最初に NIS の実装を ndbm 上で行な
     い、他のベンダは、単に Sun のコードのライセンスを受けただけで、自分達で別
     のデータベースフォーマットを使って実装を行わなかったからです)。これらのシ
     ステムでは、データベースは、通常 .dir ファイルと .pag ファイルに分けられ
     ています。ndbm コードは、これら 2 つのファイルを使って、ハッシュデータ
     ベースの別々の部分を保持するようになっています。Berkeley DB ハッシュの方
     法では、この 2 つの部分に分かれている情報を保持するのに単一のファイルを使
     います。つまり、他のオペレーティングシステムでは、passwd.byname.dir ファ
     イルと passwd.byname.pag ファイルがあるのに対し (これら 2 つは、どちらも
     同じマップの一部分です)、FreeBSD では、passwd.byname という名前のファイル
     がひとつあるだけです。このフォーマットの違いは、たいして重要ではありませ
     ん。NIS サーバ ypserv(8) そして関連のあるツール群だけが、NIS マップの
     フォーマットがどうなっているのかを知る必要があります。NIS クライアントシ
     ステムでは、NIS データは、すべて ASCII 形式で受け取ります。

     NIS システムには、主要な 3 つのタイプがあります。

     1.   NIS クライアント。これは、NIS サーバに情報の問い合わせをします。

     2.   NIS マスタサーバ。これは、NIS マップすべての正当なコピーを管理してい
          ます。

     3.   NIS スレーブサーバ。これは、NIS マップのバックアップコピーを管理して
          います。バックアップコピーは、定期的にマスタサーバが更新しています。

     NIS クライアントは、ypbind(8) デーモンを利用してそれぞれの NIS サーバとい
     わゆるバインドを確立します。ypbind(8) ユーティリティは、システムのデフォ
     ルトのドメインをチェックし (domainname(1) コマンドで設定されます)、RPC リ
     クエストをローカルネットワーク上でブロードキャストし始めます。ypbind(8)
     ユーティリティがバインドを確立しようとしているドメイン名は、これらのリク
     エストで指定します。リクエストのあったドメインのサービスを行うように設定
     されているサーバがこのブロードキャストメッセージを受け取ると、このサーバ
     は、ypbind(8) に対して応答します。そして、ypbind(8) は、このサーバのアド
     レスを記録するのです。もし、複数のサーバが使用可能であるなら (例えば、マ
     スタサーバ 1 台とスレーブサーバ数台というような場合)、ypbind(8) は、一番
     最初に応答してきたサーバのアドレスを使用します。この時点から、クライアン
     トシステムは、NIS リクエストをすべてこのサーバに送ります。ypbind(8) は、
     時々サーバに ``ping'' をかけ、サーバがまだ稼動中であることを確認します。
     この ping の応答を適切な時間内に受け取らない場合は、ypbind(8) は、バイン
     ドされていないという印をこのドメインにつけ、再度ブロードキャストを始めて
     別のサーバの場所を特定しようとします。

     NIS マスタサーバおよびスレーブサーバでは、NIS のリクエストは、すべて
     ypserv(8) デーモンで扱います。ypserv(8) ユーティリティは、NIS クライアン
     トから入ってくるリクエストを受け取り、リクエストされたドメインおよびマッ
     プ名を対応するデータベースファイルへのパスに変換し、そのデータベースから
     データを取り出してクライアントに送り返すという仕事をしています。特別なリ
     クエストの集合があり、ypserv(8) は、この集合を扱えるように設計されていま
     す。そのほとんどが標準 C ライブラリ内の関数として実装されています。

     yp_order()   この関数は、当該のマップの生成日時を調べます。

     yp_master()  この関数は、与えられたマップ / ドメインの NIS マスタサーバ名
                  を獲得します。

     yp_match()   この関数は、当該のマップ / ドメイン内で与えられたキーに対応
                  するデータを見つけます。

     yp_first()   この関数は、当該のマップ / ドメイン内の最初のキーとデータの
                  ペアを獲得します。

     yp_next()    この関数は、ypserv(8) に当該のマップ / ドメイン内のキーを渡
                  し、このキーのすぐ次にあるキーとデータの対を ypserv(8) に返
                  してもらいます (関数 yp_first() と yp_next() とを用いて、NIS
                  マップを順番に検索できます)。

     yp_all()     この関数は、マップの内容をすべて取り出します。

     この他にも、ypserv(8) が扱うことのできるリクエストは、いくつかあります
     (つまり、特定のドメインを扱うことができているのかどうかを応答するもの
     (YPPROC_DOMAIN) や、ドメインを扱うことができるときだけ応答し、そうでない
     ときには、黙っているもの (YPPROC_DOMAIN_NONACK) などです)。しかし、これら
     は、普通 ypbind(8) のみが生成するリクエストであり、標準のユーティリティで
     扱われるわけではありません。

     ホストが膨大にあるネットワーク上では、ただ 1 台のマスタサーバを使うより
     も、マスタサーバ 1 台と複数のスレーブサーバを使う方が良いことが多いもので
     す。スレーブサーバは、マスタサーバと全く同じ情報を提供します。ですから、
     マスタサーバ上のマップを変更するときはいつでも新しいデータを yppush(8) コ
     マンドを使ってスレーブサーバに伝達させるようにすべきです。NIS Makefile
     (/var/yp/Makefile) は、管理者が /var/yp/Makefile.local を作成して、NOPUSH
     変数を空にするなら、自動的に、これを行います:

         NOPUSH=

     (NOPUSH は、NIS サーバが 1 つだけの小さなネットワーク用になっているので、
     デフォルトで true に設定されています)。yppush(8) コマンドは、マスタサーバ
     とスレーブサーバとのトランザクションを開始します。その間に、スレーブサー
     バは、特定のマップをマスタサーバから、ypxfr(8) コマンドを用いて転送します
     (スレーブサーバは、ypserv(8) の内部から ypxfr(8) コマンドを自動的に呼び出
     します。そのため、管理者が直接 ypxfr(8) コマンドを実行する必要は普通あり
     ません。それでも、そうしたいなら、手作業で実行することもできます)。スレー
     ブサーバを維持管理すると、大きなネットワーク上の NIS のパフォーマンス向上
     に役立ちます。理由は、次の通りです。

     •   NIS マスタサーバがクラッシュした場合や参照できない場合に、バックアッ
         プサービスを提供します。

     •   マスタサーバの負荷が過度に増してしまわないように、クライアントの負荷
         を複数のマシンに分散します。

     •   1 つの NIS ドメインをローカルネットワークを越えて使用できます (サーバ
         が ypbind(8) のブロードキャストの範囲外にあれば、ypbind(8) デーモン
         は、サーバの位置を自動では決定できません。ypset(8) コマンドを使って
         ypbind(8) デーモンが特定のサーバとバインドを確立するようにすることは
         できますが、このようにすると不便なことがあります。この問題は、スレー
         ブサーバをローカルネットワーク上に置くだけで簡単に回避できます)。

     FreeBSD の ypserv(8) は、FreeBSD のクライアントシステムだけを使った場合、
     (他の NIS の実装よりも) 強化されたセキュリティを提供するように設計されて
     います。FreeBSD のパスワードデータベースシステム (これは、4.4BSD からその
     まま受け継がれたものです) には、「シャドウパスワード」のサポートが含まれ
     ています。標準的なパスワードデータベースには、暗号化されたユーザパスワー
     ドは、含まれていません。かわりに、暗号化されたパスワードは、(他の情報と一
     緒に) スーパユーザのみがアクセス可能なデータベースに分けて保存されていま
     す。暗号化されたパスワードが NIS マップとして入手できるとしたら、このセ
     キュリティは、全体的に機能しなくなるでしょう。なぜなら、ユーザは、誰でも
     NIS のデータを取得できるからです。

     暗号化されたパスワードを NIS 経由で取得されないようにするため、FreeBSD の
     NIS サーバでは、特殊な方法でシャドウパスワードマップ
     (master.passwd.byname, master.passwd.byuid, shadow.bynameshadow.byuid) を扱います。サーバは、特権ポートで生成されたリクエストに対
     する応答をするときのみ、シャドウパスワードマップにアクセスします。特権
     ポートへの接続が許されているのは、root だけなので、サーバは、そのようなリ
     クエストは、すべて特権ユーザ (root) からのものであると仮定するわけです。
     その他のポートからのアクセスは、すべて拒否されます。特権のないポートから
     リクエストを出してもサーバからはエラーコードが返ってくるだけです。さら
     に、FreeBSD の ypserv(8) は、Wietse Venema の tcp ラッパパッケージをサ
     ポートしています。tcp ラッパのサポートを有効にすると、管理者は、ypserv(8)
     が限られたクライアントマシンに対してのみ応答するように、設定可能です。

     これらの機能強化によって、普通の NIS よりも優れたセキュリティを提供できま
     すが、それでも決して 100 パーセント有効であるわけではありません。ネット
     ワークにアクセスできる誰かがサーバをだましてシャドウパスワードマップを開
     示させるようにすることがそれでも可能なのです。

     クライアント側では、FreeBSD の getpwent(3) 関数は、自動的に master.passwd
     マップを検索し、存在していたらそれを使います。もし、マップが存在していた
     ら、それを使い、これら特別なマップの全フィールド (クラス、パスワードが使
     われている期間、そしてアカウントの有効期限) をデコードします。もし、存在
     していないなら、標準の passwd マップが代わりに使われます。

互換性
     FreeBSD ではない NIS サーバを passwd(5) ファイルに対して適用する場合は、
     FreeBSD でパスワードに使用しているデフォルトの MD5 形式は、恐らく使用でき
     ないでしょう。もしそうであれば、互換性を確保するため login.conf(5) に設定
     している passwd_format の値を "des" と変更してください。

     システムによっては、例えば SunOS 4.x などでは、ホスト名を解決する関数
     (gethostbyname(), gethostbyaddr() など) が正しく作動するためには、NIS が
     動作している必要があるものがあります。こういったシステムでは、ypserv(8)
     デーモンは、hosts.byname あるいは hosts.byaddr マップ中に存在していないホ
     ストに関する情報を返すように要求された場合には、DNS を参照します。FreeBSD
     のリゾルバは、デフォルトで DNS を使います (望むなら、NIS を使うようにもで
     きます)。そのため、FreeBSD の NIS サーバは、DNS をデフォルトでは参照しま
     せん。しかし、特別なフラグをつけて ypserv(8) を起動した場合は、DNS を参照
     するようになります。また、v1 サーバが存在することを強く要求するようなシス
     テムをおとなしくさせるため、ypserv(8) を NIS v1 サーバとして登録すること
     もできます (FreeBSD は、NIS v2 のみ使用しますが、その他のシステムでは、
     SunOS 4.x もそうですが、バインドを確立する際に、v1 および v2 の両方の機能
     を有するサーバを検索するものが多いです)。FreeBSD の ypserv(8) は、実は
     NIS v1 リクエストを扱いません。しかし、この ``対処モード (kludge mode)''
     は、v1 および v2 の両方の機能を有するサーバを頑固に検索するシステムを黙ら
     せるには便利です。

     (これらの特殊な機能やフラグについての詳細は、ypserv(8) のマニュアルページ
     を参照してください)。

関連項目
     domainname(1), ypcat(1), ypmatch(1), ypwhich(1), nsswitch.conf(5),
     yp_mkdb(8), ypbind(8), ypinit(8), yppoll(8), yppush(8), ypserv(8),
     ypset(8), ypxfr(8)

歴史
     YP サブシステムは、Sun の実装と互換となるように、Theo de Raadt によって最
     初から書かれました。バグフィックス、改良と NIS サーバのサポートは、後に
     Bill Paul によって追加されました。サーバ側のコードは、もともと、Peter
     Eriksson と Tobias Reber によって書かれ、GNU Public License に従っていま
     す。Sun のコードは、一切参照されませんでした。

バグ
     FreeBSD では、現在 NIS クライアントにもサーバにもなることができますが、
     ypupdated(8) または yp_update() 関数は、サポートされていません。これらに
     は両方とも安全な RPC が必要ですが、FreeBSD ではこれについてもサポートされ
     ていません。

     getservent(3)getprotoent(3) 関数は、まだ NIS をサポートしていません。
     幸いなことに、これらのファイルは、それほど頻繁に更新する必要がありませ
     ん。

     マニュアルページをもっとたくさん書くべきです。特に ypclnt(3) についてはそ
     うです。しばらくは、手元の Sun マシンを探して、それ用のマニュアルを読んで
     ください。

     Sun もこの著者も、起動時に ypbind がサーバを見つけられないときに生じる問
     題を分かりやすく扱う方法を思い付きませんでした。

FreeBSD 11.2                   December 14, 2011                  FreeBSD 11.2

Table of Contents

FreeBSD マニュアル検索