III. 시스템 관리 I
1. 솔라리스 부팅과정의 이해
가. 유닉스 부팅의 개요
(1) 부팅이란?
컴퓨터에서 부팅이란 시작한다는 뜻으로 통용되는 용어이며, Bootstrapping 의 줄임말이다. Bootstrap이란 장화(부츠)를 손쉽게 신기 위해 잡아당길 수 있도록 되어 있는 손잡이가죽을 말하며, 결국 bootstrapping은 장화를 신듯이 시스템이 운영할 수 있는 준비를 하는 것을 뜻한다.
(2) boot 과정
일반적인 UNIX의 부팅 과정에서 진행되는 일은 다음과 같다.
- Kernel의 loading 과 initialization
- Device detection 과 configuration
- System process 의 생성
- Operator intervention(single-user boot에서만 가능함)
- System 시작 스크립트 수행
- Multi-user operation
x86 계열의 부팅과정으로, 보다 구체화시키면 다음과 같다.
- 전원이 들어오면 일단 BIOS가 시스템 하드웨어에 문제가 없는지 테스트한다.
- 첫 번째 하드디스크의 MBR(Master Boot Record)의 프로그램이 Partition Table을 검사하여 활성화(active)된 파티션의 부트섹터를 읽어 그 코드를 실행한다. 해당 코드는 커널을 메모리로 읽어 들이는 역할을 한다.
- 커널은 자료구조를 초기화하고 필요한 커널 모듈을 읽어 들인다.
- Root file system 을 mount 한다.
- init 프로그램을 수행한다(init 프로그램이 다양한 스크립트를 수행하여 multi-user mode로 전환하게 된다).
(3) 초기 프로세스의 생성
커널이 메모리에 올라오고 초기화 작업이 끝나는 시점에서 사용자 메모리 영역에 몇 개의 자발적(spontaneous) 프로세스(fork와 같은 방법으로 만들어지는 것이 아닌 프로세스)를 만든다. BSD계열에서는
- swapper : process 0
- init : process 1
- pagedaemon : process 2
등이며, System V 계열에서는
- sched : process 0
- init : process 1
- memory handler(각 시스템마다 차이가 있음)
등의 이름을 가지고 있다. 몇몇 초기 프로세스의 생성이 끝나면, 부팅 에 관한 커널의 임무는 여기서 끝나고 나머지 부팅 과정은 init process 가 주도한다.
(4) 시작 스크립트
init 는 각종 스크립트를 수행하여 시스템 운영 환경을 구축한다. 스크립트의 수행구조는 BSD계열과 System V 계열이 약간 차이가 있다.
BSD계열은 /etc 하위에 rc로 시작하는 파일들이 수행되는 스크립트이며, System V계열은 /etc/init.d 하위에 시작 스크립트들이 존재하고 이중 필요한 것들이 /etc/rc0.d, /etc/rc1.d 등의 디렉토리에 링크되어 사용된다.
어떤 시스템이든 시작 스크립트는 대략 다음과 같은 일들을 한다.
- 컴퓨터의 이름 setting
- time zone setting
- 시스템의 디스크들을 mount
- network interface를 configuration
- 각종 daemon 과 network service를 시작
우리는 솔라리스가 따르고 있는 System V 방식의 시작 스크립트에 대해 자세히 알아보도록 하겠다.
(5) run level
System V 계열의 init daemon 은 run level 이라는 것을 지원한다. Run level은 시스템 자원을 서로 다르게 조합하여 운영하는 것을 가능케 하는데 시작 스크립트도 이에 따라 여러 부분으로 나누어져 있다.
System V에서는 다음과 같이 8개의 run level 을 제공한다.
|
Run Level |
Functionality |
|
0 |
Power down state : 시스템과 주변장치의 power 를 내려도 안전한 레벨 |
|
1 |
System Administration state : 다른 log-on 한 사용자에게 영향을 주지 않고 관리 업무를 수행할 때 사용 |
|
2 |
Multiuser mode : NFS 외의 모든 서비스가 제공되는 상태 |
|
3 |
Networked Multiuser mode : 일반적인 operating mode |
|
4 |
Alternative Multiuser mode : 현재 사용되지 않는 run level |
|
5 |
Firmware state : maintenance activity를 위해 사용 |
|
6 |
Shutdown and reboot state : 보통상태에서 reboot 할 때 사용 |
|
S |
Single-user mode |
나. 솔라리스의 부팅
(1) 솔라리스 부팅의 개요
솔라리스는 다음과 같은 네 단계를 거쳐 부팅이 수행된다. 일단 BIOS 단계에서 시스템의 하드웨어적인 이상유무를 판단하고, MBR을 읽어 들이고, 커널을 인식시킨 후에 init 프로세서를 통해 부팅을 마무리하게 된다. 그럼 각 과정에 대해 조금 더 깊이 들어가 보자.
(2) BIOS 단계
시스템의 전원을 켰을 때 BIOS 는 시스템에 H/W와 메모리를 검사하기 위해 Self-test를 실시한다. 에러가 발견되지 않았을 경우, BIOS는 첫 번째 부트섹터(MBR)에 저장된 mboot를 메모리에 적재하고 수행한다.
(3) boot program 단계
mboot는 활성화(active)된 파티션을 찾아서, pboot를 메모리에 적재하고 수행시킨다. 그리고 pboot는 디스크 안에 있는 secondary boot program을 메모리에 적재하기 위한 primary boot proram인 bootblk을 메모리에 적재한다. 기본적으로 파란 화면에서 10초간 기다리도록 설정되어 있는데, 부팅 가능한 파티션이 여러 개라면 이 화면에서 선택하여 부팅을 할 수 있다. Bootblk는 secondary boot program 인 boot.bin 이나 ufsboot 를 찾아 수행하는데, boot.bin 이나 ufsboot는 /etc/bootrc 스크립트를 수행하기 위해 command interpreter를 시작한다.
(4) 커널 인식 단계
core kernel 이 메모리에 올라온 이후 자신의 데이터 구조를 초기화하고, 모듈들을 메모리에 적재한다. 필요한 모듈을 불러온 이후에 커널은 /sbin/init 프로그램을 수행한다.
(5) init 단계
커널에서 init를 호출한 이후부터는 init 프로세스가 /etc/inittab 파일의 내용을 바탕으로 마지막 부팅 작업을 하기 시작한다.
각 run level 별로 수행되는 디렉토리와 파일을 알아보고, 특히 우리가 일반적으로 사용하는 run level 3 이 수행되는 경우에 대해서 알아보도록 하자.
/etc/ 디렉토리 아래에는 다음과 같은 파일들이 존재하는데 그림으로 알아보도록 하자.
|
MEMO:
|
그림 40) init 개념도
run level 들이 명시되어 있는 파일인 /etc/inittab 파일을 조금만 살펴보도록 하자.
|
sS:s:wait:/sbin/rcS >/dev/msglog 2<>/dev/msglog </dev/console s0:0:wait:/sbin/rc0 >/dev/msglog 2<>/dev/msglog </dev/console s1:1:respawn:/sbin/rc1 >/dev/msglog 2<>/dev/msglog </dev/console s2:23:wait:/sbin/rc2 >/dev/msglog 2<>/dev/msglog </dev/console s3:3:wait:/sbin/rc3 >/dev/msglog 2<>/dev/msglog </dev/console s5:5:wait:/sbin/rc5 >/dev/msglog 2<>/dev/msglog </dev/console s6:6:wait:/sbin/rc6 >/dev/msglog 2<>/dev/msglog </dev/console |
위의 내용은 /etc/inittab 파일의 중간 부분을 발췌한 것이다. 눈치가 빠른 사람은 금방 알아챘겠지만, s3로 시작하는 부분이 run level 3일 경우에 관련된 부분이다. 따라서 run level 3일 경우에 /sbin/rc3를 실행하게 된다.
물론 inittab 파일 안에 보면 전후에 실행되는 default 필드들이 있으나 여기서는 생략하도록 하겠다.
그럼 /sbin/rc3 파일을 살펴보도록 하자.
|
if [ -d /etc/rc3.d ]; then for f in /etc/rc3.d/K*; do if [ -s $f ]; then case $f in *.sh) . $f ;; *) /sbin/sh $f stop ;; esac fi done for f in /etc/rc3.d/S*; do if [ -s $f ]; then case $f in *.sh) . $f ;; *) /sbin/sh $f start ;; esac fi done fi |
위의 파일 역시 중간 부분을 발췌하였다. 이 부분은 /etc/rc3.d 디렉토리의 여러 데몬들을 구동시키는 스크립트인데, 보는 바와 같이 /etc/rc3.d 디렉토리의 파일들 중에 S로 시작하는 파일에는 start 인수를 넘겨서 시작하도록 하고, K로 시작하는 파일들은 stop 인수를 넘긴다. 한번 자신의 /etc/rc3.d 디렉토리를 살펴보고 파일명을 살펴보도록 하자.
(6) run level 바꾸기
run level 을 바꾸는 방법에는 여러 가지가 있다. 그 중에 유용하게 쓰이는 init 명령을 살펴보도록 하자.
지금 우리가 디스크에 문제가 생겨서, single-user mode 로 부팅을 했다고 가정하자. 문제를 해결하고 원래대로 부팅을 하고 싶은데 우리는 reboot 작업을 거쳐야 할까? 물론 아니다. 다음과 같이 명령을 내리면 된다.
# init 3
위의 명령으로 run level 3로 들어가게 할 수 있다.
숫자 부분에 올 수 있는 인수로는 0, 1, 2, 3, 4, 5, 6, s 가 있다.
2. 사용자 계정 관리
관리자가 해야할 일 중에 가장 기본적이라고 할 수 있는 것이 바로 사용자의 계정을 관리하는 것이다. 관리자는 필요한 계정을 등록 해야하고 필요하면 삭제도 해야한다. 여기서는 이러한 계정 등록과 삭제에 관한 내용을 살펴볼 것이다.
가. 사용자 계정 등록하기
사용자 계정을 등록하는 방법에는 여러 가지가 있지만 그 중에서 두 가지를 여기서 설명하겠다. 먼저 GUI환경에서 제공해주는 admintool이라는 명령어를 이용하여 등록이 가능하며 useradd라는 터미널 상에서의 명령어를 사용해서 계정을 등록할 수도 있다. 일반적으로 관리자는 admintool은 한 두 명의 사용자를 등록하기에는 편리하지만 여러 명의 계정을 등록하려면 아무래도 useradd명령어를 사용해서 하는 것이 더 편리하다.
(1) admintool
admintool을 사용하는 것은 해당 메뉴를 보면 사용하기가 쉬울 것이다. Admintool을 수행하면 3개의 풀다운 메뉴가 보일 것이다.
File은 하위 메뉴로 종료(Exit)하는 기능의 메뉴가 있으며
Edit는 창에 있는 항목을 선택하여 추가(Add), 수정(Modify), 삭제(Delete)하는 기능의 메뉴가 있고 Browse 메뉴가 어떠한 기능을 제공하는지 다음 표에 나와있다.
|
메뉴 |
기능 |
|
사용자 |
사용자 추가, 수정 및 삭제 |
|
그룹 |
그룹 추가, 수정 및 삭제 |
|
호스트 |
호스트 추가, 수정 및 삭제 |
|
프린터 |
프린터 추가, 수정 및 삭제 |
|
직렬 포트 |
직렬 포트 추가, 수정 및 삭제 |
|
소프트웨어 |
패키지 관련 소프트웨어 추가, 수정 및 삭제 |
(2) useradd
useradd는 터미널 모드에서 사용하는 명령어로써 자주 사용되는 옵션은 숙지하여야 한다.
useradd [-c comment] [-d dir] [-e expire] [-f inactive] [-g group]
[-G group [, group...]] [-m [-k skel_dir]] [-u uid [-o]] [-s shell]
[-P profile [, profile...]] login
useradd 명령어의 사용 예를 보자.
#useradd -c Superman -d /data/home/jo -s /usr/bin/csh -g 100 -u 1001 -m jo
#useradd -d /data/home/jo -s /usr/bin/csh -g users -m jo
일반적으로 사용되는 옵션을 이용해서 사용자를 등록한 예이다. -m 옵션은 홈 디렉토리가 존재하지 않을 경우 생성시키는 옵션이다. 모든 옵션을 생략하고 다음과 같이 간단히 사용자를 등록할 수도 있다.
# useradd jo
이렇게 하면 단지 jo라는 사용자 계정만 만들어질 뿐이고 홈디렉토리는 만들어지지 않는다. UID는 가장 큰 UID다음번호가 등록이 되며 GID는 1(other)로 등록이 된다. 그리고 쉘은 본쉘(/bin/sh)이 기본적으로 세팅이 된다.
등록해야할 사용자가 많을 경우에는 간단한 쉘 스크립트를 사용하여 사용자 등록을 자동적으로 해줄 수도 있다. /etc/passwd에 단순히 편집모드에서 사용자를 추가했을 경우에도 계정 등록이 가능하다 하지만 /etc/shadow에도 추가되어야 하므로 다음과 같은 명령어를 사용하여 /etc/shadow에도 추가해준다.
# pwconv
pwconv(/bin/pwconv)명령어는 /etc/passwd파일을 참조하여 /etc/shadow파일을 갱신해준다.
나. 사용자 계정 삭제하기
유효기간이 지난 사용자나 필요 없는 사용자가 존재하면 가능하면 보안상 즉시 삭제를 해주는 것이 좋다. 삭제하는 방법은 마찬가지로 ??admintool??을 사용할 수도 있지만 여기서는 ??userdel??이라는 명령어를 사용하겠다.
# userdel [-r] login
-r 옵션은 사용자가 사용했던 홈 디렉토리까지 삭제하라는 옵션이다.
삭제 후 제대로 삭제되었는지를 확인하려면 /etc/passwd와 /etc/shadow를 확인해서 해당 login id가 존재하는지를 확인해보면 된다.
다. 그룹 추가하기
그룹추가도 마찬가지로 적은 수의 그룹 관리이면 ??admintool??을 사용해도 무난하다. 만일 그룹수가 많아지면 ??groupadd??라는 명령어를 사용한다.
groupadd [-g gid [-o]] group
'-g gid'옵션은 GID(정수)를 써주는 부분이며 -o 옵션은 GID의 중복 사용을 허용해주는 옵션이다.
# groupadd -g 100 solaris
이렇게 solaris라는 그룹이 100이라는 GID로 등록이 되며 이는 /etc/group에 저장이 된다.
/etc/group이라는 파일을 보면 네 개의 필드가 존재한다. 첫 번째 필드는 그룹명, 두 번째 필드는 passwd, 세 번째 필드는 그룹의 실제 ID(GID), 네 번째 필드는 해당 그룹의 사용자 목록이다.
라. 그룹 삭제하기
그룹 삭제는 ??groupdel??이라는 명령어를 사용하면 된다. 사용법은 다음과 같다.
groupdel group
여기서 group은 그룹명을 적어주면 된다.
마. 사용자 패스워드
패스워드 파일(/etc/passwd)은 사용자들에 대한 정보를 지닌 파일로 각 라인마다 7개의 필드로 구성되어 있다.
[사용자 계정]:[암호]:[사용자 ID]:[그룹 ID]:[주석]:[홈 디렉토리]:[로그인 쉘]
위에서 jo라는 계정을 만들었을 때 /etc/passwd에는 다음과 같이 추가가 된다.
jo:x:1001:100:Superman:/data/users/jo:/usr/bin/csh
여기서 암호필드에 x라고 되어있는데 이는 shadow 파일을 사용하겠다는 의미이다. 예전에는 이곳에 사용자 암호를 암호화한 내용이 들어있었지만 보안상의 문제로 요즘에는 보통 /etc/shadow에 넣어둔다. 그리고 이 shadow파일은 일반사용자는 열람이 불가하게 기본 설정이 되어있다. 나머지 필드는 이해하는데 별 어려움이 없을 것이다. 참고로 주석(comment) 필드는 생략 가능하다.
passwd파일에서 UID가 0이면 root(관리자)를 의미하며, UID와 사용자 계정은 중복해서 사용할 수가 없다. 또한 UID, GID는 항상 숫자로 나타내어야 한다.
3. 솔라리스 /etc 디렉토리
★ 이전의 시스템 정보를 다시 반영시키기 위해 백업이 필요한 파일목록
① /etc/group(현재 사용자들의 그룹 정보)
② /etc/passwd(현재 사용자들의 이용자 번호와 홈디렉토리 정보)
③ /etc/shadow(현재 사용자들의 암호가 암호화되어 있음)
④ /etc/hosts(서비스를 받을 수 있는 클라이언트들의 정보)
⑤ /etc/vfstab(현재 mount 되어 있는 파일시스템의 정보)
⑥ /etc/dfs/dfstab(file system sharing service 위치 정보)
⑦ /etc/dfs/sharetab(file system sharing service 위치 정보)
⑧ /opt/SUNWspro/license_dir/sunpro,lic.1(C 컴파일러등의 라이센스 정보)
⑨ /etc/opt/licenses_combined(C 컴파일러등의 라이센스 정보)
⑩ /etc/init.d에서 필요한 파일들(부팅시 필요한 실행파일들)
⑪ /etc/rc0.d ～ /etc/rc4.d에서 필요한 스크립트 파일들
⑫ /etc/networks(network 정보)
⑬ /etc/defaultrouter(기본 router 의 정보)
⑭ /etc/netmasks(netmask 정보)
⑮ /etc/resolv.conf(name server 정보)
? /.cshrc 및 /.login(root 가 가지는 C-shell 정보 및 login 정보)
? /etc/skel에 있는 .* 파일들(사용자 생성시 자동으로 복사되는 .cshrc 파일과 .login 파일, 이름이 각각 .cshrc 및 .login, .profile로 되어 있어야 함) .cshrc 은 사용자의 shell을 C로 설정했을 때 자동으로 복사가 되는 파일이며, .profile 은 사용자의 shell을 Bourne으로 설정했을 때 복사되는 파일이다. 선택적으로 복사가 되기 때문에 두 가지 다 넣어주는 것이 바람직하다.
4. 솔라리스 파일 시스템
가. 정의
UNIX 파일 시스템은 데이터를 체계적으로 구성하기 위한 부분
계층적 트리 구조로 이루어져 있기 때문에 정보의 저장이나 검색이 용이
나. 종류
(1) 일반 파일 (Ordinary file)
일반적으로 정보를 저장하기 위한 수단으로 이용되는데 이것은 OS 에 의해 특수한 구조를 갖지 않는 파일을 지칭한다.
Execution file, source program file, text file, data file 등이 있음.
(가) 텍스트 파일 (text file)
알파벳, 숫자, 특수문자, 제어문자, 한글문자 등으로 구성되어진 파일들로 원시 프로그램이나 쉘 프로그램 파일들이 이에 해당된다.
단말기나 프린터를 통하여 파일의 내용을 볼 수 있다.
(나) 이진 파일 (binary file)
원시 프로그램으로부터 어셈블(assemble)하거나 컴파일(compile)하여 만들어진 실행 가능한 파일 혹은 일정한 형식을 지닌 데이터 파일들이 이에 해당된다.
파일의 내용이 단말기나 프린터를 통해 표시되지 않는다.
내용을 보기 위해서는 OD(Octal Dump)라는 명령어를 이용한다.
(2) 디렉토리 파일 (Directory file)
자신의 밑에 다른 파일들을 포함하고 있는 파일들을 말한다.
다른 파일들과 디렉토리들에 관한 정보를 저장하는 논리적 영역이며 계층적 트리 구조로 이루어져 있다.
/bin, /dev, /etc, /tmp, /lib, etc.
(가) 디렉토리(Directory) 체제
root directory : /
UNIX O.S. 자신 : HOME
현재 자신의 directory : .
자신의 한 단계 위 directory : ..
(나) 대표적인 Directory 파일
/bin : UNIX의 기본 커맨드 파일들이 위치한다. 기본적인 실행 가능한 명령파일을 가지고 있는 디렉토리로 대표적 파일로는 cat, cp, date, echo, mv, pwd, who, rm 등 많은 파일이 있다.
/dev : 장치 파일들이 있는 디렉토리 즉, 시스템의 모든 입/출력 파일을 가지고 있는 디렉토리로 대표적 파일로는 console, lp, tty 등의 파일이 있다.
/etc : 시스템에서 사용하는 많은 관리 파일(administrative file)을 가지며 대표적 파일로는 chmod, init, getty, mknod, motd, passwd, rc, wall 등의 파일이 있다.
/tmp : 프로그래머들이 임시파일을 만들기 위해 사용하며, man, queuer 등의 파일이 있다.
/lib : 기본적인 프로그램 모듈들이 있는 디렉토리로 cpc, libc.a, popt, spopt 등의 파일이 있다.
/ : UNIX 커널의 실행화일 및 시스템 관리에 중요한 .login, .profile 등의 파일이 포함된다.
/usr : 일반적으로 시스템 관리자의 파일들이 배치한다.
/usr/bin : 워드, 데이터 베이스관리 프로그램들과 개발된 프로그램 등이 포함된다.
/export/home : 사용자들의 홈 디렉토리로서 대표적으로 지정하는 것이나 시스템을 설치할 때 다른 곳으로 정해줄 수도 있으며 사용자계정을 만들 때에 다른 곳으로 만들어 줄 수도 있다.
/usr/include : C언어의 header 파일들이 포함된다.
/usr/man : UNIX의 매뉴얼이 위치한다.
/usr/spool : CPU와 주변장치를 중첩하여 수행시키기 위하여 주변장치로 출력되는 데이터 파일들을 임시로 저장하는 스풀용의 디렉토리다.
/usr/adm : UNIX의 사용자와 프로세스의 작동을 monitor하는 accounting error reports 같은 프로그램들이나 데이터 파일들이 포함된다.
/opt : UNIX에서 이용하는 C 컴파일러 같은 응용프로그램과 license 관리에 필요한 모든 정보가 들어가는 디렉토리이다. 따라서 아주 중요한 디렉토리이므로 정기적으로 백업하는 것이 좋다.
(3) 특수 파일 (Special file)
주변장치에 접근하는 파일들을 말한다.
일반 파일이 사용자에 의해 만들어진 정보를 그 내용으로 하는 것과는 달리 특수 파일은 입출력 주변장치인 disk, tape drive, line printer, terminal 등에 액세스 할 수 있는 채널을 마련하는 정보를 담고 있는 파일이다.
모든 입출력 장치가 UNIX와 연결되기 위해서는 적어도 하나 이상의 특수파일을 가져야 한다.
특수 파일들은 대부분 /dev 디렉토리에 존재한다.
이곳에는 입출력장치의 제어기를 이곳에서 맞추어 장치를 연결할 수 있게 한다. 예를 들면 /dev/tty12는 12번 터미널을 의미한다. 이곳에서는 자신이 가지고있는 장치가 /dev 디렉토리내의 어떤 형식의 장치를 가지고 있는가를 알고만 있어도 장치를 인식할 수 있다.
다. 파일명과 경로명
UNIX 시스템의 파일명은 255문자이내에서 사용 가능하다. 주의할 것은 대?소문자를 구별한다는 것이다. 또 한가지 "." 나 “_”로 시작되는 파일명은 시스템 파일들이 많이 사용하기 때문에 사용하지 않는 것이 바람직하다.
UNIX 시스템에서 원하는 디렉토리 아래의 파일에 접근하고 실행하려면 패스를 지정해 주어야 한다.
(1) 상대경로(relative path)
만약 현재의 /a에서 a1으로 이동하려고 할 때 cd a1라고 입력하면 된다. 또한 /a/a1에서 /a/a2로 이동하려고 할 때 cd ../a2라고 입력하면 된다. 이때 쓰이는 방식이 상대경로 이동방식이다.
(2) 절대경로(absolute path)
만약 현재의 /a/a1에서 /a/a2로 이동하려고 할 때 cd /a/a2라고 입력하면 된다. 이때 쓰이는 방식이 절대경로 이동방식이다.
그림 41) 디렉토리 경로
5. NFS (Network File System)
가. NFS란?
NFS란 Network File System의 약자로서 1980년대에 썬 마이크로시스템즈에서 처음 개발되었고, 현재 리눅스나 솔라리스와 같은 유닉스를 비롯하여 윈도95/98과 윈도2000과 같은 운영 체제에서 널리 사용되고 있다. 그럼 NFS란 무엇인가? 간단히 말해서 어떤 한 시스템(클라이언트)에서 다른 시스템(서버)의 자원을 자신의 자원처럼 사용이 가능하도록 하는 것을 말한다. 이렇게 사용함으로써 자원의 낭비를 줄이고 효율적인 운영을 할 수 있기 때문이다. 리눅스를 어느 정도 다루었던 사람들은 NFS에 대한 개념을 쉽게 잡을 수 있을 것이다. 솔라리스에서의 NFS도 다를 바가 없다. 다만 설정 상에 약간 차이가 있을 뿐이다.
NFS에 대한 개념도를 [그림 3]에 나타내었다. 그림에서는 NFS서버의 공유된 자원으로 디스크를 예로 설명된 것이다. 물론 디스크가 아니라 CD-ROM과 같은 것도 가능하다. NFS를 사용하려면 서버와 클라이언트 양쪽에서 몇 가지 설정이 필요하다. 서버의 설정이 완료되면 지정된 클라이언트에서는 단지 마운트를 통해 NFS서버의 자원을 자신의 자원인양 똑같이 사용하는 것이 가능하다. 이러한 NFS는 좋기만 한 것은 아니다. NFS로 서버와 클라이언트가 연결되어 있으면 NFS서버의 자원에 접근할 때마다 네트웍 트래픽이 걸리므로 속도면에서 많은 손실을 감안해야 한다는 점이다.
그림 42) NFS 개념도
NFS는 여러 명이 같이 사용되는 대용량 프로그램이나 데이터들을 하나의 호스트에 넣어 두고 각 클라이언트들은 이 호스트의 데이터가 들어있는 디렉토리를 마운트하여 사용한다. 따라서 디스크 공간 면에서도 많은 절약을 가져올 수 있으며 각 각의 클라이언트마다 동일한 프로그램을 설치할 필요성도 없어지므로 관리 면에서도 매우 편리해 진다. 그럼 NFS를 운영하기 위해서 NFS서버와 클라이언트에 필요한 데몬에 대해서 살펴보면 다음과 같다.
|
|
(1) NFS 서버에서 사용되는 데몬
|
데몬 |
설명 |
|
/usr/lib/nfs/nfsd |
클라이언트의 파일시스템 요청을 처리한다. |
|
/usr/lib/nfs/mountd |
NFS 접근정보에 대한 요청과 파일시스템 마운트 요청에 대해 응답을해주는 RPC 서버이다. |
클라리언트가 NFS서버에 접근 요청을 하면 제일 먼저 mountd 데몬이 수행되어 /etc/dfs/sharetab파일을 참조한다. nfsd가 돌고 있다면 mountd를 꼭 데몬으로 실행해 주어야 정상적으로 NFS서버를 운영할 수 있다.
위의 데몬들은 모두 NFS서버를 사용하기 위해서는 필수적인 데몬들이며 run level 3에서 /etc/rc3.d/S15nfs.server라는 스크립트를 통해서 실행되며 이는 /etc/init.d/nfs.server와 같은 스크립트이다.
(2) NFS 클라이언트에서 사용되는 데몬
|
데몬 |
설명 |
|
/usr/lib/nfs/statd |
lockd 데몬과함께 NFS에서의 locking 서비스를제공하기위하여 crash 또는 recovery 기능을제공한다. |
|
/usr/lib/nfs/lockd |
NFS lock기능을담당하는데몬이며, statd 데몬이모니터링서비스가가능하도록한다. |
위의 데몬들 또한 NFS서버에 접근하기 위해서 필수적인 NFS 클라이언트 데몬들이다. 이들은 모두 run level 2에서 /etc/rc2.d/S73nfs.client라는 스크립트를 통해서 실행되며 이 파일은 /etc/init.d/nfs.client와 같은 것이다.
나. NFS 서버
NFS 서버란 공유목적으로 파일 시스템과 같은 자원을 원격 호스트에게 네트웍을 통하여 제공하는 시스템을 말한다. NFS 서버를 세팅하기 위해서는 우선 공유하고자 하는 파일 시스템을 선택하고 이를 클라이언트가 NFS로 사용하도록 공유를 해줘야 한다. 공유하는 방식에 따라 수동 공유와 자동 공유가 있다.
(1) 수동 공유
수동 공유 설정은 'share'(/usr/bin/share)라는 명령어를 사용하며 'share'에 대한 사용법은 다음과 같다.
share [-F FSType] [-o specific_options] [-d description] [pathname]
-F : 파일 시스템 형태를 적어준다. 기본적으로 nfs로 인식한다. 따라서 command에서는 생략 가능하다.
-o : 클라이언트가 서버의 공유자원에 접근할 때 사용제한에 대한 옵션을 적어준다.
rw=client[:client]... ; 읽기와 쓰기 가능, client에는 네트웍 호스트 이름이나 ip를 입력
ro=client[:client]... ; 읽기만 가능
root=client[:client]... ; 지정된 클라이언트에게 root 퍼미션으로 해당 자원을 공유
anon=uid ; 지정된 uid로 해당 자원을 공유
-d description : 공유 자원을 설명하는 주석
pathname : NFS 서버측 공유자원의 절대 경로명
클라이언트의 루트 사용자가 만일 NFS 서버의 공유 자원에 쓰기를 하면 어떠한 UID와 GID로 기록이 될까? 언뜻 생각하면 보통과 같이 root:other(0:1)이라고 생각하기가 쉽지만 실제로 해보면 이렇게 기록이 되질 않는다. NFS 서버측에서는 클라이언트의 root를 nobody(uid=60001)로 인식을 하기 때문에 nobody:other로 기록이 된다. 만일 root의 uid가 0인 상태로 NFS서버로 접근하기를 원한다면 위에서 기술한 anon=0이라는 항목을 추가하면 된다.
다음 예는 share 와 unshare 에 대한 가장 간단한 사용법을 설명한 것이다. 여기서는 임시적으로 /data 라는 디렉토리를 만들어 공유를 하였다. 공유 옵션은 사용하지 않았지만 기본적으로 rw 옵션이 설정된다. 단순히 share 라는 명령을 실행시키면 공유정보를 출력시켜준다. 하지만 아직 NFS 서버가 동작하는 것은 아니다. NFS 서버상에 현재 공유가 수행되는지에 대한 정보를 보려면 dfshares 라는 명령어를 사용하면 된다. 아직 NFS 서버 데몬이 실행이 안되었으므로 dfshares 명령어를 실행하면 프로그램이 아직 등록이 안되었다고 나올 것이다. /etc/init.d/nfs.server start 라는 명령어로 NFS 서버 데몬을 실행시키면 이제부턴 NFS 클라이언트에서 마운트를 통해 서버의 공유 자원을 사용할 수가 있게 된다. 공유가 더 이상 필요하지 않게 되면 unshare 라는 명령어로 공유를 해지하고 데몬을 없애는 것은 /etc/init.d/nfs.server stop 라고 하면 된다.
share 명령어로 NFS 서버의 자원을 공유하면 해당 정보가 /etc/dfs/sharetab 에 자동 저장되며 클라이언트가 접근을 하면 이 파일을 참조하여 허용 여부를 판단한다. 또한 share 를 아무 옵션 없이 사용하면 자신의 공유 정보를 화면에 나타내 준다. 다음 표는 공유와 관련된 명령어들을 요약 정리한 것이다.
|
명령어 |
기능 |
|
share |
현재의공유정보를출력해주며자원을공유하는데사용된다. |
|
shareall |
/etc/dfs/dfstab를참조하여리스트되어있는자원을공유한다. |
|
unshare |
명시된경로에대해서 NFS 공유를모두해제시킨다. |
|
unshareall |
/etc/dfs/dfstab에명시된공유리스트를모두해제시킨다. |
다음 예는 share와 unshare에 대한 가장 간단한 사용법을 설명한 것이다. 여기서는 임시적으로 /data라는 디렉토리를 만들어 공유를 하였다. 공유 옵션은 사용하지 않았지만 기본적으로 rw옵션이 설정된다. 단순히 share라는 명령을 실행시키면 공유정보를 출력시켜준다. 하지만 아직 NFS 서버가 동작하는 것은 아니다. NFS 서버 상에 현재 공유가 수행되는지에 대한 정보를 보려면 dfshares 라는 명령어를 사용하면 된다. 아직 NFS 서버 데몬이 실행이 안되었으므로 dfshares 명령어를 실행하면 프로그램이 아직 등록이 안되었다고 나올 것이다. /etc/init.d/nfs.server start 라는 명령어로 NFS 서버 데몬을 실행시키면 이제부턴 NFS 클라이언트에서 마운트를 통해 서버의 공유 자원을 사용할 수가 있게 된다. 공유가 더 이상 필요하지 않게 되면 unshare라는 명령어로 공유를 해지하고 데몬을 없애는 것은 /etc/init.d/nfs.server stop이라고 하면 된다.
|
# cd / # mkdir /data # share /data # share - /data  rw "" # cat /etc/dfs/sharetab /data -  nfs  rw # dfshares nfs dfshares:sola: RPC: Program not registered # /etc/init.d/nfs.server start # dfshares RESOURCE  SERVER ACCESS TRANSPORT sola:/data sola - - # unshare /data # /etc/init.d/nfs.server stop |
옵션을 사용한 NFS 공유는 나중에 다시 다룰 것이다.
(2) 자동 공유
지금까지는 기본적으로 share라는 명령어를 사용하여 직접 공유를 수행하였다. 이렇게 수행된 자원 공유는 재부팅이 되면 공유된 정보가 사라지게 된다. 따라서 재부팅이 되어도 자동으로 공유가 되도록 하기 위해서는 /etc/dfs/dfstab 파일에 공유 정보를 입력해주면 된다. 그럼 run-level 3로 들어갈 때에 dfstab 파일의 정보를 참조하여 공유를 수행한다.
dfstab파일에 공유 정보 입력은 위에서 share 명령어를 사용했던 문장을 그대로 입력해 주면 된다. 다만 -F nfs 옵션은 꼭 써주어야 한다. 위에서 설명한 예를 가지고 dfstab파일을 작성해 보면 다음과 같다.
|
# cd /etc/dfs # ls -F dfstab  fstypes  sharetab # vi dfstab share -F nfs /data |
이렇게 작성된 공유는 아직 NFS 클라이언트에서 마운트를 할 수 없다. 위에서 설명한 shareall이라는 명령어를 사용하여 자원을 공유해줘야 한다. shareall은 /etc/dfs/dfstab에 들어있는 공유 정보를 가지고 공유를 실행한다. 수동 공유 때와 마찬가지로 공유를 수행한 다음 만일 현재 NFS 서버 데몬이 실행중이 아니라면 /etc/init.d/nfs.server start라는 명령어로 데몬을 실행시켜주어야 한다.
다. NFS 클라이언트에서 할 일
(1) 수동 마운트
NFS 서버의 공유 내용들을 클라이언트에서 사용하려면 서버에서 공유된 자원을 마운트 해야 한다. 마운트할 때 사용되는 명령어는 mount 이며 기본 사용법은 다음과 같다.
mount [ -F nfs ] [ -r ] [ -o specific_options ] server:pathname mount_point
-r : 읽기만 가능하게 마운트
-o : 일반적인 마운트 옵션 외에 NFS에서만 적용되는 옵션을 기술
마운트가 수행되면 해당 정보는 /etc/mnttab에 저장이 되며 마우트를 수행하는 시스템(NFS 클라이언트)에서는 해당 디렉토리에 접근할 때에 위의 파일내용을 참조한다.
간단한 마운트에 대한 예제를 전 장에서 설명된 NFS 서버에서 설정된 사항을 바탕으로 설명하겠다. NFS 서버의 도메인을 sola라하고 공유된 디렉토리는 /data라고 하면, 다음 예와 같이 마운트를 하면 된다. 여기서 sola 대신에 NFS서버의 ip주소를 입력해도 무관하다.
|
# cd / # mkdir /data # mount sola:/data /data # df k Filesystem kbytes used avail capacity Mounted on /dev/dsk/c0t1d0s0 4030518 58355 3931858 2% / /dev/dsk/c0t1d0s3 4030518 686733 3303480 18% /usr /proc 0 0 0 0% /proc fd 0 0 0 0% /dev/fd mnttab 0 0 0 0% /etc/mnttab swap 523576 0 523576 0% /var/run swap 523904 328 523576 1% /tmp /dev/dsk/c0t1d0s6 983349 217537 706812 24% /opt /dev/dsk/c0t0d0s7 8286045 304548 7898637 4% /export/home /dev/dsk/c0t1d0s4 4030518 1 3990212 1% /usr/local sola:/data 3007086 70853 2876092 3% /data |
마운트 대상 디렉토리는 로컬 시스템에서 항시 비어있어야 한다. 만일 내용이 있는 디렉토리를 마운트를 하면 에러가 발생할 수도 있으며 순조롭게 마운트가 수행되는 경우도 있다. 이것은 해당 디렉토리에서 어떠한 작업이든 사용중이면 장치 사용 중이라는 메시지가 나오며 마운트가 실패된다. 만일 장치가 사용중이 아니라면 마운트는 수행이 되며 원래의 디렉토리에 들어있던 내용은 보이질 않게 된다. 하지만 지워지는 것은 아니니 안심해도 된다. 나중에 umount를 사용해서 마운트를 해제하면 원래의 파일들을 다시 볼 수 있을 것이다.
|
# cd / # mount sola:/data /opt nfs mount: mount: /opt: 장치 사용 중 |
(2) 자동 마운트
수동으로 마운트 된 것은 시스템을 재부팅하면 마운트 정보가 사라지게 된다. 재부팅이 되어도 마운트 정보를 보존하고자 하면 /etc/vfstab라는 파일에 해당 마운트 정보를 입력하면 된다. /etc/dfs/dfstab과는 달리 여기에는 명령형태로 입력하는 것이 아니라 입력 방식이 따로 있다. 해당 파일을 열면 아마도 기존의 마운트 정보가 입력되어 있을 것이며, NFS 마운트 정보를 다음 예와 같이 추가하면 된다. 입력 시 주의할 점은 각 간격을 모두 tab으로 해야 한다는 점이다.
|
# cd /etc # cat /etc/vfstab
sola:/data - /datanfs - yes - |
라. NFS 설정 예제
이번 절은 이제까지 설명된 내용을 바탕으로 몇 가지 옵션을 주고 NFS 서버와 클라이언트를 실제로 설정을 해보도록 하겠다. 다음 표는 예제로 사용될 NFS 서버와 클라이언트에 대한 정보이다.
|
|
호스트명 |
IP 주소 |
|
NFS 서버 |
sola1 |
192.168.1.194 |
|
NFS 클라이언트 |
sola2 |
192.168.1.195 |
|
sola3 |
192.168.1.196 |
(1) NFS 서버
서버에서의 공유 자원으로는 /data/user1, /data/user2, /data/user3, /data/user4로 하며 모든 작업은 root권한으로 한다. 각 디렉토리는 서로 다르게 공유 옵션을 주었으며 해당 옵션에 대한 설명은 아래 표에 하였다.
|
sola1# cd / ; mkdir data sola1# mkdir user1 user2 user3 user4 sola1# vi /etc/dfs/dfstab share F nfs /data/user1 share F nfs o ro=sola2,rw=sola3 /data/user2 share F nfs o rw=sola2:sola3,root=sola2 /data/user3 share F nfs o rw=sola2:sola3,anon=0 /data/user4 sola1# /etc/init.d/nfs.server start sola1# dfshares RESOURCE SERVER ACCESS TRANSPORT sola1:/data/user1 sola1 - - sola1:/data/user2 sola1 - - sola1:/data/user3 sola1 - - sola1:/data/user4 sola1 - - |
|
|
/data/user1 |
/data/user2 |
/data/user3 |
/data/user4 |
|
sola2 |
읽고 쓰기 가능 |
읽기만 가능 |
읽고 쓰기 가능 root 권한으로 작업 가능 |
읽고 쓰기 가능 root 권한으로 작업 가능 |
|
sola3 |
읽고쓰기가능 |
읽고 쓰기 가능 |
읽고 쓰기 가능 |
읽고 쓰기 가능 root 권한으로 작업 가능 |
|
기타 |
공유 가능 |
공유 불가 |
공유 불가 |
공유 불가 |
/data/user1 디렉토리는 아무 옵션을 주지 않고 공유를 한 것이다. 이러한 경우는 기본적으로 rw옵션이 제공되는 것이며 어느 클라이언트라도 공유하는 것이 가능하므로 이러한 설정은 가능하면 안 하는 것이 좋다. /data/user2 디렉토리는 sola2에게는 읽기만 가능하게 설정을 하였고 sola3에게는 읽고 쓰기가 가능하게 설정한 것이다. 호스트를 구체적으로 지정하였으므로 sola2와 sola3 호스트를 제외하고는 NFS 서버의 공유 자원을 사용할 수 없다. /data/user3와 /data/user4는 NFS 클라이언트에서 root권한(UID=0)으로 작업하는 것이 가능하도록 한 것이며 다만, /data/user3는 sola2만 root권한 작업이 가능하고 /data/user4는 sola2와 sola3 둘 다 root권한으로 작업하는 것이 가능하다. 마찬가지로 호스트를 구체적으로 지정하였으므로 다른 클라이언트에서는 마운트해서 사용하는 것이 불가능하다.
이렇게 설정을 하고 NFS 클라이언트에서 마운트해서 쓰려고 하면 가능할까? 정답은 불가능하다이다. 그 이유는 처음 디렉토리를 생성하면 디렉토리 퍼미션이 755로 되어있는데 이 퍼미션으로는 루트를 제외하고는 쓰기가 불가능하다. 즉 sola2는 /data/user3와 /data/user4에서 루트로만 쓰기가 가능하며 다른 계정으로는 쓰기가 불가능하고, /data/user1과 /data/user2에서는 클라이언트에서 루트로 사용을 하려고 해도 uid가 nobody로 되기 때문에 쓰기가 불가능하다. 이 부분은 각자 실제로 그렇게 되는지 한번 테스트 해보도록 하고 이를 정상적으로 사용하기 위해서는 디렉토리 퍼미션을 777로 바꾸어주기 바란다.
|
sola1# cd /data sola1# chmod 777 * sola1# ls al drwxr-xr-x 6 root other 512 Nov 22 11:55 ./ drwxr-xr-x 28 root root 1024 Nov 22 11:54 ../ drwxrwxrwx 2 root other 512 Nov 23 19:25 user1/ drwxrwxrwx 2 root other 512 Nov 22 11:55 user2/ drwxrwxrwx 2 root other 512 Nov 23 19:51 user3/ drwxrwxrwx 2 root other 512 Nov 22 16:11 user4/ |
(2) NFS 클라이언트
NFS 클라이언트에서 해주어야 할 일은 각 디렉토리(마운트 포인트)를 만들고 NFS 서버에서 공유된 자원을 마운트 해주어야 하는 일이다. 여기서는 수동 마운트와 자동 마운트에 대해서 설명할 것이다. sola2는 수동 마운트를 사용하였으며, sola3는 자동마운트를 사용하였다. 둘 다 어느 것을 사용하여도 상관은 없다.
(가) 수동 마운트
수동 마운트는 mount라는 명령어를 사용하여 단순히 서버측 호스트와 공유디렉토리를 명시하여 주고, 클라이언트 쪽에 마운트 포인트만 지정하여 주면 된다.
|
sola2# cd / ; mkdir data sola2# mkdir user1 user2 user3 user4 sola2# /etc/init.d/nfs.client start sola2# mount F nfs sola1:/data/user1 /data/user1 sola2# mount F nfs sola1:/data/user2 /data/user2 sola2# mount F nfs sola1:/data/user3 /data/user3 sola2# mount F nfs sola1:/data/user4 /data/user4 sola2# df k Filesystem kbytes used avail capacity Mounted on /dev/dsk/c0t1d0s0 4030518 58611 3931602 2% / /dev/dsk/c0t1d0s3 4030518 686733 3303480 18% /usr /proc 0 0 0 0% /proc fd 0 0 0 0% /dev/fd mnttab 0 0 0 0% /etc/mnttab swap 553856 0 553856 0% /var/run swap 554184 328 553856 1% /tmp /dev/dsk/c0t1d0s6 983349 217537 706812 24% /opt /dev/dsk/c0t0d0s7 8286045 305049 7898136 4% /export/home /dev/dsk/c0t1d0s4 4030518 1 3990212 1% /usr/local sola1:/data/user1 3007086 64451 2882494 3% /data/user1 sola1:/data/user2 3007086 64451 2882494 3% /data/user2 sola1:/data/user3 3007086 64451 2882494 3% /data/user3 sola1:/data/user4 3007086 64451 2882494 3% /data/user4 |
(나) 자동 마운트
자동 마운트는 /etc/vfstab이라는 파일에 직접 마운트할 내용을 써주어서 /etc/init.d/nfs.client start라는 명령어를 통해 마운트가 실행이 된다. 또한 재부팅이 된다 하여도 부팅시 /etc/vfstab라는 파일을 참조하여 각 디렉토리를 마운트하게 된다. /etc/vfstab에는 기존의 파일시스템에 대한 마운트 내용이 들어있으므로 가능하면 손대지 말고 마지막 줄에 추가 내용만 써주도록 하면 된다.
|
sola3# cd / ; mkdir data sola3# mkdir user1 user2 user3 user4 Sola3# vi /etc/vfstab #device device mount FS fsck mount mount #to mount to fsck point type pass at boot options
sola1:/data/user1 - /data/user1 nfs - yes - sola1:/data/user2 - /data/user2 nfs - yes - sola1:/data/user3 - /data/user3 nfs - yes - sola1:/data/user4 - /data/user4 nfs - yes - sola3# /etc/init.d/nfs.client start sola3# df k Filesystem kbytes used avail capacity Mounted on /dev/dsk/c0d0s0 3007086 46789 2900156 2% / /dev/dsk/c0d0s3 3007086 571629 2375316 20% /usr /dev/dsk/c0d0p0:boot 10484 1623 8861 16% /boot /proc 0 0 0 0% /proc fd 0 0 0 0% /dev/fd mnttab 0 0 0 0% /etc/mnttab swap 916616 4 916612 1% /var/run swap 916620 8 916612 1% /tmp /dev/dsk/c0d0s5 3007086 1728631 1218314 59% /opt /dev/dsk/c0d0s6 3007086 8567 2938378 1% /backup /dev/dsk/c0d0s7 4043118 62343 3940344 2% /export/home /dev/dsk/c0d0s4 3007086 23034 2923911 1% /usr/local sola1:/data/user1 3007086 64451 2882494 3% /data/user1 sola1:/data/user2 3007086 64451 2882494 3% /data/user2 sola1:/data/user3 3007086 64451 2882494 3% /data/user3 sola1:/data/user4 3007086 64451 2882494 3% /data/user4 |
6. 패키지 관리
가. 패키지 개요
(1) 패키지에 대한 소개
각 OS마다 설치를 쉽게 해주는 툴들이 있다. 리눅스 레드헷에서는 rpm이라는 툴을 사용하며 MS 윈도우에서는 install.exe혹은 setup.exe를 통하여 설치를 쉽게 해주는 것처럼 솔라리스에서도 이와 비슷한 툴을 제공한다. 솔라리스에서는 패키지라고 하여 pkgadd나 pkgrm가 같은 명령어를 사용하여 패키지를 설치하거나 지우곤 한다. 이러한 OS에서 응용프로그램들을 패키지 단위로 만드는 가장 큰 목적은 설치와 제거를 쉽게 하기 위해서이다. 응용프로그램의 소스를 컴파일하여 설치를 할 경우 설치된 곳에 다른 응용프로그램도 같이 들어있을 가능성이 크다. 나중에 이러한 프로그램을 다시 삭제할 필요가 생겼을 때 해당 응용프로그램만 지운다는 것은 거의 불가능에 가깝다고 볼 수 있다.
하지만 이러한 패키지를 이용한 설치가 항상 좋은 점만 있는 것은 아니다. 우선 패키지의 배포수가 미비하다는 점이다. 자신이 필요로 하는 프로그램이 항상 패키지로 제공이 된다고 보장할 수는 없는 노릇이기 때문이다. 솔라리스를 사용하는 사람이라면 자주 애용하는 사이트가 있다. 패키지와 그에 해당하는 소스를 제공해주는 사이트인데 주소는 http://www.sunfreeware.com이다. 이곳에 들어가 보면 알겠지만 리눅스에서 제공되고 있는 패키지(rpm)에 비하면 그 양이 매우 미비하다. 하지만 자주 사용되는 웬만한 패키지는 갖추고 있으므로 잘 이용하면 유용한 사이트다.
두 번째로 패키지가 갖고 있는 한계점이라고 할 수 있는 것이 있다. 패키지는 패키지 제작자가 자신의 환경에 맞게 제작을 한 관계로 사용자가 마음대로 그 환경을 바꿀 수가 없다. 예를 들면 설치경로를 마음대로 지정해줄 수가 없다는 점이다. 솔라리스 Companion CD에 있는 패키지를 설치해본 사람은 알겠지만 여기에서 제공되는 패키지는 모두 /opt/sfw 밑에 설치가 되며 위에서 언급한 사이트에서 제공되는 패키지들은 /usr/local 밑에 설치가 된다. 이렇듯 약간 일관성이 없는 면이 있다. 만일 사용자가 특정 옵션이나 혹은 특정 설치 경로를 원한다면 소스를 직접 컴파일 해야 한다. 만일 이러한 프로그램이 자주 사용되거나 여러 컴퓨터에 설치하고자 한다면 나중에 설명될 패키지 제작을 익혀서 본인만의 패키지를 만들어보는 것도 좋은 방법이 될 것이다.
(2) 패키지 구성요소
패키지를 설치하는 방법을 설명하기에 앞서 우선 패키지가 어떻게 구성되는지를 알아볼 필요가 있다. 본 절에서는 이러한 패키지 구성요소에 대해서 설명한다. 패키지는 크게 필수적인 구성 요소와 선택적인 구성 요소로 나누어진다. 필수적인 구성 요소에는 패키지의 주된 내용물인 패키지 오브젝트, 패키지의 정보를 가지고 있는 파일(pkginfo), 패키지 오브젝트의 파일 정보 및 설치 위치에 대한 정보를 가지고 있는 파일(prototype)이 있다. 선택적인 구성요소에는 compver, depend, space, copyright등과 같은 정보제공 파일과 설치 시 수행되는 스크립트파일인 request, checkinstall, Procedure, Class Action등이 있다.
(가) 필수적인 패키지 구성요소
① 패키지 오브젝트
패키지 오브젝트란 실행파일을 포함하여 소스를 컴파일할 때 생성되는 모든 파일과 디렉토리를 지칭하는 것이다. 따라서 패키지를 구성하는 요소로서 가장 중요하며 설치가 될 실제 파일들이다. 패키지 오브젝트에 있는 주된 내용물은 실행 파일, 데이터 파일, 디렉토리, named pipe, 링크, 디바이스 파일 등 여러 파일들이 있다.
② pkginfo 파일
패키지에 대한 전반적인 어떤 파라미터 값들을 정의한 파일로 여기에 사용되는 파라미터는 PKG, ARCH, NAME, VERSION, DESC, VENDOR, BASEDIR, CATEGORY, CLASSES 등이 있다.
PKG : 총 9자 이하로 패키지의 이름을 정의해준다.
ARCH : 아키텍쳐를 정의해주는 곳으로 i386혹은 sparc을 써준다.
NAME : 패키지의 이름을 써준다. 축약된 패키지 설명을 써도 된다.
VERSION : 패키지의 버전
DESC : 패키지에 대한 간략한 설명을 써준다.
VENDOR : 소스를 제공하는 곳이나 제공자의 이름을 써준다. url을 써주는 경우도 많다.
BASEDIR : 설치될 경로의 기본 디렉토리를 지정해 준다.
CATEGORY : 해당 패키지의 category를 적어주면 된다. 일반적으로 system과 application으로 나뉘어 진다.
CLASSES : 모든 패키지 마다 CLASSES라는 것을 명명하여 pkgadd나 pkgrm시 어떠한 특정 action script를 수행할 수 있도록 한다. 일반적으로 none을 사용한다.
이밖에도 사용자가 임의적으로 pkginfo파일에 어떤 내용들을 정의해줘도 상관은 없다. 실제 패키지에 사용된 pkginfo파일을 다음 예에 나타내었다. 밑의 예제는 EB2Igftp라는 패키지의 pkginfo를 나타낸다.
|
# cat pkginfo | more CLASSES=none BASEDIR=/ TZ=ROK PATH=/sbin:/usr/sbin:/usr/bin:/usr/sadm/install/bin OAMBASE=/usr/sadm/sysadm PKG=SUNWdoc NAME=Documentation Tools ARCH=sparc VERSION=11.7.0,REV=1998.09.01.04.16 SUNW_PRODNAME=SunOS SUNW_PRODVERS=5.7/Generic SUNW_PKGTYPE=usr MAXINST=1000 CATEGORY=system |
③ prototype 파일
패키지가 구성하고 있는 파일들에 대한 리스트로 각각의 위치와 속성 및 타입을 기술하고 있다. prototype파일에 들어가는 내용의 양식은 다음과 같다.
part ftype class path major minor owner group
part : 패키지 오브젝트들을 그룹화를 해주는 번호를 입력하는 것으로 기본 값은 1이며 옵션이다.
ftype : 이 필드에는 한 문자만 입력하는 것으로 패키지 오브젝트의 타입이 입력된다. 종류는 아래 표를 참조하길 바란다.
class : 패키지 오브젝트가 지니는 class를 입력해준다. 일반적으로 none이 입력된다.
path : 절대 경로 혹은 상대 경로가 입력된다.
major : block 혹은 character special device에 대한 major device number가 입력된다.
minor : block 혹은 character special device에 대한 minor device number가 입력된다.
mode : 오브젝트 파일의 mode, 예를 들면 0755와 같이 입력된다.
owner : 패키지 오브젝트의 소유자, 예를 들면 root와 같이 입력된다.
group : 패키지 오브젝트의 그룹, 예를 들면 bin과 같이 입력된다.
|
ftype |
정의 |
|
f e v d x l p c b i s |
표준 실행파일 혹은 데이터 파일 패키지의 설치 혹은 제거시 편집되는 파일 log파일과 같이 변화가 있는 휘발성 파일 디렉토리 해당 패키지에서만 접근 가능하도록 하는 디렉토리 링크 파일 named pipe character special device block special device information file 혹은 installation script 심볼릭 링크 |
그럼 실제로 prototype 파일이 어떻게 생겼는지 아래에 있는 예제 표를 보면서 이해하길 바란다. 아래 예는 /var/sadm/pkg/SUNWxilrl/install 패키지에 대한 prototype파일을 나타낸다. 실제 내용은 여기서 나타낸 것보다 더 길다.
|
# cat prototype | more # # File: prototype.rl # Project: XIL # Revision: 1.7 # Last Mod: 16:07:07, 07/08/98 ! default 0775 root bin # d none $top d none $top/lib d none $top/lib/xil d none $top/lib/xil/utils d none $top/lib/xil/locale e OWconfig $xil_dir/config=config d none $install_dir f none $install_dir/libxil.so.1=lib/libxil.so.1 0775 bin bin s none $install_dir/libxil.so=libxil.so.1 0777 root root f none $xil_utils/xiliUtils.so.2=utils/xiliUtils.so.2 0775 bin bin |
(나) 선택적인 패키지 구성요소
패키지 구성요소 중에서 패키지를 구성하는데 꼭 필요한 요소는 아니지만 어떠한 정보나 설치를 도와주기 위한 것들이 있는데 이러한 것들에는 설치하려는 패키지와의 의존 관계에 대한 정보를 지니는 depend 파일, 버전에 대한 정보를 지니는 compver 파일, 소스 파일들에 대한 copyright정보를 지니는 copyright 파일 등이 있다. 이러한 정보를 제공해 주는 파일 이외에 설치 스크립트를 제공해줌으로써 설치할 때 설치자로부터의 어떠한 입력을 필요로 하거나 할 때에 사용되는 패키지 설치 스크립트라는 것이 있다. 이들 정보 파일이나 설치 스크립트들은 패키지 설치에 어떠한 정보나 옵션을 제공해 주며 패키지 구성에 반듯이 필요한 것은 아니다.
① depend 파일
depend파일은 패키지의 의존성을 나타내주는 파일로 여기에 입력된 정보는 단순히 패키지 설치 시에 정보를 출력시켜줄 뿐이다. depend파일에서 사용되는 형식은 다음과 같다.
type pkg-inst pkg-name
type : 디펜던시 타입을 정의해준다. 여기에는 P(prerequisite package), I(incompatible package) 및 R(reverse dependency)중 하나가 지정 되야 한다. 일반적으로 P가 보통 사용된다.
pkg-inst : 패키지의 인스턴스명을 적어주는 곳으로 EB2Igftp와 같은 이름이 들어간다.
pkg-name : 패키지의 이름을 적어주는 곳으로 pkginfo파일의 NAME의 값을 써준다.
다음 예는 SUNWxilrl의 depend파일을 나타낸다. depend파일은 다음의 예와 같이 쓸 수 있다. 이렇게 정의를 하면 패키지 설치지 경고 메시지가 나타나지만 패키지 설치하는 사람은 이 경고 메시지를 무시하고 설치할 수가 있다.
|
# cat depend P SUNWcar Core Architecture, (Root) P SUNWkvm Core Architecture, (Kvm) P SUNWcsr Core Sparc, (Root) P SUNWcsu Core Sparc, (Usr) P SUNWcsd Core Sparc Devices P SUNWesu Extended System Utilities |
② compver 파일
compver파일은 현재 패키지의 이전 버전을 정의해주는 파일이다. 버전의 정의는 이미 설치된 패키지의 pkginfo파일에서 VERSION정보를 참조하여 같은 형식으로 써준다.
다음 예는 임의로 만든 compver파일을 나타낸다.
|
# cat compver 3.0 2.0 1.5 1.0 |
위의 수치들은 모두 해당 패키지 pkginfo파일의 VERSION에서 정의된 값을 뜻한다.
③ space 파일
prototype 파일에 정의된 오브젝트를 위한 공간 이외에 목표 시스템에 필요한 디스크 공간을 정의해 주는 파일이다. depend파일에서 사용되는 형식은 다음과 같다.
pathname blocks inodes
pathname : 디렉토리 경로명을 정의해준다.
blocks : 필요한 디스크 공간을 512바이트의 배수로 정의한다.
inodes : 필요한 inodes의 수를 정의한다.
|
# cat space /opt/SUNWits/Graphics-sw/xil/lib 2 1 |
위의 예는 목표 시스템의 /opt/SUNWits/Graphics-sw/xil/lib이라는 경로에 한 개의 inode와 2*512바이트의 block수를 정의한 것이다.
④ copyright 파일
copyright 파일은 이름으로도 쉽게 알 수 있듯이 해당 프로그램의 copyright를 정의해 주는 파일이다.
나. 패키지 사용 방법
(1) 패키지 설치
(가) pkgadd
맨 처음 인터넷을 통해 패키지를 다운로드받으면 아마도 filename-version-sol8-arch-local. gz이라는 파일형식을 갖고 있을 것이다. gz는 알다시피 gzip으로 압축된 것을 의미하며 local은 파일이 패키지 형태를 지니고 있다는 의미이다. arch는 머신의 종류를 의미하며, 보통 intel과 sparc 두 가지가 있다.
다운로드받은 패키지를 설치하려면 우선 gzip을 이용하여 압축을 풀고 pkgadd 명령어를 사용해서 설치한다. 유일하게 gzip으로 압축되지 않은 패키지가 하나 있다. 그것은 gzip패키지이다. 그 이유는 gzip패키지를 압축해놓으면 어떻게 gzip을 풀 수 있겠는가.
pkgadd에 대한 여러 옵션 중에서 가장 기본적이며 많이 쓰이는 것은 ??-d??옵션이다. 이를 사용하지 않으면 패키지를 설치하지 못한다. pkgadd에 대한 설치 옵션을 살펴보면 다음과 같다.
pkgadd -d device-name [-R root_path] [pkginst…]
-d device-name : 패키지의 위치를 기술한다. device-name은 tape, floppy disk, 삭제 가능한 디스크의 절대 경로 또는 identifier를 기술한다. 만일 패키지의 위치를 기술하지 않을 경우 default spool directory(/var/spool/pkg)에서 찾는다.
-R root_path : root 경로로 사용하기 위한 디렉토리의 full path name을 정의한다.
-s spool : 패키지를 설치하는 대신 패키지 인스턴스를 spool 디렉토리에 설치한다.
pkginst : 설치할 패키지 인스턴스나 인스턴스의 리스트를 써준다.
그럼 실제 예를 통해서 패키지를 설치해보도록 하자. 현재 우리 시스템엔 없는 시스템 상태를 모니터할 수 있는 프로그램인 top-3.5beta12-sol7-sparc3264-local.gz이라는 패키지 파일을 다운받자(http://www.sunfreeware.com). 이 파일을 자신의 디렉토리인 /data/users/jo에 ftp를 이용하여 전송한다. 자 이제 아래와 같이 압축을 풀고 패키지를 설치해 보도록 하자.
|
www3:/data/users/jo > gzip -d top-3.5beta12-sol7-sparc3264-local.gz www3:/data/users/jo > pkgadd -d top-3* pkgadd: ERROR: pkgadd(을)를 제대로 실행하려면 "루트"여야 합니다. www3:/data/users/jo > su - Password: Sun Microsystems Inc. SunOS 5.7 Generic October 1998 You have new mail. # /usr/sbin/pkgadd -d /data/users/jo/pkgadd -d top-3* The following packages are available: 1 SMCtop top (sparc) 3.5beta12 Select package(s) you wish to process (or 'all' to process all packages). (default: all) [?,??,q]: |
copyright와 설치정보가 화면에 나타나면서 설치되는 상황을 볼 수 있을 것이다. 설치 경로는 패키지를 제작한 사람이 어떻게 패키지를 만들었느냐에 따라 다르지만 보통 /usr/local밑에 설치가 되는 것이 기본이다. 설치 중 무슨 메시지가 나타나면 잘 읽어보고 yes나 no혹은 quit를 선택하면 된다. 일반적으로는 그냥 엔터를 치면 ok다.
위의 패키지를 설치를 했는데 ??top??라는 명령어가 실행이 안 된다면 무슨 이유일까? 그건 자신의 환경설정 파일에 해당 경로명을 정의해주지 않았기 때문이므로 설정을 수행해주면 잘 실행이 될 것이다. 설정을 안 해주었을 경우 /usr/local/bin/top이라고 하면 된다.
패키지 설치시 한가지 더 주의할 점은 비록 설치되는 패키지가 사용자의 현재 디렉토리에서 작업을 할지라도 패키지 설치와 제거는 root만이 할 수 있는 명령어이다. 따라서 jo라는 계정을 가진 사용자가 pkgadd명령어를 사용하여 패키지를 설치하려고 하면 위에서와 같은 에러메시지가 나타날 것이다.
(2) 패키지 정보 보기
(가) pkgchk
'pkgchk'라는 명령어는 설치된 파일의 정확성을 검사한다. 검사 대상으로는 file permission, ownership, block 또는 character의 major/minor, file size, checksum, modification date등이 있다. 명령어 사용시 ??-l??옵션을 사용하면 설치된 패키지의 모든 파일에 대한 정보를 화면에 출력한다.
pkgchk [-l | -v] [-R root_path] [pkginst…]
-l : 패키지가 설치된 파일들에 대한 자세한 정보를 제공한다.
-v : 검사한 파일의 리스트를 제공한다.
-R root_path : root 경로로 사용하기 위한 디렉토리의 full path name을 정의해준다.
Pkginst : 패키지 인스턴스 이름이나 인스턴스의 리스트로 만일 생략할 경우 모든 가능한 패키지를 체크한다.
여기서 ??-v??옵션과 ??-l??옵션은 같이 사용할 수 없다. 두 개의 옵션을 사용하여 나온 결과를 보면 다음과 같다.
|
# pkgchk -v SUNWdoc ................ ................ ................ /usr/share/lib/tmac/tmac.vgrind /usr/share/lib/tmac/tz.map /usr/share/lib/tmac/v /usr/share/lib/tmac/vgrind /usr/share/man |
실제로는 위 화면보다 훨씬 많다.
|
# pkgchk -l SUNWdoc ................ ................ ................ Pathname: /usr/share/man Type: directory Expected mode: 0755 Expected owner: bin Expected group: bin Referenced by the following packages: SUNWwsr SUNWuium SUNWctpls SUNWdoc SUNWswmt SUNWkleu Current status: installed |
(나) pkginfo
‘pkginfo’는 설치된 패키지의 데이터 베이스로부터 정보를 화면에 출력시키는 명령어이다. 앞에서 설명된 ??pkginfo??파일은 패키지를 구성하는데 사용되는 정보 파일이며 여기서 설명되는 ??pkginfo??는 명령어이다. ??pkginfo??를 옵션없이 사용할 경우 시스템에 설치된 모든 패키지 인스턴스와 카테고리 등의 정보를 출력한다.
pkginfo [-x | -l] [pkginst…]
-x : extracted format의 패키지 정보를 출력한다.
-ㅣ : long format의 패키지 정보를 출력한다.
|
# pkginfo system SUNWxwfs Font server system SUNWxwice ICE components system SUNWxwicx X Window System ICE 64-bit library system SUNWxwmod OpenWindows kernel modules system SUNWxwoft X Window System optional fonts system SUNWxwopt nonessential MIT core clients and server extensions system SUNWxwplt X Window System platform software system SUNWxwplx X Window System 64-bit library software system SUNWxwpsr Sun4u-platform specific X server auxiliary filter mod ules system SUNWxwrtl X Window System & Graphics Runtime Library Links in / usr/lib system SUNWxwrtx X Window System 64-bit Runtime Compatibility Package system SUNWxwslx X Window System 64-bit lint libraries system TSIpgx PGX32 (Raptor GFX) System Software/Device Driver |
|
www3:/data/users/jo > pkginfo -l SUNWdoc PKGINST: SUNWdoc NAME: Documentation Tools CATEGORY: system ARCH: sparc VERSION: 11.7.0,REV=1998.09.01.04.16 BASEDIR: / VENDOR: Sun Microsystems, Inc. DESC: utilities and fonts for development, display, and production of doc umentation such as manual pages (nroff/troff) PSTAMP: on99819980901043920 INSTDATE: 11월 13 2001 11:25 HOTLINE: Please contact your local service provider STATUS: 설치 완료 FILES: 388 설치된 경로 이름 7 공유 경로 이름 6 연결된 파일 25 디렉토리 32 실행 가능 6381 블록이 사용됨 (추정치) |
|
www3:/data/users/jo > pkginfo -x SUNWdoc SUNWdoc Documentation Tools (sparc) 11.7.0,REV=1998.09.01.04.16 |
(다) pkgparam
??pkgparam??이라는 명령어는 명령어 줄에 기술한 파라미터의 값을 출력해주며 출력되는 값은 패키지 인스턴스에 있는 ??pkginfo??라는 파일의 내용에 있는 값이다. 명령어 줄에 파라미터 값을 기술하지 않을 경우에는 패키지에 대한 모든 파라미터 값을 출력한다.
pkgparam [-v] pkginst [param…]
-v : 파라미터의 이름과 값을 출력한다. 이 옵션을 사용하지 않으면 값만 출력된다.
param : 값을 출력할 하나 이상의 파라미터를 기술한다.
|
www3:/data/users/jo > pkgparam -v SUNWdoc VERSION VERSION='11.7.0,REV=1998.09.01.04.16' |
(3) 패키지 삭제
(가) pkgrm
‘pkgrm’은 설치된 패키지를 지우는 명령어이다. 이 명령어는 제거할 패키지가 다른 패키지와 의존 관계를 가지고 있는지 의존성 검사를 하고 의존 관계를 가지고 있을 경우에는 admin파일에 정의된 작업을 수행한다. ‘pkgrm’ 명령을 쓸 때 대상으로는 항상 package instance name이 와야 한다. 즉 EB2Igftp와 같은 것을 써줘야 한다. 일반적으로 ??pkginfo?? 명령어를 사용해서 지우고자 하는 패키지의 인스턴스명을 알아낸 다음에 지운다.
pkgrm [-d device-name] [-R root_path] [pkginst…]
pkgrm -s spool [-d device-name] [pkginst…]
-d device-name : 제거할 패키지의 위치를 기술한다.
-R root_path : root 경로를 사용하기 위한 디렉토리의 full path name을 정의한다.
-s spool : spool된 패키지의 제거를 위한 디렉토리를 기술한다.
출처 : http://unix.co.kr/bbs/board.php?bo_table=02_021&wr_id=4
