On Fri, 2009-08-21 at 17:30 -0400, J. Bruce Fields wrote: > On Fri, Aug 21, 2009 at 05:15:45PM -0400, Trond Myklebust wrote: > > On Fri, 2009-08-21 at 16:36 -0400, Chuck Lever wrote: > > > On Aug 21, 2009, at 4:04 PM, J. Bruce Fields wrote: > > > > Also, while I hope this is the last bug in the mountd's flavor list > > > > return, it isn't the first--only recently did we even start using real > > > > information from the export instead of just faking something up. So I > > > > think it's safest to preserve the historical sec= behavior and give > > > > users a way to override the negotiation, to cut down on bug reports of > > > > mount failures on upgrade. > > > > > > OK, if this is a recently introduced server problem, then why do we > > > need to adjust client-side behavior? Trond's response in cases like > > > this is usually "fix the d*mn server," which you've already done. > > > > What is the definition of "recently introduced" here? What is the exact > > commit that introduced the bug in nfs-utils? > > By the way, looking at 'gitk utils/mountd/mountd.c' in my tree: > > Originally (didn't look to see how far it goes back), mountd > returned AUTH_NULL, AUTH_UNIX, in that order. > 53c5bd65c74, first in 1.0.8, always returns > AUTH_NULL, AUTH_UNIX, AUTH_GSS_KRB5, AUTH_GSS_KRB5I, > AUTH_GSS_KRB5P, in that order. So all these should work without any trouble. > 3c1bb23c037, first in 1.1.3, removes AUTH_NULL from that static > list. Does the server support auth_null security? I didn't think it did. > 603017f2c15, first in 1.1.4, derives the psuedoflavor list from > the export (and introduces the above bug). That means the bug is likely to be in Fedora 10 and 11, the latest Debian and Ubuntu, as well as SLES 11. Sounds like a long list to me... > The latest patch, not yet in Steve's repo, fixes the empty flavor > list. > For the rest of eternity, mountd is perfect. We're getting rid of it? -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.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
