Date: Fri, 14 Jan 2000 12:13:03 -0600 (CST)
From: Jonathan Abbey <jonabbey@arlut.utexas.edu>
To: ganymede-announce@arlut.utexas.edu
Subject: [Ganymede Announce] Ganymede 0.99.9 Released

Ganymede 0.99.9 is now available for download at

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

or

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

Mirrors: (may take a short while to update)

 ftp://ftp.netlag.com/ganymede/ (USA)
 ftp://mirror.aarnet.edu.au/pub/ganymede/ (Australia/NZ only)
 ftp://ftp.kddlabs.co.jp/pub/ganymede/ (KDD R&D Labs, Saitama, Japan)

Ganymede is a GPL'ed metadirectory system written in Java, providing
support for team management of NIS, DNS, etc.  Ganymede provides a
multithreaded database server with plug-in intelligence for managing
directory data, custom scripting to propagate changes from the
database to external directory services, and a easy to use, graphical
client.

				  --

Mostly bug fixes this time, resulting from ARL's experience running
Ganymede in full production over the last couple of months.  The
server has been reworked to fix several deadlock vulnerabilities
relating to user time out and admin console operations.  The client
has had several usability improvements made to it, including the
ability for users to browse all objects in the tree that they have
permission to view but not edit, and some threading improvements in
the history panel.

I had hoped to do a rework of the schema kit distribution system this
time around, but I have decided that to do it right is going to
involve truly major surgery on the server, so I wanted to go ahead and
put out this release to tide people over for now.  

My current plans for the next major release are to incorporate the
Xerces-Java XML parser from The Apache Group into the Ganymede server,
and to support XML import/export of data from the Ganymede server.

This will simplify the schema kit data importation code, and will make
it possible for people to write their own code in Perl, etc., for bulk
data importing into the Ganymede server.  Part of this effort will
involve separating schema definition information from the object
database in the XML file, hopefully making it possible to
independently upgrade the Ganymede server's schema and/or objects in
the database.

All of this will require some experimentation on my part, though, so
for now, here is a nice and stable release of the Ganymede system as
it exists today.

-------------------- Changes from 0.99.8 to 0.99.9 -------------------

RELEASE DATE: January 13, 2000

1. [SCHEMA] Fixed gasharl schema errors

a. The gasharl schema kit had a bug which made it impossible to edit a
system if that system was connected to a room that had no networks
listed.

b. The gasharl GASHBuilderTask code is designed to handle netgroups that
overflow the 1024 byte NIS line length limit, but the code that
handled netgroup folding did so very inefficiently, putting only one
netgroup entry per line after the first.

2. [SERVER] Fixed race condition in Qstmp stopThreaded() method

The Qstmp shutdown process could throw a NullPointerException in
stopThreaded() if thread timing worked out just wrong.  This has been
caught, and this race condition will no longer be able to prevent
clean server shut-down.

3. [SERVER] Fixed various deadlock possibilities in server

a. The 3 DBLock subclasses (DBReadLock, DBWriteLock, DBDumpLock) did not
properly call notifyAll() on the DBStore object if they threw an
exception in their establish() method.  Now, all synchronized blocks
in the DBLock subclasses use try..finally to guarantee that other
threads waiting on DBStore will be woken up, even if something
unexpected happens.

The DBReadLock.establish() code had code to throw an exception if a
session that possessed a write or dump lock tried to obtain a readlock
at the same time.  Unfortunately, the internal sessions used for the
Ganymede builder tasks, expiration task, and warning task were given
the same identifier as the standard 'internal' session used to process
queries in the login process, so if a login was attempted during a
builder task's phase1 execution, or during portions of the expire or
warning task, an exception could be thrown, possibly causing
threadlock if other threads had wait()'ed at that point.  All this
should be fixed now.

b. There are several ways a user can be forced off of the Ganymede
server..  the idle timer, the admin console, and the RMI unreferenced
object mechanism.  Previously, various essential objects in the server
could get locked if the client refused to respond to the server's
disconnect command.  Now the client force-disconnect code is better
coordinated so only one thread in the server will ever attempt to
force the user to disconnect, and that thread will itself spawn a
background thread to force the user to disconnect.  As a result,
although the server may wind up with a single dangling thread per
client if the RMI system blocks trying to call the client, nothing
in the server will deadlock because of it.

As a result of this change, knocking a user off the system by the
admin console is no longer a synchronous operation, so it may take a
few seconds before the admin console updates to show the results of a
user kill operation.

c. The admin console code in the server had a number of problems that
could lead to a deadlock that blocked any admin console operations
(including the stopServer script).

The server code that handles communications to/from the admin consoles
have been significantly reworked so as to not be vulnerable to a
threadlock condition, and some redundant operations have been pruned
to reduce overhead.  A number of possible race conditions have been
closed.

This will make the server faster and safer when admin consoles are
attached, but the admin console updating is still generally
synchronous.  Every admin console connected to the Ganymede server
will slow the server down a bit.

4. [SERVER/CLIENT] Added support for 'browse' mode in client

John Knutson pointed out that the Ganymede client wasn't an adequate
directory browser because it always hid things that couldn't be
edited, when in fact the user had a perfect right to see everything
for which he is granted view access.  This was intended to be a
feature of the client, that it could present a simplified tree to the
user to avoid confusion, but it needlessly restricts advanced users.

The server and client have now been modified so that the client can
display all objects and object types viewable by the user, even if
the user does not have editing permission.

This is toggled by a 'Hide non-editable objects' checkbox menu item
under the client's 'File' menu.  I expect I may move this someplace
else in the client's GUI eventually.

This involved changes to GanymedeSession.java, Session.java, and
CategoryTransport.java on the server, and gclient.java on the client,
so a 0.99.9 server will now require a 0.99.9 client.

As before, the server is really responsible for deciding what object
types are reported to the client.. the client can't choose to show
object types in the tree if the server doesn't report them, but the
client can now ask to have all visible object types reported, which it
couldn't do before.

5. [CLIENT] Reworked object folder pop-up menus in client tree display

The client's object folder pop-up menus in the tree display has been
reworked to be less ambiguous.  The old 'List editable' and 'List all'
have been changed to 'Report editable' and 'Report all', and the old
'Show All Objects' has been changed to 'Show Non-Editables', and moved
to the top of the pop-up menu.

Hopefully this should be less confusing for folks.

6. [SERVER] Fixed custom schema migration bug from 0.99.8

Change 0.99.8, #17, listed below, which modified how the server
handles non-symmetrically linked InvidDBFields, didn't properly handle
InvidDBField definitions that explicitly listed the backlinks field as
the field to be linked to.  Apparently, in 0.99.7 and before, the
schema editor presented the backlinks field as a valid symmetric field
target.

Martin Schneider reported that Ganymede 0.99.8 was complaining when it
came across such a field in his ganymede.db file from 0.99.7.  I had
the server handling invid fields with target fields set to 'none', but
I hadn't handled the equivalence case of the 'backlinks' target.

The Ganymede server will now treat an invid field with a target field
set to field 8 (the obsolete backlinks field) in precisely the same
way that it treats invid fields with no target field specified.  This
should make Martin's ganymede.db file from 0.99.7 work properly in
0.99.9.

7. [SERVER] Made bad login user notification optional

Previously, the Ganymede server would always attempt to send
notification of a bad password/login attempt to the name of the user
entered at the login attempt, regardless of the configuration of the
'badpass' system event object.

Now the Ganymede server will not do this unless the 'badpass' system
event object in the ganymede.db database has the 'Cc: Admin' flag set.

8. [SERVER] Took out unnecessary fields in DBField.java

The DBField base class had a number of redundant or unnecessary
fields, including both a scalar and vector field, even though no field
is both a scalar and a vector.

I've removed the Vector values holding field and replaced it with
accessors which will treat the single value field as a Vector as
appropriate.

I also took out the 'fieldID' short, which was redundant, since the
DBField.getFieldDef() method already calculated that information from
the field definition reference.

I also took out the 'newValue' field, which was only used in one very
specialized case in the userCustom plug-in, and which was better
handled by putting an extra field in that custom DBEditObject subclass.

This will save 10 bytes per field in the database while in memory,
with probably around 40 bytes of per-field overhead remaining for
scalar fields, rather more for Vector fields.  Not a very big deal,
but it does amount to 80-300 bytes of RAM per object in the
database. For our current database, this probably saves us a megabyte
of in-memory space, or around 3% of the total resident memory usage.
That percentage could probably get quite a bit higher when the initial
size of the server itself is amortized over larger and larger
databases.

This change doesn't affect the on-disk database file at all.

9. [STOPSERVER] Modified the stopServer code to prompt for supergash password

Previously, if the Ganymede server's supergash ("root") password was
not kept in the server's ganymede.properties file, the stopServer
client would simply fail.

Now, if it can't load the supergash password from the
ganymede.properties file, stopServer will prompt the user for the
supergash password.

10. [CLIENT] Threaded out the client's history panel to avoid locking GUI

Here at ARL, our server log is getting quite large, and the round trip
time for reporting on the history of changes to an object is getting
large.  Because of this, the client's GUI has been locked for a longer
and longer time as the client's GUI thread blocks waiting for the
server to report the object history.

Because of this, the Ganymede client has been modified to thread out
history reporting.  The client's GUI will no longer lock up while the
client is waiting to get a report on an object's history back.

-------------------------------------------------------------------------------
Jonathan Abbey 				              jonabbey@arlut.utexas.edu
Applied Research Laboratories                 The University of Texas at Austin
Ganymede, a GPL'ed metadirectory for UNIX     http://www.arlut.utexas.edu/gash2

----------------------------------------------------------------------------
To make changes to your subscription to the ganymede announcement list, send
mail to majordomo@arlut.utexas.edu.

To unsubcribe, include the line

unsubscribe ganymede-announce

in the body of your mail message

Visit the Ganymede web page at http://www.arlut.utexas.edu/gash2

----------------------------------------------------------------------------