Bug 474946 - Permissions problems prevent Zope service from starting
Permissions problems prevent Zope service from starting
Status: CLOSED WONTFIX
Product: Fedora EPEL
Classification: Fedora
Component: zope (Show other bugs)
el5
i386 Linux
low Severity high
: ---
: ---
Assigned To: Jonathan Steffan
Fedora Extras Quality Assurance
ActualBug
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-05 18:58 EST by Russell Haering
Modified: 2009-09-07 17:03 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-07 17:03:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Russell Haering 2008-12-05 18:58:48 EST
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):
zope.i386 2.10.6-1.el5

How reproducible:
Always

Steps to Reproduce:
1. $ yum install zope
2. $ service zope start
  
Actual results:
Starting zope:
... never returns

Expected results:
Starting zope:                                             [  OK  ]
or
Starting zope:                                             [FAILED]

Additional info:
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.
Comment 1 Jonathan Steffan 2009-05-25 16:03:38 EDT
/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.
Comment 2 Jonathan Steffan 2009-09-07 17:03:38 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.