Using inetd

The traditional Linux super server is inetd. Debian 3.0, Slackware 9.0, and SuSE 8.1 all use inetd by default. Earlier versions of Mandrake and Red Hat also used inetd, but recent versions of these distributions have switched to xinetd. The inetd super server is configured via the /etc/inetd.conf file. This file contains comment lines that begin with hash marks (#) and server definition lines that take the following form:

service-name socket-type protocol flags user server args

Each field is separated from its neighbors by spaces or tabs. The meanings of these fields are listed here:

service-name This field is the name of the protocol, as defined in /etc/services. For instance, ftp stands for an FTP server and telnet is a Telnet server.

socket-type The socket type is normally either stream or dgram, although a few other options, such as raw, rdm, and seqpacket, are also possible. The appropriate value varies from one server to another, so consult the server's documentation to learn which you should use.

protocol Most servers use the tcp protocol, but a few servers use udp, and an even smaller number use other protocols. Servers that use the Remote Procedure Call (RPC) system to mediate connections specify a protocol of rpc/tcp or rpc/udp. In any event, the protocol must be listed in /etc/protocols. You should consult your server's documentation to learn which it uses.

flags You can pass a wait or nowait flag, which tells inetd whether the server is single-threaded or multithreaded, respectively. This option is only relevant for datagram (dgram socket type) servers; others use a nowait entry by convention. You can append a dot and a number to this entry to limit the number of instances of a server that inetd will allow to run at once. You can use this feature to limit the number of simultaneous connections your system will accept, thereby heading off potential CPU, memory, or network bandwidth use problems. If you omit the maximum connections number, it defaults to 40.

user This entry specifies the user under whose name the server is run. This value is frequently either root or nobody, but any user listed in /etc/passwd is valid. You can append a group name after a dot, as in ftp.servers to run the server as the ftp user in the servers group.

Warning Never run a server with higher privilege than is required. Doing so can pose a security risk in the event of a bug, or sometimes even when a server is operating normally. The privileges a server requires vary from one server to another, so consult its documentation for details.

server This field points to the server itself, such as /usr/sbin/vsftpd to launch vsftpd. The inetd server also supports a few protocols by itself. For these, the sen/erfield should read internal. If you use TCP Wrappers to launch a server, this field should read /usr/sbin/tcpd (of course, the path should be adjusted if tcpd resides somewhere else on your system).

args Many servers rely upon arguments passed to them on the command line. The final field is where you specify these arguments, separated by spaces, if necessary. If you launch a server via TCP Wrappers, the first argument is the name of the server you want to launch.

As an example, consider the following entry, which is from a SuSE system: ¡map stream tcp nowait root /usr/sbin/tcpd imapd

This entry tells inetd to listen on the imap TCP port (143) and to launch imapd via TCP Wrappers whenever a connection appears. This server is run with root privileges because it's an Internet Message Access Protocol (IMAP) server, which requires root privileges to process logins from any user who wants to retrieve e-mail via IMAP.

Most distributions that use inetd ship with many predefined entries for common servers; however, most of these entries are commented out by placing hash marks before each deactivated server. This practice ensures that a server won't be launched accidentally just because you've installed it; you must take active steps to activate the server by uncommenting the relevant line before it will work. Some protocols are represented by multiple entries, one for each server that can handle the protocol. If you want your system to use the protocol in question, you must decide which server to use and uncomment the correct inetd.conf entry. If you uncomment the wrong entry, the server won't respond. Some servers—particularly those that don't ship with a distribution—don't have default entries in inetd.conf. To use such a server, you must add the entry. The simplest way to do this is usually to copy a sample entry from the server's documentation. If the documentation doesn't provide such an entry, it may not have been designed to run from a super server, but you can try creating an entry by modifying another. You may have to guess at the socket-type, protocol, and flags fields, though.

Changing the inetd.conf settings will not change the way your currently running inetd process responds to incoming requests. Restarting the computer will accomplish this change, but much simpler methods are to restart inetd or to pass the server a HUP signal. You can restart inetd by stopping it and starting it again via its own SysV startup script, or usually by passing the script the restart option. For instance, you might type /etc/init.d/inetd restart on a SuSE system. You can do this manually by using kill and then launching inetd manually, as well, but using the SysV startup scripts is better if your system uses them. This approach has a major drawback, though: It's likely to kill any open connections mediated by inetd. To avoid this problem, pass the HUP signal, as in killall -HUP inetd. Some distributions support a reload option to their inetd SysV startup scripts to accomplish this goal, as well. For instance, /etc/init.d/inetd reload will do the job on Debian and SuSE systems.

If you implement changes to your inetd configuration and can't connect to the new server, check the system log files. You may find entries from inetd concerning an inability to find the program file, a socket already being open, or various other error conditions. Knowing what's causing a problem may suggest corrections, such as double-checking the filename in /etc/inetd.conf to correct a typo.

0 0

Post a comment