05-Jun-2015

Latest news on PHP
Got two messages from Mark:
1. PHPWASD.EXE in the kit is no good.
2. He reviewed all kits and rebuilt them when needed – there should be no more mismatches any more.
To be tested tonight, or during the weekend.

Evening update
I downloaded the updated kit from Mark’s site and installed it. First, it didn’t work since PHPWASD: couldn’t access PHPSHR, and later, it seemed that the MySQL extension was missing. The reason was just a matter of file protections’, I had to change the n all, and edit php.ini to enable the extensions (PHP_MysQL.EXE in particular -PHP_MySQLI.EXE alone wasn’t enough for this version of WordPress) but now it works, though it looks to be a bit slower. However, I should NOW be able to update to WP 4.2.2. Fingers crossed 🙂
Evening update 2
Updating WP means: revert to default theme and disable plugins – after creating a backup (so if it fails, it’s easy to revert to the stae before the update)/ No it should be a matter of changing the logical (the second location should be where the new version of WordPress is stored, in my case WP42:), than restart the webserver (to remove any running PHPWASD images), and start the blog. It does start with the mentioning that WP version has been changed and that the database needs an update, It starts – and stops without a notice, somewhere in step one of the process.
So I had to revert to the state prior to the update, by simply restoring the database, change the logical back to the original version and restart WASD.
Now it’s a matter of finding out what is going on….
It may be related to the resource limits in PHP.INI:

;;;;;;;;;;;;;;;;;;;
; Resource Limits ;
;;;;;;;;;;;;;;;;;;;

max_execution_time = 30 ; Maximum execution time of each script, in seconds
max_input_time = 60 ; Maximum amount of time each script may spend parsing request data
;max_input_nesting_level = 64 ; Maximum input variable nesting level
memory_limit = 128M ; Maximum amount of memory a script may consume (128MB)

that may be too low, keeping in mind that this system is limited in resources…

Maintenance
It has been a few days ago that the maintenance jib has run. No surprises:
PMAS statistics for May
Total messages    :   1026 = 100.0 o/o
DNS Blacklisted   :      0 =    .0 o/o (Files:  0)
Relay attempts    :     88 =   8.5 o/o (Files: 31)
Accepted by PMAS  :    938 =  91.4 o/o (Files: 31)
  Handled by explicit rule
         Rejected :    387 =  41.2 o/o (processed),  37.7 o/o (all)
         Accepted :    197 =  21.0 o/o (processed),  19.2 o/o (all)
  Handled by content
        Discarded :    152 =  16.2 o/o (processed),  14.8 o/o (all)
     Quarantained :    185 =  19.7 o/o (processed),  18.0 o/o (all)
        Delivered :     17 =   1.8 o/o (processed),   1.6 o/o (all)

The number of relay attempts has been minimal this month: No file exceeded 10 blocks; there have been some, of course, but only three files were large enough (over 2K in size) to be examined: mail was sent from addresses 173.254.223.72 , |185.60.229.89 and 5.79.68.231; faked senders, no doubt, since From: was either empty, a (non-existing) user from grootersnet.nl (and I do know my users, and my address :)) of admin from a site that is not related to the address it is sent from.

04-Jun-2015

More tests on PHP upgrade
I got a reminder of Mark Berryman, to re-download the kits and install them.
I started with PHP 5.2.13, the one I testes two and a half year ago or do and found in not working. I still had a PHPWASD executable of that one – separate – because it became clear that there was a problem with that file – or with PHPSHR.EXE.
But this one wasn’t working either, I got “Ident mismatch with shareable image” again, so the kit wasn’t right. I tried again with the separate image, which appeared tp be from a later date, but the same happened.. Analyzing the images, it became clear that these two images were the same. Also it was proven there indeed was a mismatch between the programs and the shareable image. So I signaled this to Mark.

31-May-2015

More on PHP and WordPress upgrades
After yesterday’s mistake, I had to revert the activity from PHP 5.4 back to 5.2 – it is just execution of a script, without a problem.
First thing today was re-trying the blog with PHP 5.4. Setting this is no problem, PHP_INFO.PHP works – but none of the blogs do because of deprecated and non-strict syntax – but these wouldn’t be the biggest problem since I must have got them yesterday as well. To get them out of the way anyway, I redirected this logging to a file, but that didn’t solve the problem: the last error typically is:
PHP Parse error: syntax error, unexpected end of file in /sysblog/000000/wp-includes/post-template.php on line 734
The code does indeed miss the training end-tag:
<?php
else :
echo "<ul class='post-revisions'>n";
echo $rows;
echo "";
endif;

[EndOfFile]

So no ?> tag on line 734 (on EndOfFile line) which is in fact simply completely valid.

Yesterday there wasn’t a problem with this, so why there is today?? This means I have to revert to 5.2….
(I now know why. I didn’t close down PHP sessions so the current version still was 5.2, but unseen)

Second, I wanted to create a new blog using WordPress 4.2.2. I updated the file containing the database credentials, started the blog which introduced the 5-minute install. No problem – except that is stalls on step 2, the page doesn’t show anything except for a white rectangle, there should be a first-level header but it seems the page isn’t complete. No error message, nothing.
So I dropped the database (the right one) and recreated it (it must exist) but now I cannot connect to the database – as shown in the WATCH output….
Even on 5.2, it is a problem. Not really strange if the mapping is false….Once that was settled, I can get it running on 5.2 to start with. But it seems it doesn’t use wp-config.php, so take a look there: matter of protection: Should be readable. Once that is settled for all files, installation fails on the glob function – which is missing in this PHP version – now I remember why I wanted this upgrade….
However, the database does exist and tables have been created; some have been filled as well.
But now this is settled, I could retry re-installing the 4.2 version using PHP 5.4. But that fails – again, where PHP_INFO just works.
Tried it with 5.3, but that fails as well, but for no apparent reason: just a 500-error….And 5.2.13 (re-installed) runs into
Ident mismatch…
So I seem to be stuck with this version.
I could however try upgrading the blogs to 4.2.2 directly: Change the logical to use WP42 in stead of WP265.
But no. I need to switch to all defaults before and I forgot. So returned to the previous setting – with a typo caused NoService to appear! Even after repair, where Trips, Tracks and Travels have no problem…..
(As it turned out – after having saved last entries using mySql and save them into a file and restoring yesterday’s backup – it was just the cache of InternetExlorer that caused the problems….)

Give it another try: Update requires all specifics switched off and running the update script as administrator. Before doing anything, I backup the database, then switched to WP4.2 and ran the update script.It showed that a database update was required as well, I started it but that one – as wll – stoped on a fatal error: the glob() function being undefined.
Duh.
This is still PHP 5.2.6….
Restored it all: WP version and database. Wait until I get WP up and running using PHP 5.4 (or higher: I have downloaded 5.5 as well but I think it will have the very same issues as 5.4).

Informed Mark Berryman, perhaps he has something to solve the problems….

30-May-2015

PHP Upgrade
Finally, I got some time to upgrade PHP and WordPress.
First things first: Do PHP first; I already tried 5.2.13 but ran into trouble with that. The next versions were 5.3 and 5.4, and I decided to go for 5.4. The procedure to establish this version needed a slight adaptation but once done, all logicals were set properly. But running a PHP-script by the browser always ended in an error: Ident mismatch with shareable image – being PHPWASDSHR, referring to PHPSHR.EXE. I contacted Mark Berryman, who suggested to download the kit again, install it and see if that worked.
It did.
PHP_INFO nicely showed the information, and even the SYSMGR blog was shown with no problem at all. So I could do some blogging – and there it showed there were still some issues with starting the page to add a new post (new-post.php) or, from another session, managing posts (edit.php), but on reload, it all seemed to work nicely – even without restarting the server. Since I planned to update WordPress as well, I didn’t bother too much.
Next step was the installation of WordPress 4.2.2; I use the zip-container since my version of VMStar extracts the files in all uppercase letters; both however won’t accept dots in a name, except as delimiter to filetype, and replaces them by underscores. Luckily, WordPress doesn’t use underscore in filenames, so it’s an easy step to change them back to dots, using a small script (I found the original after this!). Next step was creating a new blog, but for some reason, it stopped in step 2. So I decided to retry after cleaning up.
Here I made a mistake. I dropped the WordPress database -which contains all blogs….

The last thing I could do was restore it from last nights backup and continue working tomorrow…

DNS issues on Helena
Apart from this: the Windows 8.1 Pro workstation suddenly failed to access the VMS box (Diana) by name. This effected all protocols: POP, SMTP, HTTP, TELNET, SSH…. Ping on the name (requiring translations) didn’t work either. As it turned out: The machine considered itself member of domain grootersnet.local – I set that up in the zone-file of BIND on Diana but never implemented it; however, Helena found should be within this domain, probably because the .local extension seems to be some sort of default (I’ve seen it else where and I recall having similar issues in the past). Bow I removed it from the BIND.conf file on Diana, including the files that describe it, and restarted TCPIP$BIND. After that, translations went fine again.

19-Jan-2015

Still problems with PHP
There are still problems with PHP. Thought it looked as if it worked yesterday (and it did) the setup wasn’t completely right: I couldn’t start the php-command; as it turned out, PHP_ROOT wasn’t defined properly: referred to WASD_ROOT:[PHP.AXP.] with concealed attribute. I translated WASD_ROOT to the bone ($116dka100:[web.wasd.] and added the terminal attribute. Now the php command can be used, and when executing SYSBLOG:[000000]index.php, the pages shows. But running from the website fails. Be it because of ACCVIO, or PHPWASDSHR cannot be accesed – but the files exists and is accessible.