The server got hacked over the weekend because I had an old version of Drupal on an old version of Ubuntu (yes, Sitepoet is coming along nicely and should fix that…). So in the rebuild I made two changes to the system to help out when things like this happen again.

First, there is now an el cheapo Rackspace cloud instance functioning as a MySQL replication slave so I have a live backup of the database. This is because after the hack was discovered by the fine folks at Quantact they rate-limited the VPS so the attacker would see less use of the instance and not be able to flood anyone (a good practice). However, what that also did was cause mysqldump to fail to get a backup of my database (about 1.1GB). I had a system doing a nightly DB dump and rsync of important files, but that dump was a day old, not live. Now it’s live.

Second, on the advice of a friend I looked into Drupal’s memcache module and a local copy of memcached. It’s a rather nice little module that simply moves all cache get/set calls away from using the database and into using the memcached server instead. Sure, it takes up 64MB of RAM on my wee 512MB instance, but, well, look at the numbers:

Gets 2.20/s; 121,255 gets (82.21%); 121,255 hits (100.00%) 40,059 misses (33.04%)

That’s an 82% hit ratio for page content. That’s crazy. The site is amazingly faster now that it’s not I/O-bound under load and should it ever get hammered it will cache the queries for the hammered page in memory and not get bogged down in the database. Fantastic. Now I just need content worthy of getting hammered…

PS: Oh, if you run multiple sites off the same install (as I do) you’ll want to put a prefix on the cache keys lest you start serving out cached data from one site to another, such as the compiled page template…

A large portion of the time spent uploading a large directory with utilities like scp and sftp (and sometimes rsync) is sending all the meta information over for the various files (and creating them). For some reason, this sometimes takes a purely silly amount of time.

The upside is there’s a simple trick that will let you upload things very quickly. The tar command is optimized for dealing with lots of little files and does it far, far better than the other commands. It’s not network enabled, but ssh does understand pipes…

tar cz MyDirectoryOfLittleFiles | ssh remote.host "tar xz"

Ta da! Full-speed uploads with tar on either end doing all the file work and ssh just encrypting the stream. For me, over local connections, this gives a much more even upload experience than scp alone ever did, especially for large directories of small files (source, for example).

Downside: it doesn’t do syncing like rsync. If this fails in the middle, you get to start over or switch to rsync to finish it.

Disconnect everything, power first. Keep the drain hose above the top of the washer if the bucket’s full of water. If there are clothes in it, remove them to a water-tight location (like a cooler or something).

Put the unit on an appliance dolly and get it onto the driveway before removing the drain hose from the rear of the unit. Water will gush out for a while here.

Unscrew the two hex bolts at the top of the unit that attach the plastic tabs to the console. Unscrew the screws in the end caps that attach it to the top of the cabinet. Unscrew the two hex bolts at the base of the rear panel that attach it to the base.

Pull the console forward and up a little to dislodge it. Slide it out of the way enough to get access to the two brass clips. Put a flat-head screwdriver in the hole towards the front and pry the clip forward a little to release it. Remove both clips. This releases the rear panel from the top of the cabinet.

One cable goes from the console to the top of the cabinet: this is the lid switch. Disconnect it.

Pull the cabinet forward now that everything is detached. It helps to have someone holding the console and rear panel while you do this. Remove the cabinet.

Place it on something to prevent scuffing, like a few towels or a small animal. The lid switch is the only device here. Unscrew it from the ground (one hex screw) and from the inside of the lid (two Phillips screws). Push the grey tube holding the wires out of the clip holding it in and release the plug from the top of the lid.

Take this to a parts shop and ask for another. It’s around $25-50 depending on how desperate you look.

Snap the gray tube back in, screw in the ground and switch. Close the lid: it should click now. If not, check that you actually screwed the new unit in properly. Yes, the new one.

Replace the cabinet and the rear panel, then the clips and the console. Replace all screws and bolts. Make sure there are no spare parts.

Codesign error: no certificate for identifier “iPhone Developer” was found in your keychain

Getting this error when building an iPhone app? Yeah … you’re going to love the solution:

After much tinkering around, I tracked the problem to a keychain error.

And TADAAAAA: Go to Keychain Access -> Preferences -> Certificates and deactivate both automatic checking gizmos.

Quit Xcode, relaunch. It worked for me. Instantly.

Best advice for .Mac Sync failures, ever.

One creative little AppleScript later and with a couple of keystrokes you can see your bank balances on screen immediately. Oh, the things curious coders will code.

read more | digg story