On Tue, 2003-03-11 at 00:24, Edward Muller wrote:
> Once zope is installed in /opt/zope-2.7.0 can it be moved without
> damaging the install .... say to
> /home/virtual/some.host.name/opt/zope-2.7.0 ?

Yes.  Its location is only meaningful to the instance files that need to
find it.

> In our hosting setup some things get run in a chroot, some things
> can't...
> Currently zope get's installed in a chroot environment for anyone who
> wants a zope install. It must be a complete install since when the user
> restarts it he will be in his chroot environment.
> So I'd ideally like to install zope in a way where all of the core of
> zope is in one place ... say ... /opt/zope/<version #> (/opt/zope/2.7.0,
> /opt/zope/2.7.1, etc...)
> This I can hardlink/symlink into each chroot and make permissions 755
> root/root.

I think this will work.  The only thing that might be a little weird is
tracebacks generated by pyc files, as they may report the filenames of
the Python modules where they were originally installed, instead of
where they live now.  There is some contention about whether this
happens under Python 2.2, but I know it's true for Python 2.1 and prior.

> >From there I would like to be able to install an 'instance', which is
> ... in my case meaning the data.fs, /Products directory, log files, etc,
> etc. The stuff that make this users instance theirs. When the install is
> happening, the script executing it would most likely be outside of the
> chroot ... but I guess it could be configured to chroot as well..

You would need to chroot the run of makeinstance currently as it encodes
paths to software within the instance files that start Zope.  So if you
ran it outside the chroot it would work, but when the user logged in to
the chroot, the paths to the software would be wrong.

I think this might be made configurable with a switch to mkzopeinstance
(--sw_location=/some/path), though.  I will add this to the tentative
TODO, thanks.

> I already have start/stop scripts to go through the users that have a
> zope install and chroot into that users 'host' and then start zope as
> that 'hosts' administrative user.

These scripts will unfortunately need to change for Zope 2.7 unless we
create some sort of backwards compatibilty layer for startup.

- C

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to