An example rollout of SteamWorks, with Pulley to configure programs (or "Machines").

This site reflects work in progress.

In a factory driven by a steam engine, the Pulley usually carries rotary motion from a factory-wide shaft over to mechanical machinery.

Likewise, the Pulley program retrieves configuration information from LDAP, using LDAP Sync to follow the motion, and it presents the configuration information to local programs. In effect, Pulley enhances local programs with an LDAP facility, in a less problematic manner than integrating LDAP in each of those programs.

Read the intuition behind this tool (written in preparation of coding)

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

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

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

Various programs support LDAP as a source of configuration data and, more commonly, account information and access control lists. These programs need an LDAP server to always be online, or otherwise they cannot perform their function. Another potential problem is that configuration and access control may concentrate on one site, which is especially problematic when complex group queries are needed to decide on privileges.

Although this approach works for some programs, not all do actually support LDAP, not all support the various schemes in existence and the ability to access LDAP itself may be authenticated in various ways, and a diversity of programs doing this leads to a choice for a common-least-denominator of security. Probably a password stored in the memory space of the program, together with all its application frivolities.

The approach with the Pulley program is to ignore any LDAP support that a program may or may not have, and instead provide it with some configuration that it supports, be it a DBM-database, a configuration file or any other local mechanism. The Pulley queries LDAP, reshuffles its findings, and outputs the format to a (generic) plugin that delivers it in the preferred local configuration format. As a result, the local program has a local copy of all configuration information in LDAP, precalculated to avoid dealys, and without being dependent on a live connection to an LDAP directory service.

But Pulley is not just a fetcher of configuration information; it derives its name from acting like the Pulley in a factory run by a steam engine; it connects to the centrally driven Shaft over which configuration information updates are relayed. This is done using the LDAP Sync mechanism specified in RFC 4533. Briefly put, a query submitted under LDAP Sync is processed like a normal query, but it also asks the server to keep me informed about any future changes in the query outcome so after initialising the connection it turns into a change subscription. And even initialisation need not start at zero; Pulley and the LDAP server may use LDAP Sync to define a marker point from which to continue a prior conversation.

To support scaling up to large data sets, Pulley is designed to suppressing repeated information; it implements the principle of idempotence for configuration information: No use saying things twice; adding something once is enough, and removing something once is, too, as long as the order of changes does not get switched. The things that do actually change are restructured to meet the local programs' needs and put into formats suitable for them.