WACSip
|
Web-based Adult Content Server
|
AppNote 02: Running Multiple WACS instances
Background
One of the questions we have been asked about WACS is whether it is
possible to run multiple separate instances of WACS on a single
server. The answer is yes, and this document sets out how you
configure this to work. The one limitation at present is that all
the instances need to run the same release of Wacs because the standard
WACS modules (that do all the hard work) are installed globally on the
host server.
Step One: Add a SetEnv Directive To Your httpd.conf file
The first step is to edit your Apache 2 httpd.conf file, virtual
server entry, to include the following extra configuration line:
SetEnv WACS_CONFIG /vol/www/data/beaky-wacs/wacs.d
The httpd.conf file is usually to be found in /etc/httpd/conf
and is expected to already contain a number of <VirtualHost>
sections. Find the one for the new server (second instance or greater) and
add the line shown above, modified to the location you actually wish to store
the new virtual host WACS configuration in.
Step Two: Creating The Virtual Site Configuration File
Each WACS installation needs it's own configuration file pointing to the
document and icon trees for that installation. This configuration file
therefore needs to be customised for each virtual site created. The best
starting point is probably to copy either the default system file created
by easyinstall in /etc/wacs.d/wacs.cfg or by copying the example
file from the conf subdirectory of the WACS distribution.
Make sure you have created the directory named in the Apache 2
httpd.conf file (see above) and copy this new file into it.
Then work through the settings given in the wacs.cfg file and
modify them as necessary. Note that at a very minimum you will want
different database login credentials and your image archive tree must
be different. Details of what these settings are and what they should
be set to can be found in the configuration section of the documentation
for WACS.
Step Three: Adding The Menu File
The way that WACS works, any configuration file not found in the specified
location will also be checked for in the standard locations, so when trying
to have multiple virtual hosts, you have to make sure that the key files
do exist in the specified configuration directory. This means if you don't
create a menu.cfg file for each configuration, the default one in
/etc/wacs.d/wacs.cfg, which may be totally inappropriate to that
virtual site, will be used. In other circumstances, you may be able to use
this to your advantage, but you need to be aware of it. At a very minimum,
creating your new menu.cfg file as:
<?xml version='1.0' standalone='yes'?>
<menu>
</menu>
and this will ensure that the virtual site has standard WACS menus.
Step Four: The Access Control List
As with the menu configuration file, the static access control list
/etc/wacs.d/wacs.acl will also be common across all virtual
hosts unless you create a local one in the specified new config location.
This is more commonally what you might actually want because it allows
your system support and help desk staff the same level of automatic
access to all virtual servers hosted on the system. If you do want to
override this, you again create a local one within the configuration
file area for the virtual host in question.
Step Five: Creating The Virtual Host Database
Since each installation has it's own database, you will obviously
need to create a new database table for each instance, and to do this
you will need to follow the manual installation proceedure, detailed
in the WACS installation document from step 9 (Creating the database).
Normally you would create a different database account for each instance
and create the necessary database tables within that account and then
populate them.
When using Oracle it is possible to have a single
models database instance and access it via a Named View
from each virtual server using an idmap to determine if a given model
should appear in a given virtual server's catalogue. Through the ability
to specify the database schema name to use in the config file, you can
also import certain tables from a central repository account using the
account.schema notation. If you didn't understand the last two
sentances, don't worry, they're pretty complex relational database concepts
and you almost certainly won't need to use them! If you did, you'll hopefully
to be beginning to grasp that WACS is fully capable of giving service in an
enterprise level environment.
Step Six: Populating The Virtual WACS Server
Once the steps above have been completed you can then populate the server
using eitehr the web based tools, or the command line based ones. Do note
that if you're using the command line tools, including the wacsimport and
wacsxmlin tools, you will need to specify the environment variable
WACS_CONFIG to ensure that the tools are working on the correct
installation. By default, it'll always go to the one configured in
/etc/wacs.d/wacs.cfg. As with the Apache configuration, setting
the environment variable changes the environment in which the tools act.
The commands would be along the lines of:
sh/bash shells:
export WACS_CONFIG=/vol/www/data/beaky-wacs/wacs.d
or
csh/tcsh shells:
setenv WACS_CONFIG /vol/www/data/beaky-wacs/wacs.d
With this done the tools will then act on the file tree and database of
the desired virtual server.
Back to the FAQ
WACS Home Page on Sourceforge