I am using Virtualmin with PHP-FPM enabled for a virtual server, and when trying to install a web app that requires ionCube, the installer fails with this message:
Since PHP-FPM is a common and recommended PHP execution mode, I would like to ask whether support for installing or enabling ionCube with FPM could be added in Virtualmin.
At the moment, this limitation makes the installer unusable for apps that depend on ionCube unless the PHP execution mode is changed or ionCube is configured manually.
Is there any plan to add ionCube support for PHP-FPM in the installer?
That may work for a debian system running php v8.1 but there is the point that 8.1 should be replaced with the version of php that you wish to install ioncube to, then as we don’t know if the OP is running some form of EL if so the above command is useless as apt does not exist in those environments and php is packaged differently so perhaps we need to know which operating system the OP is using
It took me WAY to long to find what web apps are available for PRO but it does appear this is included so I’m assuming the OP has a PRO license? In this case it would seem to be a fair request that the install script perhaps be updated.
There is no official apt package for ionCube on Debian. The apt-get install php8.1-ioncube command does not exist in any official or standard Debian repository — it will simply return “package not found”.
The only supported installation method is a manual download of the loader binary directly from ioncube.com. Also worth noting: placing the loader in conf.d/ via a .ini file does not work with PHP-FPM regardless of the filename prefix — ionCube requires the zend_extension directive to be placed directly in the main php.ini file, before opcache.
Currently, there is no straightforward way to load ionCube on a per-virtual-server basis on Debian systems and derivatives when using PHP-FPM. The simplest and most reliable way to use ionCube on Debian systems is by running PHP in FCGId mode.
Yet, when using PHP-FPM with ionCube on Debian systems, a practical solution is to install and enable ionCube manually at the global level, which should work reliably across all PHP execution modes.
EL-based systems, however, support installation from repositories using package names such as php84-php-ioncube-loader, provided that the Remi repository is enabled.
What is the command to install on debian and Ubuntu?
The reason I ask other than not knowing, is that when I install a higher version of php, it is that version that is then set as default and the php version that is run from the cli when using php command.
This would be resolved by having independent PHP-FPM services, which we need for resource limits to actually work as expected, anyway. I think that’s a pretty high priority.
I need to install ionCube for a VS. I’m on RockyLinux 10
I only need it for one VS, what does this conversation mean exactly?
Can ionCube be installed for single VS using the app installer?
It means you can enable it globally and it’ll work for that Virtual Server. It won’t break PHP that doesn’t need it, but it does add a bit of memory usage for the others (but not much, it’s a shared library and Linux is extremely good at sharing pages in situations like this..the cost is probably measurable in kilobytes, not even megabytes and definitely not gigabytes).
To repeat what Ilia said:
“Currently, there is no straightforward way to load ionCube on a per-virtual-server basis on Debian systems and derivatives when using PHP-FPM.”
But, it’s not going to hurt anything to have it loaded in all of them.
ionCube Loader is a PHP module. That’s it. You load it like any other PHP module. The way Virtualmin configures and starts PHP-FPM doesn’t provide a way to load modules per Virtual Server…there’s no technical reason it couldn’t, though there is a (small) memory cost for that implementation change, as well. But, we’re planning to switch to that model at some point, anyway, because it is necessary to put PHP apps into the same slice as the user so resource limits can be accurately applied to PHP apps. But, it touches a bunch of stuff, so it’s not something we can safely do overnight.
But, there’s no harm in just adding ionCube Loader. People did it for like a decade, when mod_php was a thing, and many hosts do it in their default PHP config, regardless, because ionCube is used for obfuscating some proprietary PHP apps. (I think ionCube also is an op cache or something, but PHP has had an op cache built in for many years, now, so performance is not a reason to use ionCube, anymore).
Fully isolated virtual servers is the way forwards with complete resource control so if one account gets hammered the rest stay safe etc .
As a thought, could you not make a webmin module that installs/uninstall Ioncube? Make a pro feature of needed and this is probably only for whmcs and clientexec.
Yeah I’m not sure I like the idea of running a PHP-FPM systemd unit per domain, versus the current pool model we use now. If anything, it would make more sense to alllow ioncube to be enabled globally for all users of a PHP version (perhaps in Webmin’s PHP module)
ionCube is irrelevant, AFAIC (enabling it globally isn’t a big deal). The problem that actually needs solving is that resource limits using cgroups simply can’t work for PHP applications without systemd unit-level support for setting the slice to that of the user.
