Installing and Configuring Packages
If you want to install the application in the /usr/apps directory instead of /opt, you need to set up either the package commands or Admintool to install the software in a different directory and then install the software.
Sun suggests that you use a name for the application directory that reflects the actual product name (in lower case for simplicity), with some sort of version suffix. For example, following the proposed naming convention, you might install version 2.0 of FooTool in the /usr/apps/pkgs/footool,v2.0 directory.
Follow the vendor's directions to install the software. If the vendor's or developer's install procedure does not use the package commands, you may need to rename the directory after completing the vendor installation process. See Chapter 14, “Package Commands,” for instructions on how to use the package commands. See Chapter 15, “Admintool: Software Manager,” for instructions on how to use Admintool.
Normally you should minimize any changes that you make to the original installed software. The flexibility of the wrapper helps you adapt to unusual requirements. You do, however, typically want to add some things to the package—at least, the wrapper itself. Create a subdirectory at the top level of the package to contain the wrapper and other possible additions. Such additions might include site-specific README files, announcements, and scripts that complete server-specific setup for the package. In the following example, the subdirectory is called dist.
$ cd /usr/apps/pkgs/footool,v2.0 $ /usr/bin/mkdir dist $
Determine whether you think this directory requires additional subdivision. If so, be sure to use a consistent naming convention. The location of the wrapper determines the form of the command name links that must connect to it. For the purpose of this example, refer to the wrapper as being in the top level of this subdirectory and name it simply wrapper, as shown in the following example.
/usr/apps/pkgs/footool,v2.0/dist/wrapper
In many application packages, you must configure some of the files before the package can be run. If you are maintaining multiple application servers, consider the following issues.
Once you modify the original files, you may not have generic copies left. If you copy the package to another server, you may want the original files to match the vendor's setup documentation.
If you synchronize the package between servers after setup, be careful not to overwrite the server-specific setups with those from another server.
Consider how you want to handle such files. One way is to identify the files that are candidates for modification and to make copies of them where they reside, using a suffix such as .orig. This convention preserves generic copies. You still must avoid shipping the modified versions of these files to other servers so that you do not overwrite local configurations that are already established.