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