제 목 : [9610]유닉스 시스템 관리자 유닉스시스템 관리자 양창윤,양종윤(인하 대학교 전자 계산 공학과 전문가 시스템 연구실) 발문 : 이번 호에는 지난 달에 이어서 ATT의 스타트업 스크립트에 대해 알아보고 로그인 스크립트와 유닉스의 파일 시스템에 관해 알아보 기로 하겠다. ATT의 스타트업 스크립트 ATT에서 사용하는 스타트업 스크립트는 BSD와 굉장히 차이가 많다. 여기 서는 IRIX 5.2 버전(실리콘 그래픽사의 유닉스 시스템)을 예를 들어 간단히 설명하기로 한다. ATT의 이전 버전과 여기서 설명된 버전 사이에도 상당 히 많은 차이점들이 있다. {{{{ATT ; AT&T유닉스 시스템으로 ATT타입의 시스템에는 솔라리스 HP-UX,IRIX 등이 있다. BSD(Berkeley software distribution); 1980년대 초반 캘리포니아 대학 버클 리 분교에서 개발한 유닉스 운영체계 수행 레벨(Run Level)과 inittab파일 ATT에서 사용되는 스크립트들의 예제에 대해서는 지면 관계로 필요한 부 분만을 설명하기로 한다. 예제로 들지 않은 스크립트 파일은 어떤 기능을 하는지에 대하여만 간단히 서술하기로 한다. ATT에서 init 데몬은 다양한 수행 레벨을 지원한다. 이 수행 레벨은 각기 다른 시스템 자원들을 enable시킨다. 스타트업 스크립트는 소규모로 되어 있어 수행 레벨에 따라 init 데몬이 이들을 불러들여서 다루기가 쉽게 되어 있다. 각각의 수행 레벨은 "/etc/inittab"파일에 정의되어 있다. 만일 "/etc/inittab"파일이 없거나 손상되었다면 시스템은 단일 사용자 모드에서만 동작하게 된다. "/etc/inittab"은 스타트업 스크립트가 어떻게 실행되는가에 대한 제어뿐만 아니라 터미널에서 수행되는 getty 프로세스들의 리스트를 가지고 있다. "/etc/inittab"파일에 정의된 수행 레벨의 의미를 다소 수정할 수 있지만 이 것은 정상적인 방법이 아니다. 다음은 inittab 파일에 대한 내용이다. fs::sysinit:/etc/bcheckrc /dev/console 2> &1 mt::sysinit:/etc/brc /dev/console 2> &1 s0:06s:/etc/rc0 >/dev/console 2 >&1 /dev/console 2>&1 <.dev/console s2:23:wait:/etc/rc2 >/dev/console 2>&1 /dev/console 2>&1 키로써 화면 전환을 수행한다. HP-UX에서의 로그인 VUE(Visual User Environment)는 HP의 그래픽 유저 인터페이스로써 대부 분 HP기종의 "/etc/inittab" 파일은 VUE를 기본 수행 레벨의 일부로 지정한 다. 즉 별 이야기가 없으면 VUE를 수행한다. HP VUE의 로그인 프로그램인 vuelogin은 init, getty, login이 제공하는 기 능을 제공하지만 ".profile"과 같은 셸 스타트업 파일은 읽지 않는다. 로그인 과정은 다음과 같다. ① init 프로세스는 부팅할 때 vuelogin을 수행한다. ② vuelogin은 사용자 로그인의 제어를 위해 또 다른 vuelogin 프로세스를 시작한다. ③ 새 vuelogin은 로그인 화면과 사용자 입력을 처리하도록 vuegreet를 시 작한다. ④ 유저가 vuegreet으로 로그인할 때 "/usr/vue/config/Xstartup" 파일이 있으면 환경 변수를 세트하고 /usr/vue/config/Xsession을 수행시킨다. ⑤ Xsession은 "$HOME/.vueprofile" 파일을 읽어 session manager인 vuesession을 수행한다. HP-UX에서 다른 로그인 방법은 HP VUE의 Option 메뉴를 통해 HP-VUE Lite 혹은 fail-safe session 등으로 로그인할 수 있다. 언어 선택도 가능하 다. HP-VUE를 사용 안하려면 Option에서 No Window를 선택한다. fail-safe session은 Workspace Manager와 하나의 터미널 윈도를 가지고 로그인한 다. VUE를 수행하기 전에 어떤 명령어를 수행시켜야할 때 사용한다. 수퍼유저(root) 유닉스의 소유권(ownership) 모델 파일의 소유권 모든 유닉스 파일은 소유자(owner)와 그룹 소유자(group owner)를 갖는다. 소유자는 파일의 접근 권한을 변경할 수 있는 사용자로서 유닉스 시스템은 "/etc/passwd" 파일에서 UID number로써 구분한다. 그룹 소유자는 같은 프 로젝트를 수행하는 동료에게 접근을 허용하도록 할 때 동료 사용자를 지정 한다. 마찬가지로 "/etc/passwd" 파일에서 GID number로써 구분한다. 이러 한 소유자와 그룹 소유자를 보기 위해서는 다음과 같이 ls 명령을 수행한다. (예) BSD 계열(SunOS,BSD/OS)에서는 ls -lg ATT 계열(Solaris,HP,IRIX)에서는 ls -l 프로세스의 소유권 프로세스, 즉 메모리에 로드되어 수행되는 프로그램에는 전부 4개의 소유권 이 있다. 실제 소유자(real UID)와 실제 그룹 소유자(real GID) 그리고 유효 소유자(effective UID), 유효 그룹 소유자(effective GID)가 있다. 일반적으로 는 실제 소유자와 유효 소유자는 동일하다. 프로세스의 소유자는 프로세스에 시그널을 보낼 수도 있고, 스케줄링 우선 순위를 변경할 수 도 있다. 수퍼유저(root) UID number 0으로 보통 root로 정의되며 시스템 관리자의 역할을 수행한 다. 수퍼유저만이 할 수 있는 작업들은 다음과 같다. ① 파일 시스템의 mounting 과 unmounting ② chroot 명령어를 통한 프로세스의 root 디렉토리 변경 ③ 디바이스 파일의 생성 ④ 시스템 클럭의 세팅 ⑤ 파일의 소유권 변경 ⑥ 프로세스 우선 순위 세팅과 자원 사용 제한 ⑦ 시스템의 호스트명의 세팅 ⑧ 네트워크 인터페이스 조정 ⑨ 시스템의 셧다운 수퍼유저 암호 선택 수퍼유저의 암호는 보안 문제와 연관지어 생각한다면 아무리 강조해도 지나 치지 않는 문제이다. 수퍼유저의 암호의 관리는 다음과 같은 정도로 관리를 해야 한다. ① 최소 3달에 한 번 변경 ② 암호를 알고 있는 자가 시스템을 떠났을 때 ③ 보안에 문제가 있다고 여겨질 때 단. 술을 많이 먹어서 암호를 잊어버릴 것 같은 날은 암호를 새로 변경 하지 말 것. 수퍼유저 되기 root로 로그인 하는 방법이 가장 일반적이지만 이 외에 다른 사용자 로그인 상태에서 su명령어를 사용하는 방법이 있다. 인자 없이 단순히 su 명령을 수행하면 수퍼유저의 암호를 묻는다. 만약 다른 사용자의 암호를 알고 있는 경우는 인자로 사용자 명을 주면 해당 사용자로 로그인 해서 들어 갈 수 있 다. (예 : su -yjy) 그 밖의 사용자들 일반 사용자와 수퍼유저를 제외하고 시스템의 목적을 위해 사용되는 사람이 아닌 로그인명이 존재한다. ① daemon UID 1로써 유닉스 자체에 소속되어야 하는 파일들의 소유자로 같은 이름의 그룹도 존재한다. 대부분이 보안 목적이다. ② bin (시스템 명령의 소유자) 대부분의 실행 파일들과 시스템 명령어를 포함하는 디렉토리의 소유자 ③ sys (커널과 메모리 이미지의 소유자) 특수 파일("/dev/kmem",...) 즉 시스템의 물리적 메모리, swap space image 등의 소유자 ④ nobody 특별한 허가가 필요 없는 소프트웨어의 소유자로 UID가 -1, -2 이다. 예로 는 NFS의 fingerd 데몬이 있다. 파일 트리 파일 트리란 유닉스에서 파일 트리란 시스템의 저장 매체(자원)를 포괄적으로 나타내기 위해 커널에 의해 사용되는 추상적인 개념이다. 여기서 저장 매체(자원)는 하드 디스크나 플로피 디스크 혹은 테이프 백업 장치 등을 나타내며 각각은 하나의 파일 시스템이 된다. 커널은 이 모두를 통합하여 "/"(루트) 디렉토리 부터 시작하는 하나의 커다란 계층 구조로 만든다. 이것이 파일 트리이다. 도스와 비교한다면 마치 하드 디스크의 디렉토리 중에서 어떤 디렉토리로 가면 플로피와 연결되고, 다른 어떤 디렉토리는 CD-ROM 드라이브와 연결 되는 하나의 디렉토리 구조를 가진다고 할 수 있다. 파일 트리의 구조 앞서 말한 개개의 파일 시스템들은 처음부터 파일 트리에 연결되지는 않는 다. 각각의 파일 시스템을 파일 트리에 연결하는 일을 바로 마운트(mount) 라고 한다. 파일 트리의 시작 디렉토리(root directory)인 " / "를 포함한 파 일 시스템(주로 본체의 하드 디스크)에 플로피나 CD-ROM 혹은 테이프 백 업 장치 등을 마운트 하는 일이 바로 시스템 관리자의 몫인 것이다. 마운트 명령은 새 파일 시스템이 연결 될 파일 트리의 특정 디렉토리(mount point) 와 새로운 파일 시스템의 루트를 매핑(연결)한다. 보통 마운트 포인트는 빈 디렉토리가 되지만 빈 디렉토리가 아닌 경우 마운트한 후에는 접근이 불가 능 하니 유의해야 한다. (예) 새 하드 디스크인 /dev/sd0a를 /users 로 마운트 하기 mount /dev/sd0a /users 루트 파일 시스템에는 커널이 존재한다. 루트 파일 시스템은 보통 /unix, /vmunix 혹은 /kernel/unix 디렉토리와 다음의 디렉토리들을 포함한다. ▶ 디바이스 파일들을 가지는 /dev 디렉토리 ▶ 중요한 시스템 파일을 가지는 /etc 디렉토리 ▶ 중요한 유틸리티를 가지는 /sbin 혹은 /bin 디렉토리 ▶ 임시 파일들을 가지는 /tmp 디렉토리 그리고 /usr 과 /var 파일 시스템은 매우 중요한데 /usr은 온라인 매뉴얼과 라이브러리 등을 포함한 표준 프로그램을 가지며 /var은 스풀 디렉토리들과 로그 파일들 그리고 accounting 정보 등을 가진다. <표 1>은 표준 유닉스 디렉토리를 나타낸 것이다. 참고하기 바란다. 파일의 종류 유닉스의 파일에는 전부 8 가지 종류가 있다. ① 일반 파일 ② 디렉토리 ③ 문자 디바이스 파일 ④ 블록 디바이스 파일 ⑤ 유닉스 도메인 소켓 ⑥ Named Pipe (FIFO) ⑦ 하드 링크 (Hard Links) ⑧ 심볼릭 링크 (Symbolic Links) 일반 파일 & 디렉토리 일반 파일과 디렉토리는 도스를 생각하면 될 것이다. 다만 유닉스에서의 디 렉토리의 생성과 삭제는 mkdir , rm 명령어를 이용한다. 비어 있지 않은 디 렉토리의 삭제는 rm 명령어에 -r 옵션을 붙여 사용하면 되지만 유의해서 사용해야 한다. 잘못하면 시스템 자체를 날릴 수도 있다. 문자 & 블록 디바이스 파일들 디바이스 파일은 유닉스 프로그램이 시스템 하드웨어와 주변장치가 통신할 수 있게 한다. 문자 디바이스 파일들은 관련 드라이버들이 그들의 입출력 버퍼링을 수행하도록 한다. 블록 디바이스 파일은 큰 단위의 입출력과 그것 에 대한 버퍼링을 다루는 드라이버에 의해 이용된다. 각 디바이스 파일들은 major와 minor 디바이스 넘버로 구분 지어진다. 이들 넘버는 해당 디바이스 파일을 ls 명령으로 ( l 옵션 ) 출력해 보면 일반 파일에서 파일 크기를 나 타내는 부분에 나타난다. {{{{경로명}} {{내용}} {{/}} {{루트 디렉토리}} {{/bin 이나 /sbin}} {{시스템 운영을 위해 필요한 최소의 명령들}} {{/dev}} {{터미널, 디스크, 모뎀 등에 대한 디바이스 엔트 리}} {{/etc }} {{중요한 스타트업 파일과 컨피그 파일들}} {{/lib }} {{C 컴파일러 라이브러리}} {{/tmp}} {{리부트(reboot)할 때 없어질 임시 파일들}} {{/sys}} {{커널 구축 위한 작업 영역과 컨피그 파일들 (BSD)}} {{/proc}} {{모든 수행중인 프로세스들의 이미지}} {{/stand }} {{독립적인 유틸리티들, 디스크 포맷기 등}} {{/usr/bin}} {{실행 파일들}} {{/usr/games}} {{게임 약간(단순한 것들)}} {{/usr/include}} {{C 프로그램을 위한 헤더 파일들}} {{/usr/5bin}} {{ BSD 시스템에서의 System V 호환 명령들}} {{/usr/etc}} {{시스템 관리 명령들}} {{/usr/sbin}} {{추가의 시스템 관리 명령들}} {{/usr/lib}} {{표준 유닉스 프로그램들에 대한 지원 파일들}} {{/usr/man}} {{온라인 매뉴얼 페이지}} {{/var/adm}} {{회계 (Accounting) 파일들, 리소스(자원)사용 기 록}} {{/var/spool}} {{프린터, UUCP,메일 등을 위한 스풀링 디렉토리 들}} {{/var/tmp}} {{임시 공간}} {{/usr/ucb}} {{버클리 시스템 유틸리티들과 프로그램들}} {{/usr/local}} {{기타 소프트웨어(사용자 설치 프로그램)}} {{/usr/local/adm}} {{local 회계, 로그 파일들}} {{/usr/local/bin}} {{local 실행 파일들}} {{/usr/local/etc}} {{local 컨피그 파일들과 명령들}} {{/usr/local/lib}} {{local 지원 파일들}} {{/usr/local/sbin}} {{local 시스템 관리 명령들}} {{/usr/local/src}} {{/usr/local/* 의 소스 코드들}} {{/kernel}} {{커널을 로드하기 위한 파일들(Solaris)}}}} 표 1 : 표준 디렉토리와 내용들 ▶ Major 디바이스 넘버 - 커널에게 파일이 참조하는 드라이버가 어떤 것 인지를 알려준다. ▶ Minor 디바이스 넘버 - 드라이버에게 어떤 물리적 유닛을 지정해야 하 는지 알려준다. (예) Sun OS의 major number 12는 터미널 드라이버를 가리킨다. 디바이스 파일의 생성과 삭제는 mknod, rm 명령어를 이용한다. 유닉스 도메인 소켓(BSD) 유닉스에서 소켓이란 프로세스간 통신을 가능하게 하는 연결체이다. 유닉스 는 여러 개의 서로 다른 소켓을 제공하는데 모두 네트워크와 관련된다. 이 소켓은 파일 시스템 오브직트를 통해 참조되며 소켓 파일은 디렉토리로써 모든 프로세스가 접근 가능하지만 읽거나 쓰지는 못한다. 소켓은 프린팅 시 스템이나 X윈도 시스템, 혹은 syslog등에서 사용할 수 있다. 소켓의 생성은 socket 시스템 호출을 통해 이루어지며 삭제는 rm 명령어나 unlink 시스템 호출을 통해 수행한다. Named Pipes(ATT) Named Pipes란 두 개의 같은 호스트에서 실행하는 서로 관련이 없는 프로 세스사이의 통신을 하는 수단이다. 생성과 삭제는 mknod, rm 명령어를 이 용한다. 하드 링크(Hard Links) 링크란 파일을 가리키는 또 다른 이름이다. 일종의 별명(alias)인 셈이다. 유 닉스 시스템은 링크의 수를 가지고 있다가 최종 링크가 삭제될 때까지는 해 당 파일의 실제 내용(data block)을 삭제하지 않는다. ▶ 하드 링크의 생성 ln <가리킬 파일명> <새 이름> ▶ 하드 링크의 삭제 - rm 명령어 심볼릭 링크(Symbolic Links) 소프트 링크라고도 하며 하드 링크와 마찬가지로 파일을 가리키는 별명이 다. 하드 링크와의 차이는 하드 링크는 파일에 대한 직접적인(물리적) 참조 를 하는 반면 심볼릭 링크는 이름에 의한 간접적인(이름만 변경) 참조를 한 다는 것이다. ▶ 심볼릭 링크의 생성 ln -s <경로 포함한 파일명> <새 이름> ▶ 심볼릭 링크의 삭제 - rm 명령어 파일의 접근 허가 모든 파일은 9개의 접근 허가 비트를 가진다. 이것들은 누가 그 파일의 내 용을 읽거나 쓰거나 실행시킬 수 있는지를 제어한다. 이 비트들은 그 파일 의 소유자나 수퍼유저가 chmod 명령으로 속성을 변경시킬 수 있다. 또한 추가로 3개의 비트가 파일의 수행 모드를 나타내는데 setuid 와 setgid 비 트 그리고 sticky 비트이다. 이것들은 ls 명령으로는 보여지지 않는다. 차근 차근 설명하기로 하겠다. 다음은 ls 명령으로 볼 수 있는 접근 허가 정보이 다. $ ls -lg test (BSD 시스템에서) -rwxr-xr-x 1 root bin 1024 Sep 1 1996 test ATT 시스템의 경우는 -l 옵션으로 비슷한 결과를 볼 수 있다. 결과에서 최 초의 하이픈(-)은 파일의 종류를 나타낸다. <표 2>를 참고하기 바란다. 그 리고 다음에 나타나는 9개의 연속된 문자(rwxr-xr-x)가 앞으로 설명할 파 일 접근 허가 비트를 나타낸다. 참고로 다음의 숫자 1은 앞서 설명한 하드 링크의 수를 나타내는 것이다. {{{{파일 종류}} {{심벌}} {{생성}} {{삭제}} {{일반 파일}} {{-}} {{에디터..}} {{rm}} {{디렉토리}} {{d}} {{mkdir}} {{rmdir rm -r}} {{문자 디바이스 파일}} {{c}} {{mknod}} {{rm}} {{블록 디바이스 파일}} {{b}} {{mknod}} {{rm}} {{유닉스 도메인 소켓}} {{s}} {{socket(2)}} {{rm}} {{Named Pipes}} {{p}} {{mknod}} {{rm}} {{심볼릭 링크}} {{l}} {{ln -s}} {{rm}}}} 표 2 : 파일 종류 표시 심벌 (ls명령 시) Setuid & Setgid 비트 이 비트들은 원래 소유자나 수퍼유저가 아니면 접근 할 수 없는 파일이나 프로세스를 접근할 수 있게 해준다. Sticky 비트 Sticky란 말 그대로 끈적끈적 하다는 의미인데 이것은 과거 적은 메모리의 유닉스 시스템에서 어떤 프로그램이 계속(끈질기게) 메모리에 남아 있기를 원할 때 쓰던 비트이기 때문에 이런 명칭이 붙여진 것이라 여겨진다. 당연 히 현재는 무시하는 비트이다. 접근 허가 비트들 9개의 비트는 3개씩 3부분으로 나뉜다. 처음 3비트는 소유자의 접근 권한, 다음은 그룹 소유자의 접근 권한, 그리고 나머지 하나는 그 외의 다른 사용 자들의 접근 권한을 지정한다. 직관으로 알 수 있듯이 'r'은 읽기 가능, 'w' 는 쓰기 가능, 'x'는 수행 가능을 지정한다. <표 3>을 참고하기 바라며 이 를 이용한 chmod 명령의 사용은 다음과 같은 형식이다. (예) 파일 "test"의 접근 모드를 소유자는 모두 가능, 그 외는 읽기만 가능 하게 변경 chmod 744 test {{{{Octal}} {{2진수}} {{상태}} {{Octal}} {{2진수}} {{상태}} {{0}} {{000}} {{---}} {{4}} {{100}} {{r--}} {{1}} {{001}} {{--x}} {{5}} {{101}} {{r-x}} {{2}} {{002}} {{-w-}} {{6}} {{110}} {{rw-}} {{3}} {{003}} {{-wx}} {{7}} {{111}} {{rwx}}}} 표 3 : chmod에 대한 허가 비트 일반 파일의 접근 모드가 쓰기 가능이라 해도 파일의 삭제와 이름 변경은 그 파일의 parent 디렉토리의 접근 모드에 의해 결정된다는 것도 알아두자. 디렉토리에 대한 수행 가능 비트(x)의 세트 여부는 그 디렉토리로의 진입 여부를 결정하는 사실도 알아두자. 디폴트 접근 허가 지정 내장 셸 명령어인 umask는 파일 생성에서 디폴트 접근 허가를 지정한다. 지정하는 방법은 chmod 명령과 유사하지만 접근 모드를 나타내는 숫자가 chmod와는 반대로 되어 있음에 유의해야 한다. <표 4>를 참조하기 바란다. {{{{Octal}} {{2진수}} {{상태}} {{Octal}} {{2진수}} {{상태}} {{0}} {{000}} {{rwx}} {{4}} {{100}} {{-wx}} {{1}} {{001}} {{rw-}} {{5}} {{101}} {{-w-}} {{2}} {{002}} {{r-x}} {{6}} {{110}} {{--x}} {{3}} {{003}} {{r--}} {{7}} {{111}} {{---}}}} 표 4 : umask 에 대한 허가 비트 특별한 지정이 없으면 umask는 '022'를 지정한다. 즉 소유자에게는 모두 가 능, 그 외는 읽기와 수행 가능 모드로 지정한다. 예를 들어 소유자에게는 모 두 가능하게 하고 그룹 소유자에게는 읽고 수행만 가능하게 그리고 다른 사 용자는 아무것도 못하게 하려는 경우는 "umask 027"과 같이 수행한다. INODE 지금부터 설명하는 내용은 다소 어려울지도 모르나 관리자로써 한 번쯤은 읽어 두어야 할 내용이다. 파일의 내부 표현 모든 유닉스 파일은 고유한 inode를 가진다. 커널은 각 패스 명을 파일의 inode로 변환한다. inode에 관련된 알고리듬은 버퍼 캐시 알고리듬 상위에 위치하게 된다. iget은 이전에 알려진 inode를 리턴 한다. iput은 inode를 release한다. bmap은 파일을 접근하도록 커널의 패라미터를 세트한다. namei는 iget, iput, bmap을 이용해서 사용자가 지정한 패스 명을 inode로 변환한다. alloc와 free 알고리듬은 파일에 대해 디스크 블록을 할당하거나 해제한다. ialloc과 ifree 알고리듬은 파일에 대한 inode를 할당, 해제한다. INODEs inode는 디스크에 존재하며 커널이 그 복사본을 메모리에 가지고 관리한다. 다음은 inode의 각 필드를 나타낸 것이다. ① 파일 소유자 식별자 ② 파일 타입 ③ 파일 접근 허가 ④ 파일 접근 시간 ⑤ 파일에 대한 링크 수 ⑥ 파일 데이터의 디스크 주소를 내용으로 하는 테이블 ⑦ 파일 크기 inode는 파일의 접근 속성을 변경해도 바뀌지만 파일은 내용을 변경해야만 바뀐다. 디스크의 inode와는 다르게 커널안의 inode 복사본은 추가 정보가 들어간다. ① 커널의 inode 상태 ▶ 잠금(locked) 여부 ▶ 잠금 해제를 기다리는 프로세스의 유무 여부 ▶ 커널의 inode가 디스크의 inode와 다른지 여부 ▶ 커널의 inode 파일 지정이 디스크의 것과 다른지 여부 ▶ 파일이 마운트 점(mount point)인지 여부 ② 파일을 포함하는 파일 시스템의 논리 디바이스 넘버(logical device number) ③ Inode number - 디스크에서의 inode는 선형 배열에 저장되므로 디스크 inode를 참조 할 때 배열의 인덱스 넘버가 필요하다. ④ 커널의 다른 inode를 가리키는 포인터(pointer) - 커널에서는 inode를 해 쉬큐(hash queue)와 자유 리스트(free list)로 연결한다. 여기서 해쉬큐는 inode의 논리 디바이스 넘버와 inode 넘버로 구분된다. ⑤ 참조 카운트(reference count) - 활성화된 파일의 인스턴스 수를 가리킨 다. 커널의 inode 참조 카운트가 0인 경우에만 inode가 자유 리스트에 놓인다. 일반 파일의 구조 inode는 파일의 데이터를 가리키는 내용의 테이블을 가지는데 각 블록은 숫 자로 주소를 지정하므로 테이블의 내용은 디스크 블록 넘버의 집합이다. 유 닉스에서 inode와 데이터 블록의 대응 관계는 다음과 같다. 그림 inode와 데이터 블록 관계 마치며 이번 호까지 유닉스 시스템 관리자가 되기 위한 기본적 지식을 어느 정도 설명하였다고 생각한다. 다소 미진한 부분이 있었지만 앞으로 계속 연재를 해 나가면서 보충하도록 하겠다. 다음 호에는 관리자로써 가장 흔히 하게 되는 업무인 사용자의 추가, 환경 설정 그리고 프로세스의 제어에 관하여 알아보기로 하겠다. {{ }} ..........