On Wed, 2006-12-06 at 13:44 +0200, Alan McKinnon wrote: > This makes sense. Before moving forward though, perhaps we should get > some numbers/facts on the table. > LPI has historically focused on testing mature, proven technologies that > are deployed and in demand. I'm not convinced yet that NFSv4 meets > these criteria,
Understand NFS, the file service, is very mature. Just like SMB, the file service, is very mature. Where the "questions" arise are the RPC services built around them. Where Samba is "radical" is its varying and "work-in-progress" RPC services. As such, people deploy the "most common" services they need to work. That includes how to configure authentication, user mapping and ACLs. Other features are there, but often not used commonly. I assume we are building the Exam 302 on Samba 3.0, and not covering old Samba 2.0 (maybe some 2.2?) or earlier, correct? Likewise, NFSv4 is "radical" in its new RPC services. Although using Kerberos (and other PAM services) for authentication was available in some NFSv3 implementations, NFSv4 now integrates authentication with the full GSSAPI as IETF _standards_. So we should cover how to configure authentication for NFS exports right along with SMB exports. Likewise, when you start dealing with user mapping, IDMAP is how you can address both NFS and SMB too. Now I've already stated that NFSv4's ACLs should probably _not_ be tackled because of the on-going IETF-POSIX drafts, _except_ if it also and directly applies to Samba (e.g., the filesystem level). That would have to be evaluated further. > so I'd be asking these questions: > 1. Has it moved beyond the testing state to a stable state? Yes. NFSv4 was released almost 3 years ago, not long after Samba 3.0. It is _standard_ in kernel 2.6, including the user-space support daemons. The NFS [kernel] "daemon" itself wasn't difficult (much like the "SMB" daemon), but it's all the RPC services built around it for authentication, mapping, etc... As of 2006 Aug 22, the OSDL has _certified_ that NFSv4 is "production quality" right down to the RPCs. That was the main reason I brought it up. Novell and Red Hat have supported NFSv4 in its enterprise releases for over 18 months, and Red Hat has been shipping it in Fedora for 2.5 years. > 2. How widely deployed is it? NFS has always been extremely and widely deployed. The NFS protocol itself changes little in version 4, just like Samba hasn't changed the SMB protocol much from 1.x to 2.0 to 2.2 to 3.0. It's the RPC services built around it that have changed, just like Samba. Many corporations have started implementing NFSv4 RPC services so authentication and mapping is completely real-time. That's always been the problem with NFS (as well as SMBfs in Linux), authentication was only done at mount-time. NFSv4 finally addresses that in real-time ticketing. Although while some NFSv3 implementations could use NIS+ (Solaris) or Kerberos (Red Hat, Solaris, others) to control authentication and even a few others tackled some ACLs/ACEs, NFSv4 is now a standard implementation with a flexible set of APIs for authentication and mapping, including ACLs/ACEs, that are done right in the regular RPCs themselves. > 3. How accepted is it in places where it is deployed? NFSv4 is an evolutionary change in capabilities from NFSv3, just like Samba 3.0 is from 2.2, etc... Saying not to use the new RPC functions in NFSv4 would be like saying not to use new RPC functions in Samba 3.0. ;-> > 4. Can we confidently state that NFSv4 will be accepted by industry as a > standard, even a de-facto one? Yes. It's an Internet Engineering Task Force (IETF) standard. In fact, _unlike_ NFSv3 and (God help us) Linux's _non-standard_ NFSv2 implementation, the Linux NFSv4 implementation is the _only_, _full_ IETF compliant NFS version in Linux. ;-> I.e., Linux NFSv2 was grossly non-compliant with IETF RFCs. Linux NFSv3 had a lot of help from SGI and Sun, and was largely compliant (with a lot of non-compliant modes). Linux NFSv4 was heavily developed with help from Sun and others, and is considered "the standard" for NFSv4. > If all these questions can be answered positively, then by all means > let's move ahead. If not, that would indicate to me that discussing it > further is perhaps premature My _only_ point was that if we're going to put NFS into Exam 302, we should push aside all pre-NFSv4 concepts and _not_ bother with them since most are "non-standard." In other words, the RPC services in NFSv4 for authentication, mapping and ACLs (although the last item may be of limited or no consideration at this time) should be covered as they relate to the underlying filesystem or compatibility with Samba. I.e., it's like saying let's not cover old Samba 2.0 authentication when Samba 3.0 (and even 2.2 to a lesser extent) offer additional RPC services for true NTLMv2 and Kerberos authentication. That's my point. ;-> -- Bryan J. Smith Professional, Technical Annoyance mailto:[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
