Ganymede 0.99.2 released

Sat Jun 19 05:09:33 UTC 1999

Ganymede 0.99.2 is now available for download at

 http://www.arlut.utexas.edu/gash2/

or

 ftp://ftp.arlut.utexas.edu/pub/ganymede/

Ganymede is a GPL'ed network directory management system written in
Java, providing support for team management of NIS, DNS, etc.

--

This is a bug-fix and documentation release.  The biggest bug fixed is
that the admin console will now work properly from the Java plug-in on
Windows.  A number of bugs were fixed in the permissions and security
system in the server as well, and one logging improvement.

In the documentation arena, dozens of classes in the Ganymede server
have had javadocs written and/or expanded.  Most of the key classes in
the Ganymede server now have mini-essays in the javadocs header,
describing the use of the class, as well as hyperlinks to the main
classes that interact with the class.  It should be possible to learn
a lot about how the server works by going to the 'server javadocs'
link in the Ganymede documentation and following links around.

Despite all the work that went into improving the javadocs, I still
think that documentation is one of Ganymede's weakest areas.  You can
help!  Any feedback you could give about any aspect of Ganymede's
documentation or operations would be greatly appreciated.. we really
don't get very much e-mail at this point.  It would be nice to hear
success stories as well as critical comments on the documentation and
problems with the software.

-------------------- Changes from 0.99.1 to 0.99.2 -------------------

RELEASE DATE: June 18, 1999

1. [DOCUMENTATION] Seriously Improved Javadocs

Lots more improvements to the source code javadocs.  Improving the
javadocs is an ongoing project.. I really want to make it possible to
get a very good feel for how the entire system works on a technical
level by simply browsing through the javadocs.  It's an interesting
exercise, and a continuing one.  If you find yourself puzzling about
something in the code, please let me know so I can document it better.

2. [SERVER] Improved DBLock, DBObjectBase classes slightly

Added some more explicit lock status check methods to DBObjectBase.
Modified GanymedeAdmin's schema edit status check to use the
new DBObjectBase.isLocked() method.

Pulled some methods and variables from the DBLock subclasses up to
DBLock.  Added DBLock.isLocked(Vector) to safely test a lock against a
vector of DBObjectBases.  Modified GanymedeSession.queryDispatch() to
use the new method, and to verify that the database remains read
locked at the completion of the query loop.  (the user could have been
knocked off via the admin console, etc.).

Documented all the pieces of the lock system in the Javadocs.

3. [SERVER DISTRIB] Added permdecodeDB command

permdecodeDB will take an existing ganymede.db file and report on
the permissions bits encoded by roles in the database.  Useful
for debugging permissions code problems.  See #4 below.

4. [SERVER] Corrected, simplified server's permissions system

The Ganymede server's permissions system had a complex and (as it
turned out) broken system for inheriting 'default permissions' for
fields in an object.  Previously, an object type could have a default
permissions bitset registered, and any fields in that object for which
permissions had not been explicitly set would take on the default
value.  This was intended to support reasonable behavior for newly
created fields, but the code to implement this had problems in some
odd cases.  The notion of an explicitly recorded default permission
set for fields that differed from the permissions on an object type
itself has been removed.  In keeping with this, the
setDefaultFieldPerms() methods on both PermissionMatrixDBField and
perm_field have been taken away, in favor of setFieldPerms(), which
sets permissions for all existing fields in an object type, but
doesn't involve the complex default logic.  The permissions logic has
been simplified, and better documented in the javadocs.

Now, when new fields are added to object types through the
schema editor, all Role objects will grant the permission for the
object as a whole to the new fields.  If you run the permissions
editor in the client on a Role object's permissions fields, you can
change this default.

Since the Ganymede client's permissions editor dialog had no code for
calling the setDefaultFieldPerms() methods on perm_field, this change
shouldn't affect any custom work people have done.  The gash and
gasharl ganymede.schema files did ship in 0.99.1 with a default
permission set on a few object types.  People using a ganymede.db file
derived from a gash or gasharl ganymede.schema may find that they need
to use the permissions editor to correct problems in the GASH Admin
Role object's permissions bits.

5. [SERVER] Changes to permissions fields now descriptively logged 

If an administrator makes changes to the permission bits in a Role
object, the server's log will now record the precise changes, which
will be visible in the Role object's history panel.  

The history recorded may be a bit deceptive in the case where a field
which previously had no explicit field-level permissions set has them
set..  if the object type has a permission of view/create/edit, and
you edit the field's permission to set it to view/edit only, the log
file will show that the field gained view and edit, when it
effectively lost create, which was previously inherited.

6. [SERVER] Miscellaneous methods added

Added debugging toString() to DBField, PermMatrix classes.
Added getFieldName(short) to DBObject, db_object.

7. [ADMIN CONSOLE] Fixed admin console

The admin console now works properly in a browser, and properly
initializes under all conditions.  

The magic incantation to get the Ganymede Admin console to find the
arlut/csd/ganymede/GanymedeServer_Stub.class file was to include the
arlut/csd/ganymede/Client.class in the ganymedeAdmin.jar file.

Apparently, Sun's RMI classloading logic freaks out if it comes across
a reference to an unavailable RMI remote interface parameter in a RMI
remote method _Stub.class file, even if the freaked-out client in
question never refers to that method call.

I tried *everything* to figure this out, before finally noticing the
blurb in the Java plug-in's console about the Client.class load
attempt.. d'oh.  I wound up having to include
arlut.csd.ganymede.Client and arlut.csd.ganymede.GanymedeScheduler
because both were referenced by RMI methods or serialized objects the
admin console needed.

In addition to fixing the ganymedeAdmin.jar file, the applet code was
revised to be closer to that of the standard client, to improve its
behavior and appearance in a web browser context.

I still need to make a nice 'admin console' logo for the admin console
applet.

Thanks to Charles Adams (charles.adams at central.sun.com) and Andy
Johnson (andyjohnson at engineer.com) for reporting the problem with the
admin console not working properly with the Java plug-in.

8. [SERVER] Fixed login logic

In 0.99.1 and before, the server had an ambiguity that would allow
users to login to the wrong priviliged admin account on occasion, if
there was more than one account with the same persona name.

I.e., if there was persona account 'broccol:supergash' and
'supergash', each with different passwords, the broccol:supergash
password could allow access to the non-user-associated supergash
admin account.  This was true for both normal client login and for
admin console attachment.

9. [SERVER] Fixed DBQueryHandler's field DEFINED logic

The Ganymede server's DBQueryHandler would throw an exception if
attempting to process a "field is defined" QueryDataNode if the field
in fact did not exist.

-------------------------------------------------------------------------------
Jonathan Abbey 				              jonabbey at arlut.utexas.edu
Applied Research Laboratories                 The University of Texas at Austin
Ganymede, a free NIS/DNS management system    http://www.arlut.utexas.edu/gash2