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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
