| 탐색 링크 건너뛰기 | |
| 인쇄 보기 종료 | |
|
Oracle Solaris 11.1에서 이름 지정 및 디렉토리 서비스 작업 Oracle Solaris 11.1 Information Library (한국어) |
| 탐색 링크 건너뛰기 | |
| 인쇄 보기 종료 | |
|
|
Oracle Solaris 11.1에서 이름 지정 및 디렉토리 서비스 작업 Oracle Solaris 11.1 Information Library (한국어) |
4. Oracle Solaris Active Directory 클라이언트 설정(작업)
10. LDAP 이름 지정 서비스에 대한 계획 요구 사항(작업)
11. LDAP 클라이언트를 사용하여 Oracle Directory Server Enterprise Edition 설정(작업)
NIS 바인딩 문제의 일반적인 증상은 다음과 같습니다.
클라이언트의 명령이 백그라운드 모드에서 제대로 작동하지 않거나 정상적인 경우보다 훨씬 느리게 작동함
클라이언트의 명령이 중단됨. 전체 시스템이 정상적으로 표시되고 새 명령을 실행할 수 있는 경우에도 때때로 명령이 중단됩니다.
클라이언트의 명령이 충돌하고 모호한 메시지가 표시되거나 메시지가 표시되지 않음
NIS 바인딩 문제를 나타내는 증상이 한두 개 클라이언트에서만 발생하는 경우 해당 클라이언트에 문제가 있는 것입니다. 많은 NIS 클라이언트가 올바르게 바인딩하지 못하는 경우에는 NIS 서버 중 하나 이상에 문제가 있는 것입니다. 많은 클라이언트에 영향을 주는 NIS 문제를 참조하십시오.
한 클라이언트에 문제가 있지만 동일한 서브넷의 다른 클라이언트는 정상적으로 작동합니다. 문제 클라이언트에서 클라이언트 /etc/passwd 파일에 없는 파일을 비롯하여 많은 사용자가 소유한 파일을 포함하는 /usr 등의 디렉토리에서 ls - l을 실행합니다. 결과 표시에 로컬 /etc/passwd에 없는 파일 소유자가 이름 대신 번호로 표시되는 경우 NIS 서비스가 클라이언트에서 작동하고 있지 않은 것입니다.
이러한 증상은 대체로 ypbind 프로세스가 실행되고 있지 않음을 의미합니다. NIS 클라이언트 서비스가 실행 중인지 확인합니다.
client# svcs \*nis\* STATE STIME FMRI disabled Sep_01 svc:/network/nis/domain:default disabled Sep_01 svc:/network/nis/client:default
서비스가 disabled 상태인 경우 root로 로그인하거나 이에 상응하는 역할을 사용하고 NIS 클라이언트 서비스를 시작합니다.
client# svcadm enable network/nis/domain client# svcadm enable network/nis/client
한 클라이언트에 문제가 있고 다른 클라이언트는 정상적으로 작동 중이지만 ypbind가 문제 클라이언트에서 실행 중입니다. 클라이언트에 잘못 설정된 도메인이 있을 수 있습니다.
클라이언트에서 domainname 명령을 실행하여 설정된 도메인 이름을 확인합니다.
client7# domainname example.com
NIS 마스터 서버의 /var/yp에 있는 실제 도메인 이름과 출력을 비교합니다. 실제 NIS 도메인은 /var/yp 디렉토리에 하위 디렉토리로 표시됩니다.
client7# ls -l /var/yp -rwxr-xr-x 1 root Makefile drwxr-xr-x 2 root binding drwx------ 2 root example.com
시스템에서 domainname을 실행하여 반환된 도메인 이름이 /var/yp에 디렉토리로 나열된 서버 도메인 이름과 다른 경우 시스템의 /etc/defaultdomain 파일에 지정된 도메인 이름이 잘못된 것입니다. 시스템의 NIS 도메인 이름을 설정하는 방법에 표시된 대로 NIS 도메인 이름을 재설정합니다.
주 - NIS 도메인 이름은 대소문자를 구분합니다.
도메인 이름이 올바르게 설정되었으며 ypbind가 실행 중인데 명령이 중단되는 경우 ypwhich 명령을 실행하여 클라이언트가 서버에 바인딩되어 있는지 확인합니다. 방금 ypbind를 시작한 경우 ypwhich를 여러 번 실행합니다. 일반적으로 첫번째 시도에서는 도메인이 바인딩되어 있지 않다고 보고하고 두번째 시도는 정상적으로 성공합니다.
도메인 이름이 올바르게 설정되었으며 ypbind가 실행 중인데 클라이언트에서 서버와 통신할 수 없다는 메시지가 표시되는 경우 다음과 같은 다양한 문제를 나타낼 수 있습니다.
클라이언트에 바인딩할 서버 목록을 포함하는 /var/yp/binding/domainname /ypservers 파일이 있습니까? 없는 경우 ypinit -c를 실행하고 이 클라이언트에서 바인딩해야 하는 서버를 원하는 순서대로 지정합니다.
클라이언트에 /var/yp/binding/ domainname/ypservers 파일이 있는 경우 한두 개의 서버가 사용할 수 없게 되어도 충분한 서버가 나열되어 있습니까? 충분한 서버가 나열되어 있지 않으면 ypinit -c를 실행하여 목록에 서버를 더 추가합니다.
선택한 NIS 서버에 대한 항목이 /etc/inet/hosts 파일에 있습니까? 선택한 NIS 서버를 보려면 svcprop -p config/ypservers nis/domain 명령을 사용합니다. 이러한 호스트가 로컬 /etc/inet/hosts 파일에 없는 경우 hosts NIS 맵에 서버를 추가하고 NIS 맵 작업에 설명된 대로 ypinit -c 또는 ypinit -s 명령을 실행하여 맵을 재구성합니다.
NIS뿐 아니라 시스템의 로컬 hosts 파일을 검사하도록 이름 서비스 스위치가 설정되었습니까? 스위치에 대한 자세한 내용은 2 장이름 서비스 스위치(개요)를 참조하십시오.
services 및 rpc에 대해 files를 먼저 검사하도록 이름 서비스 스위치가 설정되었습니까? 스위치에 대한 자세한 내용은 2 장이름 서비스 스위치(개요)를 참조하십시오.
동일한 클라이언트에서 ypwhich를 여러 번 사용할 경우 NIS 서버 변경 때문에 결과 표시가 달라집니다. 이것은 정상적인 동작입니다. 네트워크 또는 NIS 서버가 사용 중인 경우 NIS 서버에 대한 NIS 클라이언트 바인딩이 시간에 따라 변경됩니다. 가능한 경우 모든 클라이언트가 NIS 서버로부터 허용되는 응답 시간을 받는 시점에 네트워크가 안정됩니다. 클라이언트 시스템이 NIS 서비스를 얻기만 하면 어디에서 서비스가 제공되는지는 중요하지 않습니다. 예를 들어, 한 NIS 서버 시스템이 네트워크의 다른 NIS 서버에서 NIS 서비스를 얻을 수 있습니다.
로컬 서버 바인딩이 가능하지 않은 극단적인 경우에 ypset 명령을 사용하면 다른 네트워크나 서브넷의 다른 서버(사용 가능한 경우)에 일시적으로 바인딩할 수 있습니다. 그러나 -ypset 옵션을 사용하려면 -ypset 또는 -ypsetme 옵션을 사용하여 ypbind를 시작해야 합니다. 자세한 내용은 ypbind(1M) 매뉴얼 페이지를 참조하십시오.
# /usr/lib/netsvc/yp/ypbind -ypset
다른 방법은 특정 NIS 서버에 바인딩을 참조하십시오.
 | 주의 - 보안을 위해 -ypset 및 -ypsetme 옵션은 사용하지 않는 것이 좋습니다. 제어된 상황에서 디버깅 용도로만 이러한 옵션을 사용합니다. -ypset 및 -ypsetme 옵션을 사용하면 데몬이 실행되는 동안 누구든지 서버 바인딩을 변경할 수 있고 이로 인해 다른 사용자에게 문제가 발생하거나 중요한 데이터에 대한 허용되지 않은 액세스가 허용될 수 있으므로 심각한 보안 위반이 초래될 수 있습니다. 이러한 옵션으로 ypbind 데몬을 시작해야 하는 경우 문제를 해결한 후 ypbind 프로세스를 강제 종료하고 이러한 옵션 없이 다시 시작해야 합니다. ypbind 데몬을 다시 시작하려면 다음과 같이 SMF를 사용합니다. # svcadm enable -r svc:/network/nis/client:default |
ypbind 데몬을 daemon crashes almost immediately each time it is started, look for a problem in the svc:/network/nis/client:default service log. 다음을 입력하여 rpcbind 데몬이 있는지 확인합니다.
% ps -e |grep rpcbind
rpcbind가 없거나, 작동하지 않거나, 이상하게 동작하는 경우 svc:/network/rpc/bind:default 로그 파일을 확인합니다. 자세한 내용은 rpcbind(1M) 및 rpcinfo(1M) 매뉴얼 페이지를 참조하십시오.
정상적으로 작동하는 시스템에서 문제 클라이언트의 rpcbind와 통신할 수도 있습니다. 작동하는 시스템에서 다음을 입력합니다.
% rpcinfo client
문제 시스템의 rpcbind가 정상인 경우 rpcinfo에서 다음 출력을 생성합니다.
program version netid address service owner
...
100007 3 udp6 ::.191.161 ypbind 1
100007 3 tcp6 ::.135.200 ypbind 1
100007 3 udp 0.0.0.0.240.221 ypbind 1
100007 2 udp 0.0.0.0.240.221 ypbind 1
100007 1 udp 0.0.0.0.240.221 ypbind 1
100007 3 tcp 0.0.0.0.250.107 ypbind 1
100007 2 tcp 0.0.0.0.250.107 ypbind 1
100007 1 tcp 0.0.0.0.250.107 ypbind 1
100007 3 ticlts 2\000\000\000 ypbind 1
100007 2 ticlts 2\000\000\000 ypbind 1
100007 3 ticotsord 9\000\000\000 ypbind 1
100007 2 ticotsord 9\000\000\000 ypbind 1
100007 3 ticots @\000\000\000 ypbind 1
...
시스템에 다른 주소가 지정됩니다. 주소가 표시되지 않는 경우 ypbind에서 서비스를 등록할 수 없습니다. 시스템을 재부트하고 rpcinfo를 다시 실행합니다. ypbind 프로세스가 있고 NIS 서비스를 다시 시작할 때마다 변경되면 rpcbind 데몬이 실행 중인 경우에도 시스템을 재부트합니다.
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)입니다.
|