The XHIER system provides convenient solutions to a number of problems by allowing one to:
This document presents the general philosophy behind XHIER, and describes how various types of users might view and use it. A simpler summary of the philosophy is also available in Xhier Philosophy and Goalshttps://rbutterworth.nfshost.com/Reports/xhier/.
In order to present the ideas rather than any particular implementation, this document gives very few specific implementation details, and those appear only in inserted boxes. We hope that the concepts presented have more value than the current underlying software.
One may view the XHIER world from several different perspectives. In particular, one may consider how packages fit onto individual machines, how software distributes from source to all destinations, and how configuration affects various machines.
Rather than intruding into the vendor's file space by going directly into /usr/bin, etc., almost all files related to a particular software package live together in one directory: /software/packagename/. This makes it easy to find all the parts of the package without having to search around the machine's filesystems, and greatly simplifies removing a package from a machine. This minimal intrusion into the rest of the machine's filespace also means that one can upgrade system files without having to worry about most of the existing XHIER software packages.
Each package has several standard directories that make it easier to find things. For instance, the directory bin contains all the package's programs that normal users might want to use, while programs intended for administrative work reside in a directory called maintenance. Similarly directories such as include, man, and doc contain header files, man pages, and other documentation. Other standard directory names provide locations for various other purposes.
Automated XHIER supervisory software knows about these and other standard locations and makes their contents available via search rules, crontab entries, mail aliases, boottime scripts, etc. The package's entries for the crontab, inetd, boottime, etc. use standard formats that XHIER translates into formats appropriate to the local host's files. These automated updates retain knowledge of the original contents of the system files, so the removal of any individual packages, or even of all of XHIER, will restore the affected parts of system files to their original state.
A package called xhier provides most of these automated tools, as well as various other maintenance programs and configuration files.
One requires a good understanding of XHIER's basic file types in order to administer a machine or maintain a software package. Most other users need not know any details, though they can often benefit by knowing more about the concept of regions.
A package's files and directory structure fall into the following types:
7. Administering a Software Packagesection below describes how a package maintainer can distribute source and build architecture-specific files on all the arch masters.) The package structure, and all share and arch files, propagate from each arch-master to other machines of the same architecture. This data may propagate from those machines to other machines of the same architecture, and so on.
In order to distinguish between the file types,
XHIER currently uses symlinks into
several directories, each having a structure parallel
to that under the /software directory.
In particular, for every
/.software/type/package/rest-of-path
there exists a corresponding
/software/package/rest-of-path.
For instance, /software/x11r5/bin symlinks to /.software/arch/x11r5/bin.
The distribution path for the share and arch files has a tree structure, with the source-master as the root, and the arch-masters as the first-level nodes.
The distribution paths for admin files forms a forest of trees, each rooted at an admin-master. The admin files propagate along paths independent of the share and arch distributions, but typically the two will share common subtrees.
Regional, local, and spool type files have no distribution path.
Politics and security considerations (each machine must trust the machine that supplies it) and load (each client adds extra load to a server) contribute to the shape of the distribution tree. Where resources permit, having machines dedicated to nothing but distributing software (e.g. the arch-masters) provides a good solution.
XHIER provides a standard configuration method by which multiple levels of administrators may specify configuration information. Not all packages will necessarily use this, but for those that do, the consistent method of configuration makes administration quick and easy.
A package may have a directory called config, which may itself contain directories named after the basic XHIER file types. Each such directory may have one or more files, with names appropriate to their use within the package.
A package's scripts and C programs may use programs and library functions, provided by the xhier package, to query a package's configuration. The process involves possibly initializing the default values, then modifying those values based on the following files, in the given order:
configname refers to an arbitrarily chosen name for the relevant configuration information. For instance a package might have configuration files called quota and privileges, which determine the allocation of quotas and privileges for the users of that package.
The xh-options command allows scripts to examine the values, automatically handling the various levels of overriding configuration.
Many configurations don't have a share type, but instead have the initial values hard-wired into the program. Similarly, the arch configuration type also rarely appears, as values seldom depend upon the architecture, and even when they do, they conceptually have the same purpose as share (i.e. specified by the package maintainer), and so can also have hard-wired initial values.
The admin configuration tends to provide the most benefit, allowing an administrator to set the defaults for possibly hundreds of machines at a time. For instance, options, say HighLoad=6 and HighTime=2, might tell a package to notify the administration whenever the loadaverage on a machine remains above 6 for more than 2 minutes. Should these values need adjusting, the administrator needs only change that one file to affect the configuration on all the machines in the administration.
Whenever making changes to a configuration file one should make use of RCS to record the change.
RCS will automatically record who made the change and when, and more importantly, will record comments supplied indicating why someone thought they needed to make the change.
In addition, properly RCSed files do not have write permission, making it less likely that someone might accidentally change the wrong instance of a file (e.g. changing an admin file on a machine other than the admin-master).
Similarly, regional configuration can save a great deal of time, and guarantee consistency, when dealing with a collection of machines with the same user community. These machines might perform critical functions, so, continuing with the same example, the regional administrator might override the default provided by the administration by setting HighLoad=3 in the package's regional configuration file.
Or perhaps the machines in the region provide heavy-duty service, so the regional administrator might set the single regional configuration file to allow a much higher limit on all the machines. But if one of the machines in the region, say the regional-server, performs more essential duties, that machine's local configuration file might specify a much lower value.
When deciding which files to use for a package's configuration, a package maintainer should almost never provide local configurability without having first provided regional, which in turn one should not provide without admin. Should the need ever arise, the package maintainer will find it very much easier to add local configuration to a package that already has regional than vice-versa.
XHIER automatically makes each package's programs, libraries, header files, man pages, etc. available, either by linking them from the standard places the system would normally contain such things or by providing an additional directory that users can add to their search rules. New user accounts will normally have this modification to the default PATH setting already in place.
The showpath command provides a simple interface that allows the selection of specific software packages that do not appear in the default search rules.
One's .cshrc file might contain the following (all on one line):
This simply sets the user's path to search first in the personal bin directory, and then in the standard places. These standard places may contain different directories, depending upon the local architecture, but will include the XHIER software ahead of the vendor's directories.
Some software packages might have configuration that prevents them from going into the default path (e.g. perhaps it contains a version of a command that would replace the vendor's version, or perhaps the machine has multiple versions of a package installed). In such cases the user can simply add the name of the package(s) to the showpath invocation, typically after the personal directory but before the standard rules.
Most users need not understand how XHIER works or even know of its existence. They might sometimes ask for new software, resulting in some administrator's requesting the appropriate package, or they might occasionally need to add a package to their personal search rules, but in general it will not directly affect their activities.
For users that work on several machines, XHIER provides a more familiar and consistent environment, especially when those machines have different architectures. Users do not need to wonder so much about where this particular vendor has hidden some file, or why some command's option flag has a different meaning here than there.
Though not strictly a part of XHIER itself, many of the available packages that use it also help to provide a comfortable environment. For instance one can rely on the same mail aliases doing the right thing on all machines (e.g. mail to accounts or consultant forwards the mail to the appropriate people, without one's having to worry about first determining the appropriate administrators or on which machines they normally receive mail).
For users with access to a collection of several machines, a regional configuration provides many advantages.
Although the system administrators could maintain such collections of machines by other means, XHIER provides enough support that these regional configurations provide a practical, convenient, and useful mechanism.
The set of packages that appear on a machine depends upon local, regional, and admin configuration. Similarly, which packages end up installed or linked into the default search rules also depends on local, regional, and admin configuration. Typically a machine administrator accepts the defaults for the administration and region, and makes local configuration changes only when necessary.
Optional /software/xhier/config/type/packages/package files override the default options associated with each package, /software/package/.admin/Options. The type represents any of share, arch, admin, regional, or local.
Since XHIER does most of its work automatically, machine administration consists mostly of making changes to local configuration files and checking mail messages and log files. And ideally, most of the configuration should happen at the administration level, causing most individual machines within the administration to have as similar configuration as possible.
Machine administrators should not make changes directly
to those system files that XHIER updates,
such as /etc/aliases, /etc/crontab
(or their equivalents).
This should not
has two different senses.
First, by avoiding manual changes and instead using
XHIER's mechanism, one gains its benefits,
such as repeatability, automation, and so on.
Second, in practical terms, one must not manually edit the
portions of such files that XHIER has
modified.
Thus, other than configuring software packages, one would make most local changes and additions (mail aliases, crontab entries, etc.) to a package called local_FQHN, where FQHN represents the fully qualified host name of the local host. This package also provides a convenient place for documentation and other data specific to the local host.
As much as possible, one should treat even a single machine as a (trivial) region, avoiding local configuration whenever possible. If the region ever gains another machine, the new machine will automatically get the existing regional configuration and the administrator will have to update only those things that actually require local configuration (hostnames, filesystem mount points, etc.).
The setpw package runs a daemon on the regional-server that accepts updates by passwd, chfn, etc. from any of the machines in the region.
It also provides programs that regularly distribute the passwd etc. files from the regional-server to the other machines, preserving original vendor entries when the destination has a different architecture.
The passwd and group files (and where applicable, shadow files etc.), must contain the same uids and gids for all users and for all accounts and groups associated with XHIER packages. Ideally one would want to have identical files everywhere, but cannot do so in cases where a region contains machines of different architectures.
The XHIERed package, setpw, will automatically provide the necessary support, including the ability to restrict login access on individual machines to specific users or members of specific groups, but one may instead choose other methods of achieving this if one desires.
All machines in a region must mount the same mailboxes, user home directories, and XHIER's regional files, though which machines the disks physically reside on does not matter.
Adding new machines to an established region (even if it consists of only one machine configured as a region) requires very little work, less in fact than setting up the new machine independently. All home directories, passwd entries, etc. will already exist, and most software package configuration will automatically appear in the mounted regional data.
Retiring old machines from a region, or even changing which machine has the regional-master designation, similarly requires little effort, and no disruption to the users.
The prsh command enables one to run things on all machines in a region at the same time. For example, this one line will display the results of the uptime command run everywhere in the region:
Similarly one could use prsh to run
to check for identical results everywhere, ensuring the correct mounts of all regional data, and to add another host to all hosts.equiv files.
To avoid confusing people when they use programs such as rdist or recover, or when creating symlinks to absolute paths, one must ensure that the paths of all regional files and all home directories have the same absolute values on all machines in the region (even if this means doing things like creating dummy /fsys3 directories on some machines).
A regional maintainer should install the software packages that users want on all machines in the region, and should ensure that for packages with multiple versions, each machine has the same version in the user's default path.
One should ensure that all hosts appear in each other's hosts.equiv files. One should also maintain similar motd files on all hosts in the region. (Unfortunately no XHIERed software provides either of these services yet.)
XHIER administrations greatly simplify such tasks as enforcing policy, setting standards, gathering statistics, and ensuring uniform environments on a large number of machines.
In general, the administrator of an XHIER administration doesn't worry about system configurations or other details specific to individual machines, but instead sets configuration files on a single machine, thereby controlling the default settings on all machines. Regional and local administrators can then override some (but not necessarily all) of these settings as they desire, without having to bother the administration administrator.
In the Math Faculty for instance, one administration contains well over a hundred UNIX machines. A small number of configuration files on the central administration machine controls all others, allowing one to specify such things as the minimal set of packages that each machine should receive, or the preferred behaviour of news and mail software.
On the source-master, a directory called /source contains one directory for each package, each having the same name as the package. Each package directory should (but doesn't always) contain one subdirectory for each program, library, etc., each having the same name as the program, library, etc.
Generally, each source directory contains a file, xh-imakefile, that contains the necessary configuration information to enable the building of the package, program, etc. It should provide common targets, such as all, install, and clean. (In the absence of an xh-imakefile, the directory must contain a appropriate files such that the xh-make command will still work.)
The xh-imakefiles use a preprocessor that allows them to share a set of predefined definitions that provide information about XHIER structures, programming languages, and file types. So for instance, one does not need to know that on some architectures one must compile most programs with -lm, on others with -lnsl -lelf, etc., as the generated makefile will automatically contain references to the appropriate libraries for the local architecture.
It might take a bit more work to set up a package's source with this structure, but the effort will more than pay for itself the next time someone has to make a small change or build it on a new architecture.
From the source directory for a package, or for a single program, one may use the command
xh-sdist -n -m all >&#made
to distribute the source to all arch-masters and build it there. And after checking the output for possible errors,
xh-sdist -n -m install >&#install
will install the new version of the software on all arch masters.
Package maintainers can make changes to individual programs within a package and then trivially (i.e. all with a single command) distribute the source to all architecture masters, build the changed software there, and install it into each machine's /software, from where it will later automatically spread to all other machines of the same architecture.
Similarly, even someone that doesn't maintain any packages may easily distribute and build software without knowing the details of each specific package, since the same standard targets and basic methods should apply to all packages. For instance, if a new architecture-master machine arrives, one can build many packages on that new machine without their individual package maintainers having to do anything.
Normally one first builds, tests, and installs updates on the source-master before updating any other machines. This means that the architecture-specific files will have older dates on the source-master than elsewhere. If any updates fail on any of the arch-masters (e.g. an unavailable machine), XHIER will eventually send mail to the package maintainer (currently every weekend) reminding them of what still needs updating.
Most standard header files have a corresponding cover file with a similar name, e.g. <mfcf/libc/stdlib.h> contains a declaration for clearenv() when used on LINUX systems, and a definition of RAND_MAX for those architectures that do not define it in a header file.
Sometimes a header file defines a new symbol to avoid problems where different architectures have different names or behaviours. e.g. <mfcf/libc/signal.h> provides a typedef for SignalType, the return type of the user-supplied signal handling function ((void) on some architectures but (int) on others).
Using a set of header files provided by an XHIERed package, one can write very portable C programs that do not depend or even need to know about the differences of specific architectures. If program source includes these rather than directly including the vendor's versions, the programmer can rely upon a common environment across all architectures, the cover file compensating for various differences.
Similarly, some common useful functions do not appear in the standard libraries on some architectures. A library, -lcfix, supplies the missing functions on each architecture. This library also supplies replacement functions in cases where the vendor's version does not work as expected. The standard makefile generator automatically requests this library, without the package maintainer's having to even know that it exists.