On a network-centric operating system, it's not uncommon for a lot of services to be running. Typically for each service that is available a program needs to be sitting around listening for connections, which can get a bit burdensome on a system that runs a lot of these servers. In order to reduce overhead, inetd was created. inetd is the “internet super-server”-- it sits around and listens for connections on many sockets, and when one comes in inetd fires up the appropriate server to handle it. Thus the many waiting servers are reduced to one.
/etc/inetd.conf is the configuration file for inetd. It specifies which servers get run for which connections. The inetd(8) man page has more detailed information, of course, but let's take a quick look at a basic service line:
ftp stream tcp nowait root /usr/sbin/tcpd wu.ftpd -l -i -a |
This is the line for the ftp server. Note the protocol name (“ftp”) first, and last the command to run to respond. In this case, the program that is run in response to a connection attempt is /usr/sbin/tcpd; it is a “wrapper” program that provides some basic security options for the server it wraps. wu.ftpd is our actual ftp server, but tcpd runs that for us. More information on tcpd is given in the section called tcp_wrappers.
Like many system files, lines in inetd.conf are commented by the # character; you can add and remove services from inetd simply by commenting their lines in or out and restarting inetd.
This is the file that tells the rest of the system where to get its DNS information. Any name servers you use are listed here, as well as your host's domain name. Here's a sample resolv.conf (from the laptop I'm typing this on, ninja.tdn):
domain tdn nameserver 192.168.1.1 search tdn. slackware.com |
The first line describes ninja's domain name; this is everything after the hostname in my address. The second is the DNS server for our house network. You can have as many of these as you need; they will be checked in order from first to last whenever a program needs to look up a domain name's corresponding IP address.
The last line is a bit more interesting. It describes any domain names that should be assumed by my system. For instance, suppose I have the machines zuul.tdn and hejaz.slackware.com. I can simply do ping zuul and ping hejaz to ping them, respectively. This is because ping first tries to add “.tdn” to zuul's name, and finds a match and goes with it. In the case of “hejaz”, it first tries “hejaz.tdn”. There's no match, so it then tries “hejaz.slackware.com”-- bingo. Note that all domains listed in the search line need to end with a '.' except the last one; if there's only one, it is the last one and needs no trailing '.'.
The hosts file allows the simplest kind of domain lookup. It is a list of hostnames and their corresponding IPs. This is useful in a small network where DNS is not worthwhile, in instances where DNS is unreliable, etc. and is used by the machine during boot time when no name servers are accessible. Mine might look like this:
127.0.0.1 localhost 192.168.1.32 ninja.tdn ninja |
The first line should be self-explanatory. The second, however, may not. You can list as many names and aliases for an address as you like, separated by a space. So I have “192.168.1.32” translated to “ninja.tdn” (and vice versa), but the alias “ninja” can also be used when I'm too lazy to type “.tdn” (which is most of the time).