Running Cloud Foundry Locally with BOSH Lite

Want to play with Cloud Foundry without using TryCF (requires AWS) or setting up a trial account with one of the PaaS providers out there (e.g. PWS)? Why not set it up on your own laptop?

Getting Started

The 411 on my laptop:

• 2012 Retina Macbook Pro
• 16 GB RAM
• 768 GB SSD
• 2.7 GHz i7 processor
• Mac OS 10.10.1

FYI: I have already installed the CF CLI tools on my laptop, so although I will explain how to install the CF CLI tools I will not be installing it again at this time.

It’s worth mentioning that I did also try running Cloud Foundry on a different Macbook with 8 GB of RAM with limited success. So for the RAM at least I would recommend having 16 GB+. This will provide enough memory for Cloud Foundry to run more comfortably alongside the system processes.

Ruby, Go, Vagrant, and VirtualBox

Make sure that you have:

• the latest stable release of Go
• the latest stable release of Ruby
  • Optional: RVM
    Not directly required for Cloud Foundry, but this will come in handy if you need to install/manage more than one version of Ruby.
• the latest release of Vagrant
• the latest release of VirtualBox

Before proceeding, check the installed versions using go version, rvm list (or ruby --version if you do not have RVM), vagrant --version, and vboxmanage --version. I am currently running the latest stable releases for all the above, in addition to version 1.9.3 for Ruby.

$ go version
go version go1.3.3 darwin/amd64

$ rvm list

rvm rubies

   ruby-1.9.3-p551 [ x86_64 ]
=* ruby-2.1.5 [ x86_64 ]

# => - current
# =* - current && default
#  * - default

$ vagrant --version
Vagrant 1.6.5

$ vboxmanage --version
4.3.18r96516

Installing BOSH Lite

In order to run Cloud Foundry you must first install BOSH. To provide some basic familiarity, there are three “types” of BOSH (if you will):

• microBOSH
• BOSH
• BOSH Lite

BOSH is used to deploy Cloud Foundry and microBOSH is used to deploy BOSH. BOSH Lite is used for local instances of Cloud Foundry – for example on a laptop like I’m doing.

The instructions for installing BOSH Lite are available on the BOSH Lite README. I followed the instructions for Vagrant and VirtualBox.

BOSH Lite install failure: nokogiri

When I first tried to install BOSH Lite with gem install bosh_cli the installation failed because it needed nokogiri:

...
Fetching: nokogiri-1.6.5.gem (100%)
Building native extensions.  This could take a while...
ERROR:  Error installing bosh_cli:
  ERROR: Failed to build gem native extension.
...

I had actually run into this issue before, on another Macbook running OS 10.9.x. I was only able to install nokogiri using the Xcode CLI tools:

$ xcode-select --install
xcode-select: note: install requested for command line developer tools

$ gem install nokogiri -- --with-xml2-include=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/libxml2
Building native extensions with: '--with-xml2-include=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/libxml2'
This could take a while...
Successfully installed nokogiri-1.6.5
Parsing documentation for nokogiri-1.6.5
Installing ri documentation for nokogiri-1.6.5
Done installing documentation for nokogiri after 3 seconds
1 gem installed

(The Xcode CLI tools install will pop up a software agreement via the App Store that you must agree to in order to install the software. The installation/updates for the Xcode CLI tools will subsequently be handled in the App Store.)

Once nokogiri was installed, I was able to install the BOSH CLI tools without difficulty.

The first time you start the VM, Vagrant will use the Vagrantfile in the BOSH Lite directory to install/create the VM. You should see something similar to the following:

$ vagrant up --provider=virtualbox
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Box 'cloudfoundry/bosh-lite' could not be found. Attempting to find and install...
    default: Box Provider: virtualbox
    default: Box Version: 388
==> default: Loading metadata for box 'cloudfoundry/bosh-lite'
    default: URL: https://vagrantcloud.com/cloudfoundry/bosh-lite
==> default: Adding box 'cloudfoundry/bosh-lite' (v388) for provider: virtualbox
    default: Downloading: https://vagrantcloud.com/cloudfoundry/boxes/bosh-lite/versions/388/providers/virtualbox.box
==> default: Successfully added box 'cloudfoundry/bosh-lite' (v388) for 'virtualbox'!
==> default: Importing base box 'cloudfoundry/bosh-lite'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'cloudfoundry/bosh-lite' is up to date...
==> default: Setting the name of the VM: bosh-lite_default_1418694875085_89186
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
    default: Adapter 2: hostonly
==> default: Forwarding ports...
    default: 22 => 2222 (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Warning: Connection timeout. Retrying...
==> default: Machine booted and ready!
==> default: Checking for guest additions in VM...
==> default: Setting hostname...
==> default: Configuring and enabling network interfaces...
==> default: Mounting shared folders...
    default: /vagrant => /Users/quinn/Development/BOSHlite/bosh-lite

You should then be able to target the BOSH Lite director and update your routing table:

$ bosh target 192.168.50.4 lite
Target set to `Bosh Lite Director'
Your username: admin
Enter password: *****
Logged in as `admin'

$ bin/add-route
Adding the following route entry to your local route table to enable direct warden container access. Your sudo password may be required.
  - net 10.244.0.0/19 via 192.168.50.4
Password:
add net 10.244.0.0: gateway 192.168.50.4

Note: when I did this install on another laptop running OS 10.9.x, I ran into an issue where the route script could not run and terminated with the error route: command not found. Turns out, somehow my PATH variable had become foobar-ed (technical term) at some point. Fixing my PATH variable resolved the issue.

Deploying Cloud Foundry

Now we’re going to hop over to the Cloud Foundry install instructions. Using the install script:

• Install spiff (requires Homebrew)
• Clone the cf-release repo
• Run ./bin/provision_cf

Install script failure: timeout

The only real issue I encountered during the installation is that when I ran the script, I encountered the following error a few times (which halted the install):

Blobstore error: Failed to fetch object, underlying error: #<HTTPClient::ReceiveTimeoutError: execution expired>

After a quick search I found that people just restarted the install and it would complete. The install does not redownload packages that have already been downloaded, it just flags that there are already local copies until it gets to the packages it hasn’t downloaded yet.

For reference, I had to run the script a total of three times before all the packages were downloaded successfully. I did not encounter any other issues with my installation.

Installing the CF CLI tools

Personally, I installed the CF CLI tools using the latest binary installer (linked on the README). Currently the development team is also experimenting with a Homebrew install, but that is still in the experimental phase at the time of this writing.

As a quick verification that the CLI tools are installed correctly, try checking the version. You should see something similar to the following:

$ cf --version
cf version 6.7.0-c38c991-2014-11-12T01:45:23+00:00

Creating the initial Org and Space

Targeting the API and logging in is the same procedure that you would use with a PaaS provider (e.g. PWS) or TryCF (requires AWS):

$ cf api --skip-ssl-validation https://api.10.244.0.34.xip.io 
Setting api endpoint to https://api.10.244.0.34.xip.io...
OK


API endpoint:   https://api.10.244.0.34.xip.io (API version: 2.18.0)
Not logged in. Use 'cf login' to log in.

$ cf login
API endpoint: https://api.10.244.0.34.xip.io

Email> admin

Password>
Authenticating...
OK

Select an org (or press enter to skip):

Org>



API endpoint:   https://api.10.244.0.34.xip.io (API version: 2.18.0)
User:           admin
No org or space targeted, use 'cf target -o ORG -s SPACE'

At first you won’t have any orgs (or spaces):

$ cf orgs
Getting orgs as admin...

name
No orgs found

This is different from service providers like PWS and TryCF, both of which have an org and a development space when they are created. Although orgs and spaces will be discussed in greater detail separately, please go ahead and create an org and at least one space. Follow the output suggestions to target the org and space.

$ cf create-org quinn
Creating org quinn as admin...
OK
TIP: Use 'cf target -o quinn' to target new org

$ cf target -o quinn
API endpoint:   https://api.10.244.0.34.xip.io (API version: 2.18.0)
User:           admin
Org:            quinn
Space:          No space targeted, use 'cf target -s SPACE'

$ cf create-space development
Creating space development in org quinn as admin...
OK
Assigning role SpaceManager to user admin in org quinn / space development as admin...
OK
Assigning role SpaceDeveloper to user admin in org quinn / space development as admin...
OK
TIP: Use 'cf target -o quinn -s development' to target new space

$ cf target -o quinn -s development
API endpoint:   https://api.10.244.0.34.xip.io (API version: 2.18.0)
User:           admin
Org:            quinn
Space:          development

[From my work blog entry here.]

And now… BOSH Lite (and Cloud Foundry)

After successfully running the routes script it was finally time to get to starting up vagrant – then onto BOSH Lite and Cloud Foundry.

Since both AWS and VMWare Fusion would need to be purchased for their options to work, I choose the free option (Virtual Box). To make sure that the Virtual Box option was the only option ever executed, I went into the Vagrantfile and commented out the VMWare Fusion portion of the file – leaving only Virtual Box.

Note: Vagrantfiles do not support multiline comments, so you have to comment unwanted lines out one at a time using #.

This means that for my setup, the following two lines are the same:

> vagrant up –provider virtualbox

> vagrant up

I suppose you could argue it’s not really necessary, but I don’t want to specify virtualbox every time when it’s the only provider I intend to use.

So to sync up with the directions I’m following on the repo page, thus far I have:

• Installed vagrant
• Created and booted the VM (with the “Using the Virtualbox Provider”) instructions
• Skipped restarting the director, as that wasn’t necessary in my page

So now I’m at the Stemcell portion. I worked on this with someone and, thank goodness, because this part actually went quite quickly.

My initial assumption was that I needed to get the stemcell while logged into the VM (the instructions use the wget command, which is usually indicative of Linux, and this setup is configured to use Ubuntu in the Vagrant VM); however, apparently this is incorrect: the wget is executed in terminal before you go into the VM (using some variable of “vagrant up” as needed).

Since I don’t have wget installed on my Mac, I grab the command using brew. Thankfully, unlike what happened with nokogiri, brew did not laugh in my face this time:

> brew install wget
[Bunch of output.]
> wget http://bosh-jenkins-gems-warden.s3.amazonaws.com/stemcells/latest-bosh-stemcell-warden.tgz
[Bunch more ouput.]
> bosh upload stemcell latest-bosh-stemcell-warden.tgz
[Output for a successful install]

Success! After completing all of that, I decide that I would try getting the stemcell through their other method, the public stemcells. To see the current listing:

> bosh public stemcells

Although the directions indicate that I should be looking for bosh-stemcell-24-warden-boshlite-ubuntu.tgz, I’m reasonably certain this is an older version. That said, I don’t see anything remotely similar in the output. So I try it anyway:

> bosh download public stemcell bosh-stemcell-24-warden-boshlite-ubuntu.tgz
‘bosh-stemcell-24-warden-boshlite-ubuntu.tgz’ not found.

Well… no surprises there I suppose. My mentor suggests that I look at the Bosh Artifacts page in case the output was truncated in some way. Unfortunately, there’s nothing of the format bosh-stemcell-<##>-warden-boshlite-ubuntu.tgz there either. Or anything that even says warden at all.

To see my current stemcell version, I enter the following:

bosh stemcells

Right now, I’m on version 60, so I tried this:

bosh download public stemcell bosh-stemcell-60-warden-boshlite-ubuntu.tgz

And…. this also failed (for the same reason). I think it’s safe to say that the second method they show on the instructions is no longer available, alas.

Although, I think I prefer the first method anyway. The second requires actually figuring out the current version and then manually putting that in, whereas the former method just grabs the latest release of that type.

Cloud Foundry

I have finally hit what all of this set up is for: to run Cloud Foundry locally. There appear to be two sets of instructions. One that I can actually read and the next that my Twitter-generation brain checks out of a little bit. Let’s try the “easy” one liner first and see if that will run without heartache:

./scripts/provision_cf
[Whole bunch of output that looks good]
./scripts/provision_cf: line 32: cd: /Users/ladyivangrey/Development/cf-release: No such file or directory

Ah, damn it. That’s what I get for being hopeful.

Let’s try it the manual way.

Wait a minute, looks like I need to start by cloning the CF repo. Well, maybe there’s hope for the script after all!

> git clone https://github.com/cloudfoundry/cf-release
> cd ~/cf-release
> ./update
[Shit ton of output, this may take a few minutes depending on your connection.]

My only complaint with the update is, while tons of information was filling my screen, there was no way to track how far the update had actually progressed. I mean, sure, it told me what it was doing at each second, but  not (e.g.) if it was on step 7/10 or 7/100,000. This is important information!

Anyway, once all that finished I did see a nice “CF Release has been updated” message, and there weren’t any errors, so I think I should just count my blessings.

According to the cf release page, the latest release as of this writing is 173, so:

> git checkout v173
> bosh upload release releases/cf-173.yml

It may come as no surprise, but that last one is another one of those “go get a cup of coffee” commands.

Since I’m still waiting on it ~20 minutes later, I’d like to humbly suggest you may want to get dinner while you wait as well.

Now that all of that is taken care of, I will try to provision_cf again:

> ./scripts/provision_cf
[Whole bunch of output that looks good]
./scripts/provision_cf: line 32: cd: /Users/ladyivangrey/Development/cf-release: No such file or directory

Of course. Ok, spiff it is.

> brew tap xoebus/homebrew-cloudfoundry
> brew install spiff

Now if I just run “spiff” it gives me the help output – how to use the application. Good! Progress… now:

> ./scripts/make_manifest_spiff
Cannot find cf-release at /Users/ladyivangrey/workspace/cf-release; override with $CF_RELEASE_DIR variable

Right on… simple text edit (FYI: my directory is /Users/ladyivangrey/Development/bosh-lite/cf-release), so the message makes sense). And again:

> ./scripts/make_manifest_spiff

Good! Successful execution (I’ve stopped putting bracketed output placeholders for now).

Now for bosh deploy:

> bosh deploy

This is going to take awhile… meal break!

Annnnnd we’re back. Since I already have Go, I could head straight to the acceptance tests:

> go get github.com/cloudfoundry/cf-acceptance-tests
> cd $GOPATH/src/github.com/cloudfoundry/cf-acceptance-tests

Although I have successfully set that up, I don’t really have anything to test yet, so I’m going to finish actually running the tests at this point. I think it is now time for me to actually progress to using the software so I can get started on the tasks that this was all for!

Thank goodness.

Adding Routes on Mac OS 10.9.x

While working with the BOSH-lite set up, I found I could not add routes. Specifically, this happened:

> vagrant up
> bosh target 192.168.50.4 lite
Your username: [admin username]
Your password: [admin password]
> scripts/add-route
Adding the following route entry to your local route table to enable direct warden container access. Your sudo password may be required.
Password: [sudo password]

sudo: route: command not found

First step to figuring out what is going on: figuring out what the add-route script is trying to execute. So I go less’ed the file and saw this:

#!/bin/bash

echo “Adding the following route entry to your local route table to enable direct warden container access. Your sudo password may be required.”

echo ”  – net 10.244.0.0/19 via 192.168.50.4″

if [ `uname` = “Darwin” ]; then
sudo route delete -net 10.244.0.0/19 192.168.50.4 > /dev/null 2>&1
sudo route add -net 10.244.0.0/19 192.168.50.4
elif [ `uname` = “Linux” ]; then
sudo route add -net 10.244.0.0/19 gw 192.168.50.4
fi

Next step: simply execute the Mac lines myself:

> sudo route delete -net 10.244.0.0/19 192.168.50.4 > /dev/null 2>&1
> sudo route add -net 10.244.0.0/19 192.168.50.4
sudo: route: command not found

Ok. So, specifically the problem appears to be “route add”. Quick sanity check: what is the syntax for route add in Mac OS 10.9? Well, according to at least one source the syntax is slightly different. In the add-route file the syntax for the Mac and Linux commands is the same for this line… I wonder if that’s the issue?

> sudo route -n add -net 10.244.0.0/19 192.168.50.4
sudo: route: command not found

Great.

Fishing for more information, or at least more helpful error messages, I tried this:

> sudo which route
> sudo which ip

You may notice I did not include any output above – because there wasn’t any. Not even an error message. On the bright side: there wasn’t an error message! On the downside: there wasn’t an error message…

Next try: figuring out what parameters are actually being used with the route command. According to the man file, the following syntax is valid:

route [-n] command [-net | -host] [-ifscope boundif] destination gateway [netmask]

Well, I need to add (add) the route and I need it to be interpreted as a network (-net), but I don’t necessarily need to “bypass attempts to print host and network names … when reporting actions”. Unfortunately, dropping “-n” does not affect the result.

After some additional research, I come across netstat. Thinking it couldn’t hurt to view the routing tables, I view the man page and discover I need to use the -r option:

> netstat -r
-bash: netstat: command not found
> sudo netstat -r
sudo: netstat: command not found

Clearly terminal does NOT love me today. It actually hurts my feelings a little bit as I have given terminal nothing but love since … forever, really. It must still be angry after the whole bundler/nokogiri thing yesterday… maybe I should send flowers.

After surfing googling for a bit longer, I came across some interesting advice: check your PATH variable.

My first thought: why would anything be wrong with my PATH variable? I’ve always treated it nicely.

My second thought: my Air has the moods of a cat and would probably seek retribution at the smallest slight. See yesterday’s entry.

Wouldn’t you know: I view the PATH variable and although there are various bin/sbin paths in there, I do NOT actually see the path to where these commands actually are.

Well, damn it.

> export PATH=$PATH:/sbin
> sudo route -n add -net 10.244.0.0/19 192.168.50.4
add net 10.244.0.0: gateway 192.168.50.4
> sudo which route
/sbin/route

Success! Maybe? After having issues with netstat, I decided to test that out again. I know I’ll be needing those tools at some point in the project, so it’s probably good to have them all working… right?

> netstat -i
-bash: netstat: command not found

> sudo lsof -i :8080
sudo: lsof: command not found

Awesome. Clearly I am missing more than just sbin. Mhm. Maybe chocolates and flowers…

Of course, as with all things, wherever a problem has been encountered, it is highly likely that someone else has had the same problem (or at least a similar one). It’s probably best if I see what is in the default PATH rather than picking through what I do and do not have (between ruby, Go, and misc. projects my PATH variable has gotten a tad bulky). According to a user on Stack Overflow, this is what their (virgin?) PATH variable looks like:

> echo $PATH
/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin

So I’m just going to add ALL these things:

> export PATH = $PATH:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin

Now to see if the two missing commands are back:

> netstat -i
[Whole bunch of output]
> lsof -i :8080
[No output, but no error]
> lsof -i -u ladyivangrey
[Whole shit ton of output]

I have my missing commands again! Booyah! \o/

Disclaimer: Using the export method is temporary in the sense that it will only change the PATH variable for the current session. If you close/re-open terminal (or iTerm, whatever your app of choice is), the changes will not be there. I will post about permanent changes to the PATH variable at a different time.

RubyGems, Bundler, and Nokogiri

As a part of my latest project, I need to install BOSH-lite (the link to the git repo is in the right navbar).

You would think this would be mostly straightforward, but it was in fact a little painful due to gemhell that I endured. To help save others I am documenting the exact process that I used.

First, after scanning the ReadMe, I saw I’d need Vagrant and Bundler. Thankfully, I have both of those things.

I have my dev-tool-type-stuff in a directory called Development, so I went into the Development directory:

> cd ~/Development

Then I looked at step 3: Clone the repo and run bundler. Cloning the repo was trivial enough:

> git clone https://github.com/cloudfoundry/bosh-lite.git
> cd bosh-lite/

Then came bundler. Ah, god damn it:

> bundle
Your Ruby version is 2.0.0, but your Gemfile specified 1.9.3

Ok, I guess I’ll just use rvm to install the appropriate version. Right? Ok, let’s see what I have going on right now.

> rvm
Warning! PATH is not properly set up, 
'/Users/ladyivangrey/.rvm/gems/ruby-2.0.0-p247/bin' 
is not at first place, usually this is caused by 
shell initialization files - check them for 'PATH=...' 
entries, ...
[whole bunch more text...]

After some scrolling I see that, in addition to the PATH message, I’m not on the latest version of RVM. No problem. I’ll just install the latest then:

> curl -L https://get.rvm.io | bash -s stable --autolibs=enabled

Pretty painless, right? Before I do anything, let’s make sure the install was sucessful…

> rvm -h
A RVM version 1.25.27 (stable) is installed yet 1.25.20 (master) is loaded.
Please do one of the following:
* 'rvm reload'
[More text...]

So I reload RVM. That was painless. The PATH message stays because, well, it isn’t at first place and I don’t feel like changing that right now. (It ends up not mattering.) Ok. Now I can switch to 1.9.3!

> rvm use 1.9.3
ruby-1.9.3-p547 is not installed.
To install do: 'rvm install ruby-1.9.3-p547'

Of course it’s not installed. What was I thinking…

> rvm install ruby-1.9.3-p547
Searching for binary rubies, this might take some time.
[Some text...]
Installing requirements for osx.
Updating system.......
Error running 'requirements_osx_brew_update_system ruby-1.9.3-p547', 
showing last 15 lines of 
/Users/ladyivangrey/.rvm/log/1403205414_ruby-1.9.3-p547/update_system.log
[More text...]
...make sure `brew update` works before continuing.

Ok. I entered brew update, and brew update did in fact work. And I was on the latest version. So I just tried again. Still failed, new error:

> rvm install ruby-1.9.3-p547
Searching for binary rubies, this might take some time.
[Some text...]
Error running 'requirements_osx_brew_libs_install automake gcc46 
libyaml readline openssl' ...
[More text...]
Try `brew tap --repair` and make sure `brew doctor` looks reasonable.
[etc.]

Alright then. I guess that’s a little more helpful.

> brew tap --repair
Pruned 0 dead formulae
Tapped 145 formulae

Looking good… Next I ran brew doctor. The output was much more lengthy, but not entirely unexpected – it had some standard system stuff and some other stuff from a recent installation of R/RStudio. Amongst the warning messages was one stating that I had MacPorts installed and that it could be causing trouble.

Interestingly, I had actually installed MacPorts a few weeks ago in a failed attempt to install nokogiri for an unrelated Ruby project. This will be relevant later. Not that I know that, mind you. For now, I remove it.

It’s worth mentioning that after removing MacPorts, I was able to install Ruby 1.9.3 (with a message informing me that it is no longer maintained as of Feb 2014). I was able to successfully switch to 1.9.3. Now all I have to do is run bundle, right?

> rvm use 1.9.3
> bundle

Ahahaha I am so naive.

An error occurred while installing nokogiri (1.6.2.1), and 
Bundler cannot continue. Make sure that `gem install nokogiri -v '1.6.2.1'` 
succeeds before bundling.

I see nokogiri and feel flashbacks involving pain and dependencies.

You see, back a few weeks ago I had tried installing nokogiri for a different project. I tried using the instructions for Home Brew (v0.9.5), since I already had it installed, to no avail. Then I installed and tried Mac Ports. Also to no avail. It’s worth mentioning that I was never actually able to install nokogiri, I just looped around in dependency hell for a couple hours before finding a way to not need it. Which is why I’m in this mess now (again). First I try the direct approach:

> gem install nokogiri -v '1.6.2.1'
[Some text...]
libiconv is missing.  please visit
http://nokogiri.org/tutorials/installing_nokogiri.html
for help with installing dependencies.
[^ this is the same issue I had before, of course...]
[...more text...]

I don’t really feel like re-installing MacPorts. Partly because I literally just removed it and haven’t needed it since the previous nokogiri debacle, and partly because I didn’t even get nokogiri successfully installed last time anyway. So I decide to plow ahead pulling up same instructions as last time. The results were the same (surprise?):

> brew install libxml2 libxslt
brew: Right on.
> brew link libxml2 libxslt
brew: LOL
> brew link --force libxml2 libxslt
brew: ROFL
> sudo brew link libxml2 libxslt
brew: ROTFLMAO
> fuck you brew
-bash: fuck: command not found

Ok. It didn’t really go like that. But I was frustrated. It installed libxml2 & libxslt, which is needed per the nokogiri installation instructions, but when I tried to link them I received a message that I needed to use –force. So I tried that, still apparently naive in thinking that these damn outputs will actually help me. That time I received a permissions error, so I figured I’d try sudo, but I just got this:

Error: Cowardly refusing to `sudo brew link`
You can use brew with sudo, but only if the brew executable is owned by root.
However, this is both not recommended and completely unsupported so do so 
at your own risk.

Then came Google. I searched around to see who had successfully managed to get nokogiri on a system running OS 10.9.x (disclosure: I currently have 10.9.3). Some had success installing just libiconv, but that didn’t work for me because I apparently don’t have apple-gcc42.

F.
M.
L.

Not having learned my lesson yet, I try installing apple-gcc42. Which of course fails.

So I decided to try a new approach. Again.

Then after much more googling, I found someone who happened to do the install with Xcode. I already have the latest version of Xcode on my machine (v5.1.1 as of the time of this writing), so I figured why not?

(What is this I’m feeling… is it… hope?)

> gem install nokogiri -- --with-xml2-include=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/libxml2
[Some text...]
ERROR:  Error installing nokogiri:
ERROR: Failed to build gem native extension.
[More text...]
libiconv is missing.  please visit 
http://nokogiri.org/tutorials/installing_nokogiri.html for 
help with installing dependencies.
[Additional text...]

Nope. Just sweat, shame, and tears. God damn it nokogiri, why must you do this to me. What did I ever do to you?

It is around this point that I decide that everyone involved with bundler, rubygems, and nokogiri should be forced to eat salad. This may not make a lot of sense, but I happen to despise salad (while simultaneously enjoying an otherwise wide variety of produce, just not leafy greens).

Upon further investigation, someone on Stack Overflow mentioned that the above worked, but only after they ran xcode-select –install. So hey, what the hell. Let’s give that a go to:

> xcode-select --install
[No errors - but there is a pop up to accept a licensing agreement/Apple TOS]
> gem install nokogiri -- --with-xml2-include=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/libxml2
[Some text... no errors...]
[...Maybe this is hope?]
Successfully installed nokogiri-1.6.2.1
Installing ri documentation for nokogiri-1.6.2.1
1 gem installed

Holy. shit.

It installed.

IT INSTALLED!

IT INSTALLED!

So now I try bundle again, and bundle runs without complaint.

I never knew I could experience happiness and Ruby dependencies at the same time. This is a foreign experience. Perhaps… perhaps a repeatable one.

Haha nah. We’ll see what happens the next time I involve myself with Ruby before I make that call.

The rest of the vagrant stuff will hopefully go through without a hitch so I can work on figuring out how to use bosh-lite.

Update 6/20: I never learn.

Summary – How I installed Nokogiri on OS 10.9.x

Since there’s a lot of pain going on up there, I figured it may be helpful to separate out how exactly I was finally able to install nokogiri on OS 10.9.x.

1. Make sure you have Xcode installed
   Note: This can be done in the AppStore. As of right now I have 5.1.1, so I can’t vouch for the effectiveness of other versions.
2. Enter the following in terminal:

   xcode-select --install

3. Accept/Agree with the Licensing agreement/TOS that pops up (unless you don’t want to install the tools of course).
   Note: This will be a pop up, it is not in the command line.
4. Enter the following in terminal:

   gem install nokogiri -- --with-xml2-include=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/libxml2

Hope someone finds this useful :)

Update 12/15/2014: I also had success installing nokogiri using the above method on OS 10.10.1