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

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

--------------080703010500090707010708
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



--------------080703010500090707010708
Content-Type: message/rfc822;
 name="Re: <Perl>...</Perl> and startup.pl equivalent?"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="Re: <Perl>...</Perl> and startup.pl equivalent?"

Message-ID: <41BE3EF3.1030504@xxxxxxx.xxx>
Date: Tue, 14 Dec 2004 01:16:35 +0000
From: colin_e <colin_e@xxxxxxx.xxx>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Stas Bekman <stas@xxxxxx.xxx>
CC: Martin Moss <martin_moss@xxxxxxxxxxx.xxx>
Subject: Re: <Perl>...</Perl> and startup.pl equivalent?
References: <20041213145100.77879.qmail@xxxxxxxx.xxxx.xxx.xxxxx.xxx> <41BE333E.408@xxxxxxx.xxx> <41BE33FB.6020902@xxxxxx.xxx>
In-Reply-To: <41BE33FB.6020902@xxxxxx.xxx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Stas Bekman wrote:

> Could you explain how making:
>
> PerlRequire /path/to/startup.pl
>
> makes it harder to keep things in sync? I'm not sure i understand your 
> example of Windows dll.
>

It doesn't. I probably didn't explain the thought process clearly. or 
maybe the thought process
itself wasn't very clear :-}

As I said, the fact that I have multiple machines with different 
architectures forces me to have
differences in the Apache configs. I could just have multiple monolithic 
httpd.conf files, but
that's a recipe for making fixes on one machine and forgetting to make 
the same changes on
at least one of the others.

So, the requirement is to have host-dependent elements in the config, 
while ideally-

1) Making it clear which elements of the config are common between 
machines, and
    which host-dependent.

2) Coming up with a reasonable compromise between (a) Everything in one 
file, which
    is hard to scroll-around in, hard to "see the wood for the trees", 
and easy to make an
    accidendal error in; (b) A rats-nest of mutiple interdependant 
files, esp. given the
    aparrent sequence-sensitivity of many of the config directives.

I don't have a major problem with putting the Perl config in a 
startup.pl script, but that does
introduce it's own level of mixing host-dependant and host-independent 
config elements
(or having startup_local.pl and startup_common.pl). I just wanted to 
know what my options
were.

As i said to Martin, I could have gone for a pure Perl "executable 
config", with all the variable
elements coded in, but that seemed like a fairly big step for someone in 
his first week of setting
up Apache. I'm not sure I would expect much help from the alias with a 
totally custom-coded
httpd.conf "application" in perl...

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.

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.

Regards: Colin




--------------080703010500090707010708
Content-Type: text/plain; charset=us-ascii

        -- 
        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
--------------080703010500090707010708--