[lpi-discuss] Re: Re (snip) more personal opinion (on NFS) -- context is everything (please understand mine)

[Bryan J. Smith]

On Thu, 2004-10-21 at 11:20, Matt Benjamin wrote:
> Bryan,
> I take your general point, but I'm disagreeing with it, in so far as 
> you're saying that distributed filesystems on Unix all look like NFS.  

No.  What I'm saying, from the standpoint of _mount_ (and automounter,
etc...), a remote filesystem is a remote filesystem.  Now there might be
additional, network filesystem-specific details for authentication,
authorization, etc...

But, getting back to the original thread, the "basics" in the LPIC-1 are
going to cover traditional NFS because they are at the foundation of
most concepts of _any_ network filesystem on UNIX/Linux.

Anything else should be left to either a LPIC-3 exam, or maybe LPIC-2 as
they become more proliferated in widespread usage.

> They don't.  (I'm staying out of the CIFS quagmire.  You can have it.)  

Then you are _not_ even discussing this with me because that is the
entire _context_ of my argument.  If you choose to ignore that portion
of it, then you are basically _ignoring_ what I'm saying in its
_entirety_.  ;->

I typically put things in the context of something versus the most
popular and well-known implementation.  As such, CIFS/SMB is it.  That's
why you're missing the crux of my viewpoint, because many people are
coming from Windows (although some are coming from Sun, etc...)

Is SFS (using NFS) on its own as good as Kerberos+AFS?  Hell no.  What
about DCE/DFS and its varying mechanisms?

Can Kerberos (user authentication) and SFS (using NFS) with a formal
X.509 certificate tree (system authentication) be acceptable as "secure
enough"?  Hell yes!  I think people forget that NFS is still a viable
solution using SFS, and acts the same.

If you re-read my post, you'll note that I was breaking down NFS +
various add-ons v. CIFS/SMB.  So how can you differ with me if you are
introducing _something_else_ that I did _not_ address?

> Also insofar as you suggest we can wave away security concerns,

Quite the opposite!  Please _re-read_ my post.

In fact, I have gone to _great_lengths_ to educate users on the
_dangers_ of CIFS/SMB.  Especially the portions that "just don't work."

Because 9 times out of 10, when I hear the comment "I wouldn't learn
NFS, it's insecure, just stick with Samba" it is from someone coming
from the Windows world.

> all designs are equivalent.  They aren't.  Irrelevant how old the design is, 
> except insofar as people are using something old and insecure.

Are you listening to my comments on Kerbosized NFS, NFS v4 user-space
authentication/authorization, and SFS tunneling of RPC/NFS?  No, I guess
not.

> Since you keep talking about mounting stuff, yes, the NFS exports 
> approach probably is the natural way to map a remote filesystem into a 
> Unix VFS, ie, allow a filesystem subtree from some server to be mounted 
> where one likes in the standard filesystem hierarchy on some client.

Correct.  It is the "common denominator" -- something a LPIC-1 should
know.

> Is it the only or the right way?  No.

Of course not.  But we're talking LPIC-1.  When we hit LPIC-2 and
LPIC-3, then we can explore things _built_ on NFS, or _alternatives_ to
it.  But the concepts are _generic_ enough to NFS and applicable to many
others.

My argument on security is that I commonly have to "educate" people on
the serious security issues with CIFS/SMB.  You seem to fail to
recognize that I _was_ talking about NFS from the standpoint of "versus
CIFS/SMB."

> A single namespace (/dfs/psu.edu/myvol) is a much better idea.  It's
> perfectly compatible with the Unix VFS, and used in several distributed
> filesystems on Unix (Linux).

You see, your response is very typical of the problem I was describing.

You wish to overwhelm the LPIC-1 or Linux newbie with concept that open
up a _whole_world_ to new terms -- all surrounding network
authentication, authorization, directory services, namespace and,
finally, the actual network filesystem itself.

In a nutshell, the LPIC-1 candidate and _any_ UNIX/Linux admin _should_
at least know what NFS does, how to export and how to mount.  Just
getting those concepts -- mount is privileged and system-wide, users
access files, RPC calls are made to establish access, etc...  Basic
concepts that can and need to be understood _before_ we start tackling
the security aspects.

> This does not materially resemble NFS.

>From the standpoint of _mounting_ on the _client_, it does very much so.
Of course there are other ways to mount, but we're getting beyond LPIC-1
material and into LPIC-2.

Again, my argument is _against_ that of "NFS is insecure so it shouldn't
be learned/tested."  The concepts are very _common_ to _all_ network
filesystems -- even if additions to or alternatives for NFS are
deployed.

> Most distributed filesystems break other "invariants" of Unix, eg, access
> controls, file locking, memory mapping, etc.  That's true of NFS, too--
> but not the same across filesystems.  There's wide variability there.
> Wide deviation, also, from the subtree export concept, too--some
> distributed filesystems actually have a meaningful notion of what a
> volume is.

Now we're getting more into architectural level.  It's important, I
agree.  I would not only like to see a LPIC-3 exam with this, but I'd
like to see even some infiltration into LPIC-2 as well.

For someone new to NT-based Windows, I don't throw at X.500 at them.
I wait until they can pass 70-210 (2000Pro) or 70-270 (XPPro) and then
bring them up to speed for 70-215/70-218 (2000Server/MCSANetwork) or the
2003 equivalents (which I haven't taught personally).

Same deal with Linux and LPIC-1.  But I am sure to mention that NFS
is 20 years old, and even the latest NFSv4 release is built more for
legacy compatibility than addressing its inherent weaknesses that other
UNIX/Linux network filesystems (alongside authentication, authorization,
directory and other) services do.

> Yes, NFSv2-3 is basic, admins need to know it.

Thank you for agreeing with me.

I don't think you realize we _agree_ far more than we _disagree_.

> But the Unix wisdom that NFS is a security problem is out there
> because NFS security has been a real problem, even on local area
> networks.

Agreed.  And I _do_ address that.

But 9 times out of 10, I'm addressing CIFS/SMB-only pukes -- be it
on a LUG list, teaching a MCSE class, teaching a Linux class, etc...

> You can't wave it away by talking about CIFS

No I can't.  But you _continue_ to want to have an argument with someone
else than myself, but you are surely not recognizing the _context_ I
made my statements under.  Again, for one last time ...

To a person that _only_ knows of CIFS/SMB, that is very much the
_context_ I was referring to!  Again, 9 times out of 10 on a LUG list or
in another support group, it's the common BS I get from someone who
_only_ has CIFS/SMB experience.

As a person who has taught both MCSE and Linux classes (among others),
there is a difference between how CIFS/SMB is _supposed_ to act, and how
it _really_ acts and what simply does _not_ work at all.  In fact, if I
get a "multi-platform guru," the first thing I tell him is to
"de-program himself" from reality, and learn the "marketing" for the
test.

In fact, knowing how to "redirect" common MCSE-like/marketing
assumptions in teaching a Linux class is _crucial_ to not only helping
the student, but assure that Linux is _properly_ understood.  That's
all.  My comments were _not_ aimed towards someone like yourself.
In your case, you are not so "ignorant" and you _know_ that NFS is a
legacy implementation that should be _avoided_ if possible.

But from the standpoint of LPIC-1, the concepts should still be learned.
Especially since they apply towards other, more secure concepts.

> or VPNs.

And I was suggesting this with???  SFS?
SFS is a little different than just a "tunnel" and certainly _not_
comparable to the popular view of what a VPN is.

Which is where NFSv4 comes in.  Not quite perfect, but a heck of a lot
better.

So, can we _agree_ to _agree_ now?  Under my _context_, I was not
incorrect.  And your statements were _outside_ of my context, but I
_do_ agree with them.  I _never_ would disagree.  Please don't make
an argument I not only did not want, but did not prompt.


-- 
Bryan J. Smith                                  b.j.smith at ieee.org 
------------------------------------------------------------------ 
"Communities don't have rights. Only individuals in the community
 have rights. ... That idea of community rights is firmly rooted
 in the 'Communist Manifesto.'" -- Michael Badnarik