[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Notice of development and future release of Ganymede 2.0
|
Hello everybody. It's been a long time since we've had much new to
say about Ganymede, but we've been very busily working on it over the
last 18 months or so, and most especially over the last 6 months.
We don't have a release date yet, but right now we believe that we've
hit most of the technical goals we are targeting with the 2.0 release,
and we're primarily lagging in documentation and some external support
code infrastructure that will be required to make the most of some of
the new features.
I just wanted to let folks know that the project is alive, that we are
working on it, and that we are very excited about the changes we have
in store for the next release. If any of you out there are actively
using or developing with Ganymede, I'd appreciate hearing from you so
that we can start to bring outside reviewers in on things.
We intend to put up a publicly available Subversion repository
sometime soon to make things more visible, but for right now I'd just
ask that anyone with experience in Ganymede who is interested in
working with the new stuff drop me a line and I can answer questions
about the new stuff as we go along towards documenting everything.
You can download the latest drop of the Ganymede 2.0 development tree
from
ftp://ftp.arlut.utexas.edu/ganymede/2.0
I'll be occasionally putting newer snapshots up there, according to
our progress and your interest. Keep in mind that right now the
documentation is scarcely updated other than the CHANGES file, so this
pre-announcement isn't really meant for folks that don't have some
experience with Ganymede and/or a lot of adventure in their soul.
I'm hoping for a formal release by April of this year.
I hope folks will be excited by all the fixes, improvements and new
features.. I know we are.
Jon
-------------------------------------------------------------------------------
Ganymede Release 2.0
?? ?, 2005
CHANGES
Last Revision Changed: $Rev: 6226 $
Last Changed By: $Author: broccol $
Last Mod Date: $Date: 2005-02-17 19:05:24 -0600 (Thu, 17 Feb 2005) $
SVN URL: $HeadURL: http://db1.arlut.utexas.edu/svn/ganymede/trunk/ganymede/CHANGES $
-------------------- Changes from 1.0.12 to 2.0.0 -------------------
RELEASE DATA: ?? ?, 2005
1. [EVERYTHING] Ganymede Rebooted.. Subversion, Ant
Went through everything in the old Ganymede tree and did lots of
surgery, completely restructuring the source tree, moving files into
new packages. Created sub packages arlut.csd.ganymede.server,
arlut.csd.ganymede.common, arlut.csd.ganymede.rmi,
arlut.csd.ganymede.admin, to make clear the different roles various
classes in the old arlut.csd.ganymede package play.
Deepak created a very nice Ant-based build system for Ganymede, and
restructured the source code into a package structure to make builds
with Ant convenient.
We imported the old Ganymede CVS repository into Subversion. I went
through all of the source files and replaced the old CVS keywords with
Subversion keywords.
Subversion is wonderful. Ganymede 2.0 would never have happened if we
were still stuck with CVS.
2. [SERVER] Localization
The Ganymede server now incorporates a method for localizing message
strings. A new class, arlut.csd.Util.TranslationService, has been
added which handles string lookup and templatization from string
resource files held in the src/resources tree.
The following classes have had their message strings pulled out into
localization resource files:
DBEditSet GanymedeSession
DBField InvidDBField
DBObject JythonServerProtocol
DBObjectBase JythonServerWorker
DBSession dumpAndArchiveTask
DBStore dumpTask
Ganymede gcTask
GanymedeServer memoryStatusTask
DBEditObject DBJournal
IPDBField XMLTransmitter
SyncRunner GASHAdmin
GASHAdminFrame fieldoption_button
fieldoption_editor GanymedeValidationTask
xmlclient
The default, American English versions of these localization files are
simply called <classname>.properties. When the Ganymede server is run
under a JVM that is configured with a different locality string, the
TranslationService class will automatically read any translated
resources from the appropriate file.
For instance, if an adopter wanted to translate the messages used by
the arlut.csd.ganymede.server.GanymedeSession class into French, he
would create the file
src/resources/arlut/csd/ganymede/server/GanymedeSession_fr.properties
Ganymede uses the standard Java Internationalization method for
handling message strings, with interpolated parameters injected into
the message strings with tokens like {0}, {1}, and etc.
The new Ant build system provides a task to cross check the
localization resources against the Ganymede source code, to ensure
that the localization message strings match the usage in the Ganymede
source code. If you run 'ant validate' in the src directory, a Perl
script is run to do this analysis and verification.
Note that the 'ant validate' task does not yet support verification of
resources with a country or language code extension. This means that
translated resources are not yet properly handled.
3. [SERVER] Added support for SSHA password hashing in DBPasswordField
Here at ARL, we're working to move from NIS to LDAP for our Unix and
Mac OS X systems. Since the OpenLDAP server doesn't support md5Crypt
and since traditional Unix crypt is just too inadequate in the face of
John the Ripper and other brute force dictionary attacks, I've
implemented support for encoding passwords entered into Ganymede using
the Netscape Salted SHA-1 hash algorithm.
See http://www.openldap.org/faq/data/cache/347.html for more details
on the SSHA hash format.
Nota bene: From what I've read, SSHA is actually a relatively cheap
hash algorithm.. it doesn't contain the arbitrary delay features that
something like md5Crypt uses to slow down the hashing algorithm. As a
consequence of this, attempts to use brute force dictionary attacks
against SSHA hashes can be pretty successful. The primary benefit of
SSHA over Crypt in the LDAP context is that longer passwords can be
supported (vs. the 8 character limit of traditional Unix Crypt).
4. [SERVER] Integrated Jython interpreter support in the server
XXX - to be written. Discuss DBEditObject subclasses, tasks.
5. [SERVER, CLIENT] Java 5.0 fixes
Sun, long may their name be praised, decided in Java 5.0 to
arbitrarily make 'enum' a language keyword, despite never having put
it on the reserved keyword list. We had to go through the entire
source code and replace 'enum' with 'en'.
In a number of other places, we had to explicitly cast some parameters
when making reflection calls to avoid confusion between an older
method call that has null as the final parameter and the newer Java
5.0 varargs versions of those methods.
We've made the ant build files for everything specify a source code
and class file target level of Java 1.4, so nothing in Ganymede 2.0
should require a Java 5.0 system.
6. [CLIENT] Cleaned up some threading
We're now using FoxTrot (http://foxtrot.sourceforge.net/) to allow
some activity in the client to be synchronous in ordering but
asynchronous in that we allow the GUI thread to continue redraw and
processing further GUI events until certain server calls complete.
This fire-and-wait support makes the GUI client feel much snappier in
a few places.
7. [SERVER] The return of passive password capture
Thanks to Deepak, we have now re-enabled the passive password capture
logic in the PasswordDBField class that was removed in 1.0.10.
Previously, the big showstopper with passive password capture was that
it was possibly to capture erroneous plaintext that nonetheless
matched a stored hash format, particularly the 8-character-significant
traditional UNIX 'crypt' hash function..
Now, passive password capture is back, but it is smart enough not to
capture plaintext on login if the password is not know from a hash
with adequate specifity. The whole point of having passive password
capture is that it enables Ganymede to learn about plaintext from
interacting with a user, while still allowing us to forego saving
plaintext passwords persistently to our ganymede.db file.
8. [SERVER] Made transaction commit more resilient to exceptions in commitPhase1
The DBEditSet's transaction commit logic was vulnerable to getting
into a confused and broken state if an object's commitPhase1() method
threw an uncaught exception. It's fixed now so that the client gets
an exception report and the transaction unwinds itself back to a
consistent state, ready to try committing again (though it will
probably fail if the error condition in the plugin classes is not
fixed).
9. [SERVER, CLIENT] Added SSL support, 1.4 requirement, Firewall friendliness
Added the arlut.csd.ganymede.server.GanymedeRMIManager class to handle
all RMI exports, which support for SSL encryption of client/server
communications through the
arlut.csd.ganymede.common.RMISSLClientSocketFactory and
arlut.csd.ganymede.common.RMISSLServerSocketFactory classes.
The Ant build process now incorporates automatic generation and
distribution of key and certificate material into the appropriate jar
files when the jar files are built.
The SSL support now present in Ganymede requires a minimum of Java 1.4
to work. We are therefore intending to make JDK 1.4 a minimum
requirement of Ganymede 2.0.
It is now possible to specify the port number that the Ganymede server
should use for publishing its RMI object targets. This means that the
Ganymede server will now use only two ports, one for the rmiregistry
and one for client access, and that these can be specified for
compatibility with a fixed firewall configuration.
10. [SERVER, CLIENT] Changes to Query system (Deepak)
Deepak implemented support for a text based (ANTLR-based) querying
language that can be used by Jython code to do queries on the Ganymede
server. Deepak also added the new
arlut.csd.ganymede.common.QueryResultContainer class, which acts like
the old arlut.csd.ganymede.common.QueryResult class, but which
implements the java.util.List interface for convenient use from
Jython. At this writing, this new QueryResultContainer isn't actually
being used, yet.
In specifying the ANTLR grammar, Deepak defined a new dereference
operator, which allows for a query to express a constraint based on
the value pointed to be an invid field. By using this dereference
operation, I was able to drastically simplify and speed up the
GanymedeSession query logic by pulling some of it inside-out.
11. [SERVER, CLIENT] Removed the OwnerObjectsOwned field from OwnerBase
With this change, Owner Group objects no longer include an
InvidDBField tracking objects owned by that Owner Group. Instead, it
is the responsibility of the owned object to point to its owner.
By making this relationship non-symmetrical, we gain the ability to
add or remove objects from an owner group during a transaction without
having to check out the owner group for exclusive editing. As such,
this change will significantly improve concurrency in the Ganymede
system when many objects are owned by a single owner group.
This change was made possible by the (now quite old) change described
in 0.99.8, #17.
The client was also changed so as not to show the 'objects owned' pane
when viewing or editing an Owner Group object. I plan on putting that
pane back in, but it will be implemented with discrete query logic,
rather than the old InvidDBField lookup, again for the benefit of
avoiding owner group locking.
12. [SERVER] Added a per-DBObjectBaseField lastChange variable
For the entire history of Ganymede, the GanymedeBuilderTask has
consulted a lastChange variable in each DBObjectBase to decide whether
any objects of a given type (user, group, system, etc.) has been
changed since that builder task last ran. Our custom builder tasks
use this to avoid doing builds when the builder task is not interested
in what has changed since it last ran.
One problem with this has always been that the object-level timestamp
didn't really have as much granularity as we would desire. Now, each
DBObjectBaseField has its own timestamp, so we can write builder tasks
that will, say, check to see if any user has had their username or
password changed since the builder task last ran. Previously, all the
builder task could do was check to see if any user had been edited in
any way since it last ran. This meant that editing the Notes field on
a user would trigger unnecessary activity in all builder tasks that
cared at all about user changes.
13. [CLIENT] Numerous fixes in the client's query table logic
Fixed a number of bugs in the client, including the bug that allowed
an object to be deleted in the client then viewed in an empty state
through the use of the query result table pop-up menu. Now, all
checks against an object being already marked as deleted are done at
the proper place, rather than being done in the tree response code.
Also, I fixed bugzilla bug #14, which caused the title of query
windows not to be properly updated when a transaction is committed and
the query windows are refreshed, possibly with a different number of
entries (see 1.0.12, item 14, below). While I was working on that, I
shuffled some code around in the client for better thread safety when
accessing some windowPanel data structures, as well as the use of a
common windowPanel.setWindowTitle() method for picking and maintaining
unique window names.
14. [ADMIN CONSOLE] Significant fixes to bugs in console login process
Improved the admin console login procedure. The server now returns
an explicit dialog refusing admin console login if the user provides
an unprivileged or incorrect username and password. The admin
console now responds properly to a failure to login or to the
Ganymede server being down. The admin console will now also
repeatedly test the server to see whether it has come up, and can be
told to attempt a new connection if the server is believed to come
back up.
Much of the connection establishment threading has been improved in
design. The use of the arlut.csd.Util.booleanSemaphore also helps
some, by allowing for proper exclusion of overlapping connection
threads. The connection thread now properly uses the SwingUtilities
to handle proper issuance of gui updates in response to the
connection thread.
Good stuff, and long overdue.
15. [NIS PASSWORD CLIENT] Removed the rpcpass program
I've taken out the old rpcpass program which was used in conjunction
with the -x option to Thorsten Kukuk's NIS yppasswdd daemon for Linux.
The vaguely named rpcpass was used to propagate password, shell, and
finger info changes from the Linux yppasswdd daemon into Ganymede.
Unfortunately, the passwords that the yppasswdd is capable of
transmitting to Ganymede are in the old Unix crypt() format, which
means that passwords submitted in this way are useless if Ganymede
needs to sync to anything but NIS.
Therefore, and given that we at ARL have not used this code in nearly
five years, I removed it. If you are reading this out there in
Internet land and decide that you've got to have it, let me know and
I'll see about resurrecting it from Subversion.
16. [XMLCLIENT] Massive speed-ups in the XML client, reversal of method calls
Previously, when the xmlclient was used to extract data from the
Ganymede server, the xmlclient would publish an RMI target and allow a
thread on the server to repeatedly call the client, pushing XML data
from the server.
This had the disadvantage that the xmlclient could not be run on a
system with a local firewall blocking incoming TCP connections. With
SSL support now added to the Ganymede server, this reverse flow of RMI
method calls also meant that the xmlclient needed its own SSL
certificates and key material, or else XML sent from the server to the
client would be unprotected on the wire.
Now that the xmlclient pulls data down from the server with iterative
method calls, the XML is naturally protected with the existing SSL
connection.
In addition to this change of direction for the method calls, the
arlut.csd.Util.BigPipedInputStream class has been fixed so that it
actually will properly increase the size of the buffer used for
internal pipes within the Ganymede server. In the case of the pipes
used to feed the xmlclient, this means that the server can now provide
64kbyte chunks from the XMLWriter, rather than the default 1k chunks
normally provided by PipedInputStream. This has the effect of
reducing the number of RMI calls required to transmit XML to the
client by a factor of 64, resulting in a massive speed-up.
In testing here, this change made the new code 5 times faster at
wall-clock time in doing a system-local xmlclient dump to /dev/null,
even with the overhead of SSL encryption included, relative to
previous releases.
17. [SERVER] Use of external rmiregistry eliminated
The Ganymede server now implements an rmiregistry in-process, rather
than depending on an external rmiregistry support process. This
simplifies the startup and shutdown of the Ganymede server, as well as
operational usage generally.
18. [XML] Improvements to namespace handling in <ganyschema>
In some testing we were doing, we got surprised at the case
sensitivity of namespaces that we were creating with the xmlclient.
The surprise was that by default, namespaces created are
case-insensitive. To be fair, our documentation said this, but it was
just too easy to forget this when crafting xml test data. To address
this, we have made the system warn if the case-sensitive attribute is
not present in <namespace>.
Also, the Ganymede server now properly handles switching a namespace
from case-sensitive to insensitive, or vice-vera, as needed, and
checks to amke sure that this redefinition operation can be done
safely on the namespace-constrained data loaded in the server. The
admin console's schema editor still does not allow changing the case
sensitivity of a namespace, but the xmlclient may be used to do this.
19. [SERVER] Fixed a bug that made newly define object types inaccessible
Oops! We weren't properly updating the baseTransport cache after
schema editing. This resulted in a failure whenever we tried to use
the Ganymede client to access an object of a type that did not exist
before the schema edit immediately after the schema edit took place.
The only reason this didn't bite us before was that we haven't added a
lot of object types through the schema editor without subsequently
shutting down and restarting the server.
Gotta love really exercising old code paths in relatively new ways.
20. [CLIENT,SERVER,userKit] Scalability work
Lots of work on increasing the scalability of the Ganymede server and
client. At the time of this writing, we've tested the userKit to a
loading of 250,000 users and 250,000 groups, a total of some 7.5
million data fields, with a nominal (fully garbage-collected rest
state) memory usage of around 600 megabytes on the server. In order
to get there, we had to fix some poor algorithmic choices in certain
points in the Ganymede server. This included a complete cut over from
using the old cheapo QuickSort implementation I slapped together in a
day from someone's online course notes to using the java.util.Arrays
sort algorithm that came in Java 1.2.
I also fixed a bug in the userKit userCustom.java class that made it
do about a bazillion times more work than it should have when doing
processing, thanks to a failure to set and retain the schemaConfStamp
time stamp variable properly.
The Ganymede transaction logging system is now very much more
efficient as well. Previously, all events that needed to be logged in
conjunction with a transaction would be assembled into a Vector of
DBLogEvent objects before any events were logged to disk. Now, the
transaction commit logic streams these log events to the logging
system as they are generated, so that garbage collection can occur
during the logging process. This should help reduce memory loading on
very large transactions.
Made some improvements in the XML import logic to intern commonly
occuring strings, again to reduce memory usage.
21. [CLIENT,SERVER] Invid redefined, private constructors, InvidPool
The Ganymede object id pointer class, arlut.csd.ganymede.common.Invid,
has been modified slightly to make its constructors private, in order
to force wanting to create Invids to go through the Invid class'
static factory method, createInvid(). The purpose of this is to allow
for intelligent re-use of Invid objects on the server, so that the
server will only need to keep one copy of any given Invid. This has
an effect similar to the interning that the Ganymede server has always
done when loading strings from its database, and should help lower the
server's memory usage a bit on large datasets.
In addition, an InvidPool has been implemented on the server, which
uses a hashing SoftReference data structure to efficiently implement
Invid interning. This seems to cut memory loading on the server with
large datasets by 15% or more.
22. [CLIENT] Reworked the client layout/rendering algorithm
The layout/rendering algorithm for the client object windows and the
admin console schema editor has been rewritten to behave better in a
greater variety of circumstances. In particular, bugs that were seen
when using the multi-line label field have been addressed.
23. [SERVER,ADMIN CONSOLE,CLIENT] New data field type added for GanymedeBuilderQueue
Introducing the first new DBField type since the introduction of Float
back in 1999.. the FieldOptionDBField!
The purpose of the FieldOptionDBField is to allow the client and/or
xmlclient to configure the list of objects and fields that the new
GanymedeBuilderQueue synchronization channels (to be introduced
hereafter) will use when writing out an XML description of
transactions to disk as they happen.
The intention is that the GanymedeBuilderQueue will write out an XML
description in a known format for each transaction that is committed,
and a dedicated queue runner will be launched on an asynchronous basis
to sweep up the XML records for the queue, up to a fixed transaction
number, for integration into directory services oriented around change
requests rather than complete dump and reloads.
24. [SERVER] Made DBEditObject.deleting private
I've made the deleting boolean in DBEditObject private rather than
protected, so that use of it can be controlled better. If your custom
plugins consult deleting directly, they will need to be tweaked to use
"isDeleting()" rather than "deleting".
25. [SERVER, XML] Corrected xmlclient behavior for namespace swaps
The xmlclient is intended to allow just about any legal change to the
Ganymede server's data to be made by submitting a declarative xml
file. Unfortunately, it turned out that one thing the Ganymede server
could not do when handed an xml file was to swap two namespace values
around.
That is, suppose you wanted to rename two user accounts
simultaneously, giving account A the name previously associated with
account B, and account B the name previously associated with account
A. If you try to do this in the GUI client, you'll find that you need
to make up some transient name to act as a placeholder for account A,
then give A's name to B, then go back and give B's name to A, erasing
the placeholder in the A account.
This kind of fine grained control over the order of operations isn't
possible when using the xmlclient, so I have tweaked the server's
namespace management logic so that it will allow non-interactive
sessions to have two namespace linkages 'in flight' at a time. Giving
name 'A' to account B will be allowed, even though it means that for a
brief window, both account A and the old account B will be associated
with the 'A' name. If the name 'A' is not unlinked from the old
account A by the time the xmlclient's transaction commits, however, an
exception will be reported and the transaction will be canceled.
26. [SERVER, XML] Rectified label handling for objects in XML
A number of pieces in the server have been tweaked to better assure
useful and consistent naming in the xmlclient's dumps and loads.
Formerly, if the server tried to dump out objects whose labels were
not guaranteed to be unique, the server would synthesize a unique
label that could not be used upon later loading to retrieve the
object. This made it difficult to impossible to properly address such
objects.
Several changes have been made to ameliorate this solution.
First, the algorithm used to synthesize a unique label when no
guaranteed unique label is available has been standardized, and the
GanymedeSession class' query mechanism has been elaborated to allow
for high speed lookups using these synthesized unique labels.
Second, the DBEditObject 'plug-in' class has had a new
labelHookGuaranteedUnique() method which a plug-in subclass can use to
affirmatively decalre that the custom label produced by getLabelHook()
is guaranteed unique. If a subclass provides a guaranteed unique
label, that label will be used in the xmlclient, and will be properly
found by the GanymedeSession query system when XML changes are loaded
back into the server with the xmlclient.
Thirdly, the logic for determining the best and most reliable label
for invid and object elements in the xmlclient's dump output has been
put into the DBObject class' new getXMLLabel() method. That method is
responsible for considering the known uniqueness constraints on the
specified label generation mechanism, and selecting the most specific
unique label possible.
These changes should make the xmlclient more reliable in loading xml
segments with reliable addressing, though if an object type does not
provide unique labels, the synthesized object labels will only be
portable so long as the desired object has the same invid number in
the server as was assumed in the generation of the input to xmlclient.
This is all made rather complicated by the degree of freedom that I
designed into Ganymede, allowing objects to have synthetic, non-unique
labels. I wanted all references done through reliable invid's and to
be able to support object renaming easily, but the xml client has a
greater need for consistency. With these changes, we should be able
to offer it as needed.
27. [SERVER] Clarified that Vector fields may not hold duplicates
Previously, certain parts of Ganymede implicitly assumed that
duplicate values were not allowed in vector fields, but no code made
sure that duplicates were not introduced into vector fields. I have
now introduced code to test and enforce that constraint.
This change may slow down bulk loading, but it will assure that we
have a consistent semantic for vector fields, and other code in the
Ganymede server can safely rely on the uniqueness of vector field
elements.
28. [SERVER] Added GanyPermissionException to server
Several classes in the Ganymede server now throw
arlut.csd.ganymede.common.GanyPermissionException when permission
problems are encountered. This change was to help insure that
Ganymede server internal code was properly tracking permissions
failures.
As a result of this change, custom schema kit code written to the
Ganymede 1.0 series may need to be altered to catch the
GanyPermissionException, as it is a declared exception that derives
from RemoteException for compatibility with the client.
In some cases, methods that previously returned ReturnVal to indicate
permissions failures may now throw GanyPermissionException. I'm not
sure that this is entirely accounted for in the client code at this
writing (10 February 2005).
29. [SERVER] Added entirely new Sync Channel build system
With Ganymede 2.0, the Ganymede server now has a second way of
handling synchronization to target directory services.
Previously, all builds were done through the use of the
GanymedeBuilderTask and its subclasses, using a two phase process. In
phase one, portions of Ganymede's internal datastore was locked
against changes while the builder task scanned the database and wrote
data (usually text files) out to a specified directory. In phase two,
the database was unlocked, and the builder task ran an external
synchronization process that used the data files written out by phase
1. When external build system finished, the task's execution was
complete, and a new build could be scheduled and issued for that same
task.
All of that is still there, and it all works the same way that it ever
did. Now, though, there is a second system, based on the SyncRunner
and syncChannelCustom classes. I call it the 'Sync Channel' system.
The Sync Channel system is based on tracking the changes made to the
Ganymede data store. When a change is made, the Ganymede transaction
commit logic examines all Sync Channels registered in the server,
looking to see if any of them are interested in the object and fields
that have changed. If any Sync Channel is so interested, that Sync
Channel will write out an XML description of the transaction with
respect to the objects and fields that the Sync Channel cares about.
Each standardized transaction description is written out to a
directory devoted to the Sync Channel, in a file whose name is the
transaction's id number. The Ganymede server then triggers the
external service program specified for each Sync Channel, passing it
the number of the highest transaction known to have been successfully
written out at the time that the service program is run.
The service program is intended to read all of the transactions up to
and including the number given it, and to integrate those changes into
whatever directory service the Sync Channel is intended to support.
At this writing (14 February 2005), I still need to write
documentation for the Sync Channel system.
30. [SERVER] Forced java.rmi.server.randomIDs on by default
In conjunction with the adoption of SSL in Ganymede 2.0, the
definition of the property statement 'java.rmi.server.randomIDs=true'
is necessary to avoid direct JRMP wire-level access to RMI objects
intended to be published by Ganymede for the benefit of a single
client.
With this property defined in the runServer script, Ganymede RMI
objects will be given cryptographically secure 64 bit random object id
numbers. Anyone wishing to hijack an RMI-published object would have
to have some way of guessing a 64 bit random number in order to send a
JRMP message to the Ganymede server forcing an unauthenticated
operation.
In theory turning off java.rmi.server.randomIDs should make the
Ganymede server startup marginally faster, but any modern system that
provides high entropy random numbers through a /dev/random device
shouldn't see any delay to speak of anyway, and the Ganymede server is
much, much, much more secure with both SSL and randomIDs turned on
than it is with one or the other of them turned on.
31. [XMLCLIENT] Added sync argument to allow for constrained dumps
Now that Ganymede 2.0 allows you to define object and field
constraints on sync channels, the xmlclient has been elaborated to be
able to apply a sync channel constraint to a dump. This makes it
possible to dump out a tailored XML report that only contains the
object and field types that a given synchronization target might be
interested in.
The ultimate purpose of this is to allow an administrator to pull the
full state of Ganymede with respect to certain objects and fields, for
the purpose of doing initial setup of an external directory service
target, before setting up a sync channel to transmits deltas as they
are committed to Ganymede.
Use is simple, just type
xmlclient -dumpdata sync=Systems > systems.xml
and Ganymede will dump out all data that fits the Systems Sync Channel
constraint.
--
-------------------------------------------------------------------------------
Jonathan Abbey jonabbey@arlut.utexas.edu
Applied Research Laboratories The University of Texas at Austin
GPG Key: 71767586 at keyserver pgp.mit.edu, http://www.ganymeta.org/workkey.gpg
Attachment:
pgp00002.pgp
Description: PGP signature