An example rollout of SteamWorks, passing configuration data across sites.

This site reflects work in progress.

In past times, a single steam engine would drive a complete factory. An overhead Shaft would transport a rotary motion throughout the factory. The steam engine drove this Shaft through a Crank and individual machines would pickup the movement with a Pulley and locally deliver the rotary energy.

Likewise, the SteamWorks represent a number of programs that co-operate to transmit more-or-less centrally controlled configuration settings over a network, and make it available to individual programs. Updates are passed around instantaneously when network connections are good, but the last version of the information can be used when the network temporarily degrades.

Why do we think SteamWorks are useful?

Computer systems nowadays are entangled with networks, and a simpe server may in fact depend on other systems to be online to be able to fulfil its services. This constitutes a degree of fragility that is not always desirable; for instance, where security policies or system access is concerned. To make things worse, there is a growing tendency to combine information sources from various parties, and crossing the technical and political boundaries of organisations can introduce many new issues that complicate normal system management.

So what we need is a system that can share (configuration) information across such parties, and reduce their cross-dependency. This is where SteamWorks steps in; it enables a central site to configure settings for a large conglomeration or a distributed enterpreise, and each of the sites can clone this information and spread it internally. Updates are automatically spread out as soon as possible, but in case of network failure the old information is retained and used until the downtime is resolved.

How are the SteamWorks constructed?

The SteamWorks are made from three programmatic components, which connect through LDAP, and more specifically the SyncRepl specification from RFC 4533:

  • Crank is where changes of mind regarding configurations are entered; these points act as primary servers for the configuration information to be spread. Focus points are user interface, and access control.
  • Shaft is the mechanism that passes information between locations, and creates a local buffer. Such buffers help to retain local consistency in case of network failures. Inputs are taken from Crank and Shaft components, several of which may be combined.
  • Pulley is the receiving endpoint of LDAP configuration information; rather than having each application pulling this information live, the intention of Pulley is to pull information from the Shaft as it is provided, and retain a local copy ready for instant use. The local copy may well be formatted in special ways for specific programs; such programs need not be aware of LDAP and could only support local configuration formats.
  • Machine is at the bottom of the configuration chain, it is an individual program being configured in any way needed. Machines are provided for by Pulley components; they are not considered part of the SteamWorks.

Who is working on the SteamWorks?

SteamWorks is a project run by OpenFortress and NLnet as part of the InternetWide project. Its practical project is hosted as an ARPA2.net project.