Apart from what happened last month, there is not much to look at. PMAS does its work:
PMAS statistics for February
Total messages    :   2534 = 100.0 o/o
DNS Blacklisted   :      0 =    .0 o/o (Files:  0)
Relay attempts    :     73 =   2.8 o/o (Files: 28)
Accepted by PMAS  :   2461 =  97.1 o/o (Files: 28)
  Handled by explicit rule
         Rejected :   1682 =  68.3 o/o (processed),  66.3 o/o (all)
         Accepted :    200 =   8.1 o/o (processed),   7.8 o/o (all)
  Handled by content
        Discarded :    278 =  11.2 o/o (processed),  10.9 o/o (all)
     Quarantained :    264 =  10.7 o/o (processed),  10.4 o/o (all)
        Delivered :     37 =   1.5 o/o (processed),   1.4 o/o (all)

Just the number of rejected messages is larger than normal, I’ve seen them coming in in the last week only; 26-Feb-2017 being most: Looking at the size of operator.log, it was over 1200 blocks on that day; the others that week were over 400, except for one, where less than 100 should be normal. The number of relay attempts was little; only on 08-Feb the attempts resulted in a log that was over 4 blocks in size, and mainly from one source – trying to relay. It could have been a test, sending from address as “antispam@nmap.scanme.org”, “antispam@diana.intra.grootersnet.nl” or “antispam@[]” to a number of addresses all related to the same organization. I checked this address and it is listed in a number of blacklists, so it might as well be an attempt to see if there is a way to abuse the mailserver. But that checks the IP address of the sending server and if it not from my own address, and the recipient is outside my domain, it will fail.
As simple as that.

I had some trouble installing OpenVMS on the Itanium servers – one at least. It would find the DVD, start reading it but then halt. First, I thought it could have been a bad DVD, so I tried to read it on my old PWS, and I could access the files (not run the executables because these at I64 images, not AXP…). The DVD wasn’t as bad as I thought it was….
So first I could try to make it accessible over the network: meaning I would have to start Infoserver on the PWS (which should be possible since that runs VMS 8.4). At last, found the documentation on the Internet to set it up, but the docs were a bit limited but with the examples, I think I had it all right, but in the end, I couldn’t start Infoserver on that box – still have to find out what caused it to fail.
Second, I found out that I need to enable the iLO unit first – meaning I had to connect it the the network (it will be set up using DHCP to begin with), see what address was assigned to it – with dhcpdbdump, the MAC address is recognizable as from the Itanium server) and access MP on the iLO using telnet (it’s on the local network so why bother about security?). Now I could boot from internal DVD and installation did start and finish. The only thing yet to do is to install the licenses and do the TCPIP configuration (and give the iLO its own. fixed address (and name)). BTW: The first Itanium is now named Iris.

No news on the PHP front
There are a few things to consider.
First, in the WASD global configuration I have a line:



causing PHPWASD to run whenever there is an extension .PHP found. I’m pretty sure it will run the executable the logical PHPWASD refers to, because otherwise there would have a version conflict with PHPSHR.EXE: Each version I have on the system resides in its own directory, referred to by logical PHP_ROOT:. This is the item that is used when I run PHP_INFO.PHP, there is no other reference elsewhere to this script; And it shows all the correct data – with the correct version at that time.

However, in the mapping, the blogs have their own reference:

redirect /sysblog /sysblog/index.php
map /sysblog**/ /sysblog*/index.php
exec+ /sysblog/**.php* (phpwasd:)/sysblog/*.php* ods=5
pass /sysblog/000000/* /sysblog/* ods=5 search=none dir=noaccess
pass /sysblog/* /sysblog/* ods=5 search=none dir=noaccess

which runs PHPWASD (the logical – explicitly via the logical) by it’s own rule.
Now what happens if BOTH start running? It might mean that the one that I expect to run (the one in the mapping) will run into an I/o error, or it might not be able to access a sourcefile; or it may finbd it’s access to the database is blocked, causing a timeout in database access (as is shown in the PUP error log file).

Another possibility that has crossed my mind: In the past I noted that PHP 5.3 and up will run a larger number of sub-processes. It might be that I have run out of process slots, or that the parsing, translating and execution of PHP code takes a far larger amount of system resources, causing the script not finishing in time (that is noted too, so I doubled the maximum execution time), but it might be the time to finish database transactions may have to be increased too. Another (and perhaps, better) solution is to increase the working set of the PHPWASD: processes: It hasn’t been changed since I started running PHP on a 256Mb system….Now I’ve seen that the peak working set can be increased – given the number of pagefaults…

So these are paths to consider. I didn’t get an answer of Mark Berryman yet.


Back to the beginning
Publishing a post, or updating one, proved to be impossible. Whatever done, publishing it would end in an error:

Status: 502
Script-Control: X-error-text="Cannot access script, i/o error.."
Script-Control: X-error-module="PHPWASD"
Script-Control: X-error-line=1337

and afterwards, there is part of the request submitted – including the text I added:

In PHP_errors since last night, theer is just one message, every 3 minutes or so:

PHP Fatal error: Maximum execution time of 60 seconds exceeded in Unknown on line 0

so I decided to revert this update until the system is more stable…


Still issues with 5.4
For some reason access to any blog fails due to an error signalled by the PHP engine: failure to access a script: IO error. But it doesn’t tell which one, and it’s not signalled in the error log file. If one blog fails, all will – until the cache is flushed and all PHP-connections are aborted.
This not just happens with this blog but with Travels as well, and with my friend’s site. Got inn trouble there to start with, I installed a plugin for agenda (linked to Google agenda) and when setting it up, trouble seems to happen. One thing however was found after properly assigning Tracks: had it defined to the wrong directory (but all seemed to be there): that one failed to finish database access within the time set in PHP.ini (30 seconds); This has now been extended to one minute.
But even adding this simple post made the server freeze. – I couldn’t publish it, and when returning at some point, I lost connection to some scripts that take care of the look-and-feel of the dashboard. It seems to happen after the content has been saved as draft automatically….

So I disabled 5.4 and started 5.3; See if that helps (it is the minimum I need for the agenda software). But the problem exists here as well. However, it will get back to activity – after some time (perhaps it’s just the save that takes too much time?)


Update succeeded
I renamed the directory holding the ‘bad’ WP version, and renamed the directory holding the correct version to the proper name, so all I needed to do next was tell WASD to restart.
Next, I set the PHP version to 5.4

That’s what you’re looking at now.

I have version 5.5 and 5.6 also on the system but I’m not sure the startup procedures have been updated to my setup. So that needs to be checked first; if all is well, I nay update PHP even further.


More on PHP 5.3 and up: Continued
Discussed the matter on the WASD-INFO list – and agreed it is a local issue: Mark Daniel has checked the installation of WordPress on his systems and he found no extra bytes. The only thing that may have caused the problem is unzip. The executable on Diana is quite old, and I found the latest (6.0) on info-zip.com. Downloaded it, built it on VMS and used it to install a separate version of WordPress. There are no extra bytes (good), all directories are lowercase now, files look good – but still, multiple dots in the filenames still occur, so the wp2vms procedure is still needed (ran it anyway to find out). For that, I set up a logical, and next, defined SYSBLOG to use it.
Well, this post has been added using this version!
It means I have to do some extra work, so all blogs run this version. After that, higher versions of PHP will probably work now.


More on PHP 5.3 and beyond
I remembered I defined PHP_ERROR.LOG in PHP.ini, and took a look into that file. There I found what I ran into some time ago:

[31-May-2015 12:13:48 UTC] PHP Parse error: syntax error, unexpected end of file in /sysblog/000000/wp-includes/post-template.php on line 734

This was because the file (in fact, many files) missed the PHP end tag “?>”. I recall I contacted Mark Berryman on this but it never came to an conclusion.
With 5.4, the problem is a bit different:

[19-Feb-2017 19:53:09 UTC] PHP Parse error: syntax error, unexpected '' (T_ENCAPSED_AND_WHITESPACE) in /sysblog/000000/wp-load.php on line 94

So I looked into this file; The weird thing is that in the editor, the file is only 93 lines long, ending in
        wp_die( $die, __( 'WordPress › Error' ) );
[End of file]
 Buffer: WP-LOAD.PHP                                                                                                  | Write | Insert | Forward
Command: line 94
You are already at the bottom of the buffer.

and the result is

Buffer has only 93 lines.  (Now going to End of Buffer).

So, there is no line 94????

Dumped the file – and behold: after the last LF, there is another character:

Dump of file WP472:[000000]wp-load.php;1 on 22-FEB-2017 21:25:30.44
File ID (14870,4,0) End of file block 7 / Allocated 8

Virtual block number 7 (00000007), 512 (0200) bytes

666E6F63 2D70773E 65646F63 3C270909 0A2C2920 222E656C 69662065 68742065 e the file." ),...'<code>wp-conf 000000
69642409 0A3B273E 702F3C27 202E2029 090A273E 65646F63 2F3C7068 702E6769 ig.ph</code>'..) . '</p>';..$di 000020
2227202E 20687461 7024202E 2027223D 66657268 20613C3E 703C2720 3D2E2065 e .= '<p><a href="' . $path . '" 000040
2E20273E 22656772 616C2D6E 6F747475 62206E6F 74747562 223D7373 616C6320 class="button button-large">' . 000060
6C694620 6E6F6974 61727567 69666E6F 43206120 65746165 72432220 285F5F20 __( "Create a Configuration Fil 000080
5F202C65 69642420 28656964 5F707709 0A0A3B27 3E612F3C 27202E20 29202265 e" ) . '</a>';...wp_die( $die, _ 0000A0
20292027 726F7272 45203B6F 75716173 72262073 73657250 64726F57 2720285F _( 'WordPress › Error' ) 0000C0
00000000 00000000 00000000 00000000 00000000 00000000 0000270A 7D0A3B29 );.}.'.......................... 0000E0
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 000100
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 000120
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 000140
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 000160
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 000180
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 0001A0
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 0001C0
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................................ 0001E0

Removed that byte – and that solved this problem, for this file.
There were numerous other ones that need a similar edit, because each of these files appear to be one byte too long.
Looked into the directory listing of the file, before edit:

$ dir/full wp472:[000000]wp-load.php;1

Directory WP472:[000000]

wp-load.php;1                 File ID:  (14870,4,0)
Size:            7/8          Owner:    [SYSTEM]
Created:    25-OCT-2016 03:15:30.00
Revised:    25-OCT-2016 03:15:30.00 (0)

Accessed:    4-FEB-2017 21:35:34.00
Attributes: 25-OCT-2016 03:15:30.00
Modified:   25-OCT-2016 03:15:30.00
Linkcount:  1
File organization:  Sequential
Shelved state:      Online
Caching attribute:  Writethrough
File attributes:    Allocation: 8, Extend: 0, Global buffer count: 0, No version limit
Record format:      Stream_LF, maximum 0 bytes, longest 0 bytes
Record attributes:  Carriage return carriage control
RMS attributes:     None
Journaling enabled: None
File protection:    System:RWED, Owner:RWD, Group:R, World:R
Access Cntrl List:  None
Client attributes:  None

Total of 1 file, 7/8 blocks.

and after edit:
$ dir/full wp472:[000000]wp-load.php;2

Directory WP472:[000000]

wp-load.php;2                 File ID:  (16777,7,0)
Size:            7/8          Owner:    [SYSTEM]
Created:    22-FEB-2017 16:05:59.27
Revised:    22-FEB-2017 16:05:59.30 (1)


Attributes: 22-FEB-2017 16:05:59.30
Modified:   22-FEB-2017 16:05:59.27
Linkcount:  1
File organization:  Sequential
Shelved state:      Online
Caching attribute:  Writethrough
File attributes:    Allocation: 8, Extend: 0, Global buffer count: 0, No version limit
Record format:      Stream_LF, maximum 0 bytes, longest 
Record attributes:  Carriage return carriage control
RMS attributes:     None
Journaling enabled: None
File protection:    System:RWED, Owner:RWD, Group:R, World:R
Access Cntrl List:  None
Client attributes:  None

Total of 1 file, 7/8 blocks.

So edit adds the size…There is more to check…

As stated, quite a lot of files need to be edited before the blog shows in PHP 5.4, but eventually is succeeds. Admin works as well but the page doesn’t show right – there may be things missing (not executed directly but referenced and linked so if that fails, there is no error.
It seems that all files are one byte longer than is actually the case. Not sure yet where it comes from, The fun part (luckily) is that 5.2 is fine, even with the edited files. But PHP 5.3 and later consider the file one byte longer. Now it.s a matter to find out what causes this extra byte: is it Unzip.exe, or is it added when the kit is created?

Anyway, if this is the case with all files (it looks as it is) it might be that a procedure to remove the last byte could do the trick.


PHP upgrade – blogs won’t run
I use Mark Berrymans’ PHP-ports to run the blogs, currently version 5.2-13, bot there is a need to upgrade to a newer version; I have them on the system (5.3-31, 5.4 and 5.6) so I changed environments – easy: run a script twice: Once to disable the current version and once to enable the one I want. This sets PHP_ROOT to the right location, and PHPWASD – the image that actually executes the PHP code – specific to the version for that particular PHP version (there will be an entry shortly showing how I did this).
All seems Ok, but the blogs fail: PHPWASD: returns status 500 (internal server error) without any other explanation, even after restarting the server. It doesn’t matter what version is activated, all but 5.2-13 works. The WATCH output clearly shows that the right version of PHPWASD: is started, so the referencing does actually work – but the image seems to run into an error and display “internal; server error” – but not what caused it.
I asked the WASD-INFO list for help. It must be something within WordPress (which should run with these versions) so I may have to dig into there.
Weird: PHP_INFO does work flawlessly – and it shows the expected information.


Installation failure
First challenge is to get connection to the Itanium box: Modern PC’s have no serial connection anymore, and the USB-based one that I have, cannot be used because either the driver is no longer available, or it cannot handle serial connections (via RS232). My old PC however does have a serial connector, and I could get into the console, enabled the built-in VGA and keyboard (and mouse) interfaces. Then the issue is to find out how to start installing OpenVMS on the box; Put the DVD in the drive, and locate the correct function in the menu. But it required a restart to note the DVD was loaded; next step is to boot from internal DVD – and behold: it stats. But with a minute, loading stalled so no installation.
Tried it a few times but it kept failing. As it turned out, the DVD was scratched – or broken? – in parallel with the tracks: a sure way to disable reading of its contents….
At that time, it was too late to do anything more. Have to find another one….


Ready to rock
Got DVD’s with OpenVMS 8.4 and related layered products for IA64, and PAKs (licenses); know now how to gain access (plain old fashioned serial port access). Got IA64 software to run (WASD and related tools; PHP (7.0-12) and MariaDb 5.5 by the Mark’s).
Still missing (yet) are development tools like available on AXP (Compilers, DECSet, FMS…). But these can wait, for now.

Now find the time to get it all on the box…..

New management tool installed
Mark Daniel introduced a new management tool: Intruspect, that uses web sockets to keep a constant eye on intrusion records. Installed it – though there seem to be not that many on my system (except occasionally: FTP, mainly) -and added a link in the operator homepage.


Second IA64
Got the second Itanium yesterday. This machine misses to airflow-ducts. It that doesn’t disallow starting it up.After connecting a screen to the VGA outlet and a keyboard in the proper USP-port, I did, and spotted something unexpected: the screen stayed blank…
I contacted the seller this morning on the missing air ducts – he’ll send them ASAP, forgot to re-install them – and this behaviour, he told me the VGA port is very likely disabled, I could connect to the (serial) console port and get on from there: You could call it “The old-fashioned way” but it (usually) works. So that’s the next thing to do. I aslo asked what’s installed: nothing, there’s no OS on this system. So this will become a plain OpenVMS box, where the other could be a HP-VM box with OpenVMS as a guest system. Or I switch the disks, since 2 CPU’s and 24Gb memory 9and 450Gb disk space seems to be a more feasible system running multiple openVMS instances (clustered?) as guest systems).
Anyway, I need to consider a re-organization of the floor space (including a (yet to obtain) 19″ rack), power grid and network. Well, that’s for a later date.