On Tue, 2003-03-11 at 08:48, Chris McDonough wrote:
> 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.
Well I can install zope in /opt/zope/2.7.1 (in the real root) and then
when I symlink/hardlink it into a virtual host I can link it into that
hosts /opt/zope/2.7.1 ... So that's not a biggie....
> > >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.
That's not a problem ... at least IIRC. I can chroot when creating the
account in a shell script and execute custom setup scripts.
> 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.
all thought that would be nice.
> > 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.
Yeah. Oh well. They aren't that complex. :-) I wouldn't worry about the
backward compatibility layer myself. I don't know if there is a great
value add to it, aside from keeping users from going 'WTF happened?' :-)
Interlix - President
Web Hosting - PC Service & Support
Custom Programming - Network Service & Support
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -