리눅스마스터1급 : 아파치(Apache) 환경 설정1편

리눅스마스터1급 : 아파치(Apache) 환경 설정1편

아파치 웹서버는 수 많은 버전업을 해 오면서 아주 많은 기능이 포함되었고, 높은 성능을 내고 있으며, 안정성 및 보안성이 높아졌다.

이러한 많은 기능을 설정파일을 사용하여 설정할 수 있으며, 많은 기능을 제공하는 만큼 설정파일이 복잡해지고 많아졌다.

이러한 설정파일에 대해 자세히 알아보자.

아파치 설정파일인 httpd.conf 파일의 수많은 지시자들을 설정하고 변경함으로써 우리는 아파치의 성능과 안정성, 그리고 보안을 구현할 수 있다.

리눅스에는 수많은 설정파일들이 있다.

그런 설정파일들을 끝없이 연구하고 의미를 해석하여 실제 적용함으로써 우리는 리눅스라는 서버를 최상의 상태로 운용할 수 있게 된다.

아파치 설정파일을 통하여 우리는 아파치웹서버를 최상의 상태로 운용하는 것이 궁극적인 목적이라고 할 수 있다.

설정 방법에 대해 알아 보기 전에 apachectl명령어에 configtest라는 옵션으로 실행하면 아파치 설정파일 httpd.conf의 문법을 검사하는 방법에 대해 알아보자. 설정파일 설정 후에 바로 웹서버를 재 시작 하게되면 설정 실수로 운영중인 서비스에 장애가 발생될 수 있다.

설정파일을 수정했다면 적용하기전에 검증이 필요하다.

httpd.conf파일의 설정에 이상이 없을 경우에는 다음과 같이 "Syntax OK"라는 메시지를 뿌려준다.

하지만 httpd.conf파일에 문제가 있는 경우에는 다음과 같이 문제가 되는 부분을 알려주기도 한다.

위의 예는 httpd.conf파일의 30행의 설정에서 잘못된 부분이 있음을 알려주고 있다.

그리고 무엇이 잘못된 것인가를 알려주고있다.

위 결과는 30행의 설정 내용중 “SrverRoot”라는 지시자는 알 수 없다는 내용이다.

이와 같이 아파치가 정상적인 방법으로 실행되지 않을 때 apachectl유틸리티를 이용하여 이와같이 원인파악을 할 수도 있다.

앞서 잠깐 설명하였듯이 아파치 설정파일은 1개가 아니다.

httpd.conf파일을 비롯하여 /usr/local/apache/conf/extra/디렉토리에 용도별로 여러개의 설정파일이 존재한다.

여기서 아파치 설정파일에 대한 히스토리를 잠깐 얘기하기로 하자. 초기 아파치웹서버의 설정파일은 3개였다.

srm.conf, access.conf, httpd.conf가 그것이었다.

물론 용도별로 설정내용이 각각 나뉘어져있었다.

그 이후에 httpd.conf파일로 하나의 설정파일로 합쳐졌다.

꽤 오랫동안 httpd.conf파일 하나로 설정되다가 아파치웹서버가 2.2버전으로 업그레이드되면서 현재에는 다음과 같이 메인 설정파일인 httpd.conf이외에 extra디렉토리에 모두 11개의 용도별 설정파일이 존재하게되었다.

앞서 간략하게 설명한 내용이기는 하지만 다음 용도별 설정파일들의 내용을 확인하기 바란다.

아파치의 주설정파일(httpd.conf)은 ServerRoot, ServerName, DocumentRoot와 같은 메인설정들을 정의하고있다.

그리고 파일의 마지막부분에는 extra디렉토리에 존재하는 11개의 설정파일들을 개별적으로 include하여 선택적으로 로딩할 수 있도록 되어있다.

개별적으로 로딩하는 11개의 용도별 설정파일들을 include하는 내용을 보면 다음과 같다.

위의 내용을 보는 바와같이 필요한 개별 설정파일의 설정부분에서 주석(#)을 제거하면 적용 되도록 설정되어있다.

이제부터 위의 설정파일들에 존재하는 내용들에 대해 설명할 것이다.

이 설정파일을 잘 다루는 것이 바로 아파치웹서버 관리를 잘하는 것이라는 말과 상통한다.

이들 설정파일은 관리자가 설정하기 위해 존재하는 파일이다.

그리고 설정파일의 내용을 수정/편집하면서 설정 한다는 것은 아파치웹서버에 서로 다른 값들이 적용된다 라는 의미이고 다른 값들이 적용된다 라는 것은 최상의 상태로 운용하기 위한 최상의 값으로 적용한다 라는 의미이므로 결론적으로 아파치웹서버를 최상의 상태로 관리하기 위한 방법이 바로 설정파일을 최적의 값으로 설정한다 라는 것이다.

따라서 지금부터 설명하는 아파치 설정파일의 설정내용들을 잘 봐 두었다가 필요한 곳에 유용하게 사용하기 바란다.

① 주 설정파일(httpd.conf)

아파치서버의 홈디렉토리를 지정하며 절대경로로 지정한다.

아파치 설치시에 나오는 아파치의 홈디렉토리를 지정하지 않아도 디폴트(default)로 /usr/local/apache로 자동 지정하여 설치하게 된다.

이후로 나오는 대부분의 경로(PATH)들은 이 경로를 루트로 한 상대경로로 지정이 된다.

시스템의 기본값 이외에 다른 IP Address와 포트에 대해서도 연결할 수 있도록 해 준다.

주로 환경설정파일(httpd.conf) 맨뒤에 나오는 가상호스트(Virtual Host)부분에서 기본 80번이외에 다른 포트를 이용하여 가상호스트를 설정하고자 할 때에 필요하다.

아파치를 DSO(Dynamic Shared Object)방식으로 설치한 다음 필요한 모듈을 아파치에 로드하는 지시자이다.

위에서 로드한 모듈은 “libphp5.so”로서 직접 로딩되는 파일들의 위치는 다음과 같다.

즉 위의 LoadModule이라는 설정에 의해 아파치 실행중에 각각 필요한 모듈들이 로딩되어 사용된다.

그리고 사용이 종료되었을 경우에는 모듈파일은 unloading되어 메모리에서 사라진다.

즉 필요한 모듈파일들을 필요할 때마다 로딩하였다가 해제하는 방식의 동적로딩을 하기 위한 설정이다.

만약 아파치를 정적(static)으로 설치하였다면 이 지시자는 필요하지 않다.

정적으로 설치된 모듈들을 확인하는 방법은 “/usr/local/apache/bin/httpd -l”을 실행하여 확인할 수 있다.

즉 정적으로 설치된 아파치의 경우에는 필요한 모듈들은 아파치의 실행과 함께 아파치가 종료될 때까지 필요하든 아니든 항상 메모리에 로딩되어있다.

이 방식은 예전 아파치의 모듈사용방식으로서 정적방식이라고 한다.

위의 User와 Group이라는 설정 지시자는 홈페이지 서비스를 직접 담당하는 아파치 자식 프로세스들의 실행소유자와 소유그룹을 각각 어떤 계정으로 할 것인가를 결정하는 것이다.

다음 아파치가 실행되어있는 프로세스를 ps로 확인한 예를 보자.

위의 예에서 daemon 소유로 되어있는 프로세스들 즉 PID가 6788, 6789, 6790, 6791, 6792인 프로세스들의 소유를 각각 어떤 계정소유로 할 것인가를 결정하는 지시자이다.

그리고 위의 모든 아파치자식프로세스들의 PPID 즉 부모프로세스는 위의 경우 root소유로 되어있는 PID가 6786인 프로세스이다.

즉 PID가 6786인 프로세스에 의해 위의 모든 아파치자식프로세스들을 fork시켜서 생성한 것이며 초기에는 5개만 생성하였지만 상황에 따라서 아파치자식프로세스들을 더 생성하기도 하고 줄이기도 한다.

이 역할을 하는 것이 6786번 PID를 가진 프로세스의 역할이다.

아파치 자식 프로세스에 대하여 좀 더 구체적으로 설명하면 다음과 같다.

아파치 웹데몬이 구동될 때에 생성되는 아파치 자식프로세스(child process)의 user와 group(여기서 지정한 User와 Group)으로 생성이 된다.

기본값으로 daemon이라는 사용자와 daemon이라는 그룹명으로 아파치 자식 프로세스는 실행된다.

혹, 많은 서버관리자들이 nobody로 설정을 해 두고 있으며, 만약 시스템에 nobody계정이 없다면 새로 생성(useradd)을 하면 될 것이다.

단, root로 설정하는 일은 절대로 있어서는 안된다.

만약 이 값이 root로 설정된다면 아파치웹서버의 모든 자식프로세스들이 root소유로 실행되며 이것은 곧 웹서비스 자체가 root권한으로 실행됨을 의미한다.

여기서 지정하는 email address는 웹문서 로딩시 에러등의 경우에 에러페이지에 보여질 아파치웹서버 관리자의 전자우편 주소이다.

일반적으로 웹서버관리자의 email address로 설정한다.

클라이언트에게 보여주는 호스트이름을 지정한다.

www를 쓰지 않는 호스트에서 www를 쓰는 것처럼 보이게 할 수 있다.

예를들어 test.sulinux.net을 www.sulinux.net으로 지정해서 쓸 수 있다.

만약 현재 사용하는 도메인이 없다면 여기에 IP Address를 설정하여 사용할 수도 있다.

아파치웹서버의 웹문서가 있는 경로를 지정한다.

만약 설치한 아파치웹서버의 도메인이 www.linux.net이라면 "http://www.linux.net/index.html"의 index.html이 로딩되는 절대경로는 "/usr/local/apache/htdocs/index.html"이 된다.

Alias를 사용하여 다른 위치를 지정할 수도 있다.

만약 가상호스트 설정을 하였다면 이 설정은 무시된다.

<Directory> ~ </Directory>지시자는 지정한 디렉토리이하의 모든 웹문서들에 대한 제어를 어떤방식으로 할 것인가를 결정하는 아주 중요한 지시자이다.

이 <Directory> ~ </Directory> 지시자는 여러개 존재할 수 있으며 직접 만들어 사용할 수도 있다.

단, 특정 디렉토리 이하의 적용설정을 하려면 <Directory>로 시작하여 </Directory>로 끝이나야 한다.

이에 대한 설명을 좀 구체적으로 해보겠다.

부디 정확하게 이해하길 바란다.

먼저 이 지시자에는 크게 두가지의 항목이 있다.

하나는 Options항목이며 두번째는 AllowOverride항목이다.

이 두가지 항목의 성격을 간단히 요약하면 다음과 같다.

먼저 Options에 대한 설명부터 해보겠다.

∙[Options] 항목

Options에서는 지정한 디렉토리이하에 모든 파일과 디렉토리들에 적용할 접근제어를 설정한다.

즉 디렉토리목록을 보여줄 것인가? CGI를 허용할 것인가? SSI를 허용할 것인가? 등의 설정을 여기서 하게된다.

<Directory>에서 지정되는 값에 대한 옵션(Options)설정은 다음과 같은 의미를 가지고있다.

예를들어 아파치설치후에 perl로 된 CGI등에서 에러가 발생하는 대부분의 원인이 이 부분에서 설정하는 ExecCGI설정 때문인 경우가 많다.

∙[AllowOverride] 항목AllowOverride는 어떻게 접근을 허락할 것인가에 대한 설정이다.

특정 디렉토리에 대한 방문자들의 접근방식을 어떤방식으로 인증하여 허용할 것인가의 문제라고 할 수 있다.

Override라는 단어를 사전에서 찾아보면 "짓밟다”, “덮어쓰다”의 의미로 나와 있다.

따라서 AllowOverride라는 의미는 현재 설정이 앞부분에서 설정하였던 내용보다 우선 적용된다라는 의미로 해석된다.

따라서 AllowOverride에서 설정하는 값들은 중복해서 설정될 수 있으며 그때마다 가장 최근에 설정된 값이 항상 우선 적용된다는 것을 반드시 기억해야 한다.

“Order allow, deny”는 접근제어의 순서를 명시하는 것이며, 뒤에 나오는 “deny”우선한다.

모든 접근을 막고 지시자에 의해 허용하겠다는 의미이다.

“Deny from all"은 모든 접근으로 부터 거부 한다는 의미이다.

결론적으로 위 설정은 모든 디렉토리에 대해 접근을 거부하겠다는 의미이다.

위 설정은 앞에서 설명하였던 <Directory> ~ </Directory>지시자에 또다른 예이다.

즉 “/usr/local/apache/htdocs” 디렉토리에 대하여 <Directory> ~ </Directory>내에 지정된 값들을 모두 적용하겠다라는 설정이다.

이를 좀 더 구체적을 설명하면 다음과 같다.

/usr/local/apache/htdocs디렉토리이하의 모든 웹문서와 디렉토리들에 대하여 Options 항목값으로 Indexes와 FollowSymLinks를 사용하였다.

따라서 Indexes값이 설정되었기 때문에 /usr/local/apache/htdocs디렉토리이하에서는 디렉토리까지만 지정하였을 때에 그 디렉토리내의 파일리스트(목록)을 웹브라우즈로 보여준다.

그리고 FollowSymLinks값이 설정되었기 때문에 /usr/local/apache/htdocs디렉토리이하에 존재하는 링크파일들의 링크가 그대로 웹브라우즈에서 사용된다.

그리고 /usr/local/apache/htdocs 디렉토리 이하의 모든 웹문서와 디렉토리들에 대하여 AllowOverride값으로 None이 사용되었기 때문에 AccessFileName에 지정한 .htaccess파일을 인식하지 않는다.

따라서 .htaccess를 이용하여 특정디렉토리인증을 사용할 수 없다는 의미가 된다.

그리고 “Order allow, deny”로 인하여 /usr/local/ apache/htdocs디렉토리내의 웹문서들에 대하여 allow를 먼저 적용하고 그 뒤에 deny를 적용하게 되며 “Allow from all”에 의해 일단 모든 곳에서의 접근을 허용하게 된다.

만약 “Allow from all”뒤에 “Deny from 192.168.1.0”등과 같은 설정이 있다면 192.168.1.0네트워크내의 사용자들에 대해서만은 /usr/local/apache/htdocs디렉토리내의 접근은 허용되지 않게 된다.

웹사이트의 초기페이지 문서로 어떤 파일을 사용할 것인가를 결정하는 지시자이다.

웹브라우즈에서 홈페이지주소(http://www.sulinux.net)를 로딩하였거나 또는 특정 디렉토리 위치만을 주소창에 지정했을 경우(예를들어 http://www.sulinux.net)에 그 디렉토리에서 자동적으로 찾아서 보여줄 웹문서(index.html 또는 index.htm 또는 index.php, 또는 index.cgi등)파일의 순서를 지정한 것이다.

즉 디렉토리 이름만을 지정하더라도 여기서 지정한 index.html을 찾아서 웹브라우즈에 로딩해준다.

여러개의 파일을 지정할 수 있으며, 이런 경우에는 순서대로 찾아서 보여준다.

예를들어 "DirectoryIndex index.html index.htm index.php index.cgi"로 지정했다면 먼저 "index.html"을 찾아서 있다면 이 파일을 로딩하고, "index.html"이 없다면 "index.htm"을 찾아서 로딩해 준다.

그리고 이 파일도 존재하지 않는다면 index.php를 찾아서 로딩하고 이 파일도 없다면 index.cgi 파일을 찾아서 로딩한다.

그리고 최종적으로 이 지시자는 지정한 모든 파일이 존재하지 않는다면 Options 지시자에 Indexes 또는 All이 지정되어 있을 경우에 디렉토리내의 파일리스트(목록)을 보여준다.

그러나 Options지시자에 Indexes또는 All이 지정되어 있지 않을 경우에 “Not Found”라는 애러문서를 로딩한다.

“.htaccess"와 같은 “.ht”로 시작하는 파일의 내용을 웹브라우즈에서 어떻게 보여줄 것인지 또는 보여주지 않을 것인지를 결정하는 지시자이다.

“.ht”로 시작하는 파일에는 주로 웹 접근 권한등에 대해 설정되어 있다.

따라서 이 파일의 내용을 웹상에서 읽을 수 있어야 사용자도 있을 것이고 봐서는 안되는 사용자도 있을 것이다.

보안상의 이유로 이 옵션은 설정해두는 것이 좋다.

<FilesMatch> ~ </FilesMatch>지시자는 이파일 외에도 특정 파일의 패턴에 해당하는 파일들의 로딩을 막기위하여 주로 사용된다.

잘 활용하면 특정 문자로 시작하는 파일이나 특정 문자열로 끝나는 파일들을 웹문서로 보여주지 않으려고 할 때에 아주 유용한 도구가 된다.

즉 웹서버의 보안을 위해 충분히 활용가치가 있는 지시자이다.

한가지 유용한 사실은 여기서 설정된 “.ht”로 시작하는 파일들 뿐만 아니라 다른 문자열로 시작하는 파일들에 대해서도 이와 같은 접근허용에 관한 설정을 별도로 할 수 있다는 것이다.