Setting Up Web Services Using Virtual Hosts
|Applies to:||Hornbill Core Services|
Setting Up Web Services Using Virtual Hosts
If you do not wish to run your external-facing Supportworks Web services (such as SelfService and Web Client / Analyst Portal) on a remote server located in a DMZ, you can, instead, present these services to the Internet by means of virtual hosts configured in the Web server within your firewall. You can then set up your firewall to accept connections on the IP addresses and ports that you designate for these virtual hosts.
With multiple virtual hosts configured, each with its own IP address/port, host name and logs, you can have more than one apparent website on the same physical Web server while maintaining a certain degree of separation between their respective configurations. The alternative to multiple virtual hosts is to have a single configuration using aliases to present all your Web services (with their respective URLs) under one IP address/port.
All the versions of Windows that are compatible with Hornbill Core Services allow for multiple IP addresses to be bound to a single physical network card. Multiple IP addresses on a Windows server could also be achieved by the machine having multiple physical network cards, but in most situations this would be overkill unless the Windows server is attached to more than one physical LAN.
Virtual hosting is comprehensively documented here on the Apache website:
The above documentation provides a definition of virtual hosting, explains the difference between IP-based and name-based virtual hosts, and contains all the information necessary for you to be able to configure any number of them.
With virtual hosts in use, users will see multiple websites with different URLs, although these are served by the one Web server.
Such multiple virtual hosts on a Web server could be serving different domains, such as:
Alternatively, they could be serving different hosts in a single domain, as in the following example, where one SelfService instance is external-facing (accessed via the Internet) and the other is internal-facing (accessed via a Local Area Network):
Configuring a Virtual Host
Virtual hosts are configured in Section 3 of the Web server's httpd.conf file, whose location (assuming a default Core Services installation) is:
C:\Program Files\Hornbill\Core Services\SwHttpServer\conf\
In a clean Core Services installation, the supplied httpd.conf file comes preconfigured with at least one virtual host, which includes Alias directives to provide the URLs required for each of the default Supportworks Web services. (Note that, from Core Services version 3.0 onwards, there are two virtual hosts available in the httpd.conf file, one of which is SSL-enabled.) You are free to modify these as necessary, and also to add extra ones if you wish to separate the Web services' configurations from each other.
Configuring the Web server will require the SwHttpServer service to be stopped and then restarted, which would affect all the HTTP-serving elements of Supportworks, such as SelfService and the Supportworks Today page in the native client. Before stopping the Web server, be sure to make a backup copy of the httpd.conf file.
Within the httpd.conf file, the configuration for a given virtual host is bounded by a pair of VirtualHost tags. The starting tag allows the specification of one or more IP addresses and ports for the virtual host concerned.
Inside a VirtualHost section, the following directives may typically be used:
DocumentRoot- This specifies the internal path, on the Web server machine, to the folder that contains the home page of the Web service represented by this virtual host. For example, the folder ...\htdocs\ would provide the Core Services home page.
ServerName- This specifies the host name (often the domain name) by which this Web service is known to the outside world. A port number can optionally be appended.
<Directory "folder-path">- This is the start tag of an envelope in which various options and settings relating to the given folder can be specified. The folder may be that of the document root or of an alias.
Examples of httpd.conf Virtual Host Entries
Here, we present two examples of virtual-host entries in an httpd.conf file. In both cases, the relevant Alias directive has been removed from the default virtual-host configuration and the internal path mapped in it has instead been specified as the document root in the new entry shown.
The first example is for a virtual host that is serving HTTP on communications port 80 from IP address 10.0.0.19 for a Supportworks SelfService instance that has an instance name of "internalwss":
<VirtualHost 10.0.0.19:80> ServerAdmin [email protected] DocumentRoot"d:/Program Files/Hornbill/Supportworks Server/html/_selfService/internalwss" ServerName internalwss.example.com ErrorLog "d:/Program Files/Hornbill/Supportworks Server/log/internalwss_error.log" CustomLog "d:/Program Files/Hornbill/Supportworks Server/log/internalwss_access.log" combined <Directory "d:\Program Files\Hornbill\Supportworks Server\html\_selfService\internalwss"> AllowOverride None Order allow,deny Allow from all </Directory> </VirtualHost>
The second example is for a virtual host that is serving HTTP on communications port 80 from IP address 10.0.0.20 for the Supportworks PDA Client service:
<VirtualHost 10.0.0.20:80> ServerAdmin [email protected] DocumentRoot "d:/Program Files/Hornbill/Supportworks Server/html/pdaclient" ServerName pdaclient.example.com ErrorLog "d:/Program Files/Hornbill/Supportworks Server/log/pdaclient_error.log" CustomLog "d:/Program Files/Hornbill/Supportworks Server/log/pdaclient_access.log" combined <Directory "d:\Program Files\Hornbill\Supportworks Server\html\pdaclient"> AllowOverride None Order allow,deny Allow from all </Directory> </VirtualHost>