Zope's Organization for Virtual Servers
Hello, I am in the process of working with my webhost on the best way to provide Zope Hosting in a virtual server environment. My webhost like many is using Linux and Apache. I had a thought and a question I wanted to pose. What would it take to setup Zope in somewhat a similar many to the way Python is setup for cgi? What I mean by that is if Zope was setup in a specified location /usr/bin/Zope or something such. Then in their own directory they have the products, external methods, /var directory, pcgiinfofiles, etc. All the items they create and generate which are not a part of the Zope distribution. This way, when the website is accessed, pcgi would instantiate a new Zope instance (if necessary) for this specific site and populate it with the site's files. This would allow for the webhost to have a single Zope install which could be forked/instantiated for each site as required. This would also allow for simplified upgrading of Zope for the webhost and users. The webhost could install a new Zope in it's own directory, usr/bin/Zope_1.10.2 and the user would just have to update their pcgiinfofile to access the new Zope install. Possibly less things to break when updating. Wouldn't have to move/copy/backup the /var directory etc. simply to upgrade. This seams to be simpler on the end user and on the webhost sysadmin. Of course I may have an over-simplified view of things. :) Just a thought. Jimmie Houchin Now it's time to get into my new book. Learning GNU Emacs. :)
On Fri, 19 Feb 1999, Jimmie Houchin wrote:
Hello,
I am in the process of working with my webhost on the best way to provide Zope Hosting in a virtual server environment.
My webhost like many is using Linux and Apache.
I had a thought and a question I wanted to pose.
What would it take to setup Zope in somewhat a similar many to the way Python is setup for cgi?
What I mean by that is if Zope was setup in a specified location /usr/bin/Zope or something such. Then in their own directory they have the products, external methods, /var directory, pcgiinfofiles, etc. All the items they create and generate which are not a part of the Zope distribution.
This way, when the website is accessed, pcgi would instantiate a new Zope instance (if necessary) for this specific site and populate it with the site's files.
This would allow for the webhost to have a single Zope install which could be forked/instantiated for each site as required.
This would also allow for simplified upgrading of Zope for the webhost and users. The webhost could install a new Zope in it's own directory, usr/bin/Zope_1.10.2 and the user would just have to update their pcgiinfofile to access the new Zope install.
Possibly less things to break when updating. Wouldn't have to move/copy/backup the /var directory etc. simply to upgrade.
This seams to be simpler on the end user and on the webhost sysadmin.
Of course I may have an over-simplified view of things. :) Just a thought.
Jimmie Houchin
Now it's time to get into my new book. Learning GNU Emacs. :)
We could anwser all of these questions for you for $1,000,000 dollars right now. Or you can wait for the next release of zope where we added these exact features, that is of course if DC hasen't lost our patch or ripped it to shreds yet. --------------------------------------------------- - Scott Robertson Phone: 714.972.2299 - - CodeIt Computing Fax: 714.972.2399 - - http://codeit.com - ---------------------------------------------------
At 05:19 PM 2/19/99 -0800, Scott Robertson wrote:
On Fri, 19 Feb 1999, Jimmie Houchin wrote: <snip Feature request deleted. > We could anwser all of these questions for you for $1,000,000 dollars right now. Or you can wait for the next release of zope where we added these exact features, that is of course if DC hasen't lost our patch or ripped it to shreds yet.
--------------------------------------------------- - Scott Robertson Phone: 714.972.2299 - - CodeIt Computing Fax: 714.972.2399 - - http://codeit.com - ---------------------------------------------------
Great! Do you accept checks? :) Jimmie Houchin
On Fri, 19 Feb 1999, Jimmie Houchin wrote:
Hello,
I am in the process of working with my webhost on the best way to provide Zope Hosting in a virtual server environment.
My webhost like many is using Linux and Apache.
I had a thought and a question I wanted to pose.
What would it take to setup Zope in somewhat a similar many to the way Python is setup for cgi?
What I mean by that is if Zope was setup in a specified location /usr/bin/Zope or something such. Then in their own directory they have the products, external methods, /var directory, pcgiinfofiles, etc. All the items they create and generate which are not a part of the Zope distribution.
This way, when the website is accessed, pcgi would instantiate a new Zope instance (if necessary) for this specific site and populate it with the site's files.
This would allow for the webhost to have a single Zope install which could be forked/instantiated for each site as required.
This would also allow for simplified upgrading of Zope for the webhost and users. The webhost could install a new Zope in it's own directory, usr/bin/Zope_1.10.2 and the user would just have to update their pcgiinfofile to access the new Zope install.
Possibly less things to break when updating. Wouldn't have to move/copy/backup the /var directory etc. simply to upgrade.
This seams to be simpler on the end user and on the webhost sysadmin.
Of course I may have an over-simplified view of things. :) Just a thought.
Jimmie Houchin
Now it's time to get into my new book. Learning GNU Emacs. :)
Jimmie, My apologies, I just reread your request and realized my previous answer was inaccurate. One of the developers here had told me about your request and how it was similar to some of the tricks we have used to setup Zope to do virtual hosting, and I had only skimmed your message. The patch I had mentioned was for something else that can give added functionality once you set Zope up to run the way you described. Anyhow, what your requesting already exists inside of Zope. Zope uses an environment variable called INSTANCE_HOME to determine where the var/ directory is. So for example if you set INSTANCE_HOME = /tmp then run Zope it would expect the object database to be in /tmp/var. What you can do next is to combine this with apache's <VirtualHost> and SetEnv directives to have the server launch one process per site. For example in your httpd.conf try this: <VirtualHost localhost> RewriteEngine on RewriteOptions inherit SetEnv INSTANCE_HOME /home/localhost SetEnv PCGI_SOCKET_FILE /home/localhost/var/pcgi.soc SetEnv PCGI_PID_FILE /home/localhost/var/pcgi.pid </VirtualHost> This will launch an instance of zope that works out of /home/localhost. You can add a similar line to the file for a different virtual host, just change the directories. You must make sure of course that their is a rewrite rule somewhere in your httpd.conf that points requests to Zope.cgi (pcgi wrapper conf file) and passes the correct Auth information. ***BLATANT PLUG**** If your ISP is still having problems and they need a consultant have them call me. =) --------------------------------------------------- - Scott Robertson Phone: 714.972.2299 - - CodeIt Computing Fax: 714.972.2399 - - http://codeit.com - ---------------------------------------------------
Anyhow, what your requesting already exists inside of Zope. Zope uses an environment variable called INSTANCE_HOME to determine where the var/ directory is. So for example if you set INSTANCE_HOME = /tmp then run Zope it would expect the object database to be in /tmp/var.
What you can do next is to combine this with apache's <VirtualHost> and SetEnv directives to have the server launch one process per site. For example in your httpd.conf try this:
<VirtualHost localhost> RewriteEngine on RewriteOptions inherit SetEnv INSTANCE_HOME /home/localhost SetEnv PCGI_SOCKET_FILE /home/localhost/var/pcgi.soc SetEnv PCGI_PID_FILE /home/localhost/var/pcgi.pid </VirtualHost>
Make sure you have the latest version of pcgi_wrapper. When we first started to do this, there was a bug in pcgi_wrapper that caused it not to read the environment variables. We fixed it, and the patch has since been applied, but just so you know, if it doesn't seem to work, make sure you have the latest version.
participants (3)
-
Jimmie Houchin -
ngarcia -
Scott Robertson