By Charles Fisher
Questions regarding this article should be directed to the author at firstname.lastname@example.org
There are two basic audiences that will have an interest in the mechanics behind virtual hosting:
There will be only minor differences in the methods used to configure these servers.
The information presented within this document is intended for Intel-based systems running Red Hat Linux 4.2. Much of the same information will be applicable, however, to other Unix platforms where IP Aliasing is available.
Red Hat 4.2 is ready for WWW virtual hosts right out of the box. Other versions of Linux (or Unix) may require substantial configuration before the principles outlined below can be applied. In other words, if you are pressed for time, use Red Hat.
This article assumes that you have a system that reliably runs Red Hat 4.2. It is also assumed that your network interface cards are properly configured, that your network routers are functioning, and that you have added user accounts to your Unix system for each of your virtual host administrators.
Over and above a working Linux system, you will require the following administrative rights:
You can get this access from your ISP, service provider, or network administrator.
If you are unable to obtain these required items, refer to the Cheaters Never Prosper section; you might be able to implement a limited workaround.
There are many issues behind virtual hosts, and many levels of technical understanding. These issues can be better understood through the use of an analogy.
It is the job of a secretary to answer a set of office telephones. There are ten companies headquartered in this imaginary office, and each telephone should be answered as one of these different companies.
The secretary, upon receiving this assignment, realizes that he will have to answer ten different telephones, one for each company. He immediately suggests to the management that they hire nine additional secretaries for each of the nine additional telephones.
The management rejects this proposition as too expensive. At this point, a (questionably) brilliant young manager goes to each of the telephones and uses call forwarding to direct all the incoming calls to a single telephone. This seems to be a good idea, but the secretary has some problems when he answers the incoming calls:
- Hello, Acme Incorporated.
- Excuse me, I was calling Widgets Ltd. Do I have the right number?
- Yes, miss, this is also Widgets Ltd. How may I help you?
The problem here is that the secretary never knows which particular company was contacted. There are many lost calls, and many complaints to management.
In abject frustration, the secretary calls the telephone company to see if they can help. A telephone company technician arrives. She brings a special telephone. This new telephone has an indicator that flashes a different code for each ringing telephone line. Finally, the secretary can determine which company is being called, and has the information to answer the telephone differently.
This situation is very similar to the principles behind WWW virtual hosts.
The Domain Name Service (DNS) is very similar to the telephone book that customers use to look up a company telephone number.
Every internet host has a unique IP Address that corresponds to a telephone number.
A person who receives a telephone call has no information about how their telephone number was found (that is, the text in the telephone book that corresponded to their number).
Usually, every different Web server must have a different IP address (just as every different company must have a different telephone number), even if several of these Web servers run on the same computer.
The major points involved in this process are then:
Let us imagine that the server network card is configured with
a single IP address, and that the names
both resolve to
this same IP address.
Let us further imagine that there is an
file in the document root of the Web
server, and that this document root must be used to serve
different pages for the different companies.
variable contains the URL
used to access the current page. In addition, if
is modified, the browser will immediately
load the new URL contained within the variable.
With this approach, the browser , not the server, makes the decision as to which page to load.
some extent, insuring that it contains the
and a trailing slash. However, you will have to experiment to
insure that all possible URL types are covered.
This method is quite handy for Webmasters who do not have full administrative control of their machine. It is much easier to apply a change to one file than perform extensive reconfiguration of the network interfaces.
However, there are some other problems with this appr oach:
method offers enhanced
flexibility. After the
executed, the user cannot navigate to the previous URL by
is not supported in any of the Netscape
Navigator 2 releases, so version tests must be performed.
Following is an example using
If you are running Red Hat Linux 4.2 with the default kernel, you can skip this section. Red Hat has IP Aliasing compiled as a module right out of the box.
If you have replaced the standard Red Hat kernel, or if you are running a different Linux distribution, you might have to initiate a kernel rebuild after you have ensured that IP Aliasing has been enabled.
Under Linux, the easiest way to reconfigure your kernel build parameters is to issue the command:
cd /usr/src/linux; make menuconfig
as root. You will be presented with a menu of kernel options. Under the networking options, you will find IP: aliasing support .
You can either configure IP Aliasing as a driver included in
the kernel, or as a loadable module. You should be familiar with
the module utilities
before you attempt to configure module
drivers. If you're not comfortable with loadable modules, just
compile the IP aliasing support right into the kernel.
A full discussion of this subject under Linux is available in the IP-Alias-HOWTO .
A general overview of IP aliasing issues on other platforms is available.
Assuming, however, that a Linux system's
Ethernet interface has been configured with IP address 184.108.40.206,
the following commands will configure
to 220.127.116.11 as well:
/sbin/ifconfig eth0:1 18.104.22.168 /sbin/route add -host 22.214.171.124 dev eth0:1
Obviously, no other machine on the network should be using the IP address 126.96.36.199. If you are unsure, do not guess; check with your administrator.
You will probably want to add these commands to your system boot
scripts. Be certain that they execute after your main
A sequence can begin with
and continue to
This allows several virtual IP addresses on one network interface --
up to 255.
Let us say that we have obtained the domain acme.com, and we want to run www.acme.com as a virtual host on 188.8.131.52.
On the pr
imary DNS server, it is necessary to modify the
file. The following line should be
primary acme.com db.acme
There should also be a line near the top of the
file that starts with the word
``directory''. It will be necessary to write a
file into the aforementioned directory on
the DNS server.
file would be of the following form:
@ IN SOA acme.com. root.acme.com. ( 199701010 ; Serial 10800 ; Refresh 1800 ; Retry 3600000 ; Expire 86400 ) ; Minimum IN NS dns1.acme.com. IN NS dns2.acme.com. IN MX 10 mail.acme.com. localh ost IN A 127.0.0.1 acme.com. IN A 184.108.40.206 www IN A 220.127.116.11 mail IN CNAME acme.com. ftp IN CNAME acme.com.
This will make both ``acme.com'' and ``www.acme.com'' the host name of the virtual host.
There are several items above that should be modified for a real installation. The names of the DNS servers (dns1 and dns2) should be configured with the actual DNS server names. And, ``acme.com'' should be replaced with the real domain name, and 18.104.22.168 should be the real IP address.
When you have finished adding the new file, run the Red Hat
to reinitialize your name
server (or send the HUP signal to the
on other platforms - you can do that with:
kill -HUP `cat /var/run/named.pid`
kill -HUP `cat /etc/named.pid`
(depending upon your version of BIND).
This configuration is for a newly-acquired domain name. If you are adding a virtual host to a preexisting domain, your configuration might be quite different.
You will also have to configure your secondary name server(s)
to update from the primary. On each of your secondary DNS
servers, you should place the following line at the end of
secondary acme.com 22.214.171.124 db.acme
above with the IP address of
your primary name server (or the IP address of another secondary,
if you have made the primary unavailable for some reason), then
If you are running your name servers under Red Hat Linux 4.2, you should have applied the DNS security patch . There have been a number of major security holes in Red Hat Linux 4.2; make sure your production systems are up to date.
For information on DNS configuration, you might consult
Tom Yager's article
on the subject
, or the famous book
DNS and BIND, 2nd.
(O'Reilly page), which can also be
purchased at a discount from the Amazon Bookstore
Your Web server must now be configured to serve a different document root to each different domain name.
You can initiate this behavior with the Red Hat Linux Apache
server by adding the followi
ng lines to the end of
<VirtualHost acme.com> ServerAdmin email@example.com DocumentRoot /home/acme/public_html ServerName acme.com ErrorLog logs/acme-error_log TransferLog logs/acme-access_log RefererLog logs/acme-referer_log AgentLog logs/acme-agent_log </VirtualHost>
A number of the above items must be changed for a real installation. The directory of the document root, the server name, and the names of the log files should be customized.
Now, restart your Web server. You should be able to load the new domain and see its relevant default page.
In case of trouble, extra documentation is available at the Apache Web Site .
The Red Hat Web site has very good documentation on this issue in their Red Ha t Sendmail Virtual Hosting Tips .
In this example, the domain
. We will configure Sendmail to route mail addressed to
any user at
The first step is to modify
the names of all the virtual hosts. In the case of
the following lines should be appended:
At this point,
must be modified.
As this is a critical system configuration file, you should
have a backup before you make any changes.
Under Ruleset 98 (search for the string "S98" in the text), append the following line:
R$* < @ $* acme.com. > [tab] $#local $@ $:luser
The only thing that is not specifically mentioned in the Red
Hat documentation is that the
extremely sensitive to placement of
tabs and spaces. The rules
below, which are discussed in the Red Hat documentation, must
have a tab in the indicated position:
R$* < @ $* virtual.com. > [tab] $#local $@ $:luser R$* < @ $* acme.com. > [tab] $(map_virtual $1 $:acme $)
Be certain that you replace the
above with a single tab. Examine the other lines in the section
if the format is not clear.
When you have finished the modifications discussed above, restart Sendmail with the following commands:
/etc/rc.d/init.d/sendmail.init stop /etc/rc.d/init.d/sendmail.init start
If you are not running on Red Hat, send the TERM signal to your sendmail daemon and then restart it with the same options that were used at boot. You also have the option of simply rebooting, or taking the system into single user mode and back to multiuser.
You can then ask Sendmail to whom it would route mail addressed to users in ``acme.com'':
sendmail -bv firstname.lastname@example.org sendmail -bv email@example.com
Both tests should report that the mail would be delivered to user acme at ``isp.net''.
If you are working on another platform, you will have to become familiar with Sendmail rulesets. You might want to start with the Sendmail, 2nd. Edition (O'Reilly page) which can be purchased at a discount from the Amazon Bookstore .
Linux is an ideal platform for many Web server applications, mostly because of its low cost. The GPL release of Red Hat Linux is available from Linux Systems Labs for the cost of the distribution media ($1.95). Linux also includes an unlimited- seat SMB server, FTP, WWW, Telnet, X Window System, NFS, Netware client/server, and electronic mail servers. If you need an inexpensive, reliable virtual host solution that offers the flexibility of Unix, Linux is the way to go.
Well-traveled Unix administrators will undoubtedly implement similar virtual hosts under the major commercial Unix variants (Solaris, AIX, HP-UX, Digital Unix), most probably under Netscape Enterprise Server. The commands change, but the concepts remain the same.
Charles Fisher is a writer and consultant who specializes in Linux. He has a home page that describes his personal and professional interests.
Edited by Becca Thomas / editor at unixworld.com