OpenVMS Notes: WASD HTTPd

Table of Contents

Edit: 2023-05-25 (a work in progress)

y2k20 - a potential crisis in 2020 (nothing to do with WASD)

Modern browsers in 2020 will expect to "connect HTTPS" only using TLSv1.2 and TLSv1.3 (this assumes that support for everything from SSLv3 up to and including TLSv1.1 will be removed)

While browsers are constantly being updated because of their use in everything from on-line purchases to on-line investing and banking, many web servers are not. What is worse it this: many organizations, including governments large and small, are slow to update their server software

comment: Firefox has been warning for several months (today is 2019-08-25) that one of my servers is preferentially offering connections via TLS-1.0 (the lock icon is closed but is orange). Chrome and IE11 each present a green lock icon.

Comparing y2k to y2k20

  • y2k (2000) was a problem related to old technology (both hardware and software) where it was not certain if internal clocks would know how to handle these two problems:
    1. would clocks properly roll over from 1999 to 2000 or would they wrap back to 1900?
    2. would the year 2000 be a leap year or not? (it was a leap year according to rule-3)
    Notice that these human-caused problems where caused by:
    1. a lack of coordination in the computer industry (caused by companies competing with each other rather than working together)
    2. businesses and governments refusing to upgrade hardware and/or software
    3. egotistic programmers doing their own thing rather than calling the operating system
  • y2k20 (2020) is a potential problem where:
    • security changes in client browsers (which are usually auto-upgraded) may not be able to communicate with web servers (which are not auto-upgraded)
      • this is a client-server problem
    • security changes in web servers (depending upon how they are implemented) may not accept connections from customers unwilling or unable to update
      • this is a B2B (business to business) problem where third party software (usually linked to older OpenSSL libraries) is used to initiate a web connection.

Why is 2020 going to be a problem?

  • y2k was (perhaps) so overblown that many people assumed that a whole lot of money had been spent but nothing happened. This assumption is faulty because the problem was largely averted
  • y2k20 does not appear to be taken seriously by anyone
    • back during Y2K, not very many people relied on browsers
    • twenty years later, almost everyone relies upon browsers for something
      • email clients have gone the way of the dodo (Microsoft will not allow you to install Windows Mail on a new Windows-10 platform); most companies tell you to read mail using a browser
      • many people uses browsers for online banking; online investing; online purchases; online entertainment (eg. youtube)
      • programmers aside, anyone who used a terminal emulator back in 2000 will most likely be using a browser today. 
      • to save money, many companies are not patching internal web-servers which are only accessed by internal employees on their internal intranets. But their employees are still agreeing to upgrade their own browsers. Kaboom!
  • Don't think this will affect you? An unexpected change to OpenSSL in CentOS-7.3 on January of 2018 broke some things for me as I have documented here 

Good News from Microsoft

  • There are a lot of desktops in the world still running Windows-7 and those users were either unwilling or unable to upgrade to Windows-10
  • Windows-10 was rolled out with two browsers, IE11 (Internet Explorer 11) and Microsoft Edge. Customers were instructed to begin using the new browser but many refused
  • Microsoft Edge was not available on older platforms which left older Windows desktops exposed to security exploits (appeared to be happening daily if not weekly)
  • Since the customer adoption of Microsoft Edge wasn't successful, in 2019 Microsoft decided to partner with Google by replacing Microsoft Edge with a newer variation called Microsoft Chrome Edge.
    • Google's Chrome browser is based upon similar technology
    • Microsoft Edge version numbers run from 12 to 18 (EDGE-12 to EDGE-18)
    • Microsoft Chrome Edge is currently at version 80
  • This new Edge variation was only available to WIndows-10 users but it needed to be downloaded manually (was never part of an automated patch kit).
  • In 2020-02-xx Microsoft announced that Microsoft Chrome Edge would be available to older platforms, including Windows-7
  • comment: we have got to convince everyone (friends, family, employers, customers) to abandon IE11 as soon as possible because it is holding back evolution of the internet.

Additional news

  • 2020-07-02
  • 2020-08-20
    • Two different people told me today that a recent Windows-10 update just killed their "Windows Live Mail" client. (I have not seen anyone else on the internet crabbing about this - yet)
    • Like IE11, Microsoft no longer supports the Windows Live Mail client (IIRC, the last version came out in 2012; if it was on Window-7 when you updated to Windows-10 then you were allowed to keep it; you were not allowed to install it onto a new version of Windows-10)
    • Non-Microsoft software, like Mozilla Firefox and Google Chrome, had the SSL and TLS protocols built into their stand-alone programs. Microsoft software (at least the stuff published ten years ago and older) relied heavily upon a large number of DLL files which were shared by many Microsoft applications in the Windows ecosystem.
      SPECULATION: it is entirely possible that the latest Windows-10 update deleted DLL files required by the "Windows Live Mail" client. Those people will either need to get a third-party email reader (here are two: thunderbird and emclient ) or sign up for an annual Microsoft subscription to Office 365 (in this new marketing paradigm, software will be rented rather than purchased)

The OpenVMS ecosystem

  • Two companies are currently supporting OpenVMS (but this is about to change)
    • In 2014, HP transferred the rights to develop/support OpenVMS to VSI (VMS Software Inc)
    • In 2015, HP split into two companies: HP (most desktop products) and HPE (enterprise)
    • HPE continued to support OpenVMS software contracts sold to HP customers before 2015 (they also sold/supported VSI products)
    • Early in 2019, HPE removed most OpenVMS stuff (documentation as well as software) from their website including CSWS-2.2-1 (Compaq Secure Web Services) based upon Apache 2.0.63
    • If you have an OpenVMS support contract with HPE, then you will be able to request the latest version of file MOD_SSL (an Apache module for CSWS) which is based upon OpenSSL-1.0L but does not implement TLSv1.3
      • HPE has announced the end of all OpenVMS support by the end of 2020.
    • Businesses requiring CSWS/Apache on OpenVMS should immediately move their support contracts over to VSI where you will have access to a new version of CSWS based upon Apache 2.4.12
      • caveat: you may be required to update your OS to OpenVMS-8.4-2 so do not wait until the last minute
  • For companies and/or hobbyists financially unable to move to VMS Software Inc, your only remaining option is to replace CSWS/Apache with WASD HTTPd
    • WASD HTTPd is a high quality high performance OpenVMS web server from Australia which is not based upon Apache
    • WASD HTTPd already supports TLSv1.2 and TLSv1.3
    • "I think" support agreements may be available
  • This web-page will document my efforts to replace CSWS/Apache with WASD HTTPd on a sacrificial laboratory system (we employ a lot of CGI including one SOAP-based feed)
  • Web server products available for VMS/OpenVMS
    Publisher Product
    Name    		 Apache
    Version    		 VAX Alpha Itanium x86-64 Active Notes
    Compaq HP HPE CSWS-1 2.0 N Y Y N ? HPE will exit the OpenVMS support business in 2020
    Old CSWS (products, patches, plugins) were free until 2016
    Since then patches are available only if you have an HPE support agreement
    VSI CSWS-2 2.4 N Y Y Y Y New CSWS (available with new support agreement)
    Ohio State University OSU DECthreads n/a Y Y N N N Product hasn't been supported for more than a decade
    Can be found on the VMS Freeware packages
    VSM Software Services WASD HTTPd n/a Y Y Y Y Y Still actively supported

Introduction to WASD HTTPd (one solution to the y2k20 problem on OpenVMS)

  • WASD HTTPd - is a very high quality free web server from VSM Software Services in Australia
    • it runs on all VMS and OpenVMS platforms: VAX, Alpha, and Itanium
    • it will run on x86-64 when VSI finally publishes a OpenVMS-9 for that CPU architecture
    • it is NOT based upon Apache
    • it is published with all the source code so if you can program in C then you can improve/extend/tinker
    • it can link to its own SSL libraries which already support TLS-1.3, or HP-SSL (based upon OpenSSL-0.9 and lower), or HP-SSL1 (OpenSSL-1.0 and higher)
    • excerpt from page-13 of the book OpenVMS with Apache, OSU, and WASD
      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 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"
    • Trivia: WASD = "Wide Area Surveillance Division". WASD was previously known as HFRD (High Frequency Radar Division) of Australia's Defense, Science and Technology Organization
Executive Summary:
  • What an unexpected surprise. WASD HTTPd is the fastest web server I have worked on to date.
    I am currently supporting web servers on these production platforms...
    Hardware CPU Cores Memory Network OS Software
    rx2800-i2 Itanium2 8 64G IPv4 on 1Gb/s OpenVMS-8.4 CSWS/Apache 2.0.xx
    DL385p-gen8 AMD x86-64 24 132G IPv4 on 1Gb/s CentOS-7.5 Apache 2.4.xx
    rx2660 Itanium2 8 16G Ipv4 on 1Gb/s OpenVMS-8.4 WASD HTTPd 11
    ...and it appears that WASD on the oldest hardware is able to out-perform Apache on the newest hardware (caveat: I haven't done any full-load stress tests just yet)
  • WASD HTTPd is published with all the source code. This means that if Adelaide gets hit with an asteroid you will be able to fix your own code (provided you have access to the DECC "C compiler)
  • The source code is mirrored in at least three other locations (see asteroid comment)

First Steps

  • download all the zip files you think you will need from here: https://wasd.vsm.com.au/wasd/ (or the various mirror sites)
    • caveat: do not skip any CUP (cumulative update package) files. I wasted a whole day trying to get both Server Admin and SYSUAF to work (I assumed I was doing something wrong). I was only successful after I noticed, then installed, the CUP file (probably need new eyeglasses)
  • none of these files offer executables so you will need to download a vanilla package (necessary to "compile-link" or just "link") as well as the architecture-specific files

Unzip then install

Unzip

$! DCL script to unzip WASD
$! this is an rx2660 (Itanium2)
$! CSWS/Apache is located on disk dka200 so that's where I'll put WASD
$!
$ define/job yada CSMIS$USER3:[ADMCSM.NEIL._WASD]	! files where downloaded here
$ set default DKA200:[000000]				! move to root of disk dka200
$ unzip yada:WASD1130.zip				! also creates folder [WASD_ROOT}
$ unzip yada:WASD1130-ia64.zip				!
$ set default [WASD_ROOT]				!
$ unzip yada:WASD_CUP_1130b.ZIP 			! do not forget this (or SYSUAF stuff won't work)
$ unzip yada:opensslwasd102r-ia64.zip			! optional

Install (part 1) you need a DEC-C compiler to do perform step 1 so consider starting with step 2

$set default wasd_root:[000000]				!
$@install						!

******************* 
*  BUILD PACKAGE  * 
******************* 

Package executables must be built.

0. skip this step 
1. compiling from source, then linking 
2. linking (separate package) object modules 

Select build method [0]:

[...snip...]

Install (part 2) really cool because you have a choice

************************** 
*  SSL TOOLKIT DETECTED  * 
************************** 

A supported Secure Sockets Layer (SSL) toolkit has been detected.
Those with item numbers are available for building, 'x's are not available.

0. do not build an SSL version 
1. OpenSSL (prior to v1.1.0) toolkit
x. OpenSSL (v1.1.0 or later) toolkit 
2. OpenVMS SSL1 product (HP)                    (OpenSSL 1.0 and higher)
x. WASD OpenSSL package                         ("x" because download it) 
x. OpenVMS SSL product (HP) no longer supported (OpenSSL 0.9 and lower)

Select item number [2]:

Config then initial start

  • now read install-and-config as well as features (or download the PDFs of those html docs from here)
    • the vanilla http server (port 80) installs itself.
    • The secure https server (443) will not work without having chapter-4 of features open while you edit the config files documented in install-and-config. IMHO, this is a good thing since we've all worked on systems initially set up by "the brain dead". Security is no laughing matter. I was not able to get HTTPS working without first using the OpenSSL CLI from another system
  • quick steps 1
    • locate your current ssl certificate file (name.crt) and key file (name.key)
    • copy both of these files into a third file with an extension of ".pem" like so:
          $copy  name.crt , name.key name.pem
      caveat: depending on the text file format, doing a DCL copy-concatenate will result in the middle of the file looking like this:
           -----END CERTIFICATE----------BEGIN RSA PRIVATE KEY-----
      rather than this:
           -----END CERTIFICATE-----
           -----BEGIN RSA PRIVATE KEY-----
  • quick steps 2:
    • edit this file: WASD_ROOT:[LOCAL]wasd_config_global.conf
      field current contents new contents notes
      [SecureSocket] disabled enabled  
      [SSLversion] TLSvALL TLSvALL,SSLv3 my system will require SSLv3 for a time
      [SSLcipherList]   MEDIUM:HIGH https will not work if this field is BLANK
      [SSLcert]   dka100:[certificates]name.pem https will not work if this field is BLANK
      [SSLkey]     leave this field BLANK
      [SSLverifyPeerCAFile]   dka100:[certificates]vendor.crt this is the vendor's chain file (in PEM format)
      [Welcome] INDEX.HTML INDEX.HTML
      DEFAULT.HTML      		 this is standard
      this is the name of our Apache home page
      [Http2Protocol] enable disable disable for use with Firefox and Chrome in 2019
  • quick step 3:
    $ @dka200:[WASD_ROOT.STARTUP]STARTUP.COM
  • startup problems? The check these locations:
    server logs: WASD_ROOT:[LOG_SERVER]
    client logs: WASD-ROOT:[LOG]
  • https testing
    • testing with browsers can be problematic because they all implement different levels of security. So I recommend you first test with the OpenSSL CLI. Do not move to browsers until this command works 
      $ openssl s_client -connect www.server.ext:443 -showcerts
    • This is an example of a failure (handshake could not find, or agree upon, a common protocol):
      $ openssl s_client -connect kawc4r.on.bell.ca:443 -ssl3
CONNECTED(00000005)
1211764609:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure ...
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 305 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1.2 
Cipher    : 0000 
Session-ID: 
Session-ID-ctx: 
Master-Key: 
Key-Arg   : None 
PSK identity: None 
PSK identity hint: None 
SRP username: None 
Start Time: 1554322235 
Timeout   : 300 (sec) 
Verify return code: 0 (ok) 
---
    • While this is an abbreviated pass
      $ openssl s_client -connect kawc4r.on.bell.ca:443 -showcerts
CONNECTED(00000005)
depth=2 C = US, O = "Entrust, Inc.", OU = See www.entrust.net/legal-terms,
	OU = "(c) 2009 Entrust, Inc. - for authorized use only",2 verify error:num=19:self ...
---
Certificate chain
0 s:/C=CA/ST=Ontario/L=Kitchener/O=Bell Canada/CN=kawc96.on.bell.ca 
i:/C=US/O=Entrust, Inc./OU=See www.entrust.net/legal-terms/OU=(c) 2012 Entrust, Inc. - for ...
-----BEGIN CERTIFICATE-----
MIIHPDCCBiSgAwIBAgIRAPaL2NZkwkK1AAAAAFDmVrowDQYJKoZIhvcNAQELBQAw
[...snip...]
TW6QHJa01MG8nTNfTYHEnZ4EbKFN+XjXb5+8+huXIJYO7Mvbpx9Uv78RJQJxn1cj
Irl6f6Wu3P59Gn5kpvwHmU4T6llV1jbquKp00G+7JDg=
-----END CERTIFICATE-----
1 s:/C=US/O=Entrust, Inc./OU=See www.entrust.net/legal-terms/OU=(c) 2012 Entrust, Inc. - f ...
i:/C=US/O=Entrust, Inc./OU=See www.entrust.net/legal-terms/OU=(c) 2009 Entrust, Inc. - fo  ...
-----BEGIN CERTIFICATE-----
MIIFDjCCA/agAwIBAgIMDulMwwAAAABR03eFMA0GCSqGSIb3DQEBCwUAMIG+MQsw
[...snip...]
exCdtTix9qrKgWRs6PLigVWXUX/hwidQosk8WwBD9lu51aX8/wdQQGcHsFXwt35u
Lcw=
-----END CERTIFICATE-----
2 s:/C=US/O=Entrust, Inc./OU=See www.entrust.net/legal-terms/OU=(c) 2009 Entrust, Inc. - f ...
i:/C=US/O=Entrust, Inc./OU=See www.entrust.net/legal-terms/OU=(c) 2009 Entrust, Inc. - fo  ...
-----BEGIN CERTIFICATE----- MIIEPjCCAyagAwIBAgIESlOMKDANBgkqhkiG9w0BAQsFADCBvjELMAkGA1UEBh ...
[...snip...]
nAuknZoh8/CbCzB428Hch0P+vGOaysXCHMnHjf87ElgI5rY97HosTvuDls4MPGmH
VHOkc8KT/1EQrBVUAdj8BbGJoX90g5pJ19xOe4pIb4tF9g==
-----END CERTIFICATE-----
---
Server certificate
subject=/C=CA/ST=Ontario/L=Kitchener/O=Bell Canada/CN=kawc96.on.bell.ca issuer=/C=US/O=Ent ...
---
No client certificate CA names sent
---
SSL handshake has read 4579 bytes and written 623 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegot ...
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1.2 
Cipher    : AES256-GCM-SHA384 
Session-ID: D24A4196DD1C6E36B35B4E85A5985BFA58A7541487A84F9B863926BB45BC249E 
Session-ID-ctx: 
Master-Key: 9C14A7397DC7FB7CCF8684A4F05EC8F3F56364491E497B9CADF7FC8550F7A25861F97B12FBA1B7 ... 
Key-Arg   : None 
PSK identity: None 
PSK identity hint: None 
SRP username: None 
TLS session ticket lifetime hint: 300 (seconds) 
TLS session ticket: 
0000 - 47 b7 de fa 7c f1 cb db-0b 80 3a 58 31 21 c8 84   G...|.....:X1!.. 
0010 - 4b 65 6b 8b 49 88 ee 49-5d 3b e0 1f f6 c1 55 81   Kek.I..I];....U. 
0020 - ee 7d 01 2e fc 85 e7 e4-c2 b4 4e 1a d0 a4 65 b7   .}........N...e. 
0030 - 09 3d 46 05 7e 6c 7c 21-97 df 4a 56 9f aa c7 3e   .=F.~l|!..JV...> 
0040 - 6b 6d 68 6a c7 81 7e 07-30 70 c8 64 a6 6a 54 f1   kmhj..~.0p.d.jT. 
0050 - 23 fb 38 4d d5 dc 83 95-95 fa c9 c5 e2 28 cc 42   #.8M.........(.B 
0060 - a6 5b 34 ac ed 80 b0 d6-7e ae de 48 12 22 68 48   .[4.....~..H."hH 
0070 - 15 34 ea 1e df fa 76 b3-3c 4b 2e 1d 58 7f 8b e1   .4....v.
    • most of our clients still use IE11 while our developers use Firefox or Chrome. Be sure to test with all browsers. For example, I initially set "[SSLcipherList] ALL" which prevented connections by Firefox and Chrome (complained that the negotiated protocols were too dangerous) but not IE11 (hasn't been patched in a long while)

Serving up Apache/CSWS Files from WASD HTTPd

  • caveat: I am currently looking for a quick way to replace CSWS/Apache with WASD under emergency conditions. Your map file would look quite different when using WASD on a new system
  • change the contents of file WASD_ROOT:[local]wasd_config_map.conf with something similar to this
    • Apache notes:
      • all the folders listed after "/dka200/apache" are folders under APACHE_ROOT:[000000] on my system
      • file "default.html" can be found in APACHE_ROOT:[MAIN] on my system
    #-------------------------------------
#	basic stuff (also means we can't use these paths in Apache)
exec	/cgi-bin/*	/cgi-bin/*
exec+	/cgiplus-bin/*	/cgi-bin/*
pass	/wasd_root/*	/wasd_root/*	dir=access dir=wildcard
#-------------------------------------
#	for CERN HTTPd compatibility
map	/httpd-intenal-icons/*	/httpd/-/*
#-------------------------------------
#	other
pass	/*/-/*	/wasd_root/runtime/*/*	cache=perm
pass	/wasd_root/runtime/*	/wasd_root/runtime/*
pass	/wasd_root/src/misc/*	/wasd_root/src/misc/*
#-------------------------------------
#	for access to server admin
pass	/httpd/-/admin/
#-------------------------------------
#	for Apache compatibility on the Bell-ATS system
set * map=root=/dka200/apache
exec /cgi-bin/*	/cgi-bin/*
exec /scripts/*	/scripts/*
pass /css/*	/css/*
pass /icons/*	/icons/*
pass /images/*	/images/*
pass /public/*	/public/*
pass /jquery/*  /jquery/*
pass /*		/main/*
fail *
  • shutdown CSWS/Apache
  • change the ownership of Apache root
    • set def dka200:[000000]
    • set file/owner=HTTP$SERVER apache.dir
  •  change the ownership of Apache files
    • set file/owner=HTTP$SERVER [apache...]*.*;
  • start WASD
  • you are ready to go (at least with static HTML)

Scripting (serving up DCL scripts)

Introduction

  • caveat: here I am referring to the scripts usually executed by the webserver on behalf of some user request (not the scripts you might find in folders like wasd_root:[startup]). Some DCL scripts might do nothing else other than run an executable (e.g. they have one line like this: "$run csmis$exe:progam.exe")
  • the scripting environment is locked down on WASD and that is probably a good thing (see my previous comments on systems setup by "the brain dead")
  • When working with Apache on most systems including Linux, Unix and OpenVMS, you can get around most webserver issues by increasing the privileges of the associated accounts.
  • The default behavior of WASD prevents you from doing this
    • remember how computers were setup before the first appearance of web servers in 1991 at CERN? No one was able to access anyone else's directories or files. Web servers were only meant to offer unrestricted access to files in a certain area of the computer. Later webserver versions attempted to add-on user authentication and authorization but the implementation was usually done in a sloppy haphazard fashion
    • scripting on WASD is usually assigned to account HTTP$NOBODY which must only have these VMS privileges: NETMBX and TMPMBX. On top of that, the account cannot be a member of the SYSTEM group. On startup, WASD will inspect these setting then will disable default scripting if it sees anything that might appear dangerous)
  • Unfortunately, over the past 20-years the CSWS/Apache on my systems have be run with more privs than NETMBX and TMPMBX. So producing a solution where WASD can be used as a drop-in replacement for CSWS/Apache required a little more effort.

Quick steps

  • step-1
    • edit file: [WASD_ROOT.local]wasd_config_global.conf
      field current contents new contents notes
      [Scripting] disabled enabled  
      [DclDetachProcess] disabled enabled  
      [DclDetachProcessPriority]   1  
      [DclScriptRunTime] .PL__ @cgi-bin:[000000]PERL.com
      .PL perl
      .DLL $CGI-BIN:[000000]CGISAPI.EXE
      .CLASS @CGI-BIN:[000000]JAVA.COM       		.COM text/plain DCL procedure
      .EXE application/octet-stream executable       		append these two lines to the current list
      or replace the current list as you see fit
  • step-2 (add this line to file "STARTUP_LOCAL.COM")
    $!-------------------------------------
$! initial setting to start hacking
$!	define/system WASD_STARTUP_SERVER "/PERSONA=(APACHE$WWW,RELAXED)/SCRIPT=AS=APACHE$WWW"
$!-------------------------------------
$! initial hacking may require /watch to write more stuff to the server log file
$!
$ if 1.eq.0
$ then
$ define/system WASD_STARTUP_SERVER "/PERSONA=relaxed/SYSUAF=relaxed/Profile"
$ else
$ define/system WASD_STARTUP_SERVER -
      "/PERSONA=relaxed/SYSUAF=relaxed/Profile/WATCH=NOSTARTUP,ITEMS=(REQUEST,RESPONSE,MAPPING,error)"    
$ endif
  • step-3 (modify file [WASD_ROOT.local]WASD_CONFIG_MAP.CONF to look similar to this)
    #-------------------------------------
#	basic stuff (also means we can't use these paths in Apache)
exec	/cgi-bin/*	/cgi-bin/*
exec+	/cgiplus-bin/*	/cgi-bin/*
pass	/wasd_root/*	/wasd_root/*	dir=access dir=wildcard
#-------------------------------------
#	for CERN HTTPd compatibility
map	/httpd-intenal-icons/*	/httpd/-/*
#-------------------------------------
#	other
pass	/*/-/*	/wasd_root/runtime/*/*	cache=perm
pass	/wasd_root/runtime/*	/wasd_root/runtime/*
pass	/wasd_root/src/misc/*	/wasd_root/src/misc/*
#-------------------------------------
#	for access to server admin
pass	/httpd/-/admin/
#-------------------------------------------------------------------------
# Bell-ATS notes
# 1) we want WASD to serve up content the same way as APACHE$WWW so the
#       server must run in persona=relaxed mode
# 2) the folders below are required by our CSWS/Apache server
# 3) WASD variables employ a CGIprefix of "www_" while our Apache does not
#-------------------------------------------------------------------------
SET     * map=root=/dka200/apache
SET     /*              report=detailed
SET     /scripts/* script=as=APACHE$WWW CGIprefix=
SET     /cgi-bin/* script=as=APACHE$WWW CGIprefix=
exec    /cgi-bin/*      /cgi-bin/*
exec    /scripts/*      /scripts/*
pass    /css/*          /css/*
pass    /icons/*        /icons/*
pass    /images/*       /images/*
pass    /public/*       /public/*
pass    /jquery/*       /jquery/*
pass    /*              /main/*
fail    *
  • restart WASD like so: 
    $ @WASD_ROOT:[STARTUP]SHUTDOWN
$ wait 0:0:05
$ @WASD_ROOT:[STARTUP]STARTUP

Properly enabling Server Admin

  • edit file WASD_ROOT:[LOCAL]WASD_CONFIG_SERVICE.MAP
    current contents new contents notes 
    [[http://*:80]]

[[https://*:443]]

      
    [[http://*:80]]

[[https://*:443]]

[[https://*:44443]]
[ServiceAdmin] enabled
    		append the stanza in red to
    enable Service Admin on port: 44443
  • edit file WASD_ROOT:[LCOAL]WASD_CONFIG_AUTH.MAP
    current contents new contents notes
    whatever 
    [[https://*:44443]]
["Web Admin"=VMS]
#       only from Neil's Desktop
#/httpd/-/admin/*       r+w,142.180.221.225
#/wasd_root/local/*     r+w,142.180.221.225
#       only from Neil's subnet
/httpd/-/admin/*        r+w,142.180.221.0/24
/wasd_root/local/*      r+w,142.180.221.0/24
    		insert a block like this
  • restart WASD

Supporting gSOAP

  • before you begin this section, ensure that gSOAP is already installed on your system. Start by typing this command:
    $ show logical gsoap_root
  • if that command doesn't work then you will need to acquire an appropriate kit (Alpha or Itanium) from here: http://gsoaponopenvms.blogspot.com/
    notes:
    • John Apps has retired but Brett Cameron is still answering email requests
    • more gSOAP information can be found here: OpenVMS-Notes: AXIS2
  • unzip
    $! DCL script to unzip gSOAP support for WASD
$! this is an rx2660 (Itanium2)
$!
$ define/job yada CSMIS$USER3:[ADMCSM.NEIL._WASD]	! files where downloaded here
$ set def DKA200:[000000]				! move to root of disk dka200
$ set def [WASD_ROOT]					!
$ unzip yada:gsoaprte104.zip				!
  • read this
  • install
    $ @ WASD_ROOT:[EXAMPLE]WASDVERBS.COM		! create some verbs required for the build script
$ SET DEFAULT WASD_ROOT:[SRC.GSOAP]		!
$ @BUILD_GSOAPRTE				! can link-only or compile-and-link
$ COPY WASD_EXE:GSOAPRTE.EXE CGI_EXE:		!
  • build gSOAP example programs found the calc folder under WASD (these are slightly different from examples found under gsoap$root)
    $ set def WASD_ROOT:[SRC.GSOAP.CALC]		! navigate here
$ edit/read calc.c				! inspect this file (basis of the service)
$ edit/read calcclient.c			! inspect this file (the standalone client)
$!
$! note: if you enable interface logging: soap_set_recv_logfile(),
$!	soap_set_sent_logfile(), soap_set_test_logfile()
$!	then you must link against gsoapdbg.olb rather than gsoap.olb 
$!
$ @build					!
$!	yields:	soap_calc_share.exe		! similar to the Brett Cameron's demo
$!		soap_calc_cgiplus.exe		! a cgi+ variant
$!		calcclient.exe			! DCL-based client
$!
  • changes to the mapping file
    #
exec	/cgi-bin/*	/cgi-bin/*
exec+	/cgiplus-bin/*	/cgi-bin/*
#-------------------------------------------------------------------------
# Default
pass	/wasd_root/*	/wasd_root/*	dir=access dir=wildcard
#-------------------------------------------------------------------------
# for CERN HTTPd icon compatibility
map	/httpd-internal-icons/*		/httpd/-/*
#-------------------------------------------------------------------------
# other
pass	/*/-/*	wasd_root/runtime/*/*	cache=perm
pass	/wasd_root/runtime/*		/wasd_root/runtime/*
pass	/wasd_root/scr/misc/*		/wasd_root/src/misc/*
#-------------------------------------------------------------------------
# access to server admin
pass	/httpd/-/admin/*
#-------------------------------------------------------------------------
# use this mapping for wasd gsoap example files copied to /cgi-bin
exec+	/soapdemo/soap_calc_sha*	(cgi_exe:gsoaprte)/cgi-bin/soap_calc_sha*
exec+	/soapdemo/soap_calc_cgi*	(cgi_exe:gsoaprte)/cgi-bin/soap_calc_cgi*
#	alternative access notes:
#		$copy soap_calc_share.exe   calc1.exe
#		$copy soap_calc_cgiplus.exe calc2.exe
exec+	/calc*				(cgi_exe:gsoaprte)/cgi-bin/calc*
#-------------------------------------------------------------------------
  • copying files to their target directories then use the DCL-based client to test the service
    $ set def WASD_ROOT:[SRC.GSOAP.CALC]
$ dir *.exe/col=1

Directory DKA200:[WASD_ROOT.SRC.GSOAP.CALC]

CALCCLIENT.EXE;1
SOAP_CALC_CGIPLUS.EXE;1
SOAP_CALC_SHARE.EXE;1

Total of 3 files.
$ copy SOAP_CALC_CGIPLUS.EXE wasd_root:[cgi-bin]
$ copy SOAP_CALC_SHARE.exe   wasd_root:[cgi-bin]
$ copy SOAP_CALC_SHARE.exe   wasd_root:[cgi-bin]calc1.exe
$ test := $DKA200:[WASD_ROOT.SRC.GSOAP.CALC]CALCCLIENT.EXE
$ test
Requires: $ CALC_URL = "http://the.host.name/the/path"
$ CALC_URL = "http://kawc4r.on.bell.ca/calc1"
$ test
Usage: [add|sub|mul|div|pow] num num
$ test add 123 456
http://kawc4r.on.bell.ca/calc1
result = 579
$

Links

Back to Home
Neil Rieck
Waterloo, Ontario, Canada.