Preamble

The freely available HTTPi webserver is a tiny (12kB), fast and secure pure-Perl webserver.

Since "HTTPi was designed first and foremost to be a hacker's webserver that was easily understood, easily patched and trivially maintainable", it is an ideal candidate for creating a small custom webserver specifically for xml-qstat. The implementation in Perl makes it highly portable, permits complex logic and rapid program development – all very good reasons to pursue it as a platform.

HTTPi Installation (for client-side XSLT)

HTTPi can be configured to run in several different operational modes: as a daemon, “on-demand” via xinetd or from launchd. The xml-qstat modules were developed using the daemonic mode, but should likely work in the other modes. The daemon-mode requires no root-level privileges for running it.

For the general configuration/installation of the HTTPi webserver, see the HTTPi installation instructions. The configuration procedure of HTTPi will interactively ask a number of questions and when it is done will save the answers as a transcript. For example, transcript.0.configure.demonic after configuring for the daemonic mode. These transcripts can be reused to supply answers next time you rebuild HTTPi (with the -d option).

If you don’t understand the configuration question, you can generally just accept the default value. Here are a few of the places where non-default values can be useful:

  • access.log = /dev/null
  • restriction matrix = n
  • resolve IP addresses to hostnames = n
  • TCP port number = 8080

However, the only really important one is the TCP port number. We select a value above 1024, since we wish to run the webserver without requiring root-level permissions.

After starting HTTPi, test it by directing your web browser to http://{host}:8080/ (assuming it was configured to use port 8080). If all goes well, you should see an error message from HTTPi complaining that it can’t find the resource:

    File Not Found
    The resource / was not found on this system.
    --------------------------------------------
    httpi/1.6.2 (Demonic/Linux) by Cameron Kaiser

HTTPi-xmlqstat Build Procedure

For the sake of clarity, we call the application HTTPi-xmlqstat, which is the normal HTTPi webserver with extra coding to handle the xmlqstat webapp. The build procedure is very similar to the normal build except that a few extra questions specific to the xmlqstat installation are asked. The transcripts are thus incompatible with the normal HTTPi build!!

As previously described, the xml-qstat/httpi-modules/ directory contains customized modules for HTTPi. The build procedure simply involves merging the relevant bits from HTTPi with those from xml-qstat (in the httpi-modules directory) before interactively configuring and installing the final HTTPi-xmlqstat webapp.

The make-httpi.sh script is included in distribution to simplify the procedure:

    usage: make-httpi.sh [OPTION]
    options:
      -clean             remove contents of build-httpi directory
      -rebuild SETTINGS  for repeated builds
      -version VERSION   specify an alternative version
      -help

The script relies on the presence of these system utilities: tar, wget.

Note that after you have built HTTPi-xmlqstat once, you should retain the relevant transcripts so that you can easily reconfigure the webserver later. For example, with the supplied script:

    $ ./make-httpi.sh -rebuild myHTTPI-xmlqstat-setttings

or just directly:

    $ cd build-httpi
    $ perl configure.demonic -d ../myHTTPI-xmlqstat-setttings

Using init-scripts/httpi stop provides the easiest way of finding and killing any running HTTPi processes on your system. The script can be started with an alternative HTTPi. For example,

    init-scripts/httpi restart /some/path/httpi-xmlqstat

The web interface should be ready for testing.

HTTPi-xmlqstat Security

Although HTTPi will be running as a non-privileged user, the module also imposes extra restrictions on which GridEngine commands can be executed and which arguments they have.

Additionally, the GridEngine commands will only be executed when they are located in the $SGE_ROOT/bin/$SGE_ARCH/ directory, where the value of $SGE_ARCH is determined internally by the program. The PATH will not be searched.