|Hexamail - Web Servers - Integration|
Hexamail products with a web interface can be accessed directly via the internal web server, or integrated into other IIS Apache web servers to enable access via your existing infrastructure. Currently, IIS can only be integrated with Hexamail on the same machine due to IIS security limitation.
The public pages from the blogging module/product can additionally be accessed via static files, via static files on the local machine or FTP'd to a remote machine.
The simplest integration is with IIS running on the same machine. This integration is performed automatically
by the Hexamail product once configured. In the Hexamail administration GUI, select the IIS integration
radio button and set the virtual directory to your preferred choice. Set the Web UI URL to be the machine name
with this virtual directory name, eg.
where the chosen virtual directory is hexamail.
When IIS integration is required for one domain on a server where multiple domains are hosted, some manual
configuration is required. Choose the 'Use Hexamail built in web interface' on the Web Interface Settings page
then do the following for the required domain.
1) Within the IIS Manager navigate to the required web site
2) Add a New Virtual Directory, eg. blogserver pointing to the subdirectory of the installation directory webui/wwwroot
3) Copy the file webui/default.asp.tmpl to webui/wwwroot/default.asp (remove the .tmpl extension)
4) Edit the file in a text editor and change the line
strmirrorURL = "<?HXM_WEBUI_PROTOCOL?>://<?HXM_WEBUI_HOST?><?HXM_WEBUI_PORT?>"
strmirrorURL = "http://127.0.0.1:8080/blogserver"
where using port 8080 and the virtual server set in 2) was blogserver.
In the Web Interface settings, set the Web UI URL to be the required domain, with this virtual directory name, eg.
where the chosen virtual directory is blogserver. The Web UI should then be available for that domain only via IIS.
Apache integration requires changes to the httpd.conf file. This is only recommended for administrators who are familiar with this file, the security implications of changes and who are comfortable with making modifications to the configuration of Apache.
Backup your current setup before you begin. Incorrect changes may easily result in Apache not being able to run.
NOTE: this section assumes you are using Apache with Dynanic Shared Objects (DSO's). If you are not using shared object, you may have to either allow it and use the method below, or even rebuild Apache with the correct modules enabled, if they are not currently. Consult the Apache documentation in such cases as this is beyond the scope of this guide.
Apache integration uses the mod_proxy and mod_rewrite modules. Most current standard distributions appear to ship with these enabled by default, but you should check that your load modules list include them. These appear under the 'Dynamic Shared Object (DSO) Support' section of the httpd.conf file:
If you are running a custom build of Apache, you may need to enable these modules in the build. Consult the Apache documentation for how to do this.
You then need to make the following changes to the relevant section of httpd.conf. If your installation of Apache is hosting multiple domains as virtual hosts this will most likely be the individual site:
where we have again used machinerunninghexamail and port 8080, with hexamail as the virtual directory that Apache will use to access the internal web interface. If the machine running hexamail is the localhost you can enter 127.0.0.1 for the machinerunninghexamail parameter. The IfModule mod_proxy.c is added protection against mod_proxy not being loaded.
Save the changes and restart Apache to make them take effect, eg. with the 'apachectl restart' command.
In the administration GUI of Hexamail, go to the Web Interface page and set the Web UI URL to be the URL of the new directory on the machine running Apache, eg. http://yourwebserver/hexamail - and Apply the change.
You should now be able to access the Hexamail Web Interface via eg. http://yourwebserver/hexamail
If not consult your Apache logs to see what the issue might be - note that Apache will fail to restart if its configuration file is incorrect, however if a module cannot be found this may not be reported until runtime when it tries to use it.
The blogging module/product can use the above methods for delivering pages, however there are cases where static pages are preferable - for example to make sure that only internal users can access the blog editing pages whilst delivering the public pages to a wider audience directly from your current web server.
There are two ways to do this - via a copy if Hexamail is running on the same machine as the web server, of via FTP if running on a different machine. Select the appropriate radio button on the Publishing settings within the Weblog pages.
With the Direct publication (local copy) you need to specify the base directory the files will be copied to (Base directory for copy). Similarly for FTP, you need to specify the Remote Base FTP path as the place the static versions of the files will be FTP'd to. All the required files will be put in appropriate subdirectories of these base directories as required. Make sure these directories are specific to Hexamail.
In either case, you need to specify the publicly accessible URL in addition to the target directory - the URL
for HTTP access. This should be the URL required to get to the base directory externally, eg.
This URL is used in for example the RSS output files, to get back to the original articles.
When using static files, the Web UI URL specified on the Web interface pages should be the local machine and
the port that Hexamail is configured to run on, eg
rather than the web server itself. This will allow access to the blog editing pages for your authors, while allowing external viewers to see the pages directly from the web server.