Skip to main content

Install or update gems behind corporate firewall or proxy server

If you work with Ruby on Windows in a corporate environment, sooner or later, you will hit an error when you are trying to install or update Gems. In my case, I simply had to set a few environment variables and I was good to go. RubyGems uses the HTTP_PROXY, HTTP_PROXY_USER and HTTP_PASS by default so if you open up a command prompt and set these as follows, it will use them to find the proxy and authenticate you to your proxy server:

set HTTP_PROXY=http://pr.oxy.ip:port
set HTTP_PROXY_USER=domain\user.name
set HTTP_PASS=sUp3rS3curepAs$w0rd

Extra points: A reader sent me a comment that this will only work when the proxy is using basic authentication. If you're having trouble using this method then you can give ntlmaps a shot. It's basically a little bit of python magic that sets up a proxy on your localhost through which you can route traffic and it will handle the authentication with your proxy server for you.

Labels:

Comments

  1. Unknown24 October 2012 at 16:43

    I normally URL encode the user and pass in HTTP_PROXY (ie http://user:pass@proxy:port) but I was having problems and found this post. Can you confirm whether to your knowledge it is HTTP_PASS or HTTP_PROXY_PASS? your snippet and post text do not agree.

    Cheers.

    ReplyDelete
  2. Ruby Flew Too26 October 2012 at 00:55

    My bad Ben - I'm using HTTP_PASS as per the code snippet. Updating the post as we speak.....

    ReplyDelete

Post a Comment

Popular posts from this blog

Getting started with Ruby on Rails 3.2 and MiniTest - a Tutorial

For fun, I thought I would start a new Ruby on Rails project and use MiniTest instead of Test::Unit. Why? Well MiniTest is Ruby 1.9s testing framework dejour, and I suspect we will see more and more new projects adopt it. It has a built in mocking framework and RSpec like contextual syntax. You can probably get away with fewer gems in your Gemfile because of that. Getting started is always the hardest part - let's jump in with a new rails project rails new tddforme --skip-test-unit Standard stuff. MiniTest sits nicely next to Test::Unit, so you can leave it in if you prefer. I've left it out just to keep things neat and tidy for now. Now we update the old Gemfile: group :development, :test do gem "minitest" end and of course, bundle it all up.....from the command line: $ bundle Note that if you start experiencing strange errors when we get in to the generators later on, make sure you read about rails not finding a JavaScript runtime . Fire up...
3 comments
Read more

Rails 3.2, MiniTest Spec and Capybara

What do you do when you love your spec testing with Capybara but you want to veer off the beaten path of Rspec and forge ahead into MiniTest waters? Follow along, and you'll have not one, but two working solutions. The setup Quickly now, let's throw together an app to test this out. I'm on rails 3.2.9. $ rails new minicap Edit the Gemfile to include a test and development block group :development, :test do gem 'capybara' gem 'database_cleaner' end Note the inclusion of database_cleaner as per the capybara documentation And bundle: $ bundle We will, of course, need something to test against, so for the sake of it, lets throw together a scaffold, migrate our database and prepare our test database all in one big lump. If you are unclear on any of this, go read the guides . $ rails g scaffold Book name:string author:string $ rake db:migrate $ rake db:test:prepare Make it minitest To make rails use minitest , we simply add a require ...
4 comments
Read more

Poor person's guide to managing Ruby versions

Understanding the guts of Ruby Version Management by rolling your own I've been tinkering with a fresh install of Ubuntu 12.10, setting up a nice clean development environment. One of the first things to do, of course, is implement some sort of Ruby version management. RVM and rbenv seem to be the clear winners in this arena, though there are a lot of tools out there that do a similar job . Writing your own version management for your Rubies isn't actually all that difficult. At it's core, we need need two things: A way to segregate the executables of the various versions A way to call the versions at will Segregating versions is trivial - working with files and folders, we can put the various versions into named directories. Actually executing our different versions is not all that difficult either. One way would be to create aliases with version numbers and explicitly call those when we want to use them. The more popular way, however, is to manipulate our PATH ...
2 comments
Read more