Client-Server Communications

Many of the problems that Backup users report when they set up and configure Backup are problems with the communications in their networks. This section contains a procedure for testing the communications in a network.

How to Troubleshoot IP Errors

To troubleshoot IP errors, follow these steps:

1. Document the steps you take and the results, especially error messages, in case you need to contact SunSoft Technical Support.

   This enables you to email or fax exact steps and error message text directly to SunSoft.

2. Set up host tables for Backup clients and Backup servers.

   See "How to Set Up Host Tables ".

3. Disable other name servers to simplify testing.

   See "How to Disable Name Servers for Troubleshooting ".

4. Use the ping command to establish basic connectivity.

   See "How to Use ping to Verify Network Connections ".

5. Use the rpcinfo command to verify that sessions can be established and that portmapping is correct.

   See "How to Use rpcinfo to Verify That Sessions Can Be Established".

How to Set Up Host Tables

We recommend that you troubleshoot IP problems using only host tables. Troubleshooting using only host tables does not mean you cannot use your name service, for example, DNS, with Backup. Test using only host tables to determine whether you have Backup installed correctly. After you know Backup works with host tables, you can enable whatever name server you are using.

To configure host tables on a server or client, follow these steps:

1. On the Backup client, list the client and the Backup servers to which it connects.

   For example:

   127.0.0.1 localhost loopback 123.456.789.111 client client.domain.com 123.456.789.222 server server.domain.com

2. On the Backup server, list the Backup server itself and all of its clients.

   For example:

   127.0.0.1 localhost loopback 123.456.789.111 server server.domain.com 123.456.789.222 client client.domain.com

3. Use the guidelines in "How to Use ping to Verify Network Connections " to ensure the highest success rate for host table parsing within any operating system.

   Notes for host table configuration include:

   • Do not use blank lines in the body of your host tables.

   • The end of the host table should always contain a blank line.

   • The first unremarked entry should always be the loopback line in the exact order and format shown in Steps 1 and 2.

   • The last character of each unremarked line should be a space, not a carriage return.

   On UNIX platforms, the host tables reside in /etc/hosts.

   You can use host tables in addition to DNS where necessary, but it is simplest to temporarily disable DNS for troubleshooting.

How to Disable Name Servers for Troubleshooting

To simplify the troubleshooting of name resolution problems, we recommend disabling services like DNS, WINS, and DHCP. If you have name resolution problems, first configure only the host tables for your machines, then test your backups.

Some common problems you may encounter with DNS, WINS, and DHCP services

• The DNS is not configured with a reverse lookup table.

• The clients are configured with the wrong IP addresses for DNS or WINS servers.

• The DHCP services do not properly update the WINS server with new addresses.

You do not need to disable DNS for your entire network, just for the initial setup of the Backup clients and the Backup server you want to test. Only disable the ability of a client to obtain IP naming information from a DNS server. Typically, you do not need to disable the DNS server itself.

To disable the DNS server on most UNIX platforms, rename the file /etc/resolv.conf and reboot.

For a Solaris system, instead of renaming resolv.conf, you can set up the IP name search order so that the host table is searched before DNS.

To set up the IP name search order, follow these steps:

1. Edit the /etc/nsswitch.conf file and verify that the /etc/resolv.conf file exists.

2. Set the host file to be first in search order, with DNS second and NIS last.

   For example:

   hosts: files [NOTFOUND=continue] DNS [NOTFOUND=continue] nis

How to Use ping to Verify Network Connections

After you create the host tables, test them with ping.

On the Backup client:

• ping the client short name (hostname) from the client

• ping the client long name (hostname plus domain information) from the client

• ping the client IP address from the client

• ping the server short name from the client

• ping the server long name from the client

• ping the server IP address from the client

  The following example shows pinging the client short name and client long name from a Backup client called mars in the oak domain:

# ping mars
# ping mars.oak.com

On the Backup server (use just the steps marked with an asterisk (*) if the server is the only client):

• ping the server short name from the server *

• ping the server long name from the server *

• ping the server IP address from the server *

• ping the client short name from the server

• ping the client long name from the server

• ping the client IP address from the server

How to Use rpcinfo to Verify That Sessions Can Be Established

If ping is successful and backup problems still exist, you can also test with rpcinfo. Because Backup relies heavily on mapping of ports, use rpcinfo to test the operation of the portmapper. Using ping tests the connection up to the network layer in the OSI model; rpcinfo checks for communication up to the session layer.

Use the same tests with rpcinfo as with ping. Run just the steps marked with an asterisk (*) if the server is the only client.

For rpcinfo to be used successfully, the machine whose hostname you enter on the command line must have a portmapper running. In most cases, SunSoft portmappers are compatible with fully functional portmappers from other vendors (this is called a third-party portmapper). If you are using a product that provides its own portmapper, we recommend not loading the third-party portmapper until you have verified that Backup works with the rest of your environment. This process lets you test portmapper compatibility without adding other unknowns.

On Solaris, the rpcbind daemon must be running. The rpcinfo utility is part of the operating system.

The syntax for using rpcinfo to display ports using TCP is:

rpcinfo -p hostname

Substitute the long name and short name for the variable hostname, just like for ping.

You can view other rpcinfo command line options by typing rpcinfo at the command line. Notes on the rpcinfo command and its error messages are available in the UNIX man page for rpcinfo. Repeat rpcinfo using all the locations and all the iterations listed in this document for ping.

When rpcinfo runs successfully, the output is a list of port numbers and names. For troubleshooting, we are only interested in the exact text of any error messages. Typical successful responses have the following format:

rpcinfo for mars
program vers proto   port
100000    2   tcp    111  portmapper
100000    2   udp    111  portmapper
390103    2   tcp    760
390109    2   tcp    760
390110    1   tcp    760
390103    2   udp    764
390109    2   udp    764
390110    1   udp    764
390113    1   tcp   7937
390105    5   tcp    821
390107    4   tcp    819
390107    5   tcp    819
390104  105   tcp    822

Verifying Firmware for Switches and Routers

If you are using switches or routers from any vendor, make sure that the switch or router firmware is dated after August 1995 (wherever they exist on your network) to ensure that RPC (Remote Procedure Call) traffic is handled properly. Most of the switch and router vendors with whom we have worked have significantly improved their handling of RPC traffic since August 1995.

Naming Requirements

Backup UNIX clients, release 4.2 and later, use the servers file in the /nsr/res subdirectory to determine whether a Backup server is authorized to back up the client's data. If you don't have the servers file, you can create it in /nsr/res using your preferred editor.

Make sure the servers file on a client contains both the short name and long name of the server you want to use to back up that client's data. For example, the servers file on a Backup client would contain the following names for a Backup server named mars in the oak.com domain:

mars
mars.oak.com

In the Clients resource, list both the short name and the long name, plus any other applicable aliases for each client, in the Alias attribute.

Binding to Server Errors

Backup follows the client/server model, where servers provide services to the client through the RPC. These services reside inside of long-lived processes, known as daemons.

For clients to find these daemons, you must register the daemons with a registration service. When the daemons start up, they register themselves with the registration service provided by the portmapper.

Backup servers provide a backup and recovery service. They receive data from clients, store the data on backup media, and retrieve it on demand. If the Backup daemons are not running and a Backup service is requested, you receive the following messages in your savegroup completion mail:

Server not available
RPC error, remote program is not registered 

These messages indicate that the Backup daemons nsrd, nsrexecd, nsrindexd, nsrmmd, and nsrmmdbd may not be running. To restart the daemons, become root and enter the following command at the shell prompt:

# /etc/init.d/networker start

Saving Remote Filesystems

You may receive the following error messages in your savegroup completion mail when a backup for a remote client fails:

All: host hostname cannot request command execution
All: sh: permission denied

The first message means that the nsrexecd daemon on the client is not configured to allow the server to back up its files. The second message means that the nsrexecd daemon is not currently running on the client.

To resolve these problems, make sure that the nsrexecd daemon is running on the client, and that the server's hostname is listed in the boot-time file. The boot-time file is automatically generated before the installation script is completed, and takes your responses to the query for the names of all the servers, in order of precedence, that can contact a client for backups. Table C-1 lists the location for the boot-time file.

Refer to the nsrexecd(1m) man page for detailed information about the nsrexecd daemon.

Remote Recover Access Rights

You can control client recover access by configuring the Client resource. The Remote Access list displays the usernames that have recover access to the client's save sets. You can add or remove usernames depending on the level of security the files require.

The following users have permission to recover any files on any client, regardless of the contents of the Remote Access list:

• Root

• Operator

• Member of the operator group

Other users can only recover files for which they have read permission, relative to the file mode and ownership at the time that the file was backed up. Files recovered by a user other than root, operator, or the operator group are owned by that user.