On 1/9/06, Paul Winkler <pw_lists@slinkp.com> wrote:

On Mon, Jan 09, 2006 at 10:15:41AM -0500, Brian Sullivan wrote:

...

I am involved in maintaining a remote Zope site that is behind a firewall where I have no remote access.

I have a (parallel) site that I use to test changes and upgrades that is accessible to me. I am a looking for a straightforward way to package tested changes, send and have changes applied at the other end -- without my physical presence (there is a systems maintenance person a the other with reasonable broad systems knowledge but no in depth Zope experience). The changes in this case consist of changes to or new python scripts, dhtml methods and documents, or images spread throughout a hierarchy of folders on the site.

Just to clarify the question: Your terminology ("folders", "dtml methods" etc.) suggests (but not conclusively) that all the changes you are concerned with are to data that lives in the ZODB. Is that true?

Yes that is what I was implying.

On 1/9/06, Paul Winkler <pw_lists@slinkp.com> wrote:

OK. You might try ZSyncer (zsyncer.sf.net).

But you will need *some* kind of remote access to install it in the Products directory.

ZSyncer won't do "packaging" for you; the UI it provides is intended for manually pushing changes from your development Zope to the remote Zope. (or vice versa - it supports pull as well as push).

But maybe you could achieve more automation and finer control with a bit of scripting. You can also call arbitrary methods on the remote server using a couple of new methods of the ZSyncer API (callRemote, callManyRemote); this can be useful if you need to e.g. programatically tweak some properties or security settings.

I considered Zsyncher a while ago -- the problem there though is that there are many things in the two sites that should not be synched -- it seemed more of a synch everything kind of tool. Maybe I should look at it again. That would be a long term project though.

If you can't install ZSyncer on the remote Zope, you can transfer objects the "old" way: using Export / Import from the ZMI. But even there, you need *some* kind of remote access in order to put the .zexp file in the import/ directory of your Zope installation.

I can have a person at the remote site perform tasks -- the person there is a competent systems person(though not fluent in Zope) -- in fact that is what I am trying to do. I am not intending to eliminate intervention completely at the site, just limit the number of steps and potential errors/miscommunications. Import/export via zexp doesn't really solve the problem of updating a smattering of files over the ZODB, unless I am missing something about using it. It might even introduce more issues than it solves.

On 1/9/06, Paul Winkler <pw_lists@slinkp.com> wrote:

On Mon, Jan 09, 2006 at 12:24:57PM -0500, Brian Sullivan wrote:

...

I considered Zsyncher a while ago -- the problem there though is that there are many things in the two sites that should not be synched -- it seemed more of a synch everything kind of tool. Maybe I should look at it again. That would be a long term project though.

Sure. ZSyncer only syncs what you tell it to sync. One wrinkle is that if you want to sync only some contents of a folder that does not exist yet on the remote side. In that case you need to arrange to create the folder remotely first. ZSyncer doesn't handle that automatically, but the callRemote() method may help if you want to script that kind of feature for your application.

As I recall the reason why I stopped looking at it earlier was that it only did push type synching (and as I am outside the firewall it didn't really solve my problem). I get the impression that now will allow a pull synching as well so that I can from inside the firewall synch to a site outside the firewall?

...

Import/export via zexp doesn't really solve the problem of updating a smattering of files over the ZODB, unless I am missing something about using it. It might even introduce more issues than it solves.

Yeah, you'd still need to arrange to export / import the particular objects (not really "files") you're interested in.

Yes -- objects -- just have a hard time sometimes mentally changing from paradigm to paradigm.

If they're scattered all over, as it sounds like, you're not going to find a ready-made solution. Only you know which objects you're interested in. That's why I suggested that you may end up scripting something.

Yes they are scattered around. What I would like to do is send a file (zexp like?) that just had the various required bits in it with an implied hierarchy and have the import take care of the distribution to match the files/hierarchy. I guess nothing like that exists?

On 1/9/06, Martijn Pieters <mj@zopatista.com> wrote:

We use a separete lib directory containing versioned Zope Product directories. That's versioned as in the directory name reflects the version. These get symlinked into the actual Products directory. For example:

lib/Foo-1.10.1 lib/Bar-2.2.3 lib/Bar-2.2.4

and in the Products directory a version of each Product is symlinked, usually the most recent:

Products/Foo -> ../lib/Foo-1.10.1 Products/Bar -> ../lib/Bar-2.2.4

We of course keep our development code in a subversion repository, and tag releases with version numbers. Pushing out a new release then becomes a simple process:

1) Create a tarball from a repository export, with a versioned directory name $ svn export url://to.repository/Foo/tags/1.11.0 Foo-1.11.0 $ tar czvf Foo-1.11.0.tgz Foo-1.11.0

2) Copy the tarball to the server and extract it in the lib directory of the Zope server

3) Repoint the Products symlink: $ rm Foo && ln -s ../lib/Foo-1.11.0 Foo

4) Restart the Zope server

It should be trivial to have someone with sysadmin experience do steps 2-4 for you.

-- Martijn Pieters

I think there is a disconnect. You are talking about Products being upgraded -- at least that is what I glean from you post? I am talking about ZODB based elements. Or am I missing something?

On 1/10/06, Gabriel Genellina <gagenellina@softlab.com.ar> wrote:

At Monday 9/1/2006 12:15, Brian Sullivan wrote:

...

I am involved in maintaining a remote Zope site that is behind a firewall where I have no remote access.

I have a (parallel) site that I use to test changes and upgrades that is accessible to me. I am a looking for a straightforward way to package tested changes, send and have changes applied at the other end -- without my physical presence (there is a systems maintenance person a the other with reasonable broad systems knowledge but no in depth Zope experience). The changes in this case consist of changes to or new python scripts, dhtml methods and documents, or images spread throughout a hierarchy of folders on the site.

We have a similar scenario. We had to develop an Updater product which basically does the following: - we pack the modified products / objects / whatever, along with a special 'update.py' script, in a Zip file - we send the file to the other guy who can do the update, and he uploads it using our Updater product - the zip file is then unpacked in a temp directory (honoring the possible subdirs structure) - the contained 'update.py' script (written each time by us) is executed (using execfile), its home directory being the temp dir, so it can access files and folders contained in the zip file easily. - that script is responsible of copying/updating things. Some handy functions (like shutil.copytree, copy2, etc) are available for its convenience. ZOPE_HOME, ProductXXX.__path__[0] and other variables are used to determine the destination directory for filesystem objects. For ZODB objects we use some helper functions which combine manage_addXXX/manage_editXXX as needed, to create new objects or update existing ones. - at the end, the temp dir is erased, some log records are updated, and usually the Zope service is restarted.

I somehow missed this post -- sorry for being late in response. Is this "Updater" product available somewhere