YP(4)

명칭
yp - YP/NIS 시스템의 상세

서식
yp

해설
YP 하부조직을 사용하면(자), passwd, group, netgroup, hosts, services, rpc, bootparams, ethers 의 각 파일의 엔트리 (을)를 다음의 함수를 통해 네트워크 관리할 수가 있습니다: getpwent(3), getgrent(3), getnetgrent(3), gethostent(3), getnetent(3), getrpcent(3), ethers(3) bootparamd(8) demon는, NIS 프로그램 라이브러리를 직접 호출합니다. 왜냐하면, 표준 C 프로그램 라이브러리에서는, bootparams 를 읽어들인다 함수가 존재하지 않기 때문입니다. hosts, services, rpc 의 데이타베이스를 NIS 그리고 서포트로 하려면 , /etc/host.conf 파일의 nis 의 행의 코멘트를 빗나가게 해 주세요. 나머지의 데이타베이스의 NIS 에서의 서포트에 대해서는, 적절한 파일에 특별한 의미를 가지는 '+'엔트리를 더하면(자) 유효하게 됩니다.

YP 하부조직은, /etc/rc.conf 파일중에서 초기화되고 있어, 한편, /var/yp 디렉토리가 존재하고 있으면 (디폴트의 배포물에서는 존재하고 있습니다), /etc/rc 파일중에서 자동적으로 실행됩니다. 디폴트의 NIS 도메인은, domainname(1) 명령로 설정되어 있을 필요가 있습니다. 이것에 대해서도, /etc/rc.conf 파일로 지정되어 있으면, 시스템 기동시에 자동적으로 행해집니다.

NIS 하 RPC 베이스의 클라이언트 서버 시스템이며, NIS 도메인내의 머신이 같은 설정 파일을 공유할 수 있도록(듯이) 하는 시스템입니다. NIS (을)를 사용하는 것으로, 시스템 관리 책임자는 최저한의 설정 데이터만으로 NIS 클라이언트 시스템을 시작할 수가 있어 1 개의 장소로부터 설정 데이터를 추가하거나 지우거나 변경하거나 할 수가 있습니다.

NIS 의 모든 정보의 정당한 카피는 NIS 마스터 서버 (으)로 불리는 1 개의 머신상에 보존됩니다. 정보를 보존하는데 사용되는 데이타베이스는 NIS MAP (으)로 불리고 있습니다. FreeBSD 그럼, 이러한 MAP는 /var/yp/[domainname] 에 보존됩니다. 여기서, [domainname] (은)는, 서비스를 받고 있다 NIS 도메인명입니다. 1 개(살)의 NIS 서버로 한 번에 복수의 도메인을 서포트할 수가 있습니다. 그 때문에, 이러한 이름의 디렉토리가 다수 있다고 하는 일도 있습니다. 서포트되는 도메인 1 개(살)에 대해, 1 개의 디렉토리를 가집니다. 도메인은 각각 독립한 NIS MAP세트를 가지고 있습니다.

FreeBSD 그럼, NIS MAP는 Barkeley DB 해시의 데이타베이스 파일 (이것은, passwd(5) 데이타베이스 파일로 사용되고 있는 포맷과 같은 것입니다) (이)가 되어 있습니다. 다른 operating system로, NIS (을)를 서포트하고 있는 것에서는, 낡은 형식의 nbdm 데이타베이스를 대신에 사용하고 있습니다 (Sun Microsystems 사가 최초로 NIS 의 실장을 ndbm 위에서 실시했던 것(적)이 큰 요인입니다. 다른 vender는, 자신들로 다른 데이타베이스 포맷을 사용해 실장을 실시하지 않고 , 단지 Sun 의 코드의 라이센스를 받았다고 하는 것입니다). 이러한 시스템에서는, 데이타베이스는 통상 .dir 파일과 .pag 파일로 나눌 수 있고 있습니다. ndbm 코드는, 이것들 2 개(살)의 파일을 사용해, 해시 데이타베이스의 다른 부분을 보관 유지하게 되어 있습니다. Berkeley DB 해시의 방법에서는, 이 2 개의 부분으로 나누어져 있는 정보를 보관 유지하는데 단일의 파일을 사용합니다. 즉, 다른 operating system에서는, passwd.byname.dir 파일과 passwd.byname.pag 파일이 있는데 대해 (이것들 2 개(살)은 어느쪽이나 같은 MAP의 일부분입니다), FreeBSD 그럼, passwd.byname (이)라는 이름의 파일이 하나만 있습니다. 이 포맷의 차이는, 별로 중요하지는 않습니다. NIS 서버 ypserv(8) 그리고 관련이 있는 툴군만이, NIS MAP의 포맷이 어떻게 되어 있는지를 안다 필요가 있습니다. NIS 클라이언트 시스템에서는, NIS 데이터는 모두 ASCII 형식에서 받습니다.

NIS 시스템에는, 주요한 3 개의 타입이 있습니다.

1.  ~ NIS 클라이언트… 이것은, NIS 서버에 정보의 문의를 합니다.

2.  ~ NIS 마스터 서버… 이것은, NIS MAP의 정당한 카피를 모두 관리하고 있습니다.

3.  ~ NIS 슬레이브 서버… 이것은, NIS MAP의 백업 카피를 관리하고 있습니다. 백업 카피는, 정기적으로 마스터 서버가 갱신하고 있습니다.

NIS 클라이언트는, ypbind(8) demon를 이용해 NIS 서버와 이른바 바인드 (을)를 확립합니다. ypbind(8) (은)는 시스템의 디폴트의 도메인을 체크해 ( domainname(1) 명령로 설정됩니다), RPC 리퀘스트를 로컬 네트워크상에서 브로드캐스트 하기 시작합니다. ypbind(8) 하지만 바인드를 확립하려고 하고 있는 도메인명은, 이러한 리퀘스트가 지정합니다. 리퀘스트가 있던 도메인의 서비스를 실시하도록(듯이) 설정되어 있는 서버가 이 브로드캐스트 메세지를 받으면(자), 이 서버는, ypbind(8) 에 대해서 응답합니다. 그리고, ypbind(8) (은)는 이 서버의 주소를 기록합니다. 만약, 복수의 서버가 사용 가능하다면 (예를 들면, 마스터 서버 1 대와 슬레이브 서버수대라고 하는 것 같은 경우), ypbind(8) (은)는, 제일 최초로 응답해 온 서버의 주소를 사용합니다. 이 시점으로부터, 클라이언트 시스템은 NIS 리퀘스트를 모두 이 서버에 보냅니다. ypbind(8) (은)는 가끔 서버에 "ping" 를 걸어 서버가 아직 오르고 있어, 동작 하고 있는지를 확인합니다. 이 ping 의 응답을 적절한 시간내에 받지 않는 경우는, ypbind(8) (은)는, 바인드되어 있지 않다고 하는 표를 이 도메인 조림, 재차 브로드캐스트를 시작해 다른 서버의 장소를 특정 하려고 합니다.

NIS 마스터 서버 및 슬레이브 서버에서는, NIS 의 리퀘스트는 모두 ypserv(8) demon로 취급합니다. ypserv(8) demon는, NIS 클라이언트로부터 들어 오는 리퀘스트를 받아, 리퀘스트 된 도메인 및 MAP명을 대응하는 데이타베이스 에의 패스로 변환해, 그 데이타베이스로부터 데이타를 뽑기 시작해 클라이언트에 돌려 보낸다고 하는 일을 하고 있습니다. 특별한 리퀘스트세트가 있어, ypserv(8) (은)는 이 세트를 취급할 수 있도록(듯이) 설계되고 있습니다. 그 대부분이 표준 C 프로그램 라이브러리내의 함수로서 실장되고 있습니다.

•   yp_order() 이 함수는, 특정의 MAP의 작성 일시를 조사합니다.

•   yp_master() 이 함수는, 주어진 MAP / 도메인의 NIS 마스터 서버명을 획득합니다.

•   yp_match() 이 함수는, 특정의 MAP / 도메인내의 키로 주어졌다 물건에 대응하는 데이터를 찾아냅니다.

•   yp_first() 이 함수는, 특정의 MAP / 도메인내의 최초의 키와 데이터의 페어를 획득합니다.

•   yp_next() 이 함수는, ypserv(8) 에 특정의 MAP / 도메인내의 키를 건네주어, 이 키의 곧 다음에 어느 키와 데이터의 대를 ypserv(8) 에 돌려 받습니다 (함수 yp_first() (와)과 yp_next() (을)를 이용해, NIS MAP를 차례로 검색할 수 있습니다).

•   yp_all() 이 함수는, MAP의 내용을 모두 꺼냅니다.

이 그 밖에도, ypserv(8) 하지만 취급할 수 있는 리퀘스트는 몇개인가 있습니다 (즉, 특정의 도메인을 취급하는 것이 되어 있는지 어떤지를 응답하는 것 (YPPROC_DOMAIN)나, 도메인을 취급할 수가 있다 때만 응답해, 그렇지 않을 때에는 입다물고 있는 것 (YPPROC_DOMAIN_NONACK) 등입니다). 그러나, 이것들은 보통, ypbind(8) 만이 생성하는 리퀘스트이며, 표준의 유틸리티 그리고 다루어지는 것은 아닙니다.

호스트가 방대하게 어느 네트워크상에서는, 다만 1 대의 마스터 서버를 사용하는 것보다도, 마스터 서버 1 대와 복수의 슬레이브 서버 (을)를 사용하는 편이 좋은 일이 많습니다. 슬레이브 서버는, 마스터 서버와 완전히 같은 정보를 제공합니다. 그러니까, 마스터 서버상의 MAP를 변경할 때는 언제라도 새로운 데이터를 yppush(8) 명령을 사용해 슬레이브 서버에 전파 시키도록(듯이) 해야 합니다. NIS 의 Makefile (/var/yp/Makefile) (을)를 사용하면(자), 이 조작을 자동적으로 실시할 수가 있습니다. 그러기 위해서는, 관리자가 Makefile 파일중의 NOPUSH=true (이)라고 쓰여진 행을 comment out 해 주세요 (NOPUSH 는, 디폴트에서는 true 로 설정되어 있습니다. 디폴트의 설정에서는, NIS 서버가 1 개만의, 작은 네트워크용이 되어 있기 때문입니다). yppush(8) 명령은, 마스터 서버와 슬레이브 서버와의 트랜잭션(transaction)를 개시합니다. 그 사이에, 슬레이브 서버는, 특정의 MAP를 마스터 서버로부터, ypxfr(8) 명령을 이용해 전송 합니다 (슬레이브 서버는, ypserv(8) 내부에서 ypxfr(8) 명령을 자동적으로 호출합니다. 그 때문에, 관리자가 직접 ypxfr(8) 명령을 실행할 필요는 보통 없습니다. 그런데도, 그러한 좋은들 , 손뼉으로 쳐 실행할 수도 있습니다). 슬레이브 서버를 관리하면(자), 큰 네트워크상의 NIS 의 퍼포먼스 향상에 도움이 됩니다. 이유는 다음과 같습니다.

•   NIS 마스터 서버가 크래쉬 했을 경우나 참조할 수 없는 경우에, 백업 서비스를 제공합니다.

•   마스터 서버의 부하가 과도하게 늘어나 버리지 않게, 클라이언트의 부하를 복수의 머신에 분산합니다.

•   1 개(살)의 NIS 도메인을 로컬 네트워크를 넘어 사용할 수 있습니다 ( 서버가 ypbind(8) 의 브로드캐스트의 범위외의 곳에 있었다면, ypbind(8) demon는 서버의 장소를 자동적으로 결정할 수 없었었지요. ypset(8) 명령을 사용해 ypbind(8) demon가 특정의 서버와 바인드를 확립하도록(듯이) 할 수 있습니다만, 이와 같이 하면(자) 불편한 일이 있습니다. 이 문제는, 다만 슬레이브 서버를 로컬 네트워크상에 두는 것만으로 회피할 수 있습니다).

FreeBSD 의 ypserv(8) (은)는, FreeBSD 의 클라이언트 시스템만을 사용했을 경우, (다른 NIS 의 실장보다) 강화되었다 보안를 제공하도록(듯이) 설계되고 있습니다. FreeBSD 의 패스워드 데이타베이스 시스템 (이것은, 4.4BSD (으)로부터 그대로 계승해진 것입니다) 에는, 「그림자 패스워드」 의 서포트가 포함되어 있습니다. 표준적인 패스워드 데이타베이스 에는, 암호화된 유저 패스워드는 포함되어 있지 않습니다. 대신에, 암호화된 패스워드는 (다른 정보와 함께) 슈퍼 유저만이 액세스 가능한 데이타베이스로 나누어 보존되고 있습니다. 암호화된 패스워드가 NIS MAP로서 입수할 수 있다고 하면(자), 이 보안는 전체적으로 기능하지 않게 되겠지요. 왜냐하면, 유저는 누구라도 NIS 의 데이터를 취득할 수 있기 때문입니다.

암호화된 패스워드를 NIS 경유로 취득되지 않게 하기 위한(해), FreeBSD 의 NIS 서버에서는, 특수한 방법으로 그림자 패스워드 MAP (master.passwd.byname (와)과 master.passwd.byuid) (을)를 취급합니다. 서버는, 특권 포트로 생성된 리퀘스트에 대하는 응답을 할 때 마셔, 그림자 패스워드 MAP에 액세스 합니다. 특권 포트에의 접속이 용서되고 있는 것은 root 만일 수 있는이므로, 서버는, 그러한 리퀘스트는 모두 특권 유저 (root)로부터의 것이라고 가정하는 것입니다. 그 외의 포트로부터의 액세스는 모두 거부됩니다. 특권이 없는 포트로부터 리퀘스트를 꺼내도 서버로부터는 에러 코드가 되돌아 올 뿐입니다. 게다가 FreeBSD 의 ypserv(8) (은)는, Wietse Venema 의 tcp 나팔 패키지를 서포트하고 있습니다. tcp 나팔의 서포트를 유효하게 하면(자), 관리자는, ypserv(8) 하지만 한정된 클라이언트 에 대해서만 응답하도록(듯이), 설정 가능합니다.

이러한 기능 강화에 의해, 보통 NIS 보다 뛰어난 보안를 제공할 수 있습니다만, 그런데도 결코 100 퍼센트 효과가 있는 것은 아닙니다. 네트워크에 액세스 할 수 있는 누군가가 서버를 속여 그림자 패스워드 MAP를 개시시키도록(듯이) 하는 것이 그런데도 가능합니다.

클라이언트측에서는, FreeBSD 의 getpwent(3) 함수는 자동적으로 master.passwd MAP를 찾아, 존재하고 있으면(자) 그것을 사용합니다. 만약, MAP가 존재하고 있으면(자), 그것을 사용해, 이것들 특별한 MAP의 전필드 (클래스, 패스워드가 사용되고 있는 기간, 그리고 어카운트의 유효기간) (을)를 디코드합니다. 만약, 존재하고 있지 않으면, 표준의 passwd MAP가 대신에 사용됩니다.

호환성
시스템에 따라서는, 예를 들면 SunOS 4. x 등에서는, 호스트명을 해결하는 함수 ( gethostbyname() (이)나 gethostbyaddr() 등) 하지만 올바르게 작동하기 위해서는 NIS 하지만 동작하고 있을 필요가 있는 것이 있습니다. 이러한 시스템에서는, ypserv(8) demon는, hosts.byname 혹은 hosts.byaddr MAP중에 존재하고 있지 않는 호스트에 관한 정보를 돌려주도록(듯이) 요구되었을 경우에는, DNS (을)를 참조합니다. FreeBSD 의 resolver는, 디폴트로 DNS (을)를 사용합니다 (바란다면, NIS (을)를 사용하도록(듯이)도 할 수 있습니다). 그 때문에, FreeBSD 의 NIS 서버는, DNS (을)를 디폴트에서는 참조하지 않습니다. 그러나, 특별한 플래그를 붙여 ypserv(8) (을)를 기동했을 경우는 DNS (을)를 참조하게 됩니다. 또, v1 서버가 존재하는 것을 강하게 요구하는 것 같은 시스템을 점잖게 시키기 (위해)때문에, ypserv(8) (을)를 NIS v1 서버로서 등록할 수도 있습니다 (FreeBSD (은)는, NIS v2 마셔 사용합니다만, 그 외의 시스템에서는, SunOS 4. x 도 그렇습니다만, 바인드를 확립할 때에, v1 및 v2 의 양쪽 모두의 기능을 가지는 서버를 탐색하는 것이 많습니다). FreeBSD 의 ypserv(8) (은)는, 실은 NIS v1 리퀘스트를 취급하지 않습니다. 그러나, 이 "대처 모드 (kludge mode)" (은)는, v1 및 v2 의 양쪽 모두의 기능을 가지는 서버를 완고하게 탐색하는 시스템을 입다물게 하기에는 편리합니다

(이러한 특수한 기능이나 플래그에 대한 자세한 것은 ypserv(8) 의 메뉴얼 페이지를 참조해 주세요).

버그
FreeBSD 그럼, 현재 NIS 클라이언트에도 서버로도 될 수가 있습니다만, ypupdated(8) 혹은, yp_update() 함수는 서포트되고 있지 않습니다. 이것들에는, 양쪽 모두 안전한 RPC 하지만 필요합니다만, FreeBSD 그럼, 이것에 대해서도 서포트되고 있지 않습니다.

getservent(3) (와)과 getprotoent(3) 함수는, 아직 NIS (을)를 서포트하고 있지 않습니다. 다행스럽게도, 이러한 파일은 그만큼 빈번하게 갱신할 필요가 없습니다.

메뉴얼 페이지를 좀 더 많이 써야 합니다. 특히, ypclnt(3) 에 대해서는 그렇습니다. 당분간은, 수중의 Sun 머신을 찾아, 그것용의 메뉴얼을 읽어 주세요.

Sun 도 이 프로그램의 저자도, 기동시에 ypbind 가 서버를 찾아낼 수 없을 때 에 생기는 문제를 알기 쉽게 취급하는 방법을 생각나지 않았습니다.

역사
YP 하부조직은, Sun 의 실장과 호환성을 갖게하기 위해서(때문에), Theo de Raadt 하지만 최초부터 썼습니다. 버그 수정과 개량 및 NIS 서버의 서포트는, 후에 Bill Paul 하지만 추가했습니다. 서버측의 코드는, 원래, Peter Eriksson (와)과 Tobias Reber 하지만 써, GNU Public License 에 따르고 있습니다. Sun 의 코드는 일절 참조되지 않았습니다.