Platform Notes: SPARCstation Voyager Software Guide

Chapter 5 Configuring for Disconnected Operation

This chapter describes the installation and configuration procedures that allow your SPARCstation Voyager to operate in nomadic mode. The procedures assume a reasonably high level of Solaris system administration familiarity. If you do not feel comfortable with the commands and procedures, consider seeking the help or advice of a Solaris system administrator.

Installation

When you install the Solaris software, be sure to specify that your system is a standalone networked system. This installation configuration allows you maximum flexibility, providing the capability to operate your system connected to a network or disconnected as a standalone single system.

During the install process, select "Yes" when asked "Will this system be connected to a network?" Later in the install process, if the Custom Install Configuration screen is displayed, be sure that the system type is "standalone." If the Custom Install Configuration screen does not appear, your system will be configured as standalone.

Name Service Configuration

A name service fulfills requests for global objects such as name to IP address mappings, mail aliases, and password entries. NIS, NIS+, and DNS are the most common name services for standalone networked systems. For a non-networked standalone single system, a set of files in the /etc directory constitute the files name service. Solaris 7 provides a configuration file, /etc/nsswitch.conf, that directs name service accesses to the desired target name service.

Default

The install process determines the appropriate name service configuration and generates a corresponding /etc/nsswitch.conf file. For a standalone networked system, /etc/nsswitch.conf is a copy of /etc/nsswitch.nis for an NIS environment or /etc/nsswitch.nisplus for an NIS+ environment.

This default configuration will work satisfactorily as long as your SPARCstation Voyager is connected to a network. However, when it is disconnected, access to a name service will cause requesting processes to wait for a predetermined timeout period (30 seconds for NIS and 10 seconds for NIS+) while the name service client component tries to connect to the remote and inaccessible server. Since some processes generate several accesses to a name service, the aggregate wait time can be significant.

For example, if you use ls to display a long list of the contents of a local directory that contains four files owned by someone else (whose user name is not in your local /etc/passwd file), you will wait two minutes (4 files * 1 non-local name per file * 30 seconds per NIS lookup of a non-local name) for the command to finish.

Configuring /etc/nsswitch

By editing the /etc/nsswitch.conf file, you can avoid or minimize the occurrence of timeout delays.

If your facility does not make extensive use of the networked name services, configure your system to use the files name service by copying /etc/nsswitch.files to /etc/nsswitch.conf.

If your facility makes use of the networked name service, create a hybrid configuration file, such as the following one:


#
# /etc/nsswitch.conf
#
# An example file that could be copied to /etc/nsswitch.conf
# This file configures the system to use the NIS name service
# sparingly, and thus allows the system to operate even when
# NIS isn't available.

passwd:     				files
group:      				files
hosts:      				files		nis
networks:   				files
protocols: 				files
rpc:        				files
ethers:     				files
netmasks:   				files	
bootparams: 				files
publickey: 				files
netgroup:   				files
automount: 				files		nis
aliases:    				files
services:   				files
sendmailvars:				files

This configuration instructs the system to use the NIS name service only when a host name is not found in /etc/inet/hosts or when the automounter cannot find an automount map file in the /etc directory. All other name service lookups are satisfied by the files name service, as defined by the corresponding files in the /etc directory.

You may find that you can configure /etc/nsswitch.conf in a better way for your specific site's network configuration. Feel free to experiment with the contents of /etc/nsswitch.conf or add entries to the specific service files on your system until it meets your needs.


Note -

If you are running NIS, you can prevent timeouts from occurring by stopping and starting NIS binding services (i.e. ypbind) when you disconnect and reconnect the SPARCstation Voyager from and to the network. However, the user is the one who must stop and start the binding services at each disconnection and reconnection. The process may not be worth the trouble.


Network Configuration

Installing your system as a standalone networked system assures that most network configuration has been done by the install process. You can improve the ability of the SPARCstation Voyager to operate in nomadic mode by adding frequently accessed remote host names to the local hosts database and by preventing your machine from acting as a router.

Hostname to IP Address Mapping

Because the system won't always have access to the NIS/NIS+/DNS databases, hostname to IP address mapping, requested by programs such as sendmail and PPP (aspppd), may fail when the system is disconnected, if the local /etc/inet/hosts file does not contain a requested entry. Adding frequently accessed remote host names to the /etc/inet/hosts file will minimize such failures.


Example 5-1 Internet Host Table

#
# Internet host table
#
127.0.0.1	localhost loghost
224.0.0.0	multicast-ip
#
# This machine
#
192.9.10.5	voyager
#
# Frequently accessed hosts
#
192.9.11.113	sparctreker
192.9.11.126	parhelion
192.9.20.30	datehost
192.9.60.81	applserver
192.9.7.81	cosmos mailhost


Note -

You may prefer to use admintool to edit the /etc/init/hosts file.


Generally you won't have to put more than a dozen or so map entries in the /etc/inet/hosts file. After initially populating the file with entries that you think you'll need, you can then add entries as you discover them (usually because a command fails, producing a message such as "unknown host zargon").

IP Forwarding and Network Routing

If you plan to use PPP to create a wide area network connection over telephone lines, it may be necessary to disable IP forwarding. IP forwarding is enabled at boot time when the system detects more than one interface (i.e. Ethernet and PPP). In this case, the system will also be configured as a router. This is undesirable because other routers on the network will attempt to route network traffic through your system. In addition to the performance impact on your system and the network, it is possible to cause network routing failures that are difficult to detect and correct.

To avoid this, establish an /etc/defaultrouter file that contains the name of one of the routers serving your network or subnetwork. You can determine a candidate router by inspecting the route table with the netstat command while your system is connected to the network.


# netstat -r
Routing Table:
 Destination          Gateway           Flags  Ref   Use   Interface
----------------- ------------------ ----- ---- ------ ---------
localhost	localhost	UH	0	20	lo0
slivan	ethr17a-11	UGH	0	0
single	ethr17a-11	UGH	0	0
mtnview	ethr17a-11	UG	0	9
net-eng-bb	fddi17b-11	UG	0	3961
net15-067-n	ethr17a-11	UG	0	0
net17-007-n	goldigger-eng	UG	0	1291
net19-174-n	fddi17b-11	UG	0	0
net17-083-n	shunt-116	UG	0	0
net21-244-n	ethr17a-11	UG	0	0
net18-148-n	ethr17a-11	UG	0	0
milpitas	ethr17a-11	UG	0	42
net11-144-n	voyager	U	2	3788	le0
224.0.0.0	voyager	U	4	0	le0

Since most routes in the above example are directed through gateway ethr17a-11, choose ethr17a-11 as your default router by creating an /etc/defaultrouter file with that name in it. The file should contain only the name of the selected default router, as in:


ethr17a-11

Note that when you configure your system to use a default router, you sacrifice the dynamic routing capability that Solaris provides. If you don't want to do this, edit the /etc/init.d/inetinit file. Change the test for "routerhood" to always fail: in /etc/init.d/inetinit, change


if [ $numifs -gt 2 -o $numptptifs -gt 0 -o -f /etc/gateways ]; then

to:


if [ `/bin/false` ]; then	# Never be a router


Note -

The disadvantage of this method is that your system can receive Routing Information Packets (RIP) across a PPP connection, which limits the available bandwidth.


NFS Mount Configuration

The NFS and mount protocols allow your machine to access remote networked file systems in the same way that you access local file systems. If you attempt to access a remote file when your SPARCstation Voyager is not connected to a network, however, your machine may appear to stop.

Using the Automounter

To minimize remote access attempts, always use the automounter (automountd). Mounting NFS files exclusively with the automounter insures that remote files are mounted properly and that they are unmounted when not in use (typically five minutes after the last access).

Do not mount file systems with the mount command or by including a mount request in the /etc/vfstab file.

Using the Soft Mount Option

NFS mounts are hard by default, which means that if the file system server fails to respond, the client (i.e. the SPARCstation Voyager) continues to retry the request until it receives a response or until the retry limit (10,000 is the default) is exceeded. If your system is disconnected, then a process that is using a remote file system will appear to stop until the retry limit is reached. You can avoid this problem by declaring that file systems are to be soft mounted. Specify the soft option in the /etc/auto_master file, as follows:


# master map for automounter
#
+auto_master
/net		-hosts			-nosuid,soft
/home		auto_home			-soft

If you experience reliability problems traceable to soft mounts, you can consider not specifying the soft option. However you may become more prone to system stoppages if you accidently access a remote file while disconnected. To minimize this problem, be sure you specify the mount option intr so that you can interrupt mount operations. Refer to the mount_nfs man page for more information about NFS mount options.


Note -

Even if you specify soft mounts, when you are disconnected, an NFS mount request may still take a very long time to fail if you have specified replicated mount paths in the automounter configuration file. If the hosts associated with those mount paths are not defined in the /etc/inet/hosts file, even more time elapses. To avoid this problem do not specify replicated mount paths.


User Configuration

While disconnected, do not access remote file systems: they are not available. This means that you should have a local home directory. You also need a local /etc/passwd entry so you can log in to the machine when disconnected.

Creating a Local Home Environment

To create a local home environment, use either admintool or useradd to specify a local /etc/passwd entry and a local home directory (/export/home/username is recommended).

If your site does not export a network /etc/passwd map through one of the name services, the /etc/passwd entry and home directory will be the only one associated with your username. This is the simplest user configuration.

However, if there is a entry for you in a network /etc/passwd database (i.e. one managed by NIS or NIS+), specify the same user and group id numbers (UID and GID respectively) for the local /etc/passwd entry as are specified in the network database, but specify a different path name for the home directory.

Specify the same UID and GID so that your files are accessible to you whether or not you are logged into the SPARCstation Voyager or another machine and whether or not you are working in a local or remote directory.

Do not specify the same path for the local home directory as for the home directory in the network version of /etc/passwd because the network path is not accessible when the machine is disconnected.

Managing Two Home Directories

When there are two home directories, always work in the local home directory on the SPARCstation Voyager. You may use the network home directory as a backup location. If that is not possible or desirable, you will have to take precautions to insure that the two copies of the home directory do not get out of synchronization.

Define the PATH Environment

Define the PATH environment variable so that it does not contain references to non-local (such as NFS mounted) directories.

To assure that commonly accessed application programs and tools are always available, install them in local directories designated by the PATH variable.

You can initiate infrequently referenced remote programs by specifying the full path name for the command.

You can access remote programs you use more frequently by creating symbolic links to them in local directories specified in the PATH variable, or by creating shell aliases for them.

Define the MANPATH Environment

A MANPATH environment variable, if present, should avoid references to non-local directories.

sendmail Configuration

Edit the sendmail files if you use more than one kind of mail user interface: only if you are not exclusively using a nomadic mail tool.

The sendmail utility is the back end to most of the mail user interface programs such as mailtool and mailx and is responsible for sending mail to remote hosts using the Simple Mail Transport Protocol (SMTP).

The sendmail utility is not affected when the network is disconnected. Most local mail processing can still be accomplished. The front end mail user interface programs will still operate and can still read, delete, copy and move mail messages in the system's inbox (/var/mail/username) as well as in any local mail folders. You cannot, of course, send mail or receive it from remote systems.

With minor changes to a few files, outgoing mail can be composed and sent from a user interface program, and sendmail will queue the mail until the network connection is established or until a queue timeout period (the default is three days) is exceeded, but only if the full address of the recipient can be determined (either because the original mail contains the full address or because it contains a mail alias that can be expanded to the full address).

Remote Mail Host

A remote mail host is another host through which sendmail routes all outgoing mail. When your system is connected to the network, mail will take an extra hop to the mail host before it is delivered. When your system is disconnected, a remote mail host provides automatic queueing of new mail messages until the network is reconnected. This means you can still compose and "send" mail messages when disconnected. The messages will be delivered to the remote mail host shortly after reconnection.

Configuring the Remote Mail Host

To configure a remote mail host, in /etc/inet/hosts, append the word mailhost to an entry that specifies a permanently networked host. The mail host can be any host that is always available to the core network that the SPARCstation Voyager is usually connected to. See the last line in Example 5-1 for an example specification of a mail host.

Mail Aliases

The sendmail utility uses the name service aliases map to expand a mail alias into a fully specified address. If mail is sent to a username, but that name cannot be found in the aliases database, the mail is delivered to the local machine if username can be found in the /etc/passwd file, or it is returned to the sender with a "User Unknown" error message.

When disconnected from the network, or when the alias map is only present in the files name service (as recommended earlier), you must specify mail recipient names to assure delivery. For convenience, you may enter aliases for the people or mail lists you frequently send mail to in the /etc/mail/aliases file.


amy: amy@travails
andrew: andrew@telco.com
bob: bob.roberts@therally
clark: clark@phonebooth
deskset: deskset@thehouse
jim: jim@cosmos
lyn: lynda@flanders
melissa: mfields@home
nomadics: nomadics@server.Corp
our-staff: myboss@hismachine
susan: susan@ct.amber.com
trish: trussell@bambus.COM

It is not necessary to remember, or otherwise determine, the fully specified name for people (or mail lists) who are not listed in the /etc/mail/aliases file. You can send mail to them by addressing it to user@mailhost where mailhost is the name of the mail host you defined earlier (for example, user@cosmos).


Note -

Do not use the actual word mailhost in the host part of the address since that can cause your mail to be misdirected.


You may address your mail to user@domain if your site uses DNS (e.g. jsmith@eng or jsmith@some.com).

Sometimes when an alias cannot be expanded, the mail is delivered to the local machine. This usually occurs because the cache in sendmail becomes unsynchronized with the actual configuration of the system. It may not happen very often or even at all, but occasionally it is a good idea to inspect the /var/mail directory for lost mail.

Queue Limits

As stated earlier, the default maximum time that an undelivered mail message is queued is three days. If your system is disconnected for longer than three days, mail will be returned to the sender. You can change the maximum queue time by changing the following lines in the /etc/mail/sendmail.cf file from:


# return queued mail after this long
OT3d

to:


# return queued mail after this long 
OT999d

In this example, mail will be queued for 999 days before being returned to the sender. See the sendmail man page for a more complete explanation of the values for the queued mail timeout parameter.