FInd Prime number in java

class FindPrime {
public static void main(String args[]) {
int num;
boolean isPrime = true;
num = 14;
for(int i=2; i <= num/2; i++) {
if((num % i) == 0) {
isPrime = false;
break;
}
}
if(isPrime) System.out.println("Prime");
else System.out.println("Not Prime");
}
}

TCP/IP Administration

TCP/IP is one of the most common networks used for connecting UNIX System computers. TCP/IP networking utilities are part of UNIX. Many networking facilities such as the Mail System and NFS can use a TCP/IP network to communicate with other machines. (Such a network is required to run the Berkeley remote commands and the DARPA commands.

This chapter will discuss what is needed to get your TCP/IP network up and running. You will need to

1. Obtain an Internet address.

2. Install the Internet utilities on your system.

3. Configure the network for TCP/IP.

4. Configure the TCP/IP startup scripts.

5. Identify other machines to your system.

6. Configure the STREAMS listener database.

7. Start running TCP/IP.

Once you have TCP/IP running, you need to administer, operate, and maintain your network. Some areas you may be concerned with will also be addressed, including

• Security administration

• Troubleshooting

• Some advanced features available with TCP/IP

Internet Addresses

You need to establish the Internet address you will be using on your machine before you begin the installation of the Internet utilities. If you are joining an existing network, this address is usually assigned to you. If you are starting your own network, you need to obtain a network number and assign Internet addresses to all your hosts.

Internet addresses permit routing between computers to be done efficiently, much as telephone numbers are used to efficiently route calls. Area codes define a large number of telephone exchanges in a given area; exchanges define a group of numbers, which in turn define the phone on your desk. If you call within your own exchange, the call need only go as far as the telephone company office in your neighborhood that connects you to the number you are calling. If you call within your area code, the call need only go to the switching office at that level. Only if you call out of your area code is switching done between switching offices. This reduces the level of traffic, since most connections tend to stay within a small area. It also helps to quickly route calls.

The Format of Internet Addresses

The Internet has long been run on Version 4 of the Internet Protocol, or IPv4, for short. In IPv4, Internet addresses are 32 bits, separated into four 8-bit fields (each field is called an octet), separated by periods. Each field can have a value in the range of 0–255. The Internet address is made of a network address followed by a host address. (Version 6 of the Internet Protocol, IPv6, may eventually replace IPv4. In IPv6, Internet addresses have a different form that supports many more addresses.)

Obtaining IP Addresses

The Internet Corporation for Assigned Names and Numbers (ICANN) manages and coordinates the Domain Name System (discussed in depth later in this chapter). This system ensures that every Internet address used anywhere in the world is unique. Furthermore, it ensures that every user on the Internet is able to locate all valid addresses and every domain name is mapped to the correct IP address. If you want to register a new domain name for your company or organization and obtain a block of IP addresses, you need to register this domain name with one of many different domain name registrars, each accredited by ICANN. (You can find a list of accredited registrars at http://www.internic.net/regist.html.) Of course, your new domain name cannot be the same as one already taken by another organization. The domain name registrar you contact will be able to tell you if you have selected an available domain name and will be able to help you find a unique domain name if you have trouble finding one not already taken.

Once you have selected your new domain name, the registrar you select will ask you to submit contact and technical information and will give you a registration contract specifying the terms under which your registration is accepted and maintained. The registrar submits the appropriate information about your domain name and the Internet address or addresses associated with that name to the appropriate Network Information Center (NIC). The NIC maintains a database keeping track of which domain name corresponds to which IP address in the domain name service. This information can then become available to other computers throughout the world through the Domain Name Service (DNS). You will also be required to enter a registration contract with the registrar, which sets forth the terms under which your registration is accepted and will be maintained.

If you only need an IP address for your particular computer, or you have a small organization and do not want to register a domain name yourself, your Internet service provider (ISP) can obtain an IP address for you and assign you a domain name that is a subdomain of its own domain.

Network Addresses

In IPv4, the network of each Internet domain is assigned a class, or level of service. Depending on the size of the domain, that is, the number of Internet addresses it supports, a network may be of class A, B, or C. The network addresses of Class A networks consist of one field, with the remaining three fields used for host addresses. Consequently Class A networks can have as many as 16,777,216 (256×256×256) hosts. The first field of a Class A network is, by definition, in the range 1–126. Any network addresses that start with 127 are loopback addresses. A loopback address is used to test your computer’s connectivity capability and tell you if your network is set up correctly The official site for loopback testing is at 127.0.0.1.

The network addresses of Class B networks consist of two fields, with the remaining two fields used for host addresses. Consequently, Class B networks can have no more than 65,536 (256×256) hosts. The first field of a Class B network is, by definition, in the range 128–191.

The network addresses of Class C networks consist of three fields, with one field used for host addresses. Consequently, Class C networks can have no more than 256 hosts. As you can see, Class A addresses allow many hosts on a small number of networks, Class B addresses allow more networks and fewer hosts, and Class C addresses allow very few hosts and many networks. The first field of a Class C network is, by definition, in the range 192–254.

Although all Internet addresses currently follow this structure, work is proceeding in the IETF (Internet Engineering Task Force) standards group to move to a new hierarchy scheme called IPv6 (Internet Protocol Version 6). You can find more about this protocol at http://www.ipv6.com/. Many vendors are involved in deploying this architecture to their networks and hardware devices, but they are doing so slowly to maintain compatibility with existing systems. An international test bed backbone for IPv6 (called 6bone) is dedicated to aiding the deployment of IPv6 worldwide. It is on the web at http://www.6bone.net/.

Host Addresses

After you have received a network address, you can assign Internet addresses to the hosts on your network. Because most public networks are Class C networks, it is assumed that your network is in this class. For a Class C network, you use the last field to assign each machine on your network a host address. For instance, if your network has been assigned the address 192.11.105 by an authorized agent such as NSI or one of the newer authorizing agents, you use these first three fields and assign the fourth field to your machines. You may use the first valid number, 1, in the fourth field for the first machine to be added to your network, which gives this machine the Internet address 192.11.105.1. As you add machines to your network, you change only the last number. Your other machines will have addresses 192.11.105.2, 192.11.105.3, 192.11.105.4, and so on.

Each of the network classes (A, B, and C) uses the concept of a netmask to define which part of the IP address is the network address and which part is the actual host ID. For example, a Class B network has a default mask of 255.255.0.0. The fields containing the O’s are what define your host, and the others (the first two fields) mask the network ID portion. For example, 135.18.64.100 has a network address portion of 135.18 and a host ID portion of 64.100. The Class A default is 255.0.0.0, and the Class C default mask is 255.255.255.0. You may not have access to all of the addresses within the portion that is normally reserved for the host ID, though. With the ever-increasing demand for Internet addresses for host machines, the pool of numbers is decreasing. Some ISPs use a portion of what would normally be the host ID area for the network. For instance, in a Class C network, the ISP may use a netmask that is not on an 8-bit boundary, such as 192.11.105.192, which has a 26-bit netmask. This leaves only 62 possible IP addresses for hosts on this particular network.Table below shows how the classes and netmasks relate, and shows some sample host IP addresses for each class.

Table: Network Classes and Their Netmasks, Including Host IP Examples

Class	Netmask	Example Host IP Address
A	255.0.0.0	108.15.121.9
B	255.255.0.0	148.22.99.154
C	255.255.255.0	220.18.44.109
Loopback	255.255.255.0	127.0.0.1

Installing and Setting Up TCP/IP

You most likely already have TCP/IP installed on your system if you are running a UNIX variant, but if not, you can install the TCP/IP system on your computer, for instance, using pkgadd. You will need to know the Internet address for your machine and the network that your machine will be part of. The installation procedure prompts you for both of these as it does a basic setup of some of the configuration files.

There may be other dependencies for this package to be installed, so check the documentation that comes with the Internet utilities to be sure that you have everything else that you need.

Network Provider Setup

TCP/IP requires a network provider to communicate with other machines. This network provider can be a high-speed LAN such as Ethernet, or it can be a WAN that communicates via dial-up lines to remote machines and networks. Whichever network provider you use will need to be configured using netcfg (the root program for configuring and managing network interfaces) or ifconfig (configures a network interface).

Your hardware provider may have also supplied a network interface card for your particular configuration. In either situation, consult the documentation that came with your network interface hardware or TCP/IP package for more information on setting up the network provider.

Configuring the Network Interface Card

You use the ifconfig utility to set up your NIC (network interface card), sometimes called an Ethernet card. For example, if you want to configure a 3COM 3C509 card (device e130) on an HP-UX system to be at address 135.16.88.37 on a default net mask and a default broadcast mask f or that network, you would enter

#ifconfig e130  135.16.88.37

For a Linux system, the first Ethernet device is defined as eih0, regardless of the NIC used. The equivalent command would be

#ifconfig eth0 135.16.88.37

Solaris uses le0 as the first Ethernet device for 10 Mb Ethernet NICs, so its equivalent command would be

#ifconfig le0 135.16.88.37

(Note that Solaris uses eri0 for newer 10/100 Mb Ethernet devices and hme0 for the older Ultra 10/100 Mb Ethernet devices.) This would also set the netmask address to its default (255.255.0.0) and the broadcast address to its default (here, 135.16.255.255, since the address is on the 135.16 network). Note that in Solaris, to configure the NIC without having to reboot, where you have previously installed the hardware, you need to initialize, or plumb, the network card using the command

#ifconfig le0 plumb

If you already have an entry in your /etc/hosts file that maps the hostname to the IP address (see the next section), you can use it instead of the IP address. For example, if the previous machine with IP address 135.16.88.97 had the hostname bumble, you would type

#ifconfig devname bumble

where devname is the associated device name for your Ethernet card, as seen in the previous examples (such as e130, eth0, or le0).

The hosts File

To get TCP/IP working on other machines, you must first define the machines that you would like to talk to in the file /etc/hosts. This file contains an entry on a separate line for each machine you want to communicate with. Before you add any hosts, there will already be some entries in this file that are used to do loopback testing. You should add the new machines to the bottom of the file. This is the format of the file:

• Internet-address host-name host-alias

Here, the first field, Internet-address, contains the number assigned to the machine on the Internet; the second field, host-name, contains the name of the machine; and the third field, host-alias, contains another name, or alias, that the host is known by (such as its initials or a nickname). For example, if you wanted to talk to the machine moon, with alias luna, and Internet address 192.11.105.100, the line in this file for moon would look like this:

192.11.105.100  moon    luna

The most important entry in the hosts file is the entry for your own machine. This entry lets you know which network you belong to and helps you to understand who is in your network. Note that if a machine you need to talk to is not on the same network as your machine, TCP/IP still allows you to talk to it using a gateway (discussed in a later section of this chapter).

Listener Administration

Now that you have TCP/IP configured, you may want to use it as a transport provider for your networking service. If your variant of UNIX supports TLI, you can do this by setting up your TLI listener, which is used to provide access to the STREAMS services from remote machines. Note that Linux does not support TLI. To set up the TLI listener, you must first determine the hexadecimal notation for your Internet address. To create a listener database for TCP/IP, first initialize the listener by typing this:

# nlsadmin −i tcp

This creates the database needed by the listener. Next, tell the listener the hexadecimal form of your Internet address so that it can listen for requests to that address. Do this by running a command of the form

# nlsadmin −1 \xhexadecimal_address tcp

For example, if the hexadecimal number of your listener address is 00020401c00b6920, you prefix this number with \x and append 16 zeros to the number. You type this:

# nlsadmin −1 '\x00020401c00b69200000000000000000' tcp

Every service you want to run over TCP/IP needs to be added to the listener’s database. For instance, if you want to run uucp over TCP/IP, make sure that there is an entry in the database for this service.

You can modify the listener database in two ways, either by using nlsadmin or by using sacadm or pmadm . You can enter service codes for additional services that you want to run over TCP/IP by consulting the administrative guide for each service.

Starting TCP/IP

You must have TCP/IP running on your machine for users to be able to access the network. To start TCP/IP after you load it onto your system, you might need to reboot the machine. This is important on some machines because some of the changes you might have made take effect only if you reboot. To reboot most UNIX variants, you can use the shutdown command with the following options:

# /etc/shutdown −y −g0 −16

Most newer UNIX variants, including Linux and Solaris, normally do not need to be rebooted, because TCP/IP is enabled in the kernel and should start up with your system. If, for any reason, things seem to be working improperly, you may choose to reboot. Most versions of Linux support the shutdown command, and the –r option tells the system to reboot after shutdown is complete. For example,

# shutdown −r now

does an immediate (now) shutdown and then reboots. Linux users may also use the reboot command to perform the same task.

These procedures automatically reboot the machine, bringing it back up to the default run level for which you have your machine configured. To see whether TCP/IP processes are running, type this:

$ ps −ef | grep inetd

This tells you whether the network daemon inetd (the master Internet daemon) is running. The configuration information for this daemon is contained in the file /etc/indetd.conf, which contains daemons for all of the services in your Internet environment, such as the ftp daemon (ftpd), the telnet daemon (telnetd), the talk daemon (talkd), and the finger daemon (fingerd). The inetd daemon should be started by the /etc/init.d/inetinet script for machines running Solaris, HP-UX, or other UNIX variants built on UNIX System V, or by the /etc/rc.d/init.d/inet script on Linux. If you do not see it, you should stop the network by using the command

# /etc/init.d/inetinit stop

and then restart the network by typing this:

# /etc/init.d/inetinit start

If this fails, check your configuration files to make sure that you have not forgotten to do one of the steps previously covered in configuring the machine for TCP/IP. Every time you reboot your machine, TCP/IP will start up if it is configured properly

TCP/IP Security

Allowing remote users to transfer files, log in, and execute programs may make your system vulnerable. TCP/IP provides some very good security capabilities, but nevertheless there have been some notorious security problems in the Internet.

In particular, the files hosts.equiv and .rhosts capabilities provide some protection from access by unauthorized users, but it is difficult to use them to control access adequately, while still allowing authorized users to access the system. You can provide a more secure environment by using the secure shell (ssh). This feature provides encryption of information when you are logged in to a remote machine.

TCP/IP Security Problems

One of the most famous examples of a TCP/IP security problem was the Internet worm of November 1988. The Internet worm took advantage of a bug in some versions of the sendmail program (sendmail administration is discussed later in this chapter) used by many Internet hosts to allow mail to be sent to a user on a remote host.

The worm interrupted the normal execution of hundreds of machines running variants of UNIX, including the BSD System. Fortunately, the bug had already been fixed in the UNIX System V sendmail program, so that machines running UNIX System V were not affected. This worm and other security attacks have shown that it is necessary to protect certain areas by monitoring daemons and processes that could cause a breach in security Two of these are

• fingerd (the finger service daemon)

• rwhod (the remote who service daemon)

Both of these daemons supply information to remote users about users on your machine. If you are trying to maintain a secure environment, you may not want to let remote users know who is logging in to your machine. This data could provide information that could be used to guess passwords, for example. The best way to control the use of the daemons is simply not to run them on your system. For example, you can disable the finger daemon, by modifying the line

finger  stream  tc      nowait  nobody  /usr/sbin/in.fingerd    in.fingerd

in the file /etc/inetd.conf to look like

# finger   stream  tc   nowait  nobody  /usr/sbin/in.fingerd   in.fingerd

The pound sign (#) comments the line out.

In general, remember that as long as you are part of a network, you are more susceptible to security breaches than if your machine is isolated. It is possible for someone to set up a machine to masquerade as a machine that you consider trusted. Gateways can pass information about your machine to others whom you do not know, and routers may allow connections to your machine over paths that you may not trust. It is good practice to limit your connectivity into the Internet to only one machine, to disable all services that you know you do not need, and to gateway all of your traffic to the Internet via your own gateway You can then limit the traffic into the Internet or stop it completely by disconnecting the gateway into the Internet.

Utilities for Added Security

There are utilities that are available over the Internet to help you monitor your network traffic and identify intrusions. There are others, such as Tripwire at http://www.tripwiresecunty.com/, which prevents file replacement by intruders, and COPS (Computer Oracle and Password System), which can be downloaded from http://www.ciac.org/ciac/ToolsUnixSysMon.html, which checks file permissions security You can also use a package such as SARA (Security Auditor’s Research Assistant) or SAINT (Security Administrator’s Integrated Network Tool). SARA and SAINT examine TCP/IP ports on other systems on the network to discover common vulnerabilities. (Both SARA and SAINT incorporate an earlier package called SATAN [Security Administrator’s Tool for Analyzing Networks], which was also known as SANTA.) Many other tools have been developed to monitor your network’s security For an up-to-date list of network monitoring tools, go to the CERT web site, http://www.cert.org/. You can find a UNIX security checklist at http://www.cert.org/tech_tips/usc20_fullhtml. (CERT [Computer Emergency Response Team] is a network security body run by Carnegie Mellon University)

You might also want to use a program called tcp_wrappers, created by Wietse Venema, a well-known security expert. Venema has created a number of other security-related routines; the index page for all of his tools is at ftp://ftp.porcupine.org/pub/security/. The tcp_wrappers utility can be used to detect and log information that may indicate network intrusions (including spoofing). It logs the client host name of any incoming attempts to use ftp, telnet, or finger, or else to perform remote executions.

Another useful tool that you can use to identify security vulnerabilities is Nessus, which is a comprehensive vulnerability scanning program. Nessus consists of a daemon, nessusd, which performs the scanning, and a client, nessus, which presents results to the user. You can use Nessus to carry out a port scan using its internal port scanner to determine which ports are open on a target host machine. Once Nessus finds the open ports, it then tries to run different exploits that can take advantage of possible vulnerabilities, on the open ports. To learn about Nessus and to download it free of charge, go to http://www.nessus.org/.

AdministeringAnonymous FTP

The most important use of FTP is to transfer software over the Internet. You will see how you can offer files on your machine via anonymous FTP to remote users.

When you enable anonymous FTP, you give remote users access to files that you choose, without giving these users logins. Many UNIX systems include a script for setting up anonymous FTP. If your system does not provide such a script, you can set up anonymous FTP by following these steps. Note that the directories used to store the information may differ slightly among variants from this example, but the process is the same. To set up anonymous FTP,

1. Add the user ftp to your /etc/passwd and /etc/shadow files.

2. Create the subdirectories bin, etc, and pub in /var/home/ftp.

3. Copy /usr/bin/ls to the subdirectory /var/home/ftp/bin.

4. Copy the files /etc/passwd, /etc/shadow, and /etc/group to /var/home/ftp/etc.

5. Edit the copies of /etc/passwd and /etc/shadow so that they contain only the following users: root, daemon, uucp, and ftp.

6. Edit the copy of /etc/group to contain the group other, which is the group assigned to the user ftp.

7. Change permissions on the directories and files in the directories under /var/home/ ftp, using the permissions given in table below:
   
   

   Permissions Used to Enable Anonymous FTP

   File or Directory	Owner	Group	Mode
   ftp	ftp	other	555
   ftp/bin	root	other	555
   ftp/bin/ls	root	other	111
   ftp/etc	root	other	555
   ftp/etc/passwd	root	other	444
   ftp/etc/shadow	root	other	444
   ftp/etc/group	root	other	444
   ftp/pub	ftp	other	777

8. Check that there is an entry in /etc/inetd.conf for in.ftpd.

9. Put files that you want to share in /var/home/ftp/pub.

After you complete all these tasks, remote users will have access to files in the directory /var/home/ftp/pub. Remote users may also write to this directory We offer a word of caution here, however. Making a directory on your machine a repository that others can write to may result in content that drains resources or is inappropriate for the machine (such as MP3 audio files).

Troubleshooting TCP/IP Problems

Some standard tools are built into TCP/IP that allow the administrator to diagnose problems. These include ping, netstat, and ifconfig.

ping

If you are having a problem contacting a machine on the network, you can use ping to test whether the machine is active. ping responds by telling you that the machine is alive or that it is inactive. For example, if you want to check the machine ralph, type this:

$ ping ralph

If ralph is up on the network, you see this:

ralph is alive

But if ralph is not active, you see this:

no answer from ralph

Although a machine may be active, it can still lose packets. You can use the −s option to ping to check for this. For example, when you type

$ ping −s ralph

ping continuously sends packets to the machine ralph. It stops sending packets when you hit the BREAK key or when a timeout occurs. After it has stopped sending packets, ping displays output that provides packet-loss statistics.

You can use other options to ping to check whether the data you send is the data that the remote machine gets. This is helpful if you think that data is getting corrupted over the network. One example of this is using the ping command with the –s option, which performs a ping every second, until you end the ping request (usually with a CTRL-C). The results of a successful four-second ping like this for machine dodger, at IP address 135.18.99.6, would be

# ping dodger
64 bytes from dodger (135.18.99.6): icmp_seq=1.  time=38.   ms
64 bytes from dodger (135.18.99.6): icmp_seq=2.  time=25.   ms
64 bytes from dodger (135.18.99.6): icmp_seq=3.  time=45.   ms
64 bytes from dodger (135.18.99.6): icmp_seq=4.  time=36.   Ms
----dodger PING statistics---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip (ms)   min/avg/max   25/36/45

You can also specify that you want to send data packets of a different size than standard. Here the default is used (64 bytes), but you may want to diagnose how bigger blocks are handled, particularly if you think your network is slow. For instance, you would type

# ping −s dodger 4096

to request that 4,096 bytes be sent back each time from dodger to see if they all come back. Check your system’s manual page for ping to learn more about its options. If you are a user of Windows9x/NT, the options are very similar to those you would use when running an add-on vendor package such as WSPing32, which is a commercial version of ping for Windows machines with more functionality than just the built-in Windows utility

netstat

When you experience a problem with your network, you need to check the status of your network connection. You can do this using the netstat command. You can look at network traffic, routing table information, protocol statistics, and communication controller status. If you have a problem getting a network connection, check whether all connections are being used, or whether there are old connections that have not been disconnected properly

For instance, to get a listing of statistics for each protocol, type this:

$ netstat −s
ip:
  385364 total packets received
  0 bad header checksums
  0 with size smaller than minimum
  0 with data size <>

The preceding example is a report on the connection statistics. If you find many errors in the statistics for any of the protocols, you may have a problem with your network. It is also possible that a machine is sending bad packets into the network. The data gives you a general picture of the state of TCP/IP networking on your machine.

If you want to check out the communication controller, type this:

$ netstat −I
Name   Mtu    Network   Address    Ipkts   Ierrs   Opkts   Oerrs   Collis
1o0    2048   loopback  localhost     28       0      28       0        0

The output contains statistics on packets transmitted and received on the network.

If, for example, the number of collisions (abbreviated to “Collis” in the output) is high, you may have a hardware problem. On the other hand, if as you run netstat –i several times you see that the number of input packets (abbreviated to “Ipkts” in the output) is increasing, while the number of output packets (abbreviated to “Opkts” in the output) remains steady, the problem may be that a remote machine is trying to talk to your machine, but your machine does not know how to respond. This may be caused by an incorrect address for the remote machine in the hosts file or by an incorrect address in the /etc/ethers file.

Checking the Configuration of the Network Interface

You can use the ifconfig command to check the configuration of the network interface. For example, to obtain information on the Ethernet interface installed in slot 4, type this:

# /usr/sbin/ifconfig emd4
emd4: flags=3
inet 192.11.105.100 netmask ffffff00 broadcast 192.11.105.255

This tells you that the interface is up, that it is a broadcast network, and that the Internet address for this machine is 192.11.105.

Netcat, the “TCP/IP Swiss Army Knife”

Experienced system and network administrators often identify netcat, the “TCP/IP Swiss Army Knife,” as one of the more useful tools for debugging network problems and for identifying network security vulnerabilities. Basically, netcat is a general-purpose utility that can read and write data across a network, using either the TCP or UDP. It can be thought of as the network analog of the cat command on your local system. Recall that cat command can be used to write to a file or to read from a file on a UNIX system. Netcat can do the same things, but over a network, and can be used, using its various options and as part of scripts, to carry out an amazing variety of tasks over a network. If netcat is not already available on your system, you can download the GNU version of netcat from http://netcat.sourceforge.net/. This version runs without changes on Linux, Solaris, FreeBSD, NetBSD, and Mac OS X, and with minor changes on other UNIX variants. Some distributions of netcat include a set of sample scripts for carrying out basic tasks, including probing remote hosts, copying files over the network, and so on.

When you run netcat (by running either the netcat command or the nc command, depending on the version you have), you can connect to a remote host on a specified port and send your input to the service that answers on that port. For example, if you connect to port 25 on a remote host using netcat, you can determine whether the SMTP daemon is running on this port, as expected. If it is, you can use netcat to interactively test whether SMTP is running properly on this remote host. Similarly, you can interactively test other TCP/IP services, including FTP (port 21), POP3 (port 110), IMAP (port 143), HTTP (port 80), and so on.

The telnet command, which can be used for remote login over a TCP network. Note that telnet does not provide the same functionality as netcat. The netcat command has been designed to be much more useful that the telnet command. Netcat can be set up to listen for incoming connections, while telnet cannot; telnet only supports TCP and not UDP, and netcat can easily be used in a script, while telnet cannot be.

Examples of netcat Use

We will illustrate the use of netcat with two examples. (Here we use the GNU netcat command; other versions of netcat are run using the nc command for netcat. You should check to see which of these two commands is supported on your system. Generally, these two commands take the same options.) First, note that you can use netcat to send a file over a network. To send a file, you need to run netcat on both the host that is sending the file, say host1, and the host that is receiving the file, say host2. For example, on host2 you could run the command

# netcat −1 −p 3000 −v > test

to tell netcat to listen (using the –l option) on port 3000 (using the –p option). On host1, you then run

# cat test | netcat host2 3000 −q 5

to send the file test to netcat, which then sends this file to host2 on port 3000. The –q option tells netcat to quit five seconds after the end of the file (EOF). The –v (verbose) option is used to provide brief diagnostic messages, including when the connection was made and the sending and receiving hosts; the option –vv can be used to provide complete diagnostic messages, including the amount of data transmitted.

Next, we will show how you can use netcat to scan a range of ports on a remote host. For example, you can use

# netcat −v −w 3 −z 192.20.5.55 20–30

to scan all ports between 20 and 30, inclusive, on the remote host with IP address 192.20.5.55. Here the –w option with the argument 3 tells netcat to wait three seconds before reporting that a particular port did not respond, and the –z option tells netcat not to send any data to each of the ports being scanned. (Another important tools for port scanning is the powerful nmap [network mapper] program. See http://www.insecure.org/nmap/ for more information on nmap.)

System administrators and network administrators have found many ways to effectively use netcat for a wide variety of tasks. Unfortunately, malicious hackers have also figured out ways to take advantage of netcat for attacking remote hosts. Because of this, use of netcat is often limited by various security policies and systems.

For more information on netcat, go to http://www.vulnwatch.org/netcat/readme.html. To learn more about netcat and how it can be used by hackers, go to http://www.onlamp.eom/pub/a/onlamp/2003/05/29/netcat.html. There is also a version of netcat that encrypts data sent over connections, called CryptCat; you can learn about CryptCat at http://farm9.org/Cryptcat/.

Advanced Features

Other capabilities can be enabled once your system supports TCP. We will briefly discuss some of these capabilities here. Their configuration can be quite complicated.

Name Server

You can designate a single machine as a name server for your TCP/IP network. When you use a name server, a machine wishing to communicate with another host queries this name server for the address of the remote host. So, the machine itself does not need to know the Internet addresses of every machine it can communicate with. This simplifies administration because you only have to maintain an /etc/hosts file on one machine. All machines in your domain can talk to each other and the rest of the Internet using this name server. Using a name server also provides better security because Internet addresses are only available on the name server, limiting access to addresses to only the people who have access to the name server.

Just because some users in your domain can’t reach your name server doesn’t mean they can’t use the IP address directly to contact a host. Also, it doesn’t prevent them from using other name servers to get the same info. (For example, you can set up your /etc/resolv. conf to point to 138.23.180.127 even though your local name server is 207.217.126.81.)

Router

A router allows your machine to talk to another machine via an intermediate machine. Routers are used when your machine is not on the same network as the one you would like to talk to. You can set up your machine so that it uses a third machine that has access to both your network and the network of the machine you need to talk to. For instance, your machine may have Ethernet hardware, while another machine you need to communicate with can be reached only via PPP. If you have a machine that can run TCP/IP using both Ethernet and PPP, you can set this machine up as a router, which you could use to get to the remote host reachable only via PPP. You would configure your machine to use the router when it attempts to reach this remote system. The users on your machine would not need to know about any of this; to them it seems as if your machine and the remote machine are on the same network.

You need to understand a few more things about routers than we can cover here, but we can discuss some basic concepts. Routers are set up using the same network addressing scheme as for the network card we previously described. The router is assigned a specific IP address. Usually it is the first address on your network. For example, the first router on the 135.18.99 network would be 135.18.99.1. If you have additional routers, you would usually assign them the next available number (135.18.99.2 and so on). Since a router is a device on your network, you can ping it just as you would a UNIX machine. For example, if you want to know the status of the router at address 135.18.99.1, you can type

# ping 135.18.99.1

If you have assigned a name to the router, say snoozy, you can ping the router with the command sequence

# ping snoozy

You will receive responses similar to those shown in the previous section on ping in this chapter.

Networks and Ethers

As you expand the scope of your connectivity, you may want to communicate with networks other than your own local one. You can configure your machine to talk to multiple networks using the /etc/inet/networks file. Here is an example of a line you would add to this file:

mynet   192.11.105       my

The first field is the name of the network, the second is its Internet address, and the third is the optional alias name for this new network.

The file /etc/ethers is used to associate host names with Ethernet addresses. There is also a service called RARP that allows you to use Ethernet addresses instead of Internet addresses, similar to the way DNS (Domain Name Service) maps a machine node name to an IP address. RARP converts a network address into an Internet address. For example, if you know that a machine on your network has an Ethernet address of 800010031234, RARP determines the Internet address of this machine. If you are using the RARP daemon, you need to configure the ethers file so that RARP can map an Ethernet address to an IP address.

There are other files that generally do not require attention, such as /etc/services and /etc/ protocols. If you want to know more about these files, consult the network administration guide for your variant.

PPP ADMINISTRATION

PPP(Point-to-Point Protocol) is a connection-oriented protocol that allow users to connect to UNIX systems over a remote connection using a device such as a modem or a dedicated serial link. To use these protocols, you must have TCP/IP running on both the client machine and the UNIX host to which it wants to connect.

PPP Protocol Administration

PPP (Point-to-Point Protocol) is a serial connection that can be used to support reliable connections. PPP allows you to communicate over a variety of protocols, including TCP/IP. PPP provides excellent error handling and correction facilities. It also allows for intelligent connections between your machine and the UNIX host. PPP can determine the local and remote TCP/IP addresses from a connection. The program that sets up the configuration for the PPP connection is called pppd (PPP daemon).

PPP does not perform a dialing function itself. Instead, it uses a connection-oriented program such as chat . You can specify some of the commonly used options to pppd in the chat script file and provide others on the command line. For example, the command

pppd connect   'chat −f mychat.chat' /dev/cua0 33600

will start PPP on port 1 (cua0) at 33600 baud, using the chat script myscript.chat for other settings as well as actually making the connection. You can set up routine PPP options in a file called /etc/ppp/options. When you start PPP, it will look in this file first for options and only override them if the command line supplies a different value for an option.

PPP also provides a secure method for transmitting information, CHAP (Challenge Handshake Application Protocol). If you need to use authentication to ensure security between two connected systems, you can set up a security file called /etc/ppp/chap-secrets. This file contains the client’s and server’s hostnames, a key, and the range of allowed IP addresses that they can communicate from. When PPP is started with the –auth option, CHAP is used to authenticate the connection and monitor it continuously

DNS (Domain Name Service) Administration

The concept of DNS has been around since the 1980s. It was implemented to make the life of the network and system administrators easier by establishing a uniform architecture for identifying names for machines instead of TCP/IP addresses. In addition, DNS made it possible to centralize the places you look to find out the name for a particular machine into machines called DNS servers. In the following sections, we will discuss how the DNS service evolved, and how it is structured to be administered easily

A Brief History of DNS

As Internet use grew in the early 1980s, the number of networked machines required to house all of the information grew at an even higher pace. One of the biggest problems was in handling the names of all of these machines. In the beginning of the Internet, every computer had a file called hosts.txt that contained the hostname-to-IP address mapping for all the hosts on the ARPANET. UNIX modified the name to /etc/hosts. Since there were so few computers, the file was small and could be maintained easily The maintenance of the hosts.txt file was the responsibility of SRI-NIC, located at the Stanford Research Institute in Menlo Park, California. When administrators wanted to change this file, they e-mailed the request to SRI-NIC, which would incorporate requests once or twice a week. This meant that administrators also had to periodically compare their hosts.txt file against the SRI-NIC hosts.txt file, and if the files were different, the administrator had to ftp a new copy of the file.

As the Internet started to grow, the idea of centrally administering hostnames, as well as deploying the hosts.txt file, became a major issue. Every time a new host was added, a change had to be made to the central version, and every other host on ARPANET had to get the new version of this file. In addition to this problem, several other issues with a single file were encountered.

To maintain an updated hosts.txt file required administrators to constantly download new copies of the file, causing unnecessary traffic on the network and an unbearable load on the SRI machines. A single file could not handle duplicate names, which meant that machine names would eventually run out. Every computer on ARPANET needed to have the latest version of hosts.txt, but there was no automatic way of distributing updated versions. If two computers had different versions, the entire network would get confused.

In the early 1980s, the SRI-NIC called for the design of a distributed database to replace the hosts.txt file. The new system was known as the Domain Name System (DNS for short). ARPANET switched to DNS in September 1984, and it has been the standard method for publishing and retrieving host name information on the Internet ever since. DNS is a distributed database based on a hierarchical structure. Under DNS, every computer that connects to the Internet connects from an Internet domain. Each Internet domain has a name server that maintains a database of the hosts in its domain and handles requests for hostnames.

The Structure of DNS

DNS has a root domain, ‘.’, at the top of its tree, much as UNIX has the root directory, ‘/’. All domains and hosts are located underneath the root domain. The root-level domain currently has 13 name servers maintained by the NIC that can answer queries. Their names are a.root-servers.net., b.rootservers.net., c.rootservers.net., and so on.

In this section we will first look at the structure of DNS, starting with the concept of top-level domains and then continuing into subdomains. We will also look at three different types of name servers that are used to handle domain information.

Top-Level Domains

Under the root domain, several “top level” domains are classified into two types, generic and country codes. Generic top-level domains include

• .biz (Business)

• .com (Commercial)

• .edu (Educational)

• .gov (U.S. Government)

• .info (Information)

• .int (International, e.g., NATO)

• .mil (U.S. Military)

• .museum (Reserved for museums)

• .name (Reserved for individuals)

• .net (Network organizations and Internet service providers)

• .org (Nonprofit organizations)

• .travel (Reserved for the travel industry)

Country codes are used to identify top-level domains of machines located within a particular country For example, .uk is the country code for the United Kingdom, .au is the country code for Australia, .ca is the country code for Canada, and .mx is the country code for Mexico. (Note that the country code for the United States, .us, is not used very much.) A complete list of country codes, covering every part of the world, can be found at http://www. iana.org/cctld/.

Subdomains

In addition to the top-level domains, DNS also has subdomains such as att.com, nasa.gov, and berkeley.edu. Subdomains in DNS are equivalent to subdirectories in the file system. If a particular directory contains too many files, we usually create a subdirectory and move many of the related files into this new directory This helps to keep directories and files organized. The same principle applies to DNS: When a domain has too many hosts, a subdomain can be created for some of the hosts in the domain. Subdomains can be created at any time without consulting any higher authority within the tree.

Any subdomain is free to create other subdomains. The relationship between a domain and its subdomain is similar to a parent and child relationship found in the UNIX directory tree. The parent domain must know which machine handles the subdomain database information so that it will be able to tell other name servers who holds the information for the subdomain. When a parent creates a subdomain, this is known as delegation. The parent domain delegates authority for the child subdomain to the subdomain’s name server.

Fully Qualified Domain Names

Each domain has a fully qualified domain name (FQDN), which is similar to a pathname in the file system, within the DNS. To identify the FQDN for a particular domain, we start by first getting the name of the current domain, adding the name of the parent domain, and then adding the name of the grandparent’s domain, and so on until we reach the root of the tree. This method is the reverse of the method used to construct directory names in the UNIX file system. An example of a fully qualified domain name is

csua.berkeley.edu

This particular domain name corresponds to the Computer Science Undergraduate’s Association at the University of California at Berkeley From this name we can tell that csua is a subdomain of the berkeley domain, which is itself a subdomain of the edu “top-level” domain. In this representation, the strings between the dot character, ‘.’, are called labels. The last ‘.’ is used to represent the root domain.

Resolvers

Special programs that store information about the domain name tree are called DNS resolvers or name servers. These programs usually have the complete information about some part of the domain name tree. The main types of name servers are master, slave, caching, and forwarding. You may see these servers referred to as full service resolvers, because they are capable of receiving queries from clients and other name servers. A full service resolver always maintains a cache of items that it has already looked up. It is also able to perform recursive queries to other name servers, if it does not have a cached answer for a query that it received.

Master DNS Servers

Each DNS domain has a master, or primary, server that contains the authoritative zone database file. This file contains all of the hostnames and their corresponding IP addresses for the domain, along with several other pieces of information about the zone. A master name server answers queries with authoritative answers for the zone in which it is located. To service client requests, a master name server normally queries other name servers to obtain the required information. It also maintains a memory cache to remember information returned by other name servers. The master name server’s database is also used to delegate responsibility for subdomains to other name servers.

To change the information for a domain, the zone database file on the master name server must be changed. The zone database contains a serial number that must be incremented each time the database is altered, as this ensures that secondary name servers will recognize the changes.

Slave DNS Servers

Each domain should have at least one slave, or secondary, server for redundancy purposes. The slave server will obtain a copy of the zone database, usually from the master name server. The slave will serve authoritative information for the zone just as the master server does. Slave name servers will normally query other name servers to obtain information from other name servers to answer client requests. Like master name servers, slave name servers have a memory cache that remembers information returned by other name servers.

Caching DNS Servers

Caching, or hint, name servers do not serve authoritative information for any zones. Clients query such a name server, and it forwards the query to other name servers until an answer for the query is found. Once an answer is found, the caching name server remembers the answer for a period of time. If the same client makes the same query again (or if other clients do), this name server gives the answer stored in cache, instead of forwarding the query to another name server. Caching name servers are generally used to reduce DNS traffic over slow or expensive network connections.

Forwarding DNS Servers

Forwarding, or proxy, client, or remote, servers have only one purpose, to forward all DNS requests to other DNS servers, caching the results. Although forwarding DNS servers may seem rather pointless, they can help reduce traffic and external access needs. In particular, they are used when access to an external network is slow or costly

DNS Resource Records

DNS resource records are entries stored in the DNS database. The DNS database is a set of ASCII text files that contain information about the machines in a domain. This information is stored in a specific format that we will examine in this section. Information is added to a domain by adding resource records to the database located on a primary name server. When a query is made to a name server, the server will return one or more resource records containing either the exact answer to the query or information pointing to another name server in the name space to look for the answer. The resource records on a primary name server are stored in a zone database. The zone database is usually made up of at least three files:

• db.network (for example, db.10.8.11)

• db.domain (for example, db.bosland)

• db.127.0.0

The first file contains the mapping of IP addresses to hostnames for a given network. The second file contains the reverse mapping of hostnames to IP addresses. The third file contains a mapping for the local host.

DNS bind allows you to name these files differently from the examples. The name of the zone databases for bind4 mapping is in /etc/named.boot, and that for bind9 mapping is in /etc/named.conf.

The Structure of DNS Database Files

Each database file has three main sections, the Start of Authority section (SOA), the name server section (NS), and the database section. Each of these sections has one or more DNS resource records. The syntax of a DNS resource record can be in one of the following forms:

[TTL] [class] type data
[class] [TTL] type data

The first two fields, TTL and class, are optional fields that correspond to the “Time-To-Live” and the class of the record. The “Time-To-Live” is a decimal number that indicates to the name server how often this particular record needs to be updated. Usual values range from a few minutes to a few days. If this field is blank, it is, by default, assumed to be three hours.

The class field indicates which class of data the record belongs to. The only class that is used is the IN class, corresponding to Internet data. The type field is a required field and describes the type of data in the record:

• SOA Record The Start of Authority resource record is located at the top of each file in the zone database. The SOA includes many pieces of information that are primarily used by the secondary name server.

• NS Record The name server section is the second section in each of the files in the zone database. It contains a name server resource record, NS, for each of the primary and secondary name servers for the zone that the database serves.

• A Record An A record is an address record used for providing translations for hostnames to IP addresses.

• PTR Record The pointer, or PTR, records are typically seen in the db.network or the db.127.0.0 files. They are used for reverse address resolution, which is used by the name server to turn an IP address into a hostname.

• CNAME Record The Canonical Name (CNAME for short) record makes it possible to alias hostnames. This is useful for giving common names to large servers. For example, it is useful to have the server that handles both web traffic and FTP traffic for a domain respond to the names www and ftp.

• MX Record The list of host names that will accept mail for this domain, and their priority The priority indicates the urgency of mail delivery for a given host. A smaller number indicates quicker response.

The Database portion of the zone file contains all of the resource records that contain the data for the hosts in the zone. Three main types of records are encountered in this section. In the db.network file we will encounter PTR records. In the db.domain file we will encounter A and CNAME records.

Using NSLOOKUP to Find a Machine on the Network

You may want to connect to another machine on the TCP/IP network to send or receive information but not be sure what the machine’s address is, or even that the machine name (hostname) that you want to reach exists. The nslookup utility enables you to find out this information. You provide the hostname of the desired machine as part of the command line. For example,

# nslookup dodger.com
Name Server: damian.master.com
Address:   198.5.22.7
Name: dodger.com
Address: 199.14.36.112

provides the name server (damian.master.com) that dodger.com exists on as well as the IP address for both the name server and dodger.com. If the hostname for the machine does not exist, you will get a message back indicating so. For example, if you were to type in the name dogder.com by mistake, you would get a message like this:

# nslookup dogder.com
Name Server: damian.master.com
Address:   198.5.22.7
*** damian.master.com can't find dogder.com: Non-existent domain

One important point to note is that nslookup uses an authoritative approach to do its translations. It uses either your local name server or whatever is specified in /etc/resolυ.conf to do queries. As long as the machine is in your domain, you can guarantee that the machine exists without going outside the domain (called an authoritative answer). If you need to go outside your domain to get the information from another domain server, the answer is nonauthoritative (you are taking the other domain server’s word that the domain name exists). In the successful example shown previously, damian.master.com needs to be authoritative to dodger.com; otherwise, you will be informed that it is a nonauthoritative lookup.

Using host and dig

Besides nslookup, two other commands, host and dig, are often used to obtain DNS information about a particular hostname or IP address. These two commands are supported by Solaris, AIX, HP-UX, Linux, FreeBSD, NetBSD, and OpenBSD, as well as other UNIX variants. Some UNIX variants support one, but not both, of them.

The host Command

The host command can be used to find the IP address corresponding to a particular hostname, or vice versa. For example,

# host dodger.com

dodger.com is 198.5.22.7

gives us the IP address corresponding to the host dodger.com. We can find the hostname corresponding to the IP address 198.5.22.7 as follows:

# host 198.5.22.7

dodger is 198.5.22.7

The dig Command

The dig (short for domain information groper) is a powerful command that can be used to extract information from DNS servers. You can use this command for DNS lookups on particular DNS servers. Network administrators used the dig command to troubleshoot DNS problem because of its flexibility and ease of use, as well as the clear way output is presented. The following is an example of a dig query that will query each of the DNS servers listed in /etc/resolυ.conf:

# dig dodger.com

To query a particular DNS server, you use a command like

# dig @ns.dodger.com dodger.com any

This command directly queries the DNS server ns.dodger.com for any information about the hostname dodger.com. See the man page for the dig command to learn about the output provided by this command, as well as options that can be used to troubleshoot DNS problems.

sendmail Mail Administration

The sendmail daemon is a service that runs in the background on your UNIX machine to provide electronic mail services to users on a TCP/IP network. sendmail is what is known as a mail transfer agent (MTA). Although other MTAs are supported by UNIX (e.g., qmail), sendmail is by far the most commonly used one. The sendmail environment is the most complex service available on UNIX. In addition to simply sending messages from one user to another, sendmail determines how to best route the messages across networks to reach a particular destination. Finally, it provides forwarding services so that mail items can be redirected to destinations other than those they were originally sent to. Since sendmail is so complex, we will only address the basics that will allow you to get started as a network administrator for this service. If you want to learn more details, see the “How to Find Out More” section at the end of this chapter.

It is important to understand the distinction between a mail delivery function and a mail reading function. The sendmail daemon only provides the capability to encapsulate (package) a mail message so that it can be sent over a UNIX network. To read a message, a user must have an MUA (mail user agent), or mail reader, installed on the machine receiving the mail. Examples of MUAs are pine, Elm, and mailx. User interaction with sendmail is discussed in Chapter 8.

The sendmail program may already be on your machine. If it is not, you can get it for free. The best source is the official sendmail site at http://www.sendmail.org/. You can read more about sendmail in the Usenet newsgroup comp.mail.sendmail.

Once you have sendmail on your machine, you must configure it for your particular environment to use it effectively. This is done through entries in the sendmail.cf file (sendmail configuration file). This configuration file sets up the options to be used in sending mail and defines the locations of files it uses to do so. It also defines the message transfer agents (or mailers) that sendmail uses to route messages over the network. Lastly, it defines rules for senders and recipients of mail and mailers that are used on your system.

Monitoring sendmail Performance

To provide timely mail service to users on your system, not only must you configure sendmail properly, but you must also tune it and periodically and monitor its performance. The program includes a number of options that help you do this. Here are some of the more important ones that can be used when you start up the sendmail daemon:

Option	Function
–ohhop_count	Specifies the maximum number of hops for a message. sendmail will assume a problem exists and discard messages when this count is exceeded.
–oCckpt_value	Specifies how often sendmail should check the queue to see how many messages are awaiting mailing.
–qtime	Specifies how often outgoing mail is to be batch processed.
–oxload_average	Specifies a limit for the average system load, at which sendmail stops sending outgoing mail.
–oXload_average	Specifies a limit for the average system load on incoming mail, at which sendmail stops receiving mail.

Networked Mail Directories

A configuration you may find useful in a closely coupled environment is to use NFS to share the directory /var/mail between multiple machines. In this way, mail gets stored on only one file system. In the event that your particular machine is down, you can most likely use another machine on your network that has access to the mail directory /var/mail on the server.

First, decide which machine will be the primary machine that will normally have the mail file system mounted, such as company1. Second, move all mail currently found on the secondary machines to the primary machine. Next, remove the directory /var/mail/:saved from all of the secondary machines. (This directory is normally used as a staging area when mail is rewriting mail files.) Then, tell mail where it should forward the mail message if it finds that the /var/mail directory is not mounted properly Do this by adding the following variable to the mail configuration file:

FAILSAFE=company1

Finally, mount the mail directory from the primary machine using NFS. Take caution to NFS-mount the mail spool directory as a hard mount (do not use the soft option). A soft mount may cause corruption of mail. For example, if the spooler is mounted with the soft option, and you are attempting to write to your local mailbox, and sendmail is attempting to deliver mail at the same time, your mail files may become corrupted.

Setting Up SMTP

SMTP (Simple Mail Transfer Protocol) is a protocol specified for hosts connected to the Internet that is used to transmit electronic mail. SMTP is used to transfer mail messages from your machine to another machine across a link created using the TCP/IP network protocol. The sendmail daemon sets up an SMTP service for both the mail client (the user who sends mail) and the mail server (the sendmail process that sends messages over the network). SMTP is the most popular mail protocol daemon for sending mail. To read your mail, you need an additional daemon. One example is the POP3 (Post Office Protocol level 3) protocol daemon. This daemon allows you to receive mail from the network in a format that can be read by a mail reader on your system. One specialized POP3 daemon is called qpopper, used to support mailers such as Eudora. You can obtain this daemon from Eudora at http://www.eudora.com/. Eudora is now a product of Qualcomm, Inc. If you use elm as your mail reader, you do not need to set up a mail reading daemon such as POP3, since elm reads directly from the mail spool directory

Mail Domains

The most commonly used method of addressing remote users on other computers is by specifying the list of machines that the mail message must pass through to reach the user. This is often referred to as a route-based mail system, because you have to specify the route used to get to the user, as well as the user’s address.

Another method of addressing people is to use what is known as domain addressing. This is the primary way in which web browser-based e-mail is sent; for example, sending mail to dhost@domain.com In a domain-based mail system, your machine becomes a member of a domain. Every country has a high-level domain named after the country; high-level domains are also set aside for educational and commercial entities. An example of a domain address is usermachine.company.com, or equivalently, machine.company. com!user. Anyone properly registered can send mail to your machine if they know how to get directly to your machine or know the address of another, smarter host (commonly referred to as the gateway machine) that does have further information on how to get to your machine; this may require the use of other machines on the way This cannot be done unless your machine is registered with the smarter host and you have administered the gateway machine on your system as the smarter host. If you have SMTP configured, your system may be able to directly access other systems in other domains.

Once you have registered your machine within a domain, you must set the domain on your system. This can be done in several ways:

• If your domain name is the same as the Secure RPC domain name, then both can be set by using the /usr/bin/domainname program, using a line of the form

  domainname .company.com

• If you have a name server, either on your system or accessible via TCP/IP, the domain name can be set in the name server files, /etc/inet/named.boot or /etc/resolυ.conf, using a line of the form

  domain company.com

• The domain name can also be overridden within the mail configuration file using a line of the form

  DOMAIN=.company.com

NIS+ (Network Information Service Plus) Administration

NIS+ is a networking service that centrally manages information about network users and the machines they use and access, applications that are run, file systems that are used, and services that are needed to do all of these things. This type of setup is very useful if you have a network with users who share a large portion of their files and applications. It also makes the job of the network administrator easier, since NIS+ is the official repository of networking information. NIS+ provides a robust network security and authorization environment for file sharing services such as NFS, discussed a little later in this chapter.

NIS, the predecessor of NIS+, has been around for a while. Commonly called the Yellow Pages, or YP for short, NIS was introduced by Sun Microsystems in the 1980s as a method for managing NFS environments by controlling and sharing such things as password and group information among hosts in a network. NIS+, which is part of Sun Microsystem’s suite of services called the Open Network Computing Plus (ONC+) platform, has been built onto the NIS platform.

NIS+ provides a screening mechanism that authenticates users when a request is made for a resource that is shared on the network. For instance, if you want to use a file on another machine in the network, NIS+ determines whether or not you are allowed to use the resource before allowing NFS (see the following section) to mount it. If you want to perform a command on another networked machine using RPC (Remote Procedure Calls), NIS+ validates that you have access to the command as well as the information on the networked machine. If you are validated, you can perform commands such as rsh on the remote machine. (See later on in this chapter for a discussion of RPC.)

NIS does not do authentication; it merely returns database entries. In the case of a password database, it is up to the application to determine whether the requesting user has the privileges to access it.

NIS+ is implemented on the UNIX system by a daemon called rpc.nisd. This daemon starts the NIS+ service in one of two ways. The first is to run NIS+ with all of its service features. If you start the daemon with the –YB option, NIS+ is started in NIS compatibility mode. This allows machines that are on the network to use resources as though they are being managed by the older NIS services.

NFS (Network File System) Administration

NFS allows you to share files across networks. This capability eliminates the need to duplicate commonly used files on each machine in your network. NFS is used by all of the major UNIX variants. It can be used to share files between two, or among multiple, operating system types. For instance, NFS allows you to share files between a Solaris system and a Linux system.

Before you can use NFS, you need to make sure that a network provider is configured, that the Remote Procedure Call (RPC) package has been installed, and that the RPC database has been configured for your machine. Configuring a network provider has already been discussed. What follows is a discussion of the RPC package and its databases.

Checking RPC

NFS relies on RPC, which allows machines to access services on a remote machine via a network RPC handles remote requests and then hands them over to the operating system on the local machine. The local system has daemons running that attempt to process the remote request. These daemons issue the system calls needed to do the operations.

Because NFS relies on RPC, you need to check that RPC is running before starting NFS. You can check to see if it is running by typing this:

# ps −ef | grep rpc

If you see “rpc.bind” in the output of this command, then RPC is running. Otherwise, use the script /etc/init.d/rpc to start RPC. This startup script, also known as the portmapper in some variants, is in portmap/rpc.portmap/rpc.portmapper.

You should also check to make sure that the data files for RPC are set up in files with names of the form /etc/net/*/hosts and /etc/net/*/services. You replace the * with the name of your transport. You may see many transports in /etc/net, because you will have one per transport protocol, such as the transport protocols associated with TCP/IP, ticlts, ticots, and ticotsord.

Setting Up NFS

To set up NFS on clients and servers, the daemons used by NFS need to be started. For example, on Solaris machines, the daemons used by NFS clients and NFS servers are started by running the boot scripts /etc/init.d/nfs.client and /etc/init.d/nfs.server, respectively. Because this happens automatically at run level 3, you generally will not have to manually run these scripts. However, you start the NFS server daemons using the command

# /etc/init.d/nfs.server start

You can start the NFS client daemons using the command

# /etc/init.d/nfs.client start

On Linux, you can start both the NFS client and server daemons using the command

# /etc/init.d/nfs start

Note that NFS requires little in the way of configuration, as there is no notion of domains or name servers. With NFS, more of the configuration takes place as you actually make use of its facilities such as sharing and mounting resources.

Sharing NFS relies on the administrator who is sharing the resource to keep security in mind. So when you share a resource, you also must determine how secure you want that resource to be.

NFS resources do not have a name used to identify them, other than the actual path to the resource that is being shared. Machines on the network refer to the resource as machinename:resource when they attempt an operation on an NFS resource.

Mounting Mounting resources with NFS requires that resources are identified with the notation machine-name:resource. NFS resources can also be mounted via the automounter, discussed in the following section, which mounts the resource only when a user actually attempts to access it.

The Automounter

NFS includes a feature called the automounter that allows resources to be mounted on an as-needed basis, without requiring the administrator to configure anything specifically for these resources.

When a user requires a resource, it is automatically mounted for the user by the automounter. After the task using this resource has been completed, it will eventually be unmounted.

All resources are mounted under /tmp_mnt, and symbolic links are set up to place the resource on the requested mount point. The automounter uses three type of maps: master maps, direct maps, and indirect maps. A brief description of these three maps follows for the Solaris system. For more information on the particular automounter available for your system, see the documentation for your system. Note that there are two widely used automounters for Linux systems, autofs and amd (the Berkeley Automounter). For more information on autofs, go to http://www.faqs.org/docs/Linux-mini/Automount.html, and for more information on amd, go to http://www.am-utils.org/. For more information on NFS administration and automounters on AIX and HP-UX systems, go to http://www.freelab.net/uni x/hp- u x/chap1 2_nfs. html.

The Master Map The master map is used by the automounter to find a remote resource and determine what needs to be done to make it available. The master map invokes direct or indirect maps that contain detailed information. Direct maps include all information needed by automount to mount a resource. Indirect maps, on the other hand, can be used to specify alternate servers for resources. They can also be used to specify resources to be mounted as a hierarchy under a mount point.

A line in the master map has the form

mountpoint map [mount-options]

An example of a line in the master map is

/usr/add-on   /etc/libmap   −rw

This line tells the automounter to look at the map /etc/libmap and to mount what is listed in this map on the mount point /usr/add-on on the local system. It also tells the automounter to mount these resources with read/write permission.

Direct Map A direct map can be invoked through the master map or when you invoke the automount command.

An entry in a direct map has the form

key [mount-options] location 

where “key” is the full pathname to the mount point, “mount-options” are the options to be used when mounting (such as –ro for read-only), and “location” is the location of the resource specified in the form server.path-name. The following line is an example of an entry in a direct map:

/usr/memos   −ro   jersey:/usr/reports

This entry is used to tell the automounter to mount the remote resources in /usr/reports on the server jersey with read-only permission on the local mount point /usr/memos. When a user on the local system attempts to access a file in /usr/reports, the automounter reads the direct map, mounts the resource from jersey onto /tmp_mnt/usr/memos, and creates a symbolic link between /tmp_mnt/usr/memos and /usr/memos.

A direct map may have many lines specifying many resources, like this:

/usr/src \
                   /cmd-rw,softcmdsrc:/usr/src/cmd \
                   /uts-ro, softutssrc:/usr/src/uts \
                   /lib-ro,securelibsrc:/usr/lib/src

In the preceding example, the first line specifies the top level of the next three mount points. Here, /usr/src/cmd, /usr/src/uts, and /usr/src/lib all reside under /usr/src. A backslash (\) denotes that the following line is a continuation of this line. The last line does not end with a \, which means that this is the end of the line. Each entry specifies the server that provides the resource; that is, the server cmdsrc is providing the resource to be mounted on /usr/src/cmd. You can see that it is possible to have different servers for all of the mount points, with different options.

You can also specify multiple locations for a single mount point, so that more than one server provides a resource. You do this by including multiple locations in the location field. For example, the following line,

/usr/src   −rw,soft cmdsrc:/usr/src utssrc:/usr/src libsrc:/usr/src

can be used in a direct map. To mount /usr/src, the automounter first queries the servers on the local network. The automounter mounts the resource from the first server that responds, if possible.

Indirect Maps Unlike a direct map, an indirect map can only be accessed through the master map. Entries in an indirect map look like entries in a direct map, in that they have the form

key [mount-options] location 

Here, the key is the name of the directory (and not its full pathname) used for the mount point, mount-options is a list of options to mount (separated by commas), and location is the server.path-name to the resource.

NFS Security

As mentioned earlier, you can use the share command to provide some security for resources shared using NFS. (For more serious security needs, you can use the Secure NFS facility if it is available for your UNIX variant, which is described later in this chapter.)

When you share a resource, you can set the permissions you want to grant for access to this resource. You specify these permissions using the –o option to share. For instance, –o rw will allow read/write access.

You may also choose to map user IDs across the network. For example, say you want to give root on a remote machine root permissions on your local machine. (By default, remote root has no permissions on the local machine.) To map IDs, use a command such as this:

# share −o root=remotemachine

When deciding the accesses to assign to a resource, first decide who needs to be able to use this resource.

Secure NFS

Secure NFS provides a method to authenticate users across the network and allows only those users who have been authorized to make use of the resources. Secure NFS is built around the Secure RPC facility (Note that Secure NFS is not available for all UNIX variants. For some variants, a different secure version of NFS is available.) Secure RPC will be discussed first.

Secure RPC

Secure RPC is used for authentication of users via credentials and verifiers. An example of a credential is a driver’s license that has information confirming that you are licensed to drive. An example of a verifier is the picture on the license that shows what you look like. You display your credential to show you are licensed to drive, and the police officer verifies this when you show your license. In Secure RPC, a client sends both credentials and a verifier to the server, and the server sends back a verifier to the client. The client does not need to receive credentials from the server because it already knows who the server is.

Secure RPC uses the Data Encryption Standard (DES) and public-key cryptography to authenticate both users and machines. Each user has a public key, stored in encrypted form in a public database, and a private key, stored in encrypted form in a private directory The user runs the keylogin program, which prompts the user for an RPC password and uses this password to decrypt the secret key keylogin passes the decrypted secret key to the keyserver, an RPC service that stores the decrypted secret key until the user begins a transaction with a secure server. The keyserver is used to create a credential and a verifier used to set up a secure session between a client and a server. The server authenticates the client, and the client, the server, using this procedure.

You can find details about how Secure RPC works in your network administrator’s guide for your variant.

Administering Secure NFS

To administer Secure NFS, you must make sure that public keys and secret keys have been established for users. This can be done either by the administrator via the newkey command or by the user via the chkey command.

Public keys are kept in the file /etc/publickey, whereas secret keys for users, other than root, are kept in the file /etc/keystore. The secret key for root is kept in the file /etc/.rootkey/.

After this, each user must run /usr/sbin/keylogin. (As the administrator, you may want to put this command in users’ /etc/profile, to ensure that all users run it.) You then need to make sure that /usr/sbin/keyserve (the keyserve daemon) is running.

Once Secure NFS is running, you can use the share command with the –o secure option to require authentication of a client requesting a resource. For example, the command

# share −F nfs −o secure /user/games

shares the directory /usr/games so that clients must be authenticated via Secure NFS to mount it.

As with many security features, be aware that Secure NFS does not offer foolproof user security. Methods are available for breaking this security, so that unauthorized users are authenticated. However, this requires sophisticated techniques that can only be carried out by experts. Consequently, you should only use Secure NFS to provide a limited degree of user authentication capabilities.

Troubleshooting NFS Problems

As mentioned in the preceding section, NFS relies on the RPC mechanism. NFS will fail if any of the RPC daemons have stopped or were not started. You can start RPC by typing this:

# /etc/init.d/rpc start

If you wish to restart RPC, first stop RPC by executing this script, replacing the start option with stop. Then run this command again to start RPC. If you see any error messages when you start RPC, there is most probably a configuration problem in one or more of the files in /etc/net.

If NFS had been running but now no longer works, run ps –ef to check that /usr/lib/nfs/ mountd and /usr/lib/nfs/nfsd are running. If mountd is not running, you will not be able to mount remote resources; if nfsd is not running, remotes will not be able to mount your resources. You should also see at least four /usr/lib/nfs/nfsd processes running in the output. One other daemon should be running on the client machine, /usr/lib/nfs/biod, which is a client-side daemon that enables clients to use NFS.

Other problems may be related to the network itself, so be sure that the transport mechanism NFS is using is running. Consult your network administrator’s guide for information about other possible failures.