[Solved] Multiple Versions of PHP using suexec?

AndrewT

Well-Known Member
#1
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.
 

mistwang

LiteSpeed Staff
#2
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.
 

AndrewT

Well-Known Member
#3
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?
 

AndrewT

Well-Known Member
#5
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.
 
#7
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
 
#9
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!
 

webizen

Well-Known Member
#10
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.
 
#11
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?
 
#13
But /usr/local/lsws/fcgi-bin/lsphp5 -v isn't CLI

PHP 5.3.3 (litespeed) (built: Dec 21 2010 17:11:59)

Whereas /usr/local/lsws/lsphp5/bin/php -v is:

PHP 5.3.3 with Suhosin-Patch (cli) (built: Dec 21 2010 17:12:11)

- Shouldn't we be giving our SSH users the CLI binary to use?
 

webizen

Well-Known Member
#14
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.
 
#16
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?
 

slimak

Well-Known Member
#20
suEXEC capable suffixes are : "php, php4, php5, php53, phtml, php6, fastphp". avoid "php52".
Why should we avoid "php52"? If we set the version 5.3.x as default for suffix "php5" then we will not have any suffix for version 5.2.x. Could you add possibility to use also the "php52" suffix?
 
Top