asg04.htm

apache技术手册

<BR>

<P>Solaris supports virtual interfaces in the form of logical units. You can have up to 255 logical units per network interface. To add a new virtual host to the primary interface, just type the following:

<BR>

<P>ifconfig le0:<I>logicalunit</I> 204.95.222.200 up

<BR>

<P>Replace <I>logicalunit</I> with a number from 1 to 255. You can check currently used interfaces by issuing netstat -ia.

<BR>

<BR>

<A NAME="E69E27"></A>

<H4 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>The VIF Patch</B></FONT></CENTER></H4>

<BR>

<P>The VIF patch was one of the first solutions available on the Internet to enable a single interface to handle multiple IP addresses. The VIF patch was originally developed by John Ioannidis in 1991 as part of a project related to his Ph.D. thesis at Columbia University. The patch was pared down in 1994 to allow a single interface to handle multiple IP addresses under SunOS. The patch was further enhanced for SunOS 4.1.<I>x</I> by Chuck Smoko and Bob Baggerman. Two separate Ultrix 4.3a ports have been developed, one by John Hascall and the other by Phil Brandenberger .

<BR>

<P>The VIF patch creates a virtual interface that, to the networking software, looks like a hardware interface. The VIF interface allows you to assign an address as well as to configure network interface parameters with ifconfig.

<BR>

<P>After the virtual interface has been configured, you may have to add routing entries to the routing table using the route command. However, some implementations do the right thing without this step. For more information, refer to the instructions for your operating system. The VIF allows requests to any of the host's addresses, real or virtual, to be answered by the real interface. Packets leaving the host use the real or virtual IP assigned to match where they are coming from.

<BR>

<P>Detailed instructions on how to build the patch and incorporate it into the kernel, and how to use VIF for each specific architecture, are included in the source. You can obtain the latest version of the VIF patch from these repositories:

<BR>

<UL>

<LI>John Hascall's latest ULTRIX modifications can be found at <A HREF="javascript:if(confirm('ftp://ftp.iastate.edu/pub/unix/ultrix/vif/  \n\nThis file was not retrieved by Teleport Pro, because it did not meet the project\'s file type specifications.  \n\nDo you want to open it from the server?'))window.location='ftp://ftp.iastate.edu/pub/unix/ultrix/vif/'" tppabs="ftp://ftp.iastate.edu/pub/unix/ultrix/vif/"> ftp://ftp.iastate.edu/pub/unix/ultrix/vif/</A>.

<BR>

<BR>

</UL>

<BR>

<A NAME="E69E28"></A>

<H4 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>PPP</B></FONT></CENTER></H4>

<BR>

<P>If your UNIX vendor didn't provide you with the sources to the kernel, then PPP software (used for establishing dial-up networking connections) may be your only viable alternative to create a multihomed host. NEXTSTEP, the operating system I use at accessLINK, doesn't come with the source to its Mach kernel, so I developed this workaround. The result is almost an equivalent to the VIF patch, and its effects are easily removed from a system. This solution should be very portable across various UNIX boxes.

<BR>

<P>PPP provides networking interfaces, which you can configure much in the same way as VIF interfaces, with these advantages:

<BR>

<UL>

<LI>PPP's effects can be easily removed and isolated. If things are not working properly, you don't have to worry about irreversible changes made to the kernel.

<BR>

<BR>

<LI>Some vendors' systems already ship with PPP software preinstalled, making it easy to implement.

<BR>

<BR>

<LI>PPP is portable.

<BR>

<BR>

</UL>

<BLOCKQUOTE>

<BLOCKQUOTE>

<HR ALIGN=CENTER>

<BR>

<NOTE><A NAME="I3"></A>The PPP in your distribution may already have one or two PPP interfaces available named ppp0 or ppp1. You can check the number of interfaces your vendor provides by executing the following command:

<BR>% netstat - ia

<BR>PPP interfaces will be listed as ppp0 though ppp<I>X</I>. If you only need one or two virtual machines, you may be able to use your preinstalled version of ppp.</NOTE>

<BR>

<HR ALIGN=CENTER>

</BLOCKQUOTE></BLOCKQUOTE>

<P><A NAME="I4"></A>If you need additional interfaces, you will have to obtain the source code to the basic PPP software plus the system-specific changes for your operating system. You will also have to edit one of the header files to add the additional interfaces.

<BR>

<P>You can find the latest release to the source code for the PPP software at <A HREF="javascript:if(confirm('ftp://dcssoft.anu.edu.au/pub/ppp  \n\nThis file was not retrieved by Teleport Pro, because it did not meet the project\'s file type specifications.  \n\nDo you want to open it from the server?'))window.location='ftp://dcssoft.anu.edu.au/pub/ppp'" tppabs="ftp://dcssoft.anu.edu.au/pub/ppp"> ftp://dcssoft.anu.edu.au/pub/ppp</A> and <A HREF="javascript:if(confirm('ftp://ftp.merit.edu/pub/ppp  \n\nThis file was not retrieved by Teleport Pro, because it did not meet the project\'s file type specifications.  \n\nDo you want to open it from the server?'))window.location='ftp://ftp.merit.edu/pub/ppp'" tppabs="ftp://ftp.merit.edu/pub/ppp"> ftp://ftp.merit.edu/pub/ppp</A>.

<BR>

<P>After you configure the software for your particular machine, modify the number of interfaces to match your needs. In the pppd.h file, found on the pppd distribution, find the line that contains the following definition:

<BR>

<BR>

<PRE>

<FONT COLOR="#000080">#define NUM_PPP 2</FONT></PRE>

<P>The number to the right of NUM_PPP (in this case, 2)defines how many PPP interfaces are to be compiled into the software. Change this number to the number of interfaces you think you'll be needing plus a few more. I changed mine to add 25 interfaces.

<BR>

<P>In the NeXTSTEP-specific distribution of the PPP software, which is based on ppp-2.2, the defined NUM_PPP may be found on additional files. Do a grep to find them and change all instances to match the number of interfaces you want.

<BR>

<P>You should be able to build a customized version of your kernel or a kernel loader that adds supports for PPP. Read the installation instructions for your particular system.<A NAME="I5"></A> Once this is installed, you are ready to configure the interfaces.

<BR>

<BR>

<A NAME="E70E2"></A>

<H5 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Configuring the PPP Interfaces</B></FONT></CENTER></H5>

<BR>

<P>By default, PPP interfaces are named ppp0, ppp1, ppp2, and so on. It is a good idea to set up the interfaces right after the machine boots. This way you can be confident that the Web server will be accepting requests for all sites at boot time.

<BR>

<P>I suggest putting your configuration entries into your rc.local or, if you have many entries, creating your own rc.ppp.

<BR>

<P>To assign an address to an interface, I use the following commands. Your version of UNIX may provide additional or different options to these commands. Check the main page of your system prior to issuing any of these commands:

<BR>

<UL>

<UL>

<PRE>

<FONT COLOR="#000080">ifconfig ppp0 204.95.222.200 up netmask 255.255.255.0

route add host 1.2.3.4 1.2.3.4 0

arp -s 1.2.3.4 00:00:00:00:00 pub</FONT></PRE></UL></UL>

<P>In the previous example, I added a virtual host at address 1.2.3.4. Simply replace 1.2.3.4 with the address of your machine. Replace 255.255.255.0 with the netmask used in your network. Replace 00:00:00:00:00 with the Ethernet address of your networking card.

<BR>

<BLOCKQUOTE>

<BLOCKQUOTE>

<HR ALIGN=CENTER>

<BR>

<NOTE>Make sure you update your DNS to include the virtual machine. Otherwise, a client won&#146;t be able to find the new virtual address!</NOTE>

<BR>

<HR ALIGN=CENTER>

</BLOCKQUOTE></BLOCKQUOTE>

<P>The previous commands do the following:

<BR>

<UL>

<LI>[lb] The ifconfig command assigns the IP and netmask to the ppp0 interface.

<BR>

<BR>

<LI>The route command adds a static routing entry the destination and gateway IP. Refer to the virtual IP address you assigned to the PPP interface.

<BR>

<BR>

<LI>The arp command modifies the Internet-to-Ethernet address translation tables. The -s option was given to create an arp entry for the hostname, here specified in IP notation. The pub option will &quot;publish&quot; the arp for the host, even though the address is not its own (it's virtual!).

<BR>

<BR>

</UL>

<P>You can verify that the interfaces provided by PPP were incorporated into the kernel by issuing this:

<BR>

<BR>

<PRE>

<FONT COLOR="#000080">/usr/etc/netstat -ia</FONT></PRE>

<P>You should be able to see a number of ppp<I>n</I> interface names listed and be able to test whether the interfaces and the DNS are working properly. You will need to test from a machine other than the Web server. A limitation of PPP virtual hosts is that a virtual host is unreachable from the server that hosts it. However, that is not really a problem because your server is dedicated, right? To test that the virtual host is running, simply ping the virtual host. You should be get a response like the following:

<BR>

<PRE>

<FONT COLOR="#000080">hydrogen:4# /etc/ping <I>1.2.3.4</I>

PING helium: 56 data bytes

64 bytes from 204.95.222.2: icmp_seq=0. time=4. ms

64 bytes from 204.95.222.2: icmp_seq=1. time=2. ms

64 bytes from 204.95.222.2: icmp_seq=2. time=2. ms

64 bytes from 204.95.222.2: icmp_seq=3. time=2. ms

64 bytes from 204.95.222.2: icmp_seq=4. time=2. ms

64 bytes from 204.95.222.2: icmp_seq=5. time=2. ms </FONT></PRE>

<P>Replace <I>1.2.3.4</I><I> </I>with the virtual IP address that you assigned earlier.

<BR>

<BR>

<A NAME="E68E33"></A>

<H3 ALIGN=CENTER>

<CENTER>

<FONT SIZE=5 COLOR="#FF0000"><B>Apache Non-IP Virtual Hosts</B></FONT></CENTER></H3>

<BR>

<P>Starting with version 1.1, Apache added support for virtual hosts without the need for additional IP addresses. This greatly simplifies the management process of the server since it removes the hardest configuration problem from the list: how to get a machine to answer to multiple IP addresses.

<BR>

<P>Apache's implementation of non-IP virtual hosts depends on the client browser to provide information about the server being accessed. At the time of this writing, many browsers, including Netscape 2.0 or better and Microsoft's Internet Explorer 2.0 and better, support this feature.

<BR>

<P>The great advantage to non&#150;IP-intensive virtual hosts is that now there are no limits to the number of virtual sites you can host. Before, the number of virtual hosts you could support was dependent on how many IP addresses you had available for hosts. Now, a single IP address can support an unlimited number of sites without having to rely on software, such as PPP or kernel patches, to get the machine to multihome.

<BR>

<P>The new modifications to the &lt;VirtualHost&gt; section look almost identical to the old version:

<BR>

<PRE>

<FONT COLOR="#000080">&lt;VirtualHost www.company.com&gt;

 ServerName www.company.com

 ServerAlias company.com *.company.com

 DocumentRoot /usr/local/htdocs/company

&lt;/VirtualHost&gt;</FONT></PRE>

<P>Just add as many &lt;VirtualHost&gt; sections (one per virtual site as you need) to your httpd.conf configuration file and restart the server.

<BR>

<P>Additional directives can still be placed in the section. All you need to do to get the virtual server to work is add a DNS entry for www.company.com that points to your server's real address. Unlike IP-intensive virtual hosts, the IP of the virtual sites is the same as that of the real host.

<BR>

<P>A new directive, ServerAlias, allows you to reference a virtual host section configuration by other names. You must, of course, have DNS entries for each alias that point to the same IP address for this feature to work.

<BR>

<BR>

<A NAME="E69E29"></A>

<H4 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>A Workaround for Clients That Don't Support Non-IP Virtual Hosts</B></FONT></CENTER></H4>

<BR>

<P>Client browsers that do not support the non-IP virtual hosts will get the server's real main page. A fully qualified path link to your server will let the client access your materials. If your link points to the same URL, you'll create an endless loop. With careful use of the new ServerPath directive, you can redirect traffic to the right place.

<BR>

<P>The ServerPath directive should be placed in the VirtualHost section. The directive looks like this:

<BR>

<PRE>

<FONT COLOR="#000080">&lt;VirtualHost www.company.com&gt;

ServerName www.company.com

DocumentRoot /usr/local/htdocs/company

ServerPath /company 

&lt;/VirtualHost&gt;</FONT></PRE>

<P>The preceding ServerPath directive will redirect all requests beginning with the /company path to /usr/local/htdocs/company, the correct place. Your HTML documents should contain only relative links; this will make your files accessible from any browser.

<BR>

<BR>

<A NAME="E68E34"></A>

<H3 ALIGN=CENTER>

<CENTER>

<FONT SIZE=5 COLOR="#FF0000"><B>Summary</B></FONT></CENTER></H3>

<BR>

<P>With the ability to control most aspects of the server behavior on a per-virtual-host basis, multihoming is very powerful indeed. The downside of multihoming is that the load processed by a single machine is increased. One machine is going to handle all the requests for all the sites you host in it. If these requests require several connections per second, performance may degrade below acceptable levels depending on the supporting network and computer hardware. However, there are ways of eliminating these bottlenecks and obtaining the administrative benefits of a multihomed Web server. In &quot;Increasing Performance,&quot; I discuss how to distribute user load between several mirrored Web servers.

<BR>

<P>The advantages of multihoming greatly outweigh any downsides. If your traffic load is heavy, you're probably interested in distributing the load. An infrastructure of multihomed distributed servers may be your best plan. By making all your servers clones of each other, you have in fact created a fault-tolerant information service. Should one machine go down, access to the site is unaffected. Other servers will handle requests for the non-operational server. This is good because it may reduce the urgency of a disaster situation and because it will allow you to maintain a high-level performance site at a low cost.

<BR>

<P>Using a single server to host various Web sites reduces the cost of the hardware, maximizes the use of computer and network hardware, and at the same time reduces the number of administrative chores. All this occurs because there is only one machine to set up, one machine to troubleshoot, one machine to upgrade, one machine to monitor, and one machine to back up.

<BR>

<P>One is a good number. The most valuable resource of a Web site is the time of the webmaster, so reducing his workload is a good thing. If you are running more than one HTTP server hosting different content, you may want to evaluate whether this feature can make your life easier as well.<A NAME="I6"></A>

<BR>

<P ALIGN=LEFT>

<A HREF="asgpt2.htm" tppabs="http://docs.rinet.ru:8080/Apachu/asgpt2.htm" TARGET="_self"><IMG SRC="purprev.gif" tppabs="http://docs.rinet.ru:8080/Apachu/purprev.gif" WIDTH = 32 HEIGHT = 32 BORDER = 0 ALT="Previous Page"></A>

<A HREF="#I0" TARGET="_self"><IMG SRC="purtop.gif" tppabs="http://docs.rinet.ru:8080/Apachu/purtop.gif" WIDTH = 32 HEIGHT = 32 BORDER = 0 ALT="Page Top"></A>

<A HREF="index.htm" tppabs="http://docs.rinet.ru:8080/Apachu/index.htm" TARGET="_self"><IMG SRC="purtoc.gif" tppabs="http://docs.rinet.ru:8080/Apachu/purtoc.gif" WIDTH = 32 HEIGHT = 32 BORDER = 0 ALT="TOC"></A>

<A HREF="asg05.htm" tppabs="http://docs.rinet.ru:8080/Apachu/asg05.htm" TARGET="_self"><IMG SRC="purnext.gif" tppabs="http://docs.rinet.ru:8080/Apachu/purnext.gif" WIDTH = 32 HEIGHT = 32 BORDER = 0 ALT="Next Page"></A>


</BODY></HTML>