CentOS - Sep 2009 - LF examples - using site-specific RPMs for config

Hey folks,

A week or two ago someone mentioned something about using their own
home-grown RPMs for managing config info on their boxes.

I really like this idea and would like to learn more about it.  Are
there some examples out there?

I have lots of custom config info and think this would be an ideal way
to manage it.   Others mentioned puppet and CF engine which probably
have their merits as well.  But I don't really have time at the moment
to learn those.   Perhaps in this thread we could even discuss the +/-
of each method.

cheers,
-Alan

-- 
?Don't eat anything you've ever seen advertised on TV?
         - Michael Pollan, author of "In Defense of Food"

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.

-- 
Karanbir Singh : http://www.karan.org/  : 2522219 at icq

------Mensaje original------
De: Karanbir Singh
Remitente: centos-bounces at centos.org
Para: CentOS mailing list
Responder a: CentOS mailing list
Asunto: Re: [CentOS] LF examples - using site-specific RPMs for config
Enviado: 14 Sep, 2009 12:11

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.

-- 
Karanbir Singh : http://www.karan.org/  : 2522219 at icq
_______________________________________________
CentOS mailing list
CentOS at centos.org
http://lists.centos.org/mailman/listinfo/centos


Enviado desde mi oficina m?vil BlackBerry? de Telcel

Hi,

On Mon, Sep 14, 2009 at 12:35, Alan McKay <alan.mckay at gmail.com>
wrote:
> A week or two ago someone mentioned something about using their own
> home-grown RPMs for managing config info on their boxes.
I believe you are referring to my suggestion on a thread discussing
creating scripts on the %post section of a kickstart.

The suggestion was to use RPMs to manage *scripts* that are deployed
to multiple machines, since if you create them from a kickstart it
will not be very manageable and if you need to update one of the
scripts it will become a mess quite quickly...

The only way you can manage config files (for other packages) with a
home-built RPM is by scripting the changes in the %post section of the
RPM (since you do *not* want your package to own config files of other
packages), but that is quite tricky because you want that to work in
updates, so you want all your changes to be idempotent if they're not
already there. It means, if you are appending to a config file, you
must test (with grep?) if you have appended that line before, and only
append it if you still did not do it. Other changes can be done with
"ex" which accepts vi-like s///, but it really gets tricky quite
easily.

The nice side of having home-built RPMs is that you can list all the
other packages you need as dependencies of your RPM, so for instance
you may have a "my-webserver.rpm" package that has as dependencies
Apache, PHP, etc., and then you can use one short yum command to turn
that machine into a webserver. That way, you don't need to work with
hundreds of slightly different kickstarts that install machines with
different purposes, you only need a couple (mostly for different
hardware) and one a machine is installed you only log in to it and use
a short yum command to get it up and running with whatever you need
the machine to do.
> I have lots of custom config info and think this would be an ideal way
> to manage it.
Not really, since RPM is good for managing software and not managing
config files. What it does well in terms of config files is saying
which config file belongs to which package, whether it was updated
from the default one provided by the package, and whether it should be
replaced when you install a new version of that package. Managing your
custom config files for multiple machines in RPMs is not a good idea.
> Others mentioned puppet and CF engine which probably
> have their merits as well. ?But I don't really have time at the moment
> to learn those. ? Perhaps in this thread we could even discuss the +/-
> of each method.
Well, those are certainly the best tools to manage config files.

Another alternative would be setting up an rsync server from where you
download your config files to all servers, that way you edit once and
copy them everywhere you need them, but that is certainly more manual
than what puppet can do.

HTH,
Filipe

Alan McKay wrote:
> I have lots of custom config info and think this would be an ideal way
> to manage it.   Others mentioned puppet and CF engine which probably
> have their merits as well.  But I don't really have time at the moment
> to learn those.   Perhaps in this thread we could even discuss the +/-
> of each method.
It depends on the scale your working on, as others mentioned it's a
bad idea to use RPM to manage config files.

At the most simple level you could store your config files in a
central location and use rsync over ssh or scp to copy them to
your various servers using key-based authentication.

For my own systems(about half a dozen) I manage them by hand,
they all run Debian. Not much time is spent.

For my work systems(about 350 or so), I use a combination of
kickstart for the initial installation and installation of some
core services, and cfengine for the rest.

CFengine parses the host names of the systems and dynamically adds
most servers to all of the "classes" that they need to be in to
function, this works for about 99% of the systems out there, the
rest have one-off type configurations so need to be manually
added into a cfengine class(text file).

Each major class has a config file associated with it, which
includes everything for that class, whether it is config files,
or RPMs etc. The agent runs hourly and checks/applies the configs
or packages that is not present. CFengine(unlike puppet I believe)
doesn't have fancy dependency handling so initially we need to
either force run it 3 times, or let it run by itself 3 times in
order to get everything it needs.

There is one kickstart config per OS type:
centos 4.6 32-bit
centos 4.6 64-bit
centos 5.2 32-bit
centos 5.2 64-bit
fedora 8 32-bit (virtualized NTP services only)

everything in kickstart is as generic as possible.

nate