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.
Utolsó kommentek