With the recent Joomla exploit it became even more clear that we hsphere hosters have to find a way to get the latest PHP versions onto our servers.
We are using CloudLinux on every web server already to take advantage of its ability to keep customers resource usage in check.
CloudLinux also comes with alternative PHP packages (alt-php) including hardened PHP which are EOL php versions that the CloudLinux team keeps patching.
For several weeks we researched ways to use the alternative PHP packages as replacements for hsphere PHP.
Good news! We did it!
Before we go into detail on how this was accomplished, please keep in mind our hsphere web setup before any changes are made:
- – Apache 2 worker mode
- – FCGID active
- – mod_hostinglimits active
- – CloudLinux 5 with Hybrid Kernel (CL6 will work just as well)
Now on to how we accomplished the goal of replacing hsphere PHP with Cloudlinux PHP.
At first we tried to get a custom suexec from CL to replace the hsphere suexec. However, under hsphere, the pathnames to all PHP binaries are actually hardcoded into the suexec. So, a custom suexec with just adjusted parameters will NOT work.
Next, we decided to try to litterally replace the hsphere php binaries with cloudlinux binaries.
This turned out to work pefectly well even though sadly cagefs will not work within PHP scripts due to the missing custom suexec.
Here are the steps:
- yum install cagefs lvemanager -y
- yum groupinstall alt-php -y
- yum install alt-php54-zend-guard-loader -y (only on CL5)
- /usr/sbin/cagefsctl –init
- Now copy the sample PHP ini files from one user to /etc. Reason is that under Hsphere, the suexec does not respect cagefs which means php is looking for the php.ini in /etc/cl.php..
cp -r /var/cagefs/00/[SAMPLEUSER]/etc/cl.php.d /etc/
- edit the global php ini file to your liking: /etc/cl.selector/global_php.ini. What you add here will be compiled into each global php.ini in the next step
- /usr/sbin/cagefsctl –setup-cl-selector
- The last step is to copy the CloudLinux php binaries over the old hsphere binaries.
Reason this needs to be done this way is that the hsphere suexec containts the path to the php binaries hardcoded.cp -f /opt/alt/php44/usr/bin/php-cgi /hsphere/shared/php4/bin/php
cp -f /opt/alt/php52/usr/bin/php-cgi /hsphere/shared/php5/bin/php
cp -f /opt/alt/php53/usr/bin/php-cgi /hsphere/shared/php53/bin/php
cp -f /opt/alt/php54/usr/bin/php-cgi /hsphere/shared/php54/bin/php
cp -f /opt/alt/php55/usr/bin/php-cgi /hsphere/shared/php55/bin/php
cp -f /opt/alt/php53/usr/bin/php-cgi /hsphere/shared/php-internal/bin/php
(You need to use PHP 5.3 for internal PHP, otherwise the webshell will no longer work)
rm -f /usr/bin/php
rm -f /usr/local/bin/php
ln -s /opt/alt/php55/usr/bin/php /usr/bin/php
ln -s /opt/alt/php55/usr/bin/php /usr/local/bin/php
BTW, nothing stops you from for example doing a:
cp -f /opt/alt/php5.6/usr/bin/php-cgi /hsphere/shared/php4/bin/php
So, if nobody uses PHP 4.4 anymore on a server you convert it to PHP 5.6 this way, or if you are on CL6 you can use PHP 4.4 to be PHP 7.