Cloning problem
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
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.
11 Replies
@rickyalan:
The new configuration on A fails with PHP function
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 errorreporting is set to EALL so that all errors are caught. Also enable either displayerrors or logerrors 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 allowurlfopen enabled in php.ini?
@hybinet:
@rickyalan:The new configuration on A fails with PHP function
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 errorreporting is set to EALL so that all errors are caught. Also enable either displayerrors or logerrors 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 allowurlfopen 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?
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?
@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?
The function actually does a POST to
And the IP of A works fine with the URL on my old server configuration.
@rickyalan:
I clone the disk of B to A, and reboot it
Out of curiousity, why? Are you setting up a cluster?
@glg:
@rickyalan: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.
I just tried a bunch of filegetcontents() 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 filegetcontents() 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
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
@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 filegetcontents() 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 filegetcontents() 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
? That will allow you to see the HTTP status code, various headers, and all sorts of other information that filegetcontents() doesn't give you. Requests libraryI 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
get the result > 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.
The new version of PHP curl compiled with gnutls but not openssl, this makes the problem happen
@rickyalan:
@glg:
@rickyalan: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.
@rickyalan:
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!