On Dec 4, 2006, at 1:50 PM, Michael Peters wrote:
Adam Prime x443 wrote:
I'm in the process of moving about a half a dozen domains to a
light/heavy setup with SSL being done on the light server and
proxied to
the backend on localhost. I've been trying to find a good way to
minimize the potential to have inconsistencies in the
configuration of
the front, SSL, and backend servers, and it seems like the most
obvious
way to do that would be to use a single configuration file, using
IfDefine's to specify what's supposed to be for who.
We actually take a different approach for this. We used a templated
configs
(HTML::Template, but Template Toolkit would work just fine too). We
have a
single source for the data (in our case another config file, but
you could
easily just use a DB) and 2 separate configs for the proxy and
application server.
The configurations between the 2 would be very different (SSL, IP
addresses,
Keep-Alive settings, mod_perl, etc) that it's just easy to keep
them separate.
Sometimes we use the same binary for each, just with different
configs.
In my setup i don't use apache for light, i use nginx, but its kind
of similar - as I use Adam's approach to standardize FreeBSD/Ubuntu/
OSX production and dev boxes, and run 3 different mod_perl servers on
the same box:
1- I created a custom apachectl and added an IfDefine for each os.
if you run on different os's, you need to do it as each system tends
to have 1 or 2 lines that are platform specific regarding memory of
file locking or something.
2- all my vhosts are stripped out of the main file and put into a
virtual_hosts directory
i keep all this stuff in subversion along with the application
for sanity sake, i hardcode all of the config files to be placed
in "/usr/apache_custom/appname" , then just symlink the app
directory to that spot
/usr/apache_custom/appname/conf
httpd.conf
virtual_hosts.dev
virtual_hosts.production
an ifDefine directives regarding a dev/production flag ( or in your
case front/back ) specifies which directory to include
now, that said... your system is crazy. its going to be a nightmare
to maintain.
since you've got a light/heavy setup, i think you REALLY REALLY
REALLY should be not only be using two seperate httpd.conf files ,
but also treating both servers as completely independant with their
own apachectls
i strongly suggest having
/usr/apache_custom/appname/sbin
customized apachectl - points to the pid + conf files
/usr/apache_custom/appname/var
customized pid and logs ?
why?
design wise, you've got 2 completely different services going on.
the light /ssl is a port 80 service. the other one is a port X
service. they're inter-related in this application, but you might
have other services that port80 needs to forward to at a different
point.
also, you're going to need to ifDefine the modules too. don't run
modperl but run ssl and proxy if we're the light server, do the
inverse if we're not.
it'll also simplify things for when you need to support some sort of
'downtime' message ( ie , restart either port 80 or modperl using a
different configuration file when you need to do server maintenance )
then to start/stop stuff its just
/usr/apache-custom/modperl_findmeon/sbin/apachectl -D
ApacheServerFreeBSD -k stop
/usr/apache-custom/modperl_findmeon/sbin/apachectl -D
ApacheServerFreeBSD -D DownTime -k start
/usr/apache-custom/modperl_findmeon/sbin/apachectl -D
ApacheServerFreeBSD -D DownTime -k stop
/usr/apache-custom/modperl_findmeon/sbin/apachectl -D
ApacheServerFreeBSD -k stop
looks like a lot of text... but you can just make shell scripts.
( actually, i remember that in that example i have a sep. production
and dev configuration tree, and just mount the appropriate one on /
usr/apache-custom ) in any event, it took 30 minutes to migrate my
system to this setup, and i now can manage all of my dev and
production machines with no issues.
// Jonathan Vanasco
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - -
| FindMeOn.com - The cure for Multiple Web Personality Disorder
| Web Identity Management and 3D Social Networking
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - -
| RoadSound.com - Tools For Bands, Stuff For Fans
| Collaborative Online Management And Syndication Tools
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - -
