Considering using Perl Sections

A while back I realized the futility of using a single httpd.conf after
having many errors due to not repeating things correctly in SSL section
and the long length of the file.
I broke it up into a httpd.conf, mod_gzip.conf, a global SSL.conf and a
conf file (and SSL version if needed) for each virtual host.
Right now that is a total of 13 conf files.
I like being able to diff the two versions for each virtual host to look
for errors.

Right now I am using Apache::AuthCookie to protect a variety of
locations, but that is making things complicated again.

At this point, should I break the AuthCookie sections out into confs for
each virtual host using it, learn to use Perl Sections, or something
different? Any suggestions are welcome.

Thanks
Chris Bennett

Re: Considering using Perl Sections

On 10/01/2010 04:47 PM, Chris Bennett wrote:

> At this point, should I break the AuthCookie sections out into confs for
> each virtual host using it, learn to use Perl Sections, or something
> different? Any suggestions are welcome.

We actually like using templated httpd.conf files (we use
HTML::Template, but you can easily use Template Toolkit, Text Template,
etc). This lets us have really simple configs and then keep the stuff
that's different for each client in a separate config file (or even the
database) which is then pulled in and applied to the templated
httpd.conf to generate the final conf.

Works quite well for us.

--
Michael Peters
Plus Three, LP

RE: Considering using Perl Sections

We use a combination of Perl sections and Template Toolkit to generate ou=
r apache configs. The Perl sections are good for run-time setup for thin=
gs like host names (i.e., to name logs per host in our cluster) and the t=
emplating is good for setting up things like multiple proxies that have j=
ust a few differences. In this case, I set up a data structure, and then=
=20iterate over it to generate the configs for the proxies.

I also set up a utility script to deploy the whole shebang, since you can=
't use the templated configs as actual apche config files. Rendering the=
se templates takes maybe 2 seconds, so I render my dev version against th=
ose that I've deployed to one of our DEV, STAGE, or PROD environments.

Eric

> -----Original Message-----
> From: Chris Bennett [mailto:chris@bennettconstruction.biz]=20
> Sent: Friday, October 01, 2010 4:47 PM
> To: modperl@perl.apache.org
> Subject: Considering using Perl Sections
>=20
> A while back I realized the futility of using a single=20
> httpd.conf after=20
> having many errors due to not repeating things correctly in=20
> SSL section=20
> and the long length of the file.
> I broke it up into a httpd.conf, mod_gzip.conf, a global=20
> SSL.conf and a=20
> conf file (and SSL version if needed) for each virtual host.
> Right now that is a total of 13 conf files.
> I like being able to diff the two versions for each virtual=20
> host to look=20
> for errors.
>=20
> Right now I am using Apache::AuthCookie to protect a variety of=20
> locations, but that is making things complicated again.
>=20
> At this point, should I break the AuthCookie sections out=20
> into confs for=20
> each virtual host using it, learn to use Perl Sections, or something=20
> different? Any suggestions are welcome.
>=20
> Thanks
> Chris Bennett
>=20
>=20
>=20
_______________________________________________

This e-mail may contain information that is confidential, privileged or o=
therwise protected from disclosure. If you are not an intended recipient =
of this e-mail, do not duplicate or redistribute it by any means. Please =
delete it and any attachments and notify the sender that you have receive=
d it in error. Unless specifically indicated, this e-mail is not an offer=
=20to buy or sell or a solicitation to buy or sell any securities, invest=
ment products or other financial product or service, an official confirma=
tion of any transaction, or an official statement of Barclays. Any views =
or opinions presented are solely those of the author and do not necessari=
ly represent those of Barclays. This e-mail is subject to terms available=
=20at the following link: www.barcap.com/emaildisclaimer. By messaging wi=
th Barclays you consent to the foregoing. Barclays Capital is the invest=
ment banking division of Barclays Bank PLC, a company registered in Engla=
nd (number 1026167) with its registered office at 1 Churchill Place, Lond=
on, E14 5HP. This email may relate to or be sent from other members of t=
he Barclays Group.
_______________________________________________