RPC.YPXFRD(8)

명칭
rpc.ypxfrd - NIS MAP 전송 서버

서식
rpc.ypxfrd [-p path]

해설
rpc.ypxfrd 유틸리티는 NIS 마스터 서버로부터 NIS 슬레이브 서버에의 거대한 NIS MAP의 배포를 고속화하기 위한에 사용됩니다. 통상, MAP의 전송은 몇 개 인가의 순서를 거칩니다:

•   마스터 서버가 yppush(8) (을)를 호출해, 슬레이브 서버가 전송을 개시하도록 지시합니다.

•   슬레이브 서버는, ypxfr(8) (을)를 기동합니다. ypxfr(8) (은)는, 마스터 서버로부터 yp_all()를 사용해 MAP의 내용을 모두 읽습니다.

•   다음에 ypxfr(8) (은)는, db(3) 프로그램 라이브러리를 사용해 서버로부터 받은 데이터를 해시 해 새로운 MAP 데이타베이스 파일을 작성합니다.

•   모든 데이터를 써 끝내고 나서, ypxfr(8) (은)는, 새로운 파일을 옮겨놓아 로컬 머신의 ypserv(8) 앞에 데이타베이스 핸들을 갱신하도록(듯이) YPPROC_CLEAR 를 보냅니다.

거대한 MAP가 포함되어 있는 경우, 이 처리에 몇분 걸리는 일이 있습니다. 예를 들어, 수만의 엔트리가 있는 패스워드 데이타베이스에서는, 수메가바이트 의 디스크를 소비해, db(3) 프로그램 라이브러리가 해시 테이블에 모든 엔트리를 정렬 해 납입하는데 장시간 걸립니다. 게다가 MAP 파일은 2 세트 있습니다: master.passwd.by{name, uid} (와)과 passwd.by{name, uid} 입니다.

rpc.ypxfrd 유틸리티는 NIS 슬레이브 서버가 마스터 서버의 MAP 파일을 카피해, MAP 파일의 구축을 실시하지 않는 것으로, 전송 처리를 고속화해 rpc.ypxfrd (은)는, 단지 RPC 베이스의 파일 전송 프로토콜을 실장하고 있을 뿐입니다. 충분히 고속의 슬레이브 서버가 수메가바이트의 파일로부터 MAP를 구축한다 의에 몇분 걸리는데 싶고, 전송에서는 몇 초 밖에 걸리지 않습니다.

rpc.ypxfrd 유틸리티는, ypserv(8) (와)과 같은 액세스 제한 메카니즘을 사용하고 있습니다. 따라서, securenets(5) 데이타베이스로 용서되고 있는 슬레이브 서버만이 파일을 전송 할 수 있습니다. 게다가 reserved 포트를 사용하는 슬레이브 서버만이, master.passwd MAP를 전송 하는 것이 용서되고 있습니다.

옵션
옵션은 이하와 같습니다:

-p path
    이 옵션에 의해, 디폴트의 NIS 데이타베이스에의 패스를 변경 섬 /var/yp 입니다.

관련 파일
/var/yp/[domainname]/[maps]
    어느 NIS 도메인의 NIS MAP군.

관련 항목
yp(8), yppush(8), ypserv(8), ypxfr(8)

버그
FreeBSD 의 rpc.ypxfrd 프로토콜은 SunOS 로 사용되고 있는 것과 호환성이 없습니다. 이것은 유감인 일입니다만, 피할 수가 없습니다: Sun 의 프로토콜은 자유롭게 입수할 수 있지 않고, 한층 더 입수할 수 있었다고 해도, SunOS NIS v2 의 실장에서는 MAP 데이타베이스에 ndbm 패키지를 사용해 , FreeBSD 의 실장으로 사용되고 있는 Berkeley DB 패키지는 아니기 때문에 불편합니다. 이러한 두 개의 패키지간의 포맷은 매우 차이가 납니다. 게다가 ndbm 는 바이트 오더의 문제가 있어, 빅 endian의 시스템으로 만든 ndbm 데이타베이스는 little endian의 시스템에서는 읽는 것이 성과 선.

저자
Bill Paul <wpaul@ctr.columbia.edu>