I performed an ACCEPT_KEYWORDS=~sparc emerge zope For some reason, the group was set to "root" for the entire /usr/lib/zope-2.7.2 tree. The system is completely up to date (I ran 'emerge world' recently). I also managed to reproduce this on a X86 machine, which is a little less up to date (GLSA's have been updated, but not much else in about two months). Reproducible: Always Steps to Reproduce: I did have Zope previously installed on the machine, performed the following: 1) "emerge unmerge zope" 2) rm -Rf /usr/lib/zope-2.7.2 3) rm -Rf /var/lib/zope 4) rm /etc/conf.d/zope-2.7.2 5) rm /etc/init.d/zope-2.7.2 6) userdel zope 7) groupdel zope 8) ACCEPT_KEYWORDS=~x86 emerge zope 9) ls -al /usr/lib/zope-2.7.2 Actual Results: odin / # ls -al /usr/lib/zope-2.7.2/ total 60 drwxr-x--- 6 root root 4096 Aug 2 22:15 . drwxr-xr-x 87 root root 40960 Aug 2 22:15 .. drwxr-x--- 2 root root 4096 Aug 2 22:15 bin drwxr-x--- 2 root root 4096 Aug 2 22:15 import drwxr-x--- 3 root root 4096 Aug 2 22:15 lib drwxr-x--- 9 root root 4096 Aug 2 22:15 skel Once I created a Zope instance, Zope would fail to continue startup once it dropped privs and switched to the "zope" user due to the inability to read program files. Specifically, it failed when it tried to import /usr/lib/zope-2.7.2/lib/python/Zope/Startup/misc/lock_file.py (unable to traverse past zope-2.7.2). This wasn't obvious (no logging anywhere) until I started /var/lib/zope/zope-2.7.2/bin/zopectl and issued "foreground". Expected Results: Group ownership on the /usr/lib/zope-2.7.2 tree should be set to "zope" Interestingly enough, if I skip steps #6 and #7 and re-emerge, it appears to set the group ownership correctly. Maybe the user/group is getting created too late in the process for it to happen the first time around? However, it won't modify the ownership on an existing directory tree, you must remove the /usr/lib/zope-2.7.2 tree and leave the zope user+group in place. After doing steps 1-5,8-9 or 2-5,8-9 in the 'Steps to reproduce': odin / # ls -al /usr/lib/zope-2.7.2/ total 60 drwxr-x--- 6 root zope 4096 Aug 2 22:20 . drwxr-xr-x 87 root root 40960 Aug 2 22:20 .. drwxr-x--- 2 root zope 4096 Aug 2 22:20 bin drwxr-x--- 2 root zope 4096 Aug 2 22:20 import drwxr-x--- 3 root zope 4096 Aug 2 22:20 lib drwxr-x--- 9 root zope 4096 Aug 2 22:20 skel
The permissions are set in the setup_security called at the end of src_install. The zope group isn't added until after this has run (in pkg_preinst) - moving the setup_security call to pkg_postinst could sort it out
I can confirm having similar permissions-related startup issues with Zope 2.7.2 on x86. This problem may not be confined to Sparc alone. Only by running zopectl with the "foreground" command did I determine that Zope could not reach the Python packages that it needed. Altering group ownership to "zope" for the /usr/lib/zope-2.7.2 tree solved the problem.
Created attachment 37193 [details, diff] Patch to fix bug 59217 and 58562 Changes include: - ZS_DIR and ZI_DIR should no longer have double slashes at beginning (fixes bug 58562) - all dir variables now have END slashes. Fixed a few places where it was inconsistant. - moved setup_security call from src_install into pkg_preinst. If setup_security waits until pkg_postinst, the files are already merged into the system. (fixes bug #59217) Suggested change: - a better way (?) to correctly delete .default.
Another thing... After I made the necessary fixes to the ebuild, I tried doing an emerge zope (while zope-2.7.2 was still installed) and none of the permissions got fixed.... Why is that? Shouldn't the permissions from an ebuild's image overwrite whatever is on the system? Is this a philosophical question that should be moved to the forum? Or is this an "emerge" tool bug? So what I had to do is emerge -C zope-2.7.2, then emerge zope and the permissions were fixed.. Weird.. I challenge somebody else to try this and see if I'm right.
> So what I had to do is emerge -C zope-2.7.2, then emerge zope and the permissions > were fixed.. Weird.. I challenge somebody else to try this and see if I'm right. I tried out the zope-2.7.2.ebuild, having applied your patch, and can confirm that this is indeed the case. I removed /usr/lib/zope-2.7.2 prior to re-emerging to rectify the problem.
By the way, these are the components I am now using (in the net-zope category): net-zope/epoz-0.8.2 * net-zope/plonetranslations-0.1 * net-zope/formulator-1.6.2 * net-zope/cmfquickinstallertool-1.5.0 * net-zope/ploneerrorreporting-0.11 * net-zope/plone-2.0.4 * net-zope/portaltransforms-1.0.4 * net-zope/cmfactionicons-0.9 * net-zope/cmf-1.4.7 * net-zope/groupuserfolder-2.0.1 * net-zope/placelesstranslationservice-1.0_rc8 * net-zope/zope-2.7.2 * net-zope/cmfformcontroller-1.0.3_beta * net-zope/btreefolder2-1.0.1 * net-zope/externaleditor-0.8 * net-zope/archetypes-1.2.5_rc5 *
Oops, wrong bug - meant that comment for bug 51825 ... sorry.
This bug has been stagnant for nearly a month now. As the current ebuild is unusable and this patch works, can we get this patch into portage sooner than later? It's not as if it's doing anything crazy. It's fine if it remains masked ~x86 while any other issues are sorted out. Thanks. -Jacob
*** Bug 58562 has been marked as a duplicate of this bug. ***
finally applied in zope-2.7.2-r1
Apparently, one too many slashes were removed in the ebuild. zope-2.7.2-r2 improperly installs itself into /usr/libzope-2.7.2 instead of usr/lib/zope-2.7.2 Easy to fix with mv.
Wow, got bitten by the "too many slashes" myself. Too bad I zapped my entire zope installation in attempting to fix that before seeing this bug... :(
added the missing slash - sorry :) NOTE: the ebuild doesn't require zope-config as dependency. you still can use it, but it's not default anymore. the permissions in the /usr/lib are more restrictive... we treat zope like a "normal" library.
