- Destinations: Valid ZSyncers to sync to, identified by URL,
including port. For
example: http://www.myzopesite.com:8080/my_ZSyncer. These can be
https urls if you want. If your destination is a ZEO cluster,
you must only specify the URL for a single zope server in the
cluster, or just give the virtual address presented by your load
balancer if you have one.
ZSyncer supports the following URL syntax extension for HTTP Basic
This allows you to use a different username / password for each
destination server. It replaces the old "Override User" config
option, which wasn't flexible enough for some users.
(SECURITY WARNING: it also exposes the passwords in plaintext on the
ZSyncer properties page. If you use this feature, be sure that
only trusted administrators have the "View Management Screens"
permission in context of your ZSyncer instance.)
- Connection Type: the underlying transport classes to use.
You should probably leave this alone unless you know what you're
ConnectionMgr works with SSL and supports timeouts. The
previous solution, ZPublisher.Client, does neither. Therefore,
ConnectionMgr is now preferred. But if you have any problems
with it, you might try ZPublisher.Client.
(Prior to version 0.6, ZSyncer used XML-RPC. It was inefficient, had
character encoding problems, and the code is now broken; so
we have removed it.)
- Use Relative Paths: Force ZSyncer to treat object paths as
relative to "Base Path", not relative to the zope root.
(If "Base Path" is not set, it defaults to the parent
container of the ZSyncer instance.)
This means that the source and destination zsyncers can live in
different parts of the object hierarchy, and objects will be pushed
where you expect them relative to the destination zsyncer.
It also prevents you from syncing anything above the
Note that this flag MUST currently be set the same way on both
the source and destination servers. If the settings do not
match, you may have problems. This requirement may be removed in
a future release.
- Base Path: Where to look for objects if
use_relative_paths is true. See above.
- Log?: Turns on logging.
- Logfile: specify the file to log to. Should be a path relative
to your INSTANCE_HOME.
- Approval?: Require confirmation before performing actions.
- Syncable types: what meta types you want to sync. See below for
- Additional syncable types: if you want some meta_types to be syncable
and they do not show in the "Syncable types" list, you can type
them here, one per line.
- Non-syncable meta types: types to explicitly remove from the
list of syncable types. These are applied last and will override
any previously added types.
How to sync
The sync web page shows the difference between a development Zope
and one or more other Zopes. It does this by comparing the date
stamps on the objects in Zope.
- File: shows the object name in Zope. If this object is a folder,
you can click on it to traverse to the lower folder.
- Status: shows the status of the object in relation between the
Zopes it will be one of the following terms:
- this object is present on both production and
development and is in sync
- this object is present development but not
production, it needs syncing
- object is on production but not
development, it needs deleting from production
- out of date
- this object is present on both the
production and development, but has been changed on
development, it needs syncing.
- View: takes you to a version on the appropriate server
- Action: perform the highlighted action.
- copies the relevant object(s) from the local server
to all the remote servers.
- copies the relevant object(s) from the first available
remote server to the local server.
- removes the relevant object(s) from all the
servers on which it is present. (This affects the local
server and all the remote servers.)
- change the modified timestamp on both local and
remote object to now.
- This should be considered experimental, but it sort of
limits the objects that can be synced. You specify the meta
types and only objects of that type are shown.
- However if your list of syncable objects is not the same
on all systems, this could generate false results. For example,
the source has
Foo in its syncable types, but the destination
doesn't. If that's the case, an object of type
Foo that is
on both systems will be shown as
missing on the destination,
because it is filtered from the destination object list.
Foo is syncable on the destination but not on
the source system, an object of type
Foo that is on both
systems will be shown as
extra on the destination because
it is filtered from the source object list.
- Also if you sync a folderish object, all the objects in it
are moved, not just the syncable types. This is because of the
way Zope generates export files.
- Let me know if this makes it a mess.
If you sync a folder, it will sync all the items in that folder.
ZODB Versions are respected; if you have made changes in a version
they will not be synced until committed. (But of course ZODB
Versions are evil and you should use them with care.)
If you change an object in a folder, that folder does not become
out of date. However, if you add or delete objects, the immediate
parent folder becomes out of date. This is due to the way Folders
are implemented in the ZODB.