| Previous | Table of Contents | Next |
Parallel Hierarchies
You may want to create one or more parallel file systems. For example, you might want to make a distinction between packages implemented by central administration and packages introduced by regional administration. You also might want to distinguish between production and beta versions of software.
If you want to create such parallel hierarchies, you could designate them as follows:
/usr/apps/local/pkgs /usr/apps/local/exe
The /usr/apps/local/pkgs directory contains the applications, and the corresponding /usr/apps/local/exe directory would contain the symbolic links to the wrappers for those applications. Under this type of arrangement, you need to add a second path (/usr/apps/local/exe) to the users’ environment. If you arrange the directory as a parallel hierarchy instead of a separate file system, you could use a single mount point. If you create a separate file system, users would need to have a second mount point.
Clearly there are more variations not presented here. It is important for you to determine your needs. Try to plan for the long term, and try to keep your setup as simple and as consistent as possible. At Sun it has, indeed, been possible to provide most application services through a single mount.
Transitory Names
If you use wrappers, avoid the temptation to create a file system with directories that are named after architectures or other transitory distinctions; for example, /usr/apps/sun3. Packages are always present, but other distinctions come and go. Confine file system distinctions to individual application directories (which come and go themselves) where the changes impact only the wrapper.
Permissions
Unless you have good reasons not to do so, permissions should be mode 755 for directories you create and for those within applications, so that they are writable by owner, with read and execute for group and world. Sometimes vendors ship nonwritable directories that interfere with your ability to transfer the contents to another system. In general, make other files writable by owner, and readable by all, and leave execute permissions intact. You can use the following commands to change a directory hierarchy to the recommended permissions:
$ /usr/bin/find directory-name -type d -exec /usr/bin/chmod 755 {} \;
$ /usr/bin/chmod -R u+w directory-name
$ /usr/bin/chmod -R ugo+r directory-name
$
CAUTION! Do not execute these commands from the root (/) directory.
Ownership
If you set up or maintain an extensive network of application servers and update them using trusted host relationships, consider what account should own the software distribution. In general, you do not need to have root be the owner. You may find some security advantages to creating a special, nonprivileged ownership account for managing application servers.
Before users can access files on the application server, you must share (export) the file system to make it available to other systems on the network. SunSoft strongly recommends that you share the application’s file system read-only.
Follow these steps on the application server to share the file system:
share -F nfs -o ro pathname
In the following example, the pathname /usr/apps is shared:
oak% su Password # vi /etc/dfs/dfstab [Add the following line] share -F nfs -o ro /usr/apps [Quit the file and save the changes] # share /usr/apps #
If you must start the NFS service manually, use the following steps. Otherwise, the services will start up at boot time.
The pathname is the name of the mount point file system. For example, if you have mounted the partition as /usr/apps, type share -F nfs -o ro /usr/apps and press Return.
If you want to install the application in the /usr/apps directory rather than /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.
SunSoft suggests that you use a name for the application directory that reflects the actual product name (in lowercase 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 directory /usr/apps/pkgs/footool,v2.0.
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 13 for instructions on how to use the package commands. See Chapter 14 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 $
| Previous | Table of Contents | Next |