For the mod_perl apps I have worked on, we do something very similar.  We have a few apache 
config templates, the main one and separate ones for all of the vhosts (i.e. tenants); these
 files are set up with macro replacements in place:

   ex.  <VirtualHost  macro_APP_HOST:macro_APACHE_HTTP_PORT> 

And we have what we call "rules" files, that contain the macro substitutions for these:

   ex.    s|macro_APP_HOST|dev-03.yourcompany.com|g
          s|macro_APACHE_HTTP_PORT|8010|g

The rules are kept is separate files, one file per developer, one file for each QA environme
nt, and one file for production use.  They are just `sed` substitutions.  We just run the ru
les file once per deployment pretty much, and everything is set up for that environment.  Fo
r staging and production environments, we have n hosts in our server pools so we run a 2nd s
ubstitution command and the end of the rules, to make sure we have the right physical host n
ame where necessary.

We check in all conf and rules files, plus the scripts/tools used to do the macro substituti
ons into source control.  We have aliases set up to run these rule replacements, and then st
art up apache, etc.  We use file naming conventions like:

   _httpd.conf
   _somevhost.httpd.conf  (Included via the main httpd.conf)
   ...
   username.somedevhost.rules

When the substitution script runs, it will spit out the files:

   http.conf
   somevhost.httpd.conf
   ...

We found this to be the most straight-forward and simple approach for our needs.

Hope this helps,
- Jeff




----- Original Message ----
From: Mark Stosberg <mark@[...].com> 
To: modperl@[...].org
Sent: Fri, November 6, 2009 10:30:23 AM
Subject: Best Practices for managing repetitive Apache config file entries?


I'm working on a mod_perl project where we would like to implement to
Apache related goals:

1. Automate repetitive configurations. For developers, we repeat the
same configs with the only difference being the "~user" location. In
other cases, the differences are not far from s/alpha/beta. 

2. Put the Apache configurations under source control. Here the goal is
to tie changes to the Apache configs to other code changes in the
project.

Here's my outline for now we might do this. Are there other options
that work well for you?


1. We would be a template of Apache configs unders source control. 
2. When the template changes, we'll run a script to generate all the
sections. Apache would pull this in as an include file.

In the event a launch is rolled back, the template could reverted to an
older version, and the include-file could be regenerated from the older
version.

Sound reasonable? What else would you recommend?

    Mark



-- 
. . . . . . . . . . . . . . . . . . . . . . . . . . . 
   Mark Stosberg            Principal Developer  
  mark@[...].com     Summersault, LLC    
   765-939-9301 ext 202     database driven websites
. . . . . http://www.summersault.com/ . . . . . . . .