Community Support for OpenAFS for Windows

OpenAFS 1.3.70 has now shipped.  This is a major step forward
in the improvement of performance, stability, and integration
of AFS on Microsoft Windows.  I estimate that close to nine
person months of effort went into this release.  Of that I
estimate that one third was unfunded work related to coding
of features everyone needs but no one would pay for,
testing, debugging, and release packaging.  I have not done
this work alone and for that I am grateful.

I want to once again thank MIT and their student hire Asanka Herath
for all of the late nights we have spent on this project;
Rodney Dyer of UNCC for being a pain in the ass, pushing OpenAFS
for Windows to its limits and providing access to their environment
for testing; Sine Nomine Associates and their clients for allowing all
of the bug fixes and new features to be incorporated into the new
release; and those individuals who have contributed to my tequila fund.

While on one hand I am thankful for the support which has been
provided I am also somewhat disappointed by the lack of the greater
community to step up to the plate.  At the AFS Best Practices
conference it repeatedly stated by attendees that the future of
AFS in their organizations is dependent upon how well the Windows
client performs.  Many individuals and organizations offered their
support never to be heard from again.  The only conclusion I can
come to is that money is tight (isn't it always) and the collective
feeling is that progress is being made and someone else will
contribute.  While some organizations have contributed
their efforts are not enough.  If every organization deploying OpenAFS
for Windows contributed just US$1000 or US$2000 a year, there would
be significant funding to cover the development efforts.

The response to my presentation at the AFS Best Practices conference
was highly motivating.  It demonstrated that at least on a conceptual
basis my dream of having OpenAFS and Kerberos for Windows deployed
transparently on every Windows machine in order for the real work
users want to accomplish simply work in a secure environment is shared
by the community.  In order for AFS to be successful it must integrate
with Windows to such an extent that users do not notice its existence.
With the release of 1.3.70 I can honestly say that all of the easy
work has now been done.

Examples of some of the hard work which is ahead of us:

* The UI must be replaced to allow for better separation of function
   between AFS client administration; End user environment
   configuration; and credential management (k5 tickets, tokens, cell
   to principal mapping)
* The architecture of the SMB/CIFS server does not allow for sequential
   processing of SMB/CIFS requests.  This prevents us from implementing
   support for digital signing but more importantly breaks applications
   which use overlapped writes.  This causes all Microsoft Office
   applications to have failures when writing to AFS.  I can't think of
   a more important suite of applications which must simply work if AFS
   is truly to be used in a transparent manner from the end user
   experience.
* The lack of cache persistence and the inability to support GB size
   caches not only reduces the performance of the OpenAFS for Windows
   client but it also places an extremely heavy burden on the AFS file
   servers.  My rough guestimate is that when applications are being
   served out of AFS every Windows client feels like 100 Unix clients to
   the AFS servers.  This is a serious burden which must be addressed if
   95% of the clients using AFS are going to be Windows.
* Support for UNICODE in the SMB/CIFS server and unnormalized utf8
   as the character set for file and directory names stored in AFS
* Support for files greater then 2GB in size
* Support for 64-bit architectures: ia64 and amd64,
* Implementation of an Installable File System option for those sites
   with increased performance requirements and who do not rely on the
   Windows Client Side Caching support for redirected folders


These projects are significant in scope and require months or years
to complete.  I am not asking anyone to blindly write a check to
pay for all of this.  What I am asking is that those who are going to
enjoy the benefits make an effort to contribute something on an on-going
basis.  Contributions may be made in the form of:

* a check, credit card, or paypal payment to Secure Endpoints Inc.
* a tax deductible donation to the Usenix OpenAFS.org account
* a tax deductible donation to the MIT Kerberos account
* part-time employment to support the OpenAFS for Windows Gatekeeper
   role
* the assignment of some number of programmer hours on a weekly basis

In order for the community to succeed in making AFS a first class
citizen in the Windows world, each of us are going to have to answer
the question "what can I or my organization do to help?"  I understand
the temptation to assume that OpenAFS is open source and therefore it
does not cost me anything to use it is quite high.  However, I would
argue that while there is no legal obligation for the purchase of
licenses (per-user, per-client, per-server, per-organization) there is
a moral obligation to assist the community which enables you to
better serve your end users.

Thank you for listening.  I hope that I can count on you.

Jeffrey Altman
OpenAFS for Windows Gatekeeper
Secure Endpoints Inc.
http://www.secure-endpoints.com/

begin:vcard
fn:Jeffrey Altman
n:Altman;Jeffrey
org:Secure Endpoints Inc.
adr:;;255 W 94TH ST PHB;NEW YORK;NY;10025;United States
email;internet:[email protected]
title:President
tel;work:+1 212 769-9018
x-mozilla-html:TRUE
url:http://www.secure-endpoints.com
version:2.1
end:vcard