Critical: Keep Getting Call To Undefined Function Crypt_Random() When Trying To Install Blesta

[Alex Vojacek]

Hello there, i'm not new to blesta, i've been using it since more than a year now.

 

I always used it in a VPS configured by myself,  Centos 6.5 with php 5.4 and nginx.

 

Everything was working just fine, up until i tried to update the license (reissue this site dashboard).

 

Now everything stopped working on the admin so I did a fresh reinstall.

 

Now each and every time i try to install it, it all goes well up to the point of asking the license,  where i enter everything blesta responds with:

 

Call to undefined function crypt_random() on line 1660 in /home/blesta/alex/vendors/phpseclib/Crypt/RSA.php

 

 

I know i have that file and every other file in there, I already tried blesta 3.3.2 and blesta 3.4 from scratch, no luck.

 

All the php requirements are meet,  i even tried insstalling all packages for seclib

 

yum install php-phpseclib*

 

 

Still no luck,  this NEVER happened to me before,  I tried remi packages for php 5.4, php 5.5 (with included fix in blesta) and php 5.6,  they all give me the same result.

 

 

This is killing my bussiness, clients can't login since I don't have a billing system anymore, this is critical,  can anybody help me?

[Alex Vojacek]

The problem lies in blesta trying to use php include path, but the include path which is default for CentoOS does not have proper permissions, so, you have to force a path with a proper permission in there and IT WILL WORK.

 

I don't know what blesta is doing but i suspect it uses RSA to decode something and php is trying to put this into the session path, which not having the correct permission will not work and then php will throw an error in the RSA.

 

I repeat this so it's clear,  Centos will NOT work on the default path, you have to manually include the path as I stated and it will work. I tried this 5 times in a row on a new VPS just to be sure it was this and I confirm it once again now.

 

Solution:

 

Put this into /etc/php.ini

 

include_path = /usr/share/php

 

make sure the directory has correct permissions and restart php and installer should work properly.

[Alex Vojacek]

Nobody?

 

I find it really hard to understand why installing this on a simple VPS will always get me the same error.  Does anyone use a VPS with blesta?.  I cannot be the only one with this problem !

[Michael]

Nobody? Not seen another thread: http://www.blesta.com/forums/index.php?/topic/3794-install-error/ ?

 

As for VPS, I use a VPS for Blesta and my site but I use Apache and I only know 4 people with this issue (You, the other OP, a mates mate who uses Nginx and a client who uses Vesta).

[Alex Vojacek]

Well, i can confirm this happens when you install nginx, since it wont have the values specified in that thread by default, in fact, it has the admin value set and not visible as default.

 

Just to state this for any people experiencing this issue with any VPS using nginx,  you need to manually add this value to /etc/php.ini

 

include_path = /usr/share/php
 

 

and Blesta will install perfectly without a single hitch.

 

This was a really good find,  it should be documented since the majority using apache wont face this issue.  Thanks to all and specially to Max for finding the issue.

[Cody]

Attached is a test script you can execute on your server to help diagnose issues with setting include paths.

 

To use, unzip test_include_path.zip, then run it once via your web server, and via CLI. You should have the same exact result for each, printing "SUCCESS!!" at the bottom.

php test_include_path.php

Expected output:

php test_include_path.php
Current include path: .:/usr/bin/pear
Modifying include path to include: /var/www/html/include_path_test/includes
Include path is now: .:/usr/bin/pear:/var/www/html/include_path_test/includes
Success. Attempting to a include file. Should print "SUCCESS!!" below...

SUCCESS!!

If you don't receive a success, your php.ini file is configured improperly, or your user does not have permission to execute files.

include_path_test.zip

[Alex Vojacek]

This is FANTASTIC news !.

 

I'm sure it's one more step to iron out installation issues and I'm sure a lot of people using nginx will appreciate.  Thanks so much for your hard work Cody !

[Max]

Well, i can confirm this happens when you install nginx, since it wont have the values specified in that thread by default, in fact, it has the admin value set and not visible as default.

 

Just to state this for any people experiencing this issue with any VPS using nginx,  you need to manually add this value to /etc/php.ini

 

include_path = /usr/share/php

 

That's actually a bit strange.

If you do not explicitly set the include_path setting in php.ini, the defaults do should work.

I do not set that value there myself.

 

Still wonder if the real problem isn't in any of your other (php-fpm related) configuration files.

And that making the setting in php.ini perhaps prevents the other configuration file from imposing the restriction, as a side effect.

But either way, glad it solved it for you.

[Alex Vojacek]

With php.ini  and   include_path = /usr/share/php

 

 

Current include path: /usr/share/php Modifying include path to include: /home/blesta/alex/test/includes Include path is now: /usr/share/php:/home/blesta/alex/test/includes Success. Attempting to a include file. Should print "SUCCESS!!" below... SUCCESS!!

 

 

Centos recently installed with EPEL + remi + nginx + php-fpm  default (no tweaking at all)

 

Current include path: .:/usr/share/pear:/usr/share/php Modifying include path to include: /home/blesta/alex/test/includes Include path is now: .:/usr/share/pear:/usr/share/php:/home/blesta/alex/test/includes Success. Attempting to a include file. Should print "SUCCESS!!" below... SUCCESS!!

 

Be adviced that the default "didn't" worked with me and gave me errors in RSA.

[Alex Vojacek]

That's actually a bit strange.

If you do not explicitly set the include_path setting in php.ini, the defaults do should work.

I do not set that value there myself.

 

Still wonder if the real problem isn't in any of your other (php-fpm related) configuration files.

And that making the setting in php.ini perhaps prevents the other configuration file from imposing the restriction, as a side effect.

But either way, glad it solved it for you.

 

 

With Linux, there is no such thing as "strange",  at least in my book

[oasisfleeting]

It's definitely not php-fpm settings as I'm only using nginx as a front end reverse proxy (apache in the back) and don't even use php-fpm but I came across this problem also.

Prior to adding the include path explicitly as stated above my php info already reported the include path as .:/usr/share/pear:/usr/share/php

So this error makes no sense to me at all nor does the fix.

 

Took me 4 days over the course of a month to diagnose so thank you Alex and Alex only.

[Max]

It's definitely not php-fpm settings as I'm only using nginx as a front end reverse proxy (apache in the back) and don't even use php-fpm but I came across this problem also.

 

As I mentioned in the other thread, problematic settings can also be in Apache's configuration files.

 

http://www.blesta.com/forums/index.php?/topic/3794-install-error/?p=28928

[oasisfleeting]

So, let me see if I have this correct.

 

The problem may or may not be in nginx configurations or

the problem may or may not be in apache configurtions or 

the problem may or may not be in php configuations or

the problem may or may not be in phpseclib pathfinding configurations or

the problem may or may not be in blesta configurations.

 

Gee thanks.

 

I know you guys have struggled with this issue just by looking at your ten million checks around the includes of these phpseclib files. Somebody isn't being one hundred about the underlying problem here. 

[Alex Vojacek]

May I suggest the developers to take this problem seriously and include the "test for the session path"  onto the installer? It will save a lot of time to people who comes from a VPS trying to install blesta onto CentOS (which is the OS of choice for hosting).

Since CentOS clearly set this session path wrong, it should be mandatory to test for this to work properly before installing the software, this will avoid weird error messages (like the one I had) and the debugging should be much more easy then.

[Michael]

May I suggest the developers to take this problem seriously and include the "test for the session path"  onto the installer? It will save a lot of time to people who comes from a VPS trying to install blesta onto CentOS (which is the OS of choice for hosting).

Since CentOS clearly set this session path wrong, it should be mandatory to test for this to work properly before installing the software, this will avoid weird error messages (like the one I had) and the debugging should be much more easy then.

 

Or just use Ubuntu I had no issues when installing it on a clean fresh Ubuntu. But I don't see why Centos would be any different unless you do install Nginx. I will have to check one day with Centos 7.

[Cody]

May I suggest the developers to take this problem seriously and include the "test for the session path"  onto the installer? It will save a lot of time to people who comes from a VPS trying to install blesta onto CentOS (which is the OS of choice for hosting).

 

Well, you can't even install Blesta without phpseclib working correctly, so I don't think that an additional check in the installer is necessary. The error displayed in that case is actually quite specific. Moreover, the issue is not with CentOS per se, as we have dozens of installs of CentOS and this is not an isuse for any one of those.

 

Since CentOS clearly set this session path wrong, it should be mandatory to test for this to work properly before installing the software, this will avoid weird error messages (like the one I had) and the debugging should be much more easy then.

 

Just because php can't find a particular resource being requested on the include path doesn't mean the php.ini file is configured incorrectly. While it may be the issue if you are running exactly CentOS 6.5 with php 5.4 and nginx, it is not definitively the reason.

Also, CentOS 7 has been out for quite a while, has anyone been able to duplicate there? We haven't, just FYI.

[PauloV]

Paul is right, this is not an CentOS issue (we use centos 6.x on all our servers), the problem, that is not really a problem is on some aditional config in PHP.ini

P.S- Cannot reproduce the problem on fresh Centos 6 with default latest cpanel with blesta.

[Paul]

Another customers experienced this issue on cPanel with PHP 5.2.17 due to the following file:

 

/usr/local/apache/conf/userdata/std/2/USER/cp_php_magic_include_path.conf. The solution was to comment out the line:

 

php_admin_value include_path ".:/usr/lib/php:/usr/local/lib/php:/home/USER/php"

 

#

[Cody]

Also worth pointing out, the script I posted in this thread showed there was an issue. PHP is unable to set the include path if the include path is defined in an Apache conf file. Why that is, I'm not sure. Bug with PHP? So far haven't seen any reports of this issue with people running PHP 5.5+.

[Michael]

Another customers experienced this issue on cPanel with PHP 5.2.17 due to the following file:

 

/usr/local/apache/conf/userdata/std/2/USER/cp_php_magic_include_path.conf. The solution was to comment out the line:

 

php_admin_value include_path ".:/usr/lib/php:/usr/local/lib/php:/home/USER/php"

 

#

 

5.2.x ouch.

[Max]

/usr/local/apache/conf/userdata/std/2/USER/cp_php_magic_include_path.conf. The solution was to comment out the line:

 

php_admin_value include_path ".:/usr/lib/php:/usr/local/lib/php:/home/USER/php"

 

 

 

Bug with PHP?

 

 

No, not a bug in PHP itself.

By design PHP made "php_value" overridable by code, "php_admin_value" not.

 

The question however is which package added that config file, which is using the php_admin_value directive, where they should be using php_value.

 

 

And main problem with CentOS is that CentOS itself tend to only have older versions of software, so people resort to using third party repositories, and often more than one.

Which complicates finding the problem even more.

[Max]

/usr/local/apache/conf/userdata/std/2/USER/cp_php_magic_include_path.conf

 

That particular one seems to come from cPanel's broken "PHP Magic User Loader" add-on.

 

https://forums.cpanel.net/threads/fatal-error-cannot-redeclare-_pear_call_destructors-previously-declared.123693/#post-552541

[Cody]

At any rate, should be a moot issue when Blesta 4 comes out.