ISconf is a framework for recording and playing back all sysadmin work done to a network of Unix machines. Its functionality is dependent on three key features:
Because make is the only tool that fulfills all of these requirements in its default state, it was chosen as the basis for ISconf. Although I am not familiar with Version 1 of ISconf, it is assumed that make was the heart of Version 1, and all other tools descended from it.One thing make could not easily do was associate metadata, such as the filesystem sizes, with the hosts being managed. Version 2 of ISconf was born in an attempt to satisfy this need, and implemented a hosts config file for maintaining the list of host, host types, and host metadata, and this config file then became responsible for the deterministic ordering requirement. Make was still used as the state engine and for failure-on-error.
Unfortunately, because of the way that Version 2 dealt with host types, maintaining deterministic ordering was left up to policy rather than the toolset, and in fact the hard line of deterministic ordering usually had to bow to functionality.
Version 3 was developed mostly in an attempt to correct this problem, but at the same time a better host typing system was implemented, the ISconf script and parsing engine were rewritten in perl instead of sh, host types and host instances were separated into respective files, and checksums were added to the files to prevent average users from trying to break the ordering rules. Thus this new code took over the responsibility for deterministic ordering, again leaving responsibility for the state engine and failure-on-error to make, although some experiments were done to replace make entirely.
Important functionality missing from Version 2 was also added to Version 3, specifically a tool for managing the download and syncing of files (fileset), a tool for correcting permissions on files (modechk), and a tool for performing necessary actions when files change (trigger).
In addition to the programmatic changes in Version 3, attempts have been to separate the code (such as the code for installing packages) from the data (which specific package to install, for instance) within the make files. These attempts have been mostly experimental, towards deciding future developmental direction, but have helped make strides in code reuse and code/data separation.
Version 4 is still on the drawing board, but here is a short list of features one might expect to see in it:
[an error occurred while processing this directive]