[BlueOnyx:11360] Re: Web alias turn off PHP

Gustavo Silva pseudo at zbronx.com
Fri Sep 21 07:19:04 -05 2012


Nice! Thanks Michael!

Would like to report, yet another thing that could use fixing which is 
related with the subdomains of a particular vhost.
If you change the IP address of a vhost, the subdomains .conf files 
remain with the old IP address and do not get the new IP provided.
Something thats easily changed/scripted by hand but thought i should 
report it here.

I need to start looking at that SVN and maybe commit a change or two 
instead of just reporting bugs... i know... But thats a lot of reading 
to do, so that i dont end up doing more harm than good :)

Cheers guys!

Em 19-09-2012 22:14, Michael Stauber escreveu:
> Hi Steven,
>
>>> I've had a look in /usr/sausalito/conf/base/apache/Apache.conf and I *think* the handler should be running. My knowledge of this area is somewhat sketchy though. Perhaps Michael may have some input as to what's called and when. To me it looks like webscripting.pl (or webscripting2.pl ?..) isn't being called for some reason, so this section isn't making it to the config file.
>> Ok, changing
>>
>> VirtualHost.name                perl:base/apache/webscripting2.pl EXECUTE
>>
>> to
>>
>> VirtualHost.name                perl:base/apache/webscripting.pl CONFIGURE
>>
>> Makes it go away. I'd hesitate to do this on something important - I'm sure there's  reason there is a webscripting.pl and a webscripting2.pl that use different stages. I don't yet understand why, but it proves it's a handler not working correctly.
> VALIDATE, CONFIGURE, EXECUTE, TEST, CLEANUP stages all serve different
> and specific purposes and are called in sequence. Something that is
> called via VALIDATE will always be called before something that's called
> via CONFIGURE. If left blank, EXECUTE will always be assumed.
>
> So while the various stages come in sequence, there is no guarantee in
> which sequence scripts within the same stage might be called.
>
> Let us take a look at a part of Apache.conf:
>
> # Vsites have a seperate namespaces for php, cgi, ssi and
> enabling/disabling user webs
> Vsite.PHP.*             perl:base/apache/webscripting.pl CONFIGURE
> Vsite.CGI.*             perl:base/apache/webscripting.pl CONFIGURE
> Vsite.SSI.*             perl:base/apache/webscripting.pl CONFIGURE
> Vsite.*                 perl:base/apache/webscripting.pl CONFIGURE #*OLD
> Vsite.USERWEBS.*        perl:base/apache/userwebs.pl CONFIGURE
>
> Vsite.PHP.*             perl:base/apache/reload_httpd.pl CLEANUP
> Vsite.CGI.*             perl:base/apache/reload_httpd.pl CLEANUP
> Vsite.SSI.*             perl:base/apache/reload_httpd.pl CLEANUP
> Vsite.USERWEBS.*        perl:base/apache/reload_httpd.pl CLEANUP
> Vsite.webAliases.*      perl:base/apache/webscripting.pl CLEANUP #*NEW
>
> webscripting.pl is called in the CONFIGURE stage whenever *anything* in
> a "Vsite" object is added, updated or removed. That ought to be
> sufficient. But in fact it isn't. When you add or modify the "webAlias"
> of a Vsite, the virtualhost container of the Vsite will be rewritten
> from scratch with the PHP or suPHP related entries gone walkies.
>
> So I went in and call it again in the CLEANUP stage, but only when the
> "webAliases" of a "Vsite" object are added, updated or removed. So this
> makes sure that webscripting.pl is run at the end of the sequence and
> adds the PHP or suPHP related lines in case they're gone.
>
> In the testing that I did, this seems to work pretty well.
>
> I'm just publishing that change to SVN and to YUM:
>
> 5106R:
> http://devel.blueonyx.it/trac/changeset/934/
>
> 5107R/5108R:
> http://devel.blueonyx.it/trac/changeset/933
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.blueonyx.it/pipermail/blueonyx/attachments/20120921/5c80d5da/attachment.html>


More information about the Blueonyx mailing list