On 25/11/10 17:53, Alvaro Lopez Ortega wrote:
On 25/11/2010, at 02:05, David Taylor wrote:
On 25/11/10 12:01, David Taylor wrote:
I spoke too soon. It's back to the same behaviour. If I do "/etc/init.d/cherokee stop" and run
"cherokee-worker" manually, the site serves fine. If I kill "cherokee-worker" and do
"/etc/init.d/cherokee start" I get a 404. All other sites work fine. There's nothing in the error logs.
I assumed it might be something to do with permissions, because cherokee-worker
is running as root when I run it manually. But the site is www-data:www-data
on every directory and file, with 755 permissions. It's linked to by a
symbolic link, but that link also has the same ownership and permissions.
Actually, it looks like cherokee-worker drops privileges automatically when I
run as root, so that's not it either.
There is a fundamental difference between launching cherokee and
cherokee-worker as root.
When you launch cherokee there is a little process (cherokee) that will keep
root privileges. That process will spawn a cherokee-worker process that will
drop the root permissions. In this case, when an interpreter (php, django,
ror, ..) is launched, it's done through the main cherokee process, so it can be
launched under a different UID.
In case you launch cherokee-worker by hand, it won't be able to communicate
with its parent process, so it will try to launch the interpreters by it owns,
under the same UID.
Having that in mind, it looks like the problem could be related to permissions.
One of the back-end apps could be failing to read a file and returning those
404 errors, for instance.
You could try to enable CHEROKEE_TRACE¹ and set it to all. It might print
something interesting.
1.- http://www.cherokee-project.com/doc/dev_debug.html
Thankfully I can skip that. I seem to have fixed it. :-)
Based on what you said, I tried leaving cherokee running as normal but
replacing php-cgi... (I should have mentioned that it's a PHP site,
ispconfig actually)...
When I killed off the existing php-cgi and ran it as root, the site
worked fine.
After poking through the code I realised that it was trying to include
and write to parent directories (via ../../blah). Those parent
directories and files were still owned ispconfig:ispconfig with 750
permissions. Although the user www-data also belonged to the ispconfig
group, those directories and files did not have group write permission...
I added that and everything started to work.
I'll write up some instructions on getting ispconfig working with
cherokee and post them in a follow-up reply.
Thanks for all your help, Alvaro!
Cheers,
David
http://www.cloudartisan.com
_______________________________________________
Cherokee mailing list
[email protected]
http://lists.octality.com/listinfo/cherokee