[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Ganymede developer pre-release 4, dev4.tar.gz, is now available from
ftp://ftp.arlut.utexas.edu/pub/ganymede/
or
ftp://129.116.212.1/pub/ganymede/
if your client has trouble resolving a proper address for
ftp.arlut.utexas.edu.
This is a major step forward for Ganymede.. lots of things have
changed and improved, including a radically simplified wizard model,
optimizations to the log and journal logic, an entirely new event
logging/mail model, a BSD 4.4 compatible passwd/group schema, and JDK
1.2b4 compatibility.
Due to the changes to the event model, ganymede.db files from previous
pre-releases of Ganymede are not compatible with this release. As
stated before, we are not committing to a freeze on the 'built-in'
object and field types until the 1.0 release.
We consider this to be the last big release before Ganymede is ready
to use.. at this point we are going to take this code base and try to
implement Ganymede here in the lab, replacing GASH with it. The next
major release will be after we have put Ganymede into full operation,
and will include whatever bug fixes we found necessary during the
process of implementation, and more adequate documentation.
That would be dev5, in all likelihood. The 1.0 release will come once
we have much better documentation and GPL licensing approval, and
should come with full source code.
Please give us feedback on any problems you find with this release.
-------------------- Changes from dev3c to dev4 -------------------
Ganymede Developer Release 4
July 30, 1998
CHANGES
RELEASE DATE: July 30 1998
1. [SERVER] DBEditObject.finalizeInactivate() now longer assumes removal
DBEditObject.finalizeInactivate() used to throw a NullPointerException
if the inactivated object didn't have its removal date set in the
removalField field. While this is arguably appropriate, I made the
code resistant to that circumstance. I may want to change it back
to catastrophic failure.
2. [SERVER/CUSTOM] Radically Simplified Wizard Construction
I moved a lot of the wizard bookkeeping from the individual
GanymediatorWizard subclasses up into GanymediatorWizard. It's much
simpler to make wizards for DBEditObject customization now.
3. [SERVER] Modified DBEditObject.finalizeRemove() to track rescan.
The server should now properly provide field/object rescan to the
client when the client deletes an object.
4. [SERVER] Rescheduled Garbage Collection Task in Ganymede.
The server used to schedule the Garbage Collection task for 5 minutes
after startup, which always hit us right when we were testing whatever
feature we restarted the server for. Ganymede will now schedule the
Garbage Collection task for 6 hours after server startup. The server
will initiate garbage collection when it needs it anyway.. I had just
made it a task to have something to test the scheduler with. I may
take the GC task out entirely.
5. [SERVER] Fixed bugs in Journal file processing
We ran into some problems with the Journal file logic as implemented
in dev3b. The journal file format has been reworked a bit, both to
fix some vulnerabilities to failure and to further improve file size
and processing time.
6. [SERVER] Server Properly Reports Inactivated Objects
The server wasn't properly reporting the inactivation, expiration,
and removal of objects. Now whenever the client does a query on
the server (including for the building of the tree), it will get back
the proper status of the objects.
7. [SERVER] DBEditObject now has default reactivation logic
Previously, the DBEditObject reactivate() method would simply refuse
action, forcing this method to be overridden by subclasses if
inactivation was to be supported. Now DBEditObject.reactivate() will
go ahead and clear the Removal date if called on an inactive object.
Customizers are still encouraged to override this method to provide
intelligent reactivation.
8. [CUSTOM] Various refinements to the GASH schema
You can now rename a user to a name the user previously had as an
email alias. You can now inactivate a group in good conscience. The
fields in the user object have been re-ordered to make entering data
for a new user more straightforward. The mapEntryCustom code checks
to see if it is being deleted before complaining about an
auto.home.default pointer being messed with.
Added preliminary code in userCustom.commitPhase2() to perform
external actions when a user is created, deleted, renamed, or when
their home directory is moved from volume to volume. Right now, these
are just stubs, but the logic is there. Turn on the debug flag and
recompile userCustom.java to get messages about when various external
actions would be taken.
9. [SERVER] Set serialVersionUID on serializable classes
This change will allow the server and client to communicate even if
they are using slightly different versions of the data objects used to
pass data back and forth between the client and server. It will also
make for a (probably very) slight speed-up in server initialization.
10. [CLIENT] The client will now terminate when killed by the server
In recent versions, the client would not get the hint and die when the
admin console knocked a user off. Instead, it would display a dialog
reporting the boot, but would keep running, getting all kinds of
exceptions from the server. Now, the dialog will show up, and a timer
is started. When the timer counts down to zero, the client will
self-destruct. The user can, of course, acknowledge the dialog to
shut it down sooner.
11. [SERVER] original field in DBEditObject is now protected
This change allows custom DBEditObject subclasses (out of the
arlut.csd.ganymede package) to get easy access to the original state
of a changed object for comparisons.
12. [SERVER] Server now re-sorts fields after the schema is edited
The server will now properly report the correct order of fields after
that order has been changed by the schema editor. This worked before,
but only if the server was restarted.
13. [SERVER] Object creation and deletion is now logged
Before, only changes to existing objects were explicitly logged.. now
object creation and deletion is also logged, and can be emailed.
Right now, there is no straightforward way to specify that different
users should get mail when different kinds of objects are created, as
all object creation falls under a single event category. This is one
problem with trying for the super-generic, customizable event
model.. to handle this properly would involve having a whole sub-tree
under the object creation/deletion/change events, with each object
type being able to have its own notification list, like GASH has.
14. [CLIENT] Embedded objects in newly created objects are opened
Before, when you created a user in the GASH schema, you had to manually
open up the auto.home.default entry to set the user's home volume. Now
all embedded objects in newly created objects start out opened by
default.
15. [SERVER/CLIENT] The log/history system has been optimized
All of the log code has been heavily optimized, and is now both a
great deal faster and a great deal more memory efficient on the
server.
We're intending to support more general (i.e., non admin or
object-limited) log searching by the client in the next pre-release.
16. [SERVER] Event/Email notification system has been totally revised
GASH's event/mail/logging model had separate event codes for the
creation, inactivation, and editing of objects by their type. So it
was possible to specify that whenever a user was created, someone in
personnel could be notified. The code in GASH that manipulated users
was custom-coded to use those event codes. Ganymede uses a more
generic model, in which the event logging/email system is designed to
work with any kind of object handled by Ganymede. However, there is
still a need to be able to specify that certain users be notified
whenever an object of a specific type has had a specific operation
performed on it. So there is now a second kind of event object listed
under Admin-Level Objects, an 'Object Event' object, which lets the
adopter create special email for whenever an object of a specific type
is created, edited, inactivated, deleted, reactivated, etc. The orignal
event object type has been renamed 'System Event'.
Admin Persona objects now include a field to specify an email address
where email to that administrator should be sent. If Ganymede is
managing your email database, you won't need to set this field,
but it's there otherwise.
Owner Groups and System Events now have an 'external email list' field,
used when you want email related to those objects to go to email
addresses not contained within Ganymede.
17. [TREE] Significant tree fixes/enhancements
The JTree code had an error in its drag/drop logic when both
tween-dropping and on-dropping were enabled, that made it impossible
for on-dropping to ever occur. This has been fixed, which corrects a
problem in the schema editor. I added a moveNode() method to allow
the schema editor to do the right thing in moving shuffling categories
and objects around within the tree.
Made treeCanvas extend JComponent instead of JPanel.. this seems to
fix some responsiveness problems that the tree was exhibiting under
Java Plug-In 1.1 on Win32. (ref. changes dev3 #5)
18. [SCHEMA EDITOR] Fixed lots of bugs in schema editing
Moving object types and categories between categories now works
reliably. This involved both adding a new primitive to the server,
Category.moveCategoryNode() and to the tree, moveNode(). The
server-side schema editing context does a better job of mapping remote
Base references supplied by the client-side schema editor to the
server-side local DBObjectBase objects. Basically, schema editing
should be robust and reliable now. Or at least, much more so.
Forced the schema editor tree to be black on white instead of
black on SystemColor.background.. testing the admin console on a
friend's FreeBSD system showed the ugliness that results if a system
had SystemColor.background set to black.
19. [SERVER/CUSTOM] Pulled classes for critical objects into ganymedeServer.jar
Previously, all subclasses of DBEditObject were packaged along with
the custom schema code. This was inappropriate, as the server depends
on those classes for proper authentication and logging, and there is
little to be gained by forcing adopters to include those classes in
their customization efforts. Worse, if an adopter did not select a
schema at install time, no support classes for the permission system
were installed. Now, all the code that the server _depends_ on for
its own logic is kept safe and bundled.
20. [CLIENT] Fixes to the tree icon logic
There were some circumstances in which an object with more than one
exceptional condition (both checked out for editing and marked for
inactivation, say..) would not have the most sensible icon displayed
for it in the tree. The client now takes the possibility of multiple
conditons into account and takes the relevance of the various
conditions into account when assigning an icon for the object's node
in the tree.
21. [CLIENT/ADMIN CONSOLE/SERVER] Tweaks for 1.2b4 compatibility
The new security system supported in the 1.2b4 and (presumably) later
releases of the JDK forces a new security model on code that installs
a SecurityManager, in such a way that the code is not compatible
across 1.1 and 1.2, at least as of 1.2b4. To get around this, the
Ganymede client and server code no longer install the
RMISecurityManager. There is no practical downside to this, as the
only thing that the RMISecurityManager enabled was the transfer of
executable classfiles between the client and the server, which
Ganymede did not do anyway.
22. [SERVER] Various fixes
a. The fully-privileged internalSession GanymedeSession that the
server uses for its internal operations has had oversight turned off,
to speed things up somewhat, and as an attempt at debugging stuff.
b. Object reference (invid) fields can now lookup a remote object's
label in a transaction, even if the remote object has had its fields
cleared in preparation for deleting that object at transaction commit
time. This comes into play when the details of a transaction is being
logged to disk at transaction commit time. One side effect of this is
that if you (say) rename a user and then delete the user in one
transaction, the logging system will report that user <newname> was
deleted, but that <oldname> was removed from account groups, and the
like. Fixing this would be rather more involved than the payoff would
be worth at this time, I think.
c. Boolean fields are considered to be undefined if they are set to
false. This makes it possible to edit the schema to remove boolean
fields if all instances of a boolean field are false. Previously, the
boolean fields would be undefined until someone set them, at which
point they would remain defined, regardless of value. One consequence
of this is that the logging for boolean toggles may seem
counter-intuitive, with true-to-false transitions recorded as the
field being removed.
d. The database dumper, expiration processor, and expiration warning
tasks won't fire if the schema is being edited.
e. The Ganymede server will never explicitly record an object as
being owned by supergash, since by definition supergash implicitly
owns all objects. This change reduces the size and memory loading
of the database, but will increase the time it takes to do initial
bulk loading.
23. [ADMIN CONSOLE] Admin Console will exit when server is shutdown
If you use the 'shutdown server' menu option in the Ganymede Admin
Console, the console itself will shut down once the server finishes
its shutdown sequence.
24. [SERVER/CUSTOM] anonymousLinkOK and anonymousUnlinkOK expanded
In order to properly secure privileges to add or remove objects from
owner groups on the server, we have added a new parameter to the
anonymousLinkOK and anonymousUnlinkOK methods in DBEditObject. This
is the GanymedeSession parameter, so the code can determine whether to
allow the link or unlink based on the identity of the user attempting
the link. If a custom subclass author does not override the expanded
version of these methods, the old methods will be called, without
the GanymedeSession reference.
25. [SERVER] Ownership security hole fixed
Previously, the Ganymede system depended on the client being
trustworthy when it came to restricting the ability to grant ownership
of objects to an owner group. The server now checks this operation
against the admin's owner group membership to prevent abuse.
A related change fixes a similar vulnerability in all object-linking
logic. The server will no longer allow values to be placed in
InvidDBFields if the field is choice-restricted and if the value was
not a choice presented to the client.
26. [CUSTOM] Added bsd schema
Added a simple passwd/group BSD 4.4 compatible schema, analagous to
the nisonly schema, but with support for the BSD 4.4 master.passwd
file format.
-------------------------------------------------------------------------------
Jonathan Abbey jonabbey@arlut.utexas.edu
Applied Research Laboratories The University of Texas at Austin
-------------------------------------------------------------------------------
----------------------------------------------------------------------------
To make changes to your subscription to the ganymede mailing list, send
mail to majordomo@arlut.utexas.edu.
To unsubcribe, include the line
unsubscribe ganymede
in the body of your mail message
Download ganymede from ftp.arlut.utexas.edu/pub/ganymede/.
To see the latest design specs for Ganymede, visit the Ganymede web page
at http://www.arlut.utexas.edu/gash2/
----------------------------------------------------------------------------