| Previous | Table of Contents | Next |
In migrating existing users to a new software scheme, you must (carefully) simplify their existing setups. Of course, they need the mount point and mount, and the path component(s). Beyond these, you must remove most of the other hard-coded settings, to allow the dynamic connections to operate. There are always exceptions, though, and some hard-coded setups remain appropriate.
If you must maintain multiple application servers and need to copy application packages (or entire file systems) from one to another, you probably want to become familiar with the rdist(1) command. It is a standard utility specially designed for synchronizing file systems or portions of file systems between remote hosts. One of rdist’S great advantages is that it compares the status of files between the source and destination systems and copies only those files that need updating. This procedure is more efficient in many cases than using tar, for example, which copies all files unconditionally.
Unfortunately, the manual page for rdist does not provide clear guidelines for how to begin simply and scale to more sophisticated formats. The following paragraphs provide some suggestions for how to begin.
NOTE: Be sure to begin with controlled experimentation in a test environment and study of the rdist manual page so that you are not unpleasantly surprised by unexpected results.
To be able to rdist from one system to another depends on some level of trusted host relationship. (That is, the UID using rdist must be able to log in to the remote system without a password.) You may want this account to be owned by a UID other than root.
Once this privilege exists, you can rdist a hierarchy from the local system to the same destination on the remote system with a command as simple as the following:
$ rdist -c /usr/appsremote-system
Perhaps the most common form of rdist is to refer to a file that lists the target host systems and the pathnames to be synchronized. When the file has been created, use the following syntax:
$ rdist -f distfile
You may encounter limitations because rdist distfiles cannot use actual shell variables for flexibility. You can work around this limitation, however, by creating a script in which the shell expands variables before feeding the resulting syntax to rdist. The format of such a script, shown here, is the beginning of the power needed to use rdist to perform flexible, selective updates.
#!/bin/sh files=" pathname1 pathname2 . . . " hosts=" host1 host2 . . . " rdist -f - <<-EOrdist (“$files”) -> (“$hosts”) EOrdist
NOTE: Beware of using rcp -r to copy hierarchies. In the process, symbolic links get converted to actual copies of their destination files. This conversion not only can affect the amount of space occupied, but can produce unexpected behavior. You may later make changes to link destination files, such as wrappers, not realizing that command names have become outdated copies of the script itself. Also, rcp does not replicate UID, GID, or permissions.
Many SunSoft unbundled products and application software packages require software licenses that control the number of users who can access the product at the same time. If the application software has a floating license system, you can also designate the application server as a license server. Alternatively, a single license server can manage licenses for multiple application servers, provided the license server is accessible to all the application servers across an existing network.
A full description of all the available types of licenses and license servers is beyond the scope of this book. Following are three possible configurations for setting up license servers:
The following sections describe how to access files on a CD-ROM from a local drive on a system running Solaris 2.2 (and later) system software, from a local drive on a system running Solaris 2.0 and 2.1, and from a remote drive.
With Solaris 2.2 system software (and later), the CD-ROM is automatically mounted for you when you insert a CD-ROM caddy into the CD-ROM drive. Use the following procedures if you are running Solaris 2.2 system software or later. (If you are running Solaris 2.0 or 2.1 system software, use the procedures described in the section “Using a Local CD-ROM Drive (Solaris 2.0 or 2.1 System Software).”)
NOTE: Diskettes are also automatically mounted using the Solaris 2.2 volume management software. See Appendix A for more information.
To access files from a local CD-ROM drive with Solaris 2.2 (and beyond) system software, you do not need to have superuser privileges or to create a mount point. Simply insert the CD-ROM disc into the disc caddy and insert the disc caddy into the CD-ROM drive. The /cdrom mount point is created and the files are mounted. The /cdrom directory contains a cdrom0 subdirectory that is a symbolic link to the volume name of the CD-ROM. You can type either cd /cdrom/cdrom0 or cd /cdrom/cdrom-name to access the files.
| Previous | Table of Contents | Next |