| Sun ONE Application Server 7 Administrator's Guide |
Chapter 15
Using Virtual ServersThis chapter explains how to set up and administer virtual servers using your Sun ONE Application Server. For information on configuring settings for virtual server content, see Chapter 16, "Managing Virtual Server Content."
This chapter includes the following topics:
Virtual Servers OverviewWhen you use virtual servers you can offer companies or individuals domain names, IP addresses, and some server monitoring capabilities with a single installed server. For the users, it is almost as if they have their own web servers, though you provide the hardware and maintain the virtual servers.
When you install the unbundled version of the Sun ONE Application Server, a default virtual server for the application server instance is created. That is, for the default application server instance server1, a virtual server named server1 is also created. If you are using the Solaris 9 bundled version, you need to create a server instance. When you create it, a virtual server with the same name is also created. A virtual server is created for each additional application server instance you create. For more information on creating and configuring virtual servers, see "Creating and Configuring Virtual Servers". For more information on deploying virtual servers, see "Deploying Virtual Servers."
This virtual server controls the Sun ONE Application Server’s HTTP features that are available on a per-virtual server basis. You may not want to use multiple virtual servers, but you still configure certain properties for your application server instance by configuring the default virtual server created with that application server instance.
The settings for virtual servers are stored in the virtual-server element in the server.xml file, found in the instance_dir/config directory. For more information about this file, see the Sun ONE Application Server Administrator’s Configuration File Reference.
Some information pertaining to a virtual server is stored in its obj.conf file. Each virtual server has a separate obj.conf file.
This section includes the following topics:
HTTP Listeners
Connections between the server and clients happen on an HTTP listener, also called a listen socket. Each HTTP listener you create has an IP address, a port number, a return server name, and a default virtual server. If you want an HTTP listener to listen on all configured IP addresses on a given port for a machine, use 0.0.0.0, any, ANY, or INADDR_ANY for the IP address. For more information on creating and configuring HTTP Listeners, see "Creating and Configuring HTTP Listeners".
When you install the unbundled version of Sun ONE Application Server, one HTTP listener, http-listener-1, is created automatically. This HTTP listener uses the IP address 0.0.0.0 and the port number you specified as your HTTP server port number during installation (the default is 80, or 1024 on UNIX if you are not installing as root). You cannot delete the default HTTP listener. If you are using multiple virtual servers, you can either use the default HTTP listener for all virtual servers, or create multiple HTTP listeners.
When you use the Solaris 9 bundled Sun ONE Application Server, your HTTP listener is created when you create the server instance. It has the IP address 0.0.0.0 and the port number you specified when you created your instance.
Since an HTTP listener is a combination of IP address and port number, you can have multiple HTTP listeners with the same IP address and different port numbers, or with different IP addresses and the same port number. For example, you could have 1.1.1.1:81 and 1.1.1.1:82. Additionally, you could have 1.1.1.1:81 and 1.2.3.4:81, as long as your machine is configured to respond to both these addresses. However, if you use the 0.0.0.0 IP address, which listens on all IP addresses on a port, you cannot set up HTTP listeners for additional IP addresses that listen on the same port for a specific IP address. For example, if you have an HTTP listener using 0.0.0.0:80 (all IP addresses on port 80) you cannot also create an HTTP listener which uses 1.2.3.4:80.
Each HTTP listener also has a default virtual server, which is the server to which it routes requests if it can’t connect to the virtual server specified in the request.
In addition, you specify the number of acceptor threads (sometimes called accept threads) in the HTTP listener. Accept threads are threads that wait for connections. The threads accept connections and put them in a queue where they are then picked up by worker threads. Ideally, you want to have enough accept threads so that there is always one available when a new request comes in, but few enough so that they do not provide too much of a burden on the system. The default is 1. A good rule is to have one accept thread per CPU on your system. You can adjust this value if you find performance suffering.
You also specify whether security is enabled for an HTTP listener and what kind of security you are using (for example, what kind of SSL and which ciphers).
Virtual Servers
To create a virtual server you must first decide what kind of virtual server you want. You can have an IP-address-based virtual server, or a URL-host-based virtual server. To create a virtual server, all you need to specify is a virtual server ID, one or more HTTP listeners, and one or more URL hosts.
This section includes the following topics:
Types of Virtual Servers
All virtual servers have a URL host specified. However, the virtual server may also be associated with an IP address based on an HTTP listener. If the virtual server’s HTTP listener listens on a specific IP address, the virtual server is called an IP-address-based virtual server.
If several virtual servers listen on the same IP address, they are distinguished by the URL host, and are URL-host-based virtual servers.
When a new request comes in, the server determines which virtual server to send it to based on the IP address or the value in the Host header. It evaluates the IP address first. For more information, see "Virtual Server Selection for Request Processing".
IP-Address-Based Virtual Servers
In order to have multiple IP addresses on a single computer, you must either map them through the operating system or provide additional cards. To set up multiple IP addresses through the operating system, use the Network Control Panel (Windows) or the ifconfig utility (UNIX). Please note that directions for using ifconfig vary from platform to platform. Consult your operating system documentation for more information.
You create an IP-address-based virtual server by creating an HTTP listener that listens on a specific IP address. You then associate a virtual server as the default virtual server for the HTTP listener. For more information on ways to deploy virtual servers, see "Deploying Virtual Servers".
URL-Host-Based Virtual Servers
You can set up URL-host-based virtual servers by giving them unique URL hosts. The contents of the Host request header directs the server to the correct virtual server.
For example, if you want to set up virtual servers for customers aaa, bbb, and ccc) so that each customer can have an individual domain name, you first configure DNS to recognize that each customer’s URL (www.aaa.com, www.bbb.com, www.ccc.com) resolves to the IP address of the HTTP listener you are using. You then set the URL hosts for each virtual server to the correct setting (for example, www.aaa.com). Note that you map hosts to IP addresses in the /etc/hosts file.
You can have any number of these URL-host-based virtual servers associated with an HTTP listener.
Because URL-Host-based virtual servers use the Host request header to direct the user to the correct page, not all client software works with them. Older client software that does not support the HTTP Host header won’t work. These clients will receive the default virtual server for the HTTP listener.
Default Virtual Server
URL-Host-based virtual servers are selected using the Host request header. If the end user’s browser does not send the Host header, or if the server cannot find the specified Host header, the default virtual server for the HTTP listener services the request.
Also, for IP-address-based virtual servers, if Sun ONE Application Server cannot find the specified IP address, the default virtual server for the HTTP listener services the request. You can configure the default virtual server to send an error message, or server pages from a special document root.
You specify a default virtual server when you create an HTTP listener. You can always change the default virtual server.
The obj.conf File
By default, each virtual server has a separate obj.conf file where virtual server settings are stored. When you change settings through the Administration interface or command-line interface, those changes are made automatically in the configuration files, including the virtual server’s obj.conf file. All obj.conf files are located in the instance_dir/config directory. Whenever this guide refers to “the obj.conf file,” it refers to all obj.conf files or to the obj.conf file for the virtual server being described.
The file named obj.conf that lacks a prefix is a template that Sun ONE Application Server uses to create obj.conf files for each virtual server. Editing this file does not affect any existing virtual servers, but does affect any subsequently created virtual servers. For more information on editing the obj.conf file directly, see the Sun ONE Application Server Administrator’s Configuration File Reference.
By default, each active obj.conf file is named virtual_server_name-obj.conf. Because the default virtual server for a server instance is named after the instance, when you first create a server instance, its obj.conf file is named instance_name-obj.conf. Editing one of these files directly or through the Administration interface changes the configuration of a virtual server.
Virtual Server Selection for Request Processing
Before the server can process a request, it must accept the request via an HTTP listener, then direct the request to the correct virtual server. This section discusses how the virtual server is determined.
- If the HTTP listener is configured to only a default virtual server, that virtual server is selected.
- If the HTTP listener has more than one virtual server configured to it, the request Host header is matched to the hosts attribute of a virtual server. If no Host header is present or no hosts attribute matches, the default virtual server for the HTTP listener is selected.
If a virtual server is configured to an SSL HTTP listener, its hosts attribute is checked against the subject pattern of the certificate at server startup, and a warning is generated and written to the server log if they don’t match.
After the virtual server is determined, the Sun ONE Application Server executes the virtual server’s obj.conf file. For details about how the server decides which directives to execute in obj.conf, see the Sun ONE Application Server Administrator’s Configuration File Reference.
Document Root
The document root (sometimes called the primary document directory) is the central directory that contains all the virtual server’s files you want to make available to remote clients.
The document root directory provides an easy way to restrict access to the files on a virtual server. It also makes it easy to move documents to a new directory (perhaps on a different disk) without changing any of the URLs because the paths specified in the URLs are relative to the primary document directory.
For example, if your document directory is install_dir/docs, a request such as http://www.sun.com/products/info.html tells the server to look for the file in install_dir/docs/info.html. If you change the document root (that is, you move all the files and subdirectories), you only have to change the document root that the virtual server uses, instead of mapping all URLs to the new directory or somehow telling clients to look in the new directory.
The document root for your default Sun ONE Application Server instance (server1) becomes the document root for the virtual servers created within the server1 application server instance. You can override that directory for each virtual server you create.
Using Sun ONE Application Server Features with Virtual ServersSun ONE Application Server has many features, such as SSL and access control, that you can use with virtual servers. The following sections describe the features and provide information on where to look for more information.
This section includes the following topics:
Using SSL with Virtual Servers
If you want to use SSL on a virtual server, in most cases you use an IP-address-based virtual server. The customary port is 443. It is difficult to use SSL on a URL-host-based virtual server because Sun ONE Application Server must read the request before determining which URL host to send the request to. Once the server reads the request, the initial handshake, where security information is exchanged, has already happened.
The only exception is when URL-Host-based virtual servers all have the same SSL configuration, including the same server certificate, using “wildcard certificates.” For more information, see the Sun ONE Application Server Administrator’s Guide to Security.
One way to implement SSL with virtual servers is to have two HTTP listeners, one using SSL and listening to port 443, and one that is not using SSL. A user would typically access the virtual server through the non-SSL HTTP listener. When the need to have secure transactions arises, users could click a button on the web page to start initiating secure transactions. After that, the requests go through the secure HTTP listener.
Because SSL transactions are much slower than non-SSL transactions, this design limits the SSL transactions to only the ones that are necessary. Faster, non-SSL connections are used the rest of the time.
For more information on setting up and using security with you Sun ONE Application Server and virtual servers, see the Sun ONE Application Server Administrator’s Guide to Security. For a diagram of a sample SSL configuration with virtual servers, see "Example 2: Secure Server".
Using Access Log Files and Server Log Files
The access log file is the file where HTTP accesses to the virtual server are logged. When you create a new virtual server, by default the access log file is the same log file as the application server instance. In many cases you will want each individual virtual server to have its own log file. To set this up, you can change the log path for each virtual server. If you want to keep all virtual server accesses logged to the same access log file, you can change the logging settings for the server instance so that the virtual server ID is included in the log file. For more information on changing the application server instance’s logging, see Chapter 5, "Using Logging."
The server log file is the file where informational messages and errors are logged. When you create a new virtual server, its log file by default is the same as the log file for the application server instance. You can change the log file for each virtual server.
Using Access Control with Virtual Servers
With virtual servers you have the ability to set up access control on a per virtual server basis. You can even configure it so that each virtual server can have user and group authentication using an LDAP database. For more information, see the Sun ONE Application Server Administrator’s Guide to Security.
Using CGIs with Virtual Servers
You can use CGIs on virtual servers. You need to set up the directories where CGIs will be stored on each virtual server and set a file type for the CGI. For more information on CGIs, see the Sun ONE Application Server Developer’s Guide to Web Applications.
Creating and Configuring HTTP ListenersBefore the server can process a request, it must accept the request via an HTTP listener, then direct the request to the correct virtual server. One HTTP listener, http-listener-1, is created automatically when a server instance is created (either during installation or later). This HTTP listener uses the IP address 0.0.0.0 and the port number you specified as your application server port number. You cannot delete the default HTTP listener.
This section covers the following topics:
Creating an HTTP Listener
To create an HTTP listener using the Administration interface:
- In the left pane, for the application server instance, open HTTP Server.
- Click HTTP Listeners.
- Click New.
- Fill in the fields.
HTTP listeners must have a unique combination of port number and IP address. You can use either IPV4 or IPV6 addresses. If you want to create an HTTP listener for IP-address-based virtual servers, specify a particular IP address at for the HTTP listener.
The Return Server Name field specifies the host name in the URLs the server sends to the client. This affects URLs the server automatically generates; it doesn’t affect the URLs for directories and files stored in the server. This name should be the alias name if your server uses an alias.
The default virtual server is the virtual server that will answer requests for the HTTP listener if no other virtual server is found first. For more information, see "Virtual Server Selection for Request Processing".
You must enable the HTTP listener before it can accept requests.
You can also enable security and configure advanced properties for this HTTP listener. To specify IPV6, use the value inet6 in the Family field. If this value is inet6, IPv4 addresses are prefixed with ::ffff: in the server log.
- Click OK.
Please note that you must enter an existing virtual server in the default virtual server field when you create an HTTP listener. You can use the virtual server created with the server instance, and then go back and change it after you’ve created additional virtual servers, if you like.
To create an HTTP listener using the command-line interface, use the asadmin utility’s create-http-listener command. To get a list of all created HTTP listeners, use the command list-http-listeners.
To create an HTTP Listener, use the following syntax:
asadmin create-http-listener --user username [--password password] [--host hostname] [--port adminport] [--secure | -s] [--passwordfile file_name] --address address [--instance instancename] --listenerport listener_port --defaultvs virtual_server --servername server_name [--family family] [--acceptorthreads acceptor_threads] [--blockingenabled blocking_enabled] [--securityenabled security_enabled] [--enabled enabled] listener_id
For more information on command syntax, see the command-line interface help. For more information on using asadmin, see Appendix A, "Using the Command Line Interface."
Editing HTTP Listener Settings
To edit HTTP listener settings using the Administration interface:
For more information, see the online help.
You can also edit an HTTP listener using the asadmin utility in the command-line interface. Use the get command to get the current settings, and the set command to set them to new values.
To get the values of all the attributes of an HTTP listener:
asadmin> get server_instance.http-listener.http_listener_name.*
For example, to get the values for the default HTTP listener:
asadmin> get server1.http-listener.http-listener-1.*
To set the value of any attribute:
asadmin> set server_instance.http-listener.http_listener_name.attribute_name=value
For example, to set the attribute defaultVirtualServer to server2 for http-listener-1:
asadmin> set server1.http-listener.http-listener-1.defaultVirtualServer=server2
For more information on command syntax, see the command-line interface help. For more information on using asadmin, see Appendix A, "Using the Command Line Interface."
Deleting an HTTP Listener
To delete an HTTP listener using the Administration interface:
To delete an HTTP listener using the command-line interface, use the asadmin utility’s delete-http-listener command, using the following syntax:
asadmin delete-http-listener ---user username [--password password] [--host hostname] [--port adminport] [--secure | -s] [--passwordfile file_name] --instance instance httplistener_id
For more information on command syntax, see the command-line interface help. For more information on using asadmin, see Appendix A, "Using the Command Line Interface."
Creating and Configuring Virtual ServersOnce you have set up an HTTP Listener, you can create and use virtual servers.
This section covers the following topics:
Creating a Virtual Server
To create a virtual server using the Administration interface:
To create a virtual server using the command-line interface, use the asadmin utility’s create-virtual-server command, using the following syntax:
asadmin create-virtual-server --user username ---user username [--password password] [--host hostname] [--port adminport] [--secure | -s] [--passwordfile file_name] [--instance instancename] --hosts hosts --mime mime_types_file [--httplisteners http-listeners] [--defaultwebmodule default_web_module] [--configfile config_file] [--defaultobj default_object] [--state state] [--acls acls] [--acceptlang accept_language] [--logfile logfile] [--property (name=value)[:name=value]*] virtual_server_id
For more information on command syntax, see the command-line interface help. For more information on using asadmin, see Appendix A, "Using the Command Line Interface."
When you create a virtual server, you can enter settings of the following types:
Required Settings
The required setting for a virtual server include the name (ID), and the URL host or hosts.
You also must specify a MIME types file. The MIME types file contains the mappings of file extensions to types of files. For example, the MIME types file is where you can specify that all files ending .cgi be treated as CGI files.
You don’t need to create a separate MIME types file for each virtual server. Instead, you create as many MIME types files as you need and associate them with a virtual server.The default MIME types file is called mime1 and the file name is mime.types.
For more information on MIME types files, see "Configuring MIME Types".
Optional General Settings
In addition to the required fields, you can also set optional fields.
HTTP listener
The HTTP listener handles the connection to the virtual server. You must specify one in order to have remote clients access the virtual server.
ACLs
The access control list (ACL) applied to the virtual server. For more information, see the Sun ONE Application Server Administrator’s Guide to Security.
Accept Language Header
When clients contact a server using HTTP 1.1, they can send header information describing the languages they accept. You can configure your server to parse this language information.
For example, if you store documents in Japanese and English, you could choose to parse the accept language header. When clients that have Japanese as the accept language header contact the server, they receive the Japanese version of the page. When clients that have English as the accept language header contact the server, they receive the English version.
If you do not support multiple languages, you should not parse the accept language header.
State
This state is the virtual server’s state, which is independent of whether the application server instance is On or Off. If a virtual server’s state displayed on this page is On, the virtual server can only accept requests if the application server instance is On as well.
This is true of the default virtual server for the default application server instance as well. If you turn off your application server instance, your default virtual server is still set to On, but will not accept connections.
Valid states are On, Off, or Disabled. A virtual server is able to accept connections if it is set to On
You cannot turn off or disable the default virtual server for the application server instance.
Log Files
The log file, (also known as the server log file) is the file where informational messages and errors are logged. The access log file is the file where HTTP accesses to the virtual server are logged.
Document Root
The document root (sometimes called the primary document directory) is the central directory that contains all the virtual server’s files you want to make available to remote clients. For more information, see "Document Root".
Web Application Settings
A web application is a collection of servlets, JavaServer Pages, HTML documents, and other web resources which might include image files, compressed archives, and other data. A web application may be packaged into an archive (a WAR file) or exist in an open directory structure.
Sun ONE Application Server 7 supports the Servlet 2.3 API specification, which allows servlets and JSPs to be included in web applications. In addition, Sun ONE Application Server 7 supports SHTML and CGI, which are non-J2EE application components.
When you create a virtual server, you specify a default web module for the virtual server. The default web module responds to all requests that cannot be resolved to other web modules deployed to the virtual server. If you don’t specify a default web module, the web module that has an empty context root is used. If there’s no web module with an empty context root, a system default web module is created and used.
When you deploy a web application, you specify a virtual server. Once you have deployed a web application, it appears in the list of available web modules to choose as the default web module for a virtual server. When you specify a web module as the default web module for a virtual server, the virtual server is automatically added to the web application’s list of virtual servers.
CGI Settings
The CGI settings you set when you create a virtual server govern the user and group CGI programs run as, the directory to change to (chroot) before CGI execution begins, and the directory to change to after the chroot.
On UNIX you can also set nice, an increment that determines a CGI program's priority relative to the server. Typically, the server is run with a nice value of 0 and the nice increment would be between 0 (the CGI program runs at same priority as server) and 19 (the CGI program runs at much lower priority than server).
HTTP Quality of Service Settings
Quality of service refers to the performance limits you set for a virtual server. For example, an ISP might want to charge different amounts of money for virtual servers depending on how much bandwidth allowed them. These settings can either be enforced (that is, only the specified bandwidth and maximum number of connections will be allowed) or not enforced. If the settings are not enforced, a message is logged to the log file when the limits are exceeded. For more information, see "Administering the Transaction Service Using the CLI".
In addition to changing these settings through the Administration interface, you can use the command-line interface’s asadmin utility. To configure quality of service using the command-line interface’s asadmin utility, use the following commands:
These commands use the following syntax:
asadmin create-http-qos --user username [--password password] [--host hostname] [--port adminport] [--secure | -s] [--passwordfile file_name] [--virtualserver virtual_server_id] [--bwlimit bandwidth_limit] [--enforcebwlimit enforce_bandwidth_limit] [--connlimit connection_limit] [--enforceconnlimit enforce_connection_limit] instance_name
asadmin delete-http-qos --user username [--password password] [--host hostname] [--port adminport] [--secure | -s] [--passwordfile file_name] [--virtualserver virtual_server_id] instance_name
If you specify a virtual server, these commands create or delete quality of service information for that virtual server. If you do not specify a virtual server, the command affects the server instance.
For more information on command syntax, see the command-line interface help. For more information on using asadmin, see Appendix A, "Using the Command Line Interface."
Editing Virtual Server Settings
Once you have set up your virtual servers, you can edit them. For information on editing virtual server settings, see the following topics:
Editing General Settings Using the Administration Interface
The virtual server’s general settings are the ones you could set when you created the virtual server. To change them, follow these steps:
- In the left pane, for the application server instance, open HTTP Server.
- Open Virtual Servers.
- Click the virtual server you want to edit.
- Make your desired changes.
The areas you can change include quality of service settings, adding ACLs, content-related settings such as the document root and the accept language header, CGI-related settings such as the user, group, nice, and chroot settings, and the default web module.
- Click Save.
For more information on some of these settings, see "Creating and Configuring Virtual Servers". Also see the online help.
Editing General Settings Using the Command-Line Interface
You can also edit these setting using the asadmin utility in the command-line interface. Use the get command to get the current settings, and the set command to set them to new values.
To get all the attributes from a virtual server, use the following syntax:
asadmin> get instance_name.virtual-server.vserver_id.*
For example:
asadmin> get server1.virtual-server.vs1.*
If you want to get all the attributes for the application server instance server1, use the following syntax:
asadmin> get server1.virtual-server.server1.*
To set an attribute, for example, the accept language header, use the following syntax:
asadmin> set server1.virtual-server.server1.virtualserver.acceptLanguage=false
For more information on command syntax, see the command-line interface help. For more information on using asadmin, see Appendix A, "Using the Command Line Interface."
Editing CGI Settings
For information on editing CGIs, see the Sun ONE Application Server Developers Guide to Web Applications.
Editing Document Handling Settings, Document Directories Settings, and HTTP/HTML Settings
For information on changing these settings, see Chapter 16, "Managing Virtual Server Content."
Deleting a Virtual Server
To delete a virtual server:
To delete a virtual server using the command-line interface, use the asadmin utility’s delete-virtual-server command.
Usage is as follows:
asadmin delete-virtual-server --user username [--password password] [--host hostname] [--port adminport] [--secure | -s] [--passwordfile file_name] --instance instance virtualserver_id
For more information on command syntax, see the command-line interface help. For more information on using asadmin, see Appendix A, "Using the Command Line Interface."
Deploying Virtual ServersSun ONE Application Server’s virtual server architecture is very flexible. An application server instance can have any number of HTTP listeners, both secure and non-secure. You can associate any number of virtual servers with these HTTP listeners. You can have both IP-address-based and URL-host-based virtual servers.
Every virtual server can (but does not have to) have its own list of ACLs, its own mime.types file, and its own set of Java Web Applications.
This design gives you maximum flexibility to configure the server for a variety of applications. The following examples discuss some of the possible configurations available for Sun ONE Application Server.
Example 1: Default Configuration
The default configuration is one application server instance. This application server instance has just one HTTP listener listening on port 80, 1024, or whatever you selected, of any IP address to which your computer is configured.
Some mechanism in your local network establishes a name-to-address mapping for each of the addresses to which your computer is configured. In the following example, the computer has two network interfaces: the loopback interface (the interface that exists even without a network card) on address 127.0.0.1, and an ethernet interface on address 10.0.0.1.
The name example.com is mapped to 10.0.0.1 via DNS. The HTTP listener is configured to listen on port 80 on any address to which that machine is configured (“0.0.0.0:80”).
As there are no IP-address-based virtual servers in the default configuration, the only HTTP listener is the default one. All connections pass through to virtual server server1.
Figure 15-1 Default Configuration
In this configuration, connections to the following reach the server and are served by virtual server VS1
Use this configuration for traditional HTTP server use. You do not need to add additional virtual servers or HTTP listeners. You configure the settings of the server by changing the settings for server1.
Example 2: Secure Server
If you want to use SSL in the default configuration, you can simply change the HTTP listener to secure mode.
You can also add a new secure HTTP listener configured to 0.0.0.0:443 and associate server1 to the new HTTP listener. The virtual server now has HTTP listeners, one that uses the secure HTTP listener, and one that doesn’t. Now your server will serve the same content both with and without SSL, i.e. http://example.com/ and https://example.com/ deliver the same content.
Figure 15-2 Secure Server
Please note that the SSL parameters are attached to the HTTP listener.
Example 3: Intranet Hosting
A more complex configuration of the Sun ONE Application Server is one in which the server hosts a few virtual servers for an intranet deployment. For example, you have three internal sites where employees can look up other users' phone numbers, look at maps of the campus, and track the status of their requests to the Information Services department. Previously (in this example), these sites were hosted on three different computers that had the names phone.example.com, maps.example.com and is.example.com mapped to them.
To minimize hardware and administrative overhead, you want to consolidate all three sites into one application server living on the machine example.com. You could set this up in two ways: using URL-host-based or IP-address-based virtual servers. Both have distinct advantages and disadvantages.
Figure 15-3 Intranet Hosting Using URL-Host-Based Virtual Servers
While URL-host-based virtual servers are easy to set up, they have the following disadvantages:
The advantages to IP-address-based virtual servers are:
The disadvantages are:
Both configurations require setting up name-to-address mappings for the three names. In the IP-address-based configuration, each name maps to a different address. The host machine must be set up to receive connections on all these addresses. In the URL-host-based configuration, all names can map to the same address, the one the machine had originally.
Figure 15-4 Intranet Hosting Using IP-Address-Based Virtual Servers
Example 4: Mass Hosting
Mass hosting is a configuration in which you enable many low-traffic virtual servers. For example, an ISP that hosts many low-traffic personal home pages would fall into this category. The virtual servers are usually URL-host-based.
Figure 15-5 Mass Hosting
Notice that the default virtual server, server1, still exists.
