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.
Host header prefix wildcarding
This checkbox enables support for wildcarding of subserver requests. If this checkbox is selected, when a "Host:" header does not match any docroot, a wildcard directory will be checked.For example, if the browser sent a request for "foo.bar.domain.com", and a docroot directory did not exist, the web server checks for the directory "*.bar.domain.com", and if it exists, this will be used as the docroot for the request. If not, a test is made for "*.domain.com"; this process continues, matching each dotted compontent in the domain-name until a suitable docroot directory is found. If none is found, a 404 Not Found error will be returned to the 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 web sites 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 web sites are placed in the virtual server's document root directory. This is called Standard Layout. When hosting many thousands of web sites in this way, placing lots of sub-directories in the in the same directory can cause most file systems to slow down significantly.
Alternatively the Simple multi-directory filesystem layout splits the directory structure on the first two characters of the web site 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 web sites into approximately 600 subdirectories. Thus you can host 600,000 web sites without having more than 1000 entries in any directory.
A special case exists for web site names in which the first part excluding any leading "www." is less than two characters long. These map to a/a/<web site name>. For example, the document root of www.z.org will be <document root>/a/a/www.z.org
Complex multi-directory layout
The other alterative layout scheme provided, Complex multi-directory, doesn't rely directly on the web site name, but rather a hash of it. The web sites 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 web site name into its new location, for example, www.mysite -> JB/uh/www.mysite.com.
Finally, if another layout is required, Custom Subserver map function allows 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 begin 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. For example, in the case of 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:
# Add an extra script alias for www.foo.com, # but not the other Subservers scriptalias /cgi-local /usr/web/cgi-foo/In this way, any setting that can be configured with .htaccess files can be overridden for particular Subservers. This also has the added advantages that any changes to the .htaccess files are automatically reloaded by the web server, allowing easy real-time server alterations by scripts.