A while back I had some problems with MySQL running out of space on /var. Today I found out my Gallery2 was down, responding to all requests with “An error has occurred while interacting with the database.”

In the config.php file in the gallery2 install folder, there’s a line that sets the debug mode. By default it’s:

$gallery->setDebug(false);

For debugging I changed it to:

$gallery->setDebug('buffered'); 

and reloaded the Gallery main page. That displays a shitload of debug messages at the end of the page. In my case, I saw the familiar MySQL message about a table being corrupted. This time, it was g2_CacheMap. I did a quick repair table g2_CacheMap in mysql, and voila!, Gallery is back up.

Last weekend my problem with disk space exhaustion resurfaced, and seemed to upset MySQL, as I get the following warning when I log into Drupal:

user warning: Table ‘./drupal/watchdog’ is marked as crashed and should be repaired query: INSERT INTO watchdog (uid, type, message, severity, link, location, referer, hostname, timestamp) VALUES (1, ‘user’, ‘Session opened for root.’, 0, ”, ‘http://apocryph.org/?q=user/login’, ‘http://apocryph.org/?q=user/login’, ‘65.89.8.127’, 1153755477) in /usr/local/www/drupal/includes/database.mysql.inc on line 120.

This morning I noticed the /var filesystem was at 100% capacity on bonzo, leaving MySQL somewhat hosed. Upon poking around in /var (which, sadly, I only made about 300MB) I removed a CVSUp catalog for the FreeBSD src tree that was taking up alot of space, and with the time that bought, sought a permanent fix.

First, I see three big files in /var/db/mysql: ib_logfile0, ib_logfile1, and ibdata1. Upon a bit of googling, I found these were the tablespace and log files for the InnoDB storage engine in MySQL, somewhat akin to the data and log device files SQL Server uses.

The problem, though, is that none of my databases use InnoDB. The MyISAM storage engine is fine for my needs, and considerably less complicated. So, I poked around for the my.cnf config file that’s supposed to be in /var/db/mysql, but it’s not there, suggesting the InnoDB stuff was compiled in. At any rate, I moved the files elsewhere and made sure my databases were still working, which they are if you’re reading this.

A few weeks ago my father pointed out that the date stamps on my blog posts were behind by a week. Upon investigation, I found that bonzo’s clock was a week behind. I updated it and declared victory.

Then, he pointed it out again a few days ago. Sure enough, it had slipped by several days. When I logged into the VMWare Console to check for options to sync the clock or whatever, I noticed a repeated error from the FreeBSD kernel that I’ve been getting on bonzo forever and always ignored:

calcru: runtime went backwards from [some big number] usec to [another] usec for pid [pid]

Recently I had cause to set up a WordPress blog engine on a virtual host on bonzo. My experience follows:

First I need to set up DNS for the domain. The owner of the domain used the registrar’s control panel to set the authoritative nameservers to ns1.afraid.org through ns4.afraid.org, which are the nameservers provided by FreeDNS.

Next, I log into my FreeDNS account, add the new domain to my domains, and point the domain and www. to bonzo’s IP address. I don’t have mail setup yet, so I’ll ignore the MX record for now.

Now, querying the domain in a web browser should bring me to my site on bonzo…sure enough, it does.

Today I went to slightly change my Apache 2.0 config on bonzo, when was greeted with a nasty error when trying to restart the process:

bonzo# apachectl restart
/libexec/ld-elf.so.1: Shared object "libexpat.so.5" not found, required by "httpd"

I suspect this is due to some of the upgrading it with with the ports tree recently. Obviously something needed a new version of libexpat, which broke my older build of Apache. I put a band-aid on the problem with:

ln -s libexpat.so.6 libexpat.so.5

in /usr/local/lib, but I don’t like running older versions of software. I noticed that Apache 2.2 is now out and in the ports tree under www/apache22. The upgrade instructions seem fairly straightforward, so I’m going to go for it.

I want to run the popular Azureus BitTorrent client on bonzo, which has a ton of bandwidth to burn. Bonzo is a virtual machine on a rackmount server in a data center, so I need to run Azureus in headless mode, using its HTML UI to control it from afar.

I’m starting with a freshly upgraded FreeBSD 6.1-RELEASE box.

First, I’ll need to install Java 1.5. As it happens, Sun and the FreeBSD team have finally come up with an official Java release for FreeBSD.

I’m taking advantage of my leave back in the US to do some much-needed maintenance on my stateside computer systems. One such maintenance task is upgrading bonzo from FreeBSD 5.4-RELEASE to FreeBSD 6.1-RELEASE.

I’m following the upgrade procedures in the installation notes. First, I’m making a note of the device names and mount points:

 bonzo# mount
 /dev/ad0s1a on / (ufs, local)
 devfs on /dev (devfs, local)
 /dev/ad0s1g on /home (ufs, local, soft-updates)
 /dev/ad0s1e on /tmp (ufs, local, soft-updates)

I’m in Baghdad now, where my only link to the ‘net is a high-latency satellite. Mozilla Thunderbird can’t hack the delays this introduces, and thus times out when attempting to fetch my IMAP mailbox on ender. Thus, rather than use one of the other shitty IMAP clients, I’ve decided to pull the trigger on SquirrelMail.

I have previously attempted to install RoundCube, but found it a bit too immature at this point, so I’ve decided to go with something tried and true: SquirrelMail.

Fortunately, the FreeBSD ports collection includes SM, and a pre-built package based on 1.4.5 is available. Unfortunately, the pre-built package uses Apache 1.3, while I run Apache 2 on bonzo. This leads to all sorts of fun:

Today I happened to be tailing my httpd-access.log on bonzo, and noticed several requests from 85.64.146.188 for various top-level pages on apocryph.org, with a user agent value of Port Huron Labs. A bit of googling leads me to believe that Port Huron Labs is an email harvester.

The IP address is registered to an ISP in the Netherlands, according to ARIN. That ISP’s internal WHOIS server reports the IP is assigned to an Israeli company. I suspect they are innocent in all this; they have an entire Class B subnet, so I suspect one of their machines has been compromised and used to crawl the web for email addresses.