Historical information collectors portal, electronic museum 'ВиФиАй' work-flow-Initiative 16+
СОХРАНИ СВОЮ ИСТОРИЮ НА СТРАНИЦАХ WFI Категории: Актуальное Избранное Telegram: Современная Россия
Исторический альманах, портал коллекционеров информации, электронный музей


Quick Links


Подписка и соц. сети

Subscribe to site updates



New Materials

Картинка недели

Back to topBack to top
To the end
To the end
Create a personal gallery (section)Create a personal gallery (section)
Create a personal album (with images)Create a personal album (with images)
Create articleCreate article


Evaluation section:
Do not like
To developers...


One Machine, Multiple Domains

Date of publication: 2017-10-17 16:26:05
Дата модификации: 2017-10-17 16:26:05
Views: 1613
One Machine, Multiple Domains
You can serve two or more different domains from one server. Just to prove my point, click here and now here. Both of these links came from the same machine over the same Ethernet interface, which you can verify with a simple traceroute command. This page will tell how to accomplish this, and assuming you have the right hardware and software, you will be able to do this yourself.
How Does It Work?
First, let's dispell a common myth. This can not be done with simple DNS aliasing of one domain to another. Let's repeat this together so we don't quickly forget. This can not be done with simple DNS aliasing of one domain to another. If you feel that thought slipping away you may want to chant that statement a few times.
Some of you may be asking, why? Well, the reason is the client does not send the host name as part of the request. The http://www.foo.com is stripped from the request so the server does not know the target host for the request. Without that piece of information, the host can not map between multiple domains based on the request data alone.
Another popular belief is you can run different HTTP daemons on different ports and do the mapping with DNS. This can not be done. DNS does not return port numbers with a host name lookup. It simply returns the IP address. The client program is expected to know on what port the service is listening. You will still have to include the port number in the URL, which is not a very polite solution.
Okay, so how is it done? Well, each domain is assigned its own IP address. In the case above, they are both on the same Class C address. Using the same Class C is not necessarily required, depending on the support provided by your software.
So the first piece of magic, and this is really important, is you must convince your machine to answer to multiple IP addresses. Most versions of Unix will do this, although many will require a patch from the vendor, or a solution from the net.
The general solution for supporting multiple aliases, is the BSD ifconfig alias option. Many operating systems support this directly, or with a patch. Solaris 2.3 and later versions support a similar, but syntactically different mechanism based on interface logical units. The following table identifies the support for various platforms.
Operating System Support
AIX 4.1 ifconfig alias
BSDI ifconfig alias
Digital Unix
DEC OSF/1 ifconfig alias
FreeBSD ifconfig alias
HPUX 9.x VIF Patch
HPUX 10.x ifconfig alias 
Patch needed
IRIX 5.3 ifconfig alias 
Need SGI patch 1092
Linux ifconfig alias 
Patch needed
SunOS 4.x VIF Patch
Solaris >2.3 
SunOS >5.3 ifconfig logical units
Ultrix VIF Patch
Alias Example
So, lets assume you have two hosts with the following DNS records:
www.a.com IN A 
www.b.com IN A
If you have the ifconfig alias option you will make your Ethernet interface answer to both with the following commands.
ifconfig le0 www.a.com 
ifconfig le0 www.b.com alias
HTTPD Server Configuration
NCSA 1.5 supports virtual hosting without modification. Information on configuration 1.5 for virtual hosting can be found at the NCSA documentation site.
The CERN server change described here was made by me. Fortunately, the CERN httpd authors had done the really grungy work to make it possible so the changes to the code are very small and localized.
The concept behind the change is to have the CERN server bind to the address specified by HostName directive in the configuration file. You will need a configuration file for each domain name you plan to support. In addtion, you will have to run one httpd process for each domain you plan to support.
You must have the full source (including the library ) to the CERN server to install this patch. The HTDaemon.c.multi file must be placed in the WWW/Daemon/Implementation directory. You should save the current HTDaemon.c and replace it with the patched one. Once this is done, build the server following the CERN instructions.
Now you are ready to bring up the servers. I've crafted a simple config file for www.a.com and www.b.com using the sample CERN httpd.conf file as a starting point. The only two lines that were changed were the addition of the HostName directive, and the new Path directory path.
It is critically important that the HostName directive be provided and have a real host specified. I did not spend a lot of time (any?) adding code to deal with configuration errors. This entire process is for the advanced WWW admin so a certain level of tolerance and ability were assumed. I did add some tracing statements during the bind, so turn on the server debugging if you have problems. The errors should help you sort out the problem.
John Hascall has put together an alternate set of patches for the CERN server. He also has patches that support preforking servers.
The Apache server supports virtual hosting. The Apache documentation covers configuring Apache for virtual hosting.
Netscape describes how to virtual host Netsite in Technical Note 20111. Note: Netscape regularly moves files around at their site. If this link is broken drop me a note and I'll go track it down again.
What About Problems?
This document does discuss some pretty complex stuff, and I must admit that I have not tested most of the stuff here. In fact, the only instructions I have done myself are configuring Solaris and IRIX, and setting up the CERN and Netsite server. The rest has been gathered from various people around the net who provided me with information.
If this doesn't work for you, and you are on Solaris or IRIX, send me some mail and I'll try to help you sort it out. I will warn you up front though that this is not a priority for me and I only can help if I don't have real fires of my own to put out.
If you are on some other platform, then the newsgroup is your best bet. All of the information here has been posted at least once (except perhaps the IRIX stuff) and the people that fed content are out there. Beware, however, there are plenty of incorrect answers posted on this subject as well.
Finally, if you have additions, corrections, or comments, drop me a note, and I will incorporate your content as quickly as possible.
The information on this page has been evolving, although slowly due to an overworked editor. I would like to thank A.P. Barret for the NCSA patch and James Grinter for sending it to me. Erin Y. Zhu gets extra points for providing a patched source tree.
Peggy Cheng was kind enough to pull together all of the work she did to make this work on SunOS 4.1.x and provide us with a Web page. Brian Gann pointed me at his information on configuring PPP for SunOS 4.1.x. Robert Sanders created the ifconfig patch for Linux.
Evaluation of the document:
Do not like
Article description: You can serve two or more different domains from one server. Just to prove my point, click here and now here.

Other articles of the section: Developers

Previous Integration SpiderBasic and WFI

Leave a comment

Новые альбомы:

Neighboring Topics

Development page is completed by 0%
Используйте средства защиты! Соблюдайте гигиену! Избегайте посещения людных мест!