NFS Reliability .. Work Arounds.. - NFS

This is a discussion on NFS Reliability .. Work Arounds.. - NFS ; Nick Maclaren wrote: > The only major hole it introduces is Kerberos - and, yes, Kerberos is > a bug/hole/whatever at its design level. I have seen Kerberos cause > transport problems, but it isn't relevant here. Good news is ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 24 of 24

Thread: NFS Reliability .. Work Arounds..

  1. Re: NFS Reliability .. Work Arounds..

    Nick Maclaren wrote:

    > The only major hole it introduces is Kerberos - and, yes, Kerberos is
    > a bug/hole/whatever at its design level. I have seen Kerberos cause
    > transport problems, but it isn't relevant here.


    Good news is that NFSv4 is designed around GSSAPI, Kerberos was chosen
    as an initial mandatory to implement GSSAPI mechanism, because to
    choose nothing would result in no security (aka AUTH_SYS).

    There are some who are contemplating other mechanisms that should
    be suggested or mandated. Feel free to suggest your favorite
    on the NFSv4 WG alias.

    > Not necessarily - that is a common misapprehension with protocols
    > generally. There are serious bugs in TCP that do not occur in UDP
    > (e.g. "stuck connexions"), and NFS needs extra logic to deal with
    > them. Secondly, my belief is that NFS has omitted some of the error
    > recovery logic for TCP (on the grounds that it is not needed), and
    > this means that some failures that would be got trapped by a test
    > for an unrelated failure now cause trouble.


    Yes, you are right. Because NFS does not assume a reliable
    connection, either side is able to unilaterally drop
    the TCP connection and start over without losing state.
    The big mess that creates is the exposure that RPC does
    not contain at-most-once semantics so servers have to do
    tricks to catch replays triggered by connection drops.
    Replays are less likely with TCP than UDP, but UDP can
    get un-stuck quicker.

    The NFSv4.1 work on sessions is an attempt to create a better
    mechanism to deal with the unreliable nature of the
    underlying transports and get at-most-once semantics.
    This would also allow more aggressive connect dropping
    when "stuckness" is detected.

    So, you are right, not yet there but making progress.

    Now RPC over SCTP is an interesting missing piece....

    -David

  2. NFS v4 and security

    In article <43D00812.4090303@sun.com>,
    David Robinson wrote:
    >Nick Maclaren wrote:
    >
    >> The only major hole it introduces is Kerberos - and, yes, Kerberos is
    >> a bug/hole/whatever at its design level. I have seen Kerberos cause
    >> transport problems, but it isn't relevant here.

    >
    >Good news is that NFSv4 is designed around GSSAPI, Kerberos was chosen
    >as an initial mandatory to implement GSSAPI mechanism, because to
    >choose nothing would result in no security (aka AUTH_SYS).
    >
    >There are some who are contemplating other mechanisms that should
    >be suggested or mandated. Feel free to suggest your favorite
    >on the NFSv4 WG alias.


    Oh, God, yet ANOTHER mailing list :-(

    When I looked at GSSAPI, it seemed to me to be totally Kerberized,
    and useless for any other purpose. In particular, I convinced
    myself that it could not support SSH host- and key-based connexions
    (i.e. the ones that do NOT prompt for a phrase or password). And
    it is those that 90% of system administrators want[*].

    However, I have also seen references to it supporting such use, but
    have not had time to investigate how. Please note that this is a
    matter of its DESIGN, not its IMPLEMENTATION. If the very concepts
    of an interface do not support a class of use, it is a common myth
    that it can be hacked to do so. Very often, it can be hacked to
    APPEAR to do so, but only by introducing hidden and serious flaws.
    [*] Specifically:

    1) If a client connects with evidence that it knows the private key
    to which the public one is in /etc/secure_hosts (or whatever), trust
    it as for NFS v3.

    2) If a client connects as user X with evidence that it knows the
    private key to which the public one is in /etc/user_hosts (optionally
    ~X/secure_hosts), trust it as user X.

    Add variations and options to taste.

    Kerberos is an administrative nightmare and provides no advantages
    over the SSH model for 99% of systems. Its claims of scalability
    and security are quite simply bogus. Note that the original abstract
    design was good, but all of the concrete ones have been ghastly.
    This almost certainly indicates the competence of the people involved,
    and the level of supervision of the random research students that
    did most of the work.


    Regards,
    Nick Maclaren,
    University of Cambridge Computing Service,
    New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
    Email: nmm1@cam.ac.uk
    Tel.: +44 1223 334761 Fax: +44 1223 334679

  3. Re: NFS Reliability .. Work Arounds..

    On 18 Jan 2006 21:34:15 -0800, "Mike Eisler"
    wrote:

    >
    >Faeandar wrote:
    >
    >> Well, considering both RedHat and Novell (SuSe) admit that the NFSv3
    >> implementation on their respective Linux' blows goats I would say good
    >> luck.

    >
    >Interesting. Do you have a reference for this?



    Jeezus people, hasn't anyone seen Wayne's World?! The goat reference
    is in that, if you're still interested rent it and see.

    As for references, none from RedHat directly though it was bad enough
    that the company I work for stopped using RedHat altogether. Novell,
    on the other hand, has stated to us that the NFSv3 client on SuSe is
    shaky (they did not say it blows goats, that was a paraphrase). It's
    bad enough even still that our guys have had to hack out more than one
    custom kernel depending on the cluster/app being used.

    ~F

  4. Re: NFS Reliability .. Work Arounds..

    Postmaster wrote:

    (snip)

    > I was more amused by the suggestion of running Solaris x86
    > as being a reasonable idea. Yeah right ! Let's see, Linux
    > runs on a vast set of configurations and hardware, and
    > Solaris runs on what configs ? Before anyone tries that
    > solution be very very sure that you have supported hardware,
    > as stated in the documentation. It won't take you very long to
    > check, as the list is pretty small :-) Out of the 100+ PCs that
    > I have, and the storeroom full of various parts, I was able
    > to assemble 1 (one) that could boot Solaris, and talk
    > over the net. And, even then, it required me to manually
    > pump the NIC.


    The people I know who run it also run Sparc Solaris, and I believe they
    work together pretty well.

    I did once install Solaris-x86 on a machine and mostly it was fine
    except it took me a while to figure out the networking. It turns out
    that a 3C905C is completely different from a 3C905B, fortunately we
    had one of each.

    -- glen


+ Reply to Thread
Page 2 of 2 FirstFirst 1 2