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:b.j.smith at ieee.orghttp://thebs413.blogspot.com
--------------------------------------------------------
Fission Power: An Inconvenient Solution