ISconf 4 is a complete rewrite. An alpha version is in production use in our own shop but not yet released to the public.

ISconf 4 is a tool designed to be used for deterministic, reproducible management of UNIX machines, the kind of rock-hard reproducibility you can count on for disaster recovery and auditability. It's not for use in environments where you want to still make manual or ad-hoc changes to machines at the same time.

ISconf 4 builds on lessons learned from the previous versions. ISconf versions 1-3 just sorta grew, based on practice in the field. Part of that practice was the use of 'make' as the state engine. We knew this restricted us in ways we didn't think were needed; it took a deep dive into basic CS theory to figure out what parts of 'make' needed to be brought forward into the new state engine -- surprisingly little. What we wound up with is a much simpler, provably deterministic algorithm which has already shown its worth and ease of use in practice.

Some of the major features that differentiate ISconf 4 from previous versions are:

• No gold server. You work from the command line of any representative target machine.
• No central repository. Packages and change orders are stored in a distributed cache, checksummed, replicated, and spread across all participating machines.
• No CVS server. See the previous point.
• No single point of failure. See above.
• Better workflow. No more futzing around with CVS checkins, rsync updates, or ssh'ing back to the gold server -- there isn't one. You log into one of the machines you want to change -- more of a natural sysadmin workflow.
• Easier to learn, easier to train. Works roughly like 'sudo', but queues what you do up for later release and execution on target machines. Works more the way a sysadmin thinks -- "I wanna run this command on a buncha machines" or "I wanna drop this file onto a buncha machines". The difference is that those events will also be executed in the same order on machines you have yet to build, without any additional effort on your part.
• Lightweight classing; less tedious editing of configuration files to create a new class. Classes of machines can be forked with a single command. (Merges are slightly harder, and still involve use of your own gray matter, followed by testing.)
• More granular control of flow of changes from test to production machines. Machines of different roles can be mixed and matched in the same infrastructure without restriction -- test and production machines can be deployed and intermixed regardless of DNS domain, for instance. Any production machine can be declared a test machine, taken out of service, changes applied and tested, and then those same changes applied to all similar production machines on an on-demand basis.
• Cheaper test environment -- because any machine or group of machines capable of being temporarily taken out of service can be used for testing as needed, there's less of a need for a dedicated set of hardware. Depending on your environment you may even be able to get away with N+1 machines rather than N+1 sites.
• No more puzzles. With previous versions of ISconf it was possible to create bizarre and irreproducible behavior in your infrastructure, usually by abusing makefiles -- editing old makefile stanzas that had already been deployed was one of the easiest ways ("editing history"). Others include getting too cute with dependency trees or default rules. Since we aren't using 'make', makefiles, or anything like them any more, this all goes away.
• Works better with typical IT shops. The person driving no longer needs to be as much of a developer, doesn't need to write much, if any, code, and doesn't need to know as much of how the tool works internally in order to avoid hidden pitfalls. Of course this point isn't proven yet, and won't be until we have a public release.