Matt Benjamin <[EMAIL PROTECTED]> wrote: > NFSv4 is poised to be successful. However, it is by no means > universal today.
Agreed. But the exact same can be said for Samba 3.0. It's RPC services are still a "work-in-progress." > It has been developed by "all the right people" and pushed > forward by them. Agreed. > I am skeptical about including only information on NFSv4, > as you advocate. It still feels like "certifying future > practice." First off, step back and realize what I'm advocating. What I'm advocating is that whenever a _Samba_ to _core_ Linux (kernel, GLibC, NSS, LDAP, etc...) configuration _touches_ on those shared by NFSv4 (PAM, GSSAPI/Kerberos, IDMAP, etc...), we _also_ test for those concepts related to NFSv4 RPC services. That's all! By my point on "not talking about [non-standard] NFSv3 services," I mean how Red Hat implements Kerberos authentication of NFSv3 access, NIS+ or Sun One support, etc... We already covered "basic" NFSv2/3 in LPIC-1/2 just like Samba. And I'm sure we're covering "advanced" Samba 3.0 concepts in LPIC-3. So why not also cover the _core_ Linux capabilities of NFSv4 _as_ Samba 3.0 RPC support covers them. That was my point. ;-> > 1. NFS historical details and "interpretations" are not relevant > to this discussion Agreed. But I still answered the gentleman showing the "tit4tat" of the state of SMB support 5, 10 and 15 years ago against NFS -- both Linux and outside of Linux. > 2. non standards compliance and crumminess of older Linux NFS > implementations is not relevant to this discussion Agreed. I was merely admitting the issues with Linux's NFS implementation. > 3. Linux NFS implementation is NFSv4 compliant, and NFSv4 is being > adopted by larger organizations with an appropriate Kerberos V > infrastructure, people with Netapps, and whatnot Exactomundo! Thank you for supporting that point! ;-> > 4. IDMAP is not the only way to accomplish id mapping for CIFS, > Bryan, that is more special pleading It's not the only way, no. Just like IDMAP is not the only way for NFSv4 (or NFSv3 for that matter). But IDMAP is _very_common_ for Samba 3.0 to ADS or LDAP. Again, I was making an argument to _Samba_ supporters. Please recognize the context. ;-> I don't think you and I disagree at all. In fact, this is the type of detail that would go into Exam 301. ;-> > 5. People are looking to LIPKEY/X.509 GSSAPI implementation to make > NFSv4 convenient at sites that do not wish to implement Kerberos > V--this appears to be complete and supported by a group of NFSv4 > vendors now, Yes, NFSv4's GSSAPI support is very flexible. Yes, with the GPL/MPL release of Fedora Directory Server and Certificate Services (formerly Netscape Directory Server and Certificate Services, based on WU's original code also the core of Sun One's LDAP capabilities), this is also a very common option. But it doesn't support Samba, hence why the Samba people will bark. And I have to heed their bark when looking at the Samba context, namely for Exam 302. > hopefully coverage of that would not be omitted I don't think it should be in at least Exam 301 on certificate support in general, and whatever could be NFS-specific in Exam 302. Matt is the gentleman who would be far better judge of that than I. > By the way, we use AFS. ;) Hey man, I was all for putting AFS into Exam 302! ;-> In fact, everytime some ignorant fool starts the NFS v. SMB discussion, I always bark back "if you _really_ want to address security, you shouldn't be promoting SMB but seriously considering AFS." But I _tried_ to keep the "Samba context" here (namely Exam 302), so that's where my point was coming from. Thanx for your commentary. I believe you and I are in total agreement (please point out if I mis-interpreted anything you said or did not understand or appreciate one of your points as you intended it). -- Bryan J. Smith Professional, Technical Annoyance [EMAIL PROTECTED] http://thebs413.blogspot.com -------------------------------------------------- Fission Power: An Inconvenient Solution _______________________________________________ lpi-discuss mailing list [email protected] http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-discuss
