| ||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
D.M.Z
CONTENT
PRE
NEXT
10.1 Getting Acquainted with NIS 당신이 LAN을 운영한다고 할 때, 일반적인 최종 목표는 유저들에게 투명한 네트웍 환경을 제공하는 것이다. 이를 위한 중요한 발판은 유저 계정 정보과 같은 핵심 데이터를 유지하는 일이다. 우리는 이전에, hostname resolution을 위해서 강력하고도 복잡한 DNS서벼스가 존재한다는 것을 본 바 있다. 그 외의 일을을 위한 특정 서비스는 존재하지 않는다. 게다가 당신이 그저 인터넷에 연결되지 않은 소규모 LAN을 운영하려 할 때, DNS는 관리상의 문제를 고려하자면 그리 유용성 있게 보이지 않는다. 이것이 바로 Sun에서 NIS(Network Information System)를 개발한 이유이다. NIS는, passwd와 group파일의 내용과 같은 정보를 당신의 네트웍 상에 있는 모든 호스트에 배포(distribute)하는데 사용하는 일반적인 데이터 베이스 억세스 기능을 제공한다. 이는 모든 호스트에 동일한 계정을 가지게하여 네트웍이 마치 단일 시스템처럼 보이게 한다. 이와 비슷하게, 호스트네임 정보 역시 NIS를 사용하여 /etc/hosts파일에서 네트웍 상의 모든 머신에게 배포할 수 있다. NIS는 RPC를 기반으로 하고, 서버와 클라이언트 측 라이브러리, 그리고 몇가지 관리용 툴로 이루어져 있다. 원래, NIS는 Yellow Pages, 줄여서 YP라고 불리는데, 이는 이 서비스를 비공식적으로 지칭할 때 많이 쓰이는 이름이다. 반면, Yellow Pages는 British Telecom의 트레이드 마크이며, Sun 측에 그 이름을 포기할 것을 요구하고 있다. 뭐 다 그렇듯이, 이미 사람들 입에 붙어버린 YP는 NIS에 연관되 커맨드, 즉 ypserv, ypbind등과 같은 것들의 접두어로 남게되었다. 오를날 NIS는 거의 모든 Unice들에서 사용할 수 있으며, 무료 implementation 마저도 나와 있다. 하느는 BSD Net-2 릴리즈에서 유래한 것으로, Sun이 기증한 Publiv domain reference implementation을 계승한 것이다. 최근에야 NIS 관리용 프로그램이 Swen Thu:mmler에의해 리눅스로 포팅된 것과는 대조적으로, 이 릴리즈의 라이브러리 클라이언트 코드는 오래전부터 GNU libc에 내재되어 있었다. reference implementation에서는 NIS 서버가 제외되어 있었으나, Tobias Reber가 모든 툴과 서버를 지닌 새로운 NIS 패키지를 만들었으며, 이를 yps라 부른다. 현재, Peter Eriksson에 의해 완전히 재 코딩된 NIS 코드는 NYS라 불리며, 보통의 NIS와, Sun이 좀 더 수정을 가한 NIS+를 모두 지원한다. NYS는 NIS 툴셋과 서버를 지원할 뿐 아니라 언젠가는 표준 libc에 내재될 새로운 라이브러리 함수가 추가된 것이다. 이는 현재 hostname resolution을 하기위해 host.conf를 사용하는 구조 대신, 새로운 설정 구조를 지닌다. 이 기능에 대해선 나중에 논의할 것이다. 이 장은 "전통적인" NIS 코드라 말하는, 다른 두 패키지 보다는 NYS에 중점을 둔다. 만약 그 두 패키지 중 하나를 사용하고자 한다면 이 장의 설명은 충분할 수도, 불충분할 수도 있다. 추가적인 정보를 얻기위해선 Hal Stern의 NFS and NIS([Stern92]를 보라)와 같은 NIS에 대한 서적을 참고하라. NYS는 아직 개발 중이며, 네트웍 프로그램이나 login 프로그램같은 표준 리눅스 유틸리티에도 NYS 설정구조가 반영되지 않았다. NYS가 main stream이라할 수 있는 libc에 포함되기 전까지는, 그것을 사용하기위해 이 모든 바이너리들을 재 컴파일 해야한다. 이러한 어플리케이션의 Makefile에, libc앞에 -lnsl을 마지막 옵션으로 linker에 지정하라. 이것은 표준 C 라이브러리대신 NYS 라이브러리인 libnsl에서 적절한 관련함수를 링크시킨다.
10.1 Getting Acquainted with NIS NIS는 key값을 지닌 map 내에 데이터베이스 정보를 보존한다. map은 NIS 서버를 돌리는 서버에 저장되며, 클라이언트는 RPC 콜을 통해 그것을 얻어낸다. map은 DBM 형식의 파일로 저장된다. map 자체는 보통, /etc/hosts나 /etc/passwd 같은 마스터 텍스트 파일에서 생성된다. 몇가지 파일을 위해, 각 search key 타입별로 하나씩, 몇개의 map이 생성된다. 예를 들어, 당신은 호스트네임을 얻기위해서, 그리고 IP 주소를 얻기위해 hosts 파일을 검색할 수 있는 것이다. 따라서 그것에서는 두개의 NIS map, 즉 hosts.byname과 hosts.byaddr이라는 것을 각각 얻어낸다. 표 10.1은 일반적인 map과 그것을 생성하는 파일을 보여준다.
표 10.1 : 몇가지 표준 NIS map과 그에 상응하는 파일 그 외에도 다른 NIS 패키지에서 지원되는 파일과 map을 발견할 수도 있을것이다. 이들엔 이 책에서 논의하지 않는, 가령 BOOTP 서버가 사용하는 bootparams map이나 현재 리눅스에서 지원하지 않는 기능(ethers.byname과 ethers.byaddr같은)의 어플리케이션에 대한 정보를 포함할 수 있다. 몇가지 map에 대해서 사람들은 nickname을 사용하는데, 이들은 대개 짧고 타이핑하기 쉬운 것들이다. NIS 툴에 해석되는 모든 nickname의 목록을 원한다면 다음의 커맨드를 실행하라.
$ ypcat -x
NIS map nickname translation table:
"passwd" -> "passwd.byname"
"group" -> "group.byname"
"networks" -> "networks.byaddr"
"hosts" -> "hosts.byname"
"protocols" -> "protocols.bynumber"
"services" -> "services.byname"
"aliases" -> "mail.aliases"
"ethers" -> "ethers.byname"
"rpc" -> "rpc.bynumber"
"netmasks" -> "netmasks.byaddr"
"publickey" -> "publickey.byname"
"netid" -> "netid.byname"
"passwd.adjunct" -> "passwd.adjunct.byname"
"group.adjunct" -> "group.adjunct.byname"
"timezone" -> "timezone.byname"
NIS 서버는 대대로 ypserv라 불린다. 평균적인 네트웍에서는 보통 하나의 서버만으로 족하나, 보다 큰 규모의 네트웍에서는 다른 머신과 다른 네트웍 세그먼트에서 이들을 돌려, 서버 머신과 라우터의 로드를 경감시킬 수 있다. 이들 서버는 그 중 하나를 마스터 서버로 만들고 그 외의 것들을 슬레이브 서버로 함으로써 동기화된다. map은 마스터 서버의 호스트에서만 만들어지고, 이는 모든 슬레이브에 배분된다. 우리가 항상 "네트웍"이라는 것에 관해 아주 모호하게 얘기한다는 것을 느낄 것이다. 물론 NIS에서, NIS를 통해 시스템 설정의 일부를 공유하는 모든 호스트의 집합을 가리키는, 명료한 개념의 네트웍인 NIS domain도 존재한다. 불행하게도 NIS 도메인은 DNS과는 아무런 관련이 없다. 이 장에서 모호성을 피하기위해, 의미하고자 하는 도메인의 종류를 언제나 정확히 표기할 것이다. NIS 도메인은 오직 순수하게 관리적인 기능만을 가지고 있다. 도메인 내의 패스워드를 공유하는 모든 호스트외에, 그것은 유저에게 있어 전혀 신경쓸 필요가 없는 것이며, NIS 도메인으로 주어진 이름은 오직 관리자에게만 상관있는 것이다. 보통, 당신의 로컬 네트웍에 그와 같은 이름의 NIS 도메인이 존재하지 않는다면 어떤 이름도 사용할 수 있다. 예를 들어, Virtual Brewery의 관리자는, Brewery자신에 대한 brewery, 그리고 Winery에 대한 winery라는 두개의 NIS 도메인을 생성할 수 있다. 통상적으로, DNS 도메인네임을 NIS 도메인 네임으로 단순히 사용하기도 한다. 당신 호스트의 NIS 도메인네임을 설정하거나 표시하려할 때 domainname 커맨드를 사용할 수 있다. 인자를 주지 않고 실행하면 현재 NIS 도메인 네임을 출력한다. 도메인 네임을 지정하기 위해선 수퍼유저가되어 다음을 입력하라.
# domainname brewery
NIS 도메인은 어플리케이션이 query할 NIS 서버를 결정하는 구실을 한다. 예를 들어, Winery에 있는 호스트의 login 유저의 패스워드 정보를 얻기위해 프로그램은 당연히 Winery의 NIS 서버에만(만약 여러개라면, 그중 하나에) query한다. 한편, Brewery 호스트의 어플리케이션은 Brewery의 서버에게만 query한다. 해결해야할 미스터리가 있는데, 즉 클라이언트가 어느 서버에 접속해야하는지를 어떻게 찾아 낼 수 있늘까 하는 것이다. 가장 단순한 시도는 설정파일을 사용하여 어떤 서버를 찾을지를 알려주는 것이다. 그러나 이 방법은 다소 융통성 없는 것으로, 왜냐하면 클라이언트가 서버의 사용가능성에 따라 다른 서버를 (물론 같은 도메인의) 선택하여 사용하는게 허용되지 않기 때문이다. 따라서 전통적인 NIS implementation은 ypbind라는 특수한 데몬에 의존하여 그들 NIS 도메인 내에서 적당한 NIS 서버를 찾는다. 어떠한 NIS query를 하기전에, 어플리케이션은 ypbind로 부터 어떤 서버를 사용할 것인가를 찾는다. ypbind는 로컬 IP 네트웍으로 broadcasting을 하여 서버를 probe한다. 가장 먼저 대답을 해 오는 것이 잠정적으로 가장 빠른 것으로 간주되고, 이후의 모든 NIS query를 그 쪽으로 보낸다. 일정 시간이 지나거나 서버가 다운되면 ypbind는 다시 활성화되어 있는 서버를 probe할 것이다. 동적 바인딩은 필요한 경우가 거의 없으며, 보안상의 문제점까지 안고 있다. 즉 ypbind는 대답을 해오는 것이 누구이든지, 심지어 악의를 가진 침입자의 변변찮은 NIS 서버일지라도 그대로 믿어버린다. 당신이 NIS에 패스워드 데이터베이스를 운영중이라면, 이는 말할 필요도 없이 골치아픈 일이 된다. 이를 막는 방법은 NYS가 ypbind를 디폴트로 사용하지 않게 만들고, 설정파일에서 서버호스트를 꺼내오도록 하는 것이다.
NIS와 NIS+는 그들의 이름이 비슷하듯이, 같은 목표를 추구한다. NIS+는 완전히 다른 방법으로 구조화되어 있다. 상호 연관성이 없는 NIS 도메인의 평면적인 name space대신, 그것은 DNS와 마찬가지로 계층화된 name space를 사용하며, map 대신에 행(row)과 열(column)로 구성된 table이란 것을 사용하며, 각 열은 NIS+ 데이터베이스 내 오브젝트를 나타낸다. 주어진 NIS+ 도메인의 각 테이블은 상위 도메인의 그것으로 구성된다. 게다가 테이블 내의 엔트리는 다른 테이블에대한 링크가 될 수도 있다. 이러한 기능은 정보를 여러가지 방법으로 구조화 할 수 있게 만들어 준다. 전통적인 NIS는 2의 RPC 버전 번호를, NIS+는 버전 3를 사용한다. NIS+는 아직까지 널리 쓰이지 않는 것 같고, 나도 그에관해 잘(뭐, 거의 전부이다) 모른다. 이러한 이유로, 여기서 그것을 다루지 않을 것이다. 만약 그에 관해 배울 의향이 있다면, Sun의 NIS+ administration manual([NISPlus])를 참고하기 바란다.
만약 네트웍 어플리케이션을 쓰거나 포팅하는데 익숙하다면, 위에 나열한 NIS map의 대부분이 C 라이브러리의 라이브러리 함수에 상응한단 것을 눈치챘을 것이다. 예를 들어, passwd 정보를 얻기위해선 보통, getpwnam(3)과 getpwuid(3) 함수를 사용하며, 이들은 각각 주어진 유저네임 또는 유저 id 번호와 연관된 계정 정보를 리턴한다. 일반적인 상황에서 이 함수들은 요청된 검색을 /etc/passwd와 같은 표준 파일에서 수행한다. 그러나, 이 함수의 NIS-aware implementation은 위와는 다른 동작을 할 것이고, RPC 콜을 사용하여 NIS 서버가 유저네임과 id를 검색토록 할 것이다. 이러한 일들은 어플리케이션에 있어 완전히 투명한 것이다. 그 함수는 NIS map을 "추가"하거나 원 파일을 그것으로 "대체"한다. 물론, 이것이 그 파일을 실제 수정한다는 것을 의미하는 것이 아니라, 파일이 대체되거나 추가된 것 처럼 어플리케이션에게 보인다는 것을 뜻한다. 전통적인 NIS implementation의 경우, map이 원 정보에 추가되어 대체되는 것이 어떤 편이성으로 사용되어 왔다. passwd같은 몇가지는, 잘못되었을 경우 passwd 파일을 일부 수정해야 했다. 이는 보안 구멍을 열어 놓는다. (무슨 뜻인지 잘 해석이 안됨 - 역자주) 이러한 함정을 피하기 위해서 NYS는 특정 클라이언트 함수 세트가 원 파일, NIS 또는 NIS+를 어떤 순서대로 사용할 것인지를 결정하는 일반적인 설정체계를 사용한다. 이 장의 뒷부분에서 이에 관해 논의한다.
이론적인 기술상의 잡답은 그만하고, 이제 본격적으로 설정작업을 하는 시간이 돌아왔다. 이 절에서 우리는 NIS 서버의 설정에대해 다룰 것이다. 만약 이미 NIS 서버를 네트웍에 돌리고 있다면, 당신 소유의 서버를 돌려야하지만은 않다. 이러한 경우, 이 절을 건너뛰어도 좋다.
현재 리눅스에서 사용가능한 NIS 서버는 두 가지로, 하나는 Tobias Reber의 yps 패키지에 포함되어 있고, 또 하나는 Peter Eriksson의 ypserv 패키지내에 있다. 현재 libv 내의 NYS를 사용하건, 표준 NIS 클라이언트 코드를 사용하건 간데, 그 중 어느 것을 사용하건 별로 중요한 일이 아니다. 이 글을 쓰는 지금, yps 내의 NIS 슬레이브 서버 핸들링에대한 코드가 좀 더 완벽해 보인다. 그러므로 당신이 슬레이브 서버를 쓰고자 한다면 yps가 좀 더 나은 선택이 아닐까 한다. 서버 프로그램(ypserv)을 /usr/sbin에 설치한 후, 당신의 서버가 배분할 map 파일을 담을 디렉토리를 만들어야 할 것이다. brewery 도메인으로 NIS 도메인을 셋업할 때, map은 /var/yp/brewery 아래에 저장된다. 서버는 map 디렉토리가 존재하는지를 검사하여 그것이 특정 NIS 도메인을 제공하는지의 여부를 결정한다. 만약 어떤 NIS 도메인에대한 서비스를 막아놓는다면, 그 디렉토리를 제거 했는지를 확인하라. map은 보통 빠른 검색을 위해 DBM 파일 형식으로 저장된다. 그것들은 (Tobias 서버의 경우) makedbm이나 (Peter 서버의 경우)dbmload라는 프로그램을 사용하여 마스터 파일로부터 생성되는데, 그 두 프로그램은 서로 호환되지 않는다. 마스터 파일을 dbmload가 파싱할 수 있는 형태로 변형하는 일은 보통 타이핑하거나 기억하기에 약간은 장황한 면이 없지 않은, awk나 sed의 마술로써 이루어진다. 게다가 Peter Eriksson의 ypserv 패키지는 Makefile(ypMakefile라고 하는)을 포함하는데, 이것은 모든 일을 당신 대신에 처리해 준다. 그것을 Makefile 처럼 map 디렉토리에 설치하고, 당신이 배분하고자 하는 map 부분을 수정한다. 파일의 최상단에서, ypserv가 제공하고자 하는 서비스를 나열한 모든 타겟을 볼 수 있을 것이다. 디폴트로 이 라인은 다음과 같다.
all: ethers hosts networks protocols rpc services passwd group netid
가령, ethers.byname과 ethers.byaddr map을 만들고 싶지 않다면 단순히 이 rule에서 ethers 조건을 제거하면 된다. 당신이 설정한 것을 시험해 보기위해, services.* map과 같은 한 두개의 map만으로도 시작할 수 있다. Makefile을 편집한 후, map 디렉토리 내에서 "make"를 입력하라. 이것은 자동으로 map을 생성하고 설치해 준다. 마스터 파일을 변경할 때마다 map을 update하였는지 확인하라. 그렇지 않다면 변경 사항이 네트웍에 어떠한 효력도 미치지 못할 것이다. 다음 절은 어떻게 NIS 클라이언트 코드를 설정하는지를 설명한다. 만일에 당신의 셋업이 제대로 동작하지 않는다면, request가 당신의 서버에 닿는지 아닌지를 찾아내야 한다. 만약 당신이 NYS 서버에 -D 커맨드라인 플래그를 지정해 주었다면, 그것은 들어오는 모든 NIS query와 리턴되는 결과에관한 디버깅 메시지를 콘솔에 출력한다. 이들은 어디서 문제가 발생하는지 힌트를 줄 것이다. Tobias의 서버엔 이러한 옵션이 없다.
10.5 Setting up a NIS Client with NYS 이 장의 나머지 부분에서는 NIS 클라이언트 설정에 관해 다룰 것이다. 첫번째 단계는, 어떤 서버를 NIS 서비스에 사용할 것인지를 NYS에 얘기해 주는 것으로, /etc/yp.conf 설정 파일에 지정해 준다. Winery 네트웍의 호스트에대한 아주 단순한 샘플 파일의 모습은 아래와 같다.
# yp.conf - YP configuration for NYS library
#
domainname winery
server vbardolino
첫번째 선언문은 NIS 클라이언트에게 그것이 winery NIS 도메인에 속해 있다고 말해준다.
만약 이 라인은 빠뜨린다면, NYS는 domainname 커맨드를 통해 당신의 시스템에 지정해 준 도메인 네임을 사용할 것이다.
server 구문은 사용할 NIS 서버를 명시한다. 물론 vbardolino의 IP 주소가 반드시 hosts 파일에 지정되어 있어야 한다.
대신에, 아예 server 구문에 IP 주소 자체를 사용할 수도 있다.
위의 양식에서 server 커맨드는 NYS에게, 현재의 NIS 도메인이 무엇이건 간에 주어진 이름의 서버를 사용하라고 한다. 그러나 만약 당신의 머신이 자주 다른 도메인 사이를 왔다갔다한다면 yp.conf 파일에 여러개의 도메인에대한 정보를 보존하고 싶을 것이다. NIS 도메인 네임을 서버 구문 뒤에 추가함으로써 yp.conf 파일에 여러 NIS 도메인에대한 서버의 정보를 넣을 수 있다. 예를 들어, 위의 예제 파일을 랩탑용으로 바꾼다면 아래와 같을 것이다.
# yp.conf - YP configuration for NYS library
#
server vbardolino winery
server vstout brewery
이것은 단순히 부팅시에 domainname 커맨드를 통해 원하는 NIS 도메인을 지정해 줌으로써, 두 도메인 중의 어떤 것에도 배속시킬 수 있다.
이 기본 설정파일을 만들고 이것이 world-readable한지 확인한 후, 당신의 서버에 연결할 수 있는지 시험삼아 돌려보자. 서버가 배분하는 아무 map이나 골라(가령 hosts.byname같은 것), ypcat 유틸리티를 사용하여 그것을 받아보자. ypcat은 다른 모든 툴과 마찬가지로 /usr/sbin 밑에 있다.
# ypcat host.byname
191.72.2.2 vbeaujolais vbeaujolais.linus.lxnet.org
191.72.2.3 vbardolino vbardolino.linus.lxnet.org
191.72.1.1 vlager vlager.linus.lxnet.org
191.72.2.1 vlgaer vlager.linus.lxnet.org
191.72.1.2 vstout vstout.linus.lxnet.org
191.72.1.3 vale vale.linus.lxnet.org
191.72.2.4 vchianti vchianti.linus.lxnet.org
당신은 위와 비슷한 결과물을 얻을 것이다. 만약 그대신 "Can't bind ot server which serves domain"이나 이와 비슷한 에러를 낸다면, 당신이 지정한 NIS 도메인네임에 맞는 yp.conf에 정의된 서버가 없거나, 몇가지 이유로 서버에 연결할 수 없기 때문이다. 후자의 경우, 그 호스트에 ping하여 긍정적인 결과를 주는지, 그리고 rpcinfo를 사용하여 거기에서 정말로 NIS 서버를 운영하고 있는지를 확인하라. rpcinfo는 다음과 같은 결과를 출력할 것이다.
# rpcinfo -u serverhost ypserv
program 100004 version 2 ready and waitiing
NIS 서버에 연결가능하단 것을 확인하고 나면, 이제 어떤 설정파일을 NIS map으로 대체할 것인지를 결정해야한다. 통상적으로, 호스트와 패스워드 검색을 위해 NIS map을 사용하는데, 전자는 BIND를 돌리지 않는 경우에 유용하고, 후자는 모든 유저들이 NIS 도메인 내의 어떠한 시스템에서건 자신의 계정으로 로그인할 수 있게 만든다. 이것은 흔히 NFS로 모든 호스트간에 /home 디렉토리를 공유하는 것을 요하는데, 자세한 설명은 아래의 10.7 절에서 하고 있다. services.byname과 같은 map은 그런 드라마틱한 성과를 주진 못하나, 당신이 표준 services 파일에 없는 서비스네임을 사용하는 어떤 네트웍 프로그램을 설치하였다면 파일을 에디트하는 수고를 덜어줄 수 있을 것이다. 일반적으로, 로컬 파일을 사용하는 함수를 찾아낼 때, 그리고 그것이 NIS 서버에 query할 때, 당신은 어떤 선택의 자유가 있었으면 할 것이다. NYS는 이 서비스에 억세스하는 함수의 순서를 설정할 수 있게 한다. 이것은 /etc/nsswitch.conf(Name Service Switch의 약어이나 그렇다고 네임 서비스에만 국한되진 않는다)에 의해 조정된다. 어떤 데이터 검색 함수도 NYS에의해 지원되며 그것은 사용할 서비스를 명시하는 라인을 포함한다. 올바른 서비스의 순서는 데이터의 타입에 달려있다. services.byname map이 로컬 services 파일과 다른 엔트리를 지닐 것이라는 생각은 잘못된 것이며, 그것은 단지 약간 더 포괄적일 수 있는 것이다. 그러므로 로컬 파일 먼저 query하고 서비스네임이 발견되지 않을 경우에만 NIS를 체크하는 것이 좋은 선택이다. 반면에 호스트네임 정보는 자주 바뀔 수 있는 것이므로 DNS 또는 NIS 서버에 가장 정확한 내용이 있고, 로컬 hosts 파일은 단지 DNS와 NIS가 실패할 경우에대한 백업으로 보존되는 것이다. 이 경우 로컬 파일을 마지막으로 체크하는 편이 좋다. 아래의 예제는 gethostbyname(2)과 gethostbyaddr(2), 그리고 getservbyname(2) 함수를 어떻게 위에 적은 것같이 설정하는지를 보여준다. 그것들은 나열된 서비스를 차례로 시도하고 검색에 성공하면 결과가 리턴되고, 그렇지 않을 경우 다음 순서의 서비스를 시도한다.
# small sample /etc/nsswitch.conf
#
hosts: nis dns files
services: files nis
다음은 nsswitch.conf 내의 엔트리에 사용될 수 있는 모든 서비스의 목록이다. actual map과 파일, 서버, 그리고 엔트리네임에따라 query되는 object이다.
현재 NYS는 다음의 nsswitch.conf 엔트리를 지원한다: hosts, networks, passwd, group, shadow, gshadow, services, protocols, rpc, ethers이다. 더 많은 엔트리가 추가될 추세이다. 그림 10.1은 nsswitch.conf의 또다른 기능을 소개하는, 좀 더 완전한 형태의 예제이다. hosts 엔트리 내의 [NOTFOUND=return] 키워드는 NIS나 DNS 데이터베이서에서 원하는 아이템을 찾을 수 있는지 없는지를 리턴하라고 NYS에게 말하는 것이다. 즉, NYS는 NIS와 DNS 서버를 어떤 이유로 호출할 수 없을 경우에 한해서만 계속 진행하여 로컬 파일을 검색할 것이다. 그리하여 로컬파일은 부팅시에, 혹은 NIS 서버가 다운되었을 때의 백업으로써만 사용될 것이다.
# /etc/nsswitch.conf
#
hosts: nis dns [NOTFOUND=return] files
networks: nis [NOTFOUND=return] files
services: files nis
protocols: files nis
rpc: files nis
10.7 Using the passwd and group Maps NIS의 주요 응용분야는 NIS 도메인 내의 모든 호스트에 유저와 계정정보를 동기화 시키는 것이다. 이를 위해 보통 작은 로컬 /etc/passwd 파일만을 보존하고, NIS map에서 추가의 site-wide 정보를 얻는다. 그러나 단순히 nsswitch.conf에 이들 서비스에대한 검색을 가능케하는 것만으로는 충분하지 않다. NIS에 의해 배분되는 패스워드에 의존할 때엔, 먼저 당신의 로컬 passwd 파일에 있는 유저의 uid가 NIS의 uid와 일치하는지를 확인해야한다. 이것은 가령 네트웍상의 호스트에서 NFS 볼륨을 마운트할 때와 같은 또 다른 목적에서 유용하다. 만약 /etc/passwd나 /etc/group의 어떤 id 번호가 map의 그것과 다르다면, 그 유저 소유의 모든 파일에대한 소유권을 조절해 주어야만 한다. 먼저 passwd와 group의 모든 uid와 gid를 새로운 값으로 변경하고, 지금 변경된 유저의 모든 파일을 찾아 그것의 소유권을 바꿔준다. 가령 news가 9의 유저 id를, 그리고 okir는 103의 유저 id를 가지고 있었다가 다른 어떤 값으로 변경되었다고 가정해보자. 그리고 다음의 커맨드를 사용한다.
# find / -uid 9 -print >/tmp/uid.9
# find / -uid 103 -print >/tmp/uid.103
# cat /tmp/uid.9 | xargs chown news
# cat /tmp/uid.103 | xargs chown okir
새 passwd 파일을 설치할 때 이 커맨드를 실행하여, 그것들의 소유권을 변경하기전에 모든 파일을 수집하는 것은 중요한 것이다.
파일의 group 소유권을 변경할 때도 이와 비슷한 커맨드를 사용하면 된다.
이 작업을 끝낸 후에는 당신 시스템의 uid와 gid가 NIS 도메인 내의 다른 호스트의 그것에 호응할 것이다. 다음 단계는 nsswitch.conf에 유저와 그룹정보에 대한 NIS 검색을 수행하도록 설정하는 라인을 추가하는 것이다.
# /etc/nsswitch.conf - passwd and group treatment
passwd: nis files
group: nis files
이는 login 커맨드 등이, 유저가 로그인하려할 때 먼저 NIS map에 query하고 그것이 실패했을 경우에 로컬파일을 찾도록 한다. 보통, 로컬 파일에서 대부분의 유저는 지우되, root와, mail 같은 일반적인 계정은 남겨두는 것이 좋다. 이는 어떤 중추적인 시스템 작업이 uid를 유저네임으로, 또는 그 반대로의 map을 요하기 때문이다. 예를 들어, 관리역할을하는 cron job은 잠시동안 news가 되기위해, 혹은 UUCP 서브시스템이 상태보고를 mail로 보낼수 있도록하기위해 su 커맨드를 사용한다. 만약 news나 uucp에대한 엔트리가 passwd 파일에 없다면, 이러한 job은 NIS가 죽어있는동안에는 비참하게 실패할 것이다. 여기엔 두가지 큰 제약이 있는데, 하나는 위에 적힌 것처럼 셋업했을 경우엔 util-linux패키지에 포함되어 있는 것처럼, shadow 패스워드를 사용하지 않는 login suite에서나 동작한다는 것이다. NIS와 shadow 패스워드를 함께 사용하는 골치아픈 일에대해선 아래에서 다룰 것이다. 또 다른 하나는, login 커맨드가 passwd파일에 억세스하기만 하는게 아니라는 점이다 - 사람들 대부분이 항상 사용하는 ls 커맨드를 보자. long listing을 할 때마다 ls는 파일의 소유자인 유저와 그룹에대한 심볼릭 네임을 표시할 것이다. 즉, 그것이 나열하는 uid와 gid마다 한번의 NIS query를 해야한다. 당신의 네트웍사정이 좋지 못하거나, 심할 경우 NIS 서버가 동일한 물리적 네트웍 내에 있지 않아 데이터그램이 라우터를 통해 전해질 경우, 이는 모든 것을 느리게 만들어버린다. 이것이 전부는 아니다. 유저가 자신의 패스워드를 변경하길 원한다고 상상하자. 보통 그는 passwd를 실행시키는데, 이는 새 패스워드를 읽어 로컬 passwd파일을 업데이트 시키지만, 그 파일이 더 이상 로컬 상에서 사용할 수 없은 것으므로 NIS에선 이것이 불가능하다. 그들이 패스워드를 변경하고자 할 때마다 NIS 서버에 로그인 한다는 것 역시 좋은 방법이 아니다. 그리하여 NIS는 passwd의 대체물인 yppasswd라는 것을 제공하며, 이것은 NIS의 존재하에서 유사한 일을 수행한다. 서버 호스트의 패스워드를 변경하기위해서 그것은 RPC를 통해 호스트의 yppasswdd 데몬에 접촉하여 업데이트된 패스워드 정보를 전해준다. 보통, 다음과 같이 프로그램을 교체한다.
# cd /bin
# mv passwd passwd.old
# ln yppasswd passwd
이와 동시에 서버에 rpc.yppasswd를 설치하고, rc.inet2에서 그것을 구동시켜야한다. 이는 NIS에의해 변경된 사실을 사용자가 전혀 눈치챌 수 없도록 만든다.
10.8 Using NIS with Shadow Support 아직 shadow login suite를 사용하는 사이트를 지원하는 NIS는 없다. shadow suite의 저자인 John F. Haugh는 최근에 GNU 라이브러리 GPL의 보호를 받는 shadow 라이브러리 함수를 comp.sources.misc에 릴리즈하였다. 그것은 이미 NIS에 몇가지 지원을 하고 있으나 완전하지는 않으며, 그 파일은 표준 C 라이브러리에 아직 추가되지 않았다. 반면, NIS를 통해 /etc/shadow 파일에서 정보를 얻는다는 일은, shadow suite의 원래 목적과는 희미하게 만든다. NYS 패스워드 검색함수가 shadow.byname map이나 그 비슷한 것을 사용하지 않음에도, NYS는 로컬 /etc/shadow 파일을 투명성있게 사용할 수 있도록 지원해준다. getpwnam의 NYS implementation이 주어진 로그인 네임에 관련된 정보를 검색하라고 호출될 때, nsswitch.conf 내의 passwd 엔트리로 지정된 것이 query된다. nis 서비스는 단순히 NIS 서버의 passwd.byname map 내의 네임을 검색할 것이다. 그러나 files 서비스는 /etc/shadow가 존재하는지 체크하고, 만약 그렇다면 그것을 해석하려고 할 것이다. 만약 없거나, 유저가 root 권한을 갖고 있지 않다면, /etc/passwd내의 유저 정보만을 검색하는 전통적인 행동양식으로 되돌아간다. 그러나 shadow 파일이 존재하고 열 수 있다면, NYS는 shadow에서 유저 패스워드를 골라낸다. getpwuid 함수도 그와같이 실행된다. 이와 비슷하게, NYS에 맞게 컴파일된 바이너리는 로컬에 설치된 shadow suite도 투명성있게 다룰 것이다.
10.9 Using the Traditional NIS Code 만약 현재의 표준 libc에 있는 클라이언트 코드를 사용하고 있다면, NIS를 설정하는게 약간 다르다. 한편으로, 그것은 ypbind 데몬을 사용하여 설정파일에서 이 정보를 걷어들이는 대신, 동작중인 서버에대해 broadcast한다. 그러므로 부팅시에 ypbind를 구동시키는지를 확인해야만 한다. 그것은 반드시 NIS 도메인이 지젓되고 RPC portmapper가 구동된 후에 실행 되어야한다. 서버가 제대로 돌아가는지 검사하는 ypcat의 출력은 위에서 본 적이 있다. 최근에, "clntudp_create: RPC:portmapper failure - RPC: unable to receive"라는 에러를 내고 NIS가 실패하는데 대한 수많은 버그리포트가 있었다. 이는 라이브러리 함수에 바인딩하는 ypbind 통신방법의 비 호환성에서 비롯된 것으로, NIS의 최근 소스를 얻어 그것을 재컴파일하면 이 문제가 해결될 것이다. 전통적인 NIS가 로컬 파일에서의 정보와 NIS 정보를 어떻게 조합하는지를 결정하는 방법은, NYS의 그것과는 차이가 있다. 예를 들어, NIS 패스워드 map를 사용하려면 /etc/passwd map 어딘가에 다음의 라인을 넣어주어야한다.
+:*:-:0:::
이것은 패스워드 검색 함수가 NIS map을 넣을 위치를 표시하는 것으로, 비슷한 라인(마지막 두 콜론은 제외한)을 /etc/group 파일에 넣는 것은 group.* map에대해 같은 일을 한다. NIS를 사용하여 배분되는 hosts.*을 사용하려면, hosts.conf파일의 order 라인을 변경해야한다. 예를 들어, NIS, DNS, /etc/hosts 파일의 순서로 사용하길 바란다면, 다음과 같이 변경해줘야 한다.
order yp bind hosts
전통적인 NIS implementation은 현재 다른 map을 지원하지 않는다.
| ||||||||||||||||||||||||||||||||||||||||
|
Other Chapters
1. Introduction to Networking | ||||||||||||||||||||||||||||||||||||||||
|
Appendix
A. A Null Printer Cable for PLIP | ||||||||||||||||||||||||||||||||||||||||