As of the 13th, I began noticing my cron jobs started to hang and
taking forever. After investigating, I discovered that the update
status was non functional and I was getting "Unable to fetch any
information about available new releases and updates" errors in my
logs.

I ran the following command on the server that hosts my sites: "wget
http://updates.drupal.org/release-history/notify/6.x". The result was
that it just hung after several attempts.

When I run the same command from another server, it downloads the xml
file without a problem.

I have well over one hundred Drupal sites running on my web server.
Perhaps someone thinks I'm being abusive? If so, can someone correct
this or refer me to the person who made that decision? My
server's IP address is 205.237.96.185. Thanks.

Comments

killes@www.drop.org’s picture

See my answer on the infra list

greggles’s picture

Status: Active » Fixed

Status: Fixed » Closed (fixed)

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

jptavan’s picture

Status: Closed (fixed) » Active

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

$url = "http://updates.drupal.org/release-history";
 if ($fp = fopen($url,"r")){ 
     echo "fopen retourne TRUE pour $url";
 }else{
     echo "fopen retourne FALSE pour $url";
 }  

Result : ...failed to open stream: Connection timed out...

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 ?

Pol’s picture

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

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

agojc’s picture

+1 !

reptilo’s picture

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)

leoncarlo’s picture

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

nnewton’s picture

Assigned: Unassigned » nnewton

Hi all,

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

-N

jptavan’s picture

213.186.33.18 and 213.186.33.19

reptilo’s picture

213.186.33.19
213.186.33.87

rondev’s picture

213.186.33.2

mouameme’s picture

213.186.33.4 (still mutualized hosting by OVH)

jgautier’s picture

213.186.33.4 (also)

leoncarlo’s picture

94.23.64.16

agojc’s picture

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

apaderno’s picture

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.

Damien Tournoud’s picture

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.

jonjon’s picture

213.186.33.2 (also)

leoncarlo’s picture

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

jptavan’s picture

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

Gerhard Killesreiter’s picture

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.

leoncarlo’s picture

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

leoncarlo’s picture

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

Pol’s picture

My server is on that ip: 213.186.33.16

Still blocked :(

Gerhard Killesreiter’s picture

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.

jptavan’s picture

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").

leoncarlo’s picture

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

agojc’s picture

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...

killes@www.drop.org’s picture

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

jptavan’s picture

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

killes@www.drop.org’s picture

We do not block anything in 213.251.*

jptavan’s picture

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

I ask OVH support for the traceroute :

web203:~# ping updates.drupal.org
PING master.drupal.org (140.211.166.6) 56(84) bytes of data.
^C
--- master.drupal.org ping statistics ---
7 packets transmitted, 0 received, 100% packet loss, time 6047ms


web203:~# traceroute drupal.org
traceroute to drupal.org (140.211.166.6), 30 hops max, 40 byte packets
#Internal network section hidden#
6 30g.gblx.gsw-1-6k.routers.chtix.eu (213.186.32.129) 9.291 ms 8.600 ms 8.676 ms
7 xe-8-0-0.edge4.paris1.level3.net (4.68.127.97) 1.526 ms 1.706 ms 1.411 ms
8 ae-34-52.ebr2.Paris1.Level3.net (4.69.139.225) 1.902 ms 1.617 ms 1.484 ms
9 ae-2-2.ebr1.Frankfurt1.Level3.net (4.69.141.234) 14.092 ms 13.602 ms 14.172 ms
10 ae-61-61.csw1.Frankfurt1.Level3.net (4.69.140.2) 18.459 ms ae-91-91.csw4.Frankfurt1.Level3.net (4.69.140.14) 22.780 ms ae-71-71.csw2.Frankfurt1.Level3.net (4.69.140.6) 25.669 ms
11 ae-82-82.ebr2.Frankfurt1.Level3.net (4.69.140.25) 14.296 ms ae-72-72.ebr2.Frankfurt1.Level3.net (4.69.140.21) 20.497 ms ae-82-82.ebr2.Frankfurt1.Level3.net (4.69.140.25) 21.696 ms
12 ae-41-41.ebr2.Washington1.Level3.net (4.69.137.50) 90.615 ms ae-43-43.ebr2.Washington1.Level3.net (4.69.137.58) 90.369 ms ae-44-44.ebr2.Washington1.Level3.net (4.69.137.62) 92.093 ms
13 ae-2-2.ebr2.Chicago2.Level3.net (4.69.132.69) 114.984 ms 116.021 ms 115.560 ms
14 ae-1-100.ebr1.Chicago2.Level3.net (4.69.132.113) 117.772 ms 116.924 ms 115.863 ms
15 ae-3.ebr2.Denver1.Level3.net (4.69.132.61) 137.584 ms 137.206 ms 141.287 ms
16 ae-2.ebr2.Seattle1.Level3.net (4.69.132.53) 185.731 ms 185.282 ms 179.377 ms
17 ge-11-0.hsa2.Seattle1.Level3.net (4.68.105.39) 176.504 ms 172.411 ms 172.643 ms
18 unknown.Level3.net (63.211.200.246) 175.954 ms 176.493 ms 177.903 ms
19 corv-car1-gw.nero.net (207.98.64.177) 178.342 ms 181.338 ms 182.152 ms
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *

NB : chtix.eu is part of OVH network

Tony
~$ host drupal.org
drupal.org has address 140.211.166.6

tony@tony:~$ whois 140.211.166.6

OrgName: Oregon State System of Higher Education
OrgID: OSSHE-1
Address: 1225 Kincaid, UO Campus

NameServer: NS1.NERO.NET
NameServer: OUS.EDU
NameServer: PHLOEM.UOREGON.EDU

RTechHandle: DC80-ARIN
RTechName: Crowe, David
RTechPhone: +1-541-346-1698
RTechEmail: crowed@nero.net

Apparemment leur fournisseur de réseau est NERO
On voit sur le traceroute qu'on atteint le réseau de NERO (corv-car1-gw.nero.net)
Donc soit c'est un souci au niveau de leur fournisseur, soit on est bloqué par leur serveur ou leur sous-réseau

Tony

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

killes@www.drop.org’s picture

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

Damien Tournoud’s picture

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

jptavan’s picture

Status: Active » Closed (fixed)

Thank you for your help.

agojc’s picture

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

apaderno’s picture

Status: Closed (fixed) » Fixed

A fixed problem is marked as fixed.

leoncarlo’s picture

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

leoncarlo’s picture

not working

apaderno’s picture

@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.

leoncarlo’s picture

thanks, I'll wait confident

oliverstoney’s picture

Can you unblock 64.147.160.231 and 64.147.160.230

nnewton’s picture

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.

bkudrle’s picture

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.

nnewton’s picture

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

bkudrle’s picture

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.

apaderno’s picture

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).

sunradio:~ Kiam$ whois 74.124.195.152
Corporate Colocation Inc. CORPCOLO-NET03 (NET-74-124-192-0-1)
                                  74.124.192.0 - 74.124.223.255
InMotion Hosting CORPCOLO-NET-74-124-194-0-23 (NET-74-124-194-0-1)
                                  74.124.194.0 - 74.124.195.255

sunradio:~ Kiam$ whois 74.124.210.84
Corporate Colocation Inc. CORPCOLO-NET03 (NET-74-124-192-0-1)
                                  74.124.192.0 - 74.124.223.255
InMotion Hosting CORPCOLO-NET-74-124-210-0-23 (NET-74-124-210-0-1)
                                  74.124.210.0 - 74.124.211.255
sunradio:~ Kiam$ traceroute -P ICMP 74.124.210.84
traceroute to 74.124.210.84 (74.124.210.84), 64 hops max, 72 byte packets
...
22  te1-7.cr01.ord01.us.mzima.net (69.174.120.74)  125.948 ms  126.552 ms  124.145 ms
23  te0-0.cr01.dfw01.us.mzima.net (69.174.120.14)  157.431 ms  146.762 ms  156.372 ms
24  te1-1.cr01.phx01.us.mzima.net (69.174.120.37)  192.440 ms  179.271 ms  179.821 ms
25  te1-1.cr01.lax02.us.mzima.net (69.174.120.33)  189.532 ms  179.549 ms  180.131 ms
26  xe1-0.cr01.lax03.us.mzima.net (216.193.255.186)  179.651 ms  193.076 ms  179.975 ms
27  ge0-corpcolo.cust.lax03.mzima.net (72.37.172.122)  180.110 ms  179.511 ms  179.066 ms
28  biz51.inmotionhosting.com (74.124.210.84)  179.648 ms  179.335 ms  179.725 ms
sunradio:~ Kiam$ traceroute -P ICMP 74.124.195.152
traceroute to 74.124.195.152 (74.124.195.152), 64 hops max, 72 byte packets
...
21  nyiix.ge2-6.cr01.lga01.mzima.net (198.32.160.169)  107.078 ms  107.049 ms  107.804 ms
22  te1-1.cr01.iad01.us.mzima.net (69.174.120.62)  112.434 ms  121.378 ms  125.634 ms
23  te1-3.cr01.atl01.us.mzima.net (69.174.120.53)  125.409 ms  125.091 ms  125.824 ms
24  te0-1.cr01.dfw01.us.mzima.net (69.174.120.49)  153.809 ms  143.746 ms  143.595 ms
25  te1-1.cr01.phx01.us.mzima.net (69.174.120.37)  177.930 ms  178.810 ms  177.120 ms
26  te1-1.cr01.lax02.us.mzima.net (69.174.120.33)  180.536 ms  179.075 ms  179.601 ms
27  xe1-0.cr01.lax03.us.mzima.net (216.193.255.186)  178.852 ms  191.738 ms  180.054 ms
28  ge0-corpcolo.cust.lax03.mzima.net (72.37.172.122)  179.581 ms  178.269 ms  180.098 ms
29  205.134.254.17 (205.134.254.17)  179.923 ms  178.227 ms  180.267 ms
30  vps932.inmotionhosting.com (74.124.195.152)  179.250 ms  181.855 ms  180.064 ms
bkudrle’s picture

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?

leostar’s picture

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

javierdiaz’s picture

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

bkudrle’s picture

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...

jjkiesch’s picture

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!

jfeiler’s picture

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.

BrightBold’s picture

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.

apaderno’s picture

Status: Fixed » Active

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

atelier’s picture

Please check 72.249.95.146. Thank you.

* EDIT *
Please also check:
72.249.95.147
72.249.95.148
72.249.95.149

nnewton’s picture

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.

jfeiler’s picture

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?

Jazzy’s picture

Hi!

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

Thanks!

escoles’s picture

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?

jfeiler’s picture

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?

escoles’s picture

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.

jfeiler’s picture

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

nnewton’s picture

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

jfeiler’s picture

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!

jfeiler’s picture

There may be another IP address involved: 24.176.138.44.

nnewton’s picture

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.

jfeiler’s picture

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.

BrightBold’s picture

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!

Logan Bear’s picture

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

belulo’s picture

Hello!

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

Thx!

MarioTorresp’s picture

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

Anonymous’s picture

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

jfeiler’s picture

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

WebNewCastle’s picture

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

kewlguy’s picture

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

rimkashox’s picture

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 ! :)

rimkashox’s picture

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

rimkashox’s picture

Status: Active » Closed (fixed)

all's good !

apaderno’s picture

Status: Closed (fixed) » Active

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

Jazzy’s picture

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?

EPO’s picture

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.

Bastian-2’s picture

Please unblock this IP

217.172.160.41

Logan Bear’s picture

Problem fixed for my site. Thanks.

sergo2’s picture

can you unblock this ip: 81.169.145.74

thank you

nnewton’s picture

Status: Active » Fixed

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.

Status: Fixed » Closed (fixed)

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

revxml’s picture

Is this still an issue? I am having these exact problems on 64.34.179.135, multiple sub-domains using the same IP. I performed the 6.15 update, and on each site that I have updated, I receive this error. Plugin manager won't update the repository, Available Update report won't show the list. And "run cron" is always displayed, after multiple successful runs.

apaderno’s picture

Status: Closed (fixed) » Active

@revxml: The issue is now closed; if you want somebody to look into this, you should open it.

kewlguy’s picture

Can you please check to see if these IP's might be banned. I just cannot get my updates to work on my sites and my host has not been able to solve the issue for me either, well as of yet.

67.227.184.62
67.227.184.63
67.227.184.64
67.227.184.65

zengenuity’s picture

I'm pretty sure we've been blocked from our office IP. I can't get to drupal.org or any subdomain from within our network. Can someone check this IP and unblock it?

69.136.131.19

Thanks.

zengenuity’s picture

Component: Other » Webserver

Please please, can somebody unblock our IP? I run a Drupal shop, and I've had to tell everyone to stay home or go to coffee shops because nobody can access drupal.org, api.drupal.org, groups.drupal.org, updates.drupal.org from the office. It's crazy. I suppose if it continues, we'll have to set up a proxy, but it seems silly that we'd have to waste so much time on this. I have no idea why our office IP would have been banned.

Our IP again is: 69.136.131.19

Thanks.

Anonymous’s picture

Hi

I am also facing the same issue with my sites Failed to:

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

Site is hosting on JustHost.com and the IP is: 69.175.51.226

Can you please see, if this ip is blocked. Please unblock this IP, i have 3 websites of my clients
on this server and all sites showing same problem.

Thanks,
Nachhatar

nnewton’s picture

Status: Active » Fixed

None of these IPs were blocked, but to be sure we have flushed our entire rule set. Nothing is blocked as of right now.

-N

kewlguy’s picture

It seems that this has solved my issues with a few different sites.

Thank You!

Anonymous’s picture

Status: Closed (fixed) » Fixed

Hi !

My web hosting server (justhost.com ~ 69.175.51.226) still showing same error. Drupal update server (updates.drupal.org) still not responding to this web server (69.175.51.226).

I made a php script using following code: /access_check.php

echo file_get_contents('http://updates.drupal.org/release-history/project-list/all');

OUTPUT:
Warning: file_get_contents(http://updates.drupal.org/release-history/project-list/all) [function.file-get-contents]: failed to open stream: Network is unreachable in /home/[USERNAME]/public_html/access_check.php on line 2

But drupal's update server still not responding. Can you please check this IP (69.175.51.226), if it is in blocking by drupal's update server.

Thanks

-- Nachhatar

Gerhard Killesreiter’s picture

Can you try to access other websites? See http://drupal.org/node/695118#comment-2564434 for example code.

And again: We currently do not block any IPs, the problem is most likely on your end of the network. Speak to your hoster.

leostar’s picture

OK Guys,

Problem solved after 6 month.

Here is the case history.

We have 4 Drupal sites running on same IP. Initially problem started when we upgrade from 6.12 to 6.13 for all of the sites. Then upgraded to 6.14 but still the problem with automatic update. Called Godaddy Support many time, No IP banned or nothing. Tried removing all the modules on one site and and check the updates again but the same issue again. So upgrade to 6.15 and here is what I done step by step.

1. Site Offline.
2. Change the theme to basic Garland
3. Change Admin theme to basic Garland
4. Updated site theme which we are using for production (Acquia Marina)
5. Removed all unwanted modules from site and deleted from directory (It was a pain to search and remove unwanted module)
6. Unchecked Syslog, Statistics, Tracker and removed the Tracker2 module.
7. Changed the site theme to original
8. NOT changed the Admin theme (We are still using Garland for admin work)
9. Click on Available Update
10. All required update shown after 6 month.

I don't know if its a fix in 6.15 or Acquia Marina Theme or the issue with Syslog, Statistics, Tracker module but our problem solved, and yes after removing these Syslog, Statistics, Tracker modules our all sites response time is much faster than expected.

Hope this helps.

Thanks,
Leo

Status: Fixed » Closed (fixed)

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

Travis’s picture

Status: Fixed » Closed (fixed)

Check to make sure you have the correct value for 'update_fetch_url' in the 'variable' table. I've seen modules change this and cause updates to fail when the servers they point to stop serving update pages. Here it looks like the install file for the tmcontentlinks module changes it:

drupal-server [public_html]$ grep -R update_fetch_url *
sites/all/modules/tmcontentlinks/tmcontentlinks.install: variable_set('update_fetch_url', 'http://www.techcenterboise.com/release-history');

Make sure your Drupal instance is actually fetching updates from Drupal before pointing fingers.

One step in that process is checking the 'variable' table.

drupal-server [public_html]$ mysql -e 'select * from variable where name="update_fetch_url";' drupal_database
+------------------+---------------------------------------------------+
| name             | value                                             |
+------------------+---------------------------------------------------+
| update_fetch_url | s:42:"http://updates.drupal.org/release-history"; |
+------------------+---------------------------------------------------+

Another is making sure nobody modified the UPDATE_DEFAULT_URL constant.

drupal-server [public_html]$ grep -R 'UPDATE_DEFAULT_URL' modules/update/update.module
define('UPDATE_DEFAULT_URL', 'http://updates.drupal.org/release-history');

Yet another is checking for embryonic TCP connections from your drupal webserver to whatever IP address you're trying to fetch updates from. In the netstat(8) output below, the 192.168.0.50 IP is the IP of the drupal-server, and 10.0.0.50 is the IP address for the Drupal update server blocking update attempts.

drupal-server [public_html]$ netstat -anp | grep httpd
tcp        0      1 192.168.0.50:12345        10.0.0.50:80           SYN_SENT    54321/httpd
tjiel’s picture

Status: Closed (fixed) » Active

May someone please check if ip 62.159.237.107 is blocked.
I followed all the hints posted above by Travis so i'm pretty sure that the adress is banned.

Thanx for your help!

nnewton’s picture

Status: Active » Closed (works as designed)

@tjiel, no your not blocked. I checked the FW.

I'd contact your DC.

@Travis, nice writeup, but your netstat trick doesn't reveal whether we are blocking or the client DC is doing rate limiting. In most cases in this thread, it was the latter.

ArtMonkey’s picture

Hi. Updates will not work for me. I have contacted my web host provider and they say there is no issue. I installed a Drupal 7.4 test-site with no updating issues at all. But updates do not work at all on my real site. ..They are alas on separate servers with the same hosting company. But they swear the servers are identical in every way.

This makes me wonder if the ip is blocked for the server I want to use. Can you check this for me?

My IP address is 79.170.40.161

I've hit a bit of a dead end with this issue which is a shame as I really want to use Drupal for my new site.

Many thanks for your reply in advance.

killes@www.drop.org’s picture

79.170.40.161 is not banned

steveoriol’s picture

I have problem with 2 website on this server: cluster006.ovh.net [213.186.33.17] ... ?

virginie gerard’s picture

Assigned: nnewton » virginie gerard

I have problem with 1 website on this server: cluster006.ovh.net [213.186.33.17] ??
Thank you.

nnewton’s picture

We are discussing with with OVH. We do not have their IPs blocked. In most cases this is a DOS prevention device somewhere blocking our IP. We are investigating.

-N

steveoriol’s picture

Any news ? ...

By the way, you can compare with the server cluster003.ovh.net [213.186.33.4] ,
on this one the module updates work well...

steveoriol’s picture

Cool ! it is working again ;-)

In fact, OVH has rerouted traffic through another exit to bypass the problem of drupal side, waiting for a response ...
see on OVH french forum : http://forum.ovh.com/showpost.php?p=463969&postcount=54

Component: Webserver » Servers