NIS 바인딩 문제를 나타내는 증상이 한두 개 클라이언트에서만 발생하는 경우 해당 클라이언트에 문제가 있는 것입니다. 단일 클라이언트에 영향을 주는 NIS 문제 해결을 참조하십시오. 그러나 여러 NIS 클라이언트가 올바르게 바인딩하지 못하는 경우에는 NIS 서버 중 하나 이상에 문제가 있을 수 있습니다.
다음은 여러 클라이언트에 영향을 줄 수 있는 일반적인 NIS 문제입니다.
rpc.yppasswdd에서 r로 시작하는 제한되지 않는 셸을 제한되는 셸로 간주함
이 문제를 해결하려면 다음을 수행합니다.
특수 문자열 "check_restricted_shell_name=1"이 포함된 /etc/default/yppasswdd 파일을 만듭니다.
"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
NIS 서버에서 ypserv 및 ypbind 프로세스가 실행 중이면 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 셸 스크립트)을 확인합니다.
마스터 서버의 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
앞의 예에서 다음 4개 항목은 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
여기서 number는 rpcinfo에서 보고된 ID 번호(앞의 예에서는 100004)입니다.
특정 슬레이브 서버에서 맵을 업데이트하는 데 문제가 있는 경우 해당 서버에 로그인한 다음 ypxfr 명령을 대화식으로 실행합니다.
명령이 실패하면 실패한 원인에 대한 메시지가 표시되므로 문제를 수정할 수 있습니다. 명령이 성공하지만 때때로 실패했다고 의심되는 경우 다음과 같이 슬레이브 서버에서 로그 파일을 만들어 메시지 로깅을 사용으로 설정합니다.
ypslave# cd /var/yp ypslave# touch ypxfr.log
로그 파일을 출력은 대화식으로 실행하는 ypxfr 명령의 출력과 유사하며, 로그 파일의 각 라인에 시간이 기록된다는 점만 다릅니다. 시간 기록에는 ypxfr 명령이 실제로 실행된 각 시간이 표시되므로 순서가 특이합니다. ypxfr 사본이 동시에 실행되었지만 완료에 걸린 시간이 다른 경우 각 사본이 요약 상태 라인을 로그 파일에 기록하는 순서가 명령이 실행된 시간과 다를 수 있습니다. 종종 발생하는 오류의 모든 패턴이 로그에 표시됩니다.
crontab 파일 및 ypxfr 셸 스크립트를 확인합니다.
root crontab 파일을 검사하고 이 파일에서 호출되는 ypxfr 셸 스크립트를 확인합니다. 이러한 파일에 맞춤법 오류가 있으면 전파 문제가 발생할 수 있습니다. /var/spool/cron/crontabs/root 파일 내의 셸 스크립트를 참조하지 못하거나 셸 스크립트 내의 맵을 참조하지 못할 경우에도 오류가 발생할 수 있습니다.
ypservers 맵을 확인합니다.
또한 NIS 슬레이브 서버가 도메인에 대한 마스터 서버의 ypservers 맵에 나열되는지 확인합니다. 나열되지 않는 경우 슬레이브 서버가 여전히 서버로 작동하지만 yppush에서 맵 변경 사항을 슬레이브 서버로 전파하지 않습니다.
손상된 슬레이브 서버에서 맵을 업데이트합니다.
NIS 슬레이브 서버 문제가 명확하지 않으면 문제를 디버그하는 중에 scp 또는 ssh 명령을 사용하여 임시해결책을 수행할 수 있습니다. 이러한 명령은 일관성 없는 맵의 최신 버전을 정상 NIS 서버에서 복사합니다.
다음 예에서는 문제 맵을 전송하는 방법을 보여줍니다.
ypslave# scp ypmaster:/var/yp/mydomain/map.\* /var/yp/mydomain
앞의 예에서 * 문자는 ypslave에서 로컬로 확장되는 대신 ypmaster에서 확장되도록 명령줄에서 이스케이프되었습니다.