<그림 1> WWW의 구조
WWW server란 WWW를 통해서 접근할 수 있는 자료들을 보관, 관리, 통제하는 프로그램을 말한다. WWW는 HTTP라는 프로토콜로 통신하기 때문에, WWW server는 흔히 httpd 라고도 불린다. 지금까지 여러개의 httpd가 다양한 플랫포옴 상에서 다양한 언어로 씌어져 나왔다.
본 강의에서는 httpd의 역할이 무엇인가 살펴보고, 현재 나와있는 WWW 서버들을 비교해 보고, 그중에 하나를 택하여 실제로 서버를 설치, 운영하는 방법을 설명한다. WWW 서버로는 CERN httpd 3.0, NCSA httpd 1.4.2, Netscape Communication Server 1.1을 중점적으로 비교하며, 그중에서 CERN httpd 3.0을 중심으로 설치 방법과 그 운영에 대해서 살펴본다. 설치와 운영에서는 단순 설치 방법뿐 아니라, 특정 객체에 대한 access제한, log화일의 운영 및 접근 통계, chroot를 이용한 httpd의 보안등 다양한 부분을 다룬다.
1993년 NCSA의 Mosaic이 인터넷(Internet)에 출현한 이후, WWW는 그 프로토콜의 네트워크 사용량이 매년 두배 이상으로 늘어날 정도로 엄청난 보급율을 자랑하며 빠른 발전을 거듭하여 왔다. 그 결과 지금은 네트워크를 사용하는 사람이라면 WWW home page하나 정도는 가지고 있어야만 되는듯이 여겨지게 되었다.
흔히 Home page라 알려져 있는 HTML문서를 전세계의 인터넷 사용자가 살펴볼 수 있으려면 WWW 서버(server)라는 것이 있어야 한다. WWW는 기본적으로 HTTP라는 프로토콜을 사용하므로 httpd라고도 알려져 있다.
이 글에서는 WWW 서버를 설치하고자 하는 분들을 위하여, 현재 쉽게 구할수 있는 httpd들을 비교하고, 그것의 설치방법에 대해 설명한다.
이 문서는 다음과 같이 구성되어 있다. 먼저 이미 널리 알려진 인터넷 서비스인 anonymous ftp 서비스와 WWW service를 비교한다. 다음에는 현재 널리 알려진, CERN, NCSA, Netscape의 httpd들을 비교하고 각각의 특징에 대해서 자세히 알아본다. 제 4 장에서는 CERN httpd 3.0을 설치하는 과정을 차근차근 설명한다. 제 5 장에서는 httpd의 운영상의 고려사항을 언급한다. 마지막으로 결론을 내린다.
이제 당신은 당신의 home page를 인터넷에 공개하기로 마음먹었다고 하자. 그러면 맨 먼저 무엇을 하여야 할까? 사람들은 아마 httpd를 설치해야 한다고 할 것이다. 만약, 그 이유를 묻는다면 여러가지 대답을 얻을 수 있을 것이다. 어떤 사람은 WWW가 HTTP를 쓰기 때문이라고 할 것이고, 어떤 사람은 httpd를 설치하지 않으면 그림과 글씨가 들어간 HTML문서를 전송할 수 없기 때문이라고 할지도 모른다. 무조건 설치해야만 한다는 사람들도 있을 것이다. 어떤 사람은 home page의 URL을 http로 시작하기 위해서는 설치해야만 한다고 할 것이다. 그러나, 진짜로 설치해야한 하는가?
이 장에서는 이미 인터넷에서 많이 사용되고 있는 anonymous ftp서비스와 http서비스를 비교한다. 이 비교는 두가지를 목적으로 한다. 첫째, 비교를 통해 httpd의 특징을 밝힘으로서, 보다 효율적인 httpd 운영 지식을 파악한다. 둘째, ftpd와 httpd의 장점을 파악함으로써, 어떤 서비스를 시작할때 보다 좋은 도구를 선택할 수 있게 한다.
이것을 보기 쉽게 나타낸 것이 다음의 <그림 1>이다.
- HTML : Hyper-Text Markup Language
- 하이퍼 텍스트(hypertext)의 기술 방법
- URL : Uniform Resource Locator
- 네트워크의 자원을 지정(identify)하는 방법. 검색을 위한 부분도 포함되어 있다. (RFC-1738) 이와 유사한 것으로 URI, URN, RURL등이 있다.
- HTTP : Hyper-Text Transfer Protocol
- HTML을 포함한 다양한 객체의 전송을 위한 객체 전송 규약. 초기에는 HTML의 전송을 위해 설계되었으므로 하이퍼 텍스트 전송 규약이란 이름이 붙었음.
어떤 HTML문서를 전 세계에 공개하기 위해서라면, httpd를 꼭 설치할 필요는 없다. 아시다시피, 대부분의 WWW browser들은 ftp나 gopher, wais등의 다른 프로토콜들도 지원한다. 더구나, ftp로 화일을 받아오는 경우, browser가 확장자를 보고 그에 맞는 처리를 해 준다. 따라서, anonymous ftp에 들어있는 HTML화일도 WWW browser로 본다면 httpd를 통하여 날아온 HTML문서와 별 차이 없이 보인다.
만약, 당신이 httpd를 설치하는데 부담을 느낀다면, 일단 anonymous ftp를 이용하여 서비스를 해 보기 바란다. ftp는 프로토콜이 만들어 진지 꽤 오랜 시간이 지났기 때문에 프로토콜 자체가 안정화되어 있고, 다양한 플랫포옴에서 ftp daemon이 개발되었다. 대부분의 ftp 프로그램들은 설치하기도 쉽고 쓰기도 쉽게끔 만들어졌다. 심지어, Windows NT나 Linux Slackware등에서는 ftp daemon이 기본적으로 설치되어 있을 정도다.
특히, 서비스 할 화일의 크기가 크고 복잡하거나, 네트워크 연결이 별로 좋지 않은 곳들의 사람을 대상으로 하는 경우에는 httpd를 사용하기 보다는 anonymous ftp를 사용하는 것이 좋다. FTP는 글자 그대로 화일을 전송하기 위해서 만들어진 프로토콜이므로, 항상 화일이 제대로 전송되고 있는지 checksum등으로 검사하는 부분이 있다. (참조:RFC-959) 그에 비하여 HTTP는 단지 TCP를 통해서 그대로 전달할 뿐으로, 네트워크 상황이 좋지 않은 경우 HTTP를 통해 전달된 화일은 중간이 빠져 있거나 끊길 경우가 많다.
실제로, Internic의 문서들 중 FYI(For Your Information)는 ftp만을 이용하여 html문서로 제공되고 있다. (참조: ftp://ftp.krnic.net/rfc/fyi-index.html)
FTP던 HTTP던 네트워크를 통해 전달하고자 하는 화일 혹은 object를 저장, 식별(identify)하는 방법에는 차이가 없다. 그렇다면, HTTP는 프로토콜의 기능면에서 어떤 부분이 FTP와 다른가?
WWW가 다른 서비스와 크게 다른 점 중에 하나는, 서버측에 실행화일을 두어 클라이언트의 요구에 따라 그에 맞는 출력을 생성할 수 있다는 것이다.
클라이언트의 요구를 받기 위해 변형된 URL으 뒷부분을 search part라 하며, 클라이언트의 요청을 받은 서버가 그 내용을 서버측 프로그램에 넘겨주고 프로그램이 서버에게 출력을 넘겨주는 방식을 CGI(Common Gateway Interface)라고 한다.
CGI에 대한 좀 더 자세한 설명은 http://hoohoo.ncsa.uiuc.edu/cgi 를 참조하기 바란다.
MIME(Multi-purpose Internet Mail Extension)이란 텍스트, 화상, 음성, 동영상등을 포함한 컴퓨터의 데이타를 일반 텍스트로 부호화하는 통일된 방법이다. MIME은 현재 RFC-1521, 1522로 등록되어 있으며, 인터넷 메일의 표준으로 정착되고 있다. 어떤 컴퓨터 자료가 MIME 규약을 지킨다면, 일반 텍스트 밖에 전할 수 없는 메일이나 그밖의 통신수단을 통해서 여러 타입의 컴퓨터 데이타를 주고 받을 수 있다.
MIME규약은 앞부분(header)에서 전송되는 메시지의 종류를
Content-Type이란 형태로 표시하도록 요구한다.
Content-Type은 major-type/minor-type [arguments]의
형태인데, major-type으로는 text, image, audio, video,
message, applicaition, multipart등이 될 수 있다.
minor-type은 major-type이 무엇이냐에 따라 달라진다.
예를 들어 JPEG 화일이라면 이 화일의 MIME content type은 image/jpeg가 된다.
GIF로 화일이라면, image/gif가 되며, .au화일이라면 audio/basic이 된다.
공식적인 MIME content type은 IANA(Internet Assigned Numbers Authority) 관리한다. 공식적인 MIME content type에 관한 정보는 ftp://ftp.isi.edu/in-notes/iana/assignments/media-types 이나, 가장 최근의 "ASSIGNED NUMBERS" 문서 (95년 현재 RFC-1700) 에서 구할 수 있다.
HTTP는 클라이언트와 서버간의 객체 전송시에 MIME 규약을 사용하도록 규정한다. 따라서, 클라이언트나 서버는 어떠한 데이타라도 주고 받을 수 있고, 또한 자신이 받은 객체가 어떤 형태인지를 알 수 있다. 클라이언트나 서버는 자신이 수신한 객체의 형태에 맞는 처리를 할 수 있다. 이것은 화일 이름의 확장자를 보고 그 화일의 형태를 파악하는 것과는 다른 방식이다.
<그림 2>를 보자. 서버 A에서 .doc화일이 의미하는 바는 일반 텍스트 화일이라고 하자. 서버 B에서 .doc화일은 Microsoft Word 6.0화일이라고 하자. 만약, 화일의 확장자 만으로 각 문서의 형태를 고려한다고 하면, 서버 A를 자주 이용하던 사람, 즉, 서버 A의 확장자에 맞추어서 사용하는 클라이언트는 서버 B를 연결했을때 전혀 엉뚱한 문자열 (MS word 6.0 format)을 볼 수 밖에 없다. 서버 B를 자주 사용하던 사람은 단순 텍스트 화일을 보기 위해서 MS Word를 가동시키게 된다.
그러나, 클라이언트와 서버간의 교환을 MIME규약으로 통일하고, 각 서버에서 .doc화일에 대해 Content-Type을 text/plain (단순 텍스트)과 application/x-ms-word6 (사용자 정의 응용프로그램)으로 지정하여 준다면 문제는 약간 달라진다. 먼저 서버 A의 .doc화일은 단순 텍스트라는 것을 어느 클라이언트에서든지 알 수 있으므로, 그에 맞는 viewer를 가동시킨다. 서버 B의 .doc화일을 읽은 적이 없는 클라이언트는, 서버 B의 MS Word화일을 읽게 될 때 application/x-ms-word6라는 새로운 MIME type에 대한 설정을 사용자에게 요구한다. 사용자는 application/x-ms-word6라는 MIME content type의 이름을 보고 MS Word 6.0화일 형태라는 것을 짐작하고 이 MIME content type에 대해서는 MS Word 6.0이 처리하도록 설정한다. 그러면, 차후 추가되는 다른 서버의 application/x-ms-word6문서에 대해서도 클라이언트는 자동으로 MS Word 6.0을 가동한다.
실제 서버 운영상에 있어서 화일 확장자와 MIME content type을 연결하기 위해서는 서버측의 configuration file을 고쳐주면 된다.
CERN 서버는 configuration file에 AddType directive를 사용하여 화일 확장자와 MIME content type을 연결할 수 있다.
NCSA 서버나 NetSite 서버의 경우에는 conf directory에 있는
mime.types 화일내용을 고침으로서 서버 전체에 대해서
화일 확장자와 MIME content type을 연결할 수도 있고,
.htaccess
화일에서
AddType
directive를 사용함으로써 어떤 directory안에서만 화일 확장자와 MIME
content type을 연결할 수도 있다.
Content negotiation이란 클라이언트와 서버가 서로 협의하여, 클라이언트 측에서 처리가능한 객체 형태, 부호화, 자연어등을 서버가 골라서 제공해 주는 것을 말한다.
HTTP의 Request header중에서 Accept, Accept-Encoding, Accept-Language 등을 추가하여 구현되었던 것으로, HTTP 1.0 초기 draft에 들어있었다가 HTTP 1.1로 연기되었다.
일반 MIME content의 negotiation 기능은 Apache Server이 지원할 계획으로 있다. 자연언어의 negotiation 기능은 CERN httpd와 NTT의 Mosaic-L10N이 지원한다.
먼저 각 httpd에 대해서 간단히 알아본다.
이 이후부터는 특징들을 나열하고, 그 특징이 가지는 의미와 실제 사용시 어떤 것들을 참조하여야 하는지를 이야기 하겠다.
- CERN httpd
- WWW의 원산인 CERN에서 Ari Luotonen, Henrik Frystyk, Tim Berners-Lee 등에 의해서 제작되었다. 기록에 의하면 1991년 6월 처음으로 version 0.1이 나왔다. Tim Berners-Lee의 WWW의 idea를 구현하는 것이 목적으로 만들어진 것으로 무엇보다도 HTTP의 기본 아이디어가 충실하게 구현되어 있다. 또한, WWW library function들을 이용하여 구성되었다.
- NCSA httpd
- Mosaic을 만들어서 유명해진 NCSA에서 개발한 것. Rob McCool이 주동이 되어 제작되었다. NCSA httpd의 목적은 CERN의 httpd보다 실리적으로 쓸만한 것을 만드는게 있었다. version 1.3까지는 httpd의 기억용량을 줄임으로써 주 메모리(RAM) 용량이 얼마 안되는 컴퓨터에서도 쓸 수 있도록 했으며, 1.4부터는 반응 속도를 빠르게하는데 치중하고 있다.
- Netsite Server
- Netscape으로 유명한 Netscape사의 httpd. 정식 명칭은 Netscape Communication Server와 Netscape Commerce Server. 일반 상용 서버들과는 달리 교육기관에서는 무료로 사용할 수 있다는 점과 Netscape 자체를 이용한 GUI 관리자 도구가 있다는 특징때문에 일반에게 널리 알려짐. 또한, Commerce Server의 경우 Netscape사의 browser인 Mozilla와 SSL(Secure socket Layer)을 통한 보안 채널 유지가 가능하기 때문에 인터넷 상점등에서 많이 사용하고 있다.
Server-side include란 서버내에 저장되어 있는 문서가 다른 문서를 포함할 수 있는 기능을 말한다. 다른 문서를 포함할 수 있도록 HTML을 변형한 것을 SHTML(Server-parsed HTML)이라고 한다. (SHTML의 문법및 사용방법등 자세한 사항은 NCSA httpd server side includes 를 참조하기 바란다.)
AddType text/x-server-parsed-html .shtmlProxy server란, <그림 3>과 같이 방화벽(firewall)으로 외부 네트워크와 차단이 되어있을 경우, 외부의 네트워크 서비스들을 대신 연결해서 그 결과를 넘겨주는 HTTP daemon을 말한다. Proxy server자신은 firewall의 내부 호스트와 외부 호스트 양쪽에 다 접속할 수 있어야 하므로 대체로 방화벽 호스트에 설치되는 것이 보통이다.
Proxy 서버는 대행 업무 이외의 목적으로 사용되기도 한다. 첫째로, proxy 서버 내에 cache를 설치하여 자주 요청되는 문서는 cache에 저장한다. 이렇게 함으로써 관리자의 입장에서는 외부 네트워크 사용양을 줄인다는 효과를 얻을 수 있으며, 사용자는 보다 빠른 서비스를 받을수 있다.
두번째의 목적은 Protocol gateway로서 사용되는 경우이다. WAIS의 경우 WAIS 프로토콜을 처리 할 수 있는 클라이언트도 있지만, 없는 클라이언트들도 많다. 만약 WAIS 프로토콜을 처리할 수 있는 proxy 서버가 있다면, WAIS를 처리 할 수 없는 클라이언트라도 WAIS에 대해서 proxy 서버 설정을 함으로서 마치 WAIS 프로토콜 해석기를 붙인것과 같은 효과를 낼 수 있다. (Proxy 클라이언트와 proxy 서버와는 HTTP로만 연결된다는 사실을 기억하자.) Proxy 서버에 대한 보다 자세한 내용은 World-Wide Web Proxies [Luotonen94b]를 참조하기 바란다.
Map file:* ftp:* Pass http:* Pass ftp:* Pass gopher:* Pass news:* Pass wais:* Caching On CacheRoot /root/proxy-cache CacheSize 200M NoCaching http://*.kr/* NoCaching http://*.kr:*/* NoCaching http://*.nuri.net/*
Server pool이란 서버 프로세스를 미리 몇개 만들어 놓고, 연결요구가 들어오는대로 대기하고 있는 서버 프로세스에게 일을 할당하는 방식이다. 이것은 연결요구가 들어올때 마다 (다음 연결요구를 기다리기 위해) 서버 프로세스를 새로 생성해 내는(fork) 단순 multi-server의 경우와 비교해 볼때, 서버를 새로 생성하는 시간을 줄임으로서 보다 빠른 반응 시간을 얻을 수 있다. <그림 4>에 이 두가지 방식을 비교하였다.
UNIX에서 fork는 상당히 시간걸리는 작업중에 하나이므로, server pool 구조는 연결요구가 많을 경우 상당한 성능 향상을 가져온다. 초당 처리할 수 있는 최대 연결요구 수를 실험적으로 얻기 위하여 HP735 워크스테이션에서 시험해본 결과, 약 2배정도 증가한다는 결과가 [McGrath95]에 실려있다.
특히, Netscape Mozilla와 같이 한꺼번에 다중 연결요구를 수행하는 browser들에게는 server pool 구조는 반응시간이라는 측면에서 효과적이다. 그러나, 연결요구가 없어도 일정갯수의 서버 프로세스가 대기하고 있어야 하기 때문에 process slot과 주기억장치 등을 항상 차지하고 있다는 단점이 있다.
StartServers 5 MaxServers 20
Custom error responses란 HTTP error(예: 404 Not Found)가 발생하는 경우 에러 메시지를 내지 않고 지정된 HTML문서 혹은 CGI script의 실행 결과를 전송하는 방법이다.
이 방법은 사용자로 하여금 서버의 결점을 보이지 않게 하거나 서버 에러에 쉽게 대처하게 할 경우 매우 유용하게 사용될 수 있다.
자세한 내용은 NCSA httpd 사용자 매뉴얼의 ErrorDocument 부분을 참조하기 바란다.
ErrorDocument 401 /errors/auth-required.html ErrorDocument 403 /errors/forbidden.html
전세계의 자료를 쉽게 살펴볼 수 있다는 WWW의 특성상 WWW browser는 여러 언어를 지원할 수 있어야 하며, Server의 경우에도 여러 언어를 지원할 필요가 있다. 현재 국제화(Internationalization;I18N)을 위한 작업이 진행중이다.
CERN server는 초기 HTTP 1.0 draft에 포함되어 있었던
Accept-Language: 헤더를 통한 자연언어 negotiation이
구현되어 있다. 자세한 내용은 CERN httpd User's Guide의
AddLanguage
directive에 관한 부분을 참조하기 바란다.
여기서 자연언어를 지정하는 방법은
ISO-639 Language Codes
와
ISO-3166 Country Codes
에 근거하고 있다. 자세한 내용은
RFC-1766 Tags for the Identification of Languages
를 참조하기 바란다.
NetSite의 경우에는 text/* MIME type의 charset argument를 통해서 현재 전달되는 문서가 어떤 코드로 부호화되어 있는지 알려주는 방식을 택하고 있다.
AddLanguage ko_KR .ko AddLanguage en .en
CERN httpd를 가져오기 전에 source를 새로 compile할 것인가, 아니면 그냥 간편하게 binary를 가져올 것인가를 결정해야 한다. 만약 httpd를 설치하고자 하는 host에 compiler가 없다면 binary를 가져와야 할 것이다. 그러나 compiler가 있고, 설치하는 사람이 compile에 자신이 있다면 원본을 가져와서 compile을 하는것이 좋다. 왜냐하면, dynamic linking library의 버젼문제와 같은 compile된 환경과의 차이를 줄일수 있으며, patch가 발표될 경우 patch를 입히기도 쉬울 뿐 아니라, 필요한 경우 httpd자체를 고칠 수도 있기 때문이다.
CERN httpd의 source프로그램 또는 binary의 원본은
ftp://ftp.w3.org/pub/httpd
에 있다. source는 httpd_3.0_src.tar.Z란 이름으로 저장되어 있으며,
binary는 http_3.0_bin.os_type.tar.Z의 이름으로 저장되어
있다.
외국에서 직접 가져오는 경우는 매우 느린 편이므로, 대체로 mirror site라는 데서
구하는 것이 보통이다.
KAIST나 대전 지역의 경우
ftp://ftp.kaist.ac.kr/pub/www/W3C/httpd
에서 구할 수 있다.
binary를 가져오는 경우 몇가지 주의할 사항이 있다.
무엇보다도 먼저, 설치하고자 하는 기계의 OS가 무엇인지 확실히알
필요가 있다. 절대로 추측해서는 안된다. 만약 확신할 수 없다면
uname -a라는 명령을 수행해 보기 바란다.
Sun의 경우에는 binary의 종류에 신경을 쓸 필요가 있다. 먼저 +lresolv라는 것이 붙어있는 경우인데, 이것은 hostname lookup시 name server를 사용하는 것으로, 자신의 host가 /etc/hosts화일에 저장되어 있는 호스트가 아니면 hostname으로 연결할 수 없을 경우 필히 이 binary를 설치하여야 한다. +wais라고 붙어있는 것은 WAIS proxy code가 추가되어 있는 것으로서, WAIS proxy를 운영하려 한다면 이 binary를 가져와야만 한다.
또한 htadm, cgiparse, htimage와 같은 프로그램을 사용하고자 한다면
http_utils_3.0_bin.os_type.tar.Z이란 화일도
같이 가져와야만 한다.
httpd_1.4.2_source.tar.Z로
binary는 httpd_1.4.2_os_type.tar.Z로
저장되어 있으며, CERN과는 다르게 별도로 가져와야 할 화일은 없다.
단, httpd만을 따로 가져오려 한다면 httpd_1.4.2_os_type.Z를 가져오면 된다.
NetSite는 Netscape Server Test Drive 페이지에서 자신의 신분을 밝혀주면, 시험용 code를 얻을 수 있다. 상업 기관에서는 60일간의 시험 사용이 허락되며, 교육기관의 경우 무료로 사용이 가능하다.
대부분의 화일은 tar.Z로 되어 있으므로 다음과 같이 풀 수 있다.
zcat httpd_3.0_src.tar.Z | tar xf -
컴파일의 방법은 간단하다. WWW directory로 들어가서 단지 ./BUILD라고 쳐 주면,
BUILD script는 해당 system의 OStype을 파악하여 그에 맞게 compile을 시작한다.
만약 제대로 compile이 안되는 경우
WWW/All/os_typeMakefile.include
를 살펴보고 현재 자신의 system에 맞게끔 고쳐주고 다시 BUILD를 수행한다.
만약 WAIS proxy를 계획하고 있다면 freewais를 구해서 같이 compile하여야 한다. freewais는 무료 WAIS 프로그램이다.
좀더 좋은 성능의 proxy server를 원한다면 Known Bugs in HTTPD 페이지를 참조하는 것이 좋다. 이곳에는 httpd의 오류 및 성능향상을 위한 patch들을 소개하고 있다. (최근에는 Netscape의 SSL용 proxy server로 만들기 위한 patch까지 나와 있다.)
이제 설치할 화일들이 모두 마련되었으면, 이 화일들을 어디에 둘 것인지 생각해 둘 필요가 있다.
httpd에 관련된 화일들을 여기저기 흩어놓으면 나중에 관리하기가 매우 귀챦아 지기 쉽다. 따라서, server configuration에서도 관련 화일들을 어떤 directory밑에 모아두는 것을 장려하는데, 그 장소를 Server Root라고 한다. Server Root는 UNIX directory구조상 특정한 장소아 아니며, 어떤 곳이라도 될 수 있다.
<그림 5> 에 일반적인 CERN httpd의 server root구조를 보였다. icons directory는 configuration file에는 나타나지 않지만 꼭 있어야만 하는 것으로, directory를 표시할때 사용되는 icon들의 집합소이다. conf는 예제 혹은 실제 configuration file의 저장소이다. (그러나 default configuration file은 /etc/httpd.conf이다.)
httpd와 관련된 실행화일들은 다음의 3종류로 나눌 수 있다.
따라서, CGI utility나 WWW server 본체등은 bin에, CGI program은 cgi-bin에 따로따로 보관하고, cgi-bin은 server script directory로 설정하는 것이 보통이다.
먼저, configuration화일을 어디다 놓을 것인지 결정한다. Default값은 /etc/httpd.conf이지만, httpd 시작할때 -r option으로 configuration file의 위치를 지정할 수 있기 때문이다. 위치를 결정했으면, 예제 configuration file들 중에 하나를 골라 결정된 위치에 복사해 놓는다.
이제 configuration화일의 내용을 고쳐보도록 하자.
맨 먼저 설정해야 할 것은 ServerRoot이다. 이것은 앞 절에서 이야기한 server root의 위치를 절대 path로 표시하는 것이다.
PortNumber는 httpd가 어떤 TCP port number를 사용할 것인지 정해 주는 부분이다. 흔히 URL을 적을때 host부분 뒤쪽에 콜론 다음에 적는 숫자 (예: http://camis.kaist.ac.kr:8080/에서 8080) 가 해당 httpd의 port number를 의미한다. 만약, 공식 WWW service를 한다고 하면 HTTP의 공식 port number인 80번을 사용한다. 그렇지 않은 경우 1024이후의 어떤 번호를 사용해도 상관 없다. 단, 80번을 사용할 경우 httpd는 root권한으로 실행되어야만 한다.
ServerType은 이 httpd가 StandAlone으로 수행될 것인지, Inetd를 통하여 수행될 것인지를 결정하는 것이다. (참고로, httpd 제작자들은 stand alone으로 수행하는 것을 권장하고 있다.) StandAlone이란 httpd 자체로서 해당 port의 모든 connection control을 하는 것을 말하고, inetd를 통하여 수행된다는 것은 Unix의 internet service daemon인 inetd의 제어에 따라 httpd가 수행되는것을 말한다.
실제 이용상에서 stand alone과 inetd의 차이는 다음과 같다. 먼저, stand alone으로 뜨게 되면 httpd가 최소한 하나는 꼭 떠 있어야만 한다. 그에 비해서, inetd를 통하여 뜨게 된다면 http 연결요구가 오기 전까지는 httpd가 실행되지 않는다. 또한, httpd가 configuration file을 읽는 시점은 수행이 처음 시작될때와 hangup signal (kill -1로 생성)을 받았을 때 뿐이므로, stand alone으로 띄운 경우 configuration file을 변경한 후 httpd에 hangup signal을 주어야만 configuration file의 변경 내용이 반영된다. 그에 비하여, inetd를 통하여 띄우게 되면 연결 요구가 들어올때마다 configuration file을 다시 읽으므로 configuration file의 변경이 즉각적으로 반영된다. 대신, httpd의 기동에 필요한 시간, configuration file을 읽는 시간등이 있으므로 inetd를 통하는 쪽이 stand alone쪽 보다 반응시간이 매우 느린 편이다.
AccessLog, ErrorLog, ProxyLog등은 해당 log들을 저장해 놓는 장소를 지정한다. Server root의 상대 path로 지정할 수 있다.
실제 Unix filesystem의 directory와 URL의 path는 같을 필요가 없다. URL의 path를 Unix의 file system에 맞춰주는 것으로는 Pass, Fail, Map, Exec등의 directive들이 있다. 이것들은 다음과 같은 형식을 따른다.
Pass template [result]
Fail template
Map template result
Exec template script
Map이란 어떤 file을 어떤 URL로 접근할 수 있다는 의미이다. Pass란 어떤 URL을 httpd가 외부로 공개해도 좋다는 의미이다. Fail이란 어떤 URL은 httpd가 외부로 공개해서는 안된다는 의미이다. Exec란 어떤 URL로 지정된 화일들은 문서로 보지 말고 실행 가능한 script로 보라는 의미로, 이 화일들은 다른 화일들과 달리 인출되지 않고 실행된다. 주위할 점은 이 directive들은 쓰여진 순서대로 검색되므로, 순서가 어떻게 되어 있느냐에 따라 결과가 달라질 수 있다는 것이다.
<그림 6>에 예제 configuration file의 일부와 unix directory 구조를 나타내었다. 이 경우 /man/ttt.txt라는 URL은 /w3-data/man/ttt.txt가 되지 않고 /www/man/ttt.txt가 되는 점에 주의하라. 또한 /w3-data/docs/private 이하 화일들은 외부에서 접근할 수 없다는 점도 기억해 둘 만 하다. 만약 Fail directive가 맨 마지막 줄에 있다면 private directory는 외부로 공개된다는 점도 주의하라.
보안상의 이유로나 다른 이유로, WWW service의 어떤 부분은 아무에게나 보여주고 싶지 않은 경우가 있다. 이런 경우 사용할 수 있는것이 httpd의 사용제한(access control)기능이다.
현재 CERN httpd는 client의 주소에 의한 제한방법과, username과 passwd를 받아서 허락된 사용자만 받아들이는 두가지 사용 제한 방법이 있다. 두가지 경우 다 Protection, Protect등의 directive를 사용한다.
Protection PROT-NAME {
UserId server user id
GroupId server group id
AuthType Basic
ServerId server string whatever you want
PasswordFile path to password file
GroupFile path to group file
GetMask allowed user, group or @host
}
Protect URL PROT-NAME
자세한 것은 How to setup protected CERN server 를 참조하기 바란다.
별도로 사용자를 관리하는 경우에는 password file과 group file을 관리하여야 한다. password file과 group file의 형식은 다음과 같다.
여기서 item은 username이 될수도 있고 group이름도 될 수 있으며, hostname 혹은 IP address도 될 수 있다. 단, hostname이나 IP address의 경우에는 앞에 @가 붙는다. 만약, 어떤 호스트의 누구로 제한하고 싶다면 username@host형태로 적으면 된다.Password format: username:password(encrypted):realname Group format: groupname:item,item,item,...
Password file을 관리하기 위해서 CERN server에는 htadm이라는 프로그램을 제공한다.
자세한 것은 htadm manual page 를 참조하기 바란다.
httpd를 띄우는 방법에는 두가지 방법이 존재한다. Stand alone으로 띄우는 방법과 inetd가 관리하는 하나의 daemon으로써 띄우는 방법이다. (ServerType 참조)
Stand alone으로 띄우고자 한다면, 단지
httpd -r conf_file_path라고 실행해 주면 된다.
만약, 항상 httpd가 떠 있기를 바란다면, BSD의 경우에는 /etc/rc.local에
위의 한 줄을 추가해 주면 되며, System V인 경우에는 /etc/rc3.d directory에
S90locald라는 이름으로 화일을 하나 만들어서 위의 명령을 넣어주면 된다.
Inetd로 띄우는 경우에는 먼저, /etc/services에 httpd 80/tcp
라는 한줄을 추가한다. 다음 /etc/inetd.conf화일에 다음 한줄을 추가한다.
(주의: /etc/services의 경우, 만약 NIS를 돌리고 있다면 NIS source화일을 고쳐야만 하며, 다 고친 후에는 고친 정보가 ypmake등을 통하여 해당 호스트에 전달 되어야 한다.)http stream tcp nowait nobody httpd_path httpd_command
그리고 나서 inetd 에게 kill -1 로 hangup signal을 주면, 그때부터 HTTP연결요구가 올 때마다 httpd가 작동한다. 이 경우에는 항상 떠 있도록 별도로 해야 할 일이 없다.
Stand alone으로 떠 있는 경우에는 terminate signal (kill -15)로 httpd의 동작을 중단시킬 수 있다. 만약, configuration file을 변경하고 변경된 내용을 적용시키고자 한다면 hangup signal (kill -1)을 준다. 이렇게 하면 httpd를 중단시키지 않고 configuration file을 다시 읽도록 할 수 있다.
Inetd로 떠 있는 경우에는, HTTP연결요구가 들어오면 httpd를 띄우고 처리해야 될 내용이 끝나면 httpd가 끝나는 형태이므로, /etc/inetd.conf 를 원래대로 바꿔놓지 않는 한 httpd가 뜨는 것을 막을 수 없다.
여러 사람이 사용하는 호스트에 httpd를 설치하게 되면, 사용자들이 자신의 홈페이지를 갖고 싶어하는 것은 당연한 것이다. 그렇다면, 관리자의 입장에서 어떻게 사용자의 요구도 충족시킬 수 있을 것인가?
홈페이지를 갖고 싶어하는 사용자가 몇 안된다면, 그 사람들의 directory를 httpd configuration에 포함시킴으로써 사용자들이 자신의 페이지를 쓸수 있게끔 하는 것도 한가지 방법이다. 그러나, 만약 사용자가 100명이 넘어간다면 어떻게 할 것인가?
CERN httpd의 경우 UserDir public_html라는 한 줄을 configuration
file에 추가해 주면 쉽게 해결된다.
각 사용자의 home directory밑에 public_html이란
directory가 /~login_name이란 형태로,
외부로부터 httpd를 통해서 접근이 가능해 지기 때문이다.
사용자들이 CGI까지 사용하게 해 달라고 요구한다면 어떻게 해야하는가? /cgi-bin에 해당하는 directory를 아무나 쓸 수 있도록 열어주어야 하는가? (절대로 그래서는 안된다!)
이럴 경우 cgiwrap 을 설치하여 사용하도록 하는 것이 좋다. cgiwrap은 CGI program이 사용자의 권한에서만 돌아가도록 제한할 뿐 아니라, 사용자의 CGI가 언제 어떻게 실행되었는가를 기록하기도 한다.
자세한 내용은 cgiwrap 페이지를 참조하기 바란다.
httpd가 생성하는 화일중에 access log라는 화일이 있다. 이것은 해당 httpd에 접속했던 host, 시각, 가져간 문서, 접속 결과등이 기록된 화일로, 인기있는 WWW server일수록 눈덩이 처럼 불어난다.
얼핏보기에는 쓸모없는 이 화일을 유용하게 활용할 수 있다. getstats 라는 프로그램을 사용하면 access log를 읽어서 여러가지로 분석을 해 준다. 어느 호스트 또는 도메인에서 접속을 많이 했는지, 하루 중, 한주일 중 또는 한달중 언제 접속요구를 많이 하는지, 가장 인기있는 문서는 무엇인지, 언제 httpd가 대답을 잘 못해줬는지등을 option을 바꿔가면서 또는 전부 분석 할 수 있다. 또한 분석을 통하여 httpd의 configuration을 바꾸어 볼 것을 고려할 수 있다.
만약 출력을 그래프 형태로 보고 싶다면 getgraph.pl 을 설치하여 사용하면 된다. 그러나, 이것은 perl, gnuplot, pbmplus, giftrans등의 다른 공개 프로그램을 설치하여야만 한다. 단지 사용량만을 그래프로 보고자 한다면, wusage를 사용하는 것도 좋다.
다른 log 분석 도구에 관심이 있다면 HTTPD Log Analyzers 페이지를 참조하기 바란다.
CGI는 httpd가 실려있는 host에서 프로그램을 실행할 수 있다는 점에서 요주의 대상이다. 그 프로그램이라는 것이 단순한 장난 프로그램인지, host의 passwd나 기밀 문서를 가져가는 프로그램인지, 아니면 호스트를 몽땅 지워버리는 프로그램인지 알 길이 없기 때문이다.
이런 의미에서 CGI 프로그램이 저장되어 있는 directory는 다른 사람들이 프로그램을 함부로 추가하거나 바꿔칠 수 없도록 신경을 써야 한다. 사용자들이 CGI를 사용하게끔 한다면, 그 프로그램이 사용자의 권한으로만 작동하도록 신경써야 한다.
더우기 UserDir directive로 사용자 디렉토리를 설정했을 경우에는, 이상한 사용작 추가되지 않는가 유심히 살펴 볼 필요가 있다.
NCSA httpd나 NetSite에서 제공하는 Server side include기능에는 CGI 기능이 포함되어 있다. 이것 역시 신경써야 할 대상이다. Server side include에 CGI기능이 필요하지 않다면, access.conf화일에서 IncludeNOEXEC를 지정함으로써 include시 CGI실행을 제한하는 것이 좋다.
얼마전에 NCSA httpd 1.3을 통해서 httpd가 설치되어 있는 호스트의 권한을 따 낼수 있다는 사실이 알려져서 화제가 된적이 있다. 지금은 그 오류가 제거되었지만, 사실, 다른 어떤 오류가 숨어있을지 알 수 없다.
특히 port number 80번의 정식 server를 운영하려면 root가 httpd를 돌릴 수 밖에 없다. 만약 이 호스트의 httpd를 통해서 권한을 따 낼 수 있다면, root권한을 뺏긴다는 것을 의미한다.
이와 비슷한 문제가 여러 경우에 발생했기 때문에 Unix에서는 chroot라는 command를 제공하고 있다. chroot란, change root directory의 약자로서, 글자 그대로 다른 directory를 root directory라고 인식하게 만드는 command이다.
예를 들어 chroot /www-stuff httpd와 같은 형태로
httpd를 실행하였다면, httpd와 httpd가 만들어내는 모든 process는
/www-stuff directory를 root directory로 인식한다.
다시 말하면, httpd와 그의 child process들은 /www-stuff밑의 화일
이외에는 절대로 건드릴 수가 없는 것이다.
<그림 7>을 보자. chroot /www-stuff httpd라는 명령으로
httpd를 띄운 경우 httpd 및 그의 child process들은 표시한 영역을 전체
화일시스템이라고 인식한다. 따라서, httpd를 통해서 크래커가 root권한을
얻었다 하더라도, 크래커는 /usr, /etc, /home directory는 전혀 건드릴 수가
없다.
대신 모든 configuration은 새로운 root directory (여기서는 /www-stuff)를 root라고 생각하고 다시 쓰여져야만 한다. 사용자를 위한 쪽을 지원하려면 새로운 directory 밑에 etc디렉토리와 가짜 passd화일을 만들고, 가짜 user directory를 만들어야 한다. symbolic link 역시 새로운 root directory를 root로 생각하고 만들어 져야 한다.
그러나, chroot로 httpd를 띄운다면 한가지는 확실해 진다. 혹시 httpd로 크래커가 들어온다 하더라도 그가 지울수 있는것은 httpd 와 HTML문서들 뿐이다.
이 문서는 앞으로의 변화에 따라 계속 발전할 예정이다. http://camis.kaist.ac.kr/~jwjung/seminar/httpd-comp-inst/ 에서 최근의 문서를 찾아 볼 수 있다. 이 문서에 대한 comment는 언제든지 환영하며 jwjung@camis.kaist.ac.kr로 보내면 된다.