Re: [gentoo-user] NFS tutorial for the brain dead sysadmin?

[Alan McKinnon]

On 26/07/2014 04:47, walt wrote:
> In this case, the brain dead sysadmin would be moi :)
>
> For years I've been using NFS to share /usr/portage with all of the
> gentoo machines on my LAN.
>
> Problem:  occasionally it stops working for no apparent reason.
>
> Example:  two days ago I updated two ~amd64 gentoo machines, both of
> which have been mounting /usr/portage as NFS3 shares for at least a
> year with no problems.
>
> One machine worked normally after the update, the other was unable to
> mount /usr/portage because rpc.statd wouldn't start correctly.
>
> After two frustrating days I discovered that I had never enabled the
> rpcbind.service on the "broken" machine.  So I enabled rpcbind, which
> fixed the breakage.
>
> So, why did the "broken" machine work normally for more than a year
> without rpcbind until two days ago?  (I suppose because nfs-utils was
> updated to 1.3.0 ?)
>
> The real problem here is that I have no idea how NFS works, and each
> new version is more complicated because the devs are solving problems
> that I don't understand or even know about.
>
> So, please, what's the best way to learn and understand NFS?


I think you are asking for the impossible :-)

NFS is not easy to set up, and even harder to describe. It is easy to
*use* once it's set up correctly - you just mount something and the only
difference to a local mount is you add an IP address.

NFS uses RPC to do some heavy lifting - I don't know how familiar you
are with this, so here's the quick version:

When you mount something locally, and need to use the mounted
filesystem, kernel calls are used to get at the data. This works easily
as the source disk is local and the kernel can get to it. With NFS, the
source disk is remote and it's the remote kernel that must do the
accessing. RPC is a way to safely ask a remote kernel to do something
and get a result that behaves identical to a local kernel call.
Obviously, this is rather hard to implement correctly.

The original RPC was written by Sun and other newer implementations
exist, like libtirpc - to support useful features like not being stuck
with only UDP. That's what the "ti" means - Transport Independant.

RPC has been in a state of flux for some time and I too have run into
init-script oddities as things change.

In my case, I have nfs-utils-1.3.0, and rc-update configuredd to start
rpc.statd. This works because

depend() {
        ...
        need portmap
        ...
}

and in the init.d file for rpcbind:

depend() {
        ...
        provide portmap
}

So rpcbind starts at boot time and all my nfs mounts JustWork

Looks to me like your problem is actually with rpc and more specifically
with what things are currently named today (which could be different to
yesterday). Unfortunately I don't know of a place where this is all
nicely described in a sane manner except inside the init files themselves.



-- 
Alan McKinnon
alan.mckinnon@×××××.com