Re: Proxy

[Trond Myklebust <trond.myklebust@fys.uio.no>]

On Mon, 2010-05-03 at 14:56 -0400, J. Bruce Fields wrote: 
> On Mon, May 03, 2010 at 12:53:15PM -0400, maillists0@gmail.com wrote:
> > With NFS4's support for referrals and Kerberos, it seems like the
> > original reasons to prevent re-exporting of an NFS share might no
> > longer exist. With fs-proxy making its way into the mainline kernel
> > and things like cachefilesd, there are also very good reasons to allow
> > it. A proxy server with a persistent cache could give the ability to
> > robustly use shares across a WAN or do failover pairs with no need for
> > more complex replication. Speaking as an end-user, this would be very
> > desirable.
> > 
> > I see that others have implemented proxies with user-space NFS, which
> > seems reasonable but not optimal. What is the obstacle to allowing
> > re-exports with the standard nfs implentation? Is it possible at the
> > moment to patch a kernel to make this work? Anyone have experience
> > with it? Any input is appreciated.
> 
> It's probably possible, but some kernel hacking would be required.
> 
> Off the top of my head:
> 
> 	- filehandles: you probably can't pass your server's filehandles
> 	  unchanged back to your client.  At a minimum you'd want to add
> 	  a header allowing you to distinguish filehandles for the
> 	  different filesystems you export.  What if you get a
> 	  filehandle from the server that's already at the protocol's
> 	  maximum size?  Are you going to try to maintain your own
> 	  persistent mapping of filehandles, and if so, is it possible
> 	  to do that with reasonable performance?
> 	- what do you do if your server takes a really long time to
> 	  answer a request?  Or stops responding completely?

      * If you want to use Kerberos, then how do you proxy an RPCSEC_GSS
        session? 
      * How does the proxy server figure out the real server's export
        rules so that it can re-export them?