2.1 Introduction

The following are general rules for the new layout:

/dev is used for device files. The contents and meaning of /dev has not changed. Nothing should be installed in /dev. Instead, configuration files should create node-specific device files.

The /etc hierarchy contains host-specific system and application configuration files important to the correct operation of the system. Files located here are usually fixed size and do not grow. By contrast, the /var hierarchy holds files that are dynamic in length or are less critical to system execution, such as log files. In general, /etc holds essential information that must be preserved in order for the system to function correctly, while /var holds information generated by the system that may be disposed of when it is no longer of interest. Some customer sites may choose to make automatic backups of the /etc hierarchy, but not of /var.There will be subdirectories under /etc for some systems; for example /etc/mail and /etc/uucp for the mail system and uucp respectively.The /etc directory itself is used only for system configuration files. /etc no longer contains commands, rc scripts, log files (with the exception of a few critical log files), or other files not related to system configuration. Most commands have moved to /usr/sbin. Rc scripts now reside in /sbin/init.d and follow the new system start-up and shutdown paradigm (see Section 3., “System Start-up/Shutdown Model”). Log files and other miscellaneous files not related to system configuration are now in /var.

The directory is used to support diskless file sharing. Servers export root directory hierarchies for networked clients.

User directories will be created and managed under /home instead of /users. Nothing should be installed in /home. This is a portion of the file system that is allowed to grow.

/lost+found contains files located by fsck(1m).

Reserved name for mount points for local file systems. This is not an install location (that is, nothing should be directly installed here from HP update media). /mnt can be used as a mount point directory, or a directory containing multiple mount points.

Reserved name for mount points for remote file systems.

The root directory for optional applications. /opt is not a sharing point, but rather, its subdirectories are sharing points. This allows one to mount only those applications that make sense for a given machine or release, rather than mounting all applications available on a server. No files should be delivered into /opt, but rather into subdirectories of /opt, as described below.

/sbin contains the commands and scripts essential to boot and shutdown a system. /sbin contains the commands required to bring the system into a state in which the /usr filesystem can be mounted and the boot process continued. /sbin also contains commands needed to fix filesystem mounting problems.

Commands in /sbin must not depend on any filesystems that may not be mounted at the time the command must execute, including the /usr, /var, and /opt filesystems. Since shared libraries reside beneath /usr, commands in /sbin are statically linked (that is, built with archived libraries). Commands in /sbin must not execute any commands from the /usr filesystem; only other /sbin executables may be referenced. If a command referenced by an /sbin command is replicated between /sbin and either /usr/bin or /usr/sbin, then the path to the command must refer to the /sbin version.

Some commands in /sbin are duplicates of, or the target of symbolic links from, other commands in /usr/bin and /usr/sbin. For example, the ls command exists in both /sbin and /usr/bin. If a command in /sbin is duplicated in either /usr/bin or /usr/sbin, the duplicate exists to take advantage of shared libraries for most executions of that command, or to provide full functionality if the /sbin version does not.

Some commands in /sbin do not offer the full functionality provided by their /usr/bin or /usr/sbin counterparts. For example, some NLS functionality that requires shared libraries is not present in the /sbin versions of certain commands. For this reason, use of the /usr/bin or /usr/sbin versions of replicated commands is preferred, when possible. When constructing shell PATH variables that contain a /sbin component, /sbin should appear after /usr/bin and/or /usr/sbin in the path.

/stand is for system-specific kernel configuration and binary files. The files are typically needed at boot time to bring up a system. This directory is not an install point.

/tmp is for system-generated temporary files. The contents of /tmp are usually not preserved across a system reboot. The choice of whether or not /tmp is cleaned up at boot time is left to the customer.The /tmp directory is private. Since many sites will delete files from /tmp at boot time, files that must be preserved should not be placed in the /tmp directory. Application working files should go in /var/tmp or /var/opt/<application>. Files generated by the OS that must be preserved across reboots should go into the /var/tmp directory.

/usr contains the bulk of the operating system, including commands, libraries and documentation. The /usr file system contains only shareable operating system files, such as executables and ASCII documentation. Multiple systems of compatible architectures should be able to access the same /usr directories. /usr may be mounted as read-only by diskless clients, and thus may not be writable by clients.The allowed subdirectories in /usr are defined below; no additional subdirectories should be created. Any 9.x applications that resided in other subdirectories in /usr have moved beneath the /opt hierarchy.

This directory is for multipurpose log, temporary, transient, variable sized, and spool files. The /var directory is extremely “variable” in size, hence the name. In general, any files that an application or command creates at run time, and that are not critical to the operation of the system, should be placed in a directory that resides under /var. For example, /var/adm will contain log files and other run time-created files related to system administration. /var will also contain variable size files like crontabs, and print and mail spooling areas.

In general, files beneath /var are somewhat temporary. System administrators that wish to free up disk space are likely to search the /var hierarchy for files that can be purged. Some sites may choose not to make automatic backups of the /var directories. If a product locates important configuration files here that do not fit under /etc, it is recommended that documentation explicitly reference /var files to back-up.

/var should not be placed on a small, fixed-size partition. Also, /var is not an install point.

As discussed earlier, the 10.x file system model separates static and dynamic files. Application product file system layouts follow the same conventions and extend the model to provide separation among products. This is accomplished in many ways:

In general, /opt is the application directory. Below here, applications are self-contained in their own directory, /opt/<application>. Shareable files (that may be shared among multiple nodes), such as binaries, man pages and libraries, reside in this directory. Host-specific private files, such as logs and node-specific configurations, are located in the private/dynamic directories under /var/opt/<application> and /etc/opt/<application>, respectively.

The application root (/opt/<application>) should contain a subdirectory structure similar to that of /usr: bin, lbin, lib, man and newconfig. Figure 2-3, “Application File Layout”, shows a sample directory structure.

	NOTE: bin, lbin, lib, share, and newconfig look like /usr.

Figure 2-3 Application File Layout

Application binaries and libraries follow the same layout used by the operating system. User commands are located in /opt/<application>/bin, back end commands reside in /opt/<application>/lbin, and shared and archived libraries reside in /opt/<application>/lib.

Application manpages are kept separate from OS manpages and reside in /opt/<application>/share/man.

Other architecture-independent files that may be shared by more than one system reside below /opt/<application>/share and must follow the same layout conventions specified for the operating system in section 2.2, “File System Layout Specification”. These include object files and libraries, to name a few.

System-dependent configuration files for applications reside in /etc/opt/<application> and include files necessary for the proper run-time execution of the product. Files that are by-products of execution are considered temporary files and should be located under /var/opt/<application>. Because all system configurations are located under /etc, system administrators can easily view system and application configurations. This also facilitates backup of configuration data for a given machine.

	NOTE: Dynamic files, such as logs and configurations, should never be loaded directly into their target locations in /etc or /var (This may overwrite current data). These should be delivered below /opt/<application>/newconfig, as specified in section 2.2.3.12.9, “/usr/newconfig”, and moved into place during product configuration.

Temporary files created by applications (products installed in /opt) for use during run time are located in /var/opt/<application>. This includes logs and lock files that are by-products of run time execution, but does not include those configuration files necessary for correct execution of the application. Configuration files reside below /etc/opt.

Product binaries, man pages and other files are no longer contained in common system directories. Consequently, the default system path values no longer point to all the installed software and must be adjusted for products as they are added to a system. The new model provides a mechanism to “register” a product's files with the appropriate path variables.

Two path variables are considered: PATH and MANPATH. Each variable is addressed with a separate file, each containing a colon-separated list of values representative of the particular path variable:

The system default login files (/etc/profile, /etc/csh.login) appropriately source these files for the respective path variables.

The path files should never be directly manipulated by a product's installation processes. SD provides configuration utilities that enable applications to add their product-specific values to the appropriate path variable files.

Software developers frequently code pathnames into their source. These paths may appear in header files and library routines, as well as the main body of code. The 10FSL changes require developers to scan these sources for pathname values, evaluate the findings and implement the necessary changes to reflect the correct file system layout. Hard-coded pathnames may be found in:

For solutions to finding embedded pathnames, see section 2.5.1, “Finding Embedded Pathnames.”

An important, but often overlooked, area is environment variables. These may be contained in the system and user login files such as ~/.profile, ~/.login, ~/.vueprofile, ~/.cshrc, and /etc/skel/d.*. These are the most common files, but there may be others associated with applications. Be sure to check your system for other possible occurrences.

Environment variables that have execution strings or contain paths are likely to be impacted. Be sure to change all path variables to reflect the correct directories where your commands are contained.

Developers often keep separate environments for building and testing their systems and applications. This is also an important area to evaluate for hard-coded pathnames. Makefiles and test scripts may contain paths that have been changed as a result of the 10FSL.

Many applications have detailed documentation outlining the product installation locations. Documentation should also be scanned for obsolete path names.

There are a number of ways to search for embedded pathnames. A few recommended solutions are listed below. However, you should note that these are only suggestions and are not guaranteed to find all embedded pathnames. Each developer should analyze their applications and systems for any other areas that may not execute properly on the 10FSL.

HP provides a database and a tool to assist you in locating operating system product files in both the 9.x and 10.x locations. The tool is /opt/upgrade/bin/fnlookup on an HP-UX 10.x system. Please see its accompanying documentation for further details.

In the meantime, you may examine a HP-UX 10.x system using the find command:

find <path> -print | grep <filename>

This will produce the location of the desired file if it is contained below <path>. If not, try another path location.

In the 10FSL, there are no longer only a few key places, such as /usr/bin, where executables may be found. Applications will have both manual (“man”) pages and binaries in application directories below /opt.

As applications are added to a user's environment, the PATH and MANPATH variables must be updated so that commands and man pages will be found. There is an automated mechanism available to application developers to add their appropriate entries to these paths. However, all applications may not take advantage of this mechanism. In this case, the user will need to manually add to the appropriate path variables.

For example, if a (ksh, sh) user has application XYZ and wishes to have the man pages and binaries accessible without fully qualifying the path, both the PATH and MANPATH variables may be updated to resemble:

PATH=$PATH:/opt/XYZ/bin

MANPATH=$MANPATH:/opt/XYZ/share/man

This task would be executed for each application that was added to the user's environment. In some cases, applications may provide this capability during configuration. In other cases, system administrators and users must ensure their variables are set correctly for the environment. This syntax is specific for ksh and sh; csh users must use the appropriate syntax.