soyMAIL 2.1.0 requires JavaScript
soyMAIL @ wasd.vsm.com.au
       info-WASD Mailing List 2020 

Mon 20:57:10 Message "2020 / 0108" opened.  MIME.  4 kbytes.    JavaScript

Subject:[Info-WASD] WASD x86-64 running, jumping, standing still0108 / 0000
From:Mark.Daniel@wasd.vsm.com.au
Reply-to:info-wasd@vsm.com.au
Date:Tue, 22 Sep 2020 15:18:01 +0930  [22-SEP-2020 15:18]
To:info-WASD@vsm.com.au

Late last week the core server code was brought over to a VMS V9.0-D EAK
system supported by Jeremy Begg of VMS Software Systems.  It built with a
minimum of fuss and invested time, and was up running in demonstration mode.

A full WASD source kit (essentially v11.5.1) UNZIP and installation has now
been performed.  Of course the object modules needed to be cross-compiled on
an Itanium, taken to the x86 system, and the @WASD_ROOT:[000000]INSTALL
performed as a link-only build.  Voila!

As this is written it's pretty much an all-singing, all-dancing WASD server
(to further mix the metaphors).

You are welcome to have a look around.

  https://x86v1.vsm.com.au:7443/
  http://x86v1.vsm.com.au:7080/

Note that the TLS service is using an internally generated server certificate
that all browsers should complain about but most allow to be accepted and
connected to.  Alternatively, there's the plaintext port.  Once port 80 is
available (see below) wuCME will be installed and provide a Let's Encrypt
issued certificate.

Note that this server is using the more commonly demonstration mode ports,
7080 and 7443, but is NOT running in demonstration mode.  This is an interim
workaround.

Explanation: it seems a network stack bug has been encountered.  When
attempting to bind to the privileged ports 80 and 443 an insufficient
privilege status is returned.

8< snip 8<
%HTTPD-I-SERVICE, http://x86v1.vsm.com.au:80
-SERVICE-W-BIND, error binding to 119.252.17.9:80
-SYSTEM-F-NOPRIV, insufficient privilege or object protection violation
-SERVICE-W-RETRY, try again using INADDR_ANY
-SERVICE-W-BIND, error binding to 0.0.0.0(INADDR_ANY):80
-SYSTEM-F-NOPRIV, insufficient privilege or object protection violation
%HTTPD-I-SERVICE, https://x86v1.vsm.com.au:443
%HTTPD-I-SSL, x86v1.vsm.com.au:443
-SSL-I-CERT, none - make ex nihilo
-SSL-I-STRICT, HSTS transport security enabled
Generate x86v1.vsm.com.au 2048 bit private key:
................................................................................
.......................................................................+++++
..................................................................+++++
-SERVICE-W-BIND, error binding to 119.252.17.9:443
-SYSTEM-F-NOPRIV, insufficient privilege or object protection violation
-SERVICE-W-RETRY, try again using INADDR_ANY
-SERVICE-W-BIND, error binding to 0.0.0.0(INADDR_ANY):443
-SYSTEM-F-NOPRIV, insufficient privilege or object protection violation
8< snip 8<

A simple reproducer using BSD sockets and bind() has the same issue.  This
has been reported to VSI.

Further temporal expenditure; perhaps 8 hours.  Some of this is the
cross-compiling and moving objects onto the system.  An x86-64 UNZIP built by
Jeremy (after me b&m about the lack) is a much appreciated tool.  There is
probably an additional 8 hours that I'll quite happily attribute to my own
fumbles.  All in all, WASD has progressed much further on the EAK that I
imagined it might.  It seems WASD is all-but ported.  A moderately large and
complex VMS application.  Now just waiting for the lurking gremlins.

Regards, Mark.

  ¤¤¤       
  ¤¤¤