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@central.sun.com) and Andy
Johnson (andyjohnson@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@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 ----------------------------------------------------------------------------