Provided by: manpages-ja_0.5.0.0.20110915-1_all bug

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(1L),

       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)