29-Jan-2012

Updates
Three updates to be done, without much of a problem. At least, that’s anticipated.
Mysql
I’m running the release by Jean-François Piéronne, currently version 5.1.23, which has been released quite some time ago. Latest version as today is 5.1.46; same level but probably enhanced. So I updated the database, following the recommendations of the wiki on his site. There is a small typo in this document, but if you know VMS, it’s not much of a problem.
After restart, you need to update a number of tables but the script runs into a number of “Column already exists” errors. I don’t think it matters much, since the database runs fine after that.
The first attempt to access the blogs using IE8 failed but that may have been caused by running PHP-processes that lost connection the database (obviously the database needed to be stopped…)
Anyway, MySQL is now up-to-date.
Python and related
Second there are the Python updates. These come as logical devices: containers conta8ng all files, to be mounted as disks: one containing the libraries, and one containing the running software – one of them being the MoinMoin wiki. That update requires logical disks to be redefined, and some more logicals to be redefined.
This has all been taken care of, but for some reason, something goes wrong in running the WASD-procedure that starts the wiki:

ERROR 502 - External agent did not respond (or not acceptably)

Traceback (most recent call last):
File "sys$input", line 12, in

ImportError: No module named server.server_wsgi

I found the cause in the startup-file:

$ proc = f$environment("PROCEDURE")
$ proc_dir = f$parse(proc,,,"DEVICE") + f$parse(proc,,,"DIRECTORY")
$ @'proc_dir'logicals
$ @python_vms:setup
$ define PYTHON_FILE_SHARING 1
$ mcr cgi_exe:pyrte sys$input

# Debug mode - show detailed error reports
import os
os.environ['MOIN_DEBUG'] = '1'

import sys
import wasd

sys.path.insert(0, '/moin_root/')
sys.path.insert(0,'/moin_wiki_root/mywiki/')

from MoinMoin.server.server_wsgi import moinmoinApp, WsgiConfig < ---- Line 12 class Config(WsgiConfig): logPath = '/moin_wiki_root/logs/moin.log' # adapt to your needs! #loglevel_file = logging.INFO # adapt if you don't like the default config = Config() # MUST create an instance to init logging if __name__ == '__main__': while wasd.cgiplus_begin(): wasd.wsgi_run(moinmoinApp) $ $

There must be something changed internally???
I remember there is something in the WASD mailing list on the matter, so I'll have to dig the archives. But after I have removed all bogus accounts (prior to the installation...) there is little chance they have the opportunity to retry 🙂

So for the time being, the VMS-wiki won't start when acessed. Sorry for that.

30-aug-2009

PHP + MySQL
To find out what caused the inability of PHPMyAdmin on Eden, the emulated Alpha, to reach the database on the real one (Diana), I checked whether port 3306 is opened on the Windows environment. I also installed MySQL on the Vista machine, in case the problem was local on that machine.
As it turned out: the Windows installation of MySQL has no problem reaching the Diana one: start a MySQL client on the Windows machine, and connect to the database on Diana proved possible, without a problem. But still, connecting using PHPMyAdmin on Eden still didn’t work.
So I installed MySQL on Eden, following the instructions on the VMS-MySQL wiki, but wasn’t able to login once I changed the passwords, not even from the commandline. So I deleted the database and created a new one, but this time, I did not logout and tried to access it by PHPMyADMIN while the session was still open. It works fine, though now I’m too short in pagefile; I got a message within my interactive session:

mysql>
%SYSTEM-W-PAGEFRAG, page file filling up; please create more space

mysql>

After I disconnected from the session I wasn’t able to login again. Nor did PHPMyAdmin, for some reason.
I may have forgotton something…

So it looks as if connecting over the network, via PHPMyAdmin, doesn’t work yet. Locally, there is no problem (as long as the access isn’t blocked – by the McAfee or Windows firewalls on the laptop). I prefer this to be solved, I won’t need to pass all data from Diana to Eden, to test WordPress….

16-Nov-2008

Hardware problems
Due to electricity work this morning, Diana has been switched off nicely – to prevent possible problems on startup. Just a few minutes, not to bother about too much.
Well, so I thought, but it turned out that the whole excersise in getting everyting back online was a very, very different matter: to put it simple: Diana refused to come alive. power on was no problem but in the line of starting, everything froze. I’ve had the problem before and cycling power several times usually helped, but not today.
So I had to boot another Alpha off the system disk. The easiest – and probably fastest – way was to take the AlphaServer 400 – it has 160 Mb internal memory, and carries an EV4 processor running at only 233 Mz – slow, compared to the Personal Workstation but it should do for DHCP, DNS, basic mail (including PMAS – the spam filter) and the basic, static webpages. After having replaced some cards – including the one that connects to the Shared SCSI bus, I booted this machine minimal, changed some startup files to prevent starting unneeded stuff, and restarted. It hung – but interrupting on the console and boot worked. The system started nicely, though slow. Once running I could disable the links to the blogs and the wiki in the page header – I had to extract the data from the library, change it and put it back in – and could create a text file to show.
The system ran nicely for a couple of hours, I could finish the job I was working on,, examione what was wrong with the Personal Workstation (now I had DNS, I could access the Internet 🙂 ) , and after that, I tried to retrieve my mail.
I shouldn’t have done that.
For some reason, the AlphaServer froze. Login to the AlphaServer failed – only CTRL-P worked. I initiated a system crash but that didn’t finish – and the SRM dumped it’s contents. Something I’ve seen happening when booting the box on shared SCSI when the PWS already booted from it.
At that time, I had been working finding out what went wrong in the PWS. The documentation I could find showed the problem was related to memory. At some point, the PWS beeped: once, three times, three times. The doc stated: there is no memory, or if there is, something made it unavailable. Re-seating the DIMMs seemed to help, but it took several attempts to have the system come up without a problem.
Once the AS400 got stuck, I added a KZPSA card – seemed to be required to get the Shared SCSI to life. But the console has some trouble with it, the startup sequence mentioned an error at test E6: Command error 4; and error happened after test E4 as well: SIMPORT failed.
So back to KZPBA – one left so put that is. Hooking it up the shared SCSI however didn’t work. For one reason or the other, this card didn’t notice the disks. Perhaps the wrong SCSI-Id? Changed that, to no avail. Finally, I re=installed the original cards in the PWS and the AS400 – hooked them up to the system and rebooted the PWS: And all seems well, at the moment.
The lesson: It’s time to get a newer box. Power off the PWS may become a nasty problem – once down, it may not come back again. But for now , it works.
Database trouble
I found this error in the database log:
$ VERIFY = F$VERIFY(F$TRNLNM("SYLOGIN_VERIFY"))
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
081108 22:25:14 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Last MySQL binlog file position 0 3274, file name ./mysql-bin.000013
081108 22:25:23 InnoDB: Started; log sequence number 0 502105172
081108 22:25:23 [Note] Recovering after a crash using mysql-bin
081108 22:25:23 [Note] Starting crash recovery...
081108 22:25:23 [Note] Crash recovery finished.
081108 22:25:25 [ERROR] Column count of mysql.db is wrong. Expected 22, found 15. The table is probably corrupted
081108 22:25:25 [ERROR] mysql.user has no `Event_priv` column at position 29
081108 22:25:25 [ERROR] Event Scheduler: An error occurred when initializing system tables. Disabling the Event Scheduler.
081108 22:25:25 [Note] /$116$DKA100/000000/WEB/MYSQL/MYSQL051/VMS/bin/mysqld.exe: ready for connections.
Version: '5.1.23-rc-log' socket: '' port: 3306 Source distribution

and yet, everyting seems fine. I asked JEan-François about this, he suggested to do a check – it might be the result of the known problem with MyISAM – used by the MySQL engine itself. By mysqlcheck didn’t reveal anything worng. All tablwe were fine. But I might have missed something in upgrading the database, so that’s what I’ll do next – after making a backup 🙂
Update
It looks like it all worked, the conversion is done and all seems to be present. Here, at least. And a number of columns have been added to table mysql.db. Now time to restart MySQL and seen what the logfiles says:

$ type mysql051_root:[mysql_server]MYSQLD.LOG
$ Set NoOn
$ VERIFY = F$VERIFY(F$TRNLNM("SYLOGIN_VERIFY"))
081116 22:32:07 InnoDB: Started; log sequence number 0 579383835
081116 22:32:08 [Note] Event Scheduler: Loaded 0 events
081116 22:32:08 [Note] /$116$DKA100/000000/WEB/MYSQL/MYSQL051/VMS/bin/mysqld.exe: ready for connections.
Version: '5.1.23-rc-log' socket: '' port: 3306 Source distribution
081116 22:32:08 [Note] Event Scheduler: scheduler thread started with id 1
$

I guess that’s more like it should be.

08-Nov-2008

Cleaned obsolete stuff

I cleaned up some things now obsolete – and removed a bit too much: the WP23 contained the BC2008 blog… A good thing I back-up the database daily so tonight I’ll try to restore it in the WordPress database. Just the sql files needs to be adapted and that cannot be done on VMS *record size exteds the RMS capacity of 32K) ; so I’ll copy the file to one of the Ubuntu boxes and do the update there. Hopefully, that will work.

I do have a backup of the whole database anyway, worst case I’ll have to rebuild it from the ground up. But that’s an excercise I’ve done before.

It turned out not too bad, in the end. Using the umpfile of the daily backup job, taken just before the database was upgraded, contained all the data but it needed to be edited. The only way to process this 20Mb file was moving it to Maya – the Ubuntu laptop – and process is using VIM. Quite some work if you’re not acustomed to this editor….

I was able to extract just that part of the dump (Of course, I loaded the data into the WordPress database (minort change in the file :)), moved it over to Diana and sourced in in MySQL; Changed the database in the configuration – and the Bootcamp 2008 blog is back online!

System disk backup incomplete

In tthe prelude to this excercise, I found the backup’ed systemdisk could not be mounted:

%MOUNT-F-INVALIDSCB….

Pushed the question onto ITRC with an explanation how it may have happened: Lost connection to the rpocess running the BACKUP image; and although it seemed to continue, it didn’t, appearantly, since the error is the result of a non-complete image backup. So I’ll have to redo it….

I thought it might have been solved by rebooting Diana, and for that reason, I installed the latest patch; It required a reboot anyway.

The system started – but it seems there is a slight problem; The registry was started (weird) of would it have been SAMBA that caused the warning? And there is a potential pool expansion problem…

To be looked at tomorrow.