A preliminary understanding of the NFS service under Linux

RPC Introduction

1) The service consumer (client) calls the service through local calling;

2) After receiving the call, the client stub is responsible for assembling methods, parameters, etc. into a message body that can be transmitted over the network;

3) The client stub finds the service address and sends the message to the server;

4) The server stub decodes the message after receiving it;

5) The server stub calls local services based on the decoding results;

6) The local service is executed and the results are returned to the server stub;

7) The server stub packages the return result into a message and sends it to the consumer;

8) The client stub receives the message and decodes it;

9) The service consumer gets the final result.

NFS Introduction

NFS (Network File System) is one of the file systems supported by FreeBSD. It allows computers on the network to share resources through the TCP/IP network. In NFS applications, local NFS client applications can transparently read and write files located on the remote NFS server, just like accessing local files.
Currently, NFS mainly has two versions (NFSv2, NFSv3). In addition to version 3 of NFSv2 and NFSv3, which supports more new features, the main difference should be that NFSv2 uses the UDP protocol for transmission, so the connection of NFSv2 It may not be so reliable in complex network environments, and NFSv3 supports both UDP and TCP protocols.

I just took a look and found that Centos7 already supports the NFSv4 protocol. I won’t post NFSv4 here. Let’s take a look at v4 when you have time.

When the client wants to mount an NFS shared volume, it will send an RPC request to the server, and the NFS server will send a random cookie to the client after user authentication so that the client can use this cookie for authentication. Those shared volumes to be accessed.

NFS authentication supports built-in IP/host permission allocation and is also restricted by tcp wrappers.

NFS service on Redhat

NFS support is enabled by default in the Redhat kernel, and the startup of the NFS server is controlled through the NFS Daemon, which is responsible for binding network sockets and RPC calls. It also requires an rpcbind service (named in redhat5 portmap), if you cannot find the nfs service in the system, it is because the nfs-utils package is not installed. This package provides some tools and service scripts.

The entire NFS service probably includes the following (copied from Red Hat official documentation, but it seems a bit old):

• nfs — Start the corresponding RPC process to respond to NFS
• nfslock — This is an optional service used to respond to client requests for file locking.
• rpcbind(portmap) — This is the daemon process of the rpc service, used to establish connections and respond to rpc requests.

NFS service provides these RPC calls (functions):

• rpc.mountd — This function is used to respond to the client's mount request and verify whether the requested file system is authorized to be used. This process is started by the nfs service.
• rpc.nfsd — The main process (function) of nfs service.
• rpc.lockd — The main call (function) of the nfslock service above is mainly used to respond to the customer’s file locking request.
• rpc.statd - This call (function) is mainly used to notify the client when the nfs server restarts or shuts down abnormally, and is enabled by the nfslock service.
• rpc.rquotad — The nfs service is used to support quota calls (functions).

Configure NFS service

NFS configuration file is in /etc/exports
The default is an empty file. You only need to configure it in the following format, one shared volume per line

host:Limited host (domain name)
1.Single host or IP
2. Wildcard * (matches any character) or ? (matches any single character), used in domain names or host names
3.IP/MASK, for example 192.168.110.0/24

options: Mounting options, used to limit the mounting permissions of the previous host.
Common options:

• ro,rw: read-only or read-write
• sync: Synchronization, when the client's write request is completed, the data in the memory is immediately written to the disk. This is safe.
• async: Asynchronous, when the client's write request is completed, the server does not write the data to the disk immediately, but writes it to the disk at a certain opportunity (idle or... who knows), which causes data loss. possibility.
• wdelay(write delay): Write delay, this is an optimization option that allows the server to delay writing data to disk, so that if the second client write request comes, the two data will be written using one write system call to disk.
• nowdelay: Contrary to the above, only available in sync mode.
• root_squash: "squash" root, because when the client writes files to the server, the uid of the user written by the client is directly mapped to the user with the same uid of the server, so that the root user stores the file on the nfs share volume. On the server side, the owner and group are still root, which has certain security risks, so you can use this option to flatten root into the nfsnobody user.
• all_squash: Squash all users, you can use anonuid=, anongid= to specify which user to squash.

The above is the detailed content of A preliminary understanding of the NFS service under Linux. For more information, please follow other related articles on the PHP Chinese website!