Xhier is an implementation of a philosophy intended to solve several orthogonal but related problems. It was designed by MFCF in the days when we were encouraged and allowed to develop infrastructure support.
Unfortunately, over the years since it was first written it has had very little support or development.
Some complaints about xhier are quite legitimate.
The original implementation grew in ways that weren't anticipated
and so it appears a little more complicated and awkward
than it would be if we were to redesign it.
Some of its basic tools weren't written in ways that make them
as generally useful as they could have been.
Some of the xhier terminology is misleading or inappropriate.
And much of it was implemented assuming that the people that worked
with it would know to do the right thing
rather than strictly
enforcing standards.
Some people that misunderstand it have attacked xhier based on the existence of possibly better products that provide only one small aspect of what xhier provides. Even worse, others have damaged what we have accomplished by building packages or source that deliberately avoids or abuses the uniform standard methods provided by xhier.
Despite all these problems, the basic philosophy and goals of the original concept are still something that no other system or set of systems has accomplished.
Our users had access to several (at times over a dozen) different computer architectures. Some were very similar, while others were very different. We wanted to provide a uniform environment in which the same commands were available across all platforms, and all commands behaved the same way on each.
To make it easy to compile software on multiple architectures
we needed a uniform programming environment so that source
could easily be written and compiled without having thousands
of architecture-specific #ifdefs embedded in the code.
Similarly, various standard libraries and compiler options specific
to each architecture were provided automatically without the
programmer needing to know anything about them.
A programmer should be able to make changes to code on the central source master, and trivially have it built on all architectures without having to sign onto the other machines or having to do anything different for one architecture over another.
If for some reason (e.g. an architecture master was down at the time or there was a compiler error) some code is rebuilt on the master and some but not all arch-master clients, xhier will regularly and automatically notify the package maintainer of which specific parts of the package still need to be updated on which architecture masters.
To make it easy to administer a large number of packages we needed to provide uniform configuration methods. All configuration can be found in the same standard location in each package, categorized as to what level of administration may change it.
While they were not required to be used, tools were provided for several standard methods for packages to combine the various levels of configuration.
We had a large number of machines each requiring different subsets of a large number of software packages. We wanted the default set of packages and the default configuration therefor to be maintained on one central machine.
The different platforms each needed their own architecture-specific configuration, maintained on one designated machine of each type.
There were also administration-specific policies that needed to be maintained on one designated machine for each administration (e.g. MFCF, IST, CGL, Engineering). This includes a list of requested packages and administration-specific configuration.
In addition, it was convenient to group a set of machines (often of different architectures) into regions, sharing the same home directories, mailboxes, and users. There could also be region-specific configuration which would also be mounted on all machines in the region.
Any machine within a region could be arbitrarily designated as the regional server, as all machines have access to the same data. Individual package installation scripts could then have sections of code that run only on the regional server in order to avoid having several machines doing the same thing at the same time, when once would be enough.
When necessary, configuration at the individual machine level was also provided. Local configuration overrides regional configuration, regional overrides admin, and admin overrides shared.
Each package maintainer could define what levels of configuration are allowed.
The way each package is distributed is identical for all packages. In general the programmers and administrators don't need to worry about distribution, as it happens automatically based on regularly scheduled distributions. Under special circumstances, a manual distribution of individual packages can be forced at any level of the distribution tree.
The various types of files (shared, architecture specific, admin, regional, and local) are separated into the same obvious locations within each package. This makes the process of distribution and maintenance far simpler.
The distribution tree could be arbitrarily deep. Based on configured requests, package updates should automatically be distributed to all the other hosts, the common shared portion of each package being distributed from the central server to the arch masters, and thence along with the architecture-specific parts to their clients. Those clients in turn could have clients of their own, typically all hosts of the same architecture within an administration.
Administration-specific configuration could have a slightly different distribution path in order to get to different arch sub-masters within an administration.
Often it is necessary for a software package to regularly run scripts on each machine to clean up, roll logs, issue reports, check for problems, etc. This is done without any human intervention by running each package's installation script at regular intervals and each time the package is distributed.
In addition a package may, in a standard location, supply entries for crontabs, inetd, boottime, and other such data that needs to be inserted into the local system files. These files have standard formats that don't necessarily match the specific formats required by any individual architecture. Similarly header files, libraries, and programs are all automatically linked into the standard system locations.
Xhier provided mechanisms that allowed multiple versions of a package to be installed on a machine. One version would be designated as the default, but users could easily access the other versions if they so wished.
Though not strictly part of xhier itself, several packages provided obviously needed services. In theory they could have been optionally replaced on individual administrations by other packages providing the same services in other ways.
In regions with multiple machines, all changes to the passwd and group files were made on one machine (typically the regional server), and the changes distributed to the other machines in the region (with possible architecture-specific changes being made to the data).
A central machine provides user account configuration for all machines within an administration, based on the sponsorship of resources requested by professors, department administrators, etc. This data is then compiled into lists of resources (userids, groups, disk quota) for each target region. The data is automatically sent to each regional server and the existing state updated to match the requests; quota and group memberships being adjusted, new accounts being created, and old ones expired as necessary.
This guarantees that for every machine, the accounts on it will exactly match what is configured on the accounts maintenance machine. And that machine contains information that explains exactly why users have the resources that they do. This ends the problem of maintaining accounts on individual machines, where the local administrator is often unsure about why an account is there or when it is safe to remove an account.
A package can gather accounting statistics on each individual machine (e.g. printing or CPU usage) and send them to the account maintenance machine in a standard format, regardless or each machine's architecture.
The central machine can combine these statistics with the account sponsorship data to produce usage statistics and billing information.
Xhier Overview — a more detailed explanation of the implementation.https://rbutterworth.nfshost.com/Reports/xhier/