Specifically, it appears to be setting the ownership of /usr/share/zope/zope-2.6.4-r1/ to user root, group root, thus not allowing the zope server to access any of its pages contained in the directory. Reproducible: Couldn't Reproduce Steps to Reproduce: This only seems to be happen the first time you install zope. Actual Results: Visiting any pages served by the zope web server results in the page not being found (since it is the wrong user and group). Expected Results: The software should have found the page (i.e. the directory should be assigned to the correct user and group). After unmerging zope and deleting the directories it leaves behind, reemerging zope does not, unfortunately, reproduce the problem. In fact, the ebuild then seems to assign the directory to the correct user and group. However, the problem does seem to appear every time zope is installed for the _first_ time on a machine.
Created attachment 38336 [details] sample output of the broken Zope permissions I am experiencing the same issue, twice. (by installing it on two systems) I fixed it on system A by chown-ing the "problematic" zope directories to zope:zope-2_6_4. The attached HTML is output from system B. System B have (among others) these packages: net-zope/zope-2.6.4-r1 dev-lang/python-2.1.3-r1 dev-lang/python-2.3.3-r1 app-admin/zope-config-0.3 sys-apps/sed-4.0.9 'emerge info' output from system B: Portage 2.0.50-r10 (default-x86-2004.2, gcc-3.3.4, glibc-2.3.3.20040420-r1, 2.6.8-gentoo-r3) ================================================================= System uname: 2.6.8-gentoo-r3 i586 Pentium 75 - 200 Gentoo Base System version 1.4.16 Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-Os -mcpu=pentium -fomit-frame-pointer -pipe" CHOST="i586-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-Os -mcpu=pentium -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="http://gentoo.osuosl.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="accessibility apache2 apm berkdb bidi bzlib cjk crypt emacs fbcon ipv6 java mmx ncurses nls offensive oss pam perl php pic posix postgres python readline sockets ssl szip x86 xml xml2 zlib"
Confirming this is broken here too. Same stuff root:root.
i have had same problem. seems to be mostly under a python directory that the ownership is almost randomly set to root:root zope works after... cd /usr/share/zope chown -R zope:zope-2_6_4 * /etc/init.d/zope restart maybe its because the user:group of zope:zope-2_6_4 is created too late in the ebuild - so initial files are created with ownership of root:root when this is run the second time the owner and group of zope and zope-2_6_4 respectively already exist and therefore the files can be added with the correct ownership. kev PS what should the permissions under /user/share/zope actually be?
as there are many users still using zope 2.6, i will post simple fix shortly, but everyone is recomended to upgrade to zope-2.7 which is much better maintained in portage now.
ok, its fixed in portage without version bump (2.6.4-r1). It leaves /usr/share/zope/zope-2.6.4 at root:root 775/664 permissions (or 755/644 - it depends on your previous system state) - it should gives the best compromise. Also i have to disable default zope-instance creation at emerge time, due to zope-config errors. Warning message about missing instance is printed.
