centos rpcbind，centos远程桌面软件

其实centos rpcbind的问题并不复杂，但是又很多的朋友都不太了解centos远程桌面软件，因此呢，今天小编就来为大家分享centos rpcbind的一些知识，希望可以帮助到大家，下面我们一起来看看这个问题的分析吧！

CentOS7搭建NAS文件共享存储

网络存储技术大致可分为三种：网络附加存储（NAS）、存储区域网络（SAN）和直接连接存储（DAS）。NAS设备是局域网中的基于IP的文件共享设备，拥有专用、高性能、高速、单一用途的文件服务和存储系统。它内置操作系统和硬件、软件组件，以满足特定的文件服务需求。NAS在通用服务器基础上优化，具备文件服务、存储、检索、访问客户端文件等功能。

NAS设备需支持多种共享协议，以兼容不同操作系统。如Windows使用CIFS协议，Linux使用NFS协议，FreeBSD使用AFP协议等。NAS设备作为NFS服务器，而Linux、Solaris和AIX作为NFS客户端。

NFS服务包含多个关键组件：nfsd、mountd、lockd和statd。nfsd和mountd是必需的，而lockd和statd则是可选的。每个daemon需要特定端口，但这些端口并非固定分配，系统启动时动态分配端口号给启用的NFS daemon，并通过RPC daemon告知。RPC daemon监听端口111，所有NFS请求先通过此服务获得需要连接的NFS daemon端口号。

NFS连接建立过程类似于交大管浴室老头分发钥匙的过程，客户端（NFS客户机）首先连接RPC daemon获取NFS daemon的端口号，再根据此端口号发送NFS请求。

物理视图与交互视图展示了NFS服务的运行流程。

NFS服务包括portmapper（rpcbind）、nfs、rpc.mountd和rpc.statd（可选）。portmapper响应RPC服务请求，建立连接，一般监听端口111。nfs服务提供核心功能，管理客户端的文件系统挂载信息，并检查登录用户的ID。rpc.mountd管理NFS文件系统，通过读取配置文件/etc/exports判断客户端权限。rpc.statd（可选）用于检查文件一致性。

安装NFS服务器在CentOS系统中涉及安装软件（如nfs-utils、rpcbind）和配置NFS服务。配置文件位于/etc/sysconfig/nfs，确保防火墙开放NFS服务端口。通过/etc/exports文件配置共享目录，初次配置时建议设置最开放的权限（如rw）以方便测试和调试。权限设置需考虑安全性，初次配置NAS时，建议先采用开放权限以避免复杂设置导致的问题。

权限管理在NAS中至关重要，它通过IP地址、客户端操作系统当前用户ID和组ID进行控制。配置文件/etc/exports用于指定访问权限，包括允许访问的IP范围、客户端用户权限等。理解NFS权限机制有助于合理配置，以确保数据安全和访问便捷性。在客户端配置测试时，建议先采用开放权限，后续根据需求调整为更精细的权限控制。

在NFS客户端配置方面，Linux客户端需安装并配置相关服务，Windows客户端则需额外安装或启用相关功能。客户端配置包括挂载NAS共享目录和解挂载等操作。在遇到问题时，如RPC：Port mapper failure– Timed out错误，通常是因为防火墙屏蔽了NFS服务端口，解决方法是调整防火墙规则，允许接收来自NFS服务的上行请求。

总结而言，NFS服务器和客户端配置涉及多个步骤，包括服务安装、权限配置、客户端连接等。合理规划和细致配置可确保NAS文件共享存储系统的高效运行和数据安全。

一次/etc/hosts权限错误导致的es集群错误

先说一下环境：系统使用的CentOS7.5，elasticsearch版本是5.4.0。一套产品集群包括三个elasticsearch节点构成的集群。

部署了两套测试集群，配置基本类似，elasticsearch配置文件中使用主机名。在某一次测试后，一套集群里的elasticsearch就开始报错，无法提供服务。查看日志发现，elasticsearch一直抛出UnknownHostException异常，所以无法和另外两个节点通信连成集群。根据堆栈信息，这个异常是在解析其它elasticsearch节点域名的时候调用InetAddress.getAllByName()抛出的。

而另外一套集群里类似的配置，它的elasticsearch服务却是很正常的。唯一的不同是，出问题的集群临时配置了DNS服务。

按正常的情况来说，elasticsearch解析域名的方式应该是先从/etc/hosts中获取，获取不到了再查询DNS。elasticsearch服务节点的主机名、IP都有在配置在/etc/hosts中。所以，即使一套集群配置了DNS，另外一套没有，也不应该出现elasticsearch无法解析域名的问题。

为了找到域名解析错误的原因，我决定跟踪一下elasticsearch解析域名的过程，使用的工具是strace。strace命令可以追踪进程的系统调用。

安装过程很简单。

接着是修改elasticsearch的执行脚本，一般路径是/usr/share/elasticsearch/bin/elasticsearch。在这个脚本的最后几行，在exec后添加strace命令 strace-o/tmp/es.strace.log-f，如下所示。

-o参数将strace的输出保存到文件/tmp/es.strace.log，-f参数表明追踪进程的所有子进程的系统调用。

两个集群的elasticsearch节点都修改了这个脚本，重启服务后对比查看。对比这个输出文件，终于发现一些端倪。首先，elasticsearch调用的getAllByName()确实首先查看了/etc/hosts文件，但是权限不足无法访问这个文件。

这是有问题的，首先是这个文件应该是可读的，不应该出现权限不足的问题，第二是两个集群都无法访问这个文件，但是为什么一个能解析域名而另外一个不能。

接着往下对比，出问题的elasticsearch进程这时候检查到/etc/resovl.conf文件已经配置，于是向DNS服务器发出了查询。DNS无法解析，于是抛出了UnknownHostException异常。另外一边，没有问题的elasticsearch进程检查到/etc/resovl.conf未配置，这时候做了一个特别的操作，它创建了一个地址族是AF_NETLINK的原始套接字，通过这个套接字查询得到了域名对应的IP地址。我猜测，这可能是访问系统的ARP信息。

既然是DNS的问题，那么把出问题的/etc/resolv.conf中的DNS配置删除呢？重启服务之后，elasticsearch服务依然抛出异常，查看日志发现进程虽然跳过了/etc/resolv.conf，但是它却开始访问了本地的DNS端口53（UDP），可能这是java最后的解析尝试了。恰好，这个节点上部署了rpcbind服务，这个服务恰好就监听了53端口，结果就是依然无法通过DNS解析，java华丽丽的抛出了异常。

问题的根本原因还是/etc/hosts文件不可读，查看这个文件的权限，结果是600，意思就是只能root用户读写了，其它用户没有任何权限，包括读。elasticsearch服务使用的elasticsearch用户，所以当然就会被禁止读取。

经过其它的查找，发现是有一个服务进程会一直更新这个hosts文件，更新的方式是先创建一个临时文件，然后rename成hosts文件，由于临时文件的默认权限是600，所以导致hosts文件的权限最后也是600了。

至此，整个的问题的原因已经清楚。hosts权限的错误，导致elasticsearch通过DNS解析域名，又刚好DNS解析报错，没有通过ARP解析域名。

另外从这个事情中也可以看到java解析域名的套路，先/etc/hosts文件，接着是DNS，先远程的DNS后本地的DNS，最后尝试从本地ARP缓存解析，中间有一个过程抛出异常的时候，解析就会失败。

nfs:server is not responding,still trying的解决办法

系统：centos7.9

nfs版本：nfsstat: 1.3.0

rpcbind版本：rpcbind：0.2.0

查看message日志发现nfs客户连接端报如下错误

问题原因：

Mandag 27 november 2006 20:12 skrev Verner Kjærsgaard:

NFS协议到现在经历了V1、V2、V3、V4四个版本，但是它有一个缺点就是协议没有用户认证机制，而且数据在网络上传送的时候是明文传送，所以安全性极差，一般只能在局域网中使用。

NFSv3是1995年发布的，相比NFSv3，NFSv4发生了比较大的变化，最大的变化是NFSv4有状态了。NFSv2和NFSv3都是无状态协议，服务端不需要维护客户端的状态信息。无状态协议的一个优点在于灾难恢复，当服务器出现问题后，客户端只需要重复发送失败请求就可以了，直到收到服务端的响应信息。但是某些操作必须需要状态，如文件锁。如果客户端申请了文件锁，但是服务端重启了，由于NFSv3无状态，客户端再执行锁操作可能就会出错了。NFSv3需要NLM协助才能实现文件锁功能，但是有的时候两者配合不够协调。NFSv4设计成了一种有状态的协议，自身实现了文件锁功能，就不需要NLM协议了。

后来的 NFSv4.1

与NFSv4.0相比，NFSv4.1最大的变化是支持并行存储了。在以前的协议中，客户端直接与服务器连接，客户端直接将数据传输到服务器中。当客户端数量较少时这种方式没有问题，但是如果大量的客户端要访问数据时，NFS服务器很快就会成为一个瓶颈，抑制了系统的性能。NFSv4.1支持并行存储，服务器由一台元数据服务器(MDS)和多台数据服务器(DS)构成，元数据服务器只管理文件在磁盘中的布局，数据传输在客户端和数据服务器之间直接进行。由于系统中包含多台数据服务器，因此数据可以以并行方式访问，系统吞吐量迅速提升。现在新的是nfsv4.2

所以尽可能用nfs4

补充：

nfs4挂载的fsid问题

问题现象：

挂载nfs4时，报错：reason given by server:No such file or directory

背景知识：

NFSv4将所有共享使用一个虚拟文件系统展示给客户端。伪文件系统根目录(/)使用fsid=0标示，只有一个共享可以是fsid=0。客户端需要使用“nfs server ip:/”挂载伪文件系统，伪文件系统一般使用RO方式共享，其他共享可以通过mount–bind选项在伪文件系统目录下挂载。客户端挂载过程需要通过mount–t nfs4指定NFS版本为4，默认采用nfsv3。

解决：

以下是我的配置文件，我想挂在/datapool/nfs目录

/*(rw,fsid=0,insecure,no_root_squash)

/datapool/nfs*(rw,fsid=1000,insecure,no_root_squash

然后mount-t nfs4 ip:/datapool/nfs/mnt/nfs/

nfs配置参数选项说明：

ro：共享目录只读；

rw：共享目录可读可写；

all_squash：所有访问用户都映射为匿名用户或用户组；

no_all_squash（默认）：访问用户先与本机用户匹配，匹配失败后再映射为匿名用户或用户组；

root_squash（默认）：将来访的root用户映射为匿名用户或用户组；

no_root_squash：来访的root用户保持root帐号权限；

anonuid=<UID>：指定匿名访问用户的本地用户UID，默认为nfsnobody（65534）；

anongid=<GID>：指定匿名访问用户的本地用户组GID，默认为nfsnobody（65534）；

secure（默认）：限制客户端只能从小于1024的tcp/ip端口连接服务器；

insecure：允许客户端从大于1024的tcp/ip端口连接服务器；

sync：将数据同步写入内存缓冲区与磁盘中，效率低，但可以保证数据的一致性；

async：将数据先保存在内存缓冲区中，必要时才写入磁盘；

wdelay（默认）：检查是否有相关的写操作，如果有则将这些写操作一起执行，这样可以提高效率；

no_wdelay：若有写操作则立即执行，应与sync配合使用；

subtree_check（默认）：若输出目录是一个子目录，则nfs服务器将检查其父目录的权限；

no_subtree_check：即使输出目录是一个子目录，nfs服务器也不检查其父目录的权限，这样可以提高效率；

Troubleshooting

1、在上面的操作过程中，如果你不幸遇到下面这个问题的话，可以尝试更新 Linux kernel或通过打开 IPv6来解决这个问题，这是1个 bug：

mount.nfs4: Cannot allocate memory

2、如果遇到如下问题，可能是因为你的 mount-t nfs使用的是 nfsv3协议，需要明确指出使用 nfsv4协议挂载 mount-t nfs4：

mount: mount to NFS server'172.16.20.1' failed: RPC Error: Program not registered.

如果网络不稳定

NFS默认是用UDP协议，换成TCP协议挂载即可：

mount-t nfs 11.11.165.115:/tmp/test0920/data-o proto=tcp-o nolock

nfs:server xxx.xxx.xxx.xxx is not responding,still trying的解决方法

方法1：

我在 arm上通过NFS共享文件时出现下面的错误提示

nfs:server is not responding,still trying原因分析： NFS的默认传输协议是 UDP，而PC机与嵌入式系统通过UPD交互时就会出现严重的网卡丢包现象。

解决方法：在客户端改用TCP协议，使用下面的命令，**#mount-o tcp 10.10.19.25:/home/export/mnt/local

方法2：**在目标板上通过NFS复制PC机上较大文件到目标板上的时候遇到的问题：

nfs: server*** not responding, still trying

修改方法：

nfs mount时候出现的NFS崩溃，按照以下的方式mount

mount-t nfs-o intr,nolock,rsize=1024,wsize=1024 192.168.1.3/root/somedir/client

附问题四：在测试时，“./progressbar-qws”后出现如Q3一样的提示，按Q3来处理。

以上参考了一些“快乐的天空”的经验，他的网页是：

他的

mount-t nfs-o intr,nolock,rsize=1024,wsize=1024 192.168.1.3/root/somedir/host

应该改成

mount-t nfs-o intr,nolock,rsize=1024,wsize=1024 192.168.1.3/root/somedir/client