Some packages should be revealed on a subset of all hosts. Prototype hosts help manage which packages go where. This document describes the steps needed to implement a prototype host.

Motivation

Packages like web servers and backup servers should be installed only on hosts providing those services. Installation details and excutable code will vary with hardware platform and operating system.

The Arusha Project's prototype hosts provide a mechanism for controlling which packages go where and managing the many details of installation. See Deep Coolness for a vision of how this could work.

Naming

Blessed Names provides guidance on prototype host naming. Summarizing,

Names don't matter to a computer, but they help people understand.
The favored name format is: hardware-os-function. For example, the name for a web server running under Solaris 2.8 on a Sparc platform could be named sparc-solaris2.8-web-server. A web server, perhaps written in Python, that did not depend on a platform or operating system could be named web-server.

Although this naming scheme can lead to complex ontologies, most real problems require only a few prototype hosts. Keep things simple; don't introduce unneeded levels anticipating some future requirement.

For example, consider these names for web server prototype hosts:

.:granite   .:quartz    .:feldspar
     |           |            |
     --------------------------
                 |
     sparc-solaris2.8-web-server
                 |
       sparc-solaris-web-server
                 |
          solaris-web-server
                 |
             web-server

In this example, granite, quartz, and feldspar are hosts that will run web servers. All three hosts run Solaris 2.8 on Sparc hardware. If these are the only web servers at your site, defining sparc-solaris2.8-web-server will suffice. Later, when your site grows to include Intel hardware running Linux or Solaris, more prototype hosts can be added.

Protoype host setup

A brief XML file suffices for most prototype hosts. For example:

<host name="sparc-solaris2.8-web-server" xml-version="1" prototype="yes">
  <description>
    <doc>A web server running under Solaris 2.8 on Sparc hardware.</doc>
  </description>
</host>

Real host setup

Add the prototype host to the list of prototypes for each real host that needs the package. For example:

<host name="granite" xml-version="1">
  <status>active</status>
	<prototypes>
	  <prototype team="." name="sparc-solaris2.8-web-server">
	  <prototype team="." name="sparc-solaris7" />
	  <prototype team="." name="sun-netra-t1" />
	</prototypes>
	...
</host>

Package setup

Add the prototype host to the list of supported hosts for each package needed. For example:

<package name="apache--1.3.27" xml-version="1">
  <status>revealed</status>
	
  <prototypes>
	  <prototype team="sidai" name="apache.xml" />
		<prototype team="." name="ALL" />
	<prototypes>
	
	<hosts-supported><list>
	  <item>sparc-solaris2.8-web-server</item>
	</list></hosts-supported>
</package>

Package ALL setup

Edit your team's package/ALL.xml file to specify a proxy host and install directory for the prototype host.

At some sites, the gold server is the proxy host for everything. That may not be possible (with mixed platforms) or desireable (e.g., for licensing reasons). Beware of this trap: best practice prohibits C compilers from hosts running web servers, but the proxy host tries to compile and run a web server.

Add a line to the proxy hosts table in package/ALL.xml:

<proxy-hosts><table>
  <entry name="ALL">gold</entry>
  <entry name="sparc-solaris">gold/entry>
  <entry name="sparc-solaris2.8-web-server">granite</entry>
	...
</table></proxy-hosts>

Add a line to the packages install directory table to specify where to intall packages. A good choice is a directory near the existing install directories. For example, if the Sparc Solaris 8 packages are installed in /sys/.-ark-install-sparc-solaris8, then the Sparc Solaris 8 web server packages could be installed in /sys/.-ark-install-sparc-solaris8-web-server.

<packages-install-dir><table>
  <entry name="ALL">/sys/.-ark-install-ALL</entry>
  <entry name="sparc-solaris8">/sys/.-ark-install-sparc-solaris8</entry>
  <entry name="sparc-solaris8-web-server">/sys/.-ark-install-sparc-solaris8-web-server</entry>
	...
</table></packages-install-dir>

Remember to create this directory with the usual owner, group, and permissions. Consider adding this directory to site setup scripts (see Setting up site-wide ARK dirs, for example).

Dchunk setup

In your team's dchunk directory, add a dchunk description XML file for the install directory specified above. If you are simply adding another sys directory in the usual place, this will suffice:

<dchunk name="sys-ark-install-sparc-solaris8-web-server" xml-version="2">
  <status>active</status>
	<prototypes>
	  <prototype team="." name="sys-ALL" />
	</prototypes>
	
	<master-copy>
	  <param name="what"> .-ark-install-sparc-solaris8-web-server </param>
	</master-copy>
</dchunk>

This new dchunk may need to be exported. The etc-exports package handles this. For example, if the dchunk is hosted on the gold server:

gold% cd /workspace/arusha/sidai/package-utils
gold% ark-invasive --hosts=gold etc-exports
[Consider the diff results presented and, if satisfied, run:]
gold% ark package reveal --hosts=gold etc-exports

Automounter maps also must be updated on all hosts. The automount-maps package handles this:

gold% cd /workspace/arusha/sidai/package-utils
gold% ark-invasive --hosts=ALL automount-maps
[Consider the diff results presented and, if satisfied, run:]
gold% ark package reveal --hosts=ALL automount-maps