Re: Configuring NFSv4.0 Kerberos on a multi-homed Linux NFS server

["J. Bruce Fields" <bfields@fieldses.org>]

On Mon, May 09, 2016 at 11:00:06AM -0400, Chuck Lever wrote:
> 
> > On May 6, 2016, at 12:13 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
> > 
> > On Fri, May 06, 2016 at 09:23:40AM -0400, Chuck Lever wrote:
> >> 
> >>> On May 5, 2016, at 10:44 PM, Bruce Fields <bfields@fieldses.org> wrote:
> >>> 
> >>> On Thu, May 05, 2016 at 05:01:58PM -0400, Chuck Lever wrote:
> >>>> After some IRC discussion with Bruce, we think the answer
> >>>> is "this is not supported in the current Linux NFS server."
> >>>> 
> >>>> The server does not have a way to determine which service
> >>>> principal to use for NFSv4.0 callback operations. It picks
> >>>> (probably) the first nfs/ service principal in the server's
> >>>> keytab for all callback operations.
> >>>> 
> >>>> Thus if a Linux NFS server has a keytab, clients can mount
> >>>> it with NFSv4.0 (and any security flavor) only on the i/f
> >>>> whose hostname matches the name of the nfs/ service
> >>>> principal in that server's keytab.
> >>> 
> >>> One correction: the mount should still work correctly.  The server just
> >>> won't grant any delegations to the client.
> >> 
> >> Unfortunately this is not the case.
> > 
> > Ugh, OK, that's worse than I thought.  I guess you can work around it on
> > the server side with "echo 0 >/proc/sys/fs/leases-enable".
> 
> Google can find this e-mail thread, but would like me to
> open a bug report on bugzilla.linux-nfs.org as well, Bruce?

Up to you.  I'll confess to mostly ignoring upstream bugzilla until
it sends me email.

By the way, were you using gss-proxy?  (What distro?)  Did it take any
special configuration to get the basic protocol working with multiple
principals, beyond just creating the keytabs?

--b.