I'm wondering how PCGI should be supported in Zope moving forward. We currently have: - A PCGI server in ZServer - A pcgi directory that contains: o A cgi program that is very thin and whos only job is to forward requests to an app server running pcgi o An unused PCGI "publisher", which would be used by a Python application server that wasn't running ZServer. o A debugging tool named MrCreosote. I don't know if anyone is using this. I'd like to continue supporting PCGI in ZServer as long as it is used. I'd like to omit the pcgi directory fron the Zope distribution and make it a separate distribution. Would anyone object to these changes for Zope 2.7? Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (888) 344-4332 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Having only ever used Zope-behind-PCGI myself, if we drop it, what would be the prevailing approach for running Zope behind Apache? Has everyone switched to FastCGI (or Quixote's SCGI) but me? Be aware that there are Zope-specific patches (some of which I provided) in the version of PCGI that Zope ships with, so you can't refer everyone to the non-Zope version of PCGI available elsewhere on the web. The patches relate to error handling and meaningful reporting, not core functionality. -Jeff Dieter Maurer wrote:
Jim Fulton wrote at 2003-2-13 11:30 -0500:
I'm wondering how PCGI should be supported in Zope moving forward. Do we still need it?
I would prefer to drop it (to reduce complexity).
Hi I have always run Zope behind Apache utilising mod_proxy. I have to admit I never tried or really even evaluated pcgi, and don't build it when I install Zope. Is there a benefit of pcgi over using mod_proxy ? Rgds Tim Hoffman On Fri, 2003-02-14 at 09:16, Jeff Rush wrote:
Having only ever used Zope-behind-PCGI myself, if we drop it, what would be the prevailing approach for running Zope behind Apache? Has everyone switched to FastCGI (or Quixote's SCGI) but me?
Be aware that there are Zope-specific patches (some of which I provided) in the version of PCGI that Zope ships with, so you can't refer everyone to the non-Zope version of PCGI available elsewhere on the web. The patches relate to error handling and meaningful reporting, not core functionality.
-Jeff
Dieter Maurer wrote:
Jim Fulton wrote at 2003-2-13 11:30 -0500:
I'm wondering how PCGI should be supported in Zope moving forward. Do we still need it?
I would prefer to drop it (to reduce complexity).
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org 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 )
I had thought (obviously incorrectly) that mod_proxy was hard to configure correctly to pass all headers, particularly in complex virtual hosting scenarios. But I'm no Apache expert. And I thought that mod_redirect added overhead to every request, doing the redirect cycle via the browser. It also exposed the port 8000-based Zope to direct access, which some admin's might not want. But mostly I thought PCGI (and FastCGI) was the preferred way, since it is covered in detail in Zope's doc/WEBSERVER.TXT and neither mod_proxy nor mod_redirect are mentioned in there. ;-) I just figured PCGI was cleaner and let me delegate responsibility to each hosting client, to manage their own CGI-BIN stuff w/o access to Apache's config files.. So if we drop PCGI, we'll need an action item to rework that file and perhaps ZopeBook et. al. -Jeff Tim Hoffman wrote:
I have always run Zope behind Apache utilising mod_proxy.
I have to admit I never tried or really even evaluated pcgi, and don't build it when I install Zope.
Is there a benefit of pcgi over using mod_proxy ?
Guido van Rossum wrote:
AFAIK most people use Apache's mod_redirect to a Zope HTTP server running at (e.g.) port 8000. No additional software needed.
On Fri, 2003-02-14 at 09:16, Jeff Rush wrote:
Having only ever used Zope-behind-PCGI myself, if we drop it, what would be the prevailing approach for running Zope behind Apache? Has everyone switched to FastCGI (or Quixote's SCGI) but me?
But mostly I thought PCGI (and FastCGI) was the preferred way, since it is covered in detail in Zope's doc/WEBSERVER.TXT and neither mod_proxy nor mod_redirect are mentioned in there. ;-)
Unfortunately thats more a matter of documentation inertia more than anything. There are more articles on Zope.org about PCGI as well simply because it has been around the longest, although almost everyone I know runs through mod_proxy nowadays. -- Andy McKay
Andy McKay wrote:
Unfortunately thats more a matter of documentation inertia more than anything. There are more articles on Zope.org about PCGI as well simply because it has been around the longest, although almost everyone I know runs through mod_proxy nowadays.
I'd actually say it's because PCGI is the hardest to get working right ;-) mod_proxy and mod_rewrite work wonderfully for us. Never heard of mod_rewrite forcing redirects at the browser and all our 8xxx ports are blocked at the firewall... I'd vote to see PCGI vanish. cheers, Chris
Is there a benefit of pcgi over using mod_proxy ?
There was. pcgi worked over a unix domain socket, and unix domain sockets can be compartentalized much easier than say, a tcp port. This means you could effectively use pcgi with a single apache instance fronting for several zope+pcgi instances in a virtual-hosting scenario. (I used mod_pcgi2 for this purpose.) This had several seperation advantages as you can then run the zope instances as different users, ensuring your zope vhosts have no ability to cross-contaminate eachother at the zodb level, plus it was easy to define a filesystem namespace for every vhost (all of customer Foo's files go in ~foo, nice and easy). What happened is that PCGI wasn't maintained and its scalability went to hell. Zope hosting companies, atleast the one I worked for, had to switch to mod_proxy because pcgi just fell over if you looked at it funny. That means virtual hosting then requires either managing a battery of internal interface aliases, or a map of ports on some internal interface, or throwing all your eggs into one basket (zodb). All of which are less than sexy, IMO. Unix domain sockets would be great, but apache has no way to forward requests to them that I know of, outside of custom modules. Apart from that, pcgi was about on par with mod_rewrite in terms of integration with Apache. Better integration could be possible if someone wrote a module that let zope speak directly to the Apache API. To date though people seem to be more enthralled with the idea of loosely connecting Zope and Apache at the protocol. -- Jamie Heilman http://audible.transient.net/~jamie/ "I was in love once -- a Sinclair ZX-81. People said, "No, Holly, she's not for you." She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway." -Holly
Jamie Heilman wrote:
This means you could effectively use pcgi with a single apache instance fronting for several zope+pcgi instances in a virtual-hosting scenario. (I used mod_pcgi2 for this purpose.) This had several seperation advantages as you can then run the zope instances as different users, ensuring your zope vhosts have no ability to cross-contaminate eachother at the zodb level, plus it was easy to define a filesystem namespace for every vhost (all of customer Foo's files go in ~foo, nice and easy).
We do all of this using mod_rewrite and mod_proxy.
just fell over if you looked at it funny. That means virtual hosting then requires either managing a battery of internal interface aliases, or a map of ports on some internal interface, or throwing all your eggs into one basket (zodb).
...and we don't do any of this, as far as I'm aware. cheers, Chris
just fell over if you looked at it funny. That means virtual hosting then requires either managing a battery of internal interface aliases, or a map of ports on some internal interface, or throwing all your eggs into one basket (zodb).
...and we don't do any of this, as far as I'm aware.
So how do you do it? You've got to proxy those connections to somewhere, and it isn't a unix domain socket unless you know something about Apache I don't. Point is, files are "easier" to manage than network resources when it comes to ensuring uniqueness. -- Jamie Heilman http://audible.transient.net/~jamie/ "It's almost impossible to overestimate the unimportance of most things." -John Logue
Jamie Heilman wrote:
just fell over if you looked at it funny. That means virtual hosting then requires either managing a battery of internal interface aliases, or a map of ports on some internal interface, or throwing all your eggs into one basket (zodb).
...and we don't do any of this, as far as I'm aware.
So how do you do it? You've got to proxy those connections to somewhere, and it isn't a unix domain socket unless you know something about Apache I don't. Point is, files are "easier" to manage than network resources when it comes to ensuring uniqueness.
Don't think so, if you try and use the same port for two different Zope's you get a 'Port in use' error on the one that started up second (on Linux, anyway). cheers, Chris
Chris Withers wrote:
Don't think so, if you try and use the same port for two different Zope's you get a 'Port in use' error on the one that started up second (on Linux, anyway).
So you use a port map from the sound of it. I think thats too error prone and too ugly myself. Consider, you've got 20 zope instances, and 1 apache instance. Your job as the admin is to maintain a consistent configuration that encompasses the tethering of apache to zope. You can generate your configs using any number of scripting utilities. To figure out which port is 'free' you must now keep a list of zope to port mappings, so when you add a new a new instance you don't re-use a port. Yes, you could strafe the port list in a given range looking for one that already wasn't in use, but thats going to fail badly when you hit a port that is temporarily down. (who hasn't hit that dead modem in the hunt group at some point in their life) A list is safer, but its cumbersome to maintain because there's nothing inately ingrained about "port 8072" that makes one think of bobs.example.com. This is one of the things unix domain sockets are better at. You don't need a port map list if you know that the socket for bobs.example.com will always appear at /home/bobs/var/run/zope.sock. Its much easier to script configuration policies when the namespaces assure uniqueness and its much easier to do hand configuration when a domain's resources have a human recognisable property thats eases association. Plus the cost of maintaining a mapping list is much higher (especially given collision and concurrency issues that arise with multiple admins, which you must plan for) than simply using a schema which ensures uniqueness. And thats ignoring the various debates around firewalling practices as a first line of defence, weak vs. strong ES models, etc. Now all that said, I too think pcgi should just be dropped entirely from zope. It was an interesting idea, but unmaintained it does more harm than good. -- Jamie Heilman http://audible.transient.net/~jamie/ "We must be born with an intuition of mortality. Before we know the words for it, before we know there are words, out we come bloodied and squalling with the knowledge that for all the compasses in the world, there's only one direction, and time is its only measure." -Rosencrantz
Jamie Heilman wrote:
Now all that said, I too think pcgi should just be dropped entirely from zope. It was an interesting idea, but unmaintained it does more harm than good.
No sure I agree with your reasoning around port maps and domain sockets, but I do strongly agree with this statement in any case... cheers, Chris
Having only ever used Zope-behind-PCGI myself, if we drop it, what would be the prevailing approach for running Zope behind Apache? Has everyone switched to FastCGI (or Quixote's SCGI) but me?
AFAIK most people use Apache's mod_redirect to a Zope HTTP server running at (e.g.) port 8000. No additional software needed. --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (9)
-
Andy McKay -
Ben Avery -
Chris Withers -
Dieter Maurer -
Guido van Rossum -
Jamie Heilman -
Jeff Rush -
Jim Fulton -
Tim Hoffman