Summary: That way the NFS procedure won't clash with it.
Reviewed By: genevievehelsel
Differential Revision: D26159845
fbshipit-source-id: 22ce07326f9ec42aa9d44352ae5bb71368337c03
Summary:
For now, this only registers itself against rpcbind and always reply that the
procedure is unavailable. In the future, this will service all the procedures
and forward them to a Dispatcher.
Reviewed By: genevievehelsel
Differential Revision: D26159844
fbshipit-source-id: 21908f1333ed41b3eea3fb5ce19c8e68391df103
Summary:
In the NFS spec, the fhandle3 is defined as an opaque byte array, and thus its
size must preceed its content. Let's also move it to an NfsdRpc.h as this type
will be predominantly used by the Nfsd RPC program.
Reviewed By: chadaustin
Differential Revision: D26152812
fbshipit-source-id: 0cc37325078a2c7b58551eaa5177436b21e03838
Summary:
Now that we have the list of available mount points, we can properly reply to
the MNT RPC call.
Reviewed By: kmancini
Differential Revision: D26152810
fbshipit-source-id: f364292ead321689fb20f858aee45efdfbd7287d
Summary:
For a proper NFS server, rpcbind is used to query and collect the port/protocol
of the mountd and nfs programs at mount time. In EdenFS, the mount.nfs command
will be run by EdenFS directly, against itself, and we can manually specify
what the ports are for both the mountd and nfs programs. Thus we can use these
directly to avoid polluting the rpcbind database, and potentially conflicting
with a real NFS server.
This will be particularly useful when testing EdenFS as this allows multiple
tests to run at the same time.
Reviewed By: kmancini
Differential Revision: D26140416
fbshipit-source-id: 6b8aa22e69f580a9d6f6edf775d268809a909118
Summary:
Once everything is plugged in, EdenFS will first register the mount point with
Mountd, and then execute the mount.nfs CLI against itself to mount the
repository with the OS.
For now, this does the first part by simply informing Mountd of a new mount
point during mount.
Reviewed By: kmancini
Differential Revision: D26139990
fbshipit-source-id: e5097b8e90c032c8c7bdd2cd03b69695074d7874
Summary:
As I'm going through the various NFS specs, it becomes clear that variant are
widely used, and the macros to generate them is awkward and making working with
them harder than it should be. Instead writing their deserialization would be
more flexible.
While doing this, I also revamped how serialization/deserialization is done by
using a trait that contains 2 static function: serialize and deserialize, new
types are expected to specialize the XdrTrait with their own
serialization/deserialization.
Reviewed By: kmancini
Differential Revision: D26160026
fbshipit-source-id: 951bdd20620cc5715e780e99b64e15397688570d
Summary:
In NFSv3, mounting is not part of the NFS program but is done in a separate
program. This adds the basic scaffolding to reply to the NULL procedure for the
mount protocol. Later, this will be enhanced by having `eden mount` first
register a mount point to Mountd, then trigger a `mount.nfs` against localhost
where Mountd will be able to reply properly.
Similarly to PortMapUtil, I've added a small binary that allows for a "mountd"
process to be spawned. Note that since the code doesn't yet answer properly to
the mount procedure, nfusr closes the connection and retries, causing mountd to
crash due to RpcServer being unsafe on error, this will be fixed separately.
Reviewed By: chadaustin
Differential Revision: D26033504
fbshipit-source-id: 27f90d9072a93460a3a383aadde38e50801e3e87
