fsockopen won't connect on port 80 to akismet

[WindyT]

The server hasn't been connecting to akismet to verify api keys in quite a while. We've helped the clients by hard coding the keys in, which works but it's a kludge. We suspect the slowness in the multiple wordpress blogs on our server has to do with interfacing with akismet.com, and rest.akismet.com

Naturally, I suspected the firewall, and messing with the allowed IPs didn't do the trick. Turning off the firewall didn't do the trick. (I'm using Chirpy's ConfigServer Firewall, and thanks Chirpy!)

I've done a bit of searching here and on the Wordpress forums, but most searches come up with the issue, but not the solution, which I'm asking here.

It seems that fsockopen isn't connecting. I found a bit of code to test, and here's what I'm using on my personal site on the server:

<?php
$fp = fsockopen("rest.akismet.com", 80, $errno, $errstr, 30);
if (!$fp) {
        echo "$errstr ($errno)<br />\n";
} else {
        $out = "GET / HTTP/1.1\r\n";
        $out .= "Host: rest.akismet.com\r\n";
        $out .= "Connection: Close\r\n\r\n";
 
        fwrite($fp, $out);
        while (!feof($fp)) {
                echo fgets($fp, 128);
        }
        fclose($fp);
}
?>

and the resulting error from the webpage after it times out:

Warning: fsockopen() [function.fsockopen]: unable to connect to rest.akismet.com:80 (Connection timed out) in /home/mysite/public_html/testakismet.php on line 2
Connection timed out (110)

The page doesn't throw any errors in the apache logs.

I read somewhere I might have to allow the akismet URL in the
/etc/resolv.conf
but read somewhere else I have to make this resolv.conf available to the
/home
directory so normal webpage calls can use it.

Is this a CPanel issue? A CentOS issue, or a Linux/apache security issue?


---

Details on my server that has about 90 accounts on it:

cPanel 11.24.4-R36167 - WHM 11.24.2 - X 3.9
CENTOS 5.3 x86_64 standard on srv02
Server Version: Apache/2.0.63 (Unix) mod_ssl/2.0.63 OpenSSL/0.9.8e-fips-rhel5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 PHP/5.2.9
knl: 2.6.18-128.1.16.el5 #1 SMP Tue Jun 30 06:07:26 EDT 2009 x86_64

[eth00]

Have you tried to connect via telnet? That will let you at least know if it is at all related to php or if it is on a server/network level

telnet rest.akismet.com 80

what about connect to it in general?

traceroute rest.akismet.com
ping rest.akismet.com

I was able to ping the site just fine and the traceroute gets to databank.com then is stopped by a firewall

[WindyT]

Originally Posted by eth00

Have you tried to connect via telnet? That will let you at least know if it is at all related to php or if it is on a server/network level

telnet rest.akismet.com 80

what about connect to it in general?

traceroute rest.akismet.com
ping rest.akismet.com

I was able to ping the site just fine and the traceroute gets to databank.com then is stopped by a firewall

Negative results for "rest.aksimet.com" and positive for "akismet.com"
(they have different IPs. As mentioned earlier, I've greenlighted all akismet related IPs through the firewall)

so, on a hunch, I took out the "rest."

Changing my code in my test script above from
rest.akismet.com
to
akismet.com

changes the result to

HTTP/1.1 200 OK Content-type: text/html Content-Length: 16 Date: Tue, 07 Jul 2009 03:42:03 GMT Server: LiteSpeed Connection: close Invalid API key.

So, the webpage _can_ make a connection to akismet.com, but not to rest.akismet.com
This means it looks like it's on akismet's end. Funny, because so many times I've seen the "Check the settings on your server" as a reply to issues posed on this topic by others.

Thanks for the clue. My question is still unresolved, but I know more now than I did. I hope to update this thread if I find out more, and if anyone has an idea, feel free.

In the meantime, I'll experiment with the akismet api key checking code within the Wordpress admin page to see what happens when I remove the "rest." from the code. It shouldn't work. I'll do that tomorrow.

[Spiral]

Run a tracert between your server and both addresses

Nevermind: I just pulled the zone information for the hosts
for rest.akismet.com and found out that they are actually splitting
the traffic and load balancing between 4 different servers split between
2 data center locations and one of those locations is totally down so
the traffic sent to those mirrors is just dead stopping in route.

[eth00]

# telnet rest.akismet.com 80
Trying 72.233.69.3...
Connected to rest.akismet.com (72.233.69.3).
Escape character is '^]'.

I was able to connect on port 80. If what spiral is saying is right you should be able to set the above IP in /etc/hosts and have it work ( though it will not be as redundant).

Before doing that I would make sure it at least works:
telnet 72.233.69.3 80

[WindyT]

Originally Posted by eth00

# telnet rest.akismet.com 80
Trying 72.233.69.3...
Connected to rest.akismet.com (72.233.69.3).
Escape character is '^]'.

I was able to connect on port 80. If what spiral is saying is right you should be able to set the above IP in /etc/hosts and have it work ( though it will not be as redundant).

Before doing that I would make sure it at least works:
telnet 72.233.69.3 80

Wow. Bingo. I had already put one of the IPs listed for rest.akismet.com in
/etc/hosts
but it was the one for the apparently dead connection.

72.233.56.139 rest.akismet.com

worked.

Now the akismet api key checking page confirmed the akismet key instantly.

This is solved. THANK YOU.
And thanks to Spiral who checked that one of the IPs being split off was down, something I don't think Akismet folks may not even know.

[Spiral]

Originally Posted by WindyT

And thanks to Spiral who checked that one of the IPs being split off was down, something I don't think Akismet folks may not even know.

You're welcome!

First thing I generally do when network connectivity is involved
is "tracert" and "dig" the destination and then check the results
to make sure there isn't some network issue going on between
the source and destination locations.

Pretty often it will turn out some internet netsplit or some
routing or backbone issue makes it so that you can't reach
a site and people often forget about that.