Web Options


At this stage in history, the real options for VMS Web serving are CSWS/Apache, OSU, and WASD. (There are still some vocal adherents of Purveyor from Process Software, but it doesn't really make much sense to start any new project on a server that's neither Open Source nor supported, no matter how solidly it works.) Here's an overview of what the three programs offer.

CSWS

Compaq Secure Web Server (CSWS) is an official, Compaq-supported port of Apache, the most popular Web server on the planet. It's available for download from the OpenVMS Web page (www.openvms.compaq.com/openvms/products/ips/apache/csws.html). If you have a support contract for VMS, you have support for Apache, so you can call in if you find bugs. It comes as a PCSI kit and is extremely easy to install, delivering compiled images that are ready to go, so you don't need to have a C compiler on your system. (I will endeavor to use "CSWS" when referring to the VMS port in particular, and "Apache" for how Apache generally works.)

The most widely used add-ons for Apache are probably mod_ssl, FrontPage extensions, mod_php, and mod_perl. Compaq has ported mod_ssl and mod_perl, created a supported port of Perl, created a new module for OpenVMS user authorization, added a module that lets you run CGI programs written for the OSU Web server, added mod_php in the 1.2 beta release, and added mod_rewrite as well. There are dozens of modules available for Apache on other platforms; it's hoped that a VMS community will develop around Apache/CSWS and port more of the modules. (I'd certainly like to see mod_python, since there's a VMS port of that scripting language. There was a port of mod_python for an early version of Python.) There is at present no port of the FrontPage extensions to VMS. Mod_include, the server-side include module, is part of the core, so CSWS can do very full server-side includes that incorporate some scripting logic. CSWS can run Java servlets (if Java's installed), and Compaq also makes Tomcat/Jakarta, the Java application server, available on VMS. (Jakarta won't be discussed in much detail in this book.)

Perl is the amazingly capable scripting/glue language that, in addition to a lot of data manipulation and system management applications, turned out to be perfect for Web programming through the Common Gateway Interface. mod_perl embeds a persistent copy of the Perl interpreter into Apache, with two good effects: When the server needs to process a Perl script, it doesn't have to spend the time to fire up a separate process and load Perl from disk. It can handle the request faster and with less overall system load. In addition, it means that Apache can be extended with Perl modules, instead of being limited to writing, compiling, and linking additional C modules. (The mod_perl interface exposes enough of the Apache internal state to Perl that Perl modules can be involved in Apache's internal processing.)

A Perl module such as Apache::ASP brings Active Server Pages functionality, developed for Microsoft's IIS, to Perl. mod_perl in CSWS 1.1 works only with the version of Perl it was built with (5.5.3), which is not the most up-to-date version; still, with some ingenuity you can use later versions of Perl in CGI scripts but not with mod_perl. The CSW 1.2 has a CSWS_PERL and mod_perl that use Perl 5.6.1, which is the most current stable Perl version as this is written, although Perl development continues apace. See Appendix A for more about Perl history and capability. PHP is the PHP HyperText Processor, the most popular Web-templating language; see Appendix C for more about PHP's history and capability.

There are more add-ons and modules for Apache than for any other Web server, but they aren't supported by Compaq. Just because something runs on UNIX or Windows Apache doesn't mean it will necessarily work on VMS at all or without considerable porting effort, but it will probably be easier to get something that exists working than to build something from scratch. Some things that are fairly standard on UNIX Apaches (e.g., using the Berkeley database manager for authentication files) aren't supported on VMS; I'll point these instances out as we come to them.

The VMS Apache port runs only on Alpha, not on VAX. It requires VMS 7.2-1 or higher. In order to maximize portability, the port doesn't radically change the Apache core very much. As a result, it doesn't really take advantage of many of VMS's unique features—exceptions include that processes use shared memory to communicate rather than keeping a scoreboard file on disk and the use of Galactic shared memory for SSL session cache—and doesn't wring out the last possible bit of performance from the hardware.

CSWS doesn't offer a Web-based administration tool. (There are a number of third-party add-ons that do this on UNIX.) Most configuration will be done by editing the configuration file.

OSU

The Ohio State University DECthreads HTTP Server, developed by David Jones, is available from http://kcgl1.eng.ohio-state.edu/www/doc/serverinfo.html. Jones also wrote a freeware secure shell server for VMS, the first available SSH server on VMS as far as I know. (Multinet and TCPware include SSH servers, but TCP/IP Services doesn't offer one, and no plans to offer one have been announced so far.)

You can get OSU to run on VAX or Alpha with any version from 5.5-2 on up. (For versions of VMS higher than 7.2 you need to run OSU 3.6b or higher. The current version as of this writing is OSU 3.9b, with 3.10alpha in alpha test.) OSU uses threading to handle concurrent Web requests. If you're running a multiprocessor box and a version of VMS recent enough to handle kernel threads properly, you can take advantage of your CPU investment by automatically running different threads from the same image concurrently on any available processor. (OSU is really good at exposing bugs in VMS's threading implementation, and you may need to turn off kernel threading in the server. Also, the threading model has changed a couple of times, so if you're on an old-enough VMS version you may need to run an old version of OSU.)

To communicate with CGI worker processes, OSU uses DECnet internally—that is, without going outside the server box. (There's a hack that uses VMS mailboxes instead, but that isn't in common use and is really intended only for testing.) Because of the DECnet method, the scripting environment isn't completely standard, and scripts developed for other Web servers often need a small DCL wrapper to work properly. (An exception is made for Perl scripts; the environment sends the right stuff out on the DECnet link and makes the necessary assignments before invoking Perl.) OSU has some support for persistent scripting environments, ranging from using DECnet tweaking to keep the script processes around a long time to a special Webperl image to a High-Performance Script Server process pool manager that accelerates compiled programs linked with the HPSS shareable image. This server can run Java servlets on an Alpha with Java installed. OSU has also has very capable and flexible authentication and access control options.

OSU has no built-in SSL support; you have to build OpenSSL and then create an SSL_ENGINE or SSL_TASK process that communicates with OSU over DECnet, such as a CGI. You definitely need a C compiler if you're going to have encrypted communication support for OSU, and it's a good idea to have one anyway, as there are enough combinations of operating system levels and VMS TCP/IP products that it may be difficult to find a precompiled version of OSU with everything you need.

OSU has very configurable and sophisticated file caching, which gives it an advantage over serving pages just from disk. Some MicroVAX systems serve hundreds of thousands of pages a month, and the cache can help considerably in reducing the system load. Pulling something from memory is a lot cheaper than pulling it from disk.

Documentation is somewhat sketchy. There are example configuration files and some on-line documentation of what they mean, and some users have put up documentation Web pages. Digital Press expects to release an OSU manual in 2002. Quite a lot of server configuration can be done via a Web form, although I prefer editing the configuration files, and most of my examples will be in the form of edited configuration files.

Support is by volunteer effort on the VMS-WEB-DAEMON mailing list. If you have a question or problem, you can raise it on the list and will often get an answer back very promptly, day or night. (Some of the contributors are on different continents, so there's effectively 24-hour coverage.) Jones himself reads the list and answers questions when he's available. I've been using OSU since 1994 and have generally been very happy with it.

WASD

Mark Daniel developed WASD (then HFRD) for internal use at the High Frequency Radar Division of the Defense Science and Technology Organization, and it was in use for some 18 months before being released to the public. The High Frequency Radar Division of the Defense Science and Technology Organization changed its name to Wide Area Surveillance Division, so the package became WASD; later the division became Surveillance Systems Division, but WASD was too well known to change to SSD, and it might have been too easily confused with the secure shell daemon (SSHD). It's available from http://wasd.vsm.com.au. WASD runs on VAX or Alpha.

The idea with WASD was to be a really good VMS-only server; Mark Daniel says, "I suffered a bit of a VMS cringe when amongst my UNIX colleagues (VMS was and is perceived to be a bit slow and cumbersome), so I have also endeavored to make WASD as fast and efficient as I could, avoiding C run-time library and even RMS code layers where it was feasible and worth it. I also wanted a similarly tight scripting environment and have spent a lot of time honing this aspect."

Although everybody's usage varies, WASD seems to be the fastest server available, getting as much performance as possible from the system. WASD supports a number of scripting environments: standard CGI; CGIplus (each with callouts that can request the server to perform certain functions for the CGI and then resume processing); ISAPI (the fast application program interface developed for Microsoft's IIS); a framework for a persistent run-time environment that you can customize to make your own application permanently available, and a Perl processor that takes advantage of this; plus a CGIUTL utility that simplifies the job of DCL scripts. All of these goodies are supplied with object code, but for customization you'll need a C compiler. There's support for Java servlets on Alpha with Java installed, and there's also an OSU compatibility mode. WASD also allows the execution of DCL commands from within server-side include statements in HTML code.

WASD offers server administration and some statistics via a Web form, or you can edit the configuration file manually. To get SSL working you install a separate kit, which includes the OpenSSL object libraries into the WASD directory tree, and then run a script to link. You don't need to make any source code changes. It is also possible to link WASD against the object libraries of an existing OpenSSL installation. This is easier than OSU but marginally harder than CSWS.

Which should you use?

The answer to the question "Which should I use?" is always "It depends." If you're running on a VAX, CSWS isn't an option, so you'll need to choose between OSU and WASD. If your Webmaster already understands Apache, use CSWS. If you need to squeeze out the last bit of performance, use WASD. If your site policies won't let you use software without a support contract, use CSWS (or go to a third-party provider of OSU or WASD support). If you're not afraid of compiling source code and want a very stable server with a knowledgeable user base, use OSU. If being "industry standard" matters to you—being able to buy O'Reilly handbooks, Dummy's Guides, and so on—go with CSWS, but be prepared to find out that the stuff they document isn't in the VMS version, or at least be prepared to have to figure out file names and the like. If you don't have a C compiler, don't use OSU. If you're stuck on a less-current version of VMS (such as the very stable 6.2 or 6.2-1H1), Apache is out of the picture.

In most cases, everything will matter somewhat to you, so you're going to have to prioritize (i.e., figure out what matters most or how much to weight each factor). All of these servers are available for free, so you do have the comforting option of downloading each one and trying it out, seeing how well it works in your environment, and finding out which one you find most congenial to maintain. You can even run them all at once, on different TCP/IP ports, serving the same or different documents.[4]

[4]The material in Appendix B is drawn from Chapters 2 and 3 of Alan Winston, OpenVMS with Apache, OSU, and WASD: The Nonstop Webserver, 1-55558-264-8, 2002, Alan Winston.




Getting Started with OpenVMS System Management
Getting Started with OpenVMS System Management (HP Technologies)
ISBN: 1555582818
EAN: 2147483647
Year: 2004
Pages: 130
Authors: David Miller

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net