web-dev-qa-db-ja.com

NISがバインドに失敗する

NISを介して中央サーバーに認証するマシンがたくさんあります。新しいCentOS 6.2クライアントマシンを購入しましたが、認証できません。

以下はクラシックのリストですNISを扱うときに人々が間違ったり忘れたりします:

1)クライアントマシンはサーバーにpingできます(そしてsshで入力できます)

使用してテスト

    ping swordfish 

    ping <ip address>

どちらも適切な応答を生成します

2)ypbindプロセスがクライアントで実行されています

によってテスト

ps -e | grep ypbind
3172 ?        00:00:00 ypbind

/etc/yp.confは正しくフォーマットされ、正しい詳細が含まれています

4)ファイアウォールがオフになっていますですから、問題はないでしょう

5)serviceスターターthinksすべてOK

    /sbin/service ypbind restart

    Shutting down NIS service:                                 [  OK  ]
    Starting NIS service:                                      [  OK  ]
    Binding NIS service:
    .....                                                      [  OK  ]

問題

  • 私が知る限り、RPCバインディングはありません

    /usr/sbin/rpcinfo -p # no ypbind programs
    
  • /var/yp/binding/にはバインディングファイルがありません
  • /var/logs/messagesでメッセージログを表示すると、ypbindサービスを再起動するたびに次のタイプのレポートが生成されます

    Sep  7 14:21:34 localhost ypbind: NIS domain: whaleshark, NIS server:
    

WhalesharkはNISドメインの名前ですが、明らかにNISサーバーに情報がありません。 ypwhichを実行すると、

ypwhich: Can't communicate with ypbind

私がとることができる考えや手順があれば、大歓迎です!

7
Alex

Ha-私は何時間もこれを理解しようとしましたが、NetworkManagerデーモンが実行されていることに気づきました。NetworkManagerを使用しないようにネットワークインターフェイスが設定されている場合、NetworkManagerデーモンは明らかにブロックされています。

単に走る

service NetworkManager stop

そして、再起動するとすべてが修正されました。うまくいけば、これが他の人々の助けになることを願っています。オンラインで似たような症状がたくさん見られましたが、NetworkManagerについて誰も触れていません。

9
Alex

同じ問題に直面しており、networkmanagerを停止しても解決しませんでした。さまざまなトリックを試した後、興味深い回避策を見つけました。私の場合、プロセスdbus-daemonがあり、なんらかの理由でCPUを大量に消費していたため、dbus-daemonプロセスを停止してypbindサービスを再起動するとすぐに動作しました。何も動かない場合は、これを試してみてください。お役に立てば幸いです。

1

Ypbindサービスを開始する前に、次のコマンドを試してください。

authconfig --update --nisdomain=<nis domain name> --nisserver=<nis server name> --enablenis
0
suraj kr