On Sunday, February 18, 2007 01:23:42 AM -0500 Marcus Watts <[EMAIL PROTECTED]>
wrote:
Date: Fri, 16 Feb 2007 12:50:38 -0500
From: Jeffrey Hutzelman <[EMAIL PROTECTED]>
To: Marcus Watts <[EMAIL PROTECTED]>, [email protected]
cc: Jeffrey Hutzelman <[EMAIL PROTECTED]>
Subject: Re: [OpenAFS-devel] openafs rxk5 - AFS_RXK5_DEFAULT
On Friday, February 16, 2007 06:32:45 AM -0500 Marcus Watts
<[EMAIL PROTECTED]> wrote:
> The intention is that the "generic" token interface be capable
> of being augmented with with future token types (such as rxgk) in
> the future. The assumption is that in a given realm,
> all db & file servers be capable of dealing with the same
> credential type, and that is the responsibility of aklog/klog,
> with input from the user & from the kdc, to get the appropriate
> credential. The "capability" call is intended to return
> information on cm capabilities. For now it only supports
> rxk5 encryption types. In the future, it might also return
> information on other things, or have a companion pioctl
> to allow setting things. This might be used to get/set
> locking behavior or fs setcrypt.
We bashed out a lot of the details of what the new interfaces will look
like and what the fallback and transition mechanisms need to be at the
rxgk hackathon last month. Details, including the specifications for
the new VIOCGETTOK2 and VIOCSETTOK2 pioctls, can be found at
<http://www.afsig.se/afsig/space/rxgk-client-integration>
-- Jeff
Interesting. rxk5 already has a VIOC_GETTOKNEW VIOC_SETTOKNEW using
_CVICEIOCTL(7) and (8). Is this a proposal to build on top of that
interface?
This is the interface we propose to actually implement in the cache
manager, instead of the one that was in your patches. The interface you
had was not rich enough to handle multiple tokens per cell, which is
necessary for the transition and fallback behavior we defined. The
impression I got from Jeff and Derrick was that you didn't have rxk5
deployed anywhere where this change would be a problem,
Incidentally, your patch also uses three 'C' pioctl numbers (6,7,8) without
them actually having been assigned to you; the recent patch from Matt
Benjamin makes the same mistake. Numbers in this space must be obtained by
sending a request to [EMAIL PROTECTED]; otherwise, you risk
causing a collision, as the GetCapabilities pioctl included in the rxgk
patch does -- _CVICEIOCTL(6) is already assigned for VIOC_CREATE_MT_PT.
-- Jeff
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
