Server banned from using http://updates.drupal.org?

See my answer on the infra list

Automatically closed -- issue fixed for 2 weeks with no activity.

I have the same problem with several Drupal site (6.10 or 5.14 + Update status 5.x-2.3) : the http://updates.drupal.org/release-history url return a time-out : http://www.damezumari.net/test_outbound.php

I have to disable the Update status module.

My web hosting company support (http://www.ovh.com/) say they don't block outbound traffic. Other client have the same problem with Drupal site.

I have read this info on http://lists.drupal.org/private/infrastructure/2009-August/016968.html :

The problem is as follows: Due to an oversight there was a bug in the
udpate_status module which led - under certain circumstances - to it
requesting updates far more often than neccessary. This in turn led to
problems with drupal.org's stability for normal users. The problem has
been fixed in the code, but we have no way to contact site owners to
tell them to update the code. So the only thing we can do to restore a
sane drupal.org is to block problematic IPs until people notice that
they should be contacting us.

The intention is to work with them in order to get them to upgrade.

How to proceeds to unblock my IP (213.186.33.19) ?
I just have to update the module to the latest version (update_status 5.x-2.x-dev ?) and contact infrastructure@drupal.org after that ?

Same problem for all my website running Drupal 6 on OVH !!!

Même problème pour moi pour tous mes sites chez OVH !!!

+1 !

Same situation for all my D6 websites hosted by OVH.

I even try to install "Update status advanced settings 6.x-1.x-dev" but always same answer :

"Unable to fetch any information about available new releases and updates"

thx to help us !

Drupal 6.13
MySQL 5.0.68
PHP 5.2.10
Apache/2.2.X (OVH)

Same situation for me,I have my web hosting with OVH, I am using "drupal 6.13" in a lot of web. what can we do? Sorry for my English, I am Italian

Hi all,

The two ips given don't show up in our firewall rules. Any other IPs I can check for?

-N

213.186.33.18 and 213.186.33.19

213.186.33.19
213.186.33.87

213.186.33.2

213.186.33.4 (still mutualized hosting by OVH)

213.186.33.4 (also)

94.23.64.16

213.186.33.4 also. Waoh ! How many are we sharing the same IP at OVH's ?!!

If the IP is shared between many web sites, it's clear that the IP is blocked because there are too many requests coming from the same IP.
That is the reason I preferred to have a static IP for my web site.

Naranyan confirmed yesterday that we do not block any IP in the 213.186.33.0/24 range. I think this is a configuration issue on the OVH side.

213.186.33.2 (also)

I dont understand, I am with OVH, and I have this IP (94.23.64.16) and I have the same problem. and
another thing; but what we can do? Change OVH, I have other web with another hosting company and I never had this kind of problem,MY friend, what we do?
Sorry for my English and my desolation

The two ips given don't show up in our firewall rules. Any other IPs I can check for?

Naranyan, could you confirm explicitly that Drupal don't block these IP ? :
94.23.64.16
213.186.33.2
213.186.33.4
213.186.33.18
213.186.33.19
213.186.33.87

94.23.64.16 is not blocked and none of the others is blocked either.

Try to get a traceroute from the server to drupal.org.

In this period I have see that in OVH have change PHP and MYSQL, is possible that this change have created this problem?

Sorry, how can I do a traceroute from the server OVH to drupal.org?

My server is on that ip: 213.186.33.16

Still blocked :(

Yes, a change in the php config could very well explain this problem. You need to check if your sites can do external http calls at all. Try to set up an aggregator feed. If that fails, the config issue is to blame.

You need to check if your sites can do external at all

External http calls work (with the script in #4 and an other server).
I have re-open a ticket with OVH support. We just have to wait for a reponse (they first said "it's drupal").

three days ago I have speek with telefon with OVH and they have said to me that the problem is of Drupal

And they seem to reaffirm the same origin to the problem, as seen on :

http://forum.ovh.com/showthread.php?p=311057&posted=1#post311057

arguing they do not filter the outting connexions...

can you ask them to try a traceroute form their servers to drupal.org and to osuosl.org?

OVH support send me the IP for the "outgoing gateway" : 213.251.189.201 to 213.251.189.210
Do you block these IP ?

We do not block anything in 213.251.*

Try to get a traceroute from the server to drupal.org

I ask OVH support for the traceroute :

Original messages : http://forum.ovh.com/showthread.php?p=311137#post311133

It appears the traceroute ends at nero which is an uplink for the OSL. I'll discuss the matter with them.

OVH confirmed that the issue is on their end (http://forum.ovh.com/showpost.php?p=311268&postcount=31).

Thank you for your help.

Yes, thank you very much for helping to solve the problem. It works perfectly now !

A fixed problem is marked as fixed.

in my web on OVH dont works, it work for 10 minutes and now again dont work, I hope that tomorrow It works perfectly

not working

@leoncarlo: See comment #35, which reports OVH confirmed the problem is at their end. Being this the case, there is nothing to do at d.o end.

thanks, I'll wait confident

Can you unblock 64.147.160.231 and 64.147.160.230

I did not find .230 in the rules, but did find .231 and unblocked it. Please ensure your running a current version of drupal to avoid being blocked again.

I have this same problem for a client, but she is using a different hosting company - inmotionhosting.com. I have tried installing numerous Drupal versions from scratch (6.13 being the latest try - earlier I used 6.14). The provider said that they are not blocking outgoing requests. So what is the procedure that I should use at this point? The shared IP for the site is 74.124.210.84. The support at the hosting provider says that this shared IP would be the one that would have the outgoing request.

I'm not showing anything for '74.124.210.84', but did find 74.124.195.152. Can you double check with the hosting company if that IP address is anything significant for them.

-N

Thanks so much for your reply. The provider said that the 74.124.195.152 IP was theirs but should not affect requests from my site. They did also say, though, that IP 74.124.198.63 "is also assigned to your server and does answer requests for it". Could that be a problem? Thanks again for your time in this.

It seems both the IPs are own from the same company, but I don't see any relation between them (nor the traceroute passes through 74.124.195.152 to go to 74.124.210.84).

Thanks again for your work.

And can I assume that the other IP address they gave me - 74.124.198.63 - also is not blocked?

Hi

I am also facing the same issue with my site Failed to "fetch available update data". Site is hosting on Godaddy and the IP is 72.167.232.196.

Can you please see if this ip is blocked.

Thanks,
Leo

Hello,

LIke others above, I'm experiencing :Unable to fetch any information about available new releases and updates."

Can you please see if these IP's are blocked
66.40.3.4
66.40.8.100
66.40.56.80
66.40.56.79

I'm glad it's not just me with this issue.

THanks,

Javier

Would it be possible and feasible (without compromising security) to post the blocked IPs somewhere so as to minimize your work in looking all of these up? Just a thought...

I am not able to get updates either right now. IP address is 205.178.145.65. It is a Network Solutions server.

Can you check to see if it is blocked?
Thanks!

Also problems with a Network Solutions server at 205.178.145.65. Can you check? We're not getting status updates and timing out on feeds from d.o.

Like bkudrle I am with InMotion and having this problem on both Drupal sites (one 6.13 and one 6.14) I have hosted there. The server is reporting as 74.124.198.60. Thanks for your help.

The report is marked as fixed; if you don't change the status, it is difficult somebody will look into it.

Please check 72.249.95.146. Thank you.

* EDIT *
Please also check:
72.249.95.147
72.249.95.148
72.249.95.149

I've unbanned all the IPs listed above that I could find.

72.249.95.146
74.124.195.152

I'm afraid none of the other IPs were found in our rules.

Were there only the two you listed? How do we address the issues for all of the other IPs? Someone suggested posting a list of banned IPs, and this appears to do so (If it's only those two). Because a large number of IPs have been listed on this thread, there must be something going on. (I checked and I'm still not able to access updates.)

Many of us pay attention to status updates. I'm not sure there's any way of knowing how many Drupal installations don't know/understand the importance of these updates, so I don't think it's possible to know how many people are now not getting status update messages. This has the potential to really impact Drupal negatively.

Any suggestions for how to proceed?

Hi!

Can you please check 81.169.145.81, 81.169.145.74, 81.169.145.65 and 81.169.145.66?

Thanks!

I'm also unable to get updates. This is 6.14 on a VPS that's brand new to us.

Can you please check:

206.188.208.40

Host is NetSol.

What's the protocol for this? Should we be submitting individual issues? Would that be easier for you to triage?

This is at least the third issue with NetSol that has been posted here--but there have been other providers cited. I concur--what is the best way to handle this?

I'm getting through fine now - thanks. (if it's not something you did, then thanks for listening.)

Narayan et al. -- as d.o is providing a very useful service w.r.t. update checking, I'm sure most of us will be willing to carry some water to smooth out your processes. Let us know what you would like us to do to make this easier for you.

We're still not getting updates through a NetSol server at 205.178.145.65. Is there any way to let people know what is or isn't happening? There clearly are some problems and we could track them down but we need to know what is happening on the d.o. side. Are these blocked? Are they not listed or not found? We also need to know when problems have been resolved so a pattern can be found.

Not being able to rely on Drupal's automatic update checking in (unknown) circumstances, is a major vulnerability for many people

Hi jfeiler,

We have no IP's matching that in our fw rules and no other blocking takes place on our side. In fact, there are no ips with the prefix 205.178. I'd be happy to help you debug this, but as of this point I have no real options :).

-N

I've confirmed with NetSol that the IP address for our hosted site is 205.178.145.65 and that they're not using another address.

I think the error is happening in opening the connection inside drupal_http_request in common.inc. The line I'm suspicious of is
case 'http':
$port = isset($uri['port']) ? $uri['port'] : 80;
$host = $uri['host'] . ($port != 80 ? ':'. $port : '');
$fp = @fsockopen($uri['host'], $port, $errno, $errstr, 15); <--this line
break;

I saw a bug report complaining about the built-in 15 second timeout and I changed it to 45 on a spare installation of mine but it still failed. There are times when connections are taking a long time so I'm wondering if I should just try to bump that up more.

I've also not been able to run aggregator against d.o. feeds, and I thought they were related issues--when I poked around in the code I saw (not surprisingly) that both of them are coming through drupal_http_request so that is probably the issue.

Any suggestions are welcome!

There may be another IP address involved: 24.176.138.44.

I'm afraid I can't find that IP either. Could you try a telnet or nc connection on port 80 to 140.211.166.6 and 140.211.166.61 and let me know which one works. Thanks.

Both work with nc. I'm going to go through another avenue which could be interfering with the message and then I'll increase the timeout (but I don't think it's timing out for performance, just not getting through). It's got to be something simple, and it's a fluke that it happened when you blocked some IPs on d.o. and we went off on (I think) a wild goose chase.

Yea! I logged into my site today to be greeted with 11 (count-em, 11!) recommended updates. If you did something to make this magic happen, thanks!

Can you check IP 174.132.165.2 ? I'm having the same problem. Thanks.

Hello!

I have a same problem. Can you help me: 94.199.180.17?

Thx!

Please Narayan, you can check if the IP 74.81.81.100 is it blocked?, I cannot update Drupal.
Thanks.

Having the same issue with Hostmonster who uses Bluehost. Updating 6.14 renders the same error. I have dedicated IP number 66.147.240.88.

Thanks,

Bruce

Can you check this range of IP addresses? 205.178.145.64 to 205.178.145.159 We still cannot connect.

Updated: Please ignore the previous request. It appears that the hosting provider made a block on the firewall. I'm still looking into why that might be the case, but apparently in my case that is what the issue was after all.

Hello,

Can someone check 74.54.164.189 as well? As of a couple days ago, I also can't get updates and this is the first time I've ever had an issue. It doesn't appear to be the drupal_http_request_fails variable as far as I can tell. If it did get blocked, can someone also tell me how to avoid this?

Thanks,

Matt

Nero Issue still exists??

traceroute to drupal.org (140.211.166.6), 30 hops max, 38 byte packets
1 dc2-vps1-327.liquidweb.com (67.227.191.251) 0.107 ms 0.057 ms 0.051 ms
2 lw-dc2-core3-po4.rtr.liquidweb.com (209.59.157.235) 0.333 ms 0.288 ms *
3 lw-eqx-border5-te1-2.rtr.liquidweb.com (209.59.157.225) 7.892 ms 7.385 ms 7.669 ms
4 64.209.88.185 (64.209.88.185) 6.495 ms 6.495 ms 6.461 ms
5 * te6-2-10G.ar2.CHI2.gblx.net (67.16.132.213) 7.042 ms 6.788 ms
6 te-3-3.car3.chicago1.level3.net (4.68.110.193) 6.549 ms 6.563 ms 7.018 ms
7 ae-31-53.ebr1.Chicago1.Level3.net (4.68.101.94) 14.014 ms * 9.402 ms
8 ae-6.ebr1.Chicago2.Level3.net (4.69.140.190) 9.484 ms 9.862 ms 9.586 ms
9 ae-3.ebr2.Denver1.Level3.net (4.69.132.61) 38.350 ms 38.564 ms 37.657 ms
10 ae-2.ebr2.Seattle1.Level3.net (4.69.132.53) 58.443 ms 61.795 ms 54.515 ms
11 * ae-21-52.car1.Seattle1.Level3.net (4.68.105.34) 213.669 ms 207.024 ms
12 eugnor1wce1-univ-of-oregon.wcg.net (64.200.134.198) 120.815 ms 120.942 ms 124.472 ms
13 corv-car1-gw.nero.net (207.98.64.18) 136.453 ms 293.844 ms 121.239 ms
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *

Has drupal.org gotten anywhere with these folks? Got any ideas of how I could make a work around or suggest a change somewhere to my host?

Thanks for listening....lol

Same problem here.

Can you please unblock my IP if it were blocked ?!

My site is VoyageDuGout.com - IP: 174.132.165.24

Thanks so much ! :)

For me problem is solved... It was site5 that was blocking outbound access to updates.drupal.org.

all's good !

@rimkashox: Your problem may be resolved, but not other people's.

Hi!

I'm having the same problem with ips 81.169.145.81, 81.169.145.74, 81.169.145.65 and 81.169.145.66.
Again, I must say, as I posted them earlier (Oct. 13th) and after that everything worked fine for me ...till now. What happened?

If the following (Comment #4) is true:

I have read this info on http://lists.drupal.org/private/infrastructure/2009-August/016968.html :

The problem is as follows: Due to an oversight there was a bug in the
udpate_status module which led - under certain circumstances - to it
requesting updates far more often than neccessary. This in turn led to
problems with drupal.org's stability for normal users. The problem has
been fixed in the code, but we have no way to contact site owners to
tell them to update the code. So the only thing we can do to restore a
sane drupal.org is to block problematic IPs until people notice that
they should be contacting us.

Why isnt it possible to generate a second update domain. If users are blocked because they are sharing their IP with a buggy Drupal Installation, they can evade to the alternative domain, which the buggy version dont know. Problem solved.

Please unblock this IP

217.172.160.41

Problem fixed for my site. Thanks.

can you unblock this ip: 81.169.145.74

thank you

74.81.81.100: Not blocked

66.147.240.88: Not blocked

205.178.*.*: Not blocked, the entire netrange is clear

re: kewlguy: There never was a NERO issue. They are our upstream provider and are not blocking anything. Traceroutes often stop at border routers, there is nothing odd about that.

174.132.165.24: Not blocked

217.172.160.41: Not blocked

81.169.145.74: Not blocked..

I cannot stress enough that most of these issues are client side. I just went through the list here and 0 of these ips are blocked. The people who have it suddenly fixed are likely seeing their host doing something to fix it. It is possible that hosts are seeing too many connections to our single VIP. I'm going to work on getting a second VIP added to help with this, but have no ETA on it. We have not banned an ip for the updates issue in months. If your having issues, its likely not an ip ban on our webnodes.

I'm marking this as fixed, please do not re-open this issue unless you have already contacted your upstream provider.