/dev/random

A new proxy has been set up at my workplace and 'sudo apt-get' always fails. I have set up the proper environment variable but that did not help.

I was just about posting a question to Superuser.com when it striked me that I use 'sudo'. That means it won't be my regular user that runs 'apt-get' therefore all environment variables are lost at the point of execution.

Switched to root, set up environment variable, and issue 'apt-get', and tadaaa, problem solved. It was time to set up the proxy env variable temporarily for root.

Our company has moved, and we got a spectacular proxy installed at the new place, causing some chaos. Not only I had to reconfigure my Windows, I spent 2 hours to figure out how to use that proxy from a VirtualBoxed Debian. I had to supply my username and password on a command line to 'curl' or 'wget', that's for security. Setting system-wide proxy in $HTTP_PROXY env variable, also with my user/pass.

My first 'gem install' failed as it did not use the proxy. Configured it with the --http-proxy argument, it finally worked well.

Then I got home, no proxies, no whatever, just working network. A 'gem update' and a 'gem update --system' ran without error, but the next 'gem install'-s failed with a magic error:

> gem install redcarpet
WARNING:  Error fetching data: SocketError: getaddrinfo: Name or service
not known (http://rubygems.org/latest_specs.4.8.gz)
ERROR:  Could not find a valid gem 'redcarpet' (>= 0) in any repository
ERROR:  Possible alternatives: redcarpet

WTH? Gem install fails for a gem and immediately suggests the same gem?

Checked for proxy, none. Environment variable, none, there was no proxy set anywhere. Then I accidentally checkhed the 'gem install' doc:

-p, --[no-]http-proxy [URL]      Use HTTP proxy for remote operations

Err, why would it have a [no] prefix? If I don't want to use a proxy, I simply don't set it, right? Not right. Gem install remembers that I was using a proxy and tries to use it in subsequent requests.

Setting --no-http-proxy solved the problem.

Lesson learned: 'gem install' remembers if it was once run with --http-proxy parameter. Subsequent 'gem install' will use the same proxy regardless its availability.