One SSH key to rule them all: Forward your SSH agent session in 15 seconds

Recently, I used a tool that spoke of “forwarding” my SSH session to the server and thus avoiding needing to copy my private key to the server in order to be able to access Git repositories or other servers where I log in by public key.

If you manage your keys at all, you can immediately see the allure here.

The configuration is ridiculously easy. Put this in your $HOME/.ssh/config file* (Windows users, check PuTTY settings; it can probably do this too).

Host <hostname>

ForwardAgent yes

You can, of course, combine this with other options such as HostName and User.

I tested it with Fill PDF Service:

Host fps


User myusername

ForwardAgent yes

ssh fps
cd /path/to/my/web/root
git pull

(The Git repository is password-protected, and my Git setup uses SSH for authentication by default.)

I got back: Already up to date.

I used to be prompted for my password, but that’s yesterday’s news…quite literally.

Extra tip: If no one else uses your computer, you can put ForwardAgent yes on its own line. This will forward your agent to all servers you connect to. I’m not an SSH expert, but as far as I know, ssh-agent is designed to be extremely secure. The main risk is if someone is using your computer directly, but that applies to most things. SSH Agent sessions are restricted to the current user session via environment variables (so no one can simply switch to you on a server to get access).

It blew me away how easy it is to get this going. 2013 is the year of SSH agent forwarding for me. Hope this helps!

* If the file doesn’t exist, create it. Make sure the permissions on the .ssh directory are 600 (drwx——).

Klar for å ta oppdrag i Norge! (Now open for business in Norway!)

WizOne Solutions has moved to Norway! You’ll see a slight update in the footer showing its Norwegian organization number. The official new name is Kaland Web, but we will continue being WizOne Solutions. A Norwegian version of the site is likely to show up after a while. In short: I haven’t blogged in a while, but I’m still here!

Rates on new work will generally be consistent with the Norwegian economy, so that is something to keep in mind when evaluating my services.

Looking forward to seeing how this new chapter unfolds!

Norwegian speakers only beyond this point:

Kjære norskspråkelig menneske :),

Jeg snakker norsk, så bare ta kontakt direkte på norsk hvis du har behov for tjenestene mine. Jeg kommer ikke til å skrive så mye på norsk på denne bloggen. Jeg vil heller ha en helnorsk side enn å blande språkene. På Twitter kan du sende tviter til @wizoneno eller @wizonesolutions.

Git: Rebase workflow with remotes involved

Note: I haven’t gone to great pains to make this post beginner-friendly, but if you’re in my situation, you should be able to follow along and understand the problem and how I solve it. Feedback welcome in the comments.


I’ve been trying to stick strictly to a rebase workflow in Git, rather than using git merge.

This has not been without it perils.

However, I’ve found a workflow that works for me as an individual developer using my own feature branch that I push to a remote. Do not use the following workflow for other situations unless you know what you’re doing.

“Why are you doing this?” and such

The problem: After rebasing using the mainline as a base (git rebase master) you can no longer push the rebased branch to a remote since it won’t fast-forward anymore.

Why would you push it to a remote? Because you have untracked/dirty files that need to stay that way locally. In my case, my Drupal settings.php is in the repository – don’t blame me, I don’t control the client’s internal processes – and it must stay dirty for my local site to function. Rebasing is much easier when you don’t have to worry about such files, though, so I keep a second clone of the repository that I use for rebasing.

Pushing my changes from the dirty repository works fine, naturally, since I don’t rebase there.

But once I rebase in the clean repository, how do I push those changes back to the dirty one without causing a merge?

It actually only takes a few commands, and it is pretty safe as long as everything you want to commit to your feature branch is already committed.

The good part (commands!)

This is what I do:

cd /path/to/clean/repository/clone

git pull (remember, I don’t work on this repository, so it will always fast-forward)

git checkout featurebranch

git rebase master

(fix any conflicts and complete the rebase)

git push -f origin featurebranch (this overwrites the remote with what I now have)

cd /path/to/dirty/repository/clone

git checkout master

git branch -D featurebranch (this deletes the local featurebranch branch)

git checkout featurebranch (you may have to use git checkout -b featurebranch origin/featurebranch – I don’t know what differentiates if you have to or not)

Explanation and conclusion

So basically, I’m recreating the local branch from the remote branch. Then I continue developing and rinse/repeat when I need to integrate changes from the mainline or when I’m done with my feature and want to make sure it will fast-forward into the mainline. I finally developed this workflow after finding I always had to merge my feature branch into the mainline in the end; it would never fast-forward. This is because I was running git rebase origin/featurebranch from within the feature branch, since then it would let me push. This basically defeated the purpose of rebasing since it would rebase the new commits from the mainline on top of mine. I wanted mine on top of the new mainline commits.

Hope this helps some poor soul out there who’s in the same boat I was.

VirtualBox 4.1.18: How to solve “Failed to load unit ‘HGCM’ (VERR_SSM_UNEXPECTED_DATA)”

(Update 7/18/2012: My theme cuts off the title. The full title is, “VirtualBox 4.1.18: How to solve “Failed to load unit ‘HGCM’ (VERR_SSM_UNEXPECTED_DATA)”.)

So, this is a bit of a departure from my usual type of post, but it’s still DevOps-related (an area I’m increasingly getting into), and people are probably searching for this.

My experience with this error

I had to send in my Windows laptop for warranty repair, and I was running a couple work-critical VirtualBox virtual machines (“VMs”) on it. I use Vagrant to run them without a GUI, and moving them was easy. I used vagrant package, copied over the project files, and ran vagrant up on the destination machine. This was not the issue.

I got this error when I suspended the virtual machines, then tried to resume them

So for some reason the VMs started up without issue. However, upon suspend and resume, I started getting the titular error. I searched for it on the Internet and found a VirtualBox forum which linked to a bug report which suggested editing the .vbox file. This is in <home directory>/VirtualBox VMs/<name of VM> and is named after the VM as well. It ends in .vbox.

Now, before you edit it, make sure you:

  1. Suspend or shut down all running VMs
  2. Close VirtualBox

If you don’t, this won’t work because VirtualBox will use the previous configuration anyway.

OK, so open up the .vbox file. Search for SharedFolders. You will see something like:

<SharedFolder blah blah blah />

Anywhere in the file you see that, change it simply to:


and save the file.

Now open VirtualBox and try resuming the afflicted VM again.  It should work. If it doesn’t, go check the .vbox file and make sure VirtualBox didn’t change it back. If it did…then make sure you followed the two preparatory steps above. I’m speaking from experience here. You can’t skip those.

And you’ll be good!

Update (7/17/2012): If you have several VMs that you run together, sometimes one of them will resume while the others fail with this error. If you resume that one, you may be able to subsequently resume the others. Not sure why this happens since the VM in question didn’t have any VirtualBox shared folders (not even in the XML), though some were using NFS. Perhaps it was internal-network related. Just noting this here since it happened.

My mobile office is now in the Toolbox

If you follow me on Twitter, you probably already know all this. If not, however, allow me to explain.

When I’m away from home, whether at a cafe or a Drupal event, there are a few things I take with me to ensure a pleasant working experience. You may have encountered me with them at a Drupal event. I’ve had the setup since SANDcamp 2012 and also had it with me at DrupalCamp NJ, DrupalCamp Twin Cities, and DrupalCamp Sacramento.

These tools definitely increase my productivity (hint: one is a USB-powered monitor that you can carry around!).

So, without further delay, check out my mobile office!

I’m a mentor at the free DrupalCamp Sacramento training on June 8!

I haven’t been blogging enough recently, but I will try to keep you posted with short updates at least. It’s been a busy first quarter of the year!

But I wanted to post to announce that I’m mentoring this training, which as I write is tomorrow. It’s full, so this is sure to be an interesting experience on my part.’s site is here (affiliate link).

DrupalCamp Sacramento: link (Fill PDF Service is a Bronze Sponsor).

Hope to see you there!

WizOne Solutions Winter Update

Update: I’ve also sponsored DrupalCamp NJ ( at the Silver level.

I wondered what I should call this post, and the title I picked seemed to fit. It’s been some time since I’ve written a proper blog post about my attendance to (or sponsorship of) camps. I’ve definitely tweeted about it, but the blog posts have been lagging behind. Time passes, and opportunities do too. I think I’d be beating a dead horse to try and catch up now. I’d rather just list the highlights since around July:

  1. Was an individual sponsor of DrupalCamp LA ( and attended. Presented on hooks with Oliver Seldman and subbed in for Christefano’s presentation ( Also scored a great new photo courtesy of Sawako Leslie (thanks!).
  2. Attended my first DrupalCon…in London (ahem, Croydon)! I also did an individual sponsorship for that ( and ran a couple informal discussion sessions (BOFs).
  3. Experienced Drutober with nearly back-to-back DrupalCamps.The first was the Pacific Northwest Drupal Summit. This was a pretty cool event (yeah, sponsored this also. See a trend? It was targeted more at developers, apparently, and it was really well organized. I mean really well. Everything just went so smoothly and was so professionally done. My paltry $50 (OK, $200 total) was worth every penny.

    The second camp was the Bay Area Drupal Camp, a.k.a. BADCamp. (Individual sponsorship in profile: I had to work for this one (the Coder Lounge was around 15 minutes away from the sessions), but it was worth it, and I made some new acquaintances. My session on Fill PDF also made it in at the last second ( That was surprising, but cool, and the presentation went pretty well.

    Drutober was interesting because it was the first time I went to DrupalCamps with concrete goals. I think that helped me get more out of it.

  4. SANDcamp 2012 (two sponsorships! and and DrupalCamp NJ (individual sponsor; see this page: are coming next.

So it’s been an interesting year. In the coming year, I’m hoping to polish up Fill PDF Service and make it properly rock. That’s part of the reason for trying to ramp up the marketing a bit. We’ll see how it goes!

(And I’ll try to write more.)

Drush Make: Avoid the Unexpected

There are two things that are no secret and which form the basis for this post:

  1. Using the development versions of Drupal modules is sometimes the best choice.
  2. Using development versions as the project[module_name][version] parameter in a Drush Make file is always a bad choice.

How can we reconcile these two seemingly irreconcilable truths? The answer is actually very straightforward, and it’s even documented in Drush Make’s README.txt file itself1!

I tweeted a link to this pastebin snippet the other day. Keep that open, and let’s take a closer look.

This example comes directly from a Drush Make file I actually use:

; Download the module with Git
projects[webform_userpoints][download][type] = "git"

; Find this revision by clicking View Commits on the project page
; in the lower right-hand column. Click on the most recent commit
; in the branch you were going to use. Copy and paste the full revision
; identifier.
projects[webform_userpoints][download][revision] = "25bfe11d2c6dc6480d0aabc79b1edb54dec06236"

; Tell Drush Make it's a module. This might not be necessary.
projects[webform_userpoints][type] = "module"

; You can erase or change the subdirectory. I like to separate
; my Git-downloaded modules.
projects[webform_userpoints][subdir] = "_custom"

The comments are there for explanatory purposes, of course. They explain the basics, so let’s look at the finer points. First of all, what was my thinking behind doing it this way? To answer that, take a quick look at the Webform Userpoints module and the available releases. I’ll wait.

OK, as you can see, this module only has a development release. However, I’ve also used this technique for modules where the development version had a feature (or even a bug fix) that I needed. The benefit of doing it this way instead of simply specifying the version as “1.x-dev” is that your site will never suddenly stop working after a Drush Make (or Aegir)-based deployment because of the latest development version having different code than you expect (i.e., new code). Git repository revisions are fixed points in time and code. You can rely on them not changing. This is a very good thing.

Finally, I thought I should include a screenshot of where to find the commit identifier. There are a couple places; let’s start with the one I used the first time:

Click the "View commits" link on a project to get here

That’s the View Commits page for Webform Userpoints. It’s accessible through the right sidebar. You usually want the latest one for the development version you need. Click on it, and then click here to skip ahead.

Sometimes, though, especially in actively-developed projects, you’ll find that there are so many commits that it’s impractical to find the revision that way.  In these cases, the Repository Viewer is the answer. To get there, click Repository Viewer on the project page of the module or theme with which you’re dealing, and then under the heads section, find the one that looks like the development version you wanted. This will typically be something like 6.x-1.x. Next to that, you’ll see a few links such as shortlog, log, and tree. Click log, and then click on the title of the latest commit.

With either approach, this type of page is your final destination:

Once you click a specific commit, you wind up on a page like this

The highlighted text is what you want. This will be different for you unless you’re doing this for the same revision of the same module.

Bonus developer method: Clone the repository with Git and check out the branch corresponding to the development version. Run git log and copy the full commit identifier. Stick it in the right place in the Drush Make file. You probably didn’t even need me to write all this if you’re using this method.