Host Name Mapping

The most important decision related to networking is how host name mapping is implemented on your system in Internet Services ARPA. Three techniques are available for host name mapping:

• Berkeley Internet Named Domain (BIND)

• Network Information Service (NIS)

• UNIX file /etc/hosts

The most common and simplest way to implement host name mapping is with /etc/hosts, so I cover this technique in the next 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.

Using the /etc/hosts file, as you are about to see, becomes very difficult for environments where there are many systems deployed. With this solution there is one /etc/hosts 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 names 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 accesses 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 /etc/resolv.conf 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 user aspect of these networking topics, as opposed to the system administration aspect of them.

/etc/hosts

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 /etc/hosts file is modified to contain the names of the systems on your network, they have provided the basis for rlogin to another system. Although you can now rlogin to other UNIX systems, you cannot yet rcp or remsh to another system. Although adding remsh and rcp functionality is easy, it does indeed compromise security, so it is not always set up on all systems. Here is an example /etc/hosts file:

127.0.0.1     localhost loopback
15.32.199.42  a4410827
15.32.199.28  a4410tu8
15.32.199.7   a4410922
15.32.199.21  a4410tu1
15.32.199.22  a4410tu2
15.32.199.62  a4410730
15.32.199.63  hpxterm1
15.32.199.64  a4410rd1
15.32.199.62  a4410750hp1

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 /etc/hosts 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 /etc/hosts file when issuing one of the ARPA or Berkeley Internet Services commands described earlier. For instance, either of the following ARPA commands work:

$ telnet a4410750
						

or

$ telnet hp1
						

Similarly, either of the following Berkeley commands works:

$ rlogin a4410750
						

or

$ rlogin hp1
						

/etc/hosts.equiv

Your system may be setup so that user's don't have to issue a password when they rlogin to a remote system, they can set up equivalent hosts by editing this file. As I mentioned earlier, this is technique sometimes considered a security risk, so it is not always employed. The login names must be the same on both the local and remote systems for /etc/hosts.equiv to allow the user to bypass entering a password. You can either list all the equivalent hosts in /etc/hosts.equiv or list the host and user name you wish to be equivalent. Users can now use rcp and remsh, because they are equivalent users on these systems. I usually just enter all the host names on the network. Here is an example of /etc/hosts.equiv:

a4410730
a4410tu1
a4410tu2
hpxterm1
a4410827
a4410750

Keep in mind the potential security risks of using /etc/hosts.equiv. 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 convenient to not have to enter a password when logging into a remote system, you have given every user in /etc/hosts.equiv 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.

/.rhosts

This file is the /etc/hosts.equiv for a superuser. If you log in as root, you want to have this file configured with exactly the same information as /etc/hosts.equiv. 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 /.rhosts 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.