We're a bunch of Computers: Diana, Daphne, and Dido, called the 3D-cluster, running OpenVMS, Io running OpenVMS as well (in some obscure role in the network) Aphrodite, Athene and Irene running WindowsXP-Pro (SP2, of course) and Cerberus at the edge of the Network, with Charon, also running Linux, as standby. SYSMGR takes care of us.

Sunday, November 12


using Wordpress - on Diana, of course. It was very easy (like I thought) to enable multiple blogs on that machine without having to copy everything. Just using a search list as a root directory and copying and adjusting the configuration file did the trick. Of course, after adding the new root to the server configuration (since it has it's own logical root), but that would be needed anyway. Theer might still be some issues but the main fact is: it works great. I have requested to incorporate the required changes in the main code stream - we'll see.
The new address is (don't forget the last "/" otherwise it wont work yet - one of those little annoyances...)
is required to be set up to get the Blogger content (this blog, that is), but HP's PHP-engine that is used for WASD to be able to handle PHJPO code, does not include it - and the cURL site claims it ought to be built-in since 4.0, and since HP's PHP engine is based on 4.1, so you would expect it to be included. Alas, is isnt. But I could download 7.15-2 for VMS and installed it, but without rebuilding the whole PHP stuff, it's not possible. And rebuilding PHPSHR from scratch, without the required logicals or even MMS files? I don't want to get onto that!.
Having that, I could give it a try to get the data and I did. However, it's quite a lot of work to get it all into the new blog...

Friday, November 10


Update of Wordpress
to 2.0.5 after craeting a backup (see yesterday's issue). Deleting all files unless otherwise stated is a bit srastic, so I renamed the directory, created a new one and filled it up with all the "old" files. I downloaded the new zip file (the tar.gz file cannot be expanded on VMS since gunzip doesn't recognize it as a gzip file...) and unzipped it, fired the upgrade script and that was just it.
At least, it looked like that but it wasn't: publishing a new post seemed not to return - it simply failed. The page however was published so it was just the return to the edit pages that failed.
So I still had to do what was in the guide.
After that, It's all Ok!
is to create several blogs. It must be possible since the database contains a "BlogId", by which I presume different blogs carry different ID's and so there can be multiple blogs on the same code. Following the good practice to have each on them on a (concealed) device by itself, that logical could be a search list: first the blog root, and second the general code. Blog-specific code can than be kept on the blog directory itself.
Oh, the wonders of VMS!!!!

Thursday, November 9


Wordpress works!

One problem I could solve myself - which gave the admin page the proper look. The other one required some assistnace but I was on the right track.
Anyway, it's just 4 lines:
redirect /wordpress/ /wordpress/index.php?
redirect /wordpress/**/ /wordpress/*/index.php?
exec /wordpress/**.php (cgi_exe:phpwasd.exe)/wordpress/*.php ods=5 script=syntax=unix script=query=none map=once
pass /wordpress/* /wordpress/* ods=5 search=none
and now Wordpress is up and running.
Not for the real stuff yest, it will require some extra work and investigation, to be sure the product is up to the standards.

still one thing more to cover, but I think this is merely a PHP problem.
Craeting backups requires write access to two directores because some data is written there (the backup itself and some metadata). That's not really a problem, were it not that PHP will just look to the UIC-based protection, and ignore ACL's.
Workaround: use PHPMYADMIN (running as well) or mysqladmin.

Someone requested assistance on problems with the OSU webserver and my suspicion is that this is caused by intrusoin detection. To help him, I created a small procedure to scan the accounting files for people using bad passwords quite often and I found some attempts on Diana abusing the FTP account (port 21) since 01-Jan-2005: twice assuming Diana is a Windowes machine (who else would try to overflow the server with FTP logins as "Administrator" several times a second - for over an hour!. And one trying to attempt to login as 'root'.
All failed, of course.
But now I now scan accounting on a daily basis - nothing found anymore.

Wednesday, October 25


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. 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 must be run after WASD has been started.
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 - 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 gives a "page not found" error. So still room for investigation: it misses "index.php", it should read: "". 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.

Tuesday, October 24


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.
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.

Sunday, October 22


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!!

Tuesday, October 17


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.
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.

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")
post_status != "attachment"
DUH! if post_status equals "publish", it won't equal "attachement"...