WordPress vs. DSO & APC

July 17, 2014 6:13pm
Tagged with:

I’ve put off writing this post for a while now, partially because I’m still not sure that I understand it and partially to make sure that my “fixes” that I’ve put into place actually work! 🙄

So about a year ago I started having issues with the server that runs all of my websites running over-utilized. It was a big, nasty affair that we had a hard time tracking down, on top of being a nightmare because we were supposed to be celebrating my birthday over at Disney after having just started our second round of IVF with the embryo which would eventually become Christopher … needless to say, it was VERY stressful!

After we got things back up and running again, I spent about a week researching how to make sure that it never happened again and one thing that I dove heavy into was caching. There are some plugins that are decent, but you can also do caching at the server level on top of all that and this is where I met my new friend, APC

Now, the good thing about my friend APC is that it’s extremely efficient at what it does – like, it’s one of the best PHP accelerators you can run. Facebook uses it, which sometimes you wouldn’t know, but still, even I can’t deny that they’ve got a fuckton more users than I’ll ever have, so I’ll take their word for it! 8)

Of course, the bad thing about APC is that you have to change the way that PHP runs on your server to enable it … or at least I did. And that’s where the problems began…

Normally most shared environments will run under the SuPHP handler because it’s secure in the way it runs scripts under the users that actually own them. For WordPress, this makes permissions simple because everything just works right out of the box as it always has for me for the past blorgteen years.

Now to run APC, however, I needed to switch over to DSO, which from a security standpoint didn’t seem like a big deal because I run on a VPS, not a shared server now, so there’s not really any risk of “other users” running anything on my machine because there simply aren’t any.

That said, what DSO does do is royally hose up permissions in WordPress because the settings that it needs to upload images, edit themes, update plugins, etc… don’t work because now the web server runs as a separate user (“nobody”) instead of whatever user happens to own the files that it’s trying to execute.

…SOOOOOO…

I finally decided to spend some time digging in to fix this. For a few months, I actually did this very much the wrong way by chmodding the uploads folders of the main sites I was using at the time to 777 … which is bad, so don’t do that!!!

Instead, it seems that the solution wasn’t too crazy after all – to fix the file uploads, I just did a chown -R nobody:nobody uploads and that cascaded the new ownership recursively through all of the subfolders … no need to change any actual permissions, except to change them back from 777, anyways!

I was also able to do this for my Disney site that runs NextGEN Gallery and the results were the same (sorry, can’t remember the specific folder, but it’s in there somewhere!).

Now as for plugins and theme updates, this got a little trickier because I tried the same above and that didn’t seem to work, and I really didn’t want to open up permissions on these folders … even though there’s apparently a way to mask them back to normal by inserting something like these into your wp-config.php file:

define('FS_CHMOD_FILE', 0755);
define('FS_CHMOD_DIR', 0644);

Instead, I inserted these into my wp-config.php file…

define('FTP_HOST', 'localhost');
define('FTP_USER', 'username');
define('FTP_PASS', 'password');

You may have noticed as I did many times throughout this ordeal that if WordPress tries to make an update, but can’t because it doesn’t have the right permissions, it will jump to a screen asking for FTP credentials and then make the changes it wants to do via FTP instead. For the longest time I just entered these manually out of frustration, but now that I think I’ve settled on as close to a “solution” for this as I can get, the above three lines prevent it from prompting me for credentials and I’m now able to install, update, and delete plugins and themes from within WordPress just as if I was running under SuPHP!

Admittedly, I am a little curious to know if there are any other security flaws with having some folders owned by nobody, but from what I can tell it’s still feasible and loads safer than 777. And I get to keep running APC, which I’ve now thrown enough memory at to keep roughly 99% of the php files from all of my sites caching out of system memory instead of parsing off the disk, so that’s a nice little speed improvement that you may have noticed around here!

…but if you do know something I should know about setting up permissions and ownership this way, do be a good samaritan and let me know, though, would ya? Right now I’m cautiously content … so take that for what you will… 😕

Leave a Reply

Your email address will not be published. Required fields are marked *

© 1999 - 2018 Comedic-Genius Media, All Rights Reserved.