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. 3c1bb23c037, first in 1.1.3, removes AUTH_NULL from that static list. 603017f2c15, first in 1.1.4, derives the psuedoflavor list from the export (and introduces the above bug). The latest patch, not yet in Steve's repo, fixes the empty flavor list. For the rest of eternity, mountd is perfect. --b. -- 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
