Re: <Perl>...</Perl> and startup.pl equivalent?

[prev] [thread] [next] [Date index for 2004/12/14]

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:stas@xxxxxx.xxx 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