The Beginnings of Infrastructure Management

1. With that kind of platform heterogeneity, you should check out Puppet (http://reductivelabs.com/trac/puppet). It has builtin support for package management, plus users, groups, filesystem mounts, and quite a bit more.

   Its language is both more flexible and more consistent than cfengine’s, which isn’t surprising since it was based on years of consulting and development with cfengine, and I was the author of ISconf 3, so I’m very familiar with that tech, too.

2. I may yet try out Puppet. I partially went with cfengine because I assumed it would be easier to bootstrap into Solaris, but honestly, it’ll be a while before I migrate the Solaris systems into the infrastructure.

   Part of my overall strategy is to reduce the amount of data stored on the local systems as much as possible, e.g., using LDAP and Active Directory for usernames and passwords.

   If cfengine ends up offending my aesthetic or productivity senses too much, I expect puppet’s going to be the next thing I try.

   UPDATE (2007/05/02): I’m now leaning more toward Puppet. First, I’m embarrassed at how easy it appears to be to bootstrap it into Solaris. Second, I’m still in the “editfiles considered harmful” camp, and most of the examples I found led me to believe that Puppet wouldn’t serve out config files as-is, and I’d be required to put all my configuration files in Ruby template form and let Puppet parse them. It appears that the centralized sudoers recipe proves that assumption wrong, too. I don’t have a ton of time invested in cfengine yet, so I could switch without much loss of effort.

Comments are closed.