06-Nov-2017

Maintenance report
Nothing wrong with the maintenance job:
PMAS statistics for October
Total messages    :   4087 = 100.0 o/o
DNS Blacklisted   :    108 =   2.6 o/o (Files:  1)
Relay attempts    :     26 =    .6 o/o (Files: 31)
Accepted by PMAS  :   3953 =  96.7 o/o (Files: 31)
  Handled by explicit rule
         Rejected :   3074 =  77.7 o/o (processed),  75.2 o/o (all)
         Accepted :    190 =   4.8 o/o (processed),   4.6 o/o (all)
  Handled by content
        Discarded :    400 =  10.1 o/o (processed),   9.7 o/o (all)
     Quarantained :    253 =   6.4 o/o (processed),   6.1 o/o (all)
        Delivered :     36 =    .9 o/o (processed),    .8 o/o (all)

Even no large anti-relay files. Most have a few entries, but none is larger than 4 blocks (2Kb)

More on PHP
I changed the workingset parameters of the WASD scripring user (HTTP$NOBODY) because these may cause problems with PHP:

  • Bytelm 50000 to 1000000
  • wsdef 1000 to 2048
  • wsquo 8000 to 131072
  • wsextent 30000 to 524298
  • pgflquo 500000 to 1000000
  • but that didn’t make any difference for this, just that the blogs run faster, at least without updates… But PHP 5.4 and up won’t run once it fails. Though Mrak said that the adapted PHPWASD version would output the io-error code, none is shown. What I do see are the settings of the HTTP$SERVER account (that is: What’s left of the quota): Large enough.
    |19:53:51.14 CGI 1374 0004 CGI VARIABLES 1,632 bytes|
    |19:53:51.21 CGI 2214 0004 CGI NOT a strict CGI response!|
    AST:1944/2000 BIO:1949/2000 BYT:4953856/4999424 DIO:998/1000 ENQ:450/500 FIL:286/300 PGFL:461376/500000 PRC:0/100 TQ:97/100
    |19:53:51.21 ERROR 0437 **** INTERNAL CGI:2215, not a strict CGI response|
    |19:53:51.22 ERROR 1122 0004 RESPONSE DCL:5321 (basic-only) 502(502) "Script did not provide an acceptable response."|
    |19:53:51.23 GZIP 1008 0004 RESPONSE DEFLATE no, minimal content-length|
    |19:53:51.23 REQUEST 1162 0004 REQUEST STATUS 502 (Bad Gateway) rx:377 tx:917 bytes 0.109368 seconds 11,831 B/s|

    It’s getting worse. At some point, there is another response: The browser cannot find the site, and WATCH shows:
    |20:15:49.47 CGI 1374 0002 CGI VARIABLES 1,642 bytes|
    |20:15:49.47 REQUEST 1162 0002 REQUEST STATUS 000 (Unknown Code!) rx:389 tx:0 bytes 0.002929 seconds 132,787 B/s|

    But when requested immediately after a restart, the site – even the admin pages – will show when the URL is entered in the browser – but next actions will cause the same error – even:

    |20:18:14.11 CGI 1374 0002 CGI VARIABLES 2,023 bytes|
    |20:18:14.11 NET 1802 0001 CONNECT ACCEPTED 82.161.236.244,38057 on http://www.grootersnet.nl,80 (0.0.0.0) BG37011:|
    |20:18:14.11 CGI 2326 0002 CGI RESPONSE header line 1 'Status: 502' 11 bytes|
    |20:18:14.11 CGI 2326 0002 CGI RESPONSE header line 2 'Script-Control: X-error-text="Cannot chdir("/tracks/wp-admin"), i/o error."' 84 bytes|
    |20:18:14.11 CGI 2326 0002 CGI RESPONSE header line 3 'Script-Control: X-error-module="PHPWASD"' 40 bytes|
    |20:18:14.11 CGI 2326 0002 CGI RESPONSE header line 4 'Script-Control: X-error-line=1384' 33 bytes|
    |20:18:14.11 CGI 2588 0002 CGI RESPONSE stream mode|
    |20:18:14.11 ERROR 1122 0002 RESPONSE PHPWASD:1384 (basic-only) 502(502) "Cannot chdir("/tracks/wp-admin"), i/o error."|
    |20:18:14.11 GZIP 1008 0002 RESPONSE DEFLATE no, minimal content-length|
    |20:18:14.11 REQUEST 1162 0002 REQUEST STATUS 502 (Bad Gateway) rx:748 tx:917 bytes 0.006836 seconds 243,581 B/s|

    even when CGI-compliance is disabled….

    WordPress update
    Nevertheless, the update of WordPress (to 4.8.3) was straightforward.

    05-Nov-2017

    Internet connection broken
    Yesterday at 11:15 (or so) the internet connection was down at my ISP – it looked like a broken cable. They rerouted at the end of the afternoon so in the evening I did have connectivity again. This morning however, it was down again for a few hours, due to repair. Why they removed rerouting before the rupture was repaired – I don’t know. But it’s not the right thing to do ….
    PHP again
    Mark Berryman gave me something to work with: looking whether it is memory that causes problems with PHP7. He explained there are several big differences between versions 5 and 7: 7 id fully 64-bit and checks memory boundaries, something PHP 5 (32 bit) doesn’t. So the idea is to switch memory checks off by defining
    $ DEFINE/SUS USE_ZEND_ALLOC 0
    and he supplied special builds of the WASD PHP engine – but didn’t tell what the changes imply: Logging?

    Tried them this evening – but without result.

    I also set the memory boundary in PHP.INI to 512M – four times from the original. But even that didn’t help.

    So back to the version that does work…

    (There may be an issue with the database: Connection is lost, at times.. Perhaps PHP 5.2-13 does have problems as well??)

    30-Oct-2017

    PHP updates are a problem
    Installed PHP 7.0 tonight and set things up.
    The blogs show up once but on login, the site fails with a 502 error: Seems to be an IO error on PHPWASD (which is the PHP7.0 version of PHPWASD.EXE) but the problems seems to lay elsewhere, because the logfile states:
    %HTTPD-W-NOTICED, 30-OCT-2017 20:56:35, CGI:2215, not a strict CGI response
    -NOTICED-I-SERVICE, http://www.grootersnet.nl:80
    -NOTICED-I-CLIENT, 82.161.236.244
    -NOTICED-I-URI, GET (8 bytes) /Tracks/
    -NOTICED-I-SCRIPT, /tracks/index.php tracks:[000000]index.php (phpwasd:) TRACKS:[000000]index.php
    -NOTICED-I-CGI, 2544434C2D572D414354494D4147452C206572726F722061 (50 bytes) %DCL-W-ACTIMAGE, error activating image PHPWASDSHR
    -NOTICED-I-RXTX, err:0/0 raw:330/0 net:330/0

    Even after restarting WASD. After that, normal access is no problem, until login is attempted – and I get the same error: need to restart the server before I can access the site again….

    I also tried 5.4 – which did work. But that is now failing also – from the beginning.

    So back to 5.2-13, for now…
    Later, I retried 5.4. It seemed to work, but posting an update to this post caused it to fail, for some reason. A second try didn’t, so the verdicht should be “unstable”. WATCH showed this error also:

    215108 .72 DCL      5813 0003 DCL        WRITE CGIPLUSIN %X00000001
    215108.72 DCL      5813 0003 DCL        WRITE CGIPLUSIN %X00000001
    215108.72 DCL      5068 0003 DCL        READ SYS$OUTPUT %X00000001 158 bytes
    53746174 75733A20 3530320D 0A536372 6970742D 436F6E74 726F6C3A 20582D65 Status 502..Script-Control X-e
    72726F72 2D746578 743D2243 616E6E6F 74206163 63657373 20736372 6970742C rror-text=Cannot access script,
    20692F6F 20657272 6F722E2E 220D0A53 63726970 742D436F 6E74726F 6C3A2058  io error....Script-Control X
    2D657272 6F722D6D 6F64756C 653D2250 48505741 5344220D 0A536372 6970742D -error-module=PHPWASD..Script-
    436F6E74 726F6C3A 20582D65 72726F72 2D6C696E 653D3133 34390D0A 0D0A     Control X-error-line=1349....
    215108.72 CGI      2326 0003 CGI        RESPONSE header line 1 'Status 502' 11 bytes
    215108.72 CGI      2326 0003 CGI        RESPONSE header line 2 'Script-Control X-error-text=Cannot access script, io error..' 64 bytes
    215108.72 CGI      2326 0003 CGI        RESPONSE header line 3 'Script-Control X-error-module=PHPWASD' 40 bytes
    215108.72 CGI      2326 0003 CGI        RESPONSE header line 4 'Script-Control X-error-line=1349' 33 bytes
    215108.72 CGI      2588 0003 CGI        RESPONSE stream mode
    215108.72 ERROR    1122 0003 RESPONSE   PHPWASD1349 (basic-only) 502(502) Cannot access script, io error..
    215108.72 DCL      5921 0003 DCL        WRITE HTTP$INPUT 181 bytes

    But nothing of this was shown on screen – it all looked fine on the screen. Perhaps it’s just in the administration panels…

    29-Oct-2017

    All blogs on MariaDB
    Tonight I installed the latest version of MariaDB that has been published on OpenVMS (5.5.58) and moved all blogs to that version. Or stated otherwise: phased out MySQL 5.1.43, that served me well for several years. Since my requests have been included (ask what port to be used – not 3306 since yoy may have multiple database engines running…) this went fine: Copy the MYSQL databases to MariaDB and convert them. It meant I needed to redo the changes I did on the Trips, Tracks and Travels blog but since these are minor, it was not much of a problem. Added a new entry as well.
    So far, it seems that this blog is faster than the other, but time will tell about the full performance.
    If all runs well for some time, the next step is to update PHP – preferably to the latest version (7.0.24) that has been set up – but not yet activated.

    23-Oct-2017

    MariaDB active
    Tonight I started MariaDB and had it ‘active’ for at least 15 minutes – longer than the previous version could stay alive. But nothing happened, so I did some SQL work, that would cause the server to die before. But it stayed on.
    So I changed access for the Trips, Tracks and Travels blog to use MariaDB – there was no change in that blog after I moved it to MariaDB. had to do some updates but they al seemed Ok. (Changed the Admin password, for a change :)).

    For now, it looks fine; Time will tell, but if everything is going as it should, this blog will be the next – which will require moving the whole MySQL database again, but now I know that the process works, it should not be a problem. Except that the blogs will be unavailable for an hour or so.

    Stay tuned….

    22-Oct-2017

    MariaDB test
    After my last test – of which I passed the results to Mark Berryman – a new version has been released last week. I downloaded it as soon as I could, tonight I installed it and ran the upgrade that failed. This time, it succeeded, but the following step: creating SSL certificates – failed on a the heavier one. Nevertheless, the database _should_ work so I started MaraiDB and have it run – doing nothing, but it should stay alive.

    If that runs, next step is testing it with WordPress, to start with. If that’s Ok, I’ll head on with PHP upgrades. Perhaps take the big step and have 7.0 running, it should work, because that’s the recommendation of WordPress.org…

    To be continued…

    18-Oct-2017

    Blog problems
    A few days ago I noticed that neither blog was accessible: I got non-CGI-conformant reponses which caused WASD to signal an error. As it turned out, this was caused by different errors that occurred out-of-the-blue on the 6th of October:

    %HTTPD-W-NOTICED, 06-OCT-2017 06:01:44, CGI:2215, not a strict CGI response
    -NOTICED-I-SERVICE, http://www.grootersnet.nl:80
    -NOTICED-I-CLIENT, 8.29.198.27
    -NOTICED-I-URI, GET (19 bytes) /sysblog/?feed=atom
    -NOTICED-I-SCRIPT, /sysblog/index.php sysblog:[000000]index.php (phpwasd:) SYSBLOG:[000000]index.php
    -NOTICED-I-CGI, 2553595354454D2D462D53544B4F56462C20737461636B20 (66 bytes) %SYSTEM-F-STKOVF, stack overflow, PC=FFFFFFFF80C3B42C, PS=0000001B
    -NOTICED-I-RXTX, err:0/0 raw:286/0 net:286/0

    and occasionally

    %HTTPD-W-NOTICED, 06-OCT-2017 13:04:30, CGI:2215, not a strict CGI response
    -NOTICED-I-SERVICE, http://www.grootersnet.nl:80
    -NOTICED-I-CLIENT, 164.132.161.58
    -NOTICED-I-URI, GET (20 bytes) /sysblog/?m=20080721
    -NOTICED-I-SCRIPT, /sysblog/index.php sysblog:[000000]index.php (phpwasd:) SYSBLOG:[000000]index.php
    -NOTICED-I-CGI, 2553595354454D2D462D41434356494F2C20616363657373 (118 bytes) %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=000000003B706870, PC=FFFFFFFF80C3B42C, PS=0000001B
    -NOTICED-I-RXTX, err:0/0 raw:188/0 net:188/0

    It made no difference whether I restarted the server, of MySQL (since that causes time-outs in PHP 5.4 causing similar problems here).
    Unaware of any change in the environment, I consulted Mark Daniel but even he couldn’t locate something…

    However, tried again today with WATCH enabled, i DID get a response I could work with: accessing SYSBLOG not just gave me the output I was familiar with, but also a clue on what may have been the cause: WAS was able to capture the output of the PHP engine before it was overwritten (?) by the error (that also showed up) which is returned to the browser – causing the Server error (and hence, non-conformant response). And that lead to the memory blink: I renamed one of the files in the WordPress environment, assuming it was one of those blog-specific files. It isn’t….

    So I revered that error – and the blogs are accessible again.

    This is the WATCH result that suddenly showed the case: When accessing this blog, once the stack trace was found. The Trips, Tracks and Travels blog, accessed a few minutes later, shows just the result; without the warning – and this is what I normally would see when WATCHing this.

    01-Oct-2017

    Maintenance and required updates
    Last night’s maintenance run had no surprises:

    PMAS statistics for September
    Total messages    :   4064 = 100.0 o/o
    DNS Blacklisted   :      0 =    .0 o/o (Files:  0)
    Relay attempts    :    374 =   9.2 o/o (Files: 30)
    Accepted by PMAS  :   3690 =  90.7 o/o (Files: 30)
      Handled by explicit rule
             Rejected :   2873 =  77.8 o/o (processed),  70.6 o/o (all)
             Accepted :    160 =   4.3 o/o (processed),   3.9 o/o (all)
      Handled by content
            Discarded :    380 =  10.2 o/o (processed),   9.3 o/o (all)
         Quarantained :    262 =   7.1 o/o (processed),   6.4 o/o (all)
            Delivered :     15 =    .4 o/o (processed),    .3 o/o (all)

    A peak on relay attempts was on 05-Sep-2017: 350 times from address 187.188.81.84, using sender “root@www.grootersnet.nl” trying to reach “tester@auteam.com.mx”, between 17:23:10.21 and 23:32:56.63. Except for one message, using sender address “root@82.161.236.244″ (does this one use DNS translation to get the domain name? Looks like it).
    Anyway, this host is located in Mexico:

    Hostname = fixed-187-188-81-84.totalplay.net
    City = Naucalpan, Estado de Mexico MX
    Latitude/Longitude = 19.4794,-99.2383
    Postal Code = 53370

    and WHOIS gave me:

    Description:TOTAL PLAY TELECOMUNICACIONES SA DE CV
    Netname:MX-TPTE-LACNIC
    inetnum:187.188/15
    status:allocated
    aut-num:N/A
    owner:TOTAL PLAY TELECOMUNICACIONES SA DE CV
    ownerid:MX-TPTE-LACNIC
    responsible:Alejandro Enrique Rodriguez Sanchez
    address:PERIFERICO SUR, 4119, FUENTES DEL PEDREGAL
    address:14140 – TLALPAN – CX
    country:MX
    phone:+52 xxxxxxxx []
    owner-c:CIT12
    tech-c:CIT12
    abuse-c:CIT12
    inetrev:187.188/15

    just that period, no more.
    The address is listed in a number of blacklists as spammer. No wonder if your relay is open…
    But why try 350 times and in rather shorty bursts when every attempt does not succeed? Perhaps trying to cause mail service on a Linux server to fail. But PMAS has done a good job by refusing”grootersnet.nl” from outside my LAN.

    No Sir:

  • “root”?
  • “grootersnet.nl” from outside ?
  • Not on this box.

    Licenses
    But before I could check the log, I had trouble logging in: username and password returned to the password prompt without message. The Powerterm session that is the actual Alpha console was not responsive – hadn’t been whole week. As it turned out, there was no physical connection: there is a pair of connectors in between and I probably stumbled into the cable and caused the to come loose, as well as the USB-based RS232-interface. Got that working again, and since I was logged in on this terminal, I could access the machine – and try a $ Telnet 0 session. That failed: License expired. This makes sense since the expiration date of this license-2017 set was 30-Sep-2017. I thought I had installed the licens-2018 set (that came with the Itanium licenses) but it turned out I didn’t load the 2018 set, which is valid up to March next year. However, the file was already present on Diana so running it solved that problem.

    A similar thing has happened on Daphne – the Personal Workstation – that I started up. The scripts didn’t exist there so I had to be somewhat creative:

  • Prepare FileZille to connect and copy the right file
  • $ Set time=yesterday
  • $ @license2017
  • $ @sys$startup:TCPIP$STARTUP
  • Connect to Daphne and copy the file using FileZilla
  • $ @license2018
  • $ reboot ! (since the box is in a cluster, that will set time correctly)
  • Now I can get on on that machine to set up NxtWare (Samba needs to be installed with the older version)

    WordPress update
    Before entering this post, I updated WordPress to the latest version (4.8.2) and Akismet (4.0), changed the blog logicals accordingly – also in the startup script that sets them on boot. No issues.

    17-Sep-2017

    Certificates
    The job checking whether certificates need to be renewed does it job: No issues on the secured sites, but still on the main one. Will have top ask, because otherwise the expected https-connection will not work properly… It is weird because it has worked before, but it may be related to changes in eiter WASD_ONFIG_AUTH or WASD_CONFIG_MAP – but these have been minimal. Or WASD_CONFIG_SERVICE ma have a bad spec? It seems Ok, though…

    CIFS
    Required for the new development environment using NXTWARE: The old PWS (Daphne) is set up to be the scapegoat for testing, and Java and GNV are now both installed – but the product requires Samba (CIFS) as well to access the files to handle. IO have versions 1.1 in my store, but the latest I know of to be available is version 1.2 – ECO1. To locate the download site proved a search for several hours, and once found, it leads to a location of which the browsers tell me it does not exist. Or is unreachable. asked at on forum at HPE but got no reply (yet).
    Asked on the OpenVMS SIG and got a reply within minutes: ftp://ftp.hp.com/pub/openvms/private/CIFS/. Use that URL in Chrome, because Edge won’t find it:

    Hmmm…can’t reach this page
    Try this

  • Make sure you’ve got the right web address: ftp://ftp.hp.com
  • Search for “ftp://ftp.hp.com” on Bing
  • Refresh the page
  • Details

    Error Code: INET_E_OBJECT_NOT_FOUND

    and using a tool like FileZille won’t find this CIFS folder on the site.

    Anyway, got the files now, for both Alpha and Itanium. so I’ll install then somewhere this week.