system administration

iTerm as VisoriTerm2 is a replacement for the built-in Mac terminal app. It provides many terminal features you may be used to from other systems (ahem, Linux), as well as some unique features and tools.

When it comes to OS X integration, iTerm2 has some amazing capabilities. You can even configure it to emulate Visor. Here I explain how to configure iTerm2 to slide down from the top of the screen like a Quake-style Visor. You can get an idea of what this looks like from the image on the left (click on it for a full-sized version). The borderless terminal window slides down from the top when focused, and then slides back up when not used. Never again will you need to hunt through your open windows looking for the terminal.

By mapping the visor to a hotkey, it becomes easy to quickly access a shell wherever you are without even taking your hands off the keyboard. And then, just as easily, the terminal can be dismissed. This article explains how to set up a visor-like terminal and then map a hotkey.

You can set up iTerm2 to do this in only three steps.

In years past, I used to do my development on a local machine, and then push my work to a remote server for testing. About two years ago, though, I switched my environment. I began using virtual machines instead of physical servers. Configuring them for Drupal, I could do my Drupal development locally, and then do advanced testing on my virtual machine.

In this article, I give five reasons why I believe Drupal development can be enhanced through using VMs.

I noticed recently that on one of my Debian systems, my installation of varnish did not have any of its monitoring utilities installed. /usr/local/bin was missing varnishstat, varnishtop, varnishhist, and varnishsizes.

I re-ran configure and make a couple of times. I couldn't find any errors, yet none of these programs was ever compiled.

This explains how to use a UNIX-like command line (including Linux and OS X) and the find command to search through a subdirectory and find all of the files with a certain extension, and then combine those all into one file. Surprisingly, this isn't a difficult task. It can be accomplished with one command on the command line:

$ find ./src -name '*.txt' -exec cat '{}' \; > test.txt

The above looks through everything in the ./src directory (including all subdirectories) for any files with the .txt extension. Each file it finds, it adds to test.txt. So at the end of the command's run, all of the text files will be combined together into text.txt. You can use this strategy to easily combine lots of files into one.

Using find, it's easy to customize the command above to do all kinds of things with files. I gave a few examples in an earlier post about the UNIX find command.

Often times, I want to create a full directory structure, and I'd like to do it with just one call to mkdir. That is, I want to create a root directory and multiple subdirectories all at once. Here's how to do this.

mkdir -p myProject/{src,doc,tools,db}

The above creates the top-level directory myProject, along with all of the subdirectories (myProject/src, myProject/doc, etc.). How does it work? There are two things of note about the command above:

• The -p flag: This tells mkdir to create any leading directories that do not already exist. Effectively, it makes sure that myProject gets created before creating myProject/src.
• The {} lists: The technical name for these is "brace expansion lists". Basically, the shell interprets this as a list of items that should be appended individually to the preceding path. Thus, a/{b,c} is expanded into a/b a/c.

You can nest brace expansion lists. That means you can create more complex sets of subdirectories like this:

mkdir -p myProject/{src,doc/{api,system},tools,db}

Notice that this creates two directories inside of doc/.

I have recently been working on configuring a business-class Comcast SMC router to make use of a group of 5 static IPs. The documentation I found was sparse, and I spent a few days figuring out how to do this.

Turns out that it is very simple.
Configuring the Firewall

Our current environment uses AWStats to analyze our HTTP server log files and build reports. Because it has privileged access to our data, and because it is open source, we can glean more information out of it than we could from proprietary hosted analytics platforms.

It turns out that there is a PHP front-end to AWStats (called BetterAWStats) that comes complete with a Drupal module. Here, I explain how we've installed and configured this module to get our AWStats data imported into our Atrium server.

I noticed something unexpected in my nginx logs today: There were a bunch of 499 HTTP codes in the access log. Oddly, these didn't show up in Google Analytics, there were no corresponding errors in the error log, but they did show up in my AWStats. What's the deal?nginx

The answer is pretty simple: Nginx uses 499 as the status code when the client unexpectedly terminates a connection. (Thus the client may have already received a 200 in the header, AFAIK). This is consistent with the usage of 4xx errors as indicating a client error condition.

A quick calculation showed me that the 499s accounted for only 0.2% of our total traffic. Not bad. And in fact, I sorta like the ability to see how many times clients terminated connections to my server.

Every once in a while, I have some project that requires working with one of GoDaddy's servers. By far, the biggest frustration for me when dealing with GoDaddy is getting MySQL databases uploaded. I've tried all kinds of crazy tricks, from exporting MySQL databases in "bite sized chunks" to writing SQL processors that break large imports into smaller ones.The _db_backup directory

But today I think I found the Right Solution (TM) to the problem: Use GoDaddy's database restoration tool to load a large SQL file. Basically, instead of treating this as an initial import, we treat it as a restoration from a backup file.

Here's how you do it.

In Jauary we migrated a Drupal site that routinely has 40k+ hits per day. We moved the site from servers in the Pacific Northwest to a datacenter in Virginia. As if that wasn't enough, we moved the servers from Apache to Nginx, as well. But what makes this remarkable to me is that we managed to pull this off without so much as a minute of downtime. This blog explains how we did it (and it uses lots of pretty diagrams, too!).