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
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.
On Mon, Sep 14, 2009 at 12:11 PM, Karanbir Singh mail-lists@karan.org 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 second that. All the listed options are great. If you want to manage configurations on a server, use something designed for configuration management. Using RPM to manage configs will probably leave you with halfway broken machines and no clue about what we wrong.
-jonathan
Alan,
FYI last year, I tried bcfg on Centos5.1 but it was difficult to get things working. With Puppet things could work, not easily but it allowed rollback using CVS and ensuring that common config files are always applied to all machines.
Quoting Karanbir Singh mail-lists@karan.org:
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@icq _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
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@rossberry.com 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
Hi,
On Mon, Sep 14, 2009 at 12:35, Alan McKay alan.mckay@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
On 9/14/09 11:14 AM, "Filipe Brandenburger" filbranden@gmail.com wrote:
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.
This is what I do using the Slack configuration tool that uses an SVN repo checkout on the "slackmaster" which is contacted by the client to determine what roles the machine is registered as. Simple and easy to setup, however, if I had more time, I'd likely move completely over to using Puppet.
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
-
Alan McKay -
Filipe Brandenburger -
Gary Greene -
Jim Wildman -
Jonathan Moore -
Karanbir Singh -
nate -
nicholas＠oscc.org.my