File:  [NetBSD Developer Wiki] / wikisrc / guide / inetd.mdwn
Revision 1.5: download - view: text, annotated - select for diffs
Fri Jun 19 19:18:31 2015 UTC (5 years ago) by plunky
Branches: MAIN
CVS tags: HEAD
replace direct links to manpages on netbsd.gw.com with templates

    1: **Contents**
    2: 
    3: [[!toc levels=3]]
    4: 
    5: # The Internet Super Server inetd
    6: 
    7: The *internet super server*, or
    8: [[!template id=man name="inetd" section="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
   11: and several of the config files in the `/etc/` directory.
   12: 
   13: ## Overview
   14: 
   15: In this document we will look at a simple definition of
   16: [[!template id=man name="inetd" section="8"]], how
   17: several files that relate to
   18: [[!template id=man name="inetd" section="8"]] work
   19: (not that these files are not related to other software), how to add a service
   20: to [[!template id=man name="inetd" section="8"]]
   21: and some considerations both to use
   22: [[!template id=man name="inetd" section="8"]] for a
   23: particular service and times when a service might be better off running outside
   24: of [[!template id=man name="inetd" section="8"]].
   25: 
   26: ## What is inetd?
   27: 
   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
   34: request and starts an instance of that program.
   35: 
   36: Following is a very simple diagram to illustrate
   37: [[!template id=man name="inetd" section="8"]]:
   38: 
   39:     pop3  -------|  
   40:                  |  
   41:     ftpd --------| INETD | ---- Internet / DMZ / Switch / Whatever . . .  
   42:                  |  
   43:     cvsupserver -|
   44: 
   45: In the above diagram you can see the general idea. The
   46: [[!template id=man name="inetd" section="8"]]
   47: process receives a request and then starts the appropriate server process. What
   48: [[!template id=man name="inetd" section="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: [[!template id=man name="inetd" section="8"]]. On
   53: NetBSD the tcpwrapper functionality is built into
   54: [[!template id=man name="inetd" section="8"]] using
   55: libwrap.
   56: 
   57: ## Configuring inetd - /etc/inetd.conf
   58: 
   59: The operation of
   60: [[!template id=man name="inetd" section="8"]] is
   61: controlled by its own config file, surprisingly named `/etc/inetd.conf`, see
   62: [[!template id=man name="inetd.conf" section="5"]].
   63: The `inetd.conf` file basically provides enabling and mapping of services the
   64: systems administrator would like to have multiplexed through
   65: [[!template id=man name="inetd" section="8"]],
   66: indicating which program should be started for incoming requests on which port.
   67: 
   68: [[!template id=man name="inetd.conf" section="5"]]
   69: is an ascii file containing one service per line, and several fields per line.
   70: The basic field layout is:
   71: 
   72:     service-name socket-type protocol wait/nowait user:group server-program arguments
   73: 
   74:  * `service-name`: The service name indicates the port
   75:    [[!template id=man name="inetd" section="8"]]
   76:    should listen on. It is either a decimal number, or a name matching a service
   77:    name given in `/etc/services`.
   78: 
   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
   82:    packet socket. The most common socket types are `stream` and `dgram`.
   83: 
   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
   90:    (RPC) can be specified as either `rpc/tcp` or `rpc/udp`.
   91: 
   92:  * `wait/nowait`: This field tells
   93:    [[!template id=man name="inetd" section="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
  100:    field.
  101: 
  102:  * `user[:group]`: This field gives the user name and optionally a group name
  103:    that the server process which
  104:    [[!template id=man name="inetd" section="8"]]
  105:    starts up runs as.
  106: 
  107:  * `server-program`: This field is the full path of the program that gets
  108:    started.
  109: 
  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
  113:    started.
  114: 
  115: That is all a lot to digest and there are other things the systems administrator
  116: can do with some of the fields. Here is a sample line from an `inetd.conf` file:
  117: 
  118:     ftp       stream  tcp    nowait  root   /usr/libexec/ftpd    ftpd -ll
  119: 
  120: From the left, the service-name is `ftp`, socket-type is `stream`, protocol is
  121: `tcp`,
  122: [[!template id=man name="inetd" section="8"]] won't
  123: wait for the server process to terminate (`nowait`), the process runs as user
  124: `root`, path is `/usr/libexec/ftpd` and program name and arguments are
  125: `ftpd -ll`. Notice in the last field, the program name is different from the
  126: service-name.
  127: 
  128: ## Services - /etc/services
  129: 
  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
  132: to a port number. The format of the `/etc/services` file is:
  133: 
  134:     service-name port-number/protocol-name [aliases]
  135: 
  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
  139: spaces. Comments may be added after a hash mark (`#`).
  140: 
  141: Let's take a look at the `ssh` entries as an example:
  142: 
  143:     ssh             22/tcp           # Secure Shell
  144:     ssh             22/udp
  145: 
  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
  148: every protocol a service can use (even on the same port).
  149: 
  150: ## Protocols - /etc/protocols
  151: 
  152: Another file read by
  153: [[!template id=man name="inetd" section="8"]] is
  154: `/etc/protocols`. This file has the information pertaining to DARPA Internet
  155: protocols. The format of the protocols name data base is:
  156: 
  157:     protocol-name number [aliases]
  158: 
  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
  161: alias names can be added after that.
  162: 
  163: Let's look at the seventh entry in the `/etc/protocols` db as an example:
  164: 
  165:     tcp     6       TCP             # transmission control protocol
  166: 
  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
  169: Protocol as indicated by the comment in that line.
  170: 
  171: ## Remote Procedure Calls (RPC) - /etc/rpc
  172: 
  173: The rpc program number data base used by services with the `rpc` protocol type
  174: in
  175: [[!template id=man name="inetd.conf" section="5"]]
  176: is kept in `/etc/rpc` and contains name mappings to rpc program numbers. The
  177: format of the file is:
  178: 
  179:     server-name program-number aliases
  180: 
  181: For example, here is the nfs entry:
  182: 
  183:     nfs             100003  nfsprog
  184: 
  185: # Allowing and denying hosts - /etc/hosts.allow, /etc/hosts.deny
  186: 
  187: As mentioned above, NetBSD's
  188: [[!template id=man name="inetd" section="8"]] has
  189: the tcpwrapper package built in via the libwrap library. As such,
  190: [[!template id=man name="inetd" section="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: [[!template id=man name="hosts\_access" section="5"]]
  195: manpage.
  196: 
  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
  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
  201: allowed, giving standard
  202: [[!template id=man name="inetd" section="8"]]
  203: behaviour.
  204: 
  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: [[!template id=man name="hosts\_access" section="5"]]
  212: for all the details.
  213: 
  214: An example configuration that is mostly open but denies access to services to a
  215: certain host and all machines from a certain domain would look like this:
  216: 
  217:     # /etc/hostname.deny:
  218:     ALL: some.host.name, .some.domain
  219: 
  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`.
  222: The entry for `/etc/hosts.deny` would be:
  223: 
  224:     # /etc/hosts.deny
  225:     ALL: ALL
  226: 
  227: The entry to allow a few hosts would be put into `/etc/hosts.allow`:
  228: 
  229:     # /etc/hosts.allow
  230:     ALL: friend.host.domain otherfriend.otherhost.otherdomain
  231: 
  232: ## Adding a Service
  233: 
  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: [[!template id=man name="inetd" section="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
  239: of POP3 on a NetBSD system.
  240: 
  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
  246: itself.
  247: 
  248: So the first half of the new entry in `/etc/inetd.conf` looks like this:
  249: 
  250:     pop3   stream  tcp     nowait  root
  251: 
  252: After installation, pkgsrc deposited cucipop in `/usr/pkg/sbin/cucipop`. So with
  253: the next field we have:
  254: 
  255:     pop3   stream  tcp     nowait  root /usr/pkg/sbin/cucipop
  256: 
  257: Last, we want to use the Berkeley mailbox format, so our server program must be
  258: called with the `-Y` option. This leaves the entire entry looking like so:
  259: 
  260:     pop3   stream  tcp     nowait  root /usr/pkg/sbin/cucipop cucipop -Y
  261: 
  262: We have added the service named `pop3` to `/etc/inetd.conf`. Next item to check
  263: is that the system can map the service name to a port number in `/etc/services`:
  264: 
  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)
  270: 
  271: The `pop3` entries here are of interest, i.e. they are already contained in the
  272: `/etc/services` file shipped with NetBSD.
  273: 
  274: Now, to have
  275: [[!template id=man name="inetd" section="8"]] use
  276: the new entry, we simply restart it using the rc script:
  277: 
  278:     # sh /etc/rc.d/inetd restart
  279: 
  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
  284: borrow the telnet entry and change parts where needed.
  285: 
  286: ## When to use or not to use inetd
  287: 
  288: The decision to add or move a service into or out of
  289: [[!template id=man name="inetd" section="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
  292: the administrator has to feel out if a service should be moved.
  293: 
  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: [[!template id=man name="inetd" section="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
  304: [[!template id=man name="inetd" section="8"]].
  305: 
  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: [[!template id=man name="inetd" section="8"]] meta
  310: daemon the effects of a heavily loaded service can also harm other services that
  311: use [[!template id=man name="inetd" section="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: [[!template id=man name="inetd" section="8"]]. The
  315: fix, in a situation like that, is to make the offending service run outside of
  316: [[!template id=man name="inetd" section="8"]] so
  317: the response time of both the service and
  318: [[!template id=man name="inetd" section="8"]] will
  319: increase.
  320: 
  321: ## Other Resources
  322: 
  323: Following is some additional reading and information about topics covered in
  324: this document.
  325: 
  326: NetBSD manual pages:
  327: 
  328:  * [[!template id=man name="inetd" section="8"]]
  329:  * [[!template id=man name="protocols" section="5"]]
  330:  * [[!template id=man name="rpc" section="5"]]
  331:  * [[!template id=man name="services" section="5"]]
  332:  * [[!template id=man name="hosts\_access" section="5"]]
  333: 
  334: Miscellaneous links:
  335: 
  336:  * [IANA: Protocol Numbers and Assignment Services](http://www.iana.org/numbers.htm)
  337:  * [RFC1700: Assigned Numbers](http://www.isi.edu/in-notes/rfc1700.txt)
  338: 

CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb