The most important decision
to networking is how host name mapping is implemented on your system in Internet Services ARPA. Three techniques are available for host name mapping:
The most common and simplest way to implement host name mapping is with
, so I cover this technique in the
section. Keep in mind that there are probably networking manuals for your UNIX variant devoted to many networking topics including NFS, ARPA, and others. These manuals serve as a good reference material if you need to know more about networking than is covered here.
file, as you are about to see, becomes very difficult for environments where there are many systems deployed. With this solution there is one
file that must be kept up-to-date and propagated to all other systems.
The Domain Name System (DNS) is widely used in large environments. DNS uses Berkeley Internet Name Domain Service (BIND) to resolve
to addresses. There are name servers that fill a request for name data. This is the server side to BIND. There is a client side to BIND, called the resolver, that
the name server(s) to resolve names. Using this client/server model, it is much easier to maintain naming information, because it only needs to be kept in a few places as opposed to one for each system.
Clients use a file called
to configure the resolver. The name server and its corresponding address are the keys to resolving information.
This solution makes it much easier to maintain system names and addresses in large environments. DNS and BIND are primarily a system administration exercise to setup. From a user standpoint, you don't need to know much about them. What I will instead focus on in the upcoming sections are some of the programs in which users are more interested. I will supply some background so that the way in which the programs are used has more meaning. In general, though, I'll concentrate on the
aspect of these networking topics, as opposed to the system administration aspect of them.
This file contains information about the other systems to which you are connected. It contains the Internet address of each system, the system name, and any aliases for the system name. If the
file is modified to contain the names of the systems on your network, they have provided the basis for
to another system. Although you can now
to other UNIX systems, you cannot yet
to another system. Although adding
functionality is easy, it does indeed compromise security, so it is not always set up on all systems. Here is an example
127.0.0.1 localhost loopback
This file is in the following format:
The Internet Protocol address (IP address) is a class "A," "B," or "C" address. A class "A" network supports many more nodes per network than either a class "B" or "C" network. The purpose of breaking down the IP address into four fields is to define a node (or host) address and a network address. These were described in detail in figures 9-3 through 9-6.
Assuming that the above
file contains class "C" addresses, the rightmost field is the host or node address, and the other three fields comprise the network address.
You could use either the official_hostname or the alias from the
file when issuing one of the ARPA or Berkeley Internet Services commands described earlier. For instance, either of the following ARPA commands work:
Similarly, either of the following Berkeley commands works:
Your system may be setup so that user's don't have to issue a password when they
to a remote system, they can set up equivalent hosts by editing this file. As I mentioned earlier, this is technique sometimes
a security risk, so it is not always employed. The login names must be the same on both the local and remote systems for
to allow the user to bypass entering a password. You can either list all the equivalent hosts in
or list the host and user name you wish to be equivalent. Users can now use
, because they are equivalent users on these systems. I usually just enter all the host names on the network. Here is an example of
Keep in mind the potential security risks of using
. If a user can log into a remote system without a password, you have reduced the overall level of security on your network. Even though users may find it
to not have to enter a password when logging into a remote system, you have given every user in
access to the entire network. If you could ensure that all the permissions on all the files and directories on all systems were properly set up, then you wouldn't care who had access to what system. In the real UNIX world, however, permissions are sometimes not what they are supposed to be. Users have a strong tendency to "browse around," invariably stumbling upon a file they want to copy to which they really shouldn't have access.
This file is the
for a superuser. If you log in as root, you want to have this file configured with exactly the same information as
. If you do, however, you have compounded your network security risk by allowing superuser on any system to log in to a remote system without a root password. If you are the undisputed ruler of your network and you're 100 percent certain that no security holes exist, then you may want to set up
so that you don't have to issue a password when you log in remotely to a system as superuser. From a security standpoint, however, you should know that this setup is frowned upon.
I have described the process of setting up the appropriate files to get the most commonly used ARPA Services up and running. There is sometimes even more advanced functionality, such as DNS/BIND, required. You system may have DNS/BIND or similar functionality set up that gives you access to some or all of the commands covered throughout this section.