We have a genuine need for the "cluster of one" server that Mustard is to become, to provide an Apache front-end to the Tomcats on Pear, so we're checking through one last time to see if there are any running projects on Mustard. Today I added manual redirects, through meta tags in the HTML pages, from all the ACH/ALLC 2005 conference site pages on unix.uvic.ca (in lang01), so that they redirect right over to Pear. That should be sufficient for the moment; once we have addresses on port 80, we can change those over.
Category: "Announcements"
Took the plunge and upgraded to Lucid today. Here are some notes on what I had to do:
- Standard dist-upgrade worked fine, no issues with drivers.
- Thunderbird was upgraded to version 3. My QuickText plugin stopped working, but I was able to install it again from Add-ons, which worked despite complaining that it wouldn't.
- QT Phonon is still broken. This is the bug, and none of the workarounds work for me, unfortunately. But this is not a regression; it was broken in Karmic too.
- Mozilla Sunbird was uninstalled for some reason. Went and got another copy, which installed fine and found all my data, but the site says it's the last Sunbird release, and we should move to Thunderbird + Lightning. All very well, but the default Lightning plug-in is not 64-bit. Had to find a 64-bit download here. Installed that in Thunderbird, and then exported my calendar from Sunbird as ICS and imported it into Lightning, without problem.
- Lots of 3rd-party sources were disabled; re-enabled them, switching "karmic" or "jaunty" to "lucid" in the paths, and did updates, getting a new VirtualBox in the process.
If any other oddities appear, I'll document them here.
This morning I did a checkout (without deleting the existing tree) and a build; the JNLP link failed, and required that the cocoon app directory be inserted into it to get a working link. However, immediately afterwards I deleted the source tree and did a fresh checkout, and it worked correctly. It's clear that the file controller-config.xml is nothing to do with the problem, because that file is identical in the broken and working versions. It seems that deleting the source tree solves the problem. Now we need to see whether a simple build clean will solve it. More experiments continuing.
From an eXist list posting:
The error damages the indexes. To recover from it, you would need to stop the db, remove all .log and .dbx files except dom.dbx, symbols.dbx and collections.dbx, restart the db and use the Java admin client to reindex everything.
Doing my regular backups of the blog, I noticed that the size of the db had tripled over the last week. After some sleuthing, Greg and I discovered that we've been heavily hammered from an IP in Spain (193.144.251.31), which we presume must be a compromised server; it appears to be trying to comment on everything, and although comments are blocked so it's not succeeding, it's still filled up the hitlog and sessions tables, so we cleared those out. That brought the db down to half the size it was a couple of weeks ago. We've set up a cron job to do that every night.
Monday, July 21: 9:30 am – LMF class; MR instructor
Concern: Teacher's console / monitor / frozen blank screen;
Sending CD content to student machines
1. Instructor powered up Sanako,
2. Teacher’s monitor showed grey screen with small white screen displayed in center. Screen frozen.
3. Managed to return to desktop.
4. Performed successful shut down.
5. Powered back up ok but slowly.
6. Returned to Sanako screen, monitor “jumped” back to desktop screen on its own.
7. Clicked on Sanako icon on desktop, Sanako slowly returned, however, it “jumped” back to desktop.
8. Repeated same steps and on 3rd try managed to get Sanako to remain on screen.
Instructor reported unable to send CD contents to student machines.
It looks like I'll need to rebuild the DB from scratch, but it shouldn't be done until I'm finished deploying all the new machines. Just a guess, but it'll probably take a few hours to do it.
Instructions from here:
To test whether the database file is corrupt
- Close Ghost Console.
- Stop the Ghost service:
- Click Start, and then click Run. The Run dialog box appears.
- Type:
C:\Program Files\Symantec\Ghost\ngserver.exe -stop
and click OK. The drive letter and path might be different on your computer. This stops the Ghost Console Services.
- Find the SymantecGhost.db or NortonGhost.db file and copy it to
a safe location.
- The database file for Symantec Ghost 6.5 Enterprise Edition and later is SymantecGhost.db. The default location for this file is the \Program Files\Symantec\Ghost\db folder.
- The database file for Norton Ghost 6.0 Enterprise Edition NortonGhost.db
- Norton Ghost 6.0 Standard Edition does not use a database file.
- Rename the file SymantecGhost.db or NortonGhost.db or delete it from the hard disk.
- If you have Symantec Ghost 7.5 or 8.0, copy the following blank
database file to the Ghost Console computer:
download this - Restart the Ghost Service with either of the following methods:
- Restart the computer.
- Install the service:
- Click Start, and then click Run. The Run dialog box appears.
- Type:
C:\Program Files\Symantec\Ghost\Ngserver -install
and click OK, and click OK again. The drive letter and path might be different on your computer. This installs and loads the Ghost services, NGServer, and NGDB. You do not need to restart the computer.
- Open Ghost Console. The Console no longer displays configuration information. If the Ghost Console still shows configuration information such as Tasks and Image Definitions, restart the computer and then open the Console.
- Determine whether the problem is resolved. To find out, you
might need to add configuration information, such as new Tasks or
Machine Groups. When you add configuration information, Ghost 7.0
and earlier create a new database file. Ghost 7.5 and 8.0 add the
configuration information to the blank database file that you
copied to this computer in step 5.
- If the problem is resolved, the cause is likely due to corruption of the database file. Recreate the configuration information. See the section "To rebuild the database."
- If the problem is not resolved, then the problem is not due to corruption of the database file. In that case, replace the new copy of the database file with the backup you created in Step 2.
To rebuild the database
- Follow the steps in the procedure "To test whether the database file is corrupt." That procedure creates a new database.
- Click on Help and reregister the Ghost Console. Use the same information that you used when you did the original registration.
- Recreate the configuration information.
- Recreate the Tasks.