An example rollout of SteamWorks, where configuration information is primed in Crank components.

This site reflects work in progress.

In a factory driven by a steam engine, the Crank transmits the piston's linear movements into the rotary fashion of movement that is fit for distribution throughout the factory.

Likewise, the Crank program drives the change-of-mind of an operator in terms of configuration data into the SteamWorks; it is the frontend portion of the configuration information distribution network.

Read the specification for this tool (written in preparation of coding)

Read the man page for this tool (written in preparation of coding)

The purpose of the Crank is to enter configuration data, and present it to the rest of the SteamWorks. It is what would be called a "console" or "graphical interface" in other tools. Although the Crank could be operated as a remotely offered service or for site-local overrides, it is always a source of configuration data, and therefore operates independently of the rest of the SteamWorks, processing only its own data set.

The control of configuration data setup in the Crank can be segmented between any number of administrators. Each would be able to modify only those portions of data, or only those actions that were entrusted to them.

The visibility of configuration data setup in the Crank can also be segmented, to support access to certain portions to certain users only; the same mechanism may also be attached to the Shaft, to cover the case where this component collects information before it crosses over to other sites.

The structures supported for configuration data must minimally adhere to the LDAP definitions for object types and attribute types; however, to enhance this syntactical check with more semantics, plugins may perform checks on the entered configuration data to ensure that it will not break a currently working configuration.

The Crank processes changes as transactions that can span multiple LDAP objects. This is desirable to introduce larger changes in one stroke. Only when no structural problems exist, including semantical checks performed by plugins, can a transaction succeed. It may be rolled back at any time to revert to the situation before the transaction was created.

Note that the transactions are local to the Crank; they explicitly do not span the other SteamWorks components, so the actual setup of services may still differ slightly in their timing; however, the reliance on LDAP Sync makes it quite likely that no human would notice anything. This is a very deliberate pragmatic choice in light of the complexity of cross-site transactions and the general incompatibility of both LDAP and the majority of Machines (configured programs) with a transactionally updated configuration.