Since some weeks I do not get any update information, only timeouts. This is only on STRATO hosted websites. If you need the IP address, please contact me directly.

I tested the following, in node body field with enabled PHP filter module:

 // connection timeout
var_dump(file_get_contents('http://updates.drupal.org'));
 
// works
var_dump(file_get_contents('http://www.google.com')); 

Comments

killes@www.drop.org’s picture

Status: Active » Postponed (maintainer needs more info)

Please provide a traceroute.

rikibu’s picture

Status: Postponed (maintainer needs more info) » Active

Since two weeks I have the same issue.
From one day to the other the Drupal update functionality isn't able to find update information.
It only tells that everything is up to date and an error message is telling that there was a problem checking for updates.

Strange thing:
when I take this Drupal installation onto my local xampp server (including db) everything is running great. Drupal is able to run the update check...

conclusion:
It seems that drupal.org is blocking strato hosts...

sense-design’s picture

Sorry, just a shared hosting where I am not allowed to run any commands on console

killes@www.drop.org’s picture

I have access to a machine that is hosted by Strato and I have no problems getting update information.

Conclusion: It is either a specific IP that is blocked by us (in this case we need the IP) or something else.

rikibu’s picture

Maybe it is possible to put some php code inside our (share hosted) strato projects to find the information we need?

Hendrik53’s picture

There is an other thread about Strato and update problems. I have not found out what is wrong, but I've the idea that this has something to do with an IP6 address that is used. In the log both IP4 (Ipv4) and IP6 (IPv6) come up as Host.
I tried a localhost at home and disabled IPv6 support on the router. Site respons was much faster and no time-out problems.
I've added the extra lines to the config that should give it 90 seconds to repond. On the Strato server this did not work. Checking the time per module, it takes about 60 seconds to verify the core Drupal on the Strato server. Alle other modules are within 1 second.
Perhaps this info can help solving the issue.

rikibu’s picture

Still no change to the better... update requests by strato hosted Drupal sites are still blocked and I don't know how to fix that.

killes@www.drop.org’s picture

As I've said before: not all Strato IPs are affected. It is possible that some of their hosting plans do not allow outbound connections. Please contact Strato support about this.

sense-design’s picture

They say everything is working fine and I can load data from other sites except updates.drupal.org

rikibu’s picture

@killes@drupal.org

I (and a few other affected users of strato hosting service on drupalcenter.de) already reported this issue to Strato.

Strato says "this isn't our problem because our servers are running smoothly. Please contact the Drupal support because Drupal.org is blocking strato requests"

so it seems that Strato says that Drupal is responsible for this blocking issue... and Drupal says that Strato is responsible for this issue...

that means no one feels responsible for this issue...

remember: the update funcionality worked fine until mid of April 2013...

killes@www.drop.org’s picture

@sense-design sent me two IPs and we've verified that we are not blocking them.

Please ask Strato to provide a traceroute, maybe a block is somewhere in between.

rikibu’s picture

@killes@drupal.org

Can I send you the IP address of my strato domain too?

killes@www.drop.org’s picture

Only if it comes with a traceroute. :p

martijnkunstman’s picture

I experience exactly the same problem on two of my Drupal 7 sites running on a Strato shared hossting. (PowerWebAdvanced)
Sites running on my Strato VDS aren't affected.
I already contacted Strato multiple times stating this is a serious problem which makes a Strato shared hosting account less favourable for using Drupal.
Till now Strato imo does not take this problem seriously cause the only reaction i got (twice!) is: 'we do not support Drupal', completely ignoring the fact that the problem could be a server issue.
I suspect the shared hosting servers block access to/from: update.drupal.org.
I also get a timeout using: var_dump(file_get_contents('http://updates.drupal.org'));
While: var_dump(file_get_contents('http://www.google.com')); runs fine.
The problem started a few days before 18-04-2013 when i first contacted Strato.
Till now the problem exists.
I hope Strato takes this problem seriously otherwise i am forced to take my hosting elsewhere.
By the way: i am very content with running Drupal on Strato (crons a possible for example) and speed is ok.

( i also did a fresh custom Drupal install and a Starto one-click app install, both from the start (without any installed modules) faced the same problem not being able to receive update information.)

(currently i disabled the updatemanager on my affected sites and will enable them when the problem is fixed, i periodically check if the problem is already solved and will post here if that is the case.)

Question: are there any alternatives for checking for updates? (for example: receiving version information using a proxy)

martijnkunstman’s picture

I found a temporarily solution using a server that does not block updates.drupal.org doing the following:

!!!HACK CORE!!! file: update.fetch.inc

replace (+/- line 152): $xml = drupal_http_request($url);
with:
$xml = drupal_http_request("http://yourproxyserver/drupalproxy/proxy.php?url=".urlencode($url));

on yourproxyserver proxy.php content is:

if (isset($_GET['url']))
{
header ("Content-Type:text/xml");  
$url=$_GET["url"];
$url=urldecode($url);
$url="http://updates.drupal.org".str_replace("http://updates.drupal.org","",$url);
$data=file_get_contents($url);
echo($data);
}
prudal’s picture

Hi! Issue http://drupal.org/node/1979796 posted by AntoniaHH is unsolved;

Aside all details, most of all drupal-users with sites hosted by the major german provider "Strato" have the same problem: Update worked well since April, but does not work anymore since then.

Will drupal.org do something? Strato doesn't seem to care, pushes responsibility to drupal, see (in german) www.drupalcenter.de/node/46107

Thanks!

Mark

killes@www.drop.org’s picture

We can't do anything without a provided traceroute. People who can use proxies can probably also try to get a traceroute...

Look here:

http://www.adayinthelifeof.nl/2010/07/30/creating-a-traceroute-program-i...

(edit: wrong link)

Hendrik53’s picture

Yes, STRATO point to Drupal, saying their update servers block access from Strato. In Dutch the Strato response is:

Zeer geachte klant,

hartelijk dank voor uw aanvraag,

Bij deze wil ik u graag informeren over het technische ticket dat ik voor u heb aangemaakt met betrekking tot het updates van uw Drupal sites.

Op dit moment blokkeert de Drupal update server de aanvragen van STRATO.

Het is nu niet mogenlijk om met de Appwizzard updates uit te voeren.

U kunt wel handmatig de updates uitvoeren van uw Drupal sites.

Ik hoop u hierbij voldoende te hebben geinformeerd.

Met de vriendelijke groeten uit Berlijn

xxx
Customer Care

Hendrik53’s picture

I can change the code in update.fetch.inc but, what am i supposed to do with the text below "yourproxyserver proxy.php". Does this code belong to Drupal, or ???
Please explain how to set up the use of a proxy for drupal 7.22.

Hendrik53’s picture

For some reasons I believe the problem has to do with IP4 and IP6.

When I try to (in a dos box) "tracert -S www.mysite.nl update.drupal.org" I get an error that DNS translation failed.
When I do "tracert update.drupal.org" I get a list.
When I do "tracert -4 update.drupal.org" I get a list. So it responds to IP4.
When I do "tracert -6 update.drupal.org" I get an error. To my knowlegde this means that the "update.drupal.org" name could not be resolved for an IP6 address.

I tried to force IP4 with "tracert -4 -S www.mysite.nl update.drupal.org", but then I get the error that -S is only supported with IP6. And when I chage the -4 to -6 the name of the drupal site can not be resolved.

Perhaps someone knows if this "IP6 is not supported" could be the cause of this 'update' problem?

martijnkunstman’s picture

Hi Hendrik53,

Explaination:

replace (+/- line 152):

$xml = drupal_http_request($url);

with:

$xml = drupal_http_request("http://yourproxyserver/drupalproxy/proxy.php?url=".urlencode($url));

Instead of contacting the update url directly i send the update url as a querystring var to a php script running on a server that CAN make contact with updates.drupal.org.

yourproxyserver is the location/domain of the server that hosts the php file.

You should place the php file on this server and this is NOT a part of Drupal (or the server Drupal is hosted on).

In the php file the following takes place:

//check if a url querystring variable is set
if (isset($_GET['url']))
{
//make this ouput as a xml contenttype
header ("Content-Type:text/xml");  
//get the drupal update url
$url=$_GET["url"];
//decode it, because it was encoded
$url=urldecode($url);
//replace beginning of the url (http://...) for security reasons (i only want to fetch xml from http://updates.drupal.org)
$url="http://updates.drupal.org".str_replace("http://updates.drupal.org","",$url);
//read data xml from updates.drupal
$data=file_get_contents($url);
//echo it...
echo($data);
}

You can try to use my proxyserver and use the following url:
(so you don't have to host the php yourself, you can skip this part and only change update.fetch.inc

$xml = drupal_http_request("http://85.214.251.195/drupalproxy/proxy.php?url=".urlencode($url));

Let me know if this works for you.

I am not planning to keep this functionality up for a long period of time. So this is only a temporarily solution.
(for now you can make use of it, but i can give no guarantees or timespan for how long i will keep up this functionality.)

If you want you can contact me ;)

(i quess you are dutch, me to...)

c-logemann’s picture

The PHP Programm linked on #17 is very interesting and I learned a lot about traceroute and networks. But this solution is based on socket_create which needs special rights in the system. Even on my own shared setup with ssh access where I can do a traceroute CLI command I can't use this php commands. So I suggest to try another way with PHP.
Maybe somebody can use a pseudo shell like this module and type "traceroute updates.drupal.org" or maybe use this little script I just programmed and tested on two shared hosting servers I have access to:

$path_to_tr = 'traceroute'; //maybe use direct path like '/usr/sbin/traceroute'
$domain = 'updates.drupal.org';
$command = $path_to_tr . ' ' . $domain;

echo '<pre>';
system($command);
echo '</pre>';

I don't know if this is working on strato webservers. I will ask in german forum for testing this.

Edit: changed "passthru()" to system() in little script;

Hendrik53’s picture

Thanks Martijn.

I've put the php script on my home server (wamp) and modified the update file on the Strato server. It worked at once!

Although there are some more update problems with drupal modules or response. I've had this on my home server as well. Sometimes half the modules are grey (not verified). And sometimes I get an error updating a module. I thought of time out problems and put in settings.php this line at the bottom: $conf['update_max_fetch_time'] = 90;

After some manual updating of security fixes and module per module, evertything is now up tot date on both sites.

The errors I still got are:

UpdaterException: Unable to determine the type of the source directory. in Updater::factory() (line 99 of /mnt/web8/c0/96/53067996/htdocs/hnh79/includes/updater.inc).

An AJAX HTTP error occurred. HTTP Result Code: 500 Debugging information follows. Path: http://www.xxxx.nl/authorize.php?batch=1&id=139&op=do StatusText: Service unavailable (with message) ResponseText: UpdaterException: Unable to parse info file: . in Updater::getProjectTitle() (line 182 of /mnt/web8/c0/96/53067996/htdocs/hnh79/includes/updater.inc).

And I've had them before.

killes@www.drop.org’s picture

Status: Active » Fixed

I've received confirmation from Strato that this is fixed.

It turned out that indeed we blocked one of their IPs in a place where I hadn#t looked before.

martijnkunstman’s picture

I can confirm updates work again on Strato shared hosting.

I feel a bit sorry for blaming Strato and having send them quite a few 'blame' mails... i will be more careful in the future... ;)

@killes: thanks for fixing and checking this!

Status: Fixed » Closed (fixed)

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