Random thoughts, musings, and tech stuff

03 May 2013, 16:44

Share

Cloud 9 SSH Workspace issues

Recently, I decided that it would be a really cool thing to have access to a nice Cloud IDE that I could play around with. I landed on Cloud9 IDE, using an SSH workspace.

I had a bunch of issues trying to set up an SSH workspace on Cloud9 IDE, mainly due to using nvm (nodejs version manager). I started out getting these really strange hash mismatch errors. With some help from Cloud 9’s support and development teams, I was able to get it up and running.

Cloud IDEs

I checked out the options and came back with either Cloud9 IDE or Koding. Koding is pretty cool, there’s some really neat and interesting stuff that they’re doing, and as a web-app it’s very, very responsive, but it’s also very much still beta. There are just certain things that you can’t do with it at this point. Cloud 9, on the other hand, has been around for several years. I’d wanted to use it on my tablet, but due to the text editor, Ace, not working with touch screens, I wasn’t able to use it. Now, with my Chromebook Pixel, the time is right to see if I can get some use out of it.

SSH workspaces in Cloud 9

One thing that really caught my eye about Cloud 9 is that they give you one free private workspace, and they have the option of using an SSH workspace. This is perfect for me, because I have my own, quite powerful, development server that I could use. It’s awesome because I can install whatever runtimes, compilers or environments I want, use C9’s nice interface for editing files, and then use the provided terminal for running the project. You can even use tmux in that terminal, though tmux support is not great. (CTRL + b in the terminal puts you into this strange ‘File Revisions’ mode in the editor. I’m a bit concerned that certain shortcuts in the terminal might do unexpected things in the editor.)

NodeJS and nvm

Before I had started with trying to get Cloud 9 connected to my machine, I had installed nvm, since there are times when you need to have different versions of nodejs installed, as required by certain projects or certain tools. I figured nvm would be an ideal solution, because it manages all that for you, and you can install whatever version of node you feel like.

Attempting to build an SSH workspace

Initially, I when I started out with this, I figured that I could use nvm to have a few different node versions running, without causing a huge headache. There were some problems, where I had to go in and modify the output of nvm to get it to spit out the version number in the proper format for Cloud9 to read it. (I’m not going to include that config, because it ended up not helping.)

First issue - hash mismatch

I had to modify nvm.sh to print out only the version number when setting the version, so that Cloud9 could properly parse the response. Now, I’m on to the next step, of trying to create an ssh workspace, and here’s the error that I get:

I had no idea what this meant, aside from perhaps it checking the node binary or something? Regardless, Google is not being helpful here, so I fired off an email to Cloud9’s support team. They came back and suggested not using nvm, at all, and instead using a regular install of nodejs.

He also said the following:

> We don’t do any checksums over the node binaries but we do checksum the packets we send over the wire. This means two things:
>
> 1. The ssh connection was established successfully
>
> 2. Somehow the communication with the node agent running on your VM get corrupted

I think that nvm’s spitting out the 'v0.x.xx’ all the time was perhaps causing some problems.

Next issue - bad gateway

I decided to build node from source, and install it locally, since I still wanted access to nvm. When I did that, I got the following error:

The developer helping me out had suggested using either node v0.6.21 or 0.10.5, and the version that I had built was 0.11-pre. Ok, time to try something different. I belw away the 0.11 that I had built, and modified my bashrc to alias node as the binary provided by nvm:

I also set the path explicitly in Cloud9’s workspace setup as the same path:

This combination did the trick, and I was able to get my workspace set up, and start coding! (Actually, I haven’t started being productive yet, I decided to write this post first.)