SYSMGR

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.

Wednesday, April 26

26-Apr-2006

WordPress configuration
Now the MySQL trouble seems to be solved, I can continue setting up Wordpress - that is: see what works and what doesn't. Main part, for now, is the inability to change the way the blog looks like.
Now digging in the Wordpress database, there are two records that are relevant: the one named "template" and the one named "stylesheet". Both were set to "default" - what's fine, actually, but chnaging them to a theme that is present (in [.wp-content.themes]) made no difference. Obvious, since code i n functions.php checks for the existence of the directory file and that check was missing the .DIR extension. After I added this, I could change the way the blog looks like - but only to a certain extent. I have to check - [.themes] does extist but [.templates] doesn't - and I might need them as well (As an example: Setting both stylesheet and template to "industrial" showed, indeed, the page as I expected it to look like, but some menu items (including login) were missing. And changing the template to "classic", for instance, caused a flat view of the page - meaning: I lost the layout).
BTW - MYSQL 5.1 is available - in BETA - but it's not a requirement to run WordPress, so I'll wait some time.

MQ-Series
This week is filled with a course about the IBM product - which also runs on OpenVMS but I think it will be too expensive to give it a try...
Security
Funny - I haven't seen any FTP abuse attempts for some weeks now.... And HTTP is very low as well.
I have re-enabled the filtering on non-backtracable addresses - adn a lot of spam is blocked now. I will have to remove the message texts to just a simple default message stating the connection was dropped, will be signalled.

Monday, April 24

24-Apr-2006

PHP_MYSQL - another try
Had contact with Jean Francois Pieronne about PHP_MYSQL. I already found out that the shared images of OpenSSL MUST (!) reside on SYS$LIBRARY for PHP to find them. There'se one more: LIBZ_SHR32. But locating them on SYS$LIBRARY alone didn't help.
On JFP's suggestion tried to use static linking - started with LIBZ but that releaved two undefined references: COMPRESS and UNCOMPRESS.

Idea: Since it seemed required that these shared images reside on SYS$LIBRARY, added references to both OPENSSL-images and LIBZ - all residing on SYS$LIBRARY - in the build commandfile, using the names as mentioned by all the errors ruuning PHP manually (which can be different from the source names: LIBSSL for OPENSSL098A_LIBSSL_SHR32. EXE and and LIBCRIPTO for OPENSSL098A_LIBCRYTO_SHR32.EXE), and added these in the option file for building, and building went OK. Next the same references were added in PHP_SETUP.COM, just to be sure. Restarted Apache - and now it works!

The whole seqence can be read on his MySQL forum at http://www.pi-net.dyndns.org/phpbb/viewtopic.php?t=64 - and it has been mentioned to ITRC since it's mainly PHP that causes the problem, I think, by requiring any shared image to reside on SYS$LIBRARY. Not exactly VMS-like!

Now I could make a backup of the Wordpress database - and indeed, the problems using the RSS feeds that caused problems before, are now gone. But the look and feel still cannot be changed. Likely it has to be re-installed. Ok, no problem.

DECNet issue
In the restart yesterday, it was forgotton to disable the secondary NIC - not yet connected this causes a massive amount of OPCOM messages - and DTSS was kept running as well - and since it looks for 2 additional servers, this gives a large number of messages as well. This morning, I corrected that error - after finding an Operator log of a massive 26Mb, where it usually is about just 10K
It should be in the startup sequence ....

Sunday, April 23

23-Apr-2006

Power outage
This evening, there was a brief power outage - about 10 minutes - and Diana and it's periferals came backup nicely - just that the database container wasn't opened for some reaon - LD claiming duplicate device name on LDA4 , but that's nonsense - causing MySQL startup to fail. However a manual startup went flawlessly...
Next issue was that the nameserver showed only the local hostfile, and not the BIND database. Therefore, any outside access would fail. Funny though that TCPIP$DIG had no problem at all locating outside addresses...
Rebooted Diana - that is: shutdown and boot manually - and the same problem with the database container caused a failre of MYSQL-SERVER once more, but BIND came up perfectly and worked fine.
Got the database online manually.

Saturday, April 15

15-Apr-1006

PHP-Mysql rebuilt
using what Martin Borgman of www.oooovms.dyndns.org (and www.4ovms.dyndns.org) has pointed out on Jean-Francois Pieronne's bullitin board (http://www.pi-net.dyndns.org/phpbb/viewtopic.php?t=64), but it made things even worse: the resulting executable (created using CC 7.1) is not recognized as a PHP library:
PHP Warning: Unknown(): Invalid library (maybe not a PHP library) 'php_mysql.exe' in Unknown on line 0
No matter what I tried.
So I reversed to the original one and that does work properly...
The whole issue is discussed on ITRC (http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1016682) and, if JFP allows me as a member, on the mentioned Bulletin board.
Disk broke
One of the 18Gb disks broke, minutes after the moment I copied files I needed. It's completely dead. Luck it wasn't used yet except for this small stuff (that was FTP's to the location I needed it)

Tuesday, April 4

04-Apr-2006

PHP/MYSQL update
As it turned out tonight, logging at the top level using phpmyadmin indeed DID show all databases, but one level lower that user lacked privileges - as did the Wordpress administrator. Omce that was settled, the PHP programs could be reused as intended.
In that investigation proces it was found that lack of speed and surounding problems simply has been a matter of lack of paging space. On the system disk, there is a pagefile of 523.500 bl;ocks (which is 260 Mb - just over the system's memory - and on the local disk there's one of 600.000 blocks (just less than 300Mb):

Paging File Usage (8KB pages): Index Free Size
ALPHASYS:[local]PAGEFILE.SYS;1 253 15125 37496
DISK$AXP082:[SYS0.SYSEXE]PAGEFILE.SYS 254 10776 33280

size is in 8KB pages - so it makes sense.

That aought to be sufficient, but presumably, it isn't.
Fully running, after updates with PHPMyAdminand Wordpress al most consumed all. Matter of buffers in Mysql, I guess, or even a problem with PHP's memory requirements?
Putted it on ITRC, we'll see.

(What wonders me is that BOTH pagefiles are heavily used, where the primary one (index 254) should NOT be used that heavily; the other one is installed very early in the startup sequence so I would expect it be used more heavily. But it can be that pagefile usage has been improved in VMS 8.2 over 7.3-2)

Monday, April 3

03-apr-2006

PHP/MySQL trouble
PHP is very slow - there are regular time-outs and other problems, and for some reason, the MYSQL_SERVER crashed this afternoon on access violation. Guessed it wss because of shortage in memroy (it did tell "not enough core' ) so I raised APACHE$WWW's pagefilequota (500.000 to 2.000.000).
It didn't help, really....
Worst: I seems to have lost entered user data!
Patches and reboot
I installed some patches and rebooted Diana, after having made a system disk backup. Changed the default bootdevice to be the new system disk (before boot, of course)
Still trouble
After boot, it turned out that the database volume wasn't mounted - the container had not even been loaded. MySQL wasn't started, it seemed. No, of course not: since the volume containing the database wasn't available!.
Started it manually, and it tuned out again that I lost data of users I entered. More: Wordpress cannot find it's database???? PHPMyAdmin can neither, but Mysql itself has no trouble accessing the Wordpress database:
mysql> use wordpress;
mysql> select * from ws_options;
is no problem at all, but:
mysql> use mysql;
mysql> show databases;
didn't show up any of the added databases either! So I decided to recreate the wordpress database:
mysql> create database wordpress;
and it says:
Cannot create database: wordpress already exists
and
mysql> show databases;
now shows them all!

But when starting Wordpress on the web, it still cannot find it's database, and phpmyadmin doesn't see any other databases than the default ones.

MYSQL log gives no clue whatsoever on what might be the case. Nor does PHP...

Wordpress data cannot be read - by PHP
Accessing the wordpress database table wp_options - the one that cannot be read by phpmyadmin and Wordpress after line 61 - could well be read by mysql so the data itself is correct: it contains the RSS-lines on line 66 and further; the point is that one of the fields: wp_iptions.option_name, is quite long: RSS_<a number taht's over 20 characters in size>. These indeed showed up in the administration panel of Wordpress.
Since it's a problem for two distinct PHP programs, the guess is that is is the php_mysql module that has a problem.