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?' :-) -- Edward Muller Interlix - President Web Hosting - PC Service & Support Custom Programming - Network Service & Support Phone: 417-862-0573 Cell: 417-844-2435 Fax: 417-862-0572 http://www.interlix.com _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )