This is the request for ebuild for Zope-2.7.0 as it is now the latest STABLE release. Reproducible: Always Steps to Reproduce:
*** Bug 32034 has been marked as a duplicate of this bug. ***
*** Bug 43802 has been marked as a duplicate of this bug. ***
Any news on this issue?
Created attachment 28323 [details] zope-2.7.0 ebuild and related files This is my first crack at an ebuild for 2.7.0. Due to changes to the way that Zope 2.7 works (eg. no longer uses all those environment variables) and never having used zope before :) I commented a lot of the old ebuild code for now. It installs into /usr/lib/zope-2.7.0 as noted in Bug #31511. I've included a patch to zopectl from the bug here: http://zope.org/Collectors/Zope/1235
In the install_help() procedure, line 197, the proposed ebuild has einfo "$ /usr/lib/${PV}/bin/mkzopeinstance.py" I think this should be einfo "$ /usr/lib/zope-${PV}/bin/mkzopeinstance.py" Note that I've just prefaced the zope version with "zope-". -Paul Komarek
The zope instance's var and log directories were created with user.group = root.root. This caused zope to fail after some time passed, or after someone tried to connect (probably from trying to write a log or something). One symptom was a connection refused on port 8080, even though you could see zope listening there using netstat. Changing the user.group to zope.zope for these two directories worked. For concreteness: since my zope instance is in /var/zope, those directories are /var/zope/log and /var/zope/var. I followed the directions for running mkzopeinstance (as mentioned in my previos comment, the path reported by the ebuild, /usr/lib/2.7.0/bin/mkzopeinstance.py, was wrong -- that should be /usr/lib/zope-2.7.0/...). Should have run mkzopeinstance as user zope? If so, maybe the directions could include that. If mkzopeinstance is supposed to take care of perms. Note that I'm not sure how mkzopeinstance could handle user/group stuff, since the instance hasn't created yet. Therefore $INSTANCE/etc/zope.cfg doesn't exist, and the effective-user isn't set yet. I think the ebuild should suggest something more like: * To create a new Zope Instance use the following command: * $ su zope -c /usr/lib/2.7.0/bin/mkzopeinstance.py However, I have not tried this myself (I just did chown zope.zope ...) -Paul Komarek
I haven't figured out why yet, but the pcgi stuff from the Zope 2.7.0 tarball is nowhere to be found after this ebuild runs. That is, I had thought that Zope-2.7.0/pcgi would be copied to /usr/lib/zope-2.7.0/pcgi, but it was not. Nor does epm -ql zope show the pcgi directory being installed. As far as not installing stuff goes, there are many Zope directories that aren't installed. ZServer, utilities, etc. Is there a reason for this? -Paul Komarek
I caught the ${PV} typo also. It was actually supposed to be ${PF} which resolves to zope-2.7.0 which is the same as doing zope-${PV}. As for the ownership of the instance folders, I already patched mkzopeinstance.py to use ZUID and ZGID (zope:zope) when creating the instance folders. In install_help I say to run the command as a non-root user but root may in fact be required for that command. Can you try creating a new instance as root (use /tmp/zope for instance path) and see if it works? Due to how the script works you will still have ownership of /tmp/zope but all files and folders inside it should be owned by zope:zope.
The pcgi directory in the source tarball appears to be empty. Maybe it's not part of the core distribution anymore? ZServer is installed here: /usr/lib/zope/lib/python/ZServer And utilities becomes /usr/lib/zope/bin Note that /usr/lib/zope is just a symlink to /usr/lib/zope-2.7.0
I just learned that pcgi is deprecated for zope. They are now suggesting using a proxy, for instance mod_proxy with apache[2]. I'm learning how to do this. -Paul Komarek
I tried creating a new instance as root using mkzopeinstance.py. Whether or not I set ZUID and ZGID, I everything under /tmp/zope/ was owned by root. I don't see anything in mkzopeinstance.py that refers to ZUID or ZGID; maybe your patch wasn't applied for some reason? -Paul Komarek
I just tried installing this ebuild, and I did not have zope installed before. The ebuild failed when it tried to create a new user, so I changed the pkg_setup function like this: pkg_setup(){ enewgroup ${ZGID} enewuser ${ZUID} 261 /bin/bash ${ZOPE_DIR} ${ZGID} } it seems ZS_DIR is no longer defined
I just tried to emerge the ebuild listed above - it doesnt seem to install any init.d/ startup script.... am I doing something wrong? Also, the help-text at the end of the ebuild process which tells the user where to find mkzopeinstance and zopectl indicates an incorrect directory. It would be really great to get a working zope ebuild into Gentoo stable!
Created attachment 30905 [details, diff] patch for previous attachment's ebuild
Created attachment 30906 [details, diff] changes to zope-config to get zope-2.7.0+ to work.
Created attachment 30907 [details, diff] Simple change to /etc/zope-config.conf for zope-2.7.0+
Created attachment 30909 [details] proposed replacement for net-zope/zope/files/2.7.0/zope.initd
Here's summary of my proposed changes: zope-2.7.0.ebuild changes: - fixed two bugs in unpack routine. - added creation of .templates and population of zope.initd which becomes /etc/init.d/$ZOPE_INSTANCE - added help for easy step after install assuming the zope-config changes work. - included enewuser fix from previous bug comment zope-config: - added zserv_is_2.7_or_newer function to detect if selected zserver is 2.7.0+ or if it's an earlier version. - added code to invoke mkzopeinstance.py if setting up 2.7.0 or later. - added code to copy and customize /etc/init.d/$z_instance for 2.7.0 or later - added ability to use zope-config --zpasswd for 2.7.0 or later zope-config.conf - added ZS_DIR2 which defines the new location for 2.7.0+ zope versions net-zope/zope/files/2.7.0/zope.initd - This one worked on my system! Somebody else give it a try :)
Created attachment 30910 [details] proposed replacement for net-zope/zope/files/2.7.0/zope.initd
so when can we expect this in portage?
i'll take a look at the ebuilds over the next weekend. probably we can add them to ~x86 afterwards.
any news on when it's gonna hit portage?
There is a small bug in the patched zope-config -- it should chown the newly created /var/lib/zope directory to zope:zope, or the creation of subdirectories will fail (for they are created under `su zope -c` command). --- zope-config.orig 2004-06-02 19:38:46.790012184 +0800 +++ zope-config 2004-06-02 23:54:04.453373400 +0800 @@ -210,6 +210,7 @@ if [ ! -d ${ZI_DIR} ] ; then mkdir -p ${ZI_DIR} + chown zope:zope ${ZI_DIR} fi while : ; do
We're 5 months late on this upgrade, what more needs to be done to get the ebuild in portage? We seem to have sufficient headcount of interested parties to make this happen...
I did some testing with the above ebuild (and patch) and found that I had to add --ignore-largefile to the ./configure step in src_compile(). It seems that Python on Gentoo is not compiled with large file support, or at least that's what the configure script things. The test in Zope-2.7.0/inst/configure.py looks like this: def test_largefile(): OK=0 f = open(sys.argv[0], 'r') try: # 2**31 == 2147483648 f.seek(2147483649L) f.close() OK=1 except (IOError, OverflowError): f.close() if OK: return print ( """ This Python interpreter does not have 'large file support' enabled. ... """ ) sys.exit(1) I think this test is bogus. It is trying to itself by whatever name it was invoked under, and I suspect this doesn't work very well. To test it interactively, I changed sys.argv[0] to sys.executable (path to Python interpreter) and it worked fine. It should be safe to add --ignore-largefile to the configure options, although I really can't see where it is being enabled in the ebuild. Now I haven't tested the resulting build yet, because I haven't tackled the zope-config issue which apparently exists. Can someone (like maybe Carter, since he has done the most research on this) put together a complete ebuild for 2.7.0, and maybe also a patchset and ebuild for zope-config? 2.7.1_beta1 has been out for a couple weeks now and has a bunch of fixes. This bug is also blocking (somewhat) bug #51825 (plone-2.0.3) which recommends use of Zope-2.7.
Created attachment 33521 [details] zope-2.7.1_beta2.ebuild Here's an ebuild that I put together based on the 2.6.4-r1 ebuild. Summary of changes: * Attempt to future-proof version number detection * Tarball naming convention has changed * ~arch for all platforms * Remove PYTHON_SLOT_VERSION testing due to python-2.3* dependency * Remove extraneous slashes in ZSERVDIR, ZINSTDIR * Minor indent fix in install_help() * Use new configure with --ignore-largefile due to bogus test (Gentoo python has it, test thinks otherwise) * Remove all the .templates stuff since Zope now uses skel * Drop zope.confd because Zope has a etc/zope.conf now * Don't try to install a default instance; zope-config probably won't work right without changes To create a new instance without zope-config, use: /usr/share/zope/zope-2.7.1_beta2/bin/mkzopeinstance.py \ -d /var/lib/zope/zope-2_7_1_beta2 -u admin:password To start Zope without zope.initd: /var/lib/zope/zope-2_7_1_beta2/bin/runzope zprod-manager works fine, as near as I can tell. TODO: * Fix up zope-config * Rework/simplify zope.initd (Zope doesn't look at the environment variables anymore). The one attached on this bug looks reasonably good.
2.7.1 is out. Since 2.7.1b2 was the last prerelease, and 2.7.1 only has one bugfix in it, the 2.7.1_beta2 ebuild above ought to work fine. I'd update the summary and URL but it won't let me.
2.7.1 broke my ebuild because it inexplicably changed it's source directory to Zope-2.7.1-0 from the expected Zope-2.7.1. If you alter: S="${WORKDIR}/Zope-${SFPV}" to S="${WORKDIR}/Zope-${SFPV}-0" then it seems to work fine. I am reworking zope-config and doing more testing.
Created attachment 33950 [details] zope-2.7.1.ebuild Changes from 2.7.1_beta2 ebuild: * Fix ${S} due to unexpected source directory relocation * Set ZGID=zope; see discussion below * Remove some unused variables * Make setup_security() sane * Revise install_help() * Make zope user with zope group * Fix documentation * Fix speling erorrs in unicode patch section (don't know if this patch is applicable any more, please test) * Remove rc-script editing (no longer needed) * Do NOT install a default instance; discussion below * Remove .default more simply Security updates: Older ebuilds of zope (particularly 2.6.4-r1) go through the extra step of creating a default instance with it's own group, and then changing ownership of all the files to zope and the group to the default instance's group, and removing all permissions from others. This is WRONG. Instances run as the zope user; do you really want to zope user to own all the files and have them writable? You sure wouldn't do this with apache, so why Zope? As a result, all the files in the ZSERVDIR (where zope is being installed) are now owned by root and the zope group, which does not have write permission. Others still have no read/write permission; I'm not really sure what the rationale is for this, but it does not make it less secure. Additionally, zope-config (patch to follow) installs it's instance files in a similar way.
Created attachment 33951 [details] files/2.7.1/zope.initd This is the /etc/init.d/ script for the 2.7.1 ebuild. Put it in net-zope/zope/files/2.7.1.
Created attachment 33952 [details, diff] patch for zope-config for zope-2.7 compatibility Summary of changes: * Use a sane permissions scheme, but only for 2.7 right now; should probably also be applied to earlier versions * Use mkzopeinstance.py to do the heavy lifting * For Zope-2.7, make the /etc/conf.d file on the file (hardly any parameters needed now) and edit ${INSTANCE}/etc/zope.conf * Run zpasswd from the right place (2.7 has a bin directory) * Detect zope version by presence of bin directory * Don't try to add the instance group if it exists (suppress error message) * Update post-install instructions Security updates: See also the discussion on comment #29. Previously (and still for zope<2.7) the instance files were installed so that they were owned by the zope user and the instance's group, and set to be owner- and group-writable, and non-read-write by others This is WRONG. The instance runs as the zope user, and most of those files should not be writable to the running instance. Now they are owned by root and the instance's group, but not group-writable. The exceptions are the var and log directories, which are group-writable with the set-group-id bit. If you are cc:ed on this bug, please test the ebuild and patch your zope-config and report the results here. I've tested it all pretty thoroughly and I don't think there are any issues, with one exception: I have not tested the structured text unicode patch. I don't even know if it is applied or is needed, since it is leftover from 2.6.4.
I'll also point out that the zproduct eclass has the same sort of file ownership issue as the old ebuild and zope-config: When it installs files (zproduct_pkg_postinst()), it chowns them zope:root. This of course makes them writable by running zope instances. They ought to be root:root or root:zope. zprod-manager seems okay in this respect, since it preserves permissions and ownership of installed zproducts.
I have tested Andy's latest ebuild along with the zope-config patch and they seem to work smoothly except for one minor issue: if you have a prior version of Zope installed (in my case zope-2.6.4-r1) the user zope already exists and is assigned gid 100. This prevents enewuser in zope-2.7.1.ebuild from assigning the correct group (zope) to the zope user. As a result you cannot start your zope instance "out of the box". IMHO there is no clean solution to the problem. The 2.7.1 ebuild implements the ideal behavior, but raises the above issue. A workaround might be to call useradd with the -G zope option (maybe through enewuser), leaving the zope user with users (gid 100) as the default group.
Try changing the pkg_setup() section of the ebuild to this: pkg_setup() { enewgroup ${ZGID} 261 usermod -g ${ZGID} ${ZUID} 2>&1 >/dev/null || \ enewuser ${ZUID} 261 /bin/bash ${ZS_DIR} ${ZGID} } That way if the zope user already exists, it will change it's primary group to zope, otherwise it will be added that way. I haven't tested this but it looks (more) correct.
zope.initd has a leftover echo ${PIDFILE}, which is debugging cruft and should be removed.
Created attachment 34055 [details] files/2.7.1/zope.initd The old zope.initd wasn't too robust if zope had been killed: stop would fail, even though zope was no longer running. Now it uses is_zope_dead, and if it is, it doesn't try to stop it, and exits successfully.
Created attachment 34059 [details] files/2.7.1/zope.initd Sorry, I actually broke the common restart case where zope is actually running. I think I've checked all the cases now and everything looks okay. I also found a bug in is_zope_dead: A break statement caused a premature exit of the script. This is in 2.6.4-r1 as well, I think.
Created attachment 34078 [details] files/2.7.1/zope.initd The code for determining whether or not zope was still alive was *still* buggy. Since it was excessively complicated to start with, I threw out everything related to is_zope_dead (including read_pid and check_pid_status) and wrote a new zope_is_alive function. The init script is now about 25% the size of the 2.6.4 init script (reduced from 178 loc to 47). Sorry for all the updates. Hopefully this will all get committed soon. Please test this along with attachment #33950 [details] and attachment #33952 [details, diff] and report your results here.
OK, here's a relevant zproduct.eclass complaint: When you remove a package that which inherits from zproduct, it also removes it from all of your zope instances. It does this when you upgrade the package, too. When you install (or upgrade), it only installs into the default instance. If you have more than one instance, you're basically screwed, because only your default instance will have it after an upgrade. And if it didn't have it before, it will now... IMHO, the zproduct class: 1) Should not remove installed products from instances when unmerging the package. 2) Should not try to automatically install products into instances. 3) Should SLOT all zproducts. Re: slotting: /usr/share/zproduct has a directory for each installed zproduct package. Inside that are the product directory(s) supplied by the package. There would not be any conflict with having multiple versions of the same zproduct installed, though only one version of each zproduct can be installed in a given instance. This will probably require reworking zprod-manager a bit. Perhaps the behavior of installing/removing zproducts from instances could be controlled with an environment variable (set in /etc/make.conf), i.e. ZPRODUCT_UPDATE, set to a list of all the instances to automatically update. Also, I think having the default instance being determined by having a .default file in it is a little weird. Why not have a symlink named default in the /var/lib/zope directory to the default instance?
I am afraid that we're making the Gentoo zope install too complicated. The way things are going, we are likely to make all of the existing documentation on Zope irrelevant to Gentoo users. This would be unfortunate and create confusion. I think we should be careful and possibly reduce our ambitions. I expect that very few users care about having multiple instances, and a setting up a single instance is easy (and can follow the bulk of extant docs). Maybe we should have two zope ebuilds, or otherwise have an option to make things "normal" or "super-gentoo-ized"? Please, someone help me, I'm almost ready to suggest adding a use-flag for this! Unless Gentoo plans to take over Zope maintenance, we will never control the "usual" Zope install. Unless we plan to support *every* Zope product in existance, our strange super-gentoo-ized installs are likely to cause trouble. The mitigating factor is that (probably) not many people install Zope. But they should! -Paul Komarek
I agree that most people will not want to run more than one instance. One of the problems with zope-config is that it sort of gives the impression that you should create a new instance for each new version you install, since the default instance name is "zope-". I also don't think most people will want to have more than one version of Zope installed at a time. However, you can't just upgrade a new version over an old version, or automatically unmerge the old version, because you'll break the running instance. This is why I argued previously (in some other bug) that we needed to SLOT on the Zope version number: Update, change your instance config to use the new version, restart, then unmerge your old version when convenient (like if the new version didn't break something important). If anything, with the zope-config patch and new ebuild I have on this bug, configuration is less Gentoo-specific than before, because we're using the mkzopeinstance.py that comes with Zope-2.7, which is what doc/INSTALL says to use. Of course, nobody has to use the Gentoo tools; so long as we install everything in reasonable locations, they can use the standard instructions. In bug #31511 (opened by Paul), there's a good case for moving the installed version of Zope, too, since architecture-dependent files should not be in /usr/share. Most likely they'll move to /usr/lib/zope/${PV}. Anyway, I think the zproduct install mechanism is trying to be too smart at this point, and should leave instances alone. SLOTting zproducts would make things a bit more complicated, but may be necessary in the long run: Some zproducts require an upgrade procedure which we can't anticipate. Plone is the most obvious example.
Bug opened 2004-02-13, now its 2004-07-11 5 months past, all other source distributions already have it, I really think its about time this was added, even if it has to be hard masked.
Agreed. I appreciate all of the hard work you guys have been putting into making this ebuild work the way you want it to, but the time window is starting to get very out of hand here.
I had to upgrade my zope site now, so I just gave it try today. I used zope-2.7.1.ebuild, the patch for zope-config (and patched /usr/sbin/zope-config) and the latest zope.initd. Basically it worked quite OK, but I had some (minor) issues with the permissions. I had to add the zope user manually to the zope group in /etc/groups and I had to change all the subdirectory and files in /var/lib/zope/zope-2.7.1 (INSTANCEHOME) to root:zope (they were owned by root:root and naturally that didn't work at all *g*). After installing some zope products with the zprod-manager I had to change the permissions in /var/lib/zope/zope-2.7.1/Products/, but thats an issue of zprod-manager I think. BTW: I want to go along with Hackeron and Davin and I think, this should be in portage ASAP now. Last but not least: Thank you for your work with these fiddly stuff here. :-)
Created attachment 35340 [details] fixed zope-config OK, this is my zope config patched by both patches visible here. it still contains some unnecesary (?) crud but correctly sets all permissions. it just works (for me :) so you can create working zope instance. i confirm that using zope-2.7.1.ebuild and my zope-config youre able to sucessfulyy emerge zope and install instance without any errors. there is one suggestions: you can change /usr/portage/eclass/zproduct.eclass, there should be chown root:root instead of zope:root (only one chmod in file so its easy to find). its not applicable to this bug, so i dont attach patch. this causes all global versions of zope product being accessible for all users: zope instances (for zprod-manager) and ordinary system users. i think its correct to have 755 permissions on /usr/share/zproduct/* due to fact that not only zope can use these files. if someone want to achive better protecion that should be done in zprod-manager, still i dont think its good idea. i suggest leaving /var/lib/zope/INSTANCE/Products/* as a 755 too.
well :) after a few month and really good work of you, zope2.7.1 and zope-config made their way to portage. i was just able to do some quit testing, probably there are some issues left. so i added them to package.mask i don't dare to close the bug yet :) maybe next week?
Indeed, 2.7.2-rc1 is out as of yesterday (for a security fix), so let's give it a couple of days.
btw, current ebuild should be fixed to allow any python 2.3.x (and propably later). current version has it as specific 2.3.3, so 2.3.4 causes [UD] flags on emerge.
Created attachment 35399 [details, diff] zope-2.7.2_rc1.ebuild.diff This patch is against the 2.7.1 ebuild that is in portage. * Fix sub-version number, URI * Fix python dependency (python-2.3*) * Require zope-config-0.4 or newer * Set the ZS_DIR to /usr/lib/ as expected by new zope-config and be FHS-compatible * Try to make user any existing zope user has the zope group as primary BTW, zope-config looks ok, although there is a typo: sed -i -e 's/uniqe/unique/' /usr/sbin/zope-config One other possible minor issue: In previous testing, I found one product (PloneCollectorNG) which, when you try to create the object within the ZMI, dies because it cannot write to the instance's import directory. Currently this is not one of the directories that is set to be writable, but I suspect that PCNG is somewhat of an exception, and the error produced is quite explicit about what needs to be changed, so I don't really consider it an issue, especially since PCNG is not yet in portage that I'm aware of.
ok, here is my _proposal_, list of changes: 1. added pkg_config to ebuild to create default instance 2. info changes in ebuild (more einfo/ewarn) 3. changed SLOT to NOT include ${PR} 4. also changed /usr/lib/zope to not include ${PR} 5. added default instance management 6. added possibility to zope-config to create instance without user/pass ask i attach zope-config and zope-2.7.2-rc1-r1.ebuild
Created attachment 35770 [details] zope-config-0.4-r1
Created attachment 35771 [details] zope-2.7.2_rc1-r1
2.7.2 is out. Aside from spelling errors, attachment #35771 [details] looks OK to me (I diffed against my zope-2.7.2_rc1.ebuild), but I haven't tried it out yet.
Created attachment 35865 [details] newest zope 2.7.2 ebuild spelling mistakes still present, but small fixes due to tgz name change on zope has been applied to the ebuild. please test it.
Being new to zope and familiar with portage only as a user, thanks for your work! I tried adding the attachment #35865 [details] to /usr/portage/net-zope/zope as zope-2.7.2.ebuild, replacing /usr/portage/app-admin/zope-config/files/0.4/zope-config with attachment #35770 [details] and running emerge --nodeps -uv /usr/portage/net-zope/zope/zope-2.7.2.ebuild /usr/portage/app-admin/zope-config/zope-config-0.4.ebuild (nodeps because zope-2.7.2 requires inexisting zope-config-0.4-r1) zope-config runs fine expect that it complains "install: cannot stat `/usr/lib/zope-2.7.2/skel/zope.initd': No such file or directory". Consequently, in /etc/init.d/ there is no start script for zope-2_7_2. Doing a "cp /usr/portage/net-zope/zope/files/2.7.1/zope.initd /etc/init.d/zope-2_7_2" (for my zope-instance zope-2_7_2) and "chmod 755 /etc/init.d/zope-2_7_2" does the trick and zope seems to be running fine. Using current zwiki-0.32.tgz inside /var/lib/zope/zope-2_7_2/Products works fine (my inital intent to use Zope).
Warper, please put zope.initd into PORTAGE/net-zope/zope/files/2.7.2 directory and emerging 2.7.2 ebuild (35865) will install into into skell directory, making it ready for zope-config use.
i'm starting to integrate your fixes to portage. just a few things to mention: please post patches/diffs, not entire ebuilds. e.g. 2.7.2 ebuild is not in sync with 2.7.1....
integrated to portage
zope-2.7.2.ebuild : enewuser fails on completely new zope install I neverd had installed zope on my gentoo box, thus emerge will install zope user and group. For the user, it tries to create a home directory, which fails. ACCEPT_KEYWORDS="~x86" emerge zope 2>&1 | tee -a /tmp/emerge.log gives me the following output excerpt (1st run / 2nd run) * Caching service dependencies... * Adding group 'zope' to your system ... * - Groupid: 261 usermod: user zope does not exist * Adding user 'zope' to your system ... * - Userid: 261 * - Shell: /bin/bash * - Home: zope * - Groups: (none) useradd: invalid home directory `zope' !!! ERROR: net-zope/zope-2.7.2 failed. !!! Function enewuser, Line 641, Exitcode 3 !!! enewuser failed 2nd try ----------- usermod: user zope does not exist * Adding user 'zope' to your system ... * - Userid: 261 * - Shell: /bin/bash * - Home: zope * - Groups: (none) useradd: invalid home directory `zope' !!! ERROR: net-zope/zope-2.7.2 failed. !!! Function enewuser, Line 641, Exitcode 3 !!! enewuser failed
Toni, afaik its caused by removal of lines: ZGID_INST="$(echo ${PN}-${PV} | sed -e 's/\./_/g' )" ZS_DIR=${ROOT}/usr/lib/ ZI_DIR=${ROOT}/var/lib/zope/ from ebuild which went into portage. it also can result in broken pkg_config. got to investigate it.
re-added :) now i know why you introduced these vars
I don't understand why it is that the new zope.initd was set up to require zope-config doing a search/replace to set the path. It would have been much simpler to use the $INSTANCE_HOME environment variable that comes automatically from /etc/conf.d/<instancename>, particularly if that script ever needs to be upgraded. sed -i -e 's/INSTANCE_HOME/${INSTANCE_HOME}/g' zope.initd
