유닉스 네트워크 관리자(5) 시스템 파일의 공유 이번에 소개할 내용은 시스템 파일의 공유에 관한 내용이다. 주로 NIS에
대해 알아볼 것이다. 들어가며 하나의 네트워크에서 어떤 호스트의 IP주소가 바뀌었다고 생각해 보자. 이 경 우 같은
LAN으로 연결된 호스트들의 ‘/etc/hosts’파일을 모두 따로 갱신해 야 한다면 정말 피곤한 일일 것이다. 이와 같이
중복되는 일을 쉽게 관리해 처리하기 위해서는 바로 시스템들을 그룹으로 묶어 공통의 시스템 파일을 관리 하는 것이
필수적이다. 이를 위해서는 두 가지의 접근 방법이 있을 수 있을 것 이다. 첫 번째는 각 시스템의 컨피그 파일에 대한
마스터(master) 복사본을 하나 관 리하면서 어떤 시스템의 컨피그 파일이 변경될 때마다 이 마스터 복사본을 각
그룹의
멤버에게 분배하는 것이다. 이 방법은 간단하며 모든 유닉스 시스템에 서 동작한다는 장점을 가진다. 두 번째 방법으로는
모든 텍스트 파일을 없애고 각각의 시스템이 하나의 중앙 서버로부터 컨피그 파일을 가져다 쓰는 것이다. 이는 첫 번째
방법보다는 매우 복잡하나 반면 여러 문제들을 해결해 준다. 예를 들면 클라이언트가 갱신하지 않는 경우를 막아준다.
사실 어떠한 방법도 모든 면에서 좋은 것일 수는 없다. 그러므로 이제부터는 네트워크에서 파일의 동기화를 유지하는
기술과 가장 널리 사용되는 관리자 데 이터베이스 시스템인 NIS와 NIS+에 대해 이야기 해 나가도록 하겠다. 무엇을
공유해야 하는가 유닉스에서의 모든 컨피그 파일들 중에 일부만이 다른 시스템들과 공유해야할 필요가 있다. 다음 표가
이를 나타낸 것이다. 위의 표에 나온 파일들은 보통 표 준 C 라이브러리에 정의된 루틴을 통해 접근된다. 예를 들면
‘/etc/passwd’ 파일은 getpwuid, getpwnam, getpwent 루틴들을 통해 접근한다. 이 루틴들은 이러한 파일들을
열어서 읽으며 파싱하는 것이다. --------------------------------------------------------------- 파 일
명
기 능 /etc/passwd 사용자 계정 정보 데이터베이스 /etc/group 유닉스 그룹
정의파일 /etc/hosts 호스트 이름과 IP주소간의 매핑 정보 파일 /etc/networks IP 네트워크 번호와 관련된
텍스트 이름들 /etc/services 잘 알려진 네트워크 서비스의 포트 번호 목록 /etc/protocols 텍스트 이름을
프로토콜 번호와 매핑 /etc/ethers 호스트 이름과 이서네트 주소와의 매핑 /etc/aliases 전자 메일
앨리어스(별명) /etc/rpc RPC 서비스에 대한 ID 번호의 리스트 /etc/netgroup 호스트, 사용자,
네트워크의 집합을 정의 --------------------------------------------------------------- 파일의 분배
파일을
분배하는 방법에는 크게 마스터 서버가 주기적으로 클라이언트에게 파 일을 분배하는 push 모델과 지역적으로 파일을
관리하는 pull 모델이 있다. rdist : 파일들 보내기(Push 모델) 대부분의 경우 rdist 명령은 중앙 서버로부터
파일들을
분배하는데 사용되는 가장 좋은 명령이다. make 명령과 유사하게 텍스트 파일로 동작을 지정해서 그대로 수행해
나간다.
특별한 지정이 없는 경우 make 명령이 Makefile을 찾아 수행하는 것처럼 distfile이나 Distfile이라는 이름의
제어파일을 찾아 수행한다. 제어파일의 지정 을 직접하는 경우는 make와 마찬가지로 ‘-f’ 옵션을 주고 파일명을 적어주
면
된다. 제어파일은 #을 주석으로 사용하며 그 형식은 다음과 같다. label 패스명 -> 목적지 명령 label은
제어파일의 특정 명령을 실행하기 위한 것으로 ‘rdist 레이블명’ 하 면 해당 레이블이 지정된 문장만을 수행하게 된다.
패스명은 복사할 파일들의 패스와 이름을 지정하는 것이고 목적지는 파일을 복 사할 목적지에 있는 호스트명의 목록을
지정하면 된다. 만약 여러 개인 경우는 괄호로 묶어주어야 한다. 기본적으로 rdist 명령은 파일들을 목적지 호스트의
같은
위치에 복사를 수행 한다. 이러한 동작을 변경하려는 경우 마지막 필드의 명령 부분에서 조정한다. 모든 명령은 반드시
세미콜론으로 끝나야 하며 다음과 같은 명령어들이 유효하 다. install 옵션 (목적지 디렉터리); notify 네임리스트;
except 패스리스트; except_pat 패턴리스트; special (패스리스트) 스트링; install 명령어는 rdist 명령이
파일을
복사하는 방식에 영향을 주는 옵션을 지 정한다. 이 옵션들은 시스템마다 상당한 차이가 있기에 이 글에서는 자세히 언
급하지는 않겠지만 각자 자신의 시스템 매뉴얼을 참조하는 것이 좋을 것이다. 목적지 디렉터리는 목적지 호스트의
복사할
위치를 지정하는 것이다. notify 명령은 그 인자로 전자 메일 주소의 리스트를 가지는데 rdist 명령은 파 일들을 복사한
후
자동으로 이 메일의 주소를 파일이 업데이트 되었음을 알리 게 된다. 알아둘 점은 일반적으로 메일 주소에서 쓰이는 ‘@’
문자를 사용하 지 않고 사용자의 계정만으로도 지정한다는 점이다. 예를 들면 ‘yjy’라고만 해도 해당 목적지 호스트의
yjy
사용자에게 메일을 전송하는 것이다. except와 except_pat 명령은 복사될 파일들의 목록에서 일부 패스명들을 제거
한다. 이는 상당히 유용하게 쓰일 수 있는데 make와 마찬가지로 rdist 명령도 제어 파일 앞부분에 매크로를 사용할 수
있기에 자주 쓰이는 목록을 매크로로 만들어 놓고 그 중 특정 목록만을 제외시키는 경우 유용하기 때문이다. special
명령은 원격 호스트에서 sh 명령을 수행한다. 만약 패스 리스트가 존재 한다면 rdist 명령은 지정된 파일을 복사한 후에
명령을 수행한다. 다음은 제어 파일의 예를 보인 것이다. SYS_FILES = (/etc/passwd /etc/group /etc/aliases)
GET_ALL = (eshp essdt300 essdt500 esrs) GET_SOME = (esapollo eshost) all: $(SYS_FILES) ->
$(GET_ALL) notify yjy; special /etc/aliases "/usr/ucb/newaliases"; some: $(SYS_FILES) ->
$(GET_SOME) except /etc/aliases; notify leesg@eshost; 위의 예를 설명하자면 세개의 시스템 파일을
호스트 eshp, essdt300, essdt500, esrs로 복사한 후 목적지 호스트의 사용자 yjy에게 메일로 이 사실을 알리게
된다. 그리고 ‘/etc/aliases’ 파일을 복사한 후에 rdist 명령은 목적지 호스트 의 newaliases 명령을 수행한다. 또한
esapollo와 eshost에는 단지 2개의 파일 만을 복사한다. expect : 파일들 가져오기(Pull 모델) Pull 모델을
구현하는
방법은 상당히 다양하다. 그 중 괜찮은 방법이 시스템 파 일들을 중앙 서버의 ftp를 통해 접근 가능하도록 하고 이
파일들을
검색, 설치 하는 expect 명령을 사용하는 것이다. expect는 John Ousterhout의 Tcl(Tool Command Langu age)의
확장된 형태인 데 사용자와 상호 작용하는 프로그램을 위한 제어 스크립트를 쓸 수 있도록 한 다. expect를 만든 이는
NIST의 Don Libes라는 사람이다. expect는 일반 스크립트 언어와는 차이가 있는데 바로 서브프로세스의 순차적 제어를
제공하기 때문이다. 기술적으로 expect 스크립트는 Tcl의 스크립트와 거의 유사하다. Tcl은 문법적으로 간단한데
대부분의 명령어가 셸 명령어처럼 동작한다. 기본적인 expect 명령들은 다음과 같다. (1) spawn - 제어할
서브프로세스를 구동시킨다. (2) send - 서브프로세스로 입력을 준다. (3) expect - 서브프로세스의 출력에 따라
동작을
취한다. 다음의 예제를 보자. spawn /usr/ucb/ftp netserver while 1 { expect { "Name*: "
{send "netclientr"} "Password:" {send "netclientpwr} "ftp> " {break}
"failed" {send_user "Can't log in.r"; exit 1} timeout {send_user "Timeout problem.r";
exit
2} }} send "lcd /etcr" expect "ftp> " {send "cd pub/sysfilesr"} expect "ftp> " {send "get
passwdr"} expect "ftp> " {send "quitr; send_user "r"} exit 0 스크립트 첫 번째 라인은 명령어 ‘ftp
netserver’를 수행한다. 그리고 while 루프를 돌면서 이름과 암호가 들어오기를 기다린다. 다음으로 ‘ftp>’ 프롬프
트가
나오면 루프를 빠져나와 일련의 동작을 취한다. 루프 안에서는 2가지의 문제에 대해 처리를 하는데 첫 번째는 로그인이
안되는 경우에 생기는 failed 문자열이 들어오는지 검사한다. timeout 절은 10초이상 아무 응답이 없는 경우를
탐지한다. 2가지 경우 에러 메시지를 내보내고 빠져 나온다. 위의 예제 스크립트는 로그인이 성공된 후는 아무 에러도
발생하지 않는다는 가정을 하고 작성한 것이다. 그러나 실제로는 여러 에러 상황에 대한 처리가 추가되어야 할
것이다.
expect 명령어에 대해 좀더 자세히 설명하면 우선 spawn 명령은 인자로 주어 지는 프로그램의 인스턴스를 생성한다.
send
명령은 서브프로세스의 표준 출력 에 문자열을 위치시킨다. 주의할 점은 반드시 개행문자를 끝에 추가해야 한다 는
것이다.
반면 send_user 명령은 스크립트의 표준 출력에 메시지를 보내는 것이다. NIS : 네트워크 정보 서비스 1980년대
개발된 NIS는 최초의 관리자 데이터베이스이다. NIS는 최초에는 Sun Yellow Page라고 불리었으나 법적인 문제로
결국 NIS로 개명되었다. NIS 명령이 여전히 ‘yp..’로 시작하는 것은 이러한 역사적 이유 때문이다. 지금은 많은
회사들이 썬의 NIS 코드를 라이센스하여 널리 사용하게 되었다. 썬은 근래 NIS+라는 새 시스템을 내놓고 이를
솔라리스에서
NIS를 위한 클라 이언트측의 지원에 대해서만 제공해 오고 있다. 사실 이름은 비슷하나 NIS와 NIS+는 서로 관련이
없다. 다음 표는 시스템에 따른 NIS와 NIS+의 지원여부 를 나타낸 것이다. 시스템 NIS 지원여부
NIS+
지원여부 Solaris 부분적으로 지원 HP-UX 지원 지원 안함 IRIX 지원
지원
안함 SunOS 지원 지원 안함 OSF/1 지원 지원 안함 BSDI 지원 안함 지원
안함 NIS의 마스터 서버는 시스템 파일의 관리 복사본을 유지하는데 여기에는 원래 의 위치나 형식 등이 관리된다. 서버
프로세스는 이러한 파일들의 내용(NIS는 이를 맵(map)이라 한다)이 네트워크에서 유효하도록 만든다. 이와 같은 서버와
그 클라이언트가 NIS 도메인을 구성하는 것이다. NIS 맵은 ndbm 확장 해싱 루틴에 의해 프리 프로세싱된다. 그러므로
마스터 서버의 시스템 파일들이 수정되고 나면 NIS에게 ndbm 형식으로 변환하도록 make나 ypmake라는 스크립트 같은
명령을 수행해야 한다. ndbm은 각 엔트리에 연결된 오직 하나의 key만을 가지는데 이런 이유로 인해 하나의 시스템
파일이 여러 개의 NIS 맵으로 나뉠 수도 있다. 예를 들면 ‘/etc/passwd’ 파일이 NIS에서는 passwd.byname 과
passwd.byuid로 나뉘 는 것이다. 하나는 사용자명으로 접근하는 것이고 후자는 UID 번호로 접근할 때 사용된다.
NIS는
슬레이브 서버의 집합을 두어 네트워크 맵을 복사하여 그 부하를 줄이 게 되는데 클라이언트측의 관점에서는 마스터와
슬레이브의 구분은 따로 하지 않는다. 어찌되었건 하나의 네트워크에서 최소한 하나의 NIS 서버가 있어야함은 당연
하다고 하겠다. NIS netgroups NIS 는 netgroup이라는 사용자와 호스트와 네트워크를 묶어 이름을 부여함으 로써
다른 시스템 파일의 참조를 용이하게 하는데 사용한다. 이들 그룹들은 ‘/etc/netgroup’에서 정의되지만 전체적인
NIS
맵으로서도 공유된다. netgroup의 형식은 다음과 같다. 멤버들은 공백으로 구분되는데 멤버는 netgroup 이름이나 혹은
다음과 같은 3 쌍의 형식을 가진다. (호스트명, 사용자명, 도메인명) 위에서 비어있는 경우는 와일드 카드와 같이
모든
것을 대체한다. 그러므로 만 약 (eshost , , )와 같이 사용하면 이는 eshost의 모든 도메인과 사용자들을 포 함한다는
의미인 것이다. 만약 그 안에 ‘ - ’ 문자가 쓰이는 경우는 not을 의미하므로 (eshost, -, ) 표현이 eshost의 모든
도메인만을 참조함을 의미한다. 다음은 ‘/etc/netgroup’의 한 예이다. servers (eshost, , ) (esrs, , )
(essdt500, , ) allhosts servers (essdt300, ,) (esapollo, , ) netgroup은 접근허가를 정의하는 여러
파일들에서 사용될 수 있다. ‘/etc/export’에서 파일 시스템을 마운트할 수 있는 시스템을 지정할 때 사용
가능하며 ‘/etc/hosts.equiv’나 .rhosts에서 사용하면 호스트나 사용자 그룹의 로그인 허가를 제어할 수 있다.
NIS의
장점과 단점 NIS의 좋은 점은 우선 이해하기가 수월하다는 것이다. 관리자는 NIS의 내부 형식같은 것을 알 필요도
없으며 단지 이용을 위한 한, 두 가지의 진행 과정만 을 익히기만 하면 되는 것이다. 그러나 NIS는 도메인의 링크를
제공하지 않기 에 규모가 큰 네트워크의 관리에는 부적합하다. NIS는 많은 네트워크 전송량을 소모할 수도 있다. NIS는
클라이언트측의 데이 터를 캐시하지 않기 때문에 모든 참조는 패킷의 교환을 의미하게 되는 것이다. 그리고 NIS 마스터
서버에서 시스템 파일이 갱신되면 이와 관련된 모든 맵은 모든 슬레이브 서버에게 복사하게 된다. NIS의 기술적 사항
NIS의 데이터 파일과 대부분의 명령어들은 하나의 디렉터리에 위치하는데 보 통 ‘/var/yp’ 혹은 ‘/usr/etc/yp’,
‘/etc/yp’ 디렉터리이다. 앞으로는 이 들을 NIS 디렉터리라 칭하겠다. 각각의 NIS 맵은 ndbm 파일(맵.dir)과
맵.pag로
불리는 하나의 쌍으로 NIS 도 메인에 해당되는 NIS 디렉터리의 하위 디렉터리에 저장된다. 예를 들면 도메인 eslab에서
‘etc/passwd’ 맵에 대한 ndbm 파일들은 다음과 같을 것이다. /usr/etc/yp/eslab/passwd.byname.dir
/usr/etc/yp/eslab/passwd.byname.pag /usr/etc/yp/eslab/passwd.byuid.dir
/usr/etc/yp/eslab/passwd.byuid.pag 맵들은 ypxfr 명령을 통해 마스터 서버로부터 슬레이브 서버로
복사된다.
ypxfr 명령은 Pull 명령어이다. 즉 맵을 가져오기 위해서 각 슬레이브 서버에서 수행되어야 하는 명령인 것이다.
ypxfrd라는 데몬은 이 요구에 응답하기 위해 마스터 서버에서 수행되는 프로세 스이다. 슬레이브 측은 항상 주기적으로
ypxfr 명령을 수행해 최신의 맵을 가지도록 해 야 하는데 그 간격은 cron을 사용하여 조정하면 된다. yppush는 마스터
서버에서 사용되는 ypxfr의 push 버전이다. 즉 어떤 데이터 를 전송하는 것이 아니라 슬레이브측의 ypxfr 명령을
실행시키도록 지정하는 것이다. 그리고 시스템 파일들에 대한 참조는 다음 그림과 같은 원리로 이루어진다.
--------------------------------------------------------------- 프로그램 설
명 ypserv NIS 서버 데몬, 부트 할 때 시작됨 ypbind NIS 클라이언트 데몬, 부트 할 때 시작됨
domainname NIS 도메인을 설정 ypxfr 마스터 서버로부터 맵의 현재버전을 다운로드 ypxfrd
위의 ypxfr의 요구를 서비스하는 데몬 yppush 슬레이브 서버의 맵을 업데이트 시킴 makedbm flat
file(일반 간단한 형식의 텍스트 파일)로부터 ndbm맵을 구축 ypmake 변경된 flat
file로부터 ndbm맵을 재구축 ypinit 호스트를 마스터나 슬레이브 서버로 설정 ypset ypbind를
특정 서버에 연결 ypwhich 현재의 호스트가 사용하는 서버가 어느 것인지 탐색 yppoll 서버가
사용하는
맵의 버전이 무엇인지 탐색 ypcat NIS 맵에 포함된 값을 프린트함 ypmatch 지정된 키에 대한 맵의
엔트리를 프린트함 yppasswd NIS 마스터 서버의 암호를 변경 ypchfn NIS 마스터 서버의 GECOS 정보를
변경
ypchsh NIS 마스터 서버에서의 로그인 셸을 변경 yppasswdd yppasswd, ypchsh, ypchfn을 서비스하는
데몬
ypupdated NIS 맵을 업데이트하는 데몬(inetd에 의해 관리됨)
--------------------------------------------------------------- 우선은 모든 클라이언트측의 시스템에는
ypbind라는 데몬이 수행되어야 하며 서버측에는 클라이언트측의 질의에 응답 해줄 데몬으로 ypserv를 수행시킨다.
ypbind는 getpwuid와 같은 라이브러리가 정보를 가져올 서버의 위치를 파악 해 알려주면 getpwuid 루틴은 그 위치로
직접 접촉을 해서 ypserv에게 필요한 질의를 하는 제어흐름을 가지는 것이다. 위의 표는 NIS의 자세한 명령과 데몬에
대한
설명이다. NIS 도메인 설정하기 NIS는 마스터 서버와 슬레이브 서버 그리고 각 클라이언트 위에서 초기화되어 야 한다.
이를 위해서는 2가지 단계를 거치는데 첫 번째로 ypinit 명령을 각 서 버에서 수행한다. 두 번째로는 도메인의 모든
호스트의 스타트업 파일의 한군 데에서 도메인 이름을 설정한다. 그리고 ‘/etc/passwd’ 파일과 ‘/etc/grou p’
파일을
NIS 데이터를 가져오기(import) 위해 수정한다. NIS 서버 컨피그 도메인에 대해 마스터와 슬레이브 서버 모두를
초기화하기 위해 ypinit 명령이 쓰인다. 마스터 서버에서의 경우 cd /var/yp /* NIS 디렉터리로
이동
*/ domainname 도메인명 /* 새 도메인명 지정 */ ypinit -m /* 마스터 서버로 초기화 */
/usr/etc/ypserv /* NIS 서버 시작 */ 이와 같이 수행시킨다. ‘-m’ 플래그는 ypinit에게 마스터 서버의 컨피그임을
알려준다. 마스터 서버 가 일단 구동되고 나면 다음으로 슬레이브 서버를 ‘ypinit -s’ 명령으로 각 각 마스터 서버와
연결시킨다. cd /var/yp ypinit -s 마스터 호스트명 /usr/etc/ypserv ‘ypinit -s’ 명령은 마스터의 현재 데이터
복사본의 지역 복사본을 만든다. 각각의 슬레이브에서는 crontab 엔트리를 조정해 주기적으로 마스터 서버로부 터 모든
맵의 복사본을 갱신하도록 지정해야 한다. 다음은 모든 맵을 전송하는 스크립트이다. #!/bin/csh -f set mydomain =
`/usr/bin/domainname` cd /var/yp/$mydomain # NIS 디렉터리 foreach map (`/usr/bin/ls`)
/usr/etc/ypxfr $map end 어떤 시스템은 ypxfr_1perday, ypxfr_2perday, ypxfr_ 1perhour와 같은 스크립 트를
따로 가지고있는 것도 있다. NIS 클라이언트의 컨피그 이제는 각 시스템에게 새 도메인의 멤버가 되었음을 알리고 시스템
파일을 이 용할 때 네트워크 버전을 이용해야함을 알리는 작업이 필요하다. domainname 명령인 시스템의 NIS 도메인을
설정한다. 보통 부트시에 지정하 도록 하면 된다. 어떤 시스템은 부트 할 때에 ‘/etc/defaultdomain’파일을 찾아
지정하는 것도 있다. 다음은 이를 위한 스크립트 예이다. # 무슨 도메인이 있는지를 로컬 시스템에 알림
/usr/bin/domainname eslab # 로컬 시스템이 그 도메인을 서비스하는지 체크 if [-f /etc/ypserv -a -d
/var/yp`domainname`]; then /etc/ypserv; (echo -n ' ypserv') > /dev/console fi # ypbind 구동
if
[-f /etc/ypbind ] ; then /etc/ypbind; (echo -n ' ypbind') > /dev/console fi NIS+ 와 다른
데이터베이스 시스템 NIS+는 NIS의 결점을 보완하고 규모가 큰 네트워크 환경을 다룰 수 있도록 하기 위해 만들어
졌다.
NIS와 NIS+의 차이점을 말한다면 우선 NIS+는 NIS보다 더욱 데이터베이스의 성격을 가지는데 맵(이제는 테이블이라
불림)을 어떠한 필드를 가지고도 검색 할 수 있다는 점이 이를 나타낸다. NIS+는 더 이상 NIS와 같이 flat 파일을
사용하지 않는다. 슬레이브 서버를 다 루는데 NIS+가 NIS보다 더욱 좋다. NIS+는 썬의 secure RPC 시스템 위에서
구축되었기에 공유키(public-key) 암호화에 기반을 둔 인증을 가능케 한다. 실제 많은 차이점이 있음에도 불구하고
클라이언트 입장에서 보면 사실 NIS+ 는 다른 관리 데이터베이스 시스템과 거의 유사한 모습을 가진다. 모든 데이터 는
마찬가지로 라이브러리 루틴을 통해 접근 가능하며 결국은 하나의 유닉스 Flat 파일로 귀착되는 것이다. NIS+는
DNS와는
아무 상관이 없지만 DNS의 명칭부여 구조를 빌리고 있다. NIS나 NIS+ 이외에도 MIT의 Hesiod나 NeXT의 NetInfo
등의 데이터베이스 시스템이 있으나 그다지 널리 사용되고 있지 않다. MIT의 Hesiod는 관리자 데이터베이스를 분배하기
위해 DNS 프로토콜을 확장 한 것이고 NetInof는 NIS+와 매우 유사하지만 훨씬 간단하고 명확한 구조를 가진다. 여러
운영체계에서의 특정 사항 솔라리스의 경우 관리 데이터의 소스를 지정하기 위해 ‘/etc/nsswitch.conf’ 파일을
사용한다. 그 내용은 다음과 같다. passwd: files nisplus hosts: nisplus dns group: files ...
위에서
nisplus, nis, files, dns, conpat은 각각 NIS+, NIS, ‘+’같은 토큰을 없앤 파일, DNS , NIS화된 파일을
의미한다. 왼쪽에 대한 정보를 찾는 경우 오른쪽으로 진행하며 정보를 검색함을 의미하는 것이다. 또한 다음과 같이
소스에
이상이 생기는 경우에 대한 처리도 지정할 수 있다. hosts: dns [NOTFOUND=return] nisplus 자세한 조건에
대한 것은 아래 표에 나타내었다. --------------------------------------------------------------- 조
건
의 미 UNAVAIL 소스가 존재하지 않거나 다운됨 NOTFOUND 소스는 존재하나
질의에
응답할 수 없었음 TRYAGAIN 소스는 존재하나 busy 상태임 SUCCESS 소스가 질의에 응답할 수 있었음
--------------------------------------------------------------- HP-UX의 경우는 우선적으로 DNS를 이용하며
그
다음으로 NIS 그리고 나서 ‘/etc/hosts’파일을 이용한다. OSF/1의 DEC 버전은 NIS와 호환성이 있으며 탐색 순서는
‘/etc/svc.conf’ 파일에 지정된다. 이 파일의 원 이름은 ‘/etc/svcorder’이다. BSDI의 경우는 NIS를 지원하지
않는다. 대부분 ‘/etc/hosts’ 파일로 호스트를 참조하고 가능 하다면 네임서버도 이용한다. 마치며 이번 달에는 시스템
파일의 공유에 대해서 다루었다. 사실 지금까지 설명한 내용들을 제대로 활용하는 시스템이나 소규모 네트워크 를
필자는
별로 보지 못했다. 물론 이유는 보안이나 관리의 어려움 등의 여러 이유가 있을 수 있을 것이다. 하지만 대부분의
경우는
이러한 기능이 있는지 조차도 모르는 경우가 허다할 것이다. 설사 알고 있다 치더라도 이를 실제 시스템에 적용해본
관리자는 그리 많은 것 같지 않다. 여러분들이 제대로 된 시스템 관리자가 되고 싶다면 이런 기능들을 실제 적용해
보고
이를 분석하는 작업은 필수적이며 이러한 과정을 통해서만이 더 나은 시스템 구축이 가능해 질 것이다. 다음 호에는
SLIP/PPP 에 대해 진행하기로 하겠다. 필자 연락처：HiTEL-huclons 천리안 - huclons
..........
대해 알아볼 것이다. 들어가며 하나의 네트워크에서 어떤 호스트의 IP주소가 바뀌었다고 생각해 보자. 이 경 우 같은
LAN으로 연결된 호스트들의 ‘/etc/hosts’파일을 모두 따로 갱신해 야 한다면 정말 피곤한 일일 것이다. 이와 같이
중복되는 일을 쉽게 관리해 처리하기 위해서는 바로 시스템들을 그룹으로 묶어 공통의 시스템 파일을 관리 하는 것이
필수적이다. 이를 위해서는 두 가지의 접근 방법이 있을 수 있을 것 이다. 첫 번째는 각 시스템의 컨피그 파일에 대한
마스터(master) 복사본을 하나 관 리하면서 어떤 시스템의 컨피그 파일이 변경될 때마다 이 마스터 복사본을 각
그룹의
멤버에게 분배하는 것이다. 이 방법은 간단하며 모든 유닉스 시스템에 서 동작한다는 장점을 가진다. 두 번째 방법으로는
모든 텍스트 파일을 없애고 각각의 시스템이 하나의 중앙 서버로부터 컨피그 파일을 가져다 쓰는 것이다. 이는 첫 번째
방법보다는 매우 복잡하나 반면 여러 문제들을 해결해 준다. 예를 들면 클라이언트가 갱신하지 않는 경우를 막아준다.
사실 어떠한 방법도 모든 면에서 좋은 것일 수는 없다. 그러므로 이제부터는 네트워크에서 파일의 동기화를 유지하는
기술과 가장 널리 사용되는 관리자 데 이터베이스 시스템인 NIS와 NIS+에 대해 이야기 해 나가도록 하겠다. 무엇을
공유해야 하는가 유닉스에서의 모든 컨피그 파일들 중에 일부만이 다른 시스템들과 공유해야할 필요가 있다. 다음 표가
이를 나타낸 것이다. 위의 표에 나온 파일들은 보통 표 준 C 라이브러리에 정의된 루틴을 통해 접근된다. 예를 들면
‘/etc/passwd’ 파일은 getpwuid, getpwnam, getpwent 루틴들을 통해 접근한다. 이 루틴들은 이러한 파일들을
열어서 읽으며 파싱하는 것이다. --------------------------------------------------------------- 파 일
명
기 능 /etc/passwd 사용자 계정 정보 데이터베이스 /etc/group 유닉스 그룹
정의파일 /etc/hosts 호스트 이름과 IP주소간의 매핑 정보 파일 /etc/networks IP 네트워크 번호와 관련된
텍스트 이름들 /etc/services 잘 알려진 네트워크 서비스의 포트 번호 목록 /etc/protocols 텍스트 이름을
프로토콜 번호와 매핑 /etc/ethers 호스트 이름과 이서네트 주소와의 매핑 /etc/aliases 전자 메일
앨리어스(별명) /etc/rpc RPC 서비스에 대한 ID 번호의 리스트 /etc/netgroup 호스트, 사용자,
네트워크의 집합을 정의 --------------------------------------------------------------- 파일의 분배
파일을
분배하는 방법에는 크게 마스터 서버가 주기적으로 클라이언트에게 파 일을 분배하는 push 모델과 지역적으로 파일을
관리하는 pull 모델이 있다. rdist : 파일들 보내기(Push 모델) 대부분의 경우 rdist 명령은 중앙 서버로부터
파일들을
분배하는데 사용되는 가장 좋은 명령이다. make 명령과 유사하게 텍스트 파일로 동작을 지정해서 그대로 수행해
나간다.
특별한 지정이 없는 경우 make 명령이 Makefile을 찾아 수행하는 것처럼 distfile이나 Distfile이라는 이름의
제어파일을 찾아 수행한다. 제어파일의 지정 을 직접하는 경우는 make와 마찬가지로 ‘-f’ 옵션을 주고 파일명을 적어주
면
된다. 제어파일은 #을 주석으로 사용하며 그 형식은 다음과 같다. label 패스명 -> 목적지 명령 label은
제어파일의 특정 명령을 실행하기 위한 것으로 ‘rdist 레이블명’ 하 면 해당 레이블이 지정된 문장만을 수행하게 된다.
패스명은 복사할 파일들의 패스와 이름을 지정하는 것이고 목적지는 파일을 복 사할 목적지에 있는 호스트명의 목록을
지정하면 된다. 만약 여러 개인 경우는 괄호로 묶어주어야 한다. 기본적으로 rdist 명령은 파일들을 목적지 호스트의
같은
위치에 복사를 수행 한다. 이러한 동작을 변경하려는 경우 마지막 필드의 명령 부분에서 조정한다. 모든 명령은 반드시
세미콜론으로 끝나야 하며 다음과 같은 명령어들이 유효하 다. install 옵션 (목적지 디렉터리); notify 네임리스트;
except 패스리스트; except_pat 패턴리스트; special (패스리스트) 스트링; install 명령어는 rdist 명령이
파일을
복사하는 방식에 영향을 주는 옵션을 지 정한다. 이 옵션들은 시스템마다 상당한 차이가 있기에 이 글에서는 자세히 언
급하지는 않겠지만 각자 자신의 시스템 매뉴얼을 참조하는 것이 좋을 것이다. 목적지 디렉터리는 목적지 호스트의
복사할
위치를 지정하는 것이다. notify 명령은 그 인자로 전자 메일 주소의 리스트를 가지는데 rdist 명령은 파 일들을 복사한
후
자동으로 이 메일의 주소를 파일이 업데이트 되었음을 알리 게 된다. 알아둘 점은 일반적으로 메일 주소에서 쓰이는 ‘@’
문자를 사용하 지 않고 사용자의 계정만으로도 지정한다는 점이다. 예를 들면 ‘yjy’라고만 해도 해당 목적지 호스트의
yjy
사용자에게 메일을 전송하는 것이다. except와 except_pat 명령은 복사될 파일들의 목록에서 일부 패스명들을 제거
한다. 이는 상당히 유용하게 쓰일 수 있는데 make와 마찬가지로 rdist 명령도 제어 파일 앞부분에 매크로를 사용할 수
있기에 자주 쓰이는 목록을 매크로로 만들어 놓고 그 중 특정 목록만을 제외시키는 경우 유용하기 때문이다. special
명령은 원격 호스트에서 sh 명령을 수행한다. 만약 패스 리스트가 존재 한다면 rdist 명령은 지정된 파일을 복사한 후에
명령을 수행한다. 다음은 제어 파일의 예를 보인 것이다. SYS_FILES = (/etc/passwd /etc/group /etc/aliases)
GET_ALL = (eshp essdt300 essdt500 esrs) GET_SOME = (esapollo eshost) all: $(SYS_FILES) ->
$(GET_ALL) notify yjy; special /etc/aliases "/usr/ucb/newaliases"; some: $(SYS_FILES) ->
$(GET_SOME) except /etc/aliases; notify leesg@eshost; 위의 예를 설명하자면 세개의 시스템 파일을
호스트 eshp, essdt300, essdt500, esrs로 복사한 후 목적지 호스트의 사용자 yjy에게 메일로 이 사실을 알리게
된다. 그리고 ‘/etc/aliases’ 파일을 복사한 후에 rdist 명령은 목적지 호스트 의 newaliases 명령을 수행한다. 또한
esapollo와 eshost에는 단지 2개의 파일 만을 복사한다. expect : 파일들 가져오기(Pull 모델) Pull 모델을
구현하는
방법은 상당히 다양하다. 그 중 괜찮은 방법이 시스템 파 일들을 중앙 서버의 ftp를 통해 접근 가능하도록 하고 이
파일들을
검색, 설치 하는 expect 명령을 사용하는 것이다. expect는 John Ousterhout의 Tcl(Tool Command Langu age)의
확장된 형태인 데 사용자와 상호 작용하는 프로그램을 위한 제어 스크립트를 쓸 수 있도록 한 다. expect를 만든 이는
NIST의 Don Libes라는 사람이다. expect는 일반 스크립트 언어와는 차이가 있는데 바로 서브프로세스의 순차적 제어를
제공하기 때문이다. 기술적으로 expect 스크립트는 Tcl의 스크립트와 거의 유사하다. Tcl은 문법적으로 간단한데
대부분의 명령어가 셸 명령어처럼 동작한다. 기본적인 expect 명령들은 다음과 같다. (1) spawn - 제어할
서브프로세스를 구동시킨다. (2) send - 서브프로세스로 입력을 준다. (3) expect - 서브프로세스의 출력에 따라
동작을
취한다. 다음의 예제를 보자. spawn /usr/ucb/ftp netserver while 1 { expect { "Name*: "
{send "netclientr"} "Password:" {send "netclientpwr} "ftp> " {break}
"failed" {send_user "Can't log in.r"; exit 1} timeout {send_user "Timeout problem.r";
exit
2} }} send "lcd /etcr" expect "ftp> " {send "cd pub/sysfilesr"} expect "ftp> " {send "get
passwdr"} expect "ftp> " {send "quitr; send_user "r"} exit 0 스크립트 첫 번째 라인은 명령어 ‘ftp
netserver’를 수행한다. 그리고 while 루프를 돌면서 이름과 암호가 들어오기를 기다린다. 다음으로 ‘ftp>’ 프롬프
트가
나오면 루프를 빠져나와 일련의 동작을 취한다. 루프 안에서는 2가지의 문제에 대해 처리를 하는데 첫 번째는 로그인이
안되는 경우에 생기는 failed 문자열이 들어오는지 검사한다. timeout 절은 10초이상 아무 응답이 없는 경우를
탐지한다. 2가지 경우 에러 메시지를 내보내고 빠져 나온다. 위의 예제 스크립트는 로그인이 성공된 후는 아무 에러도
발생하지 않는다는 가정을 하고 작성한 것이다. 그러나 실제로는 여러 에러 상황에 대한 처리가 추가되어야 할
것이다.
expect 명령어에 대해 좀더 자세히 설명하면 우선 spawn 명령은 인자로 주어 지는 프로그램의 인스턴스를 생성한다.
send
명령은 서브프로세스의 표준 출력 에 문자열을 위치시킨다. 주의할 점은 반드시 개행문자를 끝에 추가해야 한다 는
것이다.
반면 send_user 명령은 스크립트의 표준 출력에 메시지를 보내는 것이다. NIS : 네트워크 정보 서비스 1980년대
개발된 NIS는 최초의 관리자 데이터베이스이다. NIS는 최초에는 Sun Yellow Page라고 불리었으나 법적인 문제로
결국 NIS로 개명되었다. NIS 명령이 여전히 ‘yp..’로 시작하는 것은 이러한 역사적 이유 때문이다. 지금은 많은
회사들이 썬의 NIS 코드를 라이센스하여 널리 사용하게 되었다. 썬은 근래 NIS+라는 새 시스템을 내놓고 이를
솔라리스에서
NIS를 위한 클라 이언트측의 지원에 대해서만 제공해 오고 있다. 사실 이름은 비슷하나 NIS와 NIS+는 서로 관련이
없다. 다음 표는 시스템에 따른 NIS와 NIS+의 지원여부 를 나타낸 것이다. 시스템 NIS 지원여부
NIS+
지원여부 Solaris 부분적으로 지원 HP-UX 지원 지원 안함 IRIX 지원
지원
안함 SunOS 지원 지원 안함 OSF/1 지원 지원 안함 BSDI 지원 안함 지원
안함 NIS의 마스터 서버는 시스템 파일의 관리 복사본을 유지하는데 여기에는 원래 의 위치나 형식 등이 관리된다. 서버
프로세스는 이러한 파일들의 내용(NIS는 이를 맵(map)이라 한다)이 네트워크에서 유효하도록 만든다. 이와 같은 서버와
그 클라이언트가 NIS 도메인을 구성하는 것이다. NIS 맵은 ndbm 확장 해싱 루틴에 의해 프리 프로세싱된다. 그러므로
마스터 서버의 시스템 파일들이 수정되고 나면 NIS에게 ndbm 형식으로 변환하도록 make나 ypmake라는 스크립트 같은
명령을 수행해야 한다. ndbm은 각 엔트리에 연결된 오직 하나의 key만을 가지는데 이런 이유로 인해 하나의 시스템
파일이 여러 개의 NIS 맵으로 나뉠 수도 있다. 예를 들면 ‘/etc/passwd’ 파일이 NIS에서는 passwd.byname 과
passwd.byuid로 나뉘 는 것이다. 하나는 사용자명으로 접근하는 것이고 후자는 UID 번호로 접근할 때 사용된다.
NIS는
슬레이브 서버의 집합을 두어 네트워크 맵을 복사하여 그 부하를 줄이 게 되는데 클라이언트측의 관점에서는 마스터와
슬레이브의 구분은 따로 하지 않는다. 어찌되었건 하나의 네트워크에서 최소한 하나의 NIS 서버가 있어야함은 당연
하다고 하겠다. NIS netgroups NIS 는 netgroup이라는 사용자와 호스트와 네트워크를 묶어 이름을 부여함으 로써
다른 시스템 파일의 참조를 용이하게 하는데 사용한다. 이들 그룹들은 ‘/etc/netgroup’에서 정의되지만 전체적인
NIS
맵으로서도 공유된다. netgroup의 형식은 다음과 같다. 멤버들은 공백으로 구분되는데 멤버는 netgroup 이름이나 혹은
다음과 같은 3 쌍의 형식을 가진다. (호스트명, 사용자명, 도메인명) 위에서 비어있는 경우는 와일드 카드와 같이
모든
것을 대체한다. 그러므로 만 약 (eshost , , )와 같이 사용하면 이는 eshost의 모든 도메인과 사용자들을 포 함한다는
의미인 것이다. 만약 그 안에 ‘ - ’ 문자가 쓰이는 경우는 not을 의미하므로 (eshost, -, ) 표현이 eshost의 모든
도메인만을 참조함을 의미한다. 다음은 ‘/etc/netgroup’의 한 예이다. servers (eshost, , ) (esrs, , )
(essdt500, , ) allhosts servers (essdt300, ,) (esapollo, , ) netgroup은 접근허가를 정의하는 여러
파일들에서 사용될 수 있다. ‘/etc/export’에서 파일 시스템을 마운트할 수 있는 시스템을 지정할 때 사용
가능하며 ‘/etc/hosts.equiv’나 .rhosts에서 사용하면 호스트나 사용자 그룹의 로그인 허가를 제어할 수 있다.
NIS의
장점과 단점 NIS의 좋은 점은 우선 이해하기가 수월하다는 것이다. 관리자는 NIS의 내부 형식같은 것을 알 필요도
없으며 단지 이용을 위한 한, 두 가지의 진행 과정만 을 익히기만 하면 되는 것이다. 그러나 NIS는 도메인의 링크를
제공하지 않기 에 규모가 큰 네트워크의 관리에는 부적합하다. NIS는 많은 네트워크 전송량을 소모할 수도 있다. NIS는
클라이언트측의 데이 터를 캐시하지 않기 때문에 모든 참조는 패킷의 교환을 의미하게 되는 것이다. 그리고 NIS 마스터
서버에서 시스템 파일이 갱신되면 이와 관련된 모든 맵은 모든 슬레이브 서버에게 복사하게 된다. NIS의 기술적 사항
NIS의 데이터 파일과 대부분의 명령어들은 하나의 디렉터리에 위치하는데 보 통 ‘/var/yp’ 혹은 ‘/usr/etc/yp’,
‘/etc/yp’ 디렉터리이다. 앞으로는 이 들을 NIS 디렉터리라 칭하겠다. 각각의 NIS 맵은 ndbm 파일(맵.dir)과
맵.pag로
불리는 하나의 쌍으로 NIS 도 메인에 해당되는 NIS 디렉터리의 하위 디렉터리에 저장된다. 예를 들면 도메인 eslab에서
‘etc/passwd’ 맵에 대한 ndbm 파일들은 다음과 같을 것이다. /usr/etc/yp/eslab/passwd.byname.dir
/usr/etc/yp/eslab/passwd.byname.pag /usr/etc/yp/eslab/passwd.byuid.dir
/usr/etc/yp/eslab/passwd.byuid.pag 맵들은 ypxfr 명령을 통해 마스터 서버로부터 슬레이브 서버로
복사된다.
ypxfr 명령은 Pull 명령어이다. 즉 맵을 가져오기 위해서 각 슬레이브 서버에서 수행되어야 하는 명령인 것이다.
ypxfrd라는 데몬은 이 요구에 응답하기 위해 마스터 서버에서 수행되는 프로세 스이다. 슬레이브 측은 항상 주기적으로
ypxfr 명령을 수행해 최신의 맵을 가지도록 해 야 하는데 그 간격은 cron을 사용하여 조정하면 된다. yppush는 마스터
서버에서 사용되는 ypxfr의 push 버전이다. 즉 어떤 데이터 를 전송하는 것이 아니라 슬레이브측의 ypxfr 명령을
실행시키도록 지정하는 것이다. 그리고 시스템 파일들에 대한 참조는 다음 그림과 같은 원리로 이루어진다.
--------------------------------------------------------------- 프로그램 설
명 ypserv NIS 서버 데몬, 부트 할 때 시작됨 ypbind NIS 클라이언트 데몬, 부트 할 때 시작됨
domainname NIS 도메인을 설정 ypxfr 마스터 서버로부터 맵의 현재버전을 다운로드 ypxfrd
위의 ypxfr의 요구를 서비스하는 데몬 yppush 슬레이브 서버의 맵을 업데이트 시킴 makedbm flat
file(일반 간단한 형식의 텍스트 파일)로부터 ndbm맵을 구축 ypmake 변경된 flat
file로부터 ndbm맵을 재구축 ypinit 호스트를 마스터나 슬레이브 서버로 설정 ypset ypbind를
특정 서버에 연결 ypwhich 현재의 호스트가 사용하는 서버가 어느 것인지 탐색 yppoll 서버가
사용하는
맵의 버전이 무엇인지 탐색 ypcat NIS 맵에 포함된 값을 프린트함 ypmatch 지정된 키에 대한 맵의
엔트리를 프린트함 yppasswd NIS 마스터 서버의 암호를 변경 ypchfn NIS 마스터 서버의 GECOS 정보를
변경
ypchsh NIS 마스터 서버에서의 로그인 셸을 변경 yppasswdd yppasswd, ypchsh, ypchfn을 서비스하는
데몬
ypupdated NIS 맵을 업데이트하는 데몬(inetd에 의해 관리됨)
--------------------------------------------------------------- 우선은 모든 클라이언트측의 시스템에는
ypbind라는 데몬이 수행되어야 하며 서버측에는 클라이언트측의 질의에 응답 해줄 데몬으로 ypserv를 수행시킨다.
ypbind는 getpwuid와 같은 라이브러리가 정보를 가져올 서버의 위치를 파악 해 알려주면 getpwuid 루틴은 그 위치로
직접 접촉을 해서 ypserv에게 필요한 질의를 하는 제어흐름을 가지는 것이다. 위의 표는 NIS의 자세한 명령과 데몬에
대한
설명이다. NIS 도메인 설정하기 NIS는 마스터 서버와 슬레이브 서버 그리고 각 클라이언트 위에서 초기화되어 야 한다.
이를 위해서는 2가지 단계를 거치는데 첫 번째로 ypinit 명령을 각 서 버에서 수행한다. 두 번째로는 도메인의 모든
호스트의 스타트업 파일의 한군 데에서 도메인 이름을 설정한다. 그리고 ‘/etc/passwd’ 파일과 ‘/etc/grou p’
파일을
NIS 데이터를 가져오기(import) 위해 수정한다. NIS 서버 컨피그 도메인에 대해 마스터와 슬레이브 서버 모두를
초기화하기 위해 ypinit 명령이 쓰인다. 마스터 서버에서의 경우 cd /var/yp /* NIS 디렉터리로
이동
*/ domainname 도메인명 /* 새 도메인명 지정 */ ypinit -m /* 마스터 서버로 초기화 */
/usr/etc/ypserv /* NIS 서버 시작 */ 이와 같이 수행시킨다. ‘-m’ 플래그는 ypinit에게 마스터 서버의 컨피그임을
알려준다. 마스터 서버 가 일단 구동되고 나면 다음으로 슬레이브 서버를 ‘ypinit -s’ 명령으로 각 각 마스터 서버와
연결시킨다. cd /var/yp ypinit -s 마스터 호스트명 /usr/etc/ypserv ‘ypinit -s’ 명령은 마스터의 현재 데이터
복사본의 지역 복사본을 만든다. 각각의 슬레이브에서는 crontab 엔트리를 조정해 주기적으로 마스터 서버로부 터 모든
맵의 복사본을 갱신하도록 지정해야 한다. 다음은 모든 맵을 전송하는 스크립트이다. #!/bin/csh -f set mydomain =
`/usr/bin/domainname` cd /var/yp/$mydomain # NIS 디렉터리 foreach map (`/usr/bin/ls`)
/usr/etc/ypxfr $map end 어떤 시스템은 ypxfr_1perday, ypxfr_2perday, ypxfr_ 1perhour와 같은 스크립 트를
따로 가지고있는 것도 있다. NIS 클라이언트의 컨피그 이제는 각 시스템에게 새 도메인의 멤버가 되었음을 알리고 시스템
파일을 이 용할 때 네트워크 버전을 이용해야함을 알리는 작업이 필요하다. domainname 명령인 시스템의 NIS 도메인을
설정한다. 보통 부트시에 지정하 도록 하면 된다. 어떤 시스템은 부트 할 때에 ‘/etc/defaultdomain’파일을 찾아
지정하는 것도 있다. 다음은 이를 위한 스크립트 예이다. # 무슨 도메인이 있는지를 로컬 시스템에 알림
/usr/bin/domainname eslab # 로컬 시스템이 그 도메인을 서비스하는지 체크 if [-f /etc/ypserv -a -d
/var/yp`domainname`]; then /etc/ypserv; (echo -n ' ypserv') > /dev/console fi # ypbind 구동
if
[-f /etc/ypbind ] ; then /etc/ypbind; (echo -n ' ypbind') > /dev/console fi NIS+ 와 다른
데이터베이스 시스템 NIS+는 NIS의 결점을 보완하고 규모가 큰 네트워크 환경을 다룰 수 있도록 하기 위해 만들어
졌다.
NIS와 NIS+의 차이점을 말한다면 우선 NIS+는 NIS보다 더욱 데이터베이스의 성격을 가지는데 맵(이제는 테이블이라
불림)을 어떠한 필드를 가지고도 검색 할 수 있다는 점이 이를 나타낸다. NIS+는 더 이상 NIS와 같이 flat 파일을
사용하지 않는다. 슬레이브 서버를 다 루는데 NIS+가 NIS보다 더욱 좋다. NIS+는 썬의 secure RPC 시스템 위에서
구축되었기에 공유키(public-key) 암호화에 기반을 둔 인증을 가능케 한다. 실제 많은 차이점이 있음에도 불구하고
클라이언트 입장에서 보면 사실 NIS+ 는 다른 관리 데이터베이스 시스템과 거의 유사한 모습을 가진다. 모든 데이터 는
마찬가지로 라이브러리 루틴을 통해 접근 가능하며 결국은 하나의 유닉스 Flat 파일로 귀착되는 것이다. NIS+는
DNS와는
아무 상관이 없지만 DNS의 명칭부여 구조를 빌리고 있다. NIS나 NIS+ 이외에도 MIT의 Hesiod나 NeXT의 NetInfo
등의 데이터베이스 시스템이 있으나 그다지 널리 사용되고 있지 않다. MIT의 Hesiod는 관리자 데이터베이스를 분배하기
위해 DNS 프로토콜을 확장 한 것이고 NetInof는 NIS+와 매우 유사하지만 훨씬 간단하고 명확한 구조를 가진다. 여러
운영체계에서의 특정 사항 솔라리스의 경우 관리 데이터의 소스를 지정하기 위해 ‘/etc/nsswitch.conf’ 파일을
사용한다. 그 내용은 다음과 같다. passwd: files nisplus hosts: nisplus dns group: files ...
위에서
nisplus, nis, files, dns, conpat은 각각 NIS+, NIS, ‘+’같은 토큰을 없앤 파일, DNS , NIS화된 파일을
의미한다. 왼쪽에 대한 정보를 찾는 경우 오른쪽으로 진행하며 정보를 검색함을 의미하는 것이다. 또한 다음과 같이
소스에
이상이 생기는 경우에 대한 처리도 지정할 수 있다. hosts: dns [NOTFOUND=return] nisplus 자세한 조건에
대한 것은 아래 표에 나타내었다. --------------------------------------------------------------- 조
건
의 미 UNAVAIL 소스가 존재하지 않거나 다운됨 NOTFOUND 소스는 존재하나
질의에
응답할 수 없었음 TRYAGAIN 소스는 존재하나 busy 상태임 SUCCESS 소스가 질의에 응답할 수 있었음
--------------------------------------------------------------- HP-UX의 경우는 우선적으로 DNS를 이용하며
그
다음으로 NIS 그리고 나서 ‘/etc/hosts’파일을 이용한다. OSF/1의 DEC 버전은 NIS와 호환성이 있으며 탐색 순서는
‘/etc/svc.conf’ 파일에 지정된다. 이 파일의 원 이름은 ‘/etc/svcorder’이다. BSDI의 경우는 NIS를 지원하지
않는다. 대부분 ‘/etc/hosts’ 파일로 호스트를 참조하고 가능 하다면 네임서버도 이용한다. 마치며 이번 달에는 시스템
파일의 공유에 대해서 다루었다. 사실 지금까지 설명한 내용들을 제대로 활용하는 시스템이나 소규모 네트워크 를
필자는
별로 보지 못했다. 물론 이유는 보안이나 관리의 어려움 등의 여러 이유가 있을 수 있을 것이다. 하지만 대부분의
경우는
이러한 기능이 있는지 조차도 모르는 경우가 허다할 것이다. 설사 알고 있다 치더라도 이를 실제 시스템에 적용해본
관리자는 그리 많은 것 같지 않다. 여러분들이 제대로 된 시스템 관리자가 되고 싶다면 이런 기능들을 실제 적용해
보고
이를 분석하는 작업은 필수적이며 이러한 과정을 통해서만이 더 나은 시스템 구축이 가능해 질 것이다. 다음 호에는
SLIP/PPP 에 대해 진행하기로 하겠다. 필자 연락처：HiTEL-huclons 천리안 - huclons
..........
