Is there built-in support for running different versions of PHP simultaneously using suexec? I do not see any configuration options that support this and by default only the primary PHP install is being run with suexec, additional versions are running as the LS user. This is easily resolved by using a custom wrapper for the external app though this is not ideal.
[Solved] Multiple Versions of PHP using suexec?
- Thread starter AndrewT
- Start date
The server is using cPanel.
Further testing reveals that it does work but with some file extension oddities. I've been testing numerous different PHP configurations so some non-standard file extensions were being used to differentiate the versions.
When the script handler is set for .php53 it would not run with suexec (scripts ran as nobody). When I changed this to .php5 it did work. I've tried other random extensions as well and it seems like there is some kind of limit as to what extensions suexec will recognize. Is this correct?
Further testing reveals that it does work but with some file extension oddities. I've been testing numerous different PHP configurations so some non-standard file extensions were being used to differentiate the versions.
When the script handler is set for .php53 it would not run with suexec (scripts ran as nobody). When I changed this to .php5 it did work. I've tried other random extensions as well and it seems like there is some kind of limit as to what extensions suexec will recognize. Is this correct?
Thank you very much. Now at least I know what I'm working with. 
While we're on the topic, I would like to suggest making these configurable.
We'll be running 5.2.12 and 5.3.1 (likely a 6.x version in time as well). At this point both .php and .php5 need to be 5.2.12 for compatibility. This leaves us with only other undesirable options to select for 5.3.1. Realistically users will be switching between them via AddType, it just isn't intuitive to reference PHP 5.3.1 specifically as phtml, etc.
While we're on the topic, I would like to suggest making these configurable.
We'll be running 5.2.12 and 5.3.1 (likely a 6.x version in time as well). At this point both .php and .php5 need to be 5.2.12 for compatibility. This leaves us with only other undesirable options to select for 5.3.1. Realistically users will be switching between them via AddType, it just isn't intuitive to reference PHP 5.3.1 specifically as phtml, etc.
Thanks, that's got me off on the right foot.
I've noticed that rebuilding PHP 5.2 after building 5.3 overwrites the
/usr/local/lsws/fcgi-bin/lsphp5
symbolic link, so I've had to force the External App's to look at the individual binaries for 5.3 and 5.2. Just thought someone might like to know.
With regards to the php CLI binary, on our servers we have a SL setup as below:
ln -sf /usr/local/lsws/lsphp5/bin/php /usr/bin/php
So that when our users ssh into the box they can use the CLI without needing to know it's path.
As such, I've noticed that php -v is still showing 5.3 after building 5.2, which is fine for us. However, I wondered if you could just clarify when the php cli binary in that path get's overwritten - I had assumed this would just happen as a matter of course when PHP is re-compiled?
Thanks!
I've noticed that rebuilding PHP 5.2 after building 5.3 overwrites the
/usr/local/lsws/fcgi-bin/lsphp5
symbolic link, so I've had to force the External App's to look at the individual binaries for 5.3 and 5.2. Just thought someone might like to know.
With regards to the php CLI binary, on our servers we have a SL setup as below:
ln -sf /usr/local/lsws/lsphp5/bin/php /usr/bin/php
So that when our users ssh into the box they can use the CLI without needing to know it's path.
As such, I've noticed that php -v is still showing 5.3 after building 5.2, which is fine for us. However, I wondered if you could just clarify when the php cli binary in that path get's overwritten - I had assumed this would just happen as a matter of course when PHP is re-compiled?
Thanks!
1. Is /usr/local/lsws/lsphp5/bin/php a symlink or physical file? /usr/local/lsws/fcgi-bin/lsphp5 usually symlinks to an lsphp5-x.x copy in the same directory. The point is that /usr/local/lsws/lsphp5/bin/php is likely not touched after PHP re-compile.
2. Try 'which php' to see which php was called. The point is that if you have /usr/local/bin/php, which is in the front of /usr/bin/php in search order, 'php -v' is actually '/usr/local/bin/php -v'. In other words, it is NOT the copy you want to check.
2. Try 'which php' to see which php was called. The point is that if you have /usr/local/bin/php, which is in the front of /usr/bin/php in search order, 'php -v' is actually '/usr/local/bin/php -v'. In other words, it is NOT the copy you want to check.
1. Yes, that's a physical file. It seems to be the PHP CLI binary for 5.3, so I guess that doesn't get touched after a PHP re-compile.
2. 'which php' shows '/usr/bin/php' so it's looking at the file mentioned in point 1 above based on my symlink. I just find it odd that re-compiling php doesn't overwrite the CLI binary in the lsphp5/bin folder.
That still raises the question, where is the PHP CLI for Php 5.2 that i've built?
2. 'which php' shows '/usr/bin/php' so it's looking at the file mentioned in point 1 above based on my symlink. I just find it odd that re-compiling php doesn't overwrite the CLI binary in the lsphp5/bin folder.
That still raises the question, where is the PHP CLI for Php 5.2 that i've built?
From your screenshot, lsphp5 is currently pointing to php 5.3.3 which matches with the cli binary. That looks fine to me.
You can revert /usr/bin/php.
Back to your question:
When you recompiled 5.2, did you still use "/usr/local/lsws/lsphp5" as install path prefix ? If so, /usr/local/lsws/lsphp5/bin/php should be the CLI binary of the recompiled php 5.2. AND /usr/local/lsws/lsphp5/bin/lsphp is the litespeed counterpart which is identical to the recompiled 5.2 binary copy in /usr/local/lsws/fcgi-bin. You can do following to verify:
ls -l /usr/local/lsws/fcgi-bin/lsphp* /usr/local/lsws/lsphp5/bin/*php
A possible cause of lsphp5 being mismatch with cli binary in /usr/local/lsws/lsphp5/bin/php is that php 5.2 was recompiled with a different Install Path Prefix (say /usr/local/lsws/lsphp52). The matching cli binary would be in /usr/local/lsws/lsphp52/bin/php.
You can revert /usr/bin/php.
Back to your question:
When you recompiled 5.2, did you still use "/usr/local/lsws/lsphp5" as install path prefix ? If so, /usr/local/lsws/lsphp5/bin/php should be the CLI binary of the recompiled php 5.2. AND /usr/local/lsws/lsphp5/bin/lsphp is the litespeed counterpart which is identical to the recompiled 5.2 binary copy in /usr/local/lsws/fcgi-bin. You can do following to verify:
ls -l /usr/local/lsws/fcgi-bin/lsphp* /usr/local/lsws/lsphp5/bin/*php
A possible cause of lsphp5 being mismatch with cli binary in /usr/local/lsws/lsphp5/bin/php is that php 5.2 was recompiled with a different Install Path Prefix (say /usr/local/lsws/lsphp52). The matching cli binary would be in /usr/local/lsws/lsphp52/bin/php.
Another problem has cropped up, we are using SuExec in the Apache config files which works fine when not using AddType to switch to PHP5.2.
However as soon as we use the below, Litespeed switches to running as the default user (www-data in our case) so the suexec user is ignored:
AddType application/x-httpd-php52 php
Could you let me know if this is a bug and if you can fix this ASAP?
However as soon as we use the below, Litespeed switches to running as the default user (www-data in our case) so the suexec user is ignored:
AddType application/x-httpd-php52 php
Could you let me know if this is a bug and if you can fix this ASAP?