Posted on

03-Sep-2009

WordPress
Now I can access the database on Diana, next tests concern WordPress. To simplify matters (I didn;t want to mess up an environment that actually works) I made a backup of the basic WP environment on Diana that is used by all blogs, and restored it on the emulator; set the logicals similar to Diana, and copied the hidden configuration file as well. I changed that to access the database on Diana instead the one on localhost, and tried to fire things.
It failed.
Well, partly. It took some time but in the end I got the “NoService” page – from the publioc website. Some thought: it’s rather obvious. The database contains a self-reference, and that causes the problem. Since the basic environment can only be accessed using https: from the operator page, this reference has been changed to link to this site – over a secured socket. That one didn’t exist, hence I got the “NoService” page from Diana…

So i did have to create a database on the emulator. Well, PHPMyAdmin runs so that is easy. Once created, I ran WordPress install script. Got some errors: stack overflow appeared here as well, and a missing table (of course: the database is still very, very empty 🙂 . But finally, I got my password and could login into the new blog. First action once logged in, was changing the generated password for a new one that can be remembered. A first attempt failed because there is too little pagefile left. though I created a second one yesterday, that wasn’t installed yet….
Done so (and adapted SYSTARTUP_VMS.COM) and retried. Now I could get into the user-management page, inputted the new password and hit the Update button.
But that didn’t work, that is: WASD complains about a non-compliant response – also appearing on the console:


%%%%%%%%%%%  OPCOM   3-SEP-2009 22:33:18.68  %%%%%%%%%%%
Message from user H (0)                        Cur Top: TCPIP$NTP_1 (1)
Process HTTPd:82 reports28, not a strict CGI response
%HTTPD-W-NOTICED, CGI:1928, not a strict CGI responsewp-admin]profile.php) cgi_e
-HTTPD-I-SCRIPT, /wp263/wp-admin/profile.php (wp263:[wp-admin]profile.php) cgi_e
xe:phpwasd.exe5374617475733A203330320D0A582D506F77657265642D42 (2048 bytes) Stat
-HTTPD-I-CGI, 5374617475733A203330320D0A582D506F77657265642D42 (2048 bytes) Stat
us: 302..X-Powered-B

tried it a second time and it happened again.
This is an error I’ve seen before: cr/lf between “302” and “X-Powered” causing havoc. So I’m not sure whether the password has actulaly be changed; I had the same problem on Diana before. Something to check with WATCH – but time has run out to handle it tonight….

Posted on

02-Sep-2009

A first success
One hour and a half it took, to find out why MySql didn’t work as expected.
I started with re-creating a base database since I couldn’t login anymore, and started the server. First things first: tried to access the database without password change: from the commandline, it was not a problem, but PHPMyAMIn didn’t like it – I needed to add a password.
From the commandline I tested if Diana could be reached, and that was no problem. Nor was starting a telnet session to the mySQL port: It got there – so the problem was not in the connectivity between the emulator and the real machine. Connecting to the Mysql on Diana however revealed a reason: No access for root@hera.intra.grootersnet.nl (the name comes form the DNS server – it needs to be cleaned…).
This is strange, since there is a line stating that root has access from any host. But the passwords don’t match, so access is dienied. So I added the line for this host, user ‘root’, in the Diana database, and added a password on access on the laptop database. Now, I could connect to the database on Diana, and back. I also find why i couldn’t access the database: the password needs to be specified on the commandline, as specified by the configuration…(by accident – it was in front of me in the mySQL-on-VMS-installation documentation all the time).
PHPMYAdmin now didn’t complain the server didn’t respond anumore, but next ran into a few problems causing a crash of the engine; probably because things were changed and the (persistent) server wasn’t restarted. So I stopped the PHPWASD process and restarted.
This worked fine, but an error I hade before appeared again – to be expected since I didn’t chnage the environment yes: the system ran out of pagefile space. So I added a second pagefile, doubleling the pagefilespace. That helped – I got something else to handle : I ran into a memory-size limit preventing an allocation to take place. This sounded familiar: there is a parameter in PHP.INI that limits the amount of memory than can be allocated by the PHP process. On Diana, this has been set to 12M – 1.5 times the normal value of 8M – being the default for PHP3. Since PHP 4 ( and 5 ) have a way higher maximum, it’s wise to limit it. I did so on Diana, and the PHP.INI file that comes with PHPWASD, puts on a constarint of 8M.
Updated that to 12M, stopped the process and restarted PHPMYADMIN, behold, it works:
There are still a few things left to handle in the PHPMyAdmin configuration but these are of lower priority, unless I need them.
Next to test is WordPress. I’ll start with the current setting: WP2.6.3 and one of the lesser blogs on Diana will be copied to the emulator and set up to read the data from Diana, so I don’t have to load the database on the emulator; If that works, the PHP installation on Diana will be updated.
Mark berryman has issued an update with some enhancements: some bits and pieces that are missing in HP’s version, and that one will be past of the test.

Posted on

01-Sep-2009

End-Of-Month actions
The usual monthly maintenance. There is little time to fulfill it all, and some updates need to be installed as well, so the big bunch will be done later this week.
First: the mal statistics for August:

PMAS statistics for August
Total messages    : 4906 = 100.0 o/o
DNS Blacklisted   : 3325 =  67.7 o/onbsp;(Files: 33)
Relay attempts    :   82 =  nbsp;1.6 o/o (Files: 33)
Processed by PMAS : 1499 =  30.5 o/o (Files:nbsp;33)
        Discarded :  249 =  16.6 o/o (processed),   5.0 o/o (all)
     Quarantained :  322 =  21.4 o/o (processed),   6.5 o/o (all)
        Delivered :  928 =  61.9 o/o (processed),  18.9 o/o (all)

The main activity tonight has been the archiving of operator and service logfiles. Well, that’s actually most of the work. But some check on the system health needs to be done some time soon, since the sysgen parameters have changed a few weeks ago (well, a few months ago, in fact). But as the system seems to run nicely, for it’s size, there is no reason why it couldn’t be extended some tome more.