Bug 474946

Summary:	Permissions problems prevent Zope service from starting
Product:	[Fedora] Fedora EPEL	Reporter:	Russell Haering <russell_h>
Component:	zope	Assignee:	Jonathan Steffan <jonathansteffan>
Status:	CLOSED WONTFIX	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	low
Version:	el5	CC:	jonathansteffan, mastahnke, russell_h
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:	ActualBug
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-09-07 21:03:38 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Russell Haering 2008-12-05 23:58:48 UTC

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 20:03:38 UTC

/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 21:03:38 UTC

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.