Maintenance

Drupal's fantastically complete logging caused me to check on it once again in order to respond to an associated request. I did this:
tail -f /m1/mysql/logs/mysql.log
to watch stuff go by (you can pipe out to grep <db_name> to limit the spew that comes out).
Just for the sake of interest, loading a Drupal page generates ~5MB of log, and 2 minutes on the site generates a total of ~17MB - including the initial 5MB load. So, after loading the page, the CMS seems to create approximately 6MB of logs/minute.

We're now a little short of computers for our RAs to work on, so I fired up the dual-boot machine in the corner. The video card fails to start the monitor the first time you boot, so you don't get anything until you get to the Ubuntu login screen, but a reboot enables you to see the Grub menu and choose Windows (which we need for the IMT). The AV subscription has run out (note to Greg), and there were a lot of Windows updates to do, so I'm doing those, and I've also updated the IMT. CC can work on this machine.

ES and PB came down to retrieve one or two small items, and to confirm that what's in the room they were using is now in our hands, so JN and I were able to clear that side of the wall ready for the reno too:

• Seve PCs, more than a dozen monitors, and surge-protector outlet blocks are stacked in one corner.
• The refrigerator had some unsavoury stuff in it, so we removed old food and washed ancient containers. Its icebox is full of ice, so we've left it plugged in, because defrosting it would be impractical in its current location. If the power is going to be disconnected, we need to watch out for any leaks from it. We've left easy access to it so that it can be removed if necessary. If the power in that back wall (backing onto the ETCL space) is going to be disconnected, then it should be removed and defrosted somewhere appropriate (outside, maybe).
• Other bits and pieces of equipment are stored in the cabinet.
• Desks are arranged in front of all the equipment.
• The room dividers are arrayed in front of everything, so it should be easy to sheet over it all.

I counted ports, and found that we have ten data ports and one telephone port on the coordinator side of the wall, and 14 data + 6 telephone ports on the other side.

The demo part of the renovation is now suddenly looming, so JN and I spent most of the morning clearing desks and workstations away in the area in front of the coordinator's office:

• Some stuff, including AK's workstation and our big scanner, is stashed in the coordinator's office.
• The two small desks used by the ISE project are in the workshop, along with their bookcase.
• The bigger desks are stacked up in front of the coordinator's office windows.
• All the media station hardware is stored inside the upside-down desk, where it'll be easy to cover with plastic. We did our best to disconnect as few cables as possible, so (for instance) the mixing desk and equipment rack are still rigged together, and were moved as one unit.
• A projector screen we found in the corner is in the workshop.
• Some of the ISE equipment is stashed in the upturned desks, and the rest has been taken upstairs to the ISE office.

We haven't yet done anything with the stuff on the other side of the wall (the old history project area) because we've heard nothing back from Stewart's email on Friday asking the History folks to dismantle their stuff. I'll prompt them again today, and if we don't hear anything by tomorrow morning, we'll have to start dismantling that stuff too.

Just logging the daily churn of maintenance issues:

• Early in the day, various people reported that none of the Cocoon projects which have their own domains or subdomains was visible on those domains (Coldesp, Mariage, Scancan.net). After confirming that the projects themselves were still live and working on their "real" addresses on Lettuce, I reported this to sysadmin; DL responded to the effect that the proxy server was reporting an invalid response from the upstream server. He restarted Jakarta (by which I presume he means both Tomcats, live and dev), and the problem went away. We should watch out for any recurrence.
• SB from GRS called to say that modifications to the UVic Events Calendar were not showing up on the GRS home page (they're supposed to show as a little RSS listing). For me they did show up, so I diagnosed a problem with browser cache, and explained how to do a super-reload to refresh the page. This seemed to solve the problem, although she later called back to say the events had disappeared again, and I saw the same thing until I reloaded my own page. Possibly just a weird glitch, but we should watch out for this, too.

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.

Putting in a graphics card in Martin's machine resulted in what appears to be a dead mobo (see Martin's post).
I set up Turnip as his workstation until we get things sorted out.

Here's the way things look:
The machine will make a regular POST sound; there is a brief flicker of light from the keyboard; drives and fans spin; mobo power indicator is on, etc. ad nauseum.

Going through dozens of forum posts, it turn out that this is not as strange as I expected. Lots of people complaining of similar (but not identical) problems. I've gone through every "fix" I could find with no joy. I've tested the machine with only one stick of RAM in each bank's first slot. I've tried with no HDD/DVD. I have not reseated the CPU (and I won't).

Tomorrow I will take it to the CStore and ask to get the board RMA'd.