The Condor Project is pleased to announce the release of version 0.9.1
of the Stork Data Placement Scheduler,
http://www.cs.wisc.edu/condor/stork/ .  The primary feature of the
0.9.1 release is the migration to glibc-2.3, which extends Stork
binary compatibility to Redhat 9 and Red Hat Enterprise Linux 3.  This
release also includes several new features, tools, and bug fixes.  See
the complete Change Login the release for details.

This release is available for download from:
http://www.cs.wisc.edu/condor/stork/download/stork-0.9.1-linux-x86-glibc23-dynamic.tar.gz

Note that the 0.9 series of Stork releases are still to be considered
"Beta".  We strive to ensure that all Stork releases are fully
functional, and look forward to collaborating with Stork users to
develop this unique tool into production-quality software.   All
binaries in the 0.9 series are built with full debugging symbols, and
are therefore larger than may be expected.  Installations with minimal
storage resources are free to strip Stork binaries.  However, we
encourage users to use the full debugging binaries, as this may
assist with future debugging efforts.

With the 0.9.1 release, support for glibc-2.2/Redhat 7.2 has been
dropped, because of restricted support.  Use the previous stork-0.9.0
release on Redhat 7.x platforms.

Known Issues:
An authentication error may occur between the Stork server daemon
(stork_server) and Credential Manager Daemon (condor_credd).  When
this occurs, the Stork server may be unable to obtain a credential
from the Credential Manager.  In most cases, the default value of
	max_retry = 5;
in the delivered etc/stork.config file provides added data transfer
retries to remedy the authentication problem.  In rare cases, it may
be necessary to specify the user credential directly in the stork
submit file, with the line 
	x509proxy = "/path/to/proxy";
Stork developers are currently working to remedy this issue.