25-Oct-2006

Remaining work
was to define PHP logicals that were still missing, therefore the PHP stuff didn't work. Why it wasn't there, I don't know. PHP_Startup.com is contained in the startup sequence, but there might have been an issue with logicals required - if for instance HT_ROOT needs te be defined before, that might be an issue, in that case PHP_Ssetup.com must be run after WASD has been started.
Wordpress
works - that is: after CLASSES.PHP had been changed I got rid of the error messages and the test message does show up (This was found before and I did signal this to www.issinoho.com:8080/phpbb2 - but that site seems to be gone. It _should_ be included in the main stream, I'll add that). The form (I used another theme) is still not fully what I expected but that may be a matter of protection of image files.
Downloaded a number of themes to try, and possibly use, but these weren't copied to Diana yet.
But some things don't work as planned, some links cannot be handled: Linking into comments refers to http://homedesk.grootersnet.nl/wordpress/?p=1#comments) gives a "page not found" error. So still room for investigation: it misses "index.php", it should read: "http://homedesk.grootersnet.nl/wordpress/index.php?p=1#comments". Leaving a comment doesn't work either - and returns to the same error since the URL inside the page is still missning "index.php"
Perhaps a rewrite-rule in WASD-config (wordpress.conf) would do.

23-Oct-2006

Web trouble
This morning, WASD returns:
ERROR 500 - The server has encountered an unexpected condition.
after having accepted login-credentials. That is: the login window comes up in the browser, data is entered and then this page shows up....
Yesterday, all was correct, as I could access the webs using Iona.
Update
Found the cause: the disk containing the webs was " offline" - got a lot of errors, was lost by the system, regained and went into mount verification, which timed out so the disk was gone from a system point of view, around 16:30 yesterday. It was impossible to login, something I found out this morning as well... It turned out that both the HSZ50 as Diana needed to be rebooted to get things back to normal.
After the system had come up and running again, no more errors occured - therefore I suspected the controller to have missed a bit or two (or more), or the disk hardware itself failed for some reason. Anyway, I took the chance to make an image backup of the disk, perhaps I should shadow them all.

22-Oct-2006

IONA
is another branch on the tree. Actually, it's a second incarnation of Athena, running the OpenSUSE distribution of Linux, including the latest OpenOffice suite, and some other applications (no MySQL yet - will need to set that up), to be examined as a replacement for the Windows-based frontend. However, there are reasons to keep Windows up and running on at least one machine since the Linux stuff cannot handle some formats properly.
Getting the distribution from the Internet was troublesome, but once started an FTP session from Diana (in batch) each 3.9 Gb distributions (i386 and x86-64) were downloaded in about 5 hours each. Burned them onto DVD on Aphrodite since Diana hasn't been updated to 8.3 yet.
Installation went flawlessly - but too an hour or so to complete, After that, I had some trouble connecting to the network - DHCP didn't work properly for some setting wasn't right (use DHCP "On Startup", where "On Connection" was a better solution - or was it just the other way around?) but once that was settled, it can be used - though some packages are not yet installed and it will be asked if needed. Keep the DVD at hand!!

17-Oct-2006

No E107...
because there really is something wrong in there. So that's be abandoned for the moment. Mark says I ran into one of the issues with PHP, hopefully someone at HP will pick it up.
Wordpress
however did install, but creating the database was another issue. The ones that were created before didn't work with this newer version, so I deleted them and created a new one. That is: creating a wp-config.php fila failes since the root directory seems unwriteble - but it is set to W:RWE, so HTTP$NOBODY would be able to write. No way....So I created the file manually according the manuals and created the database.
With some trouble, it does work - sort of. I got a number of messages that headers could not be resent and all of a sudden these were gone. Login did succeed - and one of the previous problems is gone: I can now see (and select) other themes, but running the admin script is still a bit of a wonder - it should run wp-admin/index.php ut it does not. Might be a default in WASD to be set.
Not 100% yet: There is some problem with a value in a select statement:

[Unknown column 'publish' in 'where clause']SELECT DISTINCT * FROM wp_posts WHERE 1=1 AND post_date_gmt <= '2006-10-17 18:35:59' AND (post_status = "publish") AND post_status != "attachment" GROUP BY wp_posts.ID ORDER BY post_date DESC LIMIT 0, 10
and the admin site has no theme loaded.

Well, something still needs to be examined.

Update
Found the cause: post_status is defined as
enum('publish', 'draft', 'private', 'static', 'object', 'attachment')
and that seems to be the trouble. Taking out the references to post_status and MySQL returns the data. Pass that to Jean-Francois Pieronne (who ported MySQL to VMS).

Anyway, it's a bit weird in the SQL statement to specify both:
(post_status = "publish")
and
post_status != "attachment"
DUH! if post_status equals "publish", it won't equal "attachement"...

06-Oct-2006

MySQL web-based admin works
When starting Homedesk from another machine I used before to access the PHPMYADMIN entry on Homedesk - the company's laptop - it directly went into is and so I re-discovered what was to be changed: Use collating sequence utf8-general-ci in stead of the (unknown) utf8-universal-ci. Now I can access the MySQL database again.
but E107 won't...
In the SWS erea I had installed E107 - a PHP/MYSQL based content management system. It did work there - somewhat, because some issues didn't due to non-VMS code (it won't recognize a file being a directory). But under WASDPHP, it crashes this image.

WATCH output doesn't say much, just something seen on screen:
SECURITY_STATUS=NONE
20:12:11.27 CGI 1968 0001 CGI NOT a strict CGI response!
20:12:11.27 ERROR 0421 **** NOTICED CGI:1969, not a strict CGI response
20:12:11.28 ERROR 1055 0001 RESPONSE DCL:4457 (basic-only) 502(502)
"Script did not provide an acceptable response."
20:12:11.29 REQUEST 0767 0001 REQUEST STATUS 502 rx:329 tx:882 bytes 2.575086 seconds
but having WASDPHP log what's passing, it shows an ACCVIO!
005620:16:41.92EXECUTE
%SYSTEM-F-ACCVIO, access violation, reason mask=00,
virtual address=0000000000000001,
PC=FFFFFFFF80A70960, PS=0000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
DECC$SHR_EV56 0 0000000000000960 FFFFFFFF80A70960
DECC$SHR_EV56 0 0000000000139BBC FFFFFFFF80BA9BBC
PHPSHR 0 0000000000174774 00000000001C6774
PHPSHR 0 00000000001839C4 00000000001D59C4
PHPSHR 0 00000000001840E8 00000000001D60E8
PHPSHR 0 0000000000185E2C 00000000001D7E2C
PHPSHR 0 0000000000187C24 00000000001D9C24
PHPSHR 0 0000000000187C24 00000000001D9C24
PHPSHR 0 0000000000187C24 00000000001D9C24
PHPSHR 0 0000000000189DBC 00000000001DBDBC
PHPSHR 0 0000000000174BB8 00000000001C6BB8
PHPSHR 0 0000000000142D54 0000000000194D54
PHPWASD PHPWASD ProcessRequest 43141 0000000000001C1C 0000000000031C1C
PHPWASD PHPWASD main 42760 00000000000005A8 00000000000305A8
PHPWASD PHPWASD __main 0 000000000000006C 000000000003006C
0 FFFFFFFF80329F94 FFFFFFFF80329F94
005720:16:42.49WRITE FLUSH

These locations are bogus - make no sense at all looking at the PHPWASSD.C code. So I rebuild the image from scratch, with /LIS on compilation and /MAP/FULL on link, and installed that version. It didn't solve the crash but gave a more consistent location of the crash:

PHPWASD PHPWASD ProcessRequest 43255 000000000000196C 000000000003196C
PHPWASD PHPWASD main 42874 00000000000005DC 00000000000305DC
PHPWASD PHPWASD __main 42799 000000000000009C 000000000003009C

and that is indeed found in the code - and looks like a more appropiate location:


1 43248 else 2 43249 {
2 43250 /* restore the *real* translated path (see above) */
2 43251 SG(request_info).path_translated = CgiVar("PATH_TRANSLATE....
2 43252
2 43253 if (WatchEnabled) WatchThis ("EXECUTE");
2 43254
2 43255 php_execute_script (&ZendFileHandle CLS_CC ELS_CC PLS_CC);
1 43256 }
1 43257
1 43258 if (WatchEnabled) WatchThis ("SHUTDOWN");
1 43259
1 43260 php_request_shutdown (NULL);


"EXECUTE" and "SHUTDOWN" are both shown around the ACC vio, so it must be somewhere in teh PHP_EXECUTE_SCRIPT call where is a problem. This routine is defined in HP's PHP-port...
I have issued an entry on HP's OpenVMS ITRC after having sent a message to the WASD mailing lits - but I found it never got there (so redone it)


More OpenVMS blogs!

Another Blog
Found another VMS blog: Dr. OpenVMS at http://dropenvms.blogspot.com - said to more technical.

There should be more!

04-Oct-2006

More PHP - and MySQL
Re-enabled PHPMYADMIN (which is, of course, behind a resticted web) but had some trouble in starting it up: Using WATCH it showed I might have to define ALL paths used - and forget about non-PHP stuff. Hard to believe! But with hints by Mark "WASD" Daniel I got it up and running.
Next, to access the MySQL database, I had to re-enable the MYSQL 4.0 madule I built before (since the HP-delevered one is built against MYSQL3). That failed as before, complaining it wasn't a PHP library, by chance - and I know it is since on SWS this worked. Digging through history (in here and elsewhere) found I had to define a few logicals to get it up and running.
Ok, so far so good - updated the startup procedure for that - and got the very same problem logging in:
#1273 - Unknown collation: 'utf8_unicode_ci'
How did I get passed that..... I know I have to change that in the URL, but to what? I forgot!

2-Oct-2006

PHP under WASD
I just installed PHP under the new webserver - using SWS's PHP engine. Just follow the description, nothing fancy up to now, and it all looks good for the moment.
Had the very same trouble in getting the MySQL 4 extension up and running but looking to the original remarks on Jean-Francois Pieronne's website, it tuned out that

$ DEFINE/SYS/EXEC /NOLOG LIBZ_SHR32 sys$library:libzshr32-1_2_3_ev56.exe
$ DEFINE/SYS/EXEC /NOLOG LIBSSL sys$library:OPENSSL098A_LIBSSL_SHR32.exe
$ DEFINE/SYS/EXEC /NOLOG LIBCRYPTO sys$library:OPENSSL098A_LIBCRYPTO_SHR32.EXE

will just do the trick. Now look for an RdB module (It is there, I know, but now looking for it)

For the rest
It's more trouble keeping the PC's up to date than anything else (mine, and others). The VMS boxes just run without any problem.
No real security issues. I have re-enabled the stricter rules on the mailserver and that blocks quite a lot of traffic. Bad , and some good. Oh well....


I have VMS 8.3 at hand - as a zip file. Still to create a disk to isntall it!