A Guide to Virtual Services
The point of virtual web services is to present different document trees to users requesting pages from the same machine using different domain names. Users receive the main index page and path names associated with a particular domain name, without any knowledge of the other domains which exist on the same machine.
There are actually two solutions to this problem. The newcomer to the scene uses a fairly elegant method where the client, in its request, also specifies the exact target it was looking for. However, this works only for web services, and only with quite recently released clients from Microsoft and Netscape. If you want to support everybody without relying on the client to make your services work, you will need another solution.
The problem is fairly simple once you understand it. You need a modified HTTP daemon listening to requests coming in to a specific IP address, rather than all those directed to the current machine. Then a server is started for each virtual client, with options specifying different configuration files, document source trees, and so on.
Most web servers now support the requirements for virtual services, but some do not. You will need at least version 1.5 if you use the NCSA server. I use the Apache server, version 1.1.1. Other servers designed as “drop-in” replacements for the NCSA daemon should have this capability, but you should check your server documentation for details on configuring this feature.
To date, almost every server has a different configuration. This article covers the Apache daemon only because it is what the author uses, not because the author considers the server to be more or less capable than any other.
Once you have ping working on the two domain names, you can begin to configure your virtual web services. The most important thing is to select an intelligent document tree layout. If you only have a few clients, you might have a single source root with different subdirectories, one per client. Their tree would then be rooted at their respective subdirectory. If you have more clients, you may need a more complex layout. It is important to decide this now because changing it later can become quite messy.
In your server configuration file, you need to set up services for each domain. This is easily done in Apache by enclosing configuration statements within a <VirtualHost> container. For example, the following configuration for 10.1.1.6 (the IP address we obtained for www.tryme.com) would be changed from:
ServerName www.tryme.com ServerAdmin firstname.lastname@example.org DocumentRoot /usr/web/tryme/docs TransferLog /usr/web/tryme/access.log ErrorLog /usr/web/tryme/errors.log
<VirtualHost 10.1.1.6> ServerName www.tryme.com ServerAdmin email@example.com DocumentRoot /usr/web/tryme/docs TransferLog /usr/web/tryme/access.log ErrorLog /usr/web/tryme/errors.log </VirtualHost>This will instruct Apache (and several other similar daemons) to accept requests with those configuration parameters only for those requests directed to 10.1.1.6, in this case www.tryme.com.
Note that this automatically disables server-hosting, and any other targets must be set up as well, or they will not be accessible. Normally, if a machine had several IP addresses, requests directed at any address would be serviced. Including a <VirtualHost> specification prevents this activity. Also note that virtual hosting in Apache can include an optional port number (e.g., <VirtualHost 10.1.1.6:8080>) to provide services for a specific port.
Once you have this configured, start or restart the web daemon, and you should be configured for virtual web services! Next month we examine virtual e-mail and FTP services, and new techniques that provide similar functionality.
Chad Robinson is the Senior Systems Analyst for BRT Technical Services Corporation. He can usually be found behind a monitor and a keyboard, especially if they are hooked to a system running Linux. When he's not programming or administering systems, he is usually spending time with his love, Alison.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Profiles and RC Files
- Understanding Ceph and Its Place in the Market
- Astronomy for KDE
- Git 2.9 Released
- Maru OS Brings Debian to Your Phone
- OpenSwitch Finds a New Home
- What's Our Next Fight?
- The Giant Zero, Part 0.x
- Snappy Moves to New Platforms
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide