If you are running TCP/IP, you can look in a couple of places for information
about your system. First, check out the file /etc/resolv.conf. If you don't find
it and you know you are running TCP/IP, don't worry! The fact that it is missing
tells you that you are not running a nameserver in your
network. If it is not there, you can find a list of
machines that your machine knows about and can contact by name in
you are running a nameserver, this information is kept on the nameserver itself.
The content of the /etc/hosts file is the IP
of a system followed
by its fully qualified name, and then any aliases you might want to use. A
common alias simply uses
the node name and omits the domain
name. Each line in the /etc/resolv.conf file contains one of a
couple different types of entries. The two most common entries are the
domain entry, which is set to
the local domain
name, and the nameserver, which is followed by the IP
of the name
"resolver." See the section on TCP/IP for more information on both of these files.
It's possible that your machine is the nameserver itself. To find this out,
look at the file /etc/named.conf. If this exists, it is probably a nameserver.
The /etc/named.conf file will tell you the directory where the
name server database information is kept. For information about the
meaning of these entries, check out the named man-page,
as well as the section on TCP/IP.
Another place to look is the start-up scripts in /etc/rc.d. Often, static
routes are added there. One likely place is /etc/rc.d/init.d/network. If these
static routes use tokens from either /etc/networks or
/etc/gateways that are
incorrect, then the routes will be incorrect. By using the
Although not as often corrupted or otherwise goofed up, a couple other files
require a quick peek. If you think back to our telephone switchboard analogy for
TCP, you can think of the
/etc/services file as the phone book that the operator uses to match names to
phone numbers. Rather than names and phone numbers, /etc/services matches the service requested to the appropriate port. To determine the characteristics of
the connection, inetd uses /etc/inetd.conf, which contains such information as whether to wait for the first process to finish before allowing new connections.
Other common places for confusion are incorrect entries and the inevitable
calls to support deals with user equivalence.
As I talked about in the section on TCP/IP, when user equivalence is
set up between machines, many remote commands can be executed without the user
having to produce a password. One more common misconception is the universality
of the /etc/hosts.equiv file. Though this file determines what
user equivalence should be established with what other machine, it does
not apply to one user: root. To me, this is rightly so. Though it does annoy
administrators who are not aware of this, it is nothing compared to the problems
that might occur if it did apply to root, and this is not what you would expect.
To allow root access, you need to create a .rhosts
file in roots home directory
(usually /) that contains the same information as /etc/hosts.equiv but
instead applies to the root account.
The most common mistake made with this file is the permission.
If the permission is such that any user other than root (as the owner of the
file) can read it, the user-equivalent mechanism will fail. See /etc/hosts.equiv
and $HOME/.rhosts to see which remote users have access to which user
A list of the essential system files can be found here.