[CentOS] LF examples - using site-specific RPMs for config

[Filipe Brandenburger]

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