curl problems API? (Plesk CentOS Nucleus P3 & ASL)

[12lamat]

Hello,

I have a new server with Centos6.5, plesk 11.3, Nucleus repo, Plesk PHP Panda for multiple php and ASL installed.

After migration of domains it seems there is no curl working. I realy don't know much about these things . I was happy i had it all up and running, but i do need curl working. Please help is needed. Anyone an idea?

Some apps have curl testing possebillities and they all give errors.

I noticed curl was not working because a WHMCS website and another applications were not connecting to the licenseserver. Eventualy the apps got a license update. I don't know how?

First WHMCS thought it was a Firewall issue so i contacted ASL support, they ruled that out.

Now i seem to have API problems too. I'm not able to reach Plesk through API and i not able to reach some apps on websites through API.

I think this is connected.....

Pklease help me figure this out.

Much appreciated ....

[prupert]

What do you mean by "curl is not working"? How exactly are you calling curl and what are the exact errors you are getting?

[12lamat]

I hope this gives you any directions:

For example:
in phpinfo I see:
Configure Command '--without-curl'

Additional .ini files parsed /etc/php.d/curl.ini

I excluded , curl_exec , curl_multi_exec from disable_functions on the local php.ini serverwide it is still disabled.

cURL Information 7.19.7
Age 3
Features
AsynchDNS No
Debug No
GSS-Negotiate Yes
IDN Yes
IPv6 Yes
Largefile Yes
NTLM Yes
SPNEGO No
SSL Yes
SSPI No
krb4 No
libz Yes
CharConv No
Protocols tftp, ftp, telnet, dict, ldap, ldaps, http, file, https, ftps, scp, sftp
Host x86_64-redhat-linux-gnu
SSL Version NSS/3.14.0.0
ZLib Version 1.2.3
libSSH Version libssh2/1.4.2

Sometimes i found in ASL PHP warning: Module 'curl' already loaded in Unknown on line 0

Or while using shell see below:

Installatron Install & Repair Utility,
Rev. 3.0 (2013-02-20)

Internal PHP Binary: /usr/bin/php
PHP Warning: Module 'curl' already loaded in Unknown on line 0
PHP Warning: Unknown: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CET/1.0/no DST' instead in Unknown on line 0
Detecting supported Fetch drivers...
- Testing System CURL Binary /usr/bin/curl... working.
- Testing PHP CURL Extension... working.

Choose a Fetch driver:
[0] System CURL Binary /usr/bin/curl
[1] PHP CURL Extension
Using: [0] System CURL Binary /usr/bin/curl

Testing ionCube loaders...
- Existing loader: Testing... working.

Checking license...
PHP Binary Version: 5.3.28 (major version 5).....
done.

[prupert]

I excluded , curl_exec , curl_multi_exec from disable_functions on the local php.ini serverwide it is still disabled.

If you want ASL to manage these settings do not change them manually in php.ini, and do not use third party tools to manage these settings.
See https://www.atomicorp.com/wiki/index.ph ... figuration

[12lamat]

Okay i include it again.

So i cant make api contact to any website I think.

[12lamat]

When accessing https://tinyweb.be/intergratie/index.php/admin/l... with APC enabled, PHP crashes with the following entry in dmesg:

php-fpm[13465]: segfault at 600000001 ip 00000330e753695e sp 000003f0cfe83bd8 error 4 in libc-2.12.so[330e74ad000+18b000]
grsec: From 144.76.67.84: Segmentation fault occurred at 0000000600000001 in /usr/sbin/php-fpm[php-fpm:13465] uid/euid:10006/10006 gid/egid:505/505, parent /usr/sbin/php-fpm[php-fpm:13420] uid/euid:0/0 gid/egid:0/0
grsec: denied exec of usermode helper binary /usr/libexec/abrt-hook-ccpp located outside of /sbin and system library paths
Core dump to |/usr/libexec/abrt-hook-ccpp 11 0 13465 10006 505 1391016283 e pipe failed


https://tinyweb.be/intergratie/index.php file is encrypted with ionCube, so it's not possible to determine what code crashes PHP.

When we comment out APC module, the page loads.

[scott]

Ive seen that before with fcgi, APC has a lot of bugs with it. Its been bad enough that php.net had pulled their plans to integrate APC as the default.

[prupert]

I concur with Scott. Zend Opcache is much better than APC for opcode caching, less bugs, more performance. Packages are available in EPEL for stock CentOS PHP packages, but not yet in Atomic. Perhaps you can ask?