Understanding Virtual Hosting at CloseRange

Virtual hosting, or sub-hosting, is one of the most powerful features of the CloseRange VPS system. With virtual hosting, you can support multiple domain names on a single VPS. In other words, with virtual hosting, you can host http://www.abc.com and http://www.xyz.com on the same VPS, each with its own domain name. You can give each virtual host the following unique characteristics:

·       Its own FTP login

·       Access to its subdirectory only

·         E-mail addresses with its own domain name

Limitations of Virtual Hosting

Virtual hosting, or subhosting, is a great feature of CloseRange's VPS system. However, there are some limitations to this capability that you should understand. These limitations include the following:

·         Browsers must be HTTP/1.1-compliant

·         Load balancing (i.e. it is possible for one subhost to use more than its "fair share" of VPS system resources)

·         Shared IP address

·         No Telnet access

·         E-mail limitations

·         Security risks

Being HTTP/1.1-Compliant

CloseRange's VPSs use HTTP/1.1, which makes subhosting a reality. However, to view subhosts you must have a browser that is HTTP/1.1-compliant. Generally speaking, subhosts are supported by Netscape Navigator 2.0+ and Microsoft Internet Explorer 3.0+. Any other browser that is HTTP/1.1-compliant is also able to access virtual subhosted servers.

If your clients use an older browser that is not HTTP/1.1-compliant, they are unable to view their sites or other sites that use virtual subhosting.

Balancing VPS Loads

A VPS is capable of handling 30,000 to 50,000 hits per day (assuming hits generally request about 5 Kbytes of data). This number does not represent "visitors," rather hits or requests for files. For instance, if you have five subhosted domain names, each trying to accommodate 10,000 hits per day (which really is not that much if you have a graphically intensive page; one request for a .gif or .jpeg file equals one hit), there is likely a slowdown that affects all of your clients on the VPS you are using to subhost.

When a slowdown occurs, the VPS administrator should reduce the number of subhosts on the VPS by doing the following:

·         Upgrading one of the especially high traffic virtual hosted sites to its own VPS

·         Moving some subhosts to a less busy VPS

Either way, proper load balancing can be accomplished by administrators that have a feel for serious virtual subhosting. A VPS can only host a finite number of virtual hosts because of resource allocations. The following limits are recommended for virtual hosting:

·         BronzeVPS Server: 5 subhosts

·         <Silver VPS Server: 25 subhosts

·         Gold VPS Server: 60 subhosts

Sharing an IP Address

Virtual subhosting uses the resources of a single VPS to accommodate the needs of multiple web sites. Among the resources that are shared is the single IP address that is associated with the VPS. Search engine "spiders" that are not HTTP/1.1-compliant are unable to index these sites. However, most major spiders and search engines are now HTTP/1.1-compliant.

A VPS can only support a single digital certificate. This makes the use of SSL difficult, since all subhosts must use the same digital certificate, and only one domain name can be associated with a digital certificate.

No Telnet

A virtual subhost does not have Telnet access to the VPS. There are several ways to set up VPS access for virtual host customers, including access via:

·         FTP

·         iManager

·         FrontPage 2000

E-mail Limitations

There are some limitations to the e-mail capability of subhosts, namely how the VPS interprets e-mail addresses. For instance, if you send e-mail to john@abc.com and john@xyz.com, the VPS views these as the same address, because both domain names resolve to the same IP address (john@192.41.5.2). However, the system used by CloseRange gets around this limitation by using a proprietary utility titled "virtmaps." For more information, see the "Creating E-mail Address Mappings or Virtmaps" section of Chapter 4.

Security Risks

It is important to consider some of the security issues that relate to virtual subhosting. Because the virtual subhosts operate in the same VPS environment, CGI scripts that are executed by any virtual subhost will inherit privileges to access any directory or file in your VPS directory hierarchy.

For example, a malicious virtual subhosted client could write a simple script to remove all of the files on your VPS. Another script could send the contents of your ~/etc/passwd file to a remote e-mail address where "weak" passwords could be decrypted. If your login password is susceptible to a dictionary crack, a subhosted client could effectively steal shell access away from you.

It is recommended that you do not offer full cgi-bin access to your virtual subhosted clients unless you have complete trust in them (and even then, they may accidentally cause damage to your VPS). We recommend one of the following alternatives.

1. Provide stock CGI scripts in a directory you control

Most web sites do not demand a great deal of custom CGI programming. It is likely that you could provide a library of "stock" CGI scripts which your subhosted clients could then use. A sample composition of such a library might include a counter, a guestbook, and a generic form processor. You would store these scripts in a subdirectory of your cgi-bin directory (e.g. vhlib). You would then configure each of your virtual subhosts to use this cgi-bin directory by adding the following lines to their <VirtualHost> definition:

ScriptAlias /cgi-bin/ /usr/local/etc/httpd/cgi-bin/vhlib/

2. Configure the cgi-bin directory separate from the Virtual Subhosts' home directory

Another alternative is to provide each of your subhosted clients with a cgi-bin that is not a subdirectory in his or her home directory. This would prohibit clients from uploading and executing any arbitrary script. Instead, the subhosted client would e-mail you the script, you would review it, and then install it into his or her cgi-bin directory (which can be configured to be a subdirectory of your main cgi-bin directory). An example is shown below.

ScriptAlias /cgi-bin/ /usr/local/etc/httpd/cgi-bin/SUBDIRECTORY/

The subdirectory SUBDIRECTORY becomes the cgi-bin directory for the subhosted client. (You may want to use the same subdirectory name for both the ~/www/vhosts and ~/www/cgi-bin to keep things neat and tidy.)

We recognize that in most cases it is likely that not only are you providing your clients with hosting service, but you are also designing their web content and writing their CGI scripts as well. So this discussion may not be applicable to your specific situation, but it is still an element to remember should you decide to expand the scope of your services in the future.