Customer Reviews

Read More

The World's Leader in Virtual Server Technology

Virtual Hosting
pg. 17

• Virtual Hosting Limitations
• Setting Up Virtual Hosting
• The vaddvhost Command
• Virtual Host Entries
• Restricting Virtual Host Disk Usage
• Canonical Domain Names as Virtual Hosts
• Virtual Hosting and Email/FTP Accounts
• Removing a Virtual Host

By default, your virtual server considers your ~/www/htdocs directory to be the Document Root - the directory that contains all the files for your main domain that can be accessed through a Web browser.
You can associate multiple domain names with your virtual server's single IP address, however, and each additional domain name can be given its very own Document Root. This process of dividing your virtual server into smaller units is known as Virtual Hosting, and each resulting division, or virtual host, can be sold to others. This is the same technology used by most large Web hosting companies.
For example, assume that Acme Industries, a prospective client, decides they would like to develop a Web presence for as little money as possible. Your virtual server offers the perfect solution. You can help Acme register or transfer the domain name "acme.com," create a directory on your virtual server, then point Acme’s domain to that directory. Visitors to the acme.com Web site will see only the Acme portion of your virtual server, and will never know that the files actually reside in a directory of your virtual server.
Despite some limitations, Virtual Hosting is intended to provide you with a way to offer prospective clients a low cost solution for Web hosting. You can sell virtual hosts for $20-$30 a month, or whatever you decide. Then, as their needs grow, you can upgrade them to their own virtual server.
Virtual Hosting can be provided not only for full domain names, but also for canonical domain names. This means that you can provide virtual hosting not only for clients who have their own domain name, but for names like "client.yourdomain.com," as well.

Virtual Hosting Limitations
Virtual Hosting is provided to help you give customers a “foot-in-the-door” Web hosting option. We realize that not all of your customers will be ready for their own virtual server when they start out, and Virtual Hosting provides a nice solution for them. As your clients’ needs grow, we hope that you will become a virtual servers Reseller and resell them their own virtual server system.
There are a few limitations to Virtual Hosting that you should be aware of before offering this service to your clients:

• Your virtual server (400 meg) is designed to handle a small to medium hit load (under 30,000 hits a day). This includes all of the Web sites hosted on your virtual server – not just your primary one. If a virtual server begins to receive over 30,000 hits per day, the quality of your Web service will begin to be affected.
• If your virtual server begins to receive a large amount of traffic, you should reduce the number of virtual hosts on the Virtual Server by either upgrading heavily trafficked virtual hosts to their own virtual servers or by moving some virtual hosts to a less busy virtual server. To ensure the best possible performance for your virtual server, we recommend that you limit the virtual server 400 meg to 45 Virtual Hosts These limits will help manage load balancing efforts on your virtual server and ensure that your virtual server runs as efficiently as possible.
• Virtual Hosting was made possible by the introduction of HTTP/1.1. In order to view Virtual Hosts you must have a browser that is HTTP/1.1 compliant. Generally speaking, most standard Web browsers support Virtual Hosts. Netscape Navigator 2.0+ and Microsoft’s Internet Explorer 3.0+ will view your Virtual Hosts fine. Any other browser that is HTTP/1.1 compliant should also be able to access your Virtual Hosts. If your clients are using an older browser that is not HTTP/1.1 compliant they will not be able to view their virtually hosted sites. However, considering that together Netscape and MSIE have 90-95% of the market share, this usually isn’t a problem. The small number of non-compliant Web browsers will display your primary Web site regardless of which domain is requested.
• Some search engines and “Web-crawler” spiders that do not support the HTTP/1.1 protocol will not be able to index your Virtual Hosts’ Web sites. Most major search engines do not have this problem, but you should be aware that there are some out there that do.
• We can only install Digital Certificates for the principal domain for the virtual server. Separate Digital Certificates cannot be created for Virtual Hosts. Virtual Hosts can use SSL with the Safe Server wildcard certificate for a small fee if you request it.
• Email aliases and account names are shared among all of the domains on a virtual server. Because of this it is important to understand the use of virtual email mappings (virtmaps).
• Because there is only one administrative Telnet account per virtual server, you cannot provide Telnet access for your virtual hosts.

Setting Up Virtual Hosting
To set up a virtual host on your virtual server, you must follow three basic steps. It is important to follow these steps in order to avoid potential problems for your customers.

Register the Domain Name
The first thing that you should do when setting up a virtual host is to ensure that the domain name for the virtual host is properly registered.
In some cases, you may need to help the client register the domain name. In other cases, your potential client may already own the domain name, and may be hosting the domain on another provider’s system. In such situations, you will need to assist the client in modifying the DNS information for their domain name, so that the name servers become authoritative for the domain.
In either case, it is important that the domain name be properly registered
Request the DNS Addition
Once a domain name is properly registered, you need to request that an entry for the domain be added to your DNS record in our name servers. If you skip this step, it is impossible for anyone to locate your virtual server using that domain name.
Just send RSH Web Services a email with your domain name or account name along with the domain name to be "pointed" added.
There is a one-time setup fee for each virtual host that you add to our name servers.
Once our staff adds the DNS record, you will receive a confirmation email.

Configure the Virtual Host
Once your new virtual host is properly registered and added to our name servers, you can configure the virtual host on your virtual server using the vaddvhost command. The vaddvhost command modifies some configuration files on your virtual server, and creates a few necessary directories and files if they do not already exist.
Example: To add a domain name as a virtual host of your virtual server, SSH to your virtual server and type the following at the command prompt:
vaddvhost Enter
The following series of prompts appear (denoted by even spaced type). For this example, we will add “acme.com” as a virtual host to your virtual server. For each prompt that appears, enter the information shown:
What is the domain you want added as a Virtual Host: acme.com
The above command instructs vaddvhost to create a directory called acme.com within your ~/www/vhosts directory. To help manage multiple hosts, it is recommended that you include the .ext extension.
How would you like to log the Web activity for this virtual host?
        1) Using separate log files for this virtual host
        2) Using the same log files as my primary domain
        3) Disable logging for this virtual host
Your choice: [1]: 1
Providing separate log files for your virtual hosts can help to track individual site traffic. However, if you have a very large number of virtual hosts, separate log files can fill up valuable disk space and possibly affect your virtual server's performance. In such cases, you may wish to have your virtual hosts use the same log files as the primary domain (Option 2) or to disable logging for the virtual hosts altogether (Option 3).
Would you like to store the access_log, referer_log, and agent_log
information into a combined access_log format? [Y]: N
Some log file analysis programs work better with a combined log format. In a combined log format, all the same information is logged into a single file rather than three, thereby reducing the number of open file handles that are used.
Would you like custom error pages for this virtual host? [N]: Y
Many virtual hosts prefer to customize their own error pages. In this example we are allowing acme.com to customize its error pages.
Do you want a separate cgi-bin directory for this host? [Y]: Y
If you would like to allow your virtual host to have its own directory for storing and executing CGI programs, type Y; otherwise, press N.
Before any changes are actually made to your ~/www/conf/vhosts.conf file, the <VirtualHost> entry is displayed and you are given the opportunity to edit the entry:
Below are the lines that will be added to your ~/www/conf/vhosts.conf
file to support the virtual host that you've just created:

<VirtualHost www.acme.com>
ServerName www.acme.com
ServerAlias acme.com
ServerAdmin webmaster@acme.com
TransferLog vhosts/acme.com/logs/access_log
ErrorLog vhosts/acme.com/logs/error_log
LogFormat "%h %l %u %t "%r" %s %b "%{Referer}i" "%{User-agent}i""
ErrorDocument 500 /errordocs/internalerror.html
ErrorDocument 404 /errordocs/filenotfound.html
ErrorDocument 403 /errordocs/accessdenied.html
<Directory "/usr/local/apache/vhosts/acme.com/htdocs">
Options Indexes Includes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
Allow from all
</Directory>
<Directory "/usr/local/apache/vhosts/acme.com/cgi-bin">
Options ExecCGI
AllowOverride All
Order allow,deny
Allow from all
</Directory>
</VirtualHost>

Press Enter to accept, 'e' to edit in text editor, 'c' to cancel:

Assuming that everything is set up to your satisfaction, press Enter. vaddvhost will add the <VirtualHost> entry to your ~/www/conf/vhosts.conf file and display the following message:
Virtual Host added successfully
If you followed all three of the above steps correctly, your virtual host should now be functioning properly. Please read the next section to understand the modifications that vaddvhost has made to your virtual server’s configuration files, so that you can change these settings later if needed.
After running vaddvhost, you must restart Apache with the command, 'apachectl restart'.

The vaddvhost Command
The vaddvhost command greatly simplifies the process of setting up <VirtualHost> entries in your ~/www/conf/vhosts.conf file. It is important to understand the changes that vaddvhost makes to your virtual server’s configuration files, in case you ever need to edit them. vaddvhost makes the following changes when adding a virtual host:
vaddvhost searches for the directory you specified as the home for the virtual host. If it doesn’t already exist, the directory is created for you.
The virtual host is added to the list of domain names in your ~/etc/sendmail.cw file. This list specifies which domain names can send and receive email from your virtual server. If a domain name is pointed to your virtual server but is not listed in this file, you may not be able to send or receive email addressed with that domain name (Note: Your primary domain name does not need to be listed in this file).
If you chose to have a separate directory for your CGI files, vaddvhost creates a cgi-bin directory in the virtual host’s home directory.

Finally, vaddvhost makes some very important additions to your ~/www/conf/vhosts.conf file. These lines, called a Virtual Host entry, are what actually allow the virtual host to function.

After running vaddvhost, 
You must restart Apache with the command, 'apachectl restart'.

Virtual Host Entries
Step 3 of Setting Up Virtual Hosting explains how to configure a virtual host on your virtual server. Here, we explain what each line of a <VirtualHost> entry actually means. All lines starting with a pound sign (#) are comments, and are ignored by your virtual server.
A Virtual Host entry always starts with the following line, where domain.com is the name of the virtual host:
<VirtualHost www.acme.com>
Configuration settings contained in a Virtual Host entry apply only when a request is received for the specified domain. These configuration settings override the defaults for the virtual server.
The first line of a Virtual Host entry defines the name your virtual server should take when requests come addressed to the virtual host (again, domain.com should be the name of your virtual host’s domain name):
ServerName www.acme.com
The second line contains any aliases that point to the main domain of your virtual host:
ServerAlias acme.com
The next line defines the email address of the virtual host’s administrator. The address only appears on error pages generated by your virtual server:
ServerAdmin webmaster@acme.com
The next line specifies the virtual host’s Document Root, the directory you specified when using the vaddvhost command. This is where your virtual server expects to find the Web pages for the virtual host:
DocumentRoot /usr/local/etc/httpd/vhosts/acme.com/htdocs
If you chose to provide a separate directory for CGI files, the following line specifies the name of the directory to use for that purpose:
ScriptAlias /cgi-bin/ /usr/local/etc/httpd/vhosts/acme.com/cgi-bin/
If you chose to provide separate log files for your virtual host, the following lines define the log file types:
TransferLog vhosts/acme.com/logs/access_log
ErrorLog vhosts/acme.com/logs/error_log
LogFormat "%h %l %u %t "%r" %s %b "%{Referer}i" "%{User-agent}i""
If you chose to enable custom error pages for your virtual host, the following lines indicate where the various error pages reside:
ErrorDocument 500 /errordocs/internalerror.html
ErrorDocument 404 /errordocs/filenotfound.html
ErrorDocument 403 /errordocs/accessdenied.html
Finally, the following line denotes the end of the configuration data for this particular virtual host:
</VirtualHost>
There are additional configuration options that you can use with Virtual Hosting. Many of the configuration directives contained here can be included in a Virtual Host entry.

Restricting Virtual Host Disk Usage
You can add users with the vadduser command and give them ftp rights and an ftp quota. The FTP account allows them to maintain their own file system, while the disk quota prevents them from using more than their fair share of disk space.

Canonical Domain Names as Virtual Hosts
If you have a customer who wants a virtual host but doesn’t want his own domain name, you can still provide Virtual Hosting services for them by using a canonical domain name. A canonical domain, often referred to as a c-name, takes the form "somename.yourdomain.com" and can be used as a virtual host just as if it were an actual domain name.
Another example is the C-name we use on our Domain Registering pages:  domain.rshweb.com
You can also use c-names and Virtual Hosting to present a larger, corporate image by appearing to have several different Internet servers. For example, your company could use "www.yourdomain.com" for the main Web site, "support.yourdomain.com" for a technical support site, and "search.yourdomain.com" as a search utility. All of these separate, distinct Web sites could be housed on the same virtual server for a relatively low cost.

Virtual Hosting and Email - FTP Accounts
Virtual hosting allows you to provide an inexpensive, professional Web service to your clients. You can also provide your clients with an FTP account so that they can maintain their own Web site without requiring your intervention.
To add an FTP/Email account for a virtual host on your virtual server 250, 300 or 800 meg, Telnet to your virtual server and type the following at the command prompt:
vadduser Enter
When asked to select a home directory for the user, choose /www/vhosts/domain.com, where domain.com is the domain you're virtually hosting.

Removing a Virtual Host
At some point you may wish to remove a virtually hosted domain from your virtual server. In order to do so, some changes must be made both to our network and to your virtual server.
First, to correct the information in our network, contact our Support Team to let us know you are no longer hosting the domain.
You will need to specify the domain name of your virtual server, as well as the domain name of the virtual host you are removing. You must also provide the Contact Name and email address for your virtual server; otherwise, we will not be authorized to remove the domain file from our nameservers.
Next, you will need to edit the vhosts.conf file in your ~/www/conf directory. Before you edit a configuration file of this type, you should create a backup copy of the file, using the following command:
cp ~/www/conf/vhosts.conf ~/www/conf/vhosts.bak Enter
You can then open vhosts.conf in pico or another editor, and find the portion dealing with that domain. You can either remove this portion, or comment it out by preceding each line with a pound sign (#).
You can also remove the files associated with the domain by using the rm -rf command. You should be very careful when using this command, however, as it will delete any and all files matching the string that follows without first verifying the command. If you have any other domains pointed to this directory, you will not want to perform this command, as it is removing the sub-directory and all of its contents.
To remove a virtual host from your vhosts directory, enter the following command, where domain.com is the domain name of your virtual host:
rm -rf ~/www/vhosts/domain.com Enter
Finally, you will want to edit the sendmail.cw file, which is located in your ~/etc directory. This file is simply a listing of every domain authorized to send and receive email through your virtual server, and of every domain for which your virtual server will attempt to resolve email. If the domain of your former virtual host is in this file, you will not be able to send email to it at its new address. Simply edit the file and remove the line that consists of that domain name.