UNIX 설치 관련

duraboys 2009. 9. 3. 13:11

2009. 9. 3. 13:11

UNIX 설치 관련..

1. Apache Program 설치에 대해서

. smc.vnet.net에서 apache program을 다운로드한다.
. gunzip apache-1.3.3-sol25-sparc-local.gz (약 2.3M)
. pkgadd -d apache-1.3.3-sol25-sparc-local
위와같이 명령을 실행하면
자동으로 /usr/local/apache 디렉토리를 만들고 시스템에 인스톨 시킴.
. atom1을 netscape server로 사용하기 위해 몇가지 configuration 작업을
해주어야 함.
. vi /usr/local/apache/etc/access.conf
# Document Root to
   < Directory /home1/homepage>

   AllowOverride All
   < Directory /usr/local/apache/share/cgi-bin>

. vi /usr/local/apache/etc/thhpd.conf

Port 80
ServerAdmin root@atom1
ServerRoot "/usr/local/apache"
Errorlog /usr/local/apache/var/log/error_log
ServerName atom1.dwt.daewoo.co.kr

. vi /usr/local/apache/etc/srm.conf
DocumentRoot /home1/homepage

. vi /etc/hosts

165.133.5.31     atom1.dwt.daewoo.co.kr atom1

. apache daemon을 시작할때
>/usr/local/apache/sbin/apachectl start

. apache daemon을 정지할때
>/usr/local/apache/sbin/apachectl stop

. mkdir /home1/homepage
. vi /home1/homepage/index.html

여기서부터 자신의 홈 페이지를 작성할 수 있다.

* 시스템이 부팅할때 자동으로 httpd daemon을 수행하고자 할때

. cp /usr/local/apache/sbin/apachectl /etc/rc3.d/S101apache
. vi /etc/rc3.d/S101apache
적당히 에디트 한다.
. 아파치 데몬의 시작/정지는
> /etc/rc3.d/S101apache start
> /etc/rc3.d/S101apache stop

Samba Server

작성자 : 박을식

최종수정일 : 1998년 12월 31일

8-1.삼바(Samba)의 설치

8-1-1.삼바란?

삼바(Samba)는 유닉스와 윈도우즈간의 자원 공유를 위해 만들어 졌다. 원래 유닉스의 파일 시스템과 윈도우즈의 파일 시스템과는 서로 호환이 되지 않았다. 그러나 이 삼바가 나오면서 부터는 윈도우즈 파일 시스템에서 유닉스 파일시스템 자원을 공유하여 유닉스 서버 머신의 자원을 마치 윈도우즈 파일 시스템의 로컬 자원처럼 사용할 수 있게 된 것이다. 물론 삼바를 통해 유닉스쪽에서 윈도우즈쪽의 파일시스템으로도 접근가능하다. 그리고 랜 매니저 클라이언트에는 반드시 TCP/IP 기반의 네트웍 프로토콜이 설치되어있어야 하며 그이유는 삼바 자체가 이 TCP/IP 프로토콜을 기반으로 자원을 공유하기 때문이다. TCP/IP프로토콜을 사용하므로 지금은 삼바 서버도 나와 일반 PC를 웹 서버로 만들어 주는 프로그램도 등장하였다.지금 현재까지는 1.0.17버전까지 나와 있고 계속해서 버그 테스트를 거쳐 패치 버전이 계속 나오고 있는 중이니 이글을 읽는 독자들은 http://samba.anu.edu.au 사이트를 방문하여 최신 삼바 프로그램을 다운 받는 것이 좋을 것이다.

8-1-2.삼바 설치

삼바를 설치하는 것은 크게 다음과 같이 구분할 수 있다.

0. 삼바프로그램을 구한다.(^^;)

1. 삼바프로그램을 컴파일 하여 이진 파일로 생성한다.( 현재 다양한 기반의 이진 파일이 있으니 컴파일 하기가 어렵다거나 귀찮은 사람들은 이진 실행 파일을 다운 받는다.)

2. 앞으로 원활한 삼바의 활용을 위해 매뉴얼 페이지를 설치한다.

3. configuration file을 자신의 시스템과 사용자의 요구에 맞게 환경을 설정한다.

4. 클라이언트의 접속에 대한 설정을 한다.

8-1-2-1. 컴파일

일단은 http://samba.anu.edu.au를 방문하여 삼바 프로그램을 구한다. 아마도 자신의 시스템에 맞는 이진 파일을 구할 수 있을 것이다.그래서 만약 자신이 사용하는 플렛폼의 이진 실행파일을 구했다면 1)~5)까지는 그냥 건너 뛰어도 무방하다. 그렇지 않고 소스를 구해서 자신에게 맞게 조절을 하고 싶다면 다음의 절차를 따른다. 그리고 아래의 작업은 슈퍼유저(root)의 권한하에서 이루어 져야 한다.

1) source/Makefile을 열어서 각종 조절값에 대한 사항들을 점검한다. 대부분 기본값들 그대로 놔두고 자신이 확실히 알고 있는 것만 고치도록 한다.

(단,아래의 내용은 꼭 들어가야 제대로 컴파일이 된다.)

2) which operation system - 이 부분은 삼바를 설치하려는 시스템의 운영체제를 적어 주는 부분이다.자신이 사용하는 시스템을 잘 모를 경우 다음의 명령으로 알 수 있다.

실행: # uname -a

SunOS elecom 5.5.1 Generic sun4u sparc SUNW,Ultra-1

밑은 실행 결과이고 이 시스템은 SunOS를 사용하며 호스트 이름은 elecom이고 커널은 5.5.1 버전을 쓰고 있고 일반 sun4u sparc SUNW,Ultra-1기종이다.

3) AFS나 DFS 사용자이면 make 파일의 AFS와 DCE/DFS부분에 걸려있는 주석문자(#)를 제거한다.

4) 필요한 라이브러리를 확인하고 만약 라이브러리가 없다면 make 파일에 직접 넣어준다.

5) 실행: #make

6) 실행: #make install

우리가 일반적으로 말하는 인스톨과정이다. 윈도우 프로그램의 경우 요즘은 대부분 setup로 나온다 그에 반해 유닉스 계열의 프로그램들은 make install혹은 install형식을 많이 사용한다.

7) 기본값으로 컴파일 했을 경우에는 `/usr/local/samba'에 삼바가 설치 된다. 만약 설치 디렉토리를 다른 것으로 했다면 그 디렉토리 Path를 기억하고 있어야 한다.

8) 덧붙여 한마디 - samba-1.9.17p1버전에서는 make install후에 'smb.conf'를 기본 디렉토리('/usr/local/samba/lib')로 복사하지 못하므로`samba-1.9.17p1/examples/smb.conf.default'를 `/usr/local/samba/lib/smb.conf'로 수동복사해야 한다. 그리고 make파일 혹은 컴파일에 자신이 없다면 이진 파일을 찾아 바로 인스톨을 해도 무방하다. 이진 파일 형태로 제공되는 것들은 이미 다양한 시스템에 맞게 컴파일이 되어 있으므로 자신의 시스템 환경에 맞는 이진 파일만 찾아 설치 하는 것이 괜한 수고를 덜을 수 있을 것이다.

8-2. 삼바 Configuration.

#.../lib/smd.conf 설정

삼바가 설치된 디렉토리로 가서 lib/smd.conf를 보면 다음과 같은 형태일 것이다.


[global] printing =sysv printcap name = /etc/printcap mangle case = no load printers = no short preserve case = yes preserve case = yes

이 부분에서는 [global] 항목에 다음 3줄이 없다면 넣어준다.

mangle case = no

preserve case = yes

short preserve case = yes

한글 파일명이 깨어지는 경우에 대비하기 위해서이다. 1.9.17 버전에서는 미리 기본값으로 설정되어 있으므로 위의 사항과 다른 분들만 고치기 바란다. 그리고 대부분 그냥 기본값으로 설정되어 있는대로 사용하시기를 권고한다. 일단 환경을 맞춘후 잘 동작하는 상황에서 차근차근 하나하나 고치면 환경 설정하면서 부딪치는 많은 오류를 줄일 수 있다. 만약 BSD 계열의 printer 패키지를 사용하는 분들은 [global] 항목에 ``lpq command = /usr/ucb/lpq''를 넣어주는 것이 좋다.


[homes] comment = Home Directories browseable = no read only = no create mode = 0755

[homes] 항목의 ``create mode = 750''을 ``create mode = 755''로 변경한다. 만일 당신이 지극히 개인적인 사람이라서 자신이 생성한 파일을 외부에 공개하기 싫다면 ``create mode = 700''으로 설정한다. 이는 파일 퍼미션 설정과 같으므로 자세한 설명은 퍼미션 부분을 참고하시 바란다.


[printers] comment = All Printers path = /tmp browseable = no printable = yes public = no writable = no create mode = 0700

1.9.17버전에서는 smb.conf에 대한 메뉴얼 페이지 (smb.conf.5)가 새롭게 추가되었으므로 이를 착실히 읽고 조절파일에 손을 대어야 한다. 여기서는 간략히 환경 설정만 하는 것이므로 삼바 매뉴얼 형식의 자세한 사항은 직접 위의 파일에서 정보를 얻기 바란다.

8-3. netbios 이름 서버와 삼바 서버의 설치

위의 과정이 매끄럽게 진행되었다면 서버의 설치작업으로 들어간다. 서버의 설치시 고려해야 할 사항으로 서버를 어떻게 동작시킬 것인가를 결정하여야 한다. 여기서 결정해야 할 것은 smbd (삼바 서버)와 nmbd (netbios 이름 서버)를 daemon으로 동작시킬 것인지, inetd로 동작시킬 것인지 결정하는 것이다. 물론 daemon으로 동작시키는 것이 속도면에서는 유리하지만 시스템 자원을 항상 점유하고 있으므로 시스템 성능을 고려한다면 inetd로 띄우는 것도 고려되어야 한다. 즉,시스템 부하가 많이 걸린 서버라면(즉,하나의 서버에 여러 서비스를 하는 중이라면) inetd로 삼바서버를 띄우는 것이 유리하고 삼바서버의 동작속도를 빠르게 하기 위한 목적이라면 daemon으로 동작시키는 것이 유리하다. 이 것은 사용자 스스로 어떻게 할것인지 자신의 시스템 환경을 고려하여 결정할 사항이다. 여기서 주의 할 것은 위의 두가지 방법을 동시에 사용하지는 못한다는 것이다.

8-3-1.daemon으로 서버동작 시키기.

컴퓨터가 처음 부팅될때 자동으로 시동되도록 만들기 위해서

(SunOS 4.1.x) - '/etc/rc.local'이나

(System V 계열) - `/sbin/rc3.d'에

'/usr/local/samba/bin/smbd -D' 와 '/usr/local/samba/bin/nmbd -D' 명령을 추가한다.

8-3-2.inetd.conf로 서버동작 시키기.

1)`/etc/services'에 아래 두줄을 추가한다.


netbios-ssn 139/tcp netbios-ns 137/udp

2)`/etc/inetd.conf'에 다음 두줄을 추가한다.


netbios-ssn stream tcp nowait root /usr/local/samba/bin/smbd smbd netbios-ns dgram udp wait root /usr/local/samba/bin/nmbd nmbd

단, 위의 사항을 추가하는 경우 중복 선언이 되었나 확인한다. 중복 선언이란 같은 정의문장이 2개 이상 있는 것을 말한다. 그리고 inetd.conf는 유닉스 계역에 따라 조금씩 차이가 있으므로 위의 사항과 틀리다면 해당 매뉴얼 페이지를 참조한다.

8-4.삼바 서버 동작 검사.

daemon으로 띄우는 경우는 위의 환경 설정이 끝난후 리부팅 명령으로(reboot) 다시 시스템을 초기화 하면 실행되게 된다. 혹은 아래의 명령을 실행하면 동작하게 된다.


# /usr/local/samba/bin/smbd -D # /usr/local/samba/bin/nmbd -D

inetd를 사용한다면 `/etc/inetd.conf'와`/etc/services'를 수정하는 것으로 이미 동작은 되고 있다. 이렇게 사바 서버를 동작 시켰다면 다음사항들을 체크하여 서버가 제대로 동작하는 지를 확인하기 바란다.

여기서,일단은 삼바가 설치된 유닉스 호스트가 elecom.hogik.ac.kr이고 공유자원이 유닉스 사용자 youngpc 의 홈 디렉토리라는 가정하에 설명하겠다.

1) 유닉스의 클라이언트로부터 삼바 서버에 접속

삼바 패키지에 딸려오는 클라이언트로 접속을 시도한다. 그리고 다음과 같이 명령을 내린다 (이때 컴퓨터의 이름은 elecom이 된다.)

# smbclient '\\elecom\youngpc'

암호를 정상적으로 입력하면, ftp와 유사한 프로그램이 동작하는 것을 확인할 수 있을 것이다.정상적으로 동작을 한다면 `help'라는 명령을 내려서 필요한 명령어를 살펴보며 삼바 클라이언트의 사용법을 익히기 바란다.

2) PC쪽의 클라이언트(Win95, WinNT, OS/2)로부터 삼바 서버에 접속

PC쪽의 도스 창으로부터 다음과 같이 명령을 내린다.

(이때 컴퓨터의 이름은 elecom으로 된다.)


dos> net use d: \\elecom\youngpc

위의 명령은 elecom에 있는 youngpc홈 디렉토리를 d:드라이브로 사용하겠다는 것이다.

만약 이와 같이 했는데 PC 클라이언트에서 암호가 틀렸다고 경고 상자가 뜬다면 네트웍 클라이언트로 로그인 했는지 확인한다. 윈도우 로그인과 네트웍로그인은 다른 것이므로 자신이 처음 윈도우 접속시 네트웍 클라이언트로 접속했는지를 확인한다. 그리고 유닉스쪽의 계정 이름과 네트웍 클라이언트 로그인 이름이 같은 지를 확인한다. 이는 반드시 그럴 필요는 없지만 될 수 있으면 같이 하는 것이 많은 오류로부터 해방될 것이다.

8-5.삼바의 사용

삼바를 성공적을 설치 했고 제대로 동작하는지 확인하는 과정도 끝났다면 삼바를 효율적으로 활용하는 방법에 대해 알아 보겠다. 물론 삼바자체가 기본적으로 네트웍에 물려 있는 유닉스와 윈도우 시스템을 기반으로 설명되고 있으므로 네트웍에는 이상이 없고 다른 시스템상의 문제가 없다는 가정하에 설명이 진행 될 것이다. 즉, 삼바의 설정에 대해서만 알아보도록 할 것이다.

8-5-1.유닉스 파일 시스템을 PC에서 사용.

우리가 이렇게 삼바를 설치한 것도 유닉스와 윈도우 같의 원활한 파일공유를 위해서였다. 그러므로 이제부터는 유닉스 시스템의 파일 시스템을 일반 PC에서 공유하여 사용하는 방법에 대해 알아보겠다.

1) 반드시 네트웍 클라이언트로 접속한다. 될 수 있으면 유닉스 계정과 네트웍 클라이언트 접속 이름과 같으면 좋다.

2) 연결하는 방법에는 여러 가지 방법이 있는데

처음 방법은 직접 네트웍 환경에서 삼바 서버가 설치되어 있는 컴퓨터 이름을 찾는다. 그런후 삼바 서버가 설치된 컴퓨터 이름을 클릭하면 자신의 홈 디렉토리 이름의 폴더가 보일 것이다. 이때 그 폴더에서 마우스 오른쪽 버튼을 누른후 '네트워크 드라이브 연결'메뉴를 선택하여 적절한 드라이브를 선택하면 선택한 드라이브로 유닉스쪽의 홈데릭토리가 공유된다.

두 번째 방법은 직접 입력하는 방법이다. 이는 메뉴바에서 디스크 항목을 선택한 후 네트워크 드라이브 연결을 선택한다. 그러면 어디에 '네트워크 드라이브'를 연결할 것인지 드라이브 명을 지정해 준다음 유닉스의 Path를 쳐주면 된다. 즉, 삼바 서버가 깔려있는 곳이 elecom.hongik.ac.kr 이고 계정이름이 youngpc라면

\\elecom\youngpc로 쳐주면 된다. 이때 네트웍 컴퓨터 이름앞에는 '//'가 붙어야 한다.

다른 방법으로는 도스 창으로부터 직접 net명령을 이용하는 방법이 있다. 이는 삼바 서버를 테스트 할 때 사용했던 방법이다. 이외에도 여러 방법이 있지만 위의 방법들이 일반적이다.

8-5-2.유닉스에 붙어 있는 프린터를 사용하자.

삼바를 이용하면 일반 윈도우 상의 네트웍 프린터기 연결과 같이 유닉스쪽의 프린터를 공유하여 사용할 수 있다.

1)조절판(Control panel)을 선택.

2)프린터 항목을 선택.

3)프린터 추가 선택.

4)인쇄할 포트를 선택한다.이때 삼바가 설치된 호스트 이름이 elecom.hongik.ac.kr이고 프린터 이름이 lp일 때

`\\elecom\lp'라고 대화상자에 입력한다.

5)인쇄에 사용할 제어기를 선택한다.(해당 프린터 드라이버 디스켓 활용)

이때, 레이저 프린터 기종은 각 프린터 매뉴얼을 참조한다.

6)시험인쇄를 해본다.

8-5-3. 유닉스에서 PC의 파일 시스템 사용.

1) 일단 PC쪽의 파일을 사용하기 위해서는 PC쪽의 사용자가 공유를 해놓아야 한다.

공유하고자 하는 디렉토리로 가서 마우스 오른쪽 버튼을 클릭하면 공유메뉴가 나온다. 이때 자신이 원하는 공유 모드를 설정하고 필요하면 암호 설정한다.

2)유닉스 콘솔모드나 터미널모드에서 다음을 입력한다.

# smbclient '\\컴퓨터이름\공유디렉토리이름'

컴퓨터이름은 PC쪽의 컴퓨터 이름이고 공유디렉토리 이름은 자신이 공유 디렉토리로 설정한 디렉토리의 이름이다. 만약,컴퓨터이름이 youngpc이고 그 컴퓨터에서 share라는 디렉토리를 공유로 설정해 놓았다면

% smbclient '\\youngpc\share'

해주면 된다. 이때 공유 디렉토리에 암호가 걸려있다면 암호를 물어올 것이다. 올바른 암호를 입력하고 제대로 PC로 접속이 되었으면 dir이라고 쳐본다. 그러면 해당 공유 디렉토리의 내용이 나타날 것이다. 자세한 삼바 클라이언트의 사용법은 'help'명령으로 확인한다.

3)작업을 종료하려면 'Ctrl + D'를 누른다.

8-5-4.유닉스에서 PC에 붙어 있는 프린터를 사용하자.

일단 cheetah라는 이름의 윈도우가 깔려 있는 시스템이 있다고 가정한다. 이 시스템에는 lp라는 이름으로 공유된 프린터기가 있다. 이 프린터기를 elecom.hongik.ac.kr에서 사용하기위한 작업을 준비해 보자!

1) 실행: # smbclient '\\cheetah\lp' -P -N

위에서 옵션 'P'는 프린터 공유를 의미하고 N은 패스워드를 그냥 지나간다는 의미이다. 2)lcd 명령을 사용하여 인쇄하고 싶은 파일이 있는 곳으로 간다.

smb: \> lcd /home/youngpc

3)put 명령을 사용하여 인쇄할 파일을 프린터로 보낸다. 여기서 프린터는 포스트스크립트를 지원하는 프린터라고 가정한다.

smb: \> put galleon.ps

위의 명령은 galleon.ps라는 포스트스크립트 파일을 PC의 프린터에서 출력하겠다는 의미이다.

8-5-5.PC의 파일을 UNIX 쪽의 장치로 백업

아직까지는 이렇다한 PC쪽의 백업 장치가 뚜렷이 나타나고 있지 않고 있다. 대부분 그냥 하드디스크에 중요한 정보를 그냥 담거나 아니면 플로피나,ZIP,JAZZ,PD등을 이용할 것이다. 물론 소량의 정보의 경우는 위의 것들로도 충분하고 JAZZ 드라이브의 경우 2Gbyte라는 용량을 지원함으로써 왠만한 데이터는 모두 백업 가능하게 되었다. 그러나 아직은 고가이고 만약 유닉스 시스템쪽에 놀고 있는 DAT가 있다면 그것들을 활용하면 좋을 것이다. 유닉스 시스템의 경우 백업의 중요성 때문에 대부분 DAT는 있을 것이다. 속도는 느리지만 백업용으로는 가격대 성능(용량)면에서 타의 추종을 불허한다. 그러므로 이제는 PC의 파일들을 유닉스에서 백업해 보기로 하자.

1)삼바 디렉토리의 bin 디렉토리로 들어가서 smbtar를 아래와 같이 편집한다.

2) 'SMBCLIENT'의 내용을 "/삼바가 설치된 디렉토리 path/bin/smbclient"로 고친다.

3) 삼바 서버의 테이프 드라이브(DAT)에 공 테이프를 넣고, 처음으로 감아둔다.

4)윈도우즈 시스템으로 가서 백업할 디렉토리를 공유한다.

5) 실행: # smbtar -s PCname -x PCdirectory -t /dev/rmt0

위의 실행에서 s옵션으로 어떤 PC에서 가져올 것인가를 설정하고 x옵션으로 어떤 공유디렉토리를 백업할 것인가를 지정해주며 t옵션으로 백업장치를 선택한다.

즉,위의 가정에서 cheetah의 share를 백업한다면

# smbtar -s cheetah -x share -t /dev/rmt0

로 하면된다.

6) 백업을 할 때 각 블록 크기를 '-b' 옵션으로 정의해줄 수 있다.

실행: # smbtar -s cheetah -b 1024 -x share -t cheetahPC.tar

위의 예는 cheetah시스템의 share디렉토리를 cheetahPC.tar의 파일로 1024블럭단위로 백업한다는 의미이다.

7)위에서 백업 받은 것을 복구하는 방법에 대하여 알아보면 다음과 같다.

(단, 반드시 복구시킬 공유 디렉토리의 접근 허가(permission)가 읽기/쓰기로 되어있어야 한다.)

실행: # smbtar -s cheetah -x share -t /dev/rmt0 -r

위의 실행은 디바이스'rmt0'(DAT)에서 cheetah의 share로 복원한다는 뜻이다.

실행: # smbtar -s cheeath -x share -t cheetahPC.tar -b 1024 -r

위의 실행은 파일'cheetahPC.tar'에서 cheetah의 share로 복원한다는 뜻이다.

이렇듯이 뒤에 '-r'옵션만 주게 되면 복원되는 것이다.

8-5-6.윈팝업으로 메세지 전달하기

기본적으로 등록되는 프로그램은 아니지만 윈도우즈에 보면 '윈 팝업(win popup)'이라는 프로그램이 있다. 파일 크기는 작지만 매우 유용한 기능을 수행한다. 이 윈 팝업은 메모리상에 떠 있으면서 전송되는 메시지가 있으면 윈도우즈 화면에 나타내주고 반대로 가른사람에게도 메시지를 보낼 수 있는 프로그램이다. 삼바의 경우는 기본적으로 윈도우즈를 지원하게 만들어 졌고 이 윈 팝업에 대한 지원도 하고 있다.

1) 일단은 윈도우즈 시스템에 윕 팝업을 구동한다.(기본적으로 windows디렉토리에 있다.)

실행: > winpopup.exe

2) 유닉스 시스템에서 다음과 같이 실행한다.

실행: # smbclient -M cheetah

여기서 cheetah가 윈도우즈 시스템의 이름을 말하며 '-M' 옵션이 메시지를 전달하겠다는 뜻이다.

3) 만약 'cheetah'라는 이름을 인식하지 못하면 '-I' 옵션으로 cheetah의 IP주소로 다시 시도한다.

4) 정상적인 연결이 되면 메시지를 입력하면 된다.

5)종료는 'Ctrl+D'이다.

네트웍의 최적화

작성자 : 박을식

작성일 : 1998년 12월 31일

4장. Network Optimize

1.System 망에 인식 시키기

2. Multi IP 할당.

같은 IP로 다른 도메인명을 쓰려고 한다면 httpd 데몬을 다른 port로 셋팅하여 쓰면

된다.

111.1.1.1:80 디폴트 포트이고

111.1.1.1.:8000으로 하여 하나더 셋팅을 하여 쓰면 된다.

이렇게 하면 두개의 httpd 데몬이 떠있는 셈이 되고 그로 인해 여러개인 도메인명을 쓸수가 있는 것이다.

3. Domain 등록.

4. DNS Server 구축.

5. NFS(Network File System) 구축.

5-1. NFS란?

NFS(Network File System)는 다른 시스템들과 다른 운영체제들간의 네트웍을 통해 파일 시스템을 공유할 수 있는 서비스이다. NFS는 원격 사용자에게 local files또는 디렉토리를 원격사용자 자신의 local Machine처럼 사용할 수 있다.

5-2. NFS 환경

5-2-1. NFS 자원

NFS 자원이라는 것은 네트웍을 통해 공유할 수 있는 자원을 말하며 파일 시스템 혹은 파일 시스템내의 파티션을 의미한다.

5-2-2. NFS 서버

NFS 서버는 자신의 파일 시스템또는 파티션을 원격 시스템이 네트웍을 통하여 공유할 수 있도록 해주는 시스템으로 네트웍상에 자신의 NFS 자원을 공유해주어야 한다.

/etc/dfs/dfstab 파일내에는 NFS서버의 공유 목록을 등록할 수 있으며 이 파일내에 등록된 공유 목록은 시스템 리부팅시에 자동으로 네트웍상에 공유된다.

5-2-3. NFS 클라이언트

NFS 클라이언트는 네트웍을 통하여 원격 시스템이 공유해준 네트웍 자원을 마운트해서 사용하는 시스템을 의미한다. NFS 클라이언트는 'mount'명령을 이용하여 공유된 자원을 사용할 수 있으며 /etc/vfstab에 NFS를 통해 마운트할 목록을 기록함으로써 부팅시에 자동으로 NFS 자원을 마운트 할 수 있다.

5-2-4. 데몬(Daemon)

5-2-4-1.서버측

#/usr/lib/nfs/nfsd - client의 파일 시스템 요청을 처리하며 NFS 서비스가 가능하도록 해준다.이는 run level 3에서 S15nfs.server에 의해 수행된다.

#/usr/lib/mountd - mountd는 RPC server로서 클라이언트의 파일 시스템 마운트 요청을 처리한다. 클라이언트로의 요청시에 /etc/sharetab을 참조해서 해당 파일 시스템을 클라이언트가 마운트 할 수 있도록 도와 준다.

5-2-4-2.클라이언트측

#/usr/lib/nfs/statd : lockd deamon 과 인터페이스하여 NFS 에서의 locking service 를 위한 crash 또는 recovery 기능을 제공한다.

#/usr/lib/nfs/lockd : kernel 에서 발생된 lock 처리나 또는 remote 의 다른 lock deamon 의 lock 처리 담당한다. lockd(lock daemon)가 lock request 를 RPC/XDR 을 통하여 전달 한 후에는 status monitor daemon 에 request 를 보내어 statd deamon 이 monitor service 가 가능하도록 한다.

5-3. 파일 시스템 공유

5-3-1.Sharing File Resources

1) share 명령.


share [ -F nfs ] [ -o specific option ] [ -d description ] pathname

rw : 지정된 path 내의 디렉토리를 read/write 권한으로 공유할 때 사용한다.

ro : 지정된 path 내의 디렉토리를 read-only 권한으로 공유할 때 사용한다.

ro=client[:client] 지정된 client 들은 read-only 권한으로 공유할 때 사용한다.

rw=client[:client] 지정된 client 들은 read/write 권한으로 공유할 때 사용한다.

root=host[:host] 지정된 host 들은 uid 0 이며 슈퍼유저(root)권한으로 해당 디렉토리를 공유할 때 사용한다.

anon=uid : 다른 uid 를 가지고 client 들이 access 가능토록 공유할 때 사용하며 만약 client 가 uid=0 로 access 시 슈퍼유저(root)권한으로 해당되는 디렉토리를 사용할 수 있다.

2) NFS에서 사용되는 명령들.

<서버쪽 명령들>

#share - Network 상에 NFS server 의 Resources 를 share 해주거나 또는 자신이 network 상에 share 한 Resources 를 display 해주는 명령이다.

#unshare - share 해준 NFS Resource 에 대한 service 중단하는 명령이다.

#shareall - /etc/dfs/dfstab 에 등록된 모든 list 를 network 상에 share 해주는 명령이다.

#unshareall - /etc/dfs/dfstab 의 모든 share list 에 대한 서비스를 중단하는 명령이다.

#/etc/dfs/dfstab - system booting 시에 자동적으로 NFS Resources 를 network 상에 share 시에 등록해주는 파일이다.

<클라이언트쪽 명령들>

# mount: 원격 NFS server로 부터의 NFS 자원을 클라이언트에 공유하거나 mount 되어 있는 목록들을 보여줌.

# umount: mount 되어 있는 NFS 자원을 제거시킨다.

# showmount: NFS server로 부터 어떠한 자원이 공유되었는지 나타내준다.

# dfshares : 원격 또는 지역 시스템의 NFS 자원을 나타내준다.

5-3-2.서버

NFS서비스를 해주려는 시스템을 말하며 해당 시스템에서 3개의 파일을 작성해야 합니다.

#/etc/dfs/share1 를 읽기쓰기(rw)로 공유한다고 할 때,

1) 실행: #share

반드시 필요한 것은 아니지만 현재의 공유 상태를 나타내는 명령이므로 현재의 설정 상태를 알고 다음 작업을 하시는 것이 좋을 것이다.

2) #/etc/dfs/dfstab 파일에 'share -F nfs /share1'의 내용을 입력한다.

3) #/etc/dfs/fstypes 파일에 'nfs NFS Utilities'의 내용을 입력한다.

4) #/etc/dfs/sharetab 파일에 '/share1 - nfs rw'의 내용을 입력한다.

위에서 살펴 보았듯이 'ro'로 주면 읽기전용(Read-Only)이 됩니다.

이 3개의 파일을 만들어 놓으면 부팅시마다 자동으로 NFS가 동작하므로 해당 디렉토리를 공유할 수 있습니다.또한 슈퍼유저(root)권한으로 'share -F nfs -o rw /user1' 이라고 해도 위의 작업과 동일한 결과를 갔습니다. 그러나 NFS의 경우는 보안문제로 인하여 일반유저가 사용하기에는 권한이 안되는 곳이 많을 것입니다.

5-3-3.클라이언트

서버로 설정된 시스템으로부터 공유된 자원을 요청하여 사용하려는 시스템을 말합니다.

1) 서버로부터 공유된 자원을 Mount할 디렉토리를 만듭니다.

ex> #mkdir /nfsmnt라고 만들고...

2)#/etc/vfstab에 다음 줄을 등록합니다.


server_name:/share1 - /nfsmnt nfs - yes -

server_name에는 위에서 NFS 서버로 설정한 호스트 이름을 적어주면 되고 서버이름뒤의 '/share1'은 서버가 제공해주는 공유 자원을 말합니다.

3) 실행: #mount /nfsmnt

4) 참고: 이런 nfs를 설정하는데는 각 시스템마다 약간은 다른 실행 프로그램이 있을 수 있습니다.share 대신에 exportfs를 쓰는 시스템도 있고 기본적인 명령형태가 아닌 프로그램형태로 지원하는 곳도 있습니다.그러나 여기서는 일반적인 경우만을 알아봤습니다. 그리고,sunOs에서는 호환성때문에 exportfs도 지원하고 있습니다.

5-3-4. 마운트( Mount)

위에서는 간략하게 알아보았지만 여기서는 자세히 하나하나 그 옵션에 대해서 알아 보도록 하겠다.


mount [ -F nfs ] [ -r ] [ -m ] [ -o specific_options ] mount point

-r : 읽기 전용으로 마운트

-m : /etc/mnttab 테이블에 entry 를 추가시키지 않고 마운트.

-o : 특성 옵션설정.

< 특성 옵션 테이블 >
rw\|ro	자원을 읽기쓰기\|읽기전용으로 마운트한다.(기본값은 'rw')
suid\|nosuid	Setuid 실행에 대한 승인/거부를 할 수 있다.(기본값은 'suid')
bg\|fg	만약 첫 번째 시도가 실패했을 경우 재시도를 background로 할 것인가 아니면foreground로 할 것인가를 설정하는 것이다. (기본값은 'fg')
retry=n	마운트 요청을 재시도 할 횟수를 설정하는 곳이다.
rsize=n	read buffer사이즈 설정 (기본값은 '8192')
wsize=n	write buffer사이즈 설정 (기본값은 '8192')
soft\|hard	서버에서 반응이 없을 때 에러를 반환할 것인가 아니면 서버로부터의 반응이 있을때까지 재시도 할 것인가를 설정하는 곳이다. (기본값은 'hard')
intr\|nointr	서버로의 응답을 기다리는 동안 키보드 인터럽트를 허용할 것인가 허용하지 않을 것인가를 설정하는 곳이다. (기본값은 'intr')

5-4.NFS 예제

위에서 알아본 설정 방법들의 실제 적용예를 알아보도록 하겠다.


nfs server: hostname : one ip address 192.9.200.1 OS: SunOS 5.4 nfs client: hostname : two ip address 192.9.200.2 OS: SunOS 5.4 nfs client: hostname : three ip address 192.9.200.3 OS: SunOS 4.1.3

<예제에 적용된 시스템 사항>

5-4-1. Solaris 2.x 에서의 share and mount

1) NFS서버에 공유 디렉토리를 만든다.


one# mkdir /usr/disk1 /usr/disk2 /usr/disk3 /usr/disk4 one# ls -alsd /usr/disk* 2 drwxr-xr-x 2 root other 512 12월 19일 13:33 /usr/disk1/ 2 drwxr-xr-x 2 root other 512 12월 19일 13:33 /usr/disk2/ 2 drwxr-xr-x 2 root other 512 12월 19일 13:33 /usr/disk3/ 2 drwxr-xr-x 2 root other 512 12월 19일 13:33 /usr/disk4/

2) #/etc/dfs/dfstab을 수정한다.


one# vi /etc/dfs/dfstab share -F nfs -o rw /usr/disk1 share -F nfs -o root=two:three /usr/disk2 share -F nfs -o anon=0 /usr/disk3 share -F nfs -o ro, rw=client /usr/disk4 :wq

3)서버 공유 실행


one# shareall one# /etc/init.d/nfs.one start

4)서버 설정 내용보기


one# cat /etc/dfs/sharetab /usr/disk1 - nfs rw /usr/disk2 - nfs root=two /usr/disk3 - nfs anon=0 /usr/disk4 - nfs ro,rw=two one# dfshares RESOURCE SERVER ACCESS TRANSPORT one:/usr/disk1 one - - one:/usr/disk2 one - - one:/usr/disk3 one - - one:/usr/disk4 one - -

5)클라이언트에 서버로부터 NFS 자원을 마운트할 디렉토리를 만든다.


client# mkdir /usr/userA /usr/userB /usr/userC

6) 서버 NFS 자원 공유 상황을 알아본다.


client# dfshares one RESOURCE SERVER ACCESS TRANSPORT one:/usr/disk1 one - - one:/usr/disk2 one - - one:/usr/disk3 one - - one:/usr/disk4 one - -

7)얻어진 정보에 따라 원하는 디렉토리에 마운트 한다.


client# mount -F nfs one:/usr/disk1 /usr/userA client# mount -F nfs one:/usr/disk2 /usr/userB client# mount -F nfs one:/usr/disk3 /usr/userC /usr/disk1 on one:/usr/userA read/write/remote on 토 12월 16 23:16:01 1996 /usr/disk2 on one:/usr/userB read/write/remote on 토 12월 16 23:35:28 1996 /usr/disk3 on one:/usr/userC read/write/remote on 토 12월 16 23:16:59 1996

8) 공유 확인


client# cd /usr/userA client# touch test_file touch: test_file cannot create client# cd /usr/userB client# touch test_file client# ls -al client# cd /usr/userC client# touch test_file client# ls

위에서 /usr/userA의 디렉토리에서 읽고 쓰기 옵션인데도 쓰기가 안됨을 볼 수있다. 이런때는 서버쪽의 /usr/disk1의 권한이 755 이기 때문이다.이런때는 다음과 같이 서버쪽의 권한을 변경해 주어야 한다.

실행: #chmod 777 /usr/disk1

위의 명령을 서버쪽에서 수행하고 나면 클라이언트가 서버의 /usr/disk1에 읽고 스기가 가능해 진다.

5-4-2.Solaris 1.x 에서의 mount

서버쪽의 작업은 위의 1)~4)의 작업과 동일하고 서버가 이미 설정되었다는 가정하에 설명한다.

1) 'one'의 마운트 상황을 알아본다.


three# showmount -e one /usr/disk1 (everyone) /usr/disk2 (everyone) /usr/disk3 (everyone) /usr/disk4 (everyone)

2) 마운트 할 디렉토리를 만들고 마운트 작업 수행 및 확인.


three# mkdir /usr/userA three# mount -t nfs one:/usr/disk1 /usr/userA three# mount one:/usr/disk4 on /usr/userA type nfs (rw) three# cd /usr/userA three# mkdir /usr/userB three# mount -t nfs one:/usr/disk3 /usr/userB three# cd /usr/userB

5-6. NFS에서 마주치는 문제들.

NFS 에서의 장애가 발생시 원인은 NFS server 또는 NFS client 그리고 네트웍자체의 문제중의 하나로 볼 수 있다. NFS server system 에는 mountd,nfsd daemon 이 반드시 running 되어야 하고 /etc/dfs/dfstab 에 entry 가 있으면 booting 시 자동적으로 nfsd,mountd 를 running 하게 되어 있다. ( /etc/rc3.d/S15nfs.one script 에 의해 실행됨)

1)"NFS server not responding,still trying "

hard mounted 의 경우 NFS server 의 fail 시 display 됨.

2)"NFS server ok"

NFS server 가 정상적으로 NFS resource 를 share 시 위와 같은 message가 나타남.

3)"intr option"

default mount option 으로 server 로 부터의 응답이 없을때이며 이때는 Ctrl-C key 를 입력 interrupt 을 수행할 수가 있다.

4) NFS server 에서의 check 사항

시스템의 processor 를 check

one# ps -ef |grep mountd

one# ps -ef |grep nfsd

rebooting 을 하지 않은 상태에서 다음과 같이 daemon 구동

one# /usr/lib/nfs/mountd

one# /usr/lib/nfs/nfsd -a 8

여기서 nfsd -a : NFS데몬을 모든 가능한 경로를 통해 띄우겠다는 의미이다.

8 : Number of ones.

5) 다음과 같이 NFS server 의 네트웍 상태를 점검한다.

client# /usr/sbin/rpcinfo -u nfs

error 인 경우: rpcinfo: RPC: Program not registered

program 100005 is not available

정상인 경우 : program 100003 version 2 ready and waiting

client# /usr/sbin/rpcinfo -u mountd

error 인 경우: rpcinfo: RPC: Program not registered

program 100005 is not available

정상인 경우 : program 100005 version 1 ready and waiting

program 100005 version 2 ready and waiting

6) Clearing Remote Mounting Problems

ex1) NFS client 에서 NFS server 의 resource 를 mount 하고자 할때 다음과 같은 error 가 발생되면,

" mount:.... server not responding:RPC_PMAP_FAILURE - RPC TIMED OUT"

위의 경우는 nfs server 의 shareing list down 또는 wrong run level, 또는 rpcbind 가 dead or hung 상태일때 발생하며 다음과 같이 조치해야 한다.

실행:# who -r ( run level checking : runlevel 3 에서 nfsd,mountd daemon 이 running 됨 )

만약 run level 이 2 가 아니면 run level 3 가 전환하거나 시스템을 rebooting 시켜서 rpcbind daemon 을 restart 시킨다.

실행:#who -r

run-level 2 Dec 18 19:23 3 0 S

실행:#init 3 * run level 3 로 전환

ex2) "mount: ... server not responding: RPC_PROG_NOT_REGISTERED"

이런 메시지가 발생된다면 mount 명령어가 server 의 rpcbind 까지는 실행이 되었으나 mountd daemon 이 running 되지 않는 경우이다. 그러므로 다음과 같이 실행하여준다.

실행: #/usr/sbin/rpcinfo -u mountd

ex3) "mount: ... No such file or directory"

이런 메시지가 발생된다면 remote directory 또는 local directory 가 존재하지 않는 경우이다. 그러므로 마운트될 디렉토리를 만들어준다.

ex4) "mount: ..... : Permission denied"

이런 메시지가 발생된다면 nfs server 의 share list 에 client 가 등록되지 않는 경우이다. 이런 경우에는 nfs서버에 클라이언트를 등록해준다.

7)마운트 옵션 중 hard 와 soft option 의 차이

NFS server 의 down 시 ( bg,soft,intr,option 으로 mount 시도 )

booting 중에 다음과 같은 message 가 나타남


nfs mount: one::RPC: Rpcbind failure -PRC: Timed out nfs mount: backgrounding:/usr/nfs

booting 이 끝난 후에 process 상태를 보면


two# ps -ef \|more root 138 1 8 02:43:53 ? 0:00 mount -o bg,soft,intr one:/usr/user /usr/nfs

위와 같은 processor 가 background 로 running 중임을 알 수 있다. NFS server 가 다시 booting 된 후에는 background 로 도는 process 에의해 정상인 경우적인 NFS mount 수행.

mount option 을 fg,hard,intr option 을 사용시 에는 rebooting 도중 hangup 상태로 계속 NFS server 측으로 retrying 을 시도하며 NFS server 가 정상인 경우상태로 돌아오면 다음과 같은 message 가 나타난다.


NFS mount:one::RPC: Rpcbind faulure -RPC : Timed out NFS mount: retrying: /usr/nfs nfs mount: /usr/userA: mounted ok

위와 같이 mount 를 끝낸후 booting procedure 를 계속 진행한다.

5-7. NFS의 보안상 허점.

NFS의 보안은 사용하는 유저에게 크게 의존한다. 호스트자체가 만들어낸 디렉토리를 설치하기 위해 정확한 포맷을 정하는 것은 UNIX의 종류에 따라 다양하다. 그러나 일반적으로 /etc/exports에 저장된다. 이 파일은 많은 디렉토리를 가지고 있으며, 각각은 NFS가 그 디렉토리로 마운트할 수 있는 특정한 호스트또는 넷트웍그룹의 목록을 가지고 있고 이 목록이 'Access List'이다. 호스트는 개별적인 시스템이지만 네트웍그룹은 /etc/netgroup에 명시되어 있는 호스트와 유저이름의 조합니다. 이러한 파일들은 읽기전용,읽기쓰기 가능,그리고 슈퍼유저(root)가 접근 할 수 있는가에 대한 정보를 포함하고 있다. 중요하게 기억해야 할 점은 /etc/ecports에 있는 특정한 디렉토리를 Access List가 포함하고 있는가이다.

1)아무런 내용도 없을 경우 이 세상 모두에게 공개되어 있는 것이다.

2) 형식화된 호스트명이 있는 경우 디렉토리는 허가된 사람만이 마운트 가능하다. 이것은 신뢰할 만한 사람을 의미하는 것은 아니며 만약 NFS가 PC에서 돌아가는 상황이라면어느 누구든지 마운트 가능하게 된다.

3)네트웍 그룹명이 있는 경우에 '호스트명,,'라고 적혀 있으며 적혀 있는 호스트 사용자만이 마운트 가능하다. 또한 ',유저명,'라고 적혀 있으면 이 사용자는 어디서든지 마운트 가능하다. 그러나 호스트명과 유저명이 없으면 누구나 마운트 가능하게 된다.

4)호스트명이나 네트웍 그룹명이 아닌 단어일 경우에는 호스트명을 잘목 입력하였다면 이 이름은 네트웍 이름으로부터 인식된다. 그러나 넷트웍그룹에 그 단어가 존재하지 않으면 빈칸으로 인식된다. 그러므로 누구든 마운트 가능하게 된다.

Basic Administration for UNIX Administrator

작성자 : 박을식

작성일 : 1998년 12월 31일

시스템의 전반적인 관리법을 소개한다. 본장의 예제들은 각 시스템에 따라 세부적인 옵션의 미묘한 차이가 있을수 있음을 염두하여야 하며, 여기서는 솔라리스(Solaris)를 기본으로 설명한다.

1.1 프로세스 (Process)

유닉스는 동시에 여러 가지 작업을 수행한다. 프로세스란 시스템에 적제(load)되어 수행되는 작업 뜻한다. 예를들어, 디렉토리의 목록을 보여주는 'ls' 명령을 사용한다면, 'ls' 프로그램이 수행되어 메모리를 할당받고, 수행될 때를 프로세스라 볼수 있다. 10명의 사용자가 동시에 'ls' 명령을 수행한다면, 10개의 프로세스가 시스템에 추가적으로 수행된후 종료된다.

유닉스 시스템에는 어떠한 명령에 대한 프로세스 이외에도, 시스템 운영에 관련된 다수의 프로세스가 수행되고 있는데, 실제로 프로세스는 아주 짧은 시간동안 CPU 시간을 할당받아 번갈아 수행된다.

관리자는 프로세스를 감시함으로써 시스템 자원을 많이 차지하는 불필요한 프로세스를 제거하고, 때로는 비정상적으로 동작하는 프로세스를 재 시동 시킬수 있는 권한을 갖는다.

1.1.1 프로세스의 5가지 상태

프로세스는 다음과 같이 크게 5가지의 상태로 분류할수 있다.

- 수행중 (Runnable)

일반적인 프로그램(ls, grep)등의 프로세스는 주로 수행중 상태에 머무른다. 이때 프로세스에게 CPU 사용이 허가된다.

- 기다림 (Sleeping)

데몬(daemon)등의 프로세스가 기다림 상태에 오래 머무른다. 이 상태에서는 줄곧 어떠한 자극(요청)을 기다리기 때문에, 시스템의 성능에 별 영향이 없다.

- 임시저장 (Swapped)

시스템의 메모리가 여유치 못할 때, 오랜시간 활동치 않는 프로세스를 보조기억장치에 저장한후, 메모리를 확보하였음을 나타낸다.

- 유령 (Zombie)

자식 프로세스가 종료되길 기다리지 않고, 모 프로세스가 먼저 종료되었음을 뜻한다. 프로그램의 버그등의 이유로 비정상적인 종료에 야기되어 파생된다. 대부분 유령 프로세스는 제거되어야 한다.

- 정지 (Stopped)

기다림 상태와 비슷하지만, 어떠한 처리가 종료되길 기다리는 것은 아니다. 또한 자의적으로 깨어날 수 없다. 사용자가 '^Z'(Ctrl + Z)로 프로세스를 정지시켰을 경우 프로세스는 정지 상태가 된다.

1.1.2 프로세스 상태 파악 (ps)

현재 시스템에 상주하는 프로세스의 상태는 'ps' 명령으로 확인할수 있다. 'ps'를 활용하여 프로세스의 PID, PPID, 우선순위, 수행 터미널등의 정보를 파악할수 있다.

인자없이 'ps'를 실행하면, 시스템에서 명령을 수행한 사용자의 프로세스만이 간략히 보여지며, 시스템에 활동중인 모든 프로세스를 보기위해 '-ef' 옵션이 활용될수 있다.


root@/> ps -ef \| more UID PID PPID C STIME TTY TIME CMD root 0 0 0 01:26:59 ? 0:01 sched root 1 0 0 01:27:02 ? 0:00 /etc/init root 134 1 0 01:28:03 ? 0:01 /usr/sbin/inetd -s root 752 134 0 03:41:34 ? 0:00 in.telnetd nobreak 754 752 0 03:41:35 pts/2 0:01 -sh root 782 134 0 03:20:50 ? 0:00 in.telnetd root 784 782 0 03:20:51 pts/1 0:01 -csh root 885 784 1 03:49:50 pts/1 0:00 ps -ef

위는 시스템의 프로세스중 몇몇부분을 추려 보였다.(공백은 편의상 삽입)

각 필드의 의미는 [표 5.1]에 나타내었다.

[표 5.1] 'ps -ef' 필드 해설
필드명	의 미
UID	해당 프로세스의 소유주를 나타내며 이는 프로세스의 활동 권한을 뜻한다.
PID	시스템에서 부여하는 해당 프로세스 고유 번호이다.
PPID	프로세스를 생성한 프로세스(Parents Process)의 PID이다.
C	스케줄러에 의해 현재 활동중인 프로세스를 표시하며 '0'으로 표시된 것은 휴지 상태를 나타낸다.
STIME	프로세스가 시작된 시간을 시:분:초로 표시한다
TTY	프로세스가 제어되는(연결된) 터미널을 표시한다. '?'는 제어 터미널이 연결되어 있지 않음을 뜻한다.
TIME	CPU 사용시간이 시:분 형태로 출력된다. 이는 사용자가 느끼는 수행시간이 아니라, 프로세스가 스케줄링되어 실제 수행한 시간의 합을 의미한다. 10분간 프로그램을 수행하였는데, 실제 CPU 사용할 때간은 10초를 기록할수 있다.
CMS	실행 명령어를 보여준다.

프로세스는 트리(tree)구조의 종속관계로 구성된다. 위의 예제에서 PID와 PPID의 연관관계를 주의깊게 살펴보기 바란다.

수행된 'ps -ef' 명령은 csh(pid:784)의 자식 프로세서로 실행중(C 값이 1)이고, csh은 in.telnetd(텔렛데몬 pid:782)의 자식프로세서로 파생되었음을 알 수 있다.

즉, inetd(pid:134)가 TCP 23번 포트로의 요청(사용자가 텔넷으로 접속시도)에 의해 in.telnetd(pid:782)를 생성하였다. 사용자의 텔넷 클라이언트는 in.telnetd와 연결된후 사용자 인증과정을 거쳐 접속하게 된다. 이때 '/etc/passwd'에 기입된 사용자 기본 쉘인 csh(pid:784)이 in.telnetd에 의해 생성되고, 사용자가 실행한 ps 명령(pid:885)이 csh에 의해 수행되었음을 알수 있다.

위 예에대한 프로세스 트리를 그려보면 다음과 같다.


sched \| /etc/init \| /usr/sbin/inetd -s \| +----------+----------+ \| \| in.telnetd in.telnetd \| \| sh csh \| ps -ef

프로세스의 좀더 상세한 정보를 얻기위해 'elf' 옵션이 사용될수 있다.


root@/> ps -elf F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD 19 T root 0 0 0 0 SY f0271ad0 0 23:51:19 ? 0:01 sched 8 S root 186 178 0 99 20 f5d9fcc8 348 f5d3ab7e 23:53:11 ? 0:00 lpNet 8 O root 2894 2403 1 99 20 f5f8f980 199 17:20:55 pts/1 0:00 ps -elf

'ps -ef'에서는 볼 수 없는 몇몇 추가 정보를 확인할수 있다. [표 5.2]에 추가 필드의 의미를 나타냈다.

[표 5.2] 'ps -elf' 필드 해설
필드명	의 미
F	프로세스 프레그(flag)를 의미한다. 별 의미는 없다.
S	프로세스의 상태를 표시한다. O = 현제 수행중 S = 처리가 종료되기를 대기함 R = 방금 생성된 프로세스로, 처리되기를 기다림 Z = 핸들링 할수 없는 좀비(Zombie) 프로세스 (제거 대상) T = 추적 모드(trace)로 수행되어, 일시 중단 되었다.
PRI	스케줄링된 우선순위, 낮을수록 높다.
NI	우선순위를 계산하기 위한 nice 값
ADDR	프로세스의 메모리 시작 주소
SZ	프로세스가 점유하고 있는 메모리 용량
WCHAN	프로세스 상태가 S 일 때 프로세스는 어떠한 처리가 종료되길 기다린다. 이때 처리되고 있는 수행의 메모리 시작 주소

1.1.3 시그널 (Signal)

유령(Zombie) 프로세스를 제거하거나, 프로세스를 재 시동하기 위해선, 프로세스와의 통신 방법이 필요하다. 유닉스에서는 각 프로세스에게 약속된 시그널을 보냄으로써 프로세스를 제어 할수 있는 방법을 제공한다.

시그널은 약 30여개가 준비되어 있는데, 다음과 같이 'kill -l' 명령으로 확인 가능하다.


root@/> kill -l HUP INT QUIT ILL TRAP ABRT EMT FPE KILL BUS SEGV SYS PIPE ALRM TERM USR1 USR2 CLD PWR WINCH URG POLL STOP TSTP CONT TTIN TTOU VTALRM PROF XCPU XFSZ WAITING LWP FREEZE THAW CANCEL RTMIN RTMIN+1 RTMIN+2 RTMIN+3 RTMAX-3 RTMAX-2 RTMAX-1 RTMAX

대부분의 시그널은 시스템에서 사용된다. 관리자가 프로세스에게 시그널을 보낼때는 프로세스를 제거하거나 재시동하고자 할 때이며, [표 5.3]에 나열된 3개의 시그널을 주로 활용한다.

[표 5.3] 주요 시그널
시그널명	번호	동작 형태
HUP	1	프로세스를 행업 시킨다. 즉, 프로세스를 완전히 종료시키고, 다시 시동 시킨것과 동일한 효과를 갖는다. 따라서 프로세스에 해당하는 설정사항을 변경하고 그것을 바로 적용하기 위해 사용한다.
KILL	9	프로세스를 강제 종료시킨다. 프로세스를 종료시킬 필요가 있을때는 기본적으로 'TERM' 시그널을 사용한다. 그러나, 프로세스가'TERM' 시그널을 무시하고 종료되지 않으면, 'KILL' 시그널을 사용하여 커널 차원에서 강제 종료 시킬수 있다.
TERM	15	프로세스를 종료 시킨다. 본 시그널은 프로세스가 시그널을 받은후, 자체적인 종료과정을 거쳐 정상 종료를 유도하는데 쓰인다. kill 명령을 시그널명 없이 사용하면 TERM 시그널이 보내진다.


- 잠깐 - 이러한 시그널은 단순히 관례적인 약속행위(프로그램 내부에서 시그널에대한 처리루틴이 존재해야함)임을 유의해야 한다. 따라서 모든 프로세스에 동일한 효과를 얻는 것은 아니며, 시그널 처리가 되어 있다 하더라도 반드시 예상된 처리가 수행되는 것은 아니다. 그러나, 대부분의 시스템 데몬 및 잘짜여진 어플리케이션은 이러한 시그널에 대한 처리가 준비되어 있고, 같은 느낌으로 동작된다.

1.1.4 프로세스 죽이기와 행업 (kill)

시스템을 관리하며 불필요한 프로세스의 제거 또는 수정된 설정사항의 적용을 위해서 프로세스를 죽이고 살리는 작업이 매우 빈번히 요구된다. 범용의 서버로써 사용되는 시스템은 규정된 점검 시간까지 시스템을 유지하기 위해, 리부팅 없이 프로세스를 제어하여야 할 때도 있다.

앞서 알아본 시그널을 프로세스에 보내는 명령으로는 'kill'이 있다. 인자로 주어진 PID에 해당 시그널을 보내어 준다.

'HUP' 시그널 활용예

inetd는 '/etc/services'와 '/etc/inetd.conf'에 설정된 TCP/UDP 포트를 관찰하다가 해당포트로 클라이언트의 요청이 있을 때, 그에따른 서버 데몬을 구동시켜주는 역할을 한다. 텔넷은 23번 포트(Well Known Port)가 사용되는데, 기업 망(LAN)의 방화벽(firewall) 설정이 외부에서는 웹(80 포트)만이 허용되어, 외부에서 telnet 접속이 불가능 하다고 가정하자.

이때 특정 서버의 telnet 서비스를 23번 포트에서 80번 포트로 옮겨서 외부에서 telnet 접속이 가능하도록 다음과 같이 '/etc/services' 파일을 수정하였다.


ftp 21/tcp # ftp telnet 80/tcp # telnet pop-3 110/tcp # Post Office 3

수정된 사항을 적용시키기 위해서, 시스템을 리부팅 시키는 것보다는 간단히 'inetd' 데몬을 재시작(행업) 시키자.


root@/> ps -ef \| grep inetd root 134 1 0 01:28:03 ? 0:01 /usr/sbin/inetd -s root 1164 784 1 05:23:20 pts/1 0:00 grep inetd root@/> kill -HUP 134

이제 외부에서 다음과같이 해당 서버에 접속포트를 명시함으로써 망 내부로의 접근이 가능하다. 본 예는 실제 방화벽구축에 있어서 내부 네트워크와의 게이트웨이(gateway)로 종종 사용되는 방법이다.


[nobreak@/home/nobreak]$ hostname star.elim.net [nobreak@/home/nobreak]$ telnet shinan.hongik.ac.kr 80 Trying 203.249.84.246... Connected to shinan.hongik.ac.kr. Escape character is '^]'. UNIX(r) System V Release 4.0 (shinan) Welcome to the 'shinan.hongik.ac.kr' Powered by H.S.N.S Hongik Shinan Network Security login:


- Well Known Port - 'Well Known Port'란 세계적으로 telnet은 23, ftp는 21, http(web)은 80과 같이 약속된 포트를 말한다. 따라서 telnet client는 서버의 telnet 서비스를 받기위해 23번 포트로 접속하면 되고, web browser에서는 서버의 80포트로 기본 접속하면 된다. 즉, well known port는 해당 클라이언트 프로그램에게 접속 포트를 명시하지 않았을 때 기본적으로 사용된다는 뜻이다.

'TERM', 'KILL' 시그널 활용예

다른 예로, 원하지 않는 사용자가 시스템에 다음과 같이 임의로 접속하였다고 가정하자.


root@/> finger Login Name TTY Idle When Where root Super-User pts/1 Thu 03:21 203.249.84.218 nobreak 'Crazy Guitar' pts/2 Thu 05:42 206.48.171.1

문제의 사용자(nobreak)를 강제 종료 시키기 위해 사용자가 연결된 쉘 프로세서를 알아내어 죽이는 일련의 절차를 따를수 있다. 대부분의 쉘은 'TERM' 시그널에 대한 종료 처리를 하지 않고 무시한다. 따라서 'KILL' 시그널로 비정상 강제 종료를 강행한다.


root@/> ps -ef \| grep nobreak # nobreak 사용자의 쉘 프로세스를 파악한다. root 1327 784 0 05:50:38 pts/1 0:00 grep nobreak nobreak 1295 1293 0 05:42:47 pts/2 0:00 -csh # nobreak의 모 프로세스 root@/> kill -TERM 1295 # 'TERM' 시그널로 프로세스 종료 시도 root@/> !ps # 종료 확인 ps -ef \| grep nobreak nobreak 1295 1293 0 05:42:47 pts/2 0:00 -csh # 종료되지 않았다. root 1329 784 0 05:50:46 pts/1 0:00 grep nobreak root@/> kill -KILL 1295 # 'KILL' 시그널로 강제종료 시도 root@/> !ps # 종료 확인 ps -ef \| grep nobreak root 1331 784 0 05:51:30 pts/1 0:00 grep nobreak

nobreak 사용자의 쉘이 종료되면 모 프로세스인 in.telnetd는 자동 종료되며, 쉘의 자 프로세스(nobreak가 쉘상에서 구동한)또한 모두 종료되며, nobreak 사용자의 터미널에는 다음과 같은 메시지와 함께 연결이 끊어질 것이다.


nobreak@/admhome/nobreak> ls # 서버 접속후 작업중 hack public_html nobreak@/admhome/nobreak> Connection closed by foreign host. # 강제 종료됨 [nobreak@cgi nobreak]$

1.1.5 우선순위 (nice)

1.2 파일 시스템 (File System)

2-1. 망가진 파일 시스템 복구

정상적인 시스템 종료 과정이 선행되지 않거나,잘못된 링크의 수행으로 인해 파일 시스템이 엉킬수 있다. 부팅시 일련의 검사작업에서 파일시스템이 심하게 손상된듯하면, 시스템은 자동적으로 싱글유저 모드로 진입한다.

이때, fsck란 명령어를 사용하여 다음과 같이 파일시스템을 복구하여야 한다. 대부분의 경우 손상된 파일은 정상적으로 닫혀지지 않은 응용파일에 국한된다. 하지만 종종 시스템관련 파일들의 손상이 야기되며, 이에대한 복구는 철저한 백업밖에 없다.

파일시스템의 검사작업은 멀티유저모드상에서 행하지 않는 것이 좋다. 가능하면 싱글유저모드로 부팅한후 작업하기 바란다.


root@/> sync (버퍼링된 데이터를 모두 저장한다.) root@/> sync root@/> init S (싱글유저모드로 진입한다.) INIT: New run level: S INIT: SINGLE USER MODE Type Ctrl-d to proceed with normal startup, (or give root password for system maintenance): root@/> fsck -y /dev/rdsk/c0t3d0s0 Currently Mounted on / Phase 1 - Check Blocks and Sizes INCORRECT BLOCK COUNT I=19477 (2 should be 0) CORRECT? yes Phase 2 - Check Pathnames Phase 3 - Check Connectivity Phase 4 - Check Reference Counts UNREF FILE I=19477 OWNER=haremoon MODE=100000 SIZE=0 MTIME=Sep 29 18:36 1997 CLEAR? yes Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? yes 22885 files, 307068 used, 174154 free (2554 frags, 21450 blocks, 0.5% fragment) * FILE SYSTEM WAS MODIFIED *** root@/> init 3 (멀티유저모드로 복귀한다.)

경험상 유닉스 파일시스템은 안정적으로 동작하지만, 사용하면 할수록 또, fsck를 돌리면 돌릴수록 조금씩 깨어지는것은 어쩔수 없다. 따라서, fsck를 필요이상으로 사용하지 않도록 한다.

2-2. 마운트

3장. 시스템 (System)

last

4장. 네트워크 (Network)

4-1.네트워크 상태 점검

w:이 명령은 누가 로그인해서 무슨일을 하고 있는지 보여준다. 이 프로그램은 ps에서 나타나는 프로세스 목록과 /etc/utmp를 조합하여 출력해주는 방식을 취하고 있다.


1: root@/root> w 2: 9:23pm up 2 day(s), 1:44, 2 users, load average: 0.00, 0.02, 0.02 3: User tty login@ idle JCPU PCPU what 4: youngpc console 9:16pm199days /usr/openwin/bin/audiotool 7 5: root pts/1 9:13pm 2 w 6: root@/root> w youngpc 7: 9:23pm up 2 day(s), 1:45, 2 users, load average: 0.00, 0.01, 0.02 8: User tty login@ idle JCPU PCPU what 9: youngpc console 9:16pm199days /usr/openwin/bin/audiotool 7 10: root@/root>

< w 명령의 사용예 >

1~5행:모든 사용자에 대한 정보 출력. 유저이음과 사용 터미널이름 접속한 시간과 접속 통계 및 CPU사용량 ,사용하고 있는 파일들에 대한 사항등을 나타내주고 있다.

6~9행:특정(youngpc) 사용자에 대한 정보 출력.

who: 이 명령은 시스템내에 누가 로그인해 있는지 사람의 목록을 출력해준다. 유닉스에서는 기본적으로 로그인을 할 때 자동으로 /etc/utmpdp에 어디로부터 로그인해 왔으며,언제 로그인을 했는지에 대한 사항들을 기록한다. 이 기록사항을 보여주는 것이 who명령이다.


root@/root> who youngpc console Dec 8 21:16 (:0) root pts/1 Dec 8 21:13 (203.249.87.8) root@/root>

< who 명령의 사용 예 >

로그인 사용자 이름과 접속 터미널명 접속 시간 및 원격 접속지 위치를 나타내고 있다.

finger: 이 명령은 who보다 사용자에 대한 좀더 자세한 정보를 얻기 위해 사용된다. 유닉스에서는 /etc/wtmp에 최근 로그인,로그아웃 시간을 기록한다. 이때 finger는 /etc/wtmp와 /etc/passwd 내의 정보를 결합하여 유저 정보를 나타내 준다.이외에도 이 명령은 사용자에 대한 인적 사항을 나타내 줄 수 있으며 각 유저 자신의 홈 디렉토리에 .plan 이라는 파일을 작성하여 자신을 알릴 수도 있는 것이다. 이때 이 .plan안에 있는 내용이 다른 사용자가 자신을 finger하면 나타나게 된다. 이 명령의 또다른 특징은 외부 정보에 대한 사항도 알려준다는 것이다. 즉, 어떤 한 시스템에서 다른 시스템으로 finger정보를 보내면 그 finger를 받은 시스템에서는 finger정보를 수집하여 다시 요청한 시스템으로 넘겨준다. 이때 양쪽 시스템 모두에 finger demon이 떠 있어야 하며 보안상의 이유로 이 finger demon을 막아 놓은 곳도 있다.


1: root@/root> finger @wow.hongik.ac.kr 2: [wow.hongik.ac.kr] connect: Connection refused 3: root@/root> finger @elecom 4: [elecom.hongik.ac.kr] 5: No one logged on 6: root@/root> finger @black 7: [black] 8: Login Name TTY Idle When Where 9: youngpc yim console Mon 21:16 :0 10: root Super-User pts/1 Mon 21:13 203.249.87.8 11: root@/root> finger youngpc 12: Login name: youngpc In real life: yim 13: Directory: /home/youngpc Shell: /bin/csh 14: On since Dec 8 21:16:39 on console from :0 15: 4 minutes 42 seconds Idle Time 16: No unread mail 17: No Plan. 18: root@/root>

< finger 사용 예>

1~2행: wow.hongik.ac.kr에 로그인해 있는 사용자를 보려 했으나 finger Demon을 막아놓아서 요청이 거절당한 경우이다.

3~5행: elecom에 로그인한 사용자를 보기 위한 명령이나 아무 사용자도 접속해 있지 않다.

6~10행: black에 로그인한 사용자에 대한 정보를 보여준다.

11~17행: youngpc에 대한 정보를 나타내주고 있다.

4-2. 네트워크 결함 발견.

많은 사람들이 네트워크하면 일단은 거리감을 느낀다. 그러나 사실상 알고 보면 그리 어려운 일들은 아니다. 그러므로 네트웍이 갑자기 다운되었다면 다음과 같은 사항들을 체크하여 기본적인 사항들을 체크해본다.

1) 게이트웨이 혹은 라우터 시스템이 다운된 경우

2) DNS가 다운된 경우( 이경우에는 IP주소로는 연결 가능하다.)

3) LAN선이 불량인 경우 ( 케이블을 케이블 테스터로 확인한다.)

4) 1번과 같은 사항이지만 장소를 옮겼거나 서브넷이 바뀌었을 경우 (이 경우 해당 서브넷의 게이트웨이로 바꿔주면 된다.)

4-2-1. Ping으로 연결 확인.

ping 명령의 경우는 사실상 간단한 명령이지만 네트워크의 상태를 점검하는데 가장 기본적으로 해보아야 할 명령이다. 이 명령은 어떤 호스트의 다운 여부나 네트워크 불능 여부를 파악하는데는 이 명령 하나면 된다. 내부적인 동작은 ICMP의 echo request기능을 이용하는데 사실 문제점은 이 명령만 가지고는 호스트가 문제는 있지만 다운되지는 않은 경우에는 네트웍상태를 파악하기가 어렵다는 것이다. 이런 경우에는 부수적으로 DNS혹은 NFS등의 서버에 대해서 테스트해서 부수적인 정보를 더 얻을 필요가 있다.

이 명령인자로 IP address와 Domain Name이 사용되므로 IP 주소를 입력했을 때 살아있던 것이 도메인 명을 넣으면 찾지 못한다면 그 호스트의 DNS 서버에 문제가 있는 것이다.

4-2-2. traceroute로 어디의 문제인가를 알아낸다.

일단 위의 ping명령으로 네트워크에 문제가 있음을 파악한 후에는 teaceroute명령으로 네트워크 선로의 어느 곳에 문제가 있는 지를 추적한다. 만약 traceroute의 결과중에서 도메인 이름이 안나오고 IP주소만 나올경우에는 그 호스트는 DNS에 등록되지 않은 경우이다.


www@~> /usr/sbin/traceroute wow.hongik.ac.kr traceroute to wow.hongik.ac.kr (203.249.66.245), 30 hops max, 40 byte packets 1 ccw.hongik.ac.kr (203.249.84.242) 0.937 ms 1.43 ms 0.942 ms 2 203.249.84.240 (203.249.84.240) 2.336 ms 1.93 ms 2.071 ms 3 wow.hongik.ac.kr (203.249.66.245) 10.574 ms 10.692 ms

<traceroute의 사용 예1>


www@~> /usr/sbin/traceroute www.oracle.com traceroute to inet07-1.us.oracle.com (192.86.154.111), 30 hops max, 40 byte pacs 1 ccw.hongik.ac.kr (203.249.84.242) 0.961 ms 1.066 ms 1.115 ms 2 203.249.84.240 (203.249.84.240) 2.23 ms 1.792 ms 2.336 ms 3 203.249.95.1 (203.249.95.1) 24.661 ms 8.678 ms 16.803 ms 4 168.126.59.254 (168.126.59.254) 24.752 ms 23.405 ms 31.19 ms 5 168.126.59.254 (168.126.59.254) 32.42 ms 168.126.63.61 (168.126.63.61) 20s 6 cent3-gsl.kornet.nm.kr (168.126.1.248) 14.721 ms 20.113 ms 168.126.63.61 s 7 cent3-gsl.kornet.nm.kr (168.126.1.248) 18.514 ms borderx2-hssi4-0.Bloomings 8 core2-fddi-1.Bloomington.mci.net (204.70.208.65) 298.423 ms borderx2-hssi4s 9 core2-fddi-1.Bloomington.mci.net (204.70.208.65) 257.313 ms 259.559 ms 2s 10 border3-fddi-0.SanFrancisco.mci.net (204.70.2.163) * * * 11 border3-fddi-0.SanFrancisco.mci.net (204.70.2.163) 528.615 ms oracle-corp.s 12 oracle-corp.SanFrancisco.mci.net (204.70.34.46) 235.228 ms 263.861 ms 24s 13 inet07.us.oracle.com (192.86.154.110) 221.721 ms 243.383 ms * www@~>

10번 패킷과 13번 패킷의 흐름을 보면 '*'표시가 있을 것이다. 이것은 게이트웨이가 제대로 동작을 안할 때 나타나게되고 그럼으로써 패킷을 제대로 처리하지 못하는 경우이다. 이러한 '*'가 계속해서 나타나면 그 게이트웨이는 다운된 것이고 가끔 이런 현상이 보인다면 네트워크의 패킷흐름이 너무 많아서 게이트웨이가 미처 다 처리하지 못해 생기는 결과 이므로 이 같은 경우에는 시간이 해결해 준다.(쩝! 달리 게이트 웨이와 접속환경을 더 좋은 것으로 바꾸는 것도 한 방법이지만......)또한 12번째 oracle-corp.SanFrancisco.mci.net와 13 번째 inet07.us.oracle.com사이에 패킷로드가 많이 걸려 있음도 알 수 있다.


www@~> /usr/sbin/traceroute www.lg.co.kr traceroute to www.lg.co.kr (165.243.5.37), 30 hops max, 40 byte packets 1 ccw.hongik.ac.kr (203.249.84.242) 0.968 ms 1.083 ms 1.222 ms 2 203.249.84.240 (203.249.84.240) 2.495 ms 2.032 ms 2.121 ms 3 elecom.hongik.ac.kr (203.249.87.4) !N !N !N

위의 예는 3번째 호스트에 보면 '!N'이 보일 것이다.이는 네트웍에 연결할 수 없음을 나타낸다. 즉, elecom.hongik.ac.kr의 라우팅 테이블에 문제가 있어서 패킷을 전달시키지 못하는 것을 말한다.

지금까지 traceroute로 패킷 흐름을 추적하여 네트웍 상태를 점검하였다. 그러나 traceroute를 통해 얻어지는 정보로 판단하는 것은 조심해야 한다. 패킷의 흐름을 조사한 것이기 때문에 마지막으로 해당 호스트를 ping을 해봐서 한번 더 확인하는 것이 실수를 하지 않을 것이다.

4-2-3. netstat로 네트워크 상태 체크

위의 사항들을 점검하여 게이트웨이 혹은 라우터에 이상이 없는데 특이하게도 어떤 시스템 혹은 몇 개의 시스템만이 네트워크가 매우 느린 경우가 있다.이런 경우에는 netstat명령으로 그 원인을 찾아보자.

netstat명령은 현재 시스템에서 네트워크를 사용하는 상황을 나타내 주는 명령이다. 어떤 유저가 어떤 작업을 하고 있는 지는 나오지 않으며, 다만 현재 이 시스템에서 어떤 포트(Port)가 사용되고 있으며 또한 어디에서 어떤 포트로 접속을 해오고 있다는 사실 정도는 알아낼 수 있다.


root@/root> netstat -i Name Mtu Net/Dest Address Ipkts Ierrs Opkts Oerrs Collis Queue lo0 8232 loopback localhost 16127 0 16127 0 0 0 hme0 1500 203.249.87.0 elecom 275482 0 46183 0 7508 0 root@/root>

위의 예제에서 '-i' 옵션은 네트워크 카드의 상태를 보여준다.

이 경우 'lo0'가 받은 패킷수는 16127개이며 입력 에러수는 0개,출력 패킷수는 16127개이며 출력에러는 없다(0개).

여기서 입출력의 비가 1%를 넘게 되면 문제가 있다는 것이다. 만약 어떤 한 시스템에서만 이런 결과가 나온다면 그 컴퓨터의 네트워크 카드에 문제가 있다는 것으로 해당 컴퓨터의 네트워크를 교환하는 것이 좋다. 만약 다수의 컴퓨터 시스템에서 이런 결과가 나온다면 시스템 사이의 선로에 문제가 있다는 것이므로 선로를 테스트 한후 교체해야 한다.

충돌(Collis)필드는 패킷의 충돌 횟수를 의미하며 출력 패킷에 대한 충돌회수의 비로 비교하여 1% 이하이면 일반적인 경우이고 3%이상이면 네트워크에 심각한 부하가 걸리고 있다는 것이다. 위의 경우 'hme0'에 부하가 많이 걸리고 있는 것이다.(그러나 위의 경우는 일반적인 경우이다. 'lo0'인 로컬 호스트에 비해 그렇다는 것이다.)


root@/root> netstat -I hme0 5 input hme0 output input (Total) output packets errs packets errs colls packets errs packets errs colls 274782 0 46002 0 7504 290907 0 62127 0 7504 30 0 1 0 0 30 0 1 0 0 23 0 2 0 0 23 0 2 0 0 29 0 2 0 0 29 0 2 0 0 62 0 2 0 0 62 0 2 0 0 19 0 2 0 0 19 0 2 0 0 21 0 2 0 0 21 0 2 0 0 11 0 2 0 0 11 0 2 0 0

위의 예는 시간 간격을 두고 네트워크의 상태를 체크하는 경우이고 '-I' 옵션이 이런 역할을 수행해주며 'hme0'는 검사하고자 하는 네트워크이며 마지막 5는 5초마다 검사를 하겠다는 뜻이다.

UNIX System Directory Hierarchy

작성자 : 박을식

작성일 : 1998년 12월 31일

솔라리스(Solaris) 2.x 버전에 초점을 맞추어 설명된다. 따라서 다른 OS에서는 파일의 위치와 디렉토리 이름등이 몇몇 다를수도 있다. 그러나, 대부분의 유닉스에서 지금부터 기술할 파일과 디렉토리를 비슷한 형태로 제공하니, 기본적인 개념을 이해하면 충분히 확장가능하다.

2-1. 전반적인 Directory 구조

OS를 인스톨한 직후 솔라리스 2.x 시스템은 대략 [그림 2-1]과 같은 트리(Tree)의 디렉토리를 형성한다.

'dev' 디렉토리에는 장치(I/O device)연동 파일들이 존재한다. 유닉스는 하드웨어를 제어할 때, 그것을 직접 핸들링 하는 것이 아니라, 장치를 파일로 매핑해놓고 실제 어플리케이션은 파일과의 통신을 함으로 장치가 제어된다.

'usr' 디렉토리는 사용자 유틸리티('/usr/bin')와 라이브러리('/usr/lib')등 전반적인 응용프로그램가 위치한다. '/etc' 디렉토리에는 여러 가지 시스템 설정파일과 관리 유틸리티가 있다.

'/var' 디렉토리는 시스템의 전반적인 로그가 싸이게 되고, 그중 주의 깊게 보아야 할 디렉토리는 'adm'과 'mail' 디렉토리 이다. 시스템의 보안적 문제가 발생하였다면, 보통 본 디렉토리의 로그 분석부터 들어간다.

'/etc' 디렉토리에는 시스템 설정에 관한 전반적인 파일들이 모여 있다. 로긴시 보여지는 메시지, 네트웍 설정, 서버 스크립트, 마운트 테이블등은 모두 이곳에 존재한다.

그리고 그림에는 없지만 '/proc'라는 재미있는 디렉토리가 있는데, 여기엔 현재 시스템에 구동중인 프로세서들이 PID를 파일명으로 하여 존재한다. 파일의 용량은 메모리 점유량을 표시하며, 소유주는 프로세서 UID/GID를 말한다. 당연히 지우려해도 지워지지 않고, 표시되는 파일 크기는 실제 파일시스템을 점유하는 용량이 아니니 참고 바란다.

2-2. 사용자 접속(login) 로그

2-2-1. 현재 시스템 접속 상황

■ /var/adm/utmp, /var/adm/utmpx

현제 시스템에 접속되어 있는 사용자에 대한 정보를 갖는다. 'finger' 명령은 이 파일을 참조한다. 파일의 내용이 일반 텍스트형식으로 저장되지 않아 'who'와 'last' 명령을 사용하여 볼아야 한다. 다음은 'finger'명령과의 내용을 비교하여 준다.


root@/var/adm> finger Login Name TTY Idle When Where root Super-User pts/1 Sat 03:47 203.249.84.218 nobreak 'Crazy Guitar' of th pts/2 2 Sat 03:54 cgi.hongik.ac.kr root@/var/adm> who utmp root pts/1 9월 13 03:47 (203.249.84.218) nobreak pts/2 9월 13 03:54 (cgi.hongik.ac.kr) root@/var/adm> last -f utmpx nobreak pts/2 cgi.hongik.ac.kr Sat Sep 13 03:54 계속 로그인 중 root pts/1 203.249.84.218 Sat Sep 13 03:47 계속 로그인 중 reboot system boot Fri Sep 12 20:25 wtmp 시작 Fri Sep 12 20:25

2-2-2. 시스템 접속 기록

■ /var/adm/wtmp, /var/adm/wtmpx

이제까지 시스템에 접속한 사용자에 대한 모든 정보를 다음과 같이 갖고 있다. 'last' 명령은 본 파일을 기본 참조 한다. 파일의 내용을 보는법은 utmp, utmpx와 동일 하다.


root@/var/adm> last -f wtmpx \| more nobreak pts/2 cgi.hongik.ac.kr Sat Sep 13 03:54 계속 로그인 중 root pts/2 cgi.hongik.ac.kr Sat Sep 13 03:54 - 03:54 (00:00) root pts/1 203.249.84.218 Sat Sep 13 03:47 계속 로그인 중 root pts/1 Sat Sep 13 01:02 - 03:45 (02:43) nobreak pts/1 Sat Sep 13 01:00 - 01:02 (00:02) . .

2-2-3. 'su' 성공 기록

■ /var/adm/sulog

su 명령에 대한 로그파일이다. 텍스트 형식으로 저장되며, 어떤 사용자가 언제 su를 성공했는지 알수 있다. 다음은 sulog의 기록 형태이다.


SU 09/11 03:11 + pts/0 nobreak-root SU 09/12 16:23 + pts/5 root-archi97 SU 09/12 18:02 + pts/4 root-danger SU 09/12 19:59 + pts/3 root-master

2-2-4. 시스템 오류 및 접근 실패 기록

■ /var/adm/message*

Console에 표시되는 메시지와 시스템에서 뿌려주는 여러 가지 메시지들이 포함된다. root로의 접근 실패등 시스템의 전반적인 에러가 기록된다.


Sep 12 12:54:58 shinan login: REPEATED LOGIN FAILURES ON /dev/pts/3 FROM 203.249 .90.159 Sep 12 13:04:39 shinan su: 'su root' failed for dotboy on /dev/pts/3 Sep 10 15:59:48 shinan sendmail[19384]: NOQUEUE: SYSERR: putoutmsg ([203.249.84. 100]): error on output channel sending "220 ESMTP spoken here": Broken pipe

2-3. 편지(mail) 및 뉴스(news)

2-3-1. 수신 편지가 저장되는곳

■ /var/mail/

수신된 편지가 사용자 ID를 파일명으로 하여 저장되어 있다. '/var' 디렉토리를 충분한 여유공간의 파일시스템에 할당하는 이유는 바로 본 디렉토리와 아래의 'mqueue' 디렉토리 때이다. 서버를 smtp(메일서버)로 사용하고 다수의 계정이 존재한다면, 그만큼 공간이 고려되어야 한다. 요즘은 E-mail에 파일을 어태치(attachment)하여 한 사용자의 편지가 수십 MByte가 되고, 장기간 메일을 확인하지 않는 사용자를 감안해야 하기 때문이다. 시스템에 따라 다르지만 대략 100MBytes 정도의 여유공간이 항시 마련되어 있지 않으면, 언제 'File system full'이란 메시지를 접할지 모른다.


root@/var/mail> ls -al \| more -rw-rw---- 1 acell mail 23863 9월 8일 13:51 acell -rw-rw---- 1 beloved mail 0 3월 20일 20:36 belove -rw-rw---- 1 beloved mail 1795 9월 9일 15:04 beloved -rw-rw---- 1 bglee mail 8078 9월 13일 05:21 bglee

2-3-2. 배송될 편지가 저장되는곳

■ /var/spool/mqueue/

스풀(spool)중인 편지가 저장되어 있다.

사용자가 편지를 보내면 sendmail은 먼저 본 스풀디렉토리에 임시 저장한후 배송을 시도한다. 그러나, 망 장애(수신지가 불분명한 경우가 아님)등의 요인으로 수신자 호스트에 접속할수 없다면 일단 보류한후 다음처리로 넘어간다. 그후 일정시간마다(sendmail을 'sendmail -bg -q1h'와 같이 실행시켰다면, 매 1시간마다) 본 디렉토리를 검사하여(실제로는 'sendmail.cf'에 명시된 스풀디렉토리이나, 대부분 본 디렉토리가 지정되어 있다) 배송되지 않은 편지가 있다면, 재시도 한다.

본 디렉토리에는 'df', 'qf'로 시작하는 파일이 'dfFAA00271', 'qfFAA00271'와 같이 존재하는데, 'df' 파일엔 실제 편지의 내용(body)이 저장되고, 'qf' 파일에는 배송 지연 원인과 편지의 헤더(header)정보가 들어있다. 정상적으로 편지가 수신된 경우 편지의 헤더에는 'SMTP id FAA00271'와 같이 스풀 디렉토리의 임시파일 명이 기록되어 있다.

메일큐에 대한 정보를 확인하기 위해 'mailq' 또는 'sendmail -bp' 명령을 사용하면, 본 디렉토리에서 상태코드가 'qf'인 파일을 읽어 표시하여 준다. 다음을 살펴보자.


root@/var/spool/mqueue> ls dfFAA00271 dfXAA00750 qfFAA00271 qfXAA00750 root@/var/spool/mqueue> mailq Mail Queue (2 requests) --Q-ID-- --Size-- -----Q-Time----- ------------Sender/Recipient------------ FAA00271 1694 Sat Sep 13 05:30 <nobreak@elecom.hongik.ac.kr> (Deferred: Name server: sbs.co.kr.: host name lookup failure) <hrsong@sbs.co.kr> XAA00750 1693 Fri Sep 12 23:19 <nobreak@shinan.hongik.ac.kr> (warning: cannot send message for 4 hours) <hrsong@sbs.co.kr>

메일에 관한 상세한 설명은 7장을 참고하기 바란다.

2-3-3. 뉴스 디렉토리

■ /var/news/

본 디렉토리에 주제를 파일명으로 파일을 작성하면, 일반사용자가 'news' 명령어로 내용을 확인할수 있다. 초기에 사용자에게 복사될 shell script에 news 라는 행을 넣어두는 것도 좋은 방법이다.


root@/var/news> vi FileSystem-확장 File System이 2기가 추가되었습니다. /backup에 물려놓았고, 퍼미션을 풀어 놓았으니, 사용하시기 바랍니다. root@/var/news> news FileSystem-확장 (root) 토 9월 13 16:59:12 1997 File System이 2기가 추가되었습니다. /backup에 물려놓았고, 퍼미션을 풀어 놓았으니, 사용하시기 바랍니다.

2-4. 보안 (security)

2-4-1. 시스템 기본 보안 설정 디렉토리

■ /etc/default/

본 디렉토리는 시스템의 기본적인 설정파일들이 들어 다음과 같이 들어 있다.


root@/etc/default> ls cron init login.org su utmpd fs login passwd tar

이중 주목할만한 것은 'su', 'login', 'passwd' 파일이다. 각각, 해당 명령이 수행될수 있는 터미널과 로그에 대한 지시사항이 있다.

'su' 파일의 내용중 몇몇 사항을 들여다 보자.


# SULOG determines the location of the file used to log all su attempts # SULOG=/var/adm/sulog # CONSOLE determines whether attempts to su to root should be logged # to the named device # #CONSOLE=/dev/console

위의 설정이 뜻하는 바는, 로그를 '/var/adm/sulog' 파일에 남기며, 모든 터미널에대해 사용제약이 없음을 뜻한다. CONSOLE 앞의 #을 제거하면 su 명령은 콘솔에서만이 사용가능하다.

다음은 'login' 파일이다.


# If CONSOLE is set, root can only login on that device. # Comment this line out to allow remote login by root. # #CONSOLE=/dev/console # PASSREQ determines if login requires a password. # PASSREQ=YES

root 로긴에 대한 터미널 제약이 주석처리되었으므로, 어떤 터미널상에서도 root 로긴이 허용되며, 비밀번호가 없는 사용자가 접속을 시도할 경우 비밀번호를 설정하라는 화면이 접속시 나타난다. 비밀번호가 없는 계정을 허용하려면 본항목을 주석처리한다.

아래는 비밀번호가 없는 사용자가 접속했을때의 비밀번호 설정 화면이다.


login: hatti Choose a new password. New password:

'passwd'는 사용자 비밀번호에대한 유효기간 및 최소 허용 길이에 대한 설정을 한다.


#ident "@(#)passwd.dfl 1.3 92/07/14 SMI" MAXWEEKS= MINWEEKS= PASSLENGTH=6

위의 설정에 있어, 비밀번호 유효기간은 없고, 비밀번호는 6자 이상만 허용됨을 뜻한다. 일정기간이 경과한후 비밀번호 교체를 일률적으로 설정하고자 할 때, 'MINWEEKS=6'과 같이 설정할수 있다. 이 경우 비밀번호는 6주의 유효기간을 갖으며, 그후의 접속에 대해서는 기존의 비밀번호 확인을 한후, 새로운 비밀번호를 요구한다.

2-4-2. 시스템 보안 관련 파일

■ /etc/hosts.equiv

신뢰하는 호스트(trusted host)가 나열된다. 본 파일에 기술된 호스트에서의 접근은 암호인증없이 허용된다. 즉 홈디렉토리에 '.rhosts' 파일은 그 사용자에 한정되지만, 이것은 모든 시스템 설정에 적용된다. '호스트명 사용자'의 형식으로 작성된다. 단, 여기서 호스트명은 '/etc/hosts'에 반드시 등록되어 있어야 한다.

다음의 설정예를 보자


root@/etc> vi hosts # User Appended 203.249.87.4 elecom 203.249.87.12 pink root@/etc> vi hosts.equiv elecom nobreak pink +

shinan 이라는 서버에 위와 같은 설정이 이루어 졌다 가정하자.

elecom 호스트의 nobreak 사용자에 대해, pink 호스트의 모든 사용자에 대해 신뢰한다는 뜻이므로, elecom의 nobreak 사용자가 shinan의 unme란 사용자로 비밀번호 확인없이 접속 가능하다. 다음을 보자.


nobreak@/home/nobreak> hostname elecom nobreak@/home/nobreak> rlogin -l unme shinan unme@/admhome/unme> hostname shinan

pink 호스트에서는 모든 사용자가 신뢰되므로, 위와같은 접근을 누구나 할 수 있다.

만약, 본 파일에 '+ +'와 같은 내용이 없도록 주의해야 한다. 이는 '/etc/hosts'에 등록된 모든 호스트의 모든 사용자를 신뢰한다는 뜻이므로, 열린 호스트가 되기 때문이다.

그나마, 솔라리스 2.x의 경우는 신뢰하는 호스트가 '/etc/hosts'에 등록되어 있어야하고, root로의 접근은 신뢰 호스트에서도 비밀번호 확인이 요구되므로 그 범위가 한정되어 있다 볼수있지만, DG-UX 같은 몇몇 OS에서 '+ +'는 이러한 제약이 없어, 어떤 호스트에서도 root를 포함한 모든 계정 접속이 인증없이 가능하다.

본 파일은 NIS+(

2-5. 네트워크 설정 파일들

2-5-1. 호스트명 설정 파일들

■ /etc/inet/hosts, /etc/hostname.le0, /etc/nodename, /etc/net/ticlts/hosts,

/etc/net/ticots/hosts, /etc/net/ticotsord/hosts

호스트명을 변경하고자 한다면, 위의 6개의 파일을 모두 수정해주어야 한다. 'hostname' 명령으로 설정하는 호스트명은 '/etc/nodename' 만이 수정됨을 유의하여야 한다. 또한 이 파일의 호스트명이 로긴시 표시된다. 외부사용자에게 표시되는 호스트명과 DNS 상의 호스트명을 다르게 주고자할때는 'nodename'만을 변경해주면 되겠다.

'/etc/hosts' 파일은 '/etc/inet/hosts'에 실볼릭 링크되어 있고, 내부적으로 정의된 호스트명을 첨가할수도 있다.

nsswitch.conf 파일중 'hosts: files dns'가 뜻하는 바는 호스트명에 대해서 먼저 '/etc/hosts' 파일을 참고하고 원하는 답이 없을 경우, '/etc/resolv.conf'에 명시된 DNS 서버에서 답을 구하라는 것이다.

2-5-2. 네트워크 설정 파일들

■ /etc/resolv.conf, /etc/defaultrouter, /etc/nsswitch.conf, /etc/defaultdomain,

'resolv.conf'는 아래와 같이 Domain -> IP 변환에 사용될 로컬 DNS 정보를 담고 있다.


root@/etc> cat resolv.conf domain hongik.ac.kr nameserver 203.249.66.245

여기서 'domain hongik.ac.kr'은 호스트 명만 쳤을때 붙여지는 도메인 이름이다. 즉 'shinan'이라고 입력했을 때 'shinan.hongik.ac.kr'로 다시 쓰여지게 되는 것이다. DNS 서버의 IP가 'nameserver 203.249.66.245'와 같이 기술됨을 알 수 있다.

'defaultrouter'는 같은 물리적 네트웍이 아닌 다른 망의 호스트나 인터넷등의 접속을 할 때 패킷을 라우팅해줄 기계의 IP를 나타내는데, 라우터가 같은 이더넷상에 존재하는 소규모 네트웍에서는 라우터의 IP를 써주면 되고, 몇몇 크래스를 스위치로 묶어 쓸때는 스위치의 해당 IP를 써주면 된다.

'nsswitch.conf' 파일은 네트워크 서비스와 이름에 대한 검색방법을 설정하기위해 쓰이는데, 네트웍에대한 설정을 한후, 도메인에 대한 검색을 DNS를 확장하라는 설정이 다음과 같이 추가되어야 한다.


hosts: files dns

'defaultdomain' 파일은 NIS(Network Information Service) 서버 트리를 구축할 때 쓰이는 기본 도메인 이름이다. NIS란 하나의 마스터 서버에서 사용자에 대한 모든 정보를 가지며, 클라이언트 서버에서는 사용자에 대한 정보를 마스터 서버에 의존하는 구축 형태를 뜻한다. 예를 들어 회사에서 서버를 A, B 2개 준비하고, 등록된 사용자가 A, B 호스트에 동일한 이름의 계정을 갖길 원한다면, NIS가 효율적으로 쓰일수 있다. 이때 사용자의 정보를 A를 마스터로 설정하고 B를 클라이언트로 설정한다면, 사용자의 정보는 A에서만 관리되고, B는 이를 참조하므로, 사용자는 비밀번호를 변경할때도 A, B 호스트에 모두 설정할 필요없이, 둘중의 한 호스트에서 행하면 그것이 두 호스트에 모두 적용된다.

일반적으로 쓰이지는 않는다.

네트웍 설정은 4장에서 자세히 다룬다.

2-5-3. TCP/UDP 리슨 포트(listen port) 설정

■ /etc/services, /etc/inetd.conf

2-6. 로긴시 접속 메시지

■ /etc/issue, /etc/motd

'/etc/issue' 파일이 존재하면 클라이언트가 telnet 접속시 login 프롬프트 전에 보여주며, 접속이 완료되면 '/etc/motd' 파일의 유무를 검사하여, 그 내용을 뿌려준다.

아래와 같은 내용을 담고 있을 때 [그림 2-2]와 같은 화면을 사용자는 보게 된다.

<'/etc/issue' 내용>
환영합니다. **

<'/etc/motd' 내용>
********************************** 계정 정리작업이 10월 1일 있습니다. **********************************

2-7. 사용자에게 복사될 쉘 스크립트

■ /etc/skel/

본 디렉토리에는 사용자가 생성될 때 사용자 홈디렉토리로 기본 복사될 파일들이 위치한다. 일반적으로 관리자는 본디렉토리에 아래와 같이 3개의 파일을 준비해 둔다.


root@/etc/skel> ls local.cshrc local.login local.profile

사용자를 생성할 때 지정한 쉘(shell)이 'sh'라면 'local.profile'이 홈디렉토리에 '.profile'로 복사되며, 'csh'이라면 'local.cshrc'와 'local.login' 파일이 홈디렉토리에 '.cshrc'와 '.login'으로 복사된다.

2-8. 'cron' 테이블이 저장되는곳

■ /var/spool/cron/crontabs/

Cron Daemon에 의해 수행되는 사용자 crontab이 사용자 ID로 저장된다. 'crontab -e ID' 명령을 수행하면 본 디렉토리에서 사용자의 ID에 해당하는 파일이 편집 저장된다.


root@/var/spool/cron/crontabs> ls adm land lp root sys uucp root@/var/spool/cron/crontabs> cat root 0 2 * * 0,4 /etc/cron.d/logchecker 5 4 * * 6 /usr/lib/newsyslog 15 3 * * * /usr/lib/fs/nfs/nfsfind 1 2 * * * [ -x /usr/sbin/rtc ] && /usr/sbin/rtc -c > /dev/null 2>&1

2-9. File System 설정 파일들

■ /etc/vfstab

부팅시 자동으로 mount될 기본 파일 시스템이 기술된다. 다음을 살펴보자.


#device device mount FS fsck mount mount #to mount to fsck point type pass at boot options /dev/dsk/c0t3d0s0 /dev/rdsk/c0t3d0s0 / ufs 1 no - /dev/dsk/c0t3d0s3 /dev/rdsk/c0t3d0s3 /opt ufs 2 yes - /dev/dsk/c0t1d0s5 /dev/rdsk/c0t1d0s5 /home ufs 3 yes rq swap - /tmp tmpfs - yes -

위는 vfstab의 예인데, '/'에 '/opt', '/home', '/tmp'를 마운트 시키라는 내용이다. 각 항목은 다음과 같은 의미를 갖고 있다.

◇ device to mount : 마운트될 장치 또는 원격 파일 시스템명을 적는다. 장치명은 '/dev/[r]dsk/cAtBdCsD'의 형태를 취하는데, A는 콘트롤러의 ID 번호로 보통 0이며, B는 SCSI ID 번호이다. C는 디스크 번호로 보통 0이고, D는 파티션 번호(0부터 7)이다.

따라서 '/dev/dsk/c0t1d0s5'는 SCSI ID 1에 연결된 하드디스크 5번 파티션 테이블을 가리키는 장치명이다. 본 명치명을 로지컬 네임(logical name)아라하며 실제로는 다음과 같은 실제 물지적 네임(physical name)으로 심볼릭 링크 되어 있다.

'/devices/iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@1,0:f'

예약된 명칭으로는 proc, swap, fd(floppy) 등이다. 예로 swap의 예약명이 존재하면, '/sbin/swapadd'이 자동 실행되어서 swap 파티션으로 표시된 파일 시스템이, 기술된 mount point에 물려진다. 스왑설정 상태는 'swap -l'명령으로 다음과 같이 확인가능 하다.


root@/etc> swap -l swapfile dev swaplo blocks free /dev/dsk/c0t3d0s1 32,25 8 262648 260912

본 시스템에서는 스왑은 '/dev/dsk/c0t3d0s1'에 약 130MByte 정도가 단일 파티션으로 설정되어 있음을 알수 있다.

◇ device to fsck : fsck 명령으로 파일 시스템 검사를 할 때 실제로 핸들링되는 기기 명인데, 보통 mount될 디바이스와 동일하다. '-' 표시는 생략을 의미하는데, 검사하지 않음을 의미한다.

◇ mount point : 마운트될 디렉토리를 뜻한다. 이 곳에 명시된 디렉토리는 포함하는 내용없이 먼저 생성되어 있어야 한다.

◇ FS type : 마운트될 기기의 형태를 정한다. ufs, proc, fd, tmpfs, nfs등의 파일시스템 타입을 기록한다. ufs는 로컬 파일 시스템을, fd는 플로피 드라이브를, tmpfs는 스왑 파티션을, nfs(Network File System)는 원결지 호스트의 파일 시스템을 뜻한다.

◇ fsck pass : 파일 시스템을 fsck 명령으로 검사할 때 검사하는 순서를 적어준다. 번호가 같을땐 기술된 순서에 따라 수행된다.

◇ mount option : 마운트될 때 사용하는 옵션을 적는다. 예로 /home에 마운트될 파일 시스템은 'rq' 옵션이 지정되어 있는데, 사용자 용량제한(quota)이 적용된다는 의미이다.

■ /etc/default/fs

mount 명령시 '-F' 옵션(마운트할 파일시스템 타입)이 기술되지 않으면 본 파일을 참조하여 기본 적용한다. 대부분의 시스템에서 다음과 같다.


LOCAL=ufs

2-10. 부트 스크립트

■ /etc/system

system 파일은 커널 설정 파일이다. 대부분의 시스템에서 별다른 수정이 필요 없다.

파일을 수정한후 시스템에 적용하기 위해서 'reboot -- -r' 명령으로 리부팅 시켜 커널을 재 구성해주어야 한다.

■ /etc/inittab

시스템이 가동될 때 각각의 런 레벨(run level:0-6) 및 운영 방법의 처리를 담고 있다. 본 파일은 init 프로세스에 의해 다루어지며, inittab 파일중 중요한 몇몇 부분을 살펴보면 아래와 같다.


fs::sysinit:/sbin/rcS >/dev/console 2>&1 </dev/console s0:0:wait:/sbin/rc0 >/dev/console 2>&1 </dev/console s1:1:wait:/usr/sbin/shutdown -y -iS -g0 >/dev/console 2>&1 </dev/console s2:2:wait:/sbin/rc2 >/dev/console 2>&1 </dev/console s3:3:wait:/sbin/rc3 >/dev/console 2>&1 </dev/console s5:5:wait:/sbin/rc5 >/dev/console 2>&1 </dev/console s6:6:wait:/sbin/rc6 >/dev/console 2>&1 </dev/console

ID로 구분되는 각 행들이 'ID:Run Level:Action:Process'의 형태를 기록되어 있음을 알수 있는데, 각각의 런 레벨에 행당하는 동작 방식(action)과 실행될 프로세스(process)는 다음과 같은 인자를 취할수 있다.

- sysinit : 시스템 부팅시 실행된다.

- respawn : 실행된 프로세스가 종료되면 다시 시동 시킨다.

- wait : init 프로세스는 실행된 프로세스가 종료되기를 기다린다.

위의 예에서 ID 's3'는 런 레벨 3일 때 wait 방식으로 동작되며, 구체적인 동작 방식은 '/sbin/rc3' 쉘 스크립트에 기술되어 있음을 알수 있다.

■ /etc/passwd, /etc/shadow

사용자 비밀번호가 저장된 파일이다. 시스템에 따라 shadow 파일은 없을수도 있다. 전에는 passwd 파일에 사용자의 비밀번호(암호화된)가 같이 저장되어 'crack'등의 소프트 웨어로 일부 해석되기에 문제가 되었었다. 그래서 고안된 방법이 쉐도우 시스템인데, 이는 passwd 파일에서 사용자 암호부분은 별도의 파일(/etc/shadow)에 저장하고 그 파일의 권한(permission)을 root 만이 읽을수 있도록 설정함을 뜻한다.

다음의 passwd 파일을 보자.


root:x:0:0:Super-User:/root:/bin/csh ftp:x:20:20:Anonymous FTP:/service/ftpd/anonymous:/bin/true nobreak:x:1001:1000:Seung-young, Kim:/home/nobreak:/bin/csh

'username:password:uid:gid:comments:home:shell'의 형식으로 저장되며, 각 항목은 다음과 같은 의미를 갖고 있다.

- username : 사용자 ID

- password : 암호화된 비밀번호가 존재하나, 'x'로 되어 있을때는 쉐도우 파일에 저장되어 있음을 뜻한다.

- uid : 사용자의 고유 번호

- gid : 사용자가 속한 그룹의 번호

- comments : 짧은 사용자 정보

- home : 홈디렉토리 절대경로

- shell : 로긴시 사용될 기본 쉘

다음은 shadow 파일이다.


root:FmYnyXHUW5ylM:10116:::::: ftp:NP:6445:::::: nobreak:iusDe0Yz6EN36:9934:::::: test:9ui97UUf/Hh0M:10127:30:30:10:20:10954:

'username:password:lastchg:min:max:warn:inactive:expire:flag'의 형식으로 저장되어 있는데, 각 항목은 다음과 같은 의미를 갖고 있다.

- username : passwd에 있는 사용자 ID

- password : 암호화된 비밀번호가 13자리 기록된다.

- lastchg : 1970년 1월 1일을부터 마지막으로 비밀번호가 변경된 날짜까지의 총 일수이다.

- min : 비밀번호 변경일을 기점으로 경과일수가 기록되며, 지정한 경과일동안 비밀번호의 변경이 없으면, 로긴시 강제 변경을 요구한다.

- max : 비밀번호가 유효한 일수를 변경일 기점으로 지정한다.

- warn : 비밀번호 유효기간이 끝나기 몇일전에 사용자에게 알려줄수 있는데, 그 일수를 지정한다.

- inactive : 마지막 접속일로부터 다음접속 까지의 최대 허용 휴지일수를 지정한다.

- expire : 1970년 1월 1일을 기점으로 계정사용이 종료되는 일수를 기록한다.

- flag : 현재는 사용치 않는다.

보통은 계정을 추가하는 툴이 알아서 설정 하지만, 간간이 수동으로 각 필드를 조작할 필요가 생긴다.

① username:password:lastchg:0:0::::

② username:password:lastchg:::::1:

위의 ①은 min과 max 필드를 0으로 설정하여, 사용자가 접속시 강제로 비밀번호를 바꾸도록 하며 ②는 expire를 1로 설정하여 계정사용을 일시 정지시킨다.

System Optimize

작성자 : 박을식

최종수정일 : 1998년 12월 31일

1.시스템 시동과 종료.

1-1.Run-Level

1-2.Boot-Script 이해

1-3.Shell Script 작성

2.사용자 관리

2-1.사용자 등록

2-2..cshrc분석

2-3.사용자 용량 제한(quota 설정)

유저 파일 시스템이 개방되어 있거나 혹은 사용자 별로 관리를 필요로 한다면 각 사용자에게 Quota를 주어 사용자의 용량을 제한 할 수 있다. 이로써 무분별한 파일 시스템의 범람을 막을 수 있고 사용자 개개인에게 적당한 용량을 할당하여 시스템의 성능과 효율성도 높일 수가 있는 것이다. 한 사용자가 엄청난 파일공세를 한다면 곧 파일 시스템은 곧 꽉 차 버릴 것이고 아무런 작업도 할 수 없게된다.또한 관리자외에는 대부분 자신이 얼마나 파일 시스템 용량을 사용하는지 관심이 없다, 그러므로 쿼터를 설정하여 각 사용자의 용량을 제한하여 둔다면 능률적인 파일 시스템관리가 가능하다.

2-3-1. Quota 설정

1)일단 이 작업은 슈퍼유저(root)의 권한에서 작업을 해야 한다.(단,아래의 내용들은 Solaris 2.x 이상의 SparcStation하에서 이루어 진다.)

2) /etc/vfstab을 설정한다.


#device device mount FS fsck mount mount #to mount to fsck point type pass at boot options # #/dev/dsk/c1d0s2 /dev/rdsk/c1d0s2 /usr ufs 1 yes - fd - /dev/fd fd - no - /proc - /proc proc - no - /dev/dsk/c0t0d0s3 - - swap - no - /dev/dsk/c0t0d0s0 /dev/rdsk/c0t0d0s0 / ufs 1 no - /dev/dsk/c0t0d0s7 /dev/rdsk/c0t0d0s7 /home ufs 2 yes - /dev/dsk/c0t1d0s6 /dev/rdsk/c0t1d0s6 /home2 ufs 2 yes rq /dev/dsk/c0t1d0s7 /dev/rdsk/c0t1d0s7 /home3 ufs 2 yes - swap - /tmp tmpfs - yes -

리눅스의 경우는 커널 버전 2.0에서부터 기본적으로 쿼타가 지원되며 fstab에 '/dev/hda2 /home ext2 defaults,usrquota 1 1'의 형식으로 넣어준다. 만약 유저별 쿼타가 아닌 그룹별 쿼타 설정이라면 'usrquota'대신'grpquota'로 적어주도록 한다.그외의 쿼타 명령들에 대해서는 공통성을 가진다.그리고 쿼타 설정된 파일 시스템의 루트 디렉토리에 'quota.user'와 'quota.group' 로 쿼타 사용자를 관리한다.리눅스의 경우는 사용자와 그룹에 대한 별도의 쿼타 설정이 가능하다.

3)해당 디렉토리로 이동.

실행: #cd /home2

용량제한을 설정한 디렉토리로 이동한다. 지금 현재 우리는 /home2를 용량제한 하고자 한다.

4)quota 파일 생성

실행: #touch quotas

(참고,touch-파일 접근설정이나 변환 시간을 바꾼다.)

이것으로 /home2디렉토리에 quotas라는 파일이 생성된다.

5)chmod 모드 변환

실행: #chmod 600 quotas

600모드로의 변환

-rw------- 1 root root 32384 9월 4일 10:47 quotas

이는 보안문제 때문에 이렇게 바꿔 주는 것이다. (보안하고 담 쌓은 사람은 그냥 생성된 그대로 사용해도 무방하다.)

2-3-2. 기본 Time Limit 바꾸기.

1) 슈퍼유저 권한으로 로그인.

2) edquota실행

실행: #edquota -t

실행하면 vi에디터가 자동으로 실행되며 아래와 같은 내용이 나온다.(다음과 같이 안나온다면 밑의 포맷에 맞게 고쳐준다.)

fs /home3 blocks time limit = 0 (default), files time limit = 0 (default)

여기서 0는 기본적인 값이므로 적절한 값으로 바꿔주면 된다.

3) 저장 후 에디터 종료한다.

2-3-3. 사용자 용량 제한.

1)edquota 유저명

실행: #edquota youngpc (사용자 이름이 youngpc일 때)

위의 명령을 실행하면 다음과 같이 나타날 것이다.(물론 값들은 틀리다.)

fs /home3 blocks time limit = 5 (soft = 1000, hard = 1100), files time limit = 5 (soft = 200, hard = 300)

설명: 1 block = 512 bytes

soft = 1000 : youngpc가 사용가능한 영역은 1000*512=512kbyte

hard = 1100 : youngpc가 1100*512 bytes 쓰자마자 사용중지

block time limit = 5 : 512kbyte이상을 5일간 사용가능,만약 5일 이상 점유시 사용자 사용 중지.

<FILES>

soft = 200 : youngpc가 사용가능한 file갯수는 200개

hard = 300 : youngpc가 사용한 file수가 300개 이상 쓰자마자 사용중지

file time limit = 5 : youngpc가 file수 200개이상 5일동안 사용가능하며 6일째는 사용중지된다.

2-3-4.다중 쿼터 설정.

실행: #edquota -p 기준쿼터사용자명 사용자1 사용자2

이 명령은 기준 쿼터사용자의 설정과 같게 사용자1과 사용자2에게 그대로 쿼터 설정을 적용하라는 것이다.

2-3-5. Quota Check

실행: 1.#quotacheck -a

2.#quotacheck /dev/dsk/c0t3d0s7

3.#quotacheck -va

1번 명령은 모든 파일시스템에 대한 쿼터체크를 하겠다는 것이고 2번 명령은 /dev/dsk/c0t3d0s7의 파일시스템에 대해서만 쿼터 체크하겠다는 것이고 3번명령은 체크하는 동안 화면에 정보를 나타나겠다는 것이다.

2-3-6. Quota 실행.

실행: 1.#quotaon -a

2.#quotaon /dev/dsk/c0t3d0s7

1번 명령으로 모든 쿼터가 실행되며 2번은 해당 파일시스템의 쿼터만을 실행시킬 때 사용하는 명령이다. 즉,파일 시스템별로 다로 쿼타 실행을 관리 할 수가 있는 것이다.

2-3-7. Quota 해제.

사용자의 모든 설정 값들(위의 내용참조)을 0으로 만들면 Quota가 해제 된다. 또는 설정 내용을 역순으로 해제하면 된다.

2-3-8. Quota량 확인

실행: #quota -v 사용자명


root@/home2> quota -v infoman Disk quotas for infoman (uid 1011): Filesystem usage quota limit timeleft files quota limit timeleft /home2 3 5000 6000 3 1500 2000 root@/home2>

<infoman이라는 사용자의 Quota정보 예>

실행: #repquota -v 디바이스장치명

이 명령은 해당 디바이스 장치에 속한 모든 쿼터정보를 나타내준다. 또한 디바이스장치명(ex./dev/dsk/c0t3d0s7) 대신에 -a 옵션을 줄 경우는 모든 파일 시스템이 대상이 된다.

2-3-9.Quota Optimize(최적화)

쿼터량을 할당할 경우 물론 quota demon이 떠있게 된다. 그러므로 너무 많이 쿼터를 설정한다면 시스템의 성능을 저하 시킬 수가 있다.(비록 아주 경미한 것이지만) 그러나 시스템 관리자의 측면에서 본다면 이같은 시스템 저하 요인을 그냥 넘길 수가 없는 것이다. 그러므로 쿼터 설정을 최적화 시켜보자.

기본적으로 설정을 할 경우에는 쿼터 데몬이 항상 떠있는 상태가 된다. 이 데몬이 항상 떠있게 되면 쿼터 할당된 유저가 접속하지 않았을때나 쿼터 체크가 불필요한 작업시 시스템 성능을 저하시킨다. 그러므로 쿼터 요청이 있을때만 쿼터 데몬을 띄우고 요청이 없을 때는 다시 데몬을 삭제하여 불필요한 낭비를 줄여 보도록 하겠다.

3.Cron 설정

크론이 하는 일은 특정한 시간(사용자가 정의한시간)에 Backup또는 실행시킬 명령어를 자동적으로 수행하는 것이다. 즉,예약 수행정도라는 단어가 적절할 것이다.

3-1.현재 crontab화일 내용 출력

실행:#crontab -l


1: #ident "@(#)root 1.12 94/03/24 SMI" /* SVr4.0 1.1.3.1 / 2: # The root crontab should be used to perform accounting data collection. 3: # The rtc command is run to adjust the real time clock if and when 4: # daylight savings time changes. 5: 0 2 * 0,4 /etc/cron.d/logchecker 6: 5 4 * * 6 /usr/lib/newsyslog 7: 15 3 * * * /usr/lib/fs/nfs/nfsfind 8: 1 2 * * * [ -x /usr/sbin/rtc ] && /usr/sbin/rtc -c > /dev/null 2>&1

위의 내용은 현재의 크론 설정을 보여주고 있다.

첫 번째 필드는 분(minute:0~59)값을 나타내고 두 번째 필드는 시(hour:0~23)값을 나타낸다. 3번째 필드는 일(Day:1~31)값을 나타내며 4번째 필드는 월(Month:1~12)값을 나타낸다.5번째 필드는 요일(Day of The Week:0~6 ,0=일요일)을 나타낸다.

이때 각 필드에는 '-'와 ','가 쓰일 수 있으며 '-'의 경우는 해당 기간동안이고 ','는 해당시간별로이다.

5행의 경우를 보면 5번째 필드에 ','가 쓰였다. 이것은 일요일과 목요일 02:00에 6번째 필드의 작업을 하겠다는 것이다.

만약 5행의 ',' 대신 '-'이 쓰였다면 이것은 일요일부터 목요일까지 매일 02:00시에 6번째 필드의 작업을 하겠다는 뜻이된다.

3-2. Cron 내용 추가.

실행: #crontab -e

(단,슈퍼유저(root)의 경우는 '-e'옵션을 사용하지 않고 /var/spool/cron/crontabs/root를 직접 에디터를 사용하여 설정한다. 일반사용자의 경우는 cron.allow에 등록된 사용자만이 크론을 사용할 수 있다.)

cron내용에 자신이 원하는 작업을 추가하려면 crontab에 -e 옵션을 주어 실행 한후 필드의 형식을 맞추어 원하는 작업을 넣어주면 된다.

3-3. cron 조절.

3-3-1.var/spool/cron/cron.allow

이 파일은 크론 설정을 할 수 있는 사용자의 정보를 담고 있는 곳이다. 일반 텍스트 에디터로 편집 가능하며 사용자의 계정을 적어주면 해당 사용자는 크론을 설정 할 수가 있다. 단,이 작업은 슈퍼유저(root)의 권한에서 해야 된다.

3-3-2.var/spool/cron/cron.deny

이 파일은 크론 설정을 막아놓을 사용자에 대한 정보를 담고 있는 곳이다. 일반 텍스트 에디터로 편집가능하며 사용자의 계정을 적어 주면 해당 사용자는 크론을 설정 할 수 없다.이 작업 역시 슈퍼유저(root)의 권한하에서 해야 된다.

3-4. cron Example.

다음은 슈퍼유저(root)가 특정 시간에 백업을 수행하기 위해 크론을 설정한다는 가정하에설명을 하겠다. 일반유저의 경우는 자신의 권한에서 실행가능한 프로그램에 대해 자세히 알고 있어야 실수를 하지 않는다.

3-4-1.HDD에 backup

HDD가 달린 백업하고자 하는 시스템에서 작업을 한다.

1)실행: #vi backup

2)아래의 내용 추가:


1: echo " rsh 호스트명 tar cvfb - 20 directory명 \| tar xvfbBp - 40 " 2: rsh 호스트명 tar cvfb - 20 directory명 \| tar xvfbBp - 40 3: echo " backup job THE END! GOOD BYE "

3)아래의 내용을 추가 했다면 저장하고 나온다.

호스트명에는 본 시스템의 백업파일을 저장할 호스트명이고 디렉토리는 배업파일을 저장할 디렉토리명이다.

4)모드 변경

실행: #chmod 755 backup

실행: #cd /var/spool/cron/crontabs

실행: #vi root

끝에 다음과 같은 내용을 추가한다.


0 3 * * * /backup > /dev/console

위의 내용은 새벽 3시에 /backup을 콘솔로 실행한다는 의미이다.이 글을 읽으시는 분들은 어느정도 기본적인 명령들은 숙지하고 있다는 가정하에 backup의 내용설명은 생략한다.

5) 실행: #reboot

시스템을 초기화 하여 변경된 크론 설정을 적용한다.

3-4-2.4mm DAT에 backup

백업하고자 하는 시스템에서 작업을 한다.

1)실행: #vi backup

2)아래의 내용 추가:


echo "tar cvfb - 20 backupdirectory \| rsh 호스트명 dd of=/dev/rst5 obs=20b " tar cvfb - 20 backupdirectory \| rsh 호스트명 dd of=/dev/rst5 obs=20b echo " backup job THE END! GOOD BYE "

3)아래의 내용을 추가 했다면 저장하고 나온다.

backupdirectory에는 백업할 디렉토리명을 적어주고 rsh뒤의 호스트명에는 4mm DAT가 장착된 시스템의 호스트명을 적어주면 된다.

4)모드 변경

실행: #chmod 755 backup

실행: #cd /var/spool/cron/crontabs

실행: #vi root

끝에 다음과 같은 내용을 추가한다.


0 3 * * * /backup > /dev/console

5) 실행: #reboot

시스템을 초기화 하여 변경된 크론 설정을 적용한다.

4. TCP_Warp설치

Web Server

작성자 : 박을식

작성일 : 1998년 12월 31일

1.적당한 웹 서버를 골라 보자!.

현재 나와 있는 웹서버들의 종류는 일반 PC용과 UNIX기반의 서버들로 주로 구성되어지며 그 종류(쉐어웨어,공개용,사용 포함 해서 100여개)는 점차 증가하고 있는 추세이다. 현재에도 많은 제품이 공개용과 상용으로 구분되며 출시되고 있고 수많은 웹 서버 소프트웨어중에서 내게 적합 한 제품을 선택하는 것 자체가 중요한 문제로 대두되었다. 웹 서버 프로그램 선택시때 고려해야 할 사항은 우선 어떤 운영체제를 사용하는가, 그리고 선택하려는 프로그램이 구성하려는 웹 사 이트의 트래픽 용량을 감당할 수 있으며 웹 서버에 자체에 만족할 만한 기능들을 갖고 있는 가 하는 것이다.

1-1. 적당한 플랫폼을 선택

처음 웹에 대한 발전을 이뤄온 것은 모두 유닉스 기반의 환경하에서 였다. 그러므로 사실상 모든 기능과 역할 등도 유닉스에 맞추어져 대부분 개발되어 왔다. 그러나 차츰 유닉스의 대안으 로 다른 운영체제들이 각광 받기 시작하면서 새로운 운영체제들에 맞는 새로운 서버 제품군들이 개발되기 시작했다 . 실제 요즘에는 유닉스 대신 윈도우NT 플랫폼을 선택하는 기업들이 늘고 있는 추세이다. NT 웹 서버는 설치나 관리가 쉬운 것이 장점이다. 또한 마이크로소프트의 IIS(Internet Information Server) 3.0,넷스케이프사의 엔터프라이즈 서버등의 성능도 크게 향상되 었다. 하지만 만약 유닉스 시스템을 현재 사용하고 있고, 유닉스 머신자체의 성능이 우수하고, 유 닉스 전문가가 있다면 아무래도 유닉스를 웹 서버의 운영체제로 선택하는 것은 좋은 선택이다.다 른 플랫폼의 선택으로 매킨토시도 활용되고 있으며, 이 플랫폼은 현재 웹 스타(WebStar)를 대부 분이 선택하고 있다. 그러나 실제 성능은 그리 만족스럽지 않기 때문에 강력한 웹 서버를 필요로 하는 사람이나 회사에게는 그리추천할 만한 웹서버는 아니다.웹 스타의 경우는 웹 사이트의 크기 가 별로 크지 않고, 업무가 매킨토시 기반의 환경을 갖고 있다면 시도해볼 만하다.

1-2.가격 대비 성능을 고려한다.

웹 서버 플랫폼을 선택할 때 또하나 고려해야 하는 것이 비용 문제이다. 웹 서버 소프트웨 어는 하드웨어 장비에 비해 가격이 저렴하다. 그러나 이것도 학생이나 소규모 회사에겐 부담이 되는 것이 사실이고 이렇기 때문에 쉐어웨어 뿐만아니라 공개용과 상용 프로그램에 대한 선택도 잘 해야 하는 것이다. 주로 서버의 성능은 같은 조건이라면 얼마나 많은 메모리를 갖고 있느냐에 따라 성능면에서 가장 많이 차이가 나게 된다. 그러나 성능만이 제품 선택 기준의 전부가 아님은 명백하다. 가장 중요한 선택 기준은 웹 사이트의 트래픽 용량이

얼마나 될 것인가 하는 것이다. 물론 사용의 용이성도 고려할 대상이다. 이런 점들을 고려하 여 자신에게 적당한 성능에 제품을 고르는 것이 낭비를 줄일 수 있을 것이다. 무조건 비싸다고 좋은 제품은 아니고 무조건 싸거나 쉐어웨어 혹은 공개용이라고 성능이 떨어지는 것은 아니다. 자신이 지금 가지고 있는 시스템과 혹은 구성하려는 시스템과의 연관성도 고려해야 하는 것이다.

2.윈도우NT 4.0 웹 서버

윈도우NT 웹 서버 제품들은 지난 몇년간 눈부신 성장을 기록했으며, 빠르게 시장을 점유해 가고 있다. 설치와 사용상의 편리성을 주로 부각시켰으며 점차 성능면에서도 유닉스 계열의 웹 서버 제품들과 어깨를 나란히 하고 있다.

2-1.Internet Information Server 3.0(IIS 3.0)

마이크로소프트의 IIS 3.0은 윈도우 NT 서버 4.0에 기본으로 포함돼 있다. 이 제품은 무료인 반면 기술 지원은 되지 않는다. 하지만 서버 제품들 중 가장 설치가 쉬운 것 중의 하나이다. 특히 NT에 최적화돼 개발됐기 때문에 사용법을 익히는 것도 평이하다. IIS는 NT의 액세스 컨트롤, 퍼포먼스 모니터, 이벤트 뷰어, 그리고 HTML 편집기인 프론트페이지와 잘 통

합된다. 하지만 아쉽게도 프록시 서버는 포함돼 있지 않다. 만약 이기능이 필요하다면 마이 크로소프트의 프록시 서버를 별도로 구입해야 한다. 이에 반해 프로세스 소프트웨어와 인터넷 팩토리(Internet Factory)사의 제품에는 프록시 서버가 기본으로 포함돼 있다.

프록시 지원 기능을 논외로 한다면 이 제품에는 그다지 흠잡을 만한 것이 없다. IIS 3.0이 획 기적으로 개선된 사항으로는 일반적인 로그 파일 포맷을 지원한다는 것이다. IIS 1.0에서는 일반 로그 파일 포맷이 지원되지 않아 서드파티의 로그 분석 프로그램을 사용할 수 없었다. 그러나 2.0에서도 로그 파일에 대한 리포트 기능은 여전히 부족한 편이다. IIS 3.0에서는 크리스탈 리포 트 라이터(Crystal Report writer)라는 프로그램이 기본 제공 되므로 이에 대한 문제점도 해결되 었다.

2-2.엔터프라이즈 서버

엔터프라이즈 서버의 경우 로그 데이터에 대한 크리스탈 리포트 라이터와 함께 주제별 검색 엔진인 베리티 토픽 서치(Verity topic Search)가 기본으로 제공된다. 다른 제품에서는 찾을 수 없는 또다른 유용한 기능으로는 네비게이터 골드에 포함돼 있는 원버튼(One-button) 웹 문서 퍼 블리싱 기능이다. 이를 이용하면 링크나 파일 포스팅 등의 작업을 원 버튼 방식으로 처리할 수 있다. 더욱이 이 기능을 통해 패스워드 보호와 페이지의 임의 수정 등도 막을 수 있다. 엔터프라 이즈 서버는 SSl 2.0와 3.0을 지원하며 모든 프로그래밍 모듈을 커스터마이징할 수 있다. 그러나 비싼 가격에도 불구하고 이미지 맵 생성과 ODBC나 SQL 데이터베이스에 대한 로그 기능은 없 다. 만약 이 기능을 구현하려면 넷스케이프의 라이브와이어(LiveWire)라는 프로그램을 별도로 구입해야 한다. 엔터프라이즈 서버의 설치도 그렇게 어렵지 않았지만 관리자 콘솔 스크 린은 조작하기가 조금 까다롭다.

2-3.웹 사이트 프로페셔널

이 제품은 히트수가 많은 웹 사이트에는 그리 나쁘지 않은 선택이 될 것이다. 오렐리사에서 는 웹 서버는 개방형 분산환경에서 유지돼야 한다고 주장한다. 이러한 정신을 바탕으로 연동 되는 다른 애플리케이션들을 거의 동시에 실행되도록 설계됐다. 웹 사이트 프로페셔널은 웹 사이 트의 구축과 관리에 필요한 다량의 유틸리티들을 갖고 있다. 또한 이 제품은 프로그래밍 모듈을 커스터마이징할 수도 있다. 이를 통해 비주얼 베이직이나 펄(Perl), 델파이 등 다양한 언어를 사용 해 자신에 맞는 환경으로 고칠 수 있는 것이다. 또 하나 유용한 것은 웹뷰(WebView)이다. 이 기 능은 웹 문서와 링크들을 그래피컬하게 보여줘 사이트를 비주얼하게 관리할 수 있도록 한다. 또 한 사이트에 있는 다양한 아이템들에 대한 인덱싱과 검색 툴도 제공한다. 이외에도 웹 사이트 프로페셔널은 ODBC 통합 기능을 내장하고 있는데, 특히 이는 웹 사이트 자체의 API를 통해 CGI 프로그램이 아니라 서버의 한 부분으로서 동작하게 된다. 이 제품에는 다양한 기술 지원 내 용을 담고 있는 프린트된 문서가 제공된다.

이는 웹 사이트를 처음, 혹은 짧은 시간 내에 구축해야 하는 사람에게 큰 도움이 된다.

그러나 웹 사이트 프로페셔널의 단점은 원격 관리 기능이 약하다는 것이다. 다른 제품들이 브라우저를 통한 관리 기능을 제공하는 반면 이 제품은 원격지의 콘솔에 전체 패키지를 모두 설 치해야 한다. 이는 원격 관리 설정을 따로 해줘야 함은 물론 원격지 시스템의 하드 디스크를 낭비하게 하는 요소이다.

2-4.퍼베이어 인크립트

프로세스 소프트웨어사의 퍼베이어 인크립트(Purveyor Encrypt)는 최고의 제품으로 꼽히 지는 않았지만 다른 제품과는 차별화되는 독특한 요소들을 포함하고 있다. 특히 브라우저는 물 론 윈도우NT 클라이언트에서도 원격 관리를 할 수 있는 라이브러리 툴들을 제공하는 것이 인 상적이다. 또한 HTTP, FTP, 고퍼 프로토콜에 대한 프록시 서버를 기본으로 포함하고 있는 몇 안되는 제품이기도 하다. 퍼베이어 인크립트에는 주제별 검색 엔진과 페이지의 링크가 살아있는 지 체크할 수 있는 링크 브라우저(Link Browser)가 내장돼 있다. 또한 데이터 위저드(Data Wizard)라는 툴을 이용하면 ODBC/SQL 서버 데이터베이스를 GUI 인터페이스상에서 별도의 프로그래밍 없이 연동시킬 수 있다. 프로세스 소프트웨어는 또한HTML 에디터를 비롯해 많은 프 리웨어 프로그램을 담은 인트라넷 리소스 CD를 무료로 제공하고 있다. 이 제품에는 3권의 문서 화된 가이드 책자가 함께 제공된다. 이 책자는 전체 내용이 일목요연하게 인덱스화돼 있어 원하 는 내용을 쉽게 찾을 수 있도록 했다.

2-5.커머스 빌더 프로

인터넷 팩토리사의 커머스 빌더 프로(Commerce Builder Pro) 2.0은 부가적인 관리 기능은 로컬 관리 콘솔은 물론 웹 브라우저를 통한 리모트 관리 콘솔에서도 이용 가능했다. 그러나 동 일한 컨텐트를 포함하고 있는 화면이 다르게 보여졌다. CGI, ISAPI, WinCGI를 지원하는 것 외 에도 이 제품은 자체적으로 SMX(Server Macro Extension)이라는 매크로 언어를 지원한다는 것 이 돋보였다. 이 언어에 포함돼 있는 140개의 매크로를 통해 쉽게 페이지 카운터나 폼을 만들 며, 웹에서 데이터베이스에 쉽게 연결할 수 있다. 커머스 빌더 프로는 무엇보다도 기술 지원 문 서가 체계적이라는 것이고 온라인 도움말도 이용할 수 있어 웹 서버의 설치와 구축이 아주 쉽 다.

3.유닉스 웹 서버

유닉스 기반의 프로그램들은 대부분 콘솔모드에서 설정을 하고 있으므로 일반 윈도우 기반의 프로그램들에 비해 좀더 신경을 써야 한다.그러므로 유닉스 전문가가 아니라면 가능한한 유닉스 계열의 웹 서버 제품은 피하는 것이 좋다. 스트롱홀드와 NCSA 프로그램은 쉘상에서 모든 환경 을 설정해야 한다. 하지만 넷스케이프사의 유닉스 제품은 윈도우계열에서와 동일한 GUI 환경을 제공한다. 그러나 이 제품에서도 역시 최적화된 성능을 발휘할 수 있는 세밀한 환경 설정은 쉘상 에서 해줘야 하며, 이는 유닉스 전문가가 아니라면 쉽게 손댈 수 있는 작업이 아니다.

3-1.NCSA와 아파치

웹 서버 프로그램의 원조라고 할 수 있는 NCSA 서버는 National Center for Supercomputing Applications의 약자로 미국 일리노이 대학에서 만들어졌다. 유닉스 시스템에 서는 이 프로그램이 아파치 서버 다음으로 많이 보급됐는데, 우리나라에서는 오히려 아파치 서 버에 비해 NCSA가 더 많이 사용되고 있다.이는 한글화된 문서차이로 인한 결과인데 아파치 서 버의 경우도 한글 문서화 작업이 이미 되어 있으므로 점차 아파치 서버로 전향하거나 설치하는 곳이 대부분이다. 아파치 서버도 역시 기본적으로는 NCSA의 개량 프로그램이다. 즉, NCSA 서 버의 소스를 사용자의 요구에 맞게 커스터마이징해 재작성된 것이다.

전 세계적으로 100만(50% 이상)이 넘는 서버가 Apache를 택하고 있을만큼, 보편적이고 안 정적이라 하겠다.

3-2.엔터프라이즈 서버 (유닉스용)

넷스케이프사의 유닉스용 엔터프라이즈 서버은 NT 제품과 동일한 기능을 제공한다. 그러나 하드웨어 비용을 고려한다면 전체 구축 비용은 NT 플랫폼이 아무래도 조금 저렴해질 것이다. 다른 유닉스 제품의 설치가 까다로운 반면 이 제품은 GUI 인터페이스를 제공해 쉽게 설치 작업 을 진행할 수 있다. 하지만 설치 외에 실제 사용은 마찬가지로 유닉스 쉘 상에서 이용해야 한 다.

4.매킨토시 웹 서버

4-1. 웹스타 1.31

쿼터덱의 웹스타 1.31은 MacHTTP의 업그레이드 소프트웨어이다. 이 제품은 매킨토시 웹 서버 시장에서 가장 많이 사용되고 있다. 웹스타는 아주 강력한 성능은 기대할 수 없지만 작은 웹 사이트나 부서 단위의 인트라넷을 구축하고자 할 때는 좋은 선택이라 할 수 있다. 다른 제품 에 비해 속도는 느려도 주목할 만한 몇가지 기능과 함께 강력한 시큐리티를 보장해준다는 것이 장점이다. 하지만 안타깝게도 NT나 유닉스 제품에서와 같은 강력한 데이터베이스 로그 파일은 지원하지 않는다. 이 제품은 매킨토시 프로그램답게 설치가 쉽고 문서화가 잘 돼있다. 특히 쿼터 덱사의 웹 사이트에 방문해보면 웹스타에 관한 다양한 기

술 자료를 다운로드받을 수 있다.

5. 종합 결과

현재 유닉스 시스템을 사용하고 있거나 히트수가 높을 것이라고 예상되는 사이트를 구축할 예정이라면 유닉스 플랫폼이 가장 적합할 것이다. 특히 이 환경에서는 넷스케이프 엔터프라이 즈 서버가 최고의 성능을 발휘할 것으로 보이며, 유닉스와 NT 제품 모두 친근한 사용자 인터 페이스를 채택하고 있다. 또한 이 제품은 시장에서 좋은 호평을 얻고 있고, 폭넓은 기술 지원을 받을 수 있다는 것도 장점이다. 실제 다른 대부분의 유닉스 서버 제품은 웹이나 뉴스그룹에 포 스팅돼 있는 문서들을 참조해야 하기 때문에 번거로울 것이다. 한편, NT는 환경 설정이 쉽고, 높 은 성능을 보장하며 NT 운영체제와 잘 통합돼 있다는 것이 매력적이다. NT 서버 제품들은 SSL 시큐리티와 버추얼 서버를 지원하고 있다. 또한 NT의 시스템 분석 툴들을 이용할 수 있 어 좋다. 또한 중점을 둬야 할 사항중 하나는 원격 콘솔 액세스이다. 워크스테이션에 전체 패키 지를 설치해야 하는 웹 사이트 프로페셔널을 제외한다면 다른 네 개의 NT 제품 모두 웹 브라우 저를 통한 원격 관리 기능을 제공하고 있다.

1.웹 서버 보안.

점차 인터넷의 여러 툴들 중 가장 각광을 받기 시작하는 것이 웹일 것이다. 그러므로 웹 보안에 대한 사항도 고려해야 한다. 일반적으로 웹 보안이라고 하면 대부분이 자료 전송시의 암호화와 관련된 이슈가 보안 관련 세미나의 주를 이루고 있다. 또한 가끔씩 웹 서버, CGI, 웹 브 라우저와 관련된 프로그램상의 구멍(hole)이나 사실 웹과는 관계없이 독자적으로 개발됐지만 웹에 큰 영향을 미치고 있는 자바가 웹과 같이 이용될 때 야기될 수 있는 보안 문제가 소개되고 있는 것이 현 실정이다. 그러나 이런 것들은 모두 실제 보안문제들과는 거리가 있는 문제들이다.

1-1. 웹 서버의 동작 구조와 문제점

웹 서버가 웹서비스를 제공하기 시작하면 웹 서버 데몬이 실행되어 클라이언트의 요청을 기 다린다. 이때 클라이언트의 요청이 들어오면 새로운 자(child)프로세스를 생성하여 이를 처리한 후 자동 소멸된다. 물론 이 같은 동작이 모든 웹 서버에 공통적인 표준은 아니다. 또한 시스템 설 정을 어떻게 하는 냐에 따라 달라지기도 한다. 그러나 대부분의 웹서버 구조는 위와 같은 형태로 동작을 한다. 여기서 주목할 것은 웹서버 데몬이 항상 떠있게 되고 그 실행되는 프로세스 자체가 루트의 권한으로 실행된다는 것이다. 왜냐하면 데몬 자체가 루트의 권한으로 실행되며 자(child) 프로세스 자체도 그 데몬에 의해 생성되므로 이 같은 동작은 보안문제로 본다면 매우 위험한 존 재이다. 이는 클라이언트들이 요청해올 때마다 새로운 루트 권한의 프로세스가 생성되기 때문에 시스템이 불필요한 루트 프로세스가 많이 떠 있는 효과를 가져오게 되기 때문이다. 그러므로, 대 부분의 웹 서버들은 클라이언트의 요청을 처리하기 위해서 자(child) 프로세 스를 생성시킬 때 이 프로세스의 권한을 루트가 아닌 특정한 사용자로 할 수 있는 방법을 제공하고 있다.


/conf/httpd.conf file: # User/Group: The name (or #number) of the user/group to run httpd as. # On SCO (ODT 3) use User nouser and Group nogroup User nobody /etc/passwd file: # grep nobody passwd nobody:x:1001:1001:nobody user::

아파치 서버의 경우를 보면 user에 nobody라고 해주고 /etc/passwd 파일에 nobody라는 사용자 를 등록해두면 동적으로 생성되는 자(child) 프로세스들은 nobody이라는 사용자의 권한으로 동작하게 된다. 여기서 nobody 사용자를 만들 때 주의할 점은 패스워드 부 분은 *와 같이 암호화된 결과가 될 수 없는 문자로 막아둬야 한다는 것이다. 만일 shadow passwd를 사용한다면 shadow passwd 파일에서 암호화된 부분을 막아둬야 한다. 이러한 동작 방식의 시나리오에서는 클라이언트는 항상 nobody 사용자 권한의 웹 서버와 통신을 하기 때문 에 이 서버 프로세스를 공격해 클라이언트가 원하는 작업을 하게 하더라도 이 때의 작업은 nobody 사용자 권한이므로 루트 소유의 파일들 (예: /etc/passwd 등)을 수정하는 등의 작업은 할 수 없게 된다. 하지만 이것만으로는 /etc/passwd 등의 중요한 시스템 파일에 접근하는 것을 원천적으로 봉쇄하지는 못한다. 즉, 읽기 권한이 부여된 시스템 파일들은 여전히 접근이 가능하 기 때문이다.

일반적으로 패스워드나 그룹 파일은 모두에게 읽기 권한을 주게끔 설정돼있어야 한다. 이 런 이유로 CGI 프로그램을 이용해 웹 서버가 있는 머신에 로긴하지 않고도 패스워드 파일을 가 져올 수 있다. 이는 웹 서버 프로그램을 인스톨했을 때, 디폴트로 cgi-bin에 포함된 CGI 프로그램 중 phf라는 프로그램으로 인해서 가능하다. phf의 버그는 지금은 널리 알려져 있어서 대부분 패 치가 됐으리라고 생각되지만 CGI 프로그램에 대해 이후에도 얼마든지 침입받을 수 있는 요소를 남겨두는 것이다. 지금 웹 서버의 cgi-bin 디렉토리의 phf 프로그램을 검사해보고 이 CGI가 존재 한다면, 즉시 이를 지워버리거나 패치하기 바란다.

1-2. chroot를 이용한 안전한 웹 서버 설치

chroot는 새로운 루트 디렉토리를 설정해 실제로 chroot된 프로세스는 이 디렉토리의 상 위 디렉토리로는 접근할 수 없고 오직 이 하위의 디렉토리로만 접근할 수 있게 해주는 보안에 는 매우 효과적인 시스템 함수이다. 즉 하나의 프로세스를 실행시킬 때 이 프로세스가 접근할 수 있는 영역을 프로세스 생성 시기에 미리 제한 시킬 수 있게 해주는 것이다. 이 함수를 이용 해 만들어진 동명의 chroot라는 명령어도 존재하는데 이는 프롬프트상에서 프로세스를 실행시킬 때도 이러한 작업을 가능하게 해주기 위해서이다.

chroot의 장점은 chroot된 디렉토리가 웹 서버 프로세스의 루트 디렉토리로 인식되기 때문 에 불필요한 파일이나 디렉토리로의 접근을 제한할 수있다.또한, 루트 권한의 프로세스가 nobody권한의 자(child) 프로세스를 생성시켜서 컨트롤을 넘기기 전에 공격당해 루트의 권한 으로 작업을 한다고 하더라도 이러한 작업이 chroot된 디렉토리를 벗어날 수 없기 때문에 시스템 에 큰 영향을 미치지 못한다. 물론 이는 chroot된 디렉토리 이하에는 시스템을 침입하는데 사용 할만한 파일이나 디렉토리가 없고 단순히 html파일, 그림 파일, CGI파일 등이 있을 뿐이기 때문 이다.게다가 기존의 웹 서버의 경우 사용자들의 홈페이지들이나 웹 서비스 를 하기 위한 프로 그램(웹 BBS, DB와 연동된 웹 서비스의 DB)들이 디스크에 흩어져 있었다. 이는 물론 기존의 웹 서버나 생성된 자(child) 프로세스가 디스크의 어디든지 접근 할 수 있었기 때문이다. 그러나 chroot를 이용해 웹 서비스를 하게 될 경우에는 하나의 큰 디스크 파티션을 지시하는 디렉토 리를 chroot해 만들기 때문에 모든 웹 서비스 관련 파일들을 이 디스크 파티션에 모아 두게 된 다. 그러면 실제로 웹 서버는 이 디스크 파티션, 정확하게는 이 디스크 파티션을 지시하는 chroot된 디렉토리 밖을 못 벗어나면서 동작 했기 때문에 이 디스크만 정기적으로 백업을 받아 둔다면 시스템이 죽거나 디스크가 망가지더라도 다른 호스트의 빈 디스크에 백업을 풀어서 즉 시 웹 서버를 복구할 수 있게 된다. 그러나 chroot를 사용하는 방법은 보안을 위해서는 매우 훌 륭한 방법이 되지만 이 또한 약간의 문제를 내포하고 있는 것은 사실이다. 보안요소를 첨가하 면 항상 그렇듯이 설치하기가 까다롭다고 말할 수 있다. 기존에 이미 웹 서버가 설치돼있는 상 태에서 chroot를 이용한 서버를 설치할 경우에는 chroot를 이용하는 장점을 살리기 힘들 수 있 다. 하지만 관리자의 재량에 따라 불가능 한 것은 아니다. 이미 기존의 웹 서버가 있다면 개인들 이 각각의 홈디렉토리에 자신의 홈페이지를 만들어놓았을 것인데, 이 홈페이지들이 chroot에서 이용하는 파일 시스템이나 chroot의 tree 바깥에 있을 수 있다는 것이다. 이에 대한 해결책은 만일 사용자들의 홈페이지가 chroot를 이용하는 tree 바깥에 있지만 같은 파일 시스템상에 있다 면 하드 링크를 이용해서 해결할 수 있다(chroot tree 이하 에서 바깥으로의 소프트 링크는 동 작하지 않는다). 하지만 완전히 다른 파일 시스템에 사용자들의 홈페이지가 있을 경우에는 loop back 마운트(로컬 파일 시스템에서 다른 로컬 파일 시스템으로의 마운트)를 이용해 해결 할 수 있다.

5-1. Apache HTTPd Install

알아본 바와 같이 많은 종류의 웹서버가 있으나,여기서는 빠르고 깔끔한 Apache를 기본으 로 웹 서버 설정에서부터 Virtual Host까지 그 구축방법을 알아보고, 카운터, 방명록, 게시판, 로 그분석등의 CGI 설치방법을 알아본다.

Apache 이외의 서버도 약간의 차이만이 있을뿐 대부분의 설정 및 설치는 동일하다.

5-1-1. Apache HTTPd Download

먼저, Apache Homepage(http://www.apache.org)에서 [그림 5-1], [그림 5-2]와 같이 최신 버전을 다운받아 설치 대상 디렉토리에 압축을 푼다.

일반적으로 응용 어플리케이션은 '/usr/local'아래 또는, '/opt'아래에 설치한다. 따라서 Apache의 기본 Configuration은 '/usr/local/etc/httpd'를 바탕으로 되어 있다. 그러나, 관례도 바뀌 어 요즈음에는 사용자 관련 어플리케이션만이 설치되고, 웹 서버같이 서버 운영의 핵이 되는 부 분은 '/service/httpd/'와 같이 독립된 디렉토리에 설치 하는 듯 하다.

다음은 패키지를 다운받아, 압축을 풀고 생성된 디렉토리를 '/service/httpd'로 옮기는 일련 의 작업을 보여준다.


root@/service> ls -al -rw-r--r-- 1 root root 708729 9월 8일 21:30 apache.1.2.4.tar.gz root@/service> gunzip apache.1.2.4.tar.gz root@/service> tar xvf apache.1.2.4.tar x apache_1.2.4, 0 bytes, 0 tape blocks . x apache_1.2.4/support/suexec.h, 5283 bytes, 11 테이프 블럭 root@/service> ls -al -rw-r--r-- 1 root root 2764800 9월 8일 21:30 apache.1.2.4.tar drwxr-xr-x 9 168 82 512 8월 22일 16:19 apache_1.2.4 root@/service> mv apache_1.2.4 httpd root@/service> ls -asCF httpd total 88 12 CHANGES 2 cgi-bin/ 2 logs/ 2 ./ 16 KEYS 2 conf/ 4 src/ 2 ../ 6 LICENSE 2 htdocs/ 2 support/ 24 ABOUT_APACHE 8 README 4 icons/

5-1-2. Compile

실행 파일(Binary)를 생성하기 위해 'httpd/src' 디렉토리에서 다음의 일련작업을 행하여 binary를 생성한후 'httpd' 디렉토리로 복사 한다.


root@/service/httpd/src> ./Configure Using config file: Configuration Using Makefile template file: Makefile.tmpl + configured for Solaris 2 platform + setting C compiler to gcc + setting C compiler optimization-level to -O2 root@/service/httpd/src> make root@/service/httpd/src> cp ./httpd ../

gcc등의 컴파일러를 설치하지 않았거나, 기타 이유로 컴파일에 실패한 사용자를 위해 사용 자를 위해 precompiled binary가 OS별로 배포되니 참고하기 바란다.

5-2. HTTPd 설정 (HTTPd Configuration)

이제 서버를 구동시키기 위한 다듬기 작업에 들어 가보자.

일반적인 웹서버를 구축하는데 필요한 설정방법을 차근차근 알아보고, Virtual Host등과 같 은 외적인 부분은 뒤에서 알아 보도록 하자.

아래에 기술된 설정은 관리자가 정확히 그 용도를 파악하고 있어야 하는 부분들이니, System Performance, 망의 대역폭(Band Width), 서비스의 규모등을 충분히 고려하여 설정하기 바란다.

5-2-1. Configuration 파일 복사

'httpd/conf' 디렉토리에는 웹 서버 설정에 관련된 3개의 httpd.conf, access.conf, srm.conf 파일이 각 파일명 꼬리에 '-dist'가 붙은 형태로 존재한다.

3개의 설정 파일을 '-dist'를 제거한 형태로 다음과 같이 복사 한다.


root@/service/httpd/conf> cp access.conf-dist access.conf root@/service/httpd/conf> cp srm.conf-dist srm.conf root@/service/httpd/conf> cp httpd.conf-dist httpd.conf root@/service/httpd/conf> ls access.conf httpd.conf mime.types srm.conf-dist access.conf-dist httpd.conf-dist srm.conf

5-2-2. httpd.conf 손질

'httpd.conf'엔 서버의 전반적인 정보를 기술한다 다음에 기술된 항목들을 'httpd.conf'에서 확인·수정하자.

■ Server 구동 방식


# ServerType is either inetd, or standalone. ServerType standalone

'standalone'과 'inetd'의 두가지 방식이 존재하는데, standalone으로 설정을 하였을 경우, 하나의 daemon process가 client의 접속을 모두 처리 감시하므로, 요구에 빠른 처리가 가능하며 client의 동시 요구에 대해 효율성이 높다. 반면 inetd라 설정하면 inetd 프로세스가 접속이 요구되 었을 때 web server를 매번 구동시킨다. 따러서 매 접속시 서버 설정사항들은 다시 판독되어야 하는 동일한 전처리가 요구된다. 대부분의 서버에서 standalone으로 구동하길 권한다.

■ Listen Port


# Port: The port the standalone listens to. For ports < 1023, you will # need httpd to be run as root initially. Port 80

서버가 요청을 받아들이는 포트번호를 설정한다. 일반적으로 80 포트가 http protocol을 위 해 예약(reserved)되어 있다. 이는 웹브라우져에서 해당 도메인으로 접속했을 때 80포트로 기본으 로 선택된다는 뜻이다. 서버의 비공개를 원하거나, 80 포트가 다른 웹 서버로 사용되고 있다면, 포트번호를 8080등으로 설정하여 'http://SERVER_DOMAIN:8080'와 같이 접속할수 있다.

0부터 1023 까지는 시스템에 예약되어 있는 포트이다. 이를 well known port 또는 reserved port라 말하는데, 80 이외의 포트를 지정할때는 이부분을 피해야 한다. 일반적으로 5000 번 이상의 포트를 사용하며, root가 아니더라도 reserved port가 아니면 서버를 구동할수 있다. 단, 이때 PID와 GID는 자신의 것으로 설정하여야 한다.

■ Log에 남길 client 주소 형태


# HostnameLookups: Log the names of clients or just their IP numbers # e.g. www.apache.org (on) or 204.62.129.132 (off) # You should probably turn this off unless you are going to actually # use the information in your logs, or with a CGI. Leaving this on # can slow down access to your site. HostnameLookups off

'on'과 'off'를 설정할수 있다. 'off'일 때에는 client의 IP를 log에 변환없이 기록한다. 'on' 일 경우에는 client의 IP를 domain으로 변환 시도하여 성공시 domain을 log에 남긴다. 따라서 client의 접근이 다소 느려진다. 로그 파일의 분석이 중요하지 않다면, 빠른 접근(access)을 위해 off로 설정하길 권한다.

■ Web Server UID, GID


# User/Group: The name (or #number) of the user/group to run httpd as. # On SCO (ODT 3) use User nouser and Group nogroup # On HPUX you may not be able to use shared memory as nobody, and the # suggested workaround is to create a user www and use that user. User nobody Group nobody

Daemon이 수행되는 UID(User ID)와 GID(Group ID)를 설정한다. 이는 web상에서 수행되 는 모든 실행 권한(permission)이 설정된 UID와 GID로 종속됨을 뜻한다.

즉, CGI를 실행했을 경우, CGI는 설정된 UID와 GID의 사용자가 실행한것과 동일한 권한 을 갖음을 뜻하며 웹 상에서 생성된 파일 및 디렉토리 등은 모두 설정된 UID와 GID로 생성됨을 뜻한다.

이는 보안과 연관되어 문제가 야기되는데, 만약 UID가 root로 설정되어 있고, 일반 계정에 서의 사용자 CGI가 허용된다면, 사용자는 간단한 script를 작성하여 이것을 root 권한으로 실행할 수 있기 때문이며, script의 내용은 'rm -rf /*'와 같은 형태를 취할수 있기 때문이다. 위와같이 nobody/nobody('/etc/passwd'와 '/etc/group'에 nobody가 등록되어 있는지 확인한다.)로 서버를 구동시키기도 하지만, CGI의 결과또한 nobody로 생성되어 root만이 수정할수 있기에, 관리의 편 리성을 위해 www/http와같이 고유의 UID와 GID를 생성하여, 사용하기도 한다. 여러모로, 후자가 효율적인 관리를 행할수 있으므로, 여기서는 www/http로 설정 하였다고 가정한다.

■ 관리자 E-mail


# ServerAdmin: Your address, where problems with the server should be e-mailed. ServerAdmin nobreak@shinan.hongik.ac.kr

관리자의 E-mail 수신 주소를 설정한다. 서버 오류시 오류메시지에 표시된다.

■ Web Server 설치 디렉토리


# ServerRoot: The directory the server's config, error, and log files are kept in ServerRoot /service/httpd

웹서버가 설치된 디렉토리를 기술한다. 또한 이것은 아래에 설정될 Log등의 기준 디렉토리 로 작용한다.

■ Log 파일명


ErrorLog logs/error_log TransferLog logs/access_log PidFile logs/httpd.pid

로그가 기록될 파일명을 기술한다. client의 모든 연결 행위는 TransferLog에 기록되고, 불 완전한 연결에 관해 ErrorLog가 기록된다.

PidFile은 Web Server의 모(Parents) 프로세스의 PID가 기록되는데, 서버를 종료 시킬 때 사용된다. 서버를 시작, 종료시키는 방법은 뒤에 자세히 설명한다.

■ 서버명0


# ServerName allows you to set a host name which is sent back to clients for # your server if it's different than the one the program would get (i.e. use # "www" instead of the host's real name). ServerName shinan.hongik.ac.kr

서버가 클라이언트에게 보내는 자신의 호스트명을 기술한다. CGI의 경우는 환경변수 'SERVER_NAME'에 설정된 호스트명이 기록된후, CGI가 호출된다. 이 값은 Domain이 될 수도 있고, IP를 기술할수도 있다.

■ Time Out


# Timeout: The number of seconds before receives and sends time out Timeout 300

서버와 클라이언트의 연결(connection)이 설립된후 양쪽에서 지정한 시간안에 어떠한 메시 지도 보내지 않을 경우 오류처리를 한다. 초단위로 설정하며, 5분(300초)이면 대부분 적당하다.

■ 속도 향상을 위한 연결 유지


# KeepAlive: Whether or not to allow persistent connections (more than # one request per connection). Set to "Off" to deactivate. KeepAlive On # MaxKeepAliveRequests: The maximum number of requests to allow # during a persistent connection. Set to 0 to allow an unlimited amount. # We recommend you leave this number high, for maximum performance. MaxKeepAliveRequests 0 # KeepAliveTimeout: Number of seconds to wait for the next request KeepAliveTimeout 15

KeepAlive란 같은 TCP연결에 여러 가지 요청을 동시에 처리할수 있는 기능이며, 'On', 'Off'로 설정할수 있다. HTTP/1.0에서는 단일 요청에 하나의 세션이 할당된후, 요청을 완료하고 연결을 종료한다. 이때, HTML 문서가 여러개의 그림을 포함하고 있을 경우, 클라이언트는 모든 그림에 대해 서버와 연결을 시도할것이며, 연결이 성립되기 까지의 지연을 반복하게 되어 비효율 적이다. KeepAlive는 HTTP/1.1 규약 초안에 명시된 내용으로, 단일 요청이 요구된후, KeepAliveTimeout에 설정된 시간(초)동안 연결을 유지함으로써 다음번 연결 요청시 지연시간을 최소화 한다. 여러 그림을 포함한 HTML문서의 로딩에 약 50%의 속도 향상을 기대할수 있다.

MaxKeepAliveRequests엔 동시에 몇 개까지의 연결을 KeepAlive 할것인지 설정한다. 0으 로 설정하면 모든 요청에 대해 KeepAlive를 적용한다.

특별한 경우가 아니면 위와같이 설정 한다.

■ 대기 서버 개수


# It does this by periodically checking how many servers are waiting # for a request. If there are fewer than MinSpareServers, it creates # a new spare. If there are more than MaxSpareServers, some of the # spares die off. These values are probably OK for most sites --- MinSpareServers 5 MaxSpareServers 10 # Number of servers to start --- should be a reasonable ballpark figure. StartServers 5

서버는 연결 지연 시간을 최소화 하기 위해, 클라이언트의 요청전에 여분의 대기 서버 (Spare Server)를 생성시켜 놓는다. MinSpareServers는 대기 서버의 최소 개수를, MaxSpareServers는 최대 개수를 지정한다. 서버는 최소 개수보다 대기 서버가 적으면 대기 서버 를 생성하고, 많으면(많은 연결을 수용하고 연결이 종료하였을 때) 제거한다.

StartServers는 서버 실행시의 대기 서버수를 지정하는데, MinSpareServers와 같게 설정한 다.

굉장히 잦은 요구를 대하는 서버가 아니라면, 본 설정값은 대부분 적절하다.

■ 동시 요청 연결 개수 및 자 프로세스 유한 생존 시간


# Limit on total number of servers running, i.e., limit on the number # of clients who can simultaneously connect --- if this limit is ever # reached, clients will be LOCKED OUT, so it should NOT BE SET TOO LOW. # It is intended mainly as a brake to keep a runaway server from taking # Unix with it as it spirals down... MaxClients 100 # MaxRequestsPerChild: the number of requests each child process is # allowed to process before the child dies. # The child will exit so as to avoid problems after prolonged use when # Apache (and maybe the libraries it uses) leak. On most systems, this # isn't really needed, but a few (such as Solaris) do have notable leaks # in the libraries. MaxRequestsPerChild 30

MaxClients는 클라이언트의 동시 연결 허용 개수이다. 설정된 값보다 많은 연결이 요구될 경우, 클라이언트는 몇몇 연결이 종료될때까지, 대기된다.

MaxRequestsPerChild는 각각의 자 프로세스(child server process)가 몇 개까지의 클라이 언트 요구를 처리할지 결정한다. 30이라고 설정되어 있을 경우, 프로세스는 30개의 개별적인 클라 이언트 요청을 처리하고 종료된다. 0으로 설정하면 프로세스가 처리하는 요청은 무한대가 되며, MaxSpareServers 제한에 의해서만 제거된다. 이를 0으로 설정하지 않는 이유는 자 프로세스의 유한 생존 시간(finite lifetime)을 설정함으로써, 버그나 어떠한 돌발적인 상황에 의해 프로세스가 메모리를 모두 점유하는 상황에 대비하기 위함이다.

예를 들어, 'a'라는 클라이언트의 요구에 의해 'X'라는 자 프로세스가 새로 생성되고 'a'와 연결, 통신, 종료의 일련 작업을 행하고 나면, 자 프로세스 'X'는 1번의 요구를 처리한 것이다. 이 후 'b'라는 클라이언트의 연결 요청이 'X' 프로세스와 연결 되었다면, 'X'는 총 2번의 요구를 처 리한 것이다. 이렇게 각 프로세스는 클라이언트와 연결된 횟수를 카운트하다가 MaxRequestsPerChild에 설정된 수치에 달하면, 요청을 완료하면서 자폭한다.

대부분의 경우 30은 적절한 생명주기(life time)이다.

5-2-3. access.conf 손질

'access.conf'는 외부 접근에 대한 디렉토리 권한 및 기능을 설정한다.

웹 페이지 루트에 대한 설정과 'cgi-bin' 디렉토리에 대한 설정이 기본으로 요구되며, 절대 경로를 사용해서 다음과 같은 형식으로 설정한다.


<Directory 디렉토리-절대경로> Options AllowOverride order allow from deny from </Directory>

본 설정은 기술된 디렉토리를 기점으로 그 서브 디렉토리에 모두 적용이 되는 공통 사항이 다. 자세한 세부 설정법을 알아보자.

● Options : 디렉토리에 대한 노출을 조절한다.


None	모든 설정을 부정한다.
All	MultiViews를 제외한 모든 항목을 적용한다.
ExecCGI	ScriptAlias로 설정되지 않은 디렉토리에서 CGI 실행을 허용할 때 사용되며, 이때는 반드시 CGI Script를 구분할수 있는 확장자를 'srm.conf'에 설정해주어야 유효하다.
FollowSymLinks	심볼릭 링크를 따라 간다.
Includes	SSI(Server Side Includes)를 허용한다.
IncludesNOEXEC	SSI를 허용하지만, '#exec'와 '#include'에 의한 CGI 실행은 거부된다.
Indexes	'http://shinan.hongik.ac.kr/test/'와 같이 구체적인 문서를 지정하지 않을 경우 요청한 디렉 토리에 index.html등의 기본 파일이 존재 하지 않을 경우 디렉토리의 목록(파일 리스트)을 제공한 다.
MultiViews	클라이언트의 요청에 따라 다른형식을 보여준다. 클라이 언트가 서버에 요청시 'Accept-Language: kr'과 같은 정보를 포함하면 서버는 이에따라 적절한 자료를 전송하여 준 다.
SymLinksIfOwnerMatch	서버의 UID/GID와 같은 심볼릭 링크만을 따라 간다.

일반적인 홈페이지일 경우 다음과 같은 조합이 주로 사용된다.

◈ 웹 루트(http://Domain) : Options ExecCGI FollowSymLinks Includes

◈ 개인계정(http://Domain/~ID) : Options ExecCGI FollowSymLinks Indexes

● AllowOverride : 사용자 인증 방식을 결정한다.

요청한 디렉토리에서 '.htaccess' 사용자 인증화일을 만났을 경우, 이전의 사용자 인증에 대해 새로운 인증 적용 방식을 결정한다. 요청된 디렉토리가 문서 루트(Document Root) 디렉토 리가 아닐 경우 상향으로 '.htaccess' 파일의 존재여부를 확인한다.

예로 문서 루트가 '/service/httpd/htdocs/'이고 요청된 디렉토리가 '/service/httpd/htdocs/a/b/'일 경우 서버는 아래의 순서로 인증을 확인한다.

1. /service/httpd/htdocs/.htaccess

2. /service/httpd/htdocs/a/.htaccess

3. /service/httpd/htdocs/a/b/.htaccess

사용자 인증을 확인하려면 'All'을 '.htaccess'화일이 있더라도 이를 무시하려면 'None'을 설정한다.

웹 설정에 있어 'AllowOverride None'으로 설정할일은 거의 없고, 대부분의 경우 'AllowOverride All'이 설정된다.

● order : 접근 가능 호스트를 정의 한다.

해당 디렉토리 및 서브 디렉토리에 접근할수 있는 호스트, 또는 접근할수 없는 호스트를 아래와 선언 한다.

다음은 'hongik.ac.kr' domain을 갖는 모든 호스트에 대해 접근이 거부된다. 따라서 'shinan.hongik.ac.kr', 'elecom.hongik.ac.kr'등에서는 접속할수 없다.


order allow,deny allow from all deny from .hongik.ac.kr

다음은 반대로 'hongik.ac.kr' domain을 갖는 호스트만 접근이 허용된다.


order deny,allow deny from all allow from .hongik.ac.kr

대부분의 경우 아래와같이 모든 접근을 허용한다. (deny는 생략)


order allow,deny allow from all

다음은 '문서 루트', 'cgi-bin' 그리고 개인홈페이지에 대한 일반적 설정 예이다.

■ 문서 루트(htdocs) 디렉토리


<Directory /service/httpd/htdocs> Options ExecCGI FollowSymLinks Includes AllowOverride All order allow,deny allow from all </Directory>

'/service/httpd/htdocs' 디렉토리를 기점으로 그 이하 서브 디렉토리에대해 CGI 실행, SSI, 심볼릭 링크를 지원한다. '.htaccess'가 존재할 경우 대상 디렉토리 또는 허용된 상위 디렉토리에 존재하면, 사용자 인증을 하고, 모든 요청에 대해 열려 있는 디렉토리 이다.

■ CGI 루트(cgi-bin) 디렉토리


<Directory /service/httpd/cgi-bin> Options ExecCGI FollowSymLinks AllowOverride None order allow,deny allow from all </Directory>

cgi-bin 디렉토리에 관해 CGI 실행과 심볼릭 링크를 지원 하고, 사용자 인증을 무시한다. 이때, 'cgi-bin' 디렉토리가 뒤에나올 'ScriptAlias'로 지정되어 있다면, ExecCGI 옵션은 자동 기 술 안해도 동일한 결과를 얻을수 있다. ExecCGI 옵션은 요청한 파일이 'srm.conf'에서 설정된 CGI 파일 형태(.cgi)일 경우 CGI로 실행하지 결정한다. 만약 이옵션이 없다면, CGI도 일반문서로 인식하고 CGI 실행파일 자체를 클라이언트에게 전달하여, 사용자는 화면에 깨어진 글씨가 나오게 된다. 만약 CGI 파일 형태에 대한 설정이 'srm.conf'에 없을 경우 ExecCGI 옵션은 무효화 되며, 서버가 CGI를 인식하는 곳은 ScriptAlias로 지정된 디렉토리에 한정된다. 뒤에 나올 'srm.conf'에 서 추가 설명한다.

■ 사용자 홈디렉토리


<Directory /home/*> Options ExecCGI FollowSymLinks Indexes AllowOverride All order allow,deny allow from all </Directory>

사용자 계정(~Account)이 '/home' 디렉토리 아래 존재한다면, 위와 같이 하여 모든 사용자 를 대상으로 목록보기, CGI 실행, 심볼링 링크, 사용자 인증을 가능하게 할수 있다.

사용자 계정에서의 CGI 실행이 거부되도록 하려면 ExecCGI 옵션을 생략 한다.

5-2-4. srm.conf 손질

서버 자원에 관해 설정한다.

■ 문서 루트


# DocumentRoot: The directory out of which you will serve your # documents. By default, all requests are taken from this directory, but # symbolic links and aliases may be used to point to other locations. DocumentRoot /service/httpd/htdocs

서버 도메인으로 접속했을 때 접속되는 디렉토리를 설정한다. 기본적으로 web server설치 디렉토리 아래의 'htdocs'를 사용하지만, 관리의 편리를 위해, 특정 계정을 document root로 설정 하는 경우도 흔히 있다. 예를들어 www 계정의 홈디렉토리를 루트로 'DocumentRoot /home/www'와 같이 설정하는 경우이다.

또다른, 방법은 htdocs에는 index.html만이 존재하고, 그 하위 디렉토리는 심볼릭 링크를 사용하는 경우이다. 이는 기업에서 각 분과별로 관리가 별도 이루어질 때 유용한데, 예를 들어 A 라는 홈페이지에는 A1, A2, A3라는 분과가 존재한다고 가정하자. 문서 루트를 '/service/httpd/htdocs'로 설정하고, 실제 A1, A2, A3의 자료는 accA1, accA2, accA3라는 계정에 저장을 한다. 그후 A1의로의 접근이 'http://Domain/~accA1'이 아닌 'http://Domain/A1'로 하기 위해, 심볼링 링크를 'ln -s ~accA1 A1'과 같이 'htdocs' 디렉토리에 설정한다. 단, 이때는 access.conf의 문서루트 설정에서 FollowSymLinks가 Options에 지정되어야 한다.

■ 계정 루트 디렉토리


# UserDir: The name of the directory which is appended onto a user's home # directory if a ~user request is recieved. UserDir public_html

'http://Domain/~Account'와 같이 사용자 계정으로 접속했을 경우, 그 사용자의 웹 문서 루 트 디렉토리명을 설정하며, 관례적으로 'public_html'을 사용한다.

'Account'라는 사용자가 '/home/Account'란 홈 디렉토리를 가지고 있을 때 이 사용자는 '/home/Account/public_html'이 문서 루트 디렉토리가 되는것이고, 'public_html' 밑에 'index.html'을 작성해야 한다.

사용자 계정으로의 접근을 금지하고 싶으땐 'UserDir disabled'과 같이 한다.

■ 디렉토리 기본 파일


# DirectoryIndex: Name of the file or files to use as a pre-written HTML # directory index. Separate multiple entries with spaces. DirectoryIndex index.html index.shtml index.cgi

서버상의 디렉토리명을 요청할 때 그 디렉토리에서 기본으로 보여줄 자료의 파일명을 기술 한다. 위의 예는 기본 파일로써 3가지를 기술하였는데, 다수가 존재할 경우 먼저 기술된 파일을 보여준다.

■ 목록보기 방식 선택


# FancyIndexing is whether you want fancy directory indexing or standard FancyIndexing on

FancyIndexing이란 디렉토리 목록을 보여줄 때, 각 파일 및 디렉토리를 예정된 ICON으로 표시하여 주는 기능이다. 'on', 'off'를 지정할수 있으며, [그림 5-3], [그림 5-4]와 같은 결과를 얻 을수 있다.

■ 목록보기 삽입 파일


# ReadmeName is the name of the README file the server will look for by # default. Format: ReadmeName name # The server will first look for name.html, include it if found, and it will # then look for name and include it as plaintext if found. # HeaderName is the name of a file which should be prepended to # directory indexes. ReadmeName README HeaderName HEADER

목록보기 화면 상단과 하단에 보여줄 파일명을 지정한다. 디렉토리에 HeaderName으로 저 의된 파일이 있으면 목록보기 상단에 표시하여 주며, ReadmeName은 하단에 [그림 5-5]와 같이 표시하여 준다.

■ 사용자 인증


# AccessFileName: The name of the file to look for in each directory # for access control information. AccessFileName .htaccess

요청한 자료가 존재하는 디렉토리에 AccessFileName으로 정의된 파일이 있으면 그 내용 에 따라 사용자 확인을 거친다. 관례적으로 '.htaccess'와 '.acl'을 사용한다.

■ 기본 Mime Type


# DefaultType is the default MIME type for documents which the server # cannot find the type of from filename extensions. DefaultType text/plain

conf 디렉토리에는 'mime.types'라는 파일이 있다. 이 파일에는 'application/x-compress Z'와 같은 형식으로 Mime Type이 정의되어 있는데, 여기에 선언되지 않은 파일에 대해 기본 Mime Type을 설정한다.

■ 압축형태 선언


# AddEncoding allows you to have certain browsers (Mosaic/X 2.1+) uncompress # information on the fly. Note: Not all browsers support this. #AddEncoding x-compress Z #AddEncoding x-gzip gz

이것은 기술된 확장자를 가지는 파일을 클라이언트가 다운로딩한후 응용 어플리케이션이 바로 해재(decoding)할수 있도록 제공되는 사항이지만, 클라이언트가 이것을 처리할수 있도록 설 정되어 있지 않으면, 'unrecognized encoding'이란 메시지 박스를 표시하므로, 사용자를 혼돈케 할수 있다. 일반적으로 주석 처리한다.

■ 디렉토리 재 지정


# Redirect allows you to tell clients about documents which used to exist in # your server's namespace, but do not anymore. This allows you to tell the # clients where to look for the relocated document. # Format: Redirect fakename url Redirect /httpd http://www.apache.org

Redirect는 매우 유용하게 사용될수 있다. 서버의 특정 디렉토리 요구를 다른 URL로 전환 시킬수 있다. 위의 경우 'http://Domain/httpd'로 접속을 시도하면 자동적으로 'http://www.apache.org'로 접속이 전환된다.

예를들어 디렉토리 '/com'에서 서비스하던 부분을 서버 이전하여 B 호스트의 '/computer' 로 옮겼을 경우, 'Redirect /com http://B/computer'처럼 사용하여, 기존의 링크를 유지 시킬수 있 다. 필요에 따라 사용한다.

■ 디렉토리 별명주기


# Note that if you include a trailing / on fakename then the server will # require it to be present in the URL. So "/icons" isn't aliased in this # example. Alias /icons/ /service/httpd/icons/ Alias /cgi-bin/ /service/httpd/cgi-bin/

문서 루트 디렉토리 아래에 존재하지 않거나, 좀더 짧은 디렉토리명을 사용하고 싶을 때 이용한다.

'cgi-bin'의 경우 예전에는 ScriptAlias를 활용하였지만, 요즘은 Alias로 배정한후 AddType 으로 확장자가 '.cgi'인 것을 script로 인식하도록 한다. 이유는 많은 수의 공개 CGI들이 cgi-bin 디렉토리에서의 문서나 그림을 보여주도록 작성되어 있는데, ScriptAlias로 배정되면 이것이 불가 능하기 때문이다.

'icons' 디렉토리는 꼭 설정하여야 한다.

■ CGI 실행 디렉토리


# ScriptAlias: This controls which directories contain server scripts. # Format: ScriptAlias fakename realname #ScriptAlias /cgi-bin/ /usr/local/etc/httpd/cgi-bin/

활용방법은 Alias와 동일하다. 단 ScriptAlias로 지정된 디렉토리를 억세스 할시에는 html 이건, 그림이건 모두 script로 인식하여 그것을 실행하려 한다는 것이다.

공개 CGI를 ScriptAlias로 배정된 'cgi-bin' 디렉토리에 설치한후 실행을 시켜보면, 그림 이미지가 모두 깨어져 나오는 경우가 있는데, 이는 이러한 이유에서 야기된다.

위에서 언급한대로 보통 주석 처리하고 일반 Alias로 설정한다.

■ CGI, SSI(Server Side Include) 구분 확장자


# To use CGI scripts: AddType application/x-httpd-cgi .cgi AddHandler cgi-script .cgi # To use server-parsed HTML files AddType text/html .shtml AddHandler server-parsed .shtml

확장자 '.cgi'와 '.shtml'을 각각 CGI Script, SSI 문서로 인식시키기 위한 방법이다.

'access.conf'에서 설정한 ExecCGI 옵션은 위와같이 CGI 인식 방법이 설정되어 있을경우 만이 유요하다. 또한 ExecCGI 옵션을 주어 CGI가 실행 가능한 디렉토리를 선별하는 작업도 잊지 말아야 한다. 서버에서 CGI와 SSI 문서를 인식시키기 위해 위와 같이 설정하기 바라며, 'access.conf'의 'Options'에 'ExecCGI', 'Includes'를 추가하거나 삭제함으로써 디렉토리별 지원 을 할수 있다.

5-3. 구동 및 종료

이제 서버 설정을 마쳤으니, 실제 서버를 구동하여 보고, 시스템이 부팅되고 종료될 때 자 동으로 서버가 작동되도록 시스템을 손보는 방법을 알아보자.

5-3-1. 서버 구동 (Server Starting)

다음과 같이 서버를 구동한후 서버에 접속하여 보자.


root@/service/httpd> pwd /service/httpd root@/service/httpd> ./httpd -d /service/httpd

유닉스 시스템에서는 무소식이 희소식이란 말이 일맥 상통한다. 서버를 구동시킨후 아무런 응답없이 프롬프트가 떨어진다면, 서버 설정에 별다른 무리가 없다는 말이다.

서버에 접속하여 보면 [그림 5-6]과 같이 미리 준비된 HTML 문서가 보여진다. 여기에는 서버 설정에 관한 내용들이 들어 있으니, 추후 'htdocs'에 자료를 올리기 전 'htdocs/manual'같은 디렉토리를 생성하여 내용을 이동 시켜 놓기 바란다.

5-3-2. 서버 종료 및 재시동 (Server Stopping and Restarting)

서버를 구동한후 'logs' 디렉토리를 보면 'httpd.pid'란 파일이 생성되어 있고, 그 내용엔 서버의 모 프로세스(Parents Process) PID가 적혀 있다.

서버를 종료할때는 'TERM' 시그널을 모 프로세스에게 보내고, 재시동 할 때는 'HUP' 시 그널을 보낸다. 서버는 시작할 때 단한번 설절사항을 읽으므로, 설정이 변경되었을때는 'HUP' 시 그널로 서버를 재시동시켜 새로운 설정사항을 적용시킬수 있다.

다음은 서버를 종료 시키는 예이다.


root@/service/httpd> cd logs root@/service/httpd/logs> ls access_log error_log httpd.pid root@/service/httpd/logs> cat httpd.pid 21895 root@/service/httpd/logs> kill -TERM `cat httpd.pid`

다음은 서버를 재시동 하는 예이다.


root@/service/httpd/logs> kill -HUP `cat httpd.pid`

만약 서버 프로세스가 가동중인데 실수로 httpd.pid를 삭제 하였을 경우, PID가 필요하다면 다음과 같이 알아낼수 있다. 아래의 ps 결과를 확인하면 감을 잡을수 있을텐데, 프로세스의 소유 주가 root(서버를 구동시킨 UID)이고 모 프로세스 번호가 1(init daemon)인 것이 웹 서버의 PID 이다. 즉 21895가 모 프로세스 PID 이다.


root@/service/httpd> ps -ef \| grep httpd \| sort UID PID PPID C STIME TTY TIME CMD root 21895 1 1 05:07:13 ? 0:00 ./httpd -d /service/httpd root 21902 21549 1 05:07:15 pts/0 0:00 grep httpd www 21896 21895 0 05:07:13 ? 0:00 ./httpd -d /service/httpd www 21897 21895 0 05:07:13 ? 0:00 ./httpd -d /service/httpd www 21898 21895 0 05:07:13 ? 0:00 ./httpd -d /service/httpd www 21899 21895 0 05:07:13 ? 0:00 ./httpd -d /service/httpd www 21900 21895 0 05:07:13 ? 0:00 ./httpd -d /service/httpd

5-3-3. 시스템 시작/종료시 서버 구동 Script

시스템을 키고 끌때마다 서버를 시동시키는 작업을 Script로 자동 구현할수 있다.

먼저 솔라리스의 경우 '/etc/init.d/httpd.server'란 파일로 아래의 스크립트를 작성한다. (리 눅스의 경우 '/etc/rc.d/init.d/httpd.server')

상단의 'SERVER_ROOT'만 자신의 서버에 맞게 변경하면, 모든 시스템에 적용가능하다.


#!/bin/sh # 서버가 설치된 디렉토리 SERVER_ROOT=/service/httpd case "$1" in 'start') # Server Daemon이 존재하면 if [ -f $SERVER_ROOT/httpd ]; then $SERVER_ROOT/httpd -d $SERVER_ROOT > /dev/console echo "Apache HTTPd server starting." # SERVER_ROOT에서 Daemon을 찾지 못함 else echo "Apache HTTPd daemon not found." fi ;; 'stop') # PID가 기술된 파일을 찾음 if [ -f $SERVER_ROOT/logs/httpd.pid ]; then # 여기서 `는 키보드 좌측 상단(ESC 및) 캐릭터이다. PID=`cat $SERVER_ROOT/logs/httpd.pid` kill -TERM $PID > /dev/console echo "Apache HTTPd server($PID) shut down." else echo "Apache PID not found." fi ;; *) echo "Usage: $0 start\|stop" exit 1 ;; esac exit 0

작성된 Script의 Permission을 755로 변경하고, '/etc/rc3.d/S99httpd.server'(리눅스 '/etc/rc.d/rc3.d/S99httpd.server')와 '/etc/rc0.d/K99httpd.server'(리눅스 '/etc/rc.d/rc0.d/K99httpd.server')란 이름으로 심볼릭 링크를 생성하자.

다음은 일련의 과정을 보여준다.


root@/service/httpd> cd /etc/init.d root@/etc/init.d> vi httpd.server root@/etc/init.d> chmod 755 httpd.server root@/etc/init.d> cd ../rc3.d root@/etc/rc3.d> ln -s ../init.d/httpd.server ./S99httpd.server root@/etc/rc3.d> cd ../rc0.d root@/etc/rc0.d> ln -s ../init.d/httpd.server ./K99httpd.server

시스템이 시동/종료할 때 정확히 작동되는지 다음과 같이 시험을 해보도록 하자.


root@/etc/rc0.d> ./K99httpd.server stop Apache HTTPd server(21661) shut down. root@/etc/rc3.d> ./S99httpd.server start Apache HTTPd server starting.

위와 같은 결과를 얻었다면 시스템이 시동/종료될 때 자동으로 Web Server가 구동되고 종 료될 것이다.

5-4. 카운터 CGI 설치

웹 서버를 서버환경에 맞게 설정하여, 구동시켜 성공적인 설치를 하였으니, 이제 카운터, 방명록, 게시판을 차근차근 설치하도록 하자.

카운터는 전세계적으로 wwwcount라는 소프트웨어가 거의 독점을 하고 있는 듯하다. 참고 로 본 소프트웨어로는 날짜, 시간을 표시하는 기능도 갖추고 있다.

'cgi-bin' 디렉토리와 'htdocs' 디렉토리는 실제 웹 서버가 구동되는 사용자로 보통 설정한 다. 이는 CGI의 실행 결과가 미리 설정해둔 웹 서버 UID/GID로 기록되기 때문에, 수정 삭제시 root의 도움없이 행할수 있기 때문이다.

기존의 디렉토리를 적절히 Backup해둔후 새로이 'cgi-bin', 'htdocs'를 생성하고 chown, chgrp 명령을 사용하여 소유주를 바꾸어 준다. 그리고 이제 부터는 root가아닌 웹 서버 UID를 갖 는 사용자 계정으로 접속하여 작업하도록 하자.

5-4-1. 'wwwcount' Download

'http://www.fccc.edu/users/muquit/Count.html'에 [그림 5-7]과 같이 접속하여, wwwcount 의 최신버젼을 다운받는다.

'cgi-bin'디렉토리 밑에 'src'라는 임시 디렉토리를 생성한후 다음과 같이 파일을 옮긴후 압 축을 해제한다.


www@/service/httpd/cgi-bin/src> ls wwwcount2.3.tar.gz www@/service/httpd/cgi-bin/src> gunzip wwwcount2.3.tar.gz www@/service/httpd/cgi-bin/src> tar xvf wwwcount2.3.tar www@/service/httpd/cgi-bin/src> ls wwwcount2.3 wwwcount2.3.tar www@/service/httpd/cgi-bin/src> cd wwwcount2.3 www@/service/httpd/cgi-bin/src/wwwcount2.3> ls Count-config VERSION configure.in main.c testcount-sh Count-install cdebug.h count.cfg makefile.wnt utils Gen-conf combine count.h mkdirhier wcount Makefile.in configNT.h docs parse.c README configure install-sh strimage.c

wwwcount는 인스톨시 질문에 대답을 하는 형식으로 설치가 진행되며, 다음과 같이 5개의 과정으로 나눌수 있다.


Step 1. ./Count-config Step 2. ./configure Step 3. make Step 4. ./Gen-conf Step 5. ./Count-install

앞으로 'cgi-bin' 디렉토리에는 여러 종류의 CGI가 공존하게 될것인데, 관리의 편리성과, 명료성을 위해, 각각의 CGI를 별도의 서브디렉토리로 분류하여 설치를 하도록 하자. 여기서 설치 할 카운터는 'cgi-bin' 아래 'count' 디렉토리로 정하자.

5-4-2. Compile and Install

wwwcount는 기본적으로 'cgi-bin' 밑에 'Count.cgi'란 CGI를 생성하고 필요한 자료는 별 도의 디렉토리에 생성하도록 하는데, 우리는 'cgi-bin/count'밑에 CGI와 자료를 같이 설치하도록 하자.

먼저 'cgi-bin/count'라는 디렉토리를 만들고 위에서 './Count-config'를 실행하여 설치 환 경에 관한 질의에 응답한다. 아래는 주석을 제외한 실행 예이다.


www@/service/httpd/cgi-bin> mkdir count www@/service/httpd/cgi-bin/src/wwwcount2.3> ./Count-config Continue [y\|n] y * cgi-bin dierctory [/usr/local/etc/httpd/cgi-bin]: /service/httpd/cgi-bin/count * Base directory [/usr/local/etc/Counter]: /service/httpd/cgi-bin/count * Config directory [/service/httpd/cgi-bin/count/conf]: * Name of the configuration file [count.cfg]: * Data directory [/service/httpd/cgi-bin/count/data]: * Log directory [/service/httpd/cgi-bin/count/Log]: * Name of the log file [Count2.3.log]: count.log ++++++++++++++++++++++++++++++ CgiBinDir=/service/httpd/cgi-bin/count BaseDir= /service/httpd/cgi-bin/count DigitDir= /service/httpd/cgi-bin/count/digits ConfDir = /service/httpd/cgi-bin/count/conf ConfFile= count.cfg DataDir= /service/httpd/cgi-bin/count/data LogDir= /service/httpd/cgi-bin/count/Log LogFile= count.log ++++++++++++++++++++++++++++++ Everything looks ok [y\|n]y

위의 예에서 'cgi-bin directory'를 묻는건 추후 생성될 'Count.cgi'가 설치될 디렉토리디고, 'Base directory'는 카운터 CGI의 자료 및 설정사항이 저장될 디렉토리이다.

그 다음, 아래 와같은 일련의 작업을 한다.


www@/service/httpd/cgi-bin/src/wwwcount2.3> ./configure checking for ANSI C header files... yes . creating Makefile www@/service/httpd/cgi-bin/src/wwwcount2.3> make www@/service/httpd/cgi-bin/src/wwwcount2.3> ls Config.tmpl README config.status install-sh strimage.c Count-config VERSION configNT.h main.c strimage.o Count-install cdebug.h configure main.o testcount-sh Count.cgi combine configure.in makefile.wnt utils Gen-conf config.cache count.cfg mkdirhier wcount Makefile config.h count.h parse.c Makefile.in config.log docs parse.o

이제 Count.cgi까지 생성 되었다. wwwcount는 'config.cfg' 파일을 생성해주는 'Gen-conf' 라는 툴을 제공해 주는데, 다음과 같이 설정할수 있다.


www@/service/httpd/cgi-bin/src/wwwcount2.3> ./Gen-conf Continue [y\|n]? y * Enter your fully qualified domain name [no default]: shinan.hongik.ac.kr * Enter your IP address [no default]: 203.249.84.246 * Does your host have any nickname [y\|n]:? n * Do you want to allow automatic file creation [[y\|n]? n * Do you want the program to run in strict mode [[y\|n]? n * Do you want to ignore access hits from your own host [y\|n]? y * Allow using the rgb.txt file [y\|n]? y

위에서 'automatic file creation'이란 사용자가 존재하지 않는 카운터 파일을 요구할시 자 동으로 요구된 파일을 생성할지를 결정하며, 'strict mode'란 허용된 웹 브라우져 일 때, 정상적인 출력을 보여준다는 것이다. 'strict mode'를 y로 설정하였을 경우 Netscape 4.0등의 새로운 브라 우져에서는 카운터가 '888888'과 같은 식으로 보이게 되니, 반드시 'n'으로 설정해야 한다. 'ignore access hits from your own host'는 자신의 서버 도메인으로 접속을 할 때 카운터를 증 가시키지 않겠다는 옵션이고, 'rgb.txt'는 카운터의 색상을 지정할 때, ff0034와 같은 숫자외에 red 와같이 설정된 색상표를 이용하겠다는 것이다.

마지막으로 install을 다음과 같이 함으로써 설치가 완료된다.


www@/service/httpd/cgi-bin/src/wwwcount2.3> ./Count-install =================== cgi-bin directory= /service/httpd/cgi-bin/count conf directory= /service/httpd/cgi-bin/count/conf conf file= count.cfg digit directory=/service/httpd/cgi-bin/count/digits data directory=/service/httpd/cgi-bin/count/data log directory=/service/httpd/cgi-bin/count/Log log file=count.log rgb file= ./wcount/rgb.txt =================== Continue [y\|n] y Do you know the user and group id of httpd' child process[y\|n]: y Enter user id of httpd's child process [no default]: www *Enter group id of httpd's child process [no default]: http

웹서버의 UID/GID를 묻는 것은 카운터에 관련된 파일 소유주를 변경하기 위함이다.

자 이제 설치가 완료 되었다. 'cgi-bin/count' 디렉토리에 원하는 대로 설치가 완료되었는 지 살펴보자. [그림 5-8]과 같은 구조로 카운터가 설치되어 있음을 확인할수 있다.


www@/service/httpd/cgi-bin/src/wwwcount2.3> cd ../../count www@/service/httpd/cgi-bin/count> ls -asCF total 210 164 Count.cgi* 2 data/ 2 ./ 2 Log/ 2 digits/ 2 ../ 2 conf/ 34 rgb.txt

Log 디렉토리엔 잘못된 사용으로 인한 오류 로그가 저장되며, conf엔 카운터 설정사항이 저장된다. 설정파일 'count.cfg'를 보면 우리가 'Gen-conf' 명령으로 설정해준 사항이 들어 있는 것을 알수 있는데, 설정을 바꾸고 싶을때는 주석을 보며 이것을 수정하면 바로 적용된다.

5-4-3. 동작 확인

'data' 디렉토리에는 카운터 파일이 있는데, 먼저 data 디렉토리에서 'test.dat'란 파일을 내 용없이 생성('touch test.dat')하고, 웹 브라우져에서 다음과 같이 실행 시켜 보자, [그림 5-9]과 같 은 결과를 얻을수 있을 것이다..

http://Domain/cgi-bin/count/Count.cgi?df=test.dat

이제 홈페이지 HTML 문서에 다음과 같은 행을 삽입하여 카운터, 날짜, 시간을 [그림 5-10]과 같이 삽입할수 있다.

wwwcount는 굉장히 다양한 기능을 가지고 있는데, 'docs' 디렉토리에서 그 사용법을 확 인할수 있으며, 기본으로 들어있는 5가지 모양 외에도 새로운 이미지를 쉽게 설치할수 있다.


(주의) wwwcount 2.3은 카운터파일 내용이 0 일 경우 카운터를 증가시키지 않는 버그가 있 다. 'data' 디렉토리에 있는 sample.dat를 아무리 동작시켜도 계속 0이 나오는 이유는 이것 때문 이니, 새로운 카운터파일을 생성할때는 'touch' 명령을 이용해 내용없는 파일을 생성하기 바란 다.

5-5. 방명록 CGI 설치

방명록으로는 CrazyGuestbook을 선택하였다. 아래와 같은 특징을 보여준다.

○ 통합 관리 툴 제공으로 웹상에서 각 DB의 Configuration을 수정할수 있다.

○ 하나의 CGI로 구현되므로 관리가 용이하다.

○ 방명록 추가 내용을 E-mail로 확인할수 있다.

○ 페이지당 출력량을 조절할수 있다.

○ 게시물의 내용중 URL과 E-mail은 자동으로 링크가 생성된다.

5-5-1. 'CrazyGuestbook' Download

'http://cgi.hongik.ac.kr'에 [그림 5-11]과 같이 접속하여, CrazyGuestbook의 최신버젼을 다 운받는다.

카운터를 설치했던 요령으로 'cgi-bin/src'로 옮긴후 다음과 같이 압축을 해제한다.


www@/service/httpd/cgi-bin/src> ls CrazyGuestbook-3.2.1.tar.Z www@/service/httpd/cgi-bin/src> uncompress CrazyGuestbook-3.2.1.tar.Z www@/service/httpd/cgi-bin/src> tar xvfp CrazyGuestbook-3.2.1.tar www@/service/httpd/cgi-bin/src> ls CrazyGuestbook-3.2.1.tar guestbook-3.2.1 www@/service/httpd/cgi-bin/src> cd guestbook-3.2.1 www@/service/httpd/cgi-bin/src/guestbook-3.2.1> ls -asCF total 18 2 Install-sh* 2 icon/ 2 src/ 2 ./ 2 README@ 2 message/ 2 ../ 2 data/ 2 qDecoder-3.4/

5-5-2. Compile and Install

CrazyGuestbook은 대부분의 설정을 웹 상에서 행할수 있다. 따라서 단순히 'Install-sh'을 실행함으로써 컴파일이 완료되고, 디렉토리를 'cgi-bin'밑에 적절한 이름으로 이동함으로써 설치 가 완료된다. 일련의 절차는 다음과 같다.


www@/service/httpd/cgi-bin/src/guestbook-3.2.1> ./Install-sh www@/service/httpd/cgi-bin/src/guestbook-3.2.1> cd .. www@/service/httpd/cgi-bin/src> mv guestbook-3.2.1 ../guestbook www@/service/httpd/cgi-bin/src> cd ../guestbook www@/service/httpd/cgi-bin/guestbook> ls -asCF 총 132 2 Install-sh* 2 message/ 2 ./ 2 README@ 2 qDecoder-3.4/ 2 ../ 2 data/ 2 src/ 114 CrazyGuestbook.cgi* 2 icon

'data' 디렉토리에는 각 방명록 자료가 보관되며, 'message' 디렉토리에는 방명록 보기, 쓰 기, 관리 화면의 출력 HTML이 'listhead.html'과 같은 식으로 저장되어 있으니, 외관을 수정할때 는 본 디렉토리를 참고하고, 한글 'README'가 제공되니 살펴보기 바란다.

5-5-3. 동작 확인

웹 브라우져에서 다음과 같이 서버에 접속하여 [그림 5-12]와 같은 화면을 얻을수 있는지 확인한다. 'test'란 방명록은 실험용으로 기본 제공된다.

http://Domain/cgi-bin/guestbook/CrazyGuestbook.cgi?db=test

혹, ICON이 깨어져 나온다면, 'cgi-bin' 디렉토리가 ScriptAlias로 설정되어 있는 경우이므 로, README를 참고하여, 권고설치 사항에 만족하도록 서버 설정을 변경하도록 한다.

원하는 이름의 방명록을 등록하고자 할 때는 다음과 같이 'guestbook/data' 디렉토리에서 원하는 이름의 디렉토리를 생성하면 된다.


www@/service/httpd/cgi-bin/guestbook> cd data www@/service/httpd/cgi-bin/guestbook/data> mkdir nobreak www@/service/httpd/cgi-bin/guestbook/data> ls -asCF total 10 2 ../ 2 nobreak/ 2 ./ 2 .htaccess 2 test/

[그림 5-13]은 생성된 'nobreak' 디렉토리로 초기 접속한 화면인데, 처음 접속하면 방명록 에 대한 설정을 하라는 화면이 출력된다. 지시에 따라 'Admin'을 클릭하면 [그림 5-14]와 같은 관리 모듈이 보이게 되고, 비밀번호와 관리자이름 관리자 E-mail등을 정확히 입력한후 저장하면, 방명록에 추가되는 글들이 E-mail로 통보된다.

다음은 E-mail로 통지된 방명록의 내용으로, 상단과 하단의 사인은 'message/mailhead.txt', 'message/mailtail.txt'의 내용을 수정함으로 변경할수 있다.


## ## Your company signature here ## 'message/mailhead.txt' ## -- [ Server Information ] ---------------------------- SoftWare : CrazyGuestbook.cgi Version 3.2.1 Server Name : shinan.hongik.ac.kr Administrator Name : 김승영 Administrator Email : mailto:nobreak@shinan.hongik.ac.kr HomePage Location : http://shinan.hongik.ac.kr DB Name : nobreak DB Location : http://shinan.hongik.ac.kr:80/cgi-bin/guestbook/CrazyGuestbook.cgi?db=nobreak -- [ Article Information ] ----------------------- @@ Name : 손님 @@ Email : sonnim@test.net @@ HomeURL : http://www.test.net/~sonnim -- [ Text ] -------------------------------------- 관리자에게 편지로 본 내용이 통지 됩니다. 성공적으로 배송되었습니까? ---[ End ] --------------------------------------- ## ## Your company messages here ## 'message/mailtail.txt' ##

5-6. 게시판 CGI 설치

게시판으로도 CrazyWWWBoard를 택하였는데, 방명록과 그 설치방법 및 관리가 흡사하다.

본 게시판의 특징은 아래와 같다.

○ 이름과 E-Mail을 한번 입력하면, 추후 다시 글을 작성할 때 자동으로 표시됨

○ 게시판에 새로운 글이 생성되면 관리자에게 E-mail로 통지

○ 답변된 글일경우 원본 작성자에게 E-mail로 통지

○ HTML 인식여부 결정가능, 자동 URL Link 기능

○ 목록보기 방식 날짜순, 관련글순(Thread) 선택

○ Page 단위로 목록보기

○ 게시판 잠금기능 (관리자만이 게시물 작성가능)

5-6-1. 'CrazyWWWBoard' Download

'http://cgi.hongik.ac.kr'에 접속하여, CrazyWWWBoard를 다운받아 방명록과 동일한 방식으 로 'cgi-bin/src'로 옮겨 압축을 해제한다.


www@/service/httpd/cgi-bin/src> ls CrazyWWWBoard-2.0.1.tar.Z www@/service/httpd/cgi-bin/src> uncompress CrazyWWWBoard-2.0.1.tar.Z www@/service/httpd/cgi-bin/src> tar xvfp CrazyWWWBoard-2.0.1.tar www@/service/httpd/cgi-bin/src> ls CrazyWWWBoard-2.0.1.tar wwwboard-2.0.1 www@/service/httpd/cgi-bin/src> cd wwwboard-2.0.1 www@/service/httpd/cgi-bin/src/wwwboard-2.0.1> ls -asCF 총 22 2 README@ 2 message/ 2 ./ 2 data/ 2 qDecoder-3.4.1/ 2 ../ 4 gdbm-1.7.3/ 2 src/ 2 Install-sh* 2 icon/

5-6-2. Compile and Install

CrazyWWWBoard 또한 방명록과 마찬가지로 대부분의 설정을 웹 상에서 행할수 있다. 같 은 요령으로 'Install-sh'을 실행하고 'cgi-bin'밑에 적절한 이름으로 이동 시킨다.


www@/service/httpd/cgi-bin/src/wwwboard-2.0.1> ./Install-sh ---- CrazyWWWBoard Installation Manager ---- Step 1. Compiling GNU 'gdbm' Library ---- Step 2. Compiling 'CrazyWWWBoard.cgi' ---- Step 3. Compiling 'createDB' ---- Step 4. Installation... ---- Installation Complete... www@/service/httpd/cgi-bin/src/wwwboard-2.0.1> cd .. www@/service/httpd/cgi-bin/src> mv wwwboard-2.0.1 ../wwwboard www@/service/httpd/cgi-bin/src> cd ../wwwboard www@/service/httpd/cgi-bin/wwwboard> ls -asCF 총 272 2 README@ 2 message/ 2 ./ 78 createDB* 2 qDecoder-3.4.1/ 2 ../ 2 data/ 2 src/ 172 CrazyWWWBoard.cgi* 4 gdbm-1.7.3/ 2 Install-sh* 2 icon/

역시 'data' 디렉토리에는 각 게시판 자료가 보관되며, 'message' 디렉토리에는 게시판의 외관에 관한 파일들이 들어 있다.

5-6-3. 동작 확인

설치된 'createDB'를 사용하여, 게시판을 하나 생성한다.


www@/service/httpd/cgi-bin/wwwboard> ./createDB test DB(data/test.gdbm) created. www@/service/httpd/cgi-bin/wwwboard> ls data test.gdbm

브라우져에서 다음과 같이 서버에 접속하면 [그림 5-15]의 초기 접속화면이 나오고, 'Admin'을 클릭하면 [그림 5-16]의 관리 모듈을 볼수 있다. 관리 모듈에서 목록보기 방식, 표시 언어, 게시물 내용 HTML 인식여부 등을 설정한후 저장하자.

http://Domain/cgi-bin/wwwboard/CrazyWWWBoard.cgi?db=test

[그림 5-17]은 목록보기 방식을 관련글순으로 설정한 화면이고, [그림 5-18]은 날짜순 목록 보기 형태이다.

다음은 E-mail로 통지된 게시물 내용, 상단과 하단의 사인은 'message/mailhead.txt', 'message/mailtail.txt'을 수정하여 변경할수 있다.


## ## Your company signature here ## 'message/mailhead.txt' ## -- [ Server Information ] ---------------------------- SoftWare : CrazyWWWBoard.cgi 2.0.1 Server Name : cgi.hongik.ac.kr Administrator Name : 김승영 Administrator Email : mailto:nobreak@shinan.hongik.ac.kr HomePage Location : http://shinan.hongik.ac.kr DB Name : test DB Location : http://cgi.hongik.ac.kr:80/cgi-bin/wwwboard/CrazyWWWBoard.cgi?db=test -- [ Article Information ] ----------------------- @@ Name : 김승영 ## Email : mailto:nobreak@shinan.hongik.ac.kr ## Date : 199709111442 3 (yyyymmddhhmmss) ## Host : 210.127.183.43 of 210.127.183.43 @@ Subject : 실험입니다. -- [ Text ] -------------------------------------- 게시판에 추가된 게시물이 관리자에게 E-mail로 통지 됩니다. 잘 동작합니까? ---[ End ] --------------------------------------- ## ## Your company messages here ## 'message/mailtail.txt' ##

5-7. Log 분석 툴의 활용

서버에 얼마나 많은 사용자의 방문이 있었고, 어떠한 페이지가 가장 인기 있으며, 트래픽이 많이 걸리는 시간대등에 대한 파악을 위해서는 로그의 분석이 필요 하다.

여러 가지 로그분석 툴이 존재하는데, 그래픽컬하게 시간대별 접속통계를 표시하여 주는 것도 있고, 단순히 텍스트로된 통계 툴도 있다.

여기서 보여줄 통계툴은 후자의 경우인데, 일반 사용자가 한눈에 알아보기에는 전자의 방 법이 효과 적이지만, 실제 관리자가 서버에 대한 세밀한 분석을 요할때는 화려함보다는 그 기능 과 정밀성이 요구되기 때문이다.

서버 방문객에게 보여줄 용도가 아닌, 관리자의 분석 용도라면 'wwwstat'를 권한다. 몇몇 서버들은 여러개의 로그 분석툴을 모두 설치하여, 사용자용과 관리자용으로 사용하기도 한다.

5-7-1. 'wwwstat' Download

'http://www.ics.uci.edu/pub/websoft/wwwstat/'에서 최신버젼의 'wwwstat'를 다운받아 압축을 푼다. 여기서는 '/service/wwwstat'을 기준으로 설명하겠다. [그림 5-19]는 wwwstat 공식 홈페이지의 접속 화면이다.


root@/service> ls -asCF total 1918 2 httpd/ 240 wwwstat-2.0.tar.gz* root@/service> gunzip wwwstat-2.0.tar.gz root@/service> tar wwwstat-2.0.tar root@/service> cd wwwstat-2.0 root@/service/wwwstat-2.0> ls -asCF total 820 4 README 78 splitlog.ps 2 ./ 14 domains.pl 12 splitlog.rc 2 ../ 52 example.html 14 wwwerrs.pl 24 Changes 10 monthly.pl 54 wwwstat.1 14 FAQ 22 oldlog2new.pl 58 wwwstat.html 10 INSTALL 22 splitlog.1 140 wwwstat.pl 14 LICENSE 24 splitlog.html 172 wwwstat.ps 2 Makefile 54 splitlog.pl 22 wwwstat.rc

5-7-2. Install and 동작확인

'Makefile'에서 'PERLBIN'의 경로가 서버의 Perl 설치 경로와 같은지 확인하고(다를 경우 수정한다) make명령을 실행한다.

wwwstat는 인자없이 실행하였을 때 'wwwstat.rc' 파일을 읽어 기술된 분석을 행한후 화 면에 결과를 출력한다. 따라서 wwwstat의 실행 형태는 './wwwstat > result.html'와 같다. 실 제 관리자는 Cron에 등록하여, 정기적으로 자동 업데이트 되도록 한다.

간단히 'wwwstat.rc'화일에서 아래 항목을 수정한후 확인해보자.

■ 로그파일의 위치

$DefaultLog = '/service/httpd/logs/access_log';

■ 호스트의 도메인명

$AppendToLocalhost = '.hongik.ac.kr';

■ IP -> Domain 변환 설정 (속도가 굉장히 느려지니 필요치 않으면 끈다)

$LookupDNS = 0

■ $OutputTitle = 'World Wide Web Access Statistics for Domain' .

$AppendToLocalhost;

wwwstat를 다음과 같이 실행시키고, 웹상에서 결과를 확인하기 위해 result.html을 웹 문 서루트(htdocs)에다 심볼릭 링크 건다.


root@/service/wwwstat-2.0> ./wwwstat > result.html & root@/service/wwwstat-2.0> cd ../httpd/htdocs www@/service/httpd/htdocs> ln -s /service/wwwstat-2.0/result.html wwwstat.html

이제 웹 브라우져에서 'http://Domain/wwwstat.html'의 위치를 열어보면 [그림]과같은 결 과를 얻을수 있다.

'wwwstat.rc'파일의 자세한 튜닝법은 다음과 같이하여 맨페이지를 참고하자.


www@/service/wwwstat-2.0> nroff -man wwwstat.1 \| more www@/service/wwwstat-2.0> nroff -man splitlog.1 \| more


(주의) wwwstat는 Perl로 제작되었다. 따라서 서버에 Perl이 설치되어 있어야 한다.

5-7-3. Cron을 활용한 자동 업데이트

이제 매일 새벽 3시에 자동으로 wwwstat가 수행되도록 Cron에 다음의 내용을 추가 하자.


root@/service/wwwstat-2.0> crontab -e ######################################## # # WWWStat # 0 3 * * * /service/wwwstat-2.0/wwwstat > /service/wwwstat-2.0/result.html

이제 매일 새벽 3시 정각에 접속통계가 업데이트될 것이다. Cron의 자세한 사용법은 3장을 참고하기 바란다.

5-8. Virtual Host 구성

Virtual Host라 함은 물리적인 1개의 서버에 다수의 웹 서비스(개별적인 도메인에 대한)를 제공하는 것이다. 물론 하나의 기계에 2개 이상의 IP를 할당하여(OS 적으로) 웹서버를 구축할수 도 있고, PORT를 다르게 하여 동작시킬수도 있다. 그러나, 다음과 같은 방식으로 1개의 IP에 여 러 도메인을 등록하여, 각각의 도메인에 대해 다른 서비스를 제공할수 있다.

예로 www.cgiserver.net 이라는 도메인으로 웹 서비스를 하고있고, 여기에 ftp.cgiserver.net 이라는 도메인으로 Hosting을 하고 싶다면 다음과 같이 할수 있다.

① 로컬 DNS에 호스트명 ftp를 www의 CNAME으로 등록한다.

② 웹서버의 설정파일(httpd.conf)을 적절히 수정한다.

로컬 DNS에는 이미 호스트명 www가 등록되어 있을테니,다음과 같이 ftp를 별명 (CNAME)으로 설정한다. 그러면 www 와 ftp는 동일한 IP를 갖게 된다.


www IN A 203.249.84.220 ftp IN CNAME www.cgiserver.net.

그리고 http.conf 파일을 열어 다음을 추가하자.


<VirtualHost ftp.cgiserver.net> ServerAdmin webmaster@cgiserver.net DocumentRoot /service/ftp/pub ServerName ftp.cgiserver.net ErrorLog logs/error_log.ftp TransferLog logs/access_log.ftp </VirtualHost>

웹 서버상에서 설정을 하지 않았다면, ftp.cgiserver.net 으로의 접속은 www.cgiserver.net 으로의 접속과 동일할 것이다. 그러나 위의 사항을 설정하고 웹서버를 행업시키고 나면, ftp.cgiserver.net 으로의 접속은 '/service/ftp/pub/'를 Document Root로 하여 내용이 출력될 것이 다.

이와 같이 Virtual Host를 설정하여 1대의 서버로 다수의 서비스를 제공할수 있다.

--------------- 이하 공백 -------------------------

1. Home Page Counter 설치방법

[atom2:/user/mentor]ftp atom1

ftp> get wwwcount2.3.tar.gz

[atom2:/user/mentor]gzip -dc wwwcount2.3.tar.gz|tar xvf -

[atom2:/user/mentor/wwwcount2.3]vi README

[atom2:/user/mentor/wwwcount2.3]ls
Config.tmpl     Makefile        cdebug.h        configure.in    install-sh*     parse.c         wcount/
Count-config*   Makefile.in     combine/        count.cfg       main.c          strimage.c
Count-install* README          configNT.h      count.h         makefile.wnt    testcount-sh*
Gen-conf*       VERSION         configure*      docs/           mkdirhier*      utils/

[atom2:/usr/local]ls
apache/    bin/       info/      lib/       man/       netscape/ samba/

[atom2:/usr/local]su

atom2# mkdir etc

[atom2:/usr/local]ls
apache/    bin/       etc/       info/      lib/       man/       netscape/ samba/

[atom2:/user/mentor/wwwcount2.3]./Count-config
Welcome to the configuration procedure of Count 2.3
---------------------------------------------------

o You must know where your system keeps CGI programs (cgi-bin directory)
is necessary to generate the install program.
This directory must exist. If this directory does not exist, the
configuration procedure will Abort!

o You have to decide a directory, where you will keep all counter related
stuff. This directory will have other directories inside. Default
values will be supplied, press Return key to accept the default value.
Accept the default value, it will make your life much easier.
During installation, the directories will be created for you
if they do not exist and if you have the permission to do so.
++
Continue [y|n]y

You need to enter the full path of the directory where you system
keeps the CGI programs. This directory must exist!

*cgi-bin dierctory [/usr/local/etc/httpd/cgi-bin]:/usr/local/apache/share/cgi-bin

You need to enter the base directory of the counter related stuff.

*Base directory [/usr/local/etc/Counter]:

You need to enter the directory of the configuration file.

* Config directory [/usr/local/etc/Counter/conf]:
You need to enter the name of the configuration file.
This file contains the information about

o if you want to ignore access from certain hosts
o host acccess authentication
You will create this file later by running the program "Gen_conf".

* Name of the configuration file [count.cfg]:

You need to enter the directory of the counter data file.

*Data directory [/usr/local/etc/Counter/data]:

You need to enter the directory of the Log file.

*Log directory [/usr/local/etc/Counter/Log]:

You need to enter the name of the Log file.
This file hold the error messages of the counter. It also
logs if someone tried to access your counter remotely.

* Name of the log file [Count2.3.log]:

You entered:
++++++++++++++++++++++++++++++
CgiBinDir=/usr/local/apache/share/cgi-bin
BaseDir= /usr/local/etc/Counter
DigitDir= /usr/local/etc/Counter/digits
ConfDir = /usr/local/etc/Counter/conf
ConfFile= count.cfg
DataDir= /usr/local/etc/Counter/data
LogDir= /usr/local/etc/Counter/Log
LogFile= Count2.3.log
++++++++++++++++++++++++++++++
Everything looks ok [y|n]y
Great! creating header file config.h
creating variables template file ./Config.tmpl for the install program..
now run ./configure

[atom2:/user/mentor/wwwcount2.3]vi configure

[atom2:/user/mentor/wwwcount2.3]./configure
creating cache ./config.cache
checking for gcc... gcc
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking for ranlib... ranlib
checking whether make sets ${MAKE}... yes
checking how to run the C preprocessor... gcc -E
checking whether cross-compiling... no
checking for ANSI C header files... yes
checking for sys/wait.h that is POSIX.1 compatible... yes
checking whether time.h and sys/time.h may both be included... yes
checking for string.h... yes
checking for fcntl.h... yes
checking for memory.h... yes
checking for malloc.h... yes
checking for unistd.h... yes
checking for ctype.h... yes
checking for strings.h... yes
checking for sys/stat.h... yes
checking for sys/param.h... yes
checking for sys/file.h... yes
checking for stdlib.h... yes
checking for working const... yes
checking whether struct tm is in sys/time.h or time.h... time.h
checking for flock... no
checking for strcasecmp... yes
checking for mktime... yes
checking for SCO... checking for scosh... maybenot
updating cache ./config.cache
creating ./config.status
creating combine/Makefile
creating Makefile
creating utils/Makefile

[atom2:/user/mentor/wwwcount2.3]make clean
(cd combine; make clean)

[atom2:/user/mentor/wwwcount2.3]vi Gen-conf

[atom2:/user/mentor/wwwcount2.3]./Gen-conf
    Welcome to the conf file generation procedure of Count 2.3

    This program creates a workable conf file for your host only, you have
    to edit it by hand if you want to add other hosts. The file will have
    enough comments in it to help you out. You also have to hand edit it
    if you want to use netmasks to mask out a entire network or a specific
    range of hosts in a network.

    First of all you must know your
        1) fully qualified domain name (FQDN), for example,
            if your hostname is foo and your domain name is foobar.com,
            then your FQDN is
            foo.foobar.com

        2) IP address of your host, for example,
            192.165.155.2

        3) If your host has any nickname defined, for example,
            www.foobar.com. The nick name also has to be FQDN.

        4) If you want to allow automatic datafile creation (bad thing).

        5) If you want to run the counter in strict mode.
        6) If you want to ignore access hits from your own host.

Continue [y|n]y

    No Error checking will be done with your hostname, therfore,
    you better make sure you are entering the fully qualifed domain name.

* Enter your fully qualified domain name [no default]:atom2.dwt.daewoo.co.kr

    No Error checking will be done with your IP address, therfore,
    you better make sure you are entering the correct IP address.

* Enter your IP address [no default]:165.133.5.32

* Does your host have any nickname [y|n]:n

    Now you need to decide if you will allow the users to create datafiles
    for them automatically. If you allow, the counter datafile will be
    created for the user if it does not exist and a pre-determined counter
    number will be inserted to it. If you do not allow, you have to create
    the datafile for each user, provided that the data diectory has proper
    write permission.

    Allowing users to create datafile is very convenient, as you do not
    have to be asked all the time when someone decides to use the counter.
    But the dark side of this is, anyone will be able create datafiles in
    the data directory. The decision is yours.

* Do you want to allow automatic file creation [[y|n]n

    Now you need to decide if you want to compile the program in strict
    mode. If you compile the program in strict mode, the browsers which
    do not return the environment variable HTTP_REFERER, will not be
    served, that is no access hit will be recorded, no time or date
    will be displayed. Instead, a string 888888 will be displayed.

    The strict mode ensures that your counter data file can not be messed
    by accesing the counter remotely from a browser which does not return
    that variable. Note, good browsers like netscape returns this
    variable. Other browsers e.g. Mosaic does not return this variable in
    IMG GET method at this time. This strict mode is experimental at this
    time!

* Do you want the program to run in strict mode [[y|n]y
* Do you want to ignore access hits from your own host [y|n]y

    Ok, do you want the users to use the file rgb.txt for color name
    lookup? It is very inefficient to search this file every time the
    web page is loaded. If you answer yes, the color name
    will be looked up and used. If you answer no, the color will be
    looked up but instead of the counter image, the RGB value will
    be displayed and the user will be asked to use the RGB value
be displayed and the user will be asked to use the RGB value
    instead. This will prevent users to use this file. However,
    the convenience of allowing to use rgb.txt file is that color name e.g,
    red, gold etc. can be used instead of cryptic red, green and blue
    components of the color.

* Allow using the rgb.txt file [y|n]y

    Created conf file "count.cfg"
    Please look at it, you might want to edit it!

[atom2:/user/mentor/wwwcount2.3]make

atom2# ./Count-install

    *** You are installing Counter as root ***

===================
Your configuration:

cgi-bin directory= /usr/local/apache/share/cgi-bin
conf directory= /usr/local/etc/Counter/conf
conf file= count.cfg
digit directory=/usr/local/etc/Counter/digits
data directory=/usr/local/etc/Counter/data
log directory=/usr/local/etc/Counter/Log
log file=Count2.3.log
rgb file= ./wcount/rgb.txt
===================

Continue [y|n]y
proceeding...

    Now if you know what user and group id child processes of http
    server use, I can change the ownership and access permission
    accordigly. If you do not know, they are usually defined in the
    file httpd.conf with User and Group. I suggest create a unique
    user and group say httpd and set the User and Group to httpd.

*Do you know the user and group id of httpd' child process[y|n]:y
*Enter user id of httpd's child process [no default]:
*Enter user id of httpd's child process [no default]:mentor
*Enter group id of httpd's child process [no default]:mentor
installing Count.cgi->/usr/local/apache/share/cgi-bin
installing count.cfg->/usr/local/etc/Counter/conf
installing sample datafile ./wcount/data/sample.dat->/usr/local/etc/Counter/data
installing rgb.txt->/usr/local/etc/Counter
creating Log directory /usr/local/etc/Counter/Log
installing image strip for digit style A->/usr/local/etc/Counter/digits/A
installing image strip for digit style B->/usr/local/etc/Counter/digits/B
installing strip image for digit style C->/usr/local/etc/Counter/digits/C
installing strip image for digit style D->/usr/local/etc/Counter/digits/D
installing sample image lenna.gif->/usr/local/etc/Counter/digits/D
installing strip image for digit style E->/usr/local/etc/Counter/digits/E

[atom2:/usr/local/etc/Counter/data]cp sample.dat oym.dat

[atom2:/usr/local/etc/Counter/data]chmod 666 oym.dat
[atom2:/user/homepage]vi index.html
여기서 다음과 같은 내용을 추가해 주면 된다.

'Infrastructure' 카테고리의 다른 글

Windows 인증서 msc (0)	2009.09.17
Vista 에서 Visual Basic 6으로 작성된 프로그램을 돌릴때 comdlg32.ocx 에러 뜰때 (0)	2009.09.03
리눅스 응용프로그램 자동 부팅 하게 하는 법 (0)	2009.09.03
공개 웹방화벽(WebKnight) 기술문서 정리 (0)	2009.08.27
SelfSSL과 SelfCert를 이용한 인증서 설치 (0)	2009.08.27

L2J with DuraBoys

UNIX 설치 관련

'Infrastructure' 카테고리의 다른 글

+ Recent posts

티스토리툴바