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.
The Coding Mant.is 