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?
Server Fault is a question and answer site for system and network administrators. It only takes a minute to sign up.Sign up to join this community
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
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
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.
There's several solutions.
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.
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.