ナビゲーションリンクをスキップ | |
印刷ビューの終了 | |
マニュアルページセクション 1M: システム管理コマンド Oracle Solaris 11 Information Library (日本語) |
- Solaris サービス管理機能の inet サービス委任リスタータ
inetd [configuration-file] start | stop | refresh
svc:/network/inetd:default
inetd は Solaris サービス管理機能 (SMF) のインターネットサービスの委任リスタータです。その基本的な役割は、管理要求、システム障害、およびサービス障害に対応してサービスの状態を管理することと、必要に応じてサービスのネットワーク要求を待機することです。
inetd 構成ファイル inetd.conf(4) の編集によってサービスを管理することはなくなりました。代わりに、inetconv(1M) を使用して構成ファイルの内容を SMF 形式のサービスに変換してから、inetadm(1M) および svcadm(1M) を使用してこれらのサービスを管理します。inetconv でサービスを変換したあとは、inetd 構成ファイルのレガシーデータの変更は何の効果も持たなくなります。ただし、構成ファイルの変更を検出すると、inetd は管理者に警告します。詳細については、「inetd のメソッド」の start に関する説明を参照してください。
現在の inetd は SMF の外部からは実行できないことにも留意してください。つまり、以前の inetd でサポートされていたようなコマンド行からの実行はできません。これを試みると、標準エラー出力にメッセージが出力され、以前の inetd と SMF バージョンの inetd でサポートされているオプションのマッピングが表示されます。
inetd は、online 状態または degraded 状態になっているすべてのサービスに代わって接続を待機します。ユーザーがサービスを有効にすると、サービスはこれらの状態のどちらかになり、inetd はそのサービスに代わって待機を試みます。すでに別のサーバー (スタンドアロンまたはサードパーティーのインターネットサービス) が同じポートを待機している場合は、待機の試みが失敗することがあります。このような場合、inetd はこの状況をログに記録し、設定されている間隔で、設定されている回数だけ、ポートへのバインドを試行し続けます。詳細については、後述の「サービスのプロパティー」の bind_fail_max プロパティーを参照してください。
inetd で管理されるすべての SMF サービスの構成は、inetd の起動時に読み取られます。inetd が SMF 要求に対応して、あるいは SIGHUP シグナルを受信したために更新されるときに、再度読み取られます。構成の更新動作については、「inetd のメソッド」の refresh に関する説明を参照してください。
inetadm(1M) または svccfg(1M) ユーティリティーを使用すると、SMF リポジトリ内のインターネットサービスの構成を変更できます。inetadm には、svccfg と比較して、インターネット/RPC サービスコンテキストを提供するという利点があります。
inetd は、サービス管理の役割の一部として、管理対象サービスごとに状態マシンを実装します。このマシンの状態は、smf(5) の状態セットから成ります。これらの状態のセマンティクスは次のとおりです。
このサービスはまだ inetd で処理されていません。
サービスは新しいネットワーク要求を処理しており、既存の接続がアクティブになっている可能性があります。
サービスがこの状態になっているのは、サービスに指定されているプロトコルについて要求の待機と処理を所定の回数だけ再試行しても、プロトコルの一部にしか成功しなかったためです。既存のネットワーク接続がアクティブになっている可能性があります。
接続がアクティブになっている可能性はありますが、新しい要求は処理されていません。これは一時的な状態です。サービスは次のいずれかの理由で offline になっている可能性があります。
サービスの依存関係がまだ処理されていません。依存関係が処理されると、サービスの状態は再評価されます。
サービスは、設定されている接続レートの制限 max_con_rate を超えました。サービスの状態は、接続オフラインタイマー con_rate_offline がタイムアウトしたときに再評価されます。
サービスは、アクティブな接続の許容数 max_copies に到達しました。サービスの状態は、アクティブな接続の数が max_copies より少なくなったときに再評価されます。
inetd は、サービスのすべてのプロトコルについて、サービスに代わって待機することに失敗しました。前述のとおり、inetd は、設定されている間隔で、設定されている最大回数まで再試行します。サービスの状態は、待機が成功するか、再試行の制限回数に達したときに再評価されます。
サービスは管理者によって無効化されているため、新しい接続は受け入れておらず、アクティブな接続もありません。この状態を終了するには管理者の操作が必要です。
サービスがこの状態になっているのは、動作異常のため管理者の対応を必要としているか、管理者がこの状態を要求したためです。
動作異常となるイベントには次のようなものがあります。サービスのプロトコルのいずれかについて、inetd がサービスに代わって待機できないまま、サービスのバインド再試行の制限回数を超えた。start 以外のメソッドから成功以外の戻り値が返されました。サービスがその障害レートを超えた。
サービスにパッチの適用などの管理を行う場合には、保守状態を要求します。この状態では、新しい要求は処理されませんが、既存の接続がアクティブになっている可能性はあります。この状態を終了するには管理者の操作が必要です。
管理対象サービスの現在の状態を取得するには、inetadm(1M) を使用します。
inetd は、状態遷移の一環として、サービスで提供されている一連のメソッドのうち、設定されているものがあればそれを実行します。次の一連のメソッドがサポートされています。
online 状態または degraded 状態のサービスに対する要求を処理するために実行されます。アクティブな接続のあるサービスを区別する状態はないため、このメソッドは状態遷移の一環としては実行されません。
サービスが online 状態または degraded 状態から offline 状態になるときに実行されます。このメソッドの実行により、その時点で独自の待機を実行している wait タイプのサービスは、待機を終了します。online 状態または degraded 状態のサービスが無効化される場合、このメソッドは disable メソッドの前に実行されます。wait タイプのサービスにはこのメソッドを実装する必要があります。
サービスが offline 状態から online 状態に遷移するときに実行されます。サービスの作成者は、このメソッドを使用すると、サービスで要求の処理を開始する前に何らかの準備を行うことができます。
サービスが offline 状態から disabled 状態に遷移するときに実行されます。このメソッドの実行により、サービスにアクティブな接続がある場合はすべて終了されます。
次の両方の条件が満たされる場合に実行されます。
inetd がフレームワークまたは SIGHUP によって更新される、または、サービスを更新する要求が届く
サービスは現在 online 状態であり、サービスをいったん offline にしてから元に戻す必要が生じるような構成変更はない。
必須のメソッドは inetd_start だけです。ほかのメソッドが指定されていない場合、inetd はメソッドを実行しませんが、1 つのメソッドを正常に実行したかのように振る舞います。
SMF によって管理されるサービスの構成は SMF リポジトリに保存されます。構成は、サービスの基本構成、各サービスのメソッドの構成、および inetd によって管理されるすべてのサービスに適用されるデフォルトの構成から成ります。
サービスの構成とデフォルト値の表示および変更について詳しくは、inetadm(1M) を参照してください。
サービスの基本構成は、サービスの inetd というプロパティーグループに保存されます。基本構成は次のプロパティーから成ります。
サービスのバインド先となるネットワークインタフェースのアドレス。空の文字列値を指定すると、サービスは任意のネットワークインタフェースで接続を受け入れます。
バインド失敗から次の再試行までの時間間隔 (秒単位)。値 0 と -1 を指定すると、再試行は行われず、最初の失敗で bind_fail_max を超えたかのように処理されます。
inetd がサービスに関連付けられたポートへのバインドを試みる最大回数。値 -1 を指定すると、再試行回数は制限されません。設定されている制限に到達したときに、サービスのどのプロトコルもバインドされていない場合、サービスは maintenance 状態になります。あるいは、プロトコルの一部しかバインドされていない場合、サービスは degraded 状態になります。
設定されている最大接続レート max_con_rate を超えた場合にサービスを offline 状態に保つ時間 (秒単位)。値 0 および -1 を指定すると、接続レートの制限は無効になります。
バックログキューサイズ。着信するクライアント要求をサーバーの待機エンドポイントでキューに入れることのできる数の制限を表します。
サービスで使用されるソケットのタイプ。または、TLI ベースのサービスを表す値 tli。ソケットタイプの有効な値は、stream、dgram、raw、seqpacket です。
サービスの障害レート制限の回数部分。障害レート制限は wait タイプのサービスに適用されます。一定時間内に count 個のサービスインスタンスが開始されると、この制限に到達します。このレートを超えると、サービスは maintenance 状態に遷移します。この動作は、10 分間隔で無期限に再試行が続けられていた以前の inetd の動作とは異なります。failrate_cnt 検査では、サービス要求を処理する前に障害が発生した、適切に動作していないサーバーが処理されます。障害レート制限がないと、このようなサーバーは再起動を繰り返してシステムリソースを大量に使用することになります。障害レートは、以前の inetd の -r オプションと同等です。値 0 および -1 を指定すると、この機能は無効になります。
サービスの障害レートの時間部分 (秒単位)。値 0 および -1 を指定すると、障害レート制限機能は無効になります。
true の場合、inetd の環境をサービスの start メソッドに渡します。この設定にかかわらず、inetd は start メソッドの環境の変数 SMF_FMRI、SMF_METHOD、および SMF_RESTARTER を設定し、メソッドコンテキストに設定されている環境変数があればそれらも設定します。これらの変数については smf_method(5) の説明を参照してください。
true の場合、これは RPC サービスです。
nowait タイプのサービスに許容される最大接続レート (1 秒あたりの接続数)。値 0 および -1 を指定すると、接続レートの制限は無効になります。
同時に実行できる nowait サービスの最大コピー数。値 0 および -1 を指定すると、コピー数の制限は無効になります。
次の値のいずれかに設定できます。
getservbyname(3SOCKET) で認識されるサービス名。
isrpc が true に設定されている場合は、getrpcbyname(3NSL) で認識されるサービス名。
isrpc が true に設定されている場合は、有効な RPC プログラム番号。
ソケットベースのサービスの場合は、サービスでサポートされているプロトコルのリスト。有効なプロトコルは、tcp、tcp6、tcp6only、udp、udp6、および udp6only です。TLI サービスの場合は、サービスでサポートされている getnetconfigent(3NSL) で認識される netid のリスト、および値 tcp6only と udp6only。RPC/TLI サービスの場合は、このリストに nettype も使用できます。inetd は最初に、リストのメンバーをこれらのサービスタイプの nettype として解釈しようとします。値 tcp6only と udp6only は、inetd に新しく導入されたもので、IPv4 のマップされた要求ではなく真の IPv6 要求だけを待機して渡すよう inetd に指示します。後述の「ソケットベースのサービスのプロトコルの構成」を参照してください。
サポートされるもっとも低い RPC バージョン。isrpc が true に設定されている場合は必須です。
サポートされるもっとも高い RPC バージョン。isrpc が true に設定されている場合は必須です。
true の場合、接続されているソケットでの定期的なメッセージ送信を有効にします。接続の相手側がこれらのメッセージに応答できない場合、接続は切断されているとみなされます。これが適用されるのは、endpoint_type が streams、かつ wait が false に設定されているサービスだけです。
true の場合、これが nowait タイプのサービスであれば、inetd は、syslog(3C) 機能を使用して、着信する接続ごとにクライアントの IP アドレスと TCP ポート番号、およびサービスの名前をログに記録します。inetd は syslog 機能の code デーモンと notice 優先度を使用します。syslog のコードと重要度については、syslog.conf(4) を参照してください。このログ機能は、TCP ラッパー機能によるログ機能とは独立しています。
tcp_trace は、以前の inetd の -t オプション (および /etc/default/inetd のプロパティー ENABLE_CONNECTION_LOGGING) と同等です。
true の場合、TCP ラッパーによるアクセス制御を有効にします。これが適用されるのは、endpoint_type が streams、かつ wait が false に設定されているサービスだけです。syslog 機能の code デーモンを使用して、許可された接続 (notice 重要度を使用) および拒否されたトラフィック (warning 重要度を使用) をログに記録します。syslog のコードと重要度については、syslog.conf(4) を参照してください。TCP ラッパー機能とその構成ファイルのインタフェースの安定性は「流動的」です。TCP ラッパー機能は Sun で管理されているものではなく、リリース間の非互換性もまれではありません。attributes(5) を参照してください。
TCP ラッパーの構成の詳細については、tcpd(1M) および hosts_access(4) のマニュアルページを参照してください。これらは、Solaris オペレーティングシステムの一部として /usr/sfw/man に用意されています。これらのページは、/usr/man にある標準の Solaris マニュアルページには属していません。
tcp_wrappers は、以前の inetd の /etc/default/inetd のプロパティー ENABLE_TCPWRAPPERS と同等です。
true の場合、これは wait タイプのサービスです。それ以外の場合は nowait タイプのサービスです。wait タイプのサービスには次の特徴があります。
サービスの inetd_start メソッドは、実行されたときに、サービスのバインドされたエンドポイントで待機する役割を引き受けます。
inetd は、このメソッドが実行されたあと終了するのを待ってから、待機の役割を再開します。
データグラムサーバーは、指定されたサービスにバインドされているサービスの提供にかかわる元のデータグラムエンドポイントで常に呼び出されるため、wait タイプとして構成する必要があります。これらの「待機」ソケットと「受け入れ」ソケットは分離されていません。TCP ストリームサービスのように接続指向のサービスは、wait タイプと nowait タイプのどちらででも設計できます。
サービスの基本プロパティーのいくつかは省略可能です。省略されている場合、その値は inetd サービスの defaults プロパティーグループにあるデフォルト値から取り出されます。このようなプロパティーとそのシード値は次のとおりです。これらの値は inetadm(1M) で設定できます。
bind_fail_interval -1 bind_fail_max -1 con_rate_offline -1 connection_backlog 10 failrate_count 40 failrate_time 60 inherit_env true max_con_rate -1 max_copies -1 tcp_keepalive false tcp_trace false tcp_wrappers false
サービスに指定されている各メソッドの構成は、SMF リポジトリの、メソッドと同じ名前のプロパティーグループ内に保存されます。これらのメソッドに使用できるプロパティーセットには、svc.startd(1M) の管理対象サービスに指定されるプロパティーも含まれています。(詳細については、svc.startd(1M) を参照してください。)さらに、inetd_start メソッドには arg0 プロパティーを設定できます。
arg0 プロパティーを設定すると、inetd のサービスで外部ラッパープログラムを使用できるようになります。具体的には、サービスの start メソッドの第 1 引数 argv[0] に、サーバープログラムのパス以外のものを指定できるようになります。
外部ラッパープログラムを使用する場合に、サービスのデーモンに引数を渡すには、引数を exec プロパティーでラッパープログラムの引数として組み込むようにしてください。例:
exec='/path/to/wrapper/prog service_daemon_args' arg0='/path/to/service/daemon'
smf_method(5) で説明されている特殊なメソッドトークンに加え、inetd では wait タイプのサービスに :kill_process トークンも使用できます。その結果は、:kill トークンを指定した場合と同じ動作になりますが、kill シグナルは wait タイプのサービスの start メソッドの親プロセスだけに送信され、そのプロセス契約の全メンバーには送信されない点が異なります (process(4) を参照)。
ソケットベースのサービスの inetd を構成する場合は、サービスでサポートしているものに応じて、前述の proto プロパティーの値を選択します。使用する proto 値のガイドラインを次に示します。
IPv4 だけをサポートするサービスの場合: tcp と udp
IPv6 だけをサポートするサービスの場合: tcp6only と udp6only
IPv4 と IPv6 の両方をサポートするサービスの場合:
廃止および非推奨: tcp6 と udp6
推奨: proto フィールドだけが異なる 2 つのエントリを使用します。一方のエントリに tcp、もう一方のエントリに tcp6only を指定するか、udp と udp6only を指定します。
IPv4 と IPv6 の両方をサポートするサービスの構成例については、「使用例」を参照してください。
inetd には、マスターリスタータ svc.startd(1M) で使用できる次のメソッドが用意されています。
inetd によるサービスの提供を開始します。このメソッドにより、inetd は、その管理対象サービスの smf 要求と、online 状態または degraded 状態になっているサービスのネットワーク要求の処理を開始します。
さらに、inetd は、監視している inetd.conf(4) 形式の構成ファイルが inetconv(1M) 変換の最後の実行以降に変更されているかどうかを確認します。変更されている場合、変更を適用するには inetconv を再度実行する必要があるという管理者へのメッセージが syslog に記録されます。
inetd によるサービスの提供を終了します。この時点で、inetd では、maintenance 状態または disabled 状態のサービスを除き、必要に応じてメソッドを実行して各サービスを offline 状態に遷移させます。
各管理対象サービスの更新を実行し、inetd.conf(4) 形式の構成ファイルが変更されているかどうかを確認します (start メソッドと同様)。サービスが更新されたときの動作は、その現在の状態によって異なります。
maintenance 状態または disabled 状態の場合は何も実行されません。構成は、サービスがこの状態でなくなったときに読み取られて処理されます。
offline 状態の場合は、構成が読み取られ、変更があればすぐに処理されます。
online 状態または degraded 状態の場合は、再バインドが必要になるような構成の変更があれば、サービスはいったん offline 状態になったあと、バインドの新しい構成を使用して元に戻ります。
online 状態の場合で再バインドが不要のときは、サービスの inetd_refresh メソッドが指定されていればそれが実行されます。これにより、online 状態の wait タイプのサービスはその他の変更を処理できます。
サポートされているオプションはありません。
レガシーサービスファイル (inetd.conf(4)) に別の場所を指定します。
実行する inetd のメソッドを指定します。
例 1 IPv4 と IPv6 の両方をサポートするサービスの構成
次のコマンドは、IPv4 と IPv6 の両方をサポートするサービスが存在することを確認し、それらに proto プロパティーを割り当てる方法を示しています。
example# svcs -a | grep mysvc online 15:48:29 svc:/network/mysvc:dgram4 online 15:48:29 svc:/network/mysvc:dgram6 online 15:51:47 svc:/network/mysvc:stream4 online 15:52:10 svc:/network/mysvc:stream6 # inetadm -M network/rpc/mysvc:dgram4 proto=udp # inetadm -M network/rpc/mysvc:dgram6 proto=udp6only # inetadm -M network/rpc/mysvc:stream4 proto=tcp # inetadm -M network/rpc/mysvc:stream6 proto=tcp6only
これらのコマンドの説明については、svcs(1) と inetadm(1M) を参照してください。
属性についての詳細は、attributes(5) を参照してください。
|
fmd(1M), inetadm(1M), inetconv(1M), svcadm(1M), svccfg(1M), svcs(1), svc.startd(1M), syslog(3C), getnetconfigent(3NSL), getrpcbyname(3NSL), getservbyname(3SOCKET), inetd.conf(4), process(4), syslog.conf(4), attributes(5), smf(5), smf_method(5)
inetd デーモンは、Solaris 9 リリース以前の Solaris オペレーティングシステムにある同じ名前のデーモンと比較して、実行する機能は同じですが、実装方法が大きく異なっています。Solaris の現在のリリースでは、inetd は Solaris サービス管理機能 (smf(5) を参照) の一部であり、この機能の内部でのみ実行されます。
/etc/default/inetd ファイルは非推奨になりました。ENABLE_CONNECTION_LOGGING プロパティーと ENABLE_TCP_WRAPPERS プロパティーで表されていた機能は、現在はそれぞれ tcp_trace プロパティーと tcp_wrappers プロパティーで使用可能です。これらのプロパティーについては、前述の「サービスのプロパティー」を参照してください。