在 Oracle® Solaris 11.2 中排除网络管理问题

退出打印视图

更新时间: 2014 年 7 月
 
 

排除影响多个客户机的 NIS 问题

如果只有一两台客户机出现了表明 NIS 绑定问题的症状,则可能是这些客户机存在问题。请参见排除影响单个客户机的 NIS 问题。但是,如果多个 NIS 客户机都无法正确绑定,则很可能是一台或多台 NIS 服务器存在问题。

    以下是可能影响多个客户机的常见 NIS 问题:

  • rpc.yppasswdd 将以 r 开头的非受限 Shell 视为受限制

    要解决此问题,请执行以下操作:

    1. 创建包含以下特殊字符串的 /etc/default/yppasswdd"check_restricted_shell_name=1"

    2. 如果将 "check_restricted_shell_name=1" 字符串注释掉,将不会进行 r 检查。

  • 网络或服务器不可访问

    如果网络或 NIS 服务器过载,导致 ypserv 守护进程无法在超时时间段内接收来自客户机 ypbind 进程的响应,则 NIS 将挂起。如果网络发生故障,NIS 也可能会挂起。

    在这两种情况下,网络中的每台客户机都会遇到相同或相似的问题。在大多数情况下,这种问题是暂时的。在重新引导 NIS 服务器并重新启动 ypserv 守护进程时,NIS 服务器或网络自身的负载降低时,或者当网络恢复正常运行时,这些消息通常会消失。

  • 服务器运转异常

    确保服务器已启动并且正在运行。如果您无法实际接近服务器,请使用 ping 命令来确定服务器是否可访问。

  • NIS 守护进程未运行

    如果服务器已启动并且正在运行,请尝试找一台能够正常工作的客户机,然后在其上运行 ypwhich 命令。如果 ypwhich 命令不响应,请将其中止。然后,成为 NIS 服务器上的 root 角色,并检查 NIS 进程是否正在运行,如下所示:

    # ptree |grep ypbind
    100759 /usr/lib/netsvc/yp/ypbind -broadcast
    527360 grep yp

    如果 ypserv 守护进程(NIS 服务器)和 ypbind 守护进程(NIS 客户机)都没有在运行,请通过以下命令重新启动它们:

    重新启动 NIS 客户机服务,如下所示:

    # svcadm restart network/nis/client

    如果 ypservypbind 进程都在 NIS 服务器上运行,请运行 ypwhich 命令。如果该命令没有响应,则表明 ypserv 守护进程可能已挂起并应当重新启动。

    在服务器上,重新启动 NIS 服务,如下所示:

    # svcadm restart network/nis/server
  • 服务器的 NIS 映射版本不同

    因为 NIS 在服务器之间传播映射,所以有时您可能会在网络中的不同 NIS 服务器上找到同一个映射的不同版本。如果差别持续的时间不长,则此版本差异正常并且可以接受。

    导致映射差异最常见的原因是正常的映射传播被阻止。例如,NIS 服务器或 NIS 服务器之间的路由器关闭。当所有 NIS 服务器以及它们之间的路由器都在运行时,ypxfr 命令应该能成功运行。

      如果服务器和路由器运行正常,请按以下方式操作:

    • 检查 ypxfr 日志输出:请参见Example 3–1

    • 检查 svc:/network/nis/xfr:default 日志文件以查找错误。

    • 检查控制文件(crontab 文件和 yupxfr shell 脚本)。

    • 检查主服务器上的 ypservers 映射。

  • ypserv 进程崩溃

    如果 ypserv 进程几乎总是在启动后的瞬间崩溃,并且即使重复启动也无法持续运行,则基本上可按照 ypbind 崩溃时所进行的调试过程进行调试。

    首先,运行以下命令来查看是否会报告任何错误:

    # svcs -vx nis/server

    如下所示,检查是否存在 rpcbind 守护进程:

    # ptree |grep rpcbind

    如果找不到该守护进程,请重新引导服务器。否则,如果该守护进程正在运行,请运行以下命令查找类似输出:

    # rpcinfo -p ypserver
    program vers     proto  port 	service
    100000	4	    tcp	111	portmapper
    100000	3	    tcp	111	portmapper
    100068	2	    udp  32813	cmsd
    ...
    100007	1	    tcp  34900	ypbind
    100004	2	    udp	731	ypserv
    100004	1	    udp	731	ypserv
    100004	1	    tcp	732	ypserv
    100004	2	    tcp  32772	ypserv

    在之前的示例中,以下四项表示 ypserv 进程:

    100004     2     udp 	731 	ypserv
    100004 	1 	udp 	731 	ypserv
    100004 	1 	tcp 	732 	ypserv
    100004 	2 	tcp   32772 	ypserv

    如果不存在任何项并且 ypserv 无法向 rpcbind 注册其服务,请重新引导此系统。如果这些项存在,请在重新启动 ypserv 之前从 rpcbind 取消注册服务。例如,您可以从 rpcbind 取消注册该服务,如下所示:

    # rpcinfo -d number 1
    # rpcinfo -d number 2

    其中,numberrpcinfo 报告的 ID 号(在以上示例中,ID 号为 100004)。

示例 3-1  记录 ypxfr 命令输出
  • 如果特定从属服务器在更新映射时出现问题,请登录该服务器并以交互方式运行 ypxfr 命令。

    如果该命令失败,则会显示一条消息,指明为何失败,以供您修复问题。如果此命令运行成功,但您怀疑运行有时会失败,请在从属服务器上创建一个日志文件以便记录消息,如下所示:

    ypslave# cd /var/yp
    ypslave# touch ypxfr.log

    该日志文件的输出与以交互方式运行 ypxfr 命令时的输出类似,区别在于日志文件中的每行都带有时间戳。您可能会发现时间戳中排序有异常,这是因为每次实际运行 ypxfr 命令时都会显示该输出。如果 ypxfr 的多个副本同时运行,但所用的时间不同,则各个副本可能是按照不同于命令运行顺序的顺序将摘要状态行写入日志文件。任何形式的间歇性故障都会在日志中显示。


    注 -  解决问题后,请删除日志文件以关闭记录功能。如果忘记删除该文件,它将继续无限制地增大。
  • 检查 crontab 文件和 ypxfr Shell 脚本。

    检查 root crontab 文件,并检查它调用的 ypxfr shell 脚本。这些文件中的排字错误可能会引起传播问题。在 /var/spool/cron/crontabs/root 文件中引用 shell 脚本失败,或者在任何 shell 脚本中引用映射失败,也可能会导致错误。

  • 检查 ypservers 映射。

    另外,请确保 NIS 从属服务器已列在域中主服务器的 ypservers 映射中。否则,从属服务器虽然仍可作为服务器正常运行,但 yppush 不会将映射的更改传播至从属服务器。

  • 在有故障的从属服务器上更新映射。

    如果 NIS 从属服务器问题不明显,则您可以采用以下解决方案来调试问题:使用 scpssh 命令。这些命令从正常运行的 NIS 服务器复制不一致映射的最新版本。

    以下示例显示了如何传送有问题的映射:

    ypslave# scp ypmaster:/var/yp/mydomain/map.\* /var/yp/mydomain

    在上述示例中,命令行中的 * 字符已转义,这样它将在 ypmaster 中展开,而不是在 ypslave 本地展开。