All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
cURL, not being able to resolve a hostname
This is something weird, I have been spending the last few days trying to get Google+ sign in button working, I also tried Persona (from Mozilla) just so that users don't have to remember another user/pw combination.
I have been running into this issue, cURL is not able to resolve the google account page. Here is the error:
http://hastebin.com/baxasagoci.cmake
And here is the page from the same vps:
http://snapr.pw/i/d77e76edd2.png
Now the weirdest part is that it is only happening on this vps. I tried on another vps from the same provider in the Netherlands, I also tried on my Rasperry Pi in Rotterdam (PCExtreme, also NL) and both are working fine. This is the only vps the problem occurs. Both servers have the same /etc/resolv.conf. I tried the most recent source from Github but also a older one from a tutorial found online. Both produce the same error. And it isn't google's fault because Persona is also giving me problems.
To be clear, I don't really need this to be fixed, I just want to know why this is happening.
Comments
accounts.google.com seems to have both ipv4 and ipv6 address. How about your VPS servers, do they have ipv6? Is it working? Also what's in /etc/gai.conf, is there anything that's not a comment there?
@rds100
cat /etc/gai.conf#prefer IPv4 over IPv6 precedence ::ffff:0:0/96 100(they are exactly the same)
They both have 1 IPv4 and 16 IPv6 ip's. The only difference between those two vps's are the OS (Debian 6 and 7). Also both running lighttpd.
And what's in resolv.conf ? Can you ping and ping6 accounts.google.com from both VPSes?
On both vps'es /etc/resolv.conf are the same.
nameserver 8.8.8.8 nameserver 8.8.4.4From VPS1 where the problem occurs:
http://hastebin.com/vapigubapi.avrasm
From VPS2 where the problem doesn't occur:
http://hastebin.com/gelehowina.avrasm
So both ipv4 and ipv6 are working fine. Don't know then, strace the failing program and see what it tries to do.
In my opinion it's just because you have to follow redirections in curl: "curl -L accounts.google.com" works for me
You can try
curl -v -i accounts.google.comto get something more verbose. -v for verbose and -i to include the HTTP response headers. If you're getting the same issue...curl --help | grep ipv4 -4, --ipv4 Resolve name to IPv4 addressSince you're using a PHP library I suspect that it's still trying to use IPv6 regardless of precedence... have a look here stackoverflow.com/questions/11220416/php-curl-curlopt-ipresolve
particularly
curl_setopt($c, CURLOPT_IPRESOLVE, CURL_IPRESOLVE_V4);
Why do you think it doesnt resolve it? There is simply a HTTP 302 redirect.