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
Comment #1
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedSee my answer on the infra list
Comment #2
gregglesComment #4
jptavan CreditAttribution: jptavan commentedI 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
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 :
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 ?
Comment #5
PolSame problem for all my website running Drupal 6 on OVH !!!
Même problème pour moi pour tous mes sites chez OVH !!!
Comment #6
agojc CreditAttribution: agojc commented+1 !
Comment #7
reptilo CreditAttribution: reptilo commentedSame 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)
Comment #8
leoncarlo CreditAttribution: leoncarlo commentedSame 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
Comment #9
nnewton CreditAttribution: nnewton commentedHi all,
The two ips given don't show up in our firewall rules. Any other IPs I can check for?
-N
Comment #10
jptavan CreditAttribution: jptavan commented213.186.33.18 and 213.186.33.19
Comment #11
reptilo CreditAttribution: reptilo commented213.186.33.19
213.186.33.87
Comment #12
rondev CreditAttribution: rondev commented213.186.33.2
Comment #13
mouameme CreditAttribution: mouameme commented213.186.33.4 (still mutualized hosting by OVH)
Comment #14
jgautier CreditAttribution: jgautier commented213.186.33.4 (also)
Comment #15
leoncarlo CreditAttribution: leoncarlo commented94.23.64.16
Comment #16
agojc CreditAttribution: agojc commented213.186.33.4 also. Waoh ! How many are we sharing the same IP at OVH's ?!!
Comment #17
apadernoIf 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.
Comment #18
Damien Tournoud CreditAttribution: Damien Tournoud commentedNaranyan 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.
Comment #19
jonjon CreditAttribution: jonjon commented213.186.33.2 (also)
Comment #20
leoncarlo CreditAttribution: leoncarlo commentedI 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
Comment #21
jptavan CreditAttribution: jptavan commentedNaranyan, 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
Comment #22
Gerhard Killesreiter CreditAttribution: Gerhard Killesreiter commented94.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.
Comment #23
leoncarlo CreditAttribution: leoncarlo commentedIn this period I have see that in OVH have change PHP and MYSQL, is possible that this change have created this problem?
Comment #24
leoncarlo CreditAttribution: leoncarlo commentedSorry, how can I do a traceroute from the server OVH to drupal.org?
Comment #25
PolMy server is on that ip: 213.186.33.16
Still blocked :(
Comment #26
Gerhard Killesreiter CreditAttribution: Gerhard Killesreiter commentedYes, 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.
Comment #27
jptavan CreditAttribution: jptavan commentedExternal 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").
Comment #28
leoncarlo CreditAttribution: leoncarlo commentedthree days ago I have speek with telefon with OVH and they have said to me that the problem is of Drupal
Comment #29
agojc CreditAttribution: agojc commentedAnd 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...
Comment #30
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedcan you ask them to try a traceroute form their servers to drupal.org and to osuosl.org?
Comment #31
jptavan CreditAttribution: jptavan commentedOVH support send me the IP for the "outgoing gateway" : 213.251.189.201 to 213.251.189.210
Do you block these IP ?
Comment #32
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedWe do not block anything in 213.251.*
Comment #33
jptavan CreditAttribution: jptavan commentedI ask OVH support for the traceroute :
Original messages : http://forum.ovh.com/showthread.php?p=311137#post311133
Comment #34
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedIt appears the traceroute ends at nero which is an uplink for the OSL. I'll discuss the matter with them.
Comment #35
Damien Tournoud CreditAttribution: Damien Tournoud commentedOVH confirmed that the issue is on their end (http://forum.ovh.com/showpost.php?p=311268&postcount=31).
Comment #36
jptavan CreditAttribution: jptavan commentedThank you for your help.
Comment #37
agojc CreditAttribution: agojc commentedYes, thank you very much for helping to solve the problem. It works perfectly now !
Comment #38
apadernoA fixed problem is marked as fixed.
Comment #39
leoncarlo CreditAttribution: leoncarlo commentedin my web on OVH dont works, it work for 10 minutes and now again dont work, I hope that tomorrow It works perfectly
Comment #40
leoncarlo CreditAttribution: leoncarlo commentednot working
Comment #41
apaderno@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.
Comment #42
leoncarlo CreditAttribution: leoncarlo commentedthanks, I'll wait confident
Comment #43
oliverstoney CreditAttribution: oliverstoney commentedCan you unblock 64.147.160.231 and 64.147.160.230
Comment #44
nnewton CreditAttribution: nnewton commentedI 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.
Comment #45
bkudrle CreditAttribution: bkudrle commentedI 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.
Comment #46
nnewton CreditAttribution: nnewton commentedI'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
Comment #47
bkudrle CreditAttribution: bkudrle commentedThanks 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.
Comment #48
apadernoIt 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).
Comment #49
bkudrle CreditAttribution: bkudrle commentedThanks again for your work.
And can I assume that the other IP address they gave me - 74.124.198.63 - also is not blocked?
Comment #50
leostar CreditAttribution: leostar commentedHi
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
Comment #51
javierdiaz CreditAttribution: javierdiaz commentedHello,
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
Comment #52
bkudrle CreditAttribution: bkudrle commentedWould 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...
Comment #53
jjkiesch CreditAttribution: jjkiesch commentedI 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!
Comment #54
jfeiler CreditAttribution: jfeiler commentedAlso 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.
Comment #55
BrightBoldLike 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.
Comment #56
apadernoThe report is marked as fixed; if you don't change the status, it is difficult somebody will look into it.
Comment #57
atelier CreditAttribution: atelier commentedPlease check 72.249.95.146. Thank you.
* EDIT *
Please also check:
72.249.95.147
72.249.95.148
72.249.95.149
Comment #58
nnewton CreditAttribution: nnewton commentedI'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.
Comment #59
jfeiler CreditAttribution: jfeiler commentedWere 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?
Comment #60
Jazzy CreditAttribution: Jazzy commentedHi!
Can you please check 81.169.145.81, 81.169.145.74, 81.169.145.65 and 81.169.145.66?
Thanks!
Comment #61
escoles CreditAttribution: escoles commentedI'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?
Comment #62
jfeiler CreditAttribution: jfeiler commentedThis 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?
Comment #63
escoles CreditAttribution: escoles commentedI'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.
Comment #64
jfeiler CreditAttribution: jfeiler commentedWe'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
Comment #65
nnewton CreditAttribution: nnewton commentedHi 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
Comment #66
jfeiler CreditAttribution: jfeiler commentedI'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!
Comment #67
jfeiler CreditAttribution: jfeiler commentedThere may be another IP address involved: 24.176.138.44.
Comment #68
nnewton CreditAttribution: nnewton commentedI'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.
Comment #69
jfeiler CreditAttribution: jfeiler commentedBoth 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.
Comment #70
BrightBoldYea! 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!
Comment #71
Logan Bear CreditAttribution: Logan Bear commentedCan you check IP 174.132.165.2 ? I'm having the same problem. Thanks.
Comment #72
belulo CreditAttribution: belulo commentedHello!
I have a same problem. Can you help me: 94.199.180.17?
Thx!
Comment #73
MarioTorresp CreditAttribution: MarioTorresp commentedPlease Narayan, you can check if the IP 74.81.81.100 is it blocked?, I cannot update Drupal.
Thanks.
Comment #74
Anonymous (not verified) CreditAttribution: Anonymous commentedHaving 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
Comment #75
jfeiler CreditAttribution: jfeiler commentedCan you check this range of IP addresses? 205.178.145.64 to 205.178.145.159 We still cannot connect.
Comment #76
WebNewCastle CreditAttribution: WebNewCastle commentedUpdated: 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
Comment #77
kewlguy CreditAttribution: kewlguy commentedNero 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
Comment #78
rimkashox CreditAttribution: rimkashox commentedSame 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 ! :)
Comment #79
rimkashox CreditAttribution: rimkashox commentedFor me problem is solved... It was site5 that was blocking outbound access to updates.drupal.org.
Comment #80
rimkashox CreditAttribution: rimkashox commentedall's good !
Comment #81
apaderno@rimkashox: Your problem may be resolved, but not other people's.
Comment #82
Jazzy CreditAttribution: Jazzy commentedHi!
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?
Comment #83
EPO CreditAttribution: EPO commentedIf 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.
Comment #84
Bastian-2 CreditAttribution: Bastian-2 commentedPlease unblock this IP
217.172.160.41
Comment #85
Logan Bear CreditAttribution: Logan Bear commentedProblem fixed for my site. Thanks.
Comment #86
sergo2 CreditAttribution: sergo2 commentedcan you unblock this ip: 81.169.145.74
thank you
Comment #87
nnewton CreditAttribution: nnewton commented74.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.
Comment #89
revxml CreditAttribution: revxml commentedIs 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.
Comment #90
apaderno@revxml: The issue is now closed; if you want somebody to look into this, you should open it.
Comment #91
kewlguy CreditAttribution: kewlguy commentedCan 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
Comment #92
zengenuity CreditAttribution: zengenuity commentedI'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.
Comment #93
zengenuity CreditAttribution: zengenuity commentedPlease 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.
Comment #94
Anonymous (not verified) CreditAttribution: Anonymous commentedHi
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
Comment #95
nnewton CreditAttribution: nnewton commentedNone of these IPs were blocked, but to be sure we have flushed our entire rule set. Nothing is blocked as of right now.
-N
Comment #96
kewlguy CreditAttribution: kewlguy commentedIt seems that this has solved my issues with a few different sites.
Thank You!
Comment #97
Anonymous (not verified) CreditAttribution: Anonymous commentedHi !
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
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
Comment #98
Gerhard Killesreiter CreditAttribution: Gerhard Killesreiter commentedCan 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.
Comment #99
leostar CreditAttribution: leostar commentedOK 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
Comment #101
Travis CreditAttribution: Travis commentedCheck 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:
Make sure your Drupal instance is actually fetching updates from Drupal before pointing fingers.
One step in that process is checking the 'variable' table.
Another is making sure nobody modified the UPDATE_DEFAULT_URL constant.
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.
Comment #102
tjiel CreditAttribution: tjiel commentedMay 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!
Comment #103
nnewton CreditAttribution: nnewton commented@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.
Comment #104
ArtMonkey CreditAttribution: ArtMonkey commentedHi. 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.
Comment #105
killes@www.drop.org CreditAttribution: killes@www.drop.org commented79.170.40.161 is not banned
Comment #106
steveoriolI have problem with 2 website on this server: cluster006.ovh.net [213.186.33.17] ... ?
Comment #107
virginie gerard CreditAttribution: virginie gerard commentedI have problem with 1 website on this server: cluster006.ovh.net [213.186.33.17] ??
Thank you.
Comment #108
nnewton CreditAttribution: nnewton commentedWe 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
Comment #109
steveoriolAny 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...
Comment #110
steveoriolCool ! 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