
Providing Miva for Virtual Subhosts |
<VirtualHost> configuration directive.
virtualhostvariable=SERVER_NAME dnslookup=0
NOTE: If you
choose to set virtualhostvariable=HTTP_HOST, then your miva.conf
must have a <VirtualHost> directive for
each of the virtual subhost's domain names. For
example, using 'HTTP_HOST' will require both
subhost-domain.com and www.subhost-domain.com to
have its own <VirtualHost> directive in miva.conf.
This is why we recommend using 'SERVER_NAME'
instead, because in your httpd.conf, you
can consolidate a virtual subhost's multiple host
names under a single <VirtualHost> directive with
just one ServerName. This is
documented in the instructions below. |
<VirtualHost> directive to miva.conf.
Assuming that you are using virtualhostvariable=SERVER_NAME in miva.conf,
the name of the <VirtualHost> should equal the ServerName for the subhost defined
in the <VirtualHost> directive for your web
server in your httpd.conf. Ideally, the mivaroot parameter should equal
the virtual subhost's DocumentRoot (another parameter of
the <VirtualHost> directive in
httpd.conf).
The stdmodedatadir should be outside of
the ~/www/htdocs directory, unaccessable by
others, since all data collected by Miva will be stored
in that directory.
The VirtualHost directive in miva.conf should look something like this:
<VirtualHost www.SUBHOST-DOMAIN.NAME> mivaroot=/usr/local/etc/httpd/htdocs/SUBHOST-DOMAIN-DIR stdmodedatadir=/usr/local/etc/httpd/miva/SUBHOST-DOMAIN-DIR_data mivadefault=index.html serveradmin=webmaster@SUBHOST-DOMAIN.NAME </VirtualHost>
<VirtualHost> directive in httpd.conf
matches those you set in the <VirtualHost> directive of miva.conf,
you must check if your subhost has access to the Miva
engine that was put in your ~/www/cgi-bin during
the Miva installation. If the virtual subhost is sharing
your virtual server's primary cgi-bin directory--meaning
that you have not explicitly identified an alternate ScriptAlias for the subhost in the <VirtualHost> directive of httpd.conf--then
after following all the instructions above, Miva should
be setup and ready to support your virtual subhost. If
you don't understand what a ScriptAlias is, then your virtual
subhost is probably using your primary cgi-bin directory
and the Miva engine therein, so you don't have to worry
about making anymore changes. Go on to the next step.
However, if the
virtual subhost has its own cgi-bin directory,
then we would recommend that you give that virtual
subhost access to the Miva engine in your primary cgi-bin
directory by adding the following to your httpd.conf's
<VirtualHost> directive:
ScriptAlias /cgi-miva/ /usr/local/etc/httpd/cgi-bin/ AddType application/x-httpd-Miva .mv Action application/x-httpd-Miva /cgi-miva/miva
mivaroot (which should be its DocumentRoot, assuming you followed
the instructions above) and running it in your browser.
For example: % cp /usr/local/contrib/miva_apps/maillist/* ~/www/SUBHOST-PATH
Then, in your browser, access this URL:
http://SUBHOST-DOMAIN.NAME/maillist.mv
When you run
this applet, it should save the submitted data in the
virtual subhost's stdmodedatadir in a file called mailing.dat.
If not, review the instructions above along with your own
setup for any configuration errors.
NOTE: If Miva
still has problems running an application for a
virtual subhost, or runs the application but
stores data in the wrong directory, then delete
all the files in your workdir (the default
installation will have this set as ~/www/miva/workdir).
This directory contains a caching database with
virtual subhost configuration information.
Deleting the database files will require Miva to
reload the new VirtualHost information
from miva.conf. |