active: Host is `live' and in a state in which the ARK machinery can be used to invoke methods on it.
pending: Host is not yet fully active, but will be soon. future. It is in the process of being installed, and while it is not in a state in which methods can be run on it, it should have config files generated for it, and added to relevant access control lists etc.
external: Host is not in the ARK system at all (no methods to run). We keep a little information about it in ARK land, and can access that if we try hard.
deprecated: Host was once active, and might even still be up, but it's on its way out.
historical: Host is not in use at all. We may be retaining its records for historical purposes.

`host/ALL.xml` for a team

Your team's host/ALL.xml file provides information that is common to all of the hosts at your site. (We assume, of course, that all of your hosts have ALL as one of their prototypes.)

In the future, much/all of this file may be generated; still, the understanding required is the same :-)

This example is a cut-down version of the `glasli1' host/ALL.xml file.

The preliminaries should come as no surprise:

<host name="ALL" xml-version="1" prototype="yes">
<description>
Any host at all at glasli1
</description>
<prototypes>
  <prototype team="sidai" name="ALL" />
</prototypes>

Here's some common information which is used in a Sidai-style `net-config' package. (You don't need it unless you're going to do something `net-config'-like.)

<domainname>dcs.gla.ac.uk</domainname>

<gateway>130.209.240.48</gateway>

<name-servers><list>
  <item>130.209.240.49</item>
  <item>130.209.240.50</item>
</list></name-servers>

The huge bulk of host/ALL is taken up with saying where programs can be found. The main reason is that, in Sidai scripting, we always try to invoke programs by their absolute pathname, and not rely on their appearance/order in a PATH.

This entry for ARK (for command-line invocation of the ARK engine) is typical. A <string> says where the program is -- often using team.xml `macros' -- and an optional constraint records the package it depends on. (`optional' means the constraint is only checked if you do --use-deps=max.)

<ARK>
<string>@team:ark-dirs:OUR@/bin/ark</string>
</ARK>

When we are running ARK methods' code, we don't leave the PATH to chance; ARK-BUILDING-PATH is what we use.

<ARK-BUILDING-PATH>
<string>@team:ark-dirs:LOCAL@/bin:/usr/bin:/usr/sbin:@team:ark-dirs:OUR@/bin</string>
<comment>
ARK_BUILDING_PATH is best if minimal.  We include ...
* @team:ark-dirs:LOCAL@/bin, because it includes our up-to-date Perl5 and Python
  binaries.  Expect trouble if those aren't in the ARK_BUILDING_PATH
* /usr/ccs/bin, because that's where Sun's `make' is
* /sbin:/usr/sbin, because you never know what bizarre configure script
  is going to want something from it/them
* @team:ark-dirs:OUR@/bin, because it includes our GCC; various configure-y
  tools love to just run it out of the blue, so...  We put it near the end
  so that configuring that snoops around for random tools, e.g.,
  perl looking for egrep, will find the std one, not @team:ark-dirs:OUR@'s.
</comment>
</ARK-BUILDING-PATH>

Here is a very typical entry for a program installed from outside:

<BUNZIP2>
<string>@team:ark-dirs:OUR@/bin/bunzip2</string>
<constraint><dependency type="optional" name="bzip2" /></constraint>
</BUNZIP2>

A rather involved thing is specifying our C (<CC>) and C++ (<CXX>) compilers, and the default flags we want to throw at them (<CFLAGS>, etc.). Sidai recommends GCC but, hey, it's a free country. Individual packages can (of course) override this information.

(For the -BOOT stuff, see the LNDIR entry just below.)

<CC>
<string>@team:ark-dirs:OUR@/bin/gcc</string>
</CC>

<CC-BOOT>/our/bin/gcc</CC-BOOT>

<CFLAGS>-O2</CFLAGS>

<CFLAGS-BOOT>-O2</CFLAGS-BOOT>

<CPPFLAGS></CPPFLAGS>

<CPPFLAGS-BOOT></CPPFLAGS-BOOT>

<CXX>
<string>@team:ark-dirs:OUR@/bin/g++</string>
</CXX>

<CXXFLAGS>-O2</CXXFLAGS>

<CXXFLAGS-BOOT>-O2</CXXFLAGS-BOOT>

<!-- was: /our/swdevp/bin/gcc; but for rebuilding we use the normal one now -->
<CXX-BOOT>/our/bin/g++</CXX-BOOT>

Sometimes, we want to say, ``Use the standard vendor-supplied program''; here's an example. Another reasonable choice would be ``use GNU Find everywhere'', in which case your <FIND> entry would look much like the <BUNZIP2> entry above.

<FIND>/usr/bin/find</FIND>

This entry for <LNDIR> -- a program that makes symlink farms -- demonstrates the -BOOT thing: typically, when ARK is looking for a program, it tries the main entry (<LNDIR> in this case); if it doesn't exist, it then tries the -BOOT entry (here, <LNDIR-BOOT>).

You'll be unsurprised to learn that the -BOOT entries feature most prominently when trying to boot ARK at a site.

<LNDIR>
<string>@team:ark-dirs:OUR@/bin/lndir -ignorelinks</string>
<comment>
NB: we need the -ignorelinks to avoid the symlinks in
$PKG_PROTO_HOST (which point to the symlinks in ../src, which point
to the real source) from being short-circuited
</comment>
</LNDIR>

<LNDIR-BOOT>@team:ark-dirs:ARK_SRC@/sidai/ark-prereq-utils/lndir.sh</LNDIR-BOOT>
</host>

Sidai team: how it manages hosts

Hosts, proxy hosts, and method granularity

A host's status field

host/ALL.xml for a team

`host/ALL.xml` for a team