System Admin

가. 도스, 윈도우 98의 예

도스에서는 시스템 디렉토리 구조라고 할 만한 것이 없다. 일단 최상위 디렉토리에 command.com 이라는 기본 명령 해석기가 놓이고, path가 걸린 디렉토리에 도스 외부 명령들이 위치하기만 하면 된다. 대부분 dos라는 디렉토리를 만들고, 그 안에 외부 명령들을 설치한다. 최상위 디렉토리에 있어야 할 중요 파일로는 config.sys와 autoexec.bat 파일 정도이다.

나머지 디렉토리를 어떻게 사용할 것인지에 대해서는 각종 애플리케이션 프로그램들이 결정해 버린다. 단일 사용자 단일 프로세스 시스템이므로 프로그램을 어디에 설치하든 그것은 별 문제되지 않는다.

윈도우95/98/nt의 경우에는 32비트(또는, 유사 32비트) 운여체제이며, 수많은 요소들이 좀더 체계적이고 복잡하게 정렬된다. 우선, windows 디렉토리 이하를 사용한다. 중요한 공통 파일들은 system 디렉토리에 존재한다. 보통 dll이라고 부르는 파일들이 여기에 놓인다.

윈도우 98은 windows 디렉토리 이외에도 프로그램들이 체계적으로 설치되길 바라는 의미에서 만든 program files 디렉토리, 휴지통 관리 정보를 담을 recycled 디렉토리등 몇 가지 이미 운영체제 수준에서 정한 디렉토리 이름을 가지고 잇다.

이렇게 시스템에서 이미 정한 이름의 디렉토리는 존중하여 사용하는 것이 좋다.

나. 리눅스의 복잡한, 그리고 체계적인 디렉토리 구조

이에 비해 리눅스의 디렉토리 구조는 pc 운영체제를 사용하다 처음으로 유닉스적인 운영체제를 만난 사람을 당황하게 할만큼 한 눈에 복잡하게 보이는 것이 사실이다.

리눅스의 파일 시스템 구조에는 여러 가지 약속된 디렉토리가 많고, 그것을 최대한 존중하여 사용해야 한다.

모든 디렉토리 나무 구조(tree structure)의 최상위를 루트(/)라고 부른다. 관리자 계정을 루트(root)라고 부르는 것과 상관이 있을까?

▶ /디렉토리 하부 구조

리눅스의 디렉토리 구조의 원칙은 프로그램과 시스템 설정 파일, 그리고 사용자가 만드는 파일을 확실하게 구분하여 서로 섞이지 않도록 디렉토리를 따로 사용한다는 것이다. 리눅스의 경우에는 다른 유닉스와 비슷한 점도 갖지만, 명확한 구분을 더욱 따지며 개발 초기부터 '리눅스 파일 시스템 표준(linux file system standard, fsstnd)'을 제정해 왔다. 이 기본 원칙 아래 각 배포판 제작자들은 자신들이 생각하기에 fsstnd에 맞다고 생각하고, 옳다고 생각하는 방식으로 디렉토리 구조를 배치해 왔다.

디렉토리 이름 설 명

/ 루트 디렉토리

bin 가장 필수적인 명령

boot 커널, lilo 관련 파일, 즉 부팅에 관련된 파일

dev 장치 파일

etc 시스템 전체 설정 파일

home 사용자의 홈디렉토리

lib 가장 필수적인 공유 라이브러리(c 라이브러리 포함)

mnt 임시 마운트용 디렉토리

proc 프로세스, 시스템 정보를 위한 가상적인 디렉토리

root 루트 사용자의 홈디렉토리

sbin 시스템 관리용 프로그램(superuser's bin)

tmp 임시 파일 생성용 디렉토리

usr 애플리케이션이 설치되는 디렉토리

var 시스템이 운영중 생성하는 각종 임시 파일 디렉토리

여기서 살펴보는 기본 구조는 어느 배포판이나 같다. 하지만, 그 이하 디렉토리에서는 약간의 차이를 가질 수 있다.

▶ 시스템 설정 파일 디렉토리 /etc

리눅스에서, 특히 레드햇 리눅스에서는 최대한 모든 설정 파일이 /etc 디렉토리 아래 놓이도록 신경을 쓰고 있다. 제일 중요한 파일들로서는 사용자 정보를 가지고 있는 파일인 passwd(쉐도우 파일 시스템에서는 패스워드가 shadow 파일에 따로 놓인다.), 그룹 정의 파일인 group, 프린터 목록 파일인 printcap, 자동 마운트될 파일 시스템을 등록해 두는 파일 시스템 테이블 파일인 fstab, 그리고 각종 네트웍 관련 파일들이 있다.

무엇보다도 이 디렉토리 아래에는 시스템 v 방식의 초기화 스크립트들이 놓여 있는 rc.d가 있다.

레드햇 리눅스에서는 원래의 x 윈도우 시스템 디렉토리 구조가 리눅스 파일 시스템 표준에 적합하지 않기 때문에 x11이라는 디렉토리를 만들어 x윈도우 시스템에 관련된 설정 파일을 /usr/x11r6에서 찾지 않아도 되도록 조치를 취해 놓았다.

또 하나, 예를 들어 보통 /usr/local/etc/httpd/conf와 같은 체계적이지 못하고 현명하지 못한 디렉토리에 아파치 설정 파일을 두지 않고, /etc/httpd/conf 디렉토리를 사용하도록 적절히 아파치 서버의 소스에 변경을 가하여 제공하고 있다.

어떤 설정 파일이든 망망대해같은 /usr 디렉토리 밑을 뒤질 필요없이 /etc 디렉토리에서 찾을 수 있게 해놓는다는 것은 리눅스가 다른 유닉스보다도 더 훌륭하게 일을 해내고 있는 요소이다.

▶ 시스템의 기초 중 기초인 명령이 모인 /bin

[root@leelab /bin]# ls

arch* dnsdomainname@ ipcalc* nice* su*

ash* doexec* kill* nisdomainname@ sync*

ash.static* domainname@ ksh* ping* tar*

awk@ echo* linuxconf* ps* tcsh*

basename* ed* ln* pwd* touch*

bash* egrep* login* red@ true*

bsh@ ex@ lpdconf@ remadmin* umount*

cat* false* ls* rm* uname*

chgrp* fgrep* mail* rmdir* userconf@

chmod* fsconf@ mkdir* rpm* usleep*

chown* gawk* mknod* rvi@ vi*

cp* gawk-3.0.3* mktemp* rview@ view@

cpio* gecko* more* sed* xconf@

csh@ grep* mount* setserial* ypdomainname@

date* gunzip* mt* sh@ zcat*

dd* gzip* mv* sleep* zsh*

df* hostname* netconf@ sort*

dmesg* igawk* netstat* stty*

[root@leelab /bin]#

유닉스는 /bin 디렉토리와 /usr/bin 디렉토리를 나누어 사용해 왔다. 물론, 초창기에는 지금처럼 고용량의 하드 디스크 시대가 아니었기 때문에 용량의 제한을 매우 크게 느꼈을 것이다. 따라서, 필수적인 명령과 그렇지 않은 명령을 나누는 것은 매우 자연스러운 행위이다.

하드웨어 용량 제한의 문제도 있겠지만, /bin 디렉토리와 /usr/bin 디렉토리로 나누면서 좀더 체계적인 기능 분리와 관리가 편해진 면도 있다.

위 화면은 /bin 디렉토리에서 ls 한 화면이다. 이 안에는 명령 해석기인 쉘들이 들어 있다. 기본적인 파일 처리 명령, 텍스트 처리 명령, 네트웍 정보 처리 명령이 들어 있다.

여기에 나열된 명령들은 거의 대부분은 익혀야만 리눅스를 쓴다고 할 수 있지 않을까 생각한다.

▶ 시스템 공유 라이브러리 디렉토리 /lib

32비트 대형 운영체제들은 수많은 프로그램들로 구성되어 있기 때문에 각 프로그램들의 중복 기능을 한데 모아야 할 필요성이 절실해진다.

지금부터 하는 이야기는 리눅스에 대한 일반 상식이라고 생각하고 프로그래머나 시스템에 해박한 지식을 갖고 싶은 사람이 아니라면 그렇게 완벽히 이해할 필요는 없는 내용이므로, 마음 편히 잡지 기사를 읽는 다고 생각하며 받아들이기 바란다.

이 디렉토리에 있는 동적(dynamic) 라이브러리 파일들은 시스템의 거의 모든 프로그램들이 의존하고 있는 요소이므로 함부로 삭제하거나 이름을 변경해서는 안된다. 예를 들어, c 라이브러리는 라이브러리를 지우는 순간 시스템은 정지 상태가 되어비리고 말 것이다.

이 디렉토리에는 다음과 같이 라이브러리 파일과 그 라이브러리 파일을 가리키는 심볼릭 링크로 구성되어 있다. 파일은 라이브러리 이름과 버전 그리고 .so 라는 문자로 구성되어 있다. 윈도우 95/98/nt에서 똑같은 기능의 파일이 바로 dll 인데, dll과 달리 파일 이름 자체에 버전 정보가 들어가도록 해 놓았기 때문에 알아보기 좋다. 또한, 버전에 따라 파일 이름이 다르기 때문에 필요에 따라 다른 버전의 똑같은 라이브러리가 공존할 수 도 있다는 장점을 갖는다.

[root@leelab /lib]#

libc-2.0.7.so* libpam_misc.a

libc.so.6@ libpam_misc.so@

libcom_err.so.2@ libpam_misc.so.0@

libcom_err.so.2.0* libpam_misc.so.0.64*

libcrypt-2.0.7.so* libproc.so.1.2.6*

libcrypt.so.1@ libpthread-0.7.so*

libdb-2.0.7.so* libpthread.so.0@

libdb.so.2@ libpwdb.a

libdl-2.0.7.so* libpwdb.so@

libdl.so.1@ libpwdb.so.0@

libdl.so.1.9.5* libpwdb.so.0.55*

libdl.so.2@ libresolv-2.0.7.so*

libe2p.so.2@ libresolv.so.2@

libe2p.so.2.3* libss.so.2@

libext2fs.so.2@ libss.so.2.0*

libext2fs.so.2.4* libtermcap.so.2@

libm-2.0.7.so* libtermcap.so.2.0.8*

libm.so.6@ libutil-2.0.7.so*

libnsl-2.0.7.so* libutil.so.1@

libnsl.so.1@ libuuid.so.1@

libnss_compat-2.0.7.so* libuuid.so.1.1*

libnss_compat.so.1@ modules/

libnss_db-2.0.7.so* security/

libnss_db.so.1@

[root@leelab /lib]#

libc 는 리눅스 시스템에서 가장 중요한 라이브러리이다. 그 동안 리눅스는 라이브러리에 관하여 두 번의 커다란 변화를 겪었다. libc4 버전은 전통적인 실행 바이너리 형식인 a.out 시대에 사용된 구식의 라이브러리로서, 지금은 거의 사라져 가고 있는 상태이다. libc5(립씨 파이브라고 읽는다.) 버전은 elf(executable & linkable format)라는 실행 바이너리 형식을 사용하는 시대의 라이브러리이다. elf라는 실행 바이너리 방식은 지금까지 계속 사용하고 있는 방식이다.

레드햇 리눅스 5.0부터는 gnu libc 버전 2에 해당하는 libc6 시스템이라고 부른다. libc5에서 libc6으로의 라이브러리의 변화가 매우 커서 처음에는 굉장한 혼란을 가져다 주었지만, 기존의 libc5 바이너리 또한 거의 문제없이 지원되기 때문에 걱정할 필요는 없다. 또한 , 자유 소프트웨어의 대부분이 소스의 형태로 제공되기 때문에 모두 libc6 라이브러리를 사용하도록 재 컴파일 되는 것은 시간 문제일 것이다.

libm 라이브러리는 c 라이브러리 요소 중 수학적인 함수들만이 따로 모여 있는 라이브러리이다.

libc5 시스템에서는 모든 기능이 하나의 라이브러리 이미지에 통합되어 있어 파일 개수가 적었지만, gnu libc2(리눅스에서는 libc6)에서는 모두 분리되어 개별적인 라이브러리가 되어 위에서 보는 것처럼 디렉토리 내용이 매우 장황하게 되었다.

ld로 시작하거나 libdl 로 시작하는 파일들은 프로그램들이 실행될 때 필요한 라이브러리를 알맞게 찾아서 메모리에 올려주고 연결해 주는 로더(loader)이다. 수없이 많은 프로그램들이 실행되고 종료하는 상황 속에서 끝없이 움직여야 하는 시스템 요소이다.

이미 메모리 상에 존재하는 공유 라이브러리가 올라가 있으면, 그 다음부터 그 기능을 요구하는 명령에 대하여 또 다시 같은 라이브러리를 메모리에 중복해서 올릴 필요 없이 같이 사용할 수 있어 메몰l를 절약할 수 있다.

그러나 일부 특수한 프로그램들은 공유 라이브러리를 사용하지 않고 모든 기능을 다 포함시켜놓는 경우가 있는데, 이런 프로그램들은 정적(static) 컴파일되었다고 말한다. 정적 컴파일된 라이브러리는 당연히 파일 크기 자체도 크며, 모든 기능을 자체적으로 갖고 있기 때문에 메모리 손실도 크다.

어떤 프로그램이 어떤 라이브러리와 동적 링크(link)되어 있는지 알아보는 명령으로는 ldd가 있다.

우선, 우리가 수도 없이 사용하게 될 gnu bash 쉘은 어떤 라이브러리를 필요로 하는가?

[root@leelab /lib]# ldd /bin/bash

libtermcap.so.2 => /lib/libtermcap.so.2 (0x40005000)

libc.so.6 => /lib/libc.so.6 (0x40009000)

/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00000000)

[root@leelab /lib]#

위 결과에 의하면 libtermcap, libc, ld-linux 라이브러리에 의존함을 알 수 있다. 따라서, 이 라이브러리 중 하나라도 잘못해서 지워지면 bash 쉘은 실행되지 않을 것이다.

[root@leelab /lib]# ldd /bin/rpm

not a dynamic executable

[root@leelab /lib]#

레드햇 리눅스의 패키지를 관리하는 중요 명령인 rpm은 동적 링크를 사용하지 않은 명령이다. ldd는 주어진 명령이 동적 실행 파일 (dynamic executable)이 아니라고 이야기 해 준다.

▶ 사용자 홈 디렉토리 /home

다중 사용자 시스템이므로 각 사용자의 자료가 뒤죽박죽 섞이지 않도록 모든 사용자는 자신만의 공간을 갖고, 자료 파일은 모두 그 곳에 두어야 한다. 잠시 /tmp 같은 디렉토리를 사용할 수는 있어도 자신의 홈디렉토리 이외의 공간에 둔 파일에 대해서는 보장을 해줄 수 없다.

/home 디렉토리 밑에는 보통 계정 이름과 동일한 디렉토리가 만들어지고, 바로 그 디렉토리 이하를 각 사용자가 사용할 수 있다.

하자만, 다수의 사용자를 갖고 있는 시스템이라면 /home 디렉토리 밑에 바로 사용자의 홈 디렉토리를 만들기보다는 직장에서는 부서, 학교에서라면 교수와 학생, 임직원 등을 구별하는 디렉토리를 하나 만들고 그 아래에 두어 사용할 것이다.

이런 경우 사용자의 홈 디렉토리는 예를 들어, /home/student/yong과 같이 정해질 것이다.

▶ 리눅스 고유의 시스템 정보 디렉토리 /proc

/proc 디렉토리는 커널이 보유하고 있는 시스템 정보를 실시간으로 확인할 수 잇는 특별한 정보 시스템이다. 매우 전문적인 주제이므로 많은 분량을 할애하여 소개해도 부족하며, 알면 알수록 더욱 재미를 더해가는 것이 리눅스 커널의 기능이라는 사실을 꼭 말해두고 싶다.

/proc 디렉토리에 마운트되는 가상의 시스템은 실제 어떤 물리적인 매체도 없고 용량도 차지하지 않는다. 유닉스적인 전통에 따라 시스템 정보를 파일과 디렉토리 방식을 보여주고 있는 것이 특징적이다.

[root@leelab /proc]# ls

1/ 309/ 347/ 470/ ioports pci

2/ 322/ 356/ 5/ kcore rtc

208/ 333/ 365/ 542/ kmsg scsi/

222/ 338/ 37/ 543/ ksyms self@

231/ 339/ 383/ 608/ loadavg stat

242/ 340/ 384/ 637/ locks sys/

253/ 341/ 385/ cmdline mdstat uptime

264/ 342/ 386/ cpuinfo meminfo version

275/ 343/ 387/ devices misc

286/ 344/ 388/ dma modules

295/ 345/ 390/ filesystems mounts

3/ 346/ 4/ interrupts net/

[root@leelab /proc]#

한 번 /proc 디렉토리에 들어가서 ls 해보면 위와 같은 파일 목록을 볼 수 있다. 현재 프로그램을 얼마나 많이 실행중인가에 따라 디렉토리의 내용이 달라진다.

우선, 숫자로 된 디렉토리들은 모두 프로세스 id(pid)를 의미한다. 이 디렉토리에 들어가면 각 프로세스에 대한 내부 정보를 볼 수 있다.

self 라는 링크는 여러 자신의 pid를 가리킨다. 다른 창을 열고 가서 self 링크가 가리키는 pid를 비교해 보자. 정확히 말해 /proc 파일 시스템은 여러분이 들어가서 뭔가 보고자 할 때만 보여주는 리눅스 커널이 제공하는 신기루 같은 기능이다.

확인하기 위해서는 ls -l /proc이라고 해보면 된다.

-r--r--r-- 1 root root 0 jan 20 01:30 devices

-r--r--r-- 1 root root 0 jan 20 01:30 dma

-r--r--r-- 1 root root 0 jan 20 01:30 filesystems

-r--r--r-- 1 root root 0 jan 20 01:30 interrupts

-r--r--r-- 1 root root 0 jan 20 01:30 ioports

-r-------- 1 root root 41947136 jan 20 01:30 kcore

-r-------- 1 root root 0 jan 19 18:27 kmsg

-r--r--r-- 1 root root 0 jan 20 01:30 ksyms

-r--r--r-- 1 root root 0 jan 19 23:27 loadavg

-r--r--r-- 1 root root 0 jan 20 01:30 locks

-r--r--r-- 1 root root 0 jan 20 01:30 mdstat

-r--r--r-- 1 root root 0 jan 20 01:30 meminfo

-r--r--r-- 1 root root 0 jan 20 01:30 misc

-r--r--r-- 1 root root 0 jan 20 01:30 modules

-r--r--r-- 1 root root 0 jan 20 01:30 mounts

dr-xr-xr-x 2 root root 0 jan 20 01:30 net/

-r--r--r-- 1 root root 0 jan 20 01:30 pci

-r--r--r-- 1 root root 0 jan 20 01:30 rtc

dr-xr-xr-x 2 root root 0 jan 20 01:30 scsi/

lrwxrwxrwx 1 root root 64 jan 20 01:30 self -> 639/

-r--r--r-- 1 root root 0 jan 20 01:30 stat

dr-xr-xr-x 5 root root 0 jan 20 01:30 sys/

-r--r--r-- 1 root root 0 jan 20 01:30 uptime

-r--r--r-- 1 root root 0 jan 20 01:30 version

[root@leelab /proc]#

몇 가지 파일과 그 파일이 보여주는 정보에 대하여 알아보자.

cpuinfo 파일은 시스템의 cpu 정보를 담고 있는 파일이다. 그 내용을 볼 때는 cat 명령을 사용한다.

[root@leelab /proc]# cat cpuinfo

processor : 0

cpu : 586

model : pentium mmx

vendor_id : genuineintel

stepping : 3

fdiv_bug : no

hlt_bug : no

f00f_bug : yes

fpu : yes

fpu_exception : yes

cpuid : yes

wp : yes

flags : fpu vme de pse tsc msr mce cx8 mmx

bogomips : 331.78

[root@leelab /proc]#

interupts 파일은 사용중인 인터럽트 목록과 함께 몇 번의 인터럽트가 발생했는지 보여준다.

[root@leelab /proc]# cat interrupts

0: 2920360 timer

1: 2 keyboard

2: 0 cascade

6: 494 + floppy

8: 1 + rtc

9: 163890 eth0

10: 3012917 hisax

12: 18 ps/2 mouse

13: 1 math error

14: 6527 + ide0

[root@leelab /proc]#

이 파일 내용은 현재 시스템에서 사용중인 인터럽트와 사용중이지 않은 인터럽트를 알게 해줌으로써 하드웨어 장치의 인터럽트 선택에 도움이 된다.

ioports 파일은 사용중인 i/o 주소 목록을 보여준다.

kcore 파일은 ls 명령으로 확인해 보면 엄청나게 큰 파일이며, 지워보고 싶은 욕구가 발생하는 파일인데, /proc 시스템의 파일은 가상의 파일이므로 그럴 필요도 없고, 그럴 수도 없다. kcore는 여러분이 갖고 있는 메로리량과 똑같은 크기의 파일처럼 보일 것이다. 허가권은 오로지 root에게 읽기만 주어져 있으며, 현재 메모리 상태를 그대로 보여준다. 일반적으로 이 파일을 사용하는 일은 없다.

pci 파일은 pci bios 정보를 보여주는 파일이다.

stat 파일은 시스템 통계량을 보여주는 파일이지만, 그냥 cat으로 봐서 알아보기에는 힘들게 적혀있고, 통계 수치를 보여주는 프로그램에서 사용한다.

scsi 어댑터와 커널 드라이버 정보가 표시된 후 후반부에는 각 장치에 대하여 몇 바이트짜리 자료를 얼마나 읽고 써왔는지 통계치를 보여준다.

여러분이 많은 기능을 사용할수록 /proc 디렉토리의 내용은 풍부하게 된다. 앞으로도 /proc 디렉토리의내용은 정말로 많은 기능이 추가될 것이 예상되므로 관심 있는 사람은 이 기능들을 즐겨보기 바란다.

/proc 시스템의 파일 중에는 쓰기가 가능한 파일이 있는데, 이 파일에 특정값을 적으면 커널의 기능이 그 순간부터 바뀐다. 커널의 어떤 기능을 조절 할 수 있는 제어판의 역할도 하는 것이 proc 시스템이다.

▶ 시스템 관리 명령 디렉토리 /sbin

/sbin 디렉토리에는 관리자의 권한에서만 실행할 수 있는 명령들이 들어 있다.. 파일 시스템 처리 명령, 네트웍 인터페이스 설정 명령, 시스템 초기화 명령, 커널 모듈 관리 명령 등의 이에 속한다.

디렉토리 내용을 무작위로 외우려 하지 말고 그때그때 필요할 때마다 하나씩 알아나가는 현명함이 필요하다.

▶ 임시 파일 생성 디렉토리 /tmp

/tmp 디렉토리는 수많은 프로그램들이 작업을 위해 임시 파일을 만드는 공간이다. 이 디렉토리 내용은 정기적으로 지워지므로 어떤 자료를 영구적으로 보관할 수 있는 공간이 아니다.

drwxrwxrwt 3 root root 1024 jan 19 04:03 tmp/

/tmp 디렉토리는 공공장소나 다름없으므로 보안상의이유로 인해 스틱키(sticky) 비트가 부여되어 있다는 사실에 주목하라.

로그인 사용자가 많고, 많은 작업을 하는 시스템에서는 /tmp 디렉토리를 별도의 파티션으로 두고 마운트하여 사용하기도 한다.

▶ 시스템 가동중 가변 자료 저장 디렉토리 /var

/var 디렉토리는 가변(variable) 자료 공간을 의미한다. 시스템 운영중 자료값이 바뀌거나, 그 크기가 바뀌는 내용들은 /usr 디렉토리에 두지 않고 모두 /var 디렉토리를 사용하도록 fsstnd에서 권장하고 있다.

/var/log 디렉토리 아래에는 커널 메시지를 기록하는 파일, 삼바/웹 서버/메일 서버/ftp서버 등 각종 네트웍 서버들이 파일 전송 상황이나 에러 상황을 기록해 두는 파일 등의 기록 내용이 저장된다. 레드햇 리눅스는 이 기록 파일이 너무 커지는 것을 막기 위해 정기적으로 기록 파일을 쪼개어 .1, .2, .3 이런 식으로 숫자를 붙여 확인 후 삭제할 수 있도록 해준다.

/var/lock 디렉토리는 잠금 파일들이 위치하는 곳으로서, 어떤 장치를 사용하고 있는 프로세스가 장치 사용중이라는 표시를 파일로 남긴다. 보통 모뎀을 사용하고있는 uucp스타일의 잠금 파일 (lck..ttys1과 같은 이름)이 이 곳에 있다. subsys라는 디렉토리 밑에는 레드햇 리눅스가 시스템 v 초기화 도중 실행한 데몬들의 프로세스 번호를 기록해 둔 파일이 놓인다.

/var/spool 디렉토리는 스풀링(spooling)이 필요한 프로그램들이 사용하는 공간으로서, 대형 서버의 경우에는 엄청나게 큰 용량을 요구하는 디렉토리에서 별도의 대형 파티션을 두고 마운트하여 사용하기도 한다.

우선, /var/spool/mail 디렉토리는 수신된 메일을 사용자 이름의 파일로 보관하는는 곳이다. 대형 시스템에서는 관리를 안 하는 경우 몇몇 사용자가 메일을 읽지도 않고, 몇 십메가 도는 몇 백메가의 메일을 남기는 경우가 있으므로 적절한 스크립트 또는 수동으로 알아서 지워줘야 한다.

/var/spool/lpd 디렉토리는 프린팅을 위해 스풀링을 해두는 곳이다.

at, cron 등은 각각 at 데모, cron 데몬이 예약 작업 또는 주기적인 작업을 위해 사용하는 공간이다.

/var/spool/news 디렉토리는 뉴스서버를 어떻게 운영하는가에 따라 그 용량이 천차만별인 디렉토리이다. 인터넷 뉴스그룹의 상당수를 받아들이려면 약 4기가 이상의 공간이 필요하다고 한다.

▶ /usr 디렉토리 하부구조

시스템의 기본적인 명령 이외에 뭔가 재미있고 필요한 기능을 가지고 있는 크고 작은 명령들은 /usr 디렉토리 팀에 존재한다. 무엇보다도 커다란 덩치의 x 윈도우 시스템이 바로 이 디렉토리 밑에 놓인다.

디렉토리 이름 설 명

x11r6 x 윈도우 시스템 버전 11릴리즈 6이후의 시스템 루트 디렉토리

bin 추가 사용자 프로그램들(필수 명령 이외의 대부분의 프로그램)

dos 문서 디렉토리

games 게임 또는 교육용 소프트웨어 설치 디렉토리

include 프로그램밍 헤더 파일 디렉토리

info gnu info 문서

lib 각종 공유/정적 라이브러리(필수 라이브러리 제외)

local 지역적으로 생성된 추가 프로그램 저장 장소

man 맨 페이지 문서

sbin 관리자용 추가 프로그램(주로 네트웍 관련 데몬)

share 아키텍쳐 독립적인 자료 저장소

src 프로그램 소스 디렉토리(커널 소스, 레드햇 패키지 디렉토리)

네트웍상에 많은 리눅스 박스들이 있을 때는 몇 대의 서버에만 소프트웨어를 full로 설치하고, 나머지 디스크 용량이 부족한 리눅스 박스들은 /usr 디렉토리만 만들어 두고, 고속 네트웍으로 연결된 서버의 /usr 파티션을 nfs로 마운트하여 사용한다. 유닉스나 리눅스는 네트웍을 통한 자원 공유의 관점에서 오랜 역사를 가지고 있다.

/usr 디렉토리 이하를 nfs로 제공하기 위해서는 /usr 디렉토리를 읽기만 가능한 상태로 제공하는 것이 일반적이므로, 프로그램들은 임시 파일이나 설정 파일 등을 /usr 디렉토리에서 찾지 않아야 한다. nfs로 네트웍을 통해 공유한 /usr 디렉토리 내용은 실행 바이너리와 라이브럴리만 제공하고 설정 파일은 지역 시스템의 것을 읽어야 하며, 임시 파일을 /usr 디렉토리에 만들려고 생각해서는 안된다.

이런 것들 모두가 fsstnd에서 고려하는 바이다.

/usr/bin 디렉토리의 내용은 얼마나 많은 패키지를 설치했는지에 따라 달라지지만, 대체로 정말로 많은 파일 개수에 놀랄 정도일 것이다.

▶ x 윈도우 시스템을 위한 디렉토리 /usr/x11r6

/usr/x11r6 디렉토리의 구조는 /usr 디렉토리와 비슷하다. 실행 바이너리는 /usr/x11r6/bin 디렉토리에 들어가고, 라이브러리는 /usr/x11r6/lib 디렉토리에 놓인다.

▶ 헤더 파일 디렉토리 /usr/include

여러분이 c 프로그래밍을 할 때 #include <stdio.h>라는 전처리 문장을 넣으면 바로<>안에 적은 파일을 찾는 기본 디렉토리가 /usr/include이다.

이 안에는 기본 c 라이브러리 헤더 파일은 물론, 각종 추가 라이브러리의 헤더 파일들이 놓여 있다.

▶ 라이브러리 디렉토리 /usr/lib

/lib에 들어갈 정도는 아닌 부차적인 라이브러리들이 들어간다.

/usr/bin 디렉토리에 놓인 실행 바이너리들이 동적 링크된 라이브러리가 들어가며, .a로 끝나는 정적(static) 라이브러리들도 들어 있다. 보통 컴파일을 하면 동적 라이브러리가 있을 때 동적인 방식으로 링크해 주지만, 컴파일러 옵션에 -static 등을 주면 실행 명령에 모두 포함시키는 정적 링크도 가능하다. 정적 링크인 경우 사용되는 라이브러리가 정적 라이브러리이다.

정적인 c 라이브러리인 libc.a, libm.a 가 그 예이다.

▶ 온라인 문서 디렉토리 /usr/info, /usr/man

리눅스에서는 두 가지 형식의 온라인 매뉴얼을 제공한다. 하나는 모든 유닉스에서 기본으로 제공하는 맨 페이지 방식이고, 나머지 하나는 gnu 프로젝트의 산물인 info 방식이다. 맨 페이지 자료들은 /usr/man 디렉토리에 범주별로 저장되며, info 파일은 /usr/info 밑에 저장된다.

맨 페이지는 man 명령을, info 페이지는 info 명령을 사용한다.

▶ 또 하나의 관리자만을 위한 명령 공간 /usr/sbin

/usr/sbin은 시스템이 부팅되고 작동하기 위해 필요한 필수 관리 명령을 제외한 수많은 네트웍 데몬들이 위치하는 곳이다.

▶ 소스 디렉토리 /usr/src

/usr/src 디렉토리 밑에는 전통적으로 가장 중요한 커널 소스가 linux라는 디렉토리 이하에 설치된다.

레드햇 리눅스에서는 redhat 이라는 디렉토리가 있다. 소스 rpm을 가져다 컴파일할 바이너리 rpm 패키지를 만들어 설치하려는 사람에게 필요한 공간이다. 패키지를 만들거나 재컴파일할 때 rpm 명령이 사용하는 공간이다.

▶ 직접 컴파일한 소프트웨어가 설치되는 /usr/local

/usr/local 디렉토리 이하의 구조는 /usr 디렉토리 구조와 거의 유사하다.

/usr/local 디렉토리는 매우 중요한 의미를 갖는다. 관례상 패키지가 아니라 여려분이 직접 소스를 가져다 컴파일한 소프트웨어를 설치하는 공간이다.

특히, 컴파일과 설치 작업을 매우 쉽게 해주는 gnu autoconf 기능을 제공하는 소스를 가져다 컴파일하고 설치하는 경우 기본 경로는 /usr/local로 잡힌다.

여러분이 설치한 소프트웨어와 배포판에서 제공하는 소프트웨어를 구분하는 것이 매우 중요하다. 만약 어떤 기능의 소프트웨어를 여러분 스스로 다시 컴파일하여 사용하길 원한다면, 기존의 패키지가 설치된 프로그램과 뒤죽박죽 섞이지 않도록 패키지를 먼저 지워놓고 시작하는 것이 현명하다.

배포판 제작자들은 fsstnd에 의거하여 암묵적으로 /usr/local 밑에 아무 것도 설치하지 않고, 업그레이드시에도 전혀 건드리지 않기로 하였기 때문에 보호받을 수 있는 공간이기도 하다.

만약 여러분이 프로그래밍을 하여 남들에게 소스를 제공한다면 마찬가지로 기존의 관례를 지켜주기 바란다. 맘대로 /usr/bin 디렉토리에만 설치하게 한다든지 하는 것은 정말로 많은 사람을 불쾌하게 만들 것이다. 소프트웨어 제작자라면 gnu autoconf, automake 기능을 익히는 것이 좋다.