How to keep Apache conf files in sync in web cluster

What's the best practice for keeping httpd.conf and php.ini files consistent across multiple web servers behind a load balancer?

I could periodically rsync the files, or program a custom deployment script. What other options am I missing?

From serverfault Andrew

• Our web nodes have an NFS cluster behind them. We symlink the default config file locations for both Apache and PHP to the shared copies on the the NFS share. A very simple shell script then does some basic housekeeping (rebuilding Apparmor rules, etc.) and then iterates over the web nodes triggering first an apache2ctl configtest and then apache2ctl graceful.

  Other ideas:

  1. Simple shell script wrapped around rsync or scp.
  2. For larger installations, a Puppet recipe could reliably deliver the updated config file and bounce Apache afterwards.
  From Insyte

• Ideally, you would set up configuration management server by using Puppet or other similar tools (for example cfengine).

  The best practice i could suggest with regard to server configuration in general is:

  "Never log into a machine to change anything on it. Always make the change on the [configuration management server] and let the change propagate out" (taken from http://www.infrastructures.org/papers/bootstrap/bootstrap.html)

  Best regards, Alex

  David Pashley : +1 everyone loves the puppet.

  pboin : +1 for mentioning the infrastructures paper -- the most profound admin paper I've read. ( Which is a lot. )
  From alemartini

• svn can be used to provide both version control and distribution of config files. git or bzr etc could also be used.

  edit the files on the 'master' server, svn commit them, and either a cron job or ssh can run then 'svn update' on the 'slave' servers.

  I tend to use ssh, and set up password-less access to allow the 'master' server to run a particular Makefile on the slaves - the Makefile runs 'svn update' and it's filestamp-based dependancy rules then decides what other things need to be done (e.g. generate hashed db user or group files from text, add or delete ip addresses from the nic, restart apache, and so on - any time when you can determine that a sequence of actions is dependant upon a file changing and/or another sequence of actions is a good candidate for using make to automate the process).

  even on the 'master' server, everything is driven by make. edit one or more config files, and then run make. the Makefile figures out what needs to be done (svn commit, generate config fragments from source input files, 'ssh make' to other servers, etc). using make like this ensures that every step is done in the correct order, and that no step is forgotten. and making svn an essential part of the process ensures that every change is committed with a time-stamp and an explanation in the commit log.

  of course, many would use puppet or something like it to do this. if i were to start over from scratch, i probably would too....but i've been doing it like this for years, long before puppet was around. there were similar tools around before puppet, but puppet is the first one i've seen that looks like it might actually be worth the trouble of changing...but it's hard to justify changing something that works well for something that only looks like it will probably work better.

  Badman : "I tend to use ssh, and set up password-less access to allow the 'master' server..." << IMHO, that does not sound like a very safe way of doing things.

  Craig Sanders : depends on how you set it up. you can set it up so that the ssh client can only run one particular thing, and nothing else.
  From Craig Sanders

• At the moment I have a script sitting on each web server that copies the configuration from a share and update's the configuration information to mach the local server (ip, etc). While this worked fine for 3 servers, at 10 servers it's annoying (login to server, run script, logout, rinse, wash, repeat). I'd suggest a solution (such a puppet and friends) that push the changes to server when you have completed your changes to the local file.

  From David

• There's several solutions.

  • Shared filesystem, like NFS or OCFS2.
  • Puppetmaster or equivalent configuration manager
  • Shell scripting a solution (equivalent to puppetmaster, but lightweight -- shell into server, update files, bounce apache)
  • With subversion, use a post-commit hook to do the above.
  • Manually doing the steps in the above shell script ... (here's your red stapler)

  The big question: How is your CONTENT (or the dynamic scripts that access your database for content) currently synchronized? If you think about it, config files are just another sort of content.

  From Karl Katzke