Dr. Hendrik,

I apologize for the very late reply.

On 12/12/2014 4:48 PM, Dr. Hendrik Naumann wrote:
> Hi Jeffray
>
> Thanks for you detailed answer. Questions below.
>
> [deleted text]
>
> Your users are a very heterogeniuos and international group of 
> scientists focust to there projects. Some of them even don't speak 
> good english, nor german. Thus it is very hard for us the get though 
> with this kind of information. 

I suspect you meant to say "Users of OpenAFS are a very heterogeneous
and international group ...".

Instead you addressed to me, "Your users are ...".  This bothers me
because I do not have any users.  My companies have customers and those
customers can submit support and feature requests for products they
license or purchase support for.

While it is nice to hear that members of the tu-berlin.de community are
for the most part happy with software I have contributed to, they are
not my users.  They do not feed my family or those of my employees, nor
do they put a roof over their heads nor contribute to their medical
expenses.  (That last is a sore point for those of us living in a
country without nationalized health care.)

The vast majority of consumers of open source software forget that
complex software does not magically appear.  It does not maintain itself
nor does it update itself.  Unlike most consumer applications, a file
system is tightly integrated into the operating system and requires
adjustments for each and every operating system release.  That requires
not only a deep understanding of the file system but of the operating
system internals.  In the end it is people who are the software
developers, perform the testing, and in a perfect world write documentation.

When I started publishing open source software in the late 1980s open
source for the most part was the product of academic institutions.
Whether it be students, research projects or to a large extent system
administration staff that developed programs to solve the hard problems
of the day.

When OpenAFS was released by IBM in 2000, it was academic institutions
that provided the staff that took the leadership roles on the Elders,
provided the Gatekeepers, wrote and tested the software and generated
binary releases and later installation packaging for Windows, OSX, and
Linux.  In 2000, the people that performed all of these activities were
paid to do so by the institutions that deployed OpenAFS.

Today, there are a decreasing number of contributors and contributions.
 Especially from individuals employed by end user institutions.  Its
been a long time since organizations have been called out for directly
helping OpenAFS so I'm going to do so.

Your File System Inc. pays the salaries of the gatekeepers, Daria
Brashear (also former Elder and Foundation Board member) and myself.  It
also pays Marc Dionne who has performed most of the work tracking the
nightly changes in the Linux mainline kernel repository.  Simon
Wilkinson who is the OpenAFS Security Officer and the leading expert in
Rx.  Your File System Inc. also pays Peter Scott and Rod Widdowson who
are contributors to the Windows client. Your File System provides a
number of Buildbot builders.

Secure Endpoints Inc. funds a large amount of the code that has been
contributed to Heimdal including work by Luke Howard, Nico Williams, and
others.  Secure Endpoints can also be thanked for Network Identity
Manager.  Heimdal is important to OpenAFS because OpenAFS imports
critical components including its cross-platform compatibility and
crypto libraries from Heimdal.

Sine Nomine Associates employs Andrew Deason, Mike Meffie (one of the
AFS3 Standardization Chairs and I believe a registrar), Mark Vitale, and
Perry Ruiter.  SNA also provides number of Buildbot builders as well as
assists with the administration of the Buildbot master.  SNA's Margarete
Zimmer is a Foundation Board member.

Carnegie Mellon employs Jeffrey Hutzelman (AFS3 Standardization Chair
and registrar), Chaskiel Grundman, and Roman Mitz (Treasurer, former
Elder and Foundation Board member).  Jeff and Chaskiel provide much of
the openafs.org infrastructure on a personal basis including all of the
mail services, the request tracker, web services, afs services, and
registrar services.)

MIT employs Ben Kaduk who is the most prolific developer in the
community at the moment.  MIT hosts a number of core services including
the OpenAFS Gerrit instance, the Buildbot master, and the master source
code repository.

DESY employs Stephan Wiesand (the 1.6 series release manager).

UNC Charlotte employs Jason Edgecombe (Buildbot manager) and Nathan
Hatley, and provides a number of Buildbot builders.

MIT's CSAIL employs Garrett Wollman and provides a number of Buildbot
builders.

IBM's Todd deSantis still participates in an official capacity as a
Foundation Board member.  He was a founding Elder.

Cornell NanoScale Science and Technology Facility employs David Botsch
(Newsletter author, Foundation Board member) and provides a number of
Builbot builders.

US Geological Survey employs David Boldt (Foundation Board member).

Naval Research Lab employs Chas Williams without whom Ben Kaduk would
probably go mad.  Chas not only contributes code but also performs a
large number of code reviews.

University of Edinburgh provides the Mock builder that generate much of
the linux packages. Edinburgh also hosted one of the recent conferences.

Rechenzentrum Garching (RZG) employs Christof Hanke who produces the
SuSE packages.

CERN has a number of contributors on staff but also hosted the most
recent conference.  Thanks enough cannot be offered enough to those who
enable conferences to take place.

Tom Keiser is a member of the Foundation Board and a former prolific
source contributor to OpenAFS during his time working for SNA.


There are other individual source code contributors.  A full list of
current and historical contributors can be viewed via OpenHub as
constructed from the source code repository.

  https://www.openhub.net/p/openafs/contributors

I want to offer explicit thanks to all of these organizations and
individuals for their contributions.

There are a broader number of organizations that purchase support or
services from commercial support providers such as Sine Nomine
Associates and Your File System Inc.  Purchasing a support agreement
should not be viewed as a contribution to OpenAFS.  Support providers
and their employees have legal obligations to their customers and
ethical obligations to those organizations that directly contribute to
OpenAFS; they do not have an obligation to the broader end user
community that takes free advantage of the work product.  That being
said, without support contracts Your File System Inc. and Sine Nomine
Associates would not exist to participate in the OpenAFS community.

> Is there any chance to implement a feature that the TGT ist just 
> stored to some file, that later can be importet by the NIM, by a logon 
> script?

As my friend Gerry Seidman says, "with a million lines of code you can
do anything".

I have no plans to implement such a feature for OpenAFS.  For starters,
who should implement it?  Should it be part of OpenAFS?  Part of Network
Identity Manager?  Or part of the Kerberos distribution?  These
different source trees provided by three independent groups of developers.

Is stashing the Kerberos ticket in a FILE based cache the right thing to
do for all accounts?  What if Network Identity Manager is not used and
there is nothing to consume the contents of the cache and import them
into the API based credential cache?  What if the account is a Domain
account?  There are other edge cases I can come up with.

My long term plan for Heimdal on Windows is to implement an in-kernel
Kerberos credential cache that is layered on top of the AFS Redirector
AuthGroup framework.  The benefit of this approach is that the
integrated logon process can store Kerberos credentials into the
AuthGroup cache at the same time that it obtains the AFS tokens.  The
Kerberos credentials and AFS tokens are then available not only in the
logon session processes that inherit the AuthGroup but also in child
processes that run in an elevated permission state or impersonate a
calling process.  It then becomes possible for the integrated logon
provider to spawn a process to auto-renew the credentials without the
need for a Network Identity Manager style credential manager.  Such an
approach is secure, seamless and safe to deploy in all configurations.

This is a project that an organization can choose to implement on their
own and contribute to the community, hire someone to develop, or wait
until I have time to implement it for the Your File System Inc. AuriStor
client.

> Thanks
> 
> Hendrik Naumann

Sincerely,

Jeffrey Altman




Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to