訳註: これは作業してる最中のもので、本来、訳作業者以外は見えぬべきものです。 訳作業者以外は見ないでください。意味が反対になったりとか当然にあるから、 内容は利用しないでください。この言語への変換作業(翻訳作業)物に関しては、現在、オープンなライセンス条件ではありません。 十進240のコードのキャラクターを<240>に置換してる場合あり
Chapter25.The Internet Super Server inetd

Table of Contents

25.1. Overview
25.2. What is inetd?
25.3. Configuring inetd - /etc/inetd.conf
25.4. Services - /etc/services
25.5. Protocols - /etc/protocols
25.6. Remote Procedure Calls (RPC) - /etc/rpc
25.7. Allowing and denying hosts - /etc/hosts.{allow,deny}
25.8. Adding a Service
25.9. When to use or not to use inetd
25.10. Other Resources

"internet super server" または inetd(8) は 全ての Unix(like) システムで利用可能で、 沢山の基本的ネットワークサービスを利用可能に提供します。 この章では、デーモンと /etc/ ディレクトリーの幾つかの設定ファイルの間の relationship を記述します。

25.1.Overview

この document では、 inetd(8) の simple 定義づけを見、関連する幾つかのファイルがどのように inetd(8) を work するか( これらのファイルが他のソフトウェアに無関係というわけではない)、 inetd(8) にサービスを追加する方法および、特定のサービスに inetd(8) を使うか、 inetd(8) の外でサービスを running させるほうが良い場合なのか についての何らかの考察をします。

25.2.What is inetd?

伝統的な Unix での scenarios は、一つのサーバー(デーモン)プロセスが特定のポートを 接続のために watches し、入ってくるリクエストを扱います。 さて、もし a machine [ある機械] が多くのサービスを提供すると、多くの デーモンプロセスが必要となり、ほとんどが idle で running ですが、しかし、依然として メモリーのような resources を浪費します。 internet super server 、 inetd 、は、この問題へのアプローチです。これは、多くのポートを listens し、 そして、 request を receives すると、 request を捌(さば)きプログラムのインスタンスを starts するのに、どのプログラムを run するか決定します。

以下は inetd(8) を説明するのに非常にシンプルな図表で:

pop3------|
|
ftpd-------|INETD|----Internet/DMZ/Switch/Whatever...
|
cvsupserver-|

上の図表から概念が見られます。 inetd(8) プロセスは request を receives すると、 適切なサーバープロセスを starts させます。 inetd(8) は ソフトウェア multiplexing として動作するものです。ここでのセキュリティーに関する重要な註として: 多くの他の UNIX-like システムでは、 tcpwrappers と呼ばれるパッケージが inetd(8) の セキュリティー強化として使われています。 NetBSD では、 tcpwrapper 機能性は libwrap を用いて inetd(8) に組み込んでいます。

25.3.Configuring inetd - /etc/inetd.conf

inetd(8) の operation は、自身の設定ファイルで制御されていて、 驚くべき名前 /etc/inetd.conf が付けられています。 inetd.conf(5) を御覧ください。 inetd.conf ファイルが基本的に提供するのは システム管理者が inetd(8) を through で multiplexed したいサービスの enabling および mapping で、 あるボートに来た requests に対し、どのプログラムを started すべきかを 示しています。

inetd.conf(5) は 一行につき一つのサービスについて、また、行には幾つかの fields を入れている ascii ファイルです。基本的な field 配置は:

service-name socket-type protocol wait/nowait user:group server-program arguments
service-name:

サービス名は inetd(8) が listen すべきポートを示します。 十進数値または、 /etc/services に与えられた サービス名に matching する名前です。

socket-type:

通信 socket type で、 different types があり、 TCP stream には "stream" 、 UDP service には "dgram" 、 raw socket には "raw" 、 reliably delivered message には "rdm" で、 sequenced packet socket には "seqpacket" です。 一番一般的な socket types は "stream" と "dgram" です。

protocol

利用するプロトコルで、ほとんどが "tcp", "tcp6", "udp" および "udp6" で、 for stream-oriented services via the Transmission Control Protocol, or datagram-oriented services via the User Datagram Protocol. It is worth noting that "tcp" and "udp" mean they use the default (目下 IPv4), "tcp4" はすなわち、 IPv4 のみの通信を意味します。そして、 "tcp6" および "udp6" は IPv6-only です。それらに加え、 Remote Procedure Calls (RPC) ベースの プロトコルが "rpc/tcp" または "rpc/udp" として規定できます。

wait/nowait

この field は inetd(8)に、サーバープログラムが return を wait するべきか、 直ちに新しい接続処理を続けるべきかを tells 。 サーバープロセスへの多くの接続は データ転送が完了した後 answers を必要とし、そして、他の types では、接続の transmitting の継続を維持でき、 後者は "nowait" そして、前者は "wait" です。 多くの場合、 この entry は socket-type と corresponds[一致] し、例えば、 streaming 接続は (ほとんどの回) この field に "nowait" 値を持つでしょう。

user[:group]

この field はユーザー名およびオプションとしてグループ名で、 inetd(8) が、 どのユーザーの権限としてサーバープログラムの runs を starts up するのかを 与えます。

server-program

この field は gets started なプログラムのフルパスです。

program-arguments

この field には、開始されたプログラムの引数 vector argv[] 、これは プログラム名に加え、サーバープログラムが開始されるにあたり、 システム管理者が指定する事が必要かと思う追加の引数を入れています。

これで多くの要約する事および システム管理者が fields の幾つかでできるその他の事全てです。 inetd.conf ファイルから サンプルの行をここに:

ftp       stream  tcp    nowait  root   /usr/libexec/ftpd    ftpd -ll

左から、 service-name は "ftp" 、 socket-type は "stream" 、 protocol は "tcp" 、 inetd(8) は サーバープロセスの terminate を wait せず("nowait") 、 process は "root" ユーザー として runs 、 パスは /usr/libexec/ftpd で、プログラム名と 引数は "ftpd -ll" です。 最後の field に置いての注意は、プログラム名はサービス名と異なることです。

25.4.Services - /etc/services

次に考えるファイルは、サービス名データベースで、 /etc/services に見つかります。このファイルは、 基本的にサービス名とポート番号の mapping 情報が入っています。 /etc/services ファイルの format は:

service-name port-number/protocol-name [aliases]

"service-name" はサービス名、 "port-number" はサービスに割り当てられた ポート番号、 "protocol-name" は "tcp" か "udp" で、さらに、もし、ポートの alias names が必要なら、 "aliases" として追加でき、 white spaces で分離します。 コメントは hash mark (#) の後に追加できます。

例として、 "ssh" entries を見ていきましょう:

ssh             22/tcp           # Secure Shell
ssh             22/udp

見られるように、左から、 サービス名は "ssh" 、 ポート番号は "22" 、 プロトコルは "tcp" と "udp" の両方です。 注意として、サービスは、プロトコルごとに分割された entry を (同一ポートであっても)使う事ができます。

25.5.Protocols - /etc/protocols

inetd(8) から読まれるもう一つのファイルは、 /etc/protocols です。このファイルには DARPA Internet protocols に関係する情報が入っています。 プロトコル名データベースの format は:

protocol-name number [aliases]

ここで、 "protocol-name" は IP パケットのペイロードを述べていて、 例 "tcp" または "udp" 。 "number" は IANA に割り当てられた公式プロトコル番号で、 また、 optional alias 名がその後ろに続く事ができます。

例として /etc/protocols db の7番目の entry を見ていきましょう:

tcp     6       TCP             # transmission control protocol

左から始めて見ていくと、プロトコル名は "tcp" 、 番号が "6" で only aliases としてリストされているのは "TCP" であって、 Transmission Control Protocol に属すると、その行のコメントとして示されています。

25.6.Remote Procedure Calls (RPC) - /etc/rpc

inetd.conf(5) 中で、 "rpc" プロトコル type のサービスが使う rpc プログラム番号データベースは、 /etc/rpc に保持され、 名前から rpc プログラム番号への mappings が入っています。 このファイルのフォーマットは:

server-name program-number aliases

例えば、 here is the nfs entry:

nfs             100003  nfsprog

25.7.Allowing and denying hosts - /etc/hosts.{allow,deny}

上で触れたように、 NetBSD の inetd(8) は tcpwrapper パッケージを libwrap ライブラリーを媒介として組み込んでいます。 それとして、 inetd(8) 誰にでもサービスを単に allowing するか、もしくは、全く not enabling かよりも、もっときめの細かい、サービスごとにアクセスを allow or deny できます。 access control は /etc/hosts.allow ファイルおよび /etc/hosts.deny ファイルで定義され、 hosts_access(5) manpage を御覧ください。

2つのファイルそれぞれには、 あるサーバーについての access 制限を記した幾つかの行が入っています。もし /etc/hosts.allow で permission が given されていれば Access は allowed 。もしサービスが、 /etc/hosts.allow にリストされていないけれど、 /etc/hosts.deny にあれば、それは denied 。もし、サービスが どちらのファイルにもリストされていなければ、それは allowed で、 giving standard inetd(8) 挙動。

/etc/hosts.allow および /etc/hosts.deny の各行には、サービス名( /etc/inetd.conf にある field で、 argv[0] へ与えられるもの、 例、 "ftp" の代わりに "ftpd") あるいは、全てのサービスに適用される事が明らかな 特殊サービス "ALL" のいずれかが入っています。 サービス名に引き続き - コロンで隔てられた - いくらかのアクセス制限、これは、ホスト名、ドメイン、 single IP アドレス、 IP サブネット全体 または、幾つかのほかの制限でが可能で、 詳細全体はどうか hosts_access(5) を チェックしてください。

ほぼ open なある設定例で、しかし、 ある host および、あるドメインの全部の machines からの サービスへのアクセスを denies するのはこのように:

# /etc/hostname.deny:
ALL: some.host.name, .some.domain

ほぼ closed な他の例で、全てが access を denying で、しかし、 非常に少ない machines が /etc/hosts.allow および /etc/hosts.deny に entries を必要な場合です。 /etc/hosts.deny の entry はこのようで:

# /etc/hosts.deny
ALL: ALL

幾つかのホストを allow する entry は /etc/hosts.allow に置けて:

# /etc/hosts.allow
ALL: friend.host.domain otherfriend.otherhost.otherdomain

25.8.Adding a Service

システム管理者は、未だに inetd(8) に入っていなかったり、 traffic が大して多くないからサービスをそこに移したいと思うシステムへ サービスを追加する必要が幾度もあるでしょう。これは通常とっても simple で、それで、例として、 NetBSD システムに POP3 の a version の追加を見てみましょう。

この場合、 pkgsrc/mail/cucipop にある "cucipop" パッケージを 検索しインストールしています。 このサーバーは、とっても利用が簡単で、風変わりな事は path locations の違いだけです。 "nowait" の stream oriented 接続と知っている POP3 だからです。 "root" として Running するのが 申し分なく、異なっている only item は プログラムの位置と、プログラム自身の名前です。

それで、 /etc/inetd.conf の新しい entry の前半はこのように:

pop3   stream  tcp     nowait  root

インストール後、 pkgsrc は cucipop を /usr/pkg/sbin/cucipop に置きます。 それで、次の field は:

pop3   stream  tcp     nowait  root /usr/pkg/sbin/cucipop

最後に、 Berkeley mailbox format が使いたいので、 our server プログラムは -Y オプション付きで called される必要があります。 これは entry 全体をこのようにします:

pop3   stream  tcp     nowait  root /usr/pkg/sbin/cucipop cucipop -Y

/etc/inetd.conf に "pop3" と名付けられたサービスが 追加されました。次にチェックする item は /etc/services の、 システムが行えるサービス名からボート番号 map で:

# grep ^pop3 /etc/services
pop3            110/tcp         # POP version 3
pop3            110/udp
pop3s           995/tcp                 # pop3 protocol over TLS/SSL (was spop3)
pop3s           995/udp                 # pop3 protocol over TLS/SSL (was spop3)

ここで関心があるのは、 "pop3" entries で、すなわち、 shipped with NetBSD では /etc/services ファイルに 既に含まれています。

さて、 inetd(8) に新しい entry を使われるようにするには、 rc script を使って簡単に restart し:

# sh /etc/rc.d/inetd restart

全部終わり、ほとんどの場合、利用しているソフトウェアには entry を規定するドキュメンテーションがありますが、ない場合があり、 追加しようとするサーバープログラムに似た何かが 試行発見の助けとなる場合が時々あります。 この classic 例は telnet.に組み込みの MUD サーバーです。 telnet entry をほとんど借りて、必要部分だけを変更することができます。

25.9.When to use or not to use inetd

サービスの inetd(8) への追加あるいは、そこからの引越しの決定は、通常、サーバーの負荷に基づきます。 例として、ほとんどのシステムでは、 telnet デーモンはメールサーバのように多くの新しい接続を要求されません。 大抵、管理者はサービスが移動されるべきなんではないかとひそかに探りを入れます。

私が見た良い例は smtp および pop のようなメールサービスです。 私は inetd(8) の中に pop3 を、そして exim を standalone で running なメールサーバーの setup をし、 少数のユーザー、すなわち自分自身と分析のためのアカウントなので、 fine に run すると誤った仮定をしました。このサーバーはまた、 MX のバックアップおよび、他の heavily に使われているものが down した場合の リレーとしても setup されていました。幾つかのテストを ran したとき、 リモート pop 接続で a huge time lag[非常に大きな遅れ] があるのを発見しました。 これは my steady[定期的な]メールの取得および 診断用ユーザーが constantly[しきりに] mailing diagnostics back and forth.[症状メールを戻したり出したり]の原因となりました。 結局は pop3 サービスを inetd(8) の外に移動しました。

サービスの移動の理由は本当にとても興味深いです。 特定のサービスが heavily に利用されるようになると、 もちろん、 システムに負荷をかけます。この場合 inetd(8) meta デーモン内で runs な重い負荷のサービスは inetd(8) を使うほかのサービスも害します。 もし multiplexor が、 特定の一つのサービスの requests をあまりに多く getting すると、 inetd(8) を用いる他のサービスの performance に影響を与え始めます。 . このような場合の The fix は つまづいているサービスを inetd(8) の outside で run するようにする事で、 そうすっと、サービスおよび inetd(8) 共に response time[応答時間] は increase でしょう。

25.10.Other Resources

以下は、この document が covered した topics についての some additional 読み物および情報です。

NetBSD manual pages:

Miscellaneous links[雑リンク]: