You may be aware that it is possible to configure the latest releases of NSCA httpd or Apache web servers to support what is known as "Virtual hosting". Virtual hosting is a popular concept because it allows multiple domain names to be hosted on the same httpd Server. In fact, much of the competition markets Virtual hosted packages (they usually call them "Virtual Domains" for as little as $20-$25 dollars a month. The lower price (with respect to Virtual Servers) is justified by the fact that Virtual Hosting does not offer as much power and flexibility as Virtual Servers. This is illustrated by the fact that you can configure a Virtual Server to perform Virtual Hosting but the reverse cannot be done.

Virtual Hosting, under the HTTP/1.0 specification, is based on IP addresses, where the Server requests are sorted based on the IP address and appropriate content is served from a corresponding subdirectory of the Web Server. Since Virtual Servers cannot be configured to host multiple IP addresses, Virtual Hosting has been previously unavailable. However, with the introduction of the HTTP/1.1 spec, an "IP-less" virtual hosting solution is now available. Many browsers, servers, and spiders are now pseudo HTTP/1.1 compliant--i.e. some of the HTTP/1.1 features have been implemented in an HTTP/1.0 based product.

The latest generation of browsers (Netscape 2.0+, MSIE 3.0+) and spiders are pseudo HTTP/1.1 compliant. The browsers and spiders pass to the Web Server an environment variable "HTTP_HOST" which identifies the domain name of the request. Using this environment variable, the Virtual Servers can be configured to respond to different domain name requests from the same Server. This creates a tremendous advantage for you as a Virtual Server Administrator. Not only will you be able to offer high end Virtual Servers, but you can market lower end Virtual Hosted packages for a cost that is competitive if not less than many other vendors in the market now.

You may have noticed multiple companies emerging in the market lately offering low end web services for "$19.95" (they typically place a surcharge on bandwidth usage). Now you too can offer a low cost solution by partitioning up a Virtual Server (already a great deal), into multiple low cost Virtual Hosted solutions for potential clientele. We believe that the Virtual Hosting gives you a tremendous advantage in the web presence market and we sincerely hope that you take advantage of this powerful feature. For example, a competitor offers Virtual hosted packages on T1's with 20 MB of space for $19.95/month. They place a surcharge on bandwidth over 500 MB/month (we don't).... and from what we understand they place approximately 1000 virtual domains on each machine. So clearly, you can market a Virtual Host on a Virtual Server as a superior alternative.

Modifying your httpd.conf file

To enable this feature on a Virtual Server you will need to modify your httpd.conf file. For each domain that you would like hosted on a Virtual Server, open up your httpd.conf file (in the ~/www/conf directory) and add the following at the end of the file:

# point example.com and www.example.com to subdirectory example
<VirtualHost example.com www.example.com>
ServerName www.example.com
ServerAdmin webmaster@example.com
DocumentRoot /usr/local/etc/httpd/htdocs/example
</VirtualHost>


Of course, you would substitute your domain name and subdirectory in the place of the "example.com" and "example" occurrences.

If you also want to offer FTP access and POP/IMAP e-mail accounts for your Virtual Hosts, you will use the vadduser command by typing vadduser at the telnet shell prompt. When prompted for the "home" directory for the FTP account, you will want to specify the same value that you use for the DocumentRoot definition. This will allow your subhosted client to publish web content to their Virtual Host. FTP and POP/IMAP capability is only available on the Advanced and Pro Virtual Server accounts.

Virtual Hosting and CGI Access

There are some great advantages of Virtual Hosting other than what has been outlined above. Many of your potential Virtual Hosting clientele will want cgi-bin access. This can easily be configured for a Virtual Host using the ScriptAlias directive in their VirtualHost configuration.

To add cgi-bin capability to a virtual host account, the example above can be modified to include a cgi-bin by including the following line after the DocumentRoot line:

ScriptAlias /cgi-bin/ /usr/local/etc/httpd/htdocs/example/cgi-bin/

It is important to understand that giving cgi-bin access to your virtually subhosted clients is a potential security risk. This is because the CGIs your customers upload and execute have all of the rights and privileges of the CGIs you execute. Therefore, it is possible for a virtually subhosted client, which has been granted CGI privileges, to read or remove any file in your directory heirarchy.Moreover, it is possible for a malicious subhosted client to crack weak passwords and gain shell access to your Virtual Server. Please see our document, Virtual Subhosting and Security Issues for more information.

[top]

Advanced Virtual Hosting Configurations

In the example above, we show has to add the ScriptAlias directive as a means by which you can provide a local cgi-bin for your virtual host clients. As you may have guessed, the "ScriptAlias" directive is only one of the many available options.

Pretty much any directive can be placed inside the VirtualHost section giving your virtual host clients a customized environment.

For example, we can include the definition of a "Not Found Document" (ErrorDocument 404) in the "example.com" VirtualHost configuration (note this also shows the addition of a cgi-bin directory).

# point example.com and www.example.com to subdirectory example
<VirtualHost example.com www.example.com>
ServerName www.example.com
ServerAdmin example@example.com
DocumentRoot /usr/local/etc/httpd/htdocs/example
ScriptAlias /cgi-bin/ /usr/local/etc/httpd/htdocs/example/cgi-bin/
ErrorDocument 404 /errors/notfound.html
</VirtualHost>

Note the file location is specified with respect to the DocumentRoot.... so the actual file location of the "notfound.html" is at:

/usr/home/example/usr/local/etc/httpd/example/errors/notfound.html

Another great feature is the ability to create separate log files for your Virtual hosts. In the VirtualHost directives of your httpd.conf file, add lines to define your new log files like this:

TransferLog logs/example_access_log

Of course you would replace "example_access_log" with an appropriate name to match the Virtual Host you are setting up. With the log directives added, our example Virtual Host is now configured as follows:

# point example.com and www.example.com to subdirectory example
<VirtualHost example.com www.example.com>
ServerName www.example.com
ServerAdmin example@example.com
DocumentRoot /usr/local/etc/httpd/htdocs/example
TransferLog logs/example_access_log
ErrorLog logs/example_error_log
AgentLog logs/example_agent_log
RefererLog logs/example_referer_log
ScriptAlias /cgi-bin/ /usr/local/etc/httpd/htdocs/example/cgi-bin/
ErrorDocument 404 /errors/notfound.html
</VirtualHost>

This will allow you to isolate the logs for a specific Virtual Host rather than having them all lumped into the master log files.

[top]

Virtual Hosting and E-mail Addresses

There are some limitations to the e-mail capability of virtual hosts, namely how the mail system intreprets e-mail addresses. For instance, if you send an e-mail to "sales@abc.com" and "sales@xyz.com" the mail system will view these as the same address. This happens because the mail protocols resolve the domain name to the IP address before delivery of the mail. If these example addresses were on a virtual server with IP address 192.168.1.1, "sales@abc.com" and "sales@xyz.com" would both resolve to "sales@192.168.1.1".

We have developed a workaround to this problem by creating a utility (virtmaps) that maps virtual e-mail addresses to real mail user accounts or aliases on your virtual server.

virtmaps Documentation

[top]

Related Articles

• Can One Equal Many? The New Equation in Virtual Hosting

[top]