09-Apr-2014

Webserver updates
The WASD mailing list sent out a notice of a vulnerability of OpenSSL, nicknamed “heartbleed” and since this server is built using OpenSSL (be it the WADS version) it coul be effected as well. Mark Daniel has taken a look into his sources and plugged the hole – and the new kit has been made available, send out word and recommended a rebuild of WASD.
And since the latest version (10.3) was already planned, I did both in one go. So now the server runs WASD 10.3, linked with (WASD) OpenSSL 1.0.1G. In the process, I also updated the webmail program (now 1.7.0), and some other products are waiting. But Soymail returns an error:
Internal consistency failure ... language file. and WATCH doesn’t show anything weird..
It’s not something to be worried about too much. Just a nuisance.

11-Jul-2010

A bit more on WP
One more mapping line was required to have WP 3.0 working:
map /wp30/wp-admin/ /wp30/wp-admin/index.php
otherwise, the admin page didn’t show up properly.

The biggest problem is with the PHP-engines now. It seems that almost every request launches a new WASD process. These all require a lot of resources – mainly memory, the pagefault rate peaks over 20.000….

29-Jun-2010

WASD + PHP running
The problem mentioned a few days ago was caused by multiple causes – one of them being an error in building the MySQLi extension, Mark Berryman supplied a new kit, so I installed it.
But not before I cleaned everything: the WASD_ROOT:[src.PHP] directory – that would become PHP_ROOT if you used the PHP_STARTUP procedure of WASD (?) – now holds just what’s needed to build the PHP runtime engine. The whole PHP package is now installed under WASD_ROOT:[PHP.AXP] like Mark Berryman describes in his README document that comes with the kit – the main exe’s in [.BIN], the extensions in [.EXTENSIONS], and PHP.INI aside these directories.
Now the sequence of getting it up and running is important, and I found this works:

$ DEF/SYS/EXEC PHP_ROOT DKA0:[WASD_ROOT.PHP.AXP.] /TRANS=(C,T)
$ @WASD_ROOT:[STARTUP]STARTUP
$ @WASD_ROOT:[STARTUP]PHP_STARTUP

Important as well: all PHP files must be set to W:RE. the SECURE script does NOT include this path, so the whole PHP-tree must be set correctly by hand.

Don’t forget PHP.INI – like I did, because you still won’t see the enabled extensions – and PHP doesn’t issue a warning on this! After correcting the protection mask, it works fine.

The PHP excutable now works as expected as well:

$ php cgi_bin:php_info.php
<h1><center>Testing the PHPINFO () function</center></h1><br />
phpinfo()
PHP Version => 5.2.13
...

Before I forget: of course you must enable PHP in the configuration:
in HTTPD$CONFIG.CONF, add INDEX.PHP to the section [Welcome],
.PHP $CGI-BIN:[000000]PHPWASD.EXE to the section [DclScriptRunTime], and to the section named [AddType] you should add these lines:
.PHP text/plain PHP source
.PHTML text/plain PHP source
.PHPS text/plain PHP source

For mapping, I created a separate configation file (PHP.CONF) that contains the lines:
set /**.php* script=query=relaxed
set /**.php script=query=relaxed ods=5
exec /php-bin/* (@cgi-bin:[000000]phpwasd.exe)/cgi-bin/* script=query=relaxed

and included the file in the mapping file wasd_config_map.conf, just before the DECnet lines:
[includeFile] wasd_root:[local]php.conf

Next step is installing the latest versions of PHPMyAdmin en WordPress – using the database on Diana – just for setting up the new environments, the current mapping causes loops and now I can find out how the mapping should be to get it running properly…

27-Jun-2010

More on 8.4 + WASD 10 + PHP
I installed the latest version of WASD (10.1) and PHP (5.2.13, as supplied by Mark Berryman) but still it didn’t work – got the same errors as before. After some fiddling around with files (I should have read the README file first 🙂 ) the PHP_INFO script did finally produce output, but notr entirely as I expected: for instance, no additional modules are shown. But at least, the error is now gone.
Using PHP interactively however, does produce the well known error:

$ php CGI_BIN:PHP_INFO.PHP
PHP Warning: PHP Startup: Unable to load dynamic library '/php_root/extensions/php_mysqli.exe' - %LIB-E-ACTIMAGE, error activating image $1$DKA0:[SYS0.SYSCOMMON.][SYSLIB]SSL$LIBCRYPTO_SHR32.EXE
-SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image in Unknown on line 0

but continues – and lists all modules that I enabled…

Perhaps it’s just a mismatch in logical names when running interactively, and when by the server, and if so: what caused it?

Question put into the WASD mailing list.

14-Jun-2010

Testing the new environment
I took some time today to start setting up the new environment – but I ran into serious problems.
First, the ‘new’ machine failed to boot into SRM – hun on “f4” in the Power-On Self Test, but finally – after having removed keyboard and mouse, the system booted. I didn’t want to get to hang on IP-cluster traffic, so I booted conversational and set NISCS_USE_UDP to zero – the TCPIP database wan’t loaded but boot still hung on cluster formation. That meant I had to either disable clustering alltogether (always an option) of start the (emulated) second member. I choose for the latter – being the fastest action to perform.
Next, I started the WASD webserver – which I had built before, before the holiday 🙂 – and then did the PHP build, it took some searching but in the end, I got PHPWASD built and installed.
But testing was another story. To test it all, I would like to have PHP_INFO.PHP available – and that script – nor any other – is included in Mark Berryman’s kit. No problem, I copied the file from Diana and tried it again, using te recommended PHP.INI file.
But it fails: WASD complains it gets a non-complient CGI-header.
To find out what’s the problem, I started a WATCH session, and that showed me a severe issue; and with PHP alone in stead of PHPSHR, the same error showed up:

$ php :== $php_root:[bin]php
$ php cgi_bin:php_info.php
%DCL-W-ACTIMAGE, error activating image SSL$LIBCRYPTO_SHR32
-CLI-E-IMGNAME, image file $1$DKA0:[SYS0.SYSCOMMON.][SYSLIB]SSL$LIBCRYPTO_SHR32.EXE
-SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image
$

Asked around on the WASD mailing list and ITRC, it appeared that SSL1.4 – is NOT compatible with 1.3, and quite a lot of programs are effected. For most of them, HP has delivered patches, but for others, not yet. But Mark Berryman has updated his port of PHP and supplies objects and commandprocedures for local linkage; the same has been requested to HP.
In the mean time, Mark prepares 5.3, and when that becones available, I’ll give it a try.

Nevertheless – this means that when OpenVMS 8.4 is delivered with SSL 1.4, upgrade form 8.3 requires more than just that upgrade…