Permissions issue with apache and silverstripe
I seem to be struggling with a permissions issue but am still somewhat uncertain whether the fault lies with my cpanel apache config or is more an issue with how the silverstripe cms is using it.
I have a WHM server hosting several websites all running silverstripe 2.4. They all have a sivlerstripe-cache directory located under the public_html directory of each account. Every site writes to these directories as the user account, bar one. It is this exception that we are having the issue with. The problem site seems to be wrtining everything as the nobody:nobody apache user. The CMS then lacks the permissions to view the cache files and all sorts of errors appear. chown of the silverstripe-cache directory to the user account instantly breaks the site. the only solution I have found is to chmod recursively the entire directory to 777. This works for most of the useage the site gets but occasionally the users get a silverstripe "white screen of death" that upon investigation is a permissions error to a file in the silverstripe-cache directory that it says does not exist. It does exist but it has 644 permissions and is owned by nobody:nobody. I suspect this is why the CMS can't see the file even though it has been created. I cannot seem to change the permissions on these files despite numerous combinations of chmod being run (full recursive on the parent dir down to specifically targeted commands on the files themselves).
My concern is that all the other sites write to the cache directory as themselves, not nobody and that this is the crux of my issue. I have looked at teh virtual host config and it is set to "AssignUserId user user". I have transferred the account to another identical host (we have three that all come from the same clone, different IP addresses) but cannot replicate the issue on these servers at all. As they are clones they all have the same cpanel/WHM version, the same accounts, the same PHP version, same MySQL and same EasyApache config.
I am somewhat limited in what I can run on the account as it is a live site. Has anyone seen behavior like this before? Should I be expecting a cache directory local to the account to be written to by the account? Or is the nobody:nobody account the norm for writes to the public_html directory?
Apologies this is a long rambling post but I seem to be hitting my head against a brick wall on this one. Thanks in advance.
-
Hello :) I recommend switching your PHP handler to suPHP or use DSO with Mod_Ruid2 to ensure files created by the CMS are not owned by the "nobody" username. You can find more information on different PHP handlers at: PHP Handlers Mod_Ruid2 Thank you. 0 -
Ah, that certainly seems to have sorted out the user writing the files to the cache directory!! During an easyapache rebuild is there much downtime or is it staged like the updates process so the client only see minimal, if any downtime? 0 -
Found a response from someone else that answers it. In case anyone else finds this the original Apache/php will run until a successful compilation. Then it will replace your existing files if successful and restart the required services. Couple of seconds outage on a low use server. 0 -
Yes, that is correct. You typically will only experience an Apache restart when rebuilding Apache/PHP via EasyApache. Keep in mind that you can modify the PHP handler via: "WHM Home " Service Configuration " Configure PHP and suEXEC" Thank you. 0
Please sign in to leave a comment.
Comments
4 comments