NIS(Network Information Service)는 썬 마이크로시스템즈가 개발했으며, 옐로우 페이지 서비스라고도 알려져 있다. 시스템 동작 방식은 단순하다. /etc/hosts와 /etc/passwd 같은 표준 시스템 데이터베이스를 (약어 의미는 오래전에 사라진 DBM 형식을 사용한) 일반적인 데이터베이스 형식으로 변환한다.
이 데이터베이스는 NIS 서버(NIS 마스터라고도 부른다)에 저장된다. 모든 개별 데이터베이스는 이름을 붙인 도메인에 놓아두며, RPC(Remote Procedure Call) 인터페이스를 사용해 마스터로부터 공유한다. 다음에 제시하는 다양한 파일을 지원한다.
- passwd (지원한다면 /etc/shadow 파일도)
- groups
- hosts
- netmask
- netgroup
- automount
- services
- protocols
- ethers
- (전자편지를 위한) aliases
슬레이브 서버(예를 들어, NIS 마스터 데이터베이스 백업 복사본을 제공하기를 원하는 기계)는 서버에서 공개된 데이터베이스를 복사한다. 사용자가 로그인할 경우 정보를 탐색할 필요가 생기면 NIS 클라이언트는 NIS 서버에 질의를 던진다. NIS 클라이언트는 정보를 절대로 저장하지 않는다. 클라이언트는 (ybind 도구를 사용해) NIS 서버에 묶여있기 때문이다. 이런 결과로 인해 그림 1과 같은 구조가 만들어진다.
그림 1. NIS 마스터와 슬레이브 구조
NIS 데이터베이스에 변경이 일어나면 변경이 일어난 시점에서 슬레이브 서버로 자동으로 전파되며, yppush 명령을 사용해 수동으로 전파할 수도 있다.
사용자가 암호를 변경할 때 사용자가 NIS 데이터베이스에 직접 변경을 가하면 NIS 마스터 서버로 변경 내역이 전해지며, 데이터베이스를 갱신하고 슬레이브 서버에 변경 내역을 전파한다.
NIS+는 NIS 마스터와 슬레이브 컴퓨터 사이에 자료를 교환할 때 인증과 암호화를 지원하는 점에서 NIS와 다르다. 하지만 NIS+는 설정 방식이 상당히 어렵고 복잡하므로, 보안 요구가 있을 경우에만 사용한다. NIS+는 또한 이름 시스템을 확장해 단일 도메인 대신 트리 구조에 놓이도록 만들므로 좀 더 복잡하고 넓은 범위에도 사용자 정보를 배포할 수 있다.
NIS는 일반적으로 제대로 설정된 네트워크 내부에 구축된 표준 환경에서 동작하는 데 문제가 없으며, 동일 네트워크가 인터넷에 물려 있더라도 보안 위협을 받지 않는다. 대학교나 공중망을 통해 NIS 자료가 오가는 여러 사이트를 망라하는 경우를 비롯하여 사설망이 외부로 공개된 환경에서만 NIS+를 사용하자.
솔라리스, AIX®, HP-UX는 기본으로 NIS 시스템을 지원한다. 리눅스(Linux®) 배포판은 종종 NIS를 표준으로 포함하며, glibc 라이브러리도 NIS 지원 기능을 내장한다. 하지만 NIS를 설정하고 관리하기 위해 필요한 툴킷은 별도로 설치할 필요가 있다. 리눅스에서 NIS 서버를 돌리려면 다음 패키지가 필요하다.
-
ypserver -
makedbm
두 패키지를 설치했다면, 일반적으로 /var/yp/Makefile 위치에 설치되는 NIS용 makefile를 편집해야 한다. 이 makefile은 초기 YP 데이터베이스를 빌드하는 데 사용할 환경 설정 매개변수를 포함한다. NIS에서 지원하려는 파일 유형을 포함하려면 all 정의를 편집해야 한다. 기본적으로 이런 규칙은 Listing 1에 열거된 모든 파일을 포함해야 한다.
Listing 1.
all 규칙 정의
all: passwd group hosts ipnodes ethers networks rpc services protocols \
netgroup bootparams aliases publickey netid netmasks c2secure \
timezone auto.master auto.home ageing \
auth.attr exec.attr prof.attr user.attr audit.user
|
원하지 않는 파일은 제거가 가능하다. 예를 들어 passwd, group, hosts 파일만 공유하기를 원할지도 모른다.
이제 데이터베이스를 생성할 차례다. 먼저 NIS 도메인 이름을 설정하자.
$ domainname mcslp.nis |
리눅스 서버에서 지역 네트워크에 맞도록 /var/yp/securenets와 /etc/ypserv.conf 파일을 편집하자. 두 파일은 NIS 도메인 내부에서 정보를 공유하고 접근할 기계를 통제한다.
이제 데이터베이스를 초기화하자.
$ ypinit -m |
ypinit 명령은 makefile을 사용해 원시 파일(예: /etc/passwd)을 NIS 형식으로 변환하는 나머지 작업을 수행한다.
원시 파일 내용을 바꾼 다음에는 항상 /var/yp 디렉터리로 이동해 다시 한번 make 명령을 내려 데이터베이스를 다시 빌드하자.
$ cd /var/yp $ make |
개별 사용자가 원격에서 로그인 암호를 갱신하도록 만들려면 rcp.yppasswdd 데몬을 띄워야 한다. 이 데몬은 클라이언트 요청을 받아서 NIS 데이터베이스를 직접 갱신하므로 마스터와 슬레이브 사이에 변경 사항을 전파해 클라이언트 요청을 제대로 처리하게 된다.
NIS 클라이언트 설정을 위해 NIS 도메인 이름을 정의하고, 지역 NIS 서비스를 시작하고, NIS 마스터나 마스터 슬레이브에서 정보를 찾도록 서비스를 초기화할 필요가 있다. 이 과정에서 핵심은 ypbind인데, 클라이언트 기계를 NIS 서버에 붙이는 작용을 한다.
유닉스 환경에서, ypbind를 호출하면 자동으로 NIS 서버를 결정한다. 대다수 리눅스 버전에서는, /etc/yp.conf 파일에 유효한 NIS 서버 목록을 설정해야 한다. 예는 다음과 같다.
ypserver 192.168.0.22 |
클라이언트를 NIS 서버에 연결하는 기본 과정은 다음과 같다.
-
$ domainname mcslp.nis로 NIS 도메인을 설정한다. -
$/sbin/portmap으로 필요하다면 RPC 매퍼 데몬인portmap을 시작한다. - /var/yp 디렉터리를 생성한다. 이 디렉터리는 몇몇 NIS 정보를 담는 데 사용한다.
-
$ /usr/sbin/ypbind로ypbind를 시작한다.
이제 ypcat을 사용해 직접 데이터베이스에 질의를 던지는 방법으로 NIS 연결이 활성인지를 점검한다. 예를 들어, 이름 순으로 NIS passwd 파일 내용을 보려면 다음과 같은 명령을 내린다.
$ ypcat passwd.byname |
이렇게 하면 전체 passwd 데이터베이스 내용을 출력한다. 실제로 시스템이 NIS 데이터베이스 정보를 사용하려면, 원하는 정보를 찾기 위해 시스템이 사용하는 서비스 종류를 다시 설정해야만 한다.
리눅스와 유닉스 양쪽에서 nsswich.conf 파일은 일반적으로 시스템이 다양한 자료에서 정보를 찾는 위치를 결정하기 위해 사용한다. 예를 들어, 정보 탐색을 위해 nsswitch.conf 파일을 설정해 파일에서 호스트 정보를 찾고, DNS 질의를 던지고, 해당 정보 검색을 위해 NIS 시스템을 사용하도록 만든다.
이 파일은 정보를 찾는 위치를 지정할 뿐만 아니라 다양한 정보원을 대상으로 질의 순서도 정한다. 올바른 순서는 정보를 질의하기 위한 올바른 위치 지정과 장애가 일어났을 경우 대응하는 네트워크 회복력에 영향을 미친다.
파일 형식은 시스템 데이터베이스를 열거한 단순 목록이며, 콜론 이후에 원하는 순서로 서비스 목록을 정의한다. 예를 들어, Listing 2는 NIS, DNS, 지역 파일 순서로 nsswitch.conf 파일을 간단하게 설정한 예다.
Listing 2. 간단한 nsswitch.conf 파일 예
passwd: nis files
shadow: nis files
group: nis files
hosts: nis dns files
networks: nis dns files
|
Listing 2에서 (가능하다면) NIS 데이버테이스를 사용하도록 passwd를 정의한 행을 볼 수 있다. 사용자가 로그인할 때 NIS 테이블을 먼저 참조한다. 사용자 이름을 찾지 못하면 서비스는 오류를 반환하고, 시스템은 목록에서 다음 행(이 경우에는 지역 파일)을 참조한다.
nsswitch.conf 파일을 올바르게 설정하고 활용하는 몇 가지 팁을 정리했다.
- 항상 files를 마지막 옵션으로 지정하자. 특히 passwd, shadow, hosts 자료에 해당하는 팁이다. 파일로 참조하지 않는다면 네트워크 장애가 생길 경우 시스템 전체가 사용 불능인 상태가 되며, NIS 시스템에 문제가 생길 경우 심지어 루트 사용자조차도 로그인을 거부당할 가능성이 있기 때문이다.
- 파일 자료는 중요한 로그인, 호스트, 기타 정보를 포함하도록 주의를 기울이자.
- 인터넷에 연결된 기계에서, NIS를 사용한 포워딩 시스템에 의존하는 대신 인터넷 기반 이름 탐색을 위한 서비스인 DNS를 활용하는 편이 좀 더 효율적이다.
이런 팁을 지키면 시스템이 잠기는 바람에 로그인이 불가능한 상황을 피할 수 있다.
NFS(Network File System) 역시 썬 마이크로시스템즈가 개발했으며, 기계 사이에 파일을 공유하는 방법으로 자리 잡고 있다. NFS로 디렉터리를 공유할 때, 지역 디스크인양 다른 기계의 디렉터리를 마운트할 수 있다. 동일한 보안, 파일 접근 권한, 기타 자료가 NFS 클라이언트와 NFS 서버 사이에 복제된다. 이런 이유 때문에 NIS로 사용자 자료 역시 공유해야 한다. 사용자 ID, 그룹 ID, 다른 정보가 NFS 공유 파일에 똑같이 적용되기 때문이다.
일반적으로 NFS 서버 시작에 앞서 먼저 공유할 디렉터리 설정부터 해야 한다. 리눅스에서, 이런 작업은 /etc/exports 파일을 수정하면 끝난다. /etc/exports 파일은 (보안 제약과 같은) 공유 디렉터리를 위한 디렉터리와 옵션을 정의한다. 예를 들어, 네트워크 내부에 있는 기계에만 /export/data를 공유하도록 하려면, 다음과 같이 지정한다.
/export/data *.mcslp.pri(rw,sync) *(sync) |
rw 옵션은 네트워크에 있는 클라이언트에게 읽기/쓰기 공유 권한을 설정한다. sync 옵션은 원격 마운트가 파일 시스템 자료를 서버와 동기화하도록 만든다.
솔라리스를 사용하면, /etc/dfs/dfstab 파일을 사용해 NFS로 특정 디렉터리를 공유하도록 공유 명령을 지정한다. 모든 네트워크 내부 클라이언트에게 읽기 쓰기 권한으로 동일한 디렉터리를 공유하려면 다음과 같은 명령을 내린다.
share -F nfs -o rw /export/data |
AIX를 사용하면 smit 도구로 특정 디렉터리를 공유하며, HP-UX를 사용하면 SAM 도구로 특정 디렉터리를 공유하자.
운영체제에 무관하게, 일단 파일과 환경 설정이 끝나고 나면, 가장 먼저 NFS 서버를 시작한다.
클라이언트 쪽에서는 NFS 클라이언트 프로세스만 띄우면 된다. 그리고 나서 mount 명령을 사용해 NFS 파일 시스템을 마운트한다. 다음과 같이 서버 이름, 콜론, 원격 디렉터리 전체 경로를 적어주면 된다.
$ mount bear:/export/data /mnt/data |
컴퓨터 시작 과정에서 NFS 디렉터리를 마운트하기 위해 /etc/fstab이나 /etc/vfstab 파일을 통해 NFS 디렉터리를 자동으로 마운트하도록 동일한 형식을 사용할 수 있다. 하지만 더 좋은 방법인 automount 시스템을 사용해 서버에서 성능을 최대로 이끌어내는 동시에 마운트 과정을 단순하게 만들어보자.
NFS 확장 기능으로 automount 시스템을 고려하자. 이 컴포넌트는 참조되는 시점에서 디렉터리를 자동으로 마운트한다. 예를 들어, /mnt/data로 NFS 공유를 자동 설정해 놓으면, 다음과 같이 입력한 순간 /mnt/data와 연결된 NFS 공유가 자동으로 마운트되어 사용이 가능해진다.
$ cd /mnt/data |
계속해서 디렉터리를 사용하지 않으면, 디렉터리는 언마운트된다. automounter는 사용자 디렉토리를 공유할 때 특히 유용한데, 각 사용자가 특정 기계에 로그인하는 시점에 원격 NFS 서버에서 자신의 홈 디렉토리를 마운트해 사용하도록 지원하기 때문이다.
automounter는 NFS 서버에서 원격 디렉토리를 마운트하는 방식을 단순하게 만들 뿐만 아니라 NFS 공유를 활발하게 사용하지 않는 클라이언트에 통계와 접속 유무를 제공하는 데 걸리는 서버 부하를 줄이는 데 기여한다.
여러 유닉스 기계에 automount 기능이 들어있다. 리눅스를 사용하면, 커널에서 automounting을 설정하고 automount 설정과 시작에 앞서 다시 시작해야 한다. automounter를 설정하려면, 먼저 /etc/auto.master나 /etc/autofs/auto.master 파일을 편집해야 한다. 이 파일은 최상위 공유 집합을 정의하고, 사상 파일에 대한 최상위 디렉터리를 지정한다. 예를 들어, 다음 파일은 /home과 /mnt를 사상하는 방법을 보여준다.
/home /etc/autofs/auto.home /mnt /etc/autofs/auto.mnt |
/mnt 디렉터리와 대응하는 사상을 정의한 다음에, 하위 디렉터리와 사상 대상인 NFS 디렉터리를 설정한다. 예를 들어, Listing 3은 mnt 사상을 정의한 내용이다.
Listing 3. mnt 사상을 정의한 내용
applications atuin:/Volumes/Shared1/Applications
archiveprepare atuin:/Volumes/Shared1/ArchivePrepare
backupprepare atuin:/Volumes/Shared1/BackupPrepare
build atuin:/Volumes/Shared1/Build
correspondence atuin:/Volumes/Shared1/Correspondence
devprojects atuin:/Volumes/Shared1/DevProjects
docarchive atuin:/Volumes/Shared1/DocArchive
incoming atuin:/Volumes/Shared1/Incoming
information atuin:/Volumes/Shared1/Information
|
Listing 3에서 보여준 목록은 /mnt 사상이므로, 사용자가 /mnt/applications를 방문할 때 automouner가 사상된 NFS 공유 디렉터리를 마운트하는 명령을 수행한다. 이 경우에는 atuin:/Volumes/Shared1/Applications를 마운트한다.
그리고 나서 유닉스에서 automount 데몬을 시작할 필요가 있다. 대다수 유닉스 기계에서는 automount나 automountd라는 이름이 붙어있는 반면에 대다수 리눅스 기계에서는 autofs라는 이름이 붙어 있고, 다음과 같이 시작한다.
/etc/init.d/autofs start |
NIS와 NIS+를 사용할 때, 서버 사이에 시각을 올바르게 유지하는 편이 바람직하다. NIS나 NIS+에서 시각 동기화가 특히 중요한 이유는 데이터베이스를 최신으로 유지하기 위해 정보 배포 동안에 시각 정보를 사용하기 때문이다. 기계가 동기화되어 있지 않은 상태에서, 슬레이브는 마스터에서 정보를 가져오지 않을지도 모르며, 마스터 쪽에서 갱신을 거부할지도 모른다.
가장 손쉬운 시각 동기화 기법은 NTP(Network Time Protocol)로, 대다수 리눅스 기계에 표준이나 설치 가능한 컴포넌트로 자리잡고 있으며, 유닉스 기계에서도 점차 표준 컴포넌트가 되고 있다.
NTP 관련 패키지를 내려받아 컴파일하거나 독자적으로 패키지를 설치했다면, 핵심 컴포넌트인 ntpd 데몬을 확인할 수 있다. ntpd 데몬은 배경 작업으로 동작하며, 시각 정보를 제공하거나 지정된 서버에서 지역 기계로 시각을 자동으로 맞추도록 설정할 수 있다.
NIS를 사용한다면, NIS 마스터를 내부 네트워크 시각 정보 제공 서버로 설정하자. 내장 시계를 활용하거나 인터넷에 접속했을 경우 여러 공개 서버 중 하나에서 시각 동기화 정보를 얻도록 설정하자. 예를 들어, 우리 ISP는 NTP 서버를 제공한다. /etc/ntp.conf 환경 설정 파일에 다음과 같이 ISP에서 제공하는 NTP 서버 이름을 추가하자.
server ntp0.zen.co.uk minpoll 12 maxpoll 17 |
네트워크에 물린 각 NIS 서버와 클라이언트 쪽에서 시각 동기화가 가능하게 하려면, NIS 마스터와 통신하도록 다음과 같이 동일한 /etc/ntp.conf 파일을 설정하면 끝난다.
server atuin.mcslp.pri minpoll 12 maxpoll 17 |
양쪽 시스템 설정이 끝나면 NIS 마스터에서 NTP 데몬을 다음과 같이 시작하자.
/etc/init.d/ntp start |
그리고 나서 각 NIS 슬레이브 서버와 클라이언트에서도 이 과정을 반복한다.
정보를 주고받고 공유하는 작업은 유닉스와 리눅스 시스템 통합 과정을 좀 더 쉽게 만들어준다. 일단 로그인과 다른 정보를 공유하면, 사용자는 기계마다 암호를 외우지 않고서도 유닉스와 리눅스 기계에 접속해 사용할 수 있다. 로그인과 함께 NFS 공유를 결합하면, 파일 공유가 가능해지며, automounter를 사용해 사용자 개별 홈 디렉터리를 공유하면, 동작 중인 운영체제나 기계에 무관하게 파일 시스템을 통해 각자 파일과 자원을 계속 사용할 수 있다.
교육
- IBM Redbook인 AIX and Linux Interoperability: AIX와 리눅스 사이에 협업이 가능하도록 NIS, NFS, 기타 기법을 설명한다.
-
Using the Network File System in AIX: NFS 시스템에 대한 기본기를 다룬다.
- Solaris Advanced System Administrator's Guide의 일부인 Understanding the automounter: 거의 모든 리눅스와 유닉스 시스템이 지원하는 automount 시스템 설정을 도와준다.
-
Managing NFS and NIS: 광범위한 플랫폼에서 두 가지 핵심 시스템을 활용하기 위한 훌륭한 지침서다.
-
developerWorks 기술 행사와 웹 캐스트를 놓치지 말자.
- 더 많은 정보가 필요하면, developerWorks AIX와 UNIX 영역을 방문해 AIX와 유닉스 관련 소개, 중급, 고급 튜토리얼을 비롯해서 수백 개가 넘는 기사를 읽어보자.
토론
-
developerWorks 블로그를 읽어보고 developerWorks 공동체에 참여하자.
Martin Brown은 8년 넘게 기술 필자로 활약해왔다. Brown은 다양한 주제를 다루는 수 많은 책을 집필했고 기사를 작성했다. Brown은 펄, 파이썬, 자바(Java™), 자바스크립트, 베이직, 파스칼, 모듈라-2, C, C++, 레볼, gawk, 셸 스크립트, 윈도우(Windows®), 솔라리스, 리눅스, BeOS, 맥 OS X을 비롯하여 웹 프로그래밍, 시스템 관리, 통합에 이르리까지 다양한 개발 언어와 플랫폼을 경험했다. Brown은 마이크로소프트(Microsoft®) SME(Subject Matter Expert)이며 ServerWatch.com, LinuxToday.com, IBM developerWorks에 주기적으로 기고한다. Brown은 또한 컴퓨터월드, 애플 블로그, 기타 사이트에 주기적으로 블로그 기사를 올린다. 연락 주소는 Brown이 운영하는 웹 사이트를 참조하기 바란다.