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