WASD 11.1 running!
Contacted mark Daniel directly on the issue and offered him access to the server to have a look at the live environment. As it turned out, there were a few things.
First, the SSL kit installed (1.4) is still based om 0.8.8, where WASD 11.1 requires 1.0.2. Actually, 11.0 ran TLS as well but that one is less restrictive. Than, I remembered why the later version (named SSL!) wasn;t installed – I downloaded the kit and it explicitly stated that this one is incompatibel with the 1.4 version (installed) and would require patches on a number of products – and I canbnot get them – so that’s why I didn’t. (having said that: it’s clear why this kit has a different profix (SSL1 in stead of the expected SSL).
Mark had a diffeernt approach: Het got the certificates I need from Lets’s Encrypt and installed them. Now the secure sites were accessable. Heft left 11.1 running so I could get on.
Well, that was this morning. When I found out that both Firefox and Chrome will access the first secure site acessed, and keep that site at hand when you access another. For isntance: accessing webmail (and login), next access the operator pages, you will have to login on webmail again (it will do so directly since you already did). Otherwise: first login at the operator pages will use that loigin for webmail as well – and you’ll end up in the opertaor page, even when the URL states webmail….

This happpened when HTTP/2 enabled. Without, it seemed fine. Se we left it that way – for the time being.
Not until a few hours later, when Mark notices a missing bit in the HTTP/2 processing on secure sites – a bit hidden in the specs. That has been fixed now, and so |I’m a bit ahead of other WASD users :). And HTTP/2 enabled.


New WordPress
Latest version of WordPress (4.8) has been installed and all blogs are now on this version.

But no new server
But getting WASD 11.1 running properly still doesn’t work, at least, for the secured sites. It could have been a matter of updates to the configuration files. Mine were outdates – had some obsolete options and missed some other ones, including the SSL ones, but the server would fall back on internal defaults ao it should work. But it made no difference.
Checking access using the WASD_SSL package (both with the openssl image and over the web) accessing the secured ports is file. But when started, these still fail to setup a connection. No signal AT ALL, not in the page, nor in the server logs….WATCH doesn’t show anything either, just that the request is coming in, some data is sent and the connection is closed….


More on WASD 11.1 and TLS,/font>
I Looked into some startup files, I may need other files; HP’s SSL package is still based on 9.8.0, where WASD-SSL is based on OpenSSL 1.0.2. The procedure that starts WASD defines these files to be used, so that may cause the problems. However, I could not find files to be installed or referenced in startup. So I asked the WASD mailing list.


#1: WordPress / Akismet: Without trouble. Startup updates to reflect the change.
#2: HP’s OpenSSL package – this could be the cause of problems with WASD 11.1. Just cheking whether this did the trick: I may need to redo the update procedure. 11.0 works with this new version, but 11.1 doesn’t when accessing one of the secured sites. Strange, however: in demo mode it DOES work, without rebuilding the server….
Current installation of OpenSSL:
$ sho sym openssl
$ openssl version
OpenSSL 1.0.2k 26 Jan 2017

and after HP’s installation:
OpenSSL 0.9.8zh 3 Dec 2015
SSL for OpenVMS V1.4 Feb 5 2016.

This should be the right version: I checked HPE.com, dile is version is 1.4-0503, installed today:
$ prod show hist
------------------------------------ ----------- ----------- --- -----------
PRODUCT                              KIT TYPE    OPERATION   VAL DATE
------------------------------------ ----------- ----------- --- -----------
HP AXPVMS SSL V1.4-503               Full LP     Install
     Val 04-JUN-2017
HP AXPVMS SSL V1.4-502               Full LP     Remove       -  04-JUN-2017
HP AXPVMS SSL V1.4-502               Full LP     Install
     Val 05-JAN-2016

But still, it won’t connect.
So I recreated the DH_keyfiles (512, 1024 and 2048 bit), and retried: Now it’s OK running the WASD version – using specifications I set up some time ago):

$ openssl s_client -connect www.grootersnet.nl:443

depth=0 C = NL, ST = UT, L = leusden, O = Grootersnet, OU = Webservices, CN = *.grootersnet.nl, emailAddress = system@grootersnet.nl
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = NL, ST = UT, L = leusden, O = Grootersnet, OU = Webservices, CN = *.grootersnet.nl, emailAddress = system@grootersnet.nl
verify error:num=21:unable to verify the first certificate
verify return:1
Certificate chain
 0 s:/C=NL/ST=UT/L=leusden/O=Grootersnet/OU=Webservices/CN=*.grootersnet.nl/emailAddress=system@grootersnet.nl
   i:/C=AU/ST=SA/L=Adelaide/O=WASD HTTPd CA Cert/OU=OpenSSL 0.9.8 Testing Only/CN=WASD VMS Hypertext Services/emailAddress=Mark.Dani
Server certificate
issuer=/C=AU/ST=SA/L=Adelaide/O=WASD HTTPd CA Cert/OU=OpenSSL 0.9.8 Testing Only/CN=WASD VMS Hypertext Services/emailAddress=Mark.Da
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
SSL handshake has read 2132 bytes and written 433 bytes
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 5C66A91090EB2A8444AEB1AA30E8F7FA8EE674442E2EC4042E54E7FD05197FFB
    Master-Key: 1463D1FBAA5D6B2A7B052B15187FD0E01B784B8BFC5F1C7B678FCC1074B87C2C9E6CD49A30BAAD496CE23CCC3DA0937E
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    Start Time: 1496607150
    Timeout   : 300 (sec)
    Verify return code: 21 (unable to verify the first certificate)
openssl s_client -connect www.grootersnet.nl:443
<TITLEglt;ERROR 501 Not Implemented</TITLEglt;
<BODY LINK="#0000cc" VLINK="#0000cc"glt;
<FONT SIZE=+1glt;
<Bglt;ERROR 501</Bglt;  -  The requested action is not implemented by this server.
<Pglt;Additional information: 
<A HREF="/httpd/-/status1xx.html"glt;1<Iglt;xx</Iglt;</Aglt;, 
<A HREF="/httpd/-/status2xx.html"glt;2<Iglt;xx</Iglt;</Aglt;, 
<A HREF="/httpd/-/status3xx.html"glt;3<Iglt;xx</Iglt;</Aglt;, 
<A HREF="/httpd/-/status4xx.html"glt;4<Iglt;xx</Iglt;</Aglt;, 
<A HREF="/httpd/-/status5xx.html"glt;5<Iglt;xx</Iglt;</Aglt;, 
<A HREF="/httpd/-/statushelp.html"glt;Help</Aglt;
<Pglt;<HR WIDTH=85% ALIGN=left SIZE=2 NOSHADEglt;
<ADDRESSglt;WASD/11.1.0 Server at www.grootersnet.nl Port 443</ADDRESSglt;

but now the HP version fails:
$ opensslHP s_client -connect www.grootersnet.nl:443
539100522:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:S23_CLNT:579:

but where I would expect I could access the secured sites, but that still fails. if this has to do with logical SSL$ROOT, it makes sense:
$ sho log ssl*






"SSL$EXE" = "SSL$ROOT:[Alpha_EXE]"



Restart of the server makes no difference….Maybe I need to change a few things here.


Monthly maintenance
The standard script didn’t show up anything weird:

PMAS statistics for May
Total messages    :   2929 = 100.0 o/o
DNS Blacklisted   :      0 =    .0 o/o (Files:  0)
Relay attempts    :    194 =   6.6 o/o (Files: 31)
Accepted by PMAS  :   2735 =  93.3 o/o (Files: 31)
  Handled by explicit rule
         Rejected :   1843 =  67.3 o/o (processed),  62.9 o/o (all)
         Accepted :    168 =   6.1 o/o (processed),   5.7 o/o (all)
  Handled by content
        Discarded :    404 =  14.7 o/o (processed),  13.7 o/o (all)
     Quarantained :    285 =  10.4 o/o (processed),   9.7 o/o (all)
        Delivered :     35 =   1.2 o/o (processed),   1.1 o/o (all)

Surprisingly, the number of relay attempts has dropped; most (158) occurred on 25-MAY-2017 between 08:52:48.06 and 09:02:03.88; all “sent” from (fake) users in my domain to be received by 1029mandaditos@gmail.com. from address – seems to be hosted in France (astucesaclashofclans.fr) but the domain of the PTR record is Brazilian (plmc-113-30-129-212.grandesnoticias.com.br). The address raises red flags in 6 blacklsist.

Another issue that came up when examining the router logs. Not the number (well, a new 25K+ file every 2 or 3 days, need to check out earlier files) but that may have to do with the new router, though it should be compatible with the older one. Except that its throughput is way up, so it can handle more traffic….
But that is not the point.
What I found was, that, for the current file, ever 5 minutes or so, my workstation scans port 8612 in my network – both IP4 (LAN -> LAN) and IP6 (L:AN -> WAN). These are short messages (20 bytes) but what causes it? Searching the internet I found it is a CANON protocol, and I did install new Canon drives last week…I looked into the services and found a Canon service running which might be the cause – so I stopped it. But that doesn’t help…But looking on the resource manager, I located another one: CNMNSST.exe, and that indeed is the program I’m looking for. It doesn’t do much harm, according the descriptions: Hardly any CPU, memory or disk/IO: but it doesn’t mention it will constantly scan the network for a printer. This si something I need to dig into: It’s started by the task manager so there might be something to tweak.

WASD Update failure: Source located.
Actually, the update is fine. It’s just that secures sites are no longer accusable. Mark gave me a hint that I flowed up:

$ openssl :== $ SSL$ROOT:[ALPHA_EXE]openssl.exe
$ openssl s_client -connect www.grootersnet.nl:443

on 11.0.2 (what I’m running now), this starts the handshake:

$ openssl s_client -connect www.grootersnet.nl:443
Server certificate
(etcetera etcetera)

after which a command can be entered.

On 11.1:

$ openssl s_client -connect www.grootersnet.nl:443
539094439:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:S23_CLNT:593:

And that’s it.

Mark’s comment:

Incompatible version (see below).

(because there was more…)

Might be an SSL issue?

$ OpenSSL version
OpenSSL 0.9.8ze 15 Jan 2015
SSL for OpenVMS V1.4 Feb 18 2015.

Yes. This looks like the obsolete HP SSL kit

|$ mcr SYS$COMMON:[SSL.ALPHA_EXE]OPENSSL.EXE version OpenSSL 0.9.8ze 15
|Jan 2015 SSL for OpenVMS V1.4 Feb 18 2015.

I get the same result using that version

There are some things to consider now, but first Update WordPress and Akismet 🙂


Webserver update
Just updated WASD but there is a problem with the secured access, so webmail and operator sites are not accessible; Weird is that doesn’t ask for authentication – it just fails to show completely – nothing is returned… Problem is that the WATCH output cannot be created – because the admin tools live in the (no inaccessible) operation site….
Reason: from the release notes:

TLS/SSL default configuration (cipher list and options) maximises security and is compatible with most modern agents (minimum Firefox 27, Chrome 30, IE 11 on Windows 7, Edge, Opera 17, Safari 9, Android 5.0, and Java 8). Ciphers require “Forward Secrecy” and presence of [LOCAL]DH_PARAM_nnnn.PEM safe prime files. To support older clients the configuration must be downgraded

So there is some reading and postprocessing to do.
By the way: the configuration files that were created in version 8.something, has never been updated, so it’s a good moment to do it now, using the example file.
In the mean time, I have reversed the installation, so I’m back on 10.0.2, until it’s clear what to do..


Maintenance report
There isn’t much to mention on maintenance.

PMAS statistics for April
Total messages    :   2796 = 100.0 o/o
DNS Blacklisted   :      0 =    .0 o/o (Files:  0)
Relay attempts    :    209 =   7.4 o/o (Files: 30)
Accepted by PMAS  :   2587 =  92.5 o/o (Files: 30)
  Handled by explicit rule
         Rejected :   1793 =  69.3 o/o (processed),  64.1 o/o (all)
         Accepted :    164 =   6.3 o/o (processed),   5.8 o/o (all)
  Handled by content
        Discarded :    339 =  13.1 o/o (processed),  12.1 o/o (all)
     Quarantained :    274 =  10.5 o/o (processed),   9.7 o/o (all)
        Delivered :     17 =    .6 o/o (processed),    .6 o/o (all)

The number of relay attempts is not that high: the most (100) have been on April 26th, the rest (just a few days) were far less.

New router
I purchased the follow-up mof my Vigor 2920 router: a 2925Vac one. It has bot 2.4 Ghz and 5 GHz wireless, and supports 8.11ac protocol for LAN traffic. I could prepare it yesterday evening using the 2920 as a example (I could have restored the backup of that one) and installed it this evening. Apart from one thing I forgot: specifying which phone is what number, and setting up opened ports – I set them up but probably forgot to save the configuration – changing wnet without a hitch (Of course I had to apply these changes….) and the result in access, especially Wireless, is eminent. And I run the speed test: Up- and download went up to about 85 MB/s – matching the current speed of 100Mb/sec: This router’s firewall has a throughput of 200Mb/s, 4 times the bandwidth of the 2920….

Next month, my Internet speed will increase to 160 Mb/s (with no extra cost) and this router is fit for that (I got the announcement AFTER I received the router 🙂 ) so I’m ready 🙂

PHP 5.4 retest ahead
I planned a test of PHP 5.4 (dnd MariaDB 5.5) tomorrow evening, hopefully I don’t run into problems now, since I changed the system parameters. I may also need to reboot the server to include latest changes, based on AutoGen reporting.
So far the results of the performance look nice. Memory usage goes up to 75%, as before, bot slowly, and sometimes it seems to be eset. Something to investigate.

New version of WASD (and alamode)
New version of the webserver has been downloaded, and the accompanying monitor program. To be installed tomorrow (as well)


First day
Looked into the first (approximately) 24 hours running with the new parameters; not just increased a number of process parameters, but removed some settings required for a number of programs I don’t use anymore, and an increment of page file size (not a requirement but based on minimal values): memory usage (both physical and virtual) have decreased a little from 75% to 50%, but it’s my feeling that mainly due to increased page file sizes.
Paging however, seems the same:

until about 10:00 system time this morning:

It may have to do with PMAS receiving mail, that requires the data to be available. But that has gone on for several hours from midnight, a message per minute; but after about 9:50 messages come in every 5 seconds, so it may well have to do with PMAS – or SYSLOGD writing out messages. Checked the syslogd output – the only available source at the moment – and found the address, residing in Thailand ( so I blocked it from accessing the network.

(To be continued)


Changed system parameters
Remember I had problems with MariaDB and PHP? I knew there were some changes to be done to the system, and where, but to what values? I asked Mark Berryman (who ported PHP and MariaDB to VMS – so he has some experience in the matter) and he came up with another set of values – in the PQL (Process Quota Limits) area; he has the same type of system as I do (DS10, 2 Gb memory) so I changed my system accordingly: some limits doubled, others tripled in value – which makes sense since the original values come from a 256Gb system….

parameter          old       new
-------------- -------   -------
PQL_DFILLM         128       200
PQL_DWSDEFAULT    2352      6531
PQL_MWSDEFAULT    2352      6531
PQL_DWSQUOTA      4704     13062
PQL_MWSQUOTA      4704     13062
PQL_DWSEXTENT   262144   1280000
PQL_MWSEXTENT   262144   1280000

Since WSDDAULT parameters are not dynamic, I had to reboot.
The result is eminent: the blog runs way faster and smoother; but time will tell whether this is right or needs even more adjustments.
I aloo noted an error in calling MySQL shutwond and startup procedures, and corrected them

Next is a WordPress update 🙂

(Done. Now on 4.7.4)

Next to do is trying PHP 5.4 again, to see whether that stays alive.


Cleanup and configuration changes
First of all, I have started a new accounting file – thought it’s time to do so after 5 years: It takes quite some time to get to the latest data (the file is 256 Mb in size…). Next, I extracted the data of the server-executoree (HTTP%NOBODY) after 01-Jan-2017, to find out what mnay cause the PHP problems. It could be a matter of sizing. It looks like it, and that meant I had to change the working set parameters of this user:

UAF> sho http$nobody

Username: HTTP$NOBODY                      Owner:  WASD Scripting
Account:  WEBSRV                           UIC:    [76,1] ([HTTP$NOBODY])
CLI:      DCL                              Tables: DCLTABLES
Flags:  DisNewMail DisMail
Primary days:   Mon Tue Wed Thu Fri
Secondary days:                     Sat Sun
Primary   000000000011111111112222  Secondary 000000000011111111112222
Day Hours 012345678901234567890123  Day Hours 012345678901234567890123
Network:  ##### Full access ######            ##### Full access ######
Batch:    -----  No access  ------            -----  No access  ------
Local:    -----  No access  ------            -----  No access  ------
Dialup:   -----  No access  ------            -----  No access  ------
Remote:   -----  No access  ------            -----  No access  ------
Expiration:            (none)    Pwdminimum:  6   Login Fails:     0
Pwdlifetime:         90 00:00    Pwdchange:  14-AUG-2012 07:49
Last Login: 14-AUG-2012 07:48 (interactive), 13-APR-2017 19:20 (non-interactive)
Maxjobs:         0  Fillm:       500  Bytlm:       500000
Maxacctjobs:     0  Shrfillm:      0  Pbytlm:           0
Maxdetach:       0  BIOlm:      2000  JTquota:       4000
Prclm:         100  DIOlm:      1000  WSdef:         1000
Prio:            4  ASTlm:      2000  WSquo:         4000
Queprio:         0  TQElm:       100  WSextent:     20000
CPU:        (none)  Enqlm:       500  Pgflquo:     500000
Authorized Privileges:
Default Privileges:
Identifier                         Value           Attributes
  WASD_HTTP_NOBODY                 %X8001001D
UAF> mod http$nobody/wsquo=8000/wsextend=30000/biolm=2048/diolm=1024
%UAF-I-MDFYMSG, user record(s) updated

That should make at least some difference, time will tell.

Another addition is a job that should tell me about the workload during some time, it may mean I’ll have to do some changes to system parameters and reboot. But this will take a few weeks to set in.

MariaDb test
I had installed MariaDb 5.5, as ported by Mark Berryman. There were two issue with the creation of SSL certificates: The routine wasn’t found where expected, and though all references are to SSL$ROOT:, there is one that refers to SSLROOT (within one of these procedures). Might have been a local issue, and was easily circumvented.
I copied MySQL database using conversion routines, in stead of creating a new one and loading the export (the backup of then database).
One thing to change anyway is the port to listen on: 3306 is currently in use my MySQL 5.1 that is used by the blogs. So I changed this to 3316, and started the server.
Next I connected using mysql -u root -p – entered my password, and could access the data. But at some point, the server crashed, it seems to occur in LIBRTL. This happened three times, same signature (at first glance).

That means contacting Mark Berryman….