Earlier in the week Reductive Labs became no more… But fear not the home of Puppet didn’t fade away but rather has been reborn as Puppet Labs. You can read more about the why here.

On Infrastructure There is one system, not a collection of systems. The desired state of the system should be a known quantity. The “known quantity” must be machine parseable. The actual state of the system must self-correct to the desired state. The only authoritative source for the actual state of the system is the system. The entire system must be deployable using source media and text files. On Buying Software Keep the components in the infrastructure simple so it will be better understood.

Over the last year or so a bunch of presumptuous European sysadmins and developers, joined by some of their American brethren and even a couple of us antipodeans (there are others too!) have been talking about a concept called DevOps. DevOps is the merger of the realms of development and operations (and if truth be told elements of product management, QA, and *winces* even sales should be thrown into the mix too).

In a recent post I talked about how easy it is to generate Puppet types and providers. In that post I used the example of a very simple Subversion and Git repository type, called repo. I’d like to show another example of a type and provider, this one used to manage the contents of the /etc/shells file. This type and provider makes use of some built-in Puppet functionality that allows the simple parsing of files and the management of their contents.

This is an excellent post on the phenomena of “help vampires” who suck up the support goodwill in communities. It tells you how to spot them, how to handle them and how to protect your community against them.