The inetd and xinetd programs are daemon processes. You probably know that daemons are special programs that, after starting, voluntarily release control of the terminal from which they started. The only mechanism by which daemons can interface with the rest of the system is through interprocess communication (IPC) channels, by sending entries to the system-wide log file, or by appending to a disk file.

The role of inetd is as a “superserver” for other network server-related processes, such as telnet and ftp. It’s a simple philosophy: Not all server processes (including those that accept new telnet and ftp connections) are called upon so often that they require a program to be running in memory all the time. So instead of constantly maintaining potentially dozens of services loaded in memory waiting to be used, they are all listed in inetd’s configuration file, /etc/inetd.conf. On their behalf, inetd listens for incoming connections. Thus only a single process needs to be in memory.

A secondary benefit of inetd falls to those processes needing network connectivity but whose programmers do not want to have to write it into the system. The inetd program will handle the network code and pass incoming network streams into the process as its standard-in (stdin). Any of the process’s output (stdout) is sent back to the host that has connected to the process.

NOTE

Unless you are programming, you don’t have to be concerned with inetd’s stdin/ stdout feature. On the other hand, for someone who wants to write a simple script and make it available through the network, it’s worth exploring this very powerful tool.

As a general rule of thumb, low-volume services (such as Telnet) are usually best run through the inetd, whereas higher-volume services (such as Web servers) are better run as a standalone process that is always in memory ready to handle requests.

Current distributions of Red Hat and Mandrake started using a newer version of inetd called xinetd. The xinetd program accomplishes the same task as the regular inetd program, yet it includes a new configuration file format and some additional features.

Unfortunately, xinetd uses a format that is very different than the classic inetd configuration file format. (Most other variants of UNIX, including Solaris and FreeBSD, use the classic inetd format.) This means that if you have an application that relies on inetd, you may need to provide some hand adjustments to make it work. Of course, you should definitely contact the developers of the application and let them know of the change so that they can release a newer version that works with the new xinetd configuration format, as well.

In this section, we will cover the new xinetd daemon. If your system uses inetd, you should be able to read /etc/inetd.conf and see the similarities between inetd and xinetd.

The /etc/xinetd.conf file consists of a series of blocks that take the following format:

blockname
{
    variable = value
}

where blockname  is the name of the block that is being defined, variable is the name of a variable being defined within the context of the block, and value is the value assigned to the variable. Every block can have multiple variables defined within.

One special block exists which is called “defaults.” Whatever variables are defined within this block are applied to all other blocks that are defined in the file.

An exception to the block format is the includedir directive, which tells xinetd to go read all the files in a directory and consider them to be part of the  /etc/xinetd.conf file.

Any line that begins with a number sign (#) is the start of a comment. The stock /etc/inetd.conf file that ships with Red Hat 7.3 looks like this:

#
# Simple configuration file for xinetd
#
# Some defaults, and include /etc/xinetd.d/
defaults
{
       instances         = 60
       log_type          = SYSLOG authpriv
       log_on_success    = HOST PID 
       log_on_failure    = HOST RECORD
}
includedir /etc/xinetd.d

Don’t worry if all of the variables and values aren’t familiar to you yet; we will go over those in a moment. Let’s first make sure you understand the format of the file.

In this example, the first four lines of the file are comments explaining what the file is and what it does. After the comments, you see the first block: defaults. The first variable that is defined in this block is instances, which is set to the value of 60. Four variables in total are defined in this block, the last one being log_on_failure. Since this block is titled defaults, the variables that are set within it will apply to all future blocks that are defined. Finally, the last line of the file specifies that the /etc/xinetd.d directory must be examined for other files that contain more configuration information. This will cause xinetd to read all of the files in that directory and parse them as if they were part of the /etc/xinetd.conf file.