[Zope] Duplicating a Zope Instance
Chris Kratz
chris.kratz@vistashare.com
Mon, 13 May 2002 19:11:18 -0400
Dan,
This got long, but here more or less is the process I use each time we need a
new server.
It's much easier and foolproof if the two machines are the same OS. If so,
it's a trivial copy of the entire zope directory. Depending on the products
you have installed and how your instalation is set up, this will bring them
along as well. In addition, we have a pretty extensive Postgres DB behind
our zope, so I've written some shell scripts to dump, transport and load the
(postgres) database automagically as well as send along the zope directory.
It sounds like you are running two OSs though. In that case, you will need to
go through you product list on your production server and reinstall each of
those products on your development machine. You might try copying over your
Products folder and then restarting zope, and only installing those products
that still error out when it starts up. This may work because many products
for zope are python only and as such can run unmodified on any OS.
Unfortunately this is not always the case and some products have compiled
code that has to be recompiled on each platform (database adaptors would be
one example). Unfortunately, I don't know of an easy way to know the
difference except to examine the product directory and/or the installation
instructions for each product.
One last caveat with products. I found out the hard way that you can't just
copy the products directory if the two zope versions are not identical. The
reason is that much of the functionality of zope is implemented as products
(pythonscripts, etc). So, if you are copying between versions of zope, you
may overrite a newer or older product if you just copy the entire folder. If
you are copying a data.fs to a newer version of zope, then it is far better
to install individually each product not already on the newer box. I got bit
because when we upgraded at one point, I was in a hurry and simply copied
over the products folder and overwrote it with a copy of the one from the
previous version. This caused some interesting problems which were fixed as
soon as I realized what was going on and restored the newer products
associated with the newer zope.
One final issue that we ran into. If you are using a database adaptor against
a database, you will want to make sure you are using the same da on the other
OS. At one point we tried running one windows server (demo laptop) via ODBC
and a Linux server running a native adaptor (to postgres). Unfortunately, in
certain cases, the ODBC adaptor wouldn't accept some of the SQL that the
native adaptor was fine with and in other cases the two da's would return
slightly different data sets due to the way the adaptors encapsulated the
data. It's been almost a year, but I think the biggest issue was that null
values with ODBC were returned as an empty string whereas with psycopg they
were returned as the python value None. We had the same issue when changing
between postgres database adaptors under Linux. The moral of the story we
found was it was a lot easier not to change adaptors or platforms too often.
We found the easiest thing for us due to the complexity of our app was simply
to have our development server be running an identical copy of the code
(Zope/Products/DA/DB/OS) that was on the live server(s). This removes one
more level of complexity to have to deal with. Then we use ZSyncer to move
pieces of zope code from development out to live as they are completed. This
has worked admirably well. Our only wish is that the bugs in the versioning
code would get fixed (hint, hint).
Depending on budgets and such you might take a look at a tool such as vmware.
We have had excellent luck with using it for testing purposes given that you
have enough memory and horsepower. It would allow you to run an exact
virtual copy of your server on your development box while still developing in
Windows. I run Windows under Linux on a P3-933 inside a virtual machine
under linux with very satisfactory results. We actually demo'ed awhile using
an IBM laptop running Windows 2000 Professional with VMWare running an exact
duplicate of our Live server (Linux). This worked very well because it
allowed our demoer to be in his native environment and run IE while demoing
against our app running under Linux. You pay for this with performance. The
performance hit seemed to be close to half again as much time in most cases
for similiar processor levels. But most of the time, for development having
fractionally slower page loads isn't bad. In fact it can force you to write
more efficient code (which is a good thing).
Anyway, those are some of our experiences. Good luck.
-Chris
On Monday 13 May 2002 05:29 pm, Dan Shafer wrote:
> I'm trying to figure out the best way to take an existing Zope instance on
> a remote server, which has a *lot* of virtual host stuff and quite a bit of
> product installed, and replicate it on a local Win2K box both for safety
> and to give me a local instance to experiment with.
>
> I copied down Data.fs and the related index file to my local Zope instance
> and fired up the local instance. Of course, I generated a huge number of
> errors. Not surprising. It became obvious I'd have to either copy down or
> reinstall locally all the products I've added to the remote Zope instance.
>
> But I'm not at all sure what pieces of the Zope install are essential,
> which will be automatically generated if not found (indexes?), or, frankly,
> much of anything else about this process.
>
>
>
> _______________________________________________
> Zope maillist - Zope@zope.org
> http://lists.zope.org/mailman/listinfo/zope
> ** No cross posts or HTML encoding! **
> (Related lists -
> http://lists.zope.org/mailman/listinfo/zope-announce
> http://lists.zope.org/mailman/listinfo/zope-dev )
--
Chris Kratz
Systems Analyst/Programmer
VistaShare LLC
www.vistashare.com