Facebook
Twitter
2
2xav
Guest
Hello,
I know it's possible this problem is not related to Plesk but I'm posting it in a few places in hopes someone will have a similar problem and a solution. I saw something in this forum about Plesks new iconCube loader causing problems with the Zend optimizer and that made me wonder if it was somehow related to my problem.
I have a small reseller business and my ISP is moving all accounts to a new server running plesk 8.0.1 on Linux version 2.6.9-42.ELsmp ([email protected]) (gcc version 3.4.6 20060404 (Red Hat 3.4.6-2)).
A few of my sites use the Payflow Pro SDK executed from PHP (not the PHP pfpro_extension). For some reason, the pfpro binary is unable to connect to the payflow servers when executed from a php page accessed via a browser but when executed from the command line with something like: php -q test.php, it connects and works just fine. I've tried just about every permutation of running this command from PHP using exec, popen and system. I've tried the two different Linux versions of the SDK. The NOC tech support even compiled and loaded the pfpro_extensions for us and using pfpro_process(...) produced same result. I've also tried setting up new accounts instead of using the transferred one and it doesn't matter, same result. So it doesn't seem to be related to the particular virtual host configuration.
My hosting provider gave me access to a temporary account on one of their slightly older servers that is running Plesk 7.5, Apache 2.0.52 and PHP 4.3.9 and the same script (see below) works just fine so this has become a real mystery. It's essentially exactly the same system except for Plesk 7.5 vs 8. I've tried the same script on 3 other linux systems in different locations and all work fine. I've been told by the ISP and the NOC that there is no firewall enabled yet and I've verified that the php command fopen("https://....") works to prove to myself that php could open a socket on 443. I'm hoping someone would have an idea why the pfpro lib when executed from Apache/PHP would not be able to open an outside connection but would work fine when executed from a shell command line.
Just for reference, here is the code in my test.php:
When executed from the command line: 'php -q test.php', the result looks like:
RESULT=0&PNREF=V79A0A4CEE44&RESPMSG=Approved&AUTHCODE=993PNI&AVSADDR=N&AVSZIP=Y&IAVS=N
When executed from the browser:
RESULT=-1&RESPMSG=Failed to connect to host
Apache Information:
Server version: Apache/2.0.52
Server built: Dec 15 2005 04:09:14
Server's Module Magic Number: 20020903:9
Architecture: 32-bit
Server compiled with....
-D APACHE_MPM_DIR="server/mpm/prefork"
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D HTTPD_ROOT="/etc/httpd"
-D SUEXEC_BIN="/usr/sbin/suexec"
-D DEFAULT_PIDLOG="logs/httpd.pid"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_LOCKFILE="logs/accept.lock"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="conf/mime.types"
-D SERVER_CONFIG_FILE="conf/httpd.conf"
PHP info from the command line:
PHP 4.3.9 (cgi) (built: Jun 26 2006 09:46:03)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies
with the ionCube PHP Loader v3.1.16, Copyright (c) 2002-2006, by ionCube Ltd.
I know it's possible this problem is not related to Plesk but I'm posting it in a few places in hopes someone will have a similar problem and a solution. I saw something in this forum about Plesks new iconCube loader causing problems with the Zend optimizer and that made me wonder if it was somehow related to my problem.
I have a small reseller business and my ISP is moving all accounts to a new server running plesk 8.0.1 on Linux version 2.6.9-42.ELsmp ([email protected]) (gcc version 3.4.6 20060404 (Red Hat 3.4.6-2)).
A few of my sites use the Payflow Pro SDK executed from PHP (not the PHP pfpro_extension). For some reason, the pfpro binary is unable to connect to the payflow servers when executed from a php page accessed via a browser but when executed from the command line with something like: php -q test.php, it connects and works just fine. I've tried just about every permutation of running this command from PHP using exec, popen and system. I've tried the two different Linux versions of the SDK. The NOC tech support even compiled and loaded the pfpro_extensions for us and using pfpro_process(...) produced same result. I've also tried setting up new accounts instead of using the transferred one and it doesn't matter, same result. So it doesn't seem to be related to the particular virtual host configuration.
My hosting provider gave me access to a temporary account on one of their slightly older servers that is running Plesk 7.5, Apache 2.0.52 and PHP 4.3.9 and the same script (see below) works just fine so this has become a real mystery. It's essentially exactly the same system except for Plesk 7.5 vs 8. I've tried the same script on 3 other linux systems in different locations and all work fine. I've been told by the ISP and the NOC that there is no firewall enabled yet and I've verified that the php command fopen("https://....") works to prove to myself that php could open a socket on 443. I'm hoping someone would have an idea why the pfpro lib when executed from Apache/PHP would not be able to open an outside connection but would work fine when executed from a shell command line.
Just for reference, here is the code in my test.php:
PHP:
$lib="bin/lib";
$cert="certs";
$ld_lib_path = getenv("LD_LIBRARY_PATH"); // Get current lib path
putenv("LD_LIBRARY_PATH=$lib:$ld_lib_path"); // Add Credit card lib to front
putenv("PFPRO_CERT_PATH=$cert"); // Add Cert path to env
$amt = date("H.i");
$url = 'test-payflow.verisign.com';
$parmList = 'TRXTYPE=S&TENDER=C&PWD=xxxx&USER=xxxx&VENDOR=xxxx&PARTNER=xxxx&ACCT=5105105105105100&EXPDATE=1209&AMT='.$amt.'&STREET=437 Any Street&ZIP=95071';
unset($output);
$resultcodes=exec('bin/pfpro '.$url. ' 443 "'.$parmList.'" 30 2>&1', $output, $return_value);
echo "RESULTS:<BR><PRE>\n";
print_r($resultcodes);
echo "<BR></PRE>\n";
exit;When executed from the command line: 'php -q test.php', the result looks like:
RESULT=0&PNREF=V79A0A4CEE44&RESPMSG=Approved&AUTHCODE=993PNI&AVSADDR=N&AVSZIP=Y&IAVS=N
When executed from the browser:
RESULT=-1&RESPMSG=Failed to connect to host
Apache Information:
Server version: Apache/2.0.52
Server built: Dec 15 2005 04:09:14
Server's Module Magic Number: 20020903:9
Architecture: 32-bit
Server compiled with....
-D APACHE_MPM_DIR="server/mpm/prefork"
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D HTTPD_ROOT="/etc/httpd"
-D SUEXEC_BIN="/usr/sbin/suexec"
-D DEFAULT_PIDLOG="logs/httpd.pid"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_LOCKFILE="logs/accept.lock"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="conf/mime.types"
-D SERVER_CONFIG_FILE="conf/httpd.conf"
PHP info from the command line:
PHP 4.3.9 (cgi) (built: Jun 26 2006 09:46:03)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies
with the ionCube PHP Loader v3.1.16, Copyright (c) 2002-2006, by ionCube Ltd.
