Provided by: manpages-ja_0.5.0.0.20161015+dfsg-1_all bug

名前

       xinetd.conf - 拡張されたインターネットサービスデーモンの設定ファイル

説明

       xinetd.confxinetd によって提供されるサービスを決定する設定ファイルである。 行の最初の
       空白ではない文字が '#' ならばコメント行とみなされる。 空行は無視される。

       ファイルは以下の形式のエントリからなる:

              service <service_name>
              {
                     <属性> <assign_op> <値> <値> ...
                     ...
              }

       代入演算子 assign_op'=', '+=', '-=' のいずれかである。  殆んどの属性は単純な代入演算子
       である  '='  のみをサポートする。 値が値の組合せであるような属性は、すべての代入演算子をサ
       ポートする。 そのような属性については、 '+=' は組合せに値を追加することを、 '-='  は組合せ
       から値を削除することを意味する。 どの属性がどの演算子をサポートするかは、 すべての属性につ
       いて述べた後に記述する。

       各エントリは service_name で識別されるサービスについて定義する。

       id               この属性はサービスを識別するのに用いられる。 サービスの中には違うプロトコ
                        ルを使えるものがあり、 その場合は設定ファイルの別のエントリに記述されるの
                        で、 そうしたときに有用である。 デフォルトではサービス id は service_name
                        と同じである。

       type             以下の値の任意の組合せである:

                        RPC         RPC を使ったサービスである

                        INTERNAL    xinetd によって提供されるサービス

                        TCPMUX/TCPMUXPLUS
                                    well-known(良く知られた)TCPMUX  ポートを使う、RFC 1078 プロト
                                    コルによって開始されるサービス。 後述する TCPMUX サービスにつ
                                    いて書かれた節を参照のこと。

                        UNLISTED    標準的なシステムファイル (RPC サービスなら /etc/rpc, RPC でな
                                    いサービスなら /etc/services) にはないサービス

       flags            以下のフラグの任意の組合せである:

                        INTERCEPT   パケットまたはすでに受けつけた接続を、 それが受け付けてよい場
                                    所から来ているのかを確かめるために横取りする  (内部サービスま
                                    たはマルチスレッドサービスは横取りできない)。

                        NORETRY     フォークに失敗しても再試行しない。

                        IDONLY      リモート側が、リモートのユーザを識別しているときのみ接続を受
                                    け付ける (すなわち、リモートホストは ident サーバを動かさなけ
                                    ればならない)。  ログオプション  USERID  が使われてない場合に
                                    は、このフラグは効果がない。

                        NAMEINARGS  "server_args"        の最初の引き数を、サーバが実行される際の
                                    argv[0] にする。 これにより、普通の inetd  のように  "server"
                                    を   tcpd   にし、  サーバー名を  "server_args"  に入れること
                                    で、tcpd を使うことができる。

                        NODELAY     サービスが TCP のサービスで NODELAY  フラグが立てられている場
                                    合、  ソケットに  TCP_NODELAY フラグを立てる。 サービスが TCP
                                    のサービスでなければ、このオプションは効果がない。

                        KEEPALIVE   サービスが TCP のサービスで、KEEPALIVE フラグが立てられた場合
                                    は、  ソケットに SO_KEEPALIVE フラグが立てられる。 サービスが
                                    TCP のサービスでなければ、このオプションは効果がない。

                        NOLIBWRAP   サービスへのアクセスを判断するのに、tcpwrap  の内部呼び出しを
                                    行わない。 xinetd のように長い時間動くプロセスには libwrap 機
                                    能が使えないので、 これは必要になる; その様な場合には tcpd プ
                                    ログラムを明示的に起動することができる(NAMEINARGS  フラグの項
                                    を見よ)。

                        SENSOR      サービスの代わりに、指定されたポートへのアクセスを検知するセ
                                    ンサーを使う。  注意: これはステルススキャンを検知しない。 必
                                    要ないということが分かっているサービスにのみ、このフラグを用
                                    いるべきである。   このサービスのポートへアクセスがあると、IP
                                    アドレスが no_access リストへ追加される。 以降の同じ IP  アド
                                    レスからのアクセスは、deny_time で設定した期限が切れるまで 拒
                                    否される。 このリストへ費やす時間の長さは、deny_time 属性で設
                                    定が可能である。  また、SENSOR フラグが指定された場合、同じ行
                                    に何が書かれていようと、 サーバに INTERNAL 属性が指定されたと
                                    xinetd       はみなす。      あと一つ覚えておくべき重要なこと
                                    は、socket_type を stream に設定した場合は、 wait  属性は  no
                                    に設定されなければならないということである。

                        IPv4        サービスを IPv4 サービス(AF_INET)にする。

                        IPv6        IPv6    がシステムで有効であれば、サービスを    IPv6   サービ
                                    ス(AF_INET6)にする。

       disable          "yes" または "no" の真偽値をとる。 これによりサービスが使用不能になり、起
                        動されなくなる。 DISABLE フラグに関する記述を見よ。

       socket_type      この属性に指定可能な値は以下:

                        stream      ストリーム型サービス

                        dgram       データグラム型サービス

                        raw         IP への直接制御が必要なサービス

                        seqpacket   信頼できる連続的なデータグラム交換が必要なサービス

       protocol         サービスに使われるプロトコルを指定する。 プロトコルは /etc/protocols にな
                        ければならない。 この属性が指定されなかった場合、サービスのデフォルトのプ
                        ロトコルが使われる。

       wait             この属性はサービスがシングルスレッドか、マルチスレッドかを決定する。 値が
                        yes ならシングルスレッドである; すなわち xinetd  は、サーバーを起動したら
                        そのサーバが死ぬまでは、  そのサービスへの要求に対する処理を停止する。 値
                        が no ならサービスはマルチスレッドであり、 xinetd  はサービスへの新たな要
                        求を処理し続ける。

       user             サーバプロセスの uid を指定する。 ユーザ名は /etc/passwd になければならな
                        い。 xinetd の実効ユーザIDがスーパーユーザーではない場合には、 この属性は
                        効果がない。

       group            サーバプロセスの  gid を指定する。 グループ名は /etc/group になければなら
                        ない。 xinetd の実効ユーザIDがスーパーユーザーではない場合には、 この属性
                        は効果がない。

       instances        サーバが同時にいくつサービスできるかを指定する(デフォルトは無制限)。 この
                        属性の値は数値か、もしくは無制限を意味する UNLIMITED のどちらかである。

       nice             サーバーの優先度を指定する。  値は(負の)数値である;  詳しくは  nice(3)(訳
                        注:Linux では nice(2))を見よ。

       server           そのサービスのために実行するプログラムを指定する

       server_args      サーバに渡される引き数を指定する。 inetd とは違い、サーバ名は server_args
                        には含めないonly_from        そのサービスを可能にするリモートホストを指定する。 値は IP アドレスのリス
                        トで、以下の方法の任意の組合せである:

                        a)   %d.%d.%d.%d形式の数値アドレス。  右端の部分が 0 であればワイルドカー
                             ドとして扱われる (例えば、128.138.12.0 は 128.128.12  サブネットのす
                             べてのホストに合致する)。 0.0.0.0 はすべてのインターネットアドレスに
                             合致する。 IPv6 ホストは  abcd:ef01::2345:6789  のような形式で指定す
                             る。  IPv4 の場合のワイルドカードに関するルールは、IPv6 アドレスには
                             適用されない

                        b)   %d.%d.%d.{%d,%d,...}形式の組合せアドレス。 4  つすべての部分が必要な
                             わけではない    (すなわち%d.%d.{%d,%d,...%d}形式も可である)。   しか
                             し、組合せの部分はアドレスの最後でなければならない。 この形式は IPv6
                             ホストでは使えない。

                        c)   (/etc/networks  から得られる)ネットワーク名。 この形式は IPv6 ホスト
                             では使えない。

                        d)   ホスト名。 xinetd への接続がなされると、逆引きが行われ、  得られた正
                             規名(canonical  name)と指定されたホスト名が比較される。  .domain.com
                             形式のドメイン名を指定することもできる。 クライアント IP  の逆引き結
                             果が .domain.com 内部なら、 そのクライアントは合致したことになる。

                        e)   1.2.3.4/32 形式の IPアドレス/ネットマスク 範囲指定。

                        値の指定をせずにこの属性を指定すると、 いかなるユーザにもサービス使用不可
                        となる。

       no_access        そのサービスが使用できないリモートホストを指定する。       値の指定方法は
                        only_from と同じである。 これら二つの属性により xinetd は場所に基づいたア
                        クセス制御を行う。 サービスに対しこの二つのどちらも指定されない場合には、
                        そのサービスは誰でも使用可になる。 サービスに対しこの二つが共に指定された
                        場合には、 リモートホストのアドレスがよりよく(より正確に)合致した方に基づ
                        き、    そのサービスがそのホストで使用できるかどうかが決定される    (例え
                        ば、only_from  リストに   128.138.209.0   があり、   no_access   リストに
                        128.138.209.10  があった場合には、 アドレスが 128.138.209.10 のホストはそ
                        のサービスへはアクセスできない)。

       access_times     サービスが使用できる時間間隔を指定する。 間隔の形式は 時:分-時:分  である
                        (間隔の境界での接続は受け付けられるだろう)。  時間は  0  から  23  の範囲
                        で、分は 0 から 59 である。

       log_type         サービスのログ出力がどこに送られるかを指定する。 二つの形式がある:

                        SYSLOG  syslog_facility [syslog_level]
                               ログ出力は指定された機能分類(facility)で syslog に送られる。  指定
                               可能な機能分類は  daemon,  auth,  authpriv, user, mail, lpr, news,
                               uucp, ftp, local0-7 である。  指定可能なレベル名は  emerg,  alert,
                               crit,  err, warning, notice, info, debug である。 レベル指定がない
                               場合には、メッセージは info レベルで記録される。

                        FILE  file [soft_limit [hard_limit]]
                               ログ出力は file に追加され、そのファイルが無ければ作成される。  ロ
                               グファイルのサイズに関しては、二つの制限をオプションで指定できる。
                               一つ目の制限は弱い制限(soft_limit)である; xinetd  はこの制限を最初
                               に越えたときにログ出力を行う   (xinetd  が  syslog  に出力する場合
                               は、メッセージは優先度レベル alert で送られる)。  二つ目の制限は強
                               い制限(hard_limit)である;  xinetd は影響があるサービス (ログファイ
                               ルとして共通のログファイルを使っている場合には、  二つ以上のサービ
                               スが影響受ける) のログ出力を中止し、その様にしたというメッセージを
                               ログ出力する (xinetd が syslog  に出力する場合は、メッセージは優先
                               度レベル  alert で送られる)。 強い制限が指定されていない場合は、デ
                               フォルトは弱い制限を 1% 増やした値である。  ただし、増やすサイズは
                               パラメータ  LOG_EXTRA_MIN と LOG_EXTRA_MAX (デフォルトは 5K と 20K
                               で、 これらの定数は(コンパイル時に) config.h で定義される)  の間に
                               なければならない。

       log_on_success   サーバ起動時と終了時にどの情報をログ出力するかを指定する  (サービス id は
                        ログエントリに必ず含まれる)。 以下の値の任意の組合せが指定可能である:

                        PID         サーバのプロセスIDを出力する (サービスが xinetd  によって実装
                                    され、  他のプロセスへとフォークされない場合には、プロセス ID
                                    として 0 が出力される)

                        HOST        リモートホストのアドレスを出力する

                        USERID      RFC 1413  で示される  ident(identification)  プロトコルを使っ
                                    て、  リモートユーザのユーザ ID を出力する。 このオプションは
                                    マルチスレッドなストリームサービスにのみ使用できる。

                        EXIT        サーバが終了したことを、終了ステータスまたは終了シグナルと共
                                    に出力する    (PID   オプションが指定されている場合にはプロセ
                                    スIDも出力される)

                        DURATION    サービスセッションの時間を出力する

       log_on_failure   サーバが起動できなかった場合  (リソースが足りなかった場合と、アクセス制御
                        による制限による場合のどちらでも)  にどの情報をログ出力するかを指定する。
                        サービスのidは失敗した理由と共に常にログエントリに含まれる。 以下の値の任
                        意の組合せが指定可能である:

                        HOST        リモートホストのアドレスを出力する

                        USERID      RFC  1413 で示されるident プロトコルを使って、 リモートユーザ
                                    のユーザ ID を出力する。 このオプションはマルチスレッドなスト
                                    リームサービスにのみ使用できる。

                        ATTEMPT     失敗があったことを出力する  (このオプションは他のすべてのオプ
                                    ションに含まれる)。

       rpc_version      RPC   サービスの   RPC   バージョンを指定する。    バージョンには一つの数
                        か、number-number 形式の範囲を指定できる。

       rpc_number       リストにない(UNLISTED)  RPCサービスの番号を指定する (サービスが標準的なシ
                        ステムファイルにリストされているなら、 この属性は無視される)。

       env              この属性の値は 'name=value' 形式の文字列のリストである。 これらの文字列は
                        サーバが起動する前に、環境に加えられる  (すなわち、 サーバの環境は xinetd
                        の環境に指定された文字列を加えたものである)。

       passenv          この属性の値は xinetd  の環境変数のリストで、  その環境がサーバへと渡され
                        る。 空のリストは、 env 属性を使って明示的に指定されたものを除いて、 どの
                        変数もサーバへと渡されないことを意味する (この属性と  env  の組合せによっ
                        て、 サーバにどの環境が渡されるかを正確に指定できるということである)

       port             サービスのポートを指定する。 /etc/services ファイルにリストされているサー
                        ビスに対してこの属性が指定された場合、 その値とファイルにあるポート番号と
                        は等しくなければならない。

       redirect         TCP サービスの他ホストへの転送を指定する。 このポートへの接続を xinetd が
                        受け取ったら、プロセスを起動し、 指定されたホストのポート番号への接続を確
                        立し、  二つのホストの間ですべてのデータを転送する。 このオプションは、内
                        部マシンが外界から見えない場合に有用である。 書式は redirect =  (IPアドレ
                        ス)  (ポート)  である。 IP アドレスの代わりにホスト名を使うこともできる。
                        ホスト名検索は xinetd が起動した時の一回のみ行われ、 最初に返された IP ア
                        ドレスが xinetd が再起動されるまで使われる。 このオプションが指定された場
                        合には "server" 属性は必要ではない。 "server"  属性が指定されても、こちら
                        の属性の方が優先される。

       bind             マシンの特定のインタフェースにサービスを割り当てることを指定する。   これ
                        は、安全なインタフェースであるローカルインタフェースで待ち(listen)、 外部
                        インタフェースではそうしないような telnet サーバが 作成できることを意味す
                        る。 また、あるインタフェースのあるポートで何かしている場合に、  同時に違
                        うインタフェースの同じポートで全く違ったことができる。  書式は bind = (イ
                        ンタフェースの IP アドレス) である。

       interface        bind に同じ。

       banner           サービスへの接続が確立された時に、 リモートホストで表示されるファイルの名
                        前を指定する。  このバナーはアクセス制御に関係なく表示される。 接続がなさ
                        れた場合には *いつでも* これが表示されるはずである。

       banner_success   サービスへの接続が許可された時に、 リモートホストで表示されるファイルの名
                        前を指定する。 このバナーはサービスへのアクセスが許可されるとすぐに表示さ
                        れる。

       banner_fail      サービスへの接続が拒否された時に、 リモートホストで表示されるファイルの名
                        前を指定する。  このバナーはアクセスが拒否されるとすぐに表示される。 ユー
                        ザに対し、そのユーザが何か悪いことをしたということ、 そしてこれ以上何もす
                        るなということを通知するのに有用である。

       per_source       発信元  IP アドレスごとの、そのサービスに対する最大サービス数を指定する。
                        引き数には一つの整数か "UNLIMITED"(無制限) をとる。  このオプションは、デ
                        フォルトセクション(後述)で指定することも可能である。

       cps              入ってくる接続の割合の制限。 二つの引き数を取る。 最初の引き数は 1 秒あた
                        りに処理する接続数である。 入ってくる接続の割合がこの値より大きくなると、
                        サービスは一時的に使用不可になる。 二つ目の引き数は、使用不可になってから
                        再び使用可能になるまでに待つ秒数である。  この設定のデフォルトは、50   の
                        入ってくる接続と、待つのは 10 秒である。

       max_load         サービスが接続の受け付けを停止するようになる負荷(load)値を、 浮動小数点数
                        で指定する。 例えば、2 や 2.5 である。 負荷がこの値になると、サービスは接
                        続の受け付けを停止する。  これは 1 分間の平均負荷値(load average)である。
                        これは OS に依存した機能で、Linux と Solaris でだけサポートされる。

       groups           "yes" または "no" を引き数にとる。 groups 属性が "yes" の場合、サーバの実
                        効  UID  でアクセスできる  グループにアクセスできるようにサーバが実行され
                        る。 groups 属性が "no" の場合、サーバは他のグループなしで実行される。 多
                        くの BSD システムでは、この属性は "yes" にされなければならない。 このオプ
                        ションは、デフォルトセクションで指定することも可能である。

       umask            サービスが継承する umask を指定する。 8進数で指定する。  全てのサービスの
                        umask  を設定するために、"defaults"  セクションで  指定することも可能であ
                        る。 xinetd は自分自身の umask を、継承した umask と 022 との OR に設定す
                        る。  umask オプションが指定されなければ、この xinetd の umask 値が全ての
                        子プロセスに継承される。

       enabled          有効にするサービス名のリストを指定する。 この属性の引数としてリストされた
                        サービスだけが有効になる。         すなわち、残りのサービスは無効になる。
                        "disable" 属性と  "DISABLE"  フラグは、この属性でリストされたかに関係なく
                        サービスが有効になるのを防ぐことができることに注目せよ。

       include          "include  /etc/xinetd/service"  という形式で、ファイル名を指定する。 その
                        ファイルは新たな設定ファイルとして解析(parse)される。   xinetd.conf    の
                        include  が指定された場所にファイルを貼り付けるのとは、 同じではない。 取
                        り込まれたファイルは xinetd.conf と同じ形式でなければならない。  サービス
                        定義の内部でこの属性を指定してはいけない。 サービス定義の外側で指定されな
                        ければならない。

       includedir       "includedir  /etc/xinetd.d"  という形式でディレクトリ名を指定する。  その
                        ディレクトリのすべてのファイル(ただし名前にドット('.')を含むファイルと、
                        名前がチルダ('~')で終わるファイル以外) は xinetd 設定ファイルとして解析さ
                        れる。 ファイルは C ロケールでのアルファベット順で解析される。 includedir
                        はサービス定義の内部で指定されてはならない。

       rlimit_as        サービスの、アドレス空間資源の制限を設定する。 パラメータが一つ必要で、制
                        限するバイト数 (キロバイト・メガバイトを指定するのに K, M が使える)を表す
                        正の整数か、 "UNLIMITED" (無制限)を指定する。 Linux の libc の malloc  の
                        実装方法の関係で、 rlimit_data, rlimit_rss, rlimit_stack よりもこの制限を
                        設定する方が有用である。 この資源制限は Linux  システムでのみ実装されてい
                        る。

       rlimit_cpu       サービスが使える最大  CPU  時間(秒単位)を設定する。  パラメータが一つ必要
                        で、CPU 時間を制限する正の整数か、 "UNLIMITED" (無制限)を指定する。

       rlimit_data      サービスの最大データサイズの制限を設定する。 パラメータが一つ必要で、バイ
                        ト数を表す正の整数か、 "UNLIMITED" (無制限)を指定する。

       rlimit_rss       サービスの最大常駐サイズの制限を設定する。 この値を小さくすれば、メモリが
                        少ない時に   プロセスがディスクへとスワップアウトされる候補になりやすくな
                        る。 パラメータが一つ必要で、バイト数を表す正の整数か、 "UNLIMITED" (無制
                        限)を指定する。

       rlimit_stack     サービスの最大スタックサイズを設定する。 パラメータが一つ必要で、バイト数
                        を表す正の整数か、 "UNLIMITED" (無制限)を指定する。

       deny_time        SENSOR を作動させた何者かの IP アドレスからの、全てのサービスへのアクセス
                        を 拒否する期間。単位は分。 指定可能なオプションは FOREVER, NEVER  そして
                        数値である。  FOREVER では、xinetd が再起動されるまでその IP アドレスは消
                        去されない。 NEVER は迷惑な IP アドレスをログに取る効果だけである。  典型
                        的な値は 60 分である。 これなら、正当な目的でその IP アドレスが再利用され
                        るのを許可する一方で、 殆んどの DoS 攻撃を防ぐことができる。 このオプショ
                        ンは SENSOR フラグとの組合わせで用いること。

       それぞれのサービスで以上の属性をすべて指定する必要はない。 必要な属性は以下の通り:

              socket_type
              user              (非内部サービスのみ)
              server            (非内部サービスのみ)
              wait
              protocol          (RPCリストにない(UNLISTED)サービスのみ)
              rpc_version       (RPC サービスのみ)
              rpc_number        (リストにない RPC サービスのみ)
              port              (リストにない非 RPC サービスのみ)

       以下の属性はすべての代入演算子をサポートする:

              only_from
              no_access
              log_on_success
              log_on_failure
              passenv
              env               ('-=' 演算子はサポートしない)

       これらの属性は一つのサービスエントリで複数回あらわれてもよい。 残りの属性は '=' 演算子のみ
       をサポートし、一つのサービスエントリで一回以下しか現れない。

       また、設定ファイルは以下の形式のデフォルトエントリを一つ持つ。

              defaults
              {
                     <属性> = <値> <値> ...
                     ...
              }

       このエントリは、そのサービスで属性値が指定されなかった場合の、  デフォルトの属性値を決定す
       る。指定可能なデフォルトの属性は:

              log_type
              bind
              per_source
              umask
              log_on_success    (積算効果)
              log_on_failure    (積算効果)
              only_from         (積算効果)
              no_access         (積算効果)
              passenv           (積算効果)
              instances
              disabled          (積算効果)
              enabled           (積算効果)

       積算効果を持つ属性は、複数回指定することができ、その度に積み上げられる  (すなわち  '='  は
       '+=' と同じことをする)。 disabled の例外を除いて、サービスエントリで指定された場合と同じ意
       味を持つ。  disabled は、設定ファイルにエントリがあるものでさえも使用不可にする。 これによ
       り、コメントアウトする代わりに、 disabled 属性を使って使用不可にするサービスを、素早く再設
       定できる。  この属性の値は、スペースで区切られた、サービス  id のリストである。 enabled は
       disabled と同じ特性を持つ。違いは enabled は使用可能にするサービスのリストであるということ
       だ。もし enabled が指定された場合、指定されたサービスだけが使用可能になる。 enabled が指定
       されなかった場合は、すべてのサービスが使用可能と仮定され、 disabled にリストされたものが除
       外される。

内部サービス

       xinetd  は以下のサービスを内部的に提供する (ストリーム型、データグラム型の両方とも): echo,
       time, daytime, chargen, discard である。 xinetd が他のプロセスへと fork する必要がないとい
       うことを除けば、  これらのサービスは、他のサービスと同様にアクセス制限の下にある。  これら
       (time, daytime と、データグラム型の echo, chargen, discard)  は  instances  の数に制限がな
       い。

       xinetd  はまた、二つの  UNLISTED なストリーム型内部サービスを提供する: serversservices
       である。 前者は実行しているサーバの情報を表示し、 一方後者は現在有効なサービスのリストを提
       供する。 一行に一つのサービスで、 各行はサービス名・プロトコル(例えば "tcp")・ポート番号か
       らなる。

       今や管理インタフェースがあり、それは内部サービスである。 サービス名 "xadmin"  は予約されて
       おり、それは常に内部サービスである。 このサービスにはポート番号を指定しなければならず、 多
       分 IP ベースのアクセス制御もしなければならないだろう。  なぜならば、これを執筆している時点
       では、  パスワード保護を何も持たないからである。 このポートに telnet し、xinetd にいくらか
       の問い合わせをすることができる。

TCPMUX サービス

       xinetd は RFC 1078  に準拠した  TCPMUX  サービスをサポートする。  サービスがそれに対応する
       well-known  ポートを持たなくても、  well-known  ポートである TCPMUX を通じてアクセスができ
       る。

       TCPMUX を通じてアクセスされるサービスは、それぞれ /etc/xinetd.conf  にサービスエントリーを
       持つか、もしくは  includedir  ディレクトリの設定ファイルにサービスエントリがなければならな
       い。

       service_name フィールド(各 xinetd  の設定ファイルで、サービスの最初で定義される)は  xinetd
       に(RFC  1078  プロトコルによって)渡される文字列に等しくなければならない。 それはリモートの
       サービス要求者が最初に well-known ポートである TCPMUX に アクセスしたときに渡される。 プラ
       イベートなプロトコルは高い確率で一意になるサービス名を使うべきだ。  ひとつの方法は、ドメイ
       ン名の前にサービス名を付加することである、

       type フィールドは TCPMUX または TCPMUXPLUS  のどちらかである。  TCPMUXPLUS  が指定された場
       合、 xinetd はサービスを初期化する前にプロセス呼び出して、 (RFC 1078 で定義される)プロトコ
       ルの最初のハンドシェイクを処理する。 type が TCPMUX の場合は、ハンドシェークを遂行するため
       に開始されているサーバが対処する。

       サービスが標準的なシステムファイル  (RPC  サービスなら、  /etc/rpc,  RPCサービスでないなら
       /etc/services など) に無い場合は、 type には UNLISTED も指定する。

       これらのサービスに対する socket_typestream でなければならず、また protocaltcp でな
       ければならない。

       以下は TCPMUX サービス設定のサンプルである。

              service myorg_server
              {
                     disable             = no
                     type                = TCPMUX
                     socket_type         = stream
                     protocol            = tcp
                     wait                = no
                     user                = root
                     server              = /usr/etc/my_server_exec
              }

       well-known   ポートの   TCPMUX   を通じてアクセスされる各サービスの   サービスエントリの他
       に、TCPMUX 自身のサービスエントリも xinetd の設定の中に含まれなければならない。 以下のサン
       プルを見よ:

              service tcpmux
              {
                     type                = INTERNAL
                     id                  = tcpmux
                     socket_type         = stream
                     protocol            = tcp
                     user                = root
                     wait                = no
              }

注意

       1.  以下のサービス属性は、再設定で変更することができない:   socket_type,  wait,  protocol,
           type である。

       2.  属性 only_fromno_access が(直接、defaultsのどちらでも)指定されなかったサービスは、
           アドレスの照合は成功したものとして扱われる (すなわち、アクセスは拒否されない)。

       3.  アドレス照合はリモートホストの  IP アドレスとを基にしており、 ドメインアドレスには依ら
           ない。 長い時間がかかるリモートホストの名前検索を避けられるので、そうなっている  (なぜ
           ならば、 xinetd は単一スレッドであり、 名前検索はデーモンがその検索を終えるまで、 他の
           全ての要求を受け付けるのを妨げるからである)。 この枠組の悪い面は、リモートホストの  IP
           アドレスが変わってしまうと xinetd を再設定するまでは、アクセスが拒否されてしまうことで
           ある。 アクセスが実際に供されるかどうかは、 新たな IP アドレスが許可されたアクセスにあ
           るかどうかによる。  例えば、ホストの  IP  アドレスが 1.2.3.4 から 1.2.3.5 に変更され、
           only_from が 1.2.3.0 と指定されていれば、アクセスは拒否されない。

       4.  ログオプション  USERID  が指定され、もしリモートホストが  ident   サーバを動かしてない
           か、または ident サーバが壊れた返事を送り返してきたら、 サービスフラグ IDONLY が使われ
           ない限り、アクセスは拒否されない。

       5.  プロセスをフォークし、  それがリモートホストとローカルサーバの間でフィルタとして振舞う
           ことにより、  横取りが機能する。 これは明らかに性能に影響を及ぼすので、 各サービスごと
           のセキュリティと性能との間の妥協は、あなたに任されている。  以下の表は横取りのオーバー
           ヘッドを示す。   最初の表は様々なデータグラムサイズでの、UDP  ベースのサービスにおける
           データグラムあたりのオーバーヘッドである。 TCP  ベースのサービスについては、横取りによ
           るバンド幅の減少を計測した。  計測の間は、ある量のデータをクライアントからサーバへ送っ
           た (時間のオーバーヘッドは UDP ベースのサービスと同じはずだが、 連続するデータ転送の最
           初のパケットだけにかかる)。 データ量は表の システムコール数xシステムコールあたりのデー
           タ量 から得られる。すなわち、各  send(2)  システムコールはそれほど多くのデータを転送し
           た。 バンド幅の減少は、秒あたりのバイト数と、 横取りが行われなかった場合からの割合で与
           えられる。 全ての計測は SunOS 4.1 が走る SparcStation IPC で行われた。

                  データグラムサイズ(バイト)  遅延(ミリ秒)
                  --------------------------  ------------
                  64                          1.19
                  256                         1.51
                  1024                        1.51
                  4096                        3.58

                  送信バイト                  バンド幅減少
                  ----------                  ------------
                  10000x64                    941 (1.2%)
                  10000x256                   4,231 (1.8%)
                  10000x1024                  319,300 (39.5%)
                  10000x4096                  824,461 (62.1%)

              #
              # xinetd のサンプル設定ファイル
              #

              defaults
              {
                     log_type            = FILE /var/log/servicelog
                     log_on_success      = PID
                     log_on_failure      = HOST RECORD
                     only_from           = 128.138.193.0 128.138.204.0
                     only_from           = 128.138.252.1
                     instances           = 10
                     disabled            = rstatd
              }

              #
              # 注意 1: protocol 属性は必要ない
              # 注意 2: instances 属性はデフォルト値を上書き
              #
              service login
              {
                     socket_type         = stream
                     protocol            = tcp
                     wait                = no
                     user                = root
                     server              = /usr/etc/in.rlogind
                     instances           = UNLIMITED
              }

              #
              # 注意 1: instances 属性はデフォルト値を上書き
              # 注意 2: log_on_success フラグは引き数
              #
              service shell
              {
                     socket_type         = stream
                     wait                = no
                     user                = root
                     instances           = UNLIMITED
                     server              = /usr/etc/in.rshd
                     log_on_success      += HOST RECORD
              }

              service ftp
              {
                     socket_type         = stream
                     wait                = no
                     nice                = 10
                     user                = root
                     server              = /usr/etc/in.ftpd
                     server_args         = -l
                     instances           = 4
                     log_on_success      += DURATION HOST USERID
                     access_times        = 2:00-9:00 12:00-24:00
              }

              # telnet セッションを、8 メガバイトのメモリーと子プロセスを
              # 合計 20 CPU 秒に制限
              service telnet
              {
                     socket_type         = stream
                     wait                = no
                     nice                = 10
                     user                = root
                     server              = /usr/etc/in.telnetd
                     rlimit_as           = 8M
                     rlimit_cpu          = 20
              }

              #
              # このエントリとその次は、内部サービスを指定する。
              # 違うソケットタイプの同じサービスなので、
              # 各エントリを唯一に識別するために id 属性を用いる
              #
              service echo
              {
                     id                  = echo-stream
                     type                = INTERNAL
                     socket_type         = stream
                     user                = root
                     wait                = no
              }

              service echo
              {
                     id                  = echo-dgram
                     type                = INTERNAL
                     socket_type         = dgram
                     user                = root
                     wait                = no
              }

              service servers
              {
                     type                = INTERNAL UNLISTED
                     protocol            = tcp
                     port                = 9099
                     socket_type         = stream
                     wait                = no
              }

              #
              # RPC サービスのサンプル
              #
              service rstatd
              {
                     type                = RPC
                     socket_type         = dgram
                     protocol            = udp
                     server              = /usr/etc/rpc.rstatd
                     wait                = yes
                     user                = root
                     rpc_version         = 2-4
                     env                 = LD_LIBRARY_PATH=/etc/securelib
              }

              #
              # リストにないサービスのサンプル
              #
              service unlisted
              {
                     type                = UNLISTED
                     socket_type         = stream
                     protocol            = tcp
                     wait                = no
                     server              = /home/user/some_server
                     port                = 20020
              }

関連項目

       xinetd(1),

       xinetd.log(5)

       Postel J., Echo Protocol, RFC 862, May 1983

       Postel J., Discard Protocol, RFC 863, May 1983

       Postel J., Character Generator Protocol, RFC 864, May 1983

       Postel J., Daytime Protocol, RFC 867, May 1983

       Postel J., Harrenstien K., Time Protocol, RFC 868, May 1983

       M. Lottor, TCP Port Service Multiplexer (TCPMUX), RFC 1078, Nov 1988

       StJohns M.,  Identification Protocol, RFC 1413, February 1993

バグ

       INTERCEPT フラグが使われなかった場合、 waityessocket_typestream のときは、  リ
       モートホストアドレスのアクセス制御は行われない。

       INTERCEPT フラグが使われなかった場合、 waityessocket_typedgram のサービスの リ
       モートホストアドレスによるアクセス制御は、最初のパケットにのみ行われる。  アクセス制御リス
       トにないホストからのパケットをサーバは受け付けてしまう。  これは  RPC サービスの場合に起き
       る。

       環境変数に 空白 を入れる方法がない。

       waityessocket_typestream のとき、 接続が受け付けられた場合のみ、ソケットがサー
       バへ渡される。

       INTERCEPT フラグは、内部サービスとマルチスレッドサービスではサポートされない。

                                           14 June 2001                            XINETD.CONF(5)