The first step is to alter your Apache 2 httpd.conf file: you need to edit the section that contains the virtual server definition for the machine that you wish to run a new virtual instance on. Alter the virtual server definition 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 (/etc/apache2/conf on Ubuntu) and is expected to already contain a number of <VirtualHost> sections. Conventionally the VirtualHost definitions are near the end of the file. 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.

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 installing the packages or using easyinstall in /etc/wacs.d/wacs.cfg or by copying the example file from the conf subdirectory of the WACS distribution.

	Tip
	If you've installed using a package install, the standard wacs infrastructure components (glyphs, style files, javascript scripts) will appear in /wacs on every virtual server. If you don't want to make use of these in one of the virtual servers, you can set it to use a private tree through the wacsurl directive in the wacs.cfg file. See Chapter 9, Server Details for more information.

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 other chapters of this configuration guide.

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>

This will ensure that the virtual site has standard WACS menus.

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.

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 guide 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.

Once the steps above have been completed you can then populate the server using either 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:

With this done the tools will then act on the file tree and database of the desired virtual server.