Unix Split Personality: How to Virtual Host
By Charles Fisher
Every serious Webmaster must know how to host multiple virtual Web sites upon a single server. As Unix remains the most popular Web server platform, the core of interest in virtual domains lies within this environment. This article will present general principles behind virtual hosts upon all versions of Unix, and the specific configuration commands required to configure virtual hosting on Red Hat Linux and the Apache Web Server.
Questions regarding this article should be directed to the author at email@example.com
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 is sues 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:
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 correspo nds 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
Let us further imagine that there is an
With this approach, the browser , not the server, makes the decision as to which page to load.
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:
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 r econfigure 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
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
/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
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
primary acme.com db.acme
There should also be a line near the top of the
@ 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
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
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 firstname.lastname@example.org 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
The first step is to modify
At this point,
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
R$* < @ $* virtual.com. > [tab] $#local $@ $:luser R$* < @ $* acme.com. > [tab] $(map_virtual $1 $:acme $)
Be certain that you replace the
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 email@example.com sendmail -bv firstname.lastname@example.org
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 p rofessional interests.