| The most important decision related to networking is how host name mapping is implemented on your system in ARPA. Three techniques are available for host name mapping: 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 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 on 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.1localhostloopback 15.32.199.42a4410827 15.32.199.28a4410tu8 15.32.199.7a4410922 15.32.199.21a4410tu1 15.32.199.22a4410tu2 15.32.199.62a4410730 15.32.199.63hpxterm1 15.32.199.64a4410rd1 15.32.199.62a4410750hp1 This file is in the following format: <internet_address> <official_hostname> <alias> 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. Figures 9-3 through 9-6 described these classes in detail. 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 alias from the /etc/hosts file when issuing one of the ARPA or Berkeley 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 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 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. If the appropriate changes have been made to the appropriate entries in /etc/hosts, /etc/hosts.equiv, and /.rhosts, you can use the ARPA Services commands ftp and telnet, as well as the Berkeley commands rcp, rlogin, remsh, and rwho. 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. Your 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. | 
