![]() |
[Solved] Multiple Versions of PHP using suexec?
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.
|
If you use control panel like cPanel, PHP suEXEC works with all PHP version.
If you configure vhost natively, you need to add PHP external app configuration for all PHP version for each vhost. |
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? |
suffixes php, php4, php5, php3 php6, phtml, fastphp
are PHP suEXEC capable. |
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. |
Seems like this was largely ignored. We really need support for alternative suexec-able PHP extensions.
|
Forgive my ignorance but is there a way for us or our users to specify which PHP version they want to use via .htaccess or a custom php.ini file?
How about in the vhost file? Thanks David |
|
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! |
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. |
| All times are GMT -7. The time now is 10:59 AM. |