On 11/04/2009 04:35 PM, Les Mikesell wrote: > What good is a configuration tool if it can't handle a change in NIC > setup? That's really about the only thing that is enough trouble to do > manually that it is worth more automation than a shell loop of ssh commands. I am not sure how you got from one place to another. Essentially any config tool is able to handle network setups, including stuff like bonding and HA. Think of it like this - if you can do it by hand, you can plumb in the knowledge the system needs to make those decisions for you. > Exactly - and remote 'hands on' support generally won't know which NIC > is which, making this fairly problematic. And you can't just clone > setups because the copies won't work with different MAC addresses. I personally think that cloning is for people who dont know what they are doing. Bare metal install and provision into a role with even a moderately usable app deployment strategy, cap'd with a monitoring system that actually know what it needs to do - will easily be more friendly than any form of cloning. > I'm not sure I agree with that. I really do want to know about > platform/state history even if I can't roll it back. well, most people replace or upgrade the platform ( hardware ) when things break, so rolling back is sort of academic in this sense. You are much better off storing platform inventory in something like ocs / glpi / spacewalk ( or even doing things like getting sosreport to give you the right foo, checking that into a local vcs - so you can 'track' a system's evolution ) > For example, if > someone changes the duplex setting on a NIC to match a switch I'd like > to have the change recorded - and a way to look at how that machine is > different from both the way it was at some other time and from other > similar machines. how do you mean 'changes' ? I highly recommend there be no way for people to get onto the machine unless in an emergency. So no ssh as an example. That sort of ensures that policy changes like this, need to go via the management system - leaving you a nice audit trail. Addition of a 'SSH box', needing people to contribute $5 everytime they get onto ssh, also helps get people into the right mindset :) > Also, we almost never roll out a change across all machines in a group > at the same time but instead closely schedule individual machines or > small sets. puppet, atleast, makes this sort of a thing trivial - since you can setup environments, and then nominate machines to join different environments on demand. It also make it possible for one to have code-like release and deployment cycles. You could potentially even have various test and/or wrap some of the policy in tests with rollback capabilities ( I tend to do that for my ssh and puppet configs - configs for puppet itself that is ). -- Karanbir Singh London, UK | http://www.karan.org/ | twitter.com/kbsingh ICQ: 2522219 | Yahoo IM: z00dax | Gtalk: z00dax GnuPG Key : http://www.karan.org/publickey.asc