On Jan 30, 2013, at 7:04 PM, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: > On Jan 30, 2013, at 6:51 PM, "Myklebust, Trond" <Trond.Myklebust@xxxxxxxxxx> wrote: > >> Looks good! How have you tested it? > > Start with a Solaris 11 NFS server and my client. The server has a Kerberos-only share called /test/krb5-only. > > 1. "sudo rmmod auth_rpcgss" on the client (no NFS mounts at this point) Bash history says I misremembered this. I actually used: "sudo rmmod rpcsec_gss_krb5" So, part of my next round of testing will try to remove both rpcsec_gss_krb5 and auth_rpcgss, if I can, and see if all the right things happen when I cross into a krb5-only file system. > 2. "sudo mount server:/ /mnt" > > 3. The client accesses the pseudo-fs with AUTH_UNIX (observed with wireshark) > > 4. After I kinit on the client, I cd into /test/krb5-only > > 5. The client encounters the WRONG_SEC and performs a SECINFO request (observed with wireshark) > > 6. The correct kernel modules are loaded, and the cd completes successfully. > > 7. I "cd ~" and unmount /mnt. The module refcounts go to zero. > > I've run this with debugging enabled and extra dprintk's, and it looks like the client is doing all the right things. > > I'd like to extend the testing a bit with a Linux NFS server, now that there's a server-side change in this series. And naturally I'll need broad compile-testing with various combinations of CONFIG options. I'm open to suggestions of other use cases / corner cases. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
