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
_______________________________________________
Blueonyx mailing list
Blueonyx@mail.blueonyx.it
http://mail.blueonyx.it/mailman/listinfo/blueonyx
