[OpenAFS-devel] rxgk updates

Benjamin Kaduk kaduk@MIT.EDU
Thu, 5 Jun 2014 16:36:31 -0400 (EDT)


Time for another update.

On Tue, 1 Apr 2014, Benjamin J Kaduk wrote:

> On Tue, 10 Dec 2013, Benjamin Kaduk wrote:
>
>>
>> I've also made an RXGK "todo" page on the wiki
>> (http://wiki.openafs.org/RXGKToDo/) with a list of the known outstanding
>> tasks.  I'm sure there are more tasks that have yet to be documented; as we
>> come across them, please try to keep the list updated.  If any of the items
>> are unclear, we can of course discuss them on this list or the jabber room or
>> elsewhere.  When I first started working on rxgk, I think I said something
>> about it probably being best to have just one person working on the core
>> implementation, and more hands would be handy later on.  We're probably past
>> that point, and more help is definitely useful at this point.
>
> I should update on what I'm working on.  I picked up the item to move rx
> epoch/cid generation into the core rx code, which is sitting in gerrit as
> 10840-10843.  Looking through my gerrit changes, it would be nice to get
> 10526 in as well, to help indicate which places in the tree have code that
> conditionalizes on the rx security class.

10840-10843 are still sitting in gerrit.  They would probably need to be 
rebased before being mergable, at this point, though.
I need to fix a few issues that were noted in 10526.

> I've also picked up the items on the wiki page's list to write a getkey
> routine using the cell-wide rxgk key from KeyFileExt, and make the afsconf
> changes to allow rxgk server security objects, though at the moment I'm
> only looking at the case using the cell-wide key, with the goal of using
> rxgk for the ubik synchronization connections (another item on the list).

I have code for these in gerrit; it's enough to let one run a vlserver 
-rxgk and have it use a printed rxgk token to talk to the other vlservers 
(for DISK_ RPCs).

> I also asked Andrew if he wanted to write up some notes on the vldb
> format, since he had done some research there while investigating what
> needed to be done for IPv6 support.  I or someone else could take those
> notes and flesh them out into a detailed description akin to the prdb.txt
> document that we have in the tree.

I don't think there's been any action on this front.


Looking at http://wiki.openafs.org/RXGKToDo/ , there are still several 
other open tasks:

ptserver support for extended names.  The minimum needed to get rxgk 
working with the fileservers should just be the fallback 
AuthNameToIDFallback, which should not be too hard to implement for 
gss-krb5 names.

I started sketching out a scheme for per-fileserver keys, involving 
storing them in the KeyFileExt with a different key type than the 
cell-wide key.  This isn't very useful until there's a way to store them 
in the vldb and a scheme for giving the fileserver gss initiator 
credentials.

A story for combined tokens.  Probably not actually urgent.

asetkey updates for rxgk.  asetkey should learn how to generate random 
keys of type afsconf_rxgk, and how to print/list them.

getting rxgk tokens into the kernel.  I looked at this some; the existing 
pioctl SetTokens2 has enough rope to handle rxgk tokens, and the in-kernel 
tokenJar structure will differentiate by type.  Only rxgk tokens for 
dbservers should be sent into the kernel this way, and the cache manager 
will call AFSCombineTokens as needed.  Once we can have rxgk tokens in the 
tokenJar, then we can look at using them for outgoing connections.

Help with any of these would still be greatly appreciated!

-Ben