The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

mod_php and suphp?

Discussion in 'General Discussion' started by MACscr, Sep 27, 2008.

  1. MACscr

    MACscr Well-Known Member

    Joined:
    Sep 30, 2003
    Messages:
    190
    Likes Received:
    1
    Trophy Points:
    18
    cPanel Access Level:
    Root Administrator
    I about to setup some new servers and I was wondering if EA3 allowed the ability to run mod_php and suphp at the same time. I have some older clients that i dont want to have to go through the hassle of converting them to suphp, so i figure i could keep them at mod_php and have that as the secondary php option, but using suphp for the primary php version so that new clients use it, etc.

    Advice?
     
  2. cPanelDavidG

    cPanelDavidG Technical Product Specialist

    Joined:
    Nov 29, 2006
    Messages:
    11,279
    Likes Received:
    8
    Trophy Points:
    38
    Location:
    Houston, TX
    cPanel Access Level:
    Root Administrator
    The easiest way I can think of doing this is using EA3's concurrent PHP capabilities to run PHP 4 and 5, then setting PHP 4 to run as DSO (mod_php) and PHP 5 to run as SuPHP. PHP 5 can be your default, while users of older scripts can swiftly rename their scripts to .php4 (to execute as PHP 4 / mod_php) until their inner workings are resolved to work in a PHP 5 SuPHP setup.

    In my experience, many publicly available PHP 5 scripts including the more popular apps are SuPHP-friendly nowadays.
     
  3. verdon

    verdon Well-Known Member

    Joined:
    Nov 1, 2003
    Messages:
    836
    Likes Received:
    2
    Trophy Points:
    18
    Location:
    Northern Ontario, Canada
    cPanel Access Level:
    Root Administrator
    Yes, and 3 simple shell commands will fix ownership and permissions for a client switching to suphp..
    Code:
    chown -R username:username /home/username/public_html/* ;
    find /home/username/public_html/ -type d -exec chmod 755 {} \;
    find /home/username/public_html/ -type f -exec chmod 644 {} \;
    
     
  4. MACscr

    MACscr Well-Known Member

    Joined:
    Sep 30, 2003
    Messages:
    190
    Likes Received:
    1
    Trophy Points:
    18
    cPanel Access Level:
    Root Administrator
    Thats not simple when your converting 300 accounts =P
     
  5. verdon

    verdon Well-Known Member

    Joined:
    Nov 1, 2003
    Messages:
    836
    Likes Received:
    2
    Trophy Points:
    18
    Location:
    Northern Ontario, Canada
    cPanel Access Level:
    Root Administrator
    no, but I bet it can easily be scripted to go through your users :)
     
  6. brianoz

    brianoz Well-Known Member

    Joined:
    Mar 13, 2004
    Messages:
    1,146
    Likes Received:
    6
    Trophy Points:
    38
    Location:
    Melbourne, Australia
    cPanel Access Level:
    Root Administrator
    This script provided by cPanel will do the whole server in one easy hit:

    Code:
    /scripts/chownpublichtmls
    You may have to remove write permission from a few scripts, but that's pretty easy... (chmod -R go-w /home/.)

    There's no reason to run mod_php with suphp as all your PHP scripts will work in suphp - no headaches here in 4 years of running with phpsuexec then suphp. You'd lose most of the security advantage that suphp confers if you did, for no real advantage.
     
  7. cPanelDavidG

    cPanelDavidG Technical Product Specialist

    Joined:
    Nov 29, 2006
    Messages:
    11,279
    Likes Received:
    8
    Trophy Points:
    38
    Location:
    Houston, TX
    cPanel Access Level:
    Root Administrator
    This is mostly, but not entirely true. Scripts that blindly set 777 permissions upon themselves and other files they rely upon will break in a SuPHP environment. Some older WordPress plugins exhibit this behavior.

    However, this behavior is very rare in contemporary PHP scripts and should not be considered sufficiently significant to deter a migration to SuPHP. However, it is something to keep an eye out for when your customers complain of an internal server error with one of their scripts.
     
  8. brianoz

    brianoz Well-Known Member

    Joined:
    Mar 13, 2004
    Messages:
    1,146
    Likes Received:
    6
    Trophy Points:
    38
    Location:
    Melbourne, Australia
    cPanel Access Level:
    Root Administrator
    As I mentioned briefly in my post, you may have to fix permissions - as David said, you'll see 500 errors and can go check in the logfile /etc/httpd/logs/audit_log. It's actually safe to run the following command, which will remove group and other write permission from all files and directories under public_html directories in /home:
    Code:
    chmod -R go-w /home/*/public_html
    OR
    find /home -name public_html | xargs -r chmod -R go-w
    or you can run a find variant to see what files/directories it would fix:
    Code:
    find /home \( -perm -2 -o -perm -20 \) -print | xargs ls -ld
    If you want to be cautious, run the last find command first and save the output. As both of these commands change a lot of permissions, you should make sure you have a backup first.

    It's probably safe to remove write permissions from *everything* in /home (ie: chmod -R go-w /home), but I'm not 100% sure as some of the mail hierarchy has group write permission, which is probably irrelevant as the group ownership is the user. (Perhaps someone with experience could comment)
     
  9. MACscr

    MACscr Well-Known Member

    Joined:
    Sep 30, 2003
    Messages:
    190
    Likes Received:
    1
    Trophy Points:
    18
    cPanel Access Level:
    Root Administrator
    Would be nice if someone with experience could comment on this last part about chowning/chmoding the home directories. I do know i will have users with directories/files in the /home/*/ dir that are owned by nobody and have 777 perms.
     
  10. aegis

    aegis Well-Known Member

    Joined:
    Jul 6, 2003
    Messages:
    64
    Likes Received:
    0
    Trophy Points:
    6
    There is one advantage to *NOT* using suphp. If you're running PHP as a DSO then you can use one of the many PHP caches and speed things up, sometimes dramatically so. It's the one big issue I have with PHP as a CGI.

    Whereas I agree, suPHP as the default is very worthwhile, it could be relatively useful to be able to switch individual users to DSO so that they could take advantage of caching.

    Unless someone has another idea for speeding up PHP under suPHP???
     
  11. brianoz

    brianoz Well-Known Member

    Joined:
    Mar 13, 2004
    Messages:
    1,146
    Likes Received:
    6
    Trophy Points:
    38
    Location:
    Melbourne, Australia
    cPanel Access Level:
    Root Administrator
    Totally agree, the disadvantge of suPHP is that it is slower and accelerators don't work. For high volume sites, I'd want to place them on a server with only a few trusted clients (*), suhosin and CSF. Everyday hosting clients go on a server with suPHP and CSF.

    (*) trusted means - they know what they're doing with PHP and security ...
     
Loading...

Share This Page