I am trying to install WordPress on my VPS and have run into a problem in which the php install script complains about not having write access to the wordpress directory. The site which I am trying to install is a SiteWorx site setup using NodeWorx. I am not sure if this problem is related to InterWorks but I thought I’d post here just in case.
What I did was untar the WordPress tarball in my DocumentRoot directory. I can access the WordPress install by going to:
http://<site name>/wordpress
At which point the config script starts up and complains about not having write access to the wordpress directory. I can get the script to run by changing the permissions of the directory to 777 but for obvious reasons I’d rather not do that. I changed the group for the wordpress directory to ‘nobody’ which is what httpd should be running as. This should have been enough to give httpd permission to write into the wordpress directory if the permissions are set to 755…however this didn’t work.
When a SiteWorx domain is setup how does it do anything with default permissions? Any tips/hints on what I might check?
I haven’t tried to install it yet, although it seems promising.
But from the link above Fr3d wrote:
suPHP is a tool for executing PHP scripts with the permissions of their owners. It consists of an Apache module (mod_suphp) and a setuid root binary (suphp) that is called by the Apache module to change the uid of the process executing the PHP interpreter.
So it seems that this is another module you add into apache which should make it work well with the default Iworx setup.
If you figure out a way to get your idea above with PHP4 and 5 let me know, that would be great to offer both and a nice way to slowly migrate sites to use the new PHP5 tools.
Thanks for the info. If I change the group to “apache” will that eliminate the need to use suPHP?
Also, is suPHP possibly needed because I am running using Iworks? Just asking, because I have WordPress install on non-Iworx managed sites and they work fine.
Anyway, I’ll try change the group to ‘apache’ and if that doesn’t work I’ll take a look at suPHP.
Yes, changingi the group to “apache” and making sure the directory has at least 775 permissions. 755 won’t be good enough because that is only read/execute for the group. 775 is read/write/execute for the group.
Thanks. I changed the group to “apache” and permissions to 775 and it worked. However, now I am wondering why 755 was good enough to get it working on my non-Iworx site. Also, on the WordPress site it says that the WordPress directory should only be writable by the user:
I was assuming the system was requiring write access by the webserver (apache) user. If that isn’t the case, then there’s no reason 755 won’t work. There’s nothing “special” about iworx / apache in this regard.
I dont see how that would be possible b/c if a PHP script run via HTTP (webserver) then it will run as the user of apache (ie. nobody or apache). As Paul said there is nothing special about the way apache is setup on InterWorx. Maybe your other host had suPHP installed in which case PHP would run as your username:groupname instead of apache:apache. I think if you run PHP as a CGI instead of module (as it is in Iworx) you can make PHP run with your username.
Another option that may or may not work well is using the open_basedir in the Vhost file to prevent other accounts on the shared hosting server for being able to read file owned/group by apache user.
If you are really concerned then you may want to read more about suPHP.
Thanks for the explanation. It looks like suPHP would be the best option. I installed and tried it about an hour ago using the link you posted but when I went to load my site I kept getting a pop-up asking me if I wanted to “open with” or “save as”. I go back and try to get it working again.
I don’t see why use suPHP alone. Ok it’ll show which user use PHP and it might help to find which account use exploitable scritps but it is alos runned as CGI (not sure of this) and there is also inconvenient to this. open_basedir do the job and with it you have a support able verison (not sure interworx will give support to suPHP installation yet or at least while they don’t propose it. Well I don’t say they won’t help, butr…)
It so funny to see in few days suPHP is become the most wanted
I think this is something people have wanted for a long time and now there is a working stable way to do it with suPHP. I would rather use the MPMper_child, but sicne you nor I have started work on it, I dont think we can use it
One thing Im not sure is how much suPHP slows down stuff compared to not using it? If you run pretty lite sites is it even noticeable? How does it compare vrs FastCGI with per user suexec (or whatever its called )?
Haha, there is now like 5 different threads with suPHP in them :eek:
I got suPHP working…for awhile. While I was trying to get suPHP working I had a support ticket open with my host and it appears that after I got everything working and before I was able to close the ticket they changed something (while working on this problem) and now I am getting an “internal server error”. I asked them what they changed and they said “nothing” so I went back and looked through the files in the WordPress directory and some of the files had their owner, group, and permission settings changed from what I had set them as…so I know there’s been changes. Anyway, now I am stuck trying to figure out what changed that is causing the error when I have suPHP turned on. This has been a bad day.
Internal Server Error usually happens b/c of a bad .htaccess file. That would be the first place I would look and if you have an .htaccess file I would just remove/rename it for now to see if that fixes your problem.
Yeah, I checked for that last night but there was none. Support eventually fixed the problem but told me it was just file permissions they changed. I am not sure I believe that because I went in and reinstalled the WordPress files from the tarball and it still didn’t work. Anyway, it finally “magically” started working but I am not sure what was changed to get it working.
)?