Virtual
hosting, or sub-hosting, is one of the most powerful features
of the Enetrics Communications Virtual Server system. With virtual
hosting, you can support multiple domain names on a single
Virtual Server. In other words, with virtual hosting,
you can host http://www.abc.com and http://www.xyz.com
on the same Virtual Server, each with its own domain name
and each serving pages in it's own directory on the Virtual Server. 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 Enetrics Communications's Virtual Server
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 Virtual Server system resources)
- Shared IP address
- No Telnet access
- E-mail limitations
- Security risks
Being HTTP/1.1-Compliant
Enetrics Communications's Virtual Servers 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 Virtual Server
LoadsA Virtual Server is capable
of handling 30,000 to 100,000 hits per day (assuming
hits generally request about 5 Kbytes of data), depending
upon which Virtual Server system plan you have as well
as other factors such as what type of content is being
served, your effective use of memory and cpu.
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 Virtual Server you are using to subhost.
When a slowdown occurs,
the Virtual Server administrator should reduce the number
of subhosts on the Virtual Server by doing the following:
- Upgrading one of the
especially high traffic virtual hosted sites to its
own Virtual Server
- Moving some subhosts
to a less busy Virtual Server
Either way, proper load
balancing can be accomplished by administrators that
have a feel for serious virtual subhosting. A Virtual Server can only host a finite number of virtual hosts
because of resource allocations. The following limits
are recommended for virtual hosting. These are not hard
limits, but until you get used to managing load balancing,
we recommend you stay within these limits.
- VPS v1: FreeBSD: Server B: 30 subhosts
- VPS v1: FreeBSD: Server C: 45 subhosts
- VPS v1: Solaris: Server B - 30 Subhosts
- VPS v1: Solaris: Server C - 45 Subhosts
Sharing an IP AddressVirtual subhosting uses
the resources of a single Virtual Server to accommodate
the needs of multiple web sites. Among the resources that
are shared is the single IP address that is associated
with the Virtual Server. 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 Virtual Server 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 TelnetA virtual subhost does not
have Telnet access to the Virtual Server. There are several
ways to set up Virtual Server access for virtual host
customers, including access via:
- FTP
- iManager
- FrontPage 2000/2002
E-mail LimitationsThere are some limitations
to the e-mail capability of subhosts, namely how the Virtual Server interprets e-mail addresses. For instance, if you
send e-mail to john@abc.com and john@xyz.com, the Virtual Server views these as the same address, because both domain
names resolve to the same IP address (john@192.41.5.2).
However, Enetrics Communications has developed a way to get
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 Virtual Server environment, CGI scripts that are executed by any
virtual subhost will inherit privileges to access any
directory or file in your Virtual Server directory hierarchy.
For example, a malicious
virtual subhosted client could write a simple script to
remove all of the files on your Virtual Server. 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 Virtual Server). We recommend one of the following
alternatives.
1. Provide stock CGI
scripts in a directory you controlMost 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 directoryAnother 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.
|
