On Mon, 14 Sep 2009, Karanbir Singh wrote:
> On 09/14/2009 05:35 PM, Alan McKay wrote:
>> A week or two ago someone mentioned something about using their own
>> home-grown RPMs for managing config info on their boxes.
>
> this is a really really bad idea. I'd suggest you dont waste your time
> around this and instead work with projects like chef / puppet / bcfg2
> and look at those to manage what they do - config and state.
>
I'm going to take a different tack than the others. This _may_ be a
good idea, depending on your situation. We have been using it very
effectively for delivering a tightly controlled set of configs during
the build process. Puppet/cfengine etc are out because we are not
allowed to leave a process running on the server after install (we don't
manage the boxes, we just design the build). The 'customers' each have
their own system management ideas...
Additionally, by using rpms we can nonintrusively and quickly determine
what a system that has been 'out in the wild' started as (via the rpm
versions), what has been changed (via rpm -V) and whether the content is
ours (via the signing key), without installing an agent, etc. We can
also add our content to servers that are 'forklifted' into the
environment very quickly (yum -c http://patth_to_repo_file install
master_rpm). As someone else pointed out, we have to do some extra work
to detect whether we are running at build time, as an install, or as an
upgrade, but we have that figured out for our environment and stashed
into our spec file templates.
In an environment where I had to manage the servers as well, then puppet
or cfengine or Red Hat Satellite/Spacewalk, etc, etc would definitely be
in the mix.
----------------------------------------------------------------------
Jim Wildman, CISSP, RHCE jim@xxxxxxxxxxxxx http://www.rossberry.com
"Society in every state is a blessing, but Government, even in its best
state, is a necessary evil; in its worst state, an intolerable one."
Thomas Paine
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
