I have been playing with Zope for months and am a few weeks away from putting a full Zopified site into production. I have a dedicated box so I can do whatever I want in terms of configurations and after reading everything I can get my hands on as possible solutions (I have read http://www.zope.org/Members/guy_davis/install_routes) 1) ZServer Only - This should be the simplest and fastest. The drawback I see is that I will not be able to do SSL or have very good logs to run webserver statistics software on (MKStats, Analog, etc). 2) ZServer Behind Apache + Proxy - This is the second fastest and is relatively easy (have done it once). I get my Apache logs, SSL (I think) but It require SiteAcesss product which could (and seems to) conflict with other products/functionality. 3) Apache, FAST PCGI (Zope.cgi) + ZServer - This is the slowest of them all (a new process for every request) but I most people are using this and allows for all sorts of other goodies that Apache can do (Virtual hosts, logs, SSL, etc). Is there anything I am missing or does anyone have some suggestions/comments on implementations? Thanks, JMA
Yikes have I got problems. Our server went down this morning, so I went to restart Zope after rebooting the machine. Only, the Data.fs seems to be corrupt. Traceback (innermost last): File "z2.py", line 436, in ? exec "import "+MODULE in {} File "<string>", line 1, in ? File "/home/httpd/Zope-2.1.2-linux2-x86/lib/python/Zope/__init__.py", line 109, in ? DB=ZODB.FileStorage.FileStorage(Globals.BobobaseName) File "/home/httpd/Zope-2.1.2-linux2-x86/lib/python/ZODB/FileStorage.py", line 301, in __init__ self._pos, self._oid, tid = read_index( File "/home/httpd/Zope-2.1.2-linux2-x86/lib/python/ZODB/FileStorage.py", line 1359, in read_index name, pos) File "/home/httpd/Zope-2.1.2-linux2-x86/lib/python/ZODB/FileStorage.py", line 218, in panic raise CorruptedTransactionError, message ZODB.FileStorage.CorruptedTransactionError: /home/httpd/Zope/var/Data.fs redundant transaction length check failed at 7683968 Now, I have truncated the Data.fs as seen in a previous Zope post by Jim Fulton, but unfortunately, I can't do this.. the Zope Data.fs as it is is right around 11.8M, and cutting off the file at 7.6M is not an option at this point. Is there any way to recover? ANY help at this point would be appreciated.. Adam -- M. Adam Kendall | mak@kha0s.org | "There's never enough time to do http://kha0s.org | all the nothing you want." | --Bill Watterson (Calvin and Hobbes)
----- Original Message ----- From: J. Atwood <Jatwood@bwanazulia.com>
2) ZServer Behind Apache + Proxy - This is the second fastest and is relatively easy (have done it once). I get my Apache logs, SSL (I think) but It require SiteAcesss product which could (and seems to) conflict with other products/functionality.
Not *too* much, I hope. The only "conflict" which I am certain still exists in v1.0.0 is between virtual hosts trying to access the same ZCatalog. That said, you shouldn't need SiteAccess for a proxying solution if your *entire* site will be proxied. For example... ProxyPass / http://zopeserver:8080/ ...shouldn't require any adjustments to Zope. Cheers, Evan @ 4-am & digicool
At 13:23 Uhr -0600 17.02.2000, Evan Simpson wrote:
----- Original Message ----- From: J. Atwood <Jatwood@bwanazulia.com>
2) ZServer Behind Apache + Proxy - This is the second fastest and is relatively easy (have done it once). I get my Apache logs, SSL (I think) but It require SiteAcesss product which could (and seems to) conflict with other products/functionality.
Not *too* much, I hope. The only "conflict" which I am certain still exists in v1.0.0 is between virtual hosts trying to access the same ZCatalog.
Mhmm, I guess there are quite some possibilities to break the virtual hosting done by SiteAccess (the proxypass solution as to the HowTo by anser <http://www.zope.org/Members/anser/apache_zserver/index_html>) ZPhotoAlbum for example uses an index_html method to redirect users to the correct page and this renders the path based on the PATH_INFO, which does not seem to be modified by SiteAccess like this <dtml-call "REQUEST.set('to_url', _.string.split(PATH_INFO, album_id, 1))"> <dtml-if "REQUEST.cookies.has_key('pv')"> <dtml-call "REQUEST.set('to_url', '%s%s%s/%s/%s%s' % (SERVER_URL, to_url[0], album_id, REQUEST.cookies['pv'], album_id, to_url[1]))"> <dtml-else> <dtml-call "REQUEST.set('to_url', '%s%s%s/%s/%s%s' % (SERVER_URL, to_url[0], album_id, 'simple', album_id, to_url[1]))"> </dtml-if> <p>Please <a href="&dtml-to_url;">continue</a>.</p> <dtml-call "RESPONSE.redirect(to_url)"> After this, you end up with a location field that does not represent the VHost, but VHost-based links, the pages break. Jochen
----- Original Message ----- From: Jochen Haeberle <listen@MIDRAS.de>
Not *too* much, I hope. The only "conflict" which I am certain still exists in v1.0.0 is between virtual hosts trying to access the same ZCatalog.
ZPhotoAlbum for example uses an index_html method to redirect users to the correct page and this renders the path based on the PATH_INFO, which does not seem to be modified by SiteAccess
True, I spoke a bit too strongly. I suppose I should say that I know of no other conflict between SiteAccess and "well-behaved" Zope code :-) Anyone using any REQUEST fields other than BASEn, URLn, and absolute_url to construct links should think about what *else* might break their code in the future. Cheers, Evan @ 4-am & digicool
At 8:54 Uhr -0600 18.02.2000, Evan Simpson wrote:
----- Original Message -----
Not *too* much, I hope. The only "conflict" which I am certain still exists in v1.0.0 is between virtual hosts trying to access the same ZCatalog.
ZPhotoAlbum for example uses an index_html method to redirect users to the correct page and this renders the path based on the PATH_INFO, which does not seem to be modified by SiteAccess
True, I spoke a bit too strongly. I suppose I should say that I know of no other conflict between SiteAccess and "well-behaved" Zope code :-) Anyone using any REQUEST fields other than BASEn, URLn, and absolute_url to construct links should think about what *else* might break their code in the future.
Mhmm... why does doing this (using PATH_INFO to construct a URL) qualify one to code miss-behaved Zope-Code??? Where are the rules what's good and bad code??? Jochen
[J. Atwood, on Thu, 17 Feb 2000] :: I have been playing with Zope for months and am a few weeks away from :: putting a full Zopified site into production. I have a dedicated box so I :: can do whatever I want in terms of configurations and after reading :: everything I can get my hands on as possible solutions (I have read :: http://www.zope.org/Members/guy_davis/install_routes) :: :: 1) ZServer Only - This should be the simplest and fastest. The drawback I :: see is that I will not be able to do SSL or have very good logs to run :: webserver statistics software on (MKStats, Analog, etc). :: :: 2) ZServer Behind Apache + Proxy - This is the second fastest and is :: relatively easy (have done it once). I get my Apache logs, SSL (I think) but :: It require SiteAcesss product which could (and seems to) conflict with other :: products/functionality. :: :: 3) Apache, FAST PCGI (Zope.cgi) + ZServer - This is the slowest of them all :: (a new process for every request) but I most people are using this and :: allows for all sorts of other goodies that Apache can do (Virtual hosts, :: logs, SSL, etc). :: :: Is there anything I am missing or does anyone have some suggestions/comments :: on implementations? This certainly qualifies as a FAQ (see the similar 'Apache + ZServer + SiteAccess' thread earlier today) and indeed noone installing Zope can escape having to navigate this decision tree. I'd welcome seeing further discussion and clarification here on this list from experts on this subject. But eventually, wouldn't the community really benefit from a HOW-TO on this? At the moment, the information about all the details and gotchas are scattered in various places. Or perhaps Chris McDonough's excellent installation HOW-TO might be the proper receptacle for all the ins and outs of this?
participants (5)
-
Evan Simpson -
J. Atwood -
Jochen Haeberle -
M. Adam Kendall -
Patrick Phalen