This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these messages) This article includes a list of references, related reading, or external links, but its sources remain unclear because it lacks inline citations. Please help improve this article by introducing more precise citations. (July 2019) (Learn how and when to remove this message) This article needs more citations. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "ISconf" – news · newspapers · books · scholar · JSTOR (July 2019) (Learn how and when to remove this message) (Learn how and when to remove this message)

In computing, ISconf is a software tool to manage a network of servers.

ISconf operates on a pull model, meaning even servers that are not up when a change is made will receive the change once they come back up. As of version 4, ISconf requires no central server, though it does expect all servers to start identically, which is easiest to accomplish using some form of automated install which may require a central server.

ISconf comes from the "InfraStructure administration" movement which created and defined most of the OS-side backgrounds (in theory terms) of what is now making up the DevOps sphere. It is based on the idea that the best way to keep servers from diverging is to apply the same set of operations in the same order.

This is in contrast to the "convergence" theory of system automation, which attempts to "converge" servers to known states from arbitrary states using sets of rules such as "if a package outside of this set is installed, uninstall it", "if package X is not installed, install it", or "if daemon X is not running, start it". According to Steve Traugott, there is no way to guarantee that a given set of rules will actually be able to converge from any given state.

ISconf enforces the order of operations by assuming only commands issued through it change the state of the system. As a result, if a package or file is installed on a system manually, it will stay there, which may eventually cause problems such as version conflicts. ISconf is targeted at environments where configurations must remain identical. In such environments, it is typical to give only a few systems administrators root access to hosts. This minimizes the risk of manual changes because it is easy to train a small group of people to only make changes through ISconf.

ISconf was inspired by, and originally implemented as, Makefiles. However, Makefiles specify dependencies and not a total ordering of operations. ISconf version 1 dealt with this by making each operation dependent on the previous one, but this was tedious and poorly suited to Make. More recent versions of ISconf use a simple append-only journal.

The major version in common use apparently were ISconf2 and ISconf3, while ISconf4 stayed in a very long beta period. It had in fact been finished and put to use in larger environments but due to the delay saw limited community adoption.

• ISconf 1 (Makefiles)
• ISconf 2 (early 200x?) written by Steve Traugott
• ISconf 3 (2002) was a rewrite of version 2 by Luke Kanies.
• ISconf 4 was mostly written by the original author, Steve Traugott.

Luke Kanies later switched to CFengine2, until finally authored and released Puppet. As a result, one could consider ISconf an ancestor of Puppet, though both CFengine and Puppet implement the "convergence" model of configuration management, essentially the opposite of the "order of operations" model implemented by at least ISconf versions 1, 2, and 4.

• Comparison of open source configuration management software

• ISconf's web site
• Bootstrapping an Infrastructure, Steve Traugott and Joel Huddleston's LISA '98 paper about the ideas that led to ISconf (pre-dates ISconf itself)
• Lukes description of ISconf 3 theoretical background and goals
• Theory section and mailing list archives for system management automation
• Github Repository for ISconf4