[Solved] Multiple Versions of PHP using suexec?

Discussion in 'PHP' started by AndrewT, Jan 26, 2010.

  1. AndrewT

    AndrewT Well-Known Member

    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.
  2. mistwang

    mistwang LiteSpeed Staff

    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.
  3. AndrewT

    AndrewT Well-Known Member

    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?
  4. mistwang

    mistwang LiteSpeed Staff

    suffixes php, php4, php5, php3 php6, phtml, fastphp
    are PHP suEXEC capable.
  5. AndrewT

    AndrewT Well-Known Member

    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.
  6. AndrewT

    AndrewT Well-Known Member

    Seems like this was largely ignored. We really need support for alternative suexec-able PHP extensions.
  7. outeredge

    outeredge Active Member

    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?


  8. webizen

    webizen Well-Known Member

  9. outeredge

    outeredge Active Member

    Thanks, that's got me off on the right foot.

    I've noticed that rebuilding PHP 5.2 after building 5.3 overwrites the


    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?

  10. webizen

    webizen Well-Known Member

    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. outeredge

    outeredge Active Member

    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?
  12. webizen

    webizen Well-Known Member

    You should do below instead.

    ln -sf /usr/local/lsws/fcgi-bin/lsphp5 /usr/bin/php
  13. outeredge

    outeredge Active Member

    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?
  14. webizen

    webizen Well-Known Member

    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.
  15. outeredge

    outeredge Active Member

    Ah, of course. It was the /usr/local/lsws/lsphp52 folder I'd forgotten about!

  16. outeredge

    outeredge Active Member

    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?
  17. mistwang

    mistwang LiteSpeed Staff

    suEXEC capable suffixes are : "php, php4, php5, php53, phtml, php6, fastphp". avoid "php52".
  18. MikeDVB

    MikeDVB Well-Known Member

    Does this apply to 4.1RC4 as well or is there a newer 4.1 RC available?
  19. NiteWave

    NiteWave Administrator

    tested, apply for 4.1RC4.
  20. slimak

    slimak Well-Known Member

    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?

Share This Page