30-jun-2010

PhpMyAdmin
I downloaded the latest version (3.3.4) and installed it on Daphne, to test it with the new PHP installation.
That, by itself, was a challenge.
First, I tried the .ZIP file. but no: There are issues with files with multiple dots – and directory-names with dots in them. Unzip – as far as I knew – translated all but the last dots into underscores – and that’s not what I want. So I got the .tar.gz file – and had to get gzip and vmstar, and build them. For VMSTar, it meant re-compilation as well, since required objectfiles were missing. So C had to be installed – and the license loaded. But even that wasn’t sufficient, I also needed MMS to be installed, for a proper build….
Finally, I got both and could now work on the compressed tarball. decormpressing worked fne, but for some reason, VMSTAR choked on a CRC error in a directory and stopped.
Exit .tar.gz.
Got myself the latest version of UNZIP, hoping it would get over the problems with it’s predecessor, But it simply down’t work: not only were multiple dots – again – translated into undersores, the files were always stored in upercase – even when the “-LL” option was specified. Even the -a option doesn’t work…
Set proces-environment into extended parse-style – that might have been the problem, but not even that did work.
Exit UNZIP60, and back to the old one. Which now, all of a sudden did actually work: I got a directory name full of dots where expected, and files stored in their original (lowercase) names.

so fa, so good.
Next, add the location and handling in the mapping-file, using the PHP-INFO one as a starting point.
That didn’t wo the trick, and it required quite some fiddling with config itens and logicals to get at least some result (here, WASD’s real-time logging facilities are proiceless!): Defined “DBA” to be the right location, and use it in the configuration:

set /dba/**.php* script=query=relaxed
set /dba/**.php script=query=relaxed ods=5
exec /dba/**.php ($cgi-bin:[000000]phpwasd.exe)/dba/* script=query=relaxed
pass /dba/* /dba/*

or use the plain definotion instead of the logical:

exec /dba/**.php ($cgi-bin:[000000]phpwasd.exe)/dka0/web/dba/* script=query=relaxed
pass /dba/* /dka0/web/dba/*

But the scripts ends within index.php, where files need to be located:

PHP Warning: require_once(./libraries/common.inc.php) [function.require-once]: failed to open stream: no such file or directory in /dka0/web/dba/DKA0:[web.dba]index.php on line 35

Pasrse-style (should be EXTENDED since it’s an ODS-5 disk) and default directory (should be DKA0:[WEB.DBA]) are correct accoring the WASD WATCH output:

|08:13:20.12 DCL 4856 0001 DCL WRITE SYS$COMMAND 26|SET PROCESS/PARSE=EXTENDED
|08:13:20.12 DCL 4856 0001 DCL WRITE SYS$COMMAND 51|IF F$TRNLNM("HTTPD$LOGIN").NES."" THEN @HTTPD$LOGIN
|08:13:20.12 DCL 4856 0001 DCL WRITE SYS$COMMAND 49|IF F$TRNLNM("WASD_LOGIN").NES."" THEN @WASD_LOGIN
|08:13:20.12 DCL 4856 0001 DCL WRITE SYS$COMMAND 26|SET DEFAULT DKA0:[web.dba]
|08:13:20.12 DCL 4856 0001 DCL WRITE SYS$COMMAND 31|RUN cgi-bin:[000000]phpwasd.exe
|08:13:20.12 DCL 4856 0001 DCL WRITE SYS$COMMAND 9|STOP/ID=0
|08:13:20.12 DCL 4842 0001 DCL WRITE SYS$COMMAND EOF|

so now I’m stuck – there might be something within PHP? Because the same applies when the same file is run using PHP.

A second ‘flaw’ I found: running PHPWASD.EXE sometimes failes for uncertain reasons.
the setting for PHP_INFO specifies “@cgi-bin:phpwasd.exe” in the EXEC statement, and it always works. With PHPMyADMIN, however, it _may_ work (I do have a logfile that shows just that) but for some reason, it may result in a load of warnings:

%DCL-W-IVVERB, unrecognized command verb - check validity and spelling

as if the executable is interpreted as a commandprocedure – consistent with the “@” character. Removing it, or replacing it by “$” causes the same error as before. The main configurations states “$” for an executable, so my guess is that that’s actually right (PHP_INFO works with “$”, I’ve checked that.
So these quetsions are moved to the WASD mailing list – see what comes out of this.

WordPress
Again, I obtained the lastest version (3.0), immediately after I downloaded PHPMyAdmin. First the .tar.gz version because of the (expeted) problems with UNZIP. But knowing the problems I had with installing PHPMYADMIN, I used the ZIP version – and it installed nicely.
Using the same construct as for PHPMYADMIN, and adapting protection of all files, this turned out to be far easier. However, it relies on the MySQL extension, which I didn’t enable (since I expected MySQLi to be more feasable). So I enabled it in PHP.INI, but found out I had to rerun PHP_STARTUP to get it available. After that, I got thhe message I lacked a config file. Duh – I didn’t do anything here! So I created one, referring to Diana for a database. But connection failed – I needed to create one first. Now, index.php redirects to installation.php – and there it all ends – no warning, just an empty page. This rings a bell: there seems to be a redirectrion and this may not be handled by WASD.
Even using the configuration as on Diana, it doens’t do anything.

Another way to get around it is to install MySQL and use a local database. That might be the next thing to do.

09-Sep-2009

More on PHP
More testing done tonight.
The “zend mm heap corruption” issue has been solved, more or less. Mark notified to define a logical (/SYSTEM since it is to be used by every PHP process) to bypass the Zend memory manager: Set it to “0” and the problem would be solved. It was – but another appeared: it looks it slows the system down – which makes sense if I have read the doc well: zend allocates one chunk of memory, and keeps its own administration (and fails sometimes, hence the error) and with that bypassed, each allocation means another call to the OS to get a few bytes. Far less efficient, thouh it shouldn’t matter that much…
WordPress was the first to be tried. Normal access is no problem, as it has always been. The admin pages now come up nicely, most activities can indeed be done – except for uploading a file. I checked the protections of the upload directories – upload should create a new directory and put the files on that, so the processes require RWE acces to the main directory (wp-content.upload] ) and all directories below. But a new directroy [2009] is not created, despite the protetection or W:REW on [wp-content]uploads.dir… Not even a message – expect when the file is not that big: I got “Error writing to disk” when I tried to upload a 40K image – but a 400K image will silently be discarded.
PHPMyAdmin was even more frustrating.
The login pages may appear with, or without CSS applied. But at least, login is possible. But than things go wrong

  • The database selection pane appears, and is overwritten by the login page, with, or without CSS applied
  • The login page re-appears, with, or without CSS applied
  • The main page appears, without database selection page, with, or without CSS applied
  • The database selection panel appears, including the main panel, with, or without CSS applied

  • and it all takes A LOT of time…
    Observing the system, it seems I got 4 instances of PHPWASD running, and all working on PHPMyAdmin (since that was the only application I was working on). That also happened with WordPress, but at least, that didn’t get messed up.
    What’s more: it has worked before; I created the WP263 database with it, but today, I could’t get at a point that the 284 database was created. I tried whenever the main page appeared, but without notice, the login screen reappeared after some time – and the new database was not created…..
    WATCH didn’t show something weird – it all looked fine. But I’ll have to scrutenize the output to really understand the process.
    Perhaps the latest release of PHP solves the issues – but the nasty thing is: it has worked before.
    VERY frustrating.
    Blog security
    I have disabled new login on the blogs and removed the users I I don’t know – mainly on the Trips, Tracks and Travels blog; for this one, I left all users in place – I know them (at least, most of them), but new users cannot be created.
    I doublechecked protection of the directories to be READONLY – and they are.
    It is intended to make abuse a little harder.
    I cannot upgrade to a higher version until my problems with WP 2.8.x are solved: There is a redirection by the PHP code that causes a loop, which is signalled by Firefox (IE8 runs into a timeout). That’s why the BC2007b log is disabled, I used that for testing. I’ll look into 2.8.4 to see if the problem persists – but my feeling is it will still be there and so I won’t be able to upgrade. I’m not the only one experiencing these problems, but none of the solutions on the WP forum has helped me.