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