Hi; I have my own server with virtual hosts. I'm going to build a large Web site on this server with Zope as the base platform. I intend to build more on the Zope platform, but already have several sites built without it. My question is, how do I edit the z2.py file in such a way that I can call up certain virtual hosts and not others through port 80? Also, can I build the equivalent of a doc root off of the Zope root such that Zope could act, in effect, as a virtual host, or do I need to create a separate instance of Zope for each domain? TIA, BenO
On Thursday 21 December 2000, at 14 h 59, the keyboard of "Ben Ocean" <lists@TheWebsons.com> wrote:
I have my own server with virtual hosts. I'm going to build a large Web site on this server with Zope as the base platform. I intend to build more on the Zope platform, but already have several sites built without it. My question is, how do I edit the z2.py file in such a way that I can call up certain virtual hosts and not others through port 80?
I use Squid as an accelerator for my Zope sites <http://www.zope.org/Members/ht rd/howto/squid>. Squid can bind itself to an IP address (http_port in recent Squids, tcp_incoming_addr or something like that in older Squids). Use an other IP address for Apache sites (BindAddress in Apache).
Also, can I build the equivalent of a doc root off of the Zope root such that Zope could act, in effect, as a virtual host,
It is possible with SiteAccess' "Set Access Rule". It has some nasty side-effects: - Zcatalogs will no longer work :-( - do not make *one* mistake in the "root" method code or you will lose access to your Zope completely (that's the big problem with all-database systems like Zope). Even FTP access will fail, you will have to retrieve your ZODB from backups!
On Fri, Dec 22, 2000 at 09:42:35AM +0100, Stephane Bortzmeyer wrote:
It is possible with SiteAccess' "Set Access Rule". It has some nasty side-effects: - Zcatalogs will no longer work :-(
This is fixed by CHris Petrilli's patches, see elsewhere on the list (or Zope-Dev, can't remember). These fixes will be in Zope 2.3.0.
- do not make *one* mistake in the "root" method code or you will lose access to your Zope completely (that's the big problem with all-database systems like Zope). Even FTP access will fail, you will have to retrieve your ZODB from backups!
This is nonsense. There are several ways of telling the SiteAccess rule not to kick in. See the SiteAccess pages for more info on the URL modifiers and environment variables that do this. -- Martijn Pieters | Software Engineer mailto:mj@digicool.com | Digital Creations http://www.digicool.com/ | Creators of Zope http://www.zope.org/ ---------------------------------------------
On Friday 22 December 2000, at 10 h 38, the keyboard of Martijn Pieters <mj@digicool.com> wrote:
There are several ways of telling the SiteAccess rule not to kick in. See the SiteAccess pages for more info on the URL modifiers and environment variables that do this.
When I had the problem and was in an emergency, I did not find it. Now that I'm cooler, I find it at a glance :-} If an Access Rule is broken, and is preventing normal access, it can be disabled by restarting Zope with environment variable SUPPRESS_ACCESSRULE set. Thanks.
Stephane Bortzmeyer wrote:
- do not make *one* mistake in the "root" method code or you will lose access to your Zope completely (that's the big problem with all-database systems like Zope). Even FTP access will fail, you will have to retrieve your ZODB from backups!
Umm, even if *everything* else fails, you can still manually truncate the Data.fs file to remove the last transaction (presumably the change you made to the access rule), and you'll be back to normal. That's one of the things that I really appreciate about Zope, that it's practically (though not absolutely) immune to unrecoverable data corruption. HTH, Michael Bernstein.
On Friday 22 December 2000, at 18 h 56, the keyboard of Michael Bernstein <webmaven@lvcm.com> wrote:
Umm, even if *everything* else fails, you can still manually truncate the Data.fs file to remove the last transaction
Well, this file is not human-readable so I do not really see how to truncate it properly?
--On 02 January 2001 17:23 +0100 Stephane Bortzmeyer <bortzmeyer@pasteur.fr> wrote:
On Friday 22 December 2000, at 18 h 56, the keyboard of Michael Bernstein <webmaven@lvcm.com> wrote:
Umm, even if *everything* else fails, you can still manually truncate the Data.fs file to remove the last transaction
Well, this file is not human-readable so I do not really see how to truncate it properly?
See http://www.zope.org/Members/itamar/CorruptedZODB for how to do this. Paul -- The Library, Tyndall Avenue, Univ. of Bristol, Bristol, BS8 1TJ, UK E-mail: paul.browning@bristol.ac.uk URL: http://www.bris.ac.uk/
participants (5)
-
Ben Ocean -
Martijn Pieters -
Michael Bernstein -
Paul Browning -
Stephane Bortzmeyer