Annotation of wikisrc/guide/inetd.mdwn, revision 1.4

1.4     ! jdf         1: **Contents**
        !             2: 
        !             3: [[!toc levels=3]]
        !             4: 
1.1       jdf         5: # The Internet Super Server inetd
1.3       jdf         7: The *internet super server*, or
                      8: [inetd(8)](, is
                      9: available on all Unix(like) systems, providing many of the basic network
                     10: services available. This chapter describes the relationship between the daemon
1.1       jdf        11: and several of the config files in the `/etc/` directory.
                     13: ## Overview
1.3       jdf        15: In this document we will look at a simple definition of
                     16: [inetd(8)](, how
                     17: several files that relate to
                     18: [inetd(8)]( work
                     19: (not that these files are not related to other software), how to add a service
                     20: to [inetd(8)](
                     21: and some considerations both to use
                     22: [inetd(8)]( for a
                     23: particular service and times when a service might be better off running outside
1.1       jdf        24: of [inetd(8)](
                     26: ## What is inetd?
1.3       jdf        28: In traditional Unix scenarios, one server (daemon) process watches for
                     29: connections on a particular port, and handles incoming requests. Now if a
                     30: machine offers many services, many daemon processes would be needed, mostly
                     31: running idle but still wasting resources like memory. The internet super server,
                     32: inetd, is an approach to this problem. It listens on a number of ports, and when
                     33: it receives a request it then determines which program to run to handle the
1.1       jdf        34: request and starts an instance of that program.
1.3       jdf        36: Following is a very simple diagram to illustrate
1.1       jdf        37: [inetd(8)](
                     39:     pop3  -------|  
                     40:                  |  
                     41:     ftpd --------| INETD | ---- Internet / DMZ / Switch / Whatever . . .  
                     42:                  |  
                     43:     cvsupserver -|
1.3       jdf        45: In the above diagram you can see the general idea. The
                     46: [inetd(8)](
                     47: process receives a request and then starts the appropriate server process. What
                     48: [inetd(8)]( is
                     49: doing is software multiplexing. An important note here, regarding security: On
                     50: many other UNIX-like systems, a package called tcpwrappers is used as a security
                     51: enhancement for
                     52: [inetd(8)]( On
                     53: NetBSD the tcpwrapper functionality is built into
                     54: [inetd(8)]( using
1.1       jdf        55: libwrap.
1.2       jdf        57: ## Configuring inetd - /etc/inetd.conf
1.1       jdf        58: 
1.3       jdf        59: The operation of
                     60: [inetd(8)]( is
                     61: controlled by its own config file, surprisingly named `/etc/inetd.conf`, see
                     62: [inetd.conf(5)](
                     63: The `inetd.conf` file basically provides enabling and mapping of services the
                     64: systems administrator would like to have multiplexed through
                     65: [inetd(8)](,
1.1       jdf        66: indicating which program should be started for incoming requests on which port.
1.3       jdf        68: [inetd.conf(5)](
                     69: is an ascii file containing one service per line, and several fields per line.
1.1       jdf        70: The basic field layout is:
                     72:     service-name socket-type protocol wait/nowait user:group server-program arguments
1.3       jdf        74:  * `service-name`: The service name indicates the port
                     75:    [inetd(8)](
                     76:    should listen on. It is either a decimal number, or a name matching a service
1.1       jdf        77:    name given in `/etc/services`.
1.3       jdf        79:  * `socket-type`: The communications socket type, the different types are
                     80:    `stream` for a TCP stream, `dgram` for an UDP service, `raw` for a raw
                     81:    socket, `rdm` for reliably delivered message and "seqpacket` for a sequenced
1.1       jdf        82:    packet socket. The most common socket types are `stream` and `dgram`.
1.3       jdf        84:  * `protocol`: The protocol used, mostly `tcp`, `tcp6`, `udp` and `udp6` for
                     85:    stream-oriented services via the Transmission Control Protocol, or
                     86:    datagram-oriented services via the User Datagram Protocol. It is worth noting
                     87:    that `tcp` and `udp` mean they use the default (currently IPv4), `tcp4`
                     88:    specifically means communication via IPv4 only, and `tcp6` and `udp6` are
                     89:    IPv6-only. In addition to those, protocols based on Remote Procedure Calls
1.1       jdf        90:    (RPC) can be specified as either `rpc/tcp` or `rpc/udp`.
1.3       jdf        92:  * `wait/nowait`: This field tells
                     93:    [inetd(8)]( if
                     94:    it should wait for a server program to return or to continue processing new
                     95:    connections immediately. Many connections to server processes require answers
                     96:    after data transfers are complete, where other types can keep transmitting on
                     97:    a connection continuously, the latter is a `nowait` and the former `wait`. In
                     98:    most cases, this entry corresponds to the socket-type, for example a
                     99:    streaming connection would (most of the time) have a `nowait` value in this
1.1       jdf       100:    field.
1.3       jdf       102:  * `user[:group]`: This field gives the user name and optionally a group name
                    103:    that the server process which
                    104:    [inetd(8)](
1.1       jdf       105:    starts up runs as.
1.3       jdf       107:  * `server-program`: This field is the full path of the program that gets
1.1       jdf       108:    started.
1.3       jdf       110:  * `program-arguments`: This field contains the argument vector argv[] of the
                    111:    program started, including the program name and additional arguments the
                    112:    systems administrator may need to specify for the server program that is
1.1       jdf       113:    started.
1.3       jdf       115: That is all a lot to digest and there are other things the systems administrator
1.1       jdf       116: can do with some of the fields. Here is a sample line from an `inetd.conf` file:
                    118:     ftp       stream  tcp    nowait  root   /usr/libexec/ftpd    ftpd -ll
1.3       jdf       120: From the left, the service-name is `ftp`, socket-type is `stream`, protocol is
                    121: `tcp`,
                    122: [inetd(8)]( won't
                    123: wait for the server process to terminate (`nowait`), the process runs as user
1.1       jdf       124: `root`, path is `/usr/libexec/ftpd` and program name and arguments are
1.3       jdf       125: `ftpd -ll`. Notice in the last field, the program name is different from the
1.1       jdf       126: service-name.
1.2       jdf       128: ## Services - /etc/services
1.1       jdf       129: 
1.3       jdf       130: The next file to consider is the service name data base that can be found in
                    131: `/etc/services`. This file basically contains information mapping a service name
1.1       jdf       132: to a port number. The format of the `/etc/services` file is:
                    134:     service-name port-number/protocol-name [aliases]
1.3       jdf       136: `service-name` is the name of the service, `port-number` is the port number
                    137: assigned to the service, `protocol-name` is either `tcp` or `udp`, and if alias
                    138: names for a port are needed, they can be added as `aliases`, separated by white
1.1       jdf       139: spaces. Comments may be added after a hash mark (`#`).
                    141: Let's take a look at the `ssh` entries as an example:
                    143:     ssh             22/tcp           # Secure Shell
                    144:     ssh             22/udp
1.3       jdf       146: As we can see, from the left, the service name is `ssh`, the port number is 22,
                    147: the protocols are both tcp and udp. Notice that there is a separate entry for
1.1       jdf       148: every protocol a service can use (even on the same port).
1.2       jdf       150: ## Protocols - /etc/protocols
1.1       jdf       151: 
1.3       jdf       152: Another file read by
                    153: [inetd(8)]( is
                    154: `/etc/protocols`. This file has the information pertaining to DARPA Internet
1.1       jdf       155: protocols. The format of the protocols name data base is:
                    157:     protocol-name number [aliases]
1.3       jdf       159: where `protocol-name` describes the payload of an IP packet, e.g. `tcp` or
                    160: `udp`. `number` is the official protocol number assigned by IANA, and optional
1.1       jdf       161: alias names can be added after that.
                    163: Let's look at the seventh entry in the `/etc/protocols` db as an example:
                    165:     tcp     6       TCP             # transmission control protocol
1.3       jdf       167: Starting from the left, we see that the protocol name is tcp, the number is 6
                    168: and the only aliases listed is TCP, belonging to the Transmission Control
1.1       jdf       169: Protocol as indicated by the comment in that line.
1.2       jdf       171: ## Remote Procedure Calls (RPC) - /etc/rpc
1.1       jdf       172: 
1.3       jdf       173: The rpc program number data base used by services with the `rpc` protocol type
                    174: in
                    175: [inetd.conf(5)](
                    176: is kept in `/etc/rpc` and contains name mappings to rpc program numbers. The
1.1       jdf       177: format of the file is:
                    179:     server-name program-number aliases
                    181: For example, here is the nfs entry:
                    183:     nfs             100003  nfsprog
1.2       jdf       185: # Allowing and denying hosts - /etc/hosts.allow, /etc/hosts.deny
1.1       jdf       186: 
1.3       jdf       187: As mentioned above, NetBSD's
                    188: [inetd(8)]( has
                    189: the tcpwrapper package built in via the libwrap library. As such,
                    190: [inetd(8)]( can
                    191: allow or deny access to each service on a more fine-grained base than just
                    192: allowing a service to everyone, or not enabling it at all. The access control is
                    193: defined in the files `/etc/hosts.allow` and `/etc/hosts.deny`, see the
                    194: [hosts\_access(5)](
1.1       jdf       195: manpage.
1.3       jdf       197: Each of the two files contains several lines that describe access restrictions
                    198: for a certain server. Access is allowed if permission is given in
1.1       jdf       199: `/etc/hosts.allow`. If the service is not listened in `/etc/hosts.allow` but in
                    200: `/etc/hosts.deny`, it is denied. If a service is listed in neither file, it is
1.3       jdf       201: allowed, giving standard
                    202: [inetd(8)](
1.1       jdf       203: behaviour.
1.3       jdf       205: Each line in `/etc/hosts.allow` and `/etc/hosts.deny` contains a service either
                    206: by name (as given in the field for argv[0] in `/etc/inetd.conf`, e.g. `ftpd`
                    207: instead of `ftp`), or the special service `ALL` which obviously applies to all
                    208: services. Following the service name is - separated by a colon - a number of
                    209: access restrictions, which can be hostnames, domains, single IP addresses, whole
                    210: IP subnets or some other restrictions, please check
                    211: [hosts\_access(5)](
1.1       jdf       212: for all the details.
1.3       jdf       214: An example configuration that is mostly open but denies access to services to a
1.1       jdf       215: certain host and all machines from a certain domain would look like this:
                    217:     # /etc/hostname.deny:
                    218:     ALL:, .some.domain
1.3       jdf       220: Another example that would be mostly closed, denying access to all but very few
                    221: machines would need entries in both `/etc/hosts.allow` and `/etc/hosts.deny`.
1.1       jdf       222: The entry for `/etc/hosts.deny` would be:
                    224:     # /etc/hosts.deny
                    225:     ALL: ALL
                    227: The entry to allow a few hosts would be put into `/etc/hosts.allow`:
                    229:     # /etc/hosts.allow
                    230:     ALL: otherfriend.otherhost.otherdomain
                    232: ## Adding a Service
1.3       jdf       234: Many times a systems administrator will find that they need to add a service to
                    235: their system that is not already in
                    236: [inetd(8)]( or
                    237: they may wish to move a service to it because it does not get very much traffic.
                    238: This is usually pretty simple, so as an example we will look at adding a version
1.1       jdf       239: of POP3 on a NetBSD system.
1.3       jdf       241: In this case we have retrieved and installed the `cucipop` package, which can be
                    242: found in `pkgsrc/mail/cucipop`. This server is pretty simple to use, the only
                    243: oddities are different path locations. Since it is POP3 we know it is a stream
                    244: oriented connection with `nowait`. Running as `root` will be fine, the only item
                    245: that is different is the location of the program and the name of the program
1.1       jdf       246: itself.
                    248: So the first half of the new entry in `/etc/inetd.conf` looks like this:
                    250:     pop3   stream  tcp     nowait  root
1.3       jdf       252: After installation, pkgsrc deposited cucipop in `/usr/pkg/sbin/cucipop`. So with
1.1       jdf       253: the next field we have:
                    255:     pop3   stream  tcp     nowait  root /usr/pkg/sbin/cucipop
1.3       jdf       257: Last, we want to use the Berkeley mailbox format, so our server program must be
1.1       jdf       258: called with the `-Y` option. This leaves the entire entry looking like so:
                    260:     pop3   stream  tcp     nowait  root /usr/pkg/sbin/cucipop cucipop -Y
1.3       jdf       262: We have added the service named `pop3` to `/etc/inetd.conf`. Next item to check
1.1       jdf       263: is that the system can map the service name to a port number in `/etc/services`:
                    265:     # grep ^pop3 /etc/services
                    266:     pop3            110/tcp         # POP version 3
                    267:     pop3            110/udp
                    268:     pop3s           995/tcp                 # pop3 protocol over TLS/SSL (was spop3)
                    269:     pop3s           995/udp                 # pop3 protocol over TLS/SSL (was spop3)
1.3       jdf       271: The `pop3` entries here are of interest, i.e. they are already contained in the
1.1       jdf       272: `/etc/services` file shipped with NetBSD.
1.3       jdf       274: Now, to have
                    275: [inetd(8)]( use
1.1       jdf       276: the new entry, we simply restart it using the rc script:
                    278:     # sh /etc/rc.d/inetd restart
1.3       jdf       280: All done, in most cases, the software you are using has documentation that will
                    281: specify the entry, in the off case it does not, sometimes it helps to try and
                    282: find something similar to the server program you will be adding. A classic
                    283: example of this is a MUD server which has built-in telnet. You can pretty much
1.1       jdf       284: borrow the telnet entry and change parts where needed.
                    286: ## When to use or not to use inetd
1.3       jdf       288: The decision to add or move a service into or out of
                    289: [inetd(8)]( is
                    290: usually based on server load. As an example, on most systems the telnet daemon
                    291: does not require as many new connections as say a mail server. Most of the time
1.1       jdf       292: the administrator has to feel out if a service should be moved.
1.3       jdf       294: A good example I have seen is mail services such as smtp and pop. I had setup a
                    295: mail server in which pop3 was in
                    296: [inetd(8)]( and
                    297: exim was running in standalone, I mistakenly assumed it would run fine since
                    298: there was a low amount of users, namely myself and a diagnostic account. The
                    299: server was also setup to act as a backup MX and relay in case another heavily
                    300: used one went down. When I ran some tests I discovered a huge time lag for pop
                    301: connections remotely. This was because of my steady fetching of mail and the
                    302: diagnostic user constantly mailing diagnostics back and forth. In the end I had
                    303: to move the pop3 service out of
1.1       jdf       304: [inetd(8)](
1.3       jdf       306: The reason for moving the service is actually quite interesting. When a
                    307: particular service becomes heavily used, of course, it causes a load on the
                    308: system. In the case of a service that runs within the
                    309: [inetd(8)]( meta
                    310: daemon the effects of a heavily loaded service can also harm other services that
                    311: use [inetd(8)](
                    312: If the multiplexor is getting too many requests for one particular service, it
                    313: will begin to affect the performance of other services that use
                    314: [inetd(8)]( The
                    315: fix, in a situation like that, is to make the offending service run outside of
                    316: [inetd(8)]( so
                    317: the response time of both the service and
                    318: [inetd(8)]( will
1.1       jdf       319: increase.
                    321: ## Other Resources
1.3       jdf       323: Following is some additional reading and information about topics covered in
1.1       jdf       324: this document.
                    326: NetBSD manual pages:
                    328:  * [inetd(8)](
                    329:  * [protocols(5)](
                    330:  * [rpc(5)](
                    331:  * [services(5)](
                    332:  * [hosts\_access(5)](
                    334: Miscellaneous links:
                    336:  * [IANA: Protocol Numbers and Assignment Services](
                    337:  * [RFC1700: Assigned Numbers](

CVSweb for NetBSD wikisrc <> software: FreeBSD-CVSweb