Re: [Zope-dev] Re: [Zope] Proposed installation changes for review
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/ (/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 )
Re: [Zope-dev] Re: [Zope] Proposed installation changes for review
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/ (/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] 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 )
[Zope-dev] Re: [Zope] Proposed installation changes for review
Okay here is another one :-) given... ./configure --prefix=/opt/zope-2.7.0 make make install 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 ? 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/ (/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. >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.. 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. On Mon, 2003-03-10 at 21:47, Chris McDonough wrote: > On Mon, 2003-03-10 at 22:13, Edward Muller wrote: > > Hopefully I'll get to play with this later on in the week.. > > > > But here are the things I know I need as part of my business: > > > > -The ability to specify which python to use to build, install and run > > zope with. Our production machines have various version 1.5.2, 2.1.X, > > 2.2.X, etc installed. I must be able to specify the location. > > Yup. > > ./configure --with-python=/path/to/your/python > > > > > -The ability for each instance to have separate Product directories. > > Some users want plone, some don't. Some develop their own software. > > This is inherent in INSTANCE_HOME behavior. The result of > "mkzopeinstance" will contain a Products directory which may contain > Zope software. Many instances can be configured to run from a single > software home (a software home is the result of "make install") > > > > > -The ability to start/stop zope without access to /proc (or the > > equivalent on other unices) on Linux. > > Yes. > > > > > I don't know if the changes made affect any of the above ... but it > > would suck major #$W%% if it did. Oh, and part of my business if hosting > > zope ... if you are wondering where the above (off the top of my head > > list) comes from. Other than that it looks like the changes will be good > > for me. > > > > Oh and some way to have multiple zope versions installed at the same > > time would be great as well. :-) > > Sure. > > In a Zope 2.7.0 source directory: > > ./configure --prefix=/opt/zope-2.7.0 > make > make install > > In a Zope 2.7.1 source directory: > > ./configure --prefix=/opt/zope-2.7.1 > make > make install > > ... then 'mkzopeinstance' from either. > > - C > > > > ___ > Zope maillist - [EMAIL PROTECTED] > http://mail.zope.org/mailman/listinfo/zope > ** No cross posts or HTML encoding! ** > (Related lists - > http://mail.zope.org/mailman/listinfo/zope-announce > http://mail.zope.org/mailman/listinfo/zope-dev ) -- 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 )
[Zope-dev] Re: [Zope] Proposed installation changes for review
On Mon, 2003-03-10 at 22:13, Edward Muller wrote: > Hopefully I'll get to play with this later on in the week.. > > But here are the things I know I need as part of my business: > > -The ability to specify which python to use to build, install and run > zope with. Our production machines have various version 1.5.2, 2.1.X, > 2.2.X, etc installed. I must be able to specify the location. Yup. ./configure --with-python=/path/to/your/python > > -The ability for each instance to have separate Product directories. > Some users want plone, some don't. Some develop their own software. This is inherent in INSTANCE_HOME behavior. The result of "mkzopeinstance" will contain a Products directory which may contain Zope software. Many instances can be configured to run from a single software home (a software home is the result of "make install") > > -The ability to start/stop zope without access to /proc (or the > equivalent on other unices) on Linux. Yes. > > I don't know if the changes made affect any of the above ... but it > would suck major #$W%% if it did. Oh, and part of my business if hosting > zope ... if you are wondering where the above (off the top of my head > list) comes from. Other than that it looks like the changes will be good > for me. > > Oh and some way to have multiple zope versions installed at the same > time would be great as well. :-) Sure. In a Zope 2.7.0 source directory: ./configure --prefix=/opt/zope-2.7.0 make make install In a Zope 2.7.1 source directory: ./configure --prefix=/opt/zope-2.7.1 make make install ... then 'mkzopeinstance' from either. - C ___ 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 )
[Zope-dev] Re: [Zope] Proposed installation changes for review
Hopefully I'll get to play with this later on in the week.. But here are the things I know I need as part of my business: -The ability to specify which python to use to build, install and run zope with. Our production machines have various version 1.5.2, 2.1.X, 2.2.X, etc installed. I must be able to specify the location. -The ability for each instance to have separate Product directories. Some users want plone, some don't. Some develop their own software. -The ability to start/stop zope without access to /proc (or the equivalent on other unices) on Linux. I don't know if the changes made affect any of the above ... but it would suck major #$W%% if it did. Oh, and part of my business if hosting zope ... if you are wondering where the above (off the top of my head list) comes from. Other than that it looks like the changes will be good for me. Oh and some way to have multiple zope versions installed at the same time would be great as well. :-) On Mon, 2003-03-10 at 15:41, Chris McDonough wrote: > Hi folks, > > An effort to improve Zope 2 installation, startup, and configuration for > Zope 2.7 has been ongoing for some time now (see > http://dev.zope.org/Wikis/DevSite/Proposals/InstallationAndConfiguration). > The effort has reached a point where we believe it is reasonable to > merge its fruits to the Zope trunk. Before doing so, however, we want > to gather input from people who care deeply about Zope configuration and > installation; particularly those who have significant investments in the > existing behaviors of Zope 2 configuration and installation. A bunch of > stuff is changed (most notably Zope no longer uses environment variables > as configuration, and instead defers to command-line arguments and > config file values). > > What follows is a summary of changes, a walk-through of a Zope 2 > installation under this regime, and a list of the configuration-file > changeable parameters exposed by the current Zope configuration schema. > > Please provide your feedback before this Friday, March 14. If possible, > check out and try the new software. If there are showstopper issues for > a lot of people, we will consider not performing the merge directly > after that date. Otherwise, the merge will be performed at any time > after the 14th. > > Thanks! > > - C > > - > Major changes in Zope 2.7 > = > > Zope 2.7 will contain a number of changes related to the build process > and configuration. The scripts used to start Zope will also be > substantially changed. The implementation of these changes is not yet > complete, but a substantial portion has been done and is expected to > be merged into the Zope 2 trunk in the near future. > > The exact schedule for merging these changes has not been determined; > additional notice will be provided. These changes are substantially > based on efforts by Chris McDonough on the "chrism-install-branch". > > Major changes > - > > The following are the most important and user-visible changes compared > to Zope 2.6 and the current CVS HEAD: > > - Configuration is normally done by editing a config file instead of > passing command line options. The configuration file is handled by > the ZConfig package. > > - Environment variables are no longer used for configuration. > > - Building and installing the software have become more clearly > distinct; the installation can be separate from the build. > > - Zope 2.7 uses the "instance home" model in the normal case: a script > in the installed software is used to create new "instances" of Zope. > Each instance is defined by a directory tree containing > configuration, scripts, and data. (For convenience, the instance > and the installation can be located in the same directory, and the > build area may be used in lieu of an installation if desired.) > > - The z2.py, start, and stop scripts have been replaced by the runzope > and zopectl scripts. > > - The runzope/zopectl scripts do not accept the same command-line > arguments as z2.py used to accept. > > - The wo_pcgi.py script used to build Zope without PCGI support has > been replaced by the common Unix build sequence of configure, make. > > - The pcgi/ directory and the w_pcgi.py script have been removed from > the top of the source tree. The pcgi/ directory may be made > available as a separate distribution. (The application server still > has support to allow connections from a PCGI-capable Web server.) > > - The ZServer package has been moved from the top of the source tree > into the lib/python/ directory. > > > Getting the code today > -- > > The implementation lives in the "new-install-branch", which is a > "partial" branch rather than a complete branch: only the files and > directories which need to be changed have been placed on the branch; > all other files are used from the CVS HEAD. The current state of this > code can be checked out from
