지난 달의 무거운 주제를 벗어나 이 번호에는 다시 윈도우 사용자, 회사에 리눅스를 이용해서 서버를 구성하려고 하는 사람들을 대상으로 웹서버를 설정하는 법에 대해서 알아보기로 하자. 필자에게 메일로 문의를 하는 사람들이 많은데 대체적으로 질문의 내용이 전혀 예상하지 못했던 것이 많았다. 나름대로 윈도우를 사용하듯이 리눅스를 쓸 수 있도록 하자는 목적으로 쉽고 쓸려고 노력했지만 여전히 독자들은 어려움을 느끼고 있다는 생각을 했다. 윈도우 사용자에게 친숙할 것이라고 생각했던 그래픽 방식의 제어 툴인 웹민의 설명들이 영어로 되어 있고 옵션들이 각기 다른 페이지에 있어서 생각만큼 쉽지 않은 것이다. 웹민은 리눅스 관리에 어느 정도 익숙하여 무엇을 해야 할 지 아는 사용자들이 편하게 작업할 수 있는 환경이라는 판단이다. 윈도우만 쓰던 사람들은 웹민을 이용해서도 제대로 작업하지 못하는 경우가 많았다. 그러므로 가능하면 리눅스 내부적인 동작에 대해서 설명을 주로하고자 한다. 또한 글의 내용도 리눅스에 전혀 경험이 없는 윈도우 사용자들의 눈높이에 맞추기 위해서 노력하겠다.
웹서버를 구성하기 위해서는 NT가 필요하다. 윈도우98은 개인용 운영체계로 웹서비스를 하기에는 부적합하다. 물론 억지로 할 수는 있지만 전혀 권할만한 것이 아니다. 생각을 윈도우 사용자에 맞추어 보면 이들이 새롭게 NT를 설정하여 웹서버 세팅까지 해내는 것이 쉬운 일만은 아니라고 생각된다. 여태까지 연재한 글을 참고하여 웹민을 이용해 삼바와 메일서버를 세팅할 수 있었다면 내친 김에 리눅스에서 아파치를 설정하는 것이 편할 수도 있다. 리눅스의 킬링 소프트웨어인 아파치 웹서버를 설정, 관리하는 방법을 자세하게 알아보도록 하자.
웹서버 프로그램을 돌리기 위한 HTTP 프로토콜은 사실 매우 단순하다. 그 때문에 많은 웹서버 프로그램이 존재한다. 상용제품도 있고 무료제품도 있으며, 무료일 뿐만 아니라 소스까지 제공하는 것도 있다. 또한 perl, tcl같은 스크립트 언어를 사용한 것도 있다. 대표적으로 웹민은 perl로 만든 특별한 작업을 위한 웹서버이다. 그 중에서 인터넷에서 지배적으로 사용되고 있는 것은 아파치와 MS의 IIS이다. MS의 IIS는 NT의 쓰레드 기능 위에서 동작하므로 빠른 속도를 자랑한다. MS에서 제공하는 여러 프로그램을 이용해 쉽게 기능을 확장할 수 있고 윈도우 운영체계에 내장된 기능을 활용할 수 있다. 그리고 ISAPI를 사용한 asp 스크립트 방식은 그 어떤 웹서버보다 빠른 성능을 보인다.
그러나 NT의 쓰레드기능은 치명적인 문제를 가지고 있다. 대부분의 자원을 쓰레드끼리 공유하면서 동작하는 방식을 쓰기 때문에 여러개의 쓰레드 중에서 한개가 에라를 발생시키면 모든 쓰레드에 이 에라가 파급된다. 리눅스(유닉스)의 프로세스 모델에서 돌아가는 아파치는 자식 프로세스를 따로 두고 이들이 독립적으로 접속을 처리하며 한 개의 프로세스가 치명적인 에라를 발생시켜도 그 프로세스만 죽을 뿐 에라가 다른 접속을 처리하는 프로세스에게 전파되지 않는다. 속도와 안정성의 균형이 중요한데 필자가 일하는 회사의 개발자 의견은 웹데몬같이 무작위 접속이 가능한 소프트웨어는 쓰레드 모델이 부적당하다는 결론이었다. 실제로 잘못된 asp가 웹서버 전체를 죽일 수 있으며 심각한 경우에는 NT자체가 정지하는 경우가 많았다. 또한 이런 에라는 꼭 새벽에 관리자가 없을 때 발생해서 아침까지 서비스를 할 수 없게 만든다. 속도와 안정성 사이에서 독자들의 현명한 판단을 바란다.
삼바로 리눅스의 웹서버 루트 디렉토리를 윈도우 박스에 연결해 놓으면 리눅스에서의 작업은 전혀 필요 없다. 리눅스 박스에 있는 파일을 윈도우에서 에디팅한 후에 저장하고 바로 웹검색 프로그램으로 그 결과를 볼 수 있다. 가상호스팅등을 사용하지 않는다면 아파치 설정 자체를 고칠 필요도 없다. 오로지 웹페이지 만들기에만 집중해도 된다.
메일서버와 마찬가지로 웹서버도 많은 히트수를 기록하게 되면 로그 파일이 커질 것이다. 로그 파일이 커지면 로그를 적는데 시스템 자원을 소모해야 한다고 지난 달에 말한 바 있다. 이 파일을 줄이기 위해서 "rm access_log"라고 해도 아파치의 자원 사용량은 줄지 않는데 그 이유는 리눅스(유닉스)의 특성 때문이다. 리눅스의 파일은 inode로 관리되는데 하드디스크 디렉토리 항목에 할당된 이름(ls 했을 때 나오는 파일명)에 참조계수가 할당되듯이 파일을 열 때에도 할당된다. 즉 같은 inode에 대해서 참조계수값이 2일 때 한쪽을 없앤다고 해서 물리적인 파일이 사라지지는 않음을 뜻한다. /var/log/httpd 디렉토리의 access_log를 제거했을 때 더 이상 access_log를 검색할 수는 없지만 아파치가 떠있는 동안은 이름없는 같은 파일이 물리적으로 존재하고 있으며 아파치는 그 파일의 뒷부분에 계속 로그를 덧붙이고 있는 상태가 된다. 이를 해결하려면 아파치가 열고 있는 파일을 닫고 같은 이름의 파일을 다시 열도록 해야 하는데 그 방법은 아파치를 재시작 하거나 다음 명령을 내리면 된다.
# rm access_log # killall -HUP httpd
또는
# mv access_log access_log.old # killall -HUP httpd
HUP 시그널을 받은 아파치는 모든 파일을 닫은 후에 다시 열게 된다. access_log를 닫는 순간 참조계수가 0이 되고 파일 시스템에서 이 파일이 사라진 후에 아파치가 다시 access_log를 생성하게 된다. 이제 파일 크기가 0이 되면서 자원 사용량이 줄어들게 된다. 이 설명이 어려우면 이글의 뒷부분을 참조하기 바란다.
사실 리눅스 배포본을 제대로 인스톨 했다면 아무 것도 할 것이 없다. 설치 과정에서 apache 패키지를 선택했다면 이미 웹서버가 동작중이다. 리눅스 서버의 아이피가 1.2.3.4라면 http://1.2.3.4 라고 쳐보기 바란다. 아마 "It's Worked"라는 문구와 아파치의 심볼인 가벼운 새의 깃털을 볼 수 있을 것이다. 여러분의 리눅스 서버에는 이미 웹서버가 설치되어 있고 제대로 동작하고 있다는 것을 보여주는 것이다. 만약 에라가 뜬다면 아파치를 인스톨하면 된다.
리눅스 시디롬을 마운트 한다.(시디롬이 세컨더리 마스타에 붙어 있다고 가정)
# mount /dev/hdc /mnt
아파치 패키지를 인스톨 한다.
# rpm -i /mnt/RedHat/RPMS/apache-1.3.4-1kr.i386.rpm
아파치를 기동시킨다
# /etc/rc.d/init.d/httpd start
이제 http://1.2.3.4 라고 치면 첫페이지를 볼 수 있을 것이다.
아파치가 인스톨되면 실행파일은 /etc/rc.d/init.d/httpd인데 이 것은 시스템이 부팅되면서 아파치를 띄우고 시스템을 끄면 죽이는 동작을 한다. 홈페이지는 /home/httpd/html 이며 http://1.2.3.4로 보이는 파일은 /home/httpd/html/index.html이다. cgi를 실행시킬 수 있는 디렉토리는 /home/httpd/cgi-bin이며 아파치 메뉴얼은 index.html에서 찾아 들어갈 수 있고 그 디렉토리는 /home/httpd/html/manual이다. 기본적으로 제공되는 아이콘은 /home/httpd/icons에 있다. 아파치 실행파일은 /usr/sbin/httpd이다. 그외 로그 파일의 크기를 조절할 수 있는 실행파일과 설정파일등이 있는데 완전한 목록을 보고 싶으면 아래와 같이 실행해 보기 바란다.
# rpm -qpl /mnt/RedHat/RPMS/apache-1.3.4-1kr.i386.rpm
앞으로 주로 고치게 될 파일은 /etc/httpd/conf/httpd.conf이다. /etc/httpd/conf 아래에는 srm.conf, access.conf도 있는데 1.3.x버전으로 오면서 httpd.conf에 통합되었고 쓰지 않는다. mime.typs, magic은 각종 파일을 처리하는데 필요한 파일 속성 정보가 담겨 있고 손댈 필요는 전혀 없다. 앞에서 말한 아파치 디폴트 디렉토리 설정은 httpd.conf에 있고 원하는 경우 이 파일을 고쳐서 재설정할 수 있다. 독자들이 파악해야 할 것은 httpd.conf와 이 파일에 적힌 디폴트 디렉토리 정보에 대한 것이다. 그외는 아파치를 재컴파일 하거나 독립적인 모듈을 추가할 것이 아니라면 전혀 신경쓸 필요가 없다.
리눅스의 웹서버 홈디렉토리의 파일들을 윈도우에서 편집하고 싶으면 삼바 설정을 고쳐서 윈도우에서 이 디렉토리를 볼 수 있게 하면 된다. /etc/smb.conf 설정에 다음을 추가하자.
[html]
comment = webserver
path = /home/httpd/
force user = kkyc
force group = kkyc
create mask = 0755
read only = No
guest ok = Yes
force user와 force group은 필자의 웹서버를 주로 작업하는 사용자명이다. 이렇게 해 놓으면 어떤 사람이 편집하더라도 파일의 소유권이 kkyc에게 있으므로 지우기, 변경이 용이하다. 여러분의 사이트에 주로 편집하는 사용자명으로 바꾸던지 아니면 아예 이 항목을 제거해도 된다. create mask 값은 웹파일에 모든 사용자들이 읽기 권한을 주도록 하기 위해서 쓴다. 삼바의 설정을 변경했다면 삼바를 다시 시작해야 적용이 된다.
# /etc/rc.d/init.d/smb stop # /etc/rc.d/init.d/smb start
화면 1은 서버의 /home/httpd 디렉토리를 윈도우 드라이브 I:에 매핑시키고 그 아래 /home/httpd/html 파일을 열고 있는 모습니다. index.html은 확장자가 html이므로 넷스케입 아이콘이 나타났다. 그 위에는 엑스메니저로 한텀을 열고 같은 디렉토리를 본 모습이며, 왼쪽 위에는 윈도우의 넷스케입으로 index.html을 연 모습이다. 나모 웹에디터(책을 샀을 때 준 한정 사용판, 필자는 윈도우 프로그램을 사용하지 않기 때문에 이 화면을 위해서 잠시 인스톨 했다)에서 같은 파일을 에디팅 하기 위해서 열어 놓은 모습이다.
삼바로 리눅스 웹서버 홈 디렉토리를 디스크로 매핑시키면 윈도우에서 작업하는 것과 다를 바 없다. 이 화면은 윈도우에서 리눅스 웹페이지 작성을 하는 방법의 모든 것을 한꺼번에 보여 주고 있다. 리눅스 웹페이지 작성법에 관해서 이 화면보다 더 직관적이고 쉽게 보여줄 수 있는 방법이 없다. 이 화면을 이해할 수 있다면 여러분도 웹페이지 작성에 나설 수 있을 것이다.
주의할 점은 리눅스에서는 파일명의 대소문자를 엄격하게 구별한다는 것과 윈도우에서 파일확장자를 자체적으로 관리하는 바람에 확장자가 겹칠 수 있다는 것이다. 그래서 웹페이지에 back.jpg를 읽어 오도록 링크를 적었지만 실제 저장은 back.JPG로 되어 있거나 back.jpg.JPG로 되어 있을 수 있다. 웹페이지에 적은 대로 화면이 나타나지 않으면 이런 이유때문이므로 한텀을 열어 놓고 실제 저장된 파일명을 확인하는 것이 좋을 것이다. 그리고 덧붙여 말하자면 윈도우에서 편집하다보면 헷갈려서 편집한 파일을 리눅스에 가져다 놓지도 않고 링크가 되지 않는다고 고민하는 경우도 있다. 웹서버로 확인할 파일은 리눅스에 옭겨 놓았는지 꼭 확인하도록 하자.
사용자들이 하루에 100명 미만으로 방문하는 사이트라면 여기까지 읽고 웹페이지 제작을 쉽게 해주는 나모 웹에디터 같은 윈도우 프로그램을 구해서 작업을 하면 된다. 거의 대부분의 사이트가 여기에 해당될 것인데 리눅스 박스를 잘못 다루지만 않는 다면 여기까지 읽는 것으로 아파치 웹서버 만들기는 끝났다고 할 수 있다. 이 처럼 리눅스를 웹서버로 사용하는 것은 쉬운 일이다. 이후의 글이 도움이 되기는 하겠지만 리눅스 작업이 필요하므로 원하는 사람만 읽기 바란다.
아파치는 수많은 옵션이 있으며, 아파치를 지원하는 수많은 모듈이 있다. 배포본의 기본 설치로도 일반적인 사용에 전혀 문제가 없지만 히트수가 증가하거나 한개의 서버로 여러 사이트를 서비스하거나 각 부서별로 각각의 페이지를 열고자 할 때, 그리고 방명록, 게시판같은 CGI를 붙여야 하거나 여태까지 잘 돌던 서버가 이상한 동작을 보일 때, 설정파일에 관심을 가져야 한다. 건강한 사람을 보고만 있으면 병들었을 때 대책이 없게 된다. 기본원리에 대해서 파악을 해 놓고 동작방식을 이해한 후에 비정상적인 상황을 고쳐가면서 관리를 해야 웹서버가 이상동작을 할 때 빠른 시간에 문제를 해결할 수 있을 것이다. 그러므로 앞으로의 내용은 소규모로 운영하며 제대로 동작하는 동안에는 전혀 필요가 없지만 꼭 관심을 가지고 읽어 보아야 할 내용이라고 생각된다.
아파치가 유명해지면서 여러 그래픽 설정 툴이 나오고 있다. 텍스트 방식의 아파치 설정 파일을 들여다 보는 것 보다는 그래픽 방식이 좀 더 직관적이고 각 옵션간의 연관관계를 쉽게 파악할 수 있으므로 필자는 가능하면 이런 툴이 많이 나오고 사용자들도 적극적으로 사용하기를 권하는 편이다. 그 중에는 오픈소스도 있고 상용 버전도 있다. 패키지 배포본에 주로 포함되는 것은 comanche(COnfiguration MANager for apaCHE)인데 재미있는 이름만큼이나 설정도 쉬운 편이다. 물론 이전 연재에서 설명했던 웹민또한 훌륭한 그래픽 설정툴이다. 코만치는 엑스윈도우 프로그램이므로 엑스메니저에서 실행해야 한다. 웹민은 물론 http://my.host.com:1000/(혹은 바꾼 웹민의 포트)로 접근할 수 있다. 그래픽 설정툴에 사용법에 대한 설명은 지난호까지 지루하게 했으므로 다시 반복하지 않는다. 앞으로 설명하는 설정 방법도 텍스트 방식의 설정법을 참고하여 웹민이나 코만치에서 찾아서 하기 바란다. 그래픽 방식의 작업 결과가 저장되는 파일을 이 글의 내용과 비교하여 차이가 없도록 하면 된다.
아파치의 설정은 대부분 /etc/httpd/conf/httpd.conf에서 하게 된다. 우선 기본 설정에 대해서 알아보자. 각 설정은 httpd.conf 파일안에서 흩어져 있기 때문에 전체적으로 파악하기가 힘든데 대부분은 디폴트 값을 그대로 사용하면 된다. 관리자가 알아야 주요한 것은 다음과 같다. 아래 설명을 보고 원하는 값으로 바꾸기 바란다. 참고로 한국에서 유명한 리눅스 배포본인 알짜 5.2a에서는 이 파일의 설명 부분을 직접 한글로 번역해 두었으므로 참고해도 좋다.
ServerName www.mycompany.com ServerAlias www.mycompan.com *.mycompany.com ServerAdmin root@mycompany.com
서버이름을 정하고 ServerAlias에서 위와 같이 써 줌으로써 http://mycompany.com, http://dev1.mycompany.com으로 접속하더라도 디폴트로 www.mycompany.com이 뜨게 된다. 이 사이트의 관리자는 위에서 적어준 사용자가 된다.
Listen 192.168.1.4:80 Listen 192.168.1.4:443
http 프로토콜이 기본적으로 사용하는 TCP/IP 포트는 80번이며 아파치가 이 포트를 사용할 수 있도록 Listen 설정을 해 준다. 443는 SSL인 https 방식에서 사용하는 포트이다. 만약 여러개의 IP를 한 개의 서버에 할당하고 가상호스팅을 한다면 각각의 IP에 대해 Listen값을 적어 주어야 한다.
ErrorLog /var/log/httpd/error_log CustomLog /var/log/httpd/access_log common CustomLog /var/log/httpd/agent_log agent
각종 로그 파일 설정을 해 준다. /var/log/httpd 디렉토리가 없다면 만들어야 한다. 문제가 생겼을 때 이유를 적는 error_log, 정상적인 웹검색에 대한 기록을 하는 access_log, 어떤 웹검색 프로그램으로 접속했는지 알려 주는 agent_log가 있다. 그외에 여러 로그파일을 따로 만들 수 있지만 지금은 이런 부분에 신경을 쓰지 않아도 좋다. 리눅스(유닉스) 프로그램들은 어떤 문제가 발생하면 그 원인에 대해서 항상 자세한 내용을 적도록 되어 있다. 여태까지 윈도우의 무의미한 에라 메세지에 익숙한 사용자들은 이 것을 무시하는 경향이 있는데 리눅스에서는 통용될 수 없다. "/var/log/"아래의 여러 파일(messages, secure, lastlog, dmesg)에 관심을 가져야 제대로된 관리자가 될 수 있다. 에라 메세지가 정확하기 때문에 어떤 대책을 세워야 하는지 쉽게 알 수 있다.
httpd: [xxx xxx xx xx:xx:xx 1999] [error] [client xxx.xxx.xxx.27] File does not exist: /xxx/xxx/xxx/www/frame_visnote.htm
예를 들어 위와 같은 에라가 error_log에 있다면 해당 파일(frame_visnote.htm)이 있는지 확인하고 이 파일을 링크하고 있는 html 파일을 고치면 된다. 이런 단순한 작업뿐만 아니라 웹서버가 뜨지 않는 에라나 CGI가 실행되지 않을 때도 항상 error_log 파일을 조사해보는 것이 가장 빠른 문제 해결 방법이 된다.
User nobody Group nobody
아파치는 보안을 위해서 root로 실행된 다음 사용자 권한을 강제로 User와 Group에 적어준 사용자로 바꾼다. 때문에 웹으로 접속해서 해킹을 하더라도 시스템 파일을 건들수 없도록 해 놓았다. 만약 서버에 nobody 사용자가 없다면 에라가 생길 것이다. 다음과 같이 사용자를 추가할 수 있다.
# adduser nobody # passwd nobody
웹서버가 시스템의 일반 사용자 모드로 동작하므로 웹서버의 루트 디렉토리(DocumentRoot)부터 아래의 모든 디렉토리와 파일은 소유자, 그룹, 기타 사용자가 모두 읽을 수 있어야 한다. /home 디렉토리에서 다음과 같이 실행하면 될 것이다.
/home# chmod 755 -R httpd
DocumentRoot "/home/httpd/html"
<Directory "/home/httpd/html">
Options Indexes FollowSymLinks
AllowOverride None
Order allow,deny
Allow from all
</Directory>
이제 웹서버 루트 디렉토리에 대한 설정이다. 이 설정으로 http://www.mycompany.com으로 접속하는 모든 사용자는 /home/httpd/html/index.html을 가장 먼저 보게 되는 것이다. Direcotry 옵션 설정에 나오는 값은 기본값 그대로 사용하면 된다. 각각의 설정에 대한 설명은 다음 기회로 미루기로 하자.
<Directory "/home/httpd/cgi-bin">
AllowOverride None
Options ExecCGI
Order allow,deny
Allow from all
</Directory>
http://www.mycompany.com/cgi-bin/my.cgi 로 실행했을 때 /home/httpd/cgi-bin/my.cgi가 리눅스에서 실행되어 그 결과가 사용자로 전송된다. 즉 my.cgi는 perl같은 스크립트 파일이거나 리눅스용 실행파일이라는 뜻이다. 아파치에서는 각 디렉토리 별로 실행파일을 동작시킬 수 있는지 여부를 지정할 수 있다. "Options" 항목의 ExecCGI 설정이 이 일을 하는데 기본적으로 아파치는 모든 디렉토리에 대해서 파일 실행권을 주지 않는다. 이 설정에 의해서 /home/httpd/cgi-bin에 있는 파일들이 실행될 수 있는 것이다. 참고로 이 디렉토리에 들어 있는 파일은 실행가능모드로 되어 있어야 한다. 필요하면 다음과 같이 하면 된다.
/home/httpd/cgi-bin# chmod a+rx my.cgi
Alias /icons/ "/home/httpd/icons/"
<Directory "/home/httpd/icons">
Options Indexes MultiViews
AllowOverride None
Order allow,deny
Allow from all
</Directory>
웹페이지에서 그림파일을 링크할 때 http://mycompay.com/icons/button.jpg라고 하면 위의 설정에 의해서 /home/httpd/icons/button.jpg가 불려진다. 지금은 가상 디렉토리 설정과 실제 디렉토리 설정이 같으므로 별로 유용할 것같지 않지만 아이콘이 있는 디렉토리가 /usr/lib/icons에 있다면 "Alias /icons/ "/usr/lib/icons/""으로 설정하고 http://mycompayn.com/icons/button.jpg라고 치면 /usr/lib/icons/button.jpg를 불러 올 수 있다. 이 기능은 아이콘에만 해당하는 것은 아니고 모든 물리적 디렉토리를 이런 식으로 매핑하여 사용할 수 있으므로 여러 용도로 사용하기 때문에 쉽게 옮길 수 없는 디렉토리가 있다면 이 방식을 쓸 수 있다.
UserDir public_html
<Directory /*/public_html>
AllowOverride FileInfo AuthConfig Limit
Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
<Limit GET POST OPTIONS PROPFIND>
Order allow,deny
Allow from all
</Limit>
<Limit PUT DELETE PATCH PROPPATCH MKCOL COPY MOVE LOCK UNLOCK>
Order deny,allow
Deny from all
</Limit>
</Directory>
한개의 서버를 사용하여 한 회사의 웹서버를 구축했을 때 각부서의 홈페이지는 따로 구성할 수 있다. http://www.main.com(회사 대표 페이지), http://www.main.com/development/(개발부), http://www.main.com/support/(지원부서). 그런데 각 사원을 위한 페이지를 구성해 주고 싶으면 어떻게 해야 할까? 사용자들에게 리눅스 계정을 만들어 주면 각 사용자의 홈디렉토리가 만들어 진다. /home/a_user, home/b_user,.... 이 때 각 사용자들은 자신만의 홈페이지를 만들기 위해서 /home/a_user/public_html 디렉토리를 만드고 여기에 index.html 파일을 놓으면 http://www.main.com/ a_user 라고 쳤을 때 이 파일을 볼 수 있다. 즉 UserDir 설정으로 아파치가 a_user라는 참조 URL을 보면 이 것을 /home/a_user/public_html로 번역하게 하는 것이다. 이 디렉토리에 index.html이 있다면 이 것이 보일 것이고 그렇치 않다면 디렉토리 리스트가 될 것이다. 회사에서 각 사용자들의 전용 홈페이지를 구성해 줌으로써 애사심이 길러지지 않을까?
사용자의 홈페이지는 단순한 소개 페이지 정도로 그치는 것이 좋다. 게시판이나 파일 다운로드등 본격적인 작업을 하게 해 주면 문제가 생기므로 /*/public_html 디렉토리에 대한 여러가지 제한을 붙이고 있다. 자세한 옵션은 다음에 설명하기로 하고 이 정도로 막아두는 것이 좋다는 것만 알고 넘어가자.
설정을 원하는 대로 바꾸었다면 아파치를 재시작해야 한다. 다음 세가지 방법 중에 한 가지를 쓸 수 있다.
# /etc/rc.d/init.d/httpd stop ; /etc/rc.d/init.d/httpd start
# /etc/rc.d/init.d/httpd restart
# killall -HUP httpd
첫번째가 가장 안전한 방법이며 두번째는 첫번째와 같은 방법이지만 재기동이 안되는 경우도 있다. 세번째 방법은 아파치가 설정파일을 다시 읽도록 하는 방법으로 웹서버를 잠시라도 세울 수 없는 곳에서 쓰는 방법인데 가능하면 첫번째 방법을 사용할 것을 권한다.
한 회사의 전용 페이지, 각 부서의 하위 페이지, 개인별 홈페이지만으로도 거의 대부분의 사이트는 충분하다. 이제 A 제품을 판매하는 mycompany.com과 따로 분리하여 B 제품을 판매하는 newbrand.com을 한 회사에서 서비스할 때 어떻게 해야 하는지 알아보자.
http 프로토콜은 접속이 이루어진 후에 어떤 도메인에 대해서 서비스를 요청하는지 확인할 수 있도록 되어 있다. 인터넷의 호스트명(newbrand.com)은 IP 번호(1.2.3.4)로 매핑되는데 telnet, ftp등등의 대부분의 응용계층 프로토콜은 IP번호로 접속이 이루어지고 나면 호스트명에 대해서는 관심을 가지지 않는다.
# telnet home.hitel.net Trying 203.245.15.78...
위에서 telnet 프로그램은 home.hitel.net 호스트명에 대한 IP 주소를 DNS에 요청한 후에 그 값(203.245.15.78)을 받고 접속이 이루어지며 그 다음에는 home.hitel.net은 전혀 참조되지 않는다. 그러나 http 프로토콜은 접속이 이루어진 후에 URI(Uniform Resouce Identifiers)에 호스트명이 명기되기 때문에(http://newbrand.com/index.html) 이름기반 가상 웹서비스가 가능하다. 웹서버는 URI 표기를 읽어서 목적 사이트를 구별한 후에 가상 호스트마다 다르게 설정된 디렉토리를 검색하여 파일을 전송한다. 가상호스트를 만드는 가장 단순한 설정은 다음과 같다.
Listen 192.168.1.4:80
NameVirtualHost 192.168.1.4:80
<VirtualHost 192.168.1.4:80>
ServerName www.newbrand.com
ServerAlias www.newbrand.com newbrand.com
DocumentRoot /home/httpd/newbrand
<Directory "/home/httpd/newbrand">
Options Indexes FollowSymLinks
AllowOverride None
Order allow,deny
Allow from all
</Directory>
<Directory "/home/httpd/newbrand/cgi-bin">
AllowOverride None
Options ExecCGI
Order allow,deny
Allow from all
</Directory>
ErrorLog /var/log/httpd/newbrand_error_log
TransferLog /var/log/httpd/newbrand_access_log
</VirtualHost>
NameVirtualHost 설정에 의해서 한 개의 IP에 여러 가상 호스트가 있음을 알린다. Listen은 전체 도메인에 대한 서비스(mycompang.com)를 할 때 사용했으면 없어도 된다. 그러나 한 개의 IP에 대해서 반드시 1개는 선언을 해야 한다. 192.168.1.4의 80번 포트로 접속이 이루어지면 www.newbrand.com으로 URI가 적힌 요청에 대해서 이 사이트가 반응을 하게 되고 루트 디렉토리는 /home/httpd/newbrand가 된다. http://www.newbrand.com으로 접속하면 /home/httpd/newbrand/index.html이 전송됨을 알 수 있다. 이 사이트에 대한 cgi-bin 디렉토리는 위에서 적어 준 대로이며 ExecCGI 옵션으로 파일을 실행 시킬 수 있다. 에라 로그와 전송로그는 이 사이트만을 위해서 독립적으로 사용하며 그 파일은 위에 적힌 대로이다. 이제 웹서버는 아래와 같이 동작한다.
mycompang.com이 서비스하며 /home/httpd/html/index.html 파일이 전송된다.
/home/httpd/newbrand/index.html이 전송되며 로그는 newbrand_access_log에 쌓인다.
이름 기반 가상 호스팅은 가장 단순한 형태의 가상 호스팅 서비스이다. 한 개의 회사에서 이 방식으로 각각의 브랜드에 따른 다른 회사명으로 웹서비스를 할 때 사용할 수 있다. 센드메일의 가상 사이트 설정을 사용하여 메일까지 가상 호스트와 연관시켜 webmaster@newbrand.com으로 쓸 수 있지만 여기서는 언급하지 않는다.
주소 기반 가상 호스팅은 각기 독립적인 IP 주소를 할당받아서 가상 서버를 돌리는 것을 말한다. 이름 기반 가상호스팅과 주소 기반 가상 호스팅은 웹서비스만을 한다면 사실상 별로 차이가 없다. 가장 큰 차이는 주소 기반 가상 호스팅은 각기 독립적인 ftp 서비스를 할 수 있다는 것이다. 현재 웹호스팅 서비스를 하는 업체에서 ftp를 지원하지 않는다면 이름 기반 가상 호스팅으로 모든 것을 처리할 수 있는 상태이다.
ftp 프로토콜도 telnet과 마찬가지로 접속이 이루어진 후에는 호스트명을 사용하지 않는다. ftp 프로토콜에서 http와 같이 접속 후에 목적 호스트명을 알 수 있도록 하려는 새로운 RFC 규약이 제안된 상태이며 일부 ftp 데몬 프로그램이 이 기능을 지원하고 있지만 클라이언트 프로그램들이 아직은 이 규약을 따르고 있지 않아서 현재는 이름 기반의 가상 호스팅에서 독립 ftp 서버를 지원하는 것은 어려움이 있다. 주소 기반의 가상 호스팅은 각 호스트 별로 IP를 할당해야 하는 부담이 있는데 IP 주소가 부족한 요즘에는 부적합한 방식으로 생각된다. ftp 규약이 확정되고 모든 클라이언트 프로그램이 이를 지원하기를 기다리도록 하자.
ftp를 제외하면 telnet 프로그램(이름 기반 가상 호스팅에서도 "telnet mycompany.com", "telnet newbrand.com" 모두 유효한 방식이다. 물론 같은 물리적 서버에 접속하는 것이다), mail(sendmail은 가상 호스트 기반의 메일 처리를 지원한다), http, pop-3 모두 이름 기반 가상 호스팅을 적용할 수 있으므로 굳이 주소 기반의 가상 호스팅을 할 필요는 없다.
그러나 웹서버가 이름 기반의 가상 호스팅을 지원하지 않았을 때 만들어 둔 웹페이지 내에 호스트명이 아닌 주소방식으로 참조 링크를 건 페이지가 많거나, 독립적인 ftp가 필요하거나, 서버를 분리할 예정인 여러개의 웹서비스를 하고 있을 때에는 주소 기반 가상 호스팅이 필요하다. 그 방법을 살펴 보자.
리눅스에서는 물리적인 한개의 서버가 여러개의 IP를 가질 수 있다. 이더넷 카드를 여러개 꼽아서 할 수도 있고 한개의 이더넷카드에 여러 아이피를 줄 수도 있다. 2.2에서는 IP Alias라는 개념이 조금 변화되기는 했지만 마찬가지로 쓸 수 있다. 지금 여러분의 리눅스 서버에서 ifconfig라고 쳐보기 바란다. 이더넷 카드에 192.168.1.2를 주고 있었다면 다음 명령으로 한개의 장치에 또하나의 IP를 추가할 수 있다.
(2.0에서의 모습, 2.2에서는 같은 방식이지만 결과 파일은 조금 다름)
# ifconfig eth0:0 192.168.1.98
# ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Bcast:127.255.255.255 Mask:255.0.0.0
UP BROADCAST LOOPBACK RUNNING MTU:3584 Metric:1
RX packets:26 errors:0 dropped:0 overruns:0 frame:0
TX packets:26 errors:0 dropped:0 overruns:0 carrier:0
collisions:0
eth0 Link encap:Ethernet HWaddr 00:10:4B:9E:4E:CE
inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:16674 errors:0 dropped:0 overruns:0 frame:0
TX packets:12308 errors:0 dropped:0 overruns:0 carrier:0
collisions:0
Interrupt:10 Base address:0xe000
eth0:0 Link encap:Ethernet HWaddr 00:10:4B:9E:4E:CE
inet addr:192.168.1.98 Mask:255.255.255.0
UP RUNNING MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0
eth0:0에 대해서 영구적으로 이 IP를 할당하기 위해서는 linuxconf를 쓰던지 webmin을 사용하거나 혹은 엑스메니저를 띄워서 /etc/sysconfig/network-script/ifcfg-eth0를 /etc/sysconfig/network-scripts/ifcfg-eth0:0 로 복사하고 다음과 같이 편집하면 된다. (레드헷을 사용한다면 netcfg를 쓸 수도 있다)
/etc/sysconfig/network-scripts/ifcfg-eth0 의 내용
DEVICE=eth0
IPADDR=192.168.1.2
NETMASK=255.255.255.0
NETWORK=192.168.1.0
BROADCAST=192.168.1.255
ONBOOT=yes
/etc/sysconfig/network-scripts/ifcfg-eth0:0 의 내용
DEVICE=eth0:0
IPADDR=192.168.1.98
NETMASK=255.255.255.0
NETWORK=192.168.1.0
BROADCAST=192.168.1.255
ONBOOT=yes
이렇게 IP 주소를 할당했다면 httpd.conf에 다음과 같이 추가한다.
# for www.newaddress.com
Listen 192.168.1.98:80
<VirtualHost 192.168.1.98:0>
ServerName www.newaddress.com
ServerAdmin webmaster@newaddress.com
DocumentRoot /home/httpd/newaddress
<Directory "/home/httpd/newadress">
Options Indexes FollowSymLinks
AllowOverride None
Order allow,deny
Allow from all
</Directory>
<Directory "/home/httpd/newaddress/cgi-bin">
AllowOverride None
Options ExecCGI
Order allow,deny
Allow from all
</Directory>
ErrorLog /var/log/httpd/newaddress_error_log
TransferLog /var/log/httpd/newaddress_access_log
</VirtualHost>
192.168.1.98에 대한 Listen 옵션을 새로 주고 나서 서버 이름, 다큐먼트 루트, 루트 디렉토리에 대한 설정, cgi-bin 디렉토리에 대한 설정을 해 주면 된다. 자세히 보지 않더라도 이름 기반의 가상 호스팅과 크게 차이가 나지 않는다는 것을 알 것이다.
이제 기본적으로 아파치에서 호스트 설정에 대해서 할 수 있는 작업은 모두 끝났다. 여기까지 성공적으로 했다면 서버 관리자로서 손색이 없다고 할 수 있다. 이제 아파치를 사용하면서 속도, 성능, 안정성에 영향을 미칠 수 있는 몇가지 설정을 살펴 보도록 하자. 우선 설정 파일에서 성능을 변화 시킬 수 있는 사항은 다음과 같다.
한 번의 GET 요청에 소요되는 총시간등의 설정값이다. 1200에서 300으로 디폴트값이 내려왔는데 문서에 의하면 이 값도 상당히 큰 값이라고 한다.
접속한 클라이언트의 요청을 처리한 후에 연결을 계속 유지하고 있으면 클라이언트의 다음 번 요청에 대해서 초기 시간을 절약할 수 있다. 이 것을 Off로 두면 상당한 성능상의 저하를 보인다. 참고로 최근에 윈도우 NT와 리눅스의 자체 성능 비교를 행한 Mindcraft사에서 리눅스 웹서버 성능 테스트를 하면서 이 값을 Off로 두고 했다고 한다. 가희 넌센스가 아닐 수 없다. 이 값은 디폴트로 On으로 설정되어 있으며 대부분의 웹서버에서 그렇게 쓰고 있다.
한 번의 접속에 대해서 접속을 끊지 않고 몇 번까지 요청을 받을 것인가에 대한 설정이다. 한 번의 접속에서 100번의 요청을 받은 후에는 접속을 끊고 다시 처음부터 접속 과정을 거치게 된다. 물론 내부 과정이 클라이언트측에 보여지는 것은 아니다. 문서에 의하면 대규모 사이트라면 이 값을 가능한 높일 것을 권하고 있다. 0으로 하면 클라이언트가 스스로 접속을 끊기 전까지 계속 연결되어 있게 된다.
클라이언트가 15초 내에 다음번 요청을 하지 않으면 접속을 끊는다. 사용자들이 웹페이지를 읽는 시간을 고려하면 이 값을 증가시켜도 좋을 것이다.
아파치는 자식 프로세스를 분기(fork)해서 http 요청을 처리한다. 동시에 많은 요청이 들어오면 그 때마다 자식 프로세스를 분기해야 하는데 한 번의 분기에 많은 시스템 자원이 필요하며 지연 시간이 생긴다. 요청이 없어도 미리 자식을 만들어 놓으면 이런 지연 없이 서비스를 빠르게 처리할 수 있다. 물론 너무 많은 여유 프로세스를 많들어 놓는 것도 시스템 자원의 낭비를 가져온다. 히트수가 많은 사이트라면 이 값을 늘이면 상당한 성능의 증가를 가져올 수 있다. 앞에서 말한 Mindcraft사에서는 이 값을 1로 두고 NT와 성능 비교를 했다. 아래의 MaxSpareServers와 비교해서 적당한 값을 쓰면 된다.
최대로 생성할 수 있는 여유 자식 프로세스 수, 자원을 낭비하므로 너무 큰 값은 사용하지 말 것.
한 서버가 감당할 수 있는 최대 동시 접속 수, 이 값을 크게 해야 할 필요가 생기고 그만큼 동시 접속이 많아 진다면 하드웨어의 업그레이드도 생각해야 할 것이다.
아파치 데몬이 뜬 후에 자식 프로세스를 생성하면 자식 프로세스는 여기에 적힌 갯수 만큼의 접속을 처리한 후에 죽는다. 이렇게 하면 자식 프로세스가 점유한 자원이 깨끗하게 청소가 되므로 아파치가 오래 떠 있어도 문제가 없게 된다. 이 값을 0으로 하면 한 번 뜬 자식 프로세스는 결코 죽지 않으므로 속도의 증가가 있겠지만 잘못된 코드가 실행되면서 메모리 누수등이 있었을 때 대책이 없어지므로 가능하면 적절한 값을 사용하도록 권고하고 있다. 디폴트 값은 0이지만 100혹은 그 이상의 값을 써주는 것이 좋을 것이다.
아파치가 접속을 받아 들였을 때 어디에서 접속이 들어왔는지 확인하기 위해서 호스트명에 대해 IP 주소를 확인하고 다시 IP 주소에 대해 호스트명을 확인하는 작업을 네임서버에게 의뢰한다. 이 때 상당한 시간이 필요하기 때문에 이 값을 반드시 Off로 설정해야 한다. On으로 해 놓으면 눈에 띄는 성능의 감소를 볼 수 있다.
아파치 로그파일은 계속적으로 증가하며 히트수가 많아지면 일주일에 100M 까지 증가할 수 있다. 로그 파일이 커지면 성능에 영향을 미치므로 짧은 주기로 정리하는 것이 좋다. 다음은 필자가 만들어 쓰고 있는 웹서버용 로그 파일 정리 프로그램이다.
# crontab -e ---------- # 한시간 마다 로그 파일을 정리한다. 1 * * * * /root/bin/logfiles
/root/bin/logfiles
#!/bin/sh
export PATH=$PATH:/bin:/usr/bin:/sbin:/usr/sbin:/root/bin
logrotate /root/bin/syslog.httpd
killall -HUP httpd
if [ $? -ne 0 ]; then
/etc/rc.d/init.d/httpd start
fi
/root/bin/syslog.httpd
daily
size 100k
rotate 4
# send errors to root
errors root
# create new (empty) log files after rotating old ones
create
# uncomment this if you want your log files compressed
#compress
/var/log/httpd/access.log {
}
/var/log/httpd/agent.log {
}
/var/log/httpd/error.log {
}
/var/log/httpd/suexec_log {
}
한시간 마다 logfiles 파일이 실행되고 이 프로그램은 syslog.httpd를 읽어서 access.log등의 이름을 바꾼다. 그 후에 httpd에 HUP 시그널을 주어서 새 파일을 열도록 만든다. HUP 시그널에 잘못된 반응을 하게 되면 /etc/rc.d/init.d/httpd start로 아파치를 다시 띄운다. 사실 필자의 프로그램은 짤라낸 로그를 따로 한 곳으로 모으고 일정 크기 이상이 되면 압축하여 백업본을 만들도록 구성했지만 복잡한 것은 보이기가 부적당하여 생략했다. 이 부분을 생략했기 때문에 필자가 보여준대로 하면 syslog.httpd에서 rotate 값이 4이므로 최대 4시간의 로그만 남는 문제가 있다. rotate 값을 24로 늘여서 하루분의 로그를 남기던지 crontab에서 logfiles가 실행되는 시간을 늘여주기 바란다.
아파치는 PHP혹은 perl을 이용하면 자연스럽게 데이타베이스 프로그램과 연동할 수 있다. 현재 가장 빠른 성능을 보이는 mysql(mysql은 상용 제품이지만 개인 사용자에게는 소스까지 제공한다)를 연계해서 웹데이타베이스로 꾸밀 수 있고 다양한 서드파티 모듈(물론 GPL이다)을 컴파일해서 추가하면 또다른 능력을 발휘할 수 있다. 필자는 이런 응용 프로그램 사용법까지 일일이 설명할 생각은 없지만 원하는 모듈이 있을 때 이를 컴파일하는 방법에 대해서 알아 보기로 하자. 또한 아파치를 컴파일 하면서 성능 증가를 위해서 고려해야 할 것들이 있으므로 아파치 컴파일 방법에 대해서도 다음 호에 쓰도록 하겠다. 그리고 기본적인 설정외에 본격적인 설정에 대해서도 알아보기로 하자. 다음 호는 지난 호 센드메일과 같이 조금 전문적인 이야기도 들어가게 될 것이므로 이 글을 읽고 있는 윈도우 사용자들은 아파치 설정을 하면서 http://www.apache.org(혹은 /home/httpd/html/manual 아래쪽의 파일들)을 방문해서 가능하면 이 설명서들을 숙독해 주기 바란다. 이 글은 리눅스와 아파치에 대해서 개념이 하나도 잡히지 않은 사용자를 대상으로 쓴 글이지만 일정 정도 지식이 있는 사용자들이라면 중간 과정은 생략할 예정이다.
답 : "cat a.html b.html >c.html" 한 후에 넷스케입에서 읽어와서 프린트 하면 됨.
예를 들어 contents.html이 있고 section1.html, section2.html이 있으면 각각을 프린트 할 필요 없이 cat 명령으로 순서대로 붙이면 넷스케입이 훌륭하게 한 개의 웹페이지처럼 읽어 들일 수 있다. 물론 프린트하면 content.html,s1.htmk,s2.html이 한개의 파일처럼 프린트 된다. 필자는 참고용으로 자주 보는 문서는 화면보다는 프린트해서 보기를 더 선호하기 때문에 /home/httpd/html/manual 아래의 모든 파일을 순서대로 한 개의 파일로 만든 다음 넷스케입의 프린트 버튼으로 1개의 포스트스크립트 파일을 만들었다. 페이지 수는 472페이지. 물론 압축 양면 프린트를 했기 때문에 종이는 118장이 들었다. 인터넷에서 어떤 주제에 대해서 잘 정리된 사이트가 있으면 모두 긁어 와서 프린트할 때 이 방법을 사용하기 바란다.
필자는 이 글을 쓰면서 여러번 앞에서부터 다시 읽고 있다. 가능하면 간단하고 쉬우면서 필요한 것들을 적으려고 했다. 리눅서들에게 기본적인 사항으로 거론할 필요가 없는 것이 윈도우 사용자들에게는 어렵다는 것을 깨닫고 있는 중이다. 최근에 윈도우만 사용하던 어떤 사람에게 지난 기사를 보여주면서 삼바를 설정하도록 시켜 보았는데 며칠동안 끙끙 앓으면서도 해내지 못했기 때문이다. 기본 지식이 없는 상태에서는 그래픽 방식이 전혀 도움이 되지 않는다는 것을 깨닫고 이제 가능하면 기본 지식을 쉽게 전달하고자 한다. 이 글도 어렵다면 필자에게 연락하기 바란다. 좀 더 단순하고 명확한 방법을 같이 찾아 볼 수 있으면 좋겠다고 생각하며 이글을 마친다.
NT의 IIS에서 주로 작업했기 때문에 각 디렉토리의 디폴트 페이지로 index.html보다 default.html을 쓰는게 더 편하다. 그리고 일부 웹페이지 작성자는 아파치의 약속에 따라 어떤 디렉토리는 index.html을 두고 있다. 그래서 명시적으로 파일명을 적지 않고 디렉토리를 요청하면 index.html과 default.html 둘 중에 하나가 있으면 그 것을 보내주려고 한다. 앞으로는 리눅스에서 작업할 것이므로 index.html이 증가하게 될 것이니까 둘 다있으면 index.html을 먼저 서비스 하자. 어떻게 하면 될까?
NCSA에서 개발한 웹서버의 한 패치 버전(A PAtCH)으로 태어난 아파치 웨서버는 오프소스 개발 방식을 채택하여 수많은 개발자를 끌어 안게 됨으로써 현재 가장 강력한 인터넷 웹서버 프로그램으로 부상했다. 상용 서버가 설 자리를 잃고 IIS또한 계속 무료로 제공하도록 만들었으며 NT의 ASP에 필적하는 PHP는 편리한 프로그래밍, 뛰어난 속도를 자랑하며 아파치의 지배적인 동적 웹페이지 프로그래밍 툴로 자리 잡았다(현재 ASP 소스를 PHP로 바꾸어 주는 프로그램도 나와있다). 여기에 1.3으로 넘어 오면서 DSO(Dynamic Shared Object)모델을 채택하여 데몬 재컴파일 없이 각각의 모듈만 재컴파일하여 필요할 때 동적으로 삽입할 수 있게 함으로써 수많은 지원 모듈이 생겨났다. perl 코드를 오버헤드 없이 실행하도록 해 주는 mod_perl, 보안 웹페이지를 사용하게 해 주는 mod_ssl등이 지원된다. 최근에는 NT에까지 포팅되어 ISAPI를 따르는 NT용 모듈도 실행 시킬 수 있다. 인터넷 연결기능이 중요한 개발 주제가 되면서 그 핵심인 http 프로토콜을 서비스하며 웹 DB와의 연동까지 가능한 아파치가 최고의 인터넷 프로그램이 되었다(웹서버 점유율 아파치 57%, MS-IIS 23%, http://www.netcraft.com/survey/).
아파치는 오픈소스 운영체계인 리눅스 배포본에 포함되어 있고 배포본의 기본 설정을 거의 손대지 않고도 웹페이지를 만들 수 있으므로 리눅스가 인스톨되어 있는 컴퓨터는 아파치 웹서버 머신이라고 부를 수 있을 정도이다. 실제로 아파치는 인터넷에서 가장 높은 점유율을 자랑하며 아파치가 동작 중인 서버의 대부분이 리눅스이다. 아파치 사용자가 많아지면서 유틸리티가 쏟아져 나오고 있고 모듈개발이 활성화 되어 있다. 한국내에서도 아파치 사용자 그룹이 결성되어 있고 여러가지 설정기법과 튜닝법에 대한 한글 문서도 많이 나와 있다. 물론 뉴스그룹등에 관련 질문과 답변도 활발한 편이다.
리눅스에 대한 최소한의 지식만 있으면 이미 설치되어 있는 아파치를 이용해 바로 웹서비스를 할 수 있다는 점, 전혀 추가 비용이 들지 않는다는 점, 쉽게 가상 호스팅을 할 수 있다는 점, NT보다 우수한 리눅스의 안정성은 이런 가상 호스팅 사이트수가 증가해도 전혀 문제가 없다는 점, 그리고 유닉스의 사용권한 모델에 따라 가상 호스팅에 있어서도 각 사이트간의 보안 문제가 전혀 없다는 점등으로 아파치와 리눅스는 최고의 조합이라고 얘기 할 수 있다. 현재 한국내 대부분의 웹호스팅 업체는 리눅스를 기본 플랫폼으로 사용하고 있다.
리눅스의 서버 점유율은 1998년말 기준으로 17%이며 NT는 36%의 점유율을 가지고 있는데, 성장률은 리눅스가 단연 압도적이다. 윈도우가 오피스 프로그램으로 데스크탑 시장을 점령했듯이 리눅스는 1999년에 아파치와 삼바를 무기로 서버 시장을 석권하게 될 것이다.