Red Hat Bugzilla – Bug 474946
Permissions problems prevent Zope service from starting
Last modified: 2009-09-07 17:03:38 EDT
Description of problem:
The zope init script hangs on a clean installation of Zope on CentOS 5.2
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. $ yum install zope
2. $ service zope start
... never returns
Starting zope: [ OK ]
Starting zope: [FAILED]
There are really 2 problems:
1. By default /var/lib/zope is owned by root:root with drwx------
zopectl tries to run things as user 'zope', and fails. A "chmod og+rx /var/lib/zope" fixes the problem.
2. The init script directs the output of zopectl to /dev/null, and waits for it to return. But, due to the error above zopectl never returns, so the init script is unable to catch the error.
/var/lib/zope is by default the zope INSTANCE_HOME which should be secured. By default, requiring root to run/use zope is the route I decided to go (rather, continue from the previous maintainer.) The packages would have to be completely reworked (they really should be) so using/running zope is not a privileged operation. The only real issue is how to remain upgrade compatible while still providing the ability to continue to have a default zope instance. Splitting out the default instance to zope-instance or similar subpackage is what would be ideal, but the only way I can see to make this previous version compatible is to require zope-instance via zope which is going to like break things.
With regards to the init script, those should also be rewritten. I started working on this but found that some people want to run zope on ports <1024 and the only way to do this is with the [reportedly] broken zopectl -u call. We really need to be using runuser or similar. Additionally, only stderr is redirected to /dev/null and we use the stdout results to figure out if zopectl worked. It's possible that the newer zopectl uses correct return codes now, and this is yet another legacy packaging workaround.
If you are still interested in getting these issues fixed, ideas/examples/testing are welcomed. I'm building the updated zope today but am not sure if I'll have the time to test fixes for all of the above.
I'm going to go ahead and close this. I don't have a good migration path to allow both non-root and root access to the zope service without a complete rewrite of all the packages, which would require a namespace change (which might be a good idea) but I don't have time to do this now.