CODEWITHSUNDEEP
rubygemsdebian-jessie
mrturtle
mrturtle

Reputation: 659

gem cannot access rubygems.org

I have a server with Rackspace that I use for a few Ruby sites. When I try bundle install on a new site I get

Retrying download gem from http://rubygems.org/ due to error (2/4): Gem::RemoteFetcher::UnknownHostError timed out (http://rubygems.org/gems/rake-12.3.1.gem)

Or trying gem update --system I get

ERROR:  While executing gem ... (Gem::RemoteFetcher::UnknownHostError)
timed out (http://api.rubygems.org/specs.4.8.gz)

What I have tried:

What I haven't tried:

I was finally (just before submitting this) able to get bundle install to work by removing rubygems.org as a source and adding https://gems.ruby-china.org/. Why would gem be unable to access rubygems.org?

Upvotes: 52

Views: 24946

Answers (9)

deivid
deivid

Reputation: 5268

For everybody experiencing this issue, as of rubygems 3.2.11, we're now shipping an opt-in fix for this issue inside rubygems.

If you're having this issue, you first need to upgrade rubygems to at least 3.2.11. Normally you do that by running gem update --system, but it's likely that you run into this same issue when running that command. If that's the case, you can upgrade rubygems manually following these instructions: https://bundler.io/v2.2/guides/rubygems_tls_ssl_troubleshooting_guide.html#updating-rubygems.

Once you have upgraded, put

:ipv4_fallback_enabled: true

inside your ~/.gemrc file and rubygems should no longer timeout.

The reason we haven't yet enabled this by default is that this required monkeypatching core ruby classes, so we wanted to get the fix battle tested a bit first. And also, because the underlying issue is a problem in ruby which currently lacks a happy eyeballs implementation, but it is currently being worked on, so we might not need to enable our monkeypatches by default at all if this fix in ruby lands soon.

For reference, the fix landed to our repo here: https://github.com/rubygems/rubygems/pull/2662, and the ruby issue is being worked on here: https://github.com/ruby/ruby/pull/4038.

EDIT: Happy Eyeballs support landed into Ruby's main branch in https://github.com/ruby/ruby/pull/9374. So no workarounds should be necessary once Ruby 3.4 is released (December, the 25th, 2024).

EDIT2: Actually, there's one more piece still missing for this to be fixed: https://github.com/ruby/ruby/pull/11653. But I still hope it will land in time for Ruby 3.4.

EDIT3: Happy Eyeballs did land in time for Ruby 3.4, but it will be disabled by default. So further changes will be necessary in RubyGems to actually use it in Ruby 3.4.

Upvotes: 27

Raz Luvaton
Raz Luvaton

Reputation: 3790

TL;DR created a script for MacOS that temporarily disabled IPv6 while running bundle install

Github gist with the script

This is a zx script that fix bundle install

How to run:

The bundle-install file should be without extension (but not required) added the extension to make GitHub syntax highlighting work

So from now we just gonna use bundle-install instead of bundle-install.mjs

  1. npm i -g zx
  2. Copy the bundle-install to where you want (preferably somewhere that is globally accessible - in PATH)
  3. Run chmod u+x ./bundle-install adding execution permission to the script
  4. Run bundle-install where you want to run bundle install (if you did not add the file to somewhere that is globally accessible, you will need to run using ./bundle-install)

How does this script fix it?

  1. It will get all network interfaces that have IPv6 set as Automatic
  2. Disable them
  3. Run bundle install
  4. Revert the changed network interfaces IPv6 to Automatic

Upvotes: 2

Dipen Chauhan
Dipen Chauhan

Reputation: 109

I had the same issue on Ubuntu 20.04 as of Nov 11 2020. I disabled ipv6 and it started working for me. Here are the commands to disable ipv6:

    sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1
    sudo sysctl -w net.ipv6.conf.default.disable_ipv6=1
    sudo sysctl -w net.ipv6.conf.lo.disable_ipv6=1

Upvotes: 2

Benedikt Schnatterbeck
Benedikt Schnatterbeck

Reputation: 83

I still had the same issue as well. A combination of the above worked for me so thank you all. Here is what worked for me (I'm on Linux):

In the terminal enter:

dig AAAA api.rubygems.org

Find the following:

;; ANSWER SECTION:
api.rubygems.org.   60  IN  CNAME   rubygems.org.
rubygems.org.        0  IN  A   151.101.192.70

copy the IP (in my case 151.101.192.70 but according to above answers this might vary for you so make sure you do this step and check for yourself) and go to:

etc/

and open the host file like so:

sudo vim hosts

You have to open the file as a superuser otherwise you will not be able to save it since it is a read-only file. I used vim but you can use another editor. At the bottom, ad the IP you copied followed by 'rubygems.org' like so:

151.101.192.70 rubygems.org

The save the file and exit. You can try the connection in your terminal by typing:

ping rubygems.org

You should now see a continuous packet stream. Running any gem install command should now also work providing the rest of your environment is set up correctly.

Again I'm just posting this here for visibility and to help other but he heavy lifting was done by the answers above so thank you for that :)

Upvotes: 4

Taka Suzuki
Taka Suzuki

Reputation: 117

I added the line below to my /etc/hosts and it works.

151.101.192.70 rubygems.org

Upvotes: 10

Boon
Boon

Reputation: 1173

For Windows users, the problem can be resolved by prioritizing IPv4 addresses over IPv6 (see https://superuser.com/a/436944). Check your prefix policies by using PowerShell as administrator:

netsh interface ipv6 show prefixpolicies

You should see that IPv6 addresses (::/0) have higher precedence over IPv4 (::/96 and ::ffff:0:0/96). To fix this, delete the IPv6 entry and re-add it with a lower precedence, for example:

netsh interface ipv6 del prefixpolicy ::/0
netsh interface ipv6 add prefixpolicy ::/0 3 6

where the precedence 3 on my machine was lower than all others, and the label 6 was unused.

Upvotes: 0

Alexei Khlebnikov
Alexei Khlebnikov

Reputation: 2395

api.rubygems.org is currently experiencing issues with IPv6 setup: this hostname has 4 IPv6 addresses, but responds on neither of them. Neither to ping, nor to TCP connection attempts. When you are running gem, your gem tries IPv6 addresses first and times out on them, not having time to even try IPv4 addresses.

The solution is to lower priority of IPv6 addresses for api.rubygems.org, so that gem will try IPv4 addresses first. In order to do it, put these lines into /etc/gai.conf:

# Debian defaults.
precedence  ::1/128         50
precedence  ::/0            40
precedence  2002::/16       30
precedence  ::/96           20
precedence  ::ffff:0:0/96   10

# Low precedence for api.rubygems.org IPv6 addresses.
precedence  2a04:4e42::0/32  5

Upvotes: 104

bpope
bpope

Reputation: 29

As of this date, the IPv6 issues with rubygems.org still exist, although it seems not all the time or everywhere. I ran into it with VPSs in one data center, but not those in another. Alexei Khlebnikov's answer above is by far the best and easiest way to work around the problem (at least on Linux). However, make sure to do your own lookup for the api.rubygems.org IPv6 addresses; I found that the specific addresses above are no longer correct.

$ dig AAAA api.rubygems.org +short
rubygems.org.
2a04:4e42::70
2a04:4e42:400::70
2a04:4e42:600::70
2a04:4e42:200::70

Upvotes: 2

Mauricio Mora
Mauricio Mora

Reputation: 829

I didn't find /etc/gai.conf on MacOS, so as a workaround I just disabled IPV6 to download the gems. That worked for me.

'System Preferences' -> 'Network' -> Select WiFi -> click 'Advanced' button -> select 'TCP/IP' tab -> set the Configure IPV6 select to 'link-local only'.

Upvotes: 59

Related Questions