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).