I’ve been using Vagrant for a several years now and love it. One of my few complaints was that each time I wanted to create a new machine I would need to edit my /etc/hosts file. Then I found the excellent Vagrant plugin named Landrush.

My hosts file went from this: localhost broadcasthost
::1 localhost project1 project2 project4 project5 project6 project7 project8 project9

To this: localhost broadcasthost
::1 localhost

How to Install Landrush

Installing and using Landrush is really easy.

Step 1: Install the plugin

vagrant plugin install Landrush

Step 2: Add the Landrush configuration to your Vagrantfile

config.vm.hostname = "project1.vagrant.dev" # if not set yet
config.landrush.enabled = true

There are more options you can add which can be found here.

If you don’t want to use the TLD of vagrant.dev you can change it but keep it mind it will override that TLD on your computer. If you set your box’s hostname to something.google.com and set landrush.tld = google.com your searches won’t work very well unless you use Bing…nevermind, your searches still won’t work very well.

Step 3: Start up your vagrant box

vagrant up

That’s it. Landrush does everything else for you.

Test your box, project1.vagrant.dev should be pointing to the IP address of your vagrant box.


I lent my newly upgraded Roam Mobility SIM card to my sister for a 2-day trip to Michigan. I told her I would foot the bill for her service if she would report back with some speed test screen shots. We both have an iPhone 5S and I was curious to see what kind of speeds her phone would get.

I double checked the locations in Michigan where she would be staying. According to both Roam Mobility’s website and T-Mobile’s site (the network Roam Mobility is actually using), they claimed LTE service would be available to her almost all of her trip.

Here are the results:

Detroit, Michigan

iPhone 5S on Roam Mobility in Detroit, Michigan - Map iPhone 5S on Roam Mobility in Detroit, Michigan - Speed Test

Outside of Ann Arbor, Michigan

iPphone 5s Roam Mobility, Outside Ann Arbor, Michigan - Map iPhone 5s Roam Mobility, Outside Ann Arbor, Michigan - Speed Test

Ann Arbor, Michigan

iPhone 5s Roam Mobility, Ann Arbor, Michigan - Speed Test


The 3G speeds are actually great…for 3G. But Roam Mobility now supports LTE. Why is the phone showing 3G?

Ok, my sister is pretty good with technology, but she could have messed something up, right?

We started some basic troubleshooting…

Is the iPhone 5S supported? Yep

Roam Mobility LTE 4G device list

Maybe LTE is turned off? Let’s check that because maybe changing SIM cards somehow turned off LTE.

No LTE option on iPhone with Roam Mobility

But where is the LTE option? I’m pretty sure that screen should show “enable LTE” not “Enable 3G”.

I checked Roam Mobility’s support documents and found this potentially useful page: How to enable 4G LTE on your iPhone or iPad

Roam Mobility - How to enable 4G LTE on iPhone

…but I don’t have an Enable LTE switch. At the bottom of the page:

If the feature is not available on your iPhone 5/5c/5s device, we recommend that you contact Apple customer service to troubleshoot and resolve the issue.

You can do this by visiting this Apple Support Article or visit your local Apple Store or Apple Authorized retailer.

If you have any further questions with other issues, please contact our care team via email or phone so we can ensure you have a great experience with our service.

I went to the Apple Support page and asked my sister to try some of the more reasonable suggestions. (Erasing the iPhone to start fresh is NOT an acceptable troubleshooting step for getting cheap US data roaming. It is a little more reasonable if you are at home, on Wi-Fi and you are trying to get your Canadian carrier to work.)

I contacted Roam Mobility support on August 7, 2014, first by email and then, after waiting a few hours, via Twitter.

Twitter conversation - Roam Mobility no LTE option iPhone 5S

So they are trying to blame this on Apple? Come on!

There are a number of people with the same issue on Twitter and Roam Mobility’s Facebook page.

I’d be perfectly happy if they would just acknowledge the issue and say they are working on it. I’d be ecstatic if they included a timeline. But blaming Apple? That’s pretty sad.

I did finally receive a reply to my email support request, 13 days later. Did I mention my sister’s trip was 2 days? It was an automated message that contained a link to the LTE support sections on their website.


For even having the ability to use LTE on Roam Mobility’s network I was forced to pay a $1.99 fee per SIM to “upgrade” my SIM cards to support LTE. I try not to think too hard about why this is even technically necessary because it’s only $2.  I don’t actually need LTE speeds, but since I’ve paid for the privilege, I want my iPhone saying it’s connected to their LTE network!

Despite their lack of LTE, I still need data when I travel to the US and I still don’t want to pay my Canadian carriers’ horrendous rates, so I’m sticking with the lesser of two evils, Roam Mobility on 3G, at least for now.




I use Vagrant boxes for almost all of my development work. I recently came across this simple yet incredibly time-saving Vagrant tip. I use NFS to share files between my host computer and Vagrant box. While Vagrant makes this quite trivial to do Vagrant does require elevated permissions to mount the NFS share which means I need to enter my password everytime a Vagrant box starts up. This isn’t a huge deal as I only restart my Vagrant boxes a few times a week but I frequently will start up a box then go do something else while it boots and when I return later I see my box sitting at the password prompt. By adding a few lines to my /etc/sudoers file I just type vagrant up and I’m done.

1. Open up terminal. (CMD+SPACE, type in terminal)

2. Type in:
sudo visudo

3. Enter your password.

4. Add these lines to the bottom of the file.
Cmnd_Alias VAGRANT_EXPORTS_ADD = /usr/bin/tee -a /etc/exports
Cmnd_Alias VAGRANT_NFSD = /sbin/nfsd restart
Cmnd_Alias VAGRANT_EXPORTS_REMOVE = /usr/bin/sed -E -e /*/ d -ibak /etc/exports

In case you aren’t familiar with vim, press i to insert text, when done, press ESC, then : followed by wq then press enter.

Your done! Wait 5 minutes (because you just typed in your password like 30 seconds ago). Then type vagrant up from your project root and don’t enter your password.


For years now, every time I went down to the USA, I would swap out my phone’s Canadian SIM card for a prepaid AT&T SIM card. This worked pretty well, but it was not without challenges. Now I use Roam Mobility. It isn’t perfect (although it’s close) but it is much easier and more convenient than using an actual US SIM card.

What I did before Roam Mobility

While buying the US SIM card is easy enough, successfully activating it is another story. To activate you need to enter a valid US address. Most of the Canadians I know live in Canada and do not have a US address. Usually I would just use my name at the hotel I was staying at, but it’s still not ideal and I feel a little bad about the potential junk mail AT&T might start sending them when my plan expires. You can’t just make up an address either. I actually wasted a SIM card trying that. In my experience, the address must be a valid US address.

Once you have the SIM card registered, you would then have to add money to the account. If you have a US credit card, adding money to your card is simple. You can make a payment during registration or later online. Without a US credit card, I was forced to use a third party service pinzoo. You can add money directly to your phone via their website and pay with Paypal. Once you know about pinzoo, it’s not too hard, but it’s still a bit of a hassle. Also, the last time I purchased airtime it cost me $50, as that was the only plan that would meet my needs. It wasn’t a bad price for a month of voice and data service, but I only needed it for 10 days.

When your trip is over, you switch your phone’s SIM back to your Canadian one. What do you do with the US SIM card? Well, if you are planning to visit the US again soon, you may be able to reuse the SIM. But watch out: AT&T’s prepaid SIM cards expire after 90 days if no additional money is put onto the account. I’ve never reused one of my US SIM cards since I typically don’t travel to the US more than a few times per year. As soon as I put my Canadian SIM back in my phone my US one goes right in the trash. In my case, I needed a new SIM card with each trip. I would actually buy AT&T SIM cards in bulk to get a better price.

I will say that once the account and plan were activated the service had always worked great. However, as you can see, there is much room for improvement in this process as I doubt the average person could be bothered to jump through all those AT&T hoops to get a SIM.

Note: I know I could have just visited an AT&T store once I crossed the border, but I much prefer having my cell phone and data working immediately after I cross the border. Besides, I don’t want to waste precious vacation time waiting in line at the mall to buy a cell phone plan.

Roam Mobility to the rescue

Roam Mobility solves these problems wonderfully. You can register with a Canadian address and pay with a Canadian credit card. Their plans are also very reasonable. Currently, for just $3.95 a day you get unlimited US calling, unlimited calling to Canada, unlimited text messages and 300MB of data. You also don’t have to buy a month of service. You can just buy 1 day at a time. Oh, and the best part: the SIM card doesn’t expire for a whole year! To keep the SIM active, just buy a cheap talk-only $2.95 1-day plan and you are good for another year. (I have paid between $4-$7 each for an AT&T SIM card).

Roam’s SIM cards are actually pretty expensive at $19.95 (they have deals occasionally) but since they don’t expire for a year it’s not a bad investment.

The not so great stuff about Roam Mobility

The data speed could be better. Our data speeds in Canada are actually pretty decent (at least where I travel), so getting used to the mediocre 3G was a step back. I have used Roam in New York, NY and Orlando, FL with my iPhone (4S, 5, 5S). The best speed I saw (once) was in New York at about 7Mbps. Typical speeds I experienced were between 2-4Mbps. In Orlando (and Disney World), all my best speeds were between 1-3Mbps and sometimes I was forced onto EDGE. On AT&T, my speeds were consistently double that a year prior.

Roam uses T-Mobile’s network and, well, AT&T’s network is just better at the moment (especially for iPhones) so slowness is to be expected. I should point out that the internet was perfectly usable most of the time. Photos took a little longer to upload than I’m used to, but it still got the job done. I made several phone calls back to Canada and had no issues with voice quality.

Now interestingly enough, Roam Mobility has just announced they will be launching an LTE network. This should help improve speeds immensely. The mediocre data speeds are the only drawback I can see currently with the service.

Alternatives: What about “Travel Packs”?

Over the last year or two, Canadian providers have started offering US data roaming packs. In my opinion they are still WAY overpriced compared to what Roam offers. Roam Mobility’s site has a pretty good (shocking) comparison here.


Overall I highly recommend Roam Mobility for anyone with an unlocked phone traveling in the US. They provide a much needed service, freeing Canadians from their money grubbing cell phone companies.




I recently came across a scenario where both of our Couchbase servers had failed due to major failures at our hosts’ data centers. One server eventually came back up but its state was set to “pending” and our app could not connect to it. We did enable replication but when we attempted to click the “fail over” button on the bad node, the scary data loss warnings frightened us away from attempting the fail over. Eventually, the second server came back on its own and the state of both Couchbase nodes changed to “up”.

This exercise is a test to see just how easy it is to recover from a single node and all node failure (assuming the node’s hard drives are still intact).

While the Couchbase documentation does explain all of this, I found this experiment most helpful to properly understand exactly what happens when nodes go down.

Set up a test two-node Couchbase environment

If you are using CentOS 6 or RedHat these steps should work. Otherwise just follow the instructions on couchbase.com.

sudo yum update -y
sudo wget http://packages.couchbase.com/releases/2.2.0/couchbase-server-community_2.2.0_x86_64.rpm
sudo rpm --install couchbase-server-community_2.2.0_x86_64.rpm 

Make sure the server’s firewall has these TCP ports open:

11209-11211, 4369, 8091-8092, 21100-21299

Once Couchbase is installed, you can access the Couchbase admin console from your browser:


Setup Couchbase

Since this is the first node we will start a new cluster:
Couchbase create new cluster

Default settings are fine for our test.
Create default Couchbase bucket

Select the beer-sample bucket so we can have some data to check when the nodes recover. You can use your own bucket too, just make sure replication is enabled.
Import sample bucket

We don’t care about Couchbase notifications for our test servers.
Ignore Couchbase notifications

Set up a Couchbase administrator account.
Setup an admin user

First node setup is complete:
First Couchbase node is setup

Now we need to set up the second node.

Repeat the steps above to install Couchbase.

Once Couchbase is installed on the second server visit that Couchbase server’s administration console in your browser.


This time we will be joining an existing cluster. Enter the IP address of the first node and the administrator username and password you set during the setup of the first node.
Join an existing Couchbase cluster

Server should now be associated to your Couchbase cluster.
Server added to cluster

In order to actually use the new node with your cluster, the cluster needs to be rebalanced. Click “Server Nodes” from the top nav and then click the “Pending Rebalance” tab. Then click “Rebalance” to the right.
Rebalance the Couchbase cluster

Wait for the nodes to rebalance before proceeding.
Rebalancing Couchbase nodes

When rebalancing is complete your nodes should look similar to this:
Couchbase nodes are rebalanced and active.

Now it’s time to fail some nodes.

Single-node failure

First have a look at the buckets in your cluster. Note the number of items in the beer-sample bucket. You should see 7303 items (unless the sample bucket has changed since this post).
Couchbase cluster buckets

The item count is an easy way to see how much data is potentially available.

Ok, now it’s time to kill a node. Choose one of your Couchbase nodes (it doesn’t matter which one) and either shut it down or just stop the Couchbase server service.

sudo service couchbase-server stop

If you were viewing the “failed” nodes web administration console you will be disconnected and should login to the other node’s web console.

You should see one node up and one down.
Single Couchbase node failure

Now have a look at your buckets. Note that the item count is now reduced by 50%. The data is still safe because the data was replicated and evenly distributed on all nodes. We are seeing an reduced item count because half the active data is gone.
Buckets state with one node down.

To get back access to all of our data we need to make the replica data (on our remaining node) active. This is actually really easy. Just click “Fail Over” on the down node.

You will be presented with the very scary data loss warning. I’m sure in some circumstances you will lose data but not with this simple scenario.
Confirm failover

The “down” server will be added to the “pending rebalance” tab. If you rebalance now, any data not replicated across the cluster on the “down” server will be lost. If the “down” server comes back online while it is pending rebalance you will be prompted to add the server back. If you did rebalance, the server will have to be reconfigured manually to join the cluster again.

Have a look at your buckets now. Item count should be 7303 again and it should look the same as before, except you now only have 1 node.
Cluster up with 1 node

Your Couchbase cluster should now be working (but slower and without replication).

Restart the “down” node so we can do the next test.
Couchbase should automatically detect that the previously “down” server is back and it will prompt you to add it.
Add node back

Add the node back and rebalance. Once complete your cluster should be up and running with 2 nodes.
Couchbase cluster working

Two-node failure

This is the actual situation we found ourselves in last week. Both of our nodes went down at the same time. To replicate this, stop the Couchbase service on both nodes.

Node 1:

sudo service couchbase-server stop

Node 2:

sudo service couchbase-server stop

Now start the Couchbase service on one of the nodes.

sudo service couchbase-server start

Login to the web administration console for the running node. You should see something like this:
Couchbase cluster pending and down

Now look at the buckets. Yikes! Item count is 0 on beer-sample.
Cluster down, bucket item count 0

To resolve this, it’s actually the same procedure as a single node failure. The only difference is that this time no nodes are up which means none of the Couchbase data is in an active state.
Click “Fail over” on the “down” node and confirm the fail over.

Now the node that was “pending” should now be “up”.

Couchbase, up down

Have a look at the buckets which should show 7303 items.
All items available in bucket

The cluster should now be running, just without replications and slower since we only have 1 node.

Now restart the Couchbase service on the “down” node.

sudo service couchbase-server start

Add it back to the cluster and rebalance.
Add node

Your cluster should now be fully restored.
Couchbase fully restored