inetd デーモン - ネットワークのサービス管理の提供

形式

inetd [–d] [configuration file]

説明

inetd デーモンは、ネットワークの サービス管理を提供します。例えば、ワークステーションからの リモート・ログイン要求があるときはいつも、rlogind プログラムを開始します。

rlogind プログラムは、UNIX システムで一般に見られるリモート・ログイン・コマンド rlogin のサーバーです。 これは、リモート・ログイン要求の妥当性検査をし、 ターゲット・ユーザーのパスワードまたはパスワード・フレーズを検査します。ユーザーに対して z/OS シェルを開始し、データがワークステーションとシェルの間を移動するとき に、ASCII と EBCDIC のコード・ページ変換を行います。

inetd が実行中で、接続の要求を受信すると、そのソケットに関連するプログラムに対する要求を処理します。例えば、ユーザーがリモート・システムから z/OS シェルにログインしようとした ときに inetd が実行中の場合は、inetd は、接続の要求を処理し、次に fork() と execl() を、rlogin 要求を処理する rlogin プログラムに 対して出します。次に、アプリケーションのさらなる要求のモニターに戻り ますが、これは /etc/inetd.conf ファイルで定義されているように 検出できます。

オプション

–d
inetd デーモンが、デバッグ・モードで開始するように指定します。すべてのデバッグ・メッセージは標準エラー出力 (stderr) に書き込まれます。
構成ファイル (configuration file)
inetd デーモンが、デフォルトの /etc/inetd.conf ファイル以外の 構成ファイルで開始するように指定します。

シグナル

inetd recognizes the following signals:
SIGTERM
通常の方法で inetd を終了し、/etc/inetd.pid を削除する。適宜 inetd を再始動できる。
SIGINT
SIGTERM と同じです。
SIGHUP
inetd 構成ファイルを再読み取りする。これを使用すると、新しいサービスを開始したり、別のポートでサービスを再開することができる。

SIGQUIT や SIGKILL のように通常プロセスを終わらせる他のシグナルを inetd に 送ってはいけません。プログラムが /etc/init.pid を取り除く機会が ないからです。

使用上の注意

  1. バッファー・サイズの指定は、inetd.conf ステートメントで指定される デーモンの文書がデフォルト以外を求める場合に限る必要があります。
  2. 構成ファイルはフィールド依存型ですが、カラム依存型ではありません。フィールドは、表 1に示されている順序で配置されている必要があります。 項目の継続行は、スペースまたはタブで開始する 必要があります。各項目はすべてのフィールドを含む必要があります。inetd デーモンは、構成ファイル項目を使用して、サーバーで予期される環境を適切にセットアップします。パラメーターの 1 つまたは複数の 値を誤って指定すると、サーバーが失敗する原因になる可能性があります。
    表 1. 構成ファイル (inetd デーモン) のフィールド
    フィールド 説明
    [ip_address:]service_name

    ip_address はローカル IP で、後にコロンが付きます。このアドレスは、 指定されれば、INADDR_ANY または現行のデフォルトに代わって使用されます。 特に INADDR_ANY を要求する場合は "*:" を使用します。 ip_address (またはコロン) の指定を、行にその他の項目を指定せずに行うと、 新しいデフォルトが指定されるまで、 それがそれ以降の行のデフォルトになります。

    service_name は、login または shell などの 予約済みサービス名です。 指定した名前とプロトコルは、/etc/services で 定義した複数サーバー名の 1 つと一致する必要があります。/etc/services についての詳細は、「z/OS V2R2.0 Communications Server: IP 構成解説書」 および z/OS V2R2.0 Communications Server: 新機能の要約
    socket_type ストリームまたは dgram。
    protocol [,sndbuf=n][,rcvbuf=n]

    protocol はtcp か udp でも、 あるいは (IPv6 の場合) tcp6 か udp6 でもかまいません。IPv4 を 明示的に要求する場合は tcp4 および udp4 を指定することもできます。 プロトコルは、サービス名をさらに修飾するために使用されます。サービス名およびプロトコルは、/etc/services にある項目と 一致しなければなりません (ただし、/etc/services 項目に 4 や 6 を含めてはなりません)。 /etc/services について詳しくは、「z/OS V2R2.0 Communications Server: IP 構成解説書 」および「z/OS V2R2.0 Communications Server: 新機能の要約」を参照してください。 tcp6 または udp6 が 指定されている場合、ソケットは IPv6 をサポートします (すなわち、AF_INET6 が使用されます)。

    sndbuf および rcvbuf は、 送受信のバッファー・サイズを指定します。 サイズはバイト単位です。 キロバイトまたはメガバイトを表すために、それぞれ "k" または "m" を追加できます。 sndbug および rcvbuf は、どの順序で使用してもかまいません。
    wait_flag [.max] wait または nowait。wait は、 デーモンが単一スレッドであること、および他の要求は 最初の要求が完了するまで処理されないことを示します。

    nowait が指定された場合は、 接続要求がストリーム・ソケットで受信されたときに、inetd デーモンは受け入れを発行します。 wait が指定された場合は、inetd デーモンは受け入れを発行しません。 これがストリーム・ソケットの場合は、受け入れを出すのはサーバーの責任です。

    変更の始まりmax は、60 秒間隔で許可される要求の最大数です。 デフォルトは 40 です。 この最大数を経過すると、サービスのポートはシャットダウンされます。変更の終わり
    login_name fork 済みデーモンがそのもとで実行するユーザー ID とグループ。inetd は、0 以外の UID を使用してプログラムを実行することができます。ただし、inetd が実行するプログラムが、プロセスのアイデンティティーを ユーザーのアイデンティティーに変更する必要がある場合、login_name は 、0 の UID (UID 0) を持つスーパーユーザーとして、ADDUSER を経由して RACF® に定義されている 必要があり、また、login_name は RACF に定義されている必要があります。これにより、inetd は setgid() および setuid() などの特殊な関数を使用することができます。
    inetd により呼び出されるプログラムが 、setuid() および seteuid() のような特殊な関数を 必要とする場合は、以下のログイン例のように BPX.DAEMON クラスに 許可されている必要があります。これは典型的な ADDUSER コマンドです。
    ADDUSER rlogind omvs(uid(0) home(/)
    典型的な許可コマンドは、以下になります。
    permit bpx.daemon class(facility)
   id(rlogind) access(read)

    デーモンのセキュリティーをセットアップする方法は、最終的な決定要因です。 詳しくは、「z/OS UNIX System Services 計画」の正しいデーモンのセキュリティーのレベルの確立に関するトピックを参照してください。
    server_program サービスの絶対パス名。例えば、以下のとおりです。
    /usr/sbin/rlogind
    は、rlogind コマンドの絶対パス名です。
    server_arguments 最大 20 の引数。最初の引数はサーバー名で、必ず指定します。それ以外の引数はオプションです。

関連情報

inetd デーモンは、一時ファイル /etc/inetd.pid を作成しますが、現在実行中の inetd デーモンの PID を含みます。この PID 値は、inetd デーモン処理から出た syslog レコードを識別するのに使用され、また PID を指定するのに必要な kill などのコマンドの PID 値も提供したり、一度に複数の inetd がアクティブにならないようにするロックを提供したりします。

inetd 構成ファイルのセットアップ、および、一般的にデーモンの構成について詳しくは、「z/OS UNIX System Services 計画」または「z/OS V2R2.0 Communications Server: IP 構成解説書」の デーモン に関する トピックを参照してください。

親トピック: シェル・コマンドの説明