Linode Forum

[rickyalan]

Hi every one, I have two linode A and B under my account, A was running well, I just built a new server environment (LNMP) on B, and B works fine as well.

I clone the disk of B to A, and reboot it, everything works but one serious problem. The new configuration on A fails with PHP function Code: file_get_contents to retrieve contents from a URL
, which works fine on B.

I have modified /etc/hosts, /etc/hostname, /etc/resolv.conf, and /etc/network/interfaces

Is there any other configuration will cause the problem? thanks all.

[hybinet]

rickyalan wrote: The new configuration on A fails with PHP function Code: file_get_contents to retrieve contents from a URL
Exactly how does it "fail"? Does the function return something other than the actual contents of a URL, or does it return nothing at all? Does the page display an error, and if so, what does the error message say? (If not, make sure error_reporting is set to E_ALL so that all errors are caught. Also enable either display_errors or log_errors so that error messages are not simply discarded.)

What is the URL? Is it a public web page or API? (If so, make sure it's not down, by typing the URL into your browser.) Is it something on your own site? Does the URL contain a hostname that you made up?

What did you change in /etc/resolv.conf? Do they point at proper name servers for your datacenter? Is your linode able to access other sites properly? (Try updating your server using apt-get, yum, or whatever else your distro uses. If this fails, you have more serious problems with your network configuration.)

Is allow_url_fopen enabled in php.ini?

[rickyalan]

hybinet wrote: rickyalan wrote: The new configuration on A fails with PHP function Code: file_get_contents to retrieve contents from a URL
Exactly how does it "fail"? Does the function return something other than the actual contents of a URL, or does it return nothing at all? Does the page display an error, and if so, what does the error message say? (If not, make sure error_reporting is set to E_ALL so that all errors are caught. Also enable either display_errors or log_errors so that error messages are not simply discarded.)

What is the URL? Is it a public web page or API? (If so, make sure it's not down, by typing the URL into your browser.) Is it something on your own site? Does the URL contain a hostname that you made up?

What did you change in /etc/resolv.conf? Do they point at proper name servers for your datacenter? Is your linode able to access other sites properly? (Try updating your server using apt-get, yum, or whatever else your distro uses. If this fails, you have more serious problems with your network configuration.)

Is allow_url_fopen enabled in php.ini?

hi hybinet, thanks for your reply.
The URL is for paypal express checkout, the system configuration and php codes both worked fine on my linode B, but fails on A at this point.

The function only returns FALSE without any error message even in php error log file. The error stuffs are enabled.

the file /etc/resolv.conf contains the DNS IPs from "Remote Access" of my linode, and "options rotate" at the end.

I can use lynx visit any websites outside the linode, does that mean the networks is okay?

Is there any other extra changes to be done for the cloning?

[hybinet]

FALSE isn't very informative... Unfortunately, that's how a lot of PHP functions are.

If you can access your Linode and your Linode can access arbitrary external sites, that probably means that your networking is configured properly.

Can you use lynx, wget, curl, or any other command-line tool to fetch the same URL from your Linode? If you can, the problem is with your PHP configuration. If you can't, the problem might be with the specific URL. Maybe PayPal is denying access to your new IP address for some reason? Can you use the same command-line tool to fetch the same URL from your other Linode?

[rickyalan]

hybinet wrote: FALSE isn't very informative... Unfortunately, that's how a lot of PHP functions are.

If you can access your Linode and your Linode can access arbitrary external sites, that probably means that your networking is configured properly.

Can you use lynx, wget, curl, or any other command-line tool to fetch the same URL from your Linode? If you can, the problem is with your PHP configuration. If you can't, the problem might be with the specific URL. Maybe PayPal is denying access to your new IP address for some reason? Can you use the same command-line tool to fetch the same URL from your other Linode?

The function actually does a POST to https://api-3t.paypal.com/nvp, I'm confusing that the same PHP configuration works on linode B, but fails on A.

And the IP of A works fine with the URL on my old server configuration.

[glg]

rickyalan wrote: I clone the disk of B to A, and reboot it

Out of curiousity, why? Are you setting up a cluster?

[rickyalan]

glg wrote: rickyalan wrote: I clone the disk of B to A, and reboot it

Out of curiousity, why? Are you setting up a cluster?

Not a cluster.

I supposed to switch from lamp to lnmp, and don't want to shut the site down to long, so build lnmp on B and make sure everything works well then replace lamp on A.

[hybinet]

It will be really difficult to diagnose the issue unless more descriptive error messages can be captured. At the very least, we need to know what HTTP status code PayPal is returning, if at all.

I just tried a bunch of file_get_contents() function calls, and they all emit a descriptive warning (as well as returning FALSE) when any of the following errors occur: DNS resolution failure, unresponsive server, 403 forbidden, 404 not found, and 500 internal server error. If you're seeing FALSE but not an actual error message, check your error reporting settings again. Try producing obvious errors to confirm that error messages are actually being displayed/recorded.

If that fails, you'll need to find out the source of the error some other way. Did you write the code that contains the file_get_contents() function call in question? If it uses POST, I guess you already know how to juggle stream contexts and whatnot. Could you rewrite it to use something like the Requests library? That will allow you to see the HTTP status code, various headers, and all sorts of other information that file_get_contents() doesn't give you.

I understand this is a very frustrating situation for you. But since networking seems to be working fine according to you, I can't think of any obvious culprit.

If the above sounds like too much trouble, just cancel Linode A and use Linode B :roll:

[rickyalan]

hybinet wrote: It will be really difficult to diagnose the issue unless more descriptive error messages can be captured. At the very least, we need to know what HTTP status code PayPal is returning, if at all.

I just tried a bunch of file_get_contents() function calls, and they all emit a descriptive warning (as well as returning FALSE) when any of the following errors occur: DNS resolution failure, unresponsive server, 403 forbidden, 404 not found, and 500 internal server error. If you're seeing FALSE but not an actual error message, check your error reporting settings again. Try producing obvious errors to confirm that error messages are actually being displayed/recorded.

If that fails, you'll need to find out the source of the error some other way. Did you write the code that contains the file_get_contents() function call in question? If it uses POST, I guess you already know how to juggle stream contexts and whatnot. Could you rewrite it to use something like the Requests library? That will allow you to see the HTTP status code, various headers, and all sorts of other information that file_get_contents() doesn't give you.

I understand this is a very frustrating situation for you. But since networking seems to be working fine according to you, I can't think of any obvious culprit.

If the above sounds like too much trouble, just cancel Linode A and use Linode B :roll:

just tried to
Code:

<?php

$w = stream_get_wrappers();
echo 'openssl: ',  extension_loaded  ('openssl') ? 'yes':'no', "\n";
echo 'http wrapper: ', in_array('http', $w) ? 'yes':'no', "\n";
echo 'https wrapper: ', in_array('https', $w) ? 'yes':'no', "\n";
echo 'wrappers: ', var_dump($w);

$ch = curl_init();


curl_setopt($ch, CURLOPT_URL, "https://www.paypal.com");


curl_exec($ch);

echo curl_error($ch)."\n";

curl_close($ch);


?>

get the result Quote: openssl: yes
http wrapper: yes
https wrapper: yes
wrappers: array(16) {
[0]=>
string(13) "compress.zlib"
[1]=>
string(4) "tftp"
[2]=>
string(3) "ftp"
[3]=>
string(6) "telnet"
[4]=>
string(4) "dict"
[5]=>
string(4) "ldap"
[6]=>
string(5) "ldaps"
[7]=>
string(4) "http"
[8]=>
string(5) "https"
[9]=>
string(4) "ftps"
[10]=>
string(3) "php"
[11]=>
string(4) "file"
[12]=>
string(4) "glob"
[13]=>
string(4) "data"
[14]=>
string(4) "phar"
[15]=>
string(3) "zip"
}
GnuTLS recv error (-9): A TLS packet with unexpected length was received.

[rickyalan]

thanks all, Found the reason
The new version of PHP curl compiled with gnutls but not openssl, this makes the problem happen

[glg]

rickyalan wrote: glg wrote: rickyalan wrote: I clone the disk of B to A, and reboot it

Out of curiousity, why? Are you setting up a cluster?

Not a cluster.

I supposed to switch from lamp to lnmp, and don't want to shut the site down to long, so build lnmp on B and make sure everything works well then replace lamp on A.

That's what I kinda figured. If B is working, just keep it and swap the IP from A to B.

[hybinet]

rickyalan wrote: thanks all, Found the reason
The new version of PHP curl compiled with gnutls but not openssl, this makes the problem happen
How can this happen if you just cloned the Linode?

Ah, you didn't clone the whole Linode and forgot to mention that. Naughy naughty boy! :P