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.

Switching to suPHP

Discussion in 'General Discussion' started by Hitakashi, Jul 14, 2010.

  1. Hitakashi

    Hitakashi Member

    Joined:
    Jan 14, 2010
    Messages:
    9
    Likes Received:
    0
    Trophy Points:
    1
    I'm wanting to switch to SuPHP due to
    FCGI - uses up all our RAM (We have 768 MB's)
    dso - causes random spikes in RAM usage
    cgi - Rather not use it
    None - Rather not use it

    Our host switched us from suphp to FCGI, Which caused it to eat up our RAM, Then they switched us to dso which we are on now, But it causes random spikes in RAM.

    We WERE on suphp originally and our ram load was always around 30% -40%, But now it's always in the 50% and randomly goes all the way to 100%

    Is there any steps we have to do to switch over to suphp? If so can anyone give me like a short tut, I looked over the web and couldn't find anything to help.

    Thanks
     
  2. Miraenda

    Miraenda Well-Known Member

    Joined:
    Jul 28, 2004
    Messages:
    242
    Likes Received:
    1
    Trophy Points:
    18
    Location:
    Coralville, Iowa USA
    I posted this recently in another thread, so I'll reply with the steps I noted there for switching to suPHP. Of note, only use these steps if going to suPHP (do not process these if you are on DSO).

    - Change all permissions for folders from 777 to 755

    Code:
    find /home/*/public_html -type d -exec chmod 755 {} \;
    - Change all permissions for files from 666 to 644

    Code:
    find /home/*/public_html -type f -exec chmod 644 {} \;
    - Fix ownership to public_html contents to user:user (rather than user:nobody), but keep top level of public_html as user:nobody

    See this location for why to be careful about using a recursive chown to fix these ownership issues. Use the steps noted at this post as a guide for how to fix such ownership issues.

    - Remove any php_value and php_flag entries in .htaccess files as they will produce an Internal Server Error if in an account's .htaccess file. Here are the commands to find all such files:

    Code:
    find /home -type f -name '.htaccess' -exec grep -Hrn 'php_value' '{}' \;
    find /home -type f -name '.htaccess' -exec grep -Hrn 'php_flag' '{}' \;
    After those php_flag and php_value lines have been removed from any .htaccess, then any accounts needing the values set in their own php.ini file could be done using:

    Code:
    cp /usr/local/lib/php.ini /home/username/public_html/php.ini
    chown username:username /home/username/public_html/php.ini
    Then edit the php.ini file to change to the new values, and point the .htaccess on that account to use that php.ini file:

    Code:
    suPHP_ConfigPath /home/username/public_html/
    In these examples, replace username with the actual cPanel username.

    Also, under FCGI for the RAM usage, you could have used FcgidMaxRequestInMem to limit those PHP processes from using so much memory:

    http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html#fcgidmaxrequestinmem

    There are several other limiters there. For DSO and suPHP, you can use RLimitMEM to limit memory:

    http://httpd.apache.org/docs/2.2/mod/core.html#rlimitmem

    If your RAM usage is this high, either limiting memory usage or tracking down the account(s) causing it would be in order.
     
    #2 Miraenda, Jul 15, 2010
    Last edited: Jul 16, 2010
  3. philipalex

    philipalex Registered

    Joined:
    Dec 4, 2008
    Messages:
    4
    Likes Received:
    0
    Trophy Points:
    1
    you can do it from the WHM

    Main >> Service Configuration >> Apache Configuration >> PHP and SuExec Configuration

    Also please make sue that for using the suphp the files permission must be 644 and the folder permission must be 755.
     
  4. cPanelKenneth

    cPanelKenneth cPanel Development
    Staff Member

    Joined:
    Apr 7, 2006
    Messages:
    4,458
    Likes Received:
    22
    Trophy Points:
    38
    cPanel Access Level:
    Root Administrator
  5. Miraenda

    Miraenda Well-Known Member

    Joined:
    Jul 28, 2004
    Messages:
    242
    Likes Received:
    1
    Trophy Points:
    18
    Location:
    Coralville, Iowa USA
    Thank you for the link, Kenneth. I wasn't actually aware that hard links on the same partition owned by another user could result in that behavior. If you'd prefer that I remove that line in my post above (and in another thread where I also provided that command), I could do that.
     
  6. cPanelKenneth

    cPanelKenneth cPanel Development
    Staff Member

    Joined:
    Apr 7, 2006
    Messages:
    4,458
    Likes Received:
    22
    Trophy Points:
    38
    cPanel Access Level:
    Root Administrator
    That's probably the safest.

    The problem is the recursive chown because one does not know what is being changed. To perform the ownership change one has to follow a process like:

    1. Lock the user out of the system
    2. Lock the user out of the directory tree to be changed [a]
    3. Examine each file to determine if it is a hard link to data the user shouldn't have access to
    4. Only chown files and directories verified safe by step 3
    5. Restore user access to the directory tree
    6. Restore user access to the system

    This way you only change ownership on files you've proved are safe. By locking the user out of the system and directory under examination you also prevent race conditions between performing the check and changing ownership.

    Notes:
    a. Rather than starting at the top of the tree, the procedure should really start at the leaf nodes ( the deepest points of the directory tree ). Complete work on the deepest nodes and work your way to the top of the tree ( the top-most level would be /home/user )

    b. Since the hard link files will still have ownership of the original file the full range of file to examine can be reduced to the following set:
    • root:root
    • root
    • other_user:root
    • other_user:nobody
    • nobody:nobody
    The list is representative, not exhaustive. Granted for converting from PHP DSO, the list of nobody owned files could be extensive :). Root owned files, unless you know that you placed them there, should send up huge warning flags.
     
  7. Valuehosted

    Valuehosted Well-Known Member

    Joined:
    Dec 12, 2002
    Messages:
    124
    Likes Received:
    0
    Trophy Points:
    16
    Location:
    Sweden
    Excellent tutorial...

    Quick ? - will the command "find /home/*/public_html -type d -exec chmod 755 {} \;" change the directories to 755 or will it display a list of directories that have other permissions set?

    Thanks,
    --Tone
     
  8. Miraenda

    Miraenda Well-Known Member

    Joined:
    Jul 28, 2004
    Messages:
    242
    Likes Received:
    1
    Trophy Points:
    18
    Location:
    Coralville, Iowa USA
    The command will change those directories to 755 rather than print them out.
     
  9. Valuehosted

    Valuehosted Well-Known Member

    Joined:
    Dec 12, 2002
    Messages:
    124
    Likes Received:
    0
    Trophy Points:
    16
    Location:
    Sweden
    Thank you Miraenda - I sent you a private message, if you wouldn't mind getting back to me.

    I recognize the issue with recursive chown but is there anyway you could post or mail me the code to run it anyway? (all my "clients" are me, and I tend to trust myself! :p).

    Whatabout file permissions that are set to 777 and needs to be downgraded to 664 will the above line convert those too?

    --Tone
     
  10. Miraenda

    Miraenda Well-Known Member

    Joined:
    Jul 28, 2004
    Messages:
    242
    Likes Received:
    1
    Trophy Points:
    18
    Location:
    Coralville, Iowa USA
    The command for 755 will change directories to 755 (not files), while the one for 644 will change files to 644. Under suPHP, directories should be 755 and files 644, so the commands will work properly to change those to the right ones (they don't look at the current file permissions but simply whether it is a directory or file and change appropriately).

    To read it, basically this command:

    Code:
    find /home/*/public_html -type d -exec chmod 755 {} \;
    Means to find any folders recursively in /home/*/public_html that are -type d or a directory, then to execute a chmod 755 on those directories.

    The other command has -type f, which is a file and will change the files to 644.
     
  11. Valuehosted

    Valuehosted Well-Known Member

    Joined:
    Dec 12, 2002
    Messages:
    124
    Likes Received:
    0
    Trophy Points:
    16
    Location:
    Sweden
    Thank you Miraenda,

    I really appreciate your help; and honestly, I cannot believe it was that "easy".

    I have been dreading this move for a very long time and I have known that I indeed needed to do it but I thought it would be way too hard and with your help it was a breeze.

    I would suggest adding the last step as per your email:

    It was awesome to change a site's configuration (Joomla) without having a file permission of 777 on the configuration.php file!

    Again, thank you so much for your help!

    Kind Regards,
    Tony
     
  12. konrath

    konrath Well-Known Member

    Joined:
    May 3, 2005
    Messages:
    367
    Likes Received:
    0
    Trophy Points:
    16
    Location:
    Brasil
    Hello Miraenda and cpanelkenneth

    Thank you very much.

    Konrath
     
  13. sukil

    sukil Member

    Joined:
    Nov 15, 2005
    Messages:
    24
    Likes Received:
    0
    Trophy Points:
    1
    Hi Miraenda and cpanelkenneth,

    I find after enabling suExec, a person can access any system file including /etc/passwd. I understand one has to copy the php.ini file to each user's folder and to put in the open basedir protection code in it. However, it means users can change php.ini and delete the file or I need to restrict that activity and loose out on one advantage of suExec of giving each user their own php.ini.

    Next, I have 200 different customers in my server and I find it difficult to do that to all of them. Next, for every new customer it is no more just an account creation but to copy the php.ini file and secure it against editing. That is time and resource consuming.

    So, ultimately is suExec with all its advantages at all advantageous considering the hazard of maintaining security?

    Please comment as I am really utterly confused and although finding suExec appropriate for my users but cant implement due to the hazard of maintaining security as then I am responsible for security and need to dedicate valuable time to ensure all steps are taken for each client (existing and new).

    Thank you,

    S
     
  14. cPanelTristan

    cPanelTristan Quality Assurance Analyst
    Staff Member

    Joined:
    Oct 2, 2010
    Messages:
    7,623
    Likes Received:
    21
    Trophy Points:
    38
    Location:
    somewhere over the rainbow
    cPanel Access Level:
    Root Administrator
    I've previously posted a guide on how to lock down php.ini and still allow some php.ini changes for users regardless:

    http://forums.cpanel.net/f185/metho...ricting-who-can-use-php-ini-files-167186.html

    This would prevent users from changing all settings depending on which method has been chosen.

    One point that I'm unclear about--if you wish to set open basedir restriction in the global php.ini, it should be impacting all the accounts unless you have individual php.ini files overriding it for some reason.

    In the long run, though, you would be responsible for security on your machine. Security isn't a one time incident but a constant vigil for any server administrator.
     
  15. openmind

    openmind Member

    Joined:
    Oct 30, 2007
    Messages:
    24
    Likes Received:
    0
    Trophy Points:
    1

    I'm planning a migration to suPHP and the changing of ownership of files on a shared server of over 200 accounts is the one part causing me a headache. I don't allow shell access on a permanent basis to the server but I'm still concerned about doing a recursive shown.

    I don't suppose the above steps are scripted up anywhere are they as they do appear to be the safest method...
     
  16. cPanelTristan

    cPanelTristan Quality Assurance Analyst
    Staff Member

    Joined:
    Oct 2, 2010
    Messages:
    7,623
    Likes Received:
    21
    Trophy Points:
    38
    Location:
    somewhere over the rainbow
    cPanel Access Level:
    Root Administrator
    The steps aren't scripted to my knowledge, but the best way (rather than to do a recursive chown at all) would be to get a listing of all files owned by group nobody. Those are the only files that would even need to be changed. When you get the list of files, check that the list of group nobody files aren't hardlinks.
     
  17. nivekau

    nivekau Member

    Joined:
    Jul 22, 2011
    Messages:
    22
    Likes Received:
    1
    Trophy Points:
    3
    Thanks to all who have contributed to this helpful thread.

    I am just about to make the change from DSO to suPHP because we want to run the CloudLinux PHP Selector which isn't compatible with the DSO handler. There are a couple of questions that are troubling me.

    I have some vbulletin forums on my server which create files owned by user:nobody . Now I'm fine with changing the ownership of these files. But what happens after I switch to suPHP? will uploads from the forum still work? will the files simply be owned by the cpanel account user, or will the upload fail because they cannot be created by nobody?

    My second questions relates this helpful post by Miraenda. Specifically this "keep top level of public_html as user:nobody" - why do that? (I presume suPHP will allow that)
     
  18. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    30,711
    Likes Received:
    658
    Trophy Points:
    113
    cPanel Access Level:
    Root Administrator
    1. The uploads should work without the need to modify ownership. Note that you should modify ownership to the account username for existing files owned by "nobody" under this vBulletin installation.

    2. cPanel with suPHP requires the public_html directory itself is owned by the account username, with group ownership set to "nobody" (e.g. the web server).

    Thank you.
     
  19. nivekau

    nivekau Member

    Joined:
    Jul 22, 2011
    Messages:
    22
    Likes Received:
    1
    Trophy Points:
    3
    Thanks Michael, now it all makes sense!
     
  20. nivekau

    nivekau Member

    Joined:
    Jul 22, 2011
    Messages:
    22
    Likes Received:
    1
    Trophy Points:
    3
    One more question if you don't mind. What owenership and permissions should be set for a folder which is on the same level as public_html ?

    For example, on one account we have a folder /home/vbattachments this contains a tree of folders all containing image files.

    It needs to be written to by vBulletin when users upload files. So should the owner:account username group:nobody and 755 for folders and 644 for files?

    - - - Updated - - -

    sorry I made a mistake in my previous post, the folder in question is located at; /home/account/vbattachments

    on several other accounts there is a folder on the same level as public_html to which an external user uploads xml files which are then processed by a script on that account

    so /home/account/xmlupload

    what ownership and permissions should be set for these folders?
     
Loading...

Share This Page