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