NIS 바인딩 문제를 나타내는 증상이 한두 개 클라이언트에서만 발생하는 경우 해당 클라이언트에 문제가 있는 것입니다. 한 클라이언트에 영향을 주는 NIS 문제를 참조하십시오. 많은 NIS 클라이언트가 올바르게 바인딩하지 못하는 경우에는 NIS 서버 중 하나 이상에 문제가 있는 것입니다.
특수 문자열 "check_restricted_shell_name=1"이 포함된 /etc/default/yppasswdd를 만듭니다.
"check_restricted_shell_name=1" 문자열을 주석 처리하면 'r' 확인이 수행되지 않습니다.
네트워크 또는 NIS 서버가 과부하되어 ypserv 데몬이 시간 초과 기간 내에 클라이언트 ypbind 프로세스에 대한 응답을 받지 못할 경우 NIS가 중단될 수 있습니다. 네트워크가 다운된 경우에도 NIS가 중단됩니다.
이러한 경우 네트워크의 모든 클라이언트에서 동일한 문제나 유사한 문제가 발생합니다. 대부분 이 상태는 일시적입니다. NIS 서버가 재부트되고 ypserv를 다시 시작하거나, NIS 서버 또는 네트워크 자체의 로드가 감소하거나, 네트워크가 정상 작동을 계속하면 일반적으로 메시지가 사라집니다.
서버가 작동하고 실행 중인지 확인합니다. 물리적으로 서버 근처에 없는 경우 ping 명령을 사용합니다.
서버가 작동하고 실행 중인 경우 정상적으로 동작하는 클라이언트 시스템을 찾은 다음 ypwhich 명령을 실행합니다. ypwhich가 응답하지 않으면 강제 종료합니다. 그런 다음 NIS 서버에서 root로 로그인하고 다음을 입력하여 NIS 프로세스가 실행 중인지 확인합니다.
# ptree |grep ypbind 100759 /usr/lib/netsvc/yp/ypbind -broadcast 527360 grep yp
ypserv(NIS 서버) 및 ypbind(NIS 클라이언트) 데몬이 둘 다 실행되고 있지 않으면 다음을 입력하여 다시 시작합니다.
# svcadm restart network/nis/client
NIS 서버에서 ypserv 및 ypbind 프로세스가 실행 중이면 ypwhich 명령을 실행합니다. 명령이 응답하지 않으면 ypserv 데몬이 중단된 것이며 다시 시작해야 합니다. 서버에서 root로 로그인하는 동안 다음을 입력하여 NIS 서비스를 다시 시작합니다.
# svcadm restart network/nis/server
NIS는 서버에 맵을 전파하기 때문에 네트워크의 다양한 NIS 서버에 동일한 맵의 여러 버전이 있는 것을 발견할 수 있습니다. 차이가 오랫동안 지속되지 않을 경우 이 버전 불일치는 정상적이며 허용됩니다.
맵 불일치의 가장 일반적인 원인은 정상적인 맵 전파를 방해하는 것이 있는 경우입니다. 예를 들어, 한 NIS 서버나 NIS 서버 간의 라우터가 다운되었습니다. 모든 NIS 서버와 서버 간의 라우터가 실행 중이면 ypxfr이 성공해야 합니다.
서버와 라우터가 제대로 작동 중이면 다음을 확인합니다.
ypxfr 로그 출력을 확인합니다. ypxfr 출력 기록을 참조하십시오.
svc:/network/nis/xfr:default 로그 파일에 오류가 있는지 확인합니다.
제어 파일을 확인합니다. crontab 파일 및 ypxfr 셸 스크립트 확인을 참조하십시오.
마스터 서버의 ypservers 맵을 확인합니다. ypservers 맵 확인을 참조하십시오.
특정 슬레이브 서버에 맵 업데이트 문제가 있는 경우 해당 서버에 로그인한 다음 ypxfr 명령을 대화식으로 실행합니다. 명령이 실패하면 실패한 이유가 표시되고 문제를 해결할 수 있습니다. 명령이 성공하지만 때때로 실패했다고 의심되는 경우 로그 파일을 만들어 메시지 로깅을 사용으로 설정합니다. 로그 파일을 만들려면 슬레이브에서 다음을 입력합니다.
ypslave# cd /var/yp ypslave# touch ypxfr.log
이렇게 하면 ypxfr의 모든 출력을 저장하는 ypxfr.log 파일이 생성됩니다.
이 출력은 ypxfr이 대화식으로 실행될 때 표시하는 출력과 비슷하지만 로그 파일의 각 라인에 시간이 기록되어 있습니다. 시간 기록 방식에 특이한 순서가 표시될 수도 있습니다. 이것은 정상적인 동작입니다. 시간 기록 방식은 ypxfr 실행이 시작된 시간을 알려줍니다. ypxfr의 여러 복사본이 동시에 실행되었지만 소요된 작업 시간이 다른 경우 실제로 호출된 순서와 다른 순서로 로그 파일에 요약 상태 라인을 기록할 수 있습니다. 종종 발생하는 오류의 모든 패턴이 로그에 표시됩니다.
root crontab 파일을 검사하고 이 파일에서 호출되는 ypxfr 셸 스크립트를 확인합니다. 이러한 파일에 맞춤법 오류가 있으면 전파 문제가 발생할 수 있습니다. /var/spool/cron/crontabs/root 파일 내의 셸 스크립트를 참조하지 못하거나 셸 스크립트 내의 맵을 참조하지 못할 경우에도 오류가 발생할 수 있습니다.
또한 NIS 슬레이브 서버가 도메인에 대한 마스터 서버의 ypservers 맵에 나열되는지 확인합니다. 나열되지 않는 경우 슬레이브 서버가 여전히 서버로 작동하지만 yppush에서 맵 변경 사항을 슬레이브 서버로 전파하지 않습니다.
NIS 슬레이브 서버 문제가 명확하지 않은 경우 문제를 디버깅하는 동안 scp 또는 ssh 명령을 통해 정상적인 NIS 서버에서 일치하지 않는 맵의 최근 버전을 복사하여 임시해결책을 수행할 수 있습니다. 다음은 문제 맵을 전송하는 방법을 보여 줍니다.
ypslave# scp ypmaster:/var/yp/mydomain/map.\* /var/yp/mydomain
* 문자는 ypslave에서 로컬로 확장되는 대신 ypmaster에서 확장되도록 명령줄에서 이스케이프되었습니다.
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 프로세스를 나타내는 4개 항목은 다음과 같습니다.
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
여기서 number는 rpcinfo에서 보고된 ID 번호(앞의 예에서는 100004)입니다.