/etc/ha.d/haresources and /etc/ha.d/ha.cf are config files which are specifically permitted by the FHS. "/etc contains configuration files and directories that are specific to the current system." /etc/ha.d/harc can be where it is by extension of the examples of /etc/rc.d/rc since it is analagous by design. Ditto for shellfuncs The scripts in /etc/ha.d/init.d, rc.d, and resource.d are analagous by design to the scripts in /etc/rc.d/init.d. I think /etc/ha.d/bin should be moved over to /usr/lib/heartbeat It isn't completely clear where heartbeat-fifo should go. I would suggest /var/run because it is somewhat analagous to the transient UNIX-domain socket example mentioned in the FHS. "Programs that maintain transient UNIX-domain sockets should place them in this directory". [/var/run] ------------------------------------------------------------------------------ /etc contains configuration files and directories that are specific to the current system. No binaries should be located under /etc. ------------------------------------------------------------------------------ /opt is reserved for the installation of add-on application software packages. I don't consider this an applicaiton software package. ------------------------------------------------------------------------------ /usr/lib includes object files, libraries, and internal binaries that are not intended to be executed directly by users or shell scripts. Applications may use a single subdirectory under /usr/lib. If an application uses a subdirectory, all architecture-dependent data exclusively used by the application should be placed within that subdirectory. For example, the perl5 subdirectory for Perl 5 modules and libraries. Miscellaneous architecture-independent application-specific static files and subdirectories should be placed in /usr/share. ------------------------------------------------------------------------------ 5.9 /var/run : Run-time variable files This directory contains system information files describing the system since it was booted. Files in this directory should be cleared (removed or truncated as appropriate) at the beginning of the boot process. Process identifier (PID) files, which were originally placed in /etc, should be placed in /var/run. The naming convention for PID files is .pid. For example, the crond PID file is named /var/run/crond.pid. The internal format of PID files remains unchanged. The file should consist of the process identifier in ASCII-encoded decimal, followed by a newline character. For example, if crond was process number 25, /var/run/crond.pid would contain three characters: two, five, and newline. Programs that read PID files should be somewhat flexible in what they accept; i.e., they should ignore extra whitespace, leading zeroes, absence of the trailing newline, or additional lines in the PID file. Programs that create PID files should use the simple specification located in the above paragraph. ------------------------------------------------------------------------------ set no 5.11 /var/state : Variable state information /var/state misc xdm Variable state information Editor backup files and state Miscellaneous state data X display manager variable data Packaging support files State data for packages and subsystems Tree 5.11.1 This hierarchy holds state information pertaining to an application or the system. State information is data that programs modify while they run, and that pertains to one specific host. Users should never need to modify files in /var/state to configure a package's operation. State information is generally used to preserve the condition of an application (or a group of inter-related applications) between invocations and between different instances of the same application. State information should generally remain valid after a reboot, should not be logging output, and should not be spooled data. An application (or a group of inter-related applications) should use a subdirectory of /var/state for its data. There is one required subdirectory, /var/state/misc, which is intended for state files that don't need a subdirectory; the other subdirectories should only be present if the application in question is included in the distribution. /var/state/ is the location that should be used for all distribution packaging support. Different distributions may use different names, of course. Previous releases of this standard used the name /var/lib for this hierarchy. /var/lib is deprecated, but it may be used in parallel with the required /var/state hierarchy, as a transitional measure for application-specific data. Note, however, that this allowance will be removed in a future release of the standard. Alternately, /var/lib may be made a symbolic link to /var/state. BEGIN RATIONALE /usr/lib is increasingly used solely for object files or archives of them; this is true of the current BSD UNIX variants as well as current GNU packages. Accordingly, the name /var/lib seemed inappropriate. BSD uses the name /var/db for a similar directory. This name seemed overly constricting, as it implied a directory structure intended primarily for database (.db) files. END RATIONALE ------------------------------------------------------------------------------ 4.5 /usr/lib : Libraries for programming and packages /usr/lib includes object files, libraries, and internal binaries that are not intended to be executed directly by users or shell scripts. Applications may use a single subdirectory under /usr/lib. If an application uses a subdirectory, all architecture-dependent data exclusively used by the application should be placed within that subdirectory. For example, the perl5 subdirectory for Perl 5 modules and libraries. Miscellaneous architecture-independent application-specific static files and subdirectories should be placed in /usr/share. Some executable commands such as makewhatis and sendmail have also been traditionally placed in /usr/lib. makewhatis is an internal binary and should be placed in a binary directory; users access only catman. Newer sendmail binaries are now placed by default in /usr/sbin; a symbolic link should remain from /usr/lib. Additionally, systems using Smail should place Smail in /usr/sbin/smail, and /usr/sbin/sendmail should be a symbolic link to it. A symbolic link /usr/lib/X11 pointing to the lib/X11 directory of the default X distribution is required if X is installed. Note: No host-specific data for the X Window System should be stored in /usr/lib/X11. Host-specific configuration files such as Xconfig or XF86Config should be stored in /etc/X11. This should include configuration data such as system.twmrc even if it is only made a symbolic link to a more global configuration file (probably in /usr/X11R6/lib/X11).