X-Forwarded-For 는 원격지 주소를 192.0.2.1 이 된다. 그런데 RemoteIPInternalProxy 의 영향으로 인해서 192.0.2.1 은 내부 Proxy 로 지정되었기 때문에 X-Forwarded-For 의 원격지 주소는 198.51.100.2 가 된다.
ps, X-Forwarded-For 는 여러개의 IP를 기록할 수 있다. 만일 여러개를 기록할 경우에 맨 오른쪽에 IP가 최종 원격지 IP 주소가 된다.
어떤 기능을 사용할 것인지에 따라서 위 설정은 달라지지만, 적어도 Proxy Load Balancer 를 운영하기 위해 필요한 것과 불필요한 것만 위에서 기술 했다.
현재 활성화된 모듈이 무엇인지는 다음의 명령어로 확인 가능하다.
Apache 웹 서버의 활성화 된 모듈 확인
ZSH
1
/opt/httpd/bin/httpd-M
데몬 사용자/그룹 지정
Apache 웹 서버는 실행 프로세스와 HTTP 를 처리하는 데몬의 사용자/그룹를 다르게 지정할 수 있다. mod_unixd 에서 제공하는 것으로 다음과 같이 지정할 수 있다.
프로세스 사용자/그룹 지정
ZSH
1
2
3
4
5
<IfModule unixd_module>
User daemon
Group daemon
</IfModule>
RemoteIp 사용 설정
Apache 웹 서버 앞에 AWS ELB 가 있다. AWS 의 ELB 는 Client IP 를 ‘X-Forwarded-IP’ 헤더에 담아 뒤로 넘겨준다. 하지만 Apache 웹 서버는 이것이 Client IP 인지를 인식하지 못하는데, ‘X-Forwarded-IP’ 헤더 필드 값이 실제 IP 로 사용하도록 지정할 수 있는데 mod_remoteip 가 이를 담당 한다. 다음과 같이 설정해 준다.
mod_remoteip 설정.
Apache
1
2
3
4
<IfModuleremoteip_module>
RemoteIPHeaderX-Forwarded-For
RemoteIPProxiesHeaderX-Forwarded-By
</IfModule>
이렇게 설정을 해주면 이제부터 Apache 내부에서 사용하던 Client IP 관련 환경변수들이 ‘X-Forwarded-For’ 값으로 대체(override)된다. 바꿔말해서 Client IP 관련 환경 변수들을 하나하나 찾아서 ‘X-Forwarded-For’ 값으로 대체하지 않아도 된다.
log 설정
mod_remoteip 를 사용할 경우에 Apache 웹 서버의 로그에 Client IP 가 기록되도록 다음과 같이 추가해 준다.
지금까지 Apache 2.4 에서 기초적인 Reverse Proxy 설정을 기술했다. 기본적인 설정일뿐이며 이를 기반으로 다양한 기능들을 추가하면 된다. 추가적인 기능으로는 CustomLog 에서 파일형태(그림파일), URI 별로 쪼개서 로깅하기 혹은 IP 를 기반으로 차단하기, 이미지 파일 캐싱하기 등등이 있다.
위 예제는 access.2017-04-13.log 파일에 로깅을 하는데 combinedio 로 정의된 로그 포맷대로 기록하며 86400(1day) 하루에 한번 로그 로테이션을 하도록 설정한 것이다.
그런데, 만일 기록되어지는 로그중에 특정 형식의 URI 로 시작하는 경우에 별도의 로그 파일에 기록하고 싶다면 어떻게 해야할까?
Apache 2.4 로그
Default
1
192.168.96.11--[13/Apr/2017:23:43:03+0900]"POST /wp-admin/admin-ajax.php HTTP/1.1"20058"http://linux.systemv.pe.kr/wp-admin/edit.php""Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.54 Safari/537.36""-"
위 처럼 /wp-admin 으로 시작하는 URI 를 별도 파일로 기록하고 싶다면 다음과 같이 하면 된다.
위와같이 mod_setenvif 모듈이 제공하는 SetEnvIfNoCase 문을 이용해 URI 에 형태를 정규표현식을 이용해 매칭시키고 이것을 변수로 등록한다. 그리고 CustomLog 를 하나 더 추가해 ‘combinedio env=object_is_admin’ 처럼 환경변수를 인식 시켜준다.
위와같이 하면 access_wp_admin.%Y-%m-%d.log 파일에는 /wp-admin 으로 시작하는 URI 에 대해서만 기록하게 된다.
한가지 주의할 것은 기존의 access.%Y-%m-%d.log 파일에도 여전히 /wp-admin 으로 시작하는 URI 도 함께 기록된다는 것이다. 이를 피하기 위해서 다음과 같이 지정해줄 수 있다.
mod_jk 에 대한 설정은 기본적으로 두가지 측면에서 이루어진다. 첫째는 Apache 웹서버에서 mod_jk 를 핸들링을 어떻게 할건지에 대한 설정이고 두번째는 mod_jk 가 Apache로부터 받은 요청을 어떻게 Tomcat 에 전달할 것인지에 대한 것이다.
Apache 웹서버에서 mod_jk 설정
mod_jk 를 정상적으로 컴파일 설치했다면 Apache 웹서버에서 이를 인식시켜주고 설정을 해줘야 한다.
여기서 한가지 주의해야할 것이 있는데, CentOS7 에서 Yum 으로 설치한 Apache 의 경우에는 설정하는데 카테고리별로 디렉토리를 분리를 해놨다.
모듈 로딩 설정 디렉토리: /etc/httpd/conf.modules.d
모듈별 설정 디렉토리: /etc/httpd/conf.d
모듈을 로딩하기 위해서 다음과 같이 conf.modules.d 디렉토리에서 파일을 작성한다.
vim /etc/httpd/conf.httpd.d/00-jk.conf
ZSH
1
LoadModule jk_module modules/mod_jk.so
이렇게 하고나서 다음과 같이 문법 테스트를 해준다. 이 문법 테스트는 설정을 변경할때마다 해주는 것이 좋다.
Apache 문법 테스트
Default
1
]# apachectl configtest
이제 Apache 에서 mod_jk 에 대한 설정을 다음과 같이 해준다.
vim /etc/httpd/conf/httpd-jk.conf
Apache
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
<IfModulejk_module>
# We need a workers file exactly once
# and in the global server
JkWorkersFileconf.d/workers.properties
# Our JK error log
# You can (and should) use rotatelogs here
JkLogFilelogs/mod_jk.log
# Our JK log level (trace,debug,info,warn,error)
JkLogLevelinfo
# Our JK shared memory file
JkShmFilelogs/mod_jk.shm
# If you want to put all mounts into an external file
# that gets reloaded automatically after changes
# (with a default latency of 1 minute),
# you can define the name of the file here.
JkMountFileconf.d/uriworkermap.properties
</IfModule>
기본적인 설정은 위와 같다. 저장한 다음에 “workers.properties”, “uriworkermap.properties” 빈 파일을 만들어 줍니다. Apache 문법 테스트를 해보고 오류가 없다면 정상이다.
mod_jk worker 설정
이 설정은 Apache 와 Tomcat 간에 어떻게 연결을 해야하는지에 대해 정의한다. 이 파일은 위에 “httpd-jk.conf” 파일에서 “conf.d/workers.properties” 로 정의되어 있다.
여기서 고려해야할 사항은 다음과 같다.
worker 이름: worker 이름은 정하기 나름이지만 각각 뒷단의 Tomcat 서버를 구분할 수 있는 이름이여야 한다. 이 worker 이름은 나중에 로드밸런싱을 할때에 Tomcat 에도 적용되어지는 이름이기에 잘 설정해야 한다.
worker port: 여기서 말하는 port 는 뒷단 Tomcat 서버의 AJP 포트를 말한다.
worker type: 이건 ajp13 으로 설정하면 된다.
worker lbfactor: 부하분산을 위한 설정으로 뒷단 Tomcat 서버들에 연결 무게를 설정해준다.
vim /etc/httpd/conf.d/workers.properties
Apache
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
worker.list=instance1,instance2,instance3
worker.instance1.port=8109
worker.instance1.host=localhost
worker.instance1.type=ajp13
worker.instance1.lbfactor=1
worker.instance2.port=8209
worker.instance2.host=localhost
worker.instance2.type=ajp13
worker.instance2.lbfactor=1
worker.instance3.port=8309
worker.instance3.host=localhost
worker.instance3.type=ajp13
worker.instance3.lbfactor=1
mod_jk uriworkermap 설정
이 설정은 특정 URI 에 대해서 mod_jk 의 woker 가 동작하도록 해서 요청을 Tomcat 에 넘길 수 있도록 해준다. Apache – Tomcat 구조에서 최초의 요청은 Apache 가 받아 URI 를 해석하는데, 이 설정을 해주면 특정 URI 에 대해서 Apache 가 Tomcat 에게 넘기게 된다.
여기서 간단한 시나리오를 생각해보자. 현재까지 설정은 부하분산(Loadbalance) 가 없는 것이다. 각 3대의 Tomcat 인스턴스에 대해서 동일한 무게를 주었을 뿐이다. 이렇게되면 특정 URI 요청이 있을때에 어느 Tomcat 인스턴스로 보낼것인지도 문제가 된다.
테스트를 위해서 Tomcat 설치시 나오는 메인페이지를 기준으로 하기로 했다. 이 페이지를 들여다보면 jsp, png, css 파일들로 이루어져 있다. 그러면 jsp 는 instance1 서버가 서빙을 하게하고 png 는 instance2 이 css 는 instance3 이 하게 하면 어떨까하는 시나리오를 만들고 이를 설정에 적용해 보자.
vim /etc/httpd/conf.d/uriworkermap.properties
Apache
1
2
3
/*.jsp=instance1
/*.png=instance2
/*.css=instance3
테스트
테스트는 간단하다. 브라우저를 실행시키고 http://apache-server-ip/index.jsp 주소로 이동해보는 것이다. 이때 Tomcat 초기 메인화면이 나온다면 정상이다.
그런데, 설정에서 jsp 는 instance1이 png 파일은 instance2 이 css 파일은 instance3 이 처리하도록 설정했었다. 그렇다면 실제로 그렇게 되고 있는지 확인을 해야하는데 확인방법은 각각 Tomcat 인스턴스에 접속 로그를 확인하면 된다.
내가 확인해본 바로는 원하는대로 로그가 찍혔다.
로드밸런스 설정
앞에 예제들은 로드밸런스 설정과는 관계가 없다. 로드밸런스라고 하면 instance1 인스턴스가 응답하지 않을 경우에 다른 서버들이 그 역활을 대신하는 것을 말한다. 이를 위해서는 woker 설정과 urlworkermap 설정을 변경해주어야 한다.
일단, 테스트를 위한 시나리오는 앞에서 서빙했던 jsp, png, css 파일들은 각각의 인스턴스들이 모두 제공하는 것으로 한다. 이렇게되면 urlworkermap 설정은 다음과 같이 바꿔주면 된다.
vim /etc/httpd/conf.d/uriworkermap.properties
Apache
1
/*=balancer
worker 이름을 balancer 라고 했는데, 이는 worker 설정파일에서 사용할 것이다.
로드밸런스는 특정 인스턴스가 죽었을 경우에 다른 서버가 그 역활을 대신하는 것이다. 이를 위해서 로드밸런스 역활을 위한 worker 이름을 정의하고 그 worker 에 로드밸런스를 위한 worker 이름을 정의해주면 된다. 기존의 worker 파일에 다음과 같이 로드밸런스 내용을 추가하면 된다.
로그의 형식은 다양하지만 대략적으로 어느 컴퓨터(IP 주소)에서 어떤 기기, 어떤 프로그램을 이용해서 어떤 웹 페이지를 접속했는지, 각 컨텐츠의 전송량등의 정보가 담깁니다.
이 문서는 아파치 로그 분석하기 에 대한 것입니다.
전송량 통계
로그 파일에 컨텐츠의 전송량이 담기기 때문에 이것들을 전부 더하면 아파치 웹 서버가 내보낸 전송량을 알 수 있겠지요? awk 쉘 스크립트로 간단하게 할 수 있습니다.
아파치 로그 전송량 계산
Shell
1
awk'{ s += $10 } END { print "Total ", s/1024/1024 " MB", "- Average ", s/NR/1024/1024 " MB", "- Access ", NR }'access_log
여기서 중요한 것이 access_log 파일에 전송량을 표시하는 위치 입니다. 위 명령어 앞줄에 ‘s += $10’ 이 있는데, 공백을 기준으로 10번째 칸이 전송량을 표시한다는 거기 때문에 전송량 표시되는 부분이 12번째 칸이라면 이것을 ‘s += $12’ 로 고쳐줍니다.
좀 더 나가서 특정 아이피에 대한 것만 계산하고 싶다면 다음과 같이 해줍니다.
특정 IP 만을 이용한 계산
Shell
1
grep"192.168.0.12"access_log|awk'{ s += $10 } END { print "Total ", s/1024/1024 " MB", "- Average ", s/NR/1024/1024 " MB", "- Access ", NR }'
grep 을 이용해서 필요로하는 컨테츠만을 뽑아서 총 전송량을 계산할 수 있습니다.
로봇에 의한 전송량도 계산할 수 있습니다. 구글 봇이 페이지를 긁어가는데 들어간 전송량은 다음과 같이 계산할 수 있습니다.
구글 봇이 긁어간 전송량.
Shell
1
grep-i"googlebot"access_log|awk'{ s += $10 } END { print "Total ", s/1024/1024 " MB", "- Average ", s/NR/1024/1024 " MB", "- Access ", NR }'
HTTP 응답코드별 트래픽 계산은 다음과 같이 할 수 있습니다.
HTTP 200 응답코드에 대한 트래픽 계산.
Shell
1
awk'($9 ~ /200/)'access_log|awk'{ s += $10 } END { print "Total ", s/1024/1024 " MB", "- Average ", s/NR/1024/1024 " MB", "- Access ", NR }'
응답코드만을 다르게하면 응답코드별로 트래픽 양을 알수 있습니다.
HTTP 응답코드 세기
HTTP 응답코드는 중요 합니다. 이를 잘 파악하면 웹 사이트에 대한 상태를 알 수도 있습니다.
Apache 설정 중에 Directory 디렉티브(Directive) 내에서 Options, AllowOverride 등을 사용할 수 있는데 이에 대해서 자세히 알아 보겠습니다.
AllowOverride
AllowOverride 는 AccessFileName 에 지정한 파일에서 아파치의 설정을 덮어쓸 수 있도록 해줍니다. 보통 AccessFileName 에는 .htaccess 를 지정해주고 DocumentRoot 에 .htaccess 파일에 아피치 설정에 대한 것을 해두면 아파치는 이 파일을 읽어서 반영해 줍니다.
만일 AccessFileName 을 지정하지 않았고 .htaccess 파일이 필요없을 경우에는 AllowOverride 를 사용할 필요가 없기 때문에 다음과 같이 None 으로 설정해주면 좋습니다.
AllowOverride None
Apache
1
2
3
<Directory"/home/nymph203/www">
AllowOverrideNone
</Directory>
AllowOverride 를 사용할때에 지정할 수 있는 옵션들이 있는데 다음과 같습니다.
FileInfo : 문서의 유형을 제어하는 지시자 사용을 허락함. 문서 유형을 제어하는 지시자에는 AddEncoding, AddLanguage, AddType, DefaultType, ErrorDocument, LanguagePriority 등이다.
Indexes : 디렉토리 인덱싱을 제어하는 지시자 사용을 허락함. 사용 가능한 지시자로는 AddDescription, AddIcon, AddIconByEncoding, AddIconByType 등이 있다.
AuthConfig : 인증 유형을 사용할 수 있도록 허용함.
Limit : 호스트 접근을 제어하는 지시어 사용을 허용함. Allow, Deny, Order 같은 지시어를 사용할 수 있다.
Options : 지정한 디렉토리를 제어할수 있도록 지시자 사용을 허용함.
AllowOverride 는 AccessFileName 에 지정된 파일에서 쓰일수 있는 기능들을 정의한다고 생각하면 됩니다.
Options
이것은 <Directory > 디렉티브로 지정한 파일시스템에 대해서 아파치 서버가 어떻게 제어할지를 지정해 줍니다. 아주 중요한 부분으로 보안의 시작점이라고 보시면 됩니다.
FollowSymLinks: 파일의 심볼릭 링크를 허용하고 아파치는 이를 이용할 수 있다.
SymLinksIfOwnerMatch: 심볼릭 링크를 허용하지만 심볼릭 링크의 소유자가 사용자여야 된다.
Indexes : 아파치가 디렉토리에 접근했는데, DirectoryIndex 지시자로 설정한 파일이 없을 경우 디렉토리안의 파일 목록을 보여준다.
Apache 는 TCP/IP 접속과 접속이 이루어진 후에 컨텐츠를 처리하는 프로세스의 권한이 다릅니다. TCP/IP 접속관련은 Root 권한으로 동작하고 이후 동작은 아파치의 설정에 따른 권한으로 실행 됩니다.
아파치의 동작 권한은 다음과 같이 설정 합니다.
httpd.conf
Apache
1
2
3
4
5
6
# User/Group: The name (or #number) of the user/group to run httpd as.
# It is usually good practice to create a dedicated user and group for
# running httpd, as with most system services.
#
Usernobody
Groupnobody
위 설정은 아파치의 컨텐츠를 처리하는 프로세스가 nobody:nobody 권한으로 동작하도록 지정한 것입니다.
그런데, 이렇게 하면 버추얼 호스트(VirtualHost) 설정을 할 경우에 보통 각 계정별로 RootDocument 를 설정하는데, 이럴경우 아파치 프로세스는 한가지의 권한으로 동작하고 모든 계정에 접근해야 함으로 각 계정에 액세스 권한을 줘야 합니다. 그래서 주로 다음과 같이 해줘야 합니다.
리눅스 계정 디렉토리 권한 설정.
Shell
1
2
3
4
5
ls-lh/home/
합계0
drwx-----x2testtest5910월423:06test
drwx-----x2test1 test15910월423:06test1
drwx-----x2test2 test25910월423:06test2
이러한 아파치 권한과 리눅스 시스템 계정별 권한때문에 공개 CMS 프로그램들(xe, gnuboard, wordpress) 등을 설치할때에 홈디렉토리의 퍼미션을 777 로 하게됩니다. 이럴경우 보안상 큰 문제가 됩니다.
아파치의 컨텐츠 프로세스마다 지정한 시스템 계정의 권한으로 동작하도록 하게 한다면 각 계정별로 퍼미션을 바꿀 필요가 없게 됩니다. 이러한 것을 가능하도록 해주는 모듈이 바로 mod_ruid2 입니다.
이 문서는 Apache mod_ruid2 설치 에 관련된 내용 입니다.
1. 설치 환경
설치 환경은 다음과 같습니다.
배포판: CentOS 7
Apache Version: 2.4.10
Apache MPM: prefork
2. mod_ruid2 설치.
mod_ruid2 프로젝트 홈페이지에서 다운로드 받고 압축을 해제한 후에 apxs 를 이용해서 다음과 같이 설치 해줍니다.
이 모듈은 프로세스의 소유권 변환을 해줌으로 보안성을 향상시키지만 다음과 같은 모듈과 호환성을 제공하지 않습니다. (함께 쓸수 없다는 이야기…)
mod_cache
mod_cache_disk
mod_cache_socache
MPM worker
MPM event
Apache 2.4.10 이후로 SSLSessionCache를 위해선 mod_cache_socache 의 의존성을 가지고 있기 때문에 mod_ruid2 를 사용한다면 SSL 제대로 동작하지 않을 가능성이 있습니다. (mod_cache_socache 는 과거의 mod_mem_cache 입니다.)
Apache 2.2 는 2005년 후반기에 발표되고 지금까지 큰 버전의 변화가 없이 사용되고 있습니다. 그러다 최근 고용량의 정적 파일 및 큰 규모의 싸이트가 많아짐에 따라서 대량 접속에도 적은 리소스를 사용하면서 빠르게 서비스 할 수 있는 웹서버가 절실해졌습니다. 이에 러시아에 한 업체가 자사 싸이트 운영을 위해서 웹 서버를 제작했고 이것을 공개했는데 그것이 바로 Nginx 입니다. Nginx 의 빠른 응답속도와 적은 리소스 사용은 그동안 Apache 서버에 답답해했던 많은 사용자들을 붙 잡았으며 현재 Nginx 의 시장점유율은 날이 갈수록 높아지는 추세 입니다.
이에 Apache 재단에서도 빠른 응답속도와 적은 리소스등 기존의 Apache 에 큰 변화를 주어야겠다고 생각했는지 거의 7년이 다 되어가던 2012년 2월달즘에 Apache 2.4를 릴리즈 합니다. Apache 2.4는 기존 Apache 2.2와 비교했을때에 프로세스 모델에 있어서 큰 변화를 준 만큼 웹서버 시장에서, 더군다나 Nginx 와의 경쟁이 더욱 치열해질 것으로 전망 됩니다.
2.새로운 기능
먼저, Apache 2.4의 새로운 기능에 대해서 정리해 보겠습니다.
(Run-time) Loadable MPMs
Multi MPMs는 이제 컴파일 타임에 Loadable 모듈로 빌트 인 될수 있습니다. Multi-Processing Modules (MPMs) 네트워크 포트를 바인등(Binding)하고 클라이언트로부터 요청을 받고 자식 혹은 쓰레드에 핸들링(Handling) 요청을 보냅니다. Apache 2.2까지는 이것을 정적 컴파일(static compile) 해야만 했습니다. 이는 Apache 를 컴파일 설치할때에 결정되어지는 것으로 이를 사용하지 않거나 사용하기 위해서는 컴파일 시에 결정을 해야 했습니다. 하지만 Apache 2.4 에서는 이를 실행 타임(Run-time)에서 결정할 수 있도록 ‘Loadable Module’ 로 기능을 제공합니다. 컴파일 설치시에 하게되는 Configuration 에서 ‘–enable-mpms-shared’ 를 사용하면 됩니다.
Event MPM
Nginx 는 ‘Event Driven’ 방식의 웹 서버로 유명합니다. 하지만 Apache 는 그동안에 ‘Event Driven’ 방식을 지원하지 않았습니다. 대신 한개의 동접 클라이언트당 한개의 쓰레드 (혹은 프로세스) 구조였고 이 때문에 한 클라이언트가 맺은 접속이 완전히 끝나지 않는한 쓰레드 혹은 프로세스가 죽지않는 방법을 사용했습니다. 이는 ‘Keep Alive’ 설정으로 존재합니다. 하지만 이 ‘Keep Alive’ 때문에 대량접속에서는 효율이 급격하게 떨어지는 문제점도 안고 있었습니다.
‘Event MPM’은 이러한 문제를 해결할 수 있습니다. ‘Event MPM’을 사용하기 위해서는 Kqueue 나 Epoll 과 호환되는 시스템이 필요합니다.
Asynchronous support
비동기 읽고/쓰기에 대한 기능을 지원합니다. (따로 설정하거나 하는건 없고 내부 구조적으로 저런걸 지원한다는 모양입니다.)
NameVirtualHost Deprecated
Apache 2.4 에서는 NameVirtualHost 가 앞으로 사용되지 않는 옵션으로 변경되었습니다. 가까운 미래에 이 옵션을 사라질 것입니다.
Config file variables
Apache 2.4 에서는 설정 파일 내에서 변수를 사용할 수 있게 되었습니다. 사용법은 다음과 같습니다.
Apache 2.4 define variables
Apache
1
2
3
Defineservernamewww.example.com
DocumentRoot/var/www/${servername}/htdocs
‘Define’ 을 이용해서 변수를 정의하면 설정 파일내에서 얼마든지 반복해서 사용할 수 있습니다.
Per-module and per-directory LogLevel configuration
모듈에 대한 LogLevel 과 각 디렉토리별 LogLevel 를 지정할 수 있게 되었습니다. 모듈에 대한 LogLevel 지정은 다음과 같습니다.
Apache 2.4 Per-module LogLevel Configuration
Apache
1
2
3
LogLevelinfossl:warn
LogLevelinfomod_ssl.c:warn
LogLevelinfossl_module:warn
각 디렉토리별 LogLevel 은 다음과 같습니다.
Apache 2.4 Per-Directory LogLevel Configuration
Apache
1
2
3
4
LogLevelinfo
<Directory"/usr/local/apache/htdocs/app">
LogLeveldebug
</Directory>
그리고 debug 위로 새로운 LogLevel 인 trace1 ~ trace8 이 추가되었습니다.
Access Control
Apache 의 접근 제어는 아이피 기반, 호스트 기반, 클라이언트 요청에 대한 특이한 것들에 대해서 ‘Order’, ‘Allow’, ‘Deny’, ‘Satisfy’ 를 이용해서 했었습니다. 하지만 Apache 2.4 로 넘어오면서 인증관련 메커니즘이 조금 바뀌면서 이를 수행하는 모듈, ‘mod_authz_host’가 새롭게 만들어졌습니다. Apache 2.2 와 Apache 2.4를 비교해 예제를 보겠습니다.
모든 요청을 거부
Apache 2.4 Access Control
Apache
1
2
3
4
5
6
#2.2 configuration:
Orderdeny,allow
Denyfromall
#2.4 configuration:
Requirealldenied
모든 요청을 허용
Apache 2.4 Access Control
Apache
1
2
3
4
5
6
#2.2 configuration:
Orderallow,deny
Allowfromall
#2.4 configuration:
Requireallgranted
example.org 는 허용 나머진 모두 거부
Apache 2.4 Access Control
Apache
1
2
3
4
5
6
7
8
#2.2 configuration:
OrderDeny,Allow
Denyfromall
Allowfromexample.org
#2.4 configuration:
Requirehostexample.org
Requirehost.netexample.edu
여기서 주의할 점은 ‘foo.example.org’ 를 ‘example.org’ 로 적는다고 해서 접근제한을 걸수 없다는 겁니다. ‘end in’ (위 예제의 .net 과 같이) 은 적용이 되지만 도메인의 일부부만을 매칭해서 전체가 적용되도록 할 수는 없습니다.
Require IP 클라이언트의 IP를 체크해서 맞으면 접속을 허용합니다.
Apache 2.4 Access Control
Apache
1
2
3
4
5
6
7
8
9
10
11
12
13
# A full IP address
Requireip10.1.2.3
Requireip192.168.1.104192.168.1.205
# A partial IP address
Requireip10.1
Requireip10172.20192.168.2
# A network/netmask pair
Requireip10.1.0.0/255.255.0.0
# A network/nnn CIDR specification
Requireip10.1.0.0/16
변경된 이름들
Apache 2.4 로 넘어오면서 변경된 이름들이 존재합니다. 다음과 같습니다.
mod_disk_cache -> mod_cache_disk
MaxClients -> MaxRequestWorkers
MaxRequestsPerChild -> MaxConnectionsPerChild
기타 변경된 것들
이외에도 변경된 사항들이 있는데 다음과 같습니다.
AllowOverride 의 기본값은 None 이다.
EnableSendfile 의 기본값은 Off 이다.
KeepAlive 는 오직 On 이나 Off 두개의 값만 가질 수 있다. 예전에는 Off나 0 이 아닌값이면 On 이였다.
AcceptMutex, LockFile, RewriteLock, SSLMutex, SSLStaplingMutex, WatchdogMutexPath 디렉티브는 단일 Mutex 디렉티브로 교체되었다.
mod_reqtimeout: 만약 이 모듈을 사용한다면 기본값이 자동으로 세팅 된다.
mod_autoindex: 이전에 무시됬던, .xhtml 파일의 타이틀을 추출하고 설명을 표시할 수 있게됐다.
NameVritualHost 디렉티브는 더 이상 어떤 영향도 없으며 대신 경고를 보여줄 것이다. 어떤 주소/포트를 조합해 가상호스트를 표시하는 것은 네임기반 가상 호스트처럼 묵시적으로 다루어진다.
mod_deflate: 압축으로 인해서 데이터보다 압축한 것이 더 커지는, 크기 오버헤드가 있다는걸 알게된다면 압축을 건너뛴다.
RewriteLog, RewriteLogLevel 디렉티브는 제거되었다. 이 기능은 이제 mod_rewrite 모듈의 LogLevel 디렉티브의 적절한 로깅 레벨을 설정하는 것으로 대체되었다. 보다 자세한 사항은 mode_rewrite_logging 섹션을 참조.
