ionCube loader 0 to 10.3.4 update is available.

JohnyByk

Verified User
Joined
Mar 7, 2012
Messages
251
Exactly like in subject,
after this:
Code:
/usr/local/directadmin/custombuild/update
/usr/local/directadmin/custombuild/versions

I see this:
Code:
Latest version of ionCube: 10.3.4
[B]ionCube loader 0 to 10.3.4 update is available.[/B]

I have ionCube installed - the newest version.
What's wrong? :)

Regards
 
Hello,

They check ionCube version this way:

Code:
/usr/local/bin/php -v | grep ionCube | grep -m1 -o ' v[^,]*' | cut -dv -f2

What do you see? And what PHP versions do you have?
 
I see nothing.

When i check version of ionCube in that way:
Code:
/usr/local/php71/bin/php -v| grep ionCube | grep -m1 -o ' v[^,]*' | cut -dv -f2
10.3.4

Code:
[B]/usr/local/bin/php -v[/B]
PHP 7.1.29 (cli) (built: May  6 2019 09:51:11) ( ZTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2018 Zend Technologies

[B]/usr/local/php71/bin/php -v[/B]
PHP 7.1.29 (cli) (built: May  6 2019 11:12:05) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2018 Zend Technologies
    with the ionCube PHP Loader (enabled) + Intrusion Protection from ioncube24.com (unconfigured) v10.3.4, Copyright (c) 2002-2019, by ionCube Ltd.
    with Zend OPcache v7.1.29, Copyright (c) 1999-2018, by Zend Technologies

The same php version but different date compilation?
In php info i see version with ionCube.

It's possible so /usr/local/bin/php and /usr/local/php71/bin/php are different? Why?
 
In the post #2 I've posted the code-snippet from the build script of custombuild/directadmin. They don't use your variation.

I have no idea why you have two php binaries with different compile date. Probably you've recently changed mod_php to php-fpm.

Try and rebuild PHP/ionCube and see whether or not it helps.
 
Rebuild ionCube dosen't help but cp /usr/local/php71/bin/php /usr/local/bin/php helps ;)

All works fine (for now).

In my opininon thats heppen when i change php_relase or php_mode in options.conf and compile php withe expert mode without using ./build php n, i guess :)

Regards
 
It first happened to me when I changed in options.conf php1 from 7.2 to 7.3 and recompiled using custombuild.

Later when I additionally added third and fourth PHP, the /usr/local/bin/php and php-cgi resulted to be the latter (the forth one). Now here is what happens:

Code:
root@srv2:/ # /usr/local/bin/php-cgi -v
PHP 5.6.40 (cgi-fcgi) (built: May  1 2019 17:48:56)
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies

root@srv2:/ # /usr/local/php56/bin/php-cgi -v
PHP 5.6.40 (cgi-fcgi) (built: May  1 2019 18:02:03)
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
    with the ionCube PHP Loader v10.3.6, Copyright (c) 2002-2019, by ionCube Ltd.
    with Suhosin v0.9.38, Copyright (c) 2007-2015, by SektionEins GmbH

So clearly what's inside /usr/local/bin/php* is different from what is in /usr/local/phpXX/bin/php*

And for some reason whatever is in /usr/local/bin is always the latest php that was compiled in the system by DA.

Here are the binaries in /usr/local/bin at the moment:

Code:
root@srv2:/ # ll /usr/local/bin | grep php
-rwxr-xr-x    1 root  wheel  33978174 May  1 17:49 php*
-rwxr-xr-x    1 root  wheel  33884018 May  1 17:49 php-cgi*
-rwxr-xr-x    1 root  wheel      3434 May  1 17:49 php-config*
-rwxr-xr-x    1 root  wheel      4526 May  1 17:49 phpize*

Here is what I have in /usr/local/php56/bin:

Code:
root@srv2:/ # ll /usr/local/php56/bin | grep php
lrwxr-xr-x  1 root  wheel        26 May  1 18:03 php@ -> /usr/local/php56/bin/php56
lrwxr-xr-x  1 root  wheel        30 May  1 18:03 php-cgi@ -> /usr/local/php56/bin/php-cgi56
-rwxr-xr-x  1 root  wheel  32897228 May  1 18:03 php-cgi56*
lrwxr-xr-x  1 root  wheel        33 May  1 18:03 php-config@ -> /usr/local/php56/bin/php-config56
-rwxr-xr-x  1 root  wheel      3605 May  1 18:03 php-config56*
-rwxr-xr-x  1 root  wheel  32984325 May  1 18:03 php56*
-rwxr-xr-x  1 root  wheel       262 Jun 22 21:05 php_uploadscan.sh*
lrwxr-xr-x  1 root  wheel        29 May  1 18:03 phpize@ -> /usr/local/php56/bin/phpize56
-rwxr-xr-x  1 root  wheel      4544 May  1 18:03 phpize56*

Clearly they are different.

IT MAY BE RELATED TO BUILDING IN EXPERT MODE. I built in expert mode because one of the my PHP versions is 5.4 and it cannot be compiled anymore with the current version of OpenSSL; however ./build php n is trying to rebuild it and it fails. So I had to build in expert mode.
 
Last edited:
php_expert mode does not create symlinks, so, yes, that was the main issue :) If the symlink is created already, it won't remove it though, so, you could safely update it in the future.
 
I created the following symlinks in /usr/local/bin:

php@ -> /usr/local/php73/bin/php
php-cgi@ -> /usr/local/php73/bin/php-cgi
php-config@ -> /usr/local/php73/bin/php-config
phpize@ -> /usr/local/php73/bin/phpize

Is it OK that way?
 
checking ioncube version with some problems

hello guys

i checked ioncube version by this way :

Code:
/usr/local/bin/php -v | grep ionCube | grep -m1 -o ' v[^,]*' | cut -dv -f2

and i see this :

Code:
Failed loading /usr/local/lib/ioncube_loader_lin_5.3.so:  /usr/local/lib/ioncube_loader_lin_5.3.so: undefined symbol: execute
Failed loading /usr/local/lib/ZendGuardLoader.so:  /usr/local/lib/ZendGuardLoader.so: undefined symbol: zval_used_for_init
PHP Warning:  PHP Startup: Unable to load dynamic library 'suhosin/suhosin.so' (tried: suhosin/suhosin.so (suhosin/suhosin.so: cannot open shared object file: No such file or directory), /usr/local/lib/php/extensions/no-debug-non-zts-20170718/suhosin/suhosin.so.so (/usr/local/lib/php/extensions/no-debug-non-zts-20170718/suhosin/suhosin.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0

how can i fix it ?

need help !!!
 
I see a similar message:
Code:
Latest version of ionCube: 10.3.9
ionCube loader 0 to 10.3.9 update is available.

They check ionCube version this way:

Code:
/usr/local/bin/php -v | grep ionCube | grep -m1 -o ' v[^,]*' | cut -dv -f2

What do you see? And what PHP versions do you have?
After run this command - nothing (I see # symbol to enter a new command).

After running command: #/usr/local/bin/php -v
I see:
Code:
PHP 7.4.5 (cli) (built: Apr 25 2020 03:33:38) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies

Code:
ll /usr/local/bin | grep php
-rwxr-xr-x    1 root root 43794808 Apr 25 03:33 lsphp
lrwxrwxrwx    1 root root       25 Apr 25 03:34 pear -> /usr/local/php74/bin/pear
lrwxrwxrwx    1 root root       25 Apr 25 03:34 pecl -> /usr/local/php74/bin/pecl
lrwxrwxrwx    1 root root       25 Apr 25 03:34 phar -> /usr/local/php74/bin/phar
lrwxrwxrwx    1 root root       26 Apr 25 03:34 php -> /usr/local/php74/bin/php74
lrwxrwxrwx    1 root root       31 Apr 25 03:34 php-config -> /usr/local/php74/bin/php-config
lrwxrwxrwx    1 root root       27 Apr 25 03:34 phpize -> /usr/local/php74/bin/phpize

How to fix this?
 
You may install if you need 10.3.9, then disable it for php 7.4
or install manually beta (not recommended)
or disable it from php_extensions to stop checking/notifications
 
I'm seeing this problem now with the lack of ionCube loader for PHP 7.4 as well. From what I can tell, you can't specify a different php_extensions.conf for each PHP version installed, so it's not possible to enable ionCube for e.g. PHP 7.3, and disable it for PHP 7.4.

We have set up monitoring that essentially does ./build update && ./build versions, and captures the exit code from this. Since ionCube "always" has an upgrade (which can't be satisfied), we are alerted about available updates. It's a little annoying.. Not sure what the best way is to resolve this. It also occurred to me now that anything that might be upgradeable of PHP extensions, will only ever take into account the primary PHP version, which also might not be ideal.
 
But you can just comment out in /usr/local/php74/lib/php.conf.d/10-directadmin.ini
#zend_extension=/usr/local/lib/ioncube/ioncube_loader_lin_7.4.so
and this PHP will be without ioncube
 
When you run ./build versions, there's a check for ionCube starting at line 28556, which runs (as stated in an earlier post in this thread) /usr/local/bin/php, effectively meaning it will only check if ionCube exists (and its version) for the primary PHP version installed. Could this ionCube check in its entirety be moved to the per-PHP-version check that starts on line 28303? The contents of versions.txt should be able to track if the ionCube loader exists for a certain PHP version, and thus we could avoid the false alert of something having an update available.
 
Back
Top