Subserver module
Software Virtual Servers within a Server
Overview
This module allows you to create the effect of software virtual servers
within a virtual server. All the servers share the same
configuration, but the web server will examine the "Host" header line
sent by the browser. This value is then appended to the docroot, so
that different servers will have a different docroot.
This means that creating a new subserver is a simple matter of making a directory under your docroot. It also means that creating a new subserver, does not consume any more system resources such as file handles or memory. This is a more scalable solution for large number of servers. It also becomes easier to administer a large number of servers, as they all share the same configuration.
Reference
When this module is enabled, the server takes the HTTP
"Host:" header, strips off the port number, if there is one,
converts the string to lower case and appends it to the docroot. If
no "Host" header is sent then _default is appended to
the docroot instead.
For example, if your docroot was set up to be /docroot, then somebody going for http://www.foo.com/ would get a docroot of /docroot/www.foo.com/.
Some old browsers do not send the required "Host" line. In this case the docroot would be set to /docroot/_default/. You can use this directory to create a polite error page, explaining the problem with their browser.
Setup
Once the module is enabled all you need to do to create a new
subserver is to create a new directory under your docroot, of that
server name. To later delete a server, simply delete that
directory.
The DNS records should be set up so that all the subservers resolve to the same address. The server differentiates between them solely by looking for the "Host" header line in the client's request.
Filesystem layout
The filesystem layout of websites running under the subserver module can
be tailored to the number of sites you are running and the underlying
filesystem in use.
By default, all websites are placed in the virtual server's document root directory. This is called Standard Layout. When hosting many thousands of websites in this way, placing lots of sub-directories in the in the same directory can cause most file systems to slow down significantly.
Three alternative layout schemes are available. The first, Simple multi-directory splits the directory structure on the first two characters of the website name, ignoring the leading "www.". Thus www.mysite.com would be placed in <document root>/m/y/www.mysite.com in this layout. This structure splits the websites into approximately 600 subdirectories. Thus you can host 600,000 websites without having more than 1000 entries in any directory.
The 2nd layout scheme, Complex multi-directory doesn't rely directly on the website name, but rather a hash of it. The websites are split over a two-level directory structure, each with two character subdirectory names, splitting the sites over a billion directories, more than enough for your hosting requirements! A PERL script supplied in $ZEUSHOME/webadmin/bin/subserver_hash.pl (where $ZEUSHOME is your Zeus installation directory), will convert a website name into into its new location, e.g. www.mysite -> JB/uh/www.mysite.com.
Finally, the 3rd scheme, Custom subserver map function allows any you to implement any hashing scheme you desire by linking in a DSO (dynamic shared object) containing a user-written C function which performs the mapping. Click here for details.
Layout extensions - Optional prefix/suffix
The subserver module also allows an optional prefix string, and optional suffix string to be configured. If supplied, the prefix string and/or suffix string are applied to the layout policy.This allows customers' document root directories to be a subdirectory of their 'master directory', or looking at it differently, it provides a parent directory to the customers document root directory which can be used to store per-customer related information in. For example, imagine a setup whereby each customer has a directory structure like:
Here a suffix string of docroot is being used. The customer is configured so their FTP account is chrooted to www.customer.com/docroot. However the webmaster can store customer related files, such as billing and usage information in the customer's parent directory, which the customer themselves can never access. The ability to store per-customer information directly in the filesystem tree can relieve the need for an external customer database and the complications of keeping the filesystem and database in sync as customers are added and removed or switched between quality of service categories.
The prefix string, if supplied, will be forced to end in a /, the suffix string, if supplied, will be forced to end with a /.
Htaccess extensions
Each subserver shares the same configuration as described above, but
sometimes you might want a particular subserver to have slightly
different settings, an extra scriptalias directory for example.
This can be achieved by enabling the htaccess module and setting up a global .htaccess file. When a subserver connection is received by the server, the htaccess module will consider both the global .htaccess file, and the global .htaccess file with the name of the subserver appended to it to be a single logical file. For example, if you have a global .htaccess file of /usr/web/globalconfig, and a subserver www.foo.com, and you are using the standard filesystem layout, the htaccess module will look at both the /usr/web/globalconfig and /usr/web/globalconfig.www.foo.com (in that order).
If you are using a different filesystem layout, the server will look at <globalconfigfilename>./<mapped filename> instead. E.g. for www.foo.com, with the Simple multi-directory layout, the server will look at the file /usr/web/globalconfig./f/o/www.foo.com.
In the subserver global .htaccess file you can set any directives that you can in the normal global .htaccess file.
For the example above, the contents of /usr/web/globalconfig.www.foo.com might be: