I have argued here and elsewhere that automated CM tools should adopt a truly stateful approach in which the administrator defines what system objects (packages, files, users, processes, etc.) he wants on the system and the CM tool ensures that that state is achieved and maintained. This solves a problem I have already started to see on my own systems: dead objects. Dead objects are obsolete or no longer needed and they tend to accumulate.
The way the CM tools usually work now (Puppet’s purge command is an exception) is that you specify deltas, what objects to add or remove. Over time it is easy to lose track of what objects are no longer needed. Current CM tools put the burden of tracking these objects on the administrator. Dead objects can cause problems, perhaps even big problems.
In 2012 the trading company Knight Capital lost $460 million dollars due to, among other things, dead objects. According to this analysis Knight Capital’s administrators left old versions of their software on their servers and accidentally activated one of the old programs. This is an extreme case but illustrates a potential problem with a non-stateful approach.
The cost of a stateful approach is a higher up-front investment in time. Administrators would have to fully document the desired state of their systems. The benefit is increased security and audit-ability. Because the CM tool is managing the state it eliminates the class of potential problems that result from having to manually identify which objects must be removed after a change. Let the administrator decide how the system should look and let the CM tool figure out how to implement it.