JumpBox Official Blog

If you are a JumpBox and Vista user you may have ran into a problem unzipping the JumpBox.  You might have seen an error that pops up a dialog that says:

There is already a file with the same name as the folder name you specified. Specify a different name.

Well, a few weeks ago we sorted this out and most of our JumpBoxes should now unzip just fine on Vista.  There are a few, however, that may still have this problem.  As it turns out, the problem isn’t with our JumpBox zip files, it is actually a bug in Vista.  Check out Microsoft Knowledge Base Article #952249 for details.

If you run into this, you can either install the hotfix provided by Microsoft or you can download a third party zip utility like the Open Source tool 7-zip.

Have Fun!

Austin

We get suggestions every day for open source applications that people would like to see turned into JumpBoxes. Until now we’ve been tracking these suggestions internally on a private Scuttle instance (of course running as a JumpBox).  Austin made an interesting suggestion last week though and we’ve decided to take a page from Chris Pirillo’s “Freedbacking” concept and expose this list in a decentralized and transparent manner.  

So, in a bit of an experiment, we’ve assembled what may be the most comprehensive list of valuable open source server applications on the planet in such a way that allows anyone to suggest, rate or view the submissions.  It uses the delicious bookmarking service and here’s how it works:

For any application that you’d like to see JumpBoxed, simply tag its main page with “newjumpbox” in delicious.  We monitor the RSS feed of that tag and the more bookmarks an app gets, the more attention we’ll pay to that project (and consequently the greater likelihood that it will be next in line to become a JumpBox). 

For now that page is seeded with over 130 candidate applications that have been suggested to us over many months. We’ve screened the ones that don’t seem appropriate so that list is the culmination of many hours of vetting and input from hundreds of avid open source fans. If there’s an app missing that you’d like to see, take a sec and bookmark it.  You’re of course welcome to continue sending us suggestions via the contact form on our site or by posting in the forums or comments on this blog, but we’ll be looking to that delicious tag as a main source of input on what apps should be converted to JumpBoxes next. 

What do you think of this experiment? How about the Freedbacking concept in general?  

And by the way I don’t know if anyone’s ever delicious’d a delicious page itself but I just did it and I think I may have briefly warped the spacetime continuum. My bad.

This is probably sacrilege to admit amongst IT professionals but I DESPISE the command line. For someone who grew up using a mouse in a GUI environment, it’s a daunting proposal to be told to SSH into a Linux machine and edit a bunch of stuff in VI.  ”CAT the file, TAIL the log, GREP it, CHOWN the permissions” - I can talk the jargon but when it comes to executing these commands to do something useful, well…  

That doesn’t mean us GUI people don’t want to use applications that run on Linux though. The fact a JumpBox lets anyone manage a linux-based application entirely via GUI is something that is hugely attractive to those of us who fear the command line.  While many of the common administration tasks are currently manageable via web-based tools, the reality is that there are still times when one needs to manually add or edit individual files within a JumpBox (ie. installing modules and themes in Wordpress or Drupal).

People of the mouse: fear not. There is a simple graphical-based way to achieve this.  The big disclaimer here though is that you can screw things up when you start editing files under the hood.  As always, before attempting something that has destructive potential, make a backup first.  Once you’ve done that, follow this quick 4-step tutorial to see how you can edit files sans command line:

1. You’ll need to enable SSH first.



2. Once you’ve done that, fire up the your graphical FTP client of choice as long as it supports SFTP.  Point it to the IP or local address of your JumpBox and make sure you’re telling it to communicate via SFTP. You can generally save time navigating by entering the initial path of “/var/data/appname.”



3. Navigate to the directory in question.



4. And now you can drag files and directories from your desktop into the JumpBox.

   

5. Editing files inside the JumpBox is just as easy. I happen to be using the ftp client for Mac called “Transmit” in this example. Some ftp clients will let you right-click the file and edit it in place via a text editor application.  If yours doesn’t have that capability, you can always just bring the file to your desktop, edit there and drag it back overwriting the original file. 

One of the undiscovered gems of the v.1.1 platform is the ability to backup and restore a JumpBox via your web browser. “How might this be useful?” you ask.  Imagine a situation where you have a JumpBox running in an environment with no network access.  Perhaps you’re: 

• hosting it on EC2 
• accessing a JumpBox that’s hosted internally in your office exposed via port-forwarding but with no network access available
• connecting via Bonjour to a JumpBox that’s running on a friend’s laptop 
• having network trouble backing up to a PC or Mac or your host computer

In any of these scenarios you may need to get a copy of the data without having filesystem access to the network in which the JumpBox is running.  With the new backup over HTTP feature it’s trivial to capture the state of your JumpBox and download it instantly via your browser.  You can also go the other direction and use the restore over HTTP feature to push changes from a local backup into a hosted instance.  And because the backup files work the same no matter which method used to create them, you can interchange methods (ie. take a backup that was automatically saved to a file share or S3 and restore via the browser).
 

Think about this: you mock up a project and proof it to a client over the phone remotely using EC2. Then take the client’s change requests, stage an empty JumpBox on your laptop, grab the backup via your browser and restore it into the local instance.  Hop on your flight and implement those changes while you’re in the air.  Show up at the client’s office with everything working on your laptop, make any last-minute tweaks and then wow them by instantly restoring into the live EC2 instance. Every configuration setting, every bit of data- completely portable and transferrable via your browser as a single unit. And if something were to get screwed up, you always have the original state to fall back upon.
 

This is just another way we’re giving you ultimate flexibility and control over your your applications.  What other creative use cases can you imagine with this feature? 

Look at your watch.

Fifteen minutes from now you could be running any of the JumpBoxes that are now available as public beta AMI’son Amazon’s EC2 service. As the least technical person in our office, I’ve known what EC2 is in the abstract sense for awhile now. Let me say it was extremely satisfying to finally fire up a JumpBox on EC2 and see how that service works first hand. I took screenshots of the entire process start to finish (which took just under 15min) in order to share here for anyone else who might be as daunted by EC2 as I was.

It should be noted that EC2 as a web hosting mechanism has some flaws (no persistent disk storage so if you’re node dies you can lose data not to mention your app can come back up under another IP address and disappear from its domain- this is not a hosting substitute for critical apps at this point). But this is a very slick way to get a public instance of a JumpBox running quickly for a non-critical application. It’s perfect for a scenario where you need to evaluate an application with a distributed team or proof a job for a remote client.

Here are the steps that I took to get the MarKamp.org wiki working yesterday:

First you’ll need to setup an account on Amazon Webservices if you don’t already have one. Go to aws.amazon.com, complete their application process and specify your payment details.

Next you have to enable the EC2 (Elastic Compute Cloud) and S3 (Simple Storage) services for your account.

Now you need to find out what your AWS credentials are.

Copy your Access Key ID and your Secret Access Key to some place where you can get them later.

I put mine in Textedit temporarily.

You’ll need to install Firefox and launch it if you’re not already using it. Go get the Elastic Fox extension from Amazon’s site.

Once you have this extension installed go to the Tools menu and launch it.

This is the main dashboard that shows you what’s available and which instances you have running. You’ll need to tell it how to access your AWS account. Click the “Credentials” icon in the upper-left.

Pick a name to refer to this account in Elastic Fox and enter those credentials that you stored in your text editor.

Now when you go back to the dashboard and click the “refresh” icon in the AMI panel, you should see every public AMI that’s available to you.

We’re only concerned about JumpBoxes so let’s filter this list by entering “jumpbox-amis” in the filter area. When you click refresh you should see the four JumpBoxes that we currently make available.

Now we need to setup a security policy that allows our JumpBox to communicate over the ports it needs. Navigate to the “Security Groups” tab. We could create a new group if we using this EC2 account for multiple projects and wanted to isolate the JumpBox-related stuff. For now we’ll just configure the default group to do what we want- click the green checkmark to add a new rule.

The three ports we need to open up are 22 (for ssh), 80 (for web) and 3000 (for the administrator). Leave everything as the default and enter the port info. We’ll need to do a rule for each port.

Go back to the “AMI’s and Instances” tab and launch whichever JumpBox you want to use by highlighting it and clicking on the “power button” icon.

It will bring up this scary-looking dialogue. If you’re using the default security group like we are you can ignore everything and click “Launch.”

Refresh the “Your Instances” panel and you should see your running EC2 instance. Grab the right edge of the Status header and drag it to the right so you can read the status.

When it’s finished booting it should turn green and switch to “Running.” Right-click on it and copy it’s public DNS name to your clipboard.

Now paste this into a web browser and you should get an SSL warning on first load- click OK.

This screen should look familiar if you’ve ever booted a JumpBox. Complete the configuration info as you normally would and click “Configure.”

It will think for a minute and give you the success screen once it’s finished. Click on the long address to access your application.

Your instance is running! It’s perfectly acceptable to use the application at this point but you may want to run it under a more friendly URL. Go back to the admin.

Click on the “Network” icon.

The public address you see is the URL you’re currently using to refer to your application. You’ll notice that it’s composed of four sets of numbers separated by dashes. Copy this segment of the sequence.

Paste it into your web browser, substitute dots for the dashes and you’ll find that this happens to be the public IP address of your JumpBox. At this point you’ll need to go to your domain registrar and change the “A Record” on the domain you wish to use to point to this IP address. If you need help with these steps search the help docs on your domain registrar for “DNS A Record.” For GoDaddy you access this by clicking on “My Domains,” choosing the domain in question and clicking “Total DNS Control.”

Come back to the hostname panel in your admin and specify the domain you wish to use as the public address.

You may need to wait a bit for DNS to propagate but you should very soon after be able to access your JumpBox in a browser under this domain.

Congratulations! You now have a public instance of your JumpBox running on EC2 under your own domain. Two things to keep in mind:
-You’ll want to make sure you configure automatic backups to S3 if you’re using it for any application where you care about the data.
-Remember EC2 bills based on usage - don’t leave town with an instance running that you forgot about or you will come back from vacation with an unpleasant bill from Amazon. It costs roughly $72/mo + minor bandwidth charges to host a site on EC2 24/7.

At this point you can do various cool things like work offline on your laptop to to add data to your application and then use the backup/restore features to inject these changes into your public EC2 instance. We’ll cover more of these techniques in future posts. For now, have fun tinkering with EC2!