I just came up with the perfect tagline for the new Hitchhilker's Guide to the Galaxy (HHGG) movie for which the preview is now available based on that preview:
A film almost entirely but not quite unlike the book.
That's a compliment by the way.
For all of my regular reader (sorry, old joke) the big news for February and Ben's six-month birthday is that he now sleeps unswaddled. Let angels sing and cherubim frolic. A big transition for us, and apparently of little significance to him; he's busy sleeping. I'll post more updates on Ben's beaming face, his ability to sit unsupported, and his one (so far) unassisted roll from stomach soon.
This one goes out to the MySQL administrators out there who were baffled, like me, why when they upgraded through their normal process from 4.1.8 to 4.1.9 (or to 4.1.10) their invocation scripts broke given them strange and annoying errors. The reason is that the MySQL developers changed the context into which mysqld is launched via safe_mysqld. I'm writing this post so it can be found with a clear answer (much clearer than is documented over the MySQL developer's site) on how to fix it.
I have two instances of MySQL running on a dual-processor machine in order to balance load. This made a large difference when I split up databases of equal utility among them. So I invoke them by defining a my.cnf file in /etc/ with settings applicable to both, and then I have a my.main.cnfand my.second.cnf set of files that are particular with ports, sockets, and other details.
I invoke mysqld as
Now this stopped working when I upgraded from 4.1.8 to 4.1.9. I stepped backwards assuming a bug and didn't have time to deal with it. The other night I tried to jump to 4.1.10. Same problem. I start reading bug reports and resolutions and release notes and find an obscure note about the data directory being resolved to a path relative to mysqld if mysqld is invoked via mysqld_safe through a relative means. This didn't make complete sense as I had defined the datadir in my .cnf files.
But there you go: I had to add an explicit --datadir declaration into the safe launching:
mysqld_safe --defaults-extra-file=/etc/my.main.cf --datadir=/path/mysql
mysqld_safe --defaults-extra-file=/etc/my.second.cf --datadir=/path/mysql_second
Then it worked. Really frustrating, and it took me about 45 minutes to sort it out because the behavior is inconsistent. I'm not sure whether it's a bug or just something that you can no longer define within a .cnf file. I've added a note to the bug report to see whether they'll either deprecate use of datadir within configuration files or fix this problem.
When you pull 30 miles of Ethernet into a new facility, you wind up with a comfortable pile of snipped ends, good for sleeping on at 2 a.m. while servers are rebooting (according to my co-location facility's CTO).
My co-lo is digital forest, and they're moving from the outskirts of town up northeast, where they've resided in sleepy Bothell, to the edge of Seattle--literally as the southern border of town touches their server room's edge--in a spanking new building. Spanking new in 2001, that is, when the tenant who had the building constructed went belly up, leaving it mostly empty for four years.
I took pictures with their permission of my tour. You can follow the saga of moving hundreds upon hundreds of active servers on a procession across the lake and down the highway in the wee wee hours every night for weeks on their Support blog. It's gotten quieter as they've moved virtually all of their hosted boxes that they talk about publicly and are now moving client co-lo boxes (such as mine) which they don't broadcast the identity of.
I feel for them. The technical staff hasn't had much sleep in weeks and the migration continues until mid-March.
If you're looking for a very well-priced co-location facility with top-notch people, I recommend these folks unhesitatingly. They're responsive, interested in finding a solution, and their prices are damn fine. The new facility is even higher tier than their last.
It's terribly hard to get rid of old Macs, because I love them so. However, I'm about to do a big swap.
Out: I swore I'd never sell it, but the G4 Cube no longer meets my needs as a potential home entertainment centerpiece after some months spent running Mac OS X Server in the office. It's being sold, as cool as it is, because it's still a good machine and needs to find a good home.
In: Mac mini! It'll be our music, video, DVD, CD player for the near future fitting nicely in our entertainment console. At some point, when we upgrade from CRT to LCD for our TV, we'll find the DVI interface quite nice.
Out: Power Mac G4 upgraded from 450 MHz to 850 MHz with FireWire 800 added. My brother in law needs an upgrade from his blue-and-white G3, so that's a good move for the G4. The G4 has been the office server, handling backups and faxes among other tasks, for several years. Its backups have paid for themselves several times over through a number of disasters that it's helped me recover from. But it's big.
In: G4 Xserve. This machine was, for a while, running parts of isbn.nu and other systems, but it was ultimately not fast enough as a workhorse system. It's a little too specialized. I'm bringing it from my co-location facility back into my office to fit onto a nice rack I already have in place where it will run backups, and be a testbed as Mac OS X Server 10.4 (Tiger) appears, which I will write about for various publications. It's a nice dual 1.33 GHz G4 system, so it's got a lot of life left in it. Plus, I bought a software subscription for it that expires Oct. 2006, so I'll get at least Tiger at no additional cost. It originally ran Jaguar, so I'll get $2,000 worth of software out of a $1,000 subscription.
Out: Two Linux boxes. I might drill through the hard drives instead of wiping them to avoid years of data remaining even faintly on the disks, but the old isbn.nu box, which has practically no duties at the moment, will retire. Likewise, a replacement system I built in the event of emergencies from new parts will settle into a Craig's List posting for whomever needs a nicely priced, never-used Windows or Linux system. The Xserve will answer for the working box's meager requirements.
In: A spanking new somewhat expensive database server. This will be my third Linux box from Penguin Computing that will reside at the very fancy new digs of digital forest. In fact, my other two boxes are moving on Wednesday night, I believe, and my new machine should arrive later this week to join them. The core needs of isbn.nu are database operations, and the new system will be powerful enough to handle the load. Related to this is that I need a machine solely to build new databases that isn't a production system on which users depend. This move will dramatically speed isbn.nu performance and make it even easier to keep data fresh.
This is not a doctored screen capture.
I wrote Cory Doctorow the other day "complaining" that I would have random interesting ideas flit through my head and realized they were all snippets from his intriguing fiction (and sometimes non-fiction). He response: "pwned!"
I was almost "pwned" last Sunday and yesterday when a flaw in awstats 6.2 and earlier, the program I started using partly because of Cory et al. at BoingBoing to perform traffic analysis, allowed a bunch of Brazilians to pwn sites all over the Internet. Luckily, the root kit--a prefab package for taking over a Web server when you have local user access--disabled all access to my computer when it ran rather than allowing access. A later check using rkhunter found no rootkits or replaced binaries. But I'll be watching.
By the way, I don't believe there's a connection between the theft of my credit card number and the attempt to take over my machines. I don't store credit card information on those servers, including my own.