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
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
