안녕하세요
뚱보 프로그래머 입니다.
web 서버에 대해 적습니다.
Web Server
1. 개요
현재의 인터넷을 있게 한 것은 다른 무엇보다 웹(Web, 혹은 World Wide Web)의 등장이다. 인터넷을 곧 웹이라 생각할 정도로 웹의 위력은 대단하다. 하지만 웹의 실상은 그 바탕에 하이퍼텍스트(Hypertext)라는 특별한 형태의 문서가 있었고, 이러한 문서를 전송할 수 있는 프로토콜(HTTP)이 존재하고 있었다. 즉, 하이퍼텍스트 형태로 데이터를 전송하기 위해 생성된 프로토콜이 HTTP이다.
웹 서버 종류
인터넷 상에서 웹을 이용해 자신만의 홈페이지를 구축하거나 인터넷 사이트를 개설해서 서비스를 하기 위해서는 우선 서비스를 제공할 웹 서버의 종류를 결정해야 한다.
개인용 컴퓨팅 영역이나 사무용 컴퓨팅 영역에 마이크로소프트사의 운영체제가 거의 전세계 시장을 잠식하고 그래서 사용자들은 자신이 사용하고 있는 개인용 컴퓨팅 환경과 비슷한 MS Windows NT(New Technology) 4.0이나 최근에 등장한 MS Windows 2000을 이용해 웹 서비스를 하는 경향이 증가하고 있는 경향이 있다. 따라서 이들 서버에 기본으로 설치되는 웹 서버가 있는데, 바로 IIS(Internet Information Server)이다. NT에서는 4.x 버전이었지만 Win 2000에서는 5.x 버전을 사용하고 있다. IIS는 ASP(Active Server Page)라는 강력한 서버측 스크립트 언어를 제공하고 있다는 점과 다양한 인터넷 서비스(FTP, 메일, 뉴스 등)를 통합된 관리자를 통해 관리할 수 있다는 장점이 있지만 타 운영체제에서는 사용할 수 없다는 단점외에도 Win 2000이 나온 상황에서도 안정적이지 못하다는 약점으로 인해 서버 운영자에게 신뢰를 주지 못하고 있다.
이에 대한 대안으로 등장한 것이 Freeware로 제공되는 아파치 웹 서버를 이용하는 것이다. 본래 아파치란 이름은 “A PatCHy server”에서 유래한 것으로 하나의 응용 프로그램이 있으면 이를 지속적으로 수정(patch)하기 때문에 붙여진 것이다. 특히 아파치는 소스까지 제공되고 있기 때문에 각 시스템의 환경에 맞도록 최적화할 수 있다는 장점이 있고, 전세계의 우수한 사용자들과 개발자들이 제작해 놓은 많은 모듈들을 모두 무료로 사용할 수 있다는 장점까지 제공하고 있다. 또한 운영 플랫폼에 무관하게 소스를 제공하고 있기 때문에 웹 서버의 동작 원리에 대해서 공부하고 싶은 사람에게도 기회를 제공하고 있다. 그리고 전 세계의 많은 3rd party 업체에서 아파치를 위한 제품들을 출시하고 있다.
2. 아파치 컴파일
컴파일해서 패키지화된 아파치를 설치할 수도 있지만 다양한 응용 프로그램을 설치해야 할 관리자의 입장에서 아파치는 기본적으로 설치해야 할 프로그램이기 때문에 학습 차원에서 소스를 다운로드 받아서 압축을 풀고 컴파일하고 설치해보도록 한다.
1) 아파치 구하기
일반적으로 응용 프로그램의 소스를 구할 수 있는 곳은 각 응용 프로그램의 홈페이지이므로 아파치의 홈 페이지인 http://www.apache.org를 이용한다. 이 사이트에서 가장 최신 버전의 아파치 소스를 다운 받을 수 있고 또는 테스트 중인 아파치 소스를 다운 받아서 사용할 수도 있다. 또한 각 플랫폼별로 미리 컴파일해둔 바이너리 파일들을 구할 수도 있으며 컴파일러나 링커, 라이브러리 등도 이곳에서 구할 수 있다.
아파치 웹 서버는 또한 전 세계의 여러 anonymous ftp 사이트에서 미러링하고 있다. ftp 클라이언트를 사용할 수 있다면 PSINet Korea에서 제공하고 있는 ftp://ftp.nuri.net등에 접속해서 구할 수 있다. rpm 패키지화된 프로그램을 다운받을 수 있는 곳은 http://www.rpmfind.net에서 구하면 된다.
2) 전처리 작업
1] 패키지 삭제
리눅스 설치시에 아파치를 설치하게 되면 기본적으로 /etc/httpd 디렉토리(RedHat)에 설정 파일들이 존재하게 되고 바이너리 파일들은 /usr/sbin 디렉토리에, 매뉴얼 파일들의 경우에는 /usr/man 디렉토리에, 기타 아파치와 관계된 문서 파일들은 /usr/doc 디렉토리에 저장된다.
이러한 구조는 레드햇에서 배포판을 기획할 때 다른 명령들이나 응용 프로그램들과 일관성을 유지하기 위해 설계한 구조이기 때문에 다소 불편이 있을 수 있다. 특히 유닉스 시스템에 익숙한 사용자나, 특정 디렉토리를 한꺼번에 관리하고 싶어하는 사용자에게는 작업에 방해가 될 수 있다. 이러한 불편을 해소하기 위해 다음의 명령을 이용해 아파치 패키지를 삭제하는 것이 유용하다. 특히 소스를 이용해서 다시 설치하고자 한다면 제거하는 것이 좋다.
#rpm –e apache
위의 명령을 이용해서 제거를 하고자 한다면 설치된 패키지가 삭제되지 않을 것이다. 패키지간의 의존성 문제때문인데, 사용자는 의존성 관계에 있는 패키지를 모두 삭제하고 또한 해당 디렉토리들고 삭제를 해야 시스템내의 모든 아파치를 제거했다고 할 수 있다.
2] 압축 해제
아파치 웹 서버의 소스를 http://www.apache.org에서 다운받았다면 먼저 다운 받은 소스의 압축을 풀어야 한다. GNU에서 제공하는 압축 프로그램인 gzip을 이용하거나 또는 tar를 이용하여 압축을 해제하는데 옵션을 설정해야 한다.
만약 아파치 소스 버전이 apache_1.3.22.tar.gz이라면 다음의 명령으로 압축을 해제한다.
#tar xvzf apache_1.3.22.tar.gz
위의 과정을 거치면 현재 디렉토리에 apache_1.3.22라는 디렉토리가 생성이 되고 아파치의 소스는 이 디렉토리 아래에 존재하게 된다.
만약 아파치 소스를 /usr/local에 압축을 풀고자 한다면 다음과 같이 하게된다.
#tar xvzf apache_1.3.22.tar.gz –directory=/usr/local
어떤 과정을 거치든 압축을 해제하고 파일들을 풀었다면 apache_1.3.22 디렉토리가 생성되고 이 디렉토리의 소유자와 소유 그룹이 숫자로 표시됨을 알 수 있다. 이는 apache_1.3.22.tar 파일을 만들 당시의 시스템에서 사용한 사용자와 소속 그룹의 UID와 GID이다. 이를 변경하고 싶다면 chown 명령을 이용해서 관리자의 ID와 GID로 변경하면 된다.
참고
tar 옵션 사용시 주의사항
tar 명령에 옵션을 사용할 때에는 “-“를 사용하지 않음에 유의한다. 그리고 x 옵션은 묶여진 파일을 풀어내는 역할을 하고 v 옵션은 verbose의 약자로 어떤 파일이 어떤 디렉토리로 풀리는지에 대한 정보를 출력하고 f 옵션은 file의 의미이다.
3) 컴파일 설정 및 모듈 설정
1] 설치 관련 설정
압축을 푼 후 apache_1.3.22 디렉토리로 이동을 한 후 ls 명령을 내려보면 INSTALL, README 등의 파일들을 확인할 수 있다. 설치시에 이 파일들은 반드시 읽어야 할 파일들이다.
./configure –-help
주의할 것은 configure 앞에 “/”를 반드시 붙여야 한다. 물론 현재 디렉토리가 PATH라는 환경 변수에 설정이 된 경우라면 필요가 없지만 그렇지 않다면 명령을 찾을 수 없다는 메시지가 표시되거나 configure라는 이름을 가지 다른 명령이 실행될 수도 있다. “./”는 현재 디렉토리에 존재하는 명령을 수행할 때 사용하는 명령이다.
configure 명령은 아파치를 컴파일하고 설치하기 전에 시스템이 어떻게 구성되었는지를 조사하고 설치할 위치를 결정하는 과정으로 이 명령에 의해 설치할 Makefile이 생성이 되고 컴파일에 필요한 환경을 구성하게 된다.
다음은 기본적인 설정 옵션들이다.
--prefix=PREFIX
이 옵션은 컴퓨터의 아키텍쳐와 무관하게 설치될 파일들의 위치를 지정하는 옵션이다.
--exec-prefix=EPREFIX
아키텍쳐에 의존적인 파일들이 설치될 위치를 지정한다.
--activate-module=FILE
3rd party에서 제공하는 모듈을 함께 설치하고 사용하고자 할 경우에 사용하는 옵션이다.
--enable-shared=NAME
NAME이라는 모듈을 동적 공유 객체로 사용하고자 할 경우에 이용하는 옵션이다.
--with-port=PORT
httpd.conf 파일에서 사용할 포트 번호를 설정한다.
이 외에도 많은 옵션들이 있으므로 사용을 원하는 사용자들은 옵션의 의미를 정확하게 파악하고 사용해야 할 것이다.
다음의 명령을 내려보자
#./configure –prefix=/usr/local/apache
위의 명령은 아파치의 설치 디렉토리를 /usr/local/apache로 하는 Makefile을 생성한다. 즉, prefix 값으로 현재 아파치 서버의 소스 디렉토리를 지정하는 것이 아니라 실제로 서버가 운영될 바이너리 파일들과 기타 문서들이 설치될 디렉토리명을 입력해야 한다. 이후 컴파일 설정 환경을 검사하는 과정이 계속 출력되고 컴파일에 이상이 없을 정도라면 Makefile이 생성되게 된다.
만일 위의 명령을 내린 후에 실제로 아파치가 설치될 디렉토리를 변경하고자 한다면 Makefile의 Installation paths 부분의 prefix에 설정된 경로명을 변경하면 된다. 하지만 Makefile을 수정하는 것에 익숙지 않다면 다시 configure 명령으로 경로명을 다시 지정하면 된다.
2] 모듈 설정
아파치를 비롯하여 많은 응용 프로그램 제작 기술에서 모듈(module)을 사용한다. 특히 리눅스는 커널에서 모듈별로 디바이스 드라이버를 설치할 수 있는 기능을 제공하고 있다.
아파치 모듈 홈페이지(http://httpd.apache.org/docs/mod)를 보면 다양한 모듈들이 개발되어 서비스되고 있음을 확인할 수 있다. 아파치는 모듈을 이용해 아파치 자체의 기능을 더 확장하고 있다. 아파치 웹 서버와 함께 사용할 수 있는 모듈 중 일부는 아파치 웹 서버를 설치함으로써 자동적으로 포함되는 것도 있지만 많은 경우 3rd party로 제공되며 일부 상용 프로그램을 제외하고는 대부분 무료로 다운로드 받아 사용할 수 있다.
웹 서버를 설치한 후 어떤 모듈들이 웹서버에 포함되어 사용중인지 확인하고 싶다면 웹 서버의 바이너리가 설치된 디렉토리로 이동을 해서 “httpd –l”을 실행하면 모듈 리스트가 출력될 것이다.
다음은 웹 서버만을 설치할 경우에 포함되는 기본 모듈들이다.
| 모듈 이름 | 모듈의 기능 |
| http_core | 아파치 웹 서버의 핵심이 되는 모듈 |
| mod_env | 환경 정보를 CGI에 넘겨줄 수 있는 기능 제공 |
| mod_log_config | mod_log_common을 대체해서 사용자 기반의 로그를 설정할 수 있는 기능 제공 |
| mod_mime | 파일의 확장자를 이용해서 문서의 형식을 결정할 수 있는 MIME 기능 제공 |
| mod_negotiation | 클라이언트의 성능에 가장 잘 맞춰 컨텐츠를 선별하는 기능 |
| mod_include | SSI(Server-Side Include) 등과 같이 서버측에서 구동될 수 있는 문서를 포함 |
| mod_autoindex | 디렉토리에 대해 자동으로 인덱스를 구성 |
| mod_dir | 홈 디렉토리를 다룰 수 있는 기능을 제공 |
| mod_cgi | CGI를 가동 |
| mod_asis | HTTP 헤더를 가진 파일을 있는 그대로(as is) 전송할 때 사용 |
| mod_imap | 이미지 맵(image map) 파일을 처리할 수 있는 핸들러(handler) 제공 |
| mod_actions | 파일 타입과 메소드 기반의 스크립트를 실행할 수 있음 |
| mod_userdir | 사용자의 홈 디렉토리 |
| mod_alias | alias 설저 및 재지향(redirec) |
| mod_access | 호스트를 기반으로 한 접근 제어 기능을 제공 |
| mod_auth | ASCII 텍스트 파일을 이용해서 사용자 인증을 할 수 있음 |
| mod_setenvif | 클라이언트의 정보를 기반으로 해서 환경 변수를 설정할 수 있는 기능을 제공 |
위에 제시된 모듈들은 아파치 웹 서버의 소스에 기본적으로 포함된 것으로 실제는 이보다 많은 모듈들이 존재한다. 실제 특정 웹 사이트를 기획하고 제작하고자 한다면 해당 사이트의 제작에 필요한 기능이 어떤 것인지 정의한 후 아파치 모듈 사이트를 방문하여 필요한 기능을 수행하는 모듈이 있는지 확인하는 것이 필요하다.
(1) mod_dir
이 모듈은 디렉토리를 다루는 데 필요한 여러 가지 기능을 가진 기본적인 모듈로 URL에서 제일 마지막에 붙는 “/”(trailing slash)에 대한 재지향(redirect) 역할과 해당 디렉토리에서 디렉토리 인덱스 파일을 제공하는 역할을 담당한다.
보통 webserver라는 시스템에 directory라는 디렉토리를 서비스하고 있을 때의 URL은 http://webserver/directory/가 될 것이다. 하지만 대부분의 경우 사용자들은 가장 끝에 붙은(trailing) “/”를 생략하는 경우가 많다. 사용자가 마지막 슬래시를 생략한 URL(http://webserver/directory)을 웹 브라우저의 주소 입력창에 입력하고 실행을 하면 아파치는 사용자의 요구를 받아 mod_dir 모듈을 호츨하게 된다. 호출된 mod_dir은 자동적으로 가장 마지막에 역슬래시를 붙인 http://webserver/directory/로 재지향시키게 된다.
그리고 해당 디렉토리에서 인덱스 파일을 제공하는 역할은 웹 서버의 설정 파일에 있는 DirectoryIndex라는 지시어가 mod_dir에 포함되어 있으며, 이 지시어는 클라이언트가 디렉토리 이름끝에 슬래시를 붙여서 URL을 요청하면 웹 서버 설정에서 지정한 문서가 보여지게 되는 것이다.
예를 들어 웹 서버 설정 파일에 다음과 같이 DirectoryIndex가 설정되었다고 가정해보자.
<IfModule mod_dir.c>
DirectoryIndex index.html
</IfModule>
아파치 웹 서버의 브라우저에 http://webserver/directory라고 입력하면 먼저 디렉토리 재지향이 발생하여 http://webserver/directory/로 재지향되고 그 다음 DirectoryIndex 지시어에서 지정한 index.html 파일이 덧붙여지게 된다.
참고
DirectoryIndex 지시어는 둘 이상의 문서를 나열할 수도 있는데, 이 경우 앞에서 지정한 문서가 없으면 다음 문서로 넘어간다. 하지만 웹 서버의 성능을 위해서는 둘 이상의 문서는 지정하지 않는 것이 좋다.
(2) mod_alias
웹 서비스에서 각종 alias를 사용하고 싶은 경우에 사용하는 모듈로서 제공되는 기능에 비해 사용자들이 Alias 지시어와 ScriptAlias 지시어만 사용하고 그 이외에는 거의 사용하지 않는 지시어가 많지만 기능을 익혀 사용한다면 유용한 기능을 추가할 수 있을 것이다.
다음은 mod_alias 모듈에서 지원하는 지시어에 대한 것들을 나타낸다.
| 지시어 | 의미 |
| Alias | 설정 파일에서 DocumentRoot 지시어로 지정된 디렉토리 이외의 디렉토리에서 문서를 저장할 수 있도록 하는 기능 |
| AliasMatch | Alias와 동일한 기능을 제공하지만 정규 표현식(regular expression)을 사용 |
| Redirect | 이전의 URL을 특정 URL로 mapping시키는 기능 |
| RedirectMatch | Redirect와 동일한 기능을 제공하지만, 정규 표현식을 사용 |
| RedirectTemp | 사용자에게 현재의 재지향이 임시적임을 알려주는 기능 |
| RedirectPermanent | 사용자에게 현재의 재지향이 영구적임을 알려주는 기능 |
| ScriptAlias | Alias와 비슷하지만, CGI 스크립트가 포함된 디렉토리를 지정할 때 사용 |
| ScriptAliasMatch | ScriptAlias와 동일한 기능을 수행하고 정규 표현식을 사용 |
예를 들어 보자
Alias /img /user/web/service/images
이 경우 http://webserver/img/image.gif 파일을 클라이언트가 요청하면 image.gif 파일을 찾기 위해 웹 서버의 DocumentRoot 디렉토리 아래에 존재하는 img 디렉토리를 검색하는 것이 아니라 /user/web/service/images 디렉토리에서 image.gif 파일을 검색하게 된다. 주의할 것은 /img 다음에 “/”가 와서는 안된다는 것이다.
예) RedirectMatch (.*)\.gif$ http://www.anotherwebserver.com$1.jpg
현재의 웹 서버로 요청되는 모든 .gif 파일에 대한 접근을 anotherwebserver의 .jpg로 되돌리는 것이다.
예) ScriptAlias /cgi-bin/ /user/web/service/cgi-bin/
웹 서버의 cgi-bin 디렉토리에 대한 접근을 다른 곳으로 되돌리기 위해 사용하는 것으로 http://webserver/cgi-bin/board.cgi에 대한 요청이 들어오면 board.cgi를 /user/web/service/cgi-bin 디렉토리에서 찾아서 실행하게 된다. 이 경우 ScriptAlias로 지정된 디렉토리안에는 실행 가능한 파일들만을 저장해두어야 한다. 실행이 불가능한 이미지나 HTML 등의 파일을 ScriptAlias로 지정된 곳에 저장해 두게 되면 오류가 발생하게 된다.
실제로 모듈을 아파치 웹 서버에 포함시키기 위해서는 다음의 과정을 거쳐 Makefile을 생성해야 한다.
#./configure –-enable-module=MODULE_NAME -–add-module=FILE
--enable-module 옵션은 모듈을 활성화하는 역할을 수행하고, --add-module 옵션은 추가된 모듈 파일을 이용해 3rd party 모듈을 포함시키게 된다.
(3) mod_vhost_alias
인터넷 관련 회사에서 웹 호스팅을 할 경우 직접 응용 프로그램을 개발하여 사용할 수도 있지만 아파치에서 제공하고 있는 모듈을 이용하면 좀 더 편리한 웹 호스팅을 수행할 수 있을 것이다.
mod_vhost_alias 모듈은 가상 호스팅을 대규모로 할 경우에 필요한 것으로, 대규모의 사이트를 편리하게 관리할 수 있도록 해준다. 이 모듈은 아파치의 기본 모듈에는 포함되지 않은 확장 모듈로 아파치 1.3.7 버전 이후에서 사용이 가능하다. 이 모듈은 동적으로 가상 호스트를 생성하고 유지할 수 있는 기능을 가지고 있다. 즉, IP 주소와 호스트의 이름으로만 가상 호스팅이 구성되며 호스트 이름에는 HTTP 요청 헤더를 사용하고, 요청 헤더는 서비스할 파일의 경로를 포함하고 있다. 웹 호스팅을 위해서라면 이 모듈의 사용으로 쉽고 편리하게 구축할 수 있을 것이다.
이 모듈을 설치하기 위해서는 configure 명령을 수행할 때 –-enable-module=all을 옵션으로 사용해야 한다. 만약 DSO(Dynamic Shared Object) 모듈로 사용하려면 –-enable-shared=max나 –-enable-shared=remain을 추가로 사용해야 한다.
관련 지시어로는 VirtualDocumentRoot, VirtualDocumentRootIP, VirtualScriptAlias, VirtualScriptAliasIP 등이 있다.
[1] VirtualDocumentRoot
웹 서버가 서버의 이름을 이용해서 문서의 기본이 되는 위치를 찾기 위해 사용된다. 사용 방법은 VirtualDocumentRoot directory이다. 아파치의 설정 파일에 있는 DocumentRoot 지시어와 사용법은 비슷하며, 가상 호스팅의 루트 디렉토리를 지정하는데 사용된다. 만약 directory가 없다면 이 지시어는 효력이 없다.
[2] VirtualDocumentRootIP
가상 호스트를 서버의 이름으로 연결하지 않고 IP 주소로 연결하는 것으로 나머지 부분은 VirtualDocumentRoot와 동일하다.
[3] VirtualScriptAlias
/etc/httpd/conf/httpd.conf 파일에서 CGI 스크립트의 위치를 지정하는 ScriptAlias 지시어와 동일한 역할을 수행하는 것으로, 각 가상 호스팅 사이트에서 CGI 스크립트가 존재하는 위치를 지정할 때 사용한다.
[4] VirtualScriptAliasIP
VirtualDocumentRootIP처럼 서버의 이름을 이용해서 각각의 가상 사이트를 연결하는 것이 아니라 IP 주소를 이용해서 가상 호스트의 CGI 스크립트 위치를 지정한다.
mod_vhost_alias와 관련된 모든 지시어는 특정한 문자열을 경로로 해석하여 사용한다. 해석된 문자열은 가상 호스트의 서버 이름(UseCanonicalName을 이용하여 확인 가능)이거나 IP 주소이며, 해석은 다음 형식에 의해서 제공된다.
%% : %를 디렉토리 경로에 추가
%p : 가상 호스트의 포트 번호를 추가
%N,M : 호스트 이름의 특정 부분을 추가
여기에서 N과 M은 호스트 이름의 일정 부분을 추출하기 위해서 사용되는데, N은 호스트 이름에서 점(.)으로 구분된 영역을 선택하기 위해 사용되며, M은 선택된 N에서 M개의 문자를 추출할 때 사용한다. M은 사용되지 않을 수도 있으며, 그런 경우에는 0으로 표현한다. N과 M 사이의 점은 M이 존재할 경우에만 기록하며, 사용되는 숫자는 다음과 같은 의미를 지닌다.
| N,M값 | 의미 |
| 0 | 호스트의 전체 이름(FQDN)을 의미 |
| 1 | 호스트 이름의 첫번째 부분(URL에서 시스템 이름) |
| 2 | URL에서 호스트 이름을 제외한 두번째 부분으로 도메인 이름의 첫 영역 |
| -1 | URL의 도메인 이름 부분에서 마지막 부분을 의미, 최상위 도메인을 의미 |
| -2 | URL의 도메인 이름 부분에서 마지막에서 두번째 부분 |
| 2+ | URL의 두번째 부분과 나머지 모두 |
| -2+ | URL의 도메인 이름 부분의 마지막에서 두번째와 그 이전 모두 |
| 1+와 –1+ | 0과 동일한 것으로 전체 호스트 이름 |
만약 N이나 M이 사용가능한 부분보다 클 경우에는 밑줄 하나로 디렉토리를 재구성하게 된다.
예) 이름 기반의 가상 호스트에서 httpd.conf 파일에 다음의 설정이 있다고 하자.
UseCanonicalName Off
VirtualDocumentRoot /usr/apache/vhosts/%0
만약 http://www.example.com/directory/file.html을 요청한 경우 /usr/apache/vhosts/ 밑에서 전체 호스트 이름에 해당하는 www.example.com이라는 디렉토리에 존재하는 /directory/file.html과 연결된다.
대규모의 가상 호스팅 서비스를 수행하고 있을 경우 위 경우에는 vhosts라는 디렉토리에는 수많은 디렉토리들이 생겨나게 될 것이다. 그래서 여기에 특별한 규칙을 추가한다.
UseCanonicalName Off
VirtualDocumentRoot /usr/apache/vhosts/%3+ /%2.1 /%2.2 /%2.3 /%2
만약 http://www.example.isp.com/directory/file.html을 요청할 경우 이 요청은 /usr/apache/vhosts/isp.com/e/x/a/example/directory/file.html 파일에 부합된다. 즉, vhosts 디렉토리의 하위 디렉토리를 관리하기 쉽도록 알파벳 순서로 각 사이트를 저장할 수 있어 편리하다.
만약 IP 기반의 가상 호스팅을 할 경우 다음과 같이 설정한다.
UseCanonicalName DNS
VirtualDocumentRootIP /usr/apache/vhosts/%1/%2/%3/%4/docs
VirtualScriptAliasIP /usr/apache/vhosts/%1/%2/%3/%4/cgi-bin
만약 www.exaple.com의 IP 주소가 10.20.30.40이라면 http://www.example.jsp.com /directory/file.html은 /usr/apache/vhosts/10/20/30/40/docs/directory/file.html로 매치가 된다.
4) 컴파일 및 설치
1] 컴파일
컴파일 과정에서 사용하는 도구는 make다. make는 Makefile을 읽어 들여 Makefile에서 지정한 내용대로 필요한 컴파일러 등을 호출하여 작업을 진행하게 된다.
#make
2] 설치
컴파일 과정이 모두 정상적으로 끝났다면 이제 제대로 된 위치에 설치해야 한다. 설치시에 디렉토리 지정은 이미 configure 명령을 내리면서 지정(--prefix=/usr/local/apache)되었기 때문이다. configure 과정에서 –-prefix 옵션을 지정하지 않더라도 기본적으로 /usr/local/apache 디렉토리가 아파치의 홈 디렉토리가 된다.
#make install
이 명령은 make 유틸리티가 Makefile 파일을 검색해서 어느 디렉토리에 아파치를 설치해야할 지를 결정하고 해당 디렉토리에 설치한다.
만약 아파치 웹 서버 데몬(httpd)이 실행 중인 경우에 바이너리 파일이 제대로 설치되지 않는다. 반드시 설치 전에 아파치 데몬을 정지시켜야 한다. 하지만 설정 파일들은 기존의 파일들을 그대로 사용하도록 덮어쓰기를 하지 않는다. 로그도 마찬가지로 이전에 기록되고 있던 로그를 그대로 보존한다.
5) 아파치 실행 및 종료
설치가 정상적으로 진행되었다면 prefix로 지정된 디렉토리로 이동을 해서 ls 명령을 실행한다. bin, conf, cgi-bin, htdocs, icons, include, logs, man 등의 디렉토리들이 보일 것이다. 소스를 이용해서 설치를 한 경우 /usr/local/apache/bin 디렉토리에서 다음의 명령을 내리고 확인한다.
#httpd
#ps –ef | grep ‘httpd’
정상적으로 실행된다면 웹 브라우져를 실행해서 자신의 IP 주소(혹은 http://localhost)를 웹 브라우저의 주소 입력창에 입력한다. 아파치 소개화면이 나오면 정상적으로 가동중이다.
하지만 시스템 설치시에 아파치 패키지를 선택해서 설치했다면 /etc/rc.d/init.d 디렉토리에 아파치 웹 서버 데몬인 httpd가 있을 것이다. 다음의 명령을 내리면 아파치 웹 서버 데몬을 실행할 수 있다.
#/etc/rc.d/init.d/httpd start
그리고 웹 브라우져를 실행해서 자신의 IP 주소(혹은 http://localhost)를 웹 브라우저의 주소 입력창에 입력한다.
다음은 httpd의 옵션들이다.
| 옵션 | 설명 |
| -d directory | ServerRoot 지시어에 의해 지정된 서버의 루트 디렉토리를 다른 곳으로 변경 |
| -f file | 환경 설정 파일을 file에 지정된 것을 이용 |
| -v | 아파치 웹 서버의 버전을 출력 |
| -V | 컴파일시에 설정된 내용을 출력 |
| -h | httpd의 사용법에 대한 간단한 도움말 제공 |
| -l | 컴파일시에 추가된 모듈들에 대한 리스트 출력 |
| -t | 설정 파일의 구문을 검사(DocumentRoot에 대한 검사 포함) |
| -T | 설정 파일의 구문을 검사(DocumentRoot에 대한 검사 생략) |
소스로 설치를 한 경우 위와 같이 httpd를 사용할 수도 있지만 편리한 스크립트로 제공되는 apachectl을 사용하기도 한다. “apache control”의 약자로 시작과 정지, 기타 여러 기능을 수행할 수 있다. start, stop, restart, help 등 이름만으로 알 수 있는 인자들이 있고, lynx와 mod_status가 활성화되어야만 사용할 수 있는 status, fullstatus 등 웹 서버의 성태를 볼 수 있는 인자가 있고, 설정을 검사하는 configtest와 graceful 등의 인자가 있다.
6) 웹 서버 설정
아파치 웹 서버를 설정하는 것은 어려운 작업 중 하나이다. 수십개의 지시어와 각종 변수들에 대한 이해가 있어야 하고 각각의 사용법에 대해서도 정확하게 알고 있어야 하기 때문이다. 그렇지 않을 경우 서버가 오작동을 하거나 제대로 작동하지 않을 수 있다.
1] 설정 파일 개요 및 서버 변수
아파치를 설치하고 나면 /etc/httpd/conf 디렉토리나 /usr/local/apache/conf 디렉토리내에 세개의 설정 파일(httpd.conf, srm.conf, access.conf)이 존재한다. 이전에는 세개의 설정 파일이 모두 환경 설정에 사용되었지만, 현재는 httpd.conf 파일만 적용이 된다. 참고로 이전에 srm.conf 파일은 시스템 자원에 대한 설정을, access.conf 파일은 웹 사이트 접근에 대한 설정을 포함하고 있었다.
srm.conf 파일의 경우 DocumentRoot, UserDir, AddHandler, AddType 등의 지시어를 포함하고 있으며, access.conf 파일은 <Directory> 컨테이너를 포함하고 있었다.
다음은 CGI 프로그래밍에 꼭 필요한 서버 변수들이다.
| CGI 변수명 | 변수 설명 |
| AUTH_TYPE | 사용자 인증 방법을 설정 |
| CONTENT_LENGTH | 컨텐트의 길이에 대한 정보 저장 |
| CONTENT_TYPE | 컨텐트의 MIME 타입에 대한 정보 |
| GATEWAY_INTERFACE | CGI 버전에 대한 정보 |
| PATH_INFO | URL에서 CGI 스크립트의 경로 |
| PATH_TRANSLATED | PATH_INFO의 경로를 파일시스템 경로로 변경 |
| QUERY_STRING | URL을 통해 전달되는 문자열 |
| REMOTE_ADDR | 접속한 클라이언트의 IP 주소에 대한 정보 |
| REMOTE_HOST | 접속한 클라이언트의 DNS 이름에 대한 정보 |
| REMOTE_IDENT | 검증 데몬(identd)에 의해 검증된 원격의 유저 ID |
| REMOTE_USER | 검증 데몬에 의해 검증된 사용자의 이름 |
| REQUEST_METHODS | HTTP 요청 방법(Form에서 사용된 method) |
| SCRIPT_NAME | 스크립트의 가상 경로에 대한 정보 |
| SERVER_NAME | 서버의 호스트 이름에 대한 정보 |
| SERVER_PORT | 서버의 포트 번호에 대한 정보 |
| SERVER_PROTOCOL | 프로토콜의 이름과 버전에 대한 정보 |
| SERVER_SOFTWARE | 서버의 소프트웨어 이름과 버전에 대한 정보 |
| HTTP_ACCEPT | 브라우저가 수용 가능한 MIME 타입에 대한 정보 |
| HTTP_REFERER | 이전(현재 페이지를 참조하고 있는) 문서의 URL 정보 |
| HTTP_USER_AGENT | 클라이언트의 소프트웨어에 대한 정보 |
2] 설정 파일 및 설정 지시어
아파치 설정 파일(httpd.conf)의 설정 지시어는 200여개가 넘는다. 이 모두를 여기에서 다루기에는 무리가 있으므로 몇가지 중요한 지시어를 설정파일과 함께 살펴본다.
일반적으로 apache가 설치된 디렉토리(configure 명령을 실행할 때 -–prefix 옵션값으로 준 디렉토리명이나 혹은 /usr/local/apache/conf 디렉토리에 존재하게 된다. 만약 RPM 패키지로 설치한 경우에는 /etc/httpd/conf/ 디렉토리에 존재하게 된다. 어떤 경우든 아파치가 설치된 디렉토리내의 conf 디렉토리에 설정 파일이 있게 된다.
httpd.conf 파일 이외에도 srm.conf 파일과 access.conf 파일 두개가 더 있지만, 이 파일이 가장 핵심적인 역할을 수행하며, 서버의 환경을 설정하거나 서버에게 명령을 전달하는 역할을 하게 된다.
설정을 지시하는 지시어는 크게 세개의 그룹으로 구성된다.
첫번째는 웹 서버의 전반적인 동작을 제어하는 지시어로 최대 데몬 수, 최대 동시 접속 수, 추가 모듈 설정 등을 설정(global environment)한다.
두번째는 주 웹 서버 혹은 기본 웹 서버의 파라미터를 정의하는 지시어이다.(주 서버라함은 가상 호스트에서 다룰 수 없는 요청에 대해 응답하게 되는 서버를 주 서버 혹은 기본서버라 한다.) 이러한 지시어는 가상 서버에 대해서도 기본적인 값들을 제공하게 되며, 간단히 각 디렉토리 별로 권한을 설정한다.
세번째는 가상 서버에 대한 설정으로 하나의 IP 주소에 여러 개의 도메인 주소를 부여하여 각 도메인에 대한 독립 홈페이지 서비스를 가능하게 하거나 하나의 IP에 포트를 추가적으로 선정하여 포트별로 독립적인 홈페이지 서비스 또한 가능하다. 가상 호스팅의 경우 추가 설정 파일 및 로그 파일의 생성이 가능하다.
다양한 환경 설정 파일과 로그 파일들의 이름을 지정할 경우 반드시 “/”로 시작하는 절대 경로를 지정하는 것이 좋다. 만약 절대 경로를 지정하지 않는 경우에는 ServerRoot 지시어에 의해 정의된 값이 앞에 추가된다. 예를 들어 로그 파일의 이름을 “logs/foo.log”라고 지정했고, ServerRoot 지시어의 값이 “/usr/local/apache”라고 하면 웹 서버에 의해 해석되는 실제 로그 파일의 이름은 “/usr/local/apache/logs/foo.log”가 된다.
아파치는 기본 섹션이 세개로 이루어져 있다.
섹션 1 : Global Environment (전체 환경)
섹션 2 : Main Configuration (주 서버 설정)
섹션 3 : Virtual Hosting (가상 호스트)
섹션 1 : 전체 환경 (Global Environment)
전체 환경에서의 설정은 전체 영역에 영향을 미치는 기본 설정이다.
여기서 정의된 지시어는 아파치의 운영에 영향을 많이 미치는 것들로, 최대로 가동되는 웹 서버의 수나 환경 설정 파일의 위치등이 설정된다.
ServerType 지시어는 웹 서버가 어떻게 가동될 것인지를 결정하는 것으로 inetd(Internet daemon의 약자로 네트워크를 통해 접근하는 모든 접근을 살피고 있다가 /etc/services에 정의된 포트로 사용자의 요구가 들어올 경우 해당 응용 프로그램을 실행시키는 역할)의 도움을 받아서 실행할 것인지, 독립 실행형(standalone)으로 동작할 것인지를 결정하게 된다. 독립 실행형으로 동작할 경우 항상 메모리 상에 가동 중이기 때문에 사용자의 요구에 빠른 응답이 가능하지만 시스템의 자원 소모가 많다. inetd 방식은 유닉스 플랫폼에서만 지원된다.
ServerType standalone
ServerRoot는 서버의 설정 파일이나 접근 로그 혹은 오류나 에러 로그 파일이 저장되는 디렉토리의 최상위 경로를 지정하게 된다. 주의할 점은 만약 ServerRoot의 값을 NFS 혹은 Samba 등 네트워크로 연결된 다른 시스템에 저장된 경우라면 http://www.apache.org/docs/mod/core.html#lockfile 문서에서 LockFile에 해당하는 영역을 참조한다. 네트워크로 연결된 파일 시스템의 경우 정확한 권한 설정이 이루어지지 않으면 로그 파일이 기록되지 않거나 환경 설정 파일을 읽을 수 없는 사태가 발생할 수도 있기 때문이다. 디폴트로 /etc/httpd 디렉토리를 설정하지만 소스를 이용하여 설치한 경우 configure 명령으로 지정된 –-prefix 옵션의 값이 지정된다.
디렉토리 경로 뒤에 slash(“/”) 문자를 사용하지 않는다.
ServerRoot "/etc/httpd"
LockFile 지시어는 lockfile의 경로를 지정하는 것으로 이는 아파치를 컴파일할 때 USE_FCNTL_SERIALIZED_ACCEPT 또는 USE_FLOCK_SERAILIZED_ACCEPT 옵션으로 컴파일한 후, lockfile의 경로를 지정할 경우 사용한다. 일반적으로 기본값이 그대로 사용되지만 값을 바꾸는 경우는 로그 디렉토리가 NFS 마운트된 곳에 있는 경우로서 잠금 파일은 항상 네트웤 파일 시스템이 아닌 로컬 디스크에 저장되어야 하기 때문이다. 즉, 기본값이 사용될 경우 이는 로그 파일이 로컬 파일 시스템에 저장되지 않고 네트워크 파일 시스템에 저장될 경우이다.
LockFile logs/accept.lock
PidFile 지시어는 웹 서버 프로세스가 시동될 때 자신의 고유 프로세스 ID(PID)가 저장되는 파일의 위치를 지정하게 된다. 즉, 주 서버 프로세스의 PID값이 자동으로 파일 이름뒤에 붙는다.
PidFile /var/run/httpd.pid
ScoreBoardFile 지시어는 주 서버 프로세스의 정보가 아닌 다른 웹 서버의 프로세스 정보를 저장하는 파일의 위치를 지정하는 것으로, 모든 시스템에서 이 지시어가 필요한 것은 아니다. 하지만 이 지시어를 필요로 하는 시스템에서는 둘 이상의 아파치 서버가 하나의 scoreboard 파일을 공유하도록 해서는 안된다. 즉, 서로 다른 포트를 사용하는 아파치 서버가 둘 이상 작동할 경우에는 반드시 서로 다른 파일을 지시하고 있어야 한다. 그리고 꼭 필요한 것은 아니지만 필요할 경우 하나의 아파치 프로그램을 두번 이상 실행시키는 경우 값이 중복되지 않도록 해주어야 한다.
ScoreBoardFile /var/run/httpd.scoreboard
표준적인 환경 설정에서는 웹 서버가 httpd.conf 파일을 처리하고(명령행 상에서 –f 옵션으로 지정), srm.conf 파일이 두번째로 처리되고, 마지막으로 access.conf 파일이 처리된다. 하지만 현재 배포되고 있는 버전에서는 srm.conf와 access.conf는 비어있는 상태로 배포가 된다. 이는 설정의 단순함을 위해 httpd.conf 파일에만 지시어를 사용하도록 하고 있기 때문이다. 그래서 다음의 두 지시어는 주석으로 처리해두는 것이 좋고, 다른 방법으로는 지시어의 값을 /dev/null(리눅스 혹은 유닉스)이나 nul(MS-Windows)를 사용함으로써 웹 서버가 무시하도록 지정할 수 있다.
#ResourceConfig conf/srm.conf
#AccessConfig conf/access.conf
데이터를 받고 보내는 데 소요되는 시간을 초단위로 설정하는 것이다.
Timeout 300
KeepAlive 지시어는 지속적인(persistent) 연결(연결당 하나 이상의 요청이 존재할 수 있음)을 허용할 것인지, 허용하지 않을 것인지를 결정하는 것으로, HTTP/1.1에서 세션의 연결을 유지할 때 필요한 항목이다. 즉, 한 번의 접속에서, 즉 사용자와의 세션을 유지한 상태에서 여러 개의 요청을 처리할 것인가 여부을 결정하는 것으로 허가하는 것과 허가하지 않는 것과의 효율 차이는 매우 크다. 허가하지 않기 위해서는 Off를 지정한다.
KeepAlive On
MaxKeepAliveRequests 지시어는 하나의 지속적인 접속(연결)이 이루어진 상태에서 처리할 수 있는 최대의 요청 개수를 지정하는 것으로 0으로 설정할 경우 요청의 수에 제한을 두지 않게 된다. 즉, 하나의 세션으로부터 동시에 받을 수 있는 최대의 요청 개수를 의미하며, 일반적으로 최대의 성능을 발휘하기 위해서는 이 값을 높게 설정해 두는 것이 좋다.
MaxKeepAliveRequests 100
KeepAliveTimeout 지시어는 지속적인 동일한 연결(같은 접속 상태)을 통해 동일한 클라이언트가 다음 요청이 들어올 때까지 연결을 유지시킬 시간을 초단위로 설정하는 값으로, 각 사용자의 세션 유지 시간을 설정하는 것, 즉 사용자와의 세션을 서버측에서 유지시킬 기본적인 시간을 설정하는 것이다.
KeepAliveTimeout 15
특정 웹 사이트를 방문해 로그인을 한 후 일정한 시간 동안 그 사이트에서 동작을 하지 않는 경우 다시
로그인을 하라는 메시지를 본 적이 있을 것이다. 이와 같이 사용자의 정보를 유지시키기 위해서
쿠키(cookie)라는 것과 세션(session)이라는 것을 이용하게 된다. 위의 지시어는 세션을 이용할 경우에
사용하는 것으로, 사용자와의 세션을 유지(KeepAlive)하고, 하나의 세션으로부터 동시에 받을 수 있는
최대 요청 수(MaxKeepAliveRequests)를 정하고, 사용자와의 세션을 서버측에서 유지시킬 기본적인
시간(KeepAliveTimeout) 등을 정의하게 된다.
다음 지시어는 서버의 풀(Server-pool)을 지정하는 것으로, 관리자가 임의로 서버의 프로세스 개수를
정하는 것보다는 웹 서버의 부하에 따라 웹 서버가 알아서 프로세스의 개수를 조절하도록 하는 것이
좋다. 뿐만 아니라 추가적으로 몇 개의 프로세스를 더 띄워 순간적으로 증가하는 서버의 부하(예를
들어 하나의 네스케이프 브라우저에서 동시에 여러 개의 요청이 들어올 경우)를 수용할 수 있도록 하는
기능을 가지고 있다.
이와 같은 작업은 주기적으로 얼마나 많은 웹 서버가 사용자의 요청을 기다리고 있는지, 즉 주기적으로 몇 개의 서버가 요청 대기 상태인지 체크함으로써 가능한데, MinSpareServers 항목보다 적다면 몇 개의 서버를 추가적으로 생성하고, MaxSpareServers보다 많은 경우에는 불필요한 서버를 제거하는 것이 자원 유지에도 좋다. 대부분의 사이트에서 기본적으로 설정된 값만으로도 충분할 것이다.
MinSpareServers 7
MaxSpareServers 12
초기에 시작될 웹 서버의 숫자를 지정하는 항목으로, 합리적인 근사치를 입력하는 것이 좋다.
StartServers 7
동시에 가동될 수 있는 웹 서버 프로세스의 최대 숫자를 지정하는 것으로, 이는 동시에 접속할 수 있는 사용자의 숫자를 지정하는 것이다. 만약 동시 접속한 클라이언트의 수가 여기에 지정된 숫자에 도달한 경우 클라이언트의 요청은 봉쇄되어 서비스를 제공받을 수 없게 된다. 그러므로 이 값이 너무 작아서는 않된다. 이 값의 주된 역할은 아파치 웹 서버가 너무 많은 자원을 소비하여 전체 시스템이 다운되는 것을 방지하는 것이다. 그러므로 시스템의 능력에 따라 그 수를 적절하게 조절하는 것이 좋다.
MaxClients 150
MaxRequestPerChild 지시어는 자식 프로세스 각각이 죽기 전까지 처리할 수 있도록 허용된 요청의 개수를 지정한다. 하나의 프로세스가 너무 오랫동안 사용하면 메모리 누출이나 다른 자원의 누출이 발생하기 때문에 자식 프로세스는 자동적으로 죽게 된다. 여기서 메모리나 자원의 누출은 아파치 혹은 잘못된 라이브러리의 사용으로 인해 발생된다. 대부분의 시스템에서 이 지시어는 필요가 없지만 솔라리스와 같은 몇몇 시스템에서는 라이브러리에서의 자원 누출을 막기 위해서 필요하다. 이런 플랫폼에서는 10000과 같이 일정한 숫자를 입력해두는 것이 좋다. 0으로 설정하면 제한이 없음을 의미한다. 여기에 지정된 값은 하나의 연결당 초기 요청 이후의 연속된 요청은 하나로 생각하여 지정된 값이다. 예를 들어 자식 프로세스가 초기 요청과 이후 세션이 연결된 10개의 요청을 처리할 경우에 이를 하나의 요청으로 생각한다.
MaxRequestPerChild 100
하나의 호스트에 둘 이상의 NIC(Network Interface Card)가 있어 둘 이상의 IP 주소를 가질 때 특정 IP 주소를 아파치에 연결하기 위한 항목이다. 즉, 기본값으로 지정된 IP 주소 이외의 다른 IP 주소가 있을 때 이를 특정 웹 사이트의 주소(별도의 웹 서버)와 연결할 수 있게 된다. 뿐만 아니라 기본 포트(80) 이외의 다른 포트에 아파치 웹 서버를 연결할 때 이 항목을 사용할 수 있다.
두 개의 NIC(IP 주소를 가지는)를 가지는 하나의 호스트에서 별도의 두 웹 사이트를 서비스한다고 하자. 하나의 웹 서버는 222.222.222.111:80(다른 httpd.conf 파일에서 설정했다고 가정)에, 또 다른 웹 서버는 222.222.222.112:80에 할당하기 위해서는 다음과 같이 사용하면 된다. 물론 포트에 대한 지정을 수행해도 된다.
#Listen 222.222.222.112:80
동일한 포트(물론 서로 다른 IP 주소에 부여된 포트) 번호를 사용하여 서비스할 수 있다.
#Listen 3000
#Listen 12.34.56.78:80
아래의 지시어를 사용하여 가상 호스트를 사용할 수 있다. 이 지시어는 사용자의 요청에 귀 기울일 IP 주소를 웹 서버에게 알려주는 역할을 하게 된다. 이 지시어의 값으로 “*”나 특정 IP 주소를 할당하거나 완전한 도메인 이름(FQDN: Fully Qualified Domain Name)을 지정할 수 있다.
BindAddress *
동적 공유 객체(Dynamic Shared Object, DSO) 지원
DSO 방식으로 만들어진 모듈의 기능을 사용하기 위해서는 해당 모듈과 관련된 지시어를 사용하기에 앞서 'LoadModule' 지시어로 모듈을 메모리에 탑재해야 한다. 또한 이미 httpd –l을 이용해서 컴파일 시에 아파치 웹 서버에 포함된 내용을 볼 수도 있다. 이는 httpd binary에 내장된(정적으로 링크되어 항상 사용 가능한) 모듈의 목록을 나열한다.
주의할 점은 모듈이 메모리에 적재되는 순서이며 이 순서는 매우 중요하다. 모듈의 탑재 순서를 함부로 변경하지 않기를 권한다. 만약 LoadModule 설정을 하나라도 바꾸었다면 LoadModule 설정뒤에 따라 나오는 AddModule 설정도 똑같이 바꾸어주어야 한다.
#LoadModule mmap_static_module modules/mod_mmap_static.so
LoadModule config_log_module modules/mod_log_config.so
LoadModule agent_log_module modules/mod_log_agent.so
LoadModule referer_log_module modules/mod_log_referer.so
#LoadModule mime_magic_module modules/mod_mime_magic.so
LoadModule negotiation_module modules/mod_negotiation.so
LoadModule status_module modules/mod_status.so
LoadModule info_module modules/mod_info.so
LoadModule includes_module modules/mod_include.so
LoadModule autoindex_module modules/mod_autoindex.so
LoadModule dir_module modules/mod_dir.so
LoadModule cgi_module modules/mod_cgi.so
LoadModule asis_module modules/mod_asis.so
LoadModule imap_module modules/mod_imap.so
LoadModule action_module modules/mod_actions.so
#LoadModule speling_module modules/mod_speling.so
LoadModule userdir_module modules/mod_userdir.so
LoadModule proxy_module modules/libproxy.so
LoadModule alias_module modules/mod_alias.so
LoadModule rewrite_module modules/mod_rewrite.so
LoadModule access_module modules/mod_access.so
LoadModule auth_module modules/mod_auth.so
LoadModule anon_auth_module modules/mod_auth_anon.so
LoadModule dbm_auth_module modules/mod_auth_dbm.so
LoadModule db_auth_module modules/mod_auth_db.so
LoadModule digest_module modules/mod_digest.so
LoadModule cern_meta_module modules/mod_cern_meta_so
LoadModule expires_module modules/mod_expires.so
LoadModule headers_module modules/mod_headers.so
LoadModule usertrack_module modules/mod_usertrack.so
#LoadModule example_module modules/mod_example.so
#LoadModule unique_id_module modules/mod_unique_id.so
LoadModule setenvif_module modules/mod_setenvif.so
확장 모듈을 위한 설정이다.
#LoadModule php_module modules/mod_php.so
다음은 서버 scripting 언어인 php3 모듈이다. 설정을 바꾸고 나서 다음 행의 주석을 풀어준다.
# AddType application/x-httpd-php3 .php3
LoadModule php3_module modules/libphp3.so
모듈 실행 순서를 정확하게 하기 위해 사용 가능한 모듈(정적 또는 공유 모듈 포함)로부터 완전한 목록을 다시 만들어 둔 것이다. [LOADMODULE] 섹션을 하나라도 수정했다면 이 부분도 역시 수정해야 한다.
ClearModuleList
#AddModule mod_mmap_static.c
AddModule mod_env.c
AddModule mod_log_config.c
AddModule mod_log_agent.c
AddModule mod_log_referer.c
AddModule mod_mime_magic.c
AddModule mod_mime.c
AddModule mod_negotiation.c
AddModule mod_status.c
AddModule mod_info.c
AddModule mod_include.c
AddModule mod_autoindex.c
AddModule mod_dir.c //URL에서 마지막에 붙는 "/"에 대한 재지향, 디렉토리 인덱스 파일 제공
AddModule mod_cgi.c
AddModule mod_asis.c
AddModule mod_imapc
AddModule mod_actions.c
AddModule mod_speling.c
AddModule mod_userdir.c
AddModule mod_proxy.c
AddModule mod_alias.c
AddModule mod_rewrite.c
AddModule mod_access.c
AddModule mod_auth.c
AddModule mod_auth_anon.c
#AddModule mod_auth_dbm.c
AddModule mod_digest.c
#AddModule mod_cern_meta.c
AddModule mod_expires.c
AddModule mod_headers.c
AddModule mod_usertrack.c
#AddModule mod_example.c
#AddModule mod_unique_id.c
AddModule mod_so.c
AddModule mod_setenvif.c
#Extra Modules
#AddModule mod_php.c
AddModule mod_php3.c
#AddModule mod_perl.c
아래의 지시어는 “server-status” 핸들러(처리기)가 호출되었을 때 아파치와 관련된 매우 상세한 내용(ExtendedStatus On)을 출력할 것인지, 단순한 기본 정보(ExtendedStatus Off)만을 생성시킬 것인지를 제어하게 된다. 기본값은 Off로, 자세한 내용을 출력시키는 것은 웹 사이트의 세세한 정보를 외부에 공개하는 것이므로, 이는 해킹에 유리한 정보를 외부에 제공해주기 때문에 좋지 않다. 서비스를 개발할 때만 사용하는 것이 좋다.
ExtendedStatus Off
섹션 2 : 주 서버(Main Server) 설정
이 영역에서 사용되는 지시어는 주 서버에 의해서 사용되는 설정들로, <VirtualHost> 지시어 영역에서 사용되는 가상 호스트 영역에 의해서 제어되지 않는 사용자의 요청에 대한 응답을 담당하게 된다. 또한 본 파일의 후반에서 정의될 <VirtualHost> 영역에서 사용될 지시어들에 기본값을 제공하기도 한다.
만약 전체 영역의 ServerType 지시어가 “inetd”로 지시된 경우에는 inetd의 설정으로 인해 다음 몇몇의 지시어는 아무런 영향을 미치지 못한다. 그러므로 ServerAdmin 지시어까지 건너뛴다.
독립 실행형(standalone) 서버가 사용자의 요청을 기다리는 포트의 번호를 정의하는 지시어로, 1023 미만의 포트 번호를 웹 서버가 사용할 경우에 대해서는 httpd가 처음에는 root의 권한으로 실행되어야 한다. 이 개념은 다른 데몬에도 적용된다.
Port 80
httpd가 다른 사용자나 그룹의 권한으로 사용되기를 원하면, 우선 httpd가 root 사용자의 권한으로 실행되고 난 후 설정된 다른 사용자 권한으로 전환된다. User/Group은 httpd가 실행될 때 사용하게 되는 사용자의 계정 이름이나 그룹 이름(혹은 번호)이 된다.
주의할 점은 특정 커널에서는 그룹 ID가 60000 이상의 값을 가질 경우에는 setgid나 semctl(IPC_SET) 함수를 사용할 수 없는 경우도 발생하게 되는데, 이런 시스템에서는 Group nobody를 사용하지 말 것을 권장한다.
User nobody
Group nobody
서버에 문제가 발생했을 경우, 발생한 문제에 대해 E-mail을 보낼 주소를 지정하는 것으로, 에러 페이지와 같이 서버가 생성하는 문서에 나타나게 된다.
ServerAdmin root@localhost
클라이언트 프로그램에서 요청하는 호스트의 이름과 웹 서버의 이름이 다른 경우에 클라이언트에게 보내줄 호스트의 이름을 지정할 때 사용하는 지시어로 실제 호스트의 이름 대신에 “www”를 사용하도록 지정할 수 있다. 사용자가 호스트 이름을 임의로 만들어내고 그 호스트 이름이 제대로 동작하기를 바래서는 안된다. 여기에서 정의하는 호스트 이름은 DNS에 정의된 타당한 이름이어야 한다. 만약 DNS에 등록된 호스트 이름이 없다면 여기에다 IP 주소를 입력한다. 어쨌든 IP 주소(http://222.222.222.222/)를 이용해서 웹 사이트를 방문할 수 있을 것이며, 재지향이 정상적으로 동작하는 것을 확인할 수 있을 것이다.
간혹 127.0.0.1의 IP 주소를 사용하는데, 127.0.0.1의 경우에는 TCP/IP에서 loopback 주소이며, 가끔씩은 localhost라는 이름이 사용되기도 한다. 일반적인 운영체제는 127.0.0.1이란 주소를 이용해서 항상 자기 자신을 인식하게 되는데, 아파치를 로컬 테스팅이나 개발용으로 사용할 경우에는 127.0.0.1을 서버의 이름으로 지정할 수도 있다.
ServerName www.linuxone.co.kr
DocumentRoot는 클라이언트에게 제공할 문서의 최상위 디렉토리를 지정하는 지시어로, 클라이언트의 모든 요청은 기본적으로 이 디렉토리로부터 시작된다. 하지만 다른 위치를 지정하기 위해서 심볼릭 링크나 별칭(alias)을 사용할 수도 있다.
DocumentRoot "/var/www/html"
아파치에 의해서 각 클라이언트가 접근할 수 있는 각 디렉토리(아파치 웹 서버가 서비스를 제공하는 디렉토리)에 대하여 어떤 서비스와 기능을 허용할 것인지 거부할 것인지를 설정하는 것들로, 상위 디렉토리에 대한 설정 내용은 해당 디렉토리의 하위 디렉토리에도 영향을 미친다. 즉, 서버로부터 자료를 얻어갈 수 있는 위치를 제어한다.
우선 “기본값”은 매우 제한적인 권한을 가지도록 설정하는 것이 좋다.
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
다음은 이후에 사용될 Options란 지시어에 대한 설명이다.
Options에 부여할 수 있는 것들은 다음과 같다.
1. Indexes는 디렉토리를 가리키는 URL에 대하여 DirectoryIndex에서 지정된 기본 문서(예를 들어
index.html)가 없는 경우, 디렉토리 목록을 브라우저로 전달할 것인지를 결정하는 것으로, 보안이
중요한 경우에는 디렉토리 목록을 보여주지 않는 것이 좋다.
2. ExecCGI는 해당 디렉토리 아래에 존재하는 CGI에 대한 실행을 허가하는 것으로, 이 또한 보안에 영향을 미치게 되므로 허용하지 않는 것이 좋다.
AddHandler cgi-script .cgi 참조
3. Includes는 SSI(Server-Side Include)를 허용한다.
4. IncludesNOEXEC는 SSI를 허용하기는 하지만 exec 명령과 CGI에 대해서는 include를 허용하지 않는다.
5. FollowSymLinks는 해당 디렉토리에 심볼릭 링크가 존재할 경우, 해당 심볼릭 링크를 따라갈 것인지를 결정하는 것으로, 이 옵션을 사용하게 되면 심볼릭 링크가 가리키는 곳이 웹 문서의 디렉토리 밖이라도 브라우저를 통해서 그 내용을 볼 수 있도록 허용하게 된다. 이는 보안상 문제를 발생시킬 수도 있기 때문에 특정 디렉토리 이하로만 규제를 하는 것이 안전하다.
6. SymLinksIfWonerMatch는 링크가 걸린 파일이나 디렉토리가 심볼릭 링크를 소유한 사용자와 같은 소유권을 가질 때만 링크를 따라 이동하여 그 내용을 웹 브라우저로 보내도록 한다. 그러므로 FollowSymLinks보다는 조금 더 안전한 옵션을 제공한다.
7. 이외에 All이나 None이 존재하는데, All의 경우에는 모든 동작이나 설정을 허용하기 때문에 보안상 상당한 위험이 존재하게 되고, None은 모든 것을 허용하지 않기 때문에 별 의미가 없다.
웹 브라우저를 통해 디렉토리에 개별적으로 접근하는 것은 .htaccess 파일로 제어할 수 있다. 각각의 디렉토리에 이 파일을 두게 되면 제한 설정 옵션을 변경할 수 있다. 하지만 모든 설정을 .htaccess 파일로 변경할 수 있는 것은 아니다. AllowOverride 설정을 통해 허용된 사항을 변경할 수 있게 된다. 일반적으로 None으로 설정하는 것이 가장 안전하다. None으로 설정하게 되면 .htaccess 파일에 의한 제한은 불가능하다.
참고
<Directory> 지시어(컨테이너)는 그 이름에서 의미하듯이 각각의 디렉토리별로 접근을 제한하게 된다. 만약 특정 파일별로 접근을 제한하려면 <Location>이라는 컨테이너를 사용하면 된다. <Location>은 요청된 URL을 기반으로 접근 제한을 하기 때문에 각 파일 기반의 접근 제한이 가능하다. 예를 들어 yourdomain.com 이외의 사용자들이 /security/topsecret.html에 접근하지 못하도록 하려면 다음과 같이 설정한다.
#<Location>
# order deny,allow
# deny from all
# allow from .yourdomain.com
#<Location>
위에서 설정했던 DocumentRoot 값으로 변경해서 설정을 하도록 한다.
<Directory “/usr/local/apache/htdocs”>
다음 값에는 "None", "All", 또는 "Indexes", "Includes", "FollowSymLinks", "ExecCGI", "MultiViews"의 자유로운 조합이 가능하다. 여기서 주의할 점은 "MulitViews"만큼은 "Options All"을 사용한다 할지라도 명시적으로 설정해야만 작동이 가능하다.
Options Indexes FollowSymLinks MultiViews
다음은 각 디렉토리에 위치한 .htaccess 파일에서 어떤 옵션을 사용하더라도 사용된 옵션을 마음대로 제어할 수 있는지를 결정한다. All, Options, FileInfo, AuthConfig, Limit의 자유로운 결합이 가능하다.
AllowOverride None
웹 서버의 해당 디렉토리로부터 누가 자료를 가져갈 수 있는지를 제어한다.
Order allow,deny
Allow from all
</Directory>
Order 지시어는 디렉토리에 대한 접근 정책 허용 순서를 정하는 것으로, 일반적으로 allow, deny 순서와 deny, allow 순서 등 두가지의 경우가 가능하다. 전자(allow, deny)는 먼저 허용을 하고, 이후에 거부를 하는 것이고, 후자(deny, allow)는 먼저 거부를 하고 난 후에 허용을 한다. 이 외에 mutual-failure가 있는데, 이는 allow, deny에 해당되지 않는 것은 모두 거부하기 때문에 엄격한 설정이 필요할 때 사용하게 된다.
예를 들어 다음과 같이 사용했다면
order deny, allow
deny from all
allow from .domain.com
우선 deny가 먼저 적용되어 모든 접근을 거부부터 하게 된다. 그 후에 각 클라이언트의 위치를 파악하여 domain.com이라는 도메인 주소로부터 들어온 사용자에게는 접근을 허용하게 된다. 둘 이상의 호스트로부터의 접근을 허용하려면 허용할 도메인의 이름을 공백으로 분리하여 추가한다.
웹 브라우저로부터 ~userid를 요청받았을 때, 사용자의 홈 디렉토리 뒤에 추가될 디렉토리의 이름을 지정한다. 예를 들어 아래와 같이 지정한 경우 http://www.linuxone.co.kr/~userid라는 URL은 사용자의 홈 디렉토리에 public_html 디렉토리내에 존재하는 index.html 파일을 불러오게 된다.
일반적으로 일반 사용자의 홈 계정은 디렉토리 퍼미션을 711로 설정하고 사용자 계정의 홈 디렉토리 아래에 위치하는 public_html 디렉토리는 디렉토리 퍼미션을 755로 설정한다. 그리고 public_html 디렉토리 내의 파일들은 world-readable 퍼미션을 설정해야 한다. 일반적으로 644을 설정하여 world-readable 기능을 설정하는데, 만약 파일 퍼미션을 world-readable로 설정하지 않으면, 클라이언트는 “403 Forbidden" 메시지를 받게 될 것이다.
<IfModule mod_userdir.c>
UserDir public_html
</IfModule>
IfModule은 해당하는 모듈을 아파치가 사용할 수 있는 지를 검사하는 것으로 mod_userdir이라는 모듈이 아파치에 컴파일되어 포함되어 있는지, 또는 DSO로 사용이 가능한지를 검사하고 해당 모듈이 사용 가능할 경우에만 <IfModule>과 </IfModule> 내에 정의된 내용을 실행 가능하게 된다. 만약 httpd –t 명령을 이용해 해당 모듈이 포함되어 있다면 굳이 </IfModule>을 사용하지 않아도 된다.
다음 설정 내용은 UserDir 지시어에 의해 지정된 사용자의 디렉토리에 대한 접근을 제어한다. 즉, 사용자 홈페이지에 대하여 읽기만 가능하도록 한 예제 설정 내용이다.
<Directory /home/*/public_html>
AllowOverride FileInfo AuthConfig Limit
Options MultiViews Indexes SymLinksIFOwnerMatch IncludesNoExec
<Limit GET POST OPTIONS PROPFIND>
Order allow,deny
Allow from all
</Limit>
<LimitExcept GET POST OPTIONS PROFIND>
Order deny,allow
Deny from all
</Limit>
</Directory>
사용자가 URL을 사용할 때 특정 HTML 파일을 지정하지 않고 다음과 같이 http://www.linuxone.co.kr/~userid/와 같이 디렉토리 이름만 지정할 경우에 기본적으로 제공될 HTML 문서를 지정하는 곳이다. 일반적으로 index.html이 이 지시어의 값으로 제시되지만, 다른 이름도 제공할 수 있다. 예를 들어 index.html 파일이 없는 경우 다음으로 웹 서버가 찾을 문서를 지정할 수도 있다. 여러 개의 파일 이름을 나열할 경우에는 공백으로 구분한다.
<IfModule mod_dir.c>
DirectoryIndex index.php3 index.html index.shtml index.cgi
</IfModule>
각 디렉토리에 대한 접근 제어 정보를 담고 있는 파일 명을 지정한다.
AccessFileName .htaccess
다음의 내용은 웹 브라우저나 기타 웹 클라이언트에 의해서 접근하는 것을 막을 때 사용하는 것으로, .htaccess 파일에는 인증 정보가 포함되어 있는 경우가 많기 때문에 보안상의 이유로 인해 접근을 허용하지 말아야 한다. 웹 사이트를 방문하는 사용자들이 .htaccess 파일을 살펴볼 수 있도록 접근을 허용하고 싶은 경우에는 아래의 내용을 주석으로 처리한다. 위의 AccessFileName 지시어의 값을 다른 것으로 변경할 경우에는 변경에 해당하는 내용을 아래에도 반영해야 한다. 아래는 .ht로 시작하는 모든 파일에 대한 내용을 설정했는데, 위의 AccessFileName에서 다른 파일의 이름을 사용한 경우에는 <Files specified_filename>이라고 사용하면 된다.
일반적으로 패스워드를 위한 파일 이름으로는 .htpasswd 파일을 사용하는 경우가 많은데, .htpasswd 파일에 대한 내용도 웹 클라이언트가 접근하지 못하도록 보안을 지켜준다.
즉, 웹 브라우저가 .ht* 파일을 접근할 수 없도록 하는 설정하는 부분으로 .htaccess 파일에는 인증 정보가 있으므로 보안상 이유로 이 파일에 대한 접근을 불허한다.
<Files ~ “^\.ht>
Order allow,deny
Deny from all
</Files>
기본적인 형태의 컨텐츠에 대해서는 “Pragma: no-cache”라는 내용을 웹 서버에서 기본적으로 전송해서 프록시 서버로 하여금 문서의 내용을 캐시하지 않도록 지정한다. 만약 아래의 지시어가 주석 처리 되지 않는다면 모든 캐시가 해당 컨텐츠가 프록시 서버에 저장되어 사용자의 요구가 있을 때 빠른 전송이 가능하도록 한다. 하지만 특정 파라미터에 의해 컨텐츠의 내용이 변경되는 것이 많다면 컨텐츠가 프록시에 저장되지 않도록 아래의 지시어를 주석처리하는 것이 좋다.
CacheNegotiateDocs
아래의 지시어는 1.3 버전에 처음 등장한 것으로, 이 설정을 켜두게 되면 아파치가 자기 참조 URL(데이터가 오고 있는 서버를 다시 가리키는 URL)을 만들 필요가 있을 때마다 “공식적인” 이름을 만들기 위해 ServerName과 Port를 사용하도록 한다. 그렇지 않고, 이 설정을 꺼두게 되면 아파치 웹 서버는 클라이언트가 제공한 호스트:포트 값을 사용하게 된다. 이설정은 CGI 스크립트의 SERVER_NAME과 SERVER_PORT에도 영향을 미치게 된다.
UseCanonicalName On
아래의 지시어는 mime.types 파일 혹은 이에 상응하는 파일의 위치를 지정할 때 사용한다. 즉, TypeConfig는 mime.types 파일 또는 이에 해당하는 파일을 찾을 위치를 결정한다.
<IfModule mod_mime.c>
TypesConfig /etc/mime.types
</IfModule>
파일 확장자와 같은 것을 이용해서 파일의 MIME 타입을 결정할 수 없는 문서에 대해 기본적으로 사용할 MIME 타입을 말한다. 만약 서비스하고 있는 서버가 텍스트 파일이나 HTML 문서가 대다수라면 “text/plain”이 적절하다. 하지만 서버에 탑재되어 서비스되고 있는 대부분이 응용 프로그램이나 이미지와 같은 바이너리라면 “application/octet-stream”을 사용하는 것이 좋다. 그렇지 않으면 웹 브라우저가 바이너리 파일을 마치 텍스트 파일처럼 생각하고 브라우저의 화면에 알 수 없는 문자들을 나열하게 된다.
DefaultType text/plain
mod_mime_magic 모듈은 파일의 MIME 타입을 결정하기 위해서 파일 자체의 컨텐츠를 이용하도록 허용하는 것으로, MIMEMagicFile 지시어는 해당 파일들에 대한 힌트를 어디에서 읽어올 것인가를 지정한다. mod_mime_magic 모듈은 기본 웹 서버의 일부분이 아니기 때문에 LoadModule을 이용해서 웹 서버가 시작할 때 메모리에 탑재시키거나 configure를 실행시킬 때 mod_mime_magic을 포함하도록 설정하는 것이 좋다. 참고로 configure를 이용할 경우에는 아래와 같이 <IfModule> 컨테이너에 의해서 둘러싸여지게 된다. 이는 mod_mime_magic 모듈이 웹 서버의 일부분으로 포함된 경우에만 MIMEMagicFile이 제대로 동작하게 된다.
<IfModule mod_mime_magic.c>
MIMEMagicFile conf/magic
</IfModule>
HostnameLookups 지시어는 클라이언트의 이름이나 클라이언트의 IP 주소를 기록하는 것을 설정한다. 값이 OFF인 경우에는 IP 주소(204.62.129.132)가 기록되고, 값이 ON인 경우에는 호스트의 이름(www.edu00.net)이 기록된다. 기본 값은 OFF이며, 이는 ON으로 설정한 것보다 유리한데, 이유는 호스트의 이름을 기록할 경우에는 적어도 한번은 네임 서버를 거쳐야 하기 때문에 굳이 필요한 경우가 아니라면 ON으로 설정하지 않는 것이 좋다. 즉, 기본값이 Off인 이유는 각 클라이언트 요청이 올 때마다 최소한 1번 이상의 네임서버 요청이 발생하기 때문이다
HostnameLookups Off
에러 로그를 기록할 파일의 위치를 지정하는 것으로, <VirtualHost>에서 ErrorLog 지시어가 사용되지 않았다면, 가상 호스트와 관련된 오류 메시지가 여기에 지정된 파일에 기록된다. <VirtualHost>에서 에러 로그 파일의 위치를 지정했다면, 여기서 지정한 로그 파일은 가상 호스트와 관련된 오류 내용이 기록되지 않는다.
ErrorLog logs/error_log
오류 로그 파일에 기록할 오류의 종류를 제어하는 것으로, 사용 가능한 값들은 debug, info, notice, warn, error, crit, alert, emerg 등이 있으며 저수준 레벨부터 기록되어 있다.
Loglevel warn
LogFormat 지시어는 아래의 CustomLog 지시어에서 사용하게 될 몇 가지 형식에 대한 별명을 지정하는 것이다.
LogFormat "%h %1 %u %t \"%h\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%h %l %u %t \"%r\" %>s %b" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent
위에서 사용된 로그 포맷 문자들에 대한 간단한 설명은 다음과 같다.
%a : 원격 클라이언트의 IP 주소를 기록
%A : 웹 서비스가 수행중인 서버, 즉 로컬 시스템의 IP 주소
%B : HTTP 헤더를 제외하고 전송된 Bytes 수
%b : HTTP 헤더를 제외하고 전송된 바이트 수를 기록하지만, 아무것도 전송이 되지 않은 경우에는
0 대신에 “-“가 기록된다.
%c : 서버 응답이 끝났을 때의 연결 상태를 기록하는데, “X”의 경우에는 서버의 응답이 끝나기 전에 중단된 것을, “+”는 서버 응답이 끝난 후에도 연결이 지속되는 것을, “-“는 응답이 전송된 후 연결을 닫아 버린 것을 의미한다.
%{FOOBAR}e : 환경 변수인 "FOOBAR"의 내용을 기록
%f : 파일 이름
%h : 원격 호스트(클라이언트) 이름
%H : 클라이언트가 요청한 프로토콜
%{FOOBAR}i : FOOBAR의 내용(서버에 전송된 요청의 헤더)
%l : 원격의 로그인 네임(identd 데몬의 사용이 가능한 경우로 한정)
%m : 요청 방법(GET, POST)
%{FOOBAR}n : 다른 모듈로부터의 FOOBAR 노트의 내용
%{FOOBAR}o : 응답에서 헤더라인의 FOOBAR 내용
%p : 요청에 대해서 서비스하는 포트의 공식 번호
%P : 요청을 처리하는 웹 서버의 자식 프로세스의 ID(PID)
%q : QueryString(URL에서 ?이후에 추가되는 내용)이 존재한다면 이 내용을 기록하게 되는데, 만약 존재하지 않는다면 공백으로 남게 된다.
%r : 요청의 첫줄을 기록
%s : 요청의 상태 코드, 마지막의 상태 코드를 기록할 경우에는 %>s
%t : 시간 포맷, [일/월/년:시간:분:초 time-zone]
%{format}t : 주어진 형식으로 시간에 대한 기록
%T : 요청에 대해 소요된 서비스 시간을 초단위로 기록
%u : 인증에 의한 클라이언트 사용자를 기록
%U : 요청한 URL 경로
%v : 클라이언트 요청에 대한 서버의 canonical ServerName
%V : UserCanonicalName 설정에 따른 서버 네임
접근 로그 파일의 위치와 형식(위의 LogFormat 지시어에 의해서 별명을 common으로 지정한 것)을 지정한다. 만약 <VirtualHost> 컨테이너 내에서 접근 로그 파일을 지정하지 않았다면 에러 로그 파일처럼 이곳에 기록된다. 만약 <VirtualHost> 내에서 접근 로그 파일의 위치를 지정했다면 이곳에는 기록되지 않고 지정된 파일에 기록된다.
CustomLog logs/access_log common
만약 에이젼트 로그 파일과 참조자(referer) 로그 파일을 갖기 위해서는 다음의 주석을 해제한다.
에이젼트란 사이트에 방문하는 브라우저를 의미하며 에이젼트 로그를 남기면 사이트에 방문하는 브라우저의 종류에 대한 통계를 낼 수 있다. 그리고 참조자란 배너 광고주에게 중요한 것으로 사이트 바로 직전에 방문한 사이트를 의미한다.
#CustomLog logs/referer_log referer
#CustomLog logs/agent_log agent
만약 접근 로그와 에이전트 로그, 참조자 정보를 하나의 파일에 저장하고자 할 경우(위의 LogFile에서 combined로 정의된 것)에는 다음과 같이 combined 별명을 사용한다. 하지만 접속이 많은 사이트에서 combined 로그 파일이 커져서 root 파일 시스템을 채워버리기도 한다.
#CustomLog logs/access_log combined
서버가 생성하는 페이지(오류 문서, FTP 디렉토리 리스팅, mod_status와 mod_info 출력 등)에 부가적으로 서버의 버전과 가상 호스트의 이름을 포함하는 줄을 포함시키도록 한다(CGI가 생성한 문서는 제외). Email로 설정한 경우에는 ServerAdmin에서 설정된 내용이 mailto: 로 된 링크를 포함하게 된다. 지시어의 값으로는 On, Off, Email 등이 사용된다.
ServerSignature On
다음은 별칭을 생성하는 것으로, 생성된 별칭은 제한이 없다. 사용하는 형식은 다음과 같다.
Alias 별칭 실명
<IfModule mod_alias.c>
만약 별칭의 끝에 “/”를 포함할 경우에는 아파치 서버는 실제 URL에서도 반드시 “/”를 포함시켜야 한다. 그렇기 때문에 “/icons”는 별칭으로 처리되지 않고, “/icons/”만이 별칭 처리된다. 만약 별칭을 아래와 같이 설정했다면(DocumentRoot가 /var/www/html로 설정되었고, html 디렉토리 아래에는 icons 디렉토리가 없음에도 불구하고 해당 URL은 다음과 같이 사용할 수 있다.
Alias /icons/ "/var/www/html/icons/"
<Directory "/var/www/html/icons">
Options Indexes MultiViews
AllowOverride None
Order allow,deny
Allow from all
</Directory>
ScriptAlias 지시어는 서버 스크립트를 포함하고 있는 디렉토리를 지정할 때 사용하는 것으로, Alias 항목에서 사용되는 실명 부분만이 다르고 나머지는 Alias와 동일하다. 실명 부분에 설정되는 내용은 클라이언트에 보내는 문서라고 하기 보다는 서버측에서 수행되는 응용 프로그램이 저장된 디렉토리를 지정한다. 즉, ScriptAlias는 근본적으로 Alias와 같으나 가리키고 있는 실제 디렉토리 안에 들어있는 문서를 프로그램을 취급하여 실행하며 맨 뒤에 붙는 "/"에 대한 규칙은 Alias와 같다.
ScriptAlias /cgi-bin/ "/var/www/html/cgi-bin/"
“/var/www/html/cgi-bin” 부분은 ScriptAlias로 별칭 처리된 실제 CGI 디렉토리로 지정되어야 한다.
<Directory "/var/www/html/cgi-bin">
AllowOverride None
Options None
Order allow,deny
Allow from all
</Directory>
</IfModule>
Alias 설정은 여기까지이다.
Redirect를 사용하면 과거에는 존재했으나 현재에는 운영하는 서버에 존재하지 않는 문서에 대하여 클라이언트에게 통보해줄 수 있다. 또한 다른 곳에 위치한 문서를 클라이언트에게 통보하기도 한다.
사용 형식은 Redirect old-URL new-URL을 따른다.
서버가 생성하는 디렉토리 목록을 브라우저 화면에 출력할 것인지를 제어하는 지시어가 시작된다.
<IfModule mod_autoindex.c>
FancyIndexing은 예쁜 디렉토리 목록 또는 표준적인 디렉토리 목록을 출력할지 여부를 결정한다.
IndexOptions FancyIndexing
AddIcon으로 시작하는 지시어는 웹 서버에게 다양한 파일과 파일 이름의 확장자에 대하여 어떤 아이콘을 보여 줄 것인지를 의미하는 것으로, 이 값들은 앞에서 FancyIndexing을 사용한 경우에만 해당된다.
압축된 파일에 대한 아이콘을 지정한다.
AddIconByEncoding (CMP,/icons/compressed.gif) x-compress x-gzip
텍스트, 이미지, 소리, 비디오 파일들에 대한 아이콘을 지정한다.
AddIconByType (TXT,/icons/text.gif) text/*
AddIconByType (IMG,/icons/image2.gif) image/*
AddIconByType (SND,/icons/sound2.gif) audio/*
AddIconByType (VID,/icons/movie.gif) video/*
AddIcon /icons/binary.gif .bin .exe
AddIcon /icons/binhex.gif .hqx
AddIcon /icons/tar.gif .tar
AddIcon /icons/world2.gif .wrl .wrl.gz .vrml .vrm .iv
AddIcon /icons/compressed.gif .Z .z .tgz .gz .zip
AddIcon /icons/a.gif .ps .ai .eps
AddIcon /icons/layout.gif .html .shtml .htm .pdf
AddIcon /icons/text.gif .txt
AddIcon /icons/c.gif .c
AddIcon /icons/p.gif .pl .py
AddIcon /icons/f.gif .for
AddIcon /icons/dvi.gif .dvi
AddIcon /icons/uuencoded.gif .uu
AddIcon /icons/script.gif .conf .sh .shar .csh .ksh .tcl
AddIcon /icons/tex.gif .tex
AddIcon /icons/bomb.gif core
AddIcon /icons/back.gif ..
AddIcon /icons/hand.right.gif README
AddIcon /icons/folder.gif ^^DIRECTORY^^
AddIcon /icons/blank.gif ^^BLANKICON^^
DefaultIcon 지시어는 명시적인 아이콘을 갖고 있지 않는 파일에 대한 기본 아이콘을 설정한다. 즉, 위에서 언급되지 않은 파일들에 대한 아이콘을 보여주기 위해서 사용하는 지시어이다.
DefaultIcon /icons/unknown.gif
AddDescription 지시어는 서버측에서 보여지는 디렉토리 목록에서 각각의 파일 오른쪽에 간략한 설명을 위치시키기 위한 것으로, 이 항목은 FancyIndexing이 지정된 경우에만 사용이 가능하다.
사용 형식은 AddDescription "설명" file명을 따른다.
#AddDescription "GZIP compressed document" .gz
#AddDescription "tar archive" .tar
#AddDescription "GZIP compressed tar archive" .tgz
ReadmeName 지시어는 서버가 기본적으로 찾아서 디렉토리 목록 다음에 내용을 덧붙여 넣을 README 파일의 이름을 설정한다.
HeaderName 지시어는 디렉토리 index 앞에 내용을 덧붙일 파일명을 설정한다.
다양한 옵션 중에서 MultiViews가 동작중인 경우에는, 서버측에서 name.html(ReadmeName, HeaderName 지시어에서 지정된 파일 이름이 name인 경우)이란 파일을 먼저 찾게 된다. 이 파일을 찾았다면, 이 파일의 내용을 출력하게 되고, 만약 이 파일을 찾지 못했다면 name.txt 파일을 찾아서 앞뒤로 붙이게 된다.
ReadmeName README.html
HeaderName HEADER.html
IndexIgnore 지시어는 디렉토리 index를 출력할 때 출력된 목록에서 제외시킬 파일명을 설정하는 지시어로, 쉘에서 사용할 수 있는 와일드 카드 문자를 사용할 수 있다.
IndexIgnore .??* *∼ *# HEADER* README* RCS CVS *.v *.t
</IfModule>
Indexing과 관련된 지시어의 끝이다.
문서의 형식과 관련된 내용을 정의
<IfModule mod_mime.c>
AddEncoding은 특정 브라우저(Mosaic/X 2.1+)로 하여금 자료를 다운로드 받는 것과 동시에 압축을 해제할 수 있도록 하기 위함이다. 주의할 점은 모든 브라우져가 이 기능을 지원하는 것은 아니라는 것이다. 이름이 유사할지라도 이후에 지정될 Add로 시작하는 지시어들은 FancyIndexing과는 관련이 없다.
AddEncoding x-compress Z
AddEncoding x-gzip gz
AddLanguage 지시어는 문서를 제작할 때 사용할 언어를 지정한다. 이는 컨텐츠를 브라우저에게 보낼 때 브라우저가 이해할 수 있는 언어로 제작된 내용을 제공하게 된다. 여기에 몇 가지 주의할 사항이 있는데, 첫째는 지정할 때 사용하는 접미어(suffix)는 반드시 언어를 나타내는 keyword와 꼭 같을 필요는 없다. 예를 들어 폴란드어(Polish)로 된 문서는 network 표준 언어 코드가 pl이지만 perl script와 확연히 구별하기 위해 "AddLanguage pl .po"라고 사용한다.
AddLanguage en .en
AddLanguage fr .fr
AddLanguage de .de
AddLanguage da .da
AddLanguage el .el
AddLanguage it .it
LanguagePriority 지시어는 브라우저와 서버 사이에 컨텐츠 교섭시 어떤 언어를 먼저 처리할 것인지를 결정할 때 사용하게 된다. 여기서는 단지 우선 순위에 맞추어 언어를 기록하면 되는데, 우선 순위가 높은 것부터 차례로 기록하면 된다. 또한 이 순위를 변경할 수 있으며, 일반 웹 사이트에서는 크게 사용되지 않고 있다.
<IfModule mod_negotiation.c>
LanguagePriority en fr de
</IfModule>
AddType 지시어를 사용하면 mime.types 파일의 실질적인 수정 없이도 MIME 설정을 할 수 있고 특정 파일에 대해서는 지정된 타입을 적용시킬 수 있다.
다음은 PHP4 모듈을 사용하기 위한 설정이다.
<IfModule mod_php4.c>
AddType application/x-httpd-php .php4 .php3 .phtml .php .html
AddType application/x-httpd-php-source .phps
</IfModule>
다음은 PHP3 모듈을 사용하기 위한 설정이다.
<IfModule mod_php3.c>
AddType application/x-httpd-php3 .php3
AddType application/x-httpd-php3-source .phps
</IfModule>
다음은 PHP/FI (PHP2)모듈을 사용하기 위한 설정이다.
<IfModule mod_php.c>
AddType application/x-httpd-php .phtml
</IfModule>
AddType application/x-tar .tgz
MS 계열의 운영체제에서 사용할 경우에 .htm을 지원하기 위해
AddType text/html.htm
을 사용하면 된다. 또한, 많은 사람들이 MS 계열의 운영체제에서 작업한 후 리눅스나 유닉스 계열의 웹 서버에 탑재하는 경우가 많아서 index.htm이라고 파일명을 부여하고는 파일이 제대로 보이지 않는다고 하는 경우가 많은데, 이 경우 관리자는 파일이름을 index.html로 변경시키거나 만약 다른 파일들에서 index.htm을 참조하는 경우가 많다면 DirectoryIndex 지시어 다음에 index.htm을 추가하는 것도 한 방법이다.
AddHandler 지시어의 경우에는 특정한 파일 확장자와 이를 처리할 수 있는 핸들러("처리기")를 연결하거나 특정 파일 타입에 특정 동작(action)을 연결하는 데 사용할 수 있다. 이 내용은 서버에 내장되어 있거나 또는 Action 명령을 사용하여 추가할 수 있다.
만약 SSI(Server Side Include) 또는 ScriptAlias에서 지정된 디렉토리 이외의 영역에서 CGI를 사용하고 싶을 때 다음의 주석을 해제한다.
CGI 스크립트를 사용하기 위해서는 아래와 같이 한다.
AddHandler cgi-script .cgi
하지만 AddHandler cgi-script .cgi를 설정하게 되면 보안상 심각한 위험에 처해질 수 있다. 즉, 고의든 아니든 CGI 프로그램이 잘못 실행될 경우, 시스템 내부의 정보가 외부로 흘러 나갈 수 있기 때문이다. 그렇기 때문에 실행 가능한 CGI 프로그램은 반드시 cgi-bin 디렉토리에 두는 것이 좋다.
서버측에서 처리된 HTML 파일을 처리하기 위해서는 아래처럼 사용한다.
AddType text/html .shtml
AddType text/html .htm
AddHandler server-parsed .shtml
아파치의 send-asis HTTP 파일 기능을 사용하기 위해서는 다음 행의 주석을 없앤다.
AddHandler send-asis-is asis
서버측에서 처리된 이미지 map 파일을 사용하기 위해서는 다음을 사용한다.
AddHandler imap-file map
type map을 사용하기 위해서는 아래의 주석을 없앤다.
AddHandler type-map var
</IfModule>
문서와 관련된 설정 사항의 끝
Action 지시어는 해당되는 파일이 호출될 때마다 실행되는 스크립트의 미디어 타입을 지정할 수 있다. 이는 빈번하게 사용되는 CGI 파일 프로세스에 대하여 반복적으로 URL을 사용하지 않아도 된다.
Format: Action media/type /cgi-script/location
Format: Action handler-name /cgi-script/location
MetaDir 지시어는 메타 정보를 저장하고 있는 파일을 찾을 수 있는 디렉토리 위치를 지정할 때 사용하는 지시어이다. 메타 파일은 문서를 보낼 때 추가하고자 하는 추가 HTTP 헤더 정보가 포함되어 있다.
MetaDir .web
MetaSuffix 지시어는 meta 정보를 담고 있는 파일의 접미어(혹은 확장자)를 설정한다.
MetaSuffix .meta
사용자 정의 에러 반응 메시지(아파치 스타일) 3가지 방법
1) 단순한 보통의 text
ErrorDocument 500 "The server made a boo boo.
주의할 것은 "(따옴표) 표시는 text임을 알려주는 것으로서 브라우저 화면에 출력되지 않는다.
2) 지역적인 방향 전환
ErrorDocument 404 /missing.html
지역적 URL인 /missing.html로 방향을 전환한다.
ErrorDocument 404 /cgi-bin/missing_handler.pl
주의할 점은 스크립트나 SSI로 방향전환이 가능하다는 것이다.
3) 외부로의 방향 전환
ErrorDocument 402 http://some.other_server.com/subscription_info.html
주의할 것은 원래의 요청과 관련 있는 환경변수의 상당수가 스크립트에 제대로 전달되지 못한다는 것이다.
브라우저와 관련된 행위를 사용자가 임의로 정의할 수 있다.
<IfModule mod_setenvif.c>
이후의 지시자들은 보통의 HTTP 반응 방식을 변경할 수 있다.
첫 번째 지시어는 Netscape 2.x 또는 그를 흉내내는 브라우저에 대하여 KeepAlive 기능을 사용하지 않도록 막는다. 왜냐하면 이들 브라우저들은 KeepAlive 구현에 문제가 많기 때문이다.
두 번째 지시어는 MSIE 4.0b2를 위한 것으로 MSIE 4.0b2 버전의 브라우저는 HTTP/1.1을 잘못 구현하였고 301 또는 302(재지향) 응답에 대하여 KeepAlive를 제대로 지원하지 못하기 때문이다.
BrowserMatch "Mozilla/2" nokeepalive
BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-response-1.0
다음은 기본적인 HTTP/1.1에 대한 기준을 제대로 제공하지 못하고 응답도 제대로 처리하지
못함으로서 HTTP/1.1 spec을 위반하고 있는 브라우저에 대하여 HTTP/1.1 응답을 하지 않도록 한다.
BrowserMatch "RealPlayer 4\.0" force-response1.0
BrowserMatch "Java/1\.0" force-response-1.0
BrowserMach "JDK/1.\.0" force-response-1.0
<IfModule>
다음은 홈페이지를 퍼가는 웹 로봇을 막아주는 설정이다.
BrowserMatch "WebZIP" go_out
BrowserMatch "Teleport" go_out
BrowserMatch "GetRight" go_out
만약 perl module이 인스톨되었다면 다음의 주석을 해제해서 활성화한다.
<IfModule mod_perl.c>
Alias /perl/ /var/www/perl/
<Location /perl>
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
</Location>
</IfModule>
Netscape Gold의 공식적인 특성같은 http put을 허용한다.
/etc/httpd/conf/passwd 파일을 생성하기 위해 htpasswd를 사용한다.
LoadModule put_module modules/mod_put.so
AddModule mod_put.c
Alias /upload /tmp
<Location /upload>
EnablePut On
AuthType Basic
AuthName Temporary
AuthUserFile /etc/httpd/conf/passwd
EnableDelete Off
umask 007
<Limit PUT>
require valid-user
</Limit>
</Location>
http://servername/server-status을 통해서 서버의 상태를 볼 수 있도록 허용할 것인지를 말하는 것으로, 아래의 ".your_domain.com" 부분을 실제 사용자들이 서비스할 사이트의 domain 이름으로 바꿔서 사용한다.
<Location /server-status>
SetHandler server-status
Order deny,allow
Deny from all
Allow from .your_domain.com
</Location>
아래의 내용은 원격에서 http://servername/server-info라는 URL을 통하여 원격 서버의 설정을 보고 받을 수 있도록 환경을 설정한다. 하지만 이 기능을 제대로 사용하기 위해서는 mod_info.c가 적재되어 있어야 한다. 아래에서 ".your_domain.com" 부분을 사용자가 관리하고 허용할 domain으로 바꿔서 사용한다.
<Location /server-info>
SetHandler server-info
Order deny,allow
Deny from all
Allow from .your_domain.com
</Location>
로컬 호스트에서 로컬 시스템 문서에 대한 접근을 허용한다.
Alias /doc/ /usr/share/doc/
<Location /doc>
order deny,allow
deny from all
allow from localhost .localdomain
Options Indexes FollowSymLinks
</Location>
1.1 버전 이전에서 발견된 오래된 버그를 이용해 공격하려는 사람들이 있는데, 이런 버그는 아파치의
일부분으로 제공한 CGI 스크립트의 일부분과 연관이 있다. 아래의 주석을 해제하면, 이 버그를
악용하는 공격이 있을 때 phf.apache.org상의 로그로 방향을 전환할 수 있다. 그렇지 않으면
아래의 support/phf_abuse_log.cgi 스크립트를 이용해 사용자들이 직접 기록할 수도 있다.
<Location /cgi-bin/phf*>
Deny from all
ErrorDocument 403 http://phf.apache.org/phf_abuse_log.cgi
</Location>
다음은 프록시 서버와 관련된 지시어다. 다음 행의 주석을 해제함으로써 프록시 서버의 기능을 작동시킬 수 있다.
<IfModule mod_proxy.c>
ProxyRequests On
<Directory proxy:*>
Order deny,allow
Deny from all
Allow from .your_domain.com
</Directory>
HTTP/1.1 "Via:" 헤더를 처리할 것인지 여부를 결정한다. 옵션으로 사용되는 "Full"은 서버의 버전을 포함하고, "Block"은 나가는 모든 자료에서 Via: 헤더를 제거하고 데이터를 내보내게 된다.
Off | On | Full | Block 중 하나를 지정한다.
ProxyVia On
캐시를 활성화하기 위해서는 다음의 줄에서 주석을 해제하고, 적절하게 편집한다.
CacheRoot가 없으면 캐쉬가 동작하지 않는다.
CacheRoot "/var/cache/httpd"
CacheSize 5
CacheGcInterval 4
CacheMaxExpire 24
CacheLastModifiedFactor 0.1
CacheDefaultExpire 1
NoCache a_domain.com another_domain.edu joes.garage_sale.com
</IfModule>
프록시 설정 끝
섹션 3: Virtual Host ( 가상 호스트)
리눅스 박스에서 여러 개의 도메인이나 호스트 이름을 관리하고 싶다면 각각에 대하여 VirtualHost
컨테이너를 이용하면 된다. 대부분의 설정에서 이름 기반의 가상 호스트(IP 주소의 부족으로 인해 하나의 IP 주소에 대해 여러 개의 도메인 이름을 부여하여 사용하는 방법. 반면에 하나의 시스템이 여러 개의 IP 주소를 갖고 각각의 IP 주소별로 도메인 이름을 부여하는 방법을 IP 기반 가상 호스트라고 한다.)를 사용하기 때문에 서버는 IP 주소에 대하여 염려할 필요는 없다. 가상 호스트의 설정 내용을 점검하기 위해서는 명령행 상에서 –S 옵션을 이용한다.
이름 기반의 가상 호스트를 사용하려면 사용할 IP 주소(최소 1개와 포트 번호)를 정의해주어야 한다.
먼저 가상 호스팅에 사용할 IP 주소를 NameVirtualHost 지시어를 사용해서 선언을 먼저 해주어야 한다. 만약 특정 포트를 사용하고자 한다면 IP 주소:포트 형식으로 사용하면 된다.
NameVirtualHost 211.170.43.119
NameVirtualHost 211.170.43.119:8001
아파치의 사용되는 거의 모든 지시어가 VirtualHost 컨테이너에 올 수 있다. 만약 사용자가 알려진 서버의 이름을 사용하지 않고 요구를 할 때 가상 호스트의 첫 부분이 사용된다.
다음은 기본적으로 제공되는 가상 호스트 구성 형식이다.
<VirtualHost ip.address.of.host.some_domain.com>
ServerAdmin webmaster@host.some_domain.com
DocumentRoot /www/docs/host.some_domain.com
ServerName host.some_domain.com
ErrorLog logs/host.some_domain.com-error_log
CustomLog logs/host.some_domain.com-access_log common
</VirtualHost>
<VirtualHost _default_:*>
</VirtualHost>
디렉토리의 속성을 분명히 명시한다. 이는 web이 보여지는 디렉토리에 대한 설정이다.
<Directory "/var/www/html/linuxone">
Options IncludesNoExec ExecCGI
AllowOverride None
Order allow,deny
Allow from all
Deny from env=go_out
</Directory>
2. Virtual Hosting
가상 호스팅이란 하나의 호스트에 둘 이상의 웹 서비스를 운영하는 방법이다. 가상 호스팅에는 IP 기반과 이름 기반, 그리고 port 기반의 호스팅으로 이루어지며, IP 기반 가상 호스팅이란 하나의 호스트가 둘 이상의 NIC(Network Interface Card)를 가지고 있어서 각각의 IP 주소별로 서비스를 수행하는 것을 말한다. 반면에 이름 기반 호스팅이란 IP 주소가 한 개거나 서비스별로 충분한 IP 주소를 확보하지 못한 상태에서 IP 주소를 공유하여 둘 이상의 사이트를 운영하는 것이다. 그리고 포트 기반의 호스팅은 하나의 웹 서버스의 테스트 및 긴급 상황시에 많은 사이트를 운영할 수 있다.
1) Name-Based Virtualhosting
한 개의 IP를 가지고 여러 호스트의 웹 서비스를 하고자 할 경우 사용하는 방법이다. 적은 IP로 여러 개의 웹 서비스를 하고자 할 경우 적당한 방법이다. 주의할 점은 네임 서버에서 각각의 가상 호스트에 대해 CNAME을 지정해주어야 한다. 이 경우 로컬 DNS 설정이 문제가 되므로 DNS 서버 관리자에게 문의하는 것이 좋다. 이 방식은 어디까지나 DNS에 기반하여 구축된다는 사실에 유의하자.
이름 기반의 가상 호스팅은 여러 개의 IP 주소가 필요없기 때문에 부족한 IP 주소에 대한 대안도 될 수 있을 것이다. 또한 <VirtualHost> 컨테이너 내에 반드시 ServerName 지시어가 포함되어 있어야 한다. 그리고 가상 호스팅을 사용할 IP 주소가 어떤 것인지를 가리키는 NameVirtualHost라는 지시어를 꼭 사용해야 한다.
그리고 대규모의 가상 호스팅을 위해서는 아파치에서 제공하는 기본적인 호스팅을 사용하지 말고, mod_vhost_alias 모듈을 이용하는 것이 좋다. 그렇지 않을 경우 관리자가 일일이 설정을 해야 하는 사태가 발생한다.
[root @edu00 linux]#vi /etc/httpd/conf/httpd.conf
NameVirtualHost 192.168.10.10
<VirtualHost 192.168.10.10>
ServerAdmin root@localhost
DocumentRoot /home/edu00
ServerName edu00.net
ErrorLog logs/error_log
TransferLog logs/access_log
</VirtualHost>
<VirtualHost 192.168.10.11>
ServerAdmin root@localhost
DocumentRoot /home/dream1
ServerName edu01.net
ErrorLog logs/error_log
TransferLog logs/access_log
</VirtualHost>
[root @edu00 linux]#/usr/sbin/httpd -t
[root @edu00 linux]# cd /home
[root @edu00 /home]# mkdir dream
[root @edu00 /home]# mkdir dream1
[root @edu00 /home]#cd dream
[root @edu00 dream]#vi index.html
<h1> edu00.net Virtual Hosting Sample </h1>
[root @edu00 dream]#cd /home
[root @edu00 /home]#cd dream1
[root @edu00 dream1]#vi index.html
<h1> edu01.net hosting sample </h1>
[root @edu00 linux]#vi /etc/hosts
192.168.10.10 edu00.net
192.168.10.11 edu01.net
[root @edu00 linux]#/etc/rc.d/init.d/named restart
[root @edu00 linux]#/etc/rc.d/init.d/httpd restart
[root @edu00 linux]#netscape & http://eduxx.net
[root @edu00 linux]#netscape & http://virt.eduxx.net
web browser에서 http://edu00.net, 그리고 http://edu01.net을 주소 입력창에 입력하고 실행한다.
또는 다음과 같은 방법으로 테스트한다.
[root @edu00 linux]#lynx edu00.net
[root @edu00 linux]#lynx edu01.net
[root @edu00 linux]#lynx -dump http://edu00.net
[root @edu00 linux]#lynx -dump http://edu01.net
2) IP-Based Virtual hosting
대규모의 가상 호스팅을 하려면 가상 호스팅 사이트의 주소만큼이나 많은 IP 주소가 필요하다. 하지만 그렇게 많은 IP 주소를 확보한다는 것은 상당한 무리가 따르기 때문에 현실적으로는 불가능하다고 할 수 있다. 이 경우 사용하는 방법이 한 개의 NIC에 가상의 IP 주소를 부여하는 것이다.
[root @edu00 linux]#ifconfig eth0 192.168.1.1 netmask 255.255.255.0
[root @edu00 linux]#ifconfig eth0:0 192.168.1.2 netmask 255.255.255.0
[root @edu00 linux]#route add -host 192.168.1.2 eth0:0
[root @edu00 linux]#ifconfig
각각의 장치에 할당된 IP 주소를 확인한다. 즉, eth0에는 192.168.1.1, eth0:0에는 192.168.1.2, 그리고 lo에는 127.0.0.1이 할당되어 있는 것을 확인할 수 있을 것이다. 이때 사용자들이 주의할 것은 하나의 하드웨어(Hwaddr: MAC)에 대해 두 개의 IP 주소(192.168.1.1과 192.168.1.2)가 할당되었으며, 두번 째 추가된 것은 eth0:0이라는 인터페이스 이름을 갖게 되었다. 또한 route 명령으로 가상 인터페이스에 대해서도 라우팅 테이블을 추가하였다.
사용자가 주의할 점은 가상 인터페이스는 0번부터 255번까지 모두 256개을 생성할 수 있지만 256개의 IP 주소를 하나의 NIC에 부여하여 인터넷 서비스를 하겠는가. NIC가 이를 감당할 수 없을 것이다. 그리고 또 하나 주의할 것은 이런 가상 인터페이스는 시스템이 재부팅하게 되면 관련 정보가 모두 사라진다는 것이다. 이러한 것을 방지하기 위해서 관련 스크립트를 생성하여 부팅될 때마다 다시 시작할 수 있도록 설정하는 것이다. 즉 /etc/sysconfig/network-scripts/ifcfg-eth0 파일을 /etc/sysconfig/network-scripts/ifcfg-eth0:0으로 복사해서 수정한 후에 사용할 수 있을 것이다.
가상 인터페이스에 대한 설정이 끝났다면 DNS 설정과 /etc/httpd/conf/httpd.conf 설정을 추가하면 된다. 이때 주의할 점은 이름 기반 가상 호스팅에서 사용되는 NameVirtualHost 지시어는 사용하지 않는다는 것이다.
[root @edu00 linux]#vi /etc/httpd/conf/httpd.conf
# NameVirtualHost
<VirtualHost 192.168.1.1>
ServerAdmin root@localhost
DocumentRoot /home/edu
ServerName www.edu.net
ErrorLog logs/www.edu.net.error_log
TransferLog logs/www.edu.net.access_log
</VirtualHost>
<VirtualHost 192.168.1.2>
ServerAdmin na@linux.com
DocumentRoot /home/linux
ServerName edu.linux.net
ErrorLog logs/edu.linux.net.error_log
TransferLog logs/edu.linux.net.access_log
</VirtualHost>
3. 사용자 인증
특정 문서에 대해서 사용자의 접근을 제한하는 방법은 크게 두가지가 존재하는데, 첫번째는 클라이언트가 속한 도메인 이름이나 호스트의 이름을 이용한 방법이고, 두번째는 사용자의 ID와 패스워드를 이용하는 방법이다. 전자의 경우는 특정 회사 내(혹은 특정 도메인 내)에서 사용하기 위한 방법이기 때문에 인터넷 서비스를 할 때는 적당하지 않다.
전 세계의 모든 사용자들이 접속해서 사용하는 대신, 특정 문서에 대한 접근을 개별적으로 제한하고 싶을 경우는 후자를 선택하는데, 이를 “사용자 인증”이라고 한다.
1) 사용자 데이터베이스 생성
아파치를 이용해서 기본적인 사용자 인증을 하기 위해서는 가장 먼저 사용자와 패스워드를 포함하고 있는 파일을 생성할 필요가 있다. 보안과 관련되어 있기 때문에 이 파일은 DocumentRoot로 지정된 곳에 두어서는 안된다.
사용자 데이터베이스 파일은 사용자의 계정 이름과 패스워드의 목록을 가지고 있으며, 형식은 /etc/passwd 파일과 유사하게 사용자 이름과 패스워드가 콜론(:)으로 구분되어 저장된다. 하지만 이 파일을 생성할 때 단순히 입력만 해서 되는 것은 아니다. 왜냐하면 패스워드는 암호화되어 저장되기 때문이다.
이 파일을 위해서 사용되는 프로그램이 htpasswd라는 것으로, 사용자 데이터베이스 파일을 생성하고, 사용자 추가 및 변경 등을 수행할 수 있다. Htpasswd는 아파치의 바이너리가 저장되는 디렉토리(/usr/local/apache/bin/이나 /usr/bin/)에 존재한다. 만약 이 디렉토리에서 htpasswd 파일을 찾을 수 없다면 아파치 소스가 설치된 디렉토리로 이동한 후 make htpasswd 명령을 수행하면 설치가 될 것이다.
2) htpasswd의 사용
새로운 사용자 데이터베이스 파일(/usr/local/apache/htpd/users)를 생성하고, 이 파일에 “nana”라는 사용자를 추가하고, 이 사용자의 패스워드를 “nadream”이라고 지정하기 위해서는 다음과 같은 명령을 수행한다.
#htpasswd –c /usr/local/apache/htpd/users nana
-c 옵션은 htpasswd 명령 실행시 새로운 파일을 생성하도록 한다. 위의 명령을 실행하면 nana라는 사용자의 패스워드를 묻는 프롬프트가 나오게 되고 적절한 패스워드(nadrea)를 입력하면 된다.
다른 사용자를 추가하기 위해서는 앞의 명령에서 –c 옵션만을 제외하고 그대로 사용한다. 뿐만 아니라 기존에 존재하는 사용자의 패스워드를 변경하기 위해서도 앞의 명령을 그대로 사용할 수 있다.
몇몇 사용자를 추가한 후 /usr/local/apache/htpd/users 파일을 확인해보면 다음과 같이 사용자 ID와 비밀번호가 콜론으로 구분되어 있음을 확인할 수 있다.
nana:c0vg85/wDXoX2
dabang:glY3GfbWED4jw
edu00:t1Bnm52HJsKNw
3) 서버의 설정
앞에서 생성한 파일을 웹 서버에서 사용하기 위해서는 영역을 지정해줘야 한다. 이 영역은 사용자 데이터베이스 파일에 기록된 사용자들에게 접근을 국한시키게 된다. 또한 이런 인증은 각각의 디렉토리(물론 하위 디렉토리는 포함하며, 1.2 버전 이후는 각각의 파일별로 제한할 수 있다)에 제한되다. 제한을 하고 싶은 디렉토리에 .htaccess 파일을 생성하거나 httpd.conf 파일(혹은 오래된 버전인 경우 access.conf 파일)에 <Directory> 영역을 편집한다.
.htaccess 파일 내에서 제한하기 위해서는 먼저 httpd.conf 파일에서 .htaccess 파일을 이용해서 사용자 인증을 받도록 지정해야 하는데, 이는 AuthConfig 지시어를 이용해서 설정할 수 있다. 즉, AllowOverride AuthConfig를 인증받고 싶은 디렉토리 영역내에 지정한다.
앞에서 생성한 users 파일을 이용해서 특정 디렉토리를 제한하고 싶은 경우 다음의 내용을 포함하는 .htaccess 파일을 생성한다.
AuthName “restricted stuff”
AuthType Basic
AuthUserFile /usr/local/etc/httpd/users
Require valid-user
AuthName 지시어는 보호를 원하는 영역의 이름을 지정한다. 제대로 인증된 사용자가 들어올 경우, 동일한 영역의 이름을 가진 자원은 제대로 인증을 거친 사용자에 의해서 접근이 허용된다. 이는 동일한 영역 이름을 갖는 둘 이상의 영역을 특정 사용자가 인증을 받게 되면 모두 사용할 수 있도록 허용할 경우에 이용하면 유용하다.
AuthType 지시어는 어떤 프로토콜을 이용해서 사용자 인증을 할 것인지를 결정하는 것으로, 현재로는 Basic만이 가능하다. 하지만 새로운 인증 프로토콜인 Digest(표준화 진행중)를 사용하게 되면 Basic에 비해 좀 더 안전한 인증을 제공하게 될 것이다.
AuthUserFile은 htpasswd 파일에 의해서 생성된 사용자 데이터베이스 파일의 위치를 지정하는 것으로, AuthGroupFile 지시어와 비슷하다.
이상의 세 지시어는(AuthGroupFile을 포함하면 네개)는 사용자 인증에 사용될 파일의 위치와 어떤 프로토콜을 이용할 것인지를 결정한다. 이것들만으로도 허용된 사용자에게 자원을 제한시킬 수 있다. 마지막으로 사용자 데이터베이스에 기록된 사용자 중에서 어떤 사용자가 접근에 부합된 권한을 가지고 있는지를 지정하는 것으로, 이런 기능은 require 지시어를 통해 제어할 수 있다. 위의 예에서 valid-user라는 인자는 사용자 데이터베이스에 저장된 사용자라면 누구나 접근할 수 있음을 의미한다. 만약 특정 사용자를 지칭하려면 다음과 같이 사용한다.
require user nana dabang
위와 같이 지정하면 사용자 데이터베이스에 포함된 nana와 dabang이라는 사용자만이 접근할 수 있다. 만약 require 지시어에 언급되지 않은 사용자(사용자 데이터베이스에는 기록되어 있고)가 정확한 패스워드를 이용해서 인증을 받더라도 접근이 제한되다. 이는 하나의 사용자 데이터베이스 파일을 이용해서 다른 영역을 다른 사용자가 사용할 수 있도록 제한할 수 있어 편리하다.
만약 다른 디렉토리와 이름이 다른 영역에 대해서 접근을 하려고 할 경우에는 사용자는 반드시 두 번 이상의 인증을 거쳐야 한다.
4) 그룹 사용하기
특정 영역에 대해서 사용자 데이터베이스 파일에 등록된 사용자 중에서 몇몇 사용자만을 접근 허용하고 싶은 경우, 각 사용자의 이름을 require 지시어 다음에 나열하면 된다. 하지만 사용자가 많을 경우 이런 방법은 상당히 불편하다. 이를 위해서 그룹 파일을 사용하면 편리한데, 이는 /etc/group 파일과 비슷한 기능을 수행한다. 즉, 어떤 사용자라도 그룹에 포함될 수 있으며, 그 숫자도 제한이 없다. 예를 들어 nana와 dabang을 포함하는 staff라는 그룹을 생성했다면 다음과 같이 간단하게 접근을 차단할 수 있다.
require group staff
아래의 예와 같이 둘 이상의 그룹이 나열될 수 있으며, 동시에 require user도 사용될 수 있다.
require group admin
require user adminuser
그룹 파일은 다음과 같이 그룹의 이름과 콜론, 공백으로 구분된 사용자 이름으로 구성된다.
staff: nana dabang
admin: art adminuser
지시어 AuthGroupFile은 그룹 파일의 위치를 지정할 때 사용된다. 주의할 것은 그룹 파일 내에서 한 줄의 길이는 약 8000자 정도(정확하게 8KB)이기 때문에 이를 넘기지 않도록 한다. 만약 8000자를 넘을 정도로 사용자가 많다면 동일한 그룹 이름을 두 줄에 연속해서 사용하면 된다.
5) 사용자의 수가 많을 경우의 문제
사용자 데이터베이스 파일과 그룹 파일을 단순한 텍스트로 운영하는 것은 간단하고 쉽다. 하지만 사용자 수가 많아지게 되면 사용자나 그룹에 소속된 사용자의 패스워드를 검색하는데 상당한 시간이 소요된다. 이는 보호된 영역에 대해 사용자가 매번 인증을 요청할 때마다 엄청한 부하를 가져온다. 좀 더 빠른 처리를 위해 DBM 형태의 파일이 필요하게 된다. 이는 웹 서버로 하여금 커다란 텍스트 파일을 읽지 않고도 빠르게 사용자를 검색하도록 도와준다. 하지만 DBM 파일을 사용하기 위해서는 mod_auth_dbm 모듈을 사용할 수 있도록 재컴파일해야 하는 문제도 있다.
이 외에 사용자에 대한 상세 정보를 저장하기 위해 DB 형식의 파일을 사용할 수도 있는데, 이 역시 mod_auth_db 모듈을 사용해야만 가능하다.
6) 인증 방법의 제한
앞의 .htaccess 파일의 예에서 require 지시어를 <Limit> 컨테이너와는 상관없이 사용했다. 이는 모든 요청 방법(POST, GET, PUT)에 대해서 사용이 가능함을 의미하는데, 만약 <Limit> 컨테이너 내부에 두게 되면 특정한 요청에 대해서만 인증 과정을 허용하도록 설정할 수 있다.
예를 들어 아래에서는 staff 그룹에 소속된 사용자만이 POST 방법을 이용해 인증을 요구할 수 있다.
AuthName “restrict posting”
AuthType Basic
AuthUserFile /usr/local/etc/httpd/users
<Limit POST>
require group staff
</Limit>
인증되지 않은 다른 사용자는 다른 방법(GET이나 PUT)으로 인증을 시도할 수 있다. 이와 같은 설정은 오직 인증된 사용자만이 데이터를 기록(POST)할 수 있도록 CGI 스크립트와 같은 프로그램에 제한을 둘 때 용이하다.
7) 호스트 이름이나 사용자 이름으로 제한하기
사용자를 제한할 때 호스트 이름과 사용자 이름을 둘다 동시에 이용할 수 있다. 즉, 접근이 허용된 호스트나 도메인으로부터 들어오는 사용자를 허용하고, 이들 사용자가 정확한 ID와 패스워드를 입력해야 접근을 할 수 있는 것이다. 하지만 보안과 관련된 지시어는 .htaccess 파일이나 <Directory>, <Location>, <Files> 등의 컨테이너에서 사용될 수 있는데, 이들 지시어가 사용될 때 접근이 허용된 도메인으로부터 들어오는 사용자에게는 ID나 패스워드를 요구하지 않게 된다.
물론 허용되지 않은 호스트나 도메인으로부터 진입하는 사용자는 ID와 패스워드를 요구하게 된다.
8) 웹 인증의 동작 방식
사용자 인증을 위해서 HTTP가 사용되는 방식은 의외로 간단하다. HTTP 프로토콜 자체가 상태를 기억하지 못하는 stateless(서버가 요청에 대해 응답을 주고 나면 이에 대한 어떤 정보도 서버는 가지고 있지 않는다) 프로토콜이기 때문에, 인증을 받고 난 후에 사용자 정보를 유지하기가 어렵다. 그러므로 브라우저는 계속해서 사용자의 ID와 패스워드를 전송해야 한다.
처음 제한된 자원에 접근을 하게 되면 웹 서버는 WWW-Authenticate 헤더와 함께 401 상태(인증 안됨)를 브라우저에게 보내게 된다. 이는 인증에 사용할 기술(현재는 Basic)과 영역 이름이 포함된다. 브라우저는 이 정보를 받고서 사용자에게 ID와 패스워드를 묻게 되고, 브라우저는 동일한 자원에 대해 또 한번 요청을 하게 된다. 이때 인증 기술(Basic)과 사용자가 입력한 사용자 ID와 패스워드가 포함된 Authorization 헤더를 전송하게 된다.
서버는 사용자 ID와 패스워드를 확인하여 정상적인 사용자라면 해당 자원을 브라우저에게 보내게 된다. 만약 입력한 패스워드가 정확하지 않거나, require에 등록되지 않은 사용자가 접근한 경우에 웹 서버는 이전처럼 401 상태를 전송하게 된다. 그럼 웹 브라우저는 다시 한번 사용자 ID와 비밀번호를 요구하게 된다. 하지만 이 과정은 속도가 느리기 때문에 브라우저는 Authorization 헤더를 보내게 된다. 유념해야 할 것은 동일한 서버 내에서 발생하는 이후의 인증에서 브라우저는 사용자 ID와 패스워드만을 전송하게 되다(사용자가 다른 서버로 이동할 수 있기 때문에 상세한 정보를 보내는 것은 보안상 위험할 수 있다).
그렇기 때문에 브라우저는 입력된 사용자의 ID와 비밀번호를 기억할 필요가 있다. 그래야만 동일한 서버에 대해 계속 요구되는 인증에 대해서 정보를 제대로 제공할 수 있다. 하지만 이것 또한 문제가 발생하는데, 인증을 테스트할 때는 이전에 인증한 사용자 ID와 비밀번호가 기억되어 있기 때문에 다른 사용자에 대한 테스트가 어려울 수 있다.
4. Apache + Php + MySQL
1) APM 개요
아파치는 리눅스, 유닉스 그리고 MS-WINDOW에서도 설치하여 운영이 가능한 웹 서버이다. 현재 전세계적으로 가장 많이 사용하는 웹 서버이다.
php는 personal hypertext preprocessor의 약자로 html 문서 내부에 포함되어서 서버측에서 실행되는 스크립트 언어이며 서버에서 실행되는 cgi를 작성하는 도구이다. php는 데이터베이스와의 연동이 뛰어나서 사용자들이 많다.
MySQL은 중소형급에서 사용되는 관계형 데이터베이스 서버이다.
2) 다운로드 사이트
apache 웹 사이트: http://www.apache.kr.net
PHP 웹 사이트 : http://www.php.net
MySQL 웹 사이트: http://www.mysql.com
ZendOtimizer 웹 사이트 : http://zend.com
이 사이트는 회원가입을 해야 소스를 다운로드 받을수 있다.
그리고 위의 소스를 모두 구할수 있는 곳은 http://www.tuxfinder.com 사이트이다.
3) 설치 과정
1] 소스 설치 기본 개념
대부분의 소스 설치는
#./configure
#make
#make install
형식으로 이루어진다.
(1) configure
컴파일에 필요한 여러 가지 옵션들을 제공하는 기능이다. 주로 소스가 설치될 위치를 지정(--prefix=/usr/local/xxx)하거나 사용할 언어를 선택(--with-charset=euc_kr)하는 옵션을 설정한다.
만약 제공되는 옵션을 확인하고자 한다면 다음의 명령을 실행하여 확인한다.
#./configure --help
(2) make
본래 복잡한 compile을 자동화하는 유틸리티인데, 수많은 소스들을 각기 compile하여 object 코드를 생성하고 이를 링크하는 과정을 도와주는 것이다. 기본적인 형식은 make [target]이다. 만약 target없이 make 명령을 내리면 같은 디렉토리에 있는 makefile이나 Makefile을 찾아서 그 안에 적혀있는 규칙에 따라 소스를 compile한다. 일반적으로 몇 가지의 인자가 제공되는데, make distclean은 이미 존재하는 목적 file들을 지워서 잘못된 설정값을 수정할 수 있고, make clean은 사용자의 설정에 따라 컴파일 과정에서 생성된 불필요한 파일들을 삭제한다. 그리고 make install은 compile된 실행 file들이 지정된 위치에 제대로 자리잡도록 설치하는 명령이며 root 권한을 요구한다..
2] 패키지 삭제
(1) 실행중인 아파치 프로세스 종료
[root@edu /root]# ps -ef | grep httpd
apache 5435 5432 0 14:55 ? 00:00:00 /usr/sbin/httpd -DHAVE_PROXY -DH
apache 5436 5432 0 14:55 ? 00:00:00 /usr/sbin/httpd -DHAVE_PROXY -DH
apache 5437 5432 0 14:55 ? 00:00:00 /usr/sbin/httpd -DHAVE_PROXY -DH
apache 5438 5432 0 14:55 ? 00:00:00 /usr/sbin/httpd -DHAVE_PROXY -DH
apache 5439 5432 0 14:55 ? 00:00:00 /usr/sbin/httpd -DHAVE_PROXY -DH
apache 5440 5432 0 14:55 ? 00:00:00 /usr/sbin/httpd -DHAVE_PROXY -DH
apache 5441 5432 0 14:55 ? 00:00:00 /usr/sbin/httpd -DHAVE_PROXY -DH
apache 5442 5432 0 14:55 ? 00:00:00 /usr/sbin/httpd -DHAVE_PROXY -DH
root 6749 6706 0 16:27 pts/1 00:00:00 grep httpd
[root@edu /root]#
실행중인 아파치 데몬을 중지시켜야 한다.
[root@edu /root]#killall httpd
[root @edu00 linux]#ps -aux | grep httpd
[root @edu00 linux]#ps -eaf | grep httpd
[root @edu00 linux]#killall httpd
(2) MySQL 서버 종료하기
[root @edu /root]#ps aux | grep mysql
[root @edu /root]#killall mysql
(3) rpm 패키지 삭제
[1] 아파치 삭제
[root@edu /root]#rpm -qa | grep apache
[root@edu /root]# rpm -qa | grep apache
apache-manual-1.3.20-2wl
apacheconf-0.8-3
apache-devel-1.3.20-2wl
apache-1.3.20-2wl
[root@edu /root]#
rpm -e 옵션을 사용하여 다음과 같이 실행한다.
[root@edu /root]# rpm -e apache-manual-1.3.20-2wl
이런 방식으로 차례대로 삭제하면 된다. 만약 의존성을 무시하고 삭제하고자 한다면 –nodeps 옵션을 이용할 수 있지만 시스템 안전을 위해서 가능한 사용하지 말 것을 권한다.
패키지를 삭제했다 하더라도 관련 디렉토리와 파일들은 남게 되므로 관련 디렉토리와 파일들까지 삭제해야 한다.
다음은 아파치 관련 디렉토리 삭제의 예이다.
[root @edu00 linux]#rm -rf /var/httpd
[root @edu00 linux]#rm -rf /etc/httpd
[root @edu00 linux]#rm -rf /usr/lib/apache
[root @edu00 linux]#rm -rf /var/log/httpd
[2] PHP , MySQL 삭제
아파치 삭제와 동일한 방법으로 삭제를 하면 된다. 이때 주의할 것은 아파치와 마찬가지로 관련 디렉토리와 파일들까지 삭제를 해야 한다는 것이다.
[root@edu /root]#ps -ef | grep mysql
[root@edu /root]#rpm -e mysql-3.xx.xx
[root@edu /root]#ps -ef | grep php
[root@edu /root]#rpm -e php-4.x.x
3) 설치
해당 소스를 /usr/local 디렉토리에 압축을 푼다. 일반적으로 사용자 정의 응용 프로그램들은 /usr/local 디렉토리를 이용하여 관리한다.
[root @edu00 root]#cd /tmp
[root @edu00 tmp]#tar -xvzf apache_1.3.23.tar.gz --directory=/usr/local
[root @edu00 tmp]#tar -xvzf php* --directory=/usr/local
[root @edu00 tmp]#tar -xvzf mysql* --directory=/usr/local
1] Mysql 설치
[root @edu00 tmp]#cd /usr/local
[root @edu00 local#groupadd mysql
[root @edu00 local]#useradd -g mysql mysql
[root @edu00 local]#cd mysql-version
[root @edu00 mysql-version]#./configure --prefix=/usr/local/mysql --with-charset=euc_kr –localstatdir=/usr/local/mysql/data
--prefix=/usr/local/mysql 디렉토리는 mysql이 설치될 경로이다.
--localstatedir=/usr/local/mysql/data 디렉토리는 mysql의 데이터가 존재할 위치를 지정한다.
--with-charset=euc_kr 옵션은 mysqld의 기본값이 latin1로 되어있기 때문에 한글 수행을 위해서 설정한다.
[root @edu00 mysql-version]#make ; make install
[root @edu00 mysql-version]#./scripts/mysql_install_db &
/usr/local/mysql-version에서 실행하며 기본적인 테이블 생성을 위한 것이다.
[root @edu00 mysql-version]#chown -R root /usr/local/mysql
[root @edu00 mysql-version]#chown -R mysql /usr/local/mysql/var
[root @edu00 mysql-version]#chgrp -R mysql /usr/local/mysql
[root @edu00 mysql-version]#cp support-files/my-example.cnf /etc/my.cnf
my.cnf 파일을 적절하게 수정한다.
[root @edu00 mysql-version]#/usr/local/mysql/bin/safe_mysqld –language=Korean --user=mysql &
mysqld 데몬을 실행시킨다.
[root@edu mysql]#./bin/mysqladmin -u root password 'linuxone'
''사이에 패스워드를 입력한다. 이 명령은 root권한의 패스워드를 정하는 과정이다.
[root@edu mysql]#pstree
명령을 내린 후 safe_mysqld가 실행중인지 확인한다.
[root@edu mysql]#./bin/password -p
Enter password :
이전에 입력했던 패스워드를 입력하고 접속한다.
mysql> show databases;
+----------+
| Database |
+----------+
| mysql |
| test |
+----------+
2 rows in set (0.01 sec)
mysql>
mysql>\q
종료한다.
MySQL 설치시의 에러 해결
만약 mysqld 데몬을 실행시킬 경우 해당 데몬이 실행되자 마자 바로 다운되는 경우가 발생할 수 있다.
만약 /tmp/mysql.sock 에러 메시지가 출력되거나 혹은 홈 디렉토리 지정이 달라서 해당 데몬이 곧 바로 다운되는 일이 일어난다면 다음 과정을 참고하여 에러를 해결한다.
먼저 /tmp 디렉토리로 이동한다음 mysql.sock 파일을 삭제한다. 그리고 /etc/passwd 파일에서 mysql 계정의 경로를 확인하고 해당 데몬 실행시 지정된 홈 디렉토리(지정된 경로)인 /usr/local/mysql로 바꿔준다. 그다음 /usr/local 디렉토리로 이동한 다음 mysql의 소유권을 바꿔준다.
[root @edu /tmp]#rm -f mysql.sock
[root @edu /tmp]#vi /etc/passwd
mysql 시스템 계정의 홈 디렉토리의 경로를 확인한다.
[root @edu local]#chown mysql.mysql -R mysql
이 과정을 거친 후 mysql 데몬을 재시작하면 아무런 에러 없이 데몬이 실행될 것이다.
2] 아파치 경로 지정
아래와 같이 압축을 풀어주고 압축을 풀어준 경로로 이동한다.
[root@edu /root]#tar xvfz apache_1.3.23.tar.gz -C /usr/local
[root@edu /root]#cd /usr/local/apache_1.3.23
PHP와의 연동을 위해 다음을 실행한다. 만약 이렇게 하지 않으면 PHP컴파일시 에러를 출력할 것이다.
[root@edu apache_1.3.23]#./configure --prefix=/usr/local/apache
3] Gd 라이브러리 설치
Gd 라이브러리를 설치하는 이유는 PHP 함수에서 그림함수를 쓰기 위함이다. 또한 웹상에서 그림파일(jpg,gif..)을 보기 위하여 설치한다.
[root@edu /root]#tar xvfz gd-1.8.4.tar.gz
[root@edu /root]#cd gd-1.8.4
[root@edu /gd-1.8.4]#make
[root@edu /gd-1.8.4]#mv /root/gd-1.8.4 /usr/lib
4] PHP 설치하기
[root@edu /root]#tar xvfz php-4.1.0 -C /usr/local
[root@edu /root]#cd /usr/local/php-4.1.0
[root@edu /php-4.1.0]#./configure --with-apache=/usr/local/apache_1.3.23 \
>--with-mysql=/usr/local/mysql --with-language=korean --with-charset=euc_kr \
>--with-config-file-path=/usr/local/apache/conf \
>--with-exec-dir=/usr/local/apache/bin \
>--with-enable-track-vars=yes --disable-debug --with-xml --enable-magic-quotes \
>--with-gd=/usr/lib/gd-1.8.4
다음은 옵션에 대한 설명이다.
--with-apache=/usr/local/apache_1.3.23
현재 아파치의 소스가 설치 되어있는 위치이다.
--with-mysql=/usr/local/mysql
현재 MySQL이 설치된 디렉토리 및 언어코드 선택 부분이다.
--with-config-file-path=/usr/local/apache/conf
아파치 설정 파일과 php.ini등의 환경 설정 파일을 지정하기 위함이다.
--with-exec-dir=/usr/local/apache/bin
아파치의 실행 파일의 위치를 지정한다.
--with-enable-track-vars=yes
PHP스크립트 및 xml을 실행할 수 있게해 주는 옵션이다.
--with-gd=/usr/lib/gd-1.8.4
gd 라이브러리가 설치 되어있는 위치를 지정한다.
설치를 계속 이어간다. 만약 이상없이 진행이 되었다면 다음과 같이 컴파일한다.
[root@edu /php-4.1.0]#make
[root@edu /php-4.1.0]#make install
5] apache 컴파일
[root@edu /php-4.1.0]#cd /usr/local/apache_1.3.23
[root@edu /apache_1.3.23]#./configure --prefix=/usr/local/apache
>--activate-module=src/modules/php4/libphp4.a
PHP를 아파치 웹 서버의 모듈로 설치한다는 옵션이다.
>--enable-shared=max
DSO(동적객체공유)지원 옵션이다.
이상없이 실행이 되었다면 다음과 같이 컴파일한다.
[root@edu /apache_1.3.23]#make
[root@edu /apache_1.3.23]#make install
6] ZendOptimizer 설치하기
[root@edu /root]#tar xvfz ZendOptimizer-1.2.0-PHP_4.1.0-Linux_glibc21-i386.tar.gz
[root@edu apache]# cd ZendOptimizer-1.2.0-PHP_4.1.0-Linux_glibc21-i386
[root@edu ZendOptimizer-1.2.0-PHP_4.1.0-Linux_glibc21-i386]# ls
BUILD README data doc install install-tty.sh install.sh lmutil md5
[root@edu ZendOptimizer-1.2.0-PHP_4.1.0-Linux_glibc21-i386]# cd data
[root@edu data]# ls
ZendOptimizer.so acceleratedbyoptimizer.gif php.ini-recommended
위 디렉토리에서 ZendOptimizer.so 파일이 있는지 확인한다.
[root@edu data]#mkdir /usr/local/Zend
[root@edu data]#mv ZendOptimizer-1.2.0-PHP_4.1.0-Linux_glibc21-i386 /usr/local/Zend/libㅤ
Zend 디렉토리를 생성한 뒤 php.ini파일을 아파치 환경설정파일 디렉토리로 복사한다.
[root@edu data]#cp /usr/local/php-4.1.0/php.ini-dist /usr/local/apache/conf/php.ini
그 다음 php.ini 파일을 열어 아래 부분에 zendoptimizer 부분을 추가해준다.
[root@edu data]#vi /usr/local/apache/conf/php.ini
[Zend Optimizer]
zend_optimizer.optimization_level=7
zend_extension="/usr/local/Zend/lib/ZendOtimizer.so"
7] /usr/local/apache/conf/httpd.conf 수정하기
[root@edu data]#vi /usr/local/apache/conf/httpd.conf
아래의 내용을 수정한다.
# And for PHP 4.x, use:
#
#AddType application/x-httpd-php .php
#AddType application/x-httpd-php-source .phps
AddType 부분의 주석을 풀어주시고 .php 다음으로 .html .htm .cgi 를 추가한다.
<IfModule mod_dir.c>
DirectoryIndex index.html
</IfModule>
이 부분을 찾아 index.htm index.php index.cgi 추가한다.
#ServerName localhost
이 부분의 주석을 풀어 서버 호스트를 지정한다.
8] 실행
/usr/local/apache/htdocs 디렉토리아래 test.php 파일을 만들고 아파치를 실행한다.
[root @edu htdocs]cat > test.php
<?
phpinfo();
?>
Ctrl+C
[root @edu htdocs]#/usr/local/apache/sbin/apachectl start
[root @edu htdocs]#netscape & http://localhost
9] 부팅시 웹서버 실행
[root@edu /root]#vi /etc/rc.d/rc.local
파일의 마직막 부분에 다음과 같이 추가한다.
/usr/local/apache/bin/apachectl start
cd /usr/local/mysql
./bin/safe_mysqld --language=korean &
4) rpm package 삭제 예
rpm package를 삭제할 때 의존성이 걸려있는 mod_perl, php 등의 패키지부터 거꾸로 지워나가야 쉽게 삭제할 수 있다.
[root @edu00 linux]#rpm -qa | grep apache
[root @edu00 linux]#rpm –qa | grep imap
[root @edu00 linux]#rpm -qa | grep mysql
[root @edu00 linux]#rpm -qa | grep php
[root @edu00 linux]#rm -rf /home/httpd
[root @edu00 linux]#rm -rf /etc/httpd
[root @edu00 linux]#rm -rf /usr/lib/apache
[root @edu00 linux]#rm -rf /var/log/httpd