colin_e wrote: [...]
What I have at the moment is this arrangement-
httpd.conf
------------------------
early host-dependent "section 1"
< Include httpd_common_s1.conf> < ---------------- Section 1 common config
late host-dependent "section 1"
early host-dependent "section 2"
< Include httpd_common_s2.conf> < ---------------- Section 2 common config
late host-dependent "section 2"
(if/when I need Vhosts I would add a section 3 as above).
Maybe not the most elegant or extensible solution, but it seems to work. Add Perl to
the mix, and there are multiple options for structuring this. One solution would seem to be-
<Perl>
early host-dependent Perl config
</Perl>
<PerlRequire startup.pl > <------------------------ Common Perl config
<Perl>
late host-dependent Perl config
</Perl>
this is why I asked the question, To know whether my choices were open as to
which config elements went where, or whether <Perl></Perl> sections were
constrained in any way.
I guess it's better to:
PerlRequire startup1.pl [...] PerlRequire startup2.pl [...] PerlRequire startup3.pl
but remember that PerlRequire won't be run until the post_config phase, unless <Perl> or PerlLoadModule directives were encountered before it. so the new directives which will be added in RC2 will give a better solution. Just wait till Philippe gets the time to polish those and then we will have the details to share.
There are some interesting tradeoffs here. For example, the docs recommend
<Directory> sections as more robust containers for access control than <Location>.
However my filesystem layouts obviously differ between Solaris and Windows, so
if I use <Directory>, it has to go in the host-dependent httpd.conf.
By comparison, assuming I want my devel and production machines to mirror
each other in their "public" face, If I use <Location> for acces control, the locations
will be the same and I can share these between machines. Not brain surgery, but
tricky choices when you are starting out.
Tricky. But in this kind of case, case why not having a perl program which will maintain all the details and generate the right .pl|.conf files on demand? In this way you could easily keep all the common and different parts of config in one place and have one point control.
-- __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
-- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
